What is the biggest attack in GBPS you stopped
-
What are you doing to subject yourself to these kinds of attacks, and why hasn't your ISP done anything to mitigate them?
Really? You expect a business to rely on ISP to protect against a low bandwidth attack such as this. A business could be down for days before being able to get an ISP to take meaningful action. Sure hope that it is not pfSense position that an ISP should protect a business from such a low bandwidth attack so their product doesn't have to.
Yes, that's how it's usually managed.
Stopping attacks that are taking down a piece of infrastructure are usually stopped further up the chain. I can easily pick up the phone right now and get my ISP to stop a low bandwidth SYN if I asked them, and we would come up with a solution to protect me, their customer. YMMV.
My conclusion was not based on a home connection where hosting game servers.
I am located in a prof. datacenter with DDoS protection from Arbor trough upstream provider. My pipe never gets exhausted, and i can resist any attack except low bandwidth SYN/TCP ACK flood.
I'm in Equinix NY4. I can have any attack mitigated upstream with a 30-minute SLA; obviously depending on the type of attack, but I'm sure a SYN flood would easily be resolved within 30 minutes.
Again, if you have a piece of infrastructure that has a vulnerability and you cannot mitigate it upstream, I would seriously question the security design of your network.
-
Again, if you have a piece of infrastructure that has a vulnerability and you cannot mitigate it upstream, I would seriously question the security design of your network.
… or a better solution, change the hardware. I dont want to call my ISP each and every time there is a small SYN flood. I expect my firewall to handle it, which is possible, just not with pfsense.
There is nothing wrong with the infrastructure design. I have been in touch with many hardcore network people, everyone was pointing to the firewall which i by purpose was not taking seriously. Now i do after testing it against other vendors.When you are hosting hundreds of servers which is unmanaged (customers choice) then you need a proper firewall to handle this common attacks, it should be basic stuff in each firewall. Cisco, Juniper, Fortigate, Checkpoint, SonicWall, they all have this SYN protection which at the end is just a feature to control the flow and focused on UX.
With a SLA on 99.99% to my customers, i can't afford any downtime due to 10mbit SYN flood. Indeed i can call my upstream provider, but that is just not how you should handle it.
-
I'm really seeing the logic in the point that others talked about, several times actually…
The end users firewall really isn't the place to stop or mitigate a DDOS.
I don't care what packets are coming in, 5Mb/s of packets is not an "attack", that's an aggressive port scan of your subnet or something. Other than states getting full up, anything less than 1Gb should not take down a modern high performance desktop/server CPU. Something is being incredibly wasteful by several orders of magnitude.
Let me put it in a car analogy. If I purchased a truck that claimed to be able to tow 2000 lbs, and I found it could not tow a 2000 lb block of water, would you blame the water and say "well, it's only meant to tow wood"? Packets are packets. New states do trigger a slow path, but it should not be that slow. Something is really really wrong. We're not talking about 2000 lbs of water and saying be careful of sloshing, it can effectively push you over your tow limit because of sloshing stress. We're talking about, saying "If you tow liquids, because of sloshing, you can only tow 16oz, but otherwise 2000 lbs for solid materials".
-
Exactly and it takes pfSense offline immediately!
Which it shouldnt do if everything was working as it should.
-
-
Be constructive Doktor!
This is an iinvitation to test with me. Then you can see and analyze yourself and help out.
And yes if this hits you then you are.
-
Again, if you have a piece of infrastructure that has a vulnerability and you cannot mitigate it upstream, I would seriously question the security design of your network.
… or a better solution, change the hardware.
Change the architecture.
I have a Palo Alto on the border because I want a security appliance there, and then there's an F5 behind that, and of course pfSense next. This is just a general, high level view; there's more than this. I support customers in finance and life sciences.
If I cannot handle an attack with those security layers, I escalate to the ISP.
With my SMB customers I'm looking at the Mirkotek as a $40 "fix" to stop the SYN packets in front of their pfSense installations. As I mentioned before, I might be inclined to test it out with Supermule to see if it is effective.
-
I would be glad to help Tim :)
-
So I tested it with Supermule.
Well I have 3 links (40/100, 20/20, 20/20)He took me down in 1 second with approx 3.09 Mbit traffic.
I have webserver behind this and all I see in that log is few lines of ACKs sent back and then silence.He syn flooded me on one (1) line out of 3 and everything went down.
Very nice >:(
-
So attack on one IP with 3.09mbit of traffic took down master AND slave as well despite not even running on that public IP??
Correct?
-
Yes, everything went down in less than 5 seconds.
-
You could be right on this one.
Yeah, we are all doomed. @Supermule:
Exactly and it takes pfSense offline immediately!
-
The kid in me wants more DDoS anecdotes.
The adult in me wants more debugging.Do syncookies and/or syn-cache help any?
I have a few days free. Send me the damn thing and I will read the FreeBSD handbook and solve what I can.
-
@supermule have you opened a bug report on redmine with some specifics & mailed the script/software/procedure to the devs ?
i doubt we'll get this sorted without their assistance.also, someone (who knows freebsd) should try to replicate it on stock freebsd
-
SSDD….
-
Yeah, we are all doomed. @Supermule:
Exactly and it takes pfSense offline immediately!
Yes you are. Never seen an active idiot like you on a forum. All your post (went through 100's, quite boring) are only negative, either you post google pics, "WTF", "NO", or "HELL"
Be a man, do some test before putting out shit…
-
@supermule have you opened a bug report on redmine with some specifics & mailed the script/software/procedure to the devs ? i doubt we'll get this sorted without their assistance.
No, of course not. It's much better to start a 20page "PM me to get DoS-ed" thread. ::)
Be a man, do some test before putting out shit…
What'd be purpose of the test? To post here yet another "oh noes, pfS died, t3h suxxx"?
-
I think the main point is there is no reason to scream fire in the same theater twice.
I'm sure whatever can be done will be done.
I'm just a casual bystander and for me the thread got boring already because I know the main pfsense guys and more than likely people inside BSD are on it by now.
The people who are continuing the thread already shed light on things but will not be the same people who resolve the issue.
So me personally… I think its time already to let the coders do their magic and wait.
-
Monthly updates for a long standing critical flaw would be nice. But I can appreciate busy programmers, been there, done that.
-
This is either really grave and so incurable that no one wants to officially talk about it and report back to community or they haven't figured out what Supermule does to bring it down.
Either ways this is very concerning. It's funny how you see no signs of devs being cocky about this like other issues. I hope that means they are hard at work. Really, pfsense will be useless if this is what happens…
I think we all owe Supermule a BIG thank you! Anyone says anything else is trying to hide this serious issue.
If devs have nothing to say to what Supermule has established then this is probably a business decision to shoot down the free version. I wonder if previous versions - all the way back to 1.2.3 - are also effected y this (Supermule would you please test?). If they are not then this is most likely a business decision. If they are, then it's probably an inherent issue with FreeBSD that needs attention.