What is the biggest attack in GBPS you stopped

Supermule

This is what I run in the datacenters pfsense clusters

http://ark.intel.com/products/47920/Intel-Xeon-Processor-X5670-12M-Cache-2_93-GHz-6_40-GTs-Intel-QPI

kroberts

Full disclosure: I'm a hobbyist here, no multi-gigabit access.

You said this works on Linux too. Is there common networking code between the two?

I would surely like to see a patch before this goes public, but IMO full disclosure to official channels might be a good option. For example, https://www.freebsd.org/security/reporting.html if it's freebsd itself, or https://www.kb.cert.org/vuls/html/report-a-vulnerability/ if it's cross-platform. Both offer encryption keys to send confidential information.

Harvy66

Anyone know what "kernel" is? When I was getting DDOS'd by SuperMule, that process seemed to be the offender. Prior to his attack, I have never seen that process. Just based off of this, kernel seems to be doing a lot of work that it probably doesn't need to be doing or is doing in a slow way.

KOM

Probably a NIC driver hook into the kernel or something like that. This may be helpful if anyone hasn't already seen it:

https://forums.freebsd.org/threads/high-cpu-interrupts-on-the-router-igb-driver-how-to-fix.28219/

Supermule

First one is idle…Second one is during DoS

pfinfo_idle.PNG_thumb

pfinfo_DoS.PNG_thumb

Harvy66

@KOM:

Probably a NIC driver hook into the kernel or something like that. This may be helpful if anyone hasn't already seen it:

https://forums.freebsd.org/threads/high-cpu-interrupts-on-the-router-igb-driver-how-to-fix.28219/

The funny thing is my interrupts were low, it was "kernel" that was high. On average, my NIC interrupts consume about 130x more CPU than kernel, but during the DDOS, kernel was suddenly doing a lot of stuff. Even when load testing PFSense via WAN-LAN+NAT, I never see kernel. Normally interrupts are the number one cause of load on the firewall, which makes sense because it's just a ton of network IO.

I wonder what kernel is doing that it suddenly decides to do 10,000x more work than it normally does.

Poorly scaling algorithm?

firewalluser

@KOM:

Probably a NIC driver hook into the kernel or something like that. This may be helpful if anyone hasn't already seen it:

https://forums.freebsd.org/threads/high-cpu-interrupts-on-the-router-igb-driver-how-to-fix.28219/

Possibly, but that doesnt explain how windows core & linux hangs when sat behind firewalls like pfsense which processes each packet before sending it inwards to the lan. Put another way it would seem pfsense can hang windows and linux machines sat behind them.

cmb

@Supermule:

Lowprofile is also in this test scenario.

And he ended up with a config that stands up to said attacks. Edit: though further testing saw other problems.

I have packet captures of the traffic that's generated by the tools from when lowprofile ran it against one of our systems. It's nothing special that I saw, and we went through multiple types. If someone would like to provide additional pcaps, I'll definitely check them out.

@firewalluser:

Have you considered that CMB is now under contract and cant disclose? This was something disclosed by Snowden, some individuals were forced/required to form a legal entity under guidance of the NSA.

And now we're into conspiracy theories. No, that's not the case.

@Harvy66:

The funny thing is my interrupts were low, it was "kernel" that was high.

It's the queues of the NIC, not just kernel. That's where a good chunk of pf's processing will show. Where you're hitting the packet filter hard, that's what you will see.

@Supermule:

First one is idle…Second one is during DoS

You have polling enabled, which probably isn't a good idea (in theory it might help such circumstances, in practice especially in a VM it's probably not good). You're also running snort, and logging blocked DDoS traffic from the looks of it. All not good for DoS resiliency.

@firewalluser:

Put another way it would seem pfsense can hang windows and linux machines sat behind them.

You're passing enough attack traffic through to hang Windows and Linux in that case.

lowprofile

My last test with 2.2.2 was a big failure. Right now i am struggling to get pfsense stable (2.2.2)
But i did a test and it was not impressive. A standard configuration. After adjusting it was still not good enough at all. So now i will go trough all tweak and tuning again in 2.2.2…. re-google and start all over. the syn proxy feature should easily had solved this issue, but i will make further test and return. I tried with a general SYN proxy rule. I locked my self out from gui... no response, then tried again since it was replying ICMP request, but no difference. The SYN proxy feature should had handled this issue, but it is not working as it should. Same behaviour.

Read this as well as i think some settings here would help. http://people.freebsd.org/~jlemon/papers/syncache.pdf
I will return after some test.

It would be nice if you could set a treshold for SYN proxy in general. e.x 100 half open connection pr. ip would trigger SYNproxy to be enabled....

cmb

@lowprofile:

My last test with 2.2.2 was a big failure. Right now i am struggling to get pfsense stable (2.2.2)

Which test was that you were running? I have the traffic saved with the name of the test if it was one of the same named ones.

I keep asking for pcaps and have gotten only what lowprofile helped me get. Supermule, anyone else, save the attack traffic to a pcap and put it somewhere I can download.

Run something like the following:

tcpdump -i em0 -s 0 -w ddos1.pcap

Where em0 is the source interface of the traffic. Replicate what you're seeing, then ctrl-c to break out of the tcpdump. SCP the file off and get it to me. Try not to make it too absurdly large, but a few GB is fine.

Supermule

Packet capture crashed and I have filed a crash report on the subject.

EDIT: Managed getting it going. Get the capture here:

http://bruksparken.com/log/files/packetcapture.zip

firewalluser

@cmb:

@firewalluser:

Have you considered that CMB is now under contract and cant disclose? This was something disclosed by Snowden, some individuals were forced/required to form a legal entity under guidance of the NSA.

And now we're into conspiracy theories. No, that's not the case.

@firewalluser:

Put another way it would seem pfsense can hang windows and linux machines sat behind them.

You're passing enough attack traffic through to hang Windows and Linux in that case.

I'm sure you are familiar with the wide ranging contracts that exist in the world today beit Non Disclosure Agreements, or even the more common non compete agreements as exampled here: http://pando.com/2014/03/22/revealed-apple-and-googles-wage-fixing-cartel-involved-dozens-more-companies-over-one-million-employees/
http://www.businessinsider.com/emails-eric-schmidt-sergey-brin-hiring-apple-2014-3?IR=T
http://venturebeat.com/2014/05/23/4-tech-companies-are-paying-a-325m-fine-for-their-illegal-non-compete-pact/

Put simply, you are not in a position to prove your innocence, because

To adhere to the terms of any NDA contract you may have been forced/coerced to sign would mean any disclosure would render you in breach of your contract and liable to whatever penalties may have been included in any agreement and who in their "right" mind would put themselves at a disadvantage?
Even if you have not signed any NDA contract you still cant prove your innocence, ergo the spooks & govt(s) still win, its classic divide and conquer techniques, which then begs the question why trust military & govt(s) or banks who carry out activities in secret?

What I can say is trust can take ages to build up, but can be destroyed in seconds.

On the point of passing enough traffic through pfsense, this has happened with less than 1mbits of traffic, a simple web page loading can trigger the OS cores to hang. Volume is irrelevant in the example I mention, but in relation to this thread and amounts of data, I wondered two things, exploiting the CPU designs namely cache and/or something network related as also mentioned by Kom here
https://forum.pfsense.org/index.php?topic=91856.msg517296#msg517296

I'm inclined at this stage to err towards something nic related but I will examine the zip posted by supermule to see if I can see anything untoward, but this could be a variation on the heap spraying exploit http://en.wikipedia.org/wiki/Heap_spraying

I wonder if those affected are running snort and if so do the problems still exist, assuming snort is already aware of the problem much like AV software need to have found a virus before it can protect against it?

All of the above is said with the best of intentions and for it to be educational to those who might not be aware of the deceit and duplicity in the world today.

Edit.

Has anyone tried an earlier version of pfsense like a 1.x version by any chance? ;)

Supermule

M0n0wall suffers the same.

I am running Snort.

I can easily test without it. 2mins.

Supermule

Download it here.

No Snort running, but same behaviour.

http://bruksparken.com/log/files/packetcapture_no_snort.zip

firewalluser

How about an earlier version of pfsense which will have an earlier version of freebsd in as its looking like a OS issue at this stage provided your nic(s) is/are supported in the earlier version of freebsd?

http://files.uk.pfsense.org/mirror/downloads/old/

Supermule

Havent tested below 2.0.3

firewalluser

Might be worth trying a 1.x version then as its a process of elimination.

Once/If a version is found that is resiliant to this problem then its a case of finding the differences which between the version that works and the next incremental version that doesnt work.

Not hard to do but will involve a little time when using a text comparison/difference tool like this online example http://text-compare.com/ as both freebsd and pfsense are opensource. Harder to track down with black box software though.

fwiw.

Supermule

I might test OpnSense to see if it has the same issues…

firewalluser

Its a fork and like Kom I believe at this stage its a nic hook issue in the freebsd OS, hence my suggestion to go back to an earlier 1.x version of pfsense which runs an earlier version of freebsd, but feel free to still check out the fork for piece of mind.

Supermule

Cannot even install it neither in I386 or AMD64 :D

2.1.5 as I have running in the datacenters are much more resiliant to the SYN flood.

Attached a dump of system activity.

It doesnt get unresponsive at all and is contactable at all times.

Only thing hanging is routing to the servers behind takes forever.

2.1.5_activity.PNG
2.1.5_activity.PNG_thumb