Date: Sat, 22 Jan 2000 07:50:35 -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.20000122071745.019bc4d0@localhost> In-Reply-To: <ABD44D466F85D311A69900A0C900DB6BC5FE@staff.accessus.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:42 AM 1/22/2000 , Jason Young wrote: >The job of the FreeBSD TCP/IP stack is to implement the TCP/IP standards in >a correct and reasonable manner for all users. Stopping of probes and other >purposes for which you need to selectively drop certain packets to your >system is an expression of your local policy. The tool used to impose your >local IP packet handling policy is a firewall. The OS is a perfectly good tool for imposing policy as well. 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. >Drop packets to the ports you're not using and don't want scanned. That's fine, and for that reason there should be an option that doesn't clobber all RSTs. But if you want to hinder scans, you should also drop some packets going to ports you ARE using. The overhead to do this in the stack is small. Let the admin have his choice of policies. I don't think we should penalize him or her for disagreeing with someone else. >If the >port needs to be open, then it can be "scanned" by simply connect()ing to >it. True. However, the idea is to make things more expensive for the cracker, and also to make surreptitious scans more difficult. Forcing him or her to attempt a connection makes mass probes more difficult. >As for bursts of RSTs overloading a server on bootup: If a client sends a >packet to a server, and the server fails to send a RST for whatever reason, >that client will continue retrying for an interval, giving the server >additional chances to reset the connection. Maybe. If many clients are retrying, the server could still see quite a swarm. >Envision a situation where somebody accidentally bumps the Big Red Button on >ftp.cdrom.com, and immediately brings it back up. If it rate-limited its >outgoing RSTs and hit this limit momentarily (and I really think this would >be unlikely in the extreme if the RST rate-limiting threshold is >reasonable), Would it be? Let's suppose that ftp.cdrom.com was handling 5000 connections when you hit the switch. Within a second, you'd get AT LEAST 5000 packets to which you'd need to respond with RSTs. Almost certainly more, due to windowing. The DoS we're talking about here actually sends a volume of packets of the same order of magnitude. So, ftp.cdrom.com, having developed amnesia as a result of the reboot, doesn't have the information to distinguish this flood from the DoS. And before it gets even partway down the list, it'll be getting more -- PLUS new connection attempts. (ftp.cdrom.com is a busy guy -- or is it gal.) >some of its clients will get their session cleared immediately >by an RST, and some of the clients would get no response. The clients' TCP >stack would then retry, and probably get the RST this time around since the >machine is working off its RST workload. Hopefully. >There would have to be some terribly pathological number of connections to >the machine for it not to be able to RST all (active) open TCP sessions >within 2 or 3 client retry cycles. In this case the clients will still >eventually gracefully fail by timeout as if the server had never come back >up. True. But in the meantime, here's this poor server -- struggling to boot -- that's not only being bombarded with packets but trying to respond to them all. If the boot is slowed sufficiently, you could have more downtime than you wanted. I'm sure you've seen how long it takes a FreeBSD server to boot if you pull the network plug at boot time... the boot time under this load could be even longer. So, there are some real tradeoffs to be made here. We shouldn't expect that all system administrators will make the same ones. What we SHOULD do is give them a choice. --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.20000122071745.019bc4d0>