CSAM: Misc. DNS Logs
As Adrien mentioned, we are trying to focus on "interesting" logs during October to celebrate "Cyber Security Awareness Month". For security professionals is is important to be aware of what your logs are trying to tell you. We are no looking for ground breaking new events, but just the "stuff you always wondered about what it meant".
I am starting today with a couple of DNS logs. If you haven't seen logs like this yet: You are not doing your job well protecting your network ;-)
I kept the logs as original as possible, but masked out a few IP addresses using "X" and some hostnames with 'example.com'.
1 - RFC 1918 Response
Oct 2 14:32:36 nsint named[31794]: client X.X.X.X#50873: RFC 1918 response from Internet for 1.10.64.10.in-addr.arpa
In this case, one of my internal hosts tried to reverse reolve the address 10.64.10.1. 10.0.0.0/8 is however reserved address space per RFC 1918, so this lookup just doesn't make much sense. The DNS server (named) is warning me about this lookup.
2 - FORMERR
Oct 2 14:16:01 nsint named[31794]: error (FORMERR) resolving 'ocsp.verisign.net/AAAA/IN': 199.7.59.206#53
One of my hosts tried to connect to ocsp.verisign.net. "OCSP" is a web service used to check if certifiates are valid. You will see connections to this host name from your browser as you visit some HTTPS sites. My network is dual stack, so hosts will attempt IPv4 (A) as well as IPv6 (AAAA) address lookups. Looks like Verisign doesn't support IPv6 and doesn't know what to do with AAAA queries so it is sending a format error (FORMERR) back. This caught my eye because of the security relevance of OCSP. But then again, there is nothing I can or have to do about this error.
3 - DHCP Dynamic Updates
Oct 2 14:27:25 nsint named[31794]: client X.X.X.X#38155: signer "dhcpkey" approved Oct 2 14:27:25 nsint named[31794]: client X.X.X.X#38155: updating zone 'example.com/IN': deleting an RR at laptop.example.com TXT
My DHCP server is configured to update DNS whenever it sees a new host. To authenticate and encrypt these updates, it uses a key (I call it "dhcpkey"). Since the request came from the DHCP server (masked IP address) and was approved, all is well and this is normal. I would be concerned if these requests get rejected and/or came from an IP address different then the DHCP server.
Here is a log entry for a denied update:
Oct 2 14:03:40 nsint named[31794]: client 10.5.0.254#53419: update 'lexample.com/IN' denied
In this case it turned out to be a misconfiguration of the respective zone. Remember: Watching your logs not only keeps attackers out, but also makes your network perform better!
4 - REFUSED
Oct 2 12:47:53 nsint named[31794]: error (unexpected RCODE REFUSED) resolving 'example.com/A/IN': 206.127.24.8#53
Here a name server I connected to to lookup example.com refused the query. Odd, as the domain was valid. Could be a misconfigured DNS server, or a network device (Anti-DoS?) interfering with the query.
Got any other DNS logs?
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
Currently, I'm still watching an issue with one of the nation's largest telecom providers. For well over a month they've had their primary DNS server listed with an IP address of 172.29.0.1, which is also a reserved address. I've sent emails to 4 different administrative and technical contacts within their corporation, as well as 2 of their sales staff to try to get the issue resolved.
There appears to be a rampant problem with IT staffs not only failing to inspect their logs, but also a lot of negligence in even inspecting the DNS records they post out there for the rest of the world to find their systems.
Anonymous
Oct 2nd 2013
1 decade ago
What gets me is I see an average of roughly one to two million lookup requests PER DAY for one of the mx records. (And last time I bothered to check, I was looking at less than ten thousand hosts doing the lookup. Also the TTL for the mx records is 6 months, but who pays attention to that I guess.) The other one not so much.
They're both abandoned domains our company used at one time that we don't use anymore; the only thing I point them at is cnames to our newer web server address. We've not dumped them just because we still get a paltry amount of hits per month that come in via them and really, domains are cheap.
Anonymous
Oct 2nd 2013
1 decade ago
"v=spf1 -all"
That is an SPF record that says to reject all email FROM this domain. That can help keep your unused domains from being used for spam or phishing.
Anonymous
Oct 2nd 2013
1 decade ago
I do log metadata of packets arriving for ports that aren't listening. Among TCP SYNs and UDP packets, by far the most common type (7,427 out of 13,948 last month) are UDP 53. Recently, most came from hosts with no reverse DNS, from two disparate blocks both assigned to Nintendo of America.
A few years back, I took a closer look by running tcpdump for a while. The most common pattern was bursts of three packets all asking for my in-addr.arpa PTR. I think it's an attempt at a stealth ping, based on the faulty assumption that all resolvers are also servers authoritative for their own rDNS.
Anonymous
Oct 3rd 2013
1 decade ago
found on bind source code.
Regards
@Rmkml
Anonymous
Oct 3rd 2013
1 decade ago
I put in srv records as well for the requests I generally see, all pointing to the same local.example.com which resolves to 127.0.0.1
I rarely see requests for those records though, it's mainly tons of mx lookups.
My zonefile looks something like this
$ORIGIN example.com.
$TTL 12w
@ IN SOA ns1.example.org. dnsadmin.example.org. (
123456789 ; serial
4d ; refresh
1h ; retry
12w ; expire
1d ; minimum
)
IN NS ns1.example.org
IN NS ns2.example.org.
IN NS altns.example.net.
IN A 192.0.2.135
IN MX 0 local.example.com.
IN TXT "v=spf1 -all"
default._domainkey IN TXT "v=DKIM1; p=dkimkeystring; t=s"
IN TXT "dkim=discardable"
_adsp._domainkey IN TXT "dkim=discardable"
_ssp._domainkey IN TXT "dkim=discardable"
_domainkey IN TXT "o=."
local A 127.0.0.1
www CNAME www.example.org.
;
; www.example.org is 192.0.2.135
; CNAME is better in practice but example.com is given explicit because cname is invalid there.
;
$INCLUDE example.com.keys
Anonymous
Oct 3rd 2013
1 decade ago
Good network design forces clients to local DNS servers which use forwarder to the core. So IDS's see core servers doing lookups for those domains/servers/infections.
If your core DNS is a Microsoft DNS server the only way to log client requests is in debug mode. Microsoft recommends against running these DNS servers in debug mode. So where does that leave everyone? Blind.
Anonymous
Oct 3rd 2013
1 decade ago