I own a Synology DS413j NAS, and without wanting to write a whole review about it, these things are awesome, the management UI is great, and you can run all kinds of packages on them. One thing I like to do with mine is run an OpenVPN server so that I can VPN into home and do cool stuff.
But I was a bit concerned about the notion of having my NAS internet-facing, even if it was only OpenVPN’s UDP port. So, powering through with my love for all things Dome9 (I swear they don’t pay me), I wrote my own little package that installs the Dome9 Agent onto a Synology NAS and allows you to control its firewall (and make dynamic access requests) through the Dome9 service. Now I can make pretty much any of my NAS’ services available to the internet, and not have to worry about random attackers discovering those services. Similar to Single Packet Authorization (although easier to set up and use), Dome9 allows you to dynamically open one or more ports to a given IP for a period of time, and so while the port is available to you, the services remain completely invisible to everyone else.
This is the first release of the Dome9 package, and while it may need more work to support other VPN protocols, it’s ready for testing. If you do use this package, I’d be keen to hear from you, as I’ve yet to find another Synology-owning Dome9 user!
To install this package, simply download the dome9.spk file (below) and use the Manual Install option in the Package Center in DSM. You will need to have a Dome9 account and enter your pairing key to allow the agent to pair with the Dome9 service.
Vasilis Mavroudis has launched WebKnock.org, a web-based front end to the fwknop (Single Packet Authorization) client. It does not yet seem to support the full suite of fwknop features, but the WebKnock site allows you to send basic auth packets to your fwknop server in order to open firewall ports. This can definitely come in handy if you need access to a port on your server, and don’t have the fwknop client handy on the computer, Android or iPhone (coming soon).
Note that although WebKnock uses SSL to protect the HTTP session, you are required to supply your fwknop password. If logged or intercepted, your knock details could be used to open firewall ports or even run commands on your server (depending on how you’ve configured fwknop). While WebKnock may be useful in a bind, from a purely security standpoint I don’t recommend using it regularly due to this risk. If you do use it, you should consider changing your fwknop passphrase.
I hope that WebKnock is eventually open-sourced to allow both for the code to be reviewed, and for people to host their own instance of WebKnock. It would also be nice to see more fwknop features being added, including the ability to define a username, and open multiple ports at once (eg. by entering: tcp/22 udp/53 tcp/80). The ‘Allow IP’ field should also get pre-populated with the visitor’s IP address for convenience.
Kernel.org, the primary site for the Linux kernel source, was compromised sometime in August. It is believed that the attackers gained access using compromised user credentials, and then escalated their privileges to root. Early pieces of information implied that some OpenSSH source code was stored on the compromised Kernel.org server(s), apparently this may not be the case. So far the investigation has found that several modifications were made to the compiled OpenSSH client and server binaries running on the system to log user activity. The full extent of the changes is not yet known, and nobody has yet come forward to claim this hack.
If you’ve installed or updated your kernel
or OpenSSH recently, you may want to reinstall from a known good version, although it is not yet known if any kernel sources were modified. Although in this case OpenSSH wasn’t compromised, admins can consider running some form of Single Packet Authorization, such as fwknop, as an additional layer of protection for your SSH server against these kinds of issues (backdoors) and other potential future 0days.
Hopefully more info will come to light as the investigation progresses. Hit the jump for more details.
Just a quick update to say that fwknop (Single Packet Authorization tool) has made it into the BackTrack 5 repository. Although it’s not installed by default, it’s a few keystrokes away, and can be installed by typing the following into the terminal:
apt-get install fwknop-client
apt-get install fwknop-server (if you want to use the server on your BackTrack install)
Note that it’s still version 1.9.12 of the Perl implementation, as the the C++ port (v 2.0) is still in the Release Candidate stage. Those of you who have been meaning to experiment with Single Packet Authorization and have already downloaded BT5, now’s a good time to install fwknop and give it a try! When installing fwknop-server it brings up an ultra-simple config screen that allows you to set up your initial passphrase.
I was just made aware of simpleSPA, a recently-released Java implementation of Single Packet Authorization by Chris Chrysler. The package provides a Linux-only server-side daemon, and a Linux and Windows client. Although I haven’t testing it yet, I assume the client will also work on Mac OS X. This implementation requires a Linux server as it relies on iptables being the firewall. simpleSPA uses two RSA keys in order to encrypt the authentication information. The first key encrypts the username of the user requesting access, while the second key is used to encrypt a pre-shared key and a timestamp (for freshness). The resulting authorization packet is then sent via UDP to the server. Although a timestamp is used, there doesn’t appear to be an explicit check for previously-received packets (ie. using a hash), so there may be some for time-limited replay attacks. Because RSA and public-keys are used, it’s a shame to see that it doesn’t use digital signatures to protect the payload.
simpleSPA does not allow for dynamic configuration of the firewall. As such, upon receiving a valid authorization packet (using Jpcap to sniff the wire), the server looks at a pre-defined config file that defines the firewall port(s) to be opened for the requesting user. Furthermore the port is opened for the IP that made the request, thus not allowing the client to embed an IP within the request and open a port out-of-band. The author states that this implementation is primarily an academic proof-of-concept at this point, and so is nowhere near as complete as other implementations such as fwknop (Perl/C) and Aldaba (C). It is nice, however, to see continued research and development into SPA as well as a Java implementation!
The open source Android client can be used to send authorization packets to a server running fwknop, thus opening ports based on a predefined ruleset. The application also has the ability to launch ‘Connectbot’ and connect to SSH, if this is the port being opened. Note that at the moment the Android client only provides only the most basic options of fwknop, and lacks GPG functionality, but hopefully we can look forward to these being added in the future.
Using a phone-based client to send an authorization packet on behalf of another computer can actually improve the security somewhat, as you’re sending that packet out-of-band (OOB), making it less susceptible to interception if the computer’s network traffic is being monitored.
Now we just need an iPhone/iOS app! Come on developers.
Episode 221 of Pauldotcom Security Weekly is available for download. In it I give a tech segment about Single Packet Authorization, briefly describe how to configure your firewall and use fwknop to dynamically open ports.
Here is a short video I made showing fwknop in action:
I’ve been invited to give a technical segment on Single Packet Authorization on the Pauldotcom Security Weekly podcast ‘Thanksgiving Special’ episode on Tuesday 23rd November. I’ve been listening to PSW practically from its very beginning, and if you’re only going to listen to one weekly security podcast, it’s definitely the one I’d recommend.
I’ll be giving an introduction into Single Packet Authorization, and show you how to install fwknop to protect your system and potentially vulnerable services from attack and exploitation.
[Update] Episode 221 is out!
After many months of work, fwknop (the Perl Single Packet Authorization implementation) has been entirely rewritten in C. The purpose of the C redesign has been primarily to allow an even more widespread deployment of SPA to devices on which the Perl implementation may not be suitable. One example of this is the OpenWRT platform which turns many entry-level routers into more flexible and powerful network devices. This now allows border routers to perform SPA and firewall manipulation, instead of doing this at the host-level (although it can be done at both).
The core of the C implementation is the libfko library which can be used by other applications to perform fwknop-compatible SPA. The Perl and C implementations are compatible with each other and the Perl version will continue being maintained. At the moment fwknop is still in Release Candidate, and will initially only support iptables. Further versions will bring it in line with the Perl version which supports additional firewall software and features.
fwknop offers both a server-side daemon – which listens for valid authorization packets and performs pre-defined activities (such as opening a firewall port) – as well as an SPA client which is used to construct authorization packets and send them to the target server. The Perl version of fwknop runs on Linux/Unix, Mac OS X, Windows and anything else capable of running Perl. The fwknop-C implementation should run on any device capable of compiling the necessary libraries. I haven’t yet tested it on OSX, but expect it will probably compile. The server-side functionality on OSX will have to wait until ipfw (OSX’s firewall) support is ported over.
The fwknop 2.0 source as well as a package for OpenWRT are available for download here.
I stumbled onto the ipt_pkd project recently, although apparently it’s been around since 2007. ipt_pkd is an iptables extension that allows you to do hash-based Single Packet Authorization directly within the iptables firewall. The project provides 3 parts: the kernel module ipt_pkd, the iptables user space module libipt_pkd.so, and a user space client knock program. The knock program (either a Python script or Windows exe) is used to send a UDP authorization packet.
The authorization packet consists of a SHA-256 hash of the following parameters: packet source port number, current time, some random data and a secret key. The current time and random bytes are then sent in the clear so that the server can recreate the hash. The final knock packet is 64 bytes long consisting of an 8-byte header, 4-byte id, 8-byte time, 12-byte random value, and the 32-byte SHA-256 hash.
The daemon does do some replay protection by storing valid hashes it has received and comparing newly received hashes against that list. It also does a verification of the timestamp to check for freshness.
I haven’t yet had the chance to try this one out or assess the security of the implementation, but it’s interesting to see an implementation in the form of an kernel module/iptables extension. If anyone’s tried this out I’d be interested to hear about it.