|
Hi,
Anush Elangovan wrote:
>
> 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
Hmm, agreed but consider all ICMP traffic blocked. For every incoming connection
we would lower the priority and if we got 98% saturation we start dropping. If a
lot of those connections were ok, then the resulting wrongly dropped packets
will
not differ a lot from randomly dropped packets (it's just more systematic). If
we have a lot of forged packets this will also result in lot wrongly dropped
packets since you can't verify with your method if they are faked or not. So
IMHO you gain nothing but overhead trying to ICMP-request the origin without
success. I stand corrected.
> 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,
With the above situation it will drop also innocent packets.
> 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.
Sorry if I disagree but I'd rather configure my router, packetfilter and
firewall
correctly. This proofes quite useful in real world. People putting their lvs
node directly into the internet must be happy people anyway. I still think
the current implemented defense strategies along with the already existing
ones such as rp_filter, tcp_syncookies, tcp_retries?, tcp_max_syn_backlog
(this one you could use for linux realserver protection) should be quite
good. I don't know why we should include another not 100% reliable protection.
> 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.
I wonder how you achieve to priorize different DoS attacks? See, if I do
security audits and there is a, let's say, network-based IDS, I first try
out the normal script kiddie attacks and move over to DDos attacks and if
it still resets my connections I write my own packet-forger with libnet.
If you think your method provides more reliable right positives than the
existing implementation I'd like to know. I'd appreciate if you could
prove my assumptions wrong.
> > 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.
Oups, sorry, I though you'd send a RST to the (forged) CIP and not to
the RIP. Ok, you're right.
> > 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.
IMHO this is the only way of reliably marking/dropping bad packets.
> 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?
You have to track to connection along with ISN, state table and to sychronize
it or you could tell the RS that the connection template x is fake and he
therefore has to close the socket, but this will most probably not work. No,
if we use triangulation mode (VS-DR) we have no information about the TCP states
of different RS and therefore have to know by the first packet arriving the
director if it's fake or not.
It's getting interesting. Best regards,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
