Any objection to installing fail2ban on the adhoc VM? It's a
daemon which watches /var/log/auth.log and if an IP has more than
say 6 failed paswd ssh attempts in say 10 minutes, it alters
the firewall rules to drop traffic from them for (say) 10 minutes.
Effectively it stops brute force paswd attacks but is not too
harsh on forgetful and butter-fingered users.
Perhaps installing portsentry and more fine-grained firewalls in
general could be explored? stronger encouragement of public/
private key use?
Also I'd suggest to check that /etc/ssh/sshd_config contains
PermitRootLogin no
But I'm not sure if OSUOSL or anyone is using that?
Compared to some of my other systems, the failed ssh attempts on
adhoc are not so high, but they still dwarf the number of real
user logins:
118 Apr 24
7071 Apr 25
342 Apr 26
2 Apr 27
39 Apr 29
2203 Apr 30
1 May 1
563 May 4
61 May 5
1 May 6
9 May 7
4 May 8
38 May 9
429 May 11
33 May 12
22 May 13
1 May 14
264 May 15
1 May 16
1403 May 17
1 May 19
493 May 20
130 May 21
274 May 22
72 May 23
19 May 25
477 May 26
334 May 27
I brought up the Root login question when we did the setup of the VMs.
Root doesn't actually have a password (afaik) and most OSGeo SAC members
can only get to it via ssh keys that were installed on the system. So
while I'm not in love with Root login via ssh, we don't have console
access to the VMs so it would pose an issue when LDAP is down.
Thanks,
Alex
On 05/27/2011 05:24 PM, Hamish wrote:
Hi,
Any objection to installing fail2ban on the adhoc VM? It's a
daemon which watches /var/log/auth.log and if an IP has more than
say 6 failed paswd ssh attempts in say 10 minutes, it alters
the firewall rules to drop traffic from them for (say) 10 minutes.
Effectively it stops brute force paswd attacks but is not too
harsh on forgetful and butter-fingered users.
Perhaps installing portsentry and more fine-grained firewalls in
general could be explored? stronger encouragement of public/
private key use?
Also I'd suggest to check that /etc/ssh/sshd_config contains
PermitRootLogin no
But I'm not sure if OSUOSL or anyone is using that?
Compared to some of my other systems, the failed ssh attempts on
adhoc are not so high, but they still dwarf the number of real
user logins:
118 Apr 24
7071 Apr 25
342 Apr 26
2 Apr 27
39 Apr 29
2203 Apr 30
1 May 1
563 May 4
61 May 5
1 May 6
9 May 7
4 May 8
38 May 9
429 May 11
33 May 12
22 May 13
1 May 14
264 May 15
1 May 16
1403 May 17
1 May 19
493 May 20
130 May 21
274 May 22
72 May 23
19 May 25
477 May 26
334 May 27
I brought up the Root login question when we did the setup of the VMs.
Root doesn't actually have a password (afaik) and most OSGeo SAC members
can only get to it via ssh keys that were installed on the system. So
while I'm not in love with Root login via ssh, we don't have console
access to the VMs so it would pose an issue when LDAP is down.
I am supportive of installing fail2ban if someone is willing to take the
action item. I'm not inclined to changing the root login arrangements for
the reasons Alex explains.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
> +1 on fail2ban
>[...]
> So while I'm not in love with Root login via ssh, we
> don't have console access to the VMs so it would pose an
> issue when LDAP is down.
Frank:
I am supportive of installing fail2ban if someone is
willing to take the action item.
now installed on the adhoc VM, and already doing its job.
I added 127.0.1.1 to the ignoreip list in jail.conf as that's
added as a dummy IP for `hostname` in recent Debians & Ubuntus
in the /etc/hosts file (so that `hostname` always resolves to
something; mostly useful for laptops which go off-line a lot but
still need to resolve; fixed IPs may replace that with a hard-
coded version)
one FAQ gotcha I ran into is that before running the init.d
script I had to "unset TZ" (as me), otherwise the following
sudo caused the log file time-stamps to be hours out of sync
and the program not to work.
I would suggest that others have a peek at /var/log/auth.log on
the other VMs for many thousands of 'Failed password' per day,
and deploy there as appropriate. (I don't have the necessary
sac'ness to do that myself)
I'm not inclined to changing the root login arrangements for
the reasons Alex explains.
ok.
Another tool to consider is `portsentry`, which detects port
scans and blackholes the IPs of those trying the locks. It is
both more dumb and more harsh than fail2ban (knock on port "x"
and you get banned, and firewall rules persist until reboot, vs.
fail2ban's forgiveness fuse) so I do not propose to use it for
the osgeo VMs right now, but I wonder if variants or hacks of
that might be better. Or do we just firewall everything then open
ports 22, 80, etc as needed?
On Wed, Jun 01, 2011 at 04:07:09PM -0700, Hamish wrote:
[...] Or do we just firewall everything then open > ports 22, 80, etc
as needed?
What about the idea of simply not running any services you don't need
to have public access to ? No service -> no need to block a port.
At least that's what I've been doing quite successfully for years ....
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------