What is the biggest attack in GBPS you stopped
-
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…
-
I use the default, which seems to be "Keep State". I won't use SYN Proxy because it breaks the RWIN, limiting it to 64KB.
-
Why is that an issue?
-
RWIN is how much in-flight data you can have, and at 100Mb/s, 64KB is not much data. At 100Mb, the max latency you can have before your bandwidth is reduced is 5ms. At 10ms, your maximum bandwidth is 50Mb. A system 30ms away from me would at max get 16.6Mb/s from me if they initiated the connection.
Remember, SYN proxy only affects incoming connections, so for most users that make out going connections, they won't see this issue, but if you're running any services on TCP that listen, they will be affected.
-
Doesnt the client scale the RWIN value by itself based on the latency to keep maximum throughput on the connection??
Despite using SYN Proxy as state in the FW?
-
The old RWin only supported up to 64KB, the new extended RWin that supports up to 4GB is configured during the TCP handshake. Since SYN proxy doesn't allow the receiver to participate in the handshake, SYN proxy assume the 64KB because it can't know if the target will actually support the newer RWin.
Or something along those lines. The main issue is that the increase from 64KB to 4GB was a bandaid fix. Since the field is only 16bits, they use a multiplier during negotiation, but only newer TCP stacks understand the multiplier.
http://tools.ietf.org/html/rfc1323
The scale factor is carried in a new TCP option, Window
Scale. This option is sent only in a SYN segment (a segment with
the SYN bit on), hence the window scale is fixed in each direction
when a connection is opened. -
So if one side is using delayed acks or dont send them at all, then it fills the stack until its dropped by RTT??
And thereby filling the pipe quickly and grind it to a halt if PPS is big enough?
-
If the other side does not send ACKs in a timely fashion, the un-acked data gets resent. After n seconds, the TCP connection times-out if no ACKs are received. But yes, the sender is should not have more outstanding data sent than the agreed upon amount. Technically the sender could send more than the RWin, but it would be a bad actor.
-
Even if it has the "none" setting, it crashes…
Not true, though you have to actually correctly put in rules so no states are created (both in and out directions).
There are a variety of tuning options new to 2.2.1 under System>Advanced, Firewall/NAT, to granularly control timers, which greatly helps with DDoS resiliency. TCP first in particular for SYN floods, turning that down to 3-5 seconds or so is probably a good idea if you don't care about people with really poor connectivity.
