On 2/6/07, Michael Rash <mbr@xxxxxxxxxxxxxx> wrote:
On Feb 06, 2007, R. DuFresne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 1 Feb 2007, fender wrote:
>
> >On 1/31/07, Dominic Caputo <jec6jec6@xxxxxxxxx> wrote:
> >>I have been reading up on iptables and i am by no means an expert but i
> >>have
> >>a problem with SSH brute force attacks on port 22. I am currently using
> >>the
> >>config below to minimise these threats but i am constantly getting false
> >>positives (logs actually say that my connection has been flagged as a
> >>brute
> >>force connection even on the on the first attempt-but then on others it
> >>connects first time with no problems)
> >>
> >>#SSH Brute-Force Scan Check
> >>$IPTABLES -N SSH_Brute_Force
> >>$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name
> >>SSH --set --rsource -j SSH_Brute_Force
> >>$IPTABLES -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount
> >>4 --name SSH --rsource -j ACCEPT
> >>$IPTABLES -A SSH_Brute_Force -j LOG --log-level info --log-prefix "SSH
> >>Brute
> >>Force Attempt: "
> >>$IPTABLES -A SSH_Brute_Force -p tcp -j DROP
> >>
> >>Any help with this problem would be great
> >
> >
> >About the problem with ssh brute force attacks, you can use portknocking
> >[1]. There are several portknocking projects, but you can use
> >portknocko project [2]. This is a netfilter module that implements
> >portknocking in an easy way. This module works in kernel 2.6.15, for
> >now. It will work in newer versions soon. We need more feedback about
> >this project.
> >
> >We will be thankful for your comments.
> >
> >
> >[1] http://www.portknocking.org
> >[2] http://portknocko.berlios.de
> >
> >--
> >Federico
> >
>
> portknocking is merely security through obscurity, is it not?
>
> especially so with modules that reside with preset defaults...
Section 4.1 of the following document provides a good argument for why
port knocking is not security through obscurity:
http://web.mac.com/s.j/iWeb/Security/Port%20Knocking%20and%20Single%20Packet%20Authorization/Port%20Knocking%20and%20Single%20Packet%20Authorization_files/An%20Analysis%20of%20Port%20Knocking%20and%20Single%20Packet%20Authorization%20%28Sebastien%20J.%20-%20ISG%202006%29_1.pdf
(Sorry for the length of that URL).
This argument applies equally well to single packet authorization, and
combine this with other security properties of SPA that are much more
robust that port knocking implementations; SPA is the way to go. In
summary, these properties are:
- SPA does not suffer from the replay problem.
- SPA supports much more data communication (so things like asymmetric
encryption algorithms can be supported).
- SPA cannot be trivially broken just by spoofing a duplicate packet
into the port sequence.
- SPA does not look like a port scan to any intermediate IDS.
The portknocko project implements both security techniques:
portknocking and "SPA". In our opinion, SPA is a portknocking variant,
that is why
we don't make a difference between them.
Usage [1]:
# iptables -P INPUT DROP
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
1) "the simplest way": one rule portknocking:
# iptables -A INPUT -p tcp -m state --state NEW
-m pknock --knockports 2002,2001,2004 --name SSH
-m tcp --dport 22 -j ACCEPT
2) or "the secure way" (or "SPA"): hmac auth with two iptables rules:
# iptables -A INPUT -p udp -m state --state NEW
-m pknock --knockports 2000 --name SSH
--opensecret your_opensecret --closesecret your_closesecret -j DROP
# iptables -A INPUT -p tcp -m state --state NEW
-m pknock --checkip --name SSH -m tcp --dport 22 -j ACCEPT
That's all, without daemons and without configuration files. Just
iptables to configure your firewall rules ;)
Best regards,
[1] http://portknocko.berlios.de/README.html
--
Federico
