From owner-freebsd-security Mon Sep 16 10:16:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA18508 for security-outgoing; Mon, 16 Sep 1996 10:16:56 -0700 (PDT) Received: from beeblebrox.cc.jyu.fi (beeblebrox.cc.jyu.fi [130.234.41.34]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA18499 for ; Mon, 16 Sep 1996 10:16:52 -0700 (PDT) Received: (from kallio@localhost) by beeblebrox.cc.jyu.fi (8.7.5/8.7.3) id UAA22628; Mon, 16 Sep 1996 20:16:35 +0300 (EET DST) Date: Mon, 16 Sep 1996 20:16:34 +0300 (EET DST) From: Seppo Kallio To: freebsd-security@freebsd.org Subject: Is Linux RootKit a know packet ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We had some cracker using Linux RootKit I hope the security people working with NetBSD/OpenBSD and FreeBSD know=20 this. And this time, I hope nobody will ever port it to BSD ;-) Seppo kallio@jyu.fi --- Cybernetik proudly presents... _ _ ____ _ _ _ _ ___ ___ | | (_)_ __ _ ___ __ | _ \ ___ ___ | |_| | _(_) |_ |_ _|_ _| | | | | '_ \| | | \ \/ / | |_) / _ \ / _ \| __| |/ / | __| | | | | | |___| | | | | |_| |> < | _ < (_) | (_) | |_| <| | |_ | | | | |_____|_|_| |_|\__,_/_/\_\ |_| \_\___/ \___/ \__|_|\_\_|\__| |___|___| V1.1 =09=09 Released 20/04/96 "It worked perfectly on *MY* system ;)" UPDATES 1.1=09Fixed login bug (didn't set HISTFILE properly. duh!) =09Fixed BIG inetd bug. Alright so I forgot to try it with the service=20 =09enabled. Sorry, I found this out the hard way too. (Not that anybody =09has complained yet :) =09Included linsniffer, a more practical sniffer. =20 =09Included wted and lled, two programs I wrote a while ago... the =09main difference between these and zap is that these actually REMOVE =09entries leaving no traces. =09Included bindshell.c coded by Pluvius. =09Added SHOWFLAG to netstat. This packages includes the following: chfn=09=09Trojaned! User->r00t chsh=09=09Trojaned! User->r00t inetd=09=09Trojaned! Remote access login=09=09Trojaned! Remote access ls=09=09Trojaned! Hide files du=09=09Trojaned! Hide files ifconfig=09Trojaned! Hide sniffing netstat=09=09Trojaned! Hide connections passwd=09=09Trojaned! User->r00t ps=09=09Trojaned! Hide processes top=09=09Trojaned! Hide processes rshd=09=09Trojaned! Remote access syslogd=09=09Trojaned! Hide logs linsniffer=09A kewl sniffz0r! sniffit=09=09Another kewl sniffer! fix=09=09File fixer! z2=09=09Zap2 utmp/wtmp/lastlog eraser! wted=09=09wtmp/utmp editor! lled=09=09lastlog editor! bindshell=09port/shell type daemon! =09=09 INSTALLATION To install this kit execute the command 'make all install' from ya # prompt= . All of the files/password configuration is in rootkit.h so feel free to personalise your own version of lrk2 :-) It probably won't compile everythi= ng on older systems but thats life. Everything here has been tested on a slack= ware 3.0 distribution, on other systems there were minor errors but these could = be fixed by adding the odd #include or removing the offending code. =20 USAGE OK I will go thru how to use each program one by one. NOTE when I say passw= ord I mean the rootkit password not your users password (doh!). By default the rootkit password is lrkr0x. chfn -=09=09Local user->root. Run chfn then when it asks you for a new name =09=09enter your password. chsh -=09=09Local user->root. Run chsh when it asks you for a new shell =09=09enter your password. inetd -=09 =09Binds a shell to a port for remote access. hehe look at the =09=09source if u want this one =3D) login -=09=09Allows login to any account with the rootkit password. =09=09If root login is refused on your terminal login as "rewt". =09=09History logging is disabled if you login using your password. ls -=09=09Trojaned to hide specified files and dirs. =09=09Default data file is /dev/ptyr. =09=09All files can be listed with 'ls -/'. =09=09The format of /dev/ptyr is: =09=09ptyr =09=09hack.dir =09=09w4r3z =09=09ie. just the filenames. This would hide any files/dirs with the =09=09names ptyr, hack.dir and w4r3z. du -=09=09Same as ls, 'cept for du instead :) ifconfig -=09Modified to remove PROMISC flag when sniffing. netstat -=09Modified to remove tcp/udp/sockets from or to specified =09=09addresses, uids and ports. =09=09default data file: /dev/ptyq =09=09command 0: hide uid =09=09command 1: hide local address =09=09command 2: hide remote address =09=09command 3: hide local port =09=09command 4: hide remote port =09=09command 5: hide UNIX socket path =09=09example: =09=090 500 <- Hides all connections by uid 500 =09=091 128.31 <- Hides all local connections from 128.31.X.X =09=092 128.31.39.20 <- Hides all remote connections to 128.31.39.20 =09=093 8000 <- Hides all local connections from port 8000 =09=094 6667 <- Hides all remote connections to port 6667 =09=095 .term/socket <- Hides all UNIX sockets including the path=20 =09=09=09=09 .term/socket =09=09 =09=09Yeah eyem lazy. This is ira's description. Why bother thinking =09=09up werds when someones already done it? passwd -=09Local user->root. Enter your rootkit password instead of your =09=09old password. ps -=09=09Modified to remove specified processes. =09=09Default data file is /dev/ptyp. =09=09An example data file is as follows: =090 0 Strips all processes running under root =091 p0 Strips tty p0 =092 sniffer Strips all programs with the name sniffer =09=09Don't put in the comments, obviously. top -=09=09Identical to ps, 'cept for top instead. rshd -=09=09Execute remote commands as root.=20 =09=09Usage: rsh -l rootkitpassword host command =09=09ie. rsh -l lrkr0x cert.org /bin/sh -i =09=09 would start a root shell. syslogd -=09Modified to remove specified strings from logging. =09=09I thought of this one when I was on a system which logged =09=09every connection.. I kept getting pissed off with editing =09=09files every time I connected to remove my hostname. Then I=20 =09=09thought 'Hey dude, why not trojan syslogd?!' and the rest =09=09is history. :) =09=09Default data file is /dev/ptys =09=09Example data file: =09=09evil.com =09=09123.100.101.202 =09=09rshd =09=09This would remove all logs containing the strings evil.com, =09=09123.100.101.202 and rshd. Smart! :)) sniffit -=09An advanced network sniffer. This is pretty kewl and has lots =09=09of filtering options and other stuff. Useful for targetting a =09=09single host or net. Sniffit uses ncurses. linsniffer -=09A kewl sniffer. This is smaller than sniffit and doesn't nee= d =09=09the ncurses libraries. =20 =09=09As CERT say, sniffing is responsible for more mass network =09=09breakins than anything else in the 90's. P'raps they ain't =09=09heard of Sendmail before hahahaha =20 fix -=09=09Replaces and fixes timestamp/checksum infomation on files. =09=09I modified this a bit for my own uses and to fix a nasty bug =09=09when replacing syslogd and inetd. The replacement file will =09=09be erased by fix (unlike other versions). =20 z2 -=09=09Zapper2! Run this to erase the last utmp/wtmp/lastlog entries =09=09for a username. This can be detected since it just nulls the =09=09entry out but no sysadmins know this, right? wted -=09=09This does lots of stuff. U can view ALL the entries in a wtmp =09=09or utmp type file, erase entries by username or hostname, =09=09view zapped users (admins use a util similar to this to find =09=09erased entries), erase zapped users etc. lled -=09=09Basically the same as wted but for lastlog entries.=20 SOURCES Some of these patches are derived from the original SunOS rootkit, the ps a= nd top patches came from the first linux rootkit by ira. All of the others wer= e patched by moi. I patched just about everything I could think of. njoi ;-) OTHER STUFF If u wanna send me some email direct it towards na470561@anon.penet.fi. I welcome all unreleased exploits, passwd files and offers of cash/women :) If its important then ENCRYPT IT! My pgp key is: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2i mQCNAzCG73gAAAEEAMbBS1Oy56dSvCbKBrPYj9Hz6g9c19bEW09H6+EDuYwjtWIP b393hPkrbQqGje/kVqaip8uzaN70oyME40V36YU5/VN30yhLUA9XKkw3o00PE4Co nT/mcN8z+dV69y7+M8lXv50J0FyWfcdAjlYz0NAdiLXG1t0pvvs6puG4V+tRAAUR tCNDeWJlcm5ldGlrIDxuYTQ3MDU2MUBhbm9uLnBlbmV0LmZpPg=3D=3D =3Dmh5d -----END PGP PUBLIC KEY BLOCK----- Check out these kewl sites:=09ftp://ftp =09=09=09=09http://ww =09=09=09=09http://ww =09=09=09=09http://ww =09=09=09=09http://un Lastly, don't rely on just this kit to keep yourself hidden. Learn unix, learn C, learn how to hack properly rather than just being a kr4d 3l33t sKr1ptZ h4q3R. This kit won't save you from good logging or active network monitoring. If you don't understand what this kit does then read the source code. In short - use yer brain. Seppo Kallio=09=09=09=09kallio@jyu.fi Computing Center=09=09=09Fax +358-14-603611 U of Jyv=E4skyl=E4=09=0962.14N 25.44E=09Phone +358-14-603606 PL 35, 40351 Jyv=E4skyl=E4, Finland=09=09http://www.jyu.fi/~kallio From owner-freebsd-security Mon Sep 16 10:27:35 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA19562 for security-outgoing; Mon, 16 Sep 1996 10:27:35 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA19556 for ; Mon, 16 Sep 1996 10:27:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.5/8.6.10) with SMTP id KAA27232; Mon, 16 Sep 1996 10:27:27 -0700 (PDT) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199609161727.KAA27232@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: freebsd-security@freebsd.org cc: cy@passer.osg.gov.bc.ca Subject: Vipw/pwd_mkdb Bug (?) Date: Mon, 16 Sep 96 10:27:27 -0700 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I had the opportunity to upgrade from 2.1R to 2.1.5 and have found a rather interesting bug in vipw and pwd_mkdb. My envronment consists of two machines in an NIS domain. (NIS security is not an issue since these machines are not connected to the Internet except for an hour or two a day via a dialup line with kernel firewalling enabled). Everything worked fine until I did a vipw. After that no NIS users could log in on the machine that the vipw was performed. When I restored, from backup, master.passwd, passwd, spwd.db, and pwd.db, NIS users could once again log in. I subsequently tried pwd_mkdb from 2.1R on the 2.1.5 system and NIS users could still log in. (I assume the 2.1R version of vipw would have worked as well). I then compiled pwd_mkdb.c with the 2.1 version of pwd.h. NIS users could still use log in. I tried the -current version of pwd_mkdb and NIS users could not log in. I noticed that ls and ps worked while login and su did not for NIS users, so the problem appears to be related to getpwnam(2). I started to look at the differences between the 2.1R and the 2.1.5 version of pwd_mkdb and after a little bit of hacking I've managed to isolate the problem, though I cannot explain why it works. Since I don't have the source here with me I'll try to explain the problem from memory. Pwd_mkdb appears to have been changed to replace the "pluscnt" and "minuscnt" variables with a "ypcnt" variable. Adding some code to pwd_mkdb to write ypcnt to the database with the same key as the old _PW_KEYYPPLUSCNT key used in the 2.1R pwd_mkdb appears to have fixed the problem, however I don't fully understand why since getpwnam(2) doesn't appear to reference that key. In short I with the new pwd_mkdb and vipw, the "+" is not handled properly since the count of lines containing "+" or "-" is not written to the database, or getpwnam(2) is using this informatin and I cannot see it. Any ideas? Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Mon Sep 16 18:33:29 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA26678 for security-outgoing; Mon, 16 Sep 1996 18:33:29 -0700 (PDT) Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA26670 for ; Mon, 16 Sep 1996 18:33:26 -0700 (PDT) Received: from orion.webspan.net (scanner@orion.webspan.net [206.154.70.41]) by orion.webspan.net (8.7.5/8.6.12) with SMTP id VAA11349; Mon, 16 Sep 1996 21:33:05 -0400 (EDT) Date: Mon, 16 Sep 1996 21:33:05 -0400 (EDT) From: Scanner To: Seppo Kallio cc: freebsd-security@FreeBSD.org Subject: Re: Is Linux RootKit a know packet ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Sep 1996, Seppo Kallio wrote: > We had some cracker using Linux RootKit > > I hope the security people working with NetBSD/OpenBSD and FreeBSD know > this. And this time, I hope nobody will ever port it to BSD ;-) Actually as much as i ahte to say it, it has. -- ===================================| Webspan Inc., ISP Division. FreeBSD 2.1.5 is available now! | Phone: 908-367-8030 ext. 126 -----------------------------------| 500 West Kennedy Blvd., Lakewood, NJ-08701 Turning PCs into Workstations | E-Mail: scanner@webspan.net http://www.freebsd.org | SysAdmin / Network Engineer / Security ===================================| Member BSDNET team! http://www.bsdnet.org From owner-freebsd-security Mon Sep 16 21:14:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA06061 for security-outgoing; Mon, 16 Sep 1996 21:14:16 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA06015 for ; Mon, 16 Sep 1996 21:12:50 -0700 (PDT) Received: from rover.village.org by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0v2rWe-0008udC; Mon, 16 Sep 96 21:12 PDT Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id WAA06626; Mon, 16 Sep 1996 22:06:06 -0600 (MDT) Message-Id: <199609170406.WAA06626@rover.village.org> To: Mikael Karpberg Subject: Re: Panix Attack: synflooding and source routing? Cc: freebsd-security@FreeBSD.org In-reply-to: Your message of Sat, 07 Sep 1996 19:28:34 +0200 Date: Mon, 16 Sep 1996 22:06:06 -0600 From: Warner Losh Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : Now, I'm far from an expert in this matter, but as far as I know a SYN-flood I realize this is a little late... There is a bug in AIX kernels (3.2.5ish ones at least) that older versions of TIA tripped where it would cause a flood of SYN packets. We found out about this when we got a security emergency response message forwarded to us. Maybe something like this is going on. The problem had to do with non-blocking sockets, connection attempts that were non-blocking and strange errnos that were returned. Maybe something like netscape or some other program is causing this (or maybe an old version of TIA even)? Then again, they said that the source address packets were random, which isn't the pattern for the bug I'm reporting... Warner From owner-freebsd-security Tue Sep 17 00:08:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA16057 for security-outgoing; Tue, 17 Sep 1996 00:08:01 -0700 (PDT) Received: from relay.philips.nl (ns.philips.nl [130.144.65.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA16042 for ; Tue, 17 Sep 1996 00:07:57 -0700 (PDT) Received: (from smap@localhost) by relay.philips.nl (8.6.9/8.6.9-950414) id JAA15993; Tue, 17 Sep 1996 09:07:12 +0200 Received: from unknown(192.26.173.32) by ns.philips.nl via smap (V1.3+ESMTP) with ESMTP id sma015764; Tue Sep 17 09:05:43 1996 Received: from spooky.lss.cp.philips.com (spooky.lss.cp.philips.com [130.144.199.105]) by smtp.nl.cis.philips.com (8.6.10/8.6.10-0.9z-02May95) with ESMTP id JAA07629; Tue, 17 Sep 1996 09:08:37 +0200 Received: (from guido@localhost) by spooky.lss.cp.philips.com (8.6.10/8.6.10-0.991c-08Nov95) id JAA05929; Tue, 17 Sep 1996 09:05:37 +0200 From: Guido van Rooij Message-Id: <199609170705.JAA05929@spooky.lss.cp.philips.com> Subject: Re: Vipw/pwd_mkdb Bug (?) To: cschuber@orca.gov.bc.ca Date: Tue, 17 Sep 1996 09:05:37 +0200 (MET DST) Cc: freebsd-security@freebsd.org, cy@passer.osg.gov.bc.ca Reply-To: Guido.vanRooij@nl.cis.philips.com In-Reply-To: <199609161727.KAA27232@passer.osg.gov.bc.ca> from Cy Schubert - ITSD Open Systems Group at "Sep 16, 96 10:27:27 am" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk There is another place where I also had an argument with getpwnam() and friends. From memory I believe there is some state in these functions. Yep, I remember now. I had to reverse the order of a pair of getgrname() getpwnam() to getpwnam() getgrnam() In /usr.bin/xinstall/xinstall.c. -Guido From owner-freebsd-security Tue Sep 17 07:05:24 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA10841 for security-outgoing; Tue, 17 Sep 1996 07:05:24 -0700 (PDT) Received: from cwsys.cwent.com (cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA10834 for ; Tue, 17 Sep 1996 07:05:17 -0700 (PDT) Received: from cwsys (localhost [127.0.0.1]) by cwsys.cwent.com (8.7.5/8.6.10) with ESMTP id VAA05883 for ; Mon, 16 Sep 1996 21:07:47 -0700 (PDT) Message-Id: <199609170407.VAA05883@cwsys.cwent.com> Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: Xmh To: freebsd-security@freebsd.org Subject: Pwd_mkdb and Vipw Date: Mon, 16 Sep 1996 21:07:40 -0700 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I managed to fix the problem after compiling libc. This may have had something to do with the upgrade install I did. Libc.so may have been in use by the "virtual shell" and therefore not replaced. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Tue Sep 17 23:19:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA26502 for security-outgoing; Tue, 17 Sep 1996 23:19:59 -0700 (PDT) Received: from sdev.blaze.net.au (sdev.blaze.net.au [203.17.53.11]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA25968; Tue, 17 Sep 1996 23:18:53 -0700 (PDT) Received: from localhost (davidn@localhost) by sdev.blaze.net.au (8.7.5/8.6.9) with SMTP id QAA04805; Wed, 18 Sep 1996 16:14:39 GMT Date: Wed, 18 Sep 1996 16:14:38 +0000 () From: David Nugent To: Ollivier Robert cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Could use a favor In-Reply-To: <199609161856.UAA03226@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Sep 1996, Ollivier Robert wrote: >> The only conclusion I have come at is that it is to allow only things >> that you especially allow to happen... The bad thing is that there is no >> switch to switch the firewall on/off. You compile a new kernel with the >> option for firewall and suddenly it accepts nothing over the network. > >Sure there is: > >By default all is off. To open (dangerous!!!) > >ipfw add 65000 pass all from any to any > >To close it again: > >ipfw delete 65000 I'm familiar with the theory of firewalls, but have never run one so I lack the experience to fully understand this. But this reply caught my attention. Why is an (effectively) disabled firewall "dangerous"? Is it more "dangerous" or exposed to security problems than a machine that has been configured without a firewall at all? It's just that it seems that limited firewalls are quite usful - particularly for port redirection and so forth, and in particular for preventing outgoing and incoming spam-email abusers. If putting the firewall in place without being full enabled is "dangerous", then I certainly want to know just how dangerous that is before I go ahead and do it. David Nugent, Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-791-9547 Data/BBS +61-3-792-3507 3:632/348@fidonet davidn@blaze.net.au http://www.blaze.net.au/~davidn From owner-freebsd-security Wed Sep 18 00:53:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA18644 for security-outgoing; Wed, 18 Sep 1996 00:53:58 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA18608 for ; Wed, 18 Sep 1996 00:53:55 -0700 (PDT) Received: from al.imforei.apana.org.au by mail.crl.com with SMTP id AA20528 (5.65c/IDA-1.5 for ); Wed, 18 Sep 1996 00:54:21 -0700 Received: (from pjchilds@localhost) by al.imforei.apana.org.au (8.7.5/8.7.3) id RAA07256; Wed, 18 Sep 1996 17:17:20 +0930 (CST) Date: Wed, 18 Sep 1996 17:17:20 +0930 (CST) From: Peter Childs Message-Id: <199609180747.RAA07256@al.imforei.apana.org.au> To: davidn@sdev.blaze.net.au, freebsd-security@freebsd.org Subject: Re: Could use a favor X-Newsreader: TIN [version 1.2 PL2] Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you wrote: : >Sure there is: : > : >By default all is off. To open (dangerous!!!) : I'm familiar with the theory of firewalls, but have never run : one so I lack the experience to fully understand this. But this : reply caught my attention. : Why is an (effectively) disabled firewall "dangerous"? Is it more : "dangerous" or exposed to security problems than a machine that : has been configured without a firewall at all? No. With the firewall code totally disabled the machine is identical to a machine without firewalling implace. The person above is trying to state that by default all is off, as in all packets are denyed. The reason their is a default policy for denying all packets is for those people who use the firewalling features. Consider the situation where you are using a machine running freebsd on a machine as part of your firewall. You only want selective packets to be passed. If your machine boots up with a default policy of "let everything through" then for the time between your interface being initilized/configured and your rules being enforced/entered you've just made a large hole in your security. Regards, Peter -- Peter Childs --- http://www.imforei.apana.org.au/~pjchilds Finger pjchilds@al.imforei.apana.org.au for public PGP key Drag me, drop me, treat me like an object! From owner-freebsd-security Wed Sep 18 01:27:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA02426 for security-outgoing; Wed, 18 Sep 1996 01:27:31 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA02352; Wed, 18 Sep 1996 01:27:19 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.7.5/8.7.3) id SAA03973; Wed, 18 Sep 1996 18:25:21 +1000 (EST) Date: Wed, 18 Sep 1996 18:25:19 +1000 (EST) From: "Daniel O'Callaghan" To: David Nugent cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Could use a favor In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 18 Sep 1996, David Nugent wrote: > I'm familiar with the theory of firewalls, but have never run > one so I lack the experience to fully understand this. But this > reply caught my attention. > > Why is an (effectively) disabled firewall "dangerous"? Is it more > "dangerous" or exposed to security problems than a machine that > has been configured without a firewall at all? > > It's just that it seems that limited firewalls are quite usful - > particularly for port redirection and so forth, and in particular > for preventing outgoing and incoming spam-email abusers. If > putting the firewall in place without being full enabled is > "dangerous", then I certainly want to know just how dangerous > that is before I go ahead and do it. I think it is simply a matter of if you configure IPFIREWALL into the kernel and then believe you are protected, then it is dangerous. Ugen's ipfw originally had default policy open; Poul-Henning changed this to closed when he did a code revamp. I think Poul-Henning has done the right thing, but it is a bit confusing when one meets a "Permission denied" error when trying to ping another machine. Hence my submission of some minor mods to netstart and sysconfig which tell the user what s/he has done wrong. Danny From owner-freebsd-security Wed Sep 18 12:16:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA03557 for security-outgoing; Wed, 18 Sep 1996 12:16:54 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA03511; Wed, 18 Sep 1996 12:16:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.6/8.6.10) with SMTP id MAA02810; Wed, 18 Sep 1996 12:16:37 -0700 (PDT) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199609181916.MAA02810@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: security-officer@freebsd.org cc: freebsd-security@freebsd.org Subject: CERT Advisory CA-96.20 - Sendmail Vulnerabilities Date: Wed, 18 Sep 96 12:16:37 -0700 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is an FYI. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." ------- Forwarded Message Forwarded: Wed, 18 Sep 96 10:43:35 -0700 Forwarded: jbaker@themis.ag.gov.bc.ca Forwarded: Wed, 18 Sep 96 08:50:27 -0700 Forwarded: osg osg-mgr datasec@bcsc02.gov.bc.ca kfinnie@net.gov.bc.ca rkozsan@net.gov.bc.ca tgtadsen@bcsc02.gov.bc.ca Forwarded: Wed, 18 Sep 96 08:49:46 -0700 Forwarded: mrsmith@mailhost.wlc.com cy Return-Path: cert-advisory-request@cert.org Delivery-Date: Wed, 18 Sep 96 07:43:26 -0700 Return-Path: cert-advisory-request@cert.org Received: from orca.gov.bc.ca (ORCA.gov.bc.ca [142.32.102.25]) by passer.osg.gov.bc.ca (8.7.5/8.6.10) with SMTP id HAA31619 for ; Wed, 18 Sep 1996 07:43:26 -0700 (PDT) Received: from why.cert.org by orca.gov.bc.ca (5.4R3.10/200.1.1.4) id AA04394; Wed, 18 Sep 1996 07:43:20 -0700 Received: (from cert-advisory@localhost) by why.cert.org (8.6.12/CERT-ecd.1) id KAA18734 for cert-advisory-queue-5; Wed, 18 Sep 1996 10:35:17 -0400 Date: Wed, 18 Sep 1996 10:35:17 -0400 Message-Id: <199609181435.KAA18734@why.cert.org> From: CERT Advisory To: cert-advisory@cert.org Subject: CERT Advisory CA-96.20 - Sendmail Vulnerabilities Reply-To: cert-advisory-request@cert.org Organization: CERT(sm) Coordination Center - +1 412-268-7090 - -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT(sm) Advisory CA-96.20 Original issue date: September 18, 1996 Last revised: -- Topic: Sendmail Vulnerabilities - - ----------------------------------------------------------------------------- *** This advisory supersedes CA-95:05 *** The CERT Coordination Center has received reports of two security problems in sendmail that affect all versions up to and including 8.7.5. By exploiting the first of these vulnerabilities, users who have local accounts can gain access to the default user, which is often daemon. By exploiting the second vulnerability, any local user can gain root access. The CERT/CC team recommends installing vendor patches or upgrading to the current version of sendmail (8.7.6). Until you can do so, we urge you to apply the workaround provided in Sec. III.C. In all cases, be sure to take the extra precautions listed in Sec. III.D. For beta testers of sendmail 8.8: The vulnerabilities described in this advisory have been fixed in the beta version. We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site. In addition, you can check ftp://info.cert.org/pub/latest_sw_versions/sendmail to identify the most current version of sendmail. - - ----------------------------------------------------------------------------- I. Description There are two vulnerabilities in all versions of sendmail up to and including sendmail 8.7.5. The first vulnerability is a resource starvation problem and the second is a buffer overflow problem. Resource Starvation ------------------- When email is forwarded to a program using a .forward file or an :include: statement within a .forward or alias file, that program is executed as the owner of the .forward file or the file referenced by the :include: statement. Similarly, if email is forwarded to a file, that file is opened as the owner of the .forward file or the file referenced by the :include: statement. The file owner is called the "controlling user." If the message cannot be delivered immediately, the name of the controlling user is written into the queue file along with the other delivery information so that the appropriate permissions can be acquired when the mail queue is processed. Only the name of the controlling user is written in the queue file. This name is derived by calling the system routine getpwuid(3) on the user id of the file owner. If getpwuid fails, the sendmail default user (defined by the DefaultUser option in 8.7 and by the "u" and "g" options in older releases) is assumed. In some cases, the system can be forced into resource starvation, thus forcing getpwuid(3) to fail even though an entry exists in /etc/passwd corresponding to that uid. Since getpwuid has no way of portably returning an error meaning "resource failure" as distinct from "user id not found," sendmail has no way of distinguishing between these cases; it assumes that the uid is unknown and falls back to the default user. By starving sendmail of specific resources, sendmail will create files owned by the default user. Once created, these files can be used to access other files owned by the default user. In addition, these files owned by the default user can be used to leverage access to other privileged users on the system. Buffer Overflows ---------------- There are several buffer overflows present in sendmail version 8.7.5 and earlier. Some of the buffer overflows could result in local users gaining unauthorized root access. Significant work has been done on sendmail version 8.8 (now in beta test) to eliminate the problem, and the code changes originally planned for 8.8 have been backported to 8.7.6 to address these vulnerabilities. II. Impact Resource Starvation ------------------- Anyone with access to an account on the system can run programs or write files as the default user. The danger of compromising the default user depends primarily on the other files in your system owned by that user. For example, on many systems the line printer spool directory (e.g., /var/spool/lpd) is owned by daemon; because the line printer subsystem runs setuid root, it may be possible to gain additional privileges. However, some other systems have no files owned by user daemon on the default system, and the only files owned by group daemon are not writable by that group; hence, the danger is minimal. Buffer Overflows ---------------- Anyone with access to an account on the system can gain root access. III. Solution Install a patch from your vendor if one is available (Sec. A) or upgrade to the current version of sendmail (Sec. B). Until you can take one of those actions, we recommend applying the workaround described in Sec. C. This workaround addresses the resource starvation problem but not buffer overflows. In all cases, you should take the precautions listed in Sec. D. Note to beta testers of sendmail 8.8: The vulnerabilities described in this advisory have been fixed in the beta version of 8.8. A. Install a vendor patch. Below is a list of the vendors who have provided information about sendmail. Details are in Appendix A of this advisory; we will update the appendix as we receive more information. If your vendor's name is not on this list, please contact the vendor directly. Digital Equipment Corporation Hewlett-Packard Company IBM Corporation Linux Open Software Foundation The Santa Cruz Operation Silicon Graphics Inc. Sun Microsystems, Inc. B. Upgrade to the current version of sendmail. Install sendmail 8.7.6. This version is a "drop in" replacement for 8.7.x. There is no patch for 8.6.x. If you are using version 8.6 or earlier, you need to upgrade to the current version and rebuild your sendmail.cf files. Upgrading to version 8.7.6 addresses both vulnerabilities described in this advisory. Sendmail 8.7.6 is available from ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.7.6.tar.gz ftp://info.cert.org/pub/tools/sendmail/sendmail.8.7.6.tar.gz ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.7.6.tar.gz MD5 (sendmail.8.7.6.tar.gz) = 4a1f2179c53c9106bc8d7738f4d55667 Also in that directory are .Z and .sig files. The .Z file contains the same bits as the .gz file, but is compressed using UNIX compress instead of gzip. The .sig is Eric Allman's PGP signature for the uncompressed tar file. The key fingerprint is Type bits/keyID Date User ID pub 1024/BF7BA421 1995/02/23 Eric P. Allman Key fingerprint = C0 28 E6 7B 13 5B 29 02 6F 7E 43 3A 48 4F 45 29 Eric P. Allman Eric P. Allman Eric P. Allman Eric P. Allman We strongly recommend that when you change to a new version of sendmail you also change to the configuration files that are provided with that version. Significant work has been done to make this task easier. It is now possible to build a sendmail configuration file (sendmail.cf) using the configuration files provided with the sendmail release. Consult the cf/README file for a more complete explanation. Creating your configuration files using this method makes it easier to incorporate future changes to sendmail into your configuration files. Finally, for Sun users, a paper is available to help you convert your sendmail configuration files from the Sun version of sendmail to one that works with sendmail version 8.7.x. The paper is entitled "Converting Standard Sun Config Files to Sendmail Version 8" and was written by Rick McCarty of Texas Instruments Inc. It is included in the distribution and is located in contrib/converting.sun.configs. C. Apply a workaround. Resource Starvation ------------------- Eric Allman, the author of sendmail, has provided the following workaround to the resource starvation vulnerability. Using smrsh as "prog" mailer limits the programs that can be run as the default user. Smrsh does not limit the files that can be written, but less damage can be done by writing files directly. The damage can be almost entirely constrained by ensuring that the default user is an innocuous one. Sendmail defaults to 1:1 (daemon) only because that is reasonably portable. A special "mailnull" account that is used only for this purpose would be better. This user should own no files and should have neither a real home directory nor a real shell. A sample password entry might be: mailnull:*:32765:32765:Sendmail Default User:/no/such/dir:/dev/null A corresponding entry should be made in /etc/group: mailnull:*:32765: These assume that there are no other users or groups with id = 32765 on your system; if there are, pick some other unique value. After creating this user, change the line in /etc/sendmail.cf reading O DefaultUser=1:1 to read O DefaultUser=mailnull If you are running 8.6.*, you will have to change the lines reading Ou1 Og1 to read Ou32765 Og32765 Finally, if you are using the m4(1)-based sendmail configuration scheme provided with sendmail 8.7.*, you should add the following line to the m4 input file, usually named sendmail.mc: define(`confDEF_USER_ID', 32765:32765) The actual values should, of course, match those in the passwd file. Buffer Overflows ---------------- There is no workaround for the buffer overflow problem. To address this problem, you must apply your vendor's patches or upgrade to the current version of sendmail (version 8.7.6). D. Take additional precautions. Regardless of which solution you apply, you should take these extra precautions to protect your systems. * Use the sendmail restricted shell program (smrsh) With *all* versions of sendmail, use the sendmail restricted shell program (smrsh). You should do this whether you use vendor-supplied sendmail or install sendmail yourself. Using smrsh gives you improved administrative control over the programs sendmail executes on behalf of users. A number of sites have reported some confusion about the need to continue using the sendmail restricted shell program (smrsh) when they install a vendor patch or upgrade to a new version of sendmail. You should always use the smrsh program. smrsh is included in the sendmail distribution in the subdirectory smrsh. See the RELEASE_NOTES file for a description of how to integrate smrsh into your sendmail configuration file. smrsh is also distributed with some operating systems. * Use mail.local If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with mail.local, which is included in the sendmail distribution. It is also included with some other operating systems distributions, such as FreeBSD. Although the current version of mail.local is not a perfect solution, it is important to use it because it addresses vulnerabilities that are being exploited. For more details, see CERT advisory CA-95:02. Note that as of Solaris 2.5 and beyond, mail.local is included with the standard distribution. To use mail.local, replace all references to /bin/mail with /usr/lib/mail.local. If you are using the M4(1)-based configuration scheme provided with sendmail 8.X, add the following to your configuration file: define(`LOCAL_MAILER_PATH', /usr/lib/mail.local) * WARNING: Check for executable copies of old versions of mail programs If you leave executable copies of older versions of sendmail installed in /usr/lib (on some systems, it may be installed elsewhere), the vulnerabilities in those versions could be exploited if an intruder gains access to your system. This applies to sendmail.mx as well as other sendmail programs. Either delete these versions or change the protections on them to be non-executable. Similarly, if you replace /bin/mail with mail.local, remember to remove old copies of /bin/mail or make them non-executable. ........................................................................... Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, please contact the vendor directly. Digital Equipment Corporation ============================= [About the resource starvation problem] Source: Software Security Response Team Copyright (c) Digital Equipment Corporation 1996. All rights reserved. 08.SEP.1996 At the time of writing this document, patches (binary kits) for Digital's UNIX related operating systems are being developed. Digital will provide notice of availability for remedial kits through AES services (DIA, DSNlink FLASH), placed in the public FTP patch service domain and also be available from your normal Digital Support channel. ftp://ftp.service.digital.com/public/{OS/{vn.n} | | | |--version |--osf or ultrix 9/96 - DIGITAL EQUIPMENT CORPORATION Hewlett-Packard Company ======================= [About the resource starvation problem] HP-UX is vulnerable, and a patch is in progress. The HP SupportLine Mail Service provides notification of security patches for HP-UX to its 'security_info' mailing list. For information on the service, send mail to support@us.external.hp.com with 'help' in the body of the message (without quotes). To report new security defects in HP software, send mail to security-alert@hp.com. IBM Corporation ================ The following APARs are being developed and will be available shortly. See the appropriate release below to determine your action. AIX 3.2 ------- Apply the following fixes to your system: APAR - IX61303 IX61307 AIX 4.1 ------- Apply the following fixes to your system: APAR - IX61162 IX61306 To determine if you have this APAR on your system, run the following command: instfix -ik IX61162 IX61306 AIX 4.2 ------- Apply the following fixes to your system: APAR - IX61304 IX61305 To determine if you have this APAR on your system, run the following command: instfix -ik IX61304 IX61305 To Order -------- APARs may be ordered using Electronic Fix Distribution (via FixDist) or from the IBM Support Center. For more information on FixDist, http://service.software.ibm.com/aixsupport/ or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist". IBM and AIX are registered trademarks of International Business Machines Corporation. Linux ===== [For the resource starvation problem:] Debian Linux: not vulnerable (uses smail) Red Hat and derivatives: ftp://ftp.redhat.com/pub/redhat-3.0.3/i386/updates/RPMS/sendmail* Open Software Foundation ======================== OSF's OSF/1 R1.3.2 is not vulnerable to these types of attacks described in the resource starvation sections of the advisory. OSF's OSF/1 R1.3.2 is vulnerable to the buffer overflow problems. We will address the problem in our next maintenance release. The Santa Cruz Operation ======================== Any SCO operating system running a version of sendmail provided by SCO is vulnerable to this problem. SCO is providing Support Level Supplement (SLS) oss443a for the following releases to address this issue: SCO Internet FastStart release 1.0.0 SCO OpenServer releases 5.0.0 and 5.0.2 This SLS provides a pre-release version of sendmail release 8.7.6 for these platforms. SCO hopes to have a final version of sendmail 8.7.6 available to address both issues mentioned in this advisory in the near future. Note that only SCO Internet FastStart uses sendmail as the default mail system. All other SCO operating systems use other mail systems such as the Multi-Channel Memorandum Distribution Facility (MMDF) or the "mailsurr" mail system as the default, and as such are not vulnerable to this problem unless otherwise configured to use sendmail. SCO intends to provide a similar patch for SCO UnixWare release 2.1.0 in the near future. When configured to use a version of sendmail provided by SCO, releases prior to the ones mentioned here are also vulnerable, but no plans have yet been made concerning patches for these earlier releases. You can download SLS oss443a as shown below. Anonymous ftp (World Wide Web URL) ------------- ftp://ftp.sco.COM/SSE/oss443a (SLS image) ftp://ftp.sco.COM/SSE/oss443a.ltr.sse (cover letter/install notes) Compuserve ---------- SLS oss443a is also available in the SCO Forum on Compuserve. SCO Online Support (SOS) BBS ---------------------------- SLS oss443a can also be downloaded interactively via X, Y, or Z MODEM or Kermit, using the SCO Online Support System (SOS). Follow the menu selections under "Toolchest" from the main SOS menu. The phone numbers available for interactive transfer from SOS are: 1-408-426-9495 (USA) +44 (0)1923 210 888 (United Kingdom) Checksums --------- sum -r ------ 13804 630 oss443a 35304 14 oss443a.ltr.sse MD5 --- MD5 (oss443a) = 549260a71ca76f4e98dd38bccb72748c MD5 (oss443a.ltr.sse) = 7475d83f0db64a1af69eb66cd392a9d3 Be sure to keep track of the README file at ftp://ftp.sco.COM/SSE/README for updates to this supplement. If you have further questions, contact your support provider. If you need to contact SCO, please send electronic mail to support@sco.COM, or contact SCO as follows. USA/Canada: 6am-5pm Pacific Daylight Time (PDT) ----------- 1-800-347-4381 (voice) 1-408-427-5443 (fax) Pacific Rim, Asia, and Latin American customers: 6am-5pm Pacific ------------------------------------------------ Daylight Time (PDT) 1-408-425-4726 (voice) 1-408-427-5443 (fax) Europe, Middle East, Africa: 9am-5:30pm Greenwich Mean Time (GMT) ---------------------------- +44 (0)1923 816344 (voice) +44 (0)1923 817781 (fax) Silicon Graphics, Inc. ====================== We are analyzing the vulnerability, and will provide additional information as it becomes available. Sun Microsystems, Inc. ====================== Sun is working on a patch which will fix both problems, and we expect to have it out by the end of the month. Also, we will send out a Sun bulletin on this subject at about the same time. - - ------------------------------------------------------------------------------ The CERT Coordination Center staff thanks Eric Allman, the author of sendmail, for his extensive assistance with this advisory, Wolfgang Ley of DFN-CERT for his support in the development of the advisory, and D. J. Bernstein of the University of Illinois at Chicago for reporting the resource starvation vulnerability. - - ----------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (see ftp://info.cert.org/pub/FIRST/first-contacts). CERT/CC Contact Information - - ---------------------------- Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA Using encryption We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information. You can get the CERT PGP key from ftp://info.cert.org/pub/CERT_PGP.key Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key Getting security information CERT publications and other security information are available from http://www.cert.org/ ftp://info.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for advisories and bulletins, send your email address to cert-advisory-request@cert.org - - --------------------------------------------------------------------------- Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. - - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-96.20.sendmail_vul http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMj/++HVP+x0t4w7BAQEoBQP/THORrwVlVF6WbC1zJ3V7fMLC3XSXoG7E WPbIxciOj1xwA14gvVGXyPMtnH6AmgD7PyzQyifzwu/MrecU3UHfgdjVlpJbRjFJ XplELdcjt39wKGz9TlurK/iE31PN/gOlcBBukyLjIuq9NHJEi9vN7M0nTp3KmW/b H66I2ElnY7w= =tQ1H - -----END PGP SIGNATURE----- ------- End of Forwarded Message From owner-freebsd-security Thu Sep 19 01:11:24 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA08368 for security-outgoing; Thu, 19 Sep 1996 01:11:24 -0700 (PDT) Received: from precipice.shockwave.com (ppp-206-170-5-63.rdcy01.pacbell.net [206.170.5.63]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA08330; Thu, 19 Sep 1996 01:11:17 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id BAA15858; Thu, 19 Sep 1996 01:10:54 -0700 (PDT) Message-Id: <199609190810.BAA15858@precipice.shockwave.com> To: freebsd-security-notifications@freebsd.org cc: security@freebsd.org From: FreeBSD Security Officer Date: Thu, 19 Sep 1996 01:10:53 -0700 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- DRAFT DRAFT Wed Sep 18 23:22:44 PDT 1996 DRAFT DRAFT Distribution unlimited, however there are likely to be errors or DRAFT ommissions in this text. This will be incorporated into a formal DRAFT FreeBSD Security Advisory as soon as this document has been reviewed DRAFT and more experience with the system tuning parameters is available. DRAFT -- pst 18sep96 DRAFT "Some comments from the FreeBSD Security Officer regarding recent SYN flooding attacks." Paul Traina FreeBSD, Inc. courtesy of Juniper Networks, Inc. How to detect and tune FreeBSD systems to resist SYN flooding attacks. ---------------------------------------------------------------------- (1) How do I know if I'm under attack? The attack will cause one of the TCP statistics counters in FreeBSD to increment. Under normal circumstances, this counter will rarely, if ever, increment, however if connection queues are being overflowed, we will register this event. % netstat -s | grep "listen queue overflows" 0 listen queue overflows If this value is growing rapidly over time, you may be under at that moment. If you suspect you are a likely target, we suggest that you write a script to periodicly check this counter and notify the appropriate folks if you see it rise rapidly over several polling periods. (2) How do I make my FreeBSD system invulnerable to this attack? The only sure way to stop the attack is to turn off the services that the attacker is attempting to thwart. Clearly, there are some services that can easily be eliminated (e.g. the echo and discard services), but this "cure" is worse than the disease if your service is fundamental to your endeavors (such as a HTTP server or SMTP server). There is no sure way of stopping the SYN flood attack. The packets that are sent appear to be legitimate connection attempts, and as such, any filter put in place on the destination host designed to eliminate these requests would deny desired services. An attacker with a high-bandwidth path to a target host is virtually unstoppable. We can tune the system to make it resistant to the SYN flood attack, but a suitably malicious character with significant resources can cause denial of service attacks several ways (including tricking the system administrator to inadvertently mis-tune their system so that legitimate connection attempts now fail). (3) What can I do about this attack? First off, there is a bug in the BSD TCP implementation that causes the system to hold onto resources longer than it should. Specificly, under some circumstances, the system will hold onto half-open connections for up to 12 minutes, instead of the anticipated 75 seconds. This bug is documented in Stevens volume 3. The first thing anyone should do is apply the provided patches to your FreeBSD system to eliminate this bug. In addition to fixing this TCP implementation bug, we have added the ability to tune the kernel on the fly, should an attack be discovered in progress. We do not recommend tuning the kernel under normal circumstances. The default values are perfectly reasonable. The variables are modified using the sysctl(1) program. kern.somaxconn - maximum number of entries allowable in the listen queue per socket kern.sominqueue - minimum configurable queue length (override the value passed to the kernel in the listen() system call) net.inet.tcp.keepinit - maximum time to wait for connection to move to established state You need to be reasonably intelligent when setting these values. You're "tuning" your system. When a system is under attack, the nature of the service you are providing and the aggressiveness of the attack dictate the settings of these parameters. Remember, it's possible to mis-tune your system so that you will deny legitimate connection attempts, which means you're doing your attacker's job. net.inet.tcp.keepinit The net.inet.tcp.keepinit variable controls the time the system will wait for a SYN ACK before tossing away a connection. Since the SYN flood attack relies on filling up a connection queue until the entries in the queue are aged out, reducing the time an entry may remain in the queue will effectively strengthen your system. The default value of 75 seconds was chosen as a "worst case" where a connection attempt was started over a high delay link and an acknowledgment or two were lost along the way, causing one or both sides to retransmit. Common wisdom today is that this timer may be set as low as 15 seconds without significantly affecting most legitimate connection attempts. If you set this timer too short, only "nearby" hosts with highly reliable links will be able to connect to your services. kern.somaxconn The kern.somaxconn variable is a high-water limit on the maximum number of pending connections a server may request. When a server is started under BSD, it will request a maximum number of pending connections. Most servers request "0" which means use the system maximum (which is controlled by kern.somaxconn). The default value under FreeBSD is 128 connections. This means that unless a server requests otherwise, we'll allow up to 128 "pending" connections on a given tcp port (plus a little fudge factor). By increasing the maximum length of the connection queue, you allow more half-open connections to remain active (until they are expired). Remember though, that each half-open connection requires the system to maintain some state. If you set the connection queue length too large, an attacker can run your system out of memory. Some FreeBSD users have raised this limit to 10000 when under attack (and restarted their servers so the new limit takes affect) and have not reported problems. kern.sominqueue A given server may request fewer than the system maximum queue limit. This is usually done in cases where a service is provided where low response latency is key. If a transaction has sat around in a queue for a long time, there's no point in completing the transaction. This isn't the typical case. If you have such a server, and you are unable to change the code to eliminate this artificial limitation, there's one thing you can try. The kern.sominqueue variable overrides any minimum queue length requests made by the server. The default for this variable is 0, which means that a server may request a tiny queue and that request will be respected. There really should be no reason to override the minimum queue value. If you do raise it, you may inadvertently affect the operation of other services operating on the local machine. Basicly, this is a sledge-hammer approach to tuning the system when no other option is available. (4) How do we fix this once and for all? Unfortunately, this is a vulnerability in the design of TCP. A fair number of protocol experts are musing over ways to fix this. The best solutions to date require an authenticated IP layer. There are changes being made to the Internet infrastructure which will make it more difficult for attackers to operate without detection, but for the time being, without a change to the TCP protocol or the addition of authentication below TCP, there simply is no "solution" that isn't as bad as the problem itself, despite the claims of "anti-SYN" product vendors. (5) Where do I get these patches? These patches have been incorporated into FreeBSD 2.1-STABLE and FreeBSD 2.2-CURRENT as of 19-Sep-1996. Updating your source tree from those code bases and recompiling your kernel will get you the new code. Also available are patches relative to the FreeBSD 2.1.5 release. These patches will be incorporated into an official FreeBSD security advisory when complete, but for now, you can find them at: ftp://freebsd.org/pub/CERT/patches/syn-flooding-prerelease/tcp-patches.215 -rw-r--r-- 1 pst security 10142 Sep 19 00:58 tcp-patches.215 MD5 (tcp-patches.215) = f6167c50b8d3302156fc0f9d609e89a7 DRAFT DRAFT End of draft DRAFT -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMkD/mlUuHi5z0oilAQGAOwP/SHPTXoPb2uCc/Cx+BdDkoXVNTYbkJWOR wdM6mnq/oZDUqZpyqZ1q2EZDIjhWgqecioPNg0uFuJHfyx15uQQbDepfW3l4luik PXhdCR1G8vbAgQKHPVXhRi4dCkhTb7RQLSlZf6+sj7n4JyLSliztFzNxk1Goo5Fs x5Mbx7aB7ig= =oOo2 -----END PGP SIGNATURE----- From owner-freebsd-security Thu Sep 19 06:42:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA10099 for security-outgoing; Thu, 19 Sep 1996 06:42:41 -0700 (PDT) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA10041; Thu, 19 Sep 1996 06:42:34 -0700 (PDT) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id GAA07112; Thu, 19 Sep 1996 06:42:33 -0700 (PDT) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id XAA01275; Thu, 19 Sep 1996 23:42:11 +1000 From: Julian Assange Message-Id: <199609191342.XAA01275@suburbia.net> Subject: Re: Could use a favor To: davidn@sdev.blaze.net.au (David Nugent) Date: Thu, 19 Sep 1996 23:42:11 +1000 (EST) Cc: roberto@keltia.freenix.fr, hackers@FreeBSD.org, security@FreeBSD.org In-Reply-To: from "David Nugent" at Sep 18, 96 04:14:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I'm familiar with the theory of firewalls, but have never run > one so I lack the experience to fully understand this. But this > reply caught my attention. > > Why is an (effectively) disabled firewall "dangerous"? Is it more > "dangerous" or exposed to security problems than a machine that > has been configured without a firewall at all? > > David Nugent, Unique Computing Pty Ltd - Melbourne, Australia > Voice +61-3-791-9547 Data/BBS +61-3-792-3507 3:632/348@fidonet > davidn@blaze.net.au http://www.blaze.net.au/~davidn The problem is that the interface may go up before you have added all your firewall rules creating a window of opportunity for the attacker. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | 0619737CCC143F6DEA73E27378933690 | +---------------------+--------------------+----------------------------------+ From owner-freebsd-security Thu Sep 19 12:16:00 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA26994 for security-outgoing; Thu, 19 Sep 1996 12:16:00 -0700 (PDT) Received: (from wpaul@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA26978; Thu, 19 Sep 1996 12:15:58 -0700 (PDT) From: Bill Paul Message-Id: <199609191915.MAA26978@freefall.freebsd.org> Subject: pwd_mkdb and NIS To: dg@root.com Date: Thu, 19 Sep 1996 12:15:58 -0700 (PDT) Cc: cschuber@orca.gov.bc.ca, freebsd-security@freebsd.org In-Reply-To: <199609170218.TAA08566@root.com> from "David Greenman" at Sep 16, 96 07:18:31 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I had the opportunity to upgrade from 2.1R to 2.1.5 and have found a rather > interesting bug in vipw and pwd_mkdb. [chop] It's not a bug. I've already answered a question like this on either hackers or current a while ago. Somehow, you may have botched your upgrade. When upgrading, you must insure that you end up with the most recent versions of all the shared libraries, including libc, and all the latest binaries. I strongly suspect that you somehow left an old version of libc.so from 2.1.0 on your system. This will not work: you must make sure you have the libc.so from FreeBSD 2.1.5, _and_ that the dynamic linker is finding it correctly. Yes, the magic _PW_* keys for YP changed between versions. This was intentional. I decided the old code sucked and replaced it with some less sucky code that only required one special key. What you should do is this: - Upgrade correctly: make sure that you have both the pwd_mkdb and libc binaries from 2.1.5 installed and talking to each other. - Rerun ldconfig to make sure that it actually _uses_ the new libraries after they're installed. - Rebuild your password database using _ONLY_ the /etc/master.passwd file. Just force pwd_mkdb to rebuild everything once. That last time this happened, it turned out that the user had an old version of libc on his system. How it got there I'm not sure, but if you properly match up libc with pwd_mkdb, there should not be any problems: the new getpwent(3) code knows how to deal with the databases generated by the new pwd_mkdb. Also, the 2.1.5 code is backward compatible with 2.1.0, so that it should be able to read the old style password databases and properly handle NIS users. But the new format is _not_ compatible with the old getpwent(3) code. Run 'ldd /usr/sbin/pwd_mkdb' and check which version of libc the runtime linker is choosing. It must be the latest one that came packaged with FreeBSD 2.1.5. Also try 'ldd /usr/bin/login' and make sure it displays the same libraries. If you have 2.1.5 on CD-ROM, check the live filesystem CD for libc.so and make sure it's the same as the one on your system. If you don't have the CD, you'll have to crack open the bin.?? distribution to get it. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." ============================================================================= From owner-freebsd-security Thu Sep 19 18:29:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA07198 for security-outgoing; Thu, 19 Sep 1996 18:29:36 -0700 (PDT) Received: from cwsys.cwent.com (cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA07171 for ; Thu, 19 Sep 1996 18:29:31 -0700 (PDT) Received: from cwsys (localhost [127.0.0.1]) by cwsys.cwent.com (8.7.6/8.6.10) with ESMTP id SAA00672; Thu, 19 Sep 1996 18:28:56 -0700 (PDT) Message-Id: <199609200128.SAA00672@cwsys.cwent.com> Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: Xmh To: Bill Paul cc: dg@root.com, cschuber@orca.gov.bc.ca, freebsd-security@freebsd.org Subject: Re: pwd_mkdb and NIS In-reply-to: Your message of "Thu, 19 Sep 1996 12:15:58 PDT." <199609191915.MAA26978@freefall.freebsd.org> Date: Thu, 19 Sep 1996 18:28:52 -0700 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What you describe is indeed what happened. I do remember seeing some messages going by about the compatibility libraries not being replaced because they were in use. I subsequently copied them over from CDROM #2. At the time I did not realize that libc.so was also affected by this. The next evening I recompiled libc and the problem went away. The only way I could have "botched" the upgrade was to periodically enter df -k in the "holographic shell". That probably loaded libc.so and a number of other libraries from the chrooted filesystem. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." > > > > I had the opportunity to upgrade from 2.1R to 2.1.5 and have found a rather > > interesting bug in vipw and pwd_mkdb. > > [chop] > > It's not a bug. I've already answered a question like this on either > hackers or current a while ago. > > Somehow, you may have botched your upgrade. When upgrading, you must > insure that you end up with the most recent versions of all the shared > libraries, including libc, and all the latest binaries. I strongly > suspect that you somehow left an old version of libc.so from 2.1.0 > on your system. This will not work: you must make sure you have the > libc.so from FreeBSD 2.1.5, _and_ that the dynamic linker is finding > it correctly. > > Yes, the magic _PW_* keys for YP changed between versions. This was > intentional. I decided the old code sucked and replaced it with some > less sucky code that only required one special key. What you should do > is this: > > - Upgrade correctly: make sure that you have both the pwd_mkdb and > libc binaries from 2.1.5 installed and talking to each other. > > - Rerun ldconfig to make sure that it actually _uses_ the new libraries > after they're installed. > > - Rebuild your password database using _ONLY_ the /etc/master.passwd file. > Just force pwd_mkdb to rebuild everything once. > > That last time this happened, it turned out that the user had an old > version of libc on his system. How it got there I'm not sure, but if > you properly match up libc with pwd_mkdb, there should not be any problems: > the new getpwent(3) code knows how to deal with the databases generated > by the new pwd_mkdb. Also, the 2.1.5 code is backward compatible with > 2.1.0, so that it should be able to read the old style password databases > and properly handle NIS users. But the new format is _not_ compatible > with the old getpwent(3) code. > > Run 'ldd /usr/sbin/pwd_mkdb' and check which version of libc the > runtime linker is choosing. It must be the latest one that came packaged > with FreeBSD 2.1.5. Also try 'ldd /usr/bin/login' and make sure it > displays the same libraries. If you have 2.1.5 on CD-ROM, check the > live filesystem CD for libc.so and make sure it's the same as the one > on your system. If you don't have the CD, you'll have to crack open > the bin.?? distribution to get it. > > -Bill > > -- > ============================================================================= > -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu > Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research > Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City > ============================================================================= > "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." > ============================================================================= > From owner-freebsd-security Thu Sep 19 21:10:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA24183 for security-outgoing; Thu, 19 Sep 1996 21:10:06 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA24142 for ; Thu, 19 Sep 1996 21:10:01 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id WAA25123 for ; Thu, 19 Sep 1996 22:09:54 -0600 (MDT) Message-Id: <199609200409.WAA25123@rover.village.org> To: security@FreeBSD.org Subject: comments on the SYN attack In-reply-to: Your message of Thu, 19 Sep 1996 01:10:53 PDT Date: Thu, 19 Sep 1996 22:09:54 -0600 From: Warner Losh Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : (4) How do we fix this once and for all? : : Unfortunately, this is a vulnerability in the design of TCP. A fair : number of protocol experts are musing over ways to fix this. : The best solutions to date require an authenticated IP layer. : : There are changes being made to the Internet infrastructure which will : make it more difficult for attackers to operate without detection, but : for the time being, without a change to the TCP protocol or the addition : of authentication below TCP, there simply is no "solution" that isn't as : bad as the problem itself, despite the claims of "anti-SYN" product : vendors. Question: Wouldn't randomly dropping SYN packets when the above limits are triggered "help" the problem. The reasoning is that if I'm trying to establish a connection, I'll send a SYN packet, then another and so on until I time out. Since I'm generating multiple good SYN packets, losing one or two of them won't hurt. However, dropping bogus SYN packets under heavy load will help to reduce that load somewhat. The longer the queue is, the more likely it should be that a SYN gets dropped. Much like the RED routers that were recently researched by LNLL. Or has this been considered and a flaw been found? Generally, one can't prevent the SYN packets from arriving at your machine for serves one provides to the net. However, one can be intellegent about what one listens to, can't one? Warner From owner-freebsd-security Thu Sep 19 21:48:13 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA07109 for security-outgoing; Thu, 19 Sep 1996 21:48:13 -0700 (PDT) Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA07040 for ; Thu, 19 Sep 1996 21:48:02 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.7.6/8.7.3) id OAA26057 for security@freebsd.org; Fri, 20 Sep 1996 14:47:18 +1000 Received: from pandora.devetir.qld.gov.au by ogre.devetir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with ESMTP id OAA01154 for ; Fri, 20 Sep 1996 14:49:01 +1000 (EST) Received: from netfl15a.devetir.qld.gov.au (netfl15a.devetir.qld.gov.au [167.123.24.12]) by pandora.devetir.qld.gov.au (8.6.10/8.6.12) with ESMTP id OAA01713 for ; Fri, 20 Sep 1996 14:49:03 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id EAA26487 for ; Fri, 20 Sep 1996 04:50:23 GMT Message-Id: <199609200450.EAA26487@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: security@freebsd.org Subject: Possible MD5 weakness (fwd from PEM) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Sep 1996 14:50:21 +1000 From: Stephen Hocking Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Date: Fri, 13 Sep 1996 16:09:30 -0700 (PDT) >From: Ned Freed >Subject: Re: TFM needed ro R >To: David Rudder >Cc: pem-dev@TIS.COM >Message-Id: <01I9FPRGR3US8Y5I6P@INNOSOFT.COM> >Mime-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII >Content-Transfer-Encoding: 7BIT >Sender: pem-dev-approval@neptune.hq.tis.com >Precedence: bulk > RIPEM and SSLeay seem to like MD5. RIPEM uses MD2 for it's X.509 > certificates but MD5 for it's MIC-Info. There are a bunch of MD5 > programs out there and a number written in Java. Bruce Schneier says "I am > wary of MD5" on pge 441 of Applied Cryptography. He states before that > that MD5 hasn't been provven insecure, but weaknesses have been found in > the compression function. If he is wary of this algorithm, then why is > it so popular? It's by far more prevelant than any other message digest > I've seen. It is worse than Schneier says -- there are newer results now. See the current issue of RSA's CryptoBytes publication, Volume 2 Number 2, Summer 1996, for details. Online copies are available in http://www.rsa.com/rsalabs/cryptobytes/. The bottom line is that new application should no longer specify MD5 as a MIC. And MD2 has been obsolete for some time. Use either SHA-1 or RIPEMD-160. (I prefer the former.) Ned Stephen -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-security Thu Sep 19 21:57:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA10133 for security-outgoing; Thu, 19 Sep 1996 21:57:18 -0700 (PDT) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA10092 for ; Thu, 19 Sep 1996 21:57:10 -0700 (PDT) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id OAA08686; Fri, 20 Sep 1996 14:23:50 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA09567; Fri, 20 Sep 96 14:23:18 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9609200453.AA09567@communica.com.au> Subject: Re: comments on the SYN attack To: imp@village.org (Warner Losh) Date: Fri, 20 Sep 1996 14:23:17 +0930 (CST) Cc: security@FreeBSD.org In-Reply-To: <199609200409.WAA25123@rover.village.org> from "Warner Losh" at Sep 19, 96 10:09:54 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: > : (4) How do we fix this once and for all? > : > : Unfortunately, this is a vulnerability in the design of TCP. > > Question: Wouldn't randomly dropping SYN packets when the above limits > are triggered "help" the problem. I'd suggest that keeping the SYN list sorted by arrival time and dropping the oldest SYN whenever resources are scarse would be a better solution (it's more deterministic, for a start. Also, one of the evil things about random number generators is that they're not random...) However, even that won't "solve" the problem: A determined SYN bomber would merely have to ensure that he sent packets quickly enough to make the queue cycle completely within the 200mSec or so that one can reasonable expect a SYN-SYN/ACK-ACK exchange to take (keep the un-ACK'ed SYNs walking thorugh the list LED-chaser style). That's a somewhat higher transmission rate than the one required to cause denial of service under current implementations, but it's still well within the realms of possibility :-/ If the bomber isn't that determined, dropping the oldest SYN will ensure that those SYNs which aren't the oldest (eg: the one you just planted onto the queue by typing "telnet hostname") don't get dropped unless load is exceptional. > Generally, one can't prevent the SYN packets from arriving at your > machine for serves one provides to the net. However, one can be > intellegent about what one listens to, can't one? Indeed. And as the CERT advisory this morning pointed out (and as the firewalls list has been discussing for over a week), if ISPs would put anti-spoofing access lists on their *OUTBOUND* interfaces then they could ensure that if SYN bombing isn happening it isn't from their site. - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Thu Sep 19 22:14:15 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA16704 for security-outgoing; Thu, 19 Sep 1996 22:14:15 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA16619 for ; Thu, 19 Sep 1996 22:14:02 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id XAA26063; Thu, 19 Sep 1996 23:13:21 -0600 (MDT) Message-Id: <199609200513.XAA26063@rover.village.org> To: newton@communica.com.au (Mark Newton) Subject: Re: comments on the SYN attack Cc: security@FreeBSD.org In-reply-to: Your message of Fri, 20 Sep 1996 14:23:17 +0930 Date: Thu, 19 Sep 1996 23:13:21 -0600 From: Warner Losh Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : I'd suggest that keeping the SYN list sorted by arrival time and dropping : the oldest SYN whenever resources are scarse would be a better solution : (it's more deterministic, for a start. Also, one of the evil things : about random number generators is that they're not random...) The random numbers wouldn't have to be perfect in this case. They would just have to pick a victum. The randomness is part of the solution, so changing it would change the character of it dramatically. : However, even that won't "solve" the problem: A determined SYN bomber : would merely have to ensure that he sent packets quickly enough to : make the queue cycle completely within the 200mSec or so that one : can reasonable expect a SYN-SYN/ACK-ACK exchange to take (keep the : un-ACK'ed SYNs walking thorugh the list LED-chaser style). That's a : somewhat higher transmission rate than the one required to cause denial : of service under current implementations, but it's still well within : the realms of possibility :-/ I think that's why you'd have to do it at random. : If the bomber isn't that determined, dropping the oldest SYN will ensure : that those SYNs which aren't the oldest (eg: the one you just planted onto : the queue by typing "telnet hostname") don't get dropped unless load is : exceptional. That is true. However, my gut tells me that the random victum will give better behavior than the shoot the oldest one. If you have a queue length of 1000, and can deliver 500 bogus SYNs in the 200mS that it takes, then you'd have a 60% chance of not dropping the good SYN (1 - .999 ^ 500 = 60%). If you can deliver 1000 bogus SYNs in that time, then the deterministic method would have a 0% chance, and the random method would have a 35% chance of surviving (if bc on my machine for .999^1000 can be trusted). Given that SYNs are retransmitted, then you'd be able to get after 2 tries on the average. If the bomber can pump 10,000 packets in, then you lose (< 0.0045% chance of survival). Even 5,000 drop it to 0.6%. However, 5,000 packets in 200mS is 25,000 packets in a second, which would be 1MB/s or 10Mb/s. So you'd be safe as long as you are behind something of T1 speed or slower :-) If you aren't then you'll need longer queues... I agree it isn't perfect, but it seems better than the alternatives. Warner From owner-freebsd-security Thu Sep 19 22:46:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA04503 for security-outgoing; Thu, 19 Sep 1996 22:46:42 -0700 (PDT) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA04442 for ; Thu, 19 Sep 1996 22:46:34 -0700 (PDT) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id PAA09059; Fri, 20 Sep 1996 15:13:16 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA11812; Fri, 20 Sep 96 15:12:44 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9609200542.AA11812@communica.com.au> Subject: Re: comments on the SYN attack To: imp@village.org (Warner Losh) Date: Fri, 20 Sep 1996 15:12:43 +0930 (CST) Cc: newton@communica.com.au, security@FreeBSD.org In-Reply-To: <199609200513.XAA26063@rover.village.org> from "Warner Losh" at Sep 19, 96 11:13:21 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: > However, my gut tells me that the random victum will give better > behavior than the shoot the oldest one. Oh? I believe that statistically speaking the two cases provide an identical chance of booting away an individual packet: Consider that the deterministic case is precisely equivalent to the random case with a pseudorandom number generator which just coincidentally always returns the identity of the oldest SYN packet... [ indeed, if you're looking at an individual packet, the present implementation is identical as well: it just "randomly" drops the "youngest" packet on the queue, ie: the one that has arrived at a time when there aren't enough resources to keep it ] > If you have a queue length of 1000, and can deliver 500 bogus SYNs in > the 200mS that it takes, then you'd have a 60% chance of not dropping > the good SYN (1 - .999 ^ 500 = 60%). If you can deliver 1000 bogus > SYNs in that time, then the deterministic method would have a 0% > chance, and the random method would have a 35% chance of surviving (if > bc on my machine for .999^1000 can be trusted). You're assuming that a SYN is going to spend all of that 200mSec in the queue (remember, I provided that number as an upper-bound for the purposes of discussion, not as an axiomatic interval symtomatic of catastrophic failure!). 1000 bogus SYNs in 200mSec is something that takes of the order of 200kbps of bandwidth to support. On a 200kbps channel, I'd be willing to wager that the vast majority of your SYNs are answered with SYN-ACKs (and thereby removed from this equation) within 50mSec or less, meaning that the oldest SYN would almost always be one with an unreachable return address. Keep in mind that this is making the attacker work a lot harder too - He only needs to send about five packets per second to keep queues congested under present implementations! By thowing away the oldest SYN, you're effectively extending the present algorithm by adding a variable-length timeout instead of a 75-second timeout. The size of that variable-length timeout is dependent on the demand being placed on your system. That dynamicism is biased to provide newly arrived legitimate SYNs a fair chance of survival before they're treated as bogus and thrown away due to high demand. Given that you'll end up throwing away good SYNs if you're short on resources anyway, I'd rather select which good ones get chucked on a best-efforts basis instead of a random basis. The only way you'd throw away a good SYN is if its source address was on the other side of a link that was so slow that it was indistinguishible from an unreachable host for the purposes of SYN-warfare. At that point, it becomes the "best choice" for droppage for a (relatively) good reason, rather than a random impulse. By throwing away a random SYN, you're effectively treating all packets as bogus until proven otherwise, *AND* creating the possibility that you'll randomly boot 'em up the arse before they've had a chance to provide you with that proof. Sure, if you look at a single packet in isolation after declaring that "all things are equal" then you'll probably give an individual packet a better chance of survival; But that approach ignores the fact that all things *aren't* equal, and that it is highly likely that the oldest packet in the SYN queue is there because the SYN-ACK has been dropped by a router because its destination is unreachable. > Given that SYNs are > retransmitted, then you'd be able to get after 2 tries on the average. I'd suggest that the deterministic solution would let you in on 1 try. Usually :-) You're implementation is also computationally expensive: Random numbers aren't cheap, and I wouldn't like to spend too much of my life calculating thousands of them per second... - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Thu Sep 19 23:12:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA17556 for security-outgoing; Thu, 19 Sep 1996 23:12:46 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA17485 for ; Thu, 19 Sep 1996 23:12:37 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id AAA26892; Fri, 20 Sep 1996 00:11:58 -0600 (MDT) Message-Id: <199609200611.AAA26892@rover.village.org> To: newton@communica.com.au (Mark Newton) Subject: Re: comments on the SYN attack Cc: security@FreeBSD.org In-reply-to: Your message of Fri, 20 Sep 1996 15:12:43 +0930 Date: Fri, 20 Sep 1996 00:11:58 -0600 From: Warner Losh Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : Warner Losh wrote: : : > However, my gut tells me that the random victum will give better : > behavior than the shoot the oldest one. : : Oh? I believe that statistically speaking the two cases provide an : identical chance of booting away an individual packet: Consider that the : deterministic case is precisely equivalent to the random case with a : pseudorandom number generator which just coincidentally always returns : the identity of the oldest SYN packet... I don't think so. In the determanistic case if you get 1000 SYNs when you have a queue that is 1000 long, you'd drop all 1000 of the SYNs in every case. In the randomly kill one, once you get in the queue you have about a 60% chance of survival once the next 1000 SYNs come in. That's not quite the same thing. : [ indeed, if you're looking at an individual packet, the present : implementation is identical as well: it just "randomly" drops the : "youngest" packet on the queue, ie: the one that has arrived at a : time when there aren't enough resources to keep it ] That is a possibility. However, it won't do that every time, and SYNs are retransmitted, so unless you always drop all of the legitimate SYNs, then you'll still be able to make connections. : > If you have a queue length of 1000, and can deliver 500 bogus SYNs in : > the 200mS that it takes, then you'd have a 60% chance of not dropping : > the good SYN (1 - .999 ^ 500 = 60%). If you can deliver 1000 bogus : > SYNs in that time, then the deterministic method would have a 0% : > chance, and the random method would have a 35% chance of surviving (if : > bc on my machine for .999^1000 can be trusted). : : You're assuming that a SYN is going to spend all of that 200mSec in the : queue (remember, I provided that number as an upper-bound for the purposes : of discussion, not as an axiomatic interval symtomatic of catastrophic : failure!). No. I don't think that I am. I'm saying that if, for a given time, you have a queue length of 1000 and you get 500 packets, then you have a 60% chance of survival. If you have 1000 packets come in, then you'll have a 35% chance of survival. : 1000 bogus SYNs in 200mSec is something that takes of the : order of 200kbps of bandwidth to support. Each SYN is 40 bytes long (IP + TCP headers). You'd need 5000 of these packets in a second, which is 200kBps or 2000kbps. This is faster than a T1 line right now, which is 1500kbps. : On a 200kbps channel, I'd be : willing to wager that the vast majority of your SYNs are answered with : SYN-ACKs (and thereby removed from this equation) within 50mSec or less, : meaning that the oldest SYN would almost always be one with an unreachable : return address. Agreed. If the above rate is going full throttle, then in 50ms, you'd have 250 packets delivered, which gives the chances of dropping a legitimate SYN in a sea of bogons about 25%. Your method wouldn't drop at all, in this case. : Keep in mind that this is making the attacker work a lot harder too - : He only needs to send about five packets per second to keep queues : congested under present implementations! Agreed! : By thowing away the oldest SYN, you're effectively extending the present : algorithm by adding a variable-length timeout instead of a 75-second timeout. True. However, you may also make that timeout too short in the case where SYNs are coming in much faster than your queue can hold (say for a 100 slot queue under similar conidtions). : The size of that variable-length timeout is dependent on the demand : being placed on your system. That dynamicism is biased to provide newly : arrived legitimate SYNs a fair chance of survival before they're treated : as bogus and thrown away due to high demand. Given that you'll end up : throwing away good SYNs if you're short on resources anyway, I'd rather : select which good ones get chucked on a best-efforts basis instead of a : random basis. I'm not sure I'd call it best effort. It would be chucked on a strict FIFO basis, which has different statitical properites than one where a random one is discarded. At least according to the queueing theory class I took years ago in college. : By throwing away a random SYN, you're effectively treating all packets : as bogus until proven otherwise, *AND* creating the possibility that you'll : randomly boot 'em up the arse before they've had a chance to provide you : with that proof. That is exactly correct. Trust no one. If there are too many of em, get rid of a few. The legitimate ones will be back. The bogons won't and good riddens. : Sure, if you look at a single packet in isolation after : declaring that "all things are equal" then you'll probably give an : individual packet a better chance of survival; But that approach ignores : the fact that all things *aren't* equal, and that it is highly likely : that the oldest packet in the SYN queue is there because the SYN-ACK has : been dropped by a router because its destination is unreachable. If you have queue lenghts long enough to make sure that under load the legitimate ones don't become the oldest one on the queue. : You're implementation is also computationally expensive: Random numbers : aren't cheap, and I wouldn't like to spend too much of my life calculating : thousands of them per second... "good enough" random numbers are likely cheap enough. A few adds and shifts. Most fast machines can do that quickly. They are poor for cryptographic purposes, but reasonably well suited for chosing victums. Since they change so quickly, it would be hard to time arrival times such that the random number generate is a factor. Thinking about it some more, I think that a queue length of 1000 may be way too big. The search time on it would be horrible if not hashed. I think that someone with a more recent exposure to queuing theory might be able to do a better job at a theoretical analysis of this problem and might show which is better. At this point, however, we are in agreement on the following: Some discarding of packets will help, not hurt, the situation. Further tests may be needed under fire to determine which will be better. The best method of discarding is a matter of debate and likely would make a good candidate for research. Warner From owner-freebsd-security Fri Sep 20 00:15:40 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA23490 for security-outgoing; Fri, 20 Sep 1996 00:15:40 -0700 (PDT) Received: from scapa.cs.ualberta.ca (root@scapa.cs.ualberta.ca [129.128.4.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA23463 for ; Fri, 20 Sep 1996 00:15:37 -0700 (PDT) Received: from ve6kik by scapa.cs.ualberta.ca with UUCP id <13073-12700>; Fri, 20 Sep 1996 01:15:32 -0600 Received: by ve6kik.ampr.ab.ca (Smail3.1.28.1 #5) id m0v3zkF-000O4mC; Fri, 20 Sep 96 01:11 WET DST Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id XAA14970 for ; Thu, 19 Sep 1996 23:55:11 -0600 (MDT) Date: Thu, 19 Sep 1996 23:55:10 -0600 (MDT) From: Marc Slemko To: freebsd-security@FreeBSD.ORG Subject: Re: Could use a favor In-Reply-To: <199609180747.RAA07256@al.imforei.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 18 Sep 1996, Peter Childs wrote: > Consider the situation where you are using a machine running > freebsd on a machine as part of your firewall. You only want selective > packets to be passed. If your machine boots up with a default > policy of "let everything through" then for the time between your > interface being initilized/configured and your rules being > enforced/entered you've just made a large hole in your security. Aside from the possible race condition there, which can be avoided by careful ordering of bootup configuration, there is also the idea of safest possible mode of failure. Consider the case where someone accidently messes up the firewall rules, or the utility used to manage them gets messed up. Do you prefer that no traffic is let through your firewall until it is fixed, or that all traffic is let through until it is fixed? From owner-freebsd-security Fri Sep 20 01:42:05 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA06711 for security-outgoing; Fri, 20 Sep 1996 01:42:05 -0700 (PDT) Received: from phaedrus.uchicago.edu (phaedrus.uchicago.edu [128.135.21.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA06679 for ; Fri, 20 Sep 1996 01:42:01 -0700 (PDT) Received: from phaedrus.uchicago.edu (localhost [127.0.0.1]) by phaedrus.uchicago.edu (8.7.5/8.7.3) with ESMTP id DAA03778; Fri, 20 Sep 1996 03:43:17 GMT Message-Id: <199609200343.DAA03778@phaedrus.uchicago.edu> To: newton@communica.com.au (Mark Newton) cc: imp@village.org (Warner Losh), security@freebsd.org Subject: Re: comments on the SYN attack In-reply-to: Your message of "Fri, 20 Sep 1996 15:12:43 +0930." <9609200542.AA11812@communica.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3774.843190996.1@phaedrus.uchicago.edu> Date: Fri, 20 Sep 1996 03:43:17 +0000 From: steve farrell Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk in the statement to freebsd list, paul traina said that shortening your timeout on the SYN too much ran the risk of the adminstrator 'doing the attackers job', since this itself will deny service. the suggested killing of SYNs based on age has the effect of dynamically scaling the timeout based upon the load (attack) situation (in fact, i think the aging algorithm would probably be much easier to implement by simply reducing the timeout based on the size of the queue!) if both of these statements are true, then isn't this method *guaranteed* to actually make the attackers job easier? (just by means of attacking, the target OS (effectively) cuts back its timeout. you can't argue that you'd put a lower-bound on the timeout, of course, becuase obviously at the point this lower-bound is hit you're guaranteed to be in a full-queue, unserviceable state, so it really doesn't matter what you do then.) but what about randomly? first: i think randomly killing packets is a fallacy since the longer the packet remains on the queue, the more likely it will get killed (if 1% of packets are killed every second, then the packet which hangs out on the queue 100secs will probably get killed, whereas the one that hangs out 10secs will probably not.) -- so if there is an effective difference, it's odd and probably not very important. conclusion: i think both proposals can be logically reduced into shortening the timeout on the queue, and as has been pointed out, shortening the timeout too much does the attackers job for him. in the worst case, these proposals could lead to an amplification situation where the attack is the signal, and the servers proposed tcpip modifications respond to that signal with another measure further increasing the denial of service. either cure is (by my late-night analysis) worse than the disease. so now the real question: which is worse =) my bet goes with the random-killer: one of the assumptions for the randomness is that 'bad' and 'good' SYNs will get equal treatment and killed in equal proportions. if this is the case, then it will do nothing to the ratio of 'good' to 'bad' packets in the queue, so i think this could be considered a no-gainer. in contrast, the timeout-based method would probably kill more 'bad' packets then 'good' ones, assuming that 'good' ones are generally fulfilled in a timely manner. furthermore, with the random method, there will be an additional small reduction in service to 'good' connections since some are granted premature deaths. some late-night thoughts from: steve farrell >Warner Losh wrote: > > > However, my gut tells me that the random victum will give better > > behavior than the shoot the oldest one. > >Oh? I believe that statistically speaking the two cases provide an >identical chance of booting away an individual packet: Consider that the >deterministic case is precisely equivalent to the random case with a >pseudorandom number generator which just coincidentally always returns >the identity of the oldest SYN packet... > >[ indeed, if you're looking at an individual packet, the present > implementation is identical as well: it just "randomly" drops the > "youngest" packet on the queue, ie: the one that has arrived at a > time when there aren't enough resources to keep it ] > > > If you have a queue length of 1000, and can deliver 500 bogus SYNs in > > the 200mS that it takes, then you'd have a 60% chance of not dropping > > the good SYN (1 - .999 ^ 500 = 60%). If you can deliver 1000 bogus > > SYNs in that time, then the deterministic method would have a 0% > > chance, and the random method would have a 35% chance of surviving (if > > bc on my machine for .999^1000 can be trusted). > >You're assuming that a SYN is going to spend all of that 200mSec in the >queue (remember, I provided that number as an upper-bound for the purposes >of discussion, not as an axiomatic interval symtomatic of catastrophic >failure!). 1000 bogus SYNs in 200mSec is something that takes of the >order of 200kbps of bandwidth to support. On a 200kbps channel, I'd be >willing to wager that the vast majority of your SYNs are answered with >SYN-ACKs (and thereby removed from this equation) within 50mSec or less, >meaning that the oldest SYN would almost always be one with an unreachable >return address. > >Keep in mind that this is making the attacker work a lot harder too - >He only needs to send about five packets per second to keep queues >congested under present implementations! > >By thowing away the oldest SYN, you're effectively extending the present >algorithm by adding a variable-length timeout instead of a 75-second timeout. >The size of that variable-length timeout is dependent on the demand >being placed on your system. That dynamicism is biased to provide newly >arrived legitimate SYNs a fair chance of survival before they're treated >as bogus and thrown away due to high demand. Given that you'll end up >throwing away good SYNs if you're short on resources anyway, I'd rather >select which good ones get chucked on a best-efforts basis instead of a >random basis. > >The only way you'd throw away a good SYN is if its source address was >on the other side of a link that was so slow that it was indistinguishible >from an unreachable host for the purposes of SYN-warfare. At that point, >it becomes the "best choice" for droppage for a (relatively) good reason, >rather than a random impulse. > >By throwing away a random SYN, you're effectively treating all packets >as bogus until proven otherwise, *AND* creating the possibility that you'll >randomly boot 'em up the arse before they've had a chance to provide you >with that proof. Sure, if you look at a single packet in isolation after >declaring that "all things are equal" then you'll probably give an >individual packet a better chance of survival; But that approach ignores >the fact that all things *aren't* equal, and that it is highly likely >that the oldest packet in the SYN queue is there because the SYN-ACK has >been dropped by a router because its destination is unreachable. > > > Given that SYNs are > > retransmitted, then you'd be able to get after 2 tries on the average. > >I'd suggest that the deterministic solution would let you in on 1 try. > >Usually :-) > >You're implementation is also computationally expensive: Random numbers >aren't cheap, and I wouldn't like to spend too much of my life calculating >thousands of them per second... > > - mark > >--- >Mark Newton Email: newton@communica.com.au >Systems Engineer Phone: +61-8-8373-2523 >Communica Systems WWW: http://www.communica.com.au > From owner-freebsd-security Fri Sep 20 09:15:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA19057 for security-outgoing; Fri, 20 Sep 1996 09:15:58 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA19031 for ; Fri, 20 Sep 1996 09:15:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.6/8.6.10) with SMTP id JAA08430; Fri, 20 Sep 1996 09:15:51 -0700 (PDT) From: Cy Schubert - ITSD Open Systems Group Message-Id: <199609201615.JAA08430@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Andy Schenck cc: freebsd-security@freebsd.org Subject: Re: pwd_mkdb and NIS In-reply-to: Your message of "Thu, 19 Sep 96 18:57:15 PDT." Date: Fri, 20 Sep 96 09:15:50 -0700 X-Mts: smtp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Thu, 19 Sep 1996, Cy Schubert wrote: > > > The only way I could have "botched" the upgrade was to periodically > > enter df -k in the "holographic shell". That probably loaded > > libc.so and a number of other libraries from the chrooted filesystem. > > > > I am curious as to how you could load the dynamically linked libraries > while executing a statically linked binary. It was me. I just finished writing a paragraph to explain to you how my .profile is set up and how it may have been loaded when I remembered that my .profile was replaced during the upgard. I'm rather emberrased to admit that I loaded bash in the holographic shell causing the problem. My apologies for wasting your time. > > Andy > Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Fri Sep 20 09:26:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA23158 for security-outgoing; Fri, 20 Sep 1996 09:26:21 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA23090 for ; Fri, 20 Sep 1996 09:26:07 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id KAA29669; Fri, 20 Sep 1996 10:25:42 -0600 (MDT) Message-Id: <199609201625.KAA29669@rover.village.org> To: steve farrell Subject: Re: comments on the SYN attack Cc: newton@communica.com.au (Mark Newton), security@freebsd.org In-reply-to: Your message of "Fri, 20 Sep 1996 03:43:17 -0000." <199609200343.DAA03778@phaedrus.uchicago.edu> References: <199609200343.DAA03778@phaedrus.uchicago.edu> Date: Fri, 20 Sep 1996 10:25:42 -0600 From: Warner Losh Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199609200343.DAA03778@phaedrus.uchicago.edu> steve farrell writes: : but what about randomly? first: i think randomly killing packets : is a fallacy since the longer the packet remains on the queue, the : more likely it will get killed (if 1% of packets are killed every : second, then the packet which hangs out on the queue 100secs will : probably get killed, whereas the one that hangs out 10secs will : probably not.) -- so if there is an effective difference, it's : odd and probably not very important. If you have a queue of 100, say, and 1 gets killed a second, then the chances of survival for 100 seconds is about 36%. The chances of survival for 10s is 91%. Given that you'll likely have more than one valid SYN in even a 10s window, at least one of them should generally survive. Initial SYNs are retransmitted, so dropping one of them isn't bad as long as you don't drop them all. Keep in mind that randomly killing a packet produces results that aren't intitive sometimes. I would have expected after 100 hits, the chances of a packet surviving were near 0 (like .0000something). Turns out to be about 1 in 3, which is a very different property than FIFO. In a FIFO killing model after 100s you are dead no matter what, so it is a hard limit. It that property useful? My gut tells me that it is, but I have no hard evidence to back this up at this time. The goal is to make the system more useful and make the attacker harder to starve legitimate connections. Ideally, one would want to reduce it to a ping flood attack (it eats only bandwidth). Warner From owner-freebsd-security Fri Sep 20 09:36:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA26793 for security-outgoing; Fri, 20 Sep 1996 09:36:20 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA26768 for ; Fri, 20 Sep 1996 09:36:15 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.Beta.4/8.8.Beta.3) with SMTP id LAA28739; Fri, 20 Sep 1996 11:36:09 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Fri, 20 Sep 96 11:36 CDT Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.Beta.3/8.8.Beta.3) id LAA14219; Fri, 20 Sep 1996 11:36:08 -0500 (CDT) From: Karl Denninger Message-Id: <199609201636.LAA14219@Jupiter.Mcs.Net> Subject: Re: comments on the SYN attack To: imp@village.org (Warner Losh) Date: Fri, 20 Sep 1996 11:36:08 -0500 (CDT) Cc: security@freebsd.org In-Reply-To: <199609200409.WAA25123@rover.village.org> from "Warner Losh" at Sep 19, 96 10:09:54 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > : (4) How do we fix this once and for all? > : > : Unfortunately, this is a vulnerability in the design of TCP. A fair > : number of protocol experts are musing over ways to fix this. > : The best solutions to date require an authenticated IP layer. > : > : There are changes being made to the Internet infrastructure which will > : make it more difficult for attackers to operate without detection, but > : for the time being, without a change to the TCP protocol or the addition > : of authentication below TCP, there simply is no "solution" that isn't as > : bad as the problem itself, despite the claims of "anti-SYN" product > : vendors. > > Question: Wouldn't randomly dropping SYN packets when the above limits > are triggered "help" the problem. The reasoning is that if I'm trying > to establish a connection, I'll send a SYN packet, then another and so > on until I time out. Since I'm generating multiple good SYN packets, > losing one or two of them won't hurt. However, dropping bogus SYN > packets under heavy load will help to reduce that load somewhat. The > longer the queue is, the more likely it should be that a SYN gets > dropped. > > Much like the RED routers that were recently researched by LNLL. > > Or has this been considered and a flaw been found? > > Generally, one can't prevent the SYN packets from arriving at your > machine for serves one provides to the net. However, one can be > intellegent about what one listens to, can't one? > > Warner Let's examine this idea: You have a listen queue of size "N". If your queue is full and you receive another packet, you drop the *OLDEST* (first in) connection and add the new SYN. The effect of this is that the *probability* will favor the "bad guy" getting dropped, and the legitimate users will likely get serviced *before* they get all the way to the end of the queue -- assuming it is a reasonable length (say, 200-300 entries). Worst case is that a legit connection will have to be retried (SYN reissued) if it *does* get dropped, but given a reasonable RTT to the other end this just shouldn't happen (the ack to the other and and the ack back to you should happen first). This is "radiation hard" against anyone with even a reasonably good net connection; if they guy is behind a DS-3 you're honked regardless (unless you make the queue positively huge, and that has other bad effects since the tcbs are forward-linked in a list and must be searched sequentially) but even in that case recovery is instantaneous when the flooding stops. Vernon proposed this and has tested something similar. I am looking into the code changes (they look somewhat ugly due to the possibility of locking requirements) to do this in FreeBSD. Its not a 5 minute patch, but it certainly looks like something I can cook up and test if nobody else has in a few hours. I ALSO understand there may be a version of this patch floating around already for FreeBSd. If it exists, I'd like to at least look at and validate it in our labs. Thanks. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-security Fri Sep 20 09:55:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA03862 for security-outgoing; Fri, 20 Sep 1996 09:55:18 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA03833 for ; Fri, 20 Sep 1996 09:55:14 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id KAA00661; Fri, 20 Sep 1996 10:55:08 -0600 (MDT) Message-Id: <199609201655.KAA00661@rover.village.org> To: Karl Denninger Subject: Re: comments on the SYN attack Cc: security@freebsd.org In-reply-to: Your message of "Fri, 20 Sep 1996 11:36:08 CDT." <199609201636.LAA14219@Jupiter.Mcs.Net> References: <199609201636.LAA14219@Jupiter.Mcs.Net> Date: Fri, 20 Sep 1996 10:55:07 -0600 From: Warner Losh Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199609201636.LAA14219@Jupiter.Mcs.Net> Karl Denninger writes: : The effect of this is that the *probability* will favor the "bad guy" : getting dropped, and the legitimate users will likely get serviced *before* : they get all the way to the end of the queue -- assuming it is a reasonable : length (say, 200-300 entries). I agree with that. My assertion, that I still need to test, is randomly dropping does an even better job. However, dropping the oldest is likely good enough for everyone that isn't sitting on a DS3 and isn't worried about an internal SYN attack over, say, a 100Mb ethernet. I'm in the process of upgrading from about august 20ish -current to a sept 20 -current (not that all parts of the 51 part ctm and the 45 part ctm have arrived). I'll have to try the syn bomber at 10Mb ethernet speeds against some patches that have floated accross that discard the oldest one (which are for OpenBSD, but I'm checking both oses :-). I'll then modify them to be random discard and see if that helps, hurts or is about the same. That will likely take a little while to complete, since I'm multiplexing with other things as well and since my machine takes 8-10 hours to do a make world. Warner From owner-freebsd-security Fri Sep 20 23:57:05 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA05385 for security-outgoing; Fri, 20 Sep 1996 23:57:05 -0700 (PDT) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA05344 for ; Fri, 20 Sep 1996 23:56:59 -0700 (PDT) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id QAA10625; Sat, 21 Sep 1996 16:23:39 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA03742; Sat, 21 Sep 96 16:22:46 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9609210652.AA03742@communica.com.au> Subject: Re: comments on the SYN attack To: imp@village.org (Warner Losh) Date: Sat, 21 Sep 1996 16:22:46 +0930 (CST) Cc: spfarrel@midway.uchicago.edu, newton@communica.com.au, security@FreeBSD.ORG In-Reply-To: <199609201625.KAA29669@rover.village.org> from "Warner Losh" at Sep 20, 96 10:25:42 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: > : but what about randomly? first: i think randomly killing packets > : is a fallacy since the longer the packet remains on the queue, the > : more likely it will get killed (if 1% of packets are killed every > : second, then the packet which hangs out on the queue 100secs will > : probably get killed, whereas the one that hangs out 10secs will > : probably not.) -- so if there is an effective difference, it's > : odd and probably not very important. > > If you have a queue of 100, say, and 1 gets killed a second, then the > chances of survival for 100 seconds is about 36%. The chances of > survival for 10s is 91%. Given that you'll likely have more than one > valid SYN in even a 10s window, at least one of them should generally > survive. Initial SYNs are retransmitted, so dropping one of them > isn't bad as long as you don't drop them all. This is so bogus, Warner. You keep putting forward lots of good reasons which make the random approach better, but you neglect the fact that those exact, same factors make the deterministic approach better too. At the end of the day, both approaches collapse to exactly the same thing: They both have the OS saying, "Hmm - A SYN has just arrived and I don't have space for it, so I'll nuke an existing SYN to make room." The difference between the two is that the random method makes no effort to bias itself in favour of newly arrived packets which haven't had a chance to be SYN-ACK'ed yet. The two approaches are so similar that if you were to implement the random approach, I could transform it into the deterministic approach by merely *changing your random number generator routine*. Algorithmically speaking, we're talking about *EXACTLY* the same thing; you're just leaving out the bias whiich favours the algorithm towards new arrivals. > FIFO. In a FIFO killing model after 100s you are dead no matter > what, so it is a hard limit. This is a good thing, Warner: With your model, there is a 36% chance that a bad SYN will still be in the queue after 100s, according to your figures. :-) - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Sat Sep 21 05:21:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA18329 for security-outgoing; Sat, 21 Sep 1996 05:21:36 -0700 (PDT) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA18257 for ; Sat, 21 Sep 1996 05:21:29 -0700 (PDT) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.7.6/8.6.12) with ESMTP id FAA06633; Sat, 21 Sep 1996 05:20:38 -0700 (PDT) Message-Id: <199609211220.FAA06633@ns.frihet.com> X-Mailer: exmh version 1.6.7 5/3/96 Reply-To: "David E. Tweten" To: newton@communica.com.au (Mark Newton) cc: imp@village.org (Warner Losh), spfarrel@midway.uchicago.edu, security@freebsd.org Subject: Re: comments on the SYN attack Date: Sat, 21 Sep 1996 05:20:38 -0700 From: "David E. Tweten" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk newton@communica.com.au said: >This is so bogus, Warner. Before you put down someone else's idea it is best to *do your homework*. In this case, it's a little probability. Werner has a good idea, if not a world beater. See below. >The difference between the two is that the random method makes no >effort to bias itself in favour of newly arrived packets which >haven't had a chance to be SYN-ACK'ed yet. This is exactly why making room on a stocastic basis is superior to doing it on a deterministic basis. Newly arrived packets are likely to be flood packets. Besides, the problem isn't to identify and eliminate flood packets, because identification seems to be impossible. The problem is to give legitimate SYN packets a fighting chance to survive long enough to be paired with an ACK. >The two approaches are so similar that if you were to implement the >random approach, I could transform it into the deterministic approach > by merely *changing your random number generator routine* [to one that >isn't random]. This is hogwash. A "stocastic" process which is driven deterministically isn't stocastic. What follows is my version of the homework: Make the following definitions, useful later on: f the number of flood SYNs per the amount of time from legitimate SYN/ACK sent to legitimate ACK received n the number of pending SYN storage slots p probability of a legitimate SYN lasting long enough to be paired with an ACK c probability of completing a successful connection t tries needed to get a connection with probability, c Make a variety of simplifying assumptions: 1. Flood SYNs arrive at a constant rate. 2. The required interval between SYN/ACK and ACK is constant for all attempted connections. 3. The time between SYN arrival and SYN/ACK transmission is zero. First we calculate p, for the deterministic algorithm. It throws away the oldest unacknowleged SYN when it needs to make room for a new SYN. Stated in C, it is: p = f < n ? 1.0 : 0.0; Next, calculate the same value for the stocastic algorithm. It chooses a SYN at random to discard when it needs to make room for a new one. p = pow((n - 1) / n, f); Finally, the value for t is dependent upon p, however obtained. t = ceil(log(c) / log(1 - p)); Now, lets run some numbers. Assume Werner's value of n, 100. The column labeled "det" gives p for the deterministic algorithm, and the column labeled "stat" gives p for Werner's stocastic algorithm. The column labeled "t for c >= 0.5" applies only to the stocastic algorithm. For the deterministic algorithm, t is either 1 or not defined. f det stat t for c >= 0.5 ------- ------- -------- -------------- < 68 1.0 > 0.5 1 68 1.0 0.5 1 99 1.0 0.37 2 100 0.0 0.37 2 200 0.0 0.13 5 400 0.0 0.02 39 800 0.0 0.0003 2151 Obviously, the deterministic algorithm fails to be able to establish a legitimate connection when the flood rate is high enough to flush legitimate SYNs just before their coresponding ACKs arrive. Werner's stocastic algorithm will allow a legitimate connection to be made after a reasonable number of retries for twice the flood rate that can be survived by the deterministic algorithm, though sadly not for ten times the flood rate. I leave checking of my simple derivations and running the numbers for other values of n as "an exercise to the reader". The moral seems to be, "Do your homework before ridiculing someone else's idea." Oh, and "Nice idea, Werner." -- David E. Tweten | 2047-bit PGP Key fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. From owner-freebsd-security Sat Sep 21 05:34:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA25839 for security-outgoing; Sat, 21 Sep 1996 05:34:01 -0700 (PDT) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA25770 for ; Sat, 21 Sep 1996 05:33:54 -0700 (PDT) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.7.6/8.6.12) with ESMTP id FAA06705; Sat, 21 Sep 1996 05:33:18 -0700 (PDT) Message-Id: <199609211233.FAA06705@ns.frihet.com> X-Mailer: exmh version 1.6.7 5/3/96 Reply-To: "David E. Tweten" To: newton@communica.com.au (Mark Newton) cc: imp@village.org (Warner Losh), spfarrel@midway.uchicago.edu, security@freebsd.org Subject: Re: comments on the SYN attack Date: Sat, 21 Sep 1996 05:33:18 -0700 From: "David E. Tweten" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Another good way to avoid embarassment is to check the spelling of people's names before sending e-mail. Nice idea, Warner. -- David E. Tweten | 2047-bit PGP Key fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. From owner-freebsd-security Sat Sep 21 09:29:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA17276 for security-outgoing; Sat, 21 Sep 1996 09:29:41 -0700 (PDT) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA16174 for ; Sat, 21 Sep 1996 09:28:10 -0700 (PDT) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id BAA11536; Sun, 22 Sep 1996 01:54:46 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA11272; Sun, 22 Sep 96 01:54:12 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9609211624.AA11272@communica.com.au> Subject: Re: comments on the SYN attack To: tweten@frihet.com Date: Sun, 22 Sep 1996 01:54:12 +0930 (CST) Cc: newton@communica.com.au, imp@village.org, spfarrel@midway.uchicago.edu, security@freebsd.org In-Reply-To: <199609211220.FAA06633@ns.frihet.com> from "David E. Tweten" at Sep 21, 96 05:20:38 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David E. Tweten wrote: > >This is so bogus, Warner. > > Before you put down someone else's idea it is best to *do your homework*. "Putting down someone else's good idea" was not what I was doing, sunshine. The sentence following the one you quoted *should* have provided fairly conclusive evidence of the fact that in that instance I was putting down the way that he was discussing the merits of the two proposals. To whit, pooh-poohing the behaviour of the deterministic approach in several instances by comparing it against the behaviour of the random approach *under different operating conditions*. > >The difference between the two is that the random method makes no > >effort to bias itself in favour of newly arrived packets which > >haven't had a chance to be SYN-ACK'ed yet. > > This is exactly why making room on a stocastic basis is superior to doing > it on a deterministic basis. Newly arrived packets are likely to be flood > packets. Sheer weight of numbers would suggest that yes, this is a correct assumption. When you look at the other end of the queue, however, you will find that the deterministic approach will ensure that it's highly likely that the oldest packets are illegitimate, and for sufficently large queue sizes, the chances of a packet at the end of the queue being illegitimate are quite small. The number of SYNs which can arrive at any system from any source is dependent on the bandwidth of the link between the system and the source; At the worst case, it's dependent on the speed of the pipe connecting the site under attack to that site's ISP. That places a nice upper bound on the maximum necessary queue size needed to guarantee a probability of 1.0 for acceptance of incoming legitimate SYNs. Granted, the present algorithm does too, but the present algorithm has a timeout which is far too long -- Excessively long, given the speed of today's backbone connections. > Besides, the problem isn't to identify and eliminate flood > packets, because identification seems to be impossible. The problem is to > give legitimate SYN packets a fighting chance to survive long enough to be > paired with an ACK. Bingo. Yet you favour an algorithm which has a built-in 1/n probability of nuking a SYN as soon as it arrives in the queue? > >The two approaches are so similar that if you were to implement the > >random approach, I could transform it into the deterministic approach > > by merely *changing your random number generator routine* [to one that > >isn't random]. > > This is hogwash. A "stocastic" process which is driven deterministically > isn't stocastic. It is not hogwash at all: If Warner were to implement the random algorithm by making use of a function call which randomly selected a packet for termination by returning its index into the SYN table, it could be transformed into the deterministic approach by changing that function call to one that simply returned whatever number represented the size of the queue (assuming the highest index is the oldest packet; return 0 in the converse case). Both approaches are fundamentally identical but for this detail. Warner uses a random number generator, I use "return n;" (n-1 really :-) where n is the queue size. Either way, both algorithms are selecting a single packet for termination in the event that the queue is full, they only differ in their selection method. > Now, lets run some numbers. No, let's not: You've left out some details in your derivations. You've calculated p, and defined it as "the probability of a legitimate SYN lasting long enough to be paired with an ACK." But according to my reading of your derivation, what you've *actually* calculated is the probability of ANY single SYN in the queue lasting long enough to be paired with an ACK (assuming the time interval for the pairing of a legitimate SYN with its ACK is constant), without factoring in any allowance for whether that SYN is legitimate. This is an important distinction, because in a flooding situation the vast majority of the packets in the queue will be illegitimate, and the random approach makes no effort to swing the proportions of good SYNs to bad in any positive direction (indeed, by definition that proportion will remain constant if the random number generator delivers a flat probability distribution). > f det stat t for c >= 0.5 > ------- ------- -------- -------------- > < 68 1.0 > 0.5 1 > 68 1.0 0.5 1 > 99 1.0 0.37 2 > 100 0.0 0.37 2 > 200 0.0 0.13 5 > 400 0.0 0.02 39 > 800 0.0 0.0003 2151 You've defined f as the number of flood SYNs which arrive between a SYN and its ACK. That would suggest that the probability that a given packet is legitimate is close to 1/f, or 1% for f=100 (I say "close to" because you should have defined f as "the number of SYNs which arrive betwen a SYN and its ACK," rather than the number of flood SYNs. With the definition duely corrected, the probability that a given packet in the input stream is legit is precisely 1/f, but even that doesn't accurately reflect the same probability for the domain representing the SYN queue in the kernel, because as SYNs are ACKed they are removed from the queue; This reduces the probability that any given packet in the queue is legitimate, but only marginally. Thus I conclude that that probability is *approximately* 1/f). What this says is that for n=100, the probability that any individual SYN will still be in the queue is 0.37 at f=100. In flooding conditions the number of legitimate SYNs will be vanishingly small compared to illegitimate SYNs -- Or 1% for f=100. Under those conditions, about 1% of that p=0.37 value would represent the probability that the packet that's hung around in the queue for long enough to be ACKed is legitimate, and hence the probability that a connection is successful is similarly vanishingly small. Your odds don't sound that great anymore. I'd go as far to say that at f=100 and n=100 *both* algorithms fall in a screaming heap, so perhaps n needs to be increased, yes? And if you increase n, you provide a larger range of f for which the deterministic value of p is 1, yes? And either way, n doesn't need to be increased by anywhere near the values to which it'd need to be increased under the present implementation. [ this is not surprising: Remember that both approaches are special cases of the same algorithm, ie: "my queue is full so I'll have to pick something to toss out to make room." Given that the only difference between the two is the selection method, it makes sense that they would both catastrophically fail at about the same point. ] Furthermore, with n=100, for values of f smaller than 100 the deterministic approach gives a probability of 1 for successful connection, whereas the non-deterministic case actually goes ahead and nukes a small proportion of legitimate SYNs. Indeed, if we redefine p as the probability that any SYN will have survivied for the time needed to ACK a legitimate SYN (which seems to be what you've actually calculated) then at f=99 the non-deterministic approach provides a 63% chance that a SYN *won't* survive that long (whether it's legitimate or not). While the deterministic approach says p=1.0, the non-deterministic approach gives a (63% x 1/f) chance of connection failure on the first try. Yuk, eh? But that's ok: I understand that you americans have become comfortable with the concept of friendly fire :-) [ as you can see, the chance of that friendly fire is quite small; once again, this is to be expected on the grounds that the two approaches are so similar. If it weren't for the (albeit small) chance of friendly fire, the similarities we're dealing with here would leave me wondering why we were having this discussion at all ] So, what have we found? Well, you've provided me with a statistical analysis of the algorithms which says exactly what I told Warner when we started this discussion, namely that the deterministic approach will work *perfectly* until the rate of incoming SYNs is sufficient to cause the queue to overflow in the time between the reception of a SYN and the reception of its ACK, that the non-deterministic approach contains a built-in chance of destroying an otherwise perfectly good SYN, and that the two approaches are more or less identical (allowing for small statistical variations). No further conclusions can be drawn from your presentation -- I have to wonder why you bothered. > Obviously, the deterministic algorithm fails to be able to establish a > legitimate connection when the flood rate is high enough to flush > legitimate SYNs just before their coresponding ACKs arrive. Like I said to Warner when we started this, if you consider the survival chances of any individual packet, then yes, the random approach seems better. But you can't consider a packet in isolation (no packet is an island? :-). Your 37% survival chance for a good SYN also allows bad SYNs a 37% fighting chance at the expense of the good SYNs which are, sadly, vastly outnumbered. Or, to put it another way, every time a SYN arrives from the net, the random method has a built-in 1/n probability of nuking a good SYN to make room. Oops. The random method will permit you to increase f by a few percentage points over the ceiling imposed by the deterministic method and still get the odd connection through. However, it does this at a cost: It provides the small but finite chance of allowing a legitimate connection attempt to time out unanswered. Conversely, the deterministic method guarantees perfect behaviour for all values of f up to n and no further. By sacrificing a very small margin at the high-end of f, you buy yourself reliability wins for all values of f less than or equal to n. That, IMHO, makes the deterministic method superior. > I leave checking of my simple derivations and running the numbers for other > values of n as "an exercise to the reader". The moral seems to be, "Do > your homework before ridiculing someone else's idea." I repeat, ridiculing Warner's idea is not something I set out to do, and upon rereading I can only come to the conclusion that it isn't something I actually went ahead and did either. If Warner has felt ridiculed by what I had to say then I can only apologise; If you feel that I ridiculed Warner and he believes otherwise then I can only suggest that you pull your head in. The world has enough thin-skinned brittle people already without some people making themselves thin-skinned and brittle on someone else's behalf. > Another good way to avoid embarassment is to check the spelling of people's > names before sending e-mail. Oh, a spelling flame. How trite. - mark [ driving vi about 30 keystrokes ahead over a link with an rtt of ~4.5 seconds, and suffering from an appalling lack of any urge to make any corrections to anything. ] --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Sat Sep 21 09:33:32 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA20062 for security-outgoing; Sat, 21 Sep 1996 09:33:32 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA18014 for ; Sat, 21 Sep 1996 09:30:47 -0700 (PDT) Received: from rover.village.org by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0v4Uwv-0008veC; Sat, 21 Sep 96 09:30 PDT Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id KAA10482; Sat, 21 Sep 1996 10:27:09 -0600 (MDT) Message-Id: <199609211627.KAA10482@rover.village.org> To: "David E. Tweten" Subject: Re: comments on the SYN attack Cc: newton@communica.com.au (Mark Newton), spfarrel@midway.uchicago.edu, security@freebsd.org In-reply-to: Your message of "Sat, 21 Sep 1996 05:20:38 PDT." <199609211220.FAA06633@ns.frihet.com> References: <199609211220.FAA06633@ns.frihet.com> Date: Sat, 21 Sep 1996 10:27:08 -0600 From: Warner Losh Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199609211220.FAA06633@ns.frihet.com> "David E. Tweten" writes: : Oh, and "Nice idea, Werner." The idea was stolen, by me and at least one other that I've since seen[*], from another context. Van Jacobson and his team over at LBLL proposed something called a RED gateway. As the queue length increases, random packets are dropped in increasing likelyhood. Evidentally, this provides the right kind of feedback to TCP to have it slow down. I was merely wondering if this might be applied well to the problem at hand. The random method is different than the discard the oldest, and may or may not work better.... Tests are underway right now. Warner [*] Since I made my original suggestion, I have seen mail from Robert Morris forwarded to another list suggesting the same thing, but more coherently. From owner-freebsd-security Sat Sep 21 14:25:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA26796 for security-outgoing; Sat, 21 Sep 1996 14:25:56 -0700 (PDT) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA26241 for ; Sat, 21 Sep 1996 14:24:31 -0700 (PDT) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.7.6/8.6.12) with ESMTP id OAA08641; Sat, 21 Sep 1996 14:23:04 -0700 (PDT) Message-Id: <199609212123.OAA08641@ns.frihet.com> X-Mailer: exmh version 1.6.7 5/3/96 Reply-To: "David E. Tweten" To: newton@communica.com.au (Mark Newton) cc: imp@village.org, spfarrel@midway.uchicago.edu, security@freebsd.org Subject: Re: comments on the SYN attack Date: Sat, 21 Sep 1996 14:23:04 -0700 From: "David E. Tweten" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk newton@communica.com.au said: >"Putting down someone else's good idea" was not what I was doing, >sunshine. Well, I am a native Californian, so this may be appropriate. It's at least a lot better than "Tweety Bird," the awful nickname I had to endure through grammar school. But, let us move onward to more serious things. Mark quotes me: >>Newly arrived packets are likely to be flood packets. and then continues: >When you look at the other end of the queue, however, you will find >that the deterministic approach will ensure that it's highly likely >that the oldest packets are illegitimate, and for sufficiently large >queue sizes, the chances of a packet at the end of the queue being >illegitimate are quite small. Your assumption here is at the heart of your disagreement with Warner, and of late, with me. If Warner will indulge me the privilege I'll say that neither of us is particularly concerned about the case you cite above, where "the queue" is long enough or the phony SYNs are arriving slowly enough that there is any difference in concentration of legitimate SYNs between the ends of "the queue." Our lack of concern is based upon several reasons: 1. If "the queue" is that long, there's no flood. By any definition I understand, a "flood" denial of service attack is one that generates a high enough arrival rate of requests for service that a some legitimate requests cannot be served. That's a high enough rate that the deterministic algorithm will flush any SYN before it has had time to collect an ACK. 2. Even in the high flow, but no flood case when there is enough time in queue under the deterministic algorithm for a legitimate SYN's ACK to arrive, the stochastic algorithm also works well enough to be acceptable. If you re-examine my table of numbers, you'll see that at the deterministic algorithm's limit, only two tries will get the stochastic algorithm a better than 50% chance of a successful connection. If you don't like those odds, two more tries will close the gap to certainty by half again, and so on. Lower flows require fewer tries. TCP does retry failed connections; the stochastic algorithm harnesses that fact to cover for it where it is weak. 3. Since no way has been found yet, even probabilistically, to distinguish between a legitimate SYN and a flood attack SYN, I want all SYNs to have a decent chance of surviving long enough to collect an ACK. That's right, phony SYNs included. I don't care if some flood attack SYN sits in my queue for a month, so long as I stand a decent chance of completing legitimate connections in spite of its presence. So what's the upshot? At high-flow-but-no-flood, both stochastic and deterministic methods work. The deterministic method works first try, and the stochastic method may require a retry from TCP (think big -- maybe two or three). For moderate flood conditions, the deterministic algorithm fails utterly. The deterministic method continues to work. For the particular queue size I chose for running the numbers, a "moderate flood" condition seemed to cover two to four times the fake SYN arrival rate that would cause the deterministic method to fail. Sadly, it seems that even the stochastic method isn't as resistant to flood as one would like. I would have liked to see it withstand ten times the arrival rate that will drop the deterministic method with the same "queue" size. Under the conditions I chose for running the numbers, the required retry count had begun to skyrocket by the time the flood got eight times as strong as was required to kill the deterministic algorithm. There is still some hope. The stochastic algorithm's flood resistance compared to the deterministic algorithm is dependent upon the size of the "queue." To see that, compare the formulas for "p" and note that a "queue" size of 1 makes both deterministic and stochastic algorithms completely non-resistant to flood. Maybe a larger but still reasonable "queue" could make it ten times as resistant to flood as the deterministic algorithm. I'll leave that exploration to someone else. >You've calculated p, and defined it as "the probability of a >legitimate SYN lasting long enough to be paired with an ACK." But >according to my reading of your derivation, what you've *actually* >calculated is the probability of ANY single SYN in the queue lasting >long enough to be paired with an ACK (assuming the time interval for >the pairing of a legitimate SYN with its ACK is constant), without >factoring in any allowance for whether that SYN is legitimate. Exactly. My crystal ball is a little clouded when it comes to distinguishing between flood SYNs and legitimate SYNs. I'm therefore an equal opportunity SYN storer. I'm quite literally blind to their differences. If you think about it for a moment, I belive you'll conclude that under flood conditions, so are you. >This is an important distinction, because in a flooding situation the >vast majority of the packets in the queue will be illegitimate, and >the random approach makes no effort to swing the proportions of good >SYNs to bad in any positive direction (indeed, by definition that >proportion will remain constant if the random number generator >delivers a flat probability distribution). I think I can make an argument that the proportion of "good SYNs" to "bad" will be even smaller than you say under the stochastic method, and that's good. Since we have a flood condition, the deterministic method cannot match any "good SYN" with its just-arrived "ACK", so connection completion is not available to it as a method of removing "good SYNs" from the queue. Therefore, the density of good SYNs in the queue is identical to the arrival density. Under the stochastic algorithm, the occasional good SYN lasts, by chance, long enough to be matched with its ACK and to be removed. That provides a mechanism other than random shooting for the stochastic algorithm to remove a SYN from the queue. Since this second method is highly biased toward removing good SYNs, the concentration of good SYNs in the queue under flood conditions should actually be smaller for the stochastic algorithm than for the deterministic algorithm. >You've defined f as the number of flood SYNs which arrive between a >SYN and its ACK. That would suggest that the probability that a >given packet is legitimate is close to 1/f, or 1% for f=100 With apologies to analog engineers, 1/f has nothing to do with the probability that a given SYN is legitimate. Going back to my definition of f, 1/f would be the inter-arrival time of flood SYNs, expressed in time units of the SYN/ACK to ACK delay for legitimate SYNs. Not a very useful number to your argument. >I say "close to" because you should have defined f as "the number of SYNs >which arrive between a SYN and its ACK," rather than the number of flood >SYNs. You are due this point. I should have listed as another of my simplifying assumptions that under flood conditions, flood SYNs so outnumber each legitimate SYN that the sum of the number of good SYNs and the number of flood SYNs in any sample is approximately equal to the number of flood SYNs in the sample. >With the definition duely corrected, the probability that a given >packet in the input stream is legit is precisely 1/f, but even that >doesn't accurately reflect the same probability for the domain >representing the SYN queue in the kernel, because as SYNs are ACKed >they are removed from the queue; This reduces the probability that >any given packet in the queue is legitimate, but only marginally. >Thus I conclude that that probability is *approximately* 1/f). As I pointed out a couple of paragraphs ago, 1/f has nothing to do with your argument. >What this says is that for n=100, the probability that any individual >SYN will still be in the queue is 0.37 at f=100. Right so far. >In flooding conditions the number of legitimate SYNs will be >vanishingly small compared to illegitimate SYNs -- Or 1% for f=100. As I pointed out above, you cannot derive your 1% from f. For the sake of argument, I'll accept 1% as a good engineering approximation of "vanishingly small". >Under those conditions, about 1% of that p=0.37 value would represent >the probability that the packet that's hung around in the queue for >long enough to be ACKed is legitimate, and hence the probability that >a connection is successful is similarly vanishingly small. Wrong. You are saying that the event of interest is composed of two statistically independent events. First is the event that an arriving SYN is legitimate (which you assign a probability of 0.1), and second is the event that an arriving SYN survives for the assumed-to-be fixed time it would take for an ACK to arrive, were it legitimate. Instead, the event of interest is the one you listed earlier, "that any individual SYN will still be in the queue" after a SYN/ACK to ACK delay. The person trying to make a legitimate connection has performed a deterministic act. He has put a legitimate SYN into the queue. He did not submit a legitimate SYN with 1% probability and submit an attacking SYN with 99% probability. We care about the probability that it will still be there when the ACK arrives. We don't care what the probability was that it was legitimate. It's 1.0 and that's boring. >Your odds don't sound that great anymore. 37% per retry still sounds fine to me. Even your incorrect 0.0037% per retry is better than the 0% probability of success for the deterministic algorithm. I'll grant that 0.0037%, while better than 0%, is not good enough. Fortunately, it's also wrong. >I'd go as far to say that at f=100 and n=100 *both* algorithms fall >in a screaming heap, so perhaps n needs to be increased, yes? I wouldn't go that far, and no, not for the stochastic algorithm. I'd say that at f=100 and n=100, the deterministic algorithm "falls in a screaming heap" and the stochastic algorithm begins to fail soft. By taking advantage of TCP retries, the stochastic algorithm lasts until f gets up to 800 or so, as we continue to hold n at 100. >And if you increase n, you provide a larger range of f for which the >deterministic value of p is 1, yes? Yes. You also provide a larger range of f for which the stochastic algorithm survives after the deterministic algorithm has failed. That range might even get larger faster than n. See above. >And either way, n doesn't need to be increased by anywhere near the >values to which it'd need to be increased under the present >implementation. Agreed. >While the deterministic approach says p=1.0, the non-deterministic >approach gives a (63% x 1/f) chance of connection failure on the >first try. Yuk, eh? Leaving aside your 1/f misconception, there's no yuk at all. The 63% probability of failure on the first try, under conditions in which the deterministic algorithm is just barely surviving, turns into 40% after the second try, 25% after the third, 10% after the fifth, etc. Since rcmd(3) (as a randomly chosen example :-) tries five times, 10% is a more interesting probability of failure to consider than is 63%. Furthermore, if you increase f by one, the deterministic algorithm just simply fails, irrespective of number of retries, and the stochastic algorithm hangs in at a failure rate around 10% after five tries. >But that's ok: I understand that you americans have become >comfortable with the concept of friendly fire :-) Sometimes the most embarrassing friendly fire comes from your own weapon, while aimed at your own foot. Do get well soon. :-) >you've provided me with a statistical analysis of the algorithms >which says exactly what I told Warner when we started this >discussion, namely that the deterministic approach will work >*perfectly* until the rate of incoming SYNs is sufficient to cause >the queue to overflow in the time between the reception of a SYN and >the reception of its ACK, that the non-deterministic approach >contains a built-in chance of destroying an otherwise perfectly good >SYN ... Right so far. >... and that the two approaches are more or less identical (allowing >for small statistical variations). Bang! Too bad about that foot! The part you keep missing is that built-in retries can compensate for the stochastic algorithm's failures, and that nothing can save the deterministic algorithm when f equals or exceeds n. >I have to wonder why you bothered. I bothered in a so-far unsuccessful attempt to make you understand the previous paragraph. Yes, I have better things to do, but sometimes I just cant resist a juicy windmill. >The random method will permit you to increase f by a few percentage >points over the ceiling imposed by the deterministic method and still >get the odd connection through. In the case for which I ran the numbers, those "few percentage points" were an additional 300 percentage points, after which 50% of rcmd() connections would still get through. Quite a few percentage points, I'd say. Initially quoting me, Mark continued: >>Another good way to avoid embarassment is to check the spelling of >>people's names before sending e-mail. >Oh, a spelling flame. >How trite. Actually, I was castigating myself for having misspelled Warner's name as "Werner". While I was at it, I should have checked the spelling of "embarrassment" too. Sigh. And, ever so slightly out of order: >The world has enough thin-skinned brittle people already ... Indeed. -- David E. Tweten | 2047-bit PGP Key fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. From owner-freebsd-security Sat Sep 21 14:53:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA09782 for security-outgoing; Sat, 21 Sep 1996 14:53:56 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA08579 for ; Sat, 21 Sep 1996 14:51:11 -0700 (PDT) Received: from rover.village.org by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0v4Zx4-0008saC; Sat, 21 Sep 96 14:51 PDT Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with ESMTP id PAA02996; Sat, 21 Sep 1996 15:43:35 -0600 (MDT) Message-Id: <199609212143.PAA02996@rover.village.org> To: "David E. Tweten" Subject: Re: comments on the SYN attack Cc: newton@communica.com.au (Mark Newton), spfarrel@midway.uchicago.edu, security@freebsd.org In-reply-to: Your message of "Sat, 21 Sep 1996 14:23:04 PDT." <199609212123.OAA08641@ns.frihet.com> References: <199609212123.OAA08641@ns.frihet.com> Date: Sat, 21 Sep 1996 15:43:35 -0600 From: Warner Losh Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk One thing I'd like to add. While out killing the Thistles that have seen fit to invade my front yard, and thinking about some mail that Theo de Raat had sent me on this topic... As I'm sure most people know, the TCP three way handshake is: In the diagram below, B is establishing a connection to A, and each line represents the packets that arrive at each machine: A B SYN SYN ACK ACK ACK Now, when the BSD kernel gets an SYN, and sends out the SYN ACK, it creates some state in its memory. The remote side gets the SYN ACK and considers the connection to be ESTABLISHED after sending the ACK ACK packet. When A gets the ACK ACK packet, it too thinks the connection is established. The problem that I came up with was as follows (with thanks to Theo for pointing it out): B sends the SYN, A sends the SYN ACK and places the insipient connection in a queue. B gets the SYN ACK and considers the connection open. B's socket then desides it wants to read, so it tries to do so. As we will see later, the read will fail sometimes. Meanwhile, A is under SYN attack. A is forced to discard the insipient connection to B due to a resource shortage. Then, the ACK ACK comes in. The code in FreeBSD will now say, "Hmmm, where did I put that pcb... Can't find it, send a RST." and the connection will reset, if I read the code correctly. This will cause B to die with a connection reset by peer, which many protocols won't retry. This makes discarding needlessly very expensive, and would likely tip the balance away from the randomly killing something in the insipient queue. Generally, one shouldn't drop these things unless you absolutely must. That's likely the desiding factor. I think that if you get the point of discarding stuff, then you are in trouble anyway. It would be nice to not discard it too soon. Also, if the rates are such that you know you can handle it, then I think the determanistic would be better. If they are absolutely hammering the snot out of you, then the random one would be better because the service is so crappy anyway that a little flakiness is better than no possibility of a connection. Bottom line: You don't want to drop these things if you can help it... Maybe I've missed something here, so please carefully read this and let me know what it is. Finally, I've not been offended by the discourse so far, but it is starting to sound flamelike in many respects. The general tone is degenerating somewhat, so unless there are striking new developments, I think I've said all I can and the rest will be quibbling over silly points that we really agree on... Warner From owner-freebsd-security Sat Sep 21 15:34:14 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA24703 for security-outgoing; Sat, 21 Sep 1996 15:34:14 -0700 (PDT) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA24681 for ; Sat, 21 Sep 1996 15:34:06 -0700 (PDT) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id PAA21650; Sat, 21 Sep 1996 15:34:10 -0700 From: Nathan Lawson Message-Id: <199609212234.PAA21650@kdat.calpoly.edu> Subject: SYN flood attack thoughts To: freebsd-security@freebsd.org Date: Sat, 21 Sep 1996 15:34:10 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After listening to both sides of the argument (drop oldest and drop a random packet), I think the best alternative is a combination of the two, perhaps triggered by different high-water marks. In this method, when the queue reached a certain mark (say 75% of the total size), the system would begin dropping all the oldest packets, starting at the end of the queue. If this really was a malicious flood, the queue would soon reach its second high-water mark (say 95%), random drop would begin. I see this as giving the best of both worlds. At normal to slightly congested traffic amounts, only the oldest (and therefore most likely to be invalid) packets are dropped. But when connection requests approach the second level, all packets must be considered guilty until proven innocent. The only disadvantage I see here is that the algorithm is slightly more complicated. I think the final solution is dependent on the number of malicious packets one can expect versus the number of slow connections that the server will see. In medium load conditions, dropping the oldest packet seems to give the most advantage to legitimate packets, while in high load conditions, the legitimate sender is usually the one with the lowest number of connection requests. I have not tested this hybrid algorithm yet, but would appreciate input. -- Nate Lawson "There are a thousand hacking at the branches of CPE Senior evil to one who is striking at the root." CSL Admin -- Henry David Thoreau, 'Walden', 1854 From owner-freebsd-security Sat Sep 21 19:54:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04980 for security-outgoing; Sat, 21 Sep 1996 19:54:21 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA04924 for ; Sat, 21 Sep 1996 19:54:12 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id EAA01434 for security@freebsd.org; Sun, 22 Sep 1996 04:56:41 +0200 (MET DST) From: Mikael Karpberg Message-Id: <199609220256.EAA01434@ocean.campus.luth.se> Subject: Re: comments on the SYN attack To: security@freebsd.org Date: Sun, 22 Sep 1996 04:56:40 +0200 (MET DST) In-Reply-To: <199609212143.PAA02996@rover.village.org> from Warner Losh at "Sep 21, 96 03:43:35 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello... Hello! Not saying I know anything about this at all, really, but I have to get a word in here... > I think that if you get the point of discarding stuff, then you are in > trouble anyway. It would be nice to not discard it too soon. Also, > if the rates are such that you know you can handle it, then I think > the determanistic would be better. If they are absolutely hammering > the snot out of you, then the random one would be better because the > service is so crappy anyway that a little flakiness is better than no > possibility of a connection. Wouldn't it then simply be easy to implement both, instead of arguing? Make the random_packet_to_kill function return a biased random, like: I assume older packets have lower numbers... tmp = "SYNs per sec" * "Time to hold SYNs before normal drop" tmp = tmp / "queuelength" return "oldest SYN" + (tmp * "random number") Which should be tuned to that it drops the oldest ones, until the SYN load starts to go above a certain limit, compaired with the queue length, and the the random value would kick in and become more and more random the higher the load. Then we would get the benefits of both methods. I have no knowledge about anything involved here, but it seem to make logical sense in my mind. Or am I completely off here? > Bottom line: You don't want to drop these things if you can help > it... Ofcourse... if the bandwidth of the net between you and the attacker only makes it possible for him to flood you with a certain rate, simply enlarging the queue so that you can hold (floodrate+some)*timeout entries, would make the attack only have two effects: Stealing some bandwidth and memory. If you have enough memory to spare a bit, and your net connection is not too dameged by it, you could sustain such an attack until the attacker gets bored, without it costing you much. The problem arises when you can't hold a queue big enough. Right? Just $.02 from me. /Mikael From owner-freebsd-security Sat Sep 21 21:49:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA02159 for security-outgoing; Sat, 21 Sep 1996 21:49:11 -0700 (PDT) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA02109 for ; Sat, 21 Sep 1996 21:49:06 -0700 (PDT) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id OAA12648; Sun, 22 Sep 1996 14:15:47 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA20940; Sun, 22 Sep 96 14:15:13 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9609220445.AA20940@communica.com.au> Subject: Re: SYN flood attack thoughts To: nlawson@kdat.csc.calpoly.edu (Nathan Lawson) Date: Sun, 22 Sep 1996 14:15:12 +0930 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: <199609212234.PAA21650@kdat.calpoly.edu> from "Nathan Lawson" at Sep 21, 96 03:34:10 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nathan Lawson wrote: > I have not tested this hybrid algorithm yet, but would appreciate input. Input, eh? Would a few million SYNs do? :-) - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Sat Sep 21 22:24:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA26610 for security-outgoing; Sat, 21 Sep 1996 22:24:58 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA26581 for ; Sat, 21 Sep 1996 22:24:54 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id OAA19828; Sun, 22 Sep 1996 14:54:45 +0930 From: Michael Smith Message-Id: <199609220524.OAA19828@genesis.atrad.adelaide.edu.au> Subject: Re: SYN flood attack thoughts To: newton@communica.com.au (Mark Newton) Date: Sun, 22 Sep 1996 14:54:44 +0930 (CST) Cc: nlawson@kdat.csc.calpoly.edu, freebsd-security@freebsd.org In-Reply-To: <9609220445.AA20940@communica.com.au> from "Mark Newton" at Sep 22, 96 02:15:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark Newton stands accused of saying: > > Nathan Lawson wrote: > > > I have not tested this hybrid algorithm yet, but would appreciate input. > > Input, eh? Would a few million SYNs do? :-) It's amusing that while all this pissing and moaning was going on, John Capo did the testing required to actually prove or disprove the various theories, and someone (PST?) committed the results. > Mark Newton Email: newton@communica.com.au -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[