Date: Fri, 21 Jun 2002 15:12:42 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Wouter Van Hemel <wouter@pair.com> Cc: Giorgos Keramidas <keramida@FreeBSD.org>, hackers@FreeBSD.org Subject: Re: Limiting clients per source IP address (ftpd, inetd, etc.) Message-ID: <3D13A4DA.28F3B169@mindspring.com> References: <20020621000924.GA2178@hades.hell.gr> <3D129CA8.EFADA4FF@mindspring.com> <1024656206.277.9.camel@cocaine>
next in thread | previous in thread | raw e-mail | index | archive | help
Wouter Van Hemel wrote:
> I agree with this... but I think that the reason many people like to do it
> by implementing the limitation in the daemon, is that they can send back
> some kind of reply, stating the reason of the refusal (which is a nice
> thing to do, since so many people are behind proxies, sharing the same
> ip). In that case, you need to speak the protocol of the specific service,
> even though most of it is plain text anyway.
>
> If not, the ipfw method works just fine.
>
> Just a thought.
Attila Nagy makes a similar point.
I think maybe the place for such a message is in a proxy server.
The problem here is the point is to limit the number of connections
by one IP address.
The obvious reason for this constraint is to prevent a trivial
denial of service attack occurring from a single IP address, so
that clients from other IP address can get in.
If you allow the connection to go through so that you can present
a user with a capacity limitation message, then you are in much
deeper trouble. You've already allowed your attacker to consume
a connection resource, and enough of the protocol state engine
has to be there for the inital connection negotiation, such that
a failure message can be delivered down the protocol encapsulated
channel (in the FTP case, the command channel, as a greetings
message failure).
After that happens, then you close the connection to the client.
However, an attacking client can delay the handshake negotiation
mechanism, thus consuming the per connection state information
without a full connection. Alternately, for other protocols,
immediately upon being connected to the server which is about to
reject the connection, the client can wait for the server to do
the connection close as part of the reject. This sends the
socket into TIME-WAIT on the server, tying up the server resources
for a full 2MSL.
I think that permitting the connection to go through so that you
can have a protocol rejection followed by a protocol close defeats
much of the purpose of rate limiting based on IPs.
If the patch were simply to set an overall connection limit, then
it might make sense to allow the connection. Even so, you are then
subject to attack. The ftp.cdrom.com server does a connection
rejection based on protocol negotiation and a failure handshake
message ("Too many users; maximum of 5000" or whatever). Technically,
you could DOS attack this server: it's relying on pool retention in
order to not run out of connections. In other words, it's assuming
that the people connecting to it are legitimate.
So a connection followed by a protocol rejection is for people who
are playing nice. A connection reject outright is for people who
are attacking you. In other words, it's a circuit breaker, not
door security.
Someone made the comment about people sitting behind a NAT, so that
the number of connections from a given IP is actually legitimate
traffic. This rate limitation is targetted at an attacker. One
would expect that the number of connections would be set high
enough that it would not trigger for these people, and low enough
to catch an attacker.
Really, if you get to this point in dropping connections, you are
pretty much screwed anyway. It's not going to protect you from
partial connection attempts, which are one of the most common
attach types these days (e.g. SYN-flooding), since by the time you
get through the protocol state machine, the resources that you should
be worrying about protecting have already been compromised. If the
idea is to prevent an attack, then you should not even queue the SYN
requests from an IP after you hit the connection limit -- you should
drop them. The network card DMA'ing them into memory in the first
place is where you want to squelch the problem. That's probably a
firmware issue, where you give the card a list of "squelch" IP
addresses, and it ignores packets from there for <timeout>.
In any case, there's really little justification for accepting a
connection and then immediately rejecting it with a protocol
reject, since all of your overhead for protocol state, connection,
etc., has already been consumed, if your intent is to guard against
an attack.
So I guess what needs to happen is a strict definition of what it
is people expect to actually accomplish with this class of patches.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D13A4DA.28F3B169>