What is the biggest attack in GBPS you stopped
-
Send me a PM :)
-
I just suddenly thought it would be funny if the issue was the logging caused by the default block rules was spamming his log and hanging the system, with the abrupt swings caused by the system attempting to make room in the log.
I think we covered this at one point, but I'm in a daze from lack of sleep and a busy week…. And Monday is tomorrow.. uhggg.
-
supermule ran the test on me and my wife got angry, I was having fun.
It started off like this, about 70Mb/s of traffic coming in and my WAN dropped out
After a tens more seconds, it got worse
Overall CPU usage seems low during this time, but part way through, really really bad things started to happen. I could not even talk to my admin interface.
This was all during the sub max bandwidth test of around 70Mb or less.
Eventually it transitioned into a bandwidth DDOS which maxed out my connection. PFSense started to respond again, but the Internet was mostly dead as expected when you have no bandwidth
The first quite of tests were the worst. The low bandwidth test made the entire PFSense box unresponsive
During the first tests, when PFSense was responding, it claimed CPU usage was low and System Activity looked normal.
During the high bandwidth test, CPU usage was high, but at-least PFSense was responding correctly.
-
Your box died using specific low bandwith scripts as predicted. Low bandwith script not using your CPU either.
You box got more responsive using SSYN but using larger packet size. 100mbit traffic….
-
I noticed the dashboard didn't show "70Mb" anywhere, but I did see it on the Traffic Graph which I should have kept. You can see the first spike of blocked traffic being around 70Mb. I had to reboot to get RRD sampling again, the service seems to have stopped working, but I think that has been discussed elsewhere and maybe even fixed in 2.2.1.
-
Another thing is that you can monitor your realtime traffic graph updating every second, get slow and starting to update maybe every 10 seconds or so…
-
Very interesting. Now you have my attention.
-
Hello together,
I am pretty new to pfSense and Firewalls such as based on Linux, Unix or BSD
and there was a post where @supermule, @harvy66 & @derelict where making some
interesting comments I really don´t know what was the meaning of them, so sorry if am
asking some silly questions about.I read this post also like another one concerning the DDoS/DoS debate across the forum
and I really has also some questions on top related to this thread here.It seems to only affect UNIX/Linux/BSD distros.
The first thing what I want to know, why a firewall like pfSense and such mOnOwall,
IPCop, IPFire, Untangle, SophosUTM or ZeroShell was compared against the MS Firewall?This is in my eyes a contortion of the whole situation, because the both firewalls are
absolutely working different each from another and so it should not be compared against.I revived an old ISA Server 2006 and testet it out front and it wasnt affected when configured.
The MS Server Firewall is acting as follow: "Nothing comes in, that is not requested from inside"
by blocking it like a tennis ball that is hitting a wall, it purely cant join in.But the pfSense want to let IP packets coming in to inspect them and then let them
going through or the packets will be blocked, but there fore the packets must before
coming in and not like in the other situation rebound at the firewalls NAT service.Is this true or something like this or is this a so called thinking false of mine I am in?
And the second thing is the following I really don´t understand here in this trail.
With the 70 MBit/s traffic thats hitting the pfSense firewall from the outside it
is in my eyes also a problem of the LAN Port or NIC itself and on how many
rules and/or filters are working on this LAN Port or NIC.Its in the OS. Hardware can easily handle it if you got some muscle.
- No name consumer product often feed the CPU and let the CPU doing the entire job of all.
- An Intel consumer NIC with a small chip on it that is saturating many thing by his own
- An Intel Server NIC comes with an DSP (digital signal processor) and does the entire job
itself and is not harming the CPU really hard.
So if you are now testing with 70 MBit/s of DDoS stuff it could really be that this would
smashing down one pfSense device, but another one will take this load and lames only a bit.A ordinary consumer router is doing SPI/NAT and let nothing in, ok perhaps also his
WAN port will be unreachable during the attack, but is not dying or rebooting.You mentioned Windows weathers it better. What about something like a Cisco ASA?
Other firewalls from the well known vendors are mostly going in a so called "hedgehog mode"
by closing the WAN Port and the LAN Ports at an entire count of xyz packet in xyz milliseconds
for so and so long time and then they are opening the interfaces again perhaps this will be
explaining it better because I really think that pfSense is acting in another way, can this be?No matter the cores and memory, pfSense still dies instantly.
If pfSense (NanoBSD image) is installed as read only, so many things are runs in the RAM
and if this RAM is to small or the pfSense is running out of RAM the pfSense firewall is dying
or freezing or like you both call it got rendered down is this right? Or is this only the State
Table size that is running full (39.xxx from 40.000), so that no more entries are able to be
placed in? Or should it be a greater CPU likes the shown Intel Core i-5 cpu or more then
4 cores are needed? -
I think its established by now…
-
BlueKobold, it took down my i5 3.2ghz Haswell quad with 8GB of ram and Intel i350-T2 like nothing. The entire system was rendered unresponsive, while claiming the system had low CPU usage during the brief moments the system was responsive.
-
BlueKobold, it took down my i5 3.2ghz Haswell quad with 8GB of ram and Intel i350-T2 like nothing. The entire system was rendered unresponsive, while claiming the system had low CPU usage during the brief moments the system was responsive.
]
I thought it was just another successful bandwidth DDoS, but that huge load-avg of 5-8+ is very telling.
I still think Supermule is just a highly adaptive troll though.. ;)
-
Thank you…. I think :D
What puzzles me is that the GUI becomes unresponsive despite using device polling among other things.
What worries me even more, is that you cant see the traffic on the server behind the FW thats getting the hit. It just responds as it should and keep beeing reachable from LAN side. No spike in CPU and not much traffic on the interface. (5-10mbit tops), but pfsense is completely gone.
Even if you limit the PPS creation based on the rule, it dies. I can see no more than maybe 2000 states out of 8MM total and the box is gone....
Thats actually the most scary thing.
It takes nothing to bring this site offline. When these scripts become more common and downloadable from the interweb, all hell breaks loose.
A former employee can take you offline via his private ISP if he wants due to the small bandwith needed to do it...
AS Harvy66 stated, you dont see anything unusual in the GUI. Its just gone...unresponsive and updating the traffic graphs every 10 seconds or so during the attack.
-
What puzzles me is that the GUI becomes unresponsive despite using device polling among other things.
Despite? :o You are kidding, right? Check that box and the GUI is unreachable without any (D)DoS at all. That "feature" is utter BS that should absolutely NOT be exposed in the GUI. Instant self-DOS.
-
I dont have an issue with it and it actually helped when we tested pfsense….
When not clicked, then the box was gone both from LAN and WAN, but with option checked the gui was still available despite beeing unresponsive....
-
I was thinking about a sarcastic solution (Band-Aid really) and it brought to mind this question. Does this behavior change at all for VM pfSense vs. bare metal?
Here's my sarcastic Band-Aid solution. To prevent pfSense from being subjected to the paltry 70-80 mbps required for this DOS, for every 100 mbps of pipe bandwidth run 2 load balanced pfSense VM's.
So for a gigabit pipe that would be 20 load balanced pfSense VM's. -
Yes and with 10GbE then 200 pfsense's would do the trick…..........................................................................................
TBH we havent done any tests running bare metal. I dont know if Harv66 is running it in a VM?
If its bare, then we can exclude the hypervisor in this case...
:D
-
i try to setup a test machine for that with enough bandwidth but it will take time.
-
TBH we havent done any tests running bare metal. I dont know if Harv66 is running it in a VM?
Perhaps all involved parties are willing to tell us something about this.
Was there any VM based pfSense in this tests or was this all bare metal, or was this a mixed test
equipment? Not really uninteresting for me to hear about this. -
We tested on VM's running all kinds of configs scaling from 1 CPU to 16CPU's and 96GB of RAM. No change in the end result but time it took to make it unresponsive differed a little (10-15 seconds).
We havent tested at all on bare metal so it would be nice to have Ghislain to setup a test rig.
Others are welcome to chime in as well. Harvy66 didnt inform me whether he was running VM or bare metal.
So he better answer that question :D
If he runs bare, then its 100% native OS related.
-
BlueKobold, it took down my i5 3.2ghz Haswell quad with 8GB of ram and Intel i350-T2 like nothing. The entire system was rendered unresponsive, while claiming the system had low CPU usage during the brief moments the system was responsive.
]
I thought it was just another successful bandwidth DDoS, but that huge load-avg of 5-8+ is very telling.
I still think Supermule is just a highly adaptive troll though.. ;)
During part of the test, the incoming bandwidth was around 40Mb/s, and I was still getting packetloss to my Admin interface. The bandwidth DDOS was the only part of the DDOS where PFSense was responding correctly, the other parts of the DDOS that did not consume 100% of the bandwidth left it unstable.
