[CentOS] One approach to dealing with SSH brute force attacks.

Wed Jan 30 23:03:57 UTC 2008
mouss <mouss at netoyen.net>

James B. Byrne wrote:
> Message-ID: <479F2A63.2070408 at centos.org>
>
> On: Tue, 29 Jan 2008 07:30:11 -0600, Johnny Hughes <johnny at centos.org>
> Subject Was: [CentOS] Unknown rootkit causes compromised servers
>
>   
>> SOME of the script kiddies check higher ports for SSH *_BUT_* I only see
>> 4% of the brute force attempts to login on ports other than 22.
>>
>> I would say that dropping brute force login attempts by 96% is quite a
>> good reason to move the SSH port from 22 to something else.
>>     
>
> I am not a fan of security through obscurity.  If a port is open to the
> internet then it must be secured whether it is well known or not and if it is
> properly secured then changing the port number customarily assigned provides
> no measurable benefit. 

If you consider this security through obscurity, then why not publish 
the list of your users on a public web page? after all, you should use 
strong passwords, so why hide usernames? and how about also publishing 
the list of your files and directories, of package versions, ... etc. 
Relying on the secrecy of such infos is security through obscurity too ;-p

Of course one must secure the setup and not rely solely on a port 
number. but using a different port:

- reduces the noise, and the stress level, so one can audit logs quietly 
instead of trying to separate kiddie attempts from serious attacks...

- an attacker needs to find the port. In general, this means some form 
of port scanning. and before he finds the port, there is a chance that 
he gets caught. Not certain, but still. There is the case of an attacker 
who guesses the port at once or an attacker using N machines to do the 
scanning, which is why one must not rely on the port choice, but this 
will happen less. better fight few ennemies than the full jungle.


>  In my opinion, arbitrarily switching port numbers for
> well known services provides only the illusion of security while often
> inconveniencing the legitimate users in unpredictable, and sometimes
> expensively resolved, fashions.
>   

What I would I like to do is:

- allow 22 from specific IPs
- allow another port (redirected) from anywhere. this port is then 
redirected to 22.

I guess this requires marking the redirected packets so they can be 
allowed to go to port 22? anyone having a working ruleset for this?

This way, users and programs that connect from specific machines do not 
need to use a different port (which becomes quickly annoying if you use 
rsync or other tasks over ssh and you don't want to spend your times 
setting a .ssh/config).


> [snip]
>
>