|
Hello,
On Thu, 10 Aug 2000, Kyle Sparger wrote:
> > It just seems like we'd be meddling in foreign waters. Let TCP do what we
> > pay it to do and otherwise leave it alone.
>
> Heh, and we're not meddling in foreign waters already? NAT/DR/TUN to
> multiple nodes with the same IP address isn't screwy to begin with? We're
> already in foreign waters, doing things that weren't intended. Why get
> conservative about it now? :)
>
> Besides, we're not interfering with how TCP works, we're just monitoring
> things, and _maybe_ doing something about it.
>
> The idea behind this is that if we see the same SYN sent multiple times,
> we know that for some reason, the person attempting to create a connection
> is never receiving a SYN-ACK -- or at least is claiming something to that
> effect.
Never trust the client's packets!!!
>
> What could cause this?
> 1. Real server is never receiving the SYN, and/or is never sending a
> SYN-ACK.
> 2. Client is never receiving a SYN-ACK because it's being lost in
> transit.
> 3. Client is doing broken things -- either intentionally (syn flood) or
> unintentionally (bugs)
Yes, the incoming packets are denied in the client.
The first real server dies:
ipchains -A input -p TCP -s www.kill_this_domain.com 80 -j DENY
http://www.kill_this_domain.com/be_happy
2nd request => the second real server dies. 100 requests
and your 100 real servers die.
>
> I wouldn't mind knowing about it in any of these cases.
>
> There's another possibility:
> 4. Server requested retransmission of SYN
What is this?
5. Network delays. The SYN-ACK was delayed and the director
receives the second SYN from the client. I assume we can't react on
the second SYN (3 seconds?). The next is after 6 seconds, i.e. 9 seconds.
This is very long time. Better to start a daemon to monitor the
real service status.
6. The real server is busy (may be the SYN flood protection
is disabled or there is no free memory). The SYN packets are silently
dropped. Under SYN flood you will start to exclude all real servers
one by one from the service. This is fatal under attack.
Currently, the "secure_tcp" defense strategy listens to
the packets but only the packets coming from the real servers.
This is different.
>
> When would that happen though? Checksum error? Any other cases?
>
> The idea is to cut down on the time it takes for me to notice that there's
> a problem, irrespective of where that problem may be. I think this could
> do that. LVS isn't just being used for load-balancing, it's being used
> for high availability, and the name of the game with high-availability is
> detecting problems -- fast -- so you can solve or work around them. This
> could be another tool to do that.
You have to detect the real service failures using other
methods. Don't rely on the attacker to make your checks.
>
> If it's a routing problem, I can route around it. If it's a downed
> server, I can remove it from the pool. If it's a syn-flood, I can start
> adding some firewall rules to stop the attack up stream. In any case, I
> know that something is amiss, and I can do something about it.
>
> Thanks,
>
> Kyle Sparger - Senior System Administrator
> Dialtone Internet - Extremely Fast Web Systems
> (954) 581-0097 - Voice (954) 581-7629 - Fax
> ksparger@xxxxxxxxxxxxxxxxxxxx
> http://www.dialtoneinternet.net
Regards
--
Julian Anastasov <ja@xxxxxx>
|
