Need urgent help regarding security
Marian Hettwer
MH at kernel32.de
Tue Nov 22 11:10:51 PST 2005
Hi Roger,
Roger Marquis wrote:
> ray at 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
More information about the freebsd-security
mailing list