> Say we start PF at second 0. We will prune the state tree every ten > seconds (10s, 20s, 30s). > Say we get a packet at time 5s and want to time it out ten seconds later > at time 15s. But it doesn't. PF will finally prune the table at time > 20s, notice it has expired, and then delete the state. That state got > an extra five seconds of life.
Thanks, I was pretty unclear on that point. Hm, this could seriously complicate my attack scenario... I'm still not exactly sure how you manage adaptive timeout reduction, but I guess it's in the source somewhere. :-D > The use of TCP timestamps is how an attacker could remotely determine > when the firewall came up and thus when the 10s cycle pruning started. > But OpenBSD chooses a random initial timestamp so an attacker would > have to resort to constant probing to catch the time of a reboot. Constant probing? Well, I would figure that (assuming the 10s cycle does not reset itself during this time), after an intense information-gathering effort, the attacker could produce a profile that would slowly narrow down the time when that state prune happens within a finite and reasonable amount of time. A SYNburst right around this point in time would keep the firewall states full, but the inter-burst time would be necessary for the attacker to use his own ssh connection to his advantage. I don't really want to go into a detailed explanation of how the attacker would accumulate and analyze data to create this detailed firewall profile [I don't really know how], but suffice to say he'd need to know the code, which, at the moment, I don't. But since the attacker is analyzing real probing traffic, and not using timestamps at all, TCP timestamp modulation doesn't deter him on its own. >From what you just said, though, it sounds like instead of having to modulate every state timeout, we could make the firewall equally hardened by subtracting a random (and different) delay between each state prune cycle. This should involve a lot less code, while still eliminating the aforementioned [alleged] vulnerability. Of course, I'm talking about some very hypothetical, and rather sophisticated, attacks, and I'm sure you just don't get these every day. But it can't hurt to wonder about them. I don't expect anybody to waste their time implementing something I suggest that they don't think is worthwhile, but if there's anybody who *does* think it's worthwhile, and doesn't want to have to wait for me to learn pf's source....... On the point of typical vs. atypical security attacks: One rather odd scenario I concocted was the possibility of an attacker sniffing at a point VERY close (i.e. same LAN switch) as somebody using an SSH client. Since it's SSH, he can't listen in verbatim, but many SSH clients disable Nagle, and, combined with the listener's proximity on the network, the listener can time the delay between keystrokes to within 1ms or less. Now, even if the victim is smart enough not to type his password into a computer he doesn't trust, the attacker could probably still use some social engineering to get him to type up an otherwise innocent-looking document, thereby collecting statistical data on the user's inter-keystroke latency patterns (i.e. after typing "th" how many milliseconds until he types an "e"?) Using this data, the attacker can now make certain guesses using statistical correlation (or maybe sum-of-errors-squared) as to what the user is most likely typing into the SSH terminal. Based on this, the attacker can filter out segments that look like private data (passwords) and then, using the keystroke data, in order of correlation coefficient, more [much more] optimially re-ordering a brute-force attack. After all, ANY information an attacker can gather can be used to reduce attack time. I haven't really tested this idea yet (since I haven't worked out all the math yet) but I'm sure it's a real good discussion for a different message board. The whole point, of course, is that it's not the typical attacker we really have to worry about! Sorry about all the thread bloat. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
