Hi Gerhard On Sat, Sep 20, 2014, at 08:53 AM, Gerhard Wiesinger wrote: ... > enhanced the existing versions to implement a correct state machine. The > challenges were that the iptables rule set is per definition stateless > (I'm not talking about the internals e.g. conntrack table). So each > normal iptables rule is independent of the previous one. Therefore the > current state has to be remembered and queried again. All "wrong" ports > in the sequence must reset the state machine to the initial state. > > Another motivation was enhanced security without any running additional > processes and to write also a shorewall module :-) ... > Yes, knockd works well. As I wrote above no additional process is > necessary and therefore additional security is ensured (e.g. no libpcap > necessary). > Maybe there is also a performance advantage over libpcap library > implementation where all packets must be inspected. With iptables only > matching packets are inspected. >
Thanks for the comments. Re: the stateful approach, knockd's config-specified rules allow for arbitrary rule-setting. I do, now, understand your primary goals re: doing this in SW. In the case of traditional, port-based knocking, I'll explore use of your solution. Nicely done, Thanks. > Maybe someone can tell us other pros and cons of both concepts. A comment simply based on my experience to date ... I'm currently evaluating another approach to service protection. With a port-listener-based approach, as done here & in knockd, the ports need to be listening -- i.e., open. In the case of a generally stealthed fw, where default port state is closed/non-reponse, those open listener ports can be scanned for using nmap, and can disscovered with tcpdump ... I'd thought with a reasonable # of randonly-selected ports, this would eliminate all unauthorized access attempts for a protected service. To my real surprise, I still see access attempts -- using the knock sequences. I know I'm not leaking the knock-port specs, and change them, so I can only assume they're being otherwise discovered. The services are, in fact, further protected by AUTH & fail2ban-on-fail'd-AUTH, so not really an issue. But, surprising to me nonetheless. In response to my interests in implementing persistent, db-backed ACCOUNTING data, I've been looking at libpcap-based accounting methods. I.e., libpcap sniffing might already be in place for me; I have yet to quantify the performance penalty for doing so. Assuming that libpcap listening is already in place, for knock-like service protection, I'm exploring fwknop (http://www.cipherdyne.org/fwknop/) as an alternative. As a libpcap sniffer, NO open ports are required -- eliminating that compromise vector -- and it additionally supports encryption of the 'knock', addressing the portential for tcpdump compromise. A nice depolyment bonus is the availability of iOS/Android/WebUI fwknop 'knock' clients. ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
