What is the biggest attack in GBPS you stopped
-
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.
-
You run it on bare metal Correct Harvy66??
-
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
Bare as a newborn.
Intel Core i5-4570 Haswell Quad-Core 3.2GHz
Intel Ethernet Server Adapter I350-T2 - OEM
MSI B85I LGA 1150 Intel B85 Mini ITX
G.Skill DDR3-1600 8-8-8-24
SAMSUNG 840 EVO - 2x
SeaSonic SS-300SFD 300W SFX12VUsing iperf, I get 1.3Gb/s WAN-LAN through NAT with only ~5% total cpu load. Unfortunately my desktop NICs doing the iperf cap out around 1.3Gb/s, so I could not test any faster. My latest desktop build has an Intel i210 NIC, but my wife still has integrated.
-
Thanks man! That excludes the hypervisor in this case….
So a 40Mbit/S specific protocol DoS makes the admin interface lose packets....
In my world, its the symptom of something VERY wrong :(
-
Almost forgot to mention, I have no rules, not even the default block, that logs. So no worries about log spam during the attack.
-
My node was running on ESXi 5.5.0.
-
So no forwards at all in the rules??
Can you post a screendump of the WAN rules??
Because that makes it SHIT creepy!
Almost forgot to mention, I have no rules, not even the default block, that logs. So no worries about log spam during the attack.
-
Dude - it crashes. They know. Have you tested 2.2.2?
-
Not yet.
-
I would assume that an application DDoS would be impossible if the application only needed to process the packet header before knowing a packet's legitimacy. There are quite a few superfluous firewall rules hidden behind pfSense's pretty GUI.
Harvey66, can you look at your queues and see … well, anything interesting? (Nice server btw!)
Supermule, are you spoofing IPs to achieve this? Perhaps confusing the firewall's states? Meh, that'd be too easy. Malformed packets? IPv6? Packets with knives duct-taped to them?
I still hope this is a case of misconfiguration, but I am doubting it.
-
Yes spoofed ip's and different packetsize as well.
Both TCP and UDP if needed. Also ipV6 if needed to test…
-
I'm not home to get my rules, but I have only a few WAN rules for NAT and a bunch of floating rules for traffic shaping. About the same number of floating rules as what is created by default when you run through the Traffic Shaping Wizard.
I did not check my queues after the test for any dropped packets. Most of the time during the first few tests, PFSense was unresponsive, so there would be no way for me to get information as it was happening. During the bandwidth DDOS, PFSense was perfectly responsive, even though CPU was at 100%.
-
Floating actually has fewer rules than stock QoS. Some of the games I do not plan to ever have and some rules overlapped in ports for correctness reasons, but I didn't care to have duplicates and some also had separate rules for UDP and TCP that could be combined.
-
What proxy state do you use for the rules?
Even if it has the "none" setting, it crashes…
