SSH Brute Force attempts

[Rich Healey]

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

Recently I'm getting a lot of brute force attempts on my server, in the
past I've used various tips and tricks with linux boxes but many of them
were fairly linux specific.

What do you BSD guys use for this purpose?

If this belongs on -security let me know and I'll ask over there.

Cheers


Rich
- --
Rich Healey - iTReign      \    .''`.   /         healey.rich@...
Developer / Systems Admin   \  : :' :  /        healey.rich@...
AIM: richohealey33           \ `. `'  /             richo@...
MSN: bitchohealey@... \  `-  / richohealey@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjhbpMACgkQLeTfO4yBSAf36QCdE2cI75OAmyODre33sPPMrA8j
3VYAn3aHl1w5qyynd4rfYuxxqI6b2tAF
=plT2
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Jeremy Chadwick-3]

On Tue, Sep 30, 2008 at 10:10:59AM +1000, Rich Healey wrote:
> Recently I'm getting a lot of brute force attempts on my server, in the
> past I've used various tips and tricks with linux boxes but many of them
> were fairly linux specific.
>
> What do you BSD guys use for this purpose?

This probably should've gone to -security, correct.

There are 3 ports which people often use for solving this:

ports/security/blocksshd
ports/security/sshblock
ports/security/sshguard-(pf|ipfw|ipfilter)

The latter depends on which firewalling stack you use, and I believe
one of the other two only work with ipfw (I forget which).

I have great reservations using any of these, because they dynamically
add firewalling rules/tables to your machines based on data in log
files.  For me, it smells of an accident waiting to happen.

I'm an advocate of simply blocking large netblocks where most of these
attacks come from (Latin America, eastern Europe, Asia, and Russia).
This requires that you appropriately tune things over time, and *be
intelligent* about what you're doing.  :-)

What we use in our pf.conf on our production systems:

table <ssh-allow> persist file "/conf/ME/pf.conf.ssh-allow"
table <ssh-deny> persist file "/conf/ME/pf.conf.ssh-deny"

block in on $ext_if proto tcp from <ssh-deny> to any port ssh
pass  in on $ext_if proto tcp from <ssh-allow> to any port ssh flags S/SA keep state

pf.conf.ssh-deny contains a list of IPs or CIDRs which are to be
blocked.  I can provide this file if desired.

pf.conf.ssh-allow contains a list of IPs or CIDRs which "override"
blocks in the previous "block" rule.  The reason we have this is due to
one Russian user who wasn't able to SSH into our boxes due to the
previous block rule.

You naturally have to keep pf.conf.ssh-* in sync if you have multiple
machines.  You can use pfsync(4) to accomplish this task (I think), or
you can do it the obvious way (make a central distribution box that
scp/rsync's the files out and runs "/etc/rc.d/pf reload").

--
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Bill Moran-2]

Rich Healey <healey.rich@...> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Recently I'm getting a lot of brute force attempts on my server, in the
> past I've used various tips and tricks with linux boxes but many of them
> were fairly linux specific.
>
> What do you BSD guys use for this purpose?
>
> If this belongs on -security let me know and I'll ask over there.

http://potentialtech.com/cms/node/16

--
Bill Moran
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

On Monday 29 September 2008, Rich Healey <healey.rich@...> sent a
missive stating:

> Recently I'm getting a lot of brute force attempts on my server, in the
> past I've used various tips and tricks with linux boxes but many of them
> were fairly linux specific.
>
> What do you BSD guys use for this purpose?
>
> If this belongs on -security let me know and I'll ask over there.
>
> Cheers
>
>
> Rich

Yeap, -security

However, also try this in pf.conf (specific rules related to this; you'll need
more for a real pf.conf):

table <badguys> { } persist
block in quick from <badguys>
pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
(max-src-conn 5, max-src-conn-rate 4/300, overload <badguys> flush global)

This will add "badguys" to the table if they connect more then 4 times in 300
seconds.

Then use the expiretables port from a cronjob to remove IPs if you feel like
it.


Henrik
--
Henrik Hudson
rhavenn@...
------------------------------
"There are 10 kinds of people in the world: Those who
 understand binary and those who don't..."
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Glenn Sieb]

Rich Healey said the following on 9/29/08 8:10 PM:
> Recently I'm getting a lot of brute force attempts on my server, in the
> past I've used various tips and tricks with linux boxes but many of them
> were fairly linux specific.
>
> What do you BSD guys use for this purpose?
>
> If this belongs on -security let me know and I'll ask over there.

Hi Rich!

I use DenyHosts (/usr/ports/security/denyhosts) and it works great.. :)

Best,
--Glenn

--
...destination is merely a byproduct of the journey
           --Eric Hansen

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Lars Engels-2]

Quoting Rich Healey <healey.rich@...>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Recently I'm getting a lot of brute force attempts on my server, in the
> past I've used various tips and tricks with linux boxes but many of them
> were fairly linux specific.
>
> What do you BSD guys use for this purpose?
>
> If this belongs on -security let me know and I'll ask over there.

Just do not use password authentication but public key authentication  
and a reasonable passphrase on it.

[Matthew Seaman-2]

Jeremy Chadwick wrote:

> You naturally have to keep pf.conf.ssh-* in sync if you have multiple
> machines.  You can use pfsync(4) to accomplish this task (I think), or
> you can do it the obvious way (make a central distribution box that
> scp/rsync's the files out and runs "/etc/rc.d/pf reload").

pfsync sychronises the dynamic state sessions between machines -- ie.
basically what you see by doing 'pfctl -ss'  It doesn't as far as I
know synchronise table contents even if the table changes are themselves
dynamically generated in response to traffic.  rsync is your friend
here.

As for blocking based on geographical source of IPs -- I see where
you're coming  from, but you've missed out one of the largest
territories that is the source of this sort of thing, namely the
USA.

The best strategy IMHO is to foil the automated password guessers
but not using passwords.  SSH key based auth works nicely, is easy to
setup and use and is unfeasible to break by trial and error across a
remote network connection.  Using firewall blocking on top of this
is still useful (to reduce the noise in the log files and stop system
resources being sucked up by SSH's crypto requirements) but it shouldn't
be a necessity.

        Cheers,

        Matthew

--
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

[Bob Bishop]

Hi,

On 30 Sep 2008, at 01:10, Rich Healey wrote:

> Recently I'm getting a lot of brute force attempts on my server, in  
> the
> past I've used various tips and tricks with linux boxes but many of  
> them
> were fairly linux specific.
>
> What do you BSD guys use for this purpose?

[various solutions proposed]

I too would worry about having something automatically updating filter  
rulesets. An alternative is to blackhole route the offending source, eg:

route -nq add -host a.b.c.d 127.0.0.1 -blackhole

WHatever solution you adopt, the ability to whitelist is a very good  
idea (especially if you are as inaccurate a typist as I am). And I'd  
second what others have said about avoiding passwords altogether if  
it's possible in your situation.

--
Bob Bishop          [phone]
rb@...    fax [phone]
            mobile [phone]





_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Jeroen Ruigrok van der Werven-3]

-On [20080930 05:14], Rich Healey (healey.rich@...) wrote:
>What do you BSD guys use for this purpose?

I actually use blockhosts, which is a Python solution you tie into
hosts.allow.

http://www.aczoom.com/cms/blockhosts

--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Happiness is the absence of the striving for happiness...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Ollivier Robert]

According to Henrik Hudson:
> Yeap, -security
>
> However, also try this in pf.conf (specific rules related to this; you'll need
> more for a real pf.conf):
>
> table <badguys> { } persist
> block in quick from <badguys>
> pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
> (max-src-conn 5, max-src-conn-rate 4/300, overload <badguys> flush global)

That one is very effective.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@...
Darwin sidhe.keltia.net Version 9.4.0: Mon Jun  9 19:30:53 PDT 2008; i386

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Oliver Fromme]

Rich Healey wrote:
 > Recently I'm getting a lot of brute force attempts on my server, in the
 > past I've used various tips and tricks with linux boxes but many of them
 > were fairly linux specific.
 >
 > What do you BSD guys use for this purpose?

There's nothing that replaces using either *good* passwords
or *no* passwords at all (i.e. ssh keys instead).

I completely agree with Jeremy Chadwick that using programs
that change your packet filter rules automatically can be
dangerous.  I recommend against this.  Especially it does
not protect you if you have weak passwords.  In fact it
might open a hole that someone can successfully run a DoS
attack against your machine by spoofing one of your own IP
addresses, or the IP address of your upstream router, or
DNS server, or whatever.

If you're merely annoyed about the large amount of logging
entries caused by the break-in attempts, a good solution
is to move the sshd service from the standard port 22 to a
different, non-standard port (e.g. 222 or whatever, but it
should be a "reserved" port, i.e. less than 1024 which is
the default high limit for the reserved port range).  Most
attackers are just "script kiddies" that use automated
software that tries only port 22.  You can put an entry
in ~/.ssh/config on your client machines so you don't even
have to remember to specify the port number when ssh'ing
to your server.

Alternatively you can configure sshd to listen on port 22
*and* an alternate port, and block port 22 for everything
except a few known-good addresses or networks.  That way
you don't have to do anything special when connecting from
any of your usual clients, but you can still connect from
anywhere else if necessary by using the non-standard port.

Of course, the non-standard port trick is *not* a security
measure.  It only makes your machine "a little bit more
invisible" to script kiddies and prevents them from filling
your log files.  It might also give you a very small
advance in case of zero-day attacks.  It does *not* help
against weak passwords or lazyness to patch known holes,
or other kinds of operator failure.

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"What is this talk of 'release'?  We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake."
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Jeremy Chadwick-3]

On Tue, Sep 30, 2008 at 09:56:32AM +0200, Jeroen Ruigrok van der Werven wrote:
> -On [20080930 05:14], Rich Healey (healey.rich@...) wrote:
> >What do you BSD guys use for this purpose?
>
> I actually use blockhosts, which is a Python solution you tie into
> hosts.allow.
>
> http://www.aczoom.com/cms/blockhosts

In no way shape or form does this solve the problem of the attackers
being able to establish a TCP connection to you -- they are still tying
up sockets, mbufs, and extra network I/O (coming from you when you
respond and close the socket).

TCP wrappers are absolutely 100% worthless in this day and age.

--
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Dag-Erling Smørgrav]

Oliver Fromme <olli@...> writes:
> If you're merely annoyed about the large amount of logging entries
> caused by the break-in attempts, a good solution is to move the sshd
> service from the standard port 22 to a different, non-standard port

The best choice is 443, as many corporate firewalls, especially "guest"
wifi networks, block all but a few ports (usually 22, 80 and 443, and
sometimes 25).

There are other, more complicated tricks you can play; for instance, you
could set up a web server on the box, and configure it to tunnel SSH
using the HTTP Upgrade header; this would require modifications to both
ssh (to send the initial HTTP request) and sshd (to take over the
connection from the web server).

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Oliver Fromme]

Ollivier Robert <> wrote:
 > According to Henrik Hudson:
 > > Yeap, -security
 > >
 > > However, also try this in pf.conf (specific rules related to this; you'll need
 > > more for a real pf.conf):
 > >
 > > table <badguys> { } persist
 > > block in quick from <badguys>
 > > pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
 > > (max-src-conn 5, max-src-conn-rate 4/300, overload <badguys> flush global)
 >
 > That one is very effective.

It's especially effective to enable to DoS you.
An attacker simply has to spoof the source address
on SYN packets, which is trivial.  :-(

It is marginally better to use one of those tools
that parse the logs for failed ssh logins, and use
that information to block addresses.  In order to
abuse that, and attacker would have to spoof a full
TCP connection setup plus initial SSH conversation,
which is far from trivial.

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Perl will consistently give you what you want,
unless what you want is consistency."
        -- Larry Wall
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Matthew Seaman-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Oliver Fromme wrote:
| Ollivier Robert <> wrote:
|  > According to Henrik Hudson:
|  > > Yeap, -security
|  > >
|  > > However, also try this in pf.conf (specific rules related to this; you'll need
|  > > more for a real pf.conf):
|  > >
|  > > table <badguys> { } persist
|  > > block in quick from <badguys>
|  > > pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
|  > > (max-src-conn 5, max-src-conn-rate 4/300, overload <badguys> flush global)
|  >
|  > That one is very effective.
|
| It's especially effective to enable to DoS you.
| An attacker simply has to spoof the source address
| on SYN packets, which is trivial.  :-(

Adding a whitelist of ssh addresses that should never be blocked is equally
trivial....

But, like the perl folk say: TIMTOWTDI.

        Cheers,

        Matthew

- --
Dr Matthew J Seaman MA, D.Phil.                       Flat 3
~                                                      7 Priory Courtyard
PGP: http://www.infracaninophile.co.uk/pgpkey         Ramsgate
~                                                      Kent, CT11 9PW, UK
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREDAAYFAkjiQKsACgkQ3jDkPpsZ+VbzsgCfY64vNfuMhRrGRYgK4rDawWq4
xDwAnRMXY54hiooKCFBp7U/SxILUsxsa
=yQm5
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Daniel Gerzo-3]

Hello guys,

On Mon, 29 Sep 2008 20:30:33 -0700, Jeremy Chadwick <koitsu@...>
wrote:

> On Tue, Sep 30, 2008 at 10:10:59AM +1000, Rich Healey wrote:
>> Recently I'm getting a lot of brute force attempts on my server, in the
>> past I've used various tips and tricks with linux boxes but many of them
>> were fairly linux specific.
>>
>> What do you BSD guys use for this purpose?
>
> This probably should've gone to -security, correct.
>
> There are 3 ports which people often use for solving this:
>
> ports/security/blocksshd
> ports/security/sshblock
> ports/security/sshguard-(pf|ipfw|ipfilter)

There's also a tool written by me which can be found in
security/bruteforceblocker - you may read a bit about it on
http://danger.rulez.sk/index.php/bruteforceblocker/.

The official release currently works only with pf, but I know there's a
person working towards porting it to ipf/ipfw. He recently ported it to
iptables and added CIDR support for whitelists, but I haven't had a time to
review his changes, however once I get to it I will release a new version.

--
Best regards
  Daniel Geržo

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Pierre Riteau-3]

On Tue, Sep 30, 2008 at 04:01:26PM +0200, Oliver Fromme wrote:

> Ollivier Robert <> wrote:
>  > According to Henrik Hudson:
>  > > Yeap, -security
>  > >
>  > > However, also try this in pf.conf (specific rules related to this; you'll need
>  > > more for a real pf.conf):
>  > >
>  > > table <badguys> { } persist
>  > > block in quick from <badguys>
>  > > pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
>  > > (max-src-conn 5, max-src-conn-rate 4/300, overload <badguys> flush global)
>  >
>  > That one is very effective.
>
> It's especially effective to enable to DoS you.
> An attacker simply has to spoof the source address
> on SYN packets, which is trivial.  :-(

This is not true. pf.conf(5) says:

     For stateful TCP connections, limits on established connections (connec-
     tions which have completed the TCP 3-way handshake) can also be enforced
     per source IP.

     max-src-conn <number>
           Limits the maximum number of simultaneous TCP connections which
           have completed the 3-way handshake that a single host can make.
     max-src-conn-rate <number> / <seconds>
           Limit the rate of new connections over a time interval.  The con-
           nection rate is an approximation calculated as a moving average.

     Because the 3-way handshake ensures that the source address is not being
     spoofed, more aggressive action can be taken based on these limits.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."