Date: Sat, 22 Jan 2000 01:42:05 -0600 From: Jason Young <jyoung@accessus.net> To: 'Brett Glass' <brett@lariat.org>, 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: <ABD44D466F85D311A69900A0C900DB6BC5FE@staff.accessus.net>
next in thread | raw e-mail | index | archive | help
> You propose rate-limiting RSTs, and I agree that this could help > against an attack. But there are two problems. First, it allows > port probing; and second, it might actually be a problem if a system > crashes while a large number of connections are active and then > immediately reboots. The flurry of necessary RSTs sent at the outset > might exceed the limit and fail to clean up the mess. So, you'd > probably want to allow a fairly high rate of RSTs at boot time (not > enough to crash the machine) and then fewer later on. Things > WILL get > back to normal quicker if you can RST all of the sessions that were > active before the reboot. In this situation you are absolutely right: > RSTs can do something useful. 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. Freely available implementations are 'ipfw' and 'ipfilter'. Copious documentation is provided. It is the Right Tool for the job. Drop packets to the ports you're not using and don't want scanned. If the port needs to be open, then it can be "scanned" by simply connect()ing to it. IPFW's non-statefulness makes it harder to dodge some of the more odd portscans, if I recall correctly, but you can still do it. 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. 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), 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. 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. Jason Young accessUS Chief Network Engineer 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?ABD44D466F85D311A69900A0C900DB6BC5FE>