From owner-freebsd-security Wed May 8 1:10:49 2002 Delivered-To: freebsd-security@freebsd.org Received: from host185.dolanmedia.com (host185.dolanmedia.com [209.98.197.185]) by hub.freebsd.org (Postfix) with SMTP id 0E4B237B40B for ; Wed, 8 May 2002 01:10:44 -0700 (PDT) Received: (qmail 72503 invoked by uid 0); 8 May 2002 08:10:43 -0000 Received: from greg.panula@dolaninformation.com by proxy with qmail-scanner-0.96 (. Clean. Processed in 0.316654 secs); 08 May 2002 08:10:43 -0000 X-Qmail-Scanner-Mail-From: greg.panula@dolaninformation.com via proxy X-Qmail-Scanner-Rcpt-To: root@utility.clubscholarship.com,freebsd-security@freebsd.org X-Qmail-Scanner: 0.96 (No viruses found. Processed in 0.316654 secs) Received: from unknown (HELO mail.dolanmedia.com) (10.1.1.23) by 10.1.1.10 with SMTP; 8 May 2002 08:10:42 -0000 Received: from dolaninformation.com (10.1.1.135) by mail.dolanmedia.com (Worldmail 1.3.167); 8 May 2002 03:10:42 -0500 Message-ID: <3CD8DD82.924A1DCB@dolaninformation.com> Date: Wed, 08 May 2002 03:10:42 -0500 From: Greg Panula Reply-To: greg.panula@dolaninformation.com Organization: Dolan Information Center Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: freebsd-security@freebsd.org Subject: Re: what does a syncookies attack look like ? References: <20020507235944.S8475-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nope, I've been lucky enough to not experience any strange lock-ups that weren't my own doing. And Jason covered those; file & process descriptors. You just mentioned syncookie and you hadn't applied the related the patch. So, I made blind guess. When the server crashes is the console responsive? You'll probably need to gather a tcpdumps from a couple of crashes to allow you to find a pattern/attack traffic. Just remember to set the snarf length to 1500. Something like 'tcpdump -s 1500 -w dump1.tcp -n host ' will write the raw stream of all traffic involving your server's ip address to dump1.tcp and then you can use ethereal to browse thru the traffic. From there it is pretty much a process of elimination; eliminate the legitimate traffic and then figure out what the questionable traffic is. Probably not what you want to hear, just because you'll have to suffer thru at least two more crashes. As for what an actual syn attack might look like, snort's database/rule-set is probably the best bet. You might even be able to feed a captured stream thru snort and have it spit out what it thinks. Optionally you could try applying the workaround of disabling syncookies, probably a long-shot but shouldn't hurt to try. Are there any other machines on your network that are accessing the crashing server at the "zero hour"? Could it be possible they are kicking off a fatal process? You could also try an entry like: *.* /var/log/messages and/or *.* /dev/console in your /etc/syslog.conf. Maybe you'll get lucky and capture a useful message before the server crashes. Remember to HUP syslogd after making the change. Good luck, Greg Patrick Thomas wrote: > > thank you - however based on my description of the crash (kernel seems to > be running, userland is not) people here seem to feel it is not a > syncookies attack. They seem to think a syncookies attack would be a much > harder crash/lock. > > This last email of mine was simply describing why I think it is an attack > in general - just not sure yet what kind. > > Do you have other information that leads you to believe a syncookies > attack could indeed lead to the kind of strange lockup I am describing ? > > thanks. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message