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)
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 >>>
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