Snort IPrep
-
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.