What is the biggest attack in GBPS you stopped
-
@BlueKobold:
You will be able to sniff, syslog and debug for many years something and millions of clean
code audits on top, if the mechanism it selfs (SPI/NAT) is the point we have to come closerpfsense has packet capture but its limited ie it falls over after a period of time.
Syslog is not detailed enough in places.
-
@SM, Have you tried a DMZ with two firewalls?
That way you can offload some work from the front facing fw, and other stuff can run on the rear facing fw?
I know most OS'es as in servers and desktop's have a fw of sorts, but in my experience they are really quite basic not worth relying on which is why my preferred setup is to have two fw's in place with different OS's running as monocultures are never good.
-
https://technet.microsoft.com/en-us/library/cc756722%28v=ws.10%29.aspx
I think the issue is how NAT is handled and whats done to the traffic in the queue. I dont know how deep this goes but it could be different things.
I mean the differences between this different translation methods as described here;
Methods of translationis to have two fw's in place with different OS's running as monocultures are never good.
This is owed to the circumstance, if over one system a bug or issue came out it would not be affecting both
Firewalls. -
@KOM:
So we can't expect the pfSense team to fix a problem that's not in pfSense, and they are at the mercy of the FreeBSD code releases.
While we can't expect them to, they certainly have fixed some FreeBSD bugs and submitted the patches upstream, which were accepted for inclusion by the FreeBSD team.
Yup. And if there were truly a world-is-ending issue here, we'd already have done the same already.
All firewalls require some degree of tuning to stand up to resource exhaustion attacks. Settings appropriate for such circumstances aren't defaults because they would break many more circumstances than they would help, as they're too aggressive for many VoIP configurations, among other possible problems. Also general default behaviors that most people want, like logging all blocked traffic, are really terrible in that circumstance. Among a variety of other problems I've pointed out with the scenarios in these threads.
I've seen enough of Supermule's super-secret DDoS stuff from when he (or someone using something similar) DDoSed this forum several times, and some things I've gathered from others, to be able to put together a proper analysis to get upstream at some point.
It's all doable with hping or other tools. Supermule uses shady illegal services you pay for in Bitcoin that use criminal-run botnets. The same circumstance can be lab replicated without paying criminals.
Investigating this further is still on my radar. There have just been real problems that affect many reasonable real world use cases that have taken precedence. Anyone trying to stop DDoS with a firewall of any type is doing it wrong.
-
I thought DTrace was getting nowhere because it requires ESF to include it in the version of freebsd they use with pfsense?
You need more than just dtrace, various other debug options like PMC, and it needs to be replicated on stock FreeBSD with as basic of a test case as possible. We're not holding anything up there if someone wants to do it right. Doing it right doesn't involve "watch my Youtube videos of what happens when I have a criminal botnet hit me with traffic I won't describe, using an undocumented configuration that's full of sub-optimal settings for standing up to resource exhaustion attacks."
Doing it right would entail:
take this pf.conf
run this against it
end result is: …So it's clear what's being done, the end result, and how to replicate. There's no big secret in how to run a large scale SYN flood where the world would end if it was put out there.
-
There was nothing distributed about it unless Supermule has a botnet at his disposal and that's why he's not releasing any code
He's admitted to using a criminal-run botnet, which apparently isn't as strong as it used to be as machines have gotten cleaned.
-
I missed this along the line. But it does explain why he has been unable or unwilling to offer details about the attack method.
@cmb:
He's admitted to using a criminal-run botnet, which apparently isn't as strong as it used to be as machines have gotten cleaned.
-
So you are not sure??
Just because I pissed you off…
I thought you were older than the "name calling" age.
Tell me what I used... And since you have offered little to no help at all in configuring these "sub optimal" configurations, its very clear to everybody that nothing good comes from ESF other than bickering and "sub optimal" communication.
If I really DDoS'ed you then you wouldnt be online yet.
@cmb:
@KOM:
So we can't expect the pfSense team to fix a problem that's not in pfSense, and they are at the mercy of the FreeBSD code releases.
While we can't expect them to, they certainly have fixed some FreeBSD bugs and submitted the patches upstream, which were accepted for inclusion by the FreeBSD team.
Yup. And if there were truly a world-is-ending issue here, we'd already have done the same already.
All firewalls require some degree of tuning to stand up to resource exhaustion attacks. Settings appropriate for such circumstances aren't defaults because they would break many more circumstances than they would help, as they're too aggressive for many VoIP configurations, among other possible problems. Also general default behaviors that most people want, like logging all blocked traffic, are really terrible in that circumstance. Among a variety of other problems I've pointed out with the scenarios in these threads.
I've seen enough of Supermule's super-secret DDoS stuff from when he DDoSed our forum several times (not going to believe it wasn't him), and some things I've gathered from others, to be able to put together a proper analysis to get upstream at some point.
It's all doable with hping or other tools. Supermule uses shady illegal services you pay for in Bitcoin that use criminal-run botnets. The same circumstance can be lab replicated without paying criminals.
Investigating this further is still on my radar. There have just been real problems that affect many reasonable real world use cases that have taken precedence. Anyone trying to stop DDoS with a firewall of any type is doing it wrong.
-
I have offered numerous suggestions throughout your threads. If you want in-depth help with your configuration, purchase support, and we'll be glad to assist. Ultimately there's only so much you can do, because firewalls are the wrong answer to DDoS, but it's not horrible in any reasonable circumstance. If you'd even just provide a useful problem report, I would pursue from there.
If you think nothing good comes out of here, you should pay a lot more attention. Both here, and to the complete mess your buddy Franco is presiding over. We're getting serious work put into FreeBSD (passwd/group file corruption, AES-NI and AES-GCM, fixed DHCPv6 PD in ISC dhcpd port, just in the last month or so), have a power cycling chaos monkey proving we can now stand up to limitless back-to-back-to-back power cycles in worst-case file writing scenarios (where opnsense might last a handful, and probably 1-2 == dead box), while they still haven't fixed half the bugs we fixed between 2.2-BETA and 2.2.0-REL much less anything since and all the things they broke.
We're getting damn good stuff done. One of the future things you'll see is extremely high performance packet filtering. Which is ultimately what is needed for large scale DDoS handling purposes. While FreeBSD pf has improved significantly in performance over the years, and beats OpenBSD significantly on multi-core systems, there is still a lot of work to do there (or switch to a diff packet filter entirely) to make it multi-Mpps/new connections/sec capable.
-
Thing is Chris… Franco is very kind to people.
I dont really dig into the opnsense/pfsense feud since its meaningless.
What I do mind, is that if people treat me nice, then I am nice to them and vice versa.
In regards to Opnsense, then I believe they are moving along quite nicely putting out a lot of updates very quickly. They chose a different path than ESF and thats about it.
-
You hired a power-cycling monkey? I'm pretty sure I'm qualified for that one…
-
How much power does the cycling monkey have?
Can it beat Chris Froome?
Should I hire it to pedal on the back of my tandem? -
@cmb:
I have offered numerous suggestions throughout your threads. If you want in-depth help with your configuration, purchase support, and we'll be glad to assist. Ultimately there's only so much you can do, because firewalls are the wrong answer to DDoS, but it's not horrible in any reasonable circumstance. You've turned into an impossible to satisfy asshole here, while kissing ass on that other forum you love so much.
If you think nothing good comes out of here, you should pay a lot more attention. Both here, and to the complete mess your buddy Franco is presiding over. We're getting serious work put into FreeBSD (passwd/group file corruption, AES-NI and AES-GCM, fixed DHCPv6 PD in ISC dhcpd port, just in the last month or so), have a power cycling chaos monkey proving we can now stand up to limitless back-to-back-to-back power cycles in worst-case file writing scenarios (where opnsense might last a handful, and probably 1-2 == dead box), while they still haven't fixed half the bugs we fixed between 2.2-BETA and 2.2.0-REL much less anything since and all the things they broke.
We're getting damn good stuff done. One of the future things you'll see is extremely high performance packet filtering. Which is ultimately what is needed for large scale DDoS handling purposes. While FreeBSD pf has improved significantly in performance over the years, and beats OpenBSD significantly on multi-core systems, there is still a lot of work to do there (or switch to a diff packet filter entirely) to make it multi-Mpps/new connections/sec capable.
He was able to take out my quad core 3.3ghz Haswell Intel i350-T2 8GiB memory baremetal 100Mb/100Mb firewall within seconds with 30Mb/s of traffic. All of which was being blocked and not logged.
Tell me how 30k pps of blocked traffic that was not being logged constitutes as a DDOS that will consume all resources of my entire box? I've done 70k pps ping floods against my firewall and it only consumes 5% cpu and nothing is affected. That ping flood is 0 packets dropped, max ping 10ms, avg ping 0.2ms.
But when he does a 30k pps of blocked TCP+UDP traffic, my box goes to crap and my admin interface goes offline to the point PFSense does not respond to ARP. And my admin interface isn't even the interface being hit, it's the WAN interface! They don't even share the same physical interface!
Stop down playing this issue. It's as bad as Jeep's "any one can control your car" issue. Luckily not many people are using it.
-
Tell me how 30k pps of blocked traffic that was not being logged constitutes as a DDOS that will consume all resources of my entire box? I've done 70k pps ping floods against my firewall and it only consumes 5% cpu and nothing is affected. That ping flood is 0 packets dropped, max ping 10ms, avg ping 0.2ms.
But when he does a 30k pps of blocked TCP+UDP traffic, my box goes to crap and my admin interface goes offline to the point PFSense does not respond to ARP. And my admin interface isn't even the interface being hit, it's the WAN interface! They don't even share the same physical interface
Two things: increase your state table to 8M states. The UI and the rest of the box will be fine.
Second, the underlying issue is an IRQ interrupt flood. I'm not going to rehash it here, but it's the em driver flooding the CPU with interrupts. That's why only one core goes to 100%.
I've points this out several times on this thread, go back several pages to see my data an analysis. That's the root cause. Everything else on this thread is noise.
-
@cmb:
I thought DTrace was getting nowhere because it requires ESF to include it in the version of freebsd they use with pfsense?
You need more than just dtrace, various other debug options like PMC, and it needs to be replicated on stock FreeBSD with as basic of a test case as possible.
I'll check out PMC as this is something I'm not familiar with or may know it by another name.
We're not holding anything up there if someone wants to do it right.
Not suggesting you /ESF are holding things up, but I was a bit surprised to find out that something like dtrace wasnt shipped as I recognise some things stock in freebsd is not needed for a pfsense/fw type of role or application, which then makes sense to not include in pfsense image, but imo Dtrace is useful especially when considering things like this. http://www.cybergrandchallenge.com/
Doing it right doesn't involve "watch my Youtube videos of what happens when I have a criminal botnet hit me with traffic I won't describe, using an undocumented configuration that's full of sub-optimal settings for standing up to resource exhaustion attacks."
I dont have enough data to know if it was criminal or not, but one way of looking at the use of criminal botnets is theres nothing like a real world test in some respects.
So it's clear what's being done, the end result, and how to replicate. There's no big secret in how to run a large scale SYN flood where the world would end if it was put out there.
@cmb:
It's all doable with hping or other tools. Supermule uses shady illegal services you pay for in Bitcoin that use criminal-run botnets. The same circumstance can be lab replicated without paying criminals.
Investigating this further is still on my radar. There have just been real problems that affect many reasonable real world use cases that have taken precedence. Anyone trying to stop DDoS with a firewall of any type is doing it wrong.
I havent been able to replicate yet internally which is why I'm taking a different approach atm before I get SM to hit me up again.
Bitcoins can be traced http://www.theguardian.com/technology/2013/oct/07/fbi-bitcoin-pranked-silk-road fwiw.
-
Two things: increase your state table to 8M states. The UI and the rest of the box will be fine.
Doesn't that require about 8GB of RAM? Who has that in their firewall?
-
It actually takes 16GB to do that if all 8M is used.
-
Who has that in their firewall?
RAM is cheap at this times 4 x 8 GB of ECC RAM is really payable for the masses, and why not?
-
@KOM:
Two things: increase your state table to 8M states. The UI and the rest of the box will be fine.
Doesn't that require about 8GB of RAM? Who has that in their firewall?
I have 4GB of RAM and it worked without a hitch. Memory utilization was actually very low, <50% I believe. The raw data is buried somewhere in this thread.
I think, but cannot recall specifically, that it only hit about 4.7M states at the top end before the IRQ interrupt storm warning started. That's also why I think the state table never filled up.
-
So you are not sure??
Just because I pissed you off…
I thought you were older than the "name calling" age.
Tell me what I used... And since you have offered little to no help at all in configuring these "sub optimal" configurations, its very clear to everybody that nothing good comes from ESF other than bickering and "sub optimal" communication.
If I really DDoS'ed you then you wouldnt be online yet.
@cmb:
@KOM:
So we can't expect the pfSense team to fix a problem that's not in pfSense, and they are at the mercy of the FreeBSD code releases.
While we can't expect them to, they certainly have fixed some FreeBSD bugs and submitted the patches upstream, which were accepted for inclusion by the FreeBSD team.
Yup. And if there were truly a world-is-ending issue here, we'd already have done the same already.
All firewalls require some degree of tuning to stand up to resource exhaustion attacks. Settings appropriate for such circumstances aren't defaults because they would break many more circumstances than they would help, as they're too aggressive for many VoIP configurations, among other possible problems. Also general default behaviors that most people want, like logging all blocked traffic, are really terrible in that circumstance. Among a variety of other problems I've pointed out with the scenarios in these threads.
I've seen enough of Supermule's super-secret DDoS stuff from when he DDoSed our forum several times (not going to believe it wasn't him), and some things I've gathered from others, to be able to put together a proper analysis to get upstream at some point.
It's all doable with hping or other tools. Supermule uses shady illegal services you pay for in Bitcoin that use criminal-run botnets. The same circumstance can be lab replicated without paying criminals.
Investigating this further is still on my radar. There have just been real problems that affect many reasonable real world use cases that have taken precedence. Anyone trying to stop DDoS with a firewall of any type is doing it wrong.
Brian, this is unacceptable.
Final warning. Be nice, or you are banned from this forum.
