Date: Sun, 23 Jan 2000 12:39:46 -0700 From: Brett Glass <brett@lariat.org> To: Jason Young <jyoung@accessus.net>, Matthew Dillon <dillon@apollo.backplane.com>, Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Keith Stevenson <k.stevenson@louisville.edu>, freebsd-security@FreeBSD.ORG Subject: RE: Some observations on stream.c and streamnt.c Message-ID: <4.2.2.20000123122732.01ace310@localhost> In-Reply-To: <ABD44D466F85D311A69900A0C900DB6BC601@staff.accessus.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:33 PM 1/22/2000 , Jason Young wrote:
> > In fact,
> > using ipfw or ipfilter to impose policy (only the latter can be used
> > in case of the stream.c exploit) is redundant, since ipfilter must
> > retain tables of connections which duplicate information stored by
> > the protocol stack already.
>
>Both ipfilter and the kernel correctly drop the packet.
There's a difference, though. ipfilter doesn't send RSTs, which in
turn cause congestion and additional system loading due to ICMP
messages. The kernel normally does send RSTs. That's what this discussion is
about: how to make the kernel enforce the policy rather than ipfilter,
which eats memory and CPU because it maintains redundant tables.
>The fact that
>ipfilter is being successfully used to defend against it simply means that
>it's more efficient at dropping these particular rogue packets.
IPFilter seems like a nice piece of work, but it's still not efficient to
use if if the kernel can do the right thing.
>It's my
>understanding from the list that the main reason the kernel is bogged down
>by this attack is that it is computationally expensive to generate all the
>return RSTs required by protocol.
Partially, but not entirely true. ICMP imposes an additional burden.
>Matt Dillon's rate-limiting patch is a form of hardening the TCP/IP stack
>while maintaining all possible protocol compliance. I agree with this. In
>the usual case you should stick to protocol, and in a failure or overload or
>attack situation you should do your best.
Unless you're concerned about scans. Which can be done as a very, very slow
attack if you are scanning a wide range of addresses ("slow scanning").
>Personally, I don't understand why people are so antsy about being
>portscanned or having their OS identified. Yes, it's more information for an
>attacker. But if you have a security hole, you have a security hole. This is
>exploitable if the intruder knows you're running XYZ unrelated service or
>no.
This argument is akin to the one which says, "Why are you concerned about
privacy? If you have nothing to hide, you have nothing to worry about."
>People seem to be regarding the fact that you can scan a machine for its
>open ports to be a fault in its TCP/IP stack. In fact, it is doing what it's
>supposed to do. If you don't like what it's doing, then that comes back to
>imposing local policy.
Exactly. And the kernel has always has options that let the administrator
impose local policies, such as quotas, etc. This is another one. Let's
give him an efficient choice.
>Any client/server interaction that has pending activity after the reboot
>will be in some varying stage of exponential backoff or have timed out
>depending on when the activity took place and how long the server took to
>"come back". 5000 connections will certainly not result in 5000 packets in
>one second worth of RST-able client traffic. Many of the clients will not
>have pending activity.
Actually, I already stand corrected on this. It's not as devastating as I
first painted it in the case of an FTP server. But a server that's streaming
RealAudio, for example, is likely to take a much bigger hit. I maintain one
for a radio station, and a packet monitor shows a whole lot of wild stuff
going on. RealAudio and RealVideo even encapsulate themselves in HTTP to
get through firewalls! It's ugly.
--Brett
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20000123122732.01ace310>