CentOS - Jan 2008 - One approach to dealing with SSH brute force attacks.

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.  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.

To deal with brute force attacks (not just on ssh) I spent some time tracking
down how others had dealt with the problem. I discovered thereby that one can
use the simple linux firewall iptables to restrict the number of connections
to a given port from a single source over a specified interval. I therefore
added these rules to my /etc/sysconfig/iptables file:

...
# This is usually present in all setups but, you never know....
# Established connections go right through.
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
...

# Block brute force attacks
# Drop repeated ssh connection attempts within 20 seconds interval
-A RH-Firewall-1-INPUT -p tcp -m tcp -m state -m recent -i eth0 --dport 22
--state NEW -j DROP  --rcheck --seconds 20 --name THROTTLE --rsource

# Accept ssh connection if not attempted within past 20 sec.
-A RH-Firewall-1-INPUT -p tcp -m tcp -m state -m recent -i eth0 --dport 22
--state NEW -j ACCEPT  --set --name THROTTLE --rsource

You can change the interval from 20 seconds to whatever you feel represents a
decent compromise between user satisfaction and security.  Many authorities
considered a value between 3 and 6 seconds sufficient to render brute force
attacks impractical.  These rules can be trivially modified to protect any
destination port (-dport 21 for ftp for instance) or protocol (-p udp).

I hope this information is of use to some of you.  I find this list and its
archives very helpful myself.

Regards,

-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

I use this one, works great and easy to setup

http://rfxnetworks.com/bfd.php

On Jan 30, 2008 11:54 AM, James B. Byrne <byrnejb at harte-lyne.ca> 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.  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.
>
> To deal with brute force attacks (not just on ssh) I spent some time
> tracking
> down how others had dealt with the problem. I discovered thereby that one
> can
> use the simple linux firewall iptables to restrict the number of
> connections
> to a given port from a single source over a specified interval. I
> therefore
> added these rules to my /etc/sysconfig/iptables file:
>
> ...
> # This is usually present in all setups but, you never know....
> # Established connections go right through.
> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> ...
>
> # Block brute force attacks
> # Drop repeated ssh connection attempts within 20 seconds interval
> -A RH-Firewall-1-INPUT -p tcp -m tcp -m state -m recent -i eth0 --dport 22
> --state NEW -j DROP  --rcheck --seconds 20 --name THROTTLE --rsource
>
> # Accept ssh connection if not attempted within past 20 sec.
> -A RH-Firewall-1-INPUT -p tcp -m tcp -m state -m recent -i eth0 --dport 22
> --state NEW -j ACCEPT  --set --name THROTTLE --rsource
>
> You can change the interval from 20 seconds to whatever you feel
> represents a
> decent compromise between user satisfaction and security.  Many
> authorities
> considered a value between 3 and 6 seconds sufficient to render brute
> force
> attacks impractical.  These rules can be trivially modified to protect any
> destination port (-dport 21 for ftp for instance) or protocol (-p udp).
>
> I hope this information is of use to some of you.  I find this list and
> its
> archives very helpful myself.
>
> Regards,
>
> --
> ***          E-Mail is NOT a SECURE channel          ***
> James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
> Harte & Lyne Limited          http://www.harte-lyne.ca
> 9 Brockley Drive              vox: +1 905 561 1241
> Hamilton, Ontario             fax: +1 905 561 0757
> Canada  L8E 3C3
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos/attachments/20080130/ca3e7b21/attachment-0002.html>

On Wed, Jan 30, 2008 at 12:17 PM, Ed Donahue <liberaled at gmail.com>
wrote:
> On Jan 30, 2008 11:54 AM, James B. Byrne <byrnejb at harte-lyne.ca>
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.  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.
> >
> > To deal with brute force attacks (not just on ssh) I spent some time
> tracking
> > down how others had dealt with the problem. I discovered thereby that
one
> can
> > use the simple linux firewall iptables to restrict the number of
> connections
> > to a given port from a single source over a specified interval. I
> therefore
> > added these rules to my /etc/sysconfig/iptables file:
> >
> > ...
> > # This is usually present in all setups but, you never know....
> > # Established connections go right through.
> > -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > ...
> >
> > # Block brute force attacks
> > # Drop repeated ssh connection attempts within 20 seconds interval
> > -A RH-Firewall-1-INPUT -p tcp -m tcp -m state -m recent -i eth0
--dport 22
> > --state NEW -j DROP  --rcheck --seconds 20 --name THROTTLE --rsource
> >
> > # Accept ssh connection if not attempted within past 20 sec.
> > -A RH-Firewall-1-INPUT -p tcp -m tcp -m state -m recent -i eth0
--dport 22
> > --state NEW -j ACCEPT  --set --name THROTTLE --rsource
> >
> > You can change the interval from 20 seconds to whatever you feel
> represents a
> > decent compromise between user satisfaction and security.  Many
> authorities
> > considered a value between 3 and 6 seconds sufficient to render brute
> force
> > attacks impractical.  These rules can be trivially modified to protect
any
> > destination port (-dport 21 for ftp for instance) or protocol (-p
udp).
> >
> > I hope this information is of use to some of you.  I find this list
and
> its
> > archives very helpful myself.
> >
> > Regards,
> > --
> > James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
>
> I use this one, works great and easy to setup
>
> http://rfxnetworks.com/bfd.php
>
Log parsing scripts often don't provide the immediacy that rate
limiting does when under attack.  You'd have to run the script
constantly parsing logs, since most ssh scans come in bursts.

@James:
As for the "security through obscurity" post, you are missing the
point.  Changing the port number that SSH runs on is not "security
through obscurity".  Moving an already highly secure service to a
different port so scanners don't hit it automatically is a different
thing.  This type of move is purely to reduce the amount of garbage in
one's log file due to automated scans.  However, I do agree that there
are probably better ways to handle the situation, such as using rate
limiting.

Security through obscurity would be something like leaving a shell
that requires no login running on some random port, and hoping nobody
finds it.

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]
>
>

mouss <mouss at netoyen.net> wrote:
>>
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?
<<

Usernames are comparatively hard to guess, and chosen from a large space -
although email addresses often provide a huge clue. By contrast, there are
only 64K port numbers (and only 1K privileged ports, all of which will be
scanned by default with nmap) - and to make it worse, the attacker only has
to telnet or nc to a port and sshd will obligingly send back its version
number and protocol version info as plaintext. So, the added
"obscurity" is
effectively zero.

I sort of half-buy the log volume/noise argument, but rate-limiting and
good analysis tools deal with this as well. And it does nothing for the
stress level, since the serious adversary will see through your
non-standard port number in seconds.

Best,

--- Les Bell, RHCE, CISSP
[http://www.lesbell.com.au]
Tel: +61 2 9451 1144
FreeWorldDialup: 800909

James B. Byrne wrote:
> 
> I am not a fan of security through obscurity.  
You're diluting a useful phrase.

It originally referred to practices where obscurity was the _only_ 
source of security.  As soon as you saw through the obscurity, there was 
no security.  Of course, this means that there was no real security to 
begin with.  Hiding telnet by changing its listening port would be 
security through obscurity.

Changing ssh's service port is not at all the same thing.  If you get 
past this bit of obscurity, security remains.  To employ another popular 
phrase, it's defense in depth.  The more walls you can throw up, the 
less stress on the final wall that stops the attack.

If you don't like those arguments, the CPU usage difference should 
matter to you.  Your system can reject (or ignore) a connection to an 
unused port with a lot less CPU power than it takes to reject a login 
attempt, especially to a cryptographically protected service.  And, the 
post that started this says there's a 96% chance that the port rejection 
runs the attacker off completely, whereas a password rejection just 
invites another attempt.  So, one TCP RST packet vs. several thousand 
login attempts.  Which would you rather allocate CPU resources for?