Date: Wed, 08 May 2002 19:13:40 GMT From: "Peter C. Lai" <sirmoo@cowbert.2y.net> To: Patrick Thomas <root@utility.clubscholarship.com> Cc: freebsd-security@freebsd.org Subject: Re: what does a syncookies attack look like ? Message-ID: <20020508191340.29797.qmail@d188h80.mcb.uconn.edu> In-Reply-To: <20020507235944.S8475-100000@utility.clubscholarship.com> References: <20020507235944.S8475-100000@utility.clubscholarship.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I have also seen this happen on a box that has run out of swap, or is unable to swap out (which is effectively the same result, but the second could be due to hardware failure). You say that you can no longer connect to the box remotely when the box goes down. Are you patched for the tcpip routing table memory leak? Remember that vulnerability required you to go to patchlevel 4.5-RELEASE-p3 (or -STABLE after the fix). More info on this vuln can be found here: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:21.tcpip.asc Patrick Thomas writes: > > 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 ----------- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology | Undergraduate Research Assistant http://cowbert.2y.net/ 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?20020508191340.29797.qmail>