Snort download blocked hosts = empty tar.gz?
-
G'day ;D
I am running into some problems. As I noticed that after a reboot of PFS all the hosts that snort blocked will be flushed, I thought of downloading the list first. And then, afterwards, creating an alias where I could put these blocked hosts in.
So in Services/Snort/Blocked I click 'download', it does want to save a file (snort_blocked_2013-10-15-16-50-33.tar.gz), however, this file can not be uncompressed. When looking in it with a file viewer, it clearly isn't a *.tar.gz. I have attached the file (remove the .txt at the end, the forum doesn't allow me to upload a *.tar.gz it appears).
Is there anybody who would happen to know what the problem might be? (I tried it both in IE10 and FF24).
Thank you for any help in advance ;D
-
@Hollander:
G'day ;D
I am running into some problems. As I noticed that after a reboot of PFS all the hosts that snort blocked will be flushed, I thought of downloading the list first. And then, afterwards, creating an alias where I could put these blocked hosts in.
So in Services/Snort/Blocked I click 'download', it does want to save a file (snort_blocked_2013-10-15-16-50-33.tar.gz), however, this file can not be uncompressed. When looking in it with a file viewer, it clearly isn't a *.tar.gz. I have attached the file (remove the .txt at the end, the forum doesn't allow me to upload a *.tar.gz it appears).
Is there anybody who would happen to know what the problem might be? (I tried it both in IE10 and FF24).
Thank you for any help in advance ;D
Bye,
I will take a look at this and see if I can fix it. That is legacy code that was in the package already when I started sort of maintaining it this year.
As for the filter_reload() process clearing the snort2c block table, Ermal has told me offline via e-mail that he intends to look into fixing that. However, I suspect that since it is a core pfSense process it will have to wait for the next hotfix release of 2.1.
One other comment – and some other users have posted this as well -- clearing the block table on reboot or even periodically is really not a huge deal. On the next offending packet from the same host, the block will be reinstated. Or at least it is supposed to reinstated... ;D. If that is not the case, then I need to know.
Bill
-
This problem of empty downloaded tar.gz files has been fixed in the latest Pull Request posted for Core Team review and approval. That new package version is 2.6.1. Hopefully it will get approved and merged in the next couple of days.
Bill
-
As for the filter_reload() process clearing the snort2c block table, Ermal has told me offline via e-mail that he intends to look into fixing that. However, I suspect that since it is a core pfSense process it will have to wait for the next hotfix release of 2.1.
Isn't it possible to create an alias with the blocks instead of the snort2c block table. The alias then can be added to the firewall rules and won't get cleared by the filter_reload() process.
-
As for the filter_reload() process clearing the snort2c block table, Ermal has told me offline via e-mail that he intends to look into fixing that. However, I suspect that since it is a core pfSense process it will have to wait for the next hotfix release of 2.1.
Isn't it possible to create an alias with the blocks instead of the snort2c block table. The alias then can be added to the firewall rules and won't get cleared by the filter_reload() process.
No, I don't think that process will work. The blocks actually originate within the Snort binary and not from the GUI. The Snort package GUI is just a PHP web page front-end for creating the configuration files for the regular old Snort binary that runs on a number of UNIX flavors. The Snort binary for pfSense has been modified to include a custom plugin. This plugin is in the output chain of the Snort binary code and thus gets a chance to process each alert. It compares the alert IP to the whitelist, and then calls the native FreeBSD pf code to insert a block if needed. The Snort binary runs fulltime, but the GUI only runs when a user interacts with it via the menus.
To my knowledge (which for pfSense and FreeBSD is limited) there is no way to access the firewall aliases from within the Snort binary itself. Besides, as I understand the process, those Alias values are only re-evaluated on relatively long time intervals (meaured in minutes). So if Snort worked this way, it really couldn't block realtime as it currently does.
DISCLAIMER: everything I stated above is based on my quite limited knowledge of the inner workings of pfSense. There may be mechanisms I am not aware of that would make your idea work.
Bill
-
Ok. I hoped this could be a workaround so you wouldn't get all those 'why isn't snort blocking' questions.
Hope the pfSense hotfix won't take long.Thanks for all tour hard work!
-
Thank you Bmeeks ;D
