[prev in list] [next in list] [prev in thread] [next in thread]
List: dropbear
Subject: Re: restrict access
From: Hans Harder <hans () atbas ! org>
Date: 2021-05-25 11:28:07
Message-ID: CAKzsc6dgY==T+mKv+PfWnK1zX9G=2VpUP0hBWo-kktjOoEw1bw () mail ! gmail ! com
[Download RAW message or body]
or when you have no root access...
On Tue, May 25, 2021 at 11:14 AM Walter Harms <wharms@bfs.de> 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 <steffen@sdaoden.eu>
> 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
> <c5f4926e2308461ab1fa7d7be0b3b5c5@bfs.de>:
> > 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)
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic