What is the biggest attack in GBPS you stopped
-
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.
-
Snort is not the issue since it didnt matter if it was there or not.
I wanted Snort on the testbox because its nice and I wanted to test it to see if it did somthing bad/good in regards to the overall load on the box.
When one core hits 100% its gone….
-
Well lots of possibilities but imo until we can get Dtrace working on a pfsense machine its going to be guess work for now.
-
EDIT: Rant over…
-
Any reason why?
Perhaps they feel Dtrace is not the best tool for the job?
Maybe too busy in the short term?
Some other reason?It still doesnt stop us from having a go though does it?
-
-
Yes and the dev's dont want to help at all.
Devs have helped.
I agree with Tim, here. I started a conversation with the Devs last week. Not going into it completely on this thread though.
Long and the short of it was:A) We have a mismatch of problem and solution (DoS attack and Stateful packet filtering device)
B) We need to recreate the problem on FreeBSD 10.1-RELEASE. (Something I am working on with Supermule)
C) DTrace will help locate the issue, and the quickest way to get it going is on a stock FreeBSD box.The message from devs was also educational as to the architecture of BSD in general, and FreeBSD specifically.
When we isolate the issue, I will release documentation. Keep your pants on. If you can help with tracing or logging, or configuring pf then help me. It'll help the community get the desired results (pfSense more resistant to nefarious scripts) much quicker.
-
https://forum.pfsense.org/index.php?topic=24337.0
Very interesting thread!
Do we have any that have something else than em driver nics on the boxes?
-
https://forum.pfsense.org/index.php?topic=24337.0
Very interesting thread!
Do we have any that have something else than em driver nics on the boxes?
So it's a driver and an OS issue, you don't say? ;D