Snort 3.2.6 supress lists changes made from block list not being saved
-
Snort 3.2.6, also noticed where I use the icon to add a block to the supress list, this is not appearing in the supress list for the corresponding OPTx interface.
-
Need a little more info.
For the OPTx interface, do you have a specifically defined and assigned Suppress List or are you using the default one?
When you click the icon on the ALERTS tab, do you get a confirmatory prompt at the top of the page telling you Snort is reloading the rules?
If you go to the INTERFACE SETTINGS tab in Snort for the OPTx interface and click the View List button beside the Suppress List drop-down, does your suppress entry show in there?
Bill
-
Need a little more info.
For the OPTx interface, do you have a specifically defined and assigned Suppress List or are you using the default one?
Default generated one.
When you click the icon on the ALERTS tab, do you get a confirmatory prompt at the top of the page telling you Snort is reloading the rules?
I dont recall seeing one
If you go to the INTERFACE SETTINGS tab in Snort for the OPTx interface and click the View List button beside the Suppress List drop-down, does your suppress entry show in there?
Bill
I'll check, when I looked up the corresponding optx_67867889u9898 file it wasnt showing in there, but I'll check using the method you have suggested.
-
If you go to the INTERFACE SETTINGS tab in Snort for the OPTx interface and click the View List button beside the Suppress List drop-down, does your suppress entry show in there?
Bill
I'll check, when I looked up the corresponding optx_67867889u9898 file it wasnt showing in there, but I'll check using the method you have suggested.
Its not in the file using the view list button.
Shouldnt there be a corresponding suppress entry for the wan interface and one for the lan interface, though?
In other words lets say I suppress PDF's on the wan interface, how does it get blocked on some OPTx or Lan interface?
ATM it seems a suppress on wan will suppress across all lanside interfaces, yet I might only want the suppress to apply to only one lanside interface, not all of them and I dont see how I can achieve this?
Edit. Just to be clear I also have block enabled on the optx interfaces as well, theres only 2 interfaces (lan and one optx interface) its not set to block on, which are like my dirty networks.
-
Each interface in the Snort package is completely independent from other configured Snort interfaces. Things like assigned Suppress Lists, rules and preprocessor settings are unique to each interface. So a suppress setting on the WAN has no bearing on the LAN or OPTx (and vice-versa).
I've not had any other reports of the Suppress List not working. I have a number of suppressed alerts on my LAN, and they are working as intended.
Bill
-
Each interface in the Snort package is completely independent from other configured Snort interfaces. Things like assigned Suppress Lists, rules and preprocessor settings are unique to each interface. So a suppress setting on the WAN has no bearing on the LAN or OPTx (and vice-versa).
This is what I thought but it only occurred to me that I should be doing a suppress for the OPtx interfaces which were set to block as well.
I've not been able to replicate since but I was downloading some packages from some linux mirrors and some mirrors, probably not just linux but others as well, have been known to deliver rogue software.
I did have to do a reboot of pfsense afterwards as I had and still have some devices which were not appearing on the network like in the ARP table or online in DHCP leases, even though they are getting an ip address assigned by the dhcp server which I am also investigating and still havent solved yet.
They are what you might call some stealth devices at the moment which appear to be hiding from pfsense but using pfsense for network capabilities, like getting an allowed ip address issued by pfsense to talk to the outside world. Quite clever imo, but not good for security.
-
As said above, this is per interface. (And please keep this forum tin-foil free…)
-
I know its per interface, but as I'm working on the premise freebsd has been compromised I'm trying to work out the hows, why's and when.
So far I've been through https://en.wikipedia.org/wiki/Data_link_Layer and found some areas of my network which are able to be arp spoofed. Namely VMware workstation as vshield only exists for enterprise, I already know the windows host despite being blocked by pfsense still monitors the network traffic from vmware guests which is how I know everything done on a windows pc gets reported back to MS.
I also have some code here which will trigger a BSOD in the windows host when run from a VMware guest but could equally work on the host which then enables the BSOD reports to send back info to MS which happens to get intercepted by the spooks according to snowden.
And despite going through the IEEE 802.2 & 3, there's some basic physics which can be exploited when using a hub, namely time in a preemptive manner.
If using a switch updating the switch software just moves the focus to the switch which renders useless the use of things like vlans, & Cisco's dhcp snooping as explained here. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/snoodhcp.html#wp1120427
So no tin foil hat really, but I'll find the code thats compromised freebsd as I'm sure you are familiar with the concept of honeypots and sandbagging. It can work both ways, but I'm reminded of the fact theres only 1 of me and plenty of them. ;D
-
Well if you need to filter L2, combined with L3+, your best bet is a transparent filtering bridge.
Play with arptables and ebtables to filter/log L2, send iptables/ip6tables to Suricata inline.
Heres two usefull guides:Debian like:
http://taosecurity.blogspot.ca/2014/01/suricata-20beta2-as-ips-on-ubuntu-1204.htmlRedhat like:
https://stelfox.net/knowledge_base/linux/suricata/If you think youre compromised from the inside (the real inside, not ISP…because we all know we need the consider the ISP as compromised), get the flashligh and a 6 pack of redbulls and start looking for AppleTart Pi size device...
https://www.defcon.org/images/defcon-19/dc-19-presentations/Duckwall/DEFCON-19-Duckwall-Bridge-Too-Far.pdf
F.
-
Thanks, your post has confirmed my thinking on how best to tackle this.
Edit. Actually as they have control over the firewall, they can also withdraw effectively covering their tracks as and when they wish.
Certainly the sock puppets on some forums I've been watching have been pin sharp in their tactics, but there is another way.
But it just goes to show you cant trust no one.
-
Can you take the offtopic tinfoil theory to another thread of forum. Thanks.
-
I guess the concept of getting software installed remotely is tin foil hat so viruses and malware just dont exist, just like it is to remotely uninstall software to cover ones track.
https://en.wikipedia.org/wiki/Duqu#Purpose
"Security experts are still analyzing the code to determine what information the communications contain. Initial research indicates that the original malware sample automatically removes itself after 36 days (the malware stores this setting in configuration files), which would limit its detection."How silly of me. ::)
Still no explanation as to why this went on yet, even though mirrors can be compromised like using a variation of a MITM which then renders checksums useless as well. ::)
https://forum.pfsense.org/index.php?topic=98300.0Nothing like hubris to install some denial in the system.
-
Please, go to hell with this shit. Absolutely OT here.
-
https://www.defcon.org/images/defcon-19/dc-19-presentations/Duckwall/DEFCON-19-Duckwall-Bridge-Too-Far.pdf
P115
How can we defend this?
•
Basically it’s a physical attack
–
If somebody can plant a malicious device on your
network you’re already screwedWhat has probably not crossed the authors mind is that an insecure network can be used to make a benign device a malicious device, by adding/altering some software. As I've already established there is nothing for vmware workstation to protect against arp poisoning as mentioned in a previous post, that is one area I am looking at amongst a few others, and virtualisation techniques have certainly come along a long way.
So far logs for one of the device's are filling up nicely, caught some traffic which needs investigating, only 6 packets throughout the day out of several GB's but still got to get another device setup to do the packet capture with ssl bridging wanside.
Learning iptables has been fun, I've never seen so many webpages making it seem complicated. I quite like iptables its quite easy once you figure it out at the command line.
