What is the biggest attack in GBPS you stopped
-
Hard to know who is doing it now isn't it?
-
FreeBSD is a good platform. Even PFSense moves forward slowly, as long as it keeps moving forward. It works good enough for me. If I ever stopped using PFSense, I'd probably just switch to FreeBSD/PCBSD and learn how to configure things directly or use packages if they exist.
This is the opposite of what I've done. I've been using FreeBSD as my desktop for a long time (yes, since the 3.3 days), with a couple of Windows machines in home network. Dual homed, PF (not IPFW) enabled. Requirements are simple enough that the network diagram fits on a single page, so rules are straight forward. OpenBSD documentation for PF is excellent, some differences as the FreeBSD version lags/differs, but close enough. I went to a SG2440 just to minimize downtime for the rest of the computers when I wanted to upgrade.
-
And that the pfSense team doesn't really seem to be very engaged in figuring it out so it can be fixed doesn't instill any confidence that it will be fixed anytime soon. In fact it indicates that they either have no idea what's causing the issue, or that they do know and know there is no timely fix on the horizon. So down play it. Just multiplies the sentiment.
As I have pointed out - when you are dissatisfied with the way a vendor handles a perceived security issue, then do a proper full disclosure. This thread is at page 18 with about zero useful information. ("Oh noes, pfS suxxx", "PM me to get p0wn3d", "Watch this YT video to see pfS GUI die" or "I had a nice talk with Mr. Unknown" and similar noise does not count as useful, really.)
-
Then why dont you enlist and try to help if you are that good?
And then we can shower the thread with useful information and make a full disclosure?
-
Enlist for what? PM me to get p0wn3d and I'll produce another YT video? Kidding, right… ::) There are these FreeBSD mailing lists or https://www.freebsd.org/security/ if you think it's a security issue.
-
DEFCON's coming up. Give a presentation and take down their shit. I think they rely on BSD/pf. Want attention? That'll get it.
-
I love you to bro.
Thanks for trying to spread some negativity and get a pfSense vs Fortigate fight going on your way out. You will be missed.
No fight here. Try to understand my decision. I can't run a business with these conditions. I hope it will get better in future, but i can't wait. I made a PoC which conclude the obvious issue… = pfsense.
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.
You are 100% right, thats why you should read my post again. :)
I run pfSense on multiple WANs and LANs on the same box for my business. I'm also hosting multiple web servers and mail servers. Never once taken down by any attacks.
What are you doing to subject yourself to these kinds of attacks, and why hasn't your ISP done anything to mitigate them?
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.
It just go trough the protection, the attack is too small. I know pfsense is not a mitigating box, for that i do have Arbor. but if it can't stop/drop/handle these small SYN flood unless you do some "dirty" tweaking and make 1 new TCP rule pr. rule… then it is not this worth. too much "noisy" and still not perfect.I am hosting several servers, webservers, exchange, etc. (customers) When you have public services then your network will be a victim of this type of attacks, soon or later.
I will be watching PFsense releases in future, but at this moment there is too much negative to say, regarding new updates, SYN flood handling, crashes etc.PFsense team should make a feature to better handling SYN flood, like fortigate and 1287 other vendors, a policy with features for type of attack and a threshold. At this moment one have to make 1 new TCP rule along with existing rule, and make limitations in many fields... too much to administer and too much can go wrong.
-
Thats not whats happening.
I will take you down, but you can helt in logging and whatever you can do in the other. Options I dohnt have since I know little of FreeBSD, but I know you are a contributor to a lot of things, so why not help out. Usually it takes 5-10 mins to get the captures needed to disect whats going on.
Try to be positive :)
Enlist for what? PM me to get p0wn3d and I'll produce another YT video? Kidding, right… ::) There are these FreeBSD mailing lists or https://www.freebsd.org/security/ if you think it's a security issue.
-
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!
