From owner-freebsd-hackers Fri Jun 21 15:14:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 5F88037B401; Fri, 21 Jun 2002 15:13:23 -0700 (PDT) Received: from pool0462.cvx21-bradley.dialup.earthlink.net ([209.179.193.207] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LWee-0000DH-00; Fri, 21 Jun 2002 15:13:21 -0700 Message-ID: <3D13A4DA.28F3B169@mindspring.com> Date: Fri, 21 Jun 2002 15:12:42 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Wouter Van Hemel Cc: Giorgos Keramidas , hackers@FreeBSD.org Subject: Re: Limiting clients per source IP address (ftpd, inetd, etc.) References: <20020621000924.GA2178@hades.hell.gr> <3D129CA8.EFADA4FF@mindspring.com> <1024656206.277.9.camel@cocaine> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 . 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