Crypto callback (was: New Denial of Service Attack on Panix)
Hi, I can propose yet another decision of SYNs flood attack on the site under attack. Unfortunatly I had no time to verify it in real live, but it is seemed as correct. Also it is not elegant decision, but ... 1). It is need to measure the available TCP control blocks resource and switch on to this strategy then host is under attack (for exam then number of free TCP blocks is less 1/3 of all TCP blocks). And switch back after it is seens that attack ended. The strategy consist of 2). Then host receive SYN, it calculate cryptographic initial TCP sequence depended from IP address [+ probably port] of another TCP side, answer by SYN-ACK with it and forget it. 3). Then host receive ACK which havn't IPs and ports of any already established or closing TCP session, then host verify answer-sequence in it and if it is correct - create TCP block and set it to established state and run as normal. Cryprographic calculation and verification. 4) Take the negative current time in the 4ms units (see RFC793) and add to it some cryptographic constant which is calculated from other part IP [+port] on the base of secret site key. 5) During checking subtract this cryptographic constant and verify time - it must be in range of 2 max segment live time from current time. ( More accurate strategy would be to increment "time" with any established TCP session, record the real time of each such increment and remove old values which is older than 2MSL.) 6) What it is need to do with MSS option ? - take the default (I said that it is non-elegant decision !) Advantages: - Callback allow the only non-falsified host connection. - Cryptographic sum on the base of IP [+port] deny SYNs flood also as another spoofing - the other part must answer with this callback key. (It is already used in many UNIX systems). The probability of success SYN flood attack is 1 for 80000 SYN packets. The same is for ordinary ACKs flood attack. Disadvantages/problems: - What would be after unexpected (!) reboot of server ? It is looks like one of 80000 nonclosed connection which haven't keepalive option and stay passive during reboot and long time before reboot can be accepted as new without notification of client. But if we take in account more accurate strategy of "time" calculation the probability of it can be significantly lower. - Some perfomance degradation due to MSS loss from initial SYN. But some system send MSS during first ACK also and eliminate this problem for it. - It is need to have source code of server system and some programming efforts to implement it :-) - Leonid Yegoshin, LY22
I've been thinking about something like that (which at least a few others have proposed, apparently, though I've not seen texts of their proposals). W/ a SYN, you might have: a) window-size (1 byte) b) mss (2 bytes) c) data I think tossing data is no problem (will get retransmitted) and most boxes I know of don't send data w/ SYNs. W/o worrying about window-size, Alex Yuriev & I had figured we could use the upper 12 bits of the 32 bit seq number to actually throw the mss/2 into and use 20 bits to get 1,000,000 possible crypto keys. We'd use a current secret key and change it every so often, keeping the old one around for 30-60 seconds when we change it. When an ACK of the SYN-ACK comes back, pull the MSS out and check the crypto checksum. Problem: You have window size, at least. In practice, I doubt you'd see more than 2^10=1024 or 2^12=4096 combinations of window-size and mss (so you could just store the combos and use the upper 10-12 bits to store that index). So the two challenges are: a) Hacking tcp_input.c, which is a RFM (real frigging mess) - or, to put it another way, it's written for speed, not to segregate into separate non-interrelated code paths what happens for SYNs, ACKs of SYNs, ACKS of SYN ACKs, and then for established connections... b) Fing a good algoritm to feed: 32 bits (dest ip, could be less if you keep an index of your own local IPs) + 32 bits (source IP) + 16 bits (source port) + 16 bits (dest port) + 32 bits (secret key) in and get out 20-32 bits. I doubt I'll have any time to mess with this this week, though I may. Every time I pass through tcp_input.c I grok more - or at least, feel that I don't *completely* grok less. Also, I think that someone from BSDi is working on something like this. And, bottom line is: One way or another, there needs to be a better way (like a hash into an array) of storing PCBs for the kernel. And if you solve THAT problem, avoiding PCB-and-socket creation until the ACK of the SYN-ACK isn't even needed, I suspect. Avi
2). Then host receive SYN, it calculate cryptographic initial TCP sequence depended from IP address [+ probably port] of another TCP side, answer by SYN-ACK with it and forget it.
Cryprographic calculation and verification.
4) Take the negative current time in the 4ms units (see RFC793) and add to it some cryptographic constant which is calculated from other part IP [+port] on the base of secret site key.
5) During checking subtract this cryptographic constant and verify time - it must be in range of 2 max segment live time from current time.
( More accurate strategy would be to increment "time" with any established TCP session, record the real time of each such increment and remove old values which is older than 2MSL.)
6) What it is need to do with MSS option ? - take the default (I said that it is non-elegant decision !)
- Leonid Yegoshin, LY22
In message <199609240208.WAA25022@netaxs.com>, Avi Freedman writes:
And, bottom line is: One way or another, there needs to be a better way (like a hash into an array) of storing PCBs for the kernel. And if you solve THAT problem, avoiding PCB-and-socket creation until the ACK of the SYN-ACK isn't even needed, I suspect.
Hashing the src/dst addr/port pairs, finding a candidate bucket, and then reverting to a linked list (simple one level fixed bucket size hashing) is very easy to do. Routing code used to do this until CIDR made tree algorithms nessecary due to prefix overlap relationships. And yes. BSDI already solved this although they did it to boost performance when many legitimate PCBs were allocated on heavily loaded HTTP servers. By luck (I think), it happens to also solve the SYN attack problem (or at least require an attack of 1/3 T1 of SYN traffic). The fancier algorithms you are talking about avoid the storage costs of the PCB. They might be marginally faster due to having to allocate and fill in less data structure. IMO its not worth it. Curtis
participants (3)
-
Avi Freedman -
Curtis Villamizar -
Leonid Egoshin