Snort - Attempted Denial of Service - should I be concerned?
-
Hello everyone,
I installed Snort yesterday just to see how it works and I enabled the free comunity rules. Since then I get every few hours Snort alerts because of a DoS attempt. It comes from multiple ip adresses but only one in every few hours. Do I need to be concerned or are these just bots randomly scanning? My pihole is listening on port 53 and dont seem to see anything unusal.
-
Do you have a public facing DNS server in your network? By that I mean do you offer a public DNS service for anyone on the Internet to connect with?
If the answer to the above questions is "NO", then you should not be running DNS server rules in Snort. This is a perfect example of something I've harped on for several years. Only run the IDS/IPS rules that mitigate actual vulnerabilities that exist on your internal networks. If you are not running an internal DNS, E-Mail, or web server that allows public connections (meaning from the Internet), then you generally do not need to run any of the IDS/IPS rules that protect DNS servers, e-mail servers, or web servers. Disable those rules. I assume your Pi-Hole server is only accessible by LAN clients and not by public Internet clients. And those LAN clients will communicate directly with the Pi-Hole server through the network switch (port to port) and never go through the firewall if they are on the same subnet. Thus having the rules alerting above enabled is not doing anything except generating useless alerts. Those alerts you posted are simply random hosts on the Internet probing for an open port 53 on your WAN. Hopefully you have that port closed if you are not offering a public DNS server to the Internet at large.
You are running Snort on the WAN interface. That means it is going to alert on all of the Internet "noise" out there. Snort (and Suricata) sees network traffic directly off the hardware NIC before the pfSense firewall engine has processed the traffic. That means Snort sees the junk before any firewall rules can filter it out. When you put the IDS/IPS on the WAN, it's going to see all the Internet noise and alert on traffic that the firewall's WAN rules are simply to going to drop as soon as the traffic hits the
pffirewall engine. So, Snort spent CPU cycles and consumed RAM analyzing that traffic for absolutely nothing. It's going to be blocked at the next step anyway. Much better to put the IDS/IPS on internal interfaces such as the LAN. That way the WAN firewall rules will drop all the "noise traffic" and thus not burden the IDS/IPS with inspecting traffic the default firewall rules on the WAN are going to drop anyway. When running on the LAN or other internal interfaces, the IDS/IPS can concentrate on just the traffic originating from or travelling to your LAN or other internal clients.
-
@bmeeks
Question for you then. Fledgling cloud hosting company that’s using pfsense on the edge to provide routing. If there are workloads hosted by folks behind the firewall such as DNS servers or Wordpress or really whatever they want, does it make sense to run snort? Not sure how an AWS would handle this but what’s the best way to handle this at a very small scale? -
@michmoor said in Snort - Attempted Denial of Service - should I be concerned?:
@bmeeks
Question for you then. Fledgling cloud hosting company that’s using pfsense on the edge to provide routing. If there are workloads hosted by folks behind the firewall such as DNS servers or Wordpress or really whatever they want, does it make sense to run snort? Not sure how an AWS would handle this but what’s the best way to handle this at a very small scale?So, if the cloud hosting company has clients that run such services open to the public (DNS, e-mail, etc.), then an IDS/IPS running a carefully tuned set of rules might be prudent. Just realize that it is subject to alerting on a lot of noise in addition to the occasional actual threat. And also remember that other than DNS, the bulk of all the other traffic the IDS/IPS can see is probably going to be encrypted and thus pretty much opaque to Snort or Suricata.
As the hosting provider, I'm not sure I would enable blocking in the scenario you described. At least I would not enable blocking unless I had a dedicated IDS/IPS security admin whose sole responsibilty was to watch the IDS/IPS to be sure it did not block my customers' traffic on false positives. That would be the fastest way to lose those customers
.My comment in the post above is more applicable to small enterprises or home users. Those will likely never be running public accessible DNS services. And no home user should ever be running a DNS server open to the public.
My take here is that if you are a corporate enterprise (say Fortune 500 or larger), then you are probably not going to be running firewalls such as pfSense or OPNsense on your perimeter. It is probably going to be one of the big three vendors that cost a ton of money per year for software contracts. If you are a small enough enterprise that open-source and/or free firewalls fit your use case (and get the nod from your executive suite), then it is very likely that you will not have public-facing DNS servers and probably no public-facing web servers directly on your network.
-
@bmeeks said in Snort - Attempted Denial of Service - should I be concerned?:
As the hosting provider, I'm not sure I would enable blocking in the scenario you described.
Seeking advice if such a thing would really be appropriate for a fledging cloud hosting company haha
I agree with you completely regarding regarding firewall choices but for the small price of two 8300s, you cant go wrong especially with startup costs being what they are.
I am on the side of not enabling an IPS anyway because who really has the time to disect each and every alert for customers who in theory can be doing anything they want in their VPC. -
@michmoor said in Snort - Attempted Denial of Service - should I be concerned?:
@bmeeks said in Snort - Attempted Denial of Service - should I be concerned?:
As the hosting provider, I'm not sure I would enable blocking in the scenario you described.
Seeking advice if such a thing would really be appropriate for a fledging cloud hosting company haha
I agree with you completely regarding regarding firewall choices but for the small price of two 8300s, you cant go wrong especially with startup costs being what they are.
I am on the side of not enabling an IPS anyway because who really has the time to disect each and every alert for customers who in theory can be doing anything they want in their VPC.The main thing I see here on the pfSense forum- and also to about the same degree over on the OPNsense forum where I sometimes lurk- is a fair number of users that do not really understand how an IDS/IPS works nor how much time, effort, and skill it takes to administer one. They seem to think it is the same as any generic anti-virus product. Just enable all the rules, and you are automatically "secure". But then, when stuff stops working because of all the IDS/IPS false positives, they are back here on the forum posting and wondering why things are broken
. This is especially true with home users of such packages, but I also see it from time to time with folks looking after commercial networks.An IDS/IPS needs constant attention from a skilled admin. It WILL generate false positives -- and many more of them than legitimate alerts! You must, as the admin, have the skills to sort out false positives from real threats. You also must have the skills to identify the actual vulnerabilities that exist in your protected networks and know how to choose and enable only the rules that will mitigate those vulnerabilities. That's how you reduce the rate of false positives.
-
@bmeeks it took me years of fine tuning and finesse to get mine to work the way I want, and ohhh does it work beautifully now.
Thank you bmeeks
