Snort 2.9.4.1 pkg v.2.5.8
-
The new gui is very nice. The viewing of the whitelist defaults was very helpful in making sure it was getting the list that I wanted to make sure something important didn't get blocked.
Nice job!
-
I am getting a bunch of unimportant alerts on the LAN from an ipv6 address (it is actually a dhcp solicit request to port 547). This is the first time putting an ipv6 address in the suppression list so I don't know if this is new behavior or not. I have already upgraded all my installations to 2.5.8 package but I have a feeling older packages have the same issue though.
06/14/13 15:15:37 2 Attempted Information Leak fe80::344b:2f8a:dc36:80e5 ff02::c 122:23 (portscan) UDP Filtered Portsweep
I tried adding the ipv6 address to suppress fe80::344b:2f8a:dc36:80e5 ff02::c but it gets written to the interface suppression file incorrectly which causes snort to not start up…
#(portscan) UDP Filtered Portsweep
suppress gen_id 122, sig_id 23, track by_src, ip fe80::344b:2f8a:dc36:80e5I really don't want to ignore the scan completely. I would just modify the suppression file directly but it will get overwritten on the next time the suppression file gets written to disk.
UPDATE: Even if I manually edit the suppresion file for the interface the gui seems to overwrite it with the corrupt line when I try even starting the snort instance on that interface. It was worth a try anyway.
-
I am getting a bunch of unimportant alerts on the LAN from an ipv6 address (it is actually a dhcp solicit request to port 547). This is the first time putting an ipv6 address in the suppression list so I don't know if this is new behavior or not. I have already upgraded all my installations to 2.5.8 package but I have a feeling older packages have the same issue though.
06/14/13 15:15:37 2 Attempted Information Leak fe80::344b:2f8a:dc36:80e5 ff02::c 122:23 (portscan) UDP Filtered Portsweep
I tried adding the ipv6 address to suppress fe80::344b:2f8a:dc36:80e5 ff02::c but it gets written to the interface suppression file incorrectly which causes snort to not start up…
#(portscan) UDP Filtered Portsweep
suppress gen_id 122, sig_id 23, track by_src, ip fe80::344b:2f8a:dc36:80e5I really don't want to ignore the scan completely. I would just modify the suppression file directly but it will get overwritten on the next time the suppression file gets written to disk.
UPDATE: Even if I manually edit the suppresion file for the interface the gui seems to overwrite it with the corrupt line when I try even starting the snort instance on that interface. It was worth a try anyway.
Thanks for reporting. That definitely looks like a bug. I will get it fixed and included in the new 2.5.9 update I am working on. This update will include the 2.9.4.6 binary upgrade of Snort itself, and the 2.5.9 GUI package update will include some new features. I will figure out this Suppress List bug with IPv6 and include that fix as well.
Update – after looking at what is written to the Suppress List, it dawned on me what the problem is. I added a "fix" to allow wrapping of the long IPv6 addresses in the Alerts tab columns. What I had to do is provide a zero-length space in the IPv6 string to give the browser a line break opportunity for word wrapping. I put one of those codes at each colon in the address. That's what the code is. So I inadvertently introduced this problem. I will get it fixed, but would rather just include it in the 2.5.9 update mentioned above. That will be coming out before July.
Until then you should be able to manually edit the list. First, open the list on the Suppress List tab, click the edit icon, then delete any bogus entries. Save the list. Then manually add the information. It should not get overwritten again unless you click the plus ( + ) icon on the Alerts tab to automatically add another entry.
Bill
-
Until then you should be able to manually edit the list. First, open the list on the Suppress List tab, click the edit icon, then delete any bogus entries. Save the list. Then manually add the information. It should not get overwritten again unless you click the plus ( + ) icon on the Alerts tab to automatically add another entry.
If I create the entire supression line manually through the gui it still gets saved incorrectly. Try it yourself…
I will just suppress the entire rule for now until your next major version comes out (2.5.9). Thanks.
-
Until then you should be able to manually edit the list. First, open the list on the Suppress List tab, click the edit icon, then delete any bogus entries. Save the list. Then manually add the information. It should not get overwritten again unless you click the plus ( + ) icon on the Alerts tab to automatically add another entry.
If I create the entire supression line manually through the gui it still gets saved incorrectly. Try it yourself…
I will just suppress the entire rule for now until your next major version comes out (2.5.9). Thanks.
That's strange and unexpected. I will try to reproduce. Tell me the steps you did to get the error:
I assume click on an alert from the Alerts tab to auto-add to the Suppress List ?
Bill
-
I clicked on the add id to supress list in the alert log which works fine but does not have an IP address in it (which is normal).
Stop and restart snort works fine.
I then went to the suppress list page
I then clicked on e to edit the LAN suppress list.
I edited it through the gui to add ', track by_src, ip fe80::344b:2f8a:dc36:80e5' to the end of the autogenerated entry.
I then click save.
It brings me back to the suppress listing page
I click on e button to edit the list and it displays the ipv6 address all messed up again. -
I clicked on the add id to supress list in the alert log which works fine but does not have an IP address in it (which is normal).
Stop and restart snort works fine.
I then went to the suppress list page
I then clicked on e to edit the LAN suppress list.
I edited it through the gui to add ', track by_src, ip fe80::344b:2f8a:dc36:80e5' to the end of the autogenerated entry.
I then click save.
It brings me back to the suppress listing page
I click on e button to edit the list and it displays the ipv6 address all messed up again.Did you "copy and paste" the IP address into the list? If so, that's what happened. It copied in the "invisible" zero-length space codes. They do not display, but are picked up in the copied string text. I can put a "filter" on the Suppress List page to get rid of them prior to saving.
I can also see about adding an option to auto-add the "track by_src" kind of Suppress List entry. I will add a little plus (+) icon beside the existing (x) icon under the IP addresses in the Alerts tab. Clicking the (+) icon will add the IP address to the Suppress List.
Bill
-
I am not sure about pasting. I will try to VPN in and try both methods either late tonight or tomorrow.
by_src option from the GUI would be nice.
-
I am not sure about pasting. I will try to VPN in and try both methods either late tonight or tomorrow.
by_src option from the GUI would be nice.
by_src will be added. It's an easy addition that I just had not thought about. If you type in the IPv6 address and don't paste it, then you should be OK. Although it could be that the Suppress List is now corrupted with the bogus characters. It might have to be "wiped" and reloaded.
I'm very, very close to having the 2.5.9 package ready to submit to the Core Dev Team for review. I might be able to get it posted by the end of the weekend or very early next week for them to review.
Bill
-
I will try to look at it in the next 2 hours or so then so that I can report the results back to you quicker.
-
It is copy / paste that causes it. I typed it in manually in the web GUI and viewed it after saving and it was not messed up. I started and stopped the service without issues afterwards too.
-
It is copy / paste that causes it. I typed it in manually in the web GUI and viewed it after saving and it was not messed up. I started and stopped the service without issues afterwards too.
Thanks. I can add a filter-before-save step in the Suppression List tab so any zero-length spaces that get pasted in will be removed during the save.
Bill
-
Sounds great.
I am curious.. Is there a way to deal with the copy including extra hidden characters? I only say that because I copied it into another program but now I am wondering if that document has these extra hidden characters in there too. I wonder if a copy into gnome editor for an example would strip them out during a paste into the gnome editor or not.
I don't expect anything to be done… I am just interested in knowing how things like that could be dealt with if the copy needed to be pristine. For example maybe not having the characters in the table if possible which i assume its not. You can ignore this question and I won't feel bad... I am sure you have better things to do :).
-
Sounds great.
I am curious.. Is there a way to deal with the copy including extra hidden characters? I only say that because I copied it into another program but now I am wondering if that document has these extra hidden characters in there too. I wonder if a copy into gnome editor for an example would strip them out during a paste into the gnome editor or not.
I don't expect anything to be done… I am just interested in knowing how things like that could be dealt with if the copy needed to be pristine. For example maybe not having the characters in the table if possible which i assume its not. You can ignore this question and I won't feel bad... I am sure you have better things to do :).
I don't know of a way to exclude them from the copy operation since that is totally outside the scope of the Snort GUI.Scratch that first sentence. Should have done a quick Google before I posted it originally. Turns out it is possible to "capture" a copy operation in JavaScript and manipulate the clipboard contents. I will experiment with this approach on the Alerts tab page to see if I can capture and "scrub" the clipboard data of any zero-length space characters before passing the data on to the OS.The zero-length spaces are currently a sort of quasi-necessary evil. Without them, IPv6 addresses are so long they overlap the next column on the tab. There is limited real estate on the screen for all the data required for the Alerts tab. The Widescreen package is not yet standard in pfSense. The default display width is 725 pixels no matter what the total screen width is. So I try to stay within that limit for now until something like Widescreen is incorporated into the baseline pfSense GUI. The zero-length spaces are the best I could come up with to break IPv6 addresses.
I also don't know what other editors will do with them. I do know they come across from your Forum post here to my browser. I copied your IPv6 address example and then pasted it into a PERL regex test web site. The zero-length spaces came over and showed up as the values. So they survived through that process of copying from your post and pasting into another web site's text form.
Bill
-
Just a small question regarding that….what if you change the 725px to 80% or 100% instead??
-
Guys I updated and lost all my settings - no big deal but now I have an issue with http_inspect.
Constantly sites like google, reddit, imgur, yahoo, youtube…the list goes on... are getting blocked.
Can you please tell me what I am doing wrong with the setup of this and if any of you are seeing the same issues?
I tried to disable it via options but then snort won't start - guessing some WAN categories are dependent on http_inspect starting.
-
Just a small question regarding that….what if you change the 725px to 80% or 100% instead??
I am using 100% as the table widths, but when you call in the header and footer includes that constitute the pfSense GUI, you wind up running as a nested table that ends up being 100% of 725 pixels… :(
The good news is once something like the Widescreen package stabilizes and becomes part of the standard GUI, Snort should adapt quite well since all of its width specifications are in percentage.
Bill
-
Guys I updated and lost all my settings - no big deal but now I have an issue with http_inspect.
Constantly sites like google, reddit, imgur, yahoo, youtube…the list goes on... are getting blocked.
Can you please tell me what I am doing wrong with the setup of this and if any of you are seeing the same issues?
I tried to disable it via options but then snort won't start - guessing some WAN categories are dependent on http_inspect starting.
There is a check box on the Preprocessors tab at the bottom of the HTTP_INSPECT section that says "disable http_inspect alerts" or something similar. Tick that box. You should then no longer get blocks from HTTP_INSPECT alerts. There is also a new button at the bottom of the page for 2.5.8 that will reset all the preprocessor settings to their defaults. The default for HTTP_INSPECT should be enabled but with alerts disabled.
Attached below are my HTTP_INSPECT settings. You can also automatically add problem alerts to the Suppress List by clicking the plus icons (+) under the alert on the Alerts tab. Once you do this, you will need to stop and restart Snort to pick up the change.
Bill
-
Did you see the thread I created about finding a notification script by someone else? I am making good use of it. I only block on the LAN snort instance though. I would get too many notifications on the wan side.
http://forum.pfsense.org/index.php/topic,63418.0.html -
Did you see the thread I created about finding a notification script by someone else? I am making good use of it. I only block on the LAN snort instance though. I would get too many notifications on the wan side.
http://forum.pfsense.org/index.php/topic,63418.0.htmlYes, I saw the post. It is a handy script, but with a number of commercial Snort installations I think it could lead to "information overload" with the number of blocks and unblocks that routinely happen. An improvement might be to filter the events and only send notifications for high priority ones so that you don't get an e-mail flood for something like blocks/unblocks from IPs on the RBN or CIARMY lists.
Bill
