From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 20:28:07 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EF7F1065679 for ; Thu, 21 Aug 2008 20:28:07 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3748FC0C for ; Thu, 21 Aug 2008 20:28:07 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 4556 invoked from network); 21 Aug 2008 20:28:06 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Aug 2008 20:28:06 -0000 Message-ID: <48ADCFD5.8020902@aldan.algebra.com> Date: Thu, 21 Aug 2008 16:28:05 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Jeremy Chadwick References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> In-Reply-To: <20080821200309.GA19634@eos.sc1.parodius.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2008 20:28:07 -0000 Jeremy Chadwick ΞΑΠΙΣΑΧ(ΜΑ): > The above looks like sshguard. Yes, several people have pointed this out. Thanks! > I've personally never trusted something that *automatically* adjusts firewall rules based on data read from text > logs or packets coming in off the Internet. The risks involved are insanely high. > An IP participating in a detected attack like this one, may also be the source of another problem, which may not be detected... I can't afford to monitor this system at all times, hence the reliance on automatic defenses -- better to crash/reboot than be taken over... > Stop for a moment and think what would happen to your box if a > distributed brute-force attack (e.g. 300,000 different IPs) was launched > against it; someone executing 20-30 SSH login attempts per IP. I'm > willing to bet adding 300,000 individual ipfw entries would cause some > serious havok on your machine (speculative: exhausted kernel memory, or > at a bare minimum, exhaust the number of remaining ipfw rule entries) > Yes, this is something I'm suspecting happening. But should not there be some frantic messages, when the system is getting closer to this point? There is nothing in the logs... > Surely you don't have that many users who SSH into the NAT router from > random public IPs all over the world, rather than via the LAN? Surely > if you yourself often SSH into your NAT router from a Blackberry device, > that you wouldn't have much of a problem adding a /19 to the allow list. > That's a hell of a lot better than allowing 0/0 and denying individual > /32s. > Myself -- and the owner of the box -- travel quite a bit, ssh-ing "home" from anywhere in the world. Although we could, I suppose, find out the destination-country's IP-allocation and add it before leaving, that would be quite tedious to manage... > A different approach: consider putting sshd on a different port, rather > than the default of 22. A lot of people I know do this, solely to > decrease the number of brute-force attempts you see above; I've never > seen any of those brute-force attacking programs portscan, then attack > against a port which returns a OpenSSH string. > That's sounds kinda lame -- and temporary... Like buying an SUV to be higher (and heavier) than other cars, this only works, until everyone has an SUV :-) Once enough people move their sshd to different ports, the next release of the ssh-attack will be doing the portscanning, no doubt... Essential liberty vs. temporary security and all that :) > Finally, consider moving to pf instead, if you really feel ipfw is > what's causing your machine to crash. You might be pleasantly surprised > by the syntax, and overall administrative usability (it is significantly > superior to ipfw, IMHO). > Thanks for the suggestion... But would this solve the suspected problems with kernel memory exhaustion, etc.? Whatever the firewall method, it still needs to keep the rules memorized somewhere... Yours, -mi