|
Hi,
Thanks for your comments.
>
> What is the main goal:
>
> 1. To save the real servers from the attack
> 2. To make the attack invisible for the valid requests
The main goal of the system would be (2), to make the attack invisible to
valid requests, which leads to the first point where we need to save the real
servers from the attack so that the valid requests could be processed.
> The SYN+ACK cookie has the same purpose: to eliminate the
> spoofed connections. The attacker can use valid source address of
> innocent host. From the ICMP reply you can't say whether the connection
> is valid, only whether there is such host with open ICMP firewall.
True, but with tools like Trin00 and TFN, they spoof the IP addresses randomly
and in such a situation, an ICMP would be some basis to prioritize and drop
connections. Even though the connection could be valid we are just looking at
some criteria to drop connections when there are too many connections to
handle.
>
> > Once we reach near system capacity to service connections we drop
> > (and reset with the real server) the lower priority connections.
>
> Yes, the current activation scheme can be used or may be another
> one.
But, I guess the current scheme stops the connection right at the lvs
director rarther than sending them to the real server and then reseting it
incase of it being suspected as a SYN flood. The advantage here is that you
save per connection processing time as the connection is initially sent thru
and then RST if it is a SYN flood.
> The drop_entry is smarter than drop_packet. It looks like your
> proposals. The priorities are implicit: the TCP connection state mostly
> guarantees that the source address is not spoofed. And then the number
> of incoming packets are accounted in this priority.
Agreed.
> For the ICMP function I think it will be very difficult to
> implement. Consider this situation:
>
> 1. SYN comes
> 2. You defer this packet before analyzing the source address or pass it
> to a real server?
> 2.1 If you defer this packet, then you remember so many fields from the
> TCP packet. And for long time (as part of the connection entry may be).
> 2.2 You pass it => the real server start its handshaking.
>
I would pass it on to the real server, and would be assigned an initial
priority (source IP check could be done here). Let us say the "priority
changing" mechanism could be a separate process (can even be a separate
process in userland, working fulltime just prioritizing connections and
changing their priority). All the ip_vs has to do is trigger the
connection priority based drop mechanism once system capacity is going to be
reached. (this could depend on a similar calculation using amemthresh ). This
mechanism needs to just send RST packets to the real servers.
>
> So, the main question is: do you want to guard the real servers
> or you prefer to keep the LVS director not busy, just like the current
> LVS defense strategies?
>
I am interested in total system availablity to legitimate users, this means I
should guard the real servers. Since I RST the connection on the real server,
the corresponding entry in the Director is also removed, the director will
also be available to service more legitimate connections.
>
> These method guarantee to keep the load in the real servers low
> but why they are not perfect: there is no known method to distinguish
> the real clients from the spoofed requests. If you take the role to
Yes, I understand that there is no way to distinguish the real client, but do
you think this priority based system could be a step in the right direction.
> validate the incoming requests you have to defer/drop the incoming
> SYN packet after allocating memory for storing the initial information
> while the connection is validated. You are moving the handshake from
> the real servers to the director but we don't know what happens while
> this is performed for the LVS/DR and LVS/TUN methods where the outgoing
> traffic does not come to the director. The users can't remove the
Though I didnot have in mind any idea about defering the packet in the
director, I guess it could be used in VS-NAT, and in VS-DR where all the real
server and director are in the same switched ethernet segment (if we can have
some code to sniff out all the outgoing packets). But this is not my aim here.
I would like to forward the connection immediately to the real
server, while the validation is done. The connection is allowed to continue
normally (until we find that the whole cluster is going to reach full capacity
this could also be accounted for in the number of connections. Say, each real
server can support x number of connections and we have 3 real servers, so
when we are reaching like 98% of 3x we could start resetting lower priority
connections. My point here is that we donot need to track the replies of the
real server in DR/TUN. The initial SYN packet is what we mostly use to
prioritize the connection. We will also use a little history here, like how
many concurrent connections from one IP etc. The following packets like ACK
etc will be used to adjust the connection priority.
> changing the states. But we move the load of these checks from the
> moment of the attack to the packet handling code (i.e. even when there
> is no attack). But smarter spoofing programs can fool the director
> in DR and TUN mode by sending ACK packet after the initial SYN packet.
Yes it is possible to fool the system, but it will be of no use unless the
attacker knows that this is a cluster, and then finds out it is an LVS
cluster. But if he doesnt, our system becomes more useful. If he does, his
attack is worth only half as he needs to send an double the packets i.e. the
SYN and then the ACK, which makes it harder as he needs double the number of
machines to launch an attack of similar impact.
> And we enter established state where the discussed priority is raised
> and we assume this connection is valid while it is not. So, there is
> a good reason the number of incoming packets to be involved in the
> checks.
Any suggestions on how to change the priority based on number of incoming
packets.
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
>
>
I almost forgot to mention another advantage of the proposed system, apart
from protection from DOS it could be used to prioritize connections from
particular subnets.
Say Company A has an LVS cluster and it wants its staregic partner company B
to be given priority access to the cluster, we could tell the cluster
directory to give say priorty 0 to connections coming from the subnet company
B has. This could also be used to give them access to say a dedicated real
server/ real servers for their purpose. For example yahoo, has something
similar where, a company's employees can access that company's specfic
internal information via my.yahoo.com.
Thanks again.
Anush.
|
