Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #163125 > unrolled thread

DenyHosts

Back to article view | Back to linux.debian.user

Contents

  DenyHosts Steve Matzura <sm@noisynotes.com> - 2016-01-15 22:40 +0100
    Re: DenyHosts Sven Arvidsson <sa@whiz.se> - 2016-01-15 22:50 +0100
    Re: DenyHosts "Cláudio E. Elicker" <elicker@gmail.com> - 2016-01-15 23:10 +0100
    Re: DenyHosts Reco <recoverym4n@gmail.com> - 2016-01-16 00:00 +0100
      Re: DenyHosts Steve Matzura <sm@noisynotes.com> - 2016-01-16 05:50 +0100
        Re: DenyHosts David <bouncingcats@gmail.com> - 2016-01-16 06:50 +0100
          Re: DenyHosts Chris Bannister <cbannister@slingshot.co.nz> - 2016-01-17 06:50 +0100
      Re: DenyHosts Steve Matzura <sm@noisynotes.com> - 2016-01-16 06:00 +0100
      Re: DenyHosts Steve Matzura <number6@noisynotes.com> - 2016-01-16 07:10 +0100
        Re: DenyHosts Reco <recoverym4n@gmail.com> - 2016-01-16 11:00 +0100
          Re: DenyHosts Steve Matzura <number6@noisynotes.com> - 2016-01-16 14:00 +0100
            Re: DenyHosts Reco <recoverym4n@gmail.com> - 2016-01-16 14:20 +0100
              Re: DenyHosts Steve Matzura <sm@noisynotes.com> - 2016-01-16 19:10 +0100
                Re: DenyHosts Reco <recoverym4n@gmail.com> - 2016-01-16 22:00 +0100
                  Re: DenyHosts Steve Matzura <number6@noisynotes.com> - 2016-01-16 22:30 +0100
          Re: DenyHosts Christian Seiler <christian@iwakd.de> - 2016-01-17 14:10 +0100
            Re: DenyHosts Moreanu Robert - Nicolae <robertmoreanu@gmail.com> - 2016-01-17 14:40 +0100
              Re: DenyHosts Bob Holtzman <holtzm@cox.net> - 2016-01-17 22:50 +0100
            Re: DenyHosts Igor Cicimov <icicimov@gmail.com> - 2016-01-17 14:40 +0100
    Re: DenyHosts Steve Matzura <sm@noisynotes.com> - 2016-01-16 18:10 +0100
      Re: DenyHosts Reco <recoverym4n@gmail.com> - 2016-01-16 18:20 +0100
        Re: DenyHosts Steve Matzura <number6@noisynotes.com> - 2016-01-16 19:10 +0100
          Re: DenyHosts Reco <recoverym4n@gmail.com> - 2016-01-16 21:50 +0100
            Re: DenyHosts Steve Matzura <number6@noisynotes.com> - 2016-01-16 22:40 +0100

Page 1 of 2  [1] 2  Next page →

#163125 — DenyHosts

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.

[toc] | [next] | [standalone]

#163127

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#163128

On Fri, 15 Jan 2016 16:37:48 -0500
Steve Matzura <sm@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.

[toc] | [prev] | [next] | [standalone]

#163131

	Hi.

On Fri, 15 Jan 2016 16:37:48 -0500
Steve Matzura <sm@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 60000 -j ACCEPT

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

Reco

[toc] | [prev] | [next] | [standalone]

#163134

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?

[toc] | [prev] | [next] | [standalone]

#163136

On 16 January 2016 at 15:48, Steve Matzura <sm@noisynotes.com> 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

[toc] | [prev] | [next] | [standalone]

#163193

On Sat, Jan 16, 2016 at 04:49:35PM +1100, David wrote:
> On 16 January 2016 at 15:48, Steve Matzura <sm@noisynotes.com> 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

[toc] | [prev] | [next] | [standalone]

#163135

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 60000 -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.

[toc] | [prev] | [next] | [standalone]

#163137

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 60000 -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?

[toc] | [prev] | [next] | [standalone]

#163141

	Hi.

On Sat, 16 Jan 2016 00:49:17 -0500
Steve Matzura <number6@noisynotes.com> 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 60000 -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

[toc] | [prev] | [next] | [standalone]

#163146

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.

[toc] | [prev] | [next] | [standalone]

#163148

	Hi.

On Sat, 16 Jan 2016 07:35:54 -0500
Steve Matzura <number6@noisynotes.com> 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 60000 -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

[toc] | [prev] | [next] | [standalone]

#163168

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
60000 -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.

[toc] | [prev] | [next] | [standalone]

#163178

	Hi.

On Sat, 16 Jan 2016 13:01:29 -0500
Steve Matzura <sm@noisynotes.com> 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
> 60000 -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.

[toc] | [prev] | [next] | [standalone]

#163180

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 60000 -j ACCEPT

[toc] | [prev] | [next] | [standalone]

#163204

[Multipart message — attachments visible in raw view] — view raw

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<TAB>
scp host:/srv/data/w<TAB>
scp host:/srv/data/website/ex<TAB>
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 10000 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 10000, so please don't
just use that number unconditionally either.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#163206

[Multipart message — attachments visible in raw view] — view raw

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 <icicimov@gmail.com> wrote:

>
> On 18/01/2016 12:08 AM, "Christian Seiler" <christian@iwakd.de> 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<TAB>
> > scp host:/srv/data/w<TAB>
> > scp host:/srv/data/website/ex<TAB>
> > 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 10000 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 10000, so please don't
> > just use that number unconditionally either.
> >
> > Regards,
> > Christian
> >
>



-- 

*o zi frumoasa !Robert - Nicolae  MOREANU*

[toc] | [prev] | [next] | [standalone]

#163224

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!

[toc] | [prev] | [next] | [standalone]

#163207

[Multipart message — attachments visible in raw view] — view raw

On 18/01/2016 12:08 AM, "Christian Seiler" <christian@iwakd.de> 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<TAB>
> scp host:/srv/data/w<TAB>
> scp host:/srv/data/website/ex<TAB>
> 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 10000 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 10000, so please don't
> just use that number unconditionally either.
>
> Regards,
> Christian
>

[toc] | [prev] | [next] | [standalone]

#163161

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
60000 -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
60000 -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
60000 -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
60000 -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
60000 -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
60000 -j ACCEPT
COMMIT

What'd I do?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web