From owner-freebsd-security@FreeBSD.ORG Tue Nov 22 19:10:51 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EA2E16A41F for ; Tue, 22 Nov 2005 19:10:51 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64A5343D53 for ; Tue, 22 Nov 2005 19:10:46 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id F17303F2F; Tue, 22 Nov 2005 20:10:38 +0100 (CET) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27573-20; Tue, 22 Nov 2005 20:10:32 +0100 (CET) Received: from [10.38.0.120] (unknown [212.12.51.89]) by crivens.unixoid.de (Postfix) with ESMTP id 844073EDA; Tue, 22 Nov 2005 20:10:32 +0100 (CET) Message-ID: <43836D25.5000101@kernel32.de> Date: Tue, 22 Nov 2005 20:10:29 +0100 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marquis References: <20051122120112.9D83516A423@hub.freebsd.org> <20051122075050.I81101@roble.com> In-Reply-To: <20051122075050.I81101@roble.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at unixoid.de Cc: freebsd-security@freebsd.org Subject: Re: Need urgent help regarding security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2005 19:10:51 -0000 Hi Roger, Roger Marquis wrote: > ray@redshift.com wrote: > >> The point isn't to get more secure. You are correct by saying that >> moving the port # doesn't make anything more secure. > > > Actually the point _is_ security and changing the port number _does_ > improve it significantly though only from one popular attack vector. > > Security by obscurity _does_ work and often very well just not in > place of more substantive measures. In the case of sshd dictionary > attacks those would be: > > 1) setting "MaxAuthTries 2", "Banner /etc/issue" and > "PermitRootLogin no" in /etc/ssh/sshd_config, > good ideas! > 2) running an sshd IDS that A) tests for '(for invalid user|Failed > password for)', B) blacholes source hosts 'ipfw add deny ...', and > C) alerts sysadmin or operations personnel, > Be careful with adding ip addresses to deny via a packet filter. If an attacker uses spoofed IP adresses, you may produce yourself easily a denial of service attack. Say I used the IP address of your default gateway. If you don't check that and just add a deny rule... well... bad luck ;-) However, if being careful, using a packet filter to deny access for these attackers sounds like a very good way. > 3) making sure SSL and SSH are up to date (preferably via ports), > of course :) > 4) deleting the rc script, adding sshd to /etc/inetd.conf, and > taking advantage of the rate controls, logging, and other excellent > security features of FreeBSD's inetd. > full ack too. > Hosts that don't have at least these 4 protections in place will > reduce their exposure by moving sshd to a port other than 22. Hosts > that do implement these protections will still benefit from changing > the port but can lose some excellent logging. If possible keep the > logs and either send them to the offending ISP or add to a local > list of long-term blackholes. > > Obscurity is an important and wholly necessary part of the security > toolkit. Take passwords for example. Defining a non-dictionary > password is security by obscurity. It is, however, weak protection > if you do not also log dictionary attacks and blackhole offenders > before they can try many username/password pairs. ATM PINs are even > weaker than passwords but are nevertheless adequate protection > thanks to the fact that ~3 failed passwords will cause the account > to be locked. > > Bruce Schneier looks at more areas on where security by obscurity > works and where it doesn't in the May 2002 CRYPTO-GRAM > . > I definetly take a look into that paper :) thanks and best regards, Marian