|
Hi,
> I tend to say you should use a well configured packetfilter. Anyway the
> tendency is not to open icmp-ping/pong through a router or firewall. Your
> suggestion would only work if you open the whole path to the director.
The ICMP requests are just one of the methods to locate spoofed IP
addresses. Let us say that the ICMP replies from the client is blocked, then
we lower the priority but, that doesnt mean we will RST the connection. Only
when we reach 98% system capacity will we drop those connections. So in a
system without this it would be dropping of connections randomly, but here it
is [above other things] going to be connections that did not respond to icmp,
which gives us hope that the connections dropped "may" be part of a SYN
flood. But as Julian had suggested, if we can accumulate a block of IP which
reply to icmp and use them it would be very destructive. The point is, with
script kiddies just using off the shelf tools (which randomly spoof IPs) we
stand a good chance.
> How do you know it is a SYN flood? You have nothing but the SYN from an
> IP. RFC1918 addresses won't come that far anyway. So how do you know it's
> a SYN flood?
Actually speaking, I dont care if it is a SYN flood, unless my system is going
to reach peak capacity. Then, I start dropping low priority connections.But
there, let us say all requests are valid, then the proposed system is of no
use since all the priorities would be the same, and we would have a DOS
attack.
> What if you RST a SYN ACK [CONN_ESTABLISHED on RS] connection from the
> director? The RS state table is fucked.
Any suggestions on how to generate this above mentioned RST packet. Remember
in DR and TUN as Julian pointed out we dont know what the real server replies.
> Priority scheduling of TCP states can IMHO only be done reliable with
> connection tracking. You let pass the SYN and wait for the SYN ACK.
> If it's not there: RST. Generally don't allow anything else then a SYN
> for a new TCP conn. state table entry. If the connection template exists
> only allow FIN ACK, FIN and some others. The SYN RST would be dropped.
> Check the struct masq_tcp_states_t masq_tcp_states [] in ../ipv4/ip_masq.c
> to get the idea.
This could also be added as an additional check apart from the described
mechanism.
On a different note, since it is hard to reset a connection via the TCP RST
since we cant guess the sequence number, I was thinking of a way where the
Director tells the RS to reset a particular connection, and the RS does
it. I would like to know how a RS can reset a particular TCP connection, say
from a particular IP address?
Thanks
Anush
|
