Add filter to restrict access
lately there was a discussion who to restrict access to a dropbear server. The
result were some solutions outside dropbear. I have attached a patch to show
how this could be done. It uses fnmatch() what means the patch is small and the
pattern is simple. (Try -D 192.168.1.*)
re,
wh
--- svr-runopts.c~ 2020-10-29 14:35:50.0 +0100
+++ svr-runopts.c 2021-05-29 23:01:01.087078502 +0200
@@ -102,6 +102,7 @@
"-W (default %d, larger may be faster, max 1MB)\n"
"-K (0 is never, default %d, in seconds)\n"
"-I (0 is never, default %d, in seconds)\n"
+ "-D (Host deny pattern e.g. 192.168.1.*)\n"
#if DROPBEAR_PLUGIN
"-A [,]\n"
" Enable external public key auth through \n"
@@ -163,6 +164,7 @@
svr_opts.hostkey = NULL;
svr_opts.delay_hostkey = 0;
svr_opts.pidfile = DROPBEAR_PIDFILE;
+ svr_opts.deny = NULL;
#if DROPBEAR_SVR_LOCALTCPFWD
svr_opts.nolocaltcp = 0;
#endif
@@ -247,6 +249,9 @@
case 'P':
next = _opts.pidfile;
break;
+case 'D':
+ next = _opts.deny;
+ break;
#if DO_MOTD
/* motd is displayed by default, -m turns it off */
case 'm':
--- svr-main.c~ 2020-10-29 14:35:50.0 +0100
+++ svr-main.c 2021-05-29 23:32:29.106964013 +0200
@@ -23,6 +23,7 @@
* SOFTWARE. */
#include "includes.h"
+#include
#include "dbutil.h"
#include "session.h"
#include "buffer.h"
@@ -249,6 +250,15 @@
/* Limit the number of unauthenticated connections per IP */
getaddrstring(, _host, NULL, 0);
+ if (debug_trace)
+ printf("%s:%s %s\n",__func__,remote_host,svr_opts.deny);
+ /* ignore certain IPs*/
+ if (svr_opts.deny)
+ {
+ if (fnmatch(svr_opts.deny,remote_host,FNM_PATHNAME) == 0)
+ goto out;
+ }
+
num_unauthed_for_addr = 0;
num_unauthed_total = 0;
for (j = 0; j < MAX_UNAUTH_CLIENTS; j++) {
--- runopts.h~ 2021-06-06 14:57:29.591763229 +0200
+++ runopts.h 2021-05-29 22:48:27.789528236 +0200
@@ -124,6 +124,7 @@
char * pidfile;
char * forced_command;
+ char *deny;
#if DROPBEAR_PLUGIN
char *pubkey_plugin;
AW: restrict access
yes, under normal circumstances you would use iptables to block the port. But
when you are forced to byte-counting and you do not want to install other
programms (and maintains them) on your embedded system, this is clearly an
option.
re,
wh
Von: Steffen Nurpmeso
Gesendet: Dienstag, 25. Mai 2021 02:40:50
An: Walter Harms
Cc: dropbear@ucc.asn.au
Betreff: Re: restrict access
WARNUNG: Diese E-Mail kam von außerhalb der Organisation. Klicken Sie nicht auf
Links oder öffnen Sie keine Anhänge, es sei denn, Sie kennen den/die
Absender*in und wissen, dass der Inhalt sicher ist.
Walter Harms wrote in
:
|I did a little experiment and it worked.
|
| if (fnmatch("192.168.1.*",remote_host,FNM_PATHNAME) != 0)
| goto out;
|
|this will allow only connections from 192.168.1.* to the server
|that shows the change can be very simple. I did not try with more compli\
|cated situations. The limits of this approach needs to be evaluated.
Since the begin of this thread this sounds like a 100% firewall
thing to me. Why would you like to compile this in?
I mean, i can imagine the NetBSD/FreeBSD black(now block)list
approach in which a server software who "knows" what has happened
acts via a hook instead of let some expensive log parser
reevaluate state which is known in the moment the log happens.
But this? I am not an administrator and thus firewall guru, but
i for example have in my net-qos.sh:fwcore_start() (heavily
vaporised this is)
change_chain INPUT
new_chain i_good i_alien i_sshorvpn i_tcp_new
add_rule -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
add_rule -j i_good
add_rule -j i_alien
add_rule -p tcp --syn -m conntrack --ctstate NEW -j i_tcp_new
change_chain i_tcp_new
fwcore_has_i ssh && add_rule -p tcp --dport ${p_ssh} -j i_sshorvpn
change_chain i_sshorvpn
So and in here you can allow or deny ssh-specific anyway you want
to, add, remove and change, use "-m recent" and hitcounts etc.,
and all without recompilation. (Having real address and/or CIDR
tables which could be managed separately would be cool though.)
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: restrict access
or when you have no root access...
On Tue, May 25, 2021 at 11:14 AM Walter Harms wrote:
>
> yes, under normal circumstances you would use iptables to block the port. But
> when you are forced to byte-counting and you do not want to install other
> programms (and maintains them) on your embedded system, this is clearly an
> option.
>
> re,
> wh
>
> Von: Steffen Nurpmeso
> Gesendet: Dienstag, 25. Mai 2021 02:40:50
> An: Walter Harms
> Cc: dropbear@ucc.asn.au
> Betreff: Re: restrict access
>
> WARNUNG: Diese E-Mail kam von außerhalb der Organisation. Klicken Sie nicht
> auf Links oder öffnen Sie keine Anhänge, es sei denn, Sie kennen den/die
> Absender*in und wissen, dass der Inhalt sicher ist.
>
>
> Walter Harms wrote in
> :
> |I did a little experiment and it worked.
> |
> | if (fnmatch("192.168.1.*",remote_host,FNM_PATHNAME) != 0)
> | goto out;
> |
> |this will allow only connections from 192.168.1.* to the server
> |that shows the change can be very simple. I did not try with more compli\
> |cated situations. The limits of this approach needs to be evaluated.
>
> Since the begin of this thread this sounds like a 100% firewall
> thing to me. Why would you like to compile this in?
>
> I mean, i can imagine the NetBSD/FreeBSD black(now block)list
> approach in which a server software who "knows" what has happened
> acts via a hook instead of let some expensive log parser
> reevaluate state which is known in the moment the log happens.
>
> But this? I am not an administrator and thus firewall guru, but
> i for example have in my net-qos.sh:fwcore_start() (heavily
> vaporised this is)
>
>change_chain INPUT
>new_chain i_good i_alien i_sshorvpn i_tcp_new
>
>add_rule -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
>
>add_rule -j i_good
>add_rule -j i_alien
>
>add_rule -p tcp --syn -m conntrack --ctstate NEW -j i_tcp_new
>
>change_chain i_tcp_new
>
>fwcore_has_i ssh && add_rule -p tcp --dport ${p_ssh} -j i_sshorvpn
>
>change_chain i_sshorvpn
>
> So and in here you can allow or deny ssh-specific anyway you want
> to, add, remove and change, use "-m recent" and hitcounts etc.,
> and all without recompilation. (Having real address and/or CIDR
> tables which could be managed separately would be cool though.)
>
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
AW: restrict access
I did a little experiment and it worked.
if (fnmatch("192.168.1.*",remote_host,FNM_PATHNAME) != 0)
goto out;
this will allow only connections from 192.168.1.* to the server
that shows the change can be very simple. I did not try with more complicated
situations. The limits of this approach needs to be evaluated.
Von: Dropbear im Auftrag von Sebastian Gottschall
Gesendet: Sonntag, 23. Mai 2021 02:34
An: Hans Harder
Cc: dropbear@ucc.asn.au
Betreff: Re: restrict access
WARNUNG: Diese E-Mail kam von außerhalb der Organisation. Klicken Sie nicht auf
Links oder öffnen Sie keine Anhänge, es sei denn, Sie kennen den/die
Absender*in und wissen, dass der Inhalt sicher ist.
i know .but consider that this was not my request. i was just answering
a question and giving a suggestion.
so i have no intentions to implement this on my side
Am 21.05.2021 um 16:56 schrieb Hans Harder:
> You can add some small code in svr_main.c for allowing/denying remote
> servers based on their ip address
>
> getaddrstring(, _host, NULL, 0);
> /* HH hostallow start */
> /* Check if remote host is allowed */
> if (hostallow_check(remote_host) == 0) {
> fprintf(stderr,"Not allowed, closing
> connection\n");
> goto out;
> }
> /* HH hostallow end */
> /* Limit the number of unauthenticated
> connections per IP */
> num_unauthed_for_addr = 0;
> num_unauthed_total = 0;
> for (j = 0; j < MAX_UNAUTH_CLIENTS; j++) {
>
> just add something like this in svr_main.c in the the main_noinetd function
> I check in the hostallow_check function if there is a certain file
> like host_.allow in a certain directory
> if not it will close the connection.
>
> Hans
>
>
> On Thu, May 20, 2021 at 5:05 PM Sebastian Gottschall
> 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 +, 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
>>>
Re: restrict access
Walter Harms wrote in
:
|I did a little experiment and it worked.
|
| if (fnmatch("192.168.1.*",remote_host,FNM_PATHNAME) != 0)
| goto out;
|
|this will allow only connections from 192.168.1.* to the server
|that shows the change can be very simple. I did not try with more compli\
|cated situations. The limits of this approach needs to be evaluated.
Since the begin of this thread this sounds like a 100% firewall
thing to me. Why would you like to compile this in?
I mean, i can imagine the NetBSD/FreeBSD black(now block)list
approach in which a server software who "knows" what has happened
acts via a hook instead of let some expensive log parser
reevaluate state which is known in the moment the log happens.
But this? I am not an administrator and thus firewall guru, but
i for example have in my net-qos.sh:fwcore_start() (heavily
vaporised this is)
change_chain INPUT
new_chain i_good i_alien i_sshorvpn i_tcp_new
add_rule -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
add_rule -j i_good
add_rule -j i_alien
add_rule -p tcp --syn -m conntrack --ctstate NEW -j i_tcp_new
change_chain i_tcp_new
fwcore_has_i ssh && add_rule -p tcp --dport ${p_ssh} -j i_sshorvpn
change_chain i_sshorvpn
So and in here you can allow or deny ssh-specific anyway you want
to, add, remove and change, use "-m recent" and hitcounts etc.,
and all without recompilation. (Having real address and/or CIDR
tables which could be managed separately would be cool though.)
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: restrict access
i know .but consider that this was not my request. i was just answering
a question and giving a suggestion.
so i have no intentions to implement this on my side
Am 21.05.2021 um 16:56 schrieb Hans Harder:
You can add some small code in svr_main.c for allowing/denying remote
servers based on their ip address
getaddrstring(, _host, NULL, 0);
/* HH hostallow start */
/* Check if remote host is allowed */
if (hostallow_check(remote_host) == 0) {
fprintf(stderr,"Not allowed, closing
connection\n");
goto out;
}
/* HH hostallow end */
/* Limit the number of unauthenticated
connections per IP */
num_unauthed_for_addr = 0;
num_unauthed_total = 0;
for (j = 0; j < MAX_UNAUTH_CLIENTS; j++) {
just add something like this in svr_main.c in the the main_noinetd function
I check in the hostallow_check function if there is a certain file
like host_.allow in a certain directory
if not it will close the connection.
Hans
On Thu, May 20, 2021 at 5:05 PM Sebastian Gottschall
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 +, 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
Re: restrict access
You can add some small code in svr_main.c for allowing/denying remote
servers based on their ip address
getaddrstring(, _host, NULL, 0);
/* HH hostallow start */
/* Check if remote host is allowed */
if (hostallow_check(remote_host) == 0) {
fprintf(stderr,"Not allowed, closing connection\n");
goto out;
}
/* HH hostallow end */
/* Limit the number of unauthenticated
connections per IP */
num_unauthed_for_addr = 0;
num_unauthed_total = 0;
for (j = 0; j < MAX_UNAUTH_CLIENTS; j++) {
just add something like this in svr_main.c in the the main_noinetd function
I check in the hostallow_check function if there is a certain file
like host_.allow in a certain directory
if not it will close the connection.
Hans
On Thu, May 20, 2021 at 5:05 PM Sebastian Gottschall
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 +, 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
> >
AW: restrict access
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 ? re, wh Von: Dropbear im Auftrag von Sebastian Gottschall Gesendet: Donnerstag, 20. Mai 2021 15:53 An: dropbear@ucc.asn.au Betreff: Re: restrict access isnt that a job for netfilter? Am 20.05.2021 um 15:23 schrieb Walter Harms: > Hello List, > actually i expected this would be a FAQ but i can not find an answer: > How can i restrict the hosts that are allowed to access the > dropbear server ? > > re, > wh
Re: restrict access
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.gottsch...@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 +, 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 > > >
Re: restrict access
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 +, 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
Re: restrict access
On Thu, May 20, 2021 at 02:29:20PM +, 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
Re: restrict access
even for little systems. i dont now if its about linux or something else, but even the smallest linux systems are comming with iptables at least. but if you have problems with brute force login attempts (we all have that), i can just suggest to use fail2ban. i use it to prevent the thousands of login attempts per day on my systems Am 20.05.2021 um 16:29 schrieb Walter Harms: 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 ? re, wh Von: Dropbear im Auftrag von Sebastian Gottschall Gesendet: Donnerstag, 20. Mai 2021 15:53 An: dropbear@ucc.asn.au Betreff: Re: restrict access isnt that a job for netfilter? Am 20.05.2021 um 15:23 schrieb Walter Harms: Hello List, actually i expected this would be a FAQ but i can not find an answer: How can i restrict the hosts that are allowed to access the dropbear server ? re, wh
Re: restrict access
isnt that a job for netfilter? Am 20.05.2021 um 15:23 schrieb Walter Harms: Hello List, actually i expected this would be a FAQ but i can not find an answer: How can i restrict the hosts that are allowed to access the dropbear server ? re, wh
Re: restrict access
Hi Walter, Dropbear doesn't have IP restrictions built in. You could use iptables/nftables, or tcpwrappers etc if you're running Dropbear in inetd mode. Cheers, Matt On Thu, May 20, 2021 at 01:23:28PM +, Walter Harms wrote: > Hello List, > actually i expected this would be a FAQ but i can not find an answer: > How can i restrict the hosts that are allowed to access the > dropbear server ? > > re, > wh
restrict access
Hello List, actually i expected this would be a FAQ but i can not find an answer: How can i restrict the hosts that are allowed to access the dropbear server ? re, wh
