Single-Packet Authentication (Crypto-Port-Knocking) in BASH

[Bones McCracker]

Here is a small set of BASH scripts you can take and use to set up your own single-packet authentication, and then customize it to your heart's content. I believe it is leaner and more secure the the available packaged solutions.

[Edit: note that the port-randomization concepts demonstrated in this post have been incorporated recently into fwknop as a command-line option, and the author has kindly credited this thread for the idea.]

Traditional port-knocking is vulnerable to replay attacks. While good single-packet authentication tools are not vulnerable to replay, they ARE vulnerable to piggy-back exploits. Some port-knocking tools install thousands of lines of code and dozens of perl modules and other dependencies. A couple hundred lines of BASH can do the job, give you complete flexibility, and reduce your vulnerability to scripts designed to attack common configurations. Analyzing and customizing this script for your needs should also be a good intermediate-level BASH learning exercise (please share your improvements).

The client script uses:

• openssl - used to encrypt a tiny unique one-time message
  
• hping - used to construct and send a packet containing the encrypted message

The "daemon" script uses:

• tcpdump - listens (outside the firewall) for the very special packet, and captures it
  
• openssl - decrypts the packet's payload

What's different about this approach is that it knocks on a random port every time (one of about 28,000) and makes the service connection on a random port every time. Some SPA solutions (not fwknop, any more) currently knock on one port -- the same port every time. That makes it pretty easy to monitor. And they do not randomize the ports used for service connections, which makes it very easy to simply piggy-back in on the open connection simply by spoofing the connecting client's address and banging away on the predictable port until it opens.

Aside from handling that randomization, this tool more or less imitates what is done by similar open source and commercially-available tools. The script uses encrypted information in the knock packet to decide how to insert or append iptables rules, opening a firewall port for a specific IP address only, connecting to a specific service behind the firewall, for a period of a few seconds only for a connection to be established, and then closing said port. The ongoing connection is maintained automatically by netfilter connection tracking and the port continuously appears to be closed to all other addresses, even while our client is connecting.

Please feel free to tell me how terrible my script is, as long as you tell me what I need to do make it better. : )

I call the client "Ramius", because like the submarine captain of that name in "Hunt for Red October", it sends "one ping only" (you must have seen the movie to appreciate this). Correspondingly, the daemon is called "hydrophone" because it listens for the ping.

The client consists of two scripts:

• ramius: the executable script shared system-wide among any users on the machine (run using su or sudo so hping can access a raw port); this belongs in /usr/loca/bin or someplace like that
  
• ramius_agent: a per-user extension script that runs with user privileges to initiate the actual service connections using the desired interface (e.g., ssh via shell or nautilus). Each user gets their own copy of ramius_agent so they can customize if desired, and a per-user configuration file; these go in ~/.ramius.

Similarly, the daemon consists of two scripts:

• hydrophone: basically a loop that listens for a packet using tcpdump, then parses the packet, then dispatches the airlock script to take action. Hydrophone is run as a daemon, launched by an initscript.
  
• airlock: instantiated by hydrophone to handle connections once a packet has been accepted and parsed. Airlock instances are run in parallel to hydrophone, so that multiple connections can be handled in rapid sequence if necessary. Airlock opens the port (inserts IPTables rules) waits a configurable period of time, and then closes it (removes IPTables rules).

It's easiest to understand by seeing the client first, so you understand what the daemon is decrypting and parsing.

First, a quick peek at the per-user config file. You could easily make any of these items command-line parameters if you prefer:

[UberPinguin]

Thanks very much for coming up with this - it addresses a number of concerns I've had about port knocking for a while.
I finally got around to trying to implement your scripts today, but I keep getting this error:

[Bones McCracker]

Sorry I didn't respond in time to be of help. Thanks for trying this, and I'm glad it works for you.

It appears that I did indeed fail to copy the entire ramius.conf file when I cut-and-pasted it in here, and these lines were missing:

[UberPinguin]

[Bones McCracker]

No, -a (spoof) was never one of the flags I used.

What this does is simply check to see if the directories exist, and if they don't, creates them. It shouldn't have caused an error:

[Bones McCracker]

Regarding the intermittent failure:

The vast majority of the time, the captured packet text looks like this:

[UberPinguin]

I'm also getting the "bad magic number" error on occasion, so I don't think it's due to your sed-fu. I'm afraid I won't be much help with sed, as my regex is not very good at all.
In the current implementation, if the packet is somehow damaged (bad magic number or something else that causes it to be incompletely parsed), hydrophone crashes completely and renders the box remotely inaccessible. I think we need to come up with a way to protect against that to make the script more robust, but I haven't come up with a workable solution yet.
_________________

[Bones McCracker]

I probably need to split that complex statement out into its three parts instead of using pipes. Then I could just log the error and jump out of the function on a non-zero exit code. That would keep the server-side script from crashing.

Notifying the client of the failure would make it something other than "single-packet" authentication and would require a listener on the client side. I don't think we want to go there. The client's connection attempts should perhaps have a limited time-out parameter if that can be included as a command-line option.

My intuition tells me the "bad magic number" problem I am having now is not caused by transmission error (i.e., it's not the occasional bad packet somehow mangled in transit). I was using this basic setup successfully for a month or so without that problem. Then, suddenly it's experiencing this. Although it could be a bug in hping or something, its more likely my own bad programming.

Right now, after implementing the revised sed statement, a half dozen trials show it seems to succeed on the first connection every time, and then fail (bad magic number) on the subsequent connection every time. At that point I went to bed and haven't got back to it yet. That might be something simple like bad programming -- a variable that must be reset each time or something like that.

If you are actually interested in putting some thought into this, in addition to this problem here are two other pretty core-level items that I could use somebody else's brain on:

1. I am running tcpdump one packet at a time. It's really designed to run and run. An alternative approach would be to run tcpdump continuously side-by-side with another process that receives the captures packets and then spawns the packet decomposition function in a separate thread for each packet captured. I was afraid to do that because I didn't want to end up with multiple processes trying to implement changes to the IPTables at the same time. Theoretically though, this kind of approach should work because of locking mechanisms internal to netfilter.

Tcpdump could write out to a FIFO, and then a separate loop (a peer process, if you will) could read the FIFO and fork subprocesses to perform packet decomposition (in other words, move the decomposition function into what is now the "airlock" script). In one of my very early prototypes, I think I was running tcpdump on a continuous basis like that, but I changed to a single-packet approach at some point for reasons I no longer recall.

2. The "packet history", which is checked to see if the incoming packet's hash has been received before, is currently just a log that grows indefinitely. It needs to be limited to a certain size or time period, maybe with the oldest packets being removed as new ones arrive. One idea that occurred to me is a ring-buffer of sorts, where a new file is created daily or weekly and the files are rotated. Maybe there's a better way. I wonder if a tiny database of some sort would be more efficient. The simplest approach would be to occasionally check the length of the file (as in wc -l) and delete the first 10 lines or whatever when it gets too long. I just haven't got round to giving this any thought yet.

[Bones McCracker]

Okay. Problem fixed. As far as a couple-dozen rapid-fire connections show, it now works consistently.
It was a combination of things. These are the changes I made:

1. Added the -A argument to the 'openssl enc' command to keep its output to a single line (which simplifies the task of parsing it from the surrounding packet text).
2. Modified the sed statement accordingly.
3. Put the value of $PASSARG in single-quotes instead of double-quotes.

The last one is a bit mysterious. I discovered the need to do this by interactively passing an extracted message string to the openssl decryption command used in the server script. It gave errors when the passarg was only in single quotes, apparently becoming confused by the exclamation point I had chosen to use in the actual passphrase. I thought this was probably just due to the fact that I was trying it in an interactive shell, but when I made the same change to the actual script, the behavior of "subsequent connections" failing disappeared.

So I will add the changes to the original post. Note that this change to the sed statement supersedes the one highlighted in the diff I provided above (that one can be ignored). For your convenience, here is a diff:

[UberPinguin]

This change broke hydrophone for me. Removing the -A from the openssl command restored functionality. The error was a rather vague "error reading input file".
_________________

[Bones McCracker]

Did you add the '-A' option to both sides (client and server)? It needs to go in the 'ssl enc' command in both the hydrophone script and the ramius script.

I suppose I probably should have mentioned that.

[UberPinguin]

Ah, sure enough that was the issue. Adding -A on both sides made it work
_________________

[Bones McCracker]

And here is the fix for the endlessly-growing packet history file. Be forewarned I was not in a position to test this, but it's fairly trivial so I hope it's ok. Let me know if you have problems.

Instead of a $HISTORY file, we now have a $DATA directory (to accomodate any future modifications that might also require persistent storage).

In the $DATA directory (i.e. /var/lib/hydrophone), there will be three history files, which will be rotated:
history.0
history.1
history.2

The hash of an incoming packet is appended to history.0.
When history.0 line count exceeds a threshold, the files are rotated like:
mv history.1 history.2
mv history.0 history.1

The incoming packets are compared to ${DATA}/history.* for uniqueness.

That "threshold" is one-third of $HIST_SIZE, which is configurable (the total number of records to keep). I have no idea what to set this to. I set it conservatively low (1500), but I suspect you could have tens or hundreds of thousands of records without any real performance problem (checking is a simple grep, and on the rare occasion that rotation is required, it will occur in parallel with the "airlock" script (the IPTables manipulation)). I imagine though that in reality most replay attacks would attempt to use a packet while fresh, probably even instantaneously upon receipt, so it might be quite realistic to set this number much lower, like 100 or so.

Here's the diff (it looks big because I changed a variable name and also moved a block of code). This is also in the original post if you want to just grab that:

[UberPinguin]

I was still getting intermittent failures on the payload function, so I took a closer look at it and asked for some help from a friend whose bash-fu is far greater than my own. This is what we came up with, as a substitute for all the sed work and piping:

[Bones McCracker]

[avx]

Nice one, altough it has some bash-ish - yeah, I know, bash is a dep on gentoo, but I still avoid it whenever possible. I'm trying to get this to perl if you don't mind. Till then, thanks.

[Bones McCracker]

[michaelrash]

Hi -

The original post regarding the idea to send SPA packets over random ports as well as creating NAT rules for incoming connections
over random ports is a good idea. I have implemented these ideas within the 1.9.4 release of fwknop, and credited BoneKracker with
the ideas:

http://www.cipherdyne.org/blog/2008/06/single-packet-authorization-with-port-randomization.html

Thanks,
_________________
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F

[Bones McCracker]

[michaelrash]

[Bones McCracker]

[UberPinguin]

Finally, with some help from SteveL, I managed to crack the stability issue when malformed packets or packets with the wrong password come in to the hydrophone script. Previously, this would crash the entire script, essentially creating a DoS.
Around line 81, I changed the payload= assignment statement to the following:

[Bones McCracker]

Awesome! I have not been having any problems, but that may be circumstantial.

Regarding this code: I like the use of PIPESTATUS (a builtin I didn't know about) as an alternative to breaking out the statements (so we can check the return code of the openssl enc statement. I'd like to use that. The alternative is breaking up that series of pipes and checking exit status of the openssl command (and 'return' if it's bad, to abort the f_decompose function).

However, other than the use of PIPESTATUS (and possibly printf) this function seems to introduce some inefficiency. Both of those can be used inline without nesting an additional function. Theoretically at least, the additional function call introduces overhead, as does its argument-handling. I don't follow the need to check the argument count, since the function call is intrinsic to the script (there will always be the right number of args). I'm not sure why printf is preferable to echo, but that could be substituted in the code as it stands without a function. I realize the rationale here may be over my head, so don't hesitate to educate me.

Maybe it would be more efficient to simply use PIPESTATUS like this:

[.yankee]

Seems like a great set of scripts, BoneKracker!
Though this makes little sense:

[Bones McCracker]