Pfsense freeze at DDoS attack - Tuning?
-
You can kill a pfsense FW even if no rules are applied on WAN…and thats weird.
-
?? Are you saying this specifik SYN flood kills the firewall with states even if you have no PASS rules on the WAN interface? So it accepts the packet and creates a state even though it should be blocked?
I'm worried about this issue! Still no word or reply from the pfsense guy's?
-
I think it doesn't actually create a state, I think it adds a route according to one person's idea of what's going on.
-
?? Are you saying this specifik SYN flood kills the firewall with states even if you have no PASS rules on the WAN interface? So it accepts the packet and creates a state even though it should be blocked?
I'm worried about this issue! Still no word or reply from the pfsense guy's?
I thought you guys had port 80 or port forwarding on to a webserver ?
So with a 5Mbit connection you can take down any fresh install of pfSense ?
F.
-
It doesnt create a state… its difficult to explain.
On the test setup we have closed port 80. Hammering it makes it loose packets and becoming inresponsive. It takes around 60mbit of traffic.
If we open port 80, this can be achieved with only 5mbit using specific scripts...
-
Okay, that helps a bit… Not much, but a bit.
What about ESF? Still no word from the devs? -
Chris has been in touch with Lowprofile and they will create a test environment.
Havent heard anything else yet…
-
What about ESF? Still no word from the devs?
I've been in touch with lowprofile, we're going to coordinate a test.
We have and test with tools capable of generating your typical SYN flood. At some level, you're going to get knocked offline regardless of configuration if you're passing the traffic. Whatever jackass attacked the forum this morning blew out a 10 million state limit in no time. That's why this site was offline, there were so many connections flooding in that it more or less immediately overflowed any state table size. That's a huge state table limit, only a tiny fraction of commercial firewalls in the world are capable of that, and virtually none can exceed that. The most expensive Cisco ASA money can buy maxes out at 10 million, and will run you potentially well into 6 figures USD a box depending on licensed features. Our pair of C2758s (retail $2800 USD for a pair, including support) hung in as well as a pair of ASAs costing well into 6 figures would have in this specific attack. Dead in either case under that type and scale of attack, though, until/unless you start blocking the traffic.
We're in the midst of doing a good deal of in-depth performance analysis internally. This will be part of that.
DDoS is hell on stateful firewalls is the basic summary of this thread. It's not specific to anything in any particular firewall. There are some unusual circumstances in this thread that I'll be looking into.
DDOS'n someone else's servers is probably a great way to get the FBI involved.
Yes, it most definitely is.
No harm done. They sell it, we test it against what they have….
No crime involved :D
It is unquestionably a crime to DDoS something that's not yours.
"No harm"? Someone wasted several hours of 4 people's time internally today. I'd rather be pushing us towards 2.2.1 release than spending time mitigating a childish attack. If it were to happen long enough, and at a high enough rate, to raise our 95th percentile, it'd cost us money in bandwidth in addition to the cost of time spent mitigating. Potentially cost us lost sales.
-
Assuming people are paying for these "services" there is a money trail and if there is a trail and they annoy the wrong entity with an attack they can and eventually will end up with men with badges and guns knocking at their doors. Play around long enough and everyone gets caught.
I could even see law enforcement spoofing those sites, accepting payments and showing up in short order to arrest people if the pay for attack sites get used enough.
-
FYI and to end any insinuating here… It wasnt any of us.
Just to make that perfectly clear. :)
-
I wouldn't have thought it was you - haha…
But I'd assume it was probably someone who is watching this thread.
-
It would be the easy pick… any one of us proving our point. But thats not how we work.
We only test our own setups or setups that we have agreements with, for that exact reason and thats why we came across this issue.
