Blacklisting (and blocking) remote sites - blt.tar.gz (0/1)

David Frech nimblemachines at
Thu Dec 27 16:05:28 PST 2007

An easy solution to this problem (suggested by a friend of mine) is
simply to run sshd on a port other than 22.

Within hours of putting a machine on my DSL line it was hammered by
requests - someone from an IP in Moscow tried all day to get in. I'm
not worried about security - the box is set up for pubkey-only access
- but it *is* annoying getting huge log files, and knowing that lots
of cycles are getting used up.

If you don't have heaps of users (I have two ;-) it's quite easy for
them to set up entries in their .ssh/config files with the unusual
port number, so that ssh'ing in isn't annoying. In fact once set up
you don't even think about it any more.


- David

On 12/27/07, Matthew Dillon <dillon at> wrote:
> :Hi all,
> :
> :you probably also get your logfiles flooded with lines reporting
> :failed login attempts via ftp or ssh from remote sites.
> :...
> :
> :So here's my homebrewed blacklisting toolset, consisting of just two
> :simple shell scripts and a master configuration file.
> :
> :Enjoy the show
> :
> :--Joerg
>     Cool stuff... I like the variable names you chose.
>     There are two issues that I see.  The first is that the hosts.allow
>     file can potentially become huge... thousands or tens of thousands
>     of entries (or more) if you are attacked, and that could be used as a
>     denial of service attack against regular operations.   every connect()
>     to your box will search the file.
>     The second is that I'm not sure it is safe to insert the strings
>     you are greping out of the BLACKLIST file (thrown into your
>     PISSNELKE variable) directly into the hosts.allow file like that.
>     You need to sanitize the contents of PISSNELKE before you can embed
>     it or you will be vulnerable to reverse DNS insertion attacks.  For
>     example, what would happen if $PISSNELKE contained a ':' ?  Or a
>     wildcard?
>     I'd like to see those connections denied too but the next best thing
>     is to not use passwords at all.... use ssh only for all machine access,
>     like we do on (and every other machine I manage,
>     including my personal boxes).
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at>

If I have not seen farther, it is because I have stood in the
footsteps of giants.

More information about the Users mailing list