What is the biggest attack in GBPS you stopped
-
@mer:
It's been a while since I've looked/used snort, but I would think it's looking at packets, but shouldn't be blocking pfsense until a rule match.
If it doesn't block every packet, there is a chance a packet may get through before blocking. It could inspect packets asynchronously, then signal PF to kill a connection if it sees a "bad" packet after the fact, but most everything I see about snort is it can make your bandwidth lower. If it affects your bandwidth, then it must be acting as a middleman in some way that all packets must go through it. You also runt he issue if packets are coming in faster than snort can process them, then snort can't see every packet.
-
Snort is an IDS rather than an IPS (which limits its usefulness). It gets a copy of the packet, and is not in the data path. When snort decides to block something, it performs the block by adding a pf rule. Look for the snort2c table.
I think snort is blocking and has to inspect every connection before letting it through.
-
The only time I've ever used snort was as a passive sniffer on a mirrored port, so I was unsure how it worked when on the firewall. I assume rules inserted by snort must happen before the past path of checking if a connection already exists, and maybe this is why snort is some times associated with reduced performance.
-
Snort blocks by inserting the target IP address in pfSense pre-defined pf table called "snort2c". That table is created during the pfSense boot process and always exists whether the Snort package is installed or not. The table is rather high up in the chain, so it is one of the first tables (rules) a packet will see. It's not the very first, but it does come before any other user-supplied rules.
The blocking module of Snort is a binary patch integrated into the Snort source code as an output plugin. The plugin takes every Snort alert and checks the IP addresses against any Pass List (do not block list of IPs). If there is no match to a Pass List IP, the IP is then inserted into the snort2c table using FreeBSD system calls.
If the "clear states" option is enabled within the Snort GUI, then the aforementioned blocking plugin will also do a FreeBSD system call to clear all states in the packet filter associated with the IP that was blocked.
Bill
-
What process does it call when clearing states Bill??
-
C'mon.
Troubleshoot FreeBSD first.
Why is that so difficult?
-
Its not Tim :D
I just want to know why it behaves like that. Currently bombing Anthonys provided IP. Hope he is stilla alive :D
-
It's an absolute waste of time to do anything with snort. It's built on top of pfSense, which in turn is built on top of FreeBSD.
When you troubleshoot a web server, you usually start with trying to ping the server, check to see if the port is open, and then look at the applications built on top of it. Why on God's green earth would you even look at snort?
If you want to resolve the issue, if you truly want to resolve the issue, eliminate the mast basic layers before you go up to the applications. If' stopped engaging in this ruse because of the distractions.
I can almost guarantee that the issue is with the FreeBSD networking drivers. I haven't seen a thread created on their forums to address or resolve the issue. There's no more point to this thread other than being a distraction from methodically trying to identify the root cause.
-
From those of you who are testing with Supermule, may we please have a quick update of what is happening now and what stage the testing is? And what is your current standing in regards to this issue? (e.g. will it bring the world down or not?)
I have lost tract since page 20 of the thread…
Thanks for all the hard work everyone!
-
may we please have a quick update of what is happening now and what stage the testing is?
Enough videos produced to run a dedicated YT channel for clueless nerds…
And what is your current standing in regards to this issue? (e.g. will it bring the world down or not?)
Yeah, we are all doomed.
-
Apparently not if you migrate to OPNsense…
I hate the GUI but it has no issues despite beeing a fork of pfsense.
http://youtu.be/98I7-UHvkPQ
Even with the stage table full it keeps routing and reply. Almost zero packetloss.
-
I noticed the first test had about 30Mb in the first test and only 9Mb on the second, after you made the change for adaptive scaling. What this a DDOS syn attack or just a normal one?
-
DDoS.
-
Apparently not if you migrate to OPNsense…
Excellent. So, now this thread finally can be closed…
-
Apparently not if you migrate to OPNsense…
Excellent. So, now this thread finally can be closed…
It doesnt help existing users of pfsense who dont want to waste time jumping ship to yet another product though.
I personally would like to get to the bottom of it otherwise why even have a firewall at all then other than it helps bad actors who might be in play in a variety of ways including misleading people on threads in security forums?
All or nothing.
-
Status update:
I am at a point where I need help. I am not a BSD or UNIX guru. I need help getting pf configured with a NAT behind it. I also have DTrace working, but need guidance with what to run to get it to capture useful data during an attack.
We tested base FreeBSD 10.1-RELEASE. No pf, no NAT, just open to the wild internet. Supermule's attacks would overwhelm my available bandwidth and the box would be unreachable. The instant they stopped, the box was back.
Then I tried to configure pf and screwed myself. I don't have console access to the bare metal FreeBSD box, while sitting on my couch. I'll fix it when I'm in the office today.
After screwing myself, I had yard work to get done before the rains that saturated Texas attempted to do the same to Georgia and deliver a repaired laptop to the owner of a barbecue restaurant.
-
Supermule's attacks would overwhelm my available bandwidth and the box would be unreachable.
Orerwhelming bandwidth is the expected situation, we're concerned about overwhelming the CPU for a fairly high end CPU and a small amount of traffic.
-
From what I could see in top, the attack did not get anywhere near overwhelming a CPU on the bare metal box. Interrupts were fairly low, as well. Unfortunately, the circuit is only 20Mb, but the CPE is a Catalyst 3500 series L3 switch, unlike my home connection.
Then I screwed myself trying to activate pf.
The box is not exactly high end, but it's not a steaming pile of doggie doo with an OS either. It only has the one Intel em interface, not an not an Intel igb. I'm going to scrounge up another GigE NIC today to stick in it, among things I have to do to pay bills.
I'm trying to test methodically, one layer at a time.
- Base FreeBSD 10.1-RELEASE. No pf, no NAT
- Base FreeBSD 10.1-RELEASE. pf, no NAT
- Base FreeBSD 10.1-RELEASE. pf, NAT no ports forwarded
- Base FreeBSD 10.1-RELEASE. pf, NAT one port forwarded to box on LAN
and so on…
-
The bandwith comsumed depends on the handling of the firewall…
It sounds odd, but its not a bandwith attack and the reply vs. no reply from the FW is the difference between 30mbit and 7-8mbit traffic.
Its hard to explain but when I see the traffic graphs its very different when the FW loses packets and when it survives.
-
Supermule's attacks would overwhelm my available bandwidth and the box would be unreachable.
Orerwhelming bandwidth is the expected situation, we're concerned about overwhelming the CPU for a fairly high end CPU and a small amount of traffic.
Exactly, its quite possible there might be too code expected to run when considering the workload Snort has to do when SM tested it with snort running.
Nothing can be done by a fw when the bandwith is tested to the max provided the fw can handle the bandwith in the first place which is going to be different due to different hw in use including differences in cpu's, bus speeds of the mb, nic's used etc etc. Thats a lot of variables to check.
Add in additional packages and services that its expected to run and before long you end up with something like a MS Small Business Server which is expected to handle quite alot of work on one box and then users wonder why networks grind to a halt when everyone logs in at the same time in the morning.
