On Tue, Jun 7, 2016 at 3:35 AM, Peter J. Philipp <p...@centroid.eu> wrote: > Thanks for the history of this Claudio. I am not really asking for them > I just wanted to know where they went. It's good to know that a > LISTENING tcp socket goes directly to ESTABLISHED in OpenBSD. I would > have another question though. How would an administrator tell I'm > getting SYN flooded without the hunch that something is going on and > jumping on tcpdump and doing packet accounting? How would you determine > a syn flood?
That is a very good question. Received wisdom, that I have been taught, is that no one cares, or that qualified administrators know already. My guess is that, instead, people should care and that there should be alarms (warnings, not errors / hard stops) that indicate common attack modes are in play and yet more documentation needed to describe them. This is somewhat in the same economic niche as virus checkers, and eventually should probably be moved to hardware. But I do not expect quick progress here. There's a lot of pushback, for a lot of reasons, some good, many not so good. Or, as Theo might or might not say: "show me the implementation", likely followed by heavy criticism of the flaws of the implementation. And the easy response there is to do nothing and say nothing. Another easy response is to over build. That said, as best I can determine from web searching, the current "state of the art" is to turn on pf logging (a bunch of rules to get right here which depend on the scale and focus of what you want to happen) and then focus a log analyzer on the results. Or, if you are in a large company, the current "state of the art" is to wait for someone else to tell you, or better yet to wait until something breaks. (Your manager will tell you to instead focus on "X" where "X" is the current business priority.) A fundamental underlying problem is that while "syn flood" is a real thing, it's also something of a sliding scale thing - in practice, it's just one of many denial of service attacks, which basically are "the machine is getting more traffic than it can handle". And the general solution to that problem is to have someone who cares how much traffic is being handled look for spikes and dips. And that winds up needing to be measured in several ways (so that inconsistencies can be detected), and then ride things out. -- Raul
