-
I am seeing in Snort some alerts for suspicious domains, which I would like to block. However these alerts are for DNS queries to the external DNS servers I have set up in the configuration, so Snort is not able to get the IP address of the suspicious domain and to block it. If I analyse the alert pcap I can block it by hand, but this is not really desirable.
I had already set up NAT and Firewall to redirect all DNS queries to pfSense, which would then redirect them to other DNS servers, but it does not seem to be working for Snort. It works however for Squid since I am able to log the websites that have been visited by the hosts also with HTTPS.
How can I set up pfSense in such a way that Snort sees the IP address connected resulting from these queries and blocks it?
Thank you very much.
-
Not quite sure what you mean here. Can you show logs or screenshots showing what you're seeing or not seeing?
Steve
-
Sure, I'll try to be more clear.
This is what I see in Snort, lots of DNS queries for a .ml domain. The destination address is the external DNS server, not the IP of the pfSense server nor of the malicious website. As you can see Snort does not block the malicious website because it seems to be unable to get the resolved ip address of the website. I was under the impression that if I routed all DNS queries through pfSense Snort would have been able to do that, or am I missing something?Edit: If I manually analyse the logs provided by Snort then I can get the resolved address and block it, but I do not want to do that every time.
-
Hmm, I'm not aware of that functionality. It triggers on the query and not the result.
I may simply not be aware of it of course...
Steve
-
Well, it seems a bit useless then... Thank you anyway!
If somebody else is aware of any other solution I'm all ears, otherwise I will just have to remove that rule since I can do nothing about it.
-
Do you run pfBlocker ?
https://forum.netgate.com/topic/140634/finding-internal-ip-causing-block/14
-
Nope, I'm running Snort+Squid+SquidGuard.
-
@francescocarza said in DNS queries redirect to pfSense for Snort blocking:
Sure, I'll try to be more clear.
This is what I see in Snort, lots of DNS queries for a .ml domain. The destination address is the external DNS server, not the IP of the pfSense server nor of the malicious website. As you can see Snort does not block the malicious website because it seems to be unable to get the resolved ip address of the website. I was under the impression that if I routed all DNS queries through pfSense Snort would have been able to do that, or am I missing something?Edit: If I manually analyse the logs provided by Snort then I can get the resolved address and block it, but I do not want to do that every time.
Why did you black out the Destination IP in your posted screenshot? Is it an internal IP of some sort? All that alert is telling you is that device 192.168.89.95 queried that blacked-out IP address on port 53 and asked that address for the IP of a suspicious
*.mldomain. The*.mlsuffix refers to domains normally based in Mali. The purpose of the rule is to alert the security admin that a local device within HOME_NET made a query for the IP address of a domain that is generally considered questionable (that is, any domain havingmlas the suffix). The admin is then expected to investigate and determine what to do from there. It could be there is malware installed on device 192.168.89.65 -- or maybe not. Maybe it was a legitimate query?? The rule is designed to raise a flag for the admin to perform a check.There can also be other reasons for that rule being triggered. @NogBadTheBad gave one of them -- pfBlocker and other packages sometimes perform a reverse lookup on an IP to display logging information using the actual domain name. That will trigger the rule, but is totally benign.
For some applications, rules such as this one are useful. For many other folks, not so much. If the rule is not useful to you, simply disable it.
-
Yeah, even if you could see what that IP resolved to and block it automatically it wouldn't stop the client trying to resolve it again and triggering more alerts.
What you can do is block queries against .ml entirely, or reply with bogus data. That would be via your DNS server though and that appears to be external. You could do it in pfBlocker if you were using Unbound in pfSense for DNS.
If that client should in fact be doing that then consider redirecting DNS traffic to pfSense.Steve
-
@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.