
Fail2ban security update - TimWolla
https://lists.debian.org/debian-security-announce/2014/msg00161.html
======
knyt
Unrelated to this disclosure, I have acquired quite a lot of Fail2Ban attack
reports generated by hosts around the world. I put together an initial set of
charts showing attacks by country; I was wondering if anyone had any ideas for
interesting things that should be done to analyze/visualize the data.

The data set contains the IP addresses for attacker and victim, the date, and
the service name for each of a couple million attack reports.

edit: [https://int80k.com/ftb/](https://int80k.com/ftb/)

~~~
thaumaturgy
I wouldn't mind seeing that; your data eclipses mine by about a lot.

Plotting your data on a world map would be kinda neat. D3.js is a good tool
for that. Animate it over time for even more bonus points. :-)

Or, scrub your information from the data and post it for others to mess with.

I have several thousand entries for ssh, ssh-root, and spam abuse in my
badhosts table.

~~~
knyt
I think that change over time could be pretty cool, especially if the host
locations can be resolved down to the city or province. I'll check out D3.js.

I did a first take using Kartograph:
[https://int80k.com/ftb/](https://int80k.com/ftb/)

~~~
thaumaturgy
Nice.

And I see now why you're not wanting to release the data: I thought this was
data on your network. Good job grabbing that email address.

------
NickSharp
In case anyone needs it, here is the command line to patch fail2ban:

sudo apt-get update

sudo apt-get install --only-upgrade fail2ban

Although it's considered best practice to upgrade all packages, like this:

sudo apt-get update

sudo apt-get upgrade

~~~
stevekemp
Note that Debian release do not install sudo by default, unlike Ubuntu.

So if you have not installed sudo, or do not have permission to use it, then
you should use "su - " to become root, then run "apt-get update;apt-get
upgrade".

------
daviddede
Not new:

[http://dcid.me/texts/attacking-log-analysis-
tools.html](http://dcid.me/texts/attacking-log-analysis-tools.html)

It had a similar vuln many years ago.

------
kolev
You don't need fail2ban, you need fwknop.

~~~
TimWolla
The problem is that you need a static IP address for fwknop, if I understood
the manual correctly.

~~~
akerl_
Nope, there is no need for a static IP on either end.

------
whiteagle
Thank you for this, I'll better start upgrading my servers...

------
sneak
Fail2ban is fundamentally a wrong answer to the problem. If you're taking the
time to install such things, you should instead either be turning off password
authentication (relying only on keys) or shorewall (to default deny ssh access
except to authorized subnets) or both.

Waiting for multiple authentication failures to mark a host/net as "bad" is
fundamentally a bad idea. Stop using passwords.

~~~
WestCoastJustin
How do you manage ssh keys once deployed? From personal experience using both
systems, my thinking is that once you start deploying ssh keys, in a larger
user/server environment, you have a massive rats nest. There is little to no
life cycle management.

Fail2ban works and should be deployed regardless of whether you are using
usernames/passwords or keys. I just checked one of our bastion hosts, and
there are 384 banned IPs (on a rolling 30 day basis). This info is useful, and
can be fed into other systems, like edge network devices.

There is actually a good article about this @
[http://www.networkworld.com/article/2164048/tech-
primers/ssh...](http://www.networkworld.com/article/2164048/tech-primers/ssh-
key-mismanagement-and-how-to-solve-it.html)

~~~
viraptor
That's one weird article (or maybe people really do that... I would hope they
don't):

> mesh of key-based access is so dense that it is highly likely that an attack
> can spread to nearly all servers in an organization

Why would you ever do that? Keep the keys where the users are. There is no
mesh unless you distribute the private keys and you should never do that in
the first place. ssh-agent can be used if you really need to have multiple
hops.

> odds are the virus will infect nearly all servers [...] including disaster
> recovery and backup systems that are typically also managed using such keys

Why would you store private keys to your DR/backup servers all over the place?
Backup is safer if it works via pull.

There are problems with SSH key management, but the situation they describe
looks like there are issues with the design in general.

(as for the keys management - there are many solutions allowing reading public
keys from ldap - that solves some of the problems)

~~~
lloeki
> ssh-agent can be used if you really need to have multiple hops.

Possibly you mean, in one's ~/.ssh/config:

    
    
        Host *.trusted.hosts another.one.trusted
            ForwardAgent yes
    

The restriction with Host is that otherwise an untrusted host (or someone
having compromised your remote account) could use your agent forwarding socket
to identify as you.

