Re: Cherche un testeur pour installer DenyHosts sur Debian Stable

[G2PC]

Le 20/05/2020 à 14:17, G2PC a écrit :
> Cherche un testeur pour installer DenyHosts sur Debian Stable
>
> J'ai rédigé cette documentation pour installer DenyHosts sur Debian
> Buster Stable.
>
> https://github.com/denyhosts/denyhosts/commit/98d2bb9ffd4c0bb4af91a9d4332b4a7566296376#diff-d396f81f39f45168d5772b9c65688525
>
> Pouvez vous tester ?
>
> Noter qu'il faut également avoir installé rsyslog pour renseigner le
> fichier auth.log
>
> Merci de vos retours.
Concernant l'issue 144 : https://github.com/denyhosts/denyhosts/issues/144

Je lis le message suivant, et, je me demande si il est normal de voir
affiché "tart" et non pas "start..." ?
Le message est t'il tronqué par Debian ?

|systemd[1]: denyhosts.service: Failed with result 'exit-code'.
tart-stop-daemon: unable to start /usr/share/denyhosts/denyhosts_ctl.py|

Cherche un testeur pour installer DenyHosts sur Debian Stable

[G2PC]

Cherche un testeur pour installer DenyHosts sur Debian Stable

J'ai rédigé cette documentation pour installer DenyHosts sur Debian
Buster Stable.

https://github.com/denyhosts/denyhosts/commit/98d2bb9ffd4c0bb4af91a9d4332b4a7566296376#diff-d396f81f39f45168d5772b9c65688525

Pouvez vous tester ?

Noter qu'il faut également avoir installé rsyslog pour renseigner le
fichier auth.log

Merci de vos retours.

Re: sucessor for denyhosts?

[Håkon Alstadheim]

Den 09.03.2019 11:22, skrev mj:

Hi,

We are using fail2ban to do this. It offers many more options, and 
works by creating iptables rules. This gives you  much more control 
over what ports exactly are blocked.
fail2ban can run any script of your choosing as "banaction". I have a 
script that does smtp blacklist for example. My default action is a 
shorewall command. Also needs the corresponding "unban" script, 
obviously. All in all fail2ban seems fairly solid, though it /does/ 
depend on the format of your logs to work properly. Stick with standard 
config of logging from services and syslogd/systemd as far as possible, 
and fail2ban will be pretty low-maintenance. (I have only ever used it 
together with rsyslogd).


Plus I think (correct me if Im wrong) that using /etc/hosts.deny to 
block access only works with programs that are compiled to do so, and 
iptables will always work.


That is the direction things are moving in my experience also, though I 
seem to remember a recent issue i had where I needed hosts.deny to get 
proper blocking for apache, because connections were coming in via a 
multiplexer/proxy thingamajig. Had something to do with open-vpn.





MJ

On 3/9/19 9:57 AM, Hans wrote:

Hi folks,

looks like "denyhosts" is nol more in the repos. I like this tool, 
because it

blocks the IP, when the wrong password is sent n-times.

The blocked IP is added into /etc/hosts.deny, which IMO is a great idea.

I am using a script, which, cleares the hosts.deny after a certain 
time, but

this is just my behaviour.

My question: which successor for denyhost do you suggest. I found 
sshguard,
which looks promising, but maybe you got a better tool, which is 
similar to

denyhosts.

Happy hacking!

Hans

Re: sucessor for denyhosts?

[Roger Price]

On Sat, 9 Mar 2019, mj wrote:

We are using fail2ban to do this. It offers many more options, and works by 
creating iptables rules. This gives you  much more control over what ports 
exactly are blocked.


Plus I think (correct me if Im wrong) that using /etc/hosts.deny to block 
access only works with programs that are compiled to do so, and iptables will 
always work.


/etc/hosts.deny is part of TCP Wrappers for which Wietse Venema stopped 
maintenance in 1995.  See https://en.wikipedia.org/wiki/TCP_Wrappers . See also 
October 2014 Linux Weekly News article https://lwn.net/Articles/615173/


I find that it is much easier to use an ipset with set type hash:net to define 
the IP nets and addresses that are to be rejected.  It avoids messing with the 
iptable commands.  The ipset can be initialized with the IP addresses of 
originating countries to be rejected using block lists such as those at 
http://ipverse.net/ipblocks/data/countries/ I recommend enabling the counter 
associated with each net.


I have had no problems with ipsets of over 14 sub-net entries.  I wouldn't 
like to do that with just iptables.


Roger

Re: sucessor for denyhosts?

[Hans]

Am Samstag, 9. März 2019, 11:22:45 CET schrieb mj:
Hi MJ, 

that is a good point, that only services are blocked, which are using 
hosts.deny. For the other ports I am using tools like porstentry and 
hostentry, which are running well and do a good job.

My personal style is strange: I am looking, on which kind or way an attacker 
could intrude my system and then defend with the rquired tool. I am never 
relying on one tool, it is always a combination of several tools - like I say, 
a "concept".

Of course I pay attention, that my tools do not interfere each other. And you 
may wonder - it happens, that there is a new attacking threat, then I defend 
against it and after one or two years I forgot about it. "Fire and forget".

But from time to time I recheck my strategies (like this time) and look, what 
can be improved/exchanged/whatever, like today.

I will give fail2ban a try, as it looks like the most suggested tool at the 
moment. But as I said before - let's see of more suggestions.

Best

Hans




> Hi,
> 
> We are using fail2ban to do this. It offers many more options, and works
> by creating iptables rules. This gives you  much more control over what
> ports exactly are blocked.
> 
> Plus I think (correct me if Im wrong) that using /etc/hosts.deny to
> block access only works with programs that are compiled to do so, and
> iptables will always work.
> 
> MJ


signature.asc
Description: This is a digitally signed message part.

Re: sucessor for denyhosts?

[mj]

Hi,

We are using fail2ban to do this. It offers many more options, and works 
by creating iptables rules. This gives you  much more control over what 
ports exactly are blocked.


Plus I think (correct me if Im wrong) that using /etc/hosts.deny to 
block access only works with programs that are compiled to do so, and 
iptables will always work.


MJ

On 3/9/19 9:57 AM, Hans wrote:

Hi folks,

looks like "denyhosts" is nol more in the repos. I like this tool, because it
blocks the IP, when the wrong password is sent n-times.

The blocked IP is added into /etc/hosts.deny, which IMO is a great idea.

I am using a script, which, cleares the hosts.deny after a certain time, but
this is just my behaviour.

My question: which successor for denyhost do you suggest. I found sshguard,
which looks promising, but maybe you got a better tool, which is similar to
denyhosts.

Happy hacking!

Hans

Re: sucessor for denyhosts?

[Hans]

Hi Paul,

fail2ban is looking promising, and I have it already installed since years. It 
is more expandable than sshguard, as it is checking more services than ssh.

Both are using the same techniques - both are checking logfiles and then change 
firewall rules. I think, for me fail2ban is more interesting than sshguard. 

I wonder, why denyhots is being deleted from the repo. Ok, there were security 
issues in the past, but these are fixed now. And ok, it does not support IPV6, 
but I think, most private users might not used it.

For the moment I will stay with denyhosts, but fail2ban is in the testing 
pahase here.

And maybe others have more ideas, we will see.

Best

Hans   
> Maybe have a look at fail2ban this seems to fit the description of what
> you're looking for.  I have not used it much but I found out about it
> from another Linux user group member years ago and he suggested it.
> 
> Regards
> 
> Paul



signature.asc
Description: This is a digitally signed message part.

Re: sucessor for denyhosts?

[Paul Sutton]

On 09/03/2019 08:57, Hans wrote:
> Hi folks,
>
> looks like "denyhosts" is nol more in the repos. I like this tool, because it 
> blocks the IP, when the wrong password is sent n-times.
>
> The blocked IP is added into /etc/hosts.deny, which IMO is a great idea.
>
> I am using a script, which, cleares the hosts.deny after a certain time, but 
> this is just my behaviour.
>
> My question: which successor for denyhost do you suggest. I found sshguard, 
> which looks promising, but maybe you got a better tool, which is similar to 
> denyhosts.
>
> Happy hacking!
>
> Hans 


Hi Hans

Maybe have a look at fail2ban this seems to fit the description of what
you're looking for.  I have not used it much but I found out about it
from another Linux user group member years ago and he suggested it.

Regards

Paul

-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D

sucessor for denyhosts?

[Hans]

Hi folks,

looks like "denyhosts" is nol more in the repos. I like this tool, because it 
blocks the IP, when the wrong password is sent n-times.

The blocked IP is added into /etc/hosts.deny, which IMO is a great idea.

I am using a script, which, cleares the hosts.deny after a certain time, but 
this is just my behaviour.

My question: which successor for denyhost do you suggest. I found sshguard, 
which looks promising, but maybe you got a better tool, which is similar to 
denyhosts.

Happy hacking!

Hans 

signature.asc
Description: This is a digitally signed message part.

Re: DenyHosts

[Bob Holtzman]

On Sun, Jan 17, 2016 at 03:33:05PM +0200, Moreanu Robert - Nicolae wrote:
> hi,
> i'm looking to resolve this problem when I want to install debian 8.2 or
> 8.1. I receive this message after it's take to Grub install
> 
> " the 'grub-pc' package failed to install into /target/ "
> after the operation of clean up on installing, i have a failed operations.
> 
> I don't have such expertise, please make the debian on install with more
> information and what procedure to do that for the people don't have the
> time to study the debian.
> 
> so.. how i could resolve this problem , any help from you, please
> 
> robert, waiting for your response

Don't hijack threads!

Re: DenyHosts

[Christian Seiler]

On 01/16/2016 10:57 AM, Reco wrote:
> - anyone can connect up to 16 times via ssh.
> - anyone exceeding the connection limit is tarpitted, and must wait
> for an hour to try again.

Note that while this may be adequate for your use case, I would
caution that 16 connections / hour can easily (!) be exceeded
by regular SSH usage.

If you have pubkey authentication (with an agent that remembers
the key's passphrase) and have command line completion on the
shell that also works with SSH, tabbing through scp options can
easily produce more than 16 new SSH connections within a few
minutes only.

Example:

scp host:/srv/d
scp host:/srv/data/w
scp host:/srv/data/website/ex
scp host:/srv/data/website/example.com/...
 (you get the picture)

On my system with something like that I got more than 5 new
SSH connections within just a few seconds - and while most
shell completion implementations cache this data to a certain
extent, 16 / hour seems really low for such a use case.

Also, if you use modern desktop environments (e.g. GNOME, KDE),
they can directly access e.g. SFTP from many programs (such as
text editors etc.) - but those may close connections when they
are idle for a time and re-open them - so directly editing a
file via SFTP from a program might lead to a LOT of new SSH
connections over the course of a short period of time.

As I said: for your use case this might not be relevant, so I
don't want to say that the solution presented here is wrong,
it will be perfectly fine for a good many situations; I just
wanted to illustrate that there are legitimate use cases where
it is possible to exceed that limit easily. Obviously, you
could increase the limit by a bit - because even if you allow
let's say 1 connections per hour and IP, that would still
make brute force rather difficult... OTOH, I haven't put any
thought into the best trade-off between security and usability
here, and I just made up the number 1, so please don't
just use that number unconditionally either.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: DenyHosts

[Igor Cicimov]

On 18/01/2016 12:08 AM, "Christian Seiler"  wrote:
>
> On 01/16/2016 10:57 AM, Reco wrote:
> > - anyone can connect up to 16 times via ssh.
> > - anyone exceeding the connection limit is tarpitted, and must wait
> > for an hour to try again.
>
> Note that while this may be adequate for your use case, I would
> caution that 16 connections / hour can easily (!) be exceeded
> by regular SSH usage.
>
> If you have pubkey authentication (with an agent that remembers
> the key's passphrase) and have command line completion on the
> shell that also works with SSH, tabbing through scp options can
> easily produce more than 16 new SSH connections within a few
> minutes only.
>
> Example:
>
> scp host:/srv/d
> scp host:/srv/data/w
> scp host:/srv/data/website/ex
> scp host:/srv/data/website/example.com/...
>  (you get the picture)
>
> On my system with something like that I got more than 5 new
> SSH connections within just a few seconds - and while most
> shell completion implementations cache this data to a certain
> extent, 16 / hour seems really low for such a use case.
>

Or just use multiplexing and not worry about it
https://en.m.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

> Also, if you use modern desktop environments (e.g. GNOME, KDE),
> they can directly access e.g. SFTP from many programs (such as
> text editors etc.) - but those may close connections when they
> are idle for a time and re-open them - so directly editing a
> file via SFTP from a program might lead to a LOT of new SSH
> connections over the course of a short period of time.
>
> As I said: for your use case this might not be relevant, so I
> don't want to say that the solution presented here is wrong,
> it will be perfectly fine for a good many situations; I just
> wanted to illustrate that there are legitimate use cases where
> it is possible to exceed that limit easily. Obviously, you
> could increase the limit by a bit - because even if you allow
> let's say 1 connections per hour and IP, that would still
> make brute force rather difficult... OTOH, I haven't put any
> thought into the best trade-off between security and usability
> here, and I just made up the number 1, so please don't
> just use that number unconditionally either.
>
> Regards,
> Christian
>

Re: DenyHosts

[Moreanu Robert - Nicolae]

hi,
i'm looking to resolve this problem when I want to install debian 8.2 or
8.1. I receive this message after it's take to Grub install

" the 'grub-pc' package failed to install into /target/ "
after the operation of clean up on installing, i have a failed operations.

I don't have such expertise, please make the debian on install with more
information and what procedure to do that for the people don't have the
time to study the debian.

so.. how i could resolve this problem , any help from you, please

robert, waiting for your response

On Sun, Jan 17, 2016 at 3:31 PM, Igor Cicimov  wrote:

>
> On 18/01/2016 12:08 AM, "Christian Seiler"  wrote:
> >
> > On 01/16/2016 10:57 AM, Reco wrote:
> > > - anyone can connect up to 16 times via ssh.
> > > - anyone exceeding the connection limit is tarpitted, and must wait
> > > for an hour to try again.
> >
> > Note that while this may be adequate for your use case, I would
> > caution that 16 connections / hour can easily (!) be exceeded
> > by regular SSH usage.
> >
> > If you have pubkey authentication (with an agent that remembers
> > the key's passphrase) and have command line completion on the
> > shell that also works with SSH, tabbing through scp options can
> > easily produce more than 16 new SSH connections within a few
> > minutes only.
> >
> > Example:
> >
> > scp host:/srv/d
> > scp host:/srv/data/w
> > scp host:/srv/data/website/ex
> > scp host:/srv/data/website/example.com/...
> >  (you get the picture)
> >
> > On my system with something like that I got more than 5 new
> > SSH connections within just a few seconds - and while most
> > shell completion implementations cache this data to a certain
> > extent, 16 / hour seems really low for such a use case.
> >
>
> Or just use multiplexing and not worry about it
> https://en.m.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing
>
> > Also, if you use modern desktop environments (e.g. GNOME, KDE),
> > they can directly access e.g. SFTP from many programs (such as
> > text editors etc.) - but those may close connections when they
> > are idle for a time and re-open them - so directly editing a
> > file via SFTP from a program might lead to a LOT of new SSH
> > connections over the course of a short period of time.
> >
> > As I said: for your use case this might not be relevant, so I
> > don't want to say that the solution presented here is wrong,
> > it will be perfectly fine for a good many situations; I just
> > wanted to illustrate that there are legitimate use cases where
> > it is possible to exceed that limit easily. Obviously, you
> > could increase the limit by a bit - because even if you allow
> > let's say 1 connections per hour and IP, that would still
> > make brute force rather difficult... OTOH, I haven't put any
> > thought into the best trade-off between security and usability
> > here, and I just made up the number 1, so please don't
> > just use that number unconditionally either.
> >
> > Regards,
> > Christian
> >
>



-- 

*o zi frumoasa !Robert - Nicolae  MOREANU*

Re: DenyHosts

[Reco]

Hi.

On Sat, 16 Jan 2016 07:35:54 -0500
Steve Matzura  wrote:
> >But with conjunction with the previous one it implements the following
> >policy:
> >
> >- anyone can connect up to 16 times via ssh.
> >- anyone exceeding the connection limit is tarpitted, and must wait
> >for an hour to try again.
> 
> That seems more than fair. Nobody using the system correctly should
> ever break this rule under normal circumstances and/or conditions.

Indeed. That's why I use exactly these rules for my hosts ;)


> >> How do these commands function to lock out specific addresses or
> >> address ranges?
> >
> >The current implementation works with single source IPs.
> >Modifying the rules to work with IP ranges is an exercise left for the
> >reader :)
> 
> By "the current implementation," do you mean before or after I used
> the commands you gave? There is nothing in either of these two
> complex-side command sets that specify a single address.

I meant these two netfilter rules.
There's no need to specify nor source nor destination IPs in these
rules, the whole idea of these rules is to apply to anyone.
It's sufficient to store a hash of a source IP from previous connection
attempts as it's used for counting them.


It's possible to limit this policy to a single IP (or a subnet in this
example):

iptables -I INPUT -p tcp --dport 22 -s 59.46.71.0/24 \
-m conntrack --ctstate NEW \
-m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
--hashlimit-mode srcip --hashlimit-name ssh \
--hashlimit-htable-expire 6 -j ACCEPT

iptables -I INPUT -p tcp --dport 22 -s 59.46.71.0/24 \
--tcp-flags SYN,RST,ACK SYN -j DROP


But then again - why bother? This set of rules should not interfere
with normal user activity anyway.

Reco

Re: DenyHosts

[Steve Matzura]

Reco:

On Sat, 16 Jan 2016 12:57:30 +0300, you wrote:

>>-j, --jump target
>>   This specifies the target of the rule; i.e., what to do
>> if  the packet  matches  it.   The  target  can  be a user-defined
>> chain (other than the one this rule is in), one of the special builtin
>>   targets  which  decide the fate of the packet
>> immediately, or an extension (see EXTENSIONS below).  If this option
>> is omitted  in a rule (and -g is not used), then matching the rule
>> will have no effect on the packet's fate, but the counters on the rule
>> will be incremented.
>> 
>> So if the inbound packet has some property which matches any of those
>> specified in the `--tcp-flags' list, drop it?
>
>This rule simply drops all incoming NEW connections to tcp:22.
>By itself, this rule is evil as it forbids to connect via ssh to anyone.
>
>But with conjunction with the previous one it implements the following
>policy:
>
>- anyone can connect up to 16 times via ssh.
>- anyone exceeding the connection limit is tarpitted, and must wait
>for an hour to try again.

That seems more than fair. Nobody using the system correctly should
ever break this rule under normal circumstances and/or conditions.

>> How do these commands function to lock out specific addresses or
>> address ranges?
>
>The current implementation works with single source IPs.
>Modifying the rules to work with IP ranges is an exercise left for the
>reader :)

By "the current implementation," do you mean before or after I used
the commands you gave? There is nothing in either of these two
complex-side command sets that specify a single address.

>> In the `--tcp-flags' list, why is `SYN' mentioned twice?

>It's simple. There's absolutely no need for these rules to apply once
>the connection is established.
>Removing SYN match would effecively limit any ssh session to 16 packets
>total, which will break ssh in a most curious ways.

OK. This is way over my head, I'll just accept it as gospel until I
understand it better. Thanks for the explanations though.

Re: DenyHosts

[Reco]

Hi.

On Sat, 16 Jan 2016 00:49:17 -0500
Steve Matzura  wrote:

> Reco:
> 
> All of this is an excellent learning opportunity for me. Please bear
> with me just a bit as I ask the following:
> 
> On Sat, 16 Jan 2016 01:55:38 +0300, you wrote:
> 
> >A simple solution:
> >
> >iptables -I INPUT -p dcp -s 59.46.71.0/24 -j DROP
> 
> `-p dcp'? manpages says:
> 
>[!] -p, --protocol protocol
>   The protocol of the rule or of the packet to check.  The
> specified protocol can be one of tcp, udp, udplite, icmp, icmpv6,esp,
>   ah, sctp, mh or the special  keyword  "all",  or  it can
> be  a numeric  value, representing one of these protocols or a
> different one.  A protocol name from /etc/protocols is  also  allowed.
> ...

My mistake. I meant "tcp". SSH is tcp, after all.


> >A complex one:
> >
> >iptables -I INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
> > -m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
> > --hashlimit-mode srcip --hashlimit-name ssh \
> > --hashlimit-htable-expire 6 -j ACCEPT
> 
>-m, --match match
>   Specifies  a  match  to  use,  that is, an extension
> module that tests for a specific property. The set of matches  make up
> the condition under which a target is invoked. Matches are evaluated
> first to last as specified on  the  command  line  and  work in
> short-circuit fashion, i.e. if one extension yields false, evaluation
> will stop.
> 
> If I understand the above, in this command you are doing something
> with two rule `conntrack' and `hashlimit'. But what? Adding them?
> Setting rule behavior?

This rule allows 16 connections to tcp:22 from a single IP address
(source IP) within an hour.

Conntrack is used to match NEW connections.
Hashlimit is used to hash source IP and store the result in a kernel
hashtable called ssh (see /proc/net/ipt_hashlimit/ssh for the result).

Once 16 connection limit is exceeded, netfilter will stop using this
rule for an hour, and move to a following one.

Of course, "16" and "1 hour" are arbitrary values, and can be changed.


> >iptables -I INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
> > -j DROP
> 
>-j, --jump target
>   This specifies the target of the rule; i.e., what to do
> if  the packet  matches  it.   The  target  can  be a user-defined
> chain (other than the one this rule is in), one of the special builtin
>   targets  which  decide the fate of the packet
> immediately, or an extension (see EXTENSIONS below).  If this option
> is omitted  in a rule (and -g is not used), then matching the rule
> will have no effect on the packet's fate, but the counters on the rule
> will be incremented.
> 
> So if the inbound packet has some property which matches any of those
> specified in the `--tcp-flags' list, drop it?

This rule simply drops all incoming NEW connections to tcp:22.
By itself, this rule is evil as it forbids to connect via ssh to anyone.

But with conjunction with the previous one it implements the following
policy:

- anyone can connect up to 16 times via ssh.
- anyone exceeding the connection limit is tarpitted, and must wait
for an hour to try again.


> 
> Questions:
> 
> How do these commands function to lock out specific addresses or
> address ranges?

The current implementation works with single source IPs.
Modifying the rules to work with IP ranges is an exercise left for the
reader :)


> In the `--tcp-flags' list, why is `SYN' mentioned twice?

It's simple. There's absolutely no need for these rules to apply once
the connection is established.
Removing SYN match would effecively limit any ssh session to 16 packets
total, which will break ssh in a most curious ways.

Reco

Re: DenyHosts

[Chris Bannister]

On Sat, Jan 16, 2016 at 04:49:35PM +1100, David wrote:
> On 16 January 2016 at 15:48, Steve Matzura  wrote:
> > On Sat, 16 Jan 2016 01:55:38 +0300, Reco wrote:
> >
> >>A simple solution:
> >>
> >>iptables -I INPUT -p dcp -s 59.46.71.0/24 -j DROP
> >
> > iptables v1.4.21: unknown protocol "dcp" specified
> > Try `iptables -h' or 'iptables --help' for more information.
> >
> > Should I try the complex solution, or find out what went wrong with
> > the simple one first?
> 
> There's a typo in the command Reco gave you.

Sorry, but that doesn't inspire much confidence in his suggestion. Does
that solution work if the OP is also running a firewall such as
shorewall?

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: DenyHosts

[Reco]

Hi.

On Sat, 16 Jan 2016 12:02:57 -0500
Steve Matzura  wrote:

> Well, I thought I was doing so well. I discover now that no one,
> including me, can get into my system any more via ssh. Here are the
> current iptables rules:
> 
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
> -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
> hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
> --hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
> 6 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
> -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
> hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
> --hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
> 6 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
> -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
> hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
> --hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
> 6 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
> -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
> hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
> --hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
> 6 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
> -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
> hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
> --hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
> 6 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
> -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
> -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
> hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
> --hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
> 6 -j ACCEPT
> COMMIT
> 
> What'd I do?
> 

Exactly this:

iptables -F INPUT
iptables -I INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
-m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
--hashlimit-mode srcip --hashlimit-name ssh \
--hashlimit-htable-expire 6 -j ACCEPT
iptables -I INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
-j DROP

Note that the order of netfilter rules is top-down (i.e. highest
matching rule plays).
So, first rule on your current list, namely:

-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP

blocked anyone from using ssh.

Reco

Re: DenyHosts

[Steve Matzura]

On Sat, 16 Jan 2016 20:16:28 +0300, you wrote:

>> What'd I do?
>> 
>
>Exactly this:
>
>iptables -F INPUT
>iptables -I INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
>   -m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
>   --hashlimit-mode srcip --hashlimit-name ssh \
>   --hashlimit-htable-expire 6 -j ACCEPT
>iptables -I INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
>   -j DROP
>
>Note that the order of netfilter rules is top-down (i.e. highest
>matching rule plays).
>So, first rule on your current list, namely:
>
>-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
>
>blocked anyone from using ssh.

I have to tell you, that one *did* look suspicious. Should I remove it
from the list of iptables commands and re-apply the rest of them?


>Reco
>

Re: DenyHosts

[Reco]

Hi.

On Sat, 16 Jan 2016 12:46:30 -0500
Steve Matzura  wrote:

> On Sat, 16 Jan 2016 20:16:28 +0300, you wrote:
> 
> >> What'd I do?
> >> 
> >
> >Exactly this:
> >
> >iptables -F INPUT
> >iptables -I INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
> > -m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
> > --hashlimit-mode srcip --hashlimit-name ssh \
> > --hashlimit-htable-expire 6 -j ACCEPT
> >iptables -I INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
> > -j DROP
> >
> >Note that the order of netfilter rules is top-down (i.e. highest
> >matching rule plays).
> >So, first rule on your current list, namely:
> >
> >-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
> >
> >blocked anyone from using ssh.
> 
> I have to tell you, that one *did* look suspicious. Should I remove it
> from the list of iptables commands and re-apply the rest of them?

My bad - I mistook -I (append to head) with -A (append to tail) options.

Correct sequence would be:

iptables -F INPUT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
-m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
--hashlimit-mode srcip --hashlimit-name ssh \
--hashlimit-htable-expire 6 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
-j DROP

There's no need to remove anything else by hand as -F should remove
everything anyway.

Re: DenyHosts

[Steve Matzura]

Reco:

On Sat, 16 Jan 2016 23:49:57 +0300, you wrote:

>Reverse the order of these two rules. As I wrote in another part of this
>thread, I mistook rules' sequence.

Like this?

iptables -I INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
-j DROP
iptables -I INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
-m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
--hashlimit-mode srcip --hashlimit-name ssh \
--hashlimit-htable-expire 6 -j ACCEPT

Re: DenyHosts

[Steve Matzura]

Reco:

On Sat, 16 Jan 2016 23:48:54 +0300, you wrote:

>Correct sequence would be:
>
>iptables -F INPUT
>iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
>   -m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
>   --hashlimit-mode srcip --hashlimit-name ssh \
>   --hashlimit-htable-expire 6 -j ACCEPT
>iptables -A INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
>   -j DROP

OK, got it perfect now. THANKS!

Re: DenyHosts

[Reco]

Hi.

On Sat, 16 Jan 2016 13:01:29 -0500
Steve Matzura  wrote:

> I tried redoing the tables:
> 
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
> -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
> hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
> --hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
> 6 -j ACCEPT
> COMMIT
> 
> This list looks a lot cleaner, and the first thing on it is to accept
> everything. But still I cannot connect, even after restarting the sshd
> service.

Reverse the order of these two rules. As I wrote in another part of this
thread, I mistook rules' sequence.

Re: DenyHosts

[Steve Matzura]

Well, I thought I was doing so well. I discover now that no one,
including me, can get into my system any more via ssh. Here are the
current iptables rules:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
--hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
6 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
--hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
6 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
--hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
6 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
--hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
6 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
--hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
6 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
--hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
6 -j ACCEPT
COMMIT

What'd I do?

Re: DenyHosts

[Steve Matzura]

I tried redoing the tables:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m
hashlimit --hashlimit-upto 1/hour --hashlimit-burst 16
--hashlimit-mode srcip --hashlimit-name ssh --hashlimit-htable-expire
6 -j ACCEPT
COMMIT

This list looks a lot cleaner, and the first thing on it is to accept
everything. But still I cannot connect, even after restarting the sshd
service.

DenyHosts

[Steve Matzura]

My new fledgling server is being slammed, and I mean slammed like
Sandy slammed New York, by root login attacks from 59.46.71.36,
ShenYang, China. Of course, I don't allow root logins except from the
console or via ssh key pair, so I presume I'm safe that way, but I'd
sure like to cut down on the log churning of /var/log/auth.log,
particularly since it makes it harder to read that log to get the
stuff I need to know out of it. My router (Fios Quantum gateway) is
useless at blocking anything from the outside, so I've got to do it
internally. What are folks' favorite deny-hosts applications? I tried
installing DenyHosts, but it must be from a private repo because
whatever I have in sources couldn't find it.

Thanks in advance.

Re: DenyHosts

[Sven Arvidsson]

On Fri, 2016-01-15 at 16:37 -0500, Steve Matzura wrote:
> My new fledgling server is being slammed, and I mean slammed like
> Sandy slammed New York, by root login attacks from 59.46.71.36,
> ShenYang, China. Of course, I don't allow root logins except from the
> console or via ssh key pair, so I presume I'm safe that way, but I'd
> sure like to cut down on the log churning of /var/log/auth.log,
> particularly since it makes it harder to read that log to get the
> stuff I need to know out of it. My router (Fios Quantum gateway) is
> useless at blocking anything from the outside, so I've got to do it
> internally. What are folks' favorite deny-hosts applications? I tried
> installing DenyHosts, but it must be from a private repo because
> whatever I have in sources couldn't find it.
> 
> Thanks in advance.

denyhosts only exists in oldoldstable, oldstable and unstable, so I
guess it was dropped and then reintroduced?

You could try fail2ban, it should be available in stable and testing as
well.

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 6FAB5CD5





signature.asc
Description: This is a digitally signed message part

Re: DenyHosts

[Cláudio E. Elicker]

On Fri, 15 Jan 2016 16:37:48 -0500
Steve Matzura <s...@noisynotes.com> wrote:

> My new fledgling server is being slammed, and I mean slammed like
> Sandy slammed New York, by root login attacks from 59.46.71.36,
> ShenYang, China. Of course, I don't allow root logins except from the
> console or via ssh key pair, so I presume I'm safe that way, but I'd
> sure like to cut down on the log churning of /var/log/auth.log,
> particularly since it makes it harder to read that log to get the
> stuff I need to know out of it. My router (Fios Quantum gateway) is
> useless at blocking anything from the outside, so I've got to do it
> internally. What are folks' favorite deny-hosts applications? I tried
> installing DenyHosts, but it must be from a private repo because
> whatever I have in sources couldn't find it.
> 
> Thanks in advance.
> 


As an emergency fix, add the offending(s) ip(s) to your /etc/hosts.deny
file.


-- 
EMACS is my operating system; Linux is my device driver.

Re: DenyHosts

[Steve Matzura]

Reco:

All of this is an excellent learning opportunity for me. Please bear
with me just a bit as I ask the following:

On Sat, 16 Jan 2016 01:55:38 +0300, you wrote:

>A simple solution:
>
>iptables -I INPUT -p dcp -s 59.46.71.0/24 -j DROP

`-p dcp'? manpages says:

   [!] -p, --protocol protocol
  The protocol of the rule or of the packet to check.  The
specified protocol can be one of tcp, udp, udplite, icmp, icmpv6,esp,
  ah, sctp, mh or the special  keyword  "all",  or  it can
be  a numeric  value, representing one of these protocols or a
different one.  A protocol name from /etc/protocols is  also  allowed.
...

>A complex one:
>
>iptables -I INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
>   -m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
>   --hashlimit-mode srcip --hashlimit-name ssh \
>   --hashlimit-htable-expire 6 -j ACCEPT

   -m, --match match
  Specifies  a  match  to  use,  that is, an extension
module that tests for a specific property. The set of matches  make up
the condition under which a target is invoked. Matches are evaluated
first to last as specified on  the  command  line  and  work in
short-circuit fashion, i.e. if one extension yields false, evaluation
will stop.

If I understand the above, in this command you are doing something
with two rule `conntrack' and `hashlimit'. But what? Adding them?
Setting rule behavior?

>iptables -I INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
>   -j DROP

   -j, --jump target
  This specifies the target of the rule; i.e., what to do
if  the packet  matches  it.   The  target  can  be a user-defined
chain (other than the one this rule is in), one of the special builtin
  targets  which  decide the fate of the packet
immediately, or an extension (see EXTENSIONS below).  If this option
is omitted  in a rule (and -g is not used), then matching the rule
will have no effect on the packet's fate, but the counters on the rule
will be incremented.

So if the inbound packet has some property which matches any of those
specified in the `--tcp-flags' list, drop it?

Questions:

How do these commands function to lock out specific addresses or
address ranges?

In the `--tcp-flags' list, why is `SYN' mentioned twice?

Re: DenyHosts

[Steve Matzura]

On Sat, 16 Jan 2016 01:55:38 +0300, Reco wrote:

>A complex one:
>
>iptables -I INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
>   -m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
>   --hashlimit-mode srcip --hashlimit-name ssh \
>   --hashlimit-htable-expire 6 -j ACCEPT
>
>iptables -I INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
>   -j DROP

Thank you. Since the simple solution didn't work, I took a chance and
used the second more complex one. The two commands were accepted
without error, and with no other status or output messages. I will now
use manpages and figure out what it is I just did.

Re: DenyHosts

[Reco]

Hi.

On Fri, 15 Jan 2016 16:37:48 -0500
Steve Matzura <s...@noisynotes.com> wrote:

> My new fledgling server is being slammed, and I mean slammed like
> Sandy slammed New York, by root login attacks from 59.46.71.36,
> ShenYang, China. Of course, I don't allow root logins except from the
> console or via ssh key pair, so I presume I'm safe that way, but I'd
> sure like to cut down on the log churning of /var/log/auth.log,
> particularly since it makes it harder to read that log to get the
> stuff I need to know out of it. My router (Fios Quantum gateway) is
> useless at blocking anything from the outside, so I've got to do it
> internally. What are folks' favorite deny-hosts applications? I tried
> installing DenyHosts, but it must be from a private repo because
> whatever I have in sources couldn't find it.

Why bother with userspace when you can force a kernel to do the job?

A simple solution:

iptables -I INPUT -p dcp -s 59.46.71.0/24 -j DROP

A complex one:

iptables -I INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
-m hashlimit --hashlimit 1/hour --hashlimit-burst 16 \
--hashlimit-mode srcip --hashlimit-name ssh \
--hashlimit-htable-expire 6 -j ACCEPT

iptables -I INPUT -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
-j DROP

Reco

Re: DenyHosts

[Steve Matzura]

On Sat, 16 Jan 2016 01:55:38 +0300, Reco wrote:

>A simple solution:
>
>iptables -I INPUT -p dcp -s 59.46.71.0/24 -j DROP

iptables v1.4.21: unknown protocol "dcp" specified
Try `iptables -h' or 'iptables --help' for more information.

Should I try the complex solution, or find out what went wrong with
the simple one first?

Re: DenyHosts

[David]

On 16 January 2016 at 15:48, Steve Matzura  wrote:
> On Sat, 16 Jan 2016 01:55:38 +0300, Reco wrote:
>
>>A simple solution:
>>
>>iptables -I INPUT -p dcp -s 59.46.71.0/24 -j DROP
>
> iptables v1.4.21: unknown protocol "dcp" specified
> Try `iptables -h' or 'iptables --help' for more information.
>
> Should I try the complex solution, or find out what went wrong with
> the simple one first?

There's a typo in the command Reco gave you.

The dcp should be tcp, like the others. In full it should be:

iptables -I INPUT -p tcp -s 59.46.71.0/24 -j DROP

denyhosts error

[Paul Cartwright]

I am getting these to my local user, and I can't figure out what process is 
sending them, so I can correct it:


 This is the mail system at host paulandcilla.homelinux.org.

 I'm sorry to have to inform you that your message could not
 be delivered to one or more recipients. It's attached below.

 For further assistance, please send mail to postmaster.

 If you do so, please include this problem report. You can
 delete your own text from the attached returned message.

The mail system

 r...@localhost: mail transport unavailable
From: 
DenyHosts nob...@localhost
  To: 
r...@localhost
  Date: 
Tuesday 7:22:14 am
   
Added the following hosts to /etc/hosts.deny:
xxx.xxx.xxx.xxx ( don't want to propagate spammers.)
-- 
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: denyhosts error

[Sjors Gielen]

Paul Cartwright schreef:
I am getting these to my local user, and I can't figure out what process is 
sending them, so I can correct it:



 From:
 DenyHosts nob...@localhost
  To:
 r...@localhost

There are two ways to fix this, 2 is probably preferred:

1) By default, in the Denyhosts Debian package, the configfile is 
installed at /etc/denyhosts.conf. If you didn't take the Debian package, 
it will be at /usr/share/denyhosts/denyhosts.cfg. Either way, edit this 
file, and look for the line starting with ADMIN_EMAIL. Set this to your 
own e-mail address.


2) Configure your mailserver to forward r...@localhost to you. For some 
hints, check /etc/aliases (at least on Postfix, don't know about Exim).


Sjors


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: denyhosts error

[Paul Cartwright]

On Sun March 1 2009, Sjors Gielen wrote:
   DenyHosts nob...@localhost
    To:
   r...@localhost

 There are two ways to fix this, 2 is probably preferred:

 1) By default, in the Denyhosts Debian package, the configfile is
 installed at /etc/denyhosts.conf. If you didn't take the Debian package,
 it will be at /usr/share/denyhosts/denyhosts.cfg. Either way, edit this
 file, and look for the line starting with ADMIN_EMAIL. Set this to your
 own e-mail address.

I changed it in the denyhosts.conf, we will see if that works.. I have been 
getting one or two of those message every day recently, not sure why it just 
started doing that. May be because I have ssh forwarded from my router to my 
desktop, and http port 8000 forwarded to my desktop..

 2) Configure your mailserver to forward r...@localhost to you. For some
 hints, check /etc/aliases (at least on Postfix, don't know about Exim).

I already had root forwarded to my local user in aliases, that is already 
working, which is why I was confused..


-- 
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Mas de tcpwrappers y denyhosts

[ciracusa]

Lista, siguiendo con el tema de tcpwrappers y denyhost he dado con este 
artículo:


http://www.tu-chemnitz.de/docs/lindocs/RH9/RH-DOCS/rhl-rg-es-9/s1-tcpwrappers-access.html

En el se comenta -entre otras cosas- que las reglas de hosts.allow son 
leidas primero que las de hosts.deny.


Teniendo en cuenta esto, no logro comprender la siguiente situación:

- Si partimos de la base que para poder conectarme a un servicio -en mi 
caso ssh- debo haberlo habilitado expresamente en el archivo hosts.allow:


ej. /etc/hosts.allow
sshd: 192.168.1.100

Que sentido tiene entonces que denyhosts agregue sus bloqueos al archivo 
/etc/hosts.deny, si el que se lee primero es el allow?


Bueno, espero haber sido claro en mi explicación.

Muchas Gracias.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mas de tcpwrappers y denyhosts

[Iñigo Tejedor Arrondo]

El lun, 24-03-2008 a las 15:10 -0300, ciracusa escribió:
 Lista, siguiendo con el tema de tcpwrappers y denyhost he dado con este 
 artículo:
 
 http://www.tu-chemnitz.de/docs/lindocs/RH9/RH-DOCS/rhl-rg-es-9/s1-tcpwrappers-access.html
 
 En el se comenta -entre otras cosas- que las reglas de hosts.allow son 
 leidas primero que las de hosts.deny.
 
 Teniendo en cuenta esto, no logro comprender la siguiente situación:
 
 - Si partimos de la base que para poder conectarme a un servicio -en mi 
 caso ssh- debo haberlo habilitado expresamente en el archivo hosts.allow:
 
 ej. /etc/hosts.allow
 sshd: 192.168.1.100
 
 Que sentido tiene entonces que denyhosts agregue sus bloqueos al archivo 
 /etc/hosts.deny, si el que se lee primero es el allow?

Que tcpwrappers [0] es un proyecto anterior y desvinculado de denyhosts:

[0] ftp://ftp.porcupine.org/pub/security/index.html
[1] http://denyhosts.sourceforge.net/

De la propia página del autor de tcpwrappers:

Wietse Venema's network logger, also known as TCPD or LOG_TCP. These
programs log the client host name of incoming telnet, ftp, rsh, rlogin,
finger etc. requests. Security options are: access control per host,
domain and/or service; detection of host name spoofing or host address
spoofing; booby traps to implement an early-warning system. The current
version supports the System V.4 TLI network programming interface
(Solaris, DG/UX) in addition to the traditional BSD sockets.

Y de la de denyhosts:
What is DenyHosts?
DenyHosts is a script intended to be run by Linux system administrators
to help thwart SSH server attacks (also known as dictionary based
attacks and brute force attacks).

Vamos que no hay nada que los vincule directamente, ni que diga que uno
tiene que funcionar bien con el otro. Wietse ni siquiera menciona el
sshen su descripción :-)

Para que denyhosts ignore IPs, tienes que crear el:

/var/lib/denyhosts/allowed-hosts

De acuerdo al fichero de conf. de debian y a:

http://denyhosts.sourceforge.net/faq.html#3_7

Si eso no te convence, quizás puedes abrir un BUG a la gente del
proyecto denyhosts, para que si una IP aparece en el hosts.allow, no se
moleste en agregarla al hosts.deny

 Bueno, espero haber sido claro en mi explicación.
 
 Muchas Gracias.

Saludos



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: denyhosts + tcp wrappers?

[Craig Hurley]

On 11/07/2007 04:44, Bob Proulx wrote:

If you are finding 'denyhosts' difficult then you may want to install
'fail2ban' as one standalone method to stop this since it is extremely
simple.  It should work out of the box.



Denyhosts did work out of the box.

My understanding of how denyhosts works is that it is scheduled to parse 
auth.log file every X seconds, identifing failed login attempts, it then 
tallies those attempts, if the total of failed login attempts is above Y 
write the source IP to /etc/hosts.deny.  The (very minor) hole here is 
that say denyhosts runs every 30 seconds, script-happy-john has a window 
of 30 seconds to guess user name  password pairs.


The purpose of the howto in the blog was to change the operation of 
denyhosts so rather than denyhosts being scheduled to parse auth.log 
every X seconds, denyhosts would be initiated every by every ssh login 
attempt.  Now script-happy-john only gets his first 3 attempts for free.


I will give fail2ban a go, after I'm finished testing with denyhosts.


I've read this blog: 
http://tdot.blog-city.com/securing_ssh_with_denyhosts.htm but there are 
differences in the files/paths used on debian and what the blog-author 
uses.  I've plugged along but I'm not sure if I have denyhosts 
configured right.


I don't see any file path problems.  Did you install the Debian
version?  I would assume that the Debian package maintainer took care
of getting all of the paths correct.


There are minor differences in the blog, maybe they were typos by the 
author?  IIRC there are also differences in the files paths referenced 
in the man pages and the files available in the debian install, I will 
confirm that when I'm on this particular machine again.


I downloaded denyhosts using apt; I've never changed the default apt 
sources since installing debian a couple of weeks ago.



The thing is, if I attempt to login via SSH using a bad 
username/password 3 times, there's a delay of approx 5-10 seconds before 
my IP address shows up in /etc/hosts.blocked.


Then it appears to be working.


It's this delay of 5-10 seconds that makes it possible for me to attempt 
more logins.




On averate half of that time would be waited before detection.
The alternative to this delay would be FAM and I am not sure it is
worth adding that as a dependency.


Never heard of FAM (linux beginner); I'll go check it out.


Also, if I change /etc/hosts.deny with the intention of blocking access 
to ALL services to IPs listed in /etc/hosts.blocked, denyhosts stops 
working as above.  Here's what I changed /etc/hosts.deny to:


/etc/hosts.deny
ALL:/etc/hosts.blocked
sshd:ALL:spawn /usr/sbin/denyhosts --purge -c /etc/denyhosts.conf:allow


I would avoid mixing simple and extended syntax in the same file.  I
would simply use the extended syntax and put everything in the
/etc/hosts.allow file.  Not sure this is the problem but I think it
would be a better practice anyway.  Also, dynamically updated files
are better placed in /var/run rather than in /etc.  Here is a
suggested improvement.  UNTESTED!

  ALL:/var/run/denyhosts/hosts.blocked:DENY
  sshd:ALL:spawn /usr/sbin/denyhosts --purge -c /etc/denyhosts.conf:ALLOW


I'll take this onboard and try again using these settings.


Thank you Bob.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: denyhosts + tcp wrappers?

[Andrew Sackville-West]

On Thu, Jul 12, 2007 at 06:37:13PM +0100, Craig Hurley wrote:
 On 11/07/2007 04:44, Bob Proulx wrote:
 If you are finding 'denyhosts' difficult then you may want to install
 'fail2ban' as one standalone method to stop this since it is extremely
 simple.  It should work out of the box.

 Denyhosts did work out of the box.

 My understanding of how denyhosts works is that it is scheduled to parse 
 auth.log file every X seconds, identifing failed login attempts, it then 
 tallies those attempts, if the total of failed login attempts is above Y 
 write the source IP to /etc/hosts.deny.  The (very minor) hole here is that 
 say denyhosts runs every 30 seconds, script-happy-john has a window of 30 
 seconds to guess user name  password pairs.

to solution to this problem is to read man sshd_config and look at
LoginGraceTime, MaxAuthTries, and MaxStartups. By tweaking these
values (though I think they're fairly good in stock configuration) you
can control all sorts of behaviors for ssh logins. 

MaxAuthTries is set to 6 and starts logging at half that value. At six
failures the connection is dropped. MaxStartups is 10, which means
that at most 10 unauthenticated connections at a time. With all ten
going, that's 60 attempts per shot basically. The point is even
looking at someone pounding it for 30 seconds before denyhosts picks
it up, its not really a whole lot of attempts. Throw in some firewall
rules to control frequency of permitted connections, and you can
majorly throttle someones ability to dictionary attack you. If you have good
passwords, you should be okay. 

There are other features you can throw in like random early drop
using the MaxStartups value. That will randomly kick people
(depending on how you set it) once you're above some threshold. 


finally, if possible, just turn off password authentication altogether
and pubkey authentication. 

A


signature.asc
Description: Digital signature

Re: denyhosts + tcp wrappers?

[Bob Proulx]

Andrew Sackville-West wrote:
 Craig Hurley wrote:
  My understanding of how denyhosts works is that it is scheduled to parse 
  auth.log file every X seconds, identifing failed login attempts, it then 
  tallies those attempts, if the total of failed login attempts is above Y 

  The (very minor) hole here is that 
  say denyhosts runs every 30 seconds, script-happy-john has a window of 30 
  seconds to guess user name  password pairs.

But that is not a hole.  Even without any type of rate limiting if
your passwords are reasonable then it is not possible to guess the
password.  So it really does not matter if the script kiddies are
shaking the door all of the time.  They are not going to get in.
These types of rate limiters are really only there for the aesthetics
of it and not for the security of it.  Seeing those extra entries in
the log file is annoying.  Hearing the disk drive rattle more often is
annoying.  Rate limiting controls those non-security issues.

 to solution to this problem is to read man sshd_config and look at
 LoginGraceTime, MaxAuthTries, and MaxStartups. By tweaking these
 values (though I think they're fairly good in stock configuration) you
 can control all sorts of behaviors for ssh logins. 

Good suggestions.

 The point is even looking at someone pounding it for 30 seconds
 before denyhosts picks it up, its not really a whole lot of
 attempts. Throw in some firewall rules to control frequency of
 permitted connections, and you can majorly throttle someones ability
 to dictionary attack you. If you have good passwords, you should be
 okay.

Agreed.

 finally, if possible, just turn off password authentication altogether
 and pubkey authentication. 

The best suggestion yet.  Using ssh rsa keys prevents even the
possibility of a dictionary attack from happening.

Bob


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

denyhosts + tcp wrappers?

[Craig Hurley]

Hello,

Has anyone installed and configured DenyHosts 
(http://denyhosts.sourceforge.net) so that it uses tcp wrappers on 
debian?  I've read this blog: 
http://tdot.blog-city.com/securing_ssh_with_denyhosts.htm but there are 
differences in the files/paths used on debian and what the blog-author 
uses.  I've plugged along but I'm not sure if I have denyhosts 
configured right.


I'm running:
debian: etch
kernel: 2.6.18-4-686
denyhosts: 2.6

Here are the main settings I've used to get denyhosts working (?):

/etc/denyhosts.conf
SECURE_LOG = /var/log/auth.log
HOSTS_DENY = /etc/hosts.blocked
BLOCK_SERVICE=sshd
DENY_THRESHOLD_INVALID=3
DENY_THRESHOLD_VALID=3
DENY_THRESHOLD_ROOT=3
DENY_THRESHOLD_RESTRICTED=3
AGE_RESET_INVALID=5m
AGE_RESET_VALID=5m
AGE_RESET_ROOT=5m
AGE_RESET_RESTRICTED=5m

/etc/hosts.deny
sshd:/etc/hosts.blocked
sshd:ALL:spawn /usr/sbin/denyhosts --purge -c /etc/denyhosts.conf:allow

The thing is, if I attempt to login via SSH using a bad 
username/password 3 times, there's a delay of approx 5-10 seconds before 
my IP address shows up in /etc/hosts.blocked.  I thought that by using 
tcp wrappers, denyhosts would put the IP into /etc/hosts.blocked much 
quicker than that.


Also, if I change /etc/hosts.deny with the intention of blocking access 
to ALL services to IPs listed in /etc/hosts.blocked, denyhosts stops 
working as above.  Here's what I changed /etc/hosts.deny to:


/etc/hosts.deny
ALL:/etc/hosts.blocked
sshd:ALL:spawn /usr/sbin/denyhosts --purge -c /etc/denyhosts.conf:allow

If anyone can advise or post the relevant sections of their working 
config I'd appreciated it.


Thanks,
Craig.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: denyhosts + tcp wrappers?

[Bob Proulx]

Craig Hurley wrote:
 Has anyone installed and configured DenyHosts 
 (http://denyhosts.sourceforge.net) so that it uses tcp wrappers on 
 debian?

I am confident that script kiddies shaking my doors and trying to lift
my windows cannot break through my passwords and rsa keys.  If
reasonable passwords are used and care is taken to prevent them from
being sniffed then I am confident that a brute force attack to crack
through a user and password combination is computationally infeasible.
Additionally if you ssh rsa keys then this type of attack cannot be
successful even if the connection is insecure.

I do however find the physical disk drive noise from one of my
machines as it is hit annoying and the extra noise to the log file is
also annoying.

If you are finding 'denyhosts' difficult then you may want to install
'fail2ban' as one standalone method to stop this since it is extremely
simple.  It should work out of the box.

  sudo apt-get install fail2ban

Both of these are python programs however and on some machines such as
my very small firewall I am prevented from installing a full python
environment due to disk space limitations.  If anyone can recommend a
similar solution that optimizes for disk space on a small dedicated
firewall please post it.

 I've read this blog: 
 http://tdot.blog-city.com/securing_ssh_with_denyhosts.htm but there are 
 differences in the files/paths used on debian and what the blog-author 
 uses.  I've plugged along but I'm not sure if I have denyhosts 
 configured right.

I don't see any file path problems.  Did you install the Debian
version?  I would assume that the Debian package maintainer took care
of getting all of the paths correct.  In any case I believe you have
the correct log file name /var/log/auth.log.

  apt-cache show denyhosts

 Here are the main settings I've used to get denyhosts working (?):

You will definitely want to time out blocked entries or you run the
risk of a Denial of Service attack.

 The thing is, if I attempt to login via SSH using a bad 
 username/password 3 times, there's a delay of approx 5-10 seconds before 
 my IP address shows up in /etc/hosts.blocked.

Then it appears to be working.

 I thought that by using tcp wrappers, denyhosts would put the IP
 into /etc/hosts.blocked much quicker than that.

I imagine (without looking and so may be quite wrong) that the delay
is due to getting access to the log file information to detect this
condition.  In order to avoid burning a high cpu when nothing is
happening most programs attempting this type of thing will need to
sleep for short periods of time and 10 seconds seems reasonable to
me.  On averate half of that time would be waited before detection.
The alternative to this delay would be FAM and I am not sure it is
worth adding that as a dependency.

 Also, if I change /etc/hosts.deny with the intention of blocking access 
 to ALL services to IPs listed in /etc/hosts.blocked, denyhosts stops 
 working as above.  Here's what I changed /etc/hosts.deny to:
 
 /etc/hosts.deny
 ALL:/etc/hosts.blocked
 sshd:ALL:spawn /usr/sbin/denyhosts --purge -c /etc/denyhosts.conf:allow

I would avoid mixing simple and extended syntax in the same file.  I
would simply use the extended syntax and put everything in the
/etc/hosts.allow file.  Not sure this is the problem but I think it
would be a better practice anyway.  Also, dynamically updated files
are better placed in /var/run rather than in /etc.  Here is a
suggested improvement.  UNTESTED!

  ALL:/var/run/denyhosts/hosts.blocked:DENY
  sshd:ALL:spawn /usr/sbin/denyhosts --purge -c /etc/denyhosts.conf:ALLOW

 If anyone can advise or post the relevant sections of their working 
 config I'd appreciated it.

Sorry for jumping in with the above when I am not a user of denyhosts
but hopefully it was a worthwhile contribution regardless.

Good Luck,
Bob


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: denyhosts + tcp wrappers?

[Jude DaShiell]

you might look at arno-iptables-script as another possibility.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

probleme mit denyhosts im aptitude

[Björn gräbe]

hallo,

ich kann das packet denyhosts nicht aktualisieren, entfernen klappt leider 
auch nicht. die fehlermeldung beim versuch der aktualisierung ist folgende

Stopping DenyHosts: denyhostsinvoke-rc.d: initscript denyhosts, action stop 
failed.
dpkg: Warnung - altes pre-removal-Skript wurde beendet mit Fehler-Status 1
dpkg - probiere stattdessen Skript aus dem neuen Paket ...
Stopping DenyHosts: denyhostsinvoke-rc.d: initscript denyhosts, action stop 
failed.
dpkg: Fehler beim Bearbeiten 
von /var/cache/apt/archives/denyhosts_2.5-2_all.deb (--unpack):
 Unterprozess neues pre-removal Skript gab den Fehlerwert 1 zurück
DenyHosts already running

ich hoffe mir kann jemand helfen

björn

Re: DenyHosts...

[Sven Hoexter]

On Tue, Aug 30, 2005 at 03:56:05PM -0400, Ralph Crongeyer wrote:
 Hi all,
 Is there a Debian Sarge package for DenyHosts?
 http://denyhosts.sourceforge.net/
None that I know but fail2ban looks similar.

Sven
-- 
If God passed a mic to me to speak
I'd say stay in bed, world
Sleep in peace
   [The Cardigans - 03:45: No sleep]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: DenyHosts...

[Ralph Crongeyer]

Roberto C. Sanchez [EMAIL PROTECTED] wrote: 
On Tue, Aug 30, 2005 at 03:56:05PM -0400, Ralph Crongeyer wrote:
 Hi all,
 Is there a Debian Sarge package for DenyHosts?
 http://denyhosts.sourceforge.net/
 

There is not.  However, you can use the reportbug package to file a RFP
bug.

-Roberto
-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


Thanks Roberto.
I haven't been able to get to my box to check and see if the package was
available. Work is blocking outbound SSH connections. And I couldn't find
anything on the web. 

Would a Request For Package make it into Sarge? Or just into Sid/Etch?

Thanks
--
Linux, to keep you humble.

Re: DenyHosts...

[Ralph Crongeyer]

Sven Hoexter [EMAIL PROTECTED] wrote: 
On Tue, Aug 30, 2005 at 03:56:05PM -0400, Ralph Crongeyer wrote:
 Hi all,
 Is there a Debian Sarge package for DenyHosts?
 http://denyhosts.sourceforge.net/
None that I know but fail2ban looks similar.

Sven
-- 
If God passed a mic to me to speak
I'd say stay in bed, world
Sleep in peace
   [The Cardigans - 03:45: No sleep]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]

Yea this looks similar. I would like to have a deb package so I could just
add it to my sources list though. :-)

Thanks
--
Linux, to keep you humble.

Re: DenyHosts...

[Roberto C. Sanchez]

On Wed, Aug 31, 2005 at 10:08:44AM -0400, Ralph Crongeyer wrote:
 Thanks Roberto.
 I haven't been able to get to my box to check and see if the package was
 available. Work is blocking outbound SSH connections. And I couldn't find
 anything on the web. 
 
 Would a Request For Package make it into Sarge? Or just into Sid/Etch?
 

Sarge is already released.  No new packages will be added.  An RFP, if
the is actually packaged, will first go into Sid.  After a suitable time
(10 days) it will go into Etch.  If no RC issues crop up, it will stay
in Etch (with new version migrating in from Sid).  If unfixed RC bugs
persiste, it will be removed from Etch and risk not being there in time
for release.

-Roberto
-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


pgpBOrjCFG89t.pgp
Description: PGP signature

Re: DenyHosts...

[Ralph Crongeyer]

Roberto C. Sanchez [EMAIL PROTECTED] wrote: 
On Wed, Aug 31, 2005 at 10:08:44AM -0400, Ralph Crongeyer wrote:
 Thanks Roberto.
 I haven't been able to get to my box to check and see if the package was
 available. Work is blocking outbound SSH connections. And I couldn't
find
 anything on the web. 
 
 Would a Request For Package make it into Sarge? Or just into Sid/Etch?
 

Sarge is already released.  No new packages will be added.  An RFP, if
the is actually packaged, will first go into Sid.  After a suitable time
(10 days) it will go into Etch.  If no RC issues crop up, it will stay
in Etch (with new version migrating in from Sid).  If unfixed RC bugs
persiste, it will be removed from Etch and risk not being there in time
for release.

-Roberto
-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


Thanks for the info. :-)

Ralph
--
Linux, to keep you humble.

DenyHosts...

[Ralph Crongeyer]

Hi all,
Is there a Debian Sarge package for DenyHosts?
http://denyhosts.sourceforge.net/

Thanks

Ralph
--
Linux, to keep you humble.

Re: DenyHosts...

[Roberto C. Sanchez]

On Tue, Aug 30, 2005 at 03:56:05PM -0400, Ralph Crongeyer wrote:
 Hi all,
 Is there a Debian Sarge package for DenyHosts?
 http://denyhosts.sourceforge.net/
 

There is not.  However, you can use the reportbug package to file a RFP
bug.

-Roberto
-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


pgpgiGY218qKy.pgp
Description: PGP signature