Snort 2.9.4.1 pkg v.2.5.8



  • Yeah i am aware of the color change.  When i say disabled, i mean that in the snort interface, it goes to red.  I am not sure if the interface restarts itself after i click apply in the wan rules tab.  I will retry what i was doing to see if i can reproduce the issue.



  • @shinzo:

    Yeah i am aware of the color change.  When i say disabled, i mean that in the snort interface, it goes to red.  I am not sure if the interface restarts itself after i click apply in the wan rules tab.   I will retry what i was doing to see if i can reproduce the issue.

    No, it should not restart by itself.  The APPLY button on the Rules tab simply rebuilds the enforcing rules file and rewrites the snort.conf file.  I monitored the active processes during my test and never saw but one running Snort process.

    That rule set is a bit large, and it takes several seconds for the process to complete.  This can be even longer on a less capable piece of hardware.  Make sure you wait until the browser "activity indicator" stops spinning.  IE has a spinning icon in the Address Bar, and Firefox also has some kind of status icon but I forget what it is at the moment.  Make sure any spinning status indicators or hourglass goes away before you navigate away from the Rules tab.

    Bill



  • @bmeeks:

    @shinzo:

    Yeah i am aware of the color change.  When i say disabled, i mean that in the snort interface, it goes to red.  I am not sure if the interface restarts itself after i click apply in the wan rules tab.   I will retry what i was doing to see if i can reproduce the issue.

    No, it should not restart by itself.  The APPLY button on the Rules tab simply rebuilds the enforcing rules file and rewrites the snort.conf file.  I monitored the active processes during my test and never saw but one running Snort process.

    That rule set is a bit large, and it takes several seconds for the process to complete.  This can be even longer on a less capable piece of hardware.  Make sure you wait until the browser "activity indicator" stops spinning.  IE has a spinning icon in the Address Bar, and Firefox also has some kind of status icon but I forget what it is at the moment.  Make sure any spinning status indicators or hourglass goes away before you navigate away from the Rules tab.

    Bill

    I went back and couldn't reproduce it.  I think what was happening was when i was trying out the Snort Community and vrt rules yesterday , some where along the line snort didn't restart properly.  Since there seemed to be two instances of snort running. when ever i hit apply after removing some of the current_events rules.  I would jump over and notice that in the interface window, it was red so i would click to start it again and would spawn another pid.

    I will continue messing with it and let you know if anything happens,  I also wanted to ask something about what i read the other day. 
    Would it be better to have 1 wan interface with the wan ip and lan address or separate them and have 1 wan and then 1 lan?  and thanks again



  • @shinzo:

    I also wanted to ask something about what i read the other day.  
    Would it be better to have 1 wan interface with the wan ip and lan address or separate them and have 1 wan and then 1 lan?  and thanks again

    If we are talking about a typical home network with NAT, then it depends on whether or not you want to identify specific hosts on the LAN side.  Here's what I mean.  When you have NAT, then Snort sees everything on the WAN in terms of your WAN IP address and then whatever Internet hosts are being contacted.  Snort does not see the internal LAN private IPs.  It will still block offending traffic by blocking the SRC (assuming you have that configured for the WAN interface).  But the logs will show everything in the local network as having the WAN IP address.

    So if you want to see your LAN private IP addresses in the logs and thus be able to identify which specific LAN host might contain the latest nasty online banking Trojan, then you would run an instance of Snort on your LAN interface.  This is what I do.  I have Snort on the WAN configured with some basic ET-CIARMY and ET-RBN rules, then run the Snort VRT IPS-Balanced policy on my LAN interface.  I configured my LAN interface to block BOTH (source and destination).  The auto-whitelisting feature that adds the LAN to the whitelist means my LAN IPs never get blocked, but if any LAN IP tries to "phone home" to a BOT C-n-C server on the web, then the DST would get blocked because of the BOTH setting.  So I am protected either way (whether my LAN host initiates the conversation or the far-end host does).  Plus, my logs now show me the internal LAN private IP of the infected or potentially infected host.

    P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described.  I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN).  I get this from those ET-CIARMY and RBN rules.  Then my LAN side interface is the next layer of protection and contains the richer rule set.

    Bill



  • @bmeeks:

    @shinzo:

    I also wanted to ask something about what i read the other day.  
    Would it be better to have 1 wan interface with the wan ip and lan address or separate them and have 1 wan and then 1 lan?  and thanks again

    If we are talking about a typical home network with NAT, then it depends on whether or not you want to identify specific hosts on the LAN side.  Here's what I mean.  When you have NAT, then Snort sees everything on the WAN in terms of your WAN IP address and then whatever Internet hosts are being contacted.  Snort does not see the internal LAN private IPs.  It will still block offending traffic by blocking the SRC (assuming you have that configured for the WAN interface).  But the logs will show everything in the local network as having the WAN IP address.

    So if you want to see your LAN private IP addresses in the logs and thus be able to identify which specific LAN host might contain the latest nasty online banking Trojan, then you would run an instance of Snort on your LAN interface.  This is what I do.  I have Snort on the WAN configured with some basic ET-CIARMY and ET-RBN rules, then run the Snort VRT IPS-Balanced policy on my LAN interface.  I configured my LAN interface to block BOTH (source and destination).  The auto-whitelisting feature that adds the LAN to the whitelist means my LAN IPs never get blocked, but if any LAN IP tries to "phone home" to a BOT C-n-C server on the web, then the DST would get blocked because of the BOTH setting.  So I am protected either way (whether my LAN host initiates the conversation or the far-end host does).  Plus, my logs now show me the internal LAN private IP of the infected or potentially infected host.

    P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described.  I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN).  I get this from those ET-CIARMY and RBN rules.  Then my LAN side interface is the next layer of protection and contains the richer rule set.

    Bill

    i haven't even considered a setup like that, thanks for your input


  • Banned

    Hi Bill.

    Can you test a client IP header rule that triggers in this scenario?

    The way NAT reflection works is that the packets go to the firewall, and are then sent from the firewall to the NAT target, changed to appear as if they came from the firewall, so that replies go back through the firewall.

    There is no security issue there, unless you count the loss of the client IP from the perspective of the NAT target/server. The server sees the firewall itself as the "client", not the actual IP of the client.



  • @Supermule:

    Hi Bill.

    Can you test a client IP header rule that triggers in this scenario?

    The way NAT reflection works is that the packets go to the firewall, and are then sent from the firewall to the NAT target, changed to appear as if they came from the firewall, so that replies go back through the firewall.

    There is no security issue there, unless you count the loss of the client IP from the perspective of the NAT target/server. The server sees the firewall itself as the "client", not the actual IP of the client.

    Supermule:

    I'm not sure I understand what you are asking me to do.  If in reference to my previous post, the point of that post to Shinzo was simply to show a mechanism to see the pre-NAT LAN IP addresses in the Snort logs.  If you run Snort on just the WAN (and you are using NAT), then Snort logs all "local" traffic as originating from the WAN IP.  Here is an example.  Suppose host 192.168.0.1 on the LAN communicates with a BOT C-n-C server somewhere on the web.  Snort will see and log that traffic, but what you will see in the ALERT log for the Source IP is your WAN IP and then the Destination IP of the BOT C-n-C server.  So while you will know that you have an infected host on your LAN, you won't know from the Snort logs which one it is.

    However, with my scheme (Snort on LAN), then you will see in the ALERT log the local pre-NAT LAN IP of the infected host (192.168.0.1 in my example) as well as the Destination IP of the C-n-C server.  You can then tell which LAN host is the problem.

    Bill


  • Banned

    I understand :)



  • @bmeeks:

    P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described.  I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN).  I get this from those ET-CIARMY and RBN rules.  Then my LAN side interface is the next layer of protection and contains the richer rule set.

    Bill

    Whats your recommendation then for this setup in regards to duplicate settings on the Preprocessors tab?  Are they unnecessarily redundant?



  • Thanks for the new snort interface.

    Ok , my problem is…..

    Base on my understanding with snort blocking capabilities

    LAN setting - I can block both LAN@internal and External IP with selection of new whitelist setting which i have uncheck the "Add firewall Local Networks to the list (excluding WAN)." option. Block setting "both"

    WAN setting - I can block external setting , wth default whitelist setting. Block setting "both"

    Both LAN and WAN setting will have different categories selection base on my need and requirement.

    For the above setting , I manage to

    WAN Setting - block external IP
    LAN Setting - block only external IP (supposely to block both internal@LAN ip and external IP)

    When I view the whitelist IP with "view list" function , in the new whitelist setting, the local IP still there , sort nothing happened with the uncheck action I have done?

    Bug? or I missed something?

    4 am here, since yesterday morning, I will need to have some rest first. Really appreciate if any one can advice me the next action.



  • 2.1-BETA1 (amd64)
    built on Fri May 17 16:45:31 EDT 2013
    FreeBSD 8.3-RELEASE-p8
    Snort v2.9.4.1 pkg v. 2.5.8

    Hello,

    Ever since I enabled Snort on my LAN interface, my firewall logs have been flooded with the alerts on the attached screen shot. Is there any way to get rid of these alerts? I've been running snort just on the WAN interface for a few good months now and never had these alerts on the firewall logs before. I started to test Snort on the LAN interface a couple of days ago and noticed my firewall log was full of those alerts. I do have IPv6 disabled on the WAN and LAN interfaces. BTW, thanks for this package bmeeks you’ve done a great job with it.




  • @AhnHEL:

    Whats your recommendation then for this setup in regards to duplicate settings on the Preprocessors tab?  Are they unnecessarily redundant?

    The Preprocessors are unique to each instance of Snort.  When you run Snort on more than one interface, you actually have two completely separate and independent processes running – totally separate running copies of the binary.  You may already have known that, so forgive me for repeating it if you did.  Not trying to insult anyone's skills, but just making sure we start from the same baseline for my explanation below.

    So you could certainly- depending on how you have the rule sets selected- use different Preprocessor settings on the different interfaces.  It's just my view that on today's reasonably fast hardware the preprocessor overhead is not that big of a deal.  I don't think it's nearly as taxing on CPU and RAM as say having duplicate sets of ALL the rules running on the LAN and WAN interfaces.  The rules are where all the CPU and RAM resources get used (of course the HTTP_INSPECT, Frag3 and Stream5 can use some extra RAM depending on how they are configured).  But in high traffic situations, different preprocessors settings would certainly be the way to go.  You just have to be careful that you don't disable a preprocessor that an enabled rule depends on.  Doing so will cause those "FATAL ERROR" messages on startup.

    So to sum up my answer to your question, if had 2GB or more of RAM and not a lot of load (say less than 50 Mbits/sec) with a reasonably modern CPU; then I would just run the default preprocessor setup on both interfaces.

    Bill



  • @masli:

    Thanks for the new snort interface.

    Ok , my problem is…..

    Base on my understanding with snort blocking capabilities

    LAN setting - I can block both LAN@internal and External IP with selection of new whitelist setting which i have uncheck the "Add firewall Local Networks to the list (excluding WAN)." option. Block setting "both"

    WAN setting - I can block external setting , wth default whitelist setting. Block setting "both"

    Both LAN and WAN setting will have different categories selection base on my need and requirement.

    For the above setting , I manage to

    WAN Setting - block external IP
    LAN Setting - block only external IP (supposely to block both internal@LAN ip and external IP)

    When I view the whitelist IP with "view list" function , in the new whitelist setting, the local IP still there , sort nothing happened with the uncheck action I have done?

    Bug? or I missed something?

    4 am here, since yesterday morning, I will need to have some rest first. Really appreciate if any one can advice me the next action.

    I went back and looked at the code.  Currently it is by design that the interface Snort is running on (except when it's the WAN) is always added to HOME_NET and the WHITELIST.  Do you really want to block your local LAN IP addresses?  If so, why?  You can easily lock yourself out of the firewall this way (at least lock out a workstation).  It has always been the behavior of Snort to add the interface running Snort to HOME_NET and the WHITELIST.  What changed in this last update was instead of whitelisting the entire WAN subnet, only the WAN IP is whitelisted.  The checkbox just adds all the other locally attached firewall networks to HOME_NET and the WHITELIST.  Formerly these were not added by default.

    Bill



  • @pareddefuego13:

    2.1-BETA1 (amd64)
    built on Fri May 17 16:45:31 EDT 2013
    FreeBSD 8.3-RELEASE-p8
    Snort v2.9.4.1 pkg v. 2.5.8

    Hello,

    Ever since I enabled Snort on my LAN interface, my firewall logs have been flooded with the alerts on the attached screen shot. Is there any way to get rid of these alerts? I've been running snort just on the WAN interface for a few good months now and never had these alerts on the firewall logs before. I started to test Snort on the LAN interface a couple of days ago and noticed my firewall log was full of those alerts. I do have IPv6 disabled on the WAN and LAN interfaces. BTW, thanks for this package bmeeks you’ve done a great job with it.

    Traffic on port 1900 to that destination IPv6 address is SSDP (Simple Service Discovery Protocol) traffic.  Snort does not, to the best of my knowledge, generate such traffic and has no need for it.  I would say this is not related to enabling Snort on the LAN.

    Bill



  • thanks Bill for your answer…but its weird, if I disable Snort on the LAN interface, those log entries stop and only return if I enable Snort on the LAN interface again.



  • @bmeeks:

    So to sum up my answer to your question, if had 2GB or more of RAM and not a lot of load (say less than 50 Mbits/sec) with a reasonably modern CPU; then I would just run the default preprocessor setup on both interfaces.

    Thank you Bill for your clear and concise reply.  Snort has jumped in leaps and bounds since you started contributing and adding to Ermal's package.  ;D



  • I have no choice with referring to torrent or p2p blocking 2with snort. With current version, without blocking the client who is downloading using torrent software. Not much can be done as the client kept continue downloading the file without failure. I have try it with my notebook , even though snort manage to block some external IP (using both LAN and WAN setting) , my torrent software keep continue downloading as nothing blocking it at all.

    I do understand that with the setting I intended to used , my client or some workstation will be accidentally block(if they forgot to shut off their torrent software. But it sort like reminder to the client not to use torrent software in my network. After all with cron , it will only block for 5 min. So the client must make sure their pc is according to my requirement within 5 minute.

    Really appreciate if the whitelist issue can be settle.

    @bmeeks:

    @masli:

    Thanks for the new snort interface.

    Ok , my problem is…..

    Base on my understanding with snort blocking capabilities

    LAN setting - I can block both LAN@internal and External IP with selection of new whitelist setting which i have uncheck the "Add firewall Local Networks to the list (excluding WAN)." option. Block setting "both"

    WAN setting - I can block external setting , wth default whitelist setting. Block setting "both"

    Both LAN and WAN setting will have different categories selection base on my need and requirement.

    For the above setting , I manage to

    WAN Setting - block external IP
    LAN Setting - block only external IP (supposely to block both internal@LAN ip and external IP)

    When I view the whitelist IP with "view list" function , in the new whitelist setting, the local IP still there , sort nothing happened with the uncheck action I have done?

    Bug? or I missed something?

    4 am here, since yesterday morning, I will need to have some rest first. Really appreciate if any one can advice me the next action.

    I went back and looked at the code.  Currently it is by design that the interface Snort is running on (except when it's the WAN) is always added to HOME_NET and the WHITELIST.  Do you really want to block your local LAN IP addresses?  If so, why?  You can easily lock yourself out of the firewall this way (at least lock out a workstation).  It has always been the behavior of Snort to add the interface running Snort to HOME_NET and the WHITELIST.  What changed in this last update was instead of whitelisting the entire WAN subnet, only the WAN IP is whitelisted.  The checkbox just adds all the other locally attached firewall networks to HOME_NET and the WHITELIST.  Formerly these were not added by default.

    Bill



  • @masli:

    I have no choice with referring to torrent or p2p blocking 2with snort. With current version, without blocking the client who is downloading using torrent software. Not much can be done as the client kept continue downloading the file without failure. I have try it with my notebook , even though snort manage to block some external IP (using both LAN and WAN setting) , my torrent software keep continue downloading as nothing blocking it at all.

    I do understand that with the setting I intended to used , my client or some workstation will be accidentally block(if they forgot to shut off their torrent software. But it sort like reminder to the client not to use torrent software in my network. After all with cron , it will only block for 5 min. So the client must make sure their pc is according to my requirement within 5 minute.

    Really appreciate if the whitelist issue can be settle.

    I can make the change, but I have to figure out a way to incorporate it so it does not break existing settings for folks who do not want to use it in the same manner.  I will put this on the To-Do list for the next release.  I will alter the WHITELIST so the Local Networks (including the interface Snort is running on) are not automatically included when the new Checkbox is cleared.

    In the meantime, I can show you how to modify the default behavior on your system if you will PM (Private Message) me.

    Bill



  • @pareddefuego13:

    thanks Bill for your answer…but its weird, if I disable Snort on the LAN interface, those log entries stop and only return if I enable Snort on the LAN interface again.

    OK, I will do a little research and see if something pops up.  I don't use IPv6 on my systems yet, so I have never seen this traffic.

    Bill



  • @bmeeks:

    @masli:

    I have no choice with referring to torrent or p2p blocking 2with snort. With current version, without blocking the client who is downloading using torrent software. Not much can be done as the client kept continue downloading the file without failure. I have try it with my notebook , even though snort manage to block some external IP (using both LAN and WAN setting) , my torrent software keep continue downloading as nothing blocking it at all.

    I do understand that with the setting I intended to used , my client or some workstation will be accidentally block(if they forgot to shut off their torrent software. But it sort like reminder to the client not to use torrent software in my network. After all with cron , it will only block for 5 min. So the client must make sure their pc is according to my requirement within 5 minute.

    Really appreciate if the whitelist issue can be settle.

    I can make the change, but I have to figure out a way to incorporate it so it does not break existing settings for folks who do not want to use it in the same manner.  I will put this on the To-Do list for the next release.  I will alter the WHITELIST so the Local Networks (including the interface Snort is running on) are not automatically included when the new Checkbox is cleared.

    In the meantime, I can show you how to modify the default behavior on your system if you will PM (Private Message) me.

    Bill

    Thanks will PM you now



  • @bmeeks:

    @pareddefuego13:

    thanks Bill for your answer…but its weird, if I disable Snort on the LAN interface, those log entries stop and only return if I enable Snort on the LAN interface again.

    OK, I will do a little research and see if something pops up.  I don't use IPv6 on my systems yet, so I have never seen this traffic.

    Bill

    No worries Bill, I got the firewall to stop logging IPv6 multicast, no need to look into this, thanks



  • @pareddefuego13:

    No worries Bill, I got the firewall to stop logging IPv6 multicast, no need to look into this, thanks

    OK.  I never did find any connection in my Google research between SSDP and Snort.  There is one possibility, though, that just occurred to me.  Snort puts the interface it is running on in promiscuous mode.  Perhaps that is why you suddenly started seeing the traffic when Snort was enabled on the interface.

    Just not logging it should be fine.

    Bill



  • Just posting to confirm that the blank page problem has been resolved.

    Thank you  ;D



  • 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:​80e5

    I 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.



  • @adam65535:

    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:​80e5

    I 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



  • @bmeeks:

    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.



  • @adam65535:

    @bmeeks:

    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.



  • @adam65535:

    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.



  • @adam65535:

    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.



  • @adam65535:

    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 :).



  • @adam65535:

    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


  • Banned

    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.



  • @Supermule:

    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


Log in to reply