Re: SSHBrute Force: False Postives

Re: SSHBrute Force: False Postives

[Lpct]

--------- Mensagem Original --------
De: Dominic Caputo <jec6jec6@gmail.com>
Para: netfilter@lists.netfilter.org <netfilter@lists.netfilter.org>
Asunto: SSHBrute Force: False Postives
Fecha: 01/02/07 02:30

>
> 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
&quot;SSH Brute
> Force Attempt:  &quot;
> $IPTABLES -A SSH_Brute_Force -p tcp -j DROP
>
> Any help with this problem would be great
>
> Dominic
>
.... you can start changing the ssh port from 22 to xxx... this doesnt solve
your problem, but this mesure minimize this kind of attack like a 70%
________________________________________________
linux.pctools.cl

SSHBrute Force: False Postives

[Dominic Caputo]

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

Dominic

Re: SSHBrute Force: False Postives

[Wakko Warner]

Dominic Caputo 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

I do it a little differently:
I have a chain called "internet" which is basically jumped to from INPUT and
FORWARD if the card it came in on is the one facing the internet.  Prepend
iptables to the following lines (I still use iptables-restore)

-A internet -j ACCEPT -m conntrack --ctstate ESTABLISHED
... <other rules>
-A internet -j REJECT -m recent --update --seconds 600 --reject-with icmp-admin-prohibited
... <other rules>
-A internet -j ACCEPT -p tcp -m limit --limit 5/min --dport 22
-A internet -j LOG -p tcp --dport 22 --log-prefix "SSH FLOOD:"
-A internet -j REJECT -p tcp -m recent --set --dport 22 --reject-with icmp-admin-prohibited

This allows 5 new connections to port 22 in a minute.  After which, that
rule no longer matches and goes to the next rule.  Then the packet is logged
once and then the recent module is updated with the perpetrator's IP and the
2nd rule above catche it.  They have to be quiet for 10 minutes before they
are allowed to attempt again.

This works very well for me since I don't have many people sshing into me
that often.  I went from ~1000 lines in my logs to about 30.

I also add IPs when someone connects to various other ports that are common
attacks so I would probably never see an SSH attack from them.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: SSHBrute Force: False Postives

[Wakko Warner]

franck joncourt wrote:
> In order to prevent such attacks, you can write iptables rules to set up port knocking. This is the way, I do.

I thought about doing this, but I ultimately decided against it.  The
problems of doing the knocking outweighted the benefits.  I prefer to let
them try a few times before my current rules ban them.

--
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: SSHBrute Force: False Postives

[Michael Rash]

On Feb 01, 2007, Wakko Warner wrote:

> franck joncourt wrote:
> > In order to prevent such attacks, you can write iptables rules to set up port knocking. This is the way, I do.
> 
> I thought about doing this, but I ultimately decided against it.  The
> problems of doing the knocking outweighted the benefits.  I prefer to let
> them try a few times before my current rules ban them.

If someone finds a remote exploit in sshd, then just allowing
connections at all can potentially expose you to compromise.  As far as
port knocking is concerned, I agree, there are a ton of problems.  There
is a better alternative called Single Packet Authorization:

http://www.cipherdyne.org/fwknop/docs/SPA.html

Fwknop is an implementation that is based around iptables:

http://www.cipherdyne.org/fwknop/

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

Re: SSHBrute Force: False Postives

[Wakko Warner]

Michael Rash wrote:
> > franck joncourt wrote:
> > > In order to prevent such attacks, you can write iptables rules to set up port knocking. This is the way, I do.
> > 
> > I thought about doing this, but I ultimately decided against it.  The
> > problems of doing the knocking outweighted the benefits.  I prefer to let
> > them try a few times before my current rules ban them.
> 
> If someone finds a remote exploit in sshd, then just allowing
> connections at all can potentially expose you to compromise.  As far as

True.

> port knocking is concerned, I agree, there are a ton of problems.  There
> is a better alternative called Single Packet Authorization:
> 
> http://www.cipherdyne.org/fwknop/docs/SPA.html
> 
> Fwknop is an implementation that is based around iptables:
> 
> http://www.cipherdyne.org/fwknop/

This still means that all authorized users have to do this which is not what
I want to do.  What if I'm at someone's house and decide I want in to my
system and they don't have any way of performing the port knocking or the
fwknop.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: SSHBrute Force: False Postives

[franck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wakko Warner wrote:
> Michael Rash wrote:
>>> franck joncourt wrote:
>>>> In order to prevent such attacks, you can write iptables rules to set up port knocking. This is the way, I do.
>>> I thought about doing this, but I ultimately decided against it.  The
>>> problems of doing the knocking outweighted the benefits.  I prefer to let
>>> them try a few times before my current rules ban them.
>> If someone finds a remote exploit in sshd, then just allowing
>> connections at all can potentially expose you to compromise.  As far as
> 
> True.
> 
>> port knocking is concerned, I agree, there are a ton of problems.  There
>> is a better alternative called Single Packet Authorization:
>>
>> http://www.cipherdyne.org/fwknop/docs/SPA.html
>>
>> Fwknop is an implementation that is based around iptables:
>>
>> http://www.cipherdyne.org/fwknop/
> 
> This still means that all authorized users have to do this which is not what
> I want to do.  What if I'm at someone's house and decide I want in to my
> system and they don't have any way of performing the port knocking or the
> fwknop.
> 

According to me, the only way to safely use ssh without having any
sequence to perform, is the use of private/public key with passphrase.

I have already heard about encrypted knocks, and this one seems great. I
will give it a try.

- --
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF  9A3C C490 534E 75C0 89FE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFw6GAxJBTTnXAif4RAvVCAKDPqJCbdfkwUY/BBqB5wbsVLWJqlwCgq3/3
jv30ZCnHgUxBAy25ekdnmBw=
=x2og
-----END PGP SIGNATURE-----

		
___________________________________________________________ 
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

Re: SSHBrute Force: False Postives

[fender]

On 1/31/07, Dominic Caputo <jec6jec6@gmail.com> 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

Re: SSHBrute Force: False Postives

[Brad Lhotsky]

Here's what I do:

1) Add a group on your system that all shell users are a part of.  For
me, this group was called 'shellaccess' and root was _not_ in the group.
2) Create an public/private key pair for root.  (man ssh-keygen, I
recommend -t rsa -b 2048)
3) Install the public key in ~root/.ssh/authorized_keys
4) Add these lines to your sshd_config:
  # Root can only authenticate with keys
  PermitRootLogin without-password
  AllowGroup shellaccess
5) create a table that all traffic passes through, I use SSHD
  iptables -N SSHD
  iptables -I INPUT -j SSHD
6) download and install sec.pl (search google)
7) configure sec.pl to automatically block ip addresses after 5
unsuccessful login attempts by using a badhost script, here's mine:

#!/bin/bash
#
# Block a Host

IPTABLES=/usr/local/sbin/iptables
CHAIN=SSHD
INTOCHAIN="INPUT"

LINE=`${IPTABLES} -nL|grep Chain |grep $CHAIN |wc -l`
HOST=$1

#
# Add the  Rule
if [ $LINE == 0 ]; then
        $IPTABLES -N $CHAIN
fi;

#
# Add to the main chain
LINE=`${IPTABLES} -nL ${INTOCHAIN}|grep $CHAIN|wc -l`
if [ $LINE == 0 ]; then
        $IPTABLES -I $INTOCHAIN -j $CHAIN
fi;


#
# Check for the IP in the rule:
LINE=`${IPTABLES} -nL ${CHAIN}|grep $HOST|wc -l`
if [ $LINE == 0 ]; then
        $IPTABLES -I $CHAIN -s $HOST -j DROP
fi;


If you want to get more creative, fine.  This setup has worked for me by
 limiting the accounts that can be accessed over ssh, eliminating the
root password compromise, and actively blocking all machines that will
not quit.

I've looked into tarpitting and expiring those rules in my SSHD table,
but it's never really caused a problem.  There's multiple places I can
connect to my server from, so if I do accidentally block myself, I can
undo it fairly easily.

I'd also recommend that you make sure you have:

Protocol 2

in your sshd_config.

fender wrote:
> On 1/31/07, Dominic Caputo <jec6jec6@gmail.com> wrote:
> 
> 
> 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

-- 
Brad Lhotsky <lhotskyb@grc.nia.nih.gov>
NCTS Computer Specialist
Phone: 410.558.8006
"Freedom, Privacy, Security.  Choose Two."

Re: SSHBrute Force: False Postives

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 1 Feb 2007, fender wrote:

> On 1/31/07, Dominic Caputo <jec6jec6@gmail.com> 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...

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFyOrTst+vzJSwZikRAkjqAJ0TbijLmTG4qZMVl7ZwXQu2cABfLACfRO/0
B78mFQx8+DCkDi/gY0vHgoo=
=dZEg
-----END PGP SIGNATURE-----

Re: SSHBrute Force: False Postives

[franck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

R. DuFresne wrote:

> portknocking is merely security through obscurity, is it not?
> 
> especially so with modules that reside with preset defaults...
> 
> Thanks,
> 
> Ron DuFresne


According to me, changing SSH default port is obscurity, and is not more
secure ; Port knocking is more about preventing people from gaining
access to your machine by improving authentication process, that's it.

- --
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF  9A3C C490 534E 75C0 89FE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFyO8mxJBTTnXAif4RAuxjAJ9IHjWPv4QfKOOiuXLkzSu8bntz3ACfe+ne
BXp0qd1XR73lviZ7NMvBnYs=
=WjOM
-----END PGP SIGNATURE-----

		
___________________________________________________________ 
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

Re: SSHBrute Force: False Postives

[Michael Rash]

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@gmail.com> 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.

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F



> Thanks,
> 
> Ron DuFresne
> - -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         admin & senior security consultant:  sysinfo.com
>                         http://sysinfo.com
> Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629
> 
> ...We waste time looking for the perfect lover
> instead of creating the perfect love.
> 
>                 -Tom Robbins <Still Life With Woodpecker>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> 
> iD8DBQFFyOrTst+vzJSwZikRAkjqAJ0TbijLmTG4qZMVl7ZwXQu2cABfLACfRO/0
> B78mFQx8+DCkDi/gY0vHgoo=
> =dZEg
> -----END PGP SIGNATURE-----

Re: SSHBrute Force: False Postives

[fender]

On 2/6/07, Michael Rash <mbr@cipherdyne.org> 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@gmail.com> 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

Re: SSHBrute Force: False Postives

[Michael Rash]

On Feb 08, 2007, fender wrote:

> On 2/6/07, Michael Rash <mbr@cipherdyne.org> 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@gmail.com> 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.

fwknop also implements simple port knocking, but IMHO both the security
properties and the general architecture of SPA warrant calling it
something besides "port knocking".

Technically, port knocking refers to the transmission of
authentication information within packet headers instead of application
layer data (at least if you agree with the definition given to port
knocking by the person who coined the term, Martin Krzywinski).

> 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 ;)

That's cool.  It is also worth noting however that there are some
advantages to having a userspace daemon over an in-kernel
implementation:

- The best encryption algorithms (and implementations of those algorithms)
  can be supported; both asymmetric and symmetric (fwknop supports GnuPG
  and Rijndael).

- Additional authentication requirements can be met, such as
  communicating with an LDAP server or even just checking if the remote
  user possesses a valid crypt() password (fwknop supports crypt()
  checking now, and more checks are being developed).

- Timeout-based ACCEPT rules can be managed by the userspace daemon.
  Fwknop uses a dedicated chain for all rules that it creates/destroys,
  and it uses a single well defined interface to create and destroy
  those rules.

- The client can dictate complex access requirements to the server, and
  the server can filter these requirements with granular precision.
  Once strong encryption is used and non-replayability is ensured,
  nothing prohibits even a full command channel over SPA.

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

Re: SSHBrute Force: False Postives

[fender]

On 2/8/07, Michael Rash <mbr@cipherdyne.org> wrote:
> On Feb 08, 2007, fender wrote:
>
> > On 2/6/07, Michael Rash <mbr@cipherdyne.org> 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@gmail.com> 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.
>

[snip]

> Technically, port knocking refers to the transmission of
> authentication information within packet headers instead of application
> layer data (at least if you agree with the definition given to port
> knocking by the person who coined the term, Martin Krzywinski).

Portknocko project implements SPA within UDP header.

> > 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 ;)
>
> That's cool.  It is also worth noting however that there are some
> advantages to having a userspace daemon over an in-kernel
> implementation:
>
> - The best encryption algorithms (and implementations of those algorithms)
>   can be supported; both asymmetric and symmetric (fwknop supports GnuPG
>   and Rijndael).

IMHO this is not an adventage in favor of user space applications.
You talk about a good but complicated solution to ssh brute force
attacks. It needs of a daemon, configuration files and a new syntax.

We give a simple and secure solution in kernel space. Also it allows
you to configure your firewall through iptables rules. This is an
adventage over all port knocking user space applications.

> - Additional authentication requirements can be met, such as
>   communicating with an LDAP server or even just checking if the remote
>   user possesses a valid crypt() password (fwknop supports crypt()
>   checking now, and more checks are being developed).

That's great. But IMHO this is not important when I only want to hide
a public service (such as ssh, ftp, etc) behind a security fence to
avoid brute force attacks.

> - Timeout-based ACCEPT rules can be managed by the userspace daemon.
>   Fwknop uses a dedicated chain for all rules that it creates/destroys,
>   and it uses a single well defined interface to create and destroy
>   those rules.

So, you must install a daemon, and you must learn a new interface to
create iptables rules. Besides, the daemon creates iptables rules on
the fly for me. This is just what we wanted to avoid.

> - The client can dictate complex access requirements to the server, and
>   the server can filter these requirements with granular precision.
>   Once strong encryption is used and non-replayability is ensured,
>   nothing prohibits even a full command channel over SPA.

Our SPA implementation is non-replayable too.
The pknock module (portknocko project) allows you to send a message to
user space through netlink sockets.

Regards,

-- 
Federico