What is the biggest attack in GBPS you stopped

Apr 13, 2015, 12:16 AM

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?

kejianshi · Apr 13, 2015, 1:16 AM

I think its established by now…

Harvy66 · Apr 13, 2015, 1:21 AM

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.

Nullity · Apr 13, 2015, 1:37 AM

@Harvy66:

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.. ;)

Supermule · Apr 13, 2015, 8:44 AM

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.

doktornotor · Apr 13, 2015, 9:06 AM

@Supermule:

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.

Supermule · Apr 13, 2015, 9:11 AM

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....

NOYB · Apr 13, 2015, 9:28 AM

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.

Supermule · Apr 13, 2015, 9:57 AM

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

gadnet · Apr 13, 2015, 11:31 AM

i try to setup a test machine for that with enough bandwidth but it will take time.

Apr 13, 2015, 11:39 AM

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.

Supermule · Apr 13, 2015, 11:44 AM

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.

Harvy66 · Apr 13, 2015, 12:23 PM

@Nullity:

@Harvy66:

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.

Supermule · Apr 13, 2015, 12:31 PM

You run it on bare metal Correct Harvy66??

Harvy66 · Apr 13, 2015, 12:31 PM

@Supermule:

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 SFX12V

Using 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.

Supermule · Apr 13, 2015, 12:34 PM

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 :(

Harvy66 · Apr 13, 2015, 12:55 PM

Almost forgot to mention, I have no rules, not even the default block, that logs. So no worries about log spam during the attack.

KOM · Apr 13, 2015, 1:36 PM

My node was running on ESXi 5.5.0.

Supermule · Apr 13, 2015, 1:46 PM

So no forwards at all in the rules??

Can you post a screendump of the WAN rules??

Because that makes it SHIT creepy!

@Harvy66:

Almost forgot to mention, I have no rules, not even the default block, that logs. So no worries about log spam during the attack.

kejianshi · Apr 13, 2015, 1:57 PM

Dude - it crashes. They know. Have you tested 2.2.2?