On 20.09.2014 18:20, PGNd wrote: > Hi Gerhard > > On Sat, Sep 20, 2014, at 08:53 AM, Gerhard Wiesinger wrote: > > > 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.
Interesting. How long is your knocking sequence? 8 should be enough. Of course someone with network access can sniff (ISPs, etc.). Nevertheless it should be very unlikely. > > 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. > > fwknop/SPA is also a nice approach but there are also user land library dependencies and possible security leaks (http://www.cipherdyne.org/blog/2012/09/single-packet-authorization-the-fwknop-approach.html). Of course iptables might also have a security leak. But as far as I know there never was any in the past. libpcap might also have security leaks, I think there were some in the past. OpenVPN has also a nice feature with static key authentication. All other non matching packets are ignored. Ciao, Gerhard -- http://www.wiesinger.com/ ------------------------------------------------------------------------------ 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
