DNS Server triggers Snort Alert
-
Hello everyone,
I am still rather new to pfsense/snort and I find quite often that the DNS servers I use trigger an Alert:
122:24 (portscan) UDP Filtered Distributed Portscan
I see this appearing occasionally also for the secondary and tertiary DNS, but obviously the primary appears more often. There are also sometimes other alerts triggert by the DNS servers, for example gen_id 1, sig_id 2329 or gen_id 1, sig_id 25. (Access on port 53 might perhaps make sense for a reverse lookup maybe, but there are no ports mentioned. And the description also says "PortSCAN")
Could someone perhaps explain, or even better tell me where I can find a detailed description of all the Alerts.
And more important, I would appreciate some suggestions how one should deal with such alerts from DNS servers.
Does this DNS server do something bad or is this perhaps a known behaviour of DNS servers?
Or did I configure my Snort a bit "too sharp" maybe?Thanks in advance.
-
Well using resolver your going to be talking to lots and lots of name servers, and your going to talk to them on port 53 from some random high port. So yeah their answers could look like a distributed port scan because your going to see lots of traffic might look like random IPs to random ports to your wan.
Snort is going to generate lots and lots and LOTS of noise ;) The rules really need to be tweaked to not be so noisy…
And as you talk to roots, your going to see lots of answer from same IP to different ports in answer to your queries. So yeah if snort does not see/understand that you opened the connection and expected a reply then sure it could look like a portscan.
You should prob validate that you are generating the queries and the thing it is saying a port scan is not in fact a portscan - but I would bet a very large sum of money that its just noise generated by you running a resolver and talking to many different name servers.
-
Thanks John, that makes in deed some sense for me. (I am using the DNS Resolver with forwarding.)
So far so good, but I am not yet really sure how I deal with this. Please correct me if I am heading in the wrong direction:
1. The simplest solution would of course be to just add the DNS servers to the snort whitelist. Because then I could keep the "Portscan rules (There are in fact quite a few.) untouched and they could still report the real ones from other sources. But on the other hand, this would mean that I fully "trust those DNS servers", right? I mean, they could also be (ab)used or hacked, it feels a bit "too much to grant" since all I want is DNS information.
2. Alternatively I could start adding entries to the suppression_List and then suppress all types of regular appearing (only those!) alerts for which the src is one of the DNS IPs. But this would make the supression_List pretty large I guess and I fancy keeping this list rather short.
3. So the ideal solution would probably really be your suggestion and to allow the DNS IPs incoming only after I made a request, but rejection otherwise. But this sounds for me more like a FW rule, and not something snort could do. Because snort would still call out an Alert for the Portscan. Or am I wrong here? Do you have a good suggestion on how this could be realised?
Currently I tend to option 1 (whitelisting the DNS IPs), but I am not sure if I will feel good with this in the long run.
Any advice is appreciated.
-
"I am using the DNS Resolver with forwarding.)"
For what reason?? If that is the case and your forwarding, then it never talks to roots, it never talks to authoritative servers it only talks to what you forwarded it too.
your firewall will indeed block/drop any traffic that is not in answer to something it requested. Be it you log it, be it snort alerts you to it is besides the point. Traffic that is not in answer to a request, ie stateful even though its udp with dns will be dropped.
If you are resolving good luck whitelisting the name servers you talk to ;) To be honest I am not sure why anyone would care if they are being port scanned.. Traffic is dropped/blocked/ignored so who gives shit? Its noise on the internet.. If your going to try investigate all the noise there is on the net, then you will not have time to do anything else ;)
I would trim down the rules in snort that might concern you, as to a port scan - its noise..
-
Regardless of what you do snort needs to be told to ignore that DNS traffic. I'm not a snort user so I don't know if it's possible but if it's possible to tell it to ignore any outgoing TCP/UDP traffic originating from the firewall itself going to any address with destination port 53 it would be the ideal solution.
-
"I am using the DNS Resolver with forwarding.)"
For what reason?? If that is the case and your forwarding, then it never talks to roots, it never talks to authoritative servers it only talks to what you forwarded it too.
Maybe I misunderstood something, but I think I read somewhere that "Enable Forwarding Mode" basically means, that it will ask one of the DNS servers I list (preference for "Privacy DNS", so no 8.8.8.8 ). And I also find that almost all DNS resolve attempts fail, if I untick the "Enable Forwarding Mode".
So, for me it looks like it is exactly doing that. Asking the DNS that I told him to use if it cannot resolve. What is wrong about that?
What do you recommend instead?your firewall will indeed block/drop any traffic that is not in answer to something it requested. Be it you log it, be it snort alerts you to it is besides the point. Traffic that is not in answer to a request, ie stateful even though its udp with dns will be dropped.
If you are resolving good luck whitelisting the name servers you talk to ;) To be honest I am not sure why anyone would care if they are being port scanned.. Traffic is dropped/blocked/ignored so who gives shit? Its noise on the internet.. If your going to try investigate all the noise there is on the net, then you will not have time to do anything else ;)
I would trim down the rules in snort that might concern you, as to a port scan - its noise..
Thanks for that blunt, but totally true comment. You are right. Maybe I am just still in the "being curious mode" as I am still a pfsense newbee.
I am in deed already aware that portscans, pings, SQL/HTTP attempts, SSH/Telnet login attempts are more or less normal depending on your IP.
And yes, you are right, I should trust the firewall to do its job, thats why I have installed it, right?!Well, I guess I will then listen a few more days to the noise and decide then how to deal with it.
But thinking of it as >>Noise<< is probably the smartest and most realistic way to handle this. -
In forwarder mode all it does it forward, it never asks roots for anything it just asks who you forwarded to for what your asking for. That is it.
In resolver mode, it walks down the tree from roots. Hey roots who is authoritative for .com, ok thanks .com nameserver who is authoritative for domainX.com, ok thanks hey ns for domainX.com what is the IP for www.domainX.com
To why your having problems trying to resolve vs forward could be lots of reason, your ISP is crap and doing interception of your dns query and sending it to their caching forwarding server. The domains your trying to resolve you might have a shitty connection to, or they just have a shitty connection. Maybe you have dnssec enabled and that site dnssec is broken. Maybe your isp just doesn't let you talk to anything on 53 other than theirs or 8.8.8.8, etc.
You would have to investigate why the resolve doesn't work for something specific and see why its failing.
The amount of info that snort can produce can be interesting for sure.. But in the big picture most its noise ;) or false positives. Running an IPS/IDS can be very time consuming to get it to a useful tool and not just a noise maker. If you turn it on will all its rules your going to get flooded with information that most of which is going to be noise.
I personally stopped even logging udp inbound to pfsense, just noise I only log TCP syn packets. Just because its interesting to see what ports get the most hits - yeah ssh, telnet, ftp big hitters.. 1433, rdp 3389 also very popular ;)
-
In forwarder mode all it does it forward, it never asks roots for anything it just asks who you forwarded to for what your asking for. That is it.
Okay, that sounds like what I want. I have entered the DNS servers for a purpose (region, DNSsec support, privacy), so I do want my local pfsense gateway to ask those specific DNS servers for the IP. If they don't know, I guess they will ask their root. Or, my secondary is asked. - So, that seems fine for me. For example, I do not want to ask the well known 8.8.8.8 on purpose (though I have tested it, and it works too).
In resolver mode, it walks down the tree from roots. Hey roots who is authoritative for .com, ok thanks .com nameserver who is authoritative for domainX.com, ok thanks hey ns for domainX.com what is the IP for www.domainX.com
Okay, I see the difference. But I don't see the advantage.
For me of course the fastest answer the best answer (assuming it is correct of course). So, why would I prefer to wait maybe longer, to get the same answer by starting from the root. - Isn't exactly this the job of the DNS servers, like 8.8.8.8 to get the answer from "somewhere else" (=>Root method as you described)?To why your having problems trying to resolve vs forward could be lots of reason, your ISP is crap and doing interception of your dns query and sending it to their caching forwarding server. The domains your trying to resolve you might have a shitty connection to, or they just have a shitty connection. Maybe you have dnssec enabled and that site dnssec is broken. Maybe your isp just doesn't let you talk to anything on 53 other than theirs or 8.8.8.8, etc.
You would have to investigate why the resolve doesn't work for something specific and see why its failing.
Again, thanks a lot. That is very useful input.
The DNS servers that I have entered are not from my ISP. I am also quite sure that the alternate DNS servers I enter are fine. (They work also on many clients if delivered via DHCP for example.)
As far as I am aware I have a rather unrestrictive ISP, luckily. And as those DNS servers work, I believe that my ISP is not intercepting the requests. (It looks to me more like it doesn't fine ANYthing when forwarding is off.) Also DNSsec shouldn't be an issue as I chose them with that in mind.Seems odd. I guess I will have to spend a weekend in the logs testing the settings to find out. (Just to know/understand it.)
As stated above, the forwarding mode seems to be exactly what I want. Hence, I see no reason at the moment to change that.The amount of info that snort can produce can be interesting for sure.. But in the big picture most its noise ;) or false positives. Running an IPS/IDS can be very time consuming to get it to a useful tool and not just a noise maker. If you turn it on will all its rules your going to get flooded with information that most of which is going to be noise.
I personally stopped even logging udp inbound to pfsense, just noise I only log TCP syn packets. Just because its interesting to see what ports get the most hits - yeah ssh, telnet, ftp big hitters.. 1433, rdp 3389 also very popular ;)
That is in deed also true. And I have to admit, that curiosity is an issue.
I found out that one can for example set up also kind of "detection rules" in the suppression_List, for exampleevent_filter gen_id 1, sig_id 40x, type limit, track by_src, count 5, seconds 60
The 401,402,… (labeled above 40x) are ICMP Alerts, so they are an example which I understood as follows:
It counts the alerts, and if there are more than 5 of the same type (e.g. 401) triggered within 60 sec, then it blocks that IP (if auto-blocking by alert is enabled). If I got that right, then this is quite useful, as it would enable to auto-block certain IP addresses that do not just "knock", but behave "more suspicious than average". Of course this can also be done with some of the other "noise" and that is where I think one should carefully decide what is declared noise, and when it is "more" (like the same IP repetitively "knocking on the door" or more). Unfortunately I have not yet found sufficient documentation for how complex these rules can be, but I am learning. -
The advantage of resolving vs forwarding is you getting the info from the horses mouth so less likely to have to worry about a cache poisoning.
When you forward you are at the mercy of where you forwarded it to provide you with good info. No thanks I will get my own info thank you from the source.
The only advantage to forwarding is possible faster initial query for something that is not in your cache. I ask for www.somenewdomain.com that initial query has to walk the tree, but after that any client that looks for it on my network will just get the cached copy.
Where forwarding has advantage to this when you ask it for www.somenewdomain.com - its possible that someone else had already looked that up and its cached. If not then guess what your forwarder is either forwarding to somewhere else, or is going to actual resolve. So you get no real speed increase there, and it fact could be slower since you just added a step in the process. And you also just really have to trust the info your getting is current and good.
Have you validated that who your forwarding too actually supports dnssec?