restrict access
Steffen Nurpmeso
steffen at sdaoden.eu
Tue May 25 08:40:50 AWST 2021
Walter Harms wrote in
<c5f4926e2308461ab1fa7d7be0b3b5c5 at 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)
More information about the Dropbear
mailing list