From owner-freebsd-security Wed May 8 0: 5:10 2002 Delivered-To: freebsd-security@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 4BC3037B409 for ; Wed, 8 May 2002 00:05:05 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g4871pA22132; Wed, 8 May 2002 00:01:51 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Wed, 8 May 2002 00:01:51 -0700 (PDT) From: Patrick Thomas To: Greg Panula Cc: Subject: Re: what does a syncookies attack look like ? In-Reply-To: <3CD8CC69.47021F06@dolaninformation.com> Message-ID: <20020507235944.S8475-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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. On Wed, 8 May 2002, Greg Panula wrote: > Patrick Thomas wrote: > > > > The reason we suspect it is an attack - or at least an outside influence - > > is that the crash/hang occurs at exxactly the same time every day. Of > > course the first reaction to that would be "probably a cron job" ... > > however we have ruled that out by setting the system time to the time that > > it crashes .. at times of the day with analogous (or greater) load than > > when it really does crash. When we artificially set the time to the "zero > > hour" nothing happens. > > > > However, when that time comes up in the "real world", the server hangs > > like I described. > . > . > . > > tcpdump on the machine itself and on the firewall reveals nothing > > interesting. Not an interesting level of traffic in terms of transactions > > or bandwidth. We're going crazy here trying to figure it out. We are > > running the very first 4.5-RELEASE, and we have so far only patched the > > included sshd, and done the chmod on the `keylink` file or whatever it waw > > that was suid root. Otherwise it is a stock very first release of > > 4.5-RELEASE. > > > > thanks for any suggestions/help, > > > > The answer to your problem it probably related to security advisory: > FreeBSD-SA-02:20 "syncache/syncookies denial of service" > > The full text of the advisory can be found at: > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02%3A20.syncache.asc > > All of the security advisories can be found at: > http://www.freebsd.org/security/index.html#adv > > > A google search for 'syncookies' or 'synflooding' should turn up some useful > information about SYN flooding and the use syncookies as a defense. > > I found a quick description at: > http://www.incidents.org/diary/november01/110801.php > > "On some operating systems it is possible to configure the > kernel to use a SYN flood protection mechanism known as > SYNcookies. The idea is that, if the server should detect > a SYN flood attack, it can stop keeping state on waiting-to-be- > completed three way handshakes, and switch to a challenge-response > mechanism for accepting new connections. > > When in "flood protection mode" the server embeds a cryptographically > strong "cookie" in the TCP header of each SYN-ACK it sends. This > cookie is a state-keeping mechanism. If a real client is actually > engaged on the other end of the connection, the client will > automatically return the cookie to the server when responding > with the final ACK of the three-way-handshake. Thus, the server > can completely forget about the connection after sending the > SYN-ACK, because all the state data required to establish the > new connection arrives in the final ACK. " > > Good luck, > Greg >  > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message