|
Hi Everyone,
I am studying different methodologies for prevention/neutralization of
Denial of Service Attacks on networks as part of my curriculum. I have
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.
Once we reach near system capacity to service connections we drop
(and reset with the real server) the lower priority connections.
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)
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).
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).
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?
Thanks
Anush
----------------------------
anush@xxxxxxx
It still has to be proved that intelligence has any survival value. Anon
|
