On Wed, Jan 30, 2008 at 12:17 PM, Ed Donahue <liberaled@xxxxxxxxx> wrote:
> On Jan 30, 2008 11:54 AM, James B. Byrne <byrnejb@xxxxxxxxxxxxx> wrote:
> > Message-ID: <479F2A63.2070408@xxxxxxxxxx>
> >
> > On: Tue, 29 Jan 2008 07:30:11 -0600, Johnny Hughes <johnny@xxxxxxxxxx>
> > Subject Was: 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@xxxxxxxxxxxxx
>
> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
