DNS BIND traffic capture ICMP/UDP

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

DNS BIND traffic capture ICMP/UDP

Daniel Dawalibi

Hello

 

We observed an unusual traffic combining ICMP and UDP packets while running the tcpdump command on the DNS caching server

Kindly note that only UDP DNS traffic is allowed on this server (ICMP is not allowed from outside to DNS server)

Any help regarding this issue? Why we are getting ICMP and UDP requests? Could it be an attack?

 

 

Logs:

 

# tcpdump –n icmp

 

15:41:05.054237 IP 10.151.130.74 > DNSIP: ICMP 10.151.130.74 udp port 52003 unreachable, length 52

15:41:05.064449 IP 10.75.6.36 > DNSIP: ICMP 10.75.6.36 udp port 50162 unreachable, length 52

15:41:05.067953 IP 10.33.10.155 > DNSIP: ICMP 10.33.10.155 udp port 50233 unreachable, length 52

15:41:05.067958 IP 10.75.15.162 > DNSIP: ICMP 10.75.15.162 udp port 53847 unreachable, length 52

15:41:05.072727 IP 10.33.12.219 > DNSIP: ICMP 10.33.12.219 udp port 51024 unreachable, length 52

….

Example: 10.151.130.74 (client source IP)

DNSIP: DNSServer IP

 

Regards

Daniel


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DNS BIND traffic capture ICMP/UDP

Ray Bellis
On 15/01/2016 13:48, Daniel Dawalibi wrote:

> Hello
>
>  
>
> We observed an unusual traffic combining ICMP and UDP packets while
> running the tcpdump command on the DNS caching server
>
> Kindly note that only UDP DNS traffic is allowed on this server (ICMP is
> not allowed from outside to DNS server)
>
> Any help regarding this issue? Why we are getting ICMP and UDP requests?
> Could it be an attack?

The far end is complaining that responses that your server has sent
cannot be delivered to the originator because there's no longer anything
listening at the source port from which the DNS request came.

This could be for several reasons:

1.  the far end's stateful firewall has "timed out" the state it was
    maintaining for its own outgoing UDP query

2.  the far end ran out of state memory (similar to 1)

3.  the packet didn't really come from there in the first place (i.e.
    the source was spoofed)

Your own firewall is likely permitting the inbound ICMP (despite rules
prohibiting unsolicited inbound ICMP) because as far as it's concerned,
these are *not* unsolicited ICMP packets - they relate to an existing flow.

Ray


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DNS BIND traffic capture ICMP/UDP

Warren Kumari
In reply to this post by Daniel Dawalibi


On Fri, Jan 15, 2016 at 8:49 AM Daniel Dawalibi <[hidden email]> wrote:

Hello

 

We observed an unusual traffic combining ICMP and UDP packets while running the tcpdump command on the DNS caching server

Kindly note that only UDP DNS traffic is allowed on this server (ICMP is not allowed from outside to DNS server)

Any help regarding this issue? Why we are getting ICMP and UDP requests? Could it be an attack?

 

 

Logs:

 

# tcpdump –n icmp

 

15:41:05.054237 IP 10.151.130.74 > DNSIP: ICMP 10.151.130.74 udp port 52003 unreachable, length 52

15:41:05.064449 IP 10.75.6.36 > DNSIP: ICMP 10.75.6.36 udp port 50162 unreachable, length 52

15:41:05.067953 IP 10.33.10.155 > DNSIP: ICMP 10.33.10.155 udp port 50233 unreachable, length 52

15:41:05.067958 IP 10.75.15.162 > DNSIP: ICMP 10.75.15.162 udp port 53847 unreachable, length 52

15:41:05.072727 IP 10.33.12.219 > DNSIP: ICMP 10.33.12.219 udp port 51024 unreachable, length 52

….

Example: 10.151.130.74 (client source IP)

DNSIP: DNSServer IP

 


Your description is either incomplete, or incorrect (or at least sine set of things is misconfigured) -- without additional information it will be difficult / impossible to assist.

1: You state that you observe traffic while running tcpdump **on the caching server**.
2: You state that "ICMP is not allowed from outside **to** DNS server" (emphasis mine) - this implies that ICMP is supposed to be filtered before reaching the server, not e.g iptables *on the server*.
3: The tcpdump output shows traffic from client IPs (presumably "outside") to the DNS server. 

I do not see how all of the above can simultaneously be true
A: What are the actual IPs involved?
B: What are you counting as "outside" (are the client IPs "inside" or "outside"?)?. 
C: Where are you filtering the ICMP, and, more importantly, why are you filtering ICMP (it is needed to make IP work properly...)
D: How busy is the server / what percentage of ICMP responses to DNS queries? 
E: What is the connectivity of the server? It is likely that resolutions are taking significant time, and the clients have a: given up or b: already gotten the replies from another recursive?


This could be an attack (e.g spoofed packets as part of a cache poisoning attempt).... or it could be perfectly normal operation -- eliding the IP addresses and not providing more information makes it imposs^W hard to tell....

W
 

Regards

Daniel

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: DNS BIND traffic capture ICMP/UDP

Kevin Darcy

I would also recommend looking deeper into the packet capture to determine what queries were being responded to. As Warren pointed out, if the initiator times out its original query, it will either fail the whole lookup, or at least move to another resolver, so in either case the original socket is closed and your caching server get an “ICMP Port Unreachable” when it sends its response. But this resolution slowness might not be for *everything* that a particular caching server tries to resolve; it might only be for certain names. Selectively-slow resolution can have multiple causes, but it might be worth checking into.

 

If this were a DoS attack/attempt, then the volume of actual query/response traffic – which has a much greater resource impact on your server -- would be greater than the ICMP traffic, so it would be pretty obvious that that’s what it was. Occasional or sporadic “ICMP Port Unreachable”s are more likely to be an unintentional effect of an infrastructure problem, or possibly just bad client behavior (e.g. not waiting long enough for the lookup to finish).

 

                                                                                                                                                                                                                - Kevin

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Warren Kumari
Sent: Friday, January 15, 2016 11:32 AM
To: Daniel Dawalibi; [hidden email]
Subject: Re: DNS BIND traffic capture ICMP/UDP

 

 

On Fri, Jan 15, 2016 at 8:49 AM Daniel Dawalibi <[hidden email]> wrote:

Hello

 

We observed an unusual traffic combining ICMP and UDP packets while running the tcpdump command on the DNS caching server

Kindly note that only UDP DNS traffic is allowed on this server (ICMP is not allowed from outside to DNS server)

Any help regarding this issue? Why we are getting ICMP and UDP requests? Could it be an attack?

 

 

Logs:

 

# tcpdump –n icmp

 

15:41:05.054237 IP 10.151.130.74 > DNSIP: ICMP 10.151.130.74 udp port 52003 unreachable, length 52

15:41:05.064449 IP 10.75.6.36 > DNSIP: ICMP 10.75.6.36 udp port 50162 unreachable, length 52

15:41:05.067953 IP 10.33.10.155 > DNSIP: ICMP 10.33.10.155 udp port 50233 unreachable, length 52

15:41:05.067958 IP 10.75.15.162 > DNSIP: ICMP 10.75.15.162 udp port 53847 unreachable, length 52

15:41:05.072727 IP 10.33.12.219 > DNSIP: ICMP 10.33.12.219 udp port 51024 unreachable, length 52

….

Example: 10.151.130.74 (client source IP)

DNSIP: DNSServer IP

 

 

Your description is either incomplete, or incorrect (or at least sine set of things is misconfigured) -- without additional information it will be difficult / impossible to assist.

 

1: You state that you observe traffic while running tcpdump **on the caching server**.

2: You state that "ICMP is not allowed from outside **to** DNS server" (emphasis mine) - this implies that ICMP is supposed to be filtered before reaching the server, not e.g iptables *on the server*.

3: The tcpdump output shows traffic from client IPs (presumably "outside") to the DNS server. 

 

I do not see how all of the above can simultaneously be true

A: What are the actual IPs involved?

B: What are you counting as "outside" (are the client IPs "inside" or "outside"?)?. 

C: Where are you filtering the ICMP, and, more importantly, why are you filtering ICMP (it is needed to make IP work properly...)

D: How busy is the server / what percentage of ICMP responses to DNS queries? 

E: What is the connectivity of the server? It is likely that resolutions are taking significant time, and the clients have a: given up or b: already gotten the replies from another recursive?

 

 

This could be an attack (e.g spoofed packets as part of a cache poisoning attempt).... or it could be perfectly normal operation -- eliding the IP addresses and not providing more information makes it imposs^W hard to tell....

 

W

 

Regards

Daniel

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users