Date: Wed, 8 May 2002 00:01:51 -0700 (PDT) From: Patrick Thomas <root@utility.clubscholarship.com> To: Greg Panula <greg.panula@dolaninformation.com> Cc: <freebsd-security@freebsd.org> Subject: Re: what does a syncookies attack look like ? Message-ID: <20020507235944.S8475-100000@utility.clubscholarship.com> In-Reply-To: <3CD8CC69.47021F06@dolaninformation.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020507235944.S8475-100000>