Date: Tue, 22 Nov 2005 20:10:29 +0100 From: Marian Hettwer <MH@kernel32.de> To: Roger Marquis <marquis@roble.com> Cc: freebsd-security@freebsd.org Subject: Re: Need urgent help regarding security Message-ID: <43836D25.5000101@kernel32.de> In-Reply-To: <20051122075050.I81101@roble.com> References: <20051122120112.9D83516A423@hub.freebsd.org> <20051122075050.I81101@roble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <http://archives.neohapsis.com/archives/crypto/2002-q2/0005.html>. > I definetly take a look into that paper :) thanks and best regards, Marian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43836D25.5000101>