|
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'.
|
Johannes 3693 Posts ISC Handler |
| Subscribe |
Oct 2nd 2013 6 years ago |
|
One issue I've been running into a lot lately is our queries being directed to DNS servers that have been listed with reserved IP addresses. One company recently posted their MX record for the domain with an IP address of 127.0.0.1. It was surprising that it took a full week to finally get the information in front of the right person for the issue to be resolved with only a few minutes of work. All the users of that particular mail system INSISTED that the problem had to be on my end and that I should fix it.
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. |
Mikel 1 Posts |
| Quote |
Oct 2nd 2013 6 years ago |
|
I have two domains with 127.0.0.1 mx records but they are domains I do not want to receive email on (and listing that as the MX generates fewer attempts to deliver to the default A record server).
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. |
Eric 12 Posts |
| Quote |
Oct 2nd 2013 6 years ago |
|
You should also consider setting a TXT record of
"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 |
| Quote |
Oct 2nd 2013 6 years ago |
|
I'm just a home hobby user who doesn't run a DNS Server (while BIND runs on my router, it is strictly a client so far as the public internet is concerned.), but I have something relevant to offer.
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. |
Michael 2 Posts |
| Quote |
Oct 3rd 2013 6 years ago |
|
dns axfr ? dns ixfr ? query denied ? recursive-clients soft limit exceeded ? dropped error ? possible error packet loop ? dns format error ? accept failed ? no matching view in class ?
found on bind source code. Regards @Rmkml |
Rmkml 11 Posts |
| Quote |
Oct 3rd 2013 6 years ago |
|
On my fallow domains I do indeed use spf and also dkim+domainkeys 'there are no mail servers that send mail for this domain' and 'all mail must be properly signed or discard it' records, which is difficult as I deleted the dkim signing keys after getting everything setup. I even dnssec signed the domains. (I could say it was just easy enough to do when I did the 'in use' domains, but I actually did the fallow ones first to make sure I understood how everything worked and wasn't going to break anything important).
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 |
Eric 12 Posts |
| Quote |
Oct 3rd 2013 6 years ago |
|
To make matters worst, infected machines are looking up hosts such as "infected-machine-id=xxx-internalnetwork=10_1_1_1-arp-table=500-admin-password-hash=whatever.infectioncontroller.com". This is not, of course, a real domain or even close to the real query. Check your favorite IDS rules (Snort) for the real ones.
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. |
Eric 1 Posts |
| Quote |
Oct 3rd 2013 6 years ago |
Sign Up for Free or Log In to start participating in the conversation!
