What is the biggest attack in GBPS you stopped
-
@KOM:
OK, so 45 forum pages later, we have determined that there is a problem in pf that may or may not get fixed by someone sometime, perhaps.
Can we close this thread now already?
+1
-
@jwt:
Regardless of whether or not this low bandwidth DDOS traffic should be stopped upstream, 3 mbps of any kind of traffic should not render a modern business class firewall useless. Period.
The root issue being in FreeBSD pf doesn't changes that. And since pfSense is built on FreeBSD it is by extension a pfSense problem too.
What specific work has the pfSense project done with the FreeBSD project to resolve this specific issue and provide a fix?
I outlined what we've done above. We have, what I believe to be, a similar program which can cause a similar issue.
If we develop a fix, we will attempt to upstream it to FreeBSD.
Right now, nobody is actively working on this "issue", because it is, fundamentally, a misapplication of technology.
Is there a bug report with freebsd so we can keep tabs on it?
-
Is there a bug report with freebsd so we can keep tabs on it?
Read this post: FreeBSD/pf and SYN ACK flooding. Then you'll understand why there's no upstream bug anywhere. (Unlike here, they've been able to stop the nonsense in just a single page, not 45 and counting… ::))
-
@jwt:
Regardless of whether or not this low bandwidth DDOS traffic should be stopped upstream, 3 mbps of any kind of traffic should not render a modern business class firewall useless. Period.
The root issue being in FreeBSD pf doesn't changes that. And since pfSense is built on FreeBSD it is by extension a pfSense problem too.
What specific work has the pfSense project done with the FreeBSD project to resolve this specific issue and provide a fix?
I outlined what we've done above. We have, what I believe to be, a similar program which can cause a similar issue.
If we develop a fix, we will attempt to upstream it to FreeBSD.
Right now, nobody is actively working on this "issue", because it is, fundamentally, a misapplication of technology.
So in other words the pfSense project has not done specific work with the FreeBSD project to resolve this specific issue and provide a fix.
Could you please explain the fundamental misapplication of technology?
Thanks
-
Is there a bug report with freebsd so we can keep tabs on it?
Read this post: FreeBSD/pf and SYN ACK flooding. Then you'll understand why there's no upstream bug anywhere. (Unlike here, they've been able to stop the nonsense in just a single page, not 45 and counting… ::))
https://en.wikipedia.org/wiki/SYN_flood
Can we enquire considering the botnet element what solution is being considered?
A few thoughts on this, is if a server/service is behind an ip address where more than 1 ip address is available at a moments notice but not all ip's used, could existing states be maintained, whilst DNS is updated and services moved to another ip address a bit like the multiwan setup where wan1 is incoming and outgoing goes out on Wan2 for example.
If a server/service regularly only handles traffic from a specific region or country, could something like pfblocker be made to block anything from outside that region/country on the fly? I suspect this is why google diverts searchs to their local country domains.
What are the pro's/con's from having a recycled log of good ip addresses that have previously connected in the last x minutes or by some other pattern, which are allowed in automatically whilst the unknown ip addresses perhaps have a shorter timeout or treated with some other caution. Its possible to know that some IP address ranges will have good speed and latency by virtue of who is allocated them, whilst others may not, thinking mobile phone/satellite for the latter, so could something adaptive be considered?
Where would I find the failed ACK's being reported by pfsense in this scenario?
Edit: As theres a fundamental difference between the wiki link and this link http://security.radware.com/knowledge-center/DDoSPedia/syn-ack-flood/
namely the later appears to be exploiting out of order packets and the subsequent overhead processing them, although nothing can stop any amount of bandwidth domination irrespective of what its called be it flooding, (D)Dos, if the attacks by SM have been syn ack floods described in the 2nd link, as PF in freebsd handles this, will this not require a bit of a rewrite of the fundamentals of PF to speed up its handling of this situation? -
Read this post: FreeBSD/pf and SYN ACK flooding. Then you'll understand why there's no upstream bug anywhere. (Unlike here, they've been able to stop the nonsense in just a single page, not 45 and counting… ::))
So he refuses to provide the code that tickles this to FreeBSD's security team until some unknown condition is met. Got it.
-
Read this post: FreeBSD/pf and SYN ACK flooding. Then you'll understand why there's no upstream bug anywhere. (Unlike here, they've been able to stop the nonsense in just a single page, not 45 and counting… ::))
So he refuses to provide the code that tickles this to FreeBSD's security team until some unknown condition is met. Got it.
If its a criminal botnet thats for hire, how can SM hand over the code?
At the same time, because someone has thought to test their own security arrangements by handing over some money to test, in this case pfsense protecting their systems, whilst also possibly testing the forums is not only testing their own security arrangements, but also testing the team behind the security product and the marketing claims.
In my books whilst the methods might be arguably criminal, it does show some level of ingenuity which perhaps shouldnt be denigrated and which is the lessor of two evils, testing the system and claims, or putting out there, duff solutions which threaten even more people and their businesses? 1 business or hundreds or thousands of businesses?
Its an interesting test of various claims none the less and pfsense have come out reasonably well imo, in that their servers are not down offline for any lengthy period of time and we appear to have got to the bottom of the problems with maybe some solutions under foot.
I've been the victim of CEO's lying about their products in the past, shifting blame onto other companies namely Microsoft and when called out for it, posts deleted. Shouldnt CEO's be called out for over hyping claims?
Edit. I am also not connected with SM and whilst I could quote shakespeare at myself, namely thy doth protest too much, the above is just another perspective on the whole situation, whether we like it or not.
-
In my books whilst the methods might be arguably criminal, it does show some level of ingenuity which perhaps shouldnt be denigrated and which is the lessor of two evils, testing the system and claims…
Thanks for giving everyone on the intarweb permission to rootkit all your stuff.
PS–I never particularly liked Shakespeare.
;)
-
Could you please explain the fundamental misapplication of technology?
Tim McManus will recognize some of this because I wrote he and Anthony back in May with very similar words.
If the attack referenced here is what I think it is, then it is potentially represented by the following Perl code (reported by “torontob” to jimp)
#!/usr/bin/perl
synflood.pl - Simple SYN Flooder
Author: iphelix
Requires perl, Net::RawIP module, and root privileges
use Net::RawIP;
if ($#ARGV == 2) {
($src,$dst,$port) = @ARGV;
$a = new Net::RawIP;
while(1) {
$src_port = rand(65534)+1;
$a->set({ip => {saddr => $src,daddr => $dst},tcp => {source => $src_port,dest => $port, syn => 1}});
$a->send;
}
} else {
print "./synflooder source_ip destination_ip destination_port\n";
}We were given similar ‘C’ code that looks like it was written by a 13 year-old unfamiliar with threading which I won't post here.
In any case, the net-net is that some jackass sends a lot of frames with random (or sequential) source port #s and/or source IP addresses. (We have PCAPs.)
The pf “synproxy” stuff is supposed to take care of this, but it doesn't appear to work.
pass in on $ext_if proto tcp to $forum_ip port www synproxy state
In addition to keeping states as recommended by cmb and others upthread, there is some headroom to be had by setting following tunables. (Values are just examples.)
TCP timout settings
#set timeout tcp.first 60
#set timeout tcp.established 86400
#set optimization aggressive
#set timeout { adaptive.start 20000, adaptive.end 220000 }
#set limit states 200000But this is all crap, and the above are, at best, simplistic hacks (mostly by the OpenBSD people) seeking to hide a poor architecture by liberally applying coats of paint.
Firewalls aren't DoS/DDoS mitigation devices, they're staeful policy-enforcement devices. DoS attacks are attacks against capacity and/or state. In this specific case, capacity is the number of states that can be used.
Beyond this, state-full inspection makes no sense at all on a front-end server, where every connection is by definition unsolicited. Harden the OS, harden the apps/services, run a chrooted jail, use tcpwrappers and mod_security and mod_evasive, and use stateless ACLs in an ASIC-based router or even DPDK’s ip_pipleine to enforce access policies.
Given all of these, “pf” is fundamentally a misapplication of technology here.
By placing the server behind the stateful packet filter, you increase its vulnerability due to the potential for exhaustion of the connection table by an attacker. You can use firewalls between the tiers of a multi-tier setup, where you can control the number and types of inbound connections on a bidirectional basis, but no one who operates high-volume publicly-accessible servers puts the the front-end behind a firewall, because it does nothing to increase the security posture, and can actually be harmful.
I also see little of any value in this thread. This serves to re-enforce my opinion that the forum isn’t a good use of my time.
Using the code (above) it’s fairly trivial to run the state table out of states, but an “interrupt storm” is another issue, solved via entirely different path.
To be clear, we’ll look into it (just as we looked into it back in March when Brian/Supermule first involved us in Feb/March). Eventually we'll develop a fix, though it is unlikely to leverage "pf". There are things in "pf", and also in the use "pfSense" makes of "pf" that make any such fix more complex.
Other points:
-
FreeBSD-SA-15:13.tcp has nothing to do with this.
-
I have zero idea what BlueKobold might have meant in the first paragraph of this: https://forum.pfsense.org/index.php?topic=91856.msg540545#msg540545 It looks like a slam ("profiteer"?) to me.(*)
-
In reference to: https://forum.pfsense.org/index.php?topic=91856.msg539912#msg539912 no, it's not a network driver issue
-
https://forum.pfsense.org/index.php?topic=91856.msg539638#msg539638 show us the fix in opnsense, Brian.
To summarize, in this context/thread, we are all being dragged into participating in someone else’s drama. This is never a good idea.
(*) In general, people who make statements like "pfSense is just a GUI on top of FreeBSD" obviously have no idea what they're looking at. Making such statements only shows ignorance. I am working toward an architecture where pfSense is a set of packages on top of FreeBSD, but we are not yet there.
-
-
That would be a very good idea if possible!
Opnsense has this fix done allready and a full release on friday.
I had to register solely for this crap. This is typical opnsense.
So you advertise your "skill" on pfsense forum that has infinitely more users than opnsense forum, refuse to show FreeBSD and pfSense developers how this is being done and then provide the "solution" to opnsense. Wow, that's so opn and open source spirited! I love the fact Franco is behind this, it just proves how low opnsense guys are willing to go.
Unfortunately for Franco and you, opnsense is still light years behind pfSense even with "your" fix.
-
Read this post: FreeBSD/pf and SYN ACK flooding. Then you'll understand why there's no upstream bug anywhere. (Unlike here, they've been able to stop the nonsense in just a single page, not 45 and counting… ::))
So he refuses to provide the code that tickles this to FreeBSD's security team until some unknown condition is met. Got it.
Here's the "brilliant" supermule plan:
1. snoop on some random hacker IRC for ddos tricks
2. reveal your "brilliant" trick on pfSense and freebsd forums in order to gain larger audience
3. ddos pfsense forums with botnet in order to say "I told you so, my trick is real"
4. reveal fix is coming for opnsense which is why opnsense is better, more secure blah blah blah.I bet Franco will try to push his patchwork to FreeBSD : ) equally "brilliant" like opnsense wikipedia page which is written by biased opnsense drones (who btw, constantly try to schedule pfSense wikipedia page for deletion).
Bottom line is, they are using pure scammer tactics in order to get larger userbase for opnsense.
-
Lol
-
@jwt:
. . .
You posted a bunch of good information. Appreciate that.
However it sort of side-steps the point that pfSense can be rendered useless by as little as 3 mbps of traffic. Yes I get that handling DDOS is not the job of a firewall (misapplication of technology). But that doesn't mean a business class firewall shouldn't be expected to withstand a mere 3 mbps attack. Just because it's technically DDOS doesn't automatically mean it's high bandwidth and that a business class firewall shouldn't need to be able and expected to withstand it. I for one would and do expect a business class firewall to withstand such a low bandwidth attack. No 3 mbps of anything should be a problem for such a device.
-
Franco was the only one willing to help get it upstream and the connection was made when I asked him politely.
Nothing more in it.
Dont make this an opnsense/pfsense feud. Its not. I might have called Cisco instead but their systems are vulnerable to.
I downed the emergency hotline and 2 powerstations when testing at a customer.
While somebody is using a lot of time to write about misuse of application and lots of technical stuff that is suppose to make him look smart, then it doesnt help since pfsense/ESF can be taken offline easily as well.
So either they dont understand their own words, text or product since they are very vulnerable to.
Thats the fact. We have been trying to get ESF involved by setting up freeBSD server to test in their end. Nothing.
So pfsense is vulnerable. All over the world and people using it to host servers behind it, selling hosting is vulnerable.
So stop the name calling. Its just smoke and mirrors to a severe flaw in the eco system.
That would be a very good idea if possible!
Opnsense has this fix done allready and a full release on friday.
I had to register solely for this crap. This is typical opnsense.
So you advertise your "skill" on pfsense forum that has infinitely more users than opnsense forum, refuse to show FreeBSD and pfSense developers how this is being done and then provide the "solution" to opnsense. Wow, that's so opn and open source spirited! I love the fact Franco is behind this, it just proves how low opnsense guys are willing to go.
Unfortunately for Franco and you, opnsense is still light years behind pfSense even with "your" fix.
-
:D
Only comment I have to this.
Oh forgot to add.
You guys keep posting this as a script kiddie trying hard to be a real programmer…
In the end it takes pfsense offline with 3mb/s traffic.
Now whos the kiddie?
Read this post: FreeBSD/pf and SYN ACK flooding. Then you'll understand why there's no upstream bug anywhere. (Unlike here, they've been able to stop the nonsense in just a single page, not 45 and counting… ::) )
So he refuses to provide the code that tickles this to FreeBSD's security team until some unknown condition is met. Got it.
Here's the "brilliant" supermule plan:
1. snoop on some random hacker IRC for ddos tricks
2. reveal your "brilliant" trick on pfSense and freebsd forums in order to gain larger audience
3. ddos pfsense forums with botnet in order to say "I told you so, my trick is real"
4. reveal fix is coming for opnsense which is why opnsense is better, more secure blah blah blah.I bet Franco will try to push his patchwork to FreeBSD : ) equally "brilliant" like opnsense wikipedia page which is written by biased opnsense drones (who btw, constantly try to schedule pfSense wikipedia page for deletion).
Bottom line is, they are using pure scammer tactics in order to get larger userbase for opnsense.
-
Supermule: I edited out the accusation that you targeted us.
However it sort of side-steps the point that pfSense can be rendered useless by as little as 3 mbps of traffic.
There is no circumstance in which 3 Mbps of traffic will knock off a system (unless that's enough with your config to exhaust your state table after a bit of time). You keep throwing this 3 Mbps, but no one's actually shown that to be true. Give me a test case.
I ran through the usual test cases there on 2.2.4 tonight, flood of passed traffic, blocked traffic, mix of traffic. Depending on a variety of specifics, it might be more like 60+ Mbps of purely SYNs that are being passed and answered (and RST, so it's not exhausting states) in VMs on my laptop. jIt starts dropping some packets at that point. The virtual setup is limiting things to at least some extent, and introducing variability. Still it's handling a very respectable load by commercial firewall comparison standards. Even logging all blocked packets while getting hit with 60 Mbps of SYNs you're blocking is no problem (granted this is on a system with /var as RAM disk so it's not hammering away at a drive to log it). I'll need to run through the same on physical hardware as well to get best quality results. Messing with TCP flags on floods may have more interesting results judging from some preliminary testing. Certain things definitely reduce performance.
All in all it's not bad by firewall standards. I can push significantly more new connections/sec through a 2 core VM on my laptop than a Cisco ASA 5555-X's stated new connections limit.
-
Franco was the only one willing to help get it upstream and the connection was made when I asked him politely.
Nothing more in it.
Dont make this an opnsense/pfsense feud. Its not. I might have called Cisco instead but their systems are vulnerable to.
I downed the emergency hotline and 2 powerstations when testing at a customer.
While somebody is using a lot of time to write about misuse of application and lots of technical stuff that is suppose to make him look smart, then it doesnt help since pfsense/ESF can be taken offline easily as well.
So either they dont understand their own words, text or product since they are very vulnerable to.
Thats the fact. We have been trying to get ESF involved by setting up freeBSD server to test in their end. Nothing.
So pfsense is vulnerable. All over the world and people using it to host servers behind it, selling hosting is vulnerable.
So stop the name calling. Its just smoke and mirrors to a severe flaw in the eco system.
That would be a very good idea if possible!
Opnsense has this fix done allready and a full release on friday.
I had to register solely for this crap. This is typical opnsense.
So you advertise your "skill" on pfsense forum that has infinitely more users than opnsense forum, refuse to show FreeBSD and pfSense developers how this is being done and then provide the "solution" to opnsense. Wow, that's so opn and open source spirited! I love the fact Franco is behind this, it just proves how low opnsense guys are willing to go.
Unfortunately for Franco and you, opnsense is still light years behind pfSense even with "your" fix.
Dude, thank you! thank you for confirming everything I wrote!
edit: I had to edit this because it's just way too much fun!
Thank you for proving me right, thank you for confirming you worked with Franco on this. Thank you for saying "pfsense is vulnerable"!!!!
-
In the end it takes pfsense offline with 3mb/s traffic.
How many times do I have to ask you to provide useful details? I've yet to see any 3 Mbps of traffic that will do any harm, yet you're still making these claims.
-
Franco was the only one willing to help get it upstream and the connection was made when I asked him politely.
Not true at all. If you would have come to us with an actual useful problem report at any point, even still now, we'll be able to get attention upstream if it's really an issue. Quite possibly get it fixed ourselves, since we have multiple FreeBSD committers on staff. And I'm still absolutely willing to do that, you just refuse.
You can either backup these claims so I can actually do something about it if there is an issue, or I'm just going to ban you as a troll, because these threads are an absurd waste of everyone's time at this point.
-
@cmb
He did it to me after 5 seconds traffic graph stopped at 3.19 mbits…
I dont reall care what happened after 5 seconds but before that there was no more than 3 mbits except if traffic graph was wrong...
