2

I have discovered a strange issue, and I hope someone can help me to fix it. If I'm capturing the ip packets on em1 network interface on port 53 with the "tcpdump -i em1 -vvv -s 0 -l -n port 53" command I'm getting strange result( below is a piece of them), continuously are coming packets from unknown IPs(4-5 IP repeatedly). On the server runs centos7 and Bind9 DNS server. If I turn the named service or the networking service off, the packets are still coming. I changed the private IP of the server from 10.10.10.100 to 10.10.10.xxx and the problem is still alive, ip packets are coming continuously to the original 10.10.10.100 IP. I have restarted the server several time, no result.

My question is that, can I ignore this? Is that a ddos like attack? Based on the fact that, with networking service off, the problem still persist, I think this can be a bug or a virus. Is it?

09:13:28.941958 IP (tos 0x20, ttl 105, id 12674, offset 0, flags [DF], proto TCP (6), length 52)
    107.167.18.163.32902 > 10.10.10.100.domain: Flags [S], cksum 0x9538 (correct), seq 2019438094, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
09:13:28.942006 IP (tos 0x20, ttl 64, id 41456, offset 0, flags [DF], proto TCP (6), length 40)
    10.10.10.100.domain > 107.167.18.163.32902: Flags [.], cksum 0x328e (correct), seq 0, ack 1, win 14600, length 0
09:13:29.128215 IP (tos 0x20, ttl 103, id 54720, offset 0, flags [DF], proto TCP (6), length 52)
    107.167.18.163.32902 > 10.10.10.100.domain: Flags [S], cksum 0x35d2 (correct), seq 2106165321, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0

The server is behind a cisco router, and on the router is a NAT rule(86.34.156.51 <-> 10.10.10.100). In the BIND DNS server I had to setup the local private IP, otherwise if the bind was configured with public IP, the DNS packets never arrived to the host which made the request, (probably the router interpreted that the 86.34.156.51 must to route back to the host (10.10.10.100)). An other issue related to this is that, the DNS packet's TTL value is always 0 when arrived to the destination host.

Here is the result with -A flag "tcpdump -i em1 -A -vvv -s 0 -l -n port 53" 

11:16:22.681589 IP (tos 0x20, ttl 77, id 55139, offset 0, flags [DF], proto TCP (6), length 52)
    107.167.22.93.59026 > 10.10.10.100.domain: Flags [S], cksum 0x47a6 (correct), seq 1337080454, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
E .4.c@.M...k..]


d...5O.:....... .G...............
11:16:22.681638 IP (tos 0x20, ttl 64, id 28261, offset 0, flags [DF], proto TCP (6), length 40)
    10.10.10.100.domain > 107.167.22.93.59026: Flags [.], cksum 0xd525 (correct), seq 0, ack 1, win 14600, length 0
E .(ne@.@.5.


dk..].5..kT na.7|P.9..%..
Szilveszter Zsigmond
  • 143
  • 1
  • 9
  • Evidently this client (`107.167.18.163`) believes you are able and willing to act as a resolver for it. The question is, who is it? Is that address inside your network? If not, how are packets getting to an unroutable address from the internet-at-large - is there some local port-forwarding going on at your gateway routing device? Work out how the traffic's getting to you first. That will probably shed light on who's originating it, and thence why. – MadHatter Feb 12 '15 at 08:37
  • That IPs(107.167.18.163,91.121.6.163, 105.100.9.198 ...) are not inside our network and I don't know who are they. I have edited my post, and I have explained the unroutable address. – Szilveszter Zsigmond Feb 12 '15 at 08:54
  • 1
    Inspecting the packets' payload may give you a hint as to why they are sending you DNS queries. (use flag `-A`) – Tim Lamballais Feb 12 '15 at 09:09
  • I have added the result with -A flag, but I can't construe. – Szilveszter Zsigmond Feb 12 '15 at 09:20
  • @Tim Just a FYI, tcpdump performs an automatic DNS protocol decode when port 53 is involved. The fact that this isn't happening is of interest. – Andrew B Feb 12 '15 at 14:57

1 Answers1

3

You have noted that the packets are arriving from outside your organisation, via a NAT rule in your router which translates 86.34.156.51 <-> 10.10.10.100. I reverse-resolve that address, and I get ns1.style2take.ro.. Clearly, this machine is advertised to the world as a nameserver. Turning the BIND service off on this host won't stop the queries from coming through; it should change what you send back (ie, some kind of reset/unreachable error when the service isn't running), but you don't say whether your tcpdumps were running when the service was on or off, so it's hard to comment further.

It's not insane that nameservers receive DNS lookup requests. Often, people are looking for open resolvers, as these are useful both for legitimate (name resolution) and improper (DDoS amplification) purposes.

If you intend that this machine should be a published nameserver, then make sure you've configured BIND properly (only to answer queries in its authoritative domains, and not to recursively-resolve, for the internet-at-large), keep up with your BIND patches, and don't worry about this traffic. In other words, let the application do application-layer filtering; a properly-configured BIND will do a better job of decidinig which queries to answer, and which to ignore, than any filtering device you might put in front of it.

If you don't intend that this machine should be a published nameserver, then get rid of that NAT rule, and make sure the address and name don't appear in any glue records or live zonefiles.

As for seeing payload content, any modern version of tcpdump with no extra flags at all should look inside DNS packets. Here's some sample output from my nameserver, ns.teaparty.net:

[me@lory mail]$ sudo tcpdump port 53
[...]
09:37:23.613422 IP nrdns08.fibertel.com.ar.57799 > ns.teaparty.net.domain: 62409 MX? enjura.com. (28)
[ and many, many more ]
MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • I have runed the tcpdump when the named and network service were off and when were on too. The nameserver must be public, and the bind is configured correctly, the recursive quesries aren't enabled. Then I'm going to ignore that traffic. – Szilveszter Zsigmond Feb 12 '15 at 10:18
  • The tcpdump without flags shows the domain names whichs ones are querrying my server. They are the followings _ns325560.ip-91-121-6_ , _customer.sharktech.net_, but I don't know how can they do that if the networking service is turned off. – Szilveszter Zsigmond Feb 12 '15 at 10:20
  • You don't tell us which is the "*tcpdump without flags*", as in one case you don't show the command, and in both cases the output suggests that some flags have been used. If you want an analysis of the traffic, may I suggest that you turn off `named` then run `tcpdump -n -n -i em1 port 53` and edit both the command and the output into the question, unaltered? In any case, **turning off a service doesn't stop people asking for it** - it should only stop any meaningful reply being sent. – MadHatter Feb 12 '15 at 10:36
  • None of the tcpdump outputs are showing automatic protocol analysis that the program performs on port 53... – Andrew B Feb 12 '15 at 14:40
  • Yes, I can see that. I don't know why that is, because as I have said my `tcpdump` does (as illustrated above). It may be that the traffic isn't DNS traffic at all; it looks more to me like the beginning of the three-way handshake. The OP says (s)he's run the dumps when "*the named and network service were off and when were on too*", but doesn't say which output corresponds to which set of constraints, so i'ts hard to say anything more concrete. – MadHatter Feb 12 '15 at 14:43
  • It was an observation in support of your point, I probably should have thrown an @OP in there. The domain names being cited in these comments aren't in the examples. – Andrew B Feb 12 '15 at 14:45
  • @AndrewB I'm sorry, my bad; thank you for clarifying. – MadHatter Feb 12 '15 at 14:45
  • Guys. What he's getting is not the usual DNS traffic. He's getting TCP traffic on port 53 which is not used to resolve names but for zone transfers. Funnily enough he's also showing three different TTL values for three different packets coming from the same IP address. Weird. – Pedro Perez Feb 16 '15 at 23:36
  • 1
    @PedroPerez yes, we noticed that; see comment above about "*this looks more like the beginning of the three-way handshake*". You should note, though, that DNS-over-TCP is also used for resolving names over a certain length, as well as zone transfers; see eg [RFC 5966](https://tools.ietf.org/html/rfc5966) s1. Dynamic routing protocol flaps mean that TTLs from a given source can vary. I'm not saying this *is* legitimate DNS traffic; only that without looking into the payload it's too early to be sure, and that in any case BIND will do a better job of that than either of us. – MadHatter Feb 17 '15 at 07:27
  • @MadHatter yup, my bad! I quickly scanned through the text but I've miserably failed to spot that. Thanks! – Pedro Perez Feb 17 '15 at 10:35