[Oisf-users] Suricata in IPS mode seems to discard some DNS requests.

[Matt Keeler]

First a little background.

My router is running Suricata 3.0 RC3 (I have been meaning to build a package for 3.0 final since it came out but haven’t gotten around to it) and a DNS/DHCP server for both IPv4 and IPv6 (dnsmasq). I have suricata configured in nfq accept mode with iptables rules in place to let Suricata be the final verdict on ALL traffic that would otherwise be accepted including incoming connections from my lan.

My current problem is that Suricata seems to be discarding some incoming DNS requests causing SSH logins to be very slow. After capturing packets and testing out a few things here is what I have found.

- Issuing getaddrinfo with AF_INET for the family returns immediately. On the network this is a single DNS query packet and a single response packet.
- Issuing getaddrinfo with AF_INET6 for the family also returns immediately. This looks the same over the network as AF_INET.
- Issuing getaddrinfo with AF_UNSPEC for the family hangs for a while before eventually returning both IPv4 and IPv6 results. What I can see is that the machine making the requests sends two DNS request packets one immediately after the other. My DNS server sees the first query and replies to it but never sees the second request. After the timeout expires for the second request I can see the resolver implementation fall back to issuing a single A record request then waiting for the response (which is successful) then issuing the second AAAA request and waiting for the response (which is also successful). The only thing different is that its waiting for the response before sending the second request.

After seeing these results I first thought it it was probably an issue with dnsmasq. So I added a new iptables rule to bypass suricata for incoming DNS traffic from my lan and accept it instead of queueing it for suricata to make a verdict. Surprisingly this fixed the issue. So now the problem seems to be suricata. Is there anything known that could cause this kind of behavior (dropping incoming UDP/DNS packets when sent in quick succession). Another interesting issue is that when this happens my eve-log logging does not contain dns events for the AAAA records. In the stats output (from eve-log) the ips section shows things being “blocked” but the drop.log file and the eve-log don’t show any information related to these even though I have them on. Any help/insight into this situation would be appreciated.

-- 
Matt Keeler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20160129/dec29fc8/attachment.html>