Snort 3.2.6 supress lists changes made from block list not being saved

bmeeks

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

firewalluser

@bmeeks:

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.

doktornotor

As said above, this is per interface. (And please keep this forum tin-foil free…)

firewalluser

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

fsansfil

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

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

firewalluser

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.

fragged

Can you take the offtopic tinfoil theory to another thread of forum. Thanks.

firewalluser

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

Nothing like hubris to install some denial in the system.

doktornotor

Please, go to hell with this shit. Absolutely OT here.

firewalluser

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 screwed

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