Suricata v4.1.5 Release Notes (now available for pfSense-2.4.4 RELEASE)
-
@Bob-Dig said in Suricata v4.1.5 Release Notes (now available for pfSense-2.4.4 RELEASE):
Just a Warning, also had the problem described here with the update.
I'll look into that and put a fix for it, if necessary, into the next package update.
-
Did not have the problem, update went just fine.
Thank you for adding the metadata option! -
Also it seems not blocking everything again.
-
@Bob-Dig said in Suricata v4.1.5 Release Notes (now available for pfSense-2.4.4 RELEASE):
Also it seems not blocking everything again.
What is the "Remove Blocked Hosts Interval" option set for on the GLOBAL SETTINGS page? There appears to be a 6 hour time difference in the alert times shown in your screen capture (03:56 for the highlighted alert versus 09:52 for the next alert up). Perhaps the cron task has already removed the blocked host? The task will remove blocks for hosts that have not seen additional traffic for the time period specified by the setting. The suggested setting in the help text for that control is 1 hour.
-
@bmeeks You could be right. I changed it recently and now it is only one hour. I will change that again to 24 hours. Thanks and sorry for the "false alarm".
-
@Bob-Dig said in Suricata v4.1.5 Release Notes (now available for pfSense-2.4.4 RELEASE):
@bmeeks You could be right. I changed it recently and now it is only one hour. I will change that again to 24 hours. Thanks and sorry for the "false alarm".
24 hours is unnecessary. Frankly, anything beyond say 10 minutes is overkill. Think about it this way, if Suricata blocked it the first time, then it will block it again if the same traffic shows up later. Why persist the block of a host for hours?
-
@bmeeks To not get confused, like I got before, but also to watch that it works at all, I would guess.
-
@Bob-Dig said in Suricata v4.1.5 Release Notes (now available for pfSense-2.4.4 RELEASE):
@bmeeks To not get confused, like I got before, but also to watch that it works at all, I would guess.
If you just want to watch the IDS/IPS working, then a short duration block is sufficient.
The main reason I mentioned the block duration is I frequently have folks post here wanting blocks to persist basically forever and to even survive a firewall reboot. Some have thought it horrible that blocks in Suricata and Snort don't survive a firewall reboot. That tells me those users have not carefully thought things through and likely are not understanding how the IDS/IPS truly works. Why would it be beneficial to persist blocks forever?
What happens if you are running the IDS/IPS on your WAN and all the normal Internet noise is triggering blocks by the thousands per day or even per hour on a busy network (by the way, the default "deny inbound" rule in pfSense is going to block that traffic anyway)? What happens after say a month or two of running like that and you now have a million or more individual IP addresses in firewall block rules? How much CPU horsepower and RAM are you going to need to handle that load? What about as the load continues to increase as you add more and more and more blocked hosts to the list (via persisting blocks forever). Remember that down in the bowels of your firewall there are lines of code executing that are examining the source and destination IP address of a packet against the IP addresses listed in the firewall's block rules. It's basically asking "does it match this one? No, then does it match this one? No, then what about this one, etc.. and on and on". At some point you will need a Cray quantum supercomputer in order to just maintain a 300 Mbits/sec download through your firewall ... . Because while the firewall is busy comparing a given packet's IP addresses to all the stored IPs in the block list, that packet is just sitting there. So throughput obviously begins to suffer as the required number of IP comparisons grows.
And to me, implicit in this idea that persisting IDS/IPS blocks is a good idea, is what must be the assumption that the IDS/IPS is only good enough to recognize the nefarious threat traffic once, and if that traffic shows up again the IDS/IPS will surely miss it that next time and so we need a persistent block in place. That really would be the only reason to want a persistant block. But that is not reality. If the IDS/IPS detected the nefarious traffic once, it will surely detect it again and block again if necessary. There is no need whatsoever to burden your firewall with thousands of persisted blocks from previous IDS/IPS alerts.
-
I had this problem, at least it seems, with pfBlockerNG, where I blocked almost every country and that was to much for the firewall, had problems with my favorite game.
But I am running Suricata only on the LAN-interface and the blocklist is small. But I get your point. -
Hmmm, but how is this even possible?
There was a two minute delay between the alerts.
-
@Bob-Dig said in Suricata v4.1.5 Release Notes (now available for pfSense-2.4.4 RELEASE):
Hmmm, but how is this even possible?
There was a two minute delay between the alerts.
How is what possible?
If you asking about the same IP addresses showing on the alerts tab that is normal. You have to understand where the IDS/IPS is located in the packet chain versus where the blocking is happening.
Suricata runs (in Legacy Mode) directly on the interface driver using libpcap to get a copy of every packet that hits the interface. This all happens out in front of the pfSense firewall. Blocking is done by the firewall, not Suricata. When Suricata sees an "alert", it sends that IP address downstream to the firewall and says "from now on, block this". The IP address is added to the snort2c
pf
table and then, so long as the IP remains in that table, the firewall will block traffic from that IP address from reaching the kernel network stack. However, out there on the physical NIC interface Suricata will continue to see packets arriving from that IP and it will still log the alerts. But the IP is already blocked as evidenced by the red X icon.So your screen capture above is perfectly normal. Go read this Sticky Thread to learn a bit more about how Legacy and Inline IPS mode actually operate. That should help you understand why you see what you see on the ALERTS tab.
-
@bmeeks Suricata runs here on the LAN Interface so I thought it would be blocked first. Thanks for your clarification.
-
@Bob-Dig said in Suricata v4.1.5 Release Notes (now available for pfSense-2.4.4 RELEASE):
@bmeeks Suricata runs here on the LAN Interface so I thought it would be blocked first. Thanks for your clarification.
Look at the SRC. I suspect that is one of your LAN hosts, so that traffic hits Suricata on the LAN interface before the firewall sees the traffic. In this case your LAN host was attempting to communicate with the external host at 192.2.128.131. The external host is going to be blocked by the firewall, but Suricata is seeing the communication attempt before the firewall does because this is traffic inbound to the LAN interface from your LAN host destined for that remote IP on the Internet. However, the traffic is going to be blocked by the firewall. You can tell by noting the red X beside the destination IP.
The traffic flow when using an IDS/IPS is always like this for inbound traffic:
Physical NIC --> IDS/IPS --> firewall (rules)
This is the same for any interface (LAN, WAN, DMZ, etc.).
For outbound traffic (i.e., traffic leaving your firewall the flow chain looks like this:
firewall (rules) --> IDS/IPS --> Physical NIC