What is the biggest attack in GBPS you stopped
-
EXACTLY!
And the funny shit is, that it dies also when changing SYNPROXY state to STATELESS!
What would that tell you??
Whats even funnier is that using OVH scripts and limiting the PPS pr. rule (even the block all rule) doesnt help. You can create an advanced ruleset with 100PPS and it still dies on specific scripts. Then the total bandwith will be very small, but pfSense dies…
Where to look for an error like that? Its buried deep within BSD/Linux.
I revived an old ISA Server 2006 and testet it out front and it wasnt affected when configured.
Null routing won't protect you against spoofed source IPs. It's the firewall's job to drop out of state packets, not die. I understand that the fast path is if the state already exists, I understand that running through the rules is not quite as fast as the fast path, but that's not the issue either. The issue is dropped packets are some how the most expensive path of all, to the point that the router dies with only a relatively trickle of them.
Maybe this is more of a FreeBSD issue than PFSense, but it seems to be something misconfigured or a fundamental flaw.
Step 1) See if packet is part of an existing flow, if so pass, else goto step 2
Step 2) Check packet against rules, if passes, create new flow, else goto step 3
Step 3) Drop packet then jump off a cliffStep 3 needs to be fixed to not be so emo.
-
I would like to see some examples of someone stopping, or even slightly mitigating, a UDP-based DDoS while only controlling the final hop.
as long as you do not fill up the pipe i would have hoped a
INCOMMING UDP to this IP => DROP ALL
could let me have my web server continue working, this should not cost that much to a dual eight core xeon with multiple 10gbps chelsio T5 cards and plenty of ddr4 ram.
I understand i have only a theorical 2000ft view of it but the numbers seems to indicate that this level of hardware is theoricaly capable of handling the flow, now the cost of the operating system and tcp stack is a big part of unknow here but i was naively thinking it could do this.
I am not trying to do this on the cheap, what i am trying is to keep control of it, opensource is a way to keep control of what is done and beter than a blackbox imho. Also more important i am trying to see if anyone has such setup. All the answers here indicate that this is not the case and not feasible that i should look for an upstream protection. If this is the experience of people on the field i understand, i keep looking anyway.
-
opensource is a way to keep control of what is done and beter than a blackbox imho.
OpenSource or Closed Source, Black Box or Self made Box, is all either for me. If I have a problem
and find one who is also able to solve it out, that is my dealer!See where they are placing their solution, between the routers and the firewalls.
And you try to find out a way to solve the problems out at only one point, the firewall.
 -
It's like saying there is no point to lock your door because bank are robbed ?
No, I'm saying that the strongest door you can find will happily collapse when it's being pounded on by a tank.
-
Try to add this manually in the system -> tunables
kern.ipc.somaxconn = 32768
And test again. We have seen some improvement using that setting
-
Try to add this manually in the system -> tunables
kern.ipc.somaxconn = 32768
And test again. We have seen some improvement using that setting
Was the improvement seen during a TCP or UDP DDoS?
-
Test using TCP scripts.
-
@KOM:
It's like saying there is no point to lock your door because bank are robbed ?
No, I'm saying that the strongest door you can find will happily collapse when it's being pounded on by a tank.
If what Supermule is saying is correct, 70-80 Mbps is no tank. It's like a spit wad pea shooter.
If pfSense really can be taken down by that, that is a huge serious issue.
Its in the OS. Hardware can easily handle it if you got some muscle.
I can take this site offline using a specific type of traffic that takes no more than 70-80Mbps bandwith.
When that traffic hits pfSense, its dead. Goes offline instantly. No matter how powerful the hardware is.
I run 8 Core, 16GB ram and SSD. Dead in a second if it hits.
-
It is. And we have contacted the dev. team but no replies at all from Chris on this issue. (2-3 mths).
-
You mentioned Windows weathers it better. What about something like a Cisco ASA?
-
We havent had the pleasure of having one available to test.
-
Christ, we are back to this "oooooooh I've got a supersecret attack to instacrash pfSense" noise again?
-
If what Supermule is saying is correct, 70-80 Mbps is no tank. It's like a spit wad pea shooter.
Well, it really depends on what you have. 70-80 Mbps wouldn't take down my corporate link, but it would totally hammer the links of many smaller companies I know.
If pfSense really can be taken down by that, that is a huge serious issue.
Agreed. However, I will reserve judgement until I see more than hand-waving.
-
Send me an IP address to test….
Then I will surprise you.
-
@KOM:
Well, it really depends on what you have. 70-80 Mbps wouldn't take down my corporate link, but it would totally hammer the links of many smaller companies I know.
This is not about taking down the "link" (filling the pipe). It is about taking down pfSense. In which case the link (pipe) may as well be down. The point that is being put forth is that it doesn't matter that you have gigabit + pipe when it only takes about 70-80 Mbps to take down pfSense. Rendering the pipe useless.
@KOM:
I will reserve judgement until I see more than hand-waving.
Supermule has made the offer to prove it. What are you waiting for? Accept the challenge.
Supermule has made the offer to prove this several times in this thread. Would someone please take the challenge. I would but don't have 70-80 Mbps of bandwidth.
-
What are you waiting for? Accept the challenge.
I already did and didn't see what he was talking about. He blasted me with a sustained 90 Mbps, my link max. Our access was slow and I was getting service alarms from our external sensors, but pfSense was responsive. I didn't see anything that I wouldn't already expect to see while under DoS. He wanted to try another test where he blasts a port-forwarded server but I didn't have time or patience today for that.
-
From the outside, his link was taken down immediately and it didnt respond to ping at all.
And that was on a pfsense that had NO port forwards set.
If it had a server behind and actually trying to route it, then his GUI would be hit as well.
-
But why would the GUI be slow? While under full load, my CPU never rose above a few percent. Minor disk activity.
I do think it would be nice for someone official to chime in either way.
-
Exactly. It doesnt but it takes you offline even if it shouldnt…. but wait until you actually have a route to a server.
Then the load will be very visible in the GUI. Even if very few states and not much load is on the system.
You will see it in traffic graphs among other things, that they dont update as it should. There could be as much as 10 seconds between the graph update when hit.
-
It doesnt but it takes you offline even if it shouldnt….
Maybe I'm misunderstanding something, but yes, I do fully expect to be blown off the network if you flood my WAN. That's a DoS by definition, is it not?
