From owner-freebsd-security Mon Sep 2 11:06:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA04710 for security-outgoing; Mon, 2 Sep 1996 11:06:56 -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 LAA04705 for ; Mon, 2 Sep 1996 11:06:54 -0700 (PDT) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id LAA00360 for freebsd-security@freebsd.org; Mon, 2 Sep 1996 11:06:57 -0700 From: Nathan Lawson Message-Id: <199609021806.LAA00360@kdat.calpoly.edu> Subject: user_wrapper available for testing To: freebsd-security@freebsd.org Date: Mon, 2 Sep 1996 11:06:56 -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 Jian-Da Li said: > The user_wrapper is a user-based access control which allows each > user to have personal tcp_wrapper-like access control. > > You can get it from : > ftp://freebsd.csie.nctu.edu.tw/pub/jdli/collect/user_wrapper.tgz > > ====== From README ======== > > * Related files: (mode should set to 0600) > ~/.hosts.allow : allow rules > ~/.hosts.deny : deny rules > ~/.refused-log : refused log > > * Keywords currently available: > 1. login : control telnetd/rlogind or anything use /usr/bin/login > 2. ftpd > 3. rshd > 4. su : allow who can su to your account Sounds like an interesting package. But before it is merged into FreeBSD, I'd like people to make sure of at least the following: * Does it open any config files as root? Users can read root-owned files then. * Does it write to .refused-log as anything other than the user that owns the directory? What about SysV systems where people can chown files/dirs to others? Does it make sure that the user owns .refused-log and it's not a symlink before writing? * Does it properly switch uid's (including saved id) before parsing the user's hosts.{allow,deny} files? If not, users can execute binaries as root using the twist= functionality of tcp_wrappers. * Does it properly close all open descriptors before parsing the files? If not, it is possible that the twist= functionality could be used to read and/or write to various files. * If it does drop privileges, is it at a time when the user can use ptrace to attach to the executable and modify it? In short, what I am asking is has anybody really thought about what the security implications of this are? Tcp_wrappers was designed with the assumption that it would be managed by root, and that any attacks would be coming from the network (as it does not depend on any user-owned or accessible files). Making it a user-level and user-managed program opens up a lot more security concerns than I stated above. Let's be sure it's been evaluated properly before adding this neat feature. Thanks, -- 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 Tue Sep 3 02:37:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA16168 for security-outgoing; Tue, 3 Sep 1996 02:37:54 -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 CAA16161 for ; Tue, 3 Sep 1996 02:37:48 -0700 (PDT) Received: (from smap@localhost) by relay.philips.nl (8.6.9/8.6.9-950414) id LAA06540; Tue, 3 Sep 1996 11:36:39 +0200 Received: from unknown(192.26.173.32) by ns.philips.nl via smap (V1.3+ESMTP) with ESMTP id sma006472; Tue Sep 3 11:36:11 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 LAA10604; Tue, 3 Sep 1996 11:38:58 +0200 Received: (from guido@localhost) by spooky.lss.cp.philips.com (8.6.10/8.6.10-0.991c-08Nov95) id LAA15662; Tue, 3 Sep 1996 11:36:08 +0200 From: Guido van Rooij Message-Id: <199609030936.LAA15662@spooky.lss.cp.philips.com> Subject: Re: user_wrapper available for testing To: nlawson@kdat.csc.calpoly.edu (Nathan Lawson) Date: Tue, 3 Sep 1996 11:36:08 +0200 (MET DST) Cc: freebsd-security@freebsd.org Reply-To: Guido.vanRooij@nl.cis.philips.com In-Reply-To: <199609021806.LAA00360@kdat.calpoly.edu> from Nathan Lawson at "Sep 2, 96 11:06:56 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 Nathan Lawson wrote: > > Sounds like an interesting package. But before it is merged into FreeBSD, > I'd like people to make sure of at least the following: > Who gave you the idea that this will be merged into FreeBSd? -Guido From owner-freebsd-security Thu Sep 5 11:12:22 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA06739 for security-outgoing; Thu, 5 Sep 1996 11:12:22 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA06729 for ; Thu, 5 Sep 1996 11:12:20 -0700 (PDT) Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id LAA19958 for ; Thu, 5 Sep 1996 11:12:18 -0700 (PDT) Received: from hnv.com by relay2.UU.NET with SMTP (peer crosschecked as: burn.hnv.com [198.137.222.2]) id QQbfwq08571; Thu, 5 Sep 1996 14:10:30 -0400 (EDT) Message-Id: Date: Thu, 5 Sep 96 13:10:25 CDT From: cjk@hnv.com (Chris Kunath) To: FreeBSD-security@FreeBSD.org Subject: tripwire-1.2 port? Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Has anyone successfully compiled or ported tripwire-1.2 to FreeBSD? Am busy blowing it up when using the "conf-bsd.h" defines, ditto for conf-linux.h and conf-bsdi.h. I know about mtree for FreeBSD, but was looking for a standard "file-verification" method across FreeBSD and Sun SPARC platforms. cjk@hnv.com From owner-freebsd-security Thu Sep 5 15:40:22 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA25962 for security-outgoing; Thu, 5 Sep 1996 15:40:22 -0700 (PDT) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA25870 for ; Thu, 5 Sep 1996 15:39:41 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id AAA28213 for ; Fri, 6 Sep 1996 00:39:01 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id AAA18666 for FreeBSD-security@FreeBSD.ORG; Fri, 6 Sep 1996 00:38:25 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Beta.1/keltia-uucp-2.9) id AAA29716; Fri, 6 Sep 1996 00:30:15 +0200 (MET DST) Message-Id: <199609052230.AAA29716@keltia.freenix.fr> Date: Fri, 6 Sep 1996 00:30:15 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: FreeBSD-security@freebsd.org Subject: Re: tripwire-1.2 port? In-Reply-To: ; from Chris Kunath on Sep 5, 1996 13:10:25 -0500 References: X-Mailer: Mutt 0.41 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2415 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Chris Kunath: > Has anyone successfully compiled or ported tripwire-1.2 > to FreeBSD? Yes, I did on a couple of firewalls for former clients. I don't remember what I changed in the source but it wasn't much. > I know about mtree for FreeBSD, but was looking for a standard > "file-verification" method across FreeBSD and Sun SPARC platforms. Tripwire is the one. As soon as I get my new work machine (P6/150) I'll compile Tripwire on it anyway :-) -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #20: Fri Aug 30 23:00:02 MET DST 1996 From owner-freebsd-security Thu Sep 5 16:59:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA29305 for security-outgoing; Thu, 5 Sep 1996 16:59:42 -0700 (PDT) Received: from darkwing.pacific.net.sg (darkwing.pacific.net.sg [203.120.89.89]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA29298 for ; Thu, 5 Sep 1996 16:59:38 -0700 (PDT) Received: (qmail-queue invoked from smtpd); 5 Sep 1996 23:57:50 -0000 Received: from darkwing.pacific.net.sg (203.120.89.89) by darkwing.pacific.net.sg with SMTP; 5 Sep 1996 23:57:50 -0000 Date: Fri, 6 Sep 1996 07:57:50 +0800 (SST) From: Ng Pheng Siong To: Chris Kunath cc: FreeBSD-security@FreeBSD.org Subject: Re: tripwire-1.2 port? 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 Thu, 5 Sep 1996, Chris Kunath wrote: > Has anyone successfully compiled or ported tripwire-1.2 > to FreeBSD? Yes. -- Ng Pheng Siong * Finger for PGP key. Pacific Internet Pte Ltd * Singapore Fast, secure, cheap. Pick two. From owner-freebsd-security Sat Sep 7 08:44:24 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA13089 for security-outgoing; Sat, 7 Sep 1996 08:44:24 -0700 (PDT) Received: from io.org (io.org [198.133.36.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA13084 for ; Sat, 7 Sep 1996 08:44:20 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by io.org (8.6.12/8.6.12) with SMTP id LAA21334; Sat, 7 Sep 1996 11:44:18 -0400 Date: Sat, 7 Sep 1996 11:44:18 -0400 (EDT) From: Brian Tao To: FREEBSD-SECURITY-L , BUGTRAQ@NETSPACE.ORG Subject: Panix Attack: synflooding and source routing? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wouldn't turning off source-routing on your border router alleviate most of this problem? It won't help if you have someone synflooding a port from within your network, but at least it would prevent outside attacks. Or is this a "one-way" attack (i.e., a return route to host is not needed)? -- 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" ---------- Forwarded message ---------- >Return-Path: >To: mcarr >From: Peter Kelk/Kelk >Date: 7 Sep 96 9:19:38 >Subject: Important Warning >X-Lotus-Type: Corresp > >Mike, I received this from my brother in law in New York City. Thought it >might be useful for Ican. > > > W E L C O M E T O P A N I X > > >Panix under attack! (alexis) Sat Sep 7 01:43:27 1996 > > Friday evening, starting at around 5:45, all of Panix's main mail > hosts were attacked from a site somewhere on the internet. I have been > trying to deal with this problem ever since, and the attack is still > happening at this time. > > The attacker is forging random source addresses on his packets, so > there is no way to find his/her location. There is also no way to screen > out those packets with a simple router filter. > > This is probably the most deadly type of denial-of-service attack > possible. There is no easy or quick way of dealing with it. If it continues > into Saturday we will start working on kernel modifications to try to > absorb the damage (since there's absolutely no way to avoid it). This > however will not be an easy job and it could take days to get done (and > get done right). > > For those who are IP hackers, the problem is that we're being flooded > with SYNs from random IP addresses on our smtp ports. We are getting > on average 150 packets per second (50 per host). > > We are not the only site being attacked in this way. I know of one > other site that is being attacked in an identical manner right now, > and I know of three others that have been attacked in the last two weeks. > I hope that this means that the attacker is merely playing malicious > games, and will soon tire of molesting our site. If that is the case, > mail will come back up as soon as the attack ends. But if the attacker > is really interested in damaging Panix specifically, the attack may > *never* stop and service won't be restored until we can write kernel > modifications. > > We fully understand how terrible this is. The really scary part is that > *no* site on the net is immune. No site can unilaterally do *Anything* > to protect or defend itself against this sort of attack. Only through > cooperation between the major (and minor!) providers can this sort of > problem be eliminated, and the large providers so far aren't showing > any interest in the problem (we are a Sprint customer, and tonight when > we asked for help tracing the packets back at least to their entry point > in Sprint's net, Sprint basically told us to drop dead). > > In case anyone's wondering, I spoke to CERT (In particular, Jim Ellis) > for over 90 minutes tonight. Yes, Panix and CERT have buried the hatchet. > CERT agrees with us about the gravity of the situation. They also see > no immediate solution to the problem. > > I'll try and post information about this to panix.announce, and deal with > discussion in panix.upgrade (for want of a better place), but that > won't happen immediately since I'm working on several things at once > right now trying to deal with this problem. > >-rw-r--r-- 1 sondheim 2201 Sep 7 02:13 /net/u/6/s/sondheim/.plan > 3:05am up 5 days, 10:36, 26 users, load average: 3.61, 2.83, 2.57 >User tty login@ idle JCPU PCPU what >sondheim ttyp4 3:03am 1 1 w sondheim > >k:8> df >Filesystem kbytes used avail capacity Mounted on >/dev/sd0a 10007 6891 2116 77% / >/dev/sd0g 111447 93571 6732 93% /usr >/dev/sd0d 102919 30624 62004 33% /var >/dev/sd0f 1268446 994176 147426 87% /net/u/9 >/dev/sd0h 1268446 1011007 130595 89% /net/u/10 >/dev/sd1d 937406 784194 59472 93% /net/u/18 >/dev/sd1e 937406 767067 76599 91% /net/u/19 >panix.nfs100.access.net:/net/local > 834461 706933 44082 94% /net/local >panix.nfs100.access.net:/net/u/1 > 2086894 1821103 57102 97% /net/u/1 >panix.nfs100.access.net:/net/u/2 > 2086894 1718086 160119 91% /net/u/2 >panix.nfs100.access.net:/net/u/3 > 1056788 899125 51985 95% /net/u/3 >panix2.nfs100.access.net:/net/u/4 > 1340910 1132383 74436 94% /net/u/4 >panix2.nfs100.access.net:/net/u/5 > 1245240 1077317 43399 96% /net/u/5 >panix.nfs100.access.net:/net/u/7 > 907494 772511 44234 95% /net/u/7 >panix.nfs100.access.net:/net/u/8 > 484607 365949 70198 84% /net/u/8 >panix.nfs100.access.net:/net/u/11 > 2042490 1488109 350132 81% /net/u/11 >panix2.nfs100.access.net:/net/u/13 > 1245240 1076936 43780 96% /net/u/13 >panix2.nfs100.access.net:/net/u/14 > 1245240 1052421 68295 94% /net/u/14 >panix2.nfs100.access.net:/net/u/15 > 1340910 1106245 100574 92% /net/u/15 >panix2.nfs100.access.net:/net/u/16 > 1340910 1113781 93038 92% /net/u/16 >panix2.nfs100.access.net:/net/u/17 > 953687 702839 155480 82% /net/u/17 >panix.nfs100.access.net:/net/archive > 2042490 1488109 350132 81% /net/archive >panix.nfs100.access.net:/var > 236383 142836 69909 67% /hosts/panix/var >news1.nfs100.access.net:/var > 968836 480625 439769 52% /hosts/news1/var >news1.nfs100.access.net:/var/spool/news > 2097151 361292 1534669 19% /var/spool/news >news1.nfs100.access.net:/var/spool/newsdb > 968836 551768 368626 60% /var/spool/newsdb >news1.nfs100.access.net:/net/hlocal/news > 970732 331460 590735 36% /hosts/news1/news >news1.nfs100.access.net:/var/spool/news2 > 2097151 730725 1164215 39% /var/spool/news2 >news2.panix.com:/e 628543 40141 525548 7% /hosts/news/e >news2.panix.com:/f 1036526 25659 907215 3% /hosts/news/f >web6.panix.com:/usr/local/net_public/httpd/htdocs > 2097151 324571 1577218 17% /net/w/panixdocs >web1.panix.com:/usr/local/net_public/httpd/htdocs/corp-dirs > 2097151 375851 1553220 19% /net/w/1 >web6.panix.com:/usr/local/net_public/httpd/htdocs/userdirs > 2097151 324571 1577218 17% /net/w/userdirs >web1.panix.com:/usr/local/net_public/httpd/httpd-logs > 380876 271361 90471 75% /net/httpd_logs/web1 >web6.panix.com:/usr/local/net_public/httpd/httpd-logs > 2097151 324571 1577218 17% /net/httpd_logs/web6 >web1.panix.com:/usr/local/net_public/httpd/data > 380876 271361 90471 75% /net/data/web1 >web6.panix.com:/usr/local/net_public/httpd/data > 2097151 324571 1577218 17% /net/data/web6 >198.7.0.64:/usr/local/ftp/corp-dirs > 380876 271361 90471 75% /net/ftp/1 >198.7.0.65:/var/ftp/corp-dirs > 853494 25109 785710 3% /net/ftp/2 >198.7.0.66:/var/ftp/corp-dirs > 844708 89718 712754 11% /net/ftp/3 >198.7.0.70:/usr/local/ftp/corp-dirs > 842053 80814 719136 10% /net/ftp/7 >198.7.0.71:/var/ftp/corp-dirs > 805037 5684 759101 1% /net/ftp/8 >panix4.nfs100.access.net:/holding > 609094 401462 146723 73% /mnt >/dev/sd0e 1271134 993586 150435 87% /net/u/6 >k:9> > > From owner-freebsd-security Sat Sep 7 10:20:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA20012 for security-outgoing; Sat, 7 Sep 1996 10:20:45 -0700 (PDT) Received: from silver.sms.fi (root@silver.sms.fi [194.111.122.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA20002 for ; Sat, 7 Sep 1996 10:20:40 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.7.5/8.6.9) id UAA20430; Sat, 7 Sep 1996 20:20:21 +0300 (EET DST) Date: Sat, 7 Sep 1996 20:20:21 +0300 (EET DST) Message-Id: <199609071720.UAA20430@silver.sms.fi> From: Petri Helenius To: Brian Tao Cc: FREEBSD-SECURITY-L , BUGTRAQ@NETSPACE.ORG Subject: Panix Attack: synflooding and source routing? In-Reply-To: References: Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Lukekaapas uusin villitys, alkaa menn{ aika rumaksi, imho... Pete > ---------- Forwarded message ---------- > >Return-Path: > >To: mcarr > >From: Peter Kelk/Kelk > >Date: 7 Sep 96 9:19:38 > >Subject: Important Warning > >X-Lotus-Type: Corresp > > > >Mike, I received this from my brother in law in New York City. Thought it > >might be useful for Ican. > > > > > > W E L C O M E T O P A N I X > > > > > >Panix under attack! (alexis) Sat Sep 7 01:43:27 1996 > > > > Friday evening, starting at around 5:45, all of Panix's main mail > > hosts were attacked from a site somewhere on the internet. I have been > > trying to deal with this problem ever since, and the attack is still > > happening at this time. > > > > The attacker is forging random source addresses on his packets, so > > there is no way to find his/her location. There is also no way to screen > > out those packets with a simple router filter. > > > > This is probably the most deadly type of denial-of-service attack > > possible. There is no easy or quick way of dealing with it. If it continues > > into Saturday we will start working on kernel modifications to try to > > absorb the damage (since there's absolutely no way to avoid it). This > > however will not be an easy job and it could take days to get done (and > > get done right). > > > > For those who are IP hackers, the problem is that we're being flooded > > with SYNs from random IP addresses on our smtp ports. We are getting > > on average 150 packets per second (50 per host). > > > > We are not the only site being attacked in this way. I know of one > > other site that is being attacked in an identical manner right now, > > and I know of three others that have been attacked in the last two weeks. > > I hope that this means that the attacker is merely playing malicious > > games, and will soon tire of molesting our site. If that is the case, > > mail will come back up as soon as the attack ends. But if the attacker > > is really interested in damaging Panix specifically, the attack may > > *never* stop and service won't be restored until we can write kernel > > modifications. > > > > We fully understand how terrible this is. The really scary part is that > > *no* site on the net is immune. No site can unilaterally do *Anything* > > to protect or defend itself against this sort of attack. Only through > > cooperation between the major (and minor!) providers can this sort of > > problem be eliminated, and the large providers so far aren't showing > > any interest in the problem (we are a Sprint customer, and tonight when > > we asked for help tracing the packets back at least to their entry point > > in Sprint's net, Sprint basically told us to drop dead). > > > > In case anyone's wondering, I spoke to CERT (In particular, Jim Ellis) > > for over 90 minutes tonight. Yes, Panix and CERT have buried the hatchet. > > CERT agrees with us about the gravity of the situation. They also see > > no immediate solution to the problem. > > > > I'll try and post information about this to panix.announce, and deal with > > discussion in panix.upgrade (for want of a better place), but that > > won't happen immediately since I'm working on several things at once > > right now trying to deal with this problem. > > > >-rw-r--r-- 1 sondheim 2201 Sep 7 02:13 /net/u/6/s/sondheim/.plan > > 3:05am up 5 days, 10:36, 26 users, load average: 3.61, 2.83, 2.57 > >User tty login@ idle JCPU PCPU what > >sondheim ttyp4 3:03am 1 1 w sondheim > > > >k:8> df > >Filesystem kbytes used avail capacity Mounted on > >/dev/sd0a 10007 6891 2116 77% / > >/dev/sd0g 111447 93571 6732 93% /usr > >/dev/sd0d 102919 30624 62004 33% /var > >/dev/sd0f 1268446 994176 147426 87% /net/u/9 > >/dev/sd0h 1268446 1011007 130595 89% /net/u/10 > >/dev/sd1d 937406 784194 59472 93% /net/u/18 > >/dev/sd1e 937406 767067 76599 91% /net/u/19 > >panix.nfs100.access.net:/net/local > > 834461 706933 44082 94% /net/local > >panix.nfs100.access.net:/net/u/1 > > 2086894 1821103 57102 97% /net/u/1 > >panix.nfs100.access.net:/net/u/2 > > 2086894 1718086 160119 91% /net/u/2 > >panix.nfs100.access.net:/net/u/3 > > 1056788 899125 51985 95% /net/u/3 > >panix2.nfs100.access.net:/net/u/4 > > 1340910 1132383 74436 94% /net/u/4 > >panix2.nfs100.access.net:/net/u/5 > > 1245240 1077317 43399 96% /net/u/5 > >panix.nfs100.access.net:/net/u/7 > > 907494 772511 44234 95% /net/u/7 > >panix.nfs100.access.net:/net/u/8 > > 484607 365949 70198 84% /net/u/8 > >panix.nfs100.access.net:/net/u/11 > > 2042490 1488109 350132 81% /net/u/11 > >panix2.nfs100.access.net:/net/u/13 > > 1245240 1076936 43780 96% /net/u/13 > >panix2.nfs100.access.net:/net/u/14 > > 1245240 1052421 68295 94% /net/u/14 > >panix2.nfs100.access.net:/net/u/15 > > 1340910 1106245 100574 92% /net/u/15 > >panix2.nfs100.access.net:/net/u/16 > > 1340910 1113781 93038 92% /net/u/16 > >panix2.nfs100.access.net:/net/u/17 > > 953687 702839 155480 82% /net/u/17 > >panix.nfs100.access.net:/net/archive > > 2042490 1488109 350132 81% /net/archive > >panix.nfs100.access.net:/var > > 236383 142836 69909 67% /hosts/panix/var > >news1.nfs100.access.net:/var > > 968836 480625 439769 52% /hosts/news1/var > >news1.nfs100.access.net:/var/spool/news > > 2097151 361292 1534669 19% /var/spool/news > >news1.nfs100.access.net:/var/spool/newsdb > > 968836 551768 368626 60% /var/spool/newsdb > >news1.nfs100.access.net:/net/hlocal/news > > 970732 331460 590735 36% /hosts/news1/news > >news1.nfs100.access.net:/var/spool/news2 > > 2097151 730725 1164215 39% /var/spool/news2 > >news2.panix.com:/e 628543 40141 525548 7% /hosts/news/e > >news2.panix.com:/f 1036526 25659 907215 3% /hosts/news/f > >web6.panix.com:/usr/local/net_public/httpd/htdocs > > 2097151 324571 1577218 17% /net/w/panixdocs > >web1.panix.com:/usr/local/net_public/httpd/htdocs/corp-dirs > > 2097151 375851 1553220 19% /net/w/1 > >web6.panix.com:/usr/local/net_public/httpd/htdocs/userdirs > > 2097151 324571 1577218 17% /net/w/userdirs > >web1.panix.com:/usr/local/net_public/httpd/httpd-logs > > 380876 271361 90471 75% /net/httpd_logs/web1 > >web6.panix.com:/usr/local/net_public/httpd/httpd-logs > > 2097151 324571 1577218 17% /net/httpd_logs/web6 > >web1.panix.com:/usr/local/net_public/httpd/data > > 380876 271361 90471 75% /net/data/web1 > >web6.panix.com:/usr/local/net_public/httpd/data > > 2097151 324571 1577218 17% /net/data/web6 > >198.7.0.64:/usr/local/ftp/corp-dirs > > 380876 271361 90471 75% /net/ftp/1 > >198.7.0.65:/var/ftp/corp-dirs > > 853494 25109 785710 3% /net/ftp/2 > >198.7.0.66:/var/ftp/corp-dirs > > 844708 89718 712754 11% /net/ftp/3 > >198.7.0.70:/usr/local/ftp/corp-dirs > > 842053 80814 719136 10% /net/ftp/7 > >198.7.0.71:/var/ftp/corp-dirs > > 805037 5684 759101 1% /net/ftp/8 > >panix4.nfs100.access.net:/holding > > 609094 401462 146723 73% /mnt > >/dev/sd0e 1271134 993586 150435 87% /net/u/6 > >k:9> > > > > > From owner-freebsd-security Sat Sep 7 10:21:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA20060 for security-outgoing; Sat, 7 Sep 1996 10:21:11 -0700 (PDT) Received: from silver.sms.fi (root@silver.sms.fi [194.111.122.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA20051 for ; Sat, 7 Sep 1996 10:21:09 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.7.5/8.6.9) id UAA20438; Sat, 7 Sep 1996 20:20:57 +0300 (EET DST) Date: Sat, 7 Sep 1996 20:20:57 +0300 (EET DST) Message-Id: <199609071720.UAA20438@silver.sms.fi> From: Petri Helenius To: Brian Tao Cc: FREEBSD-SECURITY-L , BUGTRAQ@NETSPACE.ORG Subject: Panix Attack: synflooding and source routing? In-Reply-To: References: Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Sorry for the previous message, I mistyped my forward .... Pete From owner-freebsd-security Sat Sep 7 10:26:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA21305 for security-outgoing; Sat, 7 Sep 1996 10:26:59 -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 KAA21299 for ; Sat, 7 Sep 1996 10:26:56 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id TAA00407 for freebsd-security@freebsd.org; Sat, 7 Sep 1996 19:28:35 +0200 (MET DST) From: Mikael Karpberg Message-Id: <199609071728.TAA00407@ocean.campus.luth.se> Subject: Re: Panix Attack: synflooding and source routing? To: freebsd-security@freebsd.org Date: Sat, 7 Sep 1996 19:28:34 +0200 (MET DST) In-Reply-To: from Brian Tao at "Sep 7, 96 11:44:18 am" 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 According to Brian Tao: > Wouldn't turning off source-routing on your border router > alleviate most of this problem? It won't help if you have someone > synflooding a port from within your network, but at least it would > prevent outside attacks. Or is this a "one-way" attack (i.e., a > return route to host is not needed)? [Long message saying Panix was SYNflood attacked] Now, I'm far from an expert in this matter, but as far as I know a SYN-flood attack is a one way attack. You simply send TCP packet saying you'd like to start a connection with a machine and port, and that machine answers with an appropriate packet. That packet is simply "thrown in the void" since the source address of the first packet was faked. Just send all those SYN packets, however, will be enough to do serious damage, since the server will get busy and/or crash from the flooding. And you have to let SYN packets in or no one can connect at all, which in this case would mean no mail, at least. And that's a Bad Thing(tm). Very effective denial of service attack. You have to trace the source of the packets, through the routers on it's way there. But in this case, this included Sprint's routers. And well... Sprint seems to be generally braindamaged in a lot of situations. This time it was saying "shove it", when someone they provided with net, needed help. Not much Panix can do, I guess. Sad. /Mikael From owner-freebsd-security Sat Sep 7 10:40:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22480 for security-outgoing; Sat, 7 Sep 1996 10:40:10 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA22467 for ; Sat, 7 Sep 1996 10:40:06 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id TAA00349; Sat, 7 Sep 1996 19:39:55 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id TAA00417; Sat, 7 Sep 1996 19:39:38 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Beta.1/keltia-uucp-2.9) id TAA10976; Sat, 7 Sep 1996 19:38:29 +0200 (MET DST) Message-Id: <199609071738.TAA10976@keltia.freenix.fr> Date: Sat, 7 Sep 1996 19:38:29 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-security@freebsd.org (FREEBSD-SECURITY-L), BUGTRAQ@NETSPACE.ORG Subject: Re: Panix Attack: synflooding and source routing? In-Reply-To: ; from Brian Tao on Sep 7, 1996 11:44:18 -0400 References: X-Mailer: Mutt 0.42 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2415 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Brian Tao: > Wouldn't turning off source-routing on your border router > alleviate most of this problem? It won't help if you have someone > synflooding a port from within your network, but at least it would > prevent outside attacks. The attack doesn't seem to have source routing in it. Source addresses in the packets are random that's all. > Or is this a "one-way" attack (i.e., a return route to host is not > needed)? It is. SYN-flooding cannot really be prevented as far as I know. The attack lies in the fact that TCP/IP stacks must way for a timeout (2MSL) if there is no ACK in answer to the SYN,ACK the target sent. attacker -------- SYN -----------> target SYN_SENT <-------- SYN, ACK ------ SYN_RCVD -------- FIN -----------> As the connection never completes, these half-open are not logged in any way. They are also used for port scanning. > > For those who are IP hackers, the problem is that we're being flooded > > with SYNs from random IP addresses on our smtp ports. We are getting > > on average 150 packets per second (50 per host). The target resources will be fast exhausted by that kind of attack... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #20: Fri Aug 30 23:00:02 MET DST 1996 From owner-freebsd-security Sat Sep 7 11:43:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA28699 for security-outgoing; Sat, 7 Sep 1996 11:43:31 -0700 (PDT) Received: from kodiak.ucla.edu (kodiak.ucla.edu [164.67.128.11]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA28692 for ; Sat, 7 Sep 1996 11:43:28 -0700 (PDT) Received: from quark.cns.ucla.edu (quark.cns.ucla.edu [164.67.62.18]) by kodiak.ucla.edu (8.7.4/8.6.9) with SMTP id LAA17964; Sat, 7 Sep 1996 11:43:14 -0700 Date: Sat, 7 Sep 1996 11:43:14 -0700 (PDT) From: Mike Tsirulnikov To: Ollivier Robert cc: FREEBSD-SECURITY-L , BUGTRAQ@NETSPACE.ORG Subject: Re: Panix Attack: synflooding and source routing? In-Reply-To: <199609071738.TAA10976@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 Why don't you move your mail gateway to another machine or change the identity of the current one? I am just wondering... Mike On Sat, 7 Sep 1996, Ollivier Robert wrote: > Date: Sat, 7 Sep 1996 19:38:29 +0200 > From: Ollivier Robert > To: FREEBSD-SECURITY-L , > BUGTRAQ@NETSPACE.ORG > Subject: Re: Panix Attack: synflooding and source routing? > > According to Brian Tao: > > Wouldn't turning off source-routing on your border router > > alleviate most of this problem? It won't help if you have someone > > synflooding a port from within your network, but at least it would > > prevent outside attacks. > > The attack doesn't seem to have source routing in it. Source addresses in > the packets are random that's all. > > > Or is this a "one-way" attack (i.e., a return route to host is not > > needed)? > > It is. > > SYN-flooding cannot really be prevented as far as I know. The attack lies > in the fact that TCP/IP stacks must way for a timeout (2MSL) if there is no > ACK in answer to the SYN,ACK the target sent. > > attacker -------- SYN -----------> target > SYN_SENT > <-------- SYN, ACK ------ SYN_RCVD > -------- FIN -----------> > > As the connection never completes, these half-open are not logged in any > way. They are also used for port scanning. > > > > For those who are IP hackers, the problem is that we're being flooded > > > with SYNs from random IP addresses on our smtp ports. We are getting > > > on average 150 packets per second (50 per host). > > The target resources will be fast exhausted by that kind of attack... > -- > Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 2.2-CURRENT #20: Fri Aug 30 23:00:02 MET DST 1996 > From owner-freebsd-security Sat Sep 7 14:59:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA14809 for security-outgoing; Sat, 7 Sep 1996 14:59:01 -0700 (PDT) Received: from freebsd.netcom.com (freebsd.netcom.com [198.211.79.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA14803 for ; Sat, 7 Sep 1996 14:58:56 -0700 (PDT) Received: by freebsd.netcom.com (8.6.12/SMI-4.1) id RAA16524; Sat, 7 Sep 1996 17:04:24 -0500 From: bugs@freebsd.netcom.com (Mark Hittinger) Message-Id: <199609072204.RAA16524@freebsd.netcom.com> Subject: re: Panix Attack: synflooding and source routing? To: freebsd-security@freebsd.org Date: Sat, 7 Sep 1996 17:04:24 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Netcom's IRC servers were attacked by a similar mechanism a couple of weeks ago - random source addresses on packets that touched telnet, smtp, auth, irc, and then back to telnet. A most effective attack. We tracked it as far as we could and have more ideas about how to follow it back now. I'm jamming with a router buddy trying to get some code into the next cisco release - we can detect the condition at the router and log which interface we are getting the packets from. If the router can query its adjacent routers' "spray log" we'd be able to very quickly find the machine that the kiddies are running from (naturally it will belong to somebody else :-) ). There may be a kernel fix for this but I'm leaning towards a router based fix at this time. Regards, Mark Hittinger Netcom/Dallas bugs@freebsd.netcom.com From owner-freebsd-security Sat Sep 7 19:53:05 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA11644 for security-outgoing; Sat, 7 Sep 1996 19:53:05 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA11619; Sat, 7 Sep 1996 19:53:00 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199609080253.TAA11619@freefall.freebsd.org> Subject: Re: Panix Attack: synflooding and source routing? To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Sat, 7 Sep 1996 19:52:59 -0700 (PDT) Cc: freebsd-security@freebsd.org, BUGTRAQ@NETSPACE.ORG In-Reply-To: <199609071738.TAA10976@keltia.freenix.fr> from "Ollivier Robert" at Sep 7, 96 07:38:29 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert wrote: > > According to Brian Tao: > > Wouldn't turning off source-routing on your border router > > alleviate most of this problem? It won't help if you have someone > > synflooding a port from within your network, but at least it would > > prevent outside attacks. > > The attack doesn't seem to have source routing in it. Source addresses in > the packets are random that's all. > > > Or is this a "one-way" attack (i.e., a return route to host is not > > needed)? > > It is. > > SYN-flooding cannot really be prevented as far as I know. The attack lies > in the fact that TCP/IP stacks must way for a timeout (2MSL) if there is no > ACK in answer to the SYN,ACK the target sent. > > attacker -------- SYN -----------> target > SYN_SENT > <-------- SYN, ACK ------ SYN_RCVD > -------- FIN -----------> > > As the connection never completes, these half-open are not logged in any > way. They are also used for port scanning. *not* 2MSL, i believe that the attack keeps the tcp control blocks, ip control blocks, mbuf, and associated resources tied up for nearly 11 minutes (2MSL is 2 minutes). rather than send a FIN, the attacker may be sending another SYN packet. the SYN packet is the last packet the attcker sends into that connection. using raw_ip protocol the attacker can prevent the FIN and fake any desired ip addresses after a SYN, the server goes into SYN_RCVD state. in SYN_RCVD, the timer "tp->t_timer[TCPT_KEEP]" is used as a *connection- establishment* timer. unfortunately, this structre member "t_timer[TCPT_KEEP]" is also used to store the keepalive timer for an *established* connection, hence the index "TCPT_KEEP". the FIN causes BSD based kernels to overwrite the connection- establishment timer value (75 seconds) with the keepalive value of 2 hours. the 2 hours is reduced to an effective 11 minutes because of retranmits by the target. the target retransmits its SYN,ACK packet until TCP_MAXRXTSHIFT (12 retransmits) occur. the server then drops the connection and releases the resources. the bug is discussed in detail in stevens tcp/ip illustrated vol 3 p 151 section "SYN_RCVD Bug". note: i may be all wrong about this ;) the code in tcp_input.c needs to be protected by a conditional "if (TCPS_HAVEESTABLISHED(tp->t_state))" which is equivalent to "if (tp->t_state > TCPS_SYN_RECEIVED)" here is a unified diff. this does not prevent the attack, it does lessen the severity. --- tcp_input.c.old Sat Sep 7 22:49:11 1996 +++ tcp_input.c Sat Sep 7 22:49:44 1996 @@ -451,5 +451,6 @@ */ tp->t_idle = 0; - tp->t_timer[TCPT_KEEP] = tcp_keepidle; + if (TCPS_HAVEESTABLISHED(tp->t_state)) + tp->t_timer[TCPT_KEEP] = tcp_keepidle; /* can someone please examine this patch and either tell me i am wrong or commit it. i sent this in >2 weeks ago and never heard a peep. grrr...being wrong is bad enough, being ignored is far worse. 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