What is the biggest attack in GBPS you stopped
-
Not yet. They are digesting the attack that I did yesterday and curretnly looking at states not beeing freed as they should…. AFAIK.
-
Did this end up in nowhere with the issue still being there?
-
Still working on it.
-
https://lists.freebsd.org/pipermail/freebsd-announce/2015-July/001655.html
Latest update.
-
https://lists.freebsd.org/pipermail/freebsd-announce/2015-July/001655.html
Latest update.
Does this need to be included in 2.2.4 before it is released?
-
That would be a very good idea if possible!
Opnsense has this fix done allready and a full release on friday.
-
Do they have snapshot that you could test?
-
Waiting for the update to come. I will update and report back.
-
https://lists.freebsd.org/pipermail/freebsd-announce/2015-July/001655.html
Latest update.
Does this need to be included in 2.2.4 before it is released?
You beat me to it. This thread is the first thing I thought about when I saw this in G+
https://www.freebsd.org/security/advisories/FreeBSD-SA-15:13.tcp.asc
-
Supermule, is this directly related to what you've been digging into?
-
Could very well be.
-
So you haven't tested it? It's more of a definite maybe that this resolves the issue?
-
Not yet.
So you haven't tested it? It's more of a definite maybe that this resolves the issue?
-
https://lists.freebsd.org/pipermail/freebsd-announce/2015-July/001655.html
Latest update.
I suppose another question to ask, is how did we miss this on our own machines, and what can we do to avoid such problems from occurring again?
-
Supermule didn't miss it. Well, possibly. If it turns out to be the same issue.
-
Spotted the behavior but nothing outputted from pfsense to observe though.
-
Spotted the behavior but nothing outputted from pfsense to observe though.
Because it's not a pfSense issue. This is an FreeBSD network driver issue.
-
So there is nothing we can do then as this is just like a HW failure of sorts then?
-
So there is nothing we can do then as this is just like a HW failure of sorts then?
Yes and no.
If you can code and want to help recode the FreeBSD network drivers, they could use the help. They've acknowledged that there will be more improvements in the networking layer in v11.
Because pfSense is built on top of FreeBSD, it's only as good as the underlying operating system code. So bugs/deficiencies in the OS code affect the applications running on it. 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. I know they regularly collaborate with the FreeBSD team, but they don't run that project.
So it's not hardware per se, there are two layers of code that are maintained by two separate projects.
Here are the two threads Supoermule opened up on the FreeBSD forums before they started ignoring him:
https://forums.freebsd.org/threads/dos-and-ddos-attacks.51899/
https://forums.freebsd.org/threads/freebsd-pf-and-syn-ack-flooding.51921/
With any software project, you need to provide very detailed information to the developers so they can ascertain what the root cause may be as well as any code you're using to trigger the issue. While Supermule provides a lot of data, it's not data the developers or forum users found useful, similar to what's in this thread.
So it's possible the revised FreeBSD code resolves something, but until it's tested against this use case appropriately (on bare metal) it's only a guess as best that it resolves this use case.
-
https://lists.freebsd.org/pipermail/freebsd-announce/2015-July/001655.html
Latest update.
That has no relation to things people have been attempting here. It only applies to sessions the system itself answers (and gets all the way to LAST_ACK state, which never happens in any of these tests). No applicability with things it's routing, or NATing, or blocking, or passing but not able to complete a TCP handshake much less get to LAST_ACK.
2.2.4 snapshots have had the patch since the first build after its release, yesterday morning. Release is coming hopefully tomorrow, though not because of that specifically, as it's non-applicable for the vast majority of use cases.
Note the credit to Netflix? Probably something they ran into by coincidence on their FreeBSD CDN boxes (when you're pumping 20-40 Gbps out of a single server across a huge number of connections, you tend to run into any possible TCP bugs), then found the associated potential security impact.