Merge Pfblocker and Snort packages?
-
Wondering if this would be ideal?
I can see a lot of the same IP's getting blocked by Snort using emerging threats and RBN rules among other things.
But the good thing about pfblocker is that you can run your own list. Could that be merged in Snort as a txt file??
-
Does Pfblocker work inline or does it work on a mirrored data stream like Snort?
I do know Snort works on a mirrored data stream as not to slow the packet delivery's down while it inspects.
-
pfblocker if set up as an alias (which is the only way it should be set up anyway) just inserts the bad IPs in the normal rules, so it's more of an inline solution (assuming that's how you set up your firewall rules).
A packet coming from a bad ip does not pass through the firewall if the firewall rule is set up to block it (or reject it on the lan side). -
@jflsakfja:
pfblocker if set up as an alias (which is the only way it should be set up anyway) just inserts the bad IPs in the normal rules, so it's more of an inline solution (assuming that's how you set up your firewall rules).
A packet coming from a bad ip does not pass through the firewall if the firewall rule is set up to block it (or reject it on the lan side).That make sense assuming that firewall rules are inline with the stream. I never have questioned it, but would think firewall rules MUST and ARE inline inspected.
But Snort is inspecting a mirror image of the data stream and a bad packet will pass until snort has a chance to inspect and block further packets from coming through the firewall that match the signature. "So bad packets CAN and WILL get through before Snort can respond and block the offending IP …..... This is why Snort doesn't slow your data throughput down. If IP is listed in PFblocker it will never get pass firewall.
I assume once Snort blocks a offending IP it is blocked in the inline stream...... if not maybe Snort should be passing the IP's to Pfblocker?
So if Pfblocker is working inline no packets can pass if a IP is a match ....... snort catches it assuming milliseconds later in the mirror stream after the packet has passed through the firewall and adds to its own block list.
Sounds like their is redundancy going on with static IP addresses between Pfblocker and Snort ....... But inline is obviously superior to mirror stream inspection.
I don't think there are any static IP numbers in any of the snort signatures? If not pfblock list found online here and there have many of the offending IP's already which is great.
I'm not a expert so if I'm wrong about the function of either packages please correct me. -
Yes, snort works exactly as you mention. I started mentioning how it works a few months back and almost got rocks thrown at me. I believe at some point a bounty was actually created on my head because I said something that no other member had said to date.
The moment snort sets up a block, no further packages from that source get through, since pf (the firewall) takes over from there. Don't confuse pfblocker with pf.
Pfblocker is an easy way to enter massive amounts of IPs in pf rules. pf is what's actually causing the block.As for the redundancy with static IPs in snort, can't do anything about that. It's not a lot of redundant IPs if you follow the thread I linked.
Up to this date, that's the best way to set up both of those packages on pfsense.
EDIT: linked on another thread, just search for blueprint and it's the first result, or go here:http://forum.pfsense.org/index.php/topic,64674
-
Everything said in this thread about Snort is correct. It is what I term "pseudo-inline". By that I mean it gets mirrors (copies, actually) of the packets from libpcap and inspects them. When it finds a bad actor, it signals the pf (packet filter) engine in pfSense to add the offending IP to the firewall block list. This does mean at least one packet will make it through before Snort inserts a firm block.
I am currently working on a Suricata package for pfSense that will hopefully be truly an inline IPS. There are some wrinkles to work out with the pfSense Core Team on the inline blocking. Ermal has said he will work with me on that. Until we actually get the inline blocking wrinkles worked out, all I can say about Suricata is "hopefully" we get there… :)
As was mentioned in a previous thread, there is some duplication of effort with Snort and pfBlocker if you run the ET-RBN, ET-CIARMY, etc., rules. My suggestion would be to not run the fixed-IP list Emerging Threats rules in Snort if you are using them with pfBlocker. In that scenario let Snort inspect the packet contents for problems using the more complex rules, and let pfBlocker handle the blind blocking of suspected or known bad IP addresses based on submitted lists.
Bill
-
My suggestion would be to not run the fixed-IP list Emerging Threats rules in Snort if you are using them with pfBlocker.
Hi Bill,
The .txt Rulesets from ET are based on the Open ruleset. I have asked if there is a PRO .txt ruleset but waiting on an answer.
They also indicated that the RBN lists will be discontinued in a few weeks.