|
Hi,
Thank you for your responses,
You have to check the standards what information should contain
this RST packet. I'm not sure if you can generate the correct values
in the TCP RST packet (seq numbers, etc.). IMO, the ICMP message to the
real servers reaches the same goal without any problems. It can't work
immediately for already established connections (the error report is very
slow, usually 2 minutes, security considerations) but this is not true
for the attacker's connections, we assume that they are not in established
state.
Taken from RFC 793:
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment
The connection remains in the same state.
So as you said it will be hard to generate the RST packet in DR and TUN as
the ACK from the realserver neednot pass through the director in which case
we could have spoofed the RST packet and reset the connection.
I had also got an interesting suggestion from Lorn about using just the
Netfilter
hook and to assign a FWMark, which could then be used by lvs. What do you think
about this method. If we use the Netfilter hook it could be used on the real server
rarther than on the director. Once we do this we dont have to worry about the
TCP RST because we will be on the localhost and we can can just drop any connection
we want via Netfilter. And if the real server can use it, it could be used as a
generic solution to all linux servers, irrespective of weather it is in a lvs
cluster.
Your ICMP checks in the director can help only to detect
valid clients for real servers that don't implement SYN cookies. But I'm
not sure about the effect if you pass all SYNs to the real server. These
packets can be dropped from the real server without notifying the director
to terminate the checks. These packets can be for valid connections but the
director doesn't know this, the real server can keep only 128 SYNs in
the incoming queue. The director will learn whether one connection is valid
at the same time when the director learns it using ICMP. What timeout you
will select for receiving the ICMP reply? Shorter than the real server's
timeout for the client's ACK?
Yes, the ICMP timeout has to be shorter than the realserver's timeout
for the client ACK, else the connection would
anyways be dropped.
The other variant is not to pass the incoming SYNs to the
real servers before the validation but this delays the handshake
under attack. When the ICMP reply is received you can pass the next
SYN packet. This can work only for clients that don't block the ICMP
echo messages.
I think this would not be a good idea as we will have to queue up a lot
of requests when we are under attack, and there is
always the possiblity of the blocked ICMP echo messages. And again, the
ICMP messages may not be able to get through
all the traffic generated during an attack.
IMO, it is difficult to guard the real servers. You can rate
limit the incoming SYNs or just to rely on the real server's own
defense.
Hm, it is interesting to see what the other people think about
the proposed strategy.
What do you think about the suggestion by Lorn Kay, of doing the same
with netfilter? It sort of becomes
the real server's defense.
Thanks
Anush
|
