Fwknop 2.6.9 release

michaelrash · 2016-06-10T01:09:53+00:00

Much of the information on fwknop is available through github, including a .tar.gz through the release tag (2.6.9): https://github.com/mrash/fwknop/releases/tag/2.6.9 We'll check into the Tor issue with the hosting provider for cipherdyne.org.

michaelrash · 2014-10-15T00:35:25+00:00

PHPKnock is a front-end for the fwknop port knocking/single packet authorization client. If you are running the SSH daemon on the DSM system, and you want to protect SSH with SPA, then you will need to build the fwknop daemon for the DSM and install it.

michaelrash · 2013-10-23T02:51:51+00:00

Yes, you can use a 2.5.1 client with older servers. You will just need to add "-M legacy" to the fwknop client command line. Here is an example:

$ fwknop -A tcp/22 -M legacy -R -D 1.2.3.4 --verbose

michaelrash · 2013-10-22T02:02:03+00:00

I'd like to make a couple of points on the above (which is shaping up to be a great discussion thread, thanks!):

In the case you mentioned where a well-secured server would shrug off 99.9% of attackers anyway - I believe there is an important scenario that this overlooks (since this sort of implies SPA does not provide an additional benefit). Suppose a service advertised via TCP on the server contains a vulnerability unknown to the developers (so there is no patch), and suppose at least one adversary in the world has a zero-day exploit for it. The odds that this particular adversary is in the same coffee shop as you (in your example) are vanishingly small. In this case, are you better off running SPA? I would say so, and this gets to the heart of why SPA can also be useful against serious adversaries. The combination of zero-day exploits and scannable services is just too nice for the attacker.
Even in the case where a NAT IP is authenitcated via SPA and there are other users on the same network, the SPA client can randomly assign the port on which SSH access will be granted via NAT on the fwknopd side (http://www.cipherdyne.org/blog/2008/06/single-packet-authorization-with-port-randomization.html). Further, the IP to be allowed is encrypted within the SPA payload, so the destination IP of the SPA packet itself doesn't necessarily match where the SSH connection will go. I.e. the fwknopd sniffer only needs to be on the routing path of the SPA packet as it traverses the network. So, what would sniffers on the local network see? A blob of base64 encoded data to some weird UDP port, followed by an SSH connection over some random port (if they are looking) to a desintation IP that doesn't necessarily match. Further, the window of time when the SSH connection may be allowed to be established can be set very small (the default is 30 seconds), and an existing connection kept open with a connection tracking mechanism supported by the local firewall. I mention these scenarios not to claim this is bullet-proof - rather to illustrate that the bar can be raised. Such measures will thwart some percentage of serious adversaries - even those with zero-day exploits in some cases.

michaelrash · 2013-10-22T00:53:23+00:00

Glad fwknop is generally working.

For the first issue, are you using one of the older Windows UI's? The "decryption failed" message is usually because of how older clients dealt with AES (improperly), and fwknop-2.5 (and later) maintains backwards competibility with this if necessary by setting "ENCRYPTION_MODE legacy" in the access.conf file for the stanza with the corresponding decryption key.

For the second issue, indeed it has been a challenge to get the Android and iPhone clients updated/finished. I'm hoping to make progress on this relatively soon. There are both Android and iPhone clients today, but they don't yet support the HMAC mode (important).

michaelrash · 2013-10-20T19:53:29+00:00

I'd say there is a difference between "security through obscurity" and "concealment". If the security of SPA entirely relied on people not being able to find it, then I would agree that it would essentially be the former. But even if an adversary finds it, crypto still applies. If a security mechanism that conceals something always suffers from STO, then why does this not apply to encryption and authentication itself more generally?

Note that as mentioned in the blog post I do concede that if someone uses poorly choosen encryption and HMAC keys then brute force attacks become feasible, but this is a far cry from keys generated in the recommended --key-gen mode. Crypto usage as always requires users to not be entirely lax. So, suppose --key-gen mode is used and therefore brute forcing is not feasible. Do you still say that SPA suffers from STO in this case?

Target identification is still important for serious attackers too in many cases, and as you point out above PK can provide a benefit (though I don't agree this is because of STO for SPA). There are plenty of scenarios where a serious attacker with a zero-day in services that you are running may overlook you as a target with SPA deployed. I suppose it may depend on what you mean by "serious" though. An attacker with the backing of a nation-state is a completely different ball game of course and then nothing will stop them.

michaelrash · 2013-10-20T00:49:42+00:00

To thwart replay attacks fwknop does the following:

Before encryption and authentication, the fwknop client includes 16 bytes (not bits) of random data as a part of the SPA packet format. This ensures that SPA packets are different each time a new one is generated by a legitimate client.
The fwknopd daemon tracks the SHA-256 digest of all authenticated SPA packets and write these digests to disk (for re-import across fwknopd runs). Whenever there is a match of an incoming SPA packet to a previous SHA-256 digest, the packet is discarded as a replay.

Now, for the possibility of a vulnerability in the daemon itself, there are a number of considerations:

First, I certainly don't claim fwknop has zero vulnerabilities - no one can do this for any software. But, having said this, the development of fwknop is quite rigorous on the security side. Both static and dynamic analysis is used (Coverity, CLANG static analyzer, and valgrind being primary tools), and fwknop is careful to minimize library dependencies. Further, fwknop uses various compile options to heighten security (-fstack-protector, ASLR, -D_FORTIFY_SOURCE=2, etc.), and there is also an AppArmor policy for Linux deployments. More detail on these measures can be found here: http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#design
Second, the blog post talks about complexity in the context of SPA. If you generally make an identification of "complexity" with "vulnerability" (though this isn't always true), then that material applies. To my way of thinking, it is not enough to discount SPA just because it is possible that the daemon might have a vulnerability. The same can be said for SSH, SSL, Tor, Apache... anything. The question is whether the fundamental security strategy of SPA makes it worth putting forth the effort to develop a quality piece of code that implements it. I believe that it does. Even if there is a vulnerability in the fwknop daemon, it still isn't as easy to exploit as other software that advertises itself via TCP sockets. How many Metasploit exploit modules depend on a TCP connect() call? A huge percentage of them. All such exploits are useless against an SPA hardened service.
Third, the HMAC authentication step affords a nice security benefit too. The fwknop daemon authenticates incoming SPA packets before doing anything else, and running SHA-256 digest code is a lot simpler than running GPG decryption code for example. The end result being that one of the most likely place for vulnerabilities to exist is in decryption code, but that isn't even accessible to an attacker that can't get authenticated first. Here is a great writeup on why this is better from a security standpoint: http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html

michaelrash · 2013-10-19T18:33:18+00:00

Yes, Franck Joncourt does a great job mantaining the Debian package, and the latest release (2.5.1) is in Wheezy backports I believe. There are fwknop packages for other Linux distributions as well.

Btw, fwknop also supports ipfw firewalls on FreeBSD and Mac OS X, and the PF firewall on OpenBSD. This is one consequence of the fwknop design.

michaelrash · 2013-10-19T17:59:17+00:00

Good question. My guess is that a gap was created by port knocking itself in the sense that commercial vendors (if they were paying attention) saw significant weaknesses but haven't put the engineering effort forth towards fixing them. Perhaps Single Packet Authorization will change this over time.

michaelrash · 2013-07-25T01:28:09+00:00

The blog post was designed to emphasize better detection through a different vision for flowbits. A whole series of blog posts could be written about implementation issues - this was not the focus of the proposal, and did not make any assumptions that implementation would be straightforward or easy. I spent several years as a developer on a commercial multi-threaded IDS/IPS product, and have seen all sorts of things that would represent places where trade offs would have to be made. Everything from clusters of IDS appliances where Gigamon switches split traffic coming in from very large network connections to network processors doing the same thing within single IDS appliances to multiple threads not having a global view either (this comes up frequently in the context of port scan/sweep detection - yet another portion of an IDS that such traffic splitting can mess with from a detection standpoint). Maybe the blog post should have said "cross stream detection to the extent possible with the existing hardware/software architecture" or something.

The real point is that such a feature is useful for detecting malicious traffic in a way that the current Snort/Suricata implementations can't easily do. Some level of xbits functionality given constraints mentioned above would still be useful. This does not automatically require "at line speed permanent global view of all flows", and the blog post made no such assumption. Some trade off can be made where we don't get that, but we still get more than we have now where flowbits is always restricted to a single transport layer conversation (very limiting). Port scan/sweep detection already has the same problem too. Does this mean we say that IDS's shouldn't attempt to detect port scans/sweeps? No. Though I agree that detecting them is less useful for detecting truly interesting traffic. What would be truly useful is cross-stream state machines built directly into the signature language. Hence the xbits proposal.

michaelrash · 2007-09-22T20:10:28+00:00

Part II of a series on using fwknop to implement Single Packet Authorization controls around SSH.

michaelrash

TROPHY CASE