What is the biggest attack in GBPS you stopped
-
I thought DTrace was getting nowhere because it requires ESF to include it in the version of freebsd they use with pfsense?
Let me back up a bit and summarize some of the results I got while testing. Initially the box and web UI slowed to a crawl while the attack was going on. When I increased my state table to 8M states, the box responded well, but I started getting an IRQ storm alert. That led me to believe that there was an issue in the em network driver in FreeBSD. In order to validate this assumption, I would need to install FreeBSD on bare metal and re-run the tests. Troubleshooting 101, remove stuff, check for error, profit. If it can be recreated in FreeBSD 10.x, then we can install dtrace there and go forward. No use trying to troubleshoot a potential FreeBSD issue on a pfSense box. Even the folks on the FreeBSD forums will tell you to do a vanilla install on bare metal and then post the results. I believe that it's possible that someone did run a test with FreeBSD and reported the same behavior on this thread. I'm not entirely sure. But that's essentially where the troubleshooting left off.
I think he provided a DDOS script which was supposed to cause the problems although I havent seen it myself as my bandwidth is not enough unless GCHQ/isp have some speed restriction in place, but I cant comment on the DDOS script other than its not unlike many which can be downloaded from the web.
Just to be clear, the attack was a DOS, not a DDOS. There was nothing distributed about it unless Supermule has a botnet at his disposal and that's why he's not releasing any code (I doubt it), but I think it's a single script randomizing source IP addresses. It could be that he's downloaded someone else's compiled code and is just using it like a script kiddie, and therefore he doesn't have any source code to release. That might be more probable, but we'll never really know until he provides some transparency.
I stopped working on the issue because I don't have the source to recreate the issue, and therefore I cannot test it in a lab. I provided my external IPs to Supermule, but I never got the same transparency in return. So I walked away.
-
At first I really don´t think thats a easy going job, only coding something new, insert it in the
next FreeBSD version and then pfSense will be the profiteer also in the next version, because
pfSense is not swapping over the code 1:1 without doing many adaptations and changes as
well.And what would be the benefit from this all, if some dozen peoples like anonymous, were
shooting with their "super canon"? Would this also secure our pfSense firewalls? Either
on bare metal or in a VM this would be the end of any firewall that is trying to proper
handle a load like this then.Would it perhaps be better to own something like a so called "hedgehog mode"
like the bigger vendors are doing on greater devices?For sure the attack driven by @supermule was a mixed one, a script combined with
a special syn flood attack. (XSYN script and OVH )I think he provided a DDOS script which was supposed to cause the problems although I havent seen it myself as my bandwidth is not enough unless GCHQ/isp have some speed restriction in place, but I cant comment on the DDOS script other than its not unlike many which can be downloaded from the web.
You can easily watch it here: This is the XSYN script
-
I think theres too much focus on the (d)dos and not enough on the fact, that, observing a system in general at a greater level of detail can show up new anomalies.
Put another way, until we log at greater detail how will we spot problems?
Dtrace wouldnt exist if there wasnt a need for it, would it?
I know OS Debugging can add an overhead, but having used tools like this one http://www.rohitab.com/apimonitor on the Windows platform has enabled me to spot things which otherwise would have gone unnoticed by using the programming languages own debugger because I could see which API's get repeatedly and unnecessarily called in OOP code for example.
That api monitor hooks into all the api's I choose and from that I can get metrics which show me things like where my code is slow, and where there might be potential problems which can be exploited at the OS level. I've found bugs in programming languages which are over 15years old possibly 20yrs and could cause any system written in the language to crash.
The thing to bear in mind with all good systems is they tend to have the original programmer(s) still in place, unlike many of the OS's today which have been taken over by younger folk as others climb the management ladder or go off elsewhere.
Those newer folk dont have the hidden knowledge thats in the heads of the original programmers. So if you dont have greater levels of logging and detail, would we spot what we maybe currently missing?
Syslog is a good, but like money you can never have enough.
-
would we spot what we maybe currently missing?
Hmmm, I will try it to explain it could be a very simple thing!
As I was digging out from some forum threads here and there it
would be not affecting lazy consumer routers, the combined attack
I mean and there for I think there must be an elemental difference
between the NAT from FreeBSD and the NAT in consumer routers.The NAT at consumer routers do the following think;
They will not pass anything in from outside that was not called
by somebody or a device from the LAN side! Is this right so? ;)The NAT at FreeBSD or pfSense based devices do also the following
likes above but on another way! And I mean really this is the small
piece that makes it really difficult to fix the entire problem. :-
FreeBSD & pfSense lets the packets in or pass to inspect
them that the rules can matching them for deny or allow or perhaps
pass through.That means that at the lazy consumer routers the packets don´t comes
in but at the pfSense side they must be coming in at first to match
the rules. Can this be the small piece of difference here in the game?Asch Conformity, mainly the blind leading the blind.
But the one-eyed man is the king of the blinds
-
Its not like that.
-
@BlueKobold:
The NAT at consumer routers do the following think;
They will not pass anything in from outside that was not called
by somebody or a device from the LAN side! Is this right so? ;)The NAT at FreeBSD or pfSense based devices do also the following
likes above but on another way! And I mean really this is the small
piece that makes it really difficult to fix the entire problem.Good thinking, could not say if its correct or not as I have no knowledge of how the different consumer routers work, they might for example have different levels of isolation or sandboxing in place. However from the freebsd thread SYN ACK seems to be an issue.
I dont know if this would work, by altering the number of retries?
https://forum.ivorde.com/quick-temporary-tuning-of-freebsd-under-spoofed-syn-flood-attack-t13632.htmlAs I cant replicate this at my end I am unable to reproduce which is half the problem but not impossible when trying to fix bugs of sorts, hence the suggestion to increase the logging at the system level. Maybe something would show up?
-
Good thinking, could not say if its correct or not as I have no knowledge of how the different consumer
routers work, they might for example have different levels of isolation or sandboxing in place.In normal as I am informed, correct me please if I am wrong with this, the NAT mechanism is working
like this (related to the consumer grade NAT routers), the way ste-by-step I mean;- rule number one is often using netfilter (SPI) in that game to prevent from IP packet fragmentations
- the second rule is something like "use rule number one on top of all other rules then followed by NAT
- from the LAN side someone or a device is calling an information such like a website to open and display
- the informations are send to the Internet by opening a session for this related to an internal IP address
- if data now from the outside (Internet) are reaching the WAN interface of the home router, the NAT
mechanism is purely and only checking if there is an open session that is matching this data and let
them pass or deny them.
And for sure on top of this, perhaps also a smaller soldered on board ASIC/FPGA that brings them
up to handle those rules and actions more liquid I am really pretty sure they own all something like this.I now I am walking now on so called thin ice
For sure from vendor to vendor this might be used in different ways, but it is really affective
working for them, so could pfSense or FreeBSD also going to solve this out like this is done?And if the most peoples want to go more likes the style is now, no problem at all I thing, it might
be not working only as a replacement, an extension or only as another option for the state of
art, the pfSense is acting and handling this point now at the time, but perhaps something like
a second option where each user will be able to set it up or activate it or may not perhaps.However from the freebsd thread SYN ACK seems to be an issue.
But you are perhaps a programmer or code writer that is able to determinate now
where are the exactly differences between this both SPI/NAT versions?Put another way, until we log at greater detail how will we spot problems?
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 closerI dont know if this would work, by altering the number of retries?
Hey, can this combined together by using syncookies against syn flood attacks?
I am not a code writer or FreeBSD and pfSense professional and also not a security
expert likes many users are here in this forum are, and this may be bringing me up
to ask some poor questions that makes more or long time experienced users and the
pros up to be running wild, but if there is out something else "they" have and not "we"
and it is still working likes a charm you will perhaps excuse the jumping in to this discussion. -
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 dont have any waiting hardware wise and its internal to FreeBSD/pfSense.
It could be the backlog and the way its handled when SYN flooded and also the fact that all traffic is copied to pf filter and inspected and then its forwarded/rejected or whatever its supposed to do…
That we have a bottleneck in that way the packets are handled using NAT. The script used spoofed IP's and is a DDoS. The traffic will at a point be flushed and then the firewall begins to route traffic again until we hit the bottlenneck again and everything halts and become unresponsive.
1 core suddenly uses 100% of the CPU and it stalls depite having enough ressources available.
So its tied to PPS and how they are composed and what the traffic wants in regards to reply from the FW. And not the overall bandwith usage.
One can monitor the usage of CPU in VmWare and see what happens hardware wise when the traffic drops on the traffic graphs. It follow suit in VmWare and everything is reachable from WAN again.
-
@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.
-
I am nice.
But you would be pissed as well if you were accused of things you didnt do.
It goes both ways.
-
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?I'll admit my shell scripts can't (yet?) pedal a bike. :)
You hired a power-cycling monkey?
No, I wrote one. :D
Borrowing the chaos monkey name.
Just scripting SNMP sets against an IP PDU to effectively yank the power plug, power it back up, wait for it to reply to pings, rinse and repeat. Many thousands of times. One box close to 20,000 times now, one over 10,000 times, others well into the thousands.
-
Come on guys…
Clearly there is an issue and it
s not only caused by resource exaustion as cmb says. Mine went down with 3Mbps of traffic and I have 40/100 and 20/20 pipes. Everything went down and he didn
t even touch my internal webserver but firewall itself.Why can
t you work together, I
m really dissapointed in the way things went on this issue.pfSense is really cool and serious project and forums didn`t let me down since I first posted here (ok besides dok and his sarcasm which I got used to and it amuses me every time hehe ;) ) but I always got help or at least hint where to start.
Open source guys…
My 2c...
-
I am nice.
But you would be pissed as well if you were accused of things you didnt do.
It goes both ways.
You may have been falsely accused. How you react to this is your choice.
There is a difference that seems to need need stating:
Chris is a co-owner, as am I. You are a guest.
While you are helpful, and respectful, you are welcome here. When that is no longer true, I will (and take this with all the requisite gravitas), remove you from this community. You will not return. I removed my former persona ("gonzopancho") in a way that I could not ever recover, because I found that I could no longer respond in a reasonable manner.
You have been far over "the line" of reasonable response on many occasions. This is your final warning. How you react is your choice.
I think you have value that you can bring, but your behavior in this and other things is, in the balance, largely negative toward the project and its owners.
-
Come on guys…
Clearly there is an issue and it
s not only caused by resource exaustion as cmb says. Mine went down with 3Mbps of traffic and I have 40/100 and 20/20 pipes. Everything went down and he didn
t even touch my internal webserver but firewall itself.Why can
t you work together, I
m really dissapointed in the way things went on this issue.pfSense is really cool and serious project and forums didn`t let me down since I first posted here (ok besides dok and his sarcasm which I got used to and it amuses me every time hehe ;) ) but I always got help or at least hint where to start.
Open source guys…
My 2c...
The issue is resource exhaustion. The 'attack' (as it were) runs pf out of states. It is not (as some seem to want to state) related to virtualization or (as others seem to want to state) interrupt load on a single CPU.
To my knowledge, Brian has never shared his scripts/code, but we do have what I believe to be similar internally. We have shown (internally)
that the problem is endemic to the pf in FreeBSD. It is not specific to pfSense, or any 'forks' of same. I have not verified that the problem occurs on OpenBSD, or another 'stateful' firewall.The problem is not made worse by the lack of dtrace on the image.
Your disappointment is not inducement to work on the problem, nor am I aware of what you mean by "Open source guys…"
We, or someone else, will eventually fix the issue. It may be quite difficult. The pf codebase is not well-structured.
-
Thing is Chris… Franco is very kind to people.
I dont really dig into the opnsense/pfsense feud since its meaningless.
I see. So is your assertion is that Brian/Supermule on forum.opnsense.org is not the same as Brian/Supermule on forum.pfsense.org?
Because if these are the same, then you said something quite different only two weeks ago:
https://forum.opnsense.org/index.php?topic=581.msg2799#msg2799
I take several issues with what you said:
Issue IMHO is that pfSense is nothing more than a name and logo.
I assert that this is false.
All the code and contributions are open source
This is true, and always has been.
and they want to change that so they can make money of other peoples work and contributions.
We have not changed that pfSense is open source, nor do we "want to change that". Your ugly accusation is false, Brian.
I dont like it and thats why I am here.
This is, of course, your choice, but I don't see why you feel allowed to be two-faced about it without challenge.
-
Its not. Plenty of ressources left as you can see. Its routing and the way pf handles it.
The issue is different.
-
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?
-
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?
-
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.
-
@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?