Snort IPrep
-
In Snorts IPrep Processor,
I have blocklists/Whitelists on WAN and LAN.
setup as - Inner, Whitelist, Unblack
Lan has the RFC 1918 checked.It seems that if an address is in the Blacklist and Whitelist, that the Blacklist supercedes?
I had to physically remove an entry in the blacklist to get it thru.Steps
Added a new entry to the Whitelist.
Clicked Save
Removed blocked entry from Blocked Snort TabDo the Suppression Lists work with the IPrep Processor? I would like my outbound mail Server to skip the IPrep processor.
I added this on the LAN Suppress list. (From what I can see it doesnt seem to work)
#(spp_reputation) packets blacklisted
suppress gen_id 136, sig_id 1, track by_src, ip xx.xx.xx.xx(I dont think I would need this on the WAN side?)
-
**** UPDATE ****
At 1pm EST, the blocklist script did an list update and added to the Blocklist the same address that I manually removed previously.
The address is also in the whitelist.
This time, it seems to have maintained the Whitelist Status and not blocked the address?
I also did a restart of the WAN snort interface previous to the list update. Not sure if that did anything?
-
@BBcan17:
In Snorts IPrep Processor,
I have blocklists/Whitelists on WAN and LAN.
setup as - Inner, Whitelist, Unblack
Lan has the RFC 1918 checked.It seems that if an address is in the Blacklist and Whitelist, that the Blacklist supercedes?
I had to physically remove an entry in the blacklist to get it thru.Steps
Added a new entry to the Whitelist.
Clicked Save
Removed blocked entry from Blocked Snort TabDo the Suppression Lists work with the IPrep Processor? I would like my outbound mail Server to skip the IPrep processor.
I added this on the LAN Suppress list. (From what I can see it doesnt seem to work)
#(spp_reputation) packets blacklisted
suppress gen_id 136, sig_id 1, track by_src, ip xx.xx.xx.xx(I dont think I would need this on the WAN side?)
The Suppress List does not function with the IP REP preprocessor. The IP REP stack is the very first thing a packet goes through, and any match (whitelist or blacklist) is immediately acted upon and further Snort action on the packet stopped (that is, it is not inspected any further).
There is a setting on the IP REP tab for an interface that controls the behavior when an IP is on both the whitelist and blacklist. You can set which has "priority". Normally the whitelist has priority. In this new Snort GUI, a whitelist for the IP REP is not the same as the old whitelists on the old WHITELISTS tab. Those kinds of whitelists are now called PASS LISTS.
Snort should be silently restarting/reloading the configuration when you save IP REP changes.
Bill
-
Thanks Bill,
I had two IPs that I added to the IPrep Whitelist.txt file. I click "Save" and it shows the new updated time correctly in IPLists.
However, it doesn't allow the IPs to pass. It continually reapplied a Block after I remove the blocks.
I tried a pkill -HUP snort (didn't change anything)
I had to Stop the interface and restart to get it to allow the new ip entry in the whitelist to work. I did this twice today already.
Not Sure if anyone else is experiencing this behavior?
So is there anyway apart from the Whitelist file for the interfaces to allow my mail server full outbound access? Would a Firewall Lan rule allow that traffic to bypass Snorts IPrep? Reason being, a mail server gets themselves on a Blacklist. If I use an DNSRBL that lists them, my mail server will block receipts of their mail, but I have no issue in sending mail to their domain while they get themselves off a spam blocklist.
-
@BBcan17:
Thanks Bill,
I had two IPs that I added to the IPrep Whitelist.txt file. I click "Save" and it shows the new updated time correctly in IPLists.
However, it doesn't allow the IPs to pass. It continually reapplied a Block after I remove the blocks.
I tried a pkill -HUP snort (didn't change anything)
I had to Stop the interface and restart to get it to allow the new ip entry in the whitelist to work. I did this twice today already.
Not Sure if anyone else is experiencing this behavior?
So is there anyway apart from the Whitelist file for the interfaces to allow my mail server full outbound access? Would a Firewall Lan rule allow that traffic to bypass Snorts IPrep? Reason being, a mail server gets themselves on a Blacklist. If I use an DNSRBL that lists them, my mail server will block receipts of their mail, but I have no issue in sending mail to their domain while they get themselves off a spam blocklist.
I think I know what the problem is with the blacklist IP. Snort needs a physical stop and start again (a cold restart) instead of a hot restart because of the Spoink plugin used on pfSense. The Spoink plugin that does the actual insertion of a block is an output plugin. I can change the hot-restart in the code to a cold-restart and that should help.
As for your DSNRBL problem, there is no good fix. Snort blocks are inserted in one of the very first tables in the packet filter firewall. That is hard-coded into pfSense itself. Blocks put in are hit before any user rules are encountered in the firewall chain.
Bill
-
I think I know what the problem is with the blacklist IP. Snort needs a physical stop and start again (a cold restart) instead of a hot restart because of the Spoink plugin used on pfSense. The Spoink plugin that does the actual insertion of a block is an output plugin. I can change the hot-restart in the code to a cold-restart and that should help.
Thanks for the reply. Could this be a patch or would I need to wait for the next package release? If so, I would need to go back to pfBlocker as the warm restart doesn't reload the new Blocklists automatically so kind of defeats the purpose. Dont really want to manually restart snort either.
Question - What would happen if a "pkill -HUP snort" was initiated while Snort was performing a Rules Update?
As for your DSNRBL problem, there is no good fix. Snort blocks are inserted in one of the very first tables in the packet filter firewall. That is hard-coded into pfSense itself. Blocks put in are hit before any user rules are encountered in the firewall chain.
I hope Snort puts something in the future code to allow LAN addresses to bypass the IP reputation processor.
-
@BBcan17:
I think I know what the problem is with the blacklist IP. Snort needs a physical stop and start again (a cold restart) instead of a hot restart because of the Spoink plugin used on pfSense. The Spoink plugin that does the actual insertion of a block is an output plugin. I can change the hot-restart in the code to a cold-restart and that should help.
Thanks for the reply. Could this be a patch or would I need to wait for the next package release? If so, I would need to go back to pfBlocker as the warm restart doesn't reload the new Blocklists automatically so kind of defeats the purpose. Dont really want to manually restart snort either.
Question - What would happen if a "pkill -HUP snort" was initiated while Snort was performing a Rules Update?
As for your DSNRBL problem, there is no good fix. Snort blocks are inserted in one of the very first tables in the packet filter firewall. That is hard-coded into pfSense itself. Blocks put in are hit before any user rules are encountered in the firewall chain.
I hope Snort puts something in the future code to allow LAN addresses to bypass the IP reputation processor.
The rules update code already does a cold restart of all Snort interfaces when the new rules are built. There is one other thing I can try, but it will have to be in a package update. I can try the UNIX socket interface the newer Snort binary offers. It's still possible the Spoink output plugin that does the pfSense blocking may still be a problem, though.
As for LAN addresses, I think the IP REP preprocessor will, as a default, not process RFC 1918 addresses. So if you have those in your LAN address scheme, they should not get blocked by the IP REP preprocessor if you uncheck that box on the IP REP tab. It is unchecked by default.
Bill
-
The rules update code already does a cold restart of all Snort interfaces when the new rules are built. There is one other thing I can try, but it will have to be in a package update. I can try the UNIX socket interface the newer Snort binary offers. It's still possible the Spoink output plugin that does the pfSense blocking may still be a problem, though.
1)When the rules update completes, does that also reload the iprep blocklists?
2)If Snort is in the middle of an update and another script runs the pkill -HUP command will the two update processes cause any issues?As for LAN addresses, I think the IP REP preprocessor will, as a default, not process RFC 1918 addresses. So if you have those in your LAN address scheme, they should not get blocked by the IP REP preprocessor if you uncheck that box on the IP REP tab. It is unchecked by default.
My issue is not in blocking an RFC 1918 address. I would like to block LAN addresses from hitting any DST addresses on the Blocklist. But allow the mail server to bypass. With pfBlocker and Aliases, it has a some more fine grain control. I could also say allow an address to bypass the blocklist to a select port only (For mail 25 and 465 only).
So in the whitelist, I can't just add a local address (say 10.1.1.1 Mail server) as the whitelist is the DST address, not SRC.
This way if a machine gets infected or a drive-by, the LAN Blocklist wont allow the outbound. (The WAN does have the Inbound protection but locking the Outbound is important also)
The unblack feature of the IPrep is good as it can still be processed by other rules, so something like BPF probably wouldn't work as it would bypass completely?
Hopefully Snort or Suricata release an updated version with some more functionality.
-
@BBcan17:
1)When the rules update completes, does that also reload the iprep blocklists?
Yes, Snort will rescan the iprep blocklist files as part of the configuration reload. When a rule update is finished, the last thing it does is cold-restart Snort on all interfaces (and Barnyard2, if it is enabled). So during the startup, Snort will reload the IP addresses from all of the IP REP files.
@BBcan17:
2)If Snort is in the middle of an update and another script runs the pkill -HUP command will the two update processes cause any issues?
Well, not sure exactly what the effect could be. Probably is some potential for trouble depending on exactly where and how they collide. If I can add that UNIX socket control to Snort on FreeBSD, then this problem could be mitigated a bit because you don't have to SIGHUP the whole Snort process. You just send a command over a UNIX socket to a listener in Snort that then reloads the IP REP lists.
Bill
-
@BBcan17:
My issue is not in blocking an RFC 1918 address. I would like to block LAN addresses from hitting any DST addresses on the Blocklist. But allow the mail server to bypass. With pfBlocker and Aliases, it has a some more fine grain control. I could also say allow an address to bypass the blocklist to a select port only (For mail 25 and 465 only).
So in the whitelist, I can't just add a local address (say 10.1.1.1 Mail server) as the whitelist is the DST address, not SRC.
This way if a machine gets infected or a drive-by, the LAN Blocklist wont allow the outbound. (The WAN does have the Inbound protection but locking the Outbound is important also)
The unblack feature of the IPrep is good as it can still be processed by other rules, so something like BPF probably wouldn't work as it would bypass completely?
Hopefully Snort or Suricata release an updated version with some more functionality.
Why not do a good portion of this on your Mail Server instead of the firewall. By that I mean set up the RBL stuff using something like IPTABLES (if you mail server is Linux). That gives you much more fine-grained control and you could do what you want (prevent an RBL domain from contacting your server, but let your server talk to the RBL domain).
If you Mail Server is Exchange, then admittedly things are a bit harder because you don't have great control with the Windows firewall.
Bill
-
I noticed this in the Blocked log? Not sure how that got added? I check the blocklist and its not there.
224 255.255.255.255 (spp_reputation) packets blacklisted - 04/15/14-13:10:56
(portscan) UDP Filtered Portsweep - 04/15/14-10:19:22 -
@BBcan17:
I noticed this in the Blocked log? Not sure how that got added? I check the blocklist and its not there.
224 255.255.255.255 (spp_reputation) packets blacklisted - 04/15/14-13:10:56
(portscan) UDP Filtered Portsweep - 04/15/14-10:19:22Obviously it was a broadcast. Could be a bug in the IP REP preprocessor code within Snort itself. Done improperly, a test of a broadcast address could seem to match any IP address. All the GUI package code does is set a handful of snort.conf parameters for the preprocessor.
-
Why not do a good portion of this on your Mail Server instead of the firewall. By that I mean set up the RBL stuff using something like IPTABLES (if you mail server is Linux). That gives you much more fine-grained control and you could do what you want (prevent an RBL domain from contacting your server, but let your server talk to the RBL domain).
If you Mail Server is Exchange, then admittedly things are a bit harder because you don't have great control with the Windows firewall.
I use Zimbra (Ubuntu & Postfix based), I have RBL's
zen.spamhaus
bl.spamcop.net
b.barracudacentral.orgI have two WAN addresses but because they are on the same gateway, I use an Alias for the mail server so my Snort WAN Interface handles both addresses so I cant tune the Snort Interface for each WAN address independently. :(
The Blocklists that I am using are not DNSRBL so I can't poll them thru a Postfix lookup in the MTA.
The three RBLs above do a great job. I have tested a lot of others but they dont seem to pickup much.
Malicious is malicious and I would prefer to rid my whole network of these addresses at the Firewall. Its also easier to control one set of rules at the firewall than maintain more software.
Always looking for suggestions! ;)
-
@BBcan17:
I noticed this in the Blocked log? Not sure how that got added? I check the blocklist and its not there.
224 255.255.255.255 (spp_reputation) packets blacklisted - 04/15/14-13:10:56
(portscan) UDP Filtered Portsweep - 04/15/14-10:19:22Obviously it was a broadcast. Could be a bug in the IP REP preprocessor code within Snort itself. Done improperly, a test of a broadcast address could seem to match any IP address. All the GUI package code does is set a handful of snort.conf parameters for the preprocessor.
I guess add that to the Whitelst?
-
@BBcan17:
@BBcan17:
I noticed this in the Blocked log? Not sure how that got added? I check the blocklist and its not there.
224 255.255.255.255 (spp_reputation) packets blacklisted - 04/15/14-13:10:56
(portscan) UDP Filtered Portsweep - 04/15/14-10:19:22Obviously it was a broadcast. Could be a bug in the IP REP preprocessor code within Snort itself. Done improperly, a test of a broadcast address could seem to match any IP address. All the GUI package code does is set a handful of snort.conf parameters for the preprocessor.
I guess add that to the Whitelst?
Nah…I wouldn't bother. You generally don't care if a broadcast is blocked because that is all subnet localized anyway.
