|
Hello,
On Mon, 27 Mar 2000, Wensong Zhang wrote:
>
>
> Hi Julian,
>
> On Sun, 26 Mar 2000, Julian Anastasov wrote:
>
> >
> > On Sun, 26 Mar 2000, Wensong Zhang wrote:
> >
> > > > It seems that we can't drop entries in SR state after passing
> > > > the SYN packet to the real server. Currently, when the real server
> > > > answers
> > > > with SYN+ACK ip_fw_masquerade() creates new entry with ip_masq_new().
> > > > Is that good?
> > > >
> > >
> > > That's not good. I think it is simple to notify the real server that
> > > destination is not reachable and drop the packet. ;)
> >
> > That is easy. We can add hash table for the destinations
> > which will be used only by ip_fw_masquerade. We even don't need
> > struct ip_masq_dest.svc pointer. We can just check if this is our
> > real service and return ICMP_PORT_UNREACH to the real server
> > when the entry is removed.
> >
>
> Yup.
>
> > >
> > > > In fact, if we start to drop entries (any kind), we have
> > > > to modify ip_fw_masquerade to check if the packet comes from our
> > > > real server. Else, we start to create MASQ entries to the real
> > > > servers with mport=MASQ_port (first free>61000) which is never used.
> > > > I.e. we create zombie entries in SS or ES state. May be we can notify
> > > > the real server here but only if we support uniq real services under
> > > > VS/NAT, i.e. one raddr/rport to be used from one virtual service.
> > > > May be we can just drop packets coming from our real service.
> > > >
> > > > Usually the SYN packets are retransmitted if not answered
> > > > soon. This is a very bad situation for VS/DR and VS/TUN methods. If
> > > > we drop SR entry for a real server after passing the packet, the next
> > > > SYN is send to another real server and the client is confused from
> > > > two different SYN+ACK packets/cookies coming from two real servers.
> > > >
> > >
> > > Yeah, it is possible, but it should rarely arise. Even if the problem
> > > arises in some situations, I think the TCP protocol of client machines
> > > should be reliable against to this problem, or just drop the connection,
> > > it doesn't hurt too much to the whole situation. ;)
> >
> > Currently, the Linux client will send the 2nd SYN packet
> > 3 seconds after the 1st. So, the client waits 3 seconds after
> > sending the initial SYN and before receiving the SYN+ACK from the
> > LVS. I think it occurs very often. On slow links, we usually
> > don't receive SYN+ACK in these 3 seconds.
> >
>
> The probability that the first SYN packet is passed then dropped and the
> 2nd SYN packet is passed is low. Even for the clients resending SYN packet
> in 3 seconds on slow links, supposing the probability that an entry is
> dropped in every second random scanning is 1/16, then the probability that
> it happens is (1/16 + (15/16)*(1/16) + (15/16)^2*(1/16))*15/16, less than
> 17%. ;-)
OK, may be we can implement some statistics in the LVS:
- dropped entries
- traffic for each real service
- etc
Or may be just for debugging, i.e. to check the behavior under
attack and with the goal to tune the mechanisms. We can encount the
ICMP_PORT_UNREACH packets sent back to the real server too. This
is only an idea.
> > I like the idea of many independent sysctl vars.
> > We have to choose correct names for the above sysctl vars.
> >
>
> It is good to have many independent sysctl vars. However, it might be good
> to have an ip_vs_defence_level sysctl, whoes value can be 0,1,2,3,4...,
> different level means different defence strategies, then there is only one
> sysctl on this. ;)
I think it is very useful to combine delayed ES transitions
with dropping packets (without passing them). Lets choose some names
for them.
1. "dropping entries" => from table
2. "dropping packets" => without passing them (using rate)
3. "secure tcp" ??? I.e. when we follow the real servers TCP state
Method 3 can be problematic for services which assume
timeout 15 minutes after the connection setup. May be this method
can be optional. But methods 1 and 2 seem as mandatory for me. But
it can be useful each to be set independently. If we choose to
use one sysctl var, we have to combine the useful combinations.
I.e. the max is 3 methods ^ 3 values (0/1/2) => 27 values. The
other parameters can be when each method is triggered in
automatical mode. OK, may be we have to choose only small number
of possible settings.
> > For the UDP entries. Is the checking in ip_vs_random_drop()
> > for IP_MASQ_S_NONE correct? Isn't the state IP_MASQ_S_UDP? May be
> > I'm missing something? May be it is better to control the UDP
> > entries by using ipchains and not to drop entries from the table?
> > We still can implement dropping UDP entries without passing them.
> >
>
> It is my mistake, the state should be IP_MASQ_S_UDP. But, I cannot see the
> reason that we cannot drop UDP entries, UDP itself is unreliable and
> connectionless, UDP packets can be lost, duplicated, out of oder in the
> transfer.
I don't know. DNS is stateless. But other service are not.
They are different things: stateless/persistent and connectionless.
May be the UDP is used for other services, i.e. when the speed is
preferred and the TCP retransmissions are not useful: game servers.
And there is a little persistency. For services which
receive one packet and answer one packet we even don't need to
remember the entry for long time. If the user thinks the real
server can answer for 2 seconds, he can set the UDP timeout
to 2 seconds with ipchains. Anything better?
It can be useful each virtual service to use different
timeouts but it is difficult to achieve. There are so many states.
May be only for the ES and UDP states. When I implement the
per-entry timeout table (ms->timeout_table) I'll check if this is
possible. If the idea looks good. So, this can be an additional timeout
value. For TCP it is ES timeout. For UDP it is UDP timeout. But the
goal is only to work under DoS attack.
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
