[gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Nikos Chantziaras]

Paul Hartman wrote:
> I'm using the online denyhosts synchronization database, I think that
> may negatively affect how often it blocks hosts locally, because it
> waits until it does a remote sync to scan the local file. This is my
> theory. I like the idea of sharing my blocks and taking advantage of
> the blocks of others, but if it renders the program ineffective
> against the IP /actively/ attacking my system, then it's pointless.
> 
> I'm going to turn off the online sharing of denyhosts and see if it
> makes a difference.
> 
> Otherwise I guess I need to set up some kind of local firewall on this
> machine to get any more fine control over the connections.

The shared list of attackers doesn't have anything to do with it. 
Denyhosts checks the logs every X seconds.  I think 30 by default, not 
sure.  In that time, there can be many more attempted logins then the 
maximum you have configured in Denyhosts.

Also, the downloaded list of known attack hosts is copied locally into 
your hosts.deny file.  That's all there is to it.

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Paul Hartman]

On Wed, Jan 21, 2009 at 6:36 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> Paul Hartman wrote:
>>
>> I'm using the online denyhosts synchronization database, I think that
>> may negatively affect how often it blocks hosts locally, because it
>> waits until it does a remote sync to scan the local file. This is my
>> theory. I like the idea of sharing my blocks and taking advantage of
>> the blocks of others, but if it renders the program ineffective
>> against the IP /actively/ attacking my system, then it's pointless.
>>
>> I'm going to turn off the online sharing of denyhosts and see if it
>> makes a difference.
>>
>> Otherwise I guess I need to set up some kind of local firewall on this
>> machine to get any more fine control over the connections.
>
> The shared list of attackers doesn't have anything to do with it. Denyhosts
> checks the logs every X seconds.  I think 30 by default, not sure.  In that
> time, there can be many more attempted logins then the maximum you have
> configured in Denyhosts.
>
> Also, the downloaded list of known attack hosts is copied locally into your
> hosts.deny file.  That's all there is to it.

Then what would cause it to not add a new denied host until after many
many attempts?

I disabled the network sync but denyhosts still takes "forever" before
denying... each IP is able to do hundreds of attempts before getting
added to the hosts.deny file.

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

On Wed, 21 Jan 2009 08:35:08 -0600, Paul Hartman wrote:

> I disabled the network sync but denyhosts still takes "forever" before
> denying... each IP is able to do hundreds of attempts before getting
> added to the hosts.deny file.
> 

I use sshutout to add the address of repeated attempts to iptables. It's
not in portage but you can get it from
http://www.techfinesse.com/sshutout/sshutout.html

-- 
Neil Bothwick

What if there were no hypothetical situations?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Nikos Chantziaras]

Paul Hartman wrote:
> On Wed, Jan 21, 2009 at 6:36 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
>> The shared list of attackers doesn't have anything to do with it. Denyhosts
>> checks the logs every X seconds.  I think 30 by default, not sure.  In that
>> time, there can be many more attempted logins then the maximum you have
>> configured in Denyhosts.
>>
>> Also, the downloaded list of known attack hosts is copied locally into your
>> hosts.deny file.  That's all there is to it.
> 
> Then what would cause it to not add a new denied host until after many
> many attempts?
> 
> I disabled the network sync but denyhosts still takes "forever" before
> denying... each IP is able to do hundreds of attempts before getting
> added to the hosts.deny file.

Can you check the logs to see the timespan in which those hundreds of 
attempts took place?  Also, what's the time interval Denyhosts checks 
for login attempts?

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Paul Hartman]

On Wed, Jan 21, 2009 at 11:53 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> Paul Hartman wrote:
>>
>> On Wed, Jan 21, 2009 at 6:36 AM, Nikos Chantziaras <realnc@arcor.de>
>> wrote:
>>>
>>> The shared list of attackers doesn't have anything to do with it.
>>> Denyhosts
>>> checks the logs every X seconds.  I think 30 by default, not sure.  In
>>> that
>>> time, there can be many more attempted logins then the maximum you have
>>> configured in Denyhosts.
>>>
>>> Also, the downloaded list of known attack hosts is copied locally into
>>> your
>>> hosts.deny file.  That's all there is to it.
>>
>> Then what would cause it to not add a new denied host until after many
>> many attempts?
>>
>> I disabled the network sync but denyhosts still takes "forever" before
>> denying... each IP is able to do hundreds of attempts before getting
>> added to the hosts.deny file.
>
> Can you check the logs to see the timespan in which those hundreds of
> attempts took place?  Also, what's the time interval Denyhosts checks for
> login attempts?

The most recently denied host from this afternoon made over 200 login
attempts in a span of 17 minutes before denyhosts caught it. In my
denyhosts.conf I have these:

DENY_THRESHOLD_INVALID = 3
DENY_THRESHOLD_VALID = 3
DENY_THRESHOLD_ROOT = 1
DENY_THRESHOLD_RESTRICTED = 1

This is with the online sync disabled, and denyhosts running in daemon
mode (not cron). The denyhosts log file verifies that it is
interpreting those setting properly, as it shows the same values.
Weird.

Here's the beginning of the attempts:

Jan 21 14:34:48 [sshd] Invalid user apple from 203.110.208.68
Jan 21 14:34:53 [sshd] Invalid user brian from 203.110.208.68
Jan 21 14:34:59 [sshd] Invalid user andrew from 203.110.208.68
Jan 21 14:35:04 [sshd] Invalid user newsroom from 203.110.208.68
Jan 21 14:35:10 [sshd] Invalid user magazine from 203.110.208.68
Jan 21 14:35:16 [sshd] Invalid user research from 203.110.208.68
Jan 21 14:35:21 [sshd] Invalid user cjohnson from 203.110.208.68
Jan 21 14:35:27 [sshd] Invalid user export from 203.110.208.68
Jan 21 14:35:32 [sshd] Invalid user photo from 203.110.208.68
Jan 21 14:35:38 [sshd] Invalid user gast from 203.110.208.68
Jan 21 14:35:43 [sshd] Invalid user murray from 203.110.208.68


So, 11 attempts in the first minute of activity (and it picked up
pace, later on attempting every 2 seconds). Surely denyhosts should
have blocked it already at that point based on my settings, correct?

Thanks :)
Paul

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Mick]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Wednesday 21 January 2009, Paul Hartman wrote:
> On Wed, Jan 21, 2009 at 11:53 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> > Paul Hartman wrote:

> The most recently denied host from this afternoon made over 200 login
> attempts in a span of 17 minutes before denyhosts caught it.

You may want to have a look at fail2ban.  I recall it kicks in much faster.

However, the best approach to this would probably be to use iptables and set a 
limit as to how many connections an unknown host could start.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Robin Atwood]

On Thursday 22 Jan 2009, Paul Hartman wrote:
> On Wed, Jan 21, 2009 at 11:53 AM, Nikos Chantziaras <realnc@arcor.de> wrote:

> Jan 21 14:35:43 [sshd] Invalid user murray from 203.110.208.68
>
>
> So, 11 attempts in the first minute of activity (and it picked up
> pace, later on attempting every 2 seconds). Surely denyhosts should
> have blocked it already at that point based on my settings, correct?

Your regex's might not be up to snuff. Try adding the one below to 
denyhosts.conf:

USERDEF_FAILED_ENTRY_REGEX=Invalid user (?P<user>.*) .*from (::ffff:)?
(?P<host>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})

HTH
-Robin
-- 

[gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Nikos Chantziaras]

Paul Hartman wrote:
> On Wed, Jan 21, 2009 at 11:53 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
>> Can you check the logs to see the timespan in which those hundreds of
>> attempts took place?  Also, what's the time interval Denyhosts checks for
>> login attempts?
> 
> The most recently denied host from this afternoon made over 200 login
> attempts in a span of 17 minutes before denyhosts caught it. In my
> denyhosts.conf I have these:
> 
> DENY_THRESHOLD_INVALID = 3
> DENY_THRESHOLD_VALID = 3
> DENY_THRESHOLD_ROOT = 1
> DENY_THRESHOLD_RESTRICTED = 1

What is the value of DAEMON_SLEEP?

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Paul Hartman]

On Thu, Jan 22, 2009 at 10:06 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> Paul Hartman wrote:
>>
>> On Wed, Jan 21, 2009 at 11:53 AM, Nikos Chantziaras <realnc@arcor.de>
>> wrote:
>>>
>>> Can you check the logs to see the timespan in which those hundreds of
>>> attempts took place?  Also, what's the time interval Denyhosts checks for
>>> login attempts?
>>
>> The most recently denied host from this afternoon made over 200 login
>> attempts in a span of 17 minutes before denyhosts caught it. In my
>> denyhosts.conf I have these:
>>
>> DENY_THRESHOLD_INVALID = 3
>> DENY_THRESHOLD_VALID = 3
>> DENY_THRESHOLD_ROOT = 1
>> DENY_THRESHOLD_RESTRICTED = 1
>
> What is the value of DAEMON_SLEEP?

#######################################################################
#
# DAEMON_SLEEP: when DenyHosts is run in daemon mode (--daemon flag)
# this is the amount of time DenyHosts will sleep between polling
# the SECURE_LOG.  See the comments in the PURGE_DENY section (above)
# for details on specifying this value or for complete details
# refer to:    http://denyhosts.sourceforge.net/faq.html#timespec
#
#
DAEMON_SLEEP = 30s

RE: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[James Homuth]

 

-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Nikos Chantziaras
Sent: January 22, 2009 11:07 AM
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Why isn't sshd blocking repeated failed login
attempts?

Paul Hartman wrote:
> On Wed, Jan 21, 2009 at 11:53 AM, Nikos Chantziaras <realnc@arcor.de>
wrote:
>> Can you check the logs to see the timespan in which those hundreds of 
>> attempts took place?  Also, what's the time interval Denyhosts checks 
>> for login attempts?
> 
> The most recently denied host from this afternoon made over 200 login 
> attempts in a span of 17 minutes before denyhosts caught it. In my 
> denyhosts.conf I have these:
> 
> DENY_THRESHOLD_INVALID = 3
> DENY_THRESHOLD_VALID = 3
> DENY_THRESHOLD_ROOT = 1
> DENY_THRESHOLD_RESTRICTED = 1

What is the value of DAEMON_SLEEP?


Denyhosts doesn't pick up on certain types of PAM auth regular expressions.
If any of those appear in your logs during those 200+ attempts, Denyhosts is
probably not reading them. I've already reported it
(http://bugs.gentoo.org/show_bug.cgi?id=248047) if you want to add anything
to it.

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Paul Hartman]

On Thu, Jan 22, 2009 at 10:37 AM, James Homuth <james@the-jdh.com> wrote:
>
>
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Nikos Chantziaras
> Sent: January 22, 2009 11:07 AM
> To: gentoo-user@lists.gentoo.org
> Subject: [gentoo-user] Re: Why isn't sshd blocking repeated failed login
> attempts?
>
> Paul Hartman wrote:
>> On Wed, Jan 21, 2009 at 11:53 AM, Nikos Chantziaras <realnc@arcor.de>
> wrote:
>>> Can you check the logs to see the timespan in which those hundreds of
>>> attempts took place?  Also, what's the time interval Denyhosts checks
>>> for login attempts?
>>
>> The most recently denied host from this afternoon made over 200 login
>> attempts in a span of 17 minutes before denyhosts caught it. In my
>> denyhosts.conf I have these:
>>
>> DENY_THRESHOLD_INVALID = 3
>> DENY_THRESHOLD_VALID = 3
>> DENY_THRESHOLD_ROOT = 1
>> DENY_THRESHOLD_RESTRICTED = 1
>
> What is the value of DAEMON_SLEEP?
>
>
> Denyhosts doesn't pick up on certain types of PAM auth regular expressions.
> If any of those appear in your logs during those 200+ attempts, Denyhosts is
> probably not reading them. I've already reported it
> (http://bugs.gentoo.org/show_bug.cgi?id=248047) if you want to add anything
> to it.

I don't use PAM in sshd so I don't think that's my problem, but the
whole regexp thing is a possiblity in general as someone else
suggested. I will check into it tonight after work.

Thanks,

Paul

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Mick]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

On Thursday 22 January 2009, Paul Hartman wrote:

> I don't use PAM in sshd so I don't think that's my problem, but the
> whole regexp thing is a possiblity in general as someone else
> suggested. I will check into it tonight after work.

Have you thought of using iptables to match the rate of new connections?  Drop 
everything that comes in thick and fast and, or drop repeated attempts from a 
certain ip address.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Paul Hartman]

On Tue, Jan 20, 2009 at 3:33 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> Hi,
>
> After setting up public key authentication i changed my sshd back to
> port 22 and got the expected bombardment of connection attempts.
> However, it doesn't seem to ever stop them. I'm using sshd with this
> setting:
>
> MaxAuthTries 3
>
> in my /etc/ssh/sshd_config
[cut]

Okay, I have some possible new embarrassing information... as well as
some new questions about access control. After combining all logs in
chronological order, it appears denyhosts IS properly adding the new
host to /etc/hosts.deny but it is simply not causing it to be
denied... See this sample:

Jan 22 18:42:58 [sshd] Invalid user staff from 59.185.104.218
Jan 22 18:43:01 [sshd] Invalid user sales from 59.185.104.218
Jan 22 18:43:03 [sshd] Invalid user recruit from 59.185.104.218
Jan 22 18:43:06 [denyhosts] Added the following hosts to
/etc/hosts.deny - 59.185.104.218
(triband-mum-59.185.104.218.mtnl.net.in)
Jan 22 18:43:06 [sshd] Invalid user alias from 59.185.104.218
Jan 22 18:43:09 [sshd] Invalid user office from 59.185.104.218
Jan 22 18:43:11 [sshd] Invalid user samba from 59.185.104.218
Jan 22 18:43:14 [sshd] Invalid user tomcat from 59.185.104.218
Jan 22 18:43:22 [sshd] Invalid user webadmin from 59.185.104.218

So now I am going back to what I should have looked at in the very
beginning, my hosts.allow and hosts.deny rules.

hosts.allow:
sshd: ALL
portmap: 127.0.0.1, 192.168.0.0/255.255.255.0
lockd: 127.0.0.1, 192.168.0.0/255.255.255.0
rquotad: 127.0.0.1, 192.168.0.0/255.255.255.0
mountd: 127.0.0.1, 192.168.0.0/255.255.255.0
statd: 127.0.0.1, 192.168.0.0/255.255.255.0
ALL: 127.0.0.1, 192.168.0.0/255.255.255.0


hosts.deny:
ALL: ALL
sshd: 58.213.125.25
sshd: 75.37.250.107
sshd: 147.83.29.83
sshd: 59.185.104.218
sshd: 210.40.128.31
(and so on)

From the manpage:

ACCESS CONTROL FILES
       The access control software consults two files. The search
stops at the first match:
       -      Access will be granted when a (daemon,client) pair
matches an entry in the /etc/hosts.allow file.
       -      Otherwise, access will be denied when a (daemon,client)
pair matches an entry in the /etc/hosts.deny file.
       -      Otherwise, access will be granted.

doh! So, basically, when it sees sshd: ALL in hosts.allow, it stops
and allows access to everyone. It never even gets around to checking
the hosts.deny file. The fact that the login attempts stopped after
about an hour must have been purely coincidence.

My intended purpose for those entires was to allow all sshd unless
they are in the deny file, but I also want to deny everything else
that doesn't have an explicit allow/deny rule. I don't think this is
possible using hosts.allow/hosts.deny unless I enumerate every
service. The deny ALL: ALL will deny me access to sshd.

I essentially want it to work the other way around. Deny access by
default unless there is an allow rule. I don't think I can do that,
though. If I put ALL: ALL or sshd: ALL in the hosts.deny file, it will
deny ME access to my own machine. I don't want that. Since I don't
have a specific IP i will connect from, I can't allow any specific IP
(or else I'd be doing it that way already).

How can I accomplish this?:

Allow all ssh connections unless they are in hosts.deny
Deny all other connections unless they are in hosts.allow

Thanks and sorry for the misdirection :)
Paul

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Alan McKinnon]

On Friday 23 January 2009 22:22:17 Paul Hartman wrote:
> I essentially want it to work the other way around. Deny access by
> default unless there is an allow rule. I don't think I can do that,
> though. If I put ALL: ALL or sshd: ALL in the hosts.deny file, it will
> deny ME access to my own machine. I don't want that. Since I don't
> have a specific IP i will connect from, I can't allow any specific IP
> (or else I'd be doing it that way already).
>
> How can I accomplish this?:
>
> Allow all ssh connections unless they are in hosts.deny
> Deny all other connections unless they are in hosts.allow

Have you looked at port knocking?

It's a complete ball ache to set up and use, far less useful than it seems, 
but it might also solve your conundrum.

A friend once mentioned on a forum that he'd managed to set up static libwrap 
rules in hosts.allow|deny for addresses that don't change and additionally 
port-knocking for himself to open up port 22 for a few minutes. I don't 
recall how he did this, only that he claimed to have done it.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Paul Hartman]

On Fri, Jan 23, 2009 at 2:33 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Friday 23 January 2009 22:22:17 Paul Hartman wrote:
>> I essentially want it to work the other way around. Deny access by
>> default unless there is an allow rule. I don't think I can do that,
>> though. If I put ALL: ALL or sshd: ALL in the hosts.deny file, it will
>> deny ME access to my own machine. I don't want that. Since I don't
>> have a specific IP i will connect from, I can't allow any specific IP
>> (or else I'd be doing it that way already).
>>
>> How can I accomplish this?:
>>
>> Allow all ssh connections unless they are in hosts.deny
>> Deny all other connections unless they are in hosts.allow
>
> Have you looked at port knocking?
>
> It's a complete ball ache to set up and use, far less useful than it seems,
> but it might also solve your conundrum.
>
> A friend once mentioned on a forum that he'd managed to set up static libwrap
> rules in hosts.allow|deny for addresses that don't change and additionally
> port-knocking for himself to open up port 22 for a few minutes. I don't
> recall how he did this, only that he claimed to have done it.

I've never tried it but I have always liked the idea. I connect to
sshd from linux (my laptop), windows (my work desktop) and symbian (my
phone).

knockd and the knocking client should be no problem for linux &
windows, but for my phone I'd probably have to make one myself. Is it
as simple as making a connection to a specific sequence of ports with
specific timing? I could probably do that easily in python. Sounds
like a project for this weekend. :)

thanks,
paul

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Alan McKinnon]

On Friday 23 January 2009 22:54:24 Paul Hartman wrote:
> > A friend once mentioned on a forum that he'd managed to set up static
> > libwrap rules in hosts.allow|deny for addresses that don't change and
> > additionally port-knocking for himself to open up port 22 for a few
> > minutes. I don't recall how he did this, only that he claimed to have
> > done it.
>
> I've never tried it but I have always liked the idea. I connect to
> sshd from linux (my laptop), windows (my work desktop) and symbian (my
> phone).
>
> knockd and the knocking client should be no problem for linux &
> windows, but for my phone I'd probably have to make one myself. Is it
> as simple as making a connection to a specific sequence of ports with
> specific timing? I could probably do that easily in python. Sounds
> like a project for this weekend. :)

I'm no expert but AFAIK that is the general idea

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Paul Hartman]

On Fri, Jan 23, 2009 at 2:22 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Tue, Jan 20, 2009 at 3:33 PM, Paul Hartman
> <paul.hartman+gentoo@gmail.com> wrote:
>> Hi,
>>
>> After setting up public key authentication i changed my sshd back to
>> port 22 and got the expected bombardment of connection attempts.
>> However, it doesn't seem to ever stop them. I'm using sshd with this
>> setting:
>>
>> MaxAuthTries 3
>>
>> in my /etc/ssh/sshd_config
> [cut]
>
> Okay, I have some possible new embarrassing information... as well as
> some new questions about access control. After combining all logs in
> chronological order, it appears denyhosts IS properly adding the new
> host to /etc/hosts.deny but it is simply not causing it to be
> denied... See this sample:
>
> Jan 22 18:42:58 [sshd] Invalid user staff from 59.185.104.218
> Jan 22 18:43:01 [sshd] Invalid user sales from 59.185.104.218
> Jan 22 18:43:03 [sshd] Invalid user recruit from 59.185.104.218
> Jan 22 18:43:06 [denyhosts] Added the following hosts to
> /etc/hosts.deny - 59.185.104.218
> (triband-mum-59.185.104.218.mtnl.net.in)
> Jan 22 18:43:06 [sshd] Invalid user alias from 59.185.104.218
> Jan 22 18:43:09 [sshd] Invalid user office from 59.185.104.218
> Jan 22 18:43:11 [sshd] Invalid user samba from 59.185.104.218
> Jan 22 18:43:14 [sshd] Invalid user tomcat from 59.185.104.218
> Jan 22 18:43:22 [sshd] Invalid user webadmin from 59.185.104.218
>
> So now I am going back to what I should have looked at in the very
> beginning, my hosts.allow and hosts.deny rules.
>
> hosts.allow:
> sshd: ALL
> portmap: 127.0.0.1, 192.168.0.0/255.255.255.0
> lockd: 127.0.0.1, 192.168.0.0/255.255.255.0
> rquotad: 127.0.0.1, 192.168.0.0/255.255.255.0
> mountd: 127.0.0.1, 192.168.0.0/255.255.255.0
> statd: 127.0.0.1, 192.168.0.0/255.255.255.0
> ALL: 127.0.0.1, 192.168.0.0/255.255.255.0
>
>
> hosts.deny:
> ALL: ALL
> sshd: 58.213.125.25
> sshd: 75.37.250.107
> sshd: 147.83.29.83
> sshd: 59.185.104.218
> sshd: 210.40.128.31
> (and so on)
>
> From the manpage:
>
> ACCESS CONTROL FILES
>       The access control software consults two files. The search
> stops at the first match:
>       -      Access will be granted when a (daemon,client) pair
> matches an entry in the /etc/hosts.allow file.
>       -      Otherwise, access will be denied when a (daemon,client)
> pair matches an entry in the /etc/hosts.deny file.
>       -      Otherwise, access will be granted.
>
> doh! So, basically, when it sees sshd: ALL in hosts.allow, it stops
> and allows access to everyone. It never even gets around to checking
> the hosts.deny file. The fact that the login attempts stopped after
> about an hour must have been purely coincidence.
>
> My intended purpose for those entires was to allow all sshd unless
> they are in the deny file, but I also want to deny everything else
> that doesn't have an explicit allow/deny rule. I don't think this is
> possible using hosts.allow/hosts.deny unless I enumerate every
> service. The deny ALL: ALL will deny me access to sshd.
>
> I essentially want it to work the other way around. Deny access by
> default unless there is an allow rule. I don't think I can do that,
> though. If I put ALL: ALL or sshd: ALL in the hosts.deny file, it will
> deny ME access to my own machine. I don't want that. Since I don't
> have a specific IP i will connect from, I can't allow any specific IP
> (or else I'd be doing it that way already).
>
> How can I accomplish this?:
>
> Allow all ssh connections unless they are in hosts.deny
> Deny all other connections unless they are in hosts.allow
>
> Thanks and sorry for the misdirection :)
> Paul
>

After reading more, I see there is an EXCEPT rule as well.. so I can
theoretically deny:

ALL: ALL EXCEPT sshd
and hopefully that will do what I was wanting... time to try it :)

[gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Paul Hartman]

On Fri, Jan 23, 2009 at 3:18 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Fri, Jan 23, 2009 at 2:22 PM, Paul Hartman
> <paul.hartman+gentoo@gmail.com> wrote:
>> On Tue, Jan 20, 2009 at 3:33 PM, Paul Hartman
>> <paul.hartman+gentoo@gmail.com> wrote:
>>> Hi,
>>>
>>> After setting up public key authentication i changed my sshd back to
>>> port 22 and got the expected bombardment of connection attempts.
>>> However, it doesn't seem to ever stop them. I'm using sshd with this
>>> setting:
>>>
>>> MaxAuthTries 3
>>>
>>> in my /etc/ssh/sshd_config
>> [cut]
>>
>> Okay, I have some possible new embarrassing information... as well as
>> some new questions about access control. After combining all logs in
>> chronological order, it appears denyhosts IS properly adding the new
>> host to /etc/hosts.deny but it is simply not causing it to be
>> denied... See this sample:
>>
>> Jan 22 18:42:58 [sshd] Invalid user staff from 59.185.104.218
>> Jan 22 18:43:01 [sshd] Invalid user sales from 59.185.104.218
>> Jan 22 18:43:03 [sshd] Invalid user recruit from 59.185.104.218
>> Jan 22 18:43:06 [denyhosts] Added the following hosts to
>> /etc/hosts.deny - 59.185.104.218
>> (triband-mum-59.185.104.218.mtnl.net.in)
>> Jan 22 18:43:06 [sshd] Invalid user alias from 59.185.104.218
>> Jan 22 18:43:09 [sshd] Invalid user office from 59.185.104.218
>> Jan 22 18:43:11 [sshd] Invalid user samba from 59.185.104.218
>> Jan 22 18:43:14 [sshd] Invalid user tomcat from 59.185.104.218
>> Jan 22 18:43:22 [sshd] Invalid user webadmin from 59.185.104.218
>>
>> So now I am going back to what I should have looked at in the very
>> beginning, my hosts.allow and hosts.deny rules.
>>
>> hosts.allow:
>> sshd: ALL
>> portmap: 127.0.0.1, 192.168.0.0/255.255.255.0
>> lockd: 127.0.0.1, 192.168.0.0/255.255.255.0
>> rquotad: 127.0.0.1, 192.168.0.0/255.255.255.0
>> mountd: 127.0.0.1, 192.168.0.0/255.255.255.0
>> statd: 127.0.0.1, 192.168.0.0/255.255.255.0
>> ALL: 127.0.0.1, 192.168.0.0/255.255.255.0
>>
>>
>> hosts.deny:
>> ALL: ALL
>> sshd: 58.213.125.25
>> sshd: 75.37.250.107
>> sshd: 147.83.29.83
>> sshd: 59.185.104.218
>> sshd: 210.40.128.31
>> (and so on)
>>
>> From the manpage:
>>
>> ACCESS CONTROL FILES
>>       The access control software consults two files. The search
>> stops at the first match:
>>       -      Access will be granted when a (daemon,client) pair
>> matches an entry in the /etc/hosts.allow file.
>>       -      Otherwise, access will be denied when a (daemon,client)
>> pair matches an entry in the /etc/hosts.deny file.
>>       -      Otherwise, access will be granted.
>>
>> doh! So, basically, when it sees sshd: ALL in hosts.allow, it stops
>> and allows access to everyone. It never even gets around to checking
>> the hosts.deny file. The fact that the login attempts stopped after
>> about an hour must have been purely coincidence.
>>
>> My intended purpose for those entires was to allow all sshd unless
>> they are in the deny file, but I also want to deny everything else
>> that doesn't have an explicit allow/deny rule. I don't think this is
>> possible using hosts.allow/hosts.deny unless I enumerate every
>> service. The deny ALL: ALL will deny me access to sshd.
>>
>> I essentially want it to work the other way around. Deny access by
>> default unless there is an allow rule. I don't think I can do that,
>> though. If I put ALL: ALL or sshd: ALL in the hosts.deny file, it will
>> deny ME access to my own machine. I don't want that. Since I don't
>> have a specific IP i will connect from, I can't allow any specific IP
>> (or else I'd be doing it that way already).
>>
>> How can I accomplish this?:
>>
>> Allow all ssh connections unless they are in hosts.deny
>> Deny all other connections unless they are in hosts.allow
>>
>> Thanks and sorry for the misdirection :)
>> Paul
>>
>
> After reading more, I see there is an EXCEPT rule as well.. so I can
> theoretically deny:
>
> ALL: ALL EXCEPT sshd
> and hopefully that will do what I was wanting... time to try it :)

Sorry, i made a typo in my email.

ALL EXCEPT sshd: ALL

Tested and working.

Paul

Re: [gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Steven Lembark]

>> How can I accomplish this?:

Use a non-standard port for yourself (e.g., 2222,
34567). A port entry in your .ssh/config will
handle that. With that back door you can set up
any remaining rules on port 22.

-- 
Steven Lembark                                            85-09 90th St.
Workhorse Computing                                 Woodhaven, NY, 11421
lembark@wrkhors.com                                      +1 888 359 3508

[gentoo-user] Re: Why isn't sshd blocking repeated failed login attempts?

[Paul Hartman]

On Fri, Jan 23, 2009 at 3:34 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Fri, Jan 23, 2009 at 3:18 PM, Paul Hartman
> <paul.hartman+gentoo@gmail.com> wrote:
>> On Fri, Jan 23, 2009 at 2:22 PM, Paul Hartman
>> <paul.hartman+gentoo@gmail.com> wrote:
>>> On Tue, Jan 20, 2009 at 3:33 PM, Paul Hartman
>>> <paul.hartman+gentoo@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> After setting up public key authentication i changed my sshd back to
>>>> port 22 and got the expected bombardment of connection attempts.
>>>> However, it doesn't seem to ever stop them. I'm using sshd with this
>>>> setting:
>>>>
>>>> MaxAuthTries 3
>>>>
>>>> in my /etc/ssh/sshd_config
>>> [cut]
>>>
>>> Okay, I have some possible new embarrassing information... as well as
>>> some new questions about access control. After combining all logs in
>>> chronological order, it appears denyhosts IS properly adding the new
>>> host to /etc/hosts.deny but it is simply not causing it to be
>>> denied... See this sample:
>>>
>>> Jan 22 18:42:58 [sshd] Invalid user staff from 59.185.104.218
>>> Jan 22 18:43:01 [sshd] Invalid user sales from 59.185.104.218
>>> Jan 22 18:43:03 [sshd] Invalid user recruit from 59.185.104.218
>>> Jan 22 18:43:06 [denyhosts] Added the following hosts to
>>> /etc/hosts.deny - 59.185.104.218
>>> (triband-mum-59.185.104.218.mtnl.net.in)
>>> Jan 22 18:43:06 [sshd] Invalid user alias from 59.185.104.218
>>> Jan 22 18:43:09 [sshd] Invalid user office from 59.185.104.218
>>> Jan 22 18:43:11 [sshd] Invalid user samba from 59.185.104.218
>>> Jan 22 18:43:14 [sshd] Invalid user tomcat from 59.185.104.218
>>> Jan 22 18:43:22 [sshd] Invalid user webadmin from 59.185.104.218
>>>
>>> So now I am going back to what I should have looked at in the very
>>> beginning, my hosts.allow and hosts.deny rules.
>>>
>>> hosts.allow:
>>> sshd: ALL
>>> portmap: 127.0.0.1, 192.168.0.0/255.255.255.0
>>> lockd: 127.0.0.1, 192.168.0.0/255.255.255.0
>>> rquotad: 127.0.0.1, 192.168.0.0/255.255.255.0
>>> mountd: 127.0.0.1, 192.168.0.0/255.255.255.0
>>> statd: 127.0.0.1, 192.168.0.0/255.255.255.0
>>> ALL: 127.0.0.1, 192.168.0.0/255.255.255.0
>>>
>>>
>>> hosts.deny:
>>> ALL: ALL
>>> sshd: 58.213.125.25
>>> sshd: 75.37.250.107
>>> sshd: 147.83.29.83
>>> sshd: 59.185.104.218
>>> sshd: 210.40.128.31
>>> (and so on)
>>>
>>> From the manpage:
>>>
>>> ACCESS CONTROL FILES
>>>       The access control software consults two files. The search
>>> stops at the first match:
>>>       -      Access will be granted when a (daemon,client) pair
>>> matches an entry in the /etc/hosts.allow file.
>>>       -      Otherwise, access will be denied when a (daemon,client)
>>> pair matches an entry in the /etc/hosts.deny file.
>>>       -      Otherwise, access will be granted.
>>>
>>> doh! So, basically, when it sees sshd: ALL in hosts.allow, it stops
>>> and allows access to everyone. It never even gets around to checking
>>> the hosts.deny file. The fact that the login attempts stopped after
>>> about an hour must have been purely coincidence.
>>>
>>> My intended purpose for those entires was to allow all sshd unless
>>> they are in the deny file, but I also want to deny everything else
>>> that doesn't have an explicit allow/deny rule. I don't think this is
>>> possible using hosts.allow/hosts.deny unless I enumerate every
>>> service. The deny ALL: ALL will deny me access to sshd.
>>>
>>> I essentially want it to work the other way around. Deny access by
>>> default unless there is an allow rule. I don't think I can do that,
>>> though. If I put ALL: ALL or sshd: ALL in the hosts.deny file, it will
>>> deny ME access to my own machine. I don't want that. Since I don't
>>> have a specific IP i will connect from, I can't allow any specific IP
>>> (or else I'd be doing it that way already).
>>>
>>> How can I accomplish this?:
>>>
>>> Allow all ssh connections unless they are in hosts.deny
>>> Deny all other connections unless they are in hosts.allow
>>>
>>> Thanks and sorry for the misdirection :)
>>> Paul
>>>
>>
>> After reading more, I see there is an EXCEPT rule as well.. so I can
>> theoretically deny:
>>
>> ALL: ALL EXCEPT sshd
>> and hopefully that will do what I was wanting... time to try it :)
>
> Sorry, i made a typo in my email.
>
> ALL EXCEPT sshd: ALL
>
> Tested and working.
>
> Paul
>

As a follow-up, using the fixed hosts.allow/deny rules & denyhosts
with sync server enabled, it's working great. The majority of ssh
connections are being blocked by the denyhosts data, and my own ssh
connections are still working fine. :)

I still plan to experiment with the more exotic approaches like
iptables & portknocking but for now the simple hosts.deny method is
working okay.

thanks to all,
Paul