|
Hi,
Ok, I step in a little bit late and may suggest something
that has already been discuss, please bear with me. But I'm
interested in security related questions, so ...
Anush Elangovan wrote:
>
> 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.
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.
> >
> > > 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.
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?
> >
> > 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.
What if you RST a SYN ACK [CONN_ESTABLISHED on RS] connection from the
director? The RS state table is fucked.
>
> 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.
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.
> > 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.
Fair enough :)
> 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.
Gosh, can't wait for 2.4.x and the advanced IProuting features to be
released.
Best regards,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
