Re: Fragment Reassembly and "Wormhole Routing" for pf
On Tue, 15 Jul 2003 14:52:45 -0700, Aaron Suen wrote: > 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. This has already been done, and works extremely well. See: http://www.kb.cert.org/vuls/id/596827 I'm not aware of a current ssh implementation which does not have a fix for this; it should no longer be possible to tell what's a password and what isn't. See the references. -- Kyle R. Hofmann <[EMAIL PROTECTED]>
Re: Fragment Reassembly and "Wormhole Routing" for pf
On Mon, 14 Jul 2003 12:37:26 -0700, Aaron Suen wrote: > Well, my theory is that we adapt the concept of "wormhole routing" as "wormhole > defragmentation and filtration" for pf. Basically, wormhole routing means that > information is stored in a routing device only until sufficient data has > arrived to make a routing decision, then all remaining data is forwarded > immediately as it arrives. This works because all of the information needed to > route a packet [almost always] arrives first. This is a novel idea, but it leads to attacks against systems behind a firewall. Consider the situation: attacker -> pf firewall -> server Attacker sends the first fragment of a huge TCP segment, say 64k. It has enough information to be routed properly. Stock pf using "fragment reassemble" would wait until the rest of the TCP segment arrived and not forward the TCP segment until then. Your proposed modification would forward the fragment, causing the server to cache the fragment until it expired or until the rest of the segment arrived. Suppose now that the rest of the fragment never does arrive; instead the first fragment of another huge TCP segment is sent. Again, both the firewall and the server must cache the fragment. And so on; by this technique an attacker can exhaust resources not only on the firewall, which is expected to be hardened against such things, but also on any machine behind it, even though those machines are supposed to be protected. While the prospect of reducing latency is nice, I don't think the potential vulnerabilities make this a good idea. -- Kyle R. Hofmann <[EMAIL PROTECTED]>
Re: pf/altq on a fast link
On 05 Jun 2003 09:25:20 -0700, Dennis wrote: > openbsd-pf is a good firewall. But as a bandwidth management tool it's > quite inferior. Priority queuing is an archaic, inferior technology, > if you can call it a technology. > > The subject here is "pf/altq" on a fast link. How does it perform on a > gigabit wire with stats gathering and limits configured for 5000 > hosts? How does granular, duration controlled bursting work? does it > automatically pace traffic to reduce queue depths when a point of > congestion is reached? > > There's nothing wrong with an open-source firewall. But an ISP need a > separate bandwidth management box. Anyone that thinks they can do it > with the free stuff is settling for a trivial solution that will cost > them in the long run. The ethical thing to do, when someone asks about > using pf/altq for a high-volume business, is to tell them the truth. > They need something a bit better. Dear Mr. Baasch, Your emails to the pf mailing list have been very unbecoming. As president and CEO of a company that competes with pf and altq, I would expect you to be gracious and polite when comparing your product to pf; your behavior here reflects how you will treat your customers, and if you are trying to win converts it is easier to change moods than minds. Instead you have been hostile and insulting, so I can only assume that you are hostile and insulting to your customers as well. As a result I not only plan to continue using pf and altq, but to warn my friends and acquaintances that not only is Emerging Technologies, Inc. afraid of pf, but that Emerging Technologies, Inc. treats its potential customers poorly. If they ask I will explain to them what you have said on this list. I will also direct them to the pf archives, so they can read your words for themselves. I would like to say I am sorry that my only contact with Emerging Technologies, Inc. has been so disappointing. Yours Sincerely, Kyle R. Hofmann
Re: matching
On Sat, 12 Apr 2003 14:31:52 +0300, "Berk D. Demir" wrote: > > >from previous discussion I recall it was O(1) ie. constant time for each > > >address family. Which is _much_ better than O(log n). > > > > > Well, I don't know exactly, but it's certainly *not* O(1), that I'm sure. > > If its O(log n) or O(log log n) or whatever in between, I'm don't know. > > > As far as I know, Patricia Trees work by inserting bits into nodes by > level. > > For example: >. > / \ > 0 . > \ \ >. 11 > / \ > 010 011 > > As seen in the figure, some nodes maybe empty depending on your set. > > The tree height for IPv4 addresses will be 32 and 128 for IPv6. > By making at most 32 or 128 comparisons you'll locate your address. > This seems to me a O(1) situation. Yes, but we can get a better bound than that. Remember that being O(f(n)) means that the quantity we're measuring (in this case time of lookups) is bounded by some constant factor times f(n), where n is some variable quantity (in this case, addresses). Since there's a fixed maximum number of nodes (because there's a fixed maximum number of IPv4 or IPv6 addresses), any correct algorithm is O(1), but it may have a really big constant in front of it. A better bound is O(log(n)) (I think--I've never quite understood Patricia trees), because the constant factor that O ignores is much smaller. This is really a shortcoming of O notation; it's easier to understand a comparison like this when you try to work out rough running times using each bound. -- Kyle R. Hofmann <[EMAIL PROTECTED]>
Re: pf(4) schemantics
On Thu, 20 Mar 2003 23:16:10 +0100, Srebrenko Sehic wrote:
> On Thu, Mar 20, 2003 at 02:49:37PM -0700, [EMAIL PROTECTED] wrote:
> > > Yes, but it could be nice if one could choose, eg.
> > > set filter-policy {in, out, both} or something.
> >
> > You can choose. Either type:
> >
> > block out all
> > or
> > pass out all keep state
>
> This is cosmetics. However, whouldn't we get some performance increase
> if pf(4) didn't bother looking at packets (in certain situations) going
> 'out' at all?
>
> I assume that 'pass out all keep state' makes pf(4), at least, do a
> state lookup in the table? AFAIK, that's, in worst case scenario, 16
> searches down the binary tree? That ought to eat a few cycles.
So far everyone who has responded to you has been polite, despite your
inability to comprehend what they're telling you. Now, in the proud
tradition of OpenBSD lusers everywhere, I will flame you:
RTFM.
RTFFAQ.
RTFRFC.
RTFS.
) ( ((
( ) () @@ ) (( (
( ( )( @@ ( )) ) (
(( ( ()( /---\ (()( (
___) ) )(@ !O O! )@@ ( ) ) )
< ) ) ( ( )( ()@ \ o / (@ ( ()( )
/--| |( o| ( ) ) ((@@(@@ !o! (@)() (
| > \___| ) ( @)@@)@ /---\-/---\ )@()( )
| /-+()@@@( // /-\ \\ @@@)@( .
| |\ =__/|@(@@@ // @ /---\ @ \\ @(@@@(@@@ . .
| \ \\=--\|@ O @@@ /-\ @@@ O @@(@@)@@ @ .
| \ \+--\-))) @@ !! % !! @@)@@@ .. .
| |\__|_)))/ .@@ !! @@ /---\ @@ !! @@(@@@ @ . .
\__== *.@@ /MM /\O O/\ MM\ @@@. .
| |-\ \ ( . @ !!! !! \-/ !! !!! @ .
| | \ \ ) . . !! !! .(. @. .. .
| | \ \(/ .( . \)). ( |O )( O! . ) .
| | / / ) ( )). (( .) !! ((( !! @@ (. ((. . .
| | / / () )) )) .( ( ( ) ). ( !! )( !! ) (( )) ..
| |_< / ( ) ( ( ) ) (( ) )).) ((/ | ( | \( )) ((. ).
<_\\__\__(___)_))_((_())__(_(___.oooO_Oooo.(_(_)_)((_
HAND, HTH.
(ASCII art courtesy of someone else)
(And, more seriously, I suggest that you read the source. Then it should be
clear why pf works as it does.)
--
Kyle R. Hofmann <[EMAIL PROTECTED]>
Re: altq, ssh, and tos
On Sun, 22 Dec 2002 23:24:57 -0500, Michael Lucas wrote: > So, above, the SSH rule is hit and is used. > > Now I go to the SSH rule, and I add the ToS field like so: > > pass out inet proto tcp from ($ExtIf) to any port 22 keep state tos 0x10 queue ssh > > Per various documentation I've read, this is the ToS for an > interactive SSH session. The rest of the rules remain unchanged. Well, very limited testing indicates that ssh sets the type of service after the connection is made. In particular, tos is *not* set in the initial SYN packet, thus your rule is not matched. scp and sftp don't set tos early, either. It seems to me that ssh is not doing the right thing here; it should determine the type of service that it will use and set it before it sends the first SYN. -- Kyle R. Hofmann <[EMAIL PROTECTED]>
Re: Scrub and fragments
On Tue, 19 Nov 2002 12:38:15 +0100, Daniel Hartmeier wrote: > On Tue, Nov 19, 2002 at 12:27:41PM +0100, [EMAIL PROTECTED] wrote: > > > come one, spend a second on it. fragmented packets with the don't fragment > > bit set are invalid. that's so obvious. > > Well, there's the case where fragments can be fragmented further, the > RFCs support that. The question is whether anyone would sanely set the > DF bit on a fragment to prevent _further_ fragmentation. Well, they can, but then they'd be stupid: An internet datagram can be marked "don't fragment." Any internet datagram so marked is not to be internet fragmented under any circumstances. (RFC 791) A fragment is fragmented; ergo, it cannot be marked don't fragment. One could argue that the "be liberal in what you accept and conservative in what you send" rule implies that you should accept fragments with DF set, but the potential for a host system to misinterpret such datagrams makes me unwilling to agree. -- Kyle R. Hofmann <[EMAIL PROTECTED]>
Re: fully transparent ftp-proxy?
On Thu, 31 Oct 2002 17:59:31 +0100, Daniel Hartmeier wrote: > On Fri, Nov 01, 2002 at 02:14:58AM +1000, loki wrote: > > having such a rule (or rules) has several other advantages, you could > > create several trees, one for each proxy that requires it (include a > > mechanism for the proxy to talk to its own tree). you could specify which > > field of the state entry is variable (id still say that remote src port > > would be th only one, but its nice to be flexible). you could specify tcp > > flags and state modulation. whatever is needed for connections created by > > the proxy. > > I can't think of a case where anything but the source port is missing, > actually. I just did, but in a way this is entirely unrelated to the proposed idea. Filter rules are, in their own way, a lot like embryonic states. They contain some information that a state does, but not all. Their other significant difference is that matching a non-quick rule does not determine whether the packet matches. To me this suggests creating embryonic states corresponding to filter rules and arranging them in trees; it feels like it would simplest to have the trees rooted by interface, but that may not be true in practice. At each node of the tree would be an embryonic state. For a packet to progress through the tree, it must be compared to the embryonic states of the children of the node it is currently in. If it matches none of them, the block/pass rule of its current node applies. If it matches one of them, that node becomes the packet's current node. Processing ends when the packet reaches a terminal node or no child of the current node matches the packet. Quick rules would always be terminal nodes. The major difficulty, as far as I can tell, is in creating the tree. No two children of the same node could ever match the same packet or else the ruleset becomes ambiguous. Furthermore, the "most efficient" tree is probably difficult to determine. Even an inefficient tree would likely take a while to create with a large ruleset, and I don't have any idea how one would insert or delete rules into an existing tree. The advantage, however, is that ruleset evaluation becomes very fast. If the tree is balanced, evaluation should be O(log n). The worst case should be a tree with a root and only terminal children, but that should still be O(n). You lose skip steps with such a case, though, so performance would be worse than it is now. But it feels to me like it should be possible to avoid such a pathological case with good tree construction. -- Kyle R. Hofmann <[EMAIL PROTECTED]>
