On Oct 19, 2013, Blair Zajac wrote: > On 10/17/2013 07:13 PM, Michael Rash wrote: > > Hello all, > > > > Here is a new blog post that sums up some of the things I've been > > thinking about regarding port knocking and how SPA solves its > > limitations: > > > > http://www.cipherdyne.org/blog/2013/10/port-knocking-why-you-should-give-it-another-look.html > > Are you referring to this article? > > http://bsdly.blogspot.com/2013/10/the-hail-mary-cloud-and-lessons-learned.html
Partially, yes, although I've heard similar arguments against port knocking in other settings so I didn't link to that post directly. > I read that and didn't get the arguments about not using port knocking. > Seems like if you do all the proper ssh protections, notwithstanding > having port-knocking, and then adding port-knocking, you have even less > to worry about. Indeed, I feel the same way. If the Hail Mary Cloud or other password guessing botnets are going to try and brute force PK they would still have a hard time even without going up against SPA. For example, the initial version of fwknop years ago supported shared PK sequences that could involve TCP, UDP, and ICMP packets, and further it could also require that the incoming TCP SYN packets conformed to a specified OS through passive OS fingerprinting. While none of these measures are strong in the cryptographic sense (which is one of the reasons SPA was developed), it would still require some pretty heavyweight port scanning by a botnet in order to successfully brute force (one could do the math on this and get an estimate for the number of packets that would be required - I'm confident this would be a non-trivial number for a sequence of any length). And all the while, a work flow that is similar to what I put in the blog post applies - i.e., each brute force attempt must be followed by an attempted connection to whatever service the adversary thinks the attempt should open up. Either way, with SPA the non-trivial number of packets for a brute force attempt is grounded in strong crypto. If an assertion is made that it is possible to brute force the fwknop vision for SPA, this is roughly equivalent then brute forcing a 512-bit HMAC SHA-256 key while simultaneously brute forcing an AES CBC 256-bit key. Or even worse for the GPG modes. I wonder which SPA implementations that bsdly post refers to when it is stated that SPA software includes the old port knocking code? fwknop has the old perl code in the legacy/ directory checked into the git repo, but it isn't even included in the tar distribution that people download and it certainly isn't (and won't be) supported by the C version. Either way, that isn't a reason not to consider SPA, and the bsdly post makes no effective argument against SPA specifically IMHO. > I still check my logcheck emails for security related log messages, so I > would hopefully see failed ssh attempts. Good point. --Mike > Blair ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Fwknop-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
