|
Hello,
On Thu, 16 Nov 2000, Anush Elangovan wrote:
> Hi Everyone,
>
> I am studying different methodologies for prevention/neutralization of
> Denial of Service Attacks on networks as part of my curriculum. I have
What is the main goal:
1. To save the real servers from the attack
2. To make the attack invisible for the valid requests
> taken a look at the currently implemented drop_entry, drop_packet and
> secure_tcp methodologies in the LVS code. I had another idea for the
> same purpose. I need your comments and feedback on such a system.
>
> In a nut shell, this method is to assign a priority to each
> connection maintained in the connection table of the LVS. This priority is
> the probablity of the connection being a Denial of Service Attack. Let us
> say priority 1 means a "legitimate" connection. And priority 7 means a
> for sure "illegitimate" connection, and then we have the intermediates. I
> have a few methods with which we can probably priroitize these connections.
> For example, most DDOS tools like trin00, TFN use source IP address spoofing
> and some come with malformed IP packets ( like a SYN FIN etc.) which could
> be used to prioritize these connections, even RFC 1918 address could be
> given a low priority, unless you know that particular address is used in
> your network. More than say 10 Connections from 1 IP address could also
> reduce the priority of the connections.
>
> We could even have a feature, {which could be turned on/off
> depending on weather it is needed, taking into consideration the
> (network_overhead/your_parnoia_towards_DOS) ratio,} which sends an
> ICMP_EchoRequest to the suspicious IP address to check their validity and
> adjusts the priority level based on the reply. Though this could
> potentially get a reply from a machine whose address was spoofed,
> it helps remove a lot of these forged source IPs from the connection
> table, and we could reset the connection that the real server has.
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.
> 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.
> BTW, I almost forgot to mention, that the systems should load balance each
> connection irrespective of the priority. Only when system capacity is
> being reached will the lower priority connections be reset, with a TCP RST,
> (this will have a forged source IP address, as if it came from the client)
Yes, we must follow the standards here, TCP RST is valid answer.
> Advantages:
>
> Unlike existing mechanisms, we do not "randomly" drop incoming
> requests, which could be lets say ,from legitimate customers. Instead
> we drop only connections that are not that important (based on the priority).
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.
> This mechanism builds intelligence into the connection droping
> mechanism.
>
>
> Potential Drawbacks:
>
> Speed, can it handle connections at the rate the connections are coming
> in??? I think it is ur (network_overhead/your_parnoia_towards_DOS) ratio
> that comes into play over here.
>
> I dont think this should be much of a problem with the
> memory/throughput of the LVS used since each connection uses only an extra
> numberic integer value.
>
> I dont know if the lvs would be become slow when operating under normal
> circumstances when compared to an lvs without such a mechanism, as there is
> almost no
> overhead involved. I think the lvs may be under a higher load when under an
> attack and the
> system is trying to reset "malicious" connections etc.
>
>
>
> Testing:
>
> Should try to implement it and see the performance.
>
>
> Help :)
>
> I am going through the code and seeing the potential places where I
> could modify to implement a prototype of such a system. I would like some
> help from the authors and people seasoned with the code to help me with
> the same.
>
> One problem was about the ICMP function, I didnot know where to
> potentially put it in, since I dont want to delay the connection
> establishment. I was wondering if this could go to the userland, from
> where we independently send ICMP requests, (we dont have to worry about
> the response as the lvs should take care of it).
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.
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 would like your expert comments and suggestions to the above
> mentioned DOS defense mechanism. Do you think it will be useful againt DOS
> attacks?
Some of the ideas are interesting but we must correctly specify
the goals and to find the proper solutions.
There are other alternatives that try to lower the effect of the
dDoS although the authors don't believe very much in the perfect result:
- rate limit the incoming SYNs using QoS ingress discipline (linux/net/sched/)
- rate limit incoming ICMP (some of the codes)
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
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
default gateway from the director if it is needed for the address
validation checks.
You have to clear the idea. But I like the idea of using a
priority value in the connection structure. We can maintain it while
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.
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.
OTOH, the secure_tcp (in LVS/NAT) guarantees that the
connection is valid by a very simple check: the real server has
validated this connection. But again, the current methods does not
guard the real servers.
> Thanks
> Anush
>
> ----------------------------
> anush@xxxxxxx
>
> It still has to be proved that intelligence has any survival value. Anon
Regards
--
Julian Anastasov <ja@xxxxxx>
|
