What is the biggest attack in GBPS you stopped
-
If I were using pfSense in a business environment I'd be right behind you.
That a disgruntled employee, dissatisfied customer, or unscrupulous competitor, could take a business behind pfSense offline with such a small amount of traffic would be a really scary and unacceptable risk. 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.
I have been assuming that this is not actually a problem, and that FreeBSD/pfSense is fully capable of withstanding this attack if configured properly.
Honestly, when I first found pfSense I bought into the "omg, SuperNetAdmin must use this!", but after a few months, the GUI's limitations were obvious even to a networking newbie like me.
I like this community though. I hope it doesn't crumble…
-
I wouldn't run a business network on assumptions.
-
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.
-
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?
I used to work for an MSP that resold and supported FortiGates and thought they sucked. I tore most of them out and replaced them with pfSense.
I just received some additional equipment to build a Security Onion appliance that I'm going to mirror two WAN ports into. I could easily integrate Snort on pfSense to use the barnyard database on the SO appliance to most likely mitigate the whole SYN attack. After I'm done building it, it would be interesting to test. Plus I'd be able to capture and inspect every packet coming in. I'm also interested to see if it takes out the MikroTik switch in front of pfSense first.
-
What are you doing to subject yourself to these kinds of attacks, and why hasn't your ISP done anything to mitigate them?
Wow! Yeah it must be the attackie's fault. After all certainly no one would do such a thing without provocation.
- Certainly if a business has an employee that becomes disgruntled it is without a doubt the businesses fault.
- Certainly if a business has a customer that becomes dissatisfied it is without a doubt the businesses fault.
- Certainly if a business has an unscrupulous competitor it is without a doubt the businesses fault.
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.
-
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.
-
CMB accused me of beeing the guy behind the forum downtime yesterday.
That saddened me…
Just because I say and keep saying that there is a major flaw in the way pf handles packets, then I must be the guy taking the forum down. :(
He asked for pcaps and I told him they were available for download in this thread. Didnt hear from him again.
I need to get somebody with the right debugging tools involved in this.
-
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.
-
