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

James B. Byrne wrote:
> Message-ID: <479F2A63.2070408@centos.org>
>
> On: Tue, 29 Jan 2008 07:30:11 -0600, Johnny Hughes <johnny@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]
>
>

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related centos.org Links centos Request more information about Pantek