-
@bmeeks The destination IP is the DNS server as I mentioned. I understand the purpose of that alert, but it just seems strange to me that Snort triggers on the query and is not able to resolve the address of the website and trigger an alert on that as well. The rule is useful to me, I expected it however to be more effective and I was wondering if there is a way to make it behave in the manner I explained earlier.
@stephenw10 I have no problem with receiving these alerts, I just want Snort to block the IP address of the .ml domain automatically when it receives one. Not all .ml domains, just the ones that get queried from my LAN.
@stephenw10 said in DNS queries redirect to pfSense for Snort blocking:
If that client should in fact be doing that then consider redirecting DNS traffic to pfSense.
I should be already doing that, that is why I found strange that the local machine was querying directly the external DNS server and not the pfSense server. I am redirecting all traffic to the 53 port to pfSense, but it seems that the query is being performed through another port here.
It may simply be the case that I do not understand how Snort operates, but I would expect it to behave as I said.
-
@francescocarza
I think maybe you do not fully understand Snort and its purpose. Snort is first an IDS (Intrusion Detection System). As such it was initially designed to simply detect problematic traffic and raise alerts. Later, as Snort usage increased, the designers added the capability of blocking traffic using various interfaces (ipfw, netmap, etc.). Snort on pfSense uses a custom output plugin to perform blocking via thepf(packet filter) firewall within FreeBSD. Because of the way that custom plugin functions, every Snort alert results in a block on pfSense. But in other firewall implementations using Snort, Snort can alert on some rules but block only on others. This is accomplished by running Snort in Inline IPS mode and changing the action in a rule from ALERT to DROP. So in a given set of rules, some will result in only alerts while others will result in drops (blocks) of traffic. Snort on pfSense today cannot make this distinction: any alert results in a block when blocking is enabled. Note that Suricata on pfSense can use an Inline IPS mode and thus will support rules with either ALERT or DROP as the action. Snort on pfSense currently only supports ALERT as the rule action and then that custom blocking plugin will in turn block on every alert.Snort works fundamentally off IP addresses at Layer 3 of the OSI model. It can do scanning of packet payloads looking for text and other byte patterns indicative of malicious behavior. However, it is not a DNS server or client. It is not designed to resolve domain or host names to find their IP address and then act on that IP. Things would slow to an absolute crawl if Snort had to wait for DNS lookups to complete before it could take any action on a packet.
So back to my original point. The rule you posted about is not really designed to "block" traffic. It is simply designed to alert on something potentially suspicious so the security admin can investigate the device that generated the alert. Within pfSense today, unfortunately, that alert will also result in a block. But if you were using Suricata and the same rule, then you could have the action be alert-only if you desired.
In your environment, since the destination IP address is your DNS server, I suspect the IP is on the automatic Pass List and thus no block happens. The source IP is, I assume, within your LAN and thus it, too, is on the automatic Pass List. So nothing is getting blocked by the alert. That is actually what the alert is intended to do: raise a flag without blocking. If your LAN host actually contacted that suspicious domain and started to download something bad, it is likely Snort will identify the packet payload as malicious and some other rule would then alert and generate a block. If you want to block known bad IP addresses, there are some other Emerging Threats categories for that (ET-CIARMY and ET-DSHIELD are two examples). You can also create and load your own IP Blacklists on the IP REP tab.
-
That looks like port 53 to me. However the alerts are on the LAN interface so it may in fact be being redirected correctly.
Steve
-
@bmeeks Then I will try Suricata to see if it suits better my use case, is there any major drawbacks with respect to Snort?
-
@francescocarza said in DNS queries redirect to pfSense for Snort blocking:
@bmeeks Then I will try Suricata to see if it suits better my use case, is there any major drawbacks with respect to Snort?
No major drawbacks of Suricata over Snort or vice-versa. One thing that will show up is that some Snort rules (those from the Snort Subscriber Rules archive) will not work in Suricata. Suricata will print an error message for those rules and skip loading the ones it does not understand. This is because certain newer Snort rule keywords are not implemented within Suricata. The Emerging Threats rules will work fine (in fact, Suricata will automatically download a Suricata-optimized version of the ET rules).
There are several threads in this forum about setting up Suricata. Also read some of the Sticky Posts at the top of this sub-forum.
However, Suricata is still not going to lookup IP addresses in order to decide what to block. It behaves exactly like Snort in terms of general behavior. No IDS is going to do what you mentioned in your first post -- examine a DNS domain lookup request, do its own lookup of that domain, and then block the resulting IP address.
-
Yeah doesn't seem like you understand what and how a IPS/IDS functions... If what you want is to not let some domain be looked up be it either specific.tld or *.tld then that is not the job of a IPS/IDS..
You would do that via your local NS, be it you run pfblocker or say pihole as another example... Or just forward to some dns service that does it for you like quad9 or something, etc.
-
My understanding of what the OP originally desired was for Snort to see the attempted lookup of a suspicous domain, perform its own lookup on that suspicious domain and then pre-emptively block subsequent access to that domain's IP address. So in a way you could say that's not letting the lookup proceed. Although you could let the lookup happen but then just block the next traffic which would presumably be a connection attempt to the domain's IP address from some local host.
However, that is not how an IDS/IPS usually operates. The biggest issue with that scenario is the need to wait for a DNS lookup before taking action on the packet. Compared to network wire speeds and packet processing times, waiting for a DNS lookup to suceed could seem like an eternity unless the lookup was already cached.
-
Lets say the IPS/IDS looks up funkydomain.tld and finds out that its IP is 1.2.3.4 which is on a bad list and should be blocked. Where is it getting this list of bad IPs?
If there is a list of bad IPs that should be blocked, then there is no point to doing a query for it, etc. Just block the bad list IPs from the git go.
-
@johnpoz said in DNS queries redirect to pfSense for Snort blocking:
Lets say the IPS/IDS looks up funkydomain.tld and finds out that its IP is 1.2.3.4 which is on a bad list and should be blocked. Where is it getting this list of bad IPs?
If there is a list of bad IPs that should be blocked, then there is no point to doing a query for it, etc. Just block the bad list IPs from the git go.
@johnpoz -- Yep! Agree 100%. That's what IP Reputation Lists are all about in an IDS and is also the basis for pfBlocker. Just block the IP individually or by entire network blocks if necessary. Don't bog down the IDS with having to do its own DNS lookups.
-
Thanks everybody for the replies! I understand it's not Snort's job to resolve the domain and I don't have any problem with seeing these kinds of alerts. However I would have at least expected it would be able to show me which domain is being looked up, moreover once the communication is established (e.g. someone visits the website or downloads something from it) Snort would kill that state and put the IP in the blacklist.
-
This post is deleted!
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.