[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dropbear
Subject:    Re: restrict access
From:       Fabrizio Bertocci <fabriziobertocci () gmail ! com>
Date:       2021-05-20 15:59:32
Message-ID: CADtzkx7VDDp2c6fmDUwzn=zJrh2_pVZjEn1KHDa9oCANt_PBOQ () mail ! gmail ! com
[Download RAW message or body]

I've used successfully (well, at least I believe it's successful) sshblack (
http://www.pettingers.org/code/sshblack.html) to block those pesky robots
through iptables.
To get it to work correctly It's not as obvious as it seems... and there
are some limitations, but once you are familiar with it, it does its job.
(In particular, the main issue of sshblack is that if not set up correctly,
its database and iptables goes out of sync after a reboot of the host and
it essentially fails to block login attempts. email me directly for more
details).
Regards,
Fabrizio


On Thu, May 20, 2021 at 11:09 AM Sebastian Gottschall <
s.gottschall@dd-wrt.com> wrote:

> what about a feature like blocking a client for N minutes if more than N
> times of failed logins. its relativily easy to implement and lows down
> brute force attacks
>
> Am 20.05.2021 um 16:44 schrieb Matt Johnston:
> > On Thu, May 20, 2021 at 02:29:20PM +0000, Walter Harms wrote:
> >> Thx for the fast response,
> >> for the background: little system, far-far-away land, but some
> script-kiddie is filling the log ...
> >> so no iptables or other fancy stuff. Seems i have to change that,
> somehow.
> >>
> >> @matt:
> >> in case i get something working ...
> >> i am thinking about fnmatch and inet_ntoa would that be acceptable ?
> > I'm not really sure it's the job of Dropbear to be doing
> > that filtering. Though I wonder if it might make sense to
> > optionally not bother logging failed SSH auth attempts,
> > given how many there are...
> >
> > Cheers,
> > Matt
> >
>

[Attachment #3 (text/html)]

<div dir="ltr">I&#39;ve used successfully (well, at least I believe it&#39;s \
successful) sshblack (<a \
href="http://www.pettingers.org/code/sshblack.html">http://www.pettingers.org/code/sshblack.html</a>) \
to block those pesky robots through iptables.<div>To get it to work correctly \
It&#39;s not as obvious as it seems... and there are some limitations, but once you \
are familiar with it, it does its job.</div><div>(In particular, the main issue of \
sshblack is that if not set up correctly, its database and iptables goes out of sync \
after a reboot of the host and it essentially fails to block login attempts. email me \
directly for more details).</div><div>Regards,</div><div>Fabrizio</div><div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 20, 2021 at 11:09 \
AM Sebastian Gottschall &lt;<a \
href="mailto:s.gottschall@dd-wrt.com">s.gottschall@dd-wrt.com</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">what about a feature \
like blocking a client for N minutes if more than N <br> times of failed logins. its \
relativily easy to implement and lows down <br> brute force attacks<br>
<br>
Am 20.05.2021 um 16:44 schrieb Matt Johnston:<br>
&gt; On Thu, May 20, 2021 at 02:29:20PM +0000, Walter Harms wrote:<br>
&gt;&gt; Thx for the fast response,<br>
&gt;&gt; for the background: little system, far-far-away land, but some script-kiddie \
is filling the log ...<br> &gt;&gt; so no iptables or other fancy stuff. Seems i have \
to change that, somehow.<br> &gt;&gt;<br>
&gt;&gt; @matt:<br>
&gt;&gt; in case i get something working ...<br>
&gt;&gt; i am thinking about fnmatch and inet_ntoa would that be acceptable ?<br>
&gt; I&#39;m not really sure it&#39;s the job of Dropbear to be doing<br>
&gt; that filtering. Though I wonder if it might make sense to<br>
&gt; optionally not bother logging failed SSH auth attempts,<br>
&gt; given how many there are...<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Matt<br>
&gt;<br>
</blockquote></div>



[prev in list] [next in list] [prev in thread] [next in thread]