|
Hello,
On Sat, 18 Nov 2000, Anush Elangovan wrote:
> 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.
Yes, this was my thought about the RST reply - it is hard to
generate the packet (NAT). For DR and TUN we even don't see these replies.
> 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.
Hm, I don't understand.
> > 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.
No, you even don't need to queue any packets. You just need
to drop them until the source address check succeeds and to forward
the next packets. The SYNs are retransmitted from the client, so the
next packet can come soon, of course, not immediately and this is the
drawback: the handshake will be delayed. The other thing is that we
try to allocate space for this information in the LVS box instead of
the real servers. Of course, the good is that these packets are not
forwarded to the real servers but I'm not sure for the total result.
> 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.
How is that related to LVS?
> Thanks
> Anush
Regards
--
Julian Anastasov <ja@xxxxxx>
|
