mrash/fwknop

Single Packet Authorization > Port Knocking

fwknop's Issues

OpenSSL compatibility by default for AES usage

The legacy way of generating salt + IV will be available through server access.conf variable support and a client command line argument. This will allow users to upgrade and not break backwards compatibility from a raw SPA communications perspective.

Add HMAC support for GPG modes

Add HMAC support for authenticated encryption when GPG is used.

[test suite] Don't remove output directory in --list mode

Make sure that the test suite does not remove any output directory from a previous run in --list mode.

UDP listener support (no pcap dependency)

Since nmap cannot tell the difference between a filtered or open UDP server when nothing is sent back in response to a probe (no UDP server is ever obligated to return anything out of necessity), there is room for a mode of operation where fwknopd binds to a UDP port and uses it to acquire SPA packet data. The advantage of this approach is that a fwknopd would not need to link against libpcap and can run as an unprivileged user except for the code that must adjust the firewall rule set.

Add ability to specify external script to take SPA command data and args

Add ability to specify external script to take SPA command data and args instead of calling the local iptables/ipfw directly. The first cut could be a simple hand off to the script with the script being responsible for creating the FW entry as well as removing that entry after the allotted time.

Android client limited IP selection

First, excellent excellent work! My security maintenance cost dropped a lot because fwknopd. (I had to upgrade my storage just to prevent disk full from bad login log).

I have two feature requests on the Android client:

1. Can there be an option to manually input the source IP, in addition to auto-detect? I use my phone to knock open the port but then use my laptop to actually do the ssh session. They have different IPs.
2. Can the server port be assigned? The code says "Until we make this settable." (android/project/jni/fwknop/fwknop_client.c line 105). Is it the current library limitation or just the client/wrapper implementation?

Thanks!

Add FORCE_NAT support for source port differentiation

Add support for multiple FORCE_NAT requirements per access stanza by using the incoming source to differentiate like so:

FORCE_NAT

This was suggested by "Poignant Murf" to the fwknop mailing list.

Ensure fko.h does not depend on other libfko headers

Damien found an issue with the current header file include strategy in fko.h where both rijndael.h and digest.h are required. This introduces unhelpful dependencies. Created the hmac_header_fixes branch to correct this issue.

Android and Windows GPG support

See what we can do for GPG support on Windows and other platforms (Android).

Ensure proper bounds checking for all strlcpy() calls

Make sure that all strlcpy() calls do not allow the circumstance where the number of bytes to copy is potentially larger than the size of the destination buffer.

[test suite] Ensure each test stops valgrind in --enable-valgrind mode

The test suite should make certain that valgrind is stopped at the conclusion of every test in --enable-valgrind mode.

Ruby bindings for libfko

Extend interpreted language support to Ruby.

OpenBSD PF NAT support

Extend fwknopd's NAT capabilities into the PF world.

[test suite] Add HMAC compatibility tests against OpenSSL

Make sure that the manner in which fwknop implements HMAC is compatible with how OpenSSL does it.

add knopwatchd to extras/ directory

Kevin Hilton reported that knopwatchd is not included in the fwknop-2.0 sources distribution. knopwatchd was part of the older perl fwknop distribution, and it wasn't promoted to the current fwknop C release. The reasoning was that there are other programs that are designed for this (such as monit, etc.). However, after thinking about it a bit, with fwknopd potentially deployed on small embedded systems where these other programs might not run, it seems like knopwatchd should be included in the extras/ directory at least. knopwatchd is extremely lightweight, and includes a feature set that is something controlled by the fwknop developers.

Replace encrypted msg len guesses with decryption operations

Use available decryption keys against incoming SPA packet data (perhaps only in HMAC mode for added security) instead of length guesses to infer which algorithm to try (Rijndael vs. GPG).

Add doxygen documentation

We should follow Franck's lead and add doxygen documentation to fwknop sources.

Optional pthreads support

This should be an optional feature gated by autoconf #defines, and not enabled by default. For users that want this, it would make for a cleaner way to implement firewall rules on the server side.

Add a series of HMAC tests that don't require base64 encoded keys

Some openssl installations don't support the hexkey: option, so on such systems it would be handy to have a series of rigorous HAMC tests that use plain keys that don't require base64 encoding (i.e. don't have embedded space or NULL chars, etc.).

Optional OpenSSL direct usage for crypto operations

This would introduce a dependency on the OpenSSL library, but some users may prefer this. Usage of OpenSSL would cause current crypto code to not be compiled in via autoconf #defines.

Key lengths passed to encryption routines - C strings not required

Specify encryption and HMAC key lengths via explicitly passing their length to crypto routines. This allows random data to be used for key information from the key generation code, and does not force libfko to guess at key length by the existence of a NULL char (which can now be part of a key).

Add HMAC support to the perl FKO module

The perl FKO module does not yet offer HMAC support in the hmac_support branch. This needs to be added before the HMAC code is released.

Ensure HMAC digest modes are selectable

Because we want to minimize libfko API changes after the fwknop-2.5 release, make sure that HMAC digest modes can be specified instead of forcing the mode to be HMAC-SHA256.

NAT mode not resolving hostnames to IP's

From Josh Smith:

There appears to be bug when using --nat-local in fwknop:

fwknop client version 2.0.4

When I do the following command:

fwknop -R -D www.mywebserver.tld -v -A tcp/PORT --nat-local --nat-port 22

I get the following error:

fwknop: fko_set_nat_access_str: Error 13 - Invalid SPA nat_access message format

However, when I replace www.mywebserver.tld with its actual IP the
command works. The basic command without natting works when I supply
the domain rather than the IP.

Build an Amazon fwknopd AMI

Create an Amazon AMI with fwknopd loaded and a default configuration that supports SNAT+DNAT so that other Amazon VPC instances can be reached through this host with SPA.

Update all docs to include HMAC information.

All fwknop documentation needs to be updated to include information on the upcoming HMAC support.

Add full IPv6 support to fwknop

Sometime potentially for the fwknop 2.1 release we should add full IPv6 support to both the fwknop client and fwknop server. A start was made on this for the client with this commit: http://www.cipherdyne.org/cgi-bin/gitweb.cgi?p=fwknop.git;a=commitdiff;h=6f79b6fb04090c53bca9abe53fc15e13786587da;hp=31ef94024cea1edb3024c9f78efa30794aa81264

Replace all atoi() calls with strtol()

The atoi() function does not detect errors, and should be replaced with calls to strtol().

User interfaces: GNOME, KDE, Windows

Implement viable user interfaces for SPA packet creation.

SELinux + AppArmor policy support

Both SELinux and AppArmor implement a Mandatory Access Control (MAC) layer within the kernel, and the fwknop sources should include policies to leverage these tools.

HMAC-SHA256 support

Usage of an HMAC will be optional and not the default in order to remain backwards compatible with older non-HMAC capable versions of fwknop. The libfko API will change though, so backwards compatibility will be maintained in the sense that an SPA packet produced by the fwknop-2.5 client can be decrypted by a pre-2.5 server, but pre-2.5 code cannot use the libfko 2.5 code and vice versa.

Android client: allow forwarding

The android client needs support for forwarding :)

ipfw NAT support

Extend fwknopd's NAT capabilities into the ipfw world.

Android client HMAC support

Add support to the Android client for the new HMAC modes.

Avoid duplicate iptables rules

I have played with fwknop on android and it works fine. Here is a part of my
iptables ruleset dump after sending multiple packets

     0     0 ACCEPT     tcp  --  any    any     192.168.1.14 \
anywhere             tcp dpt:ssh /* _exp_1357764373 */
     0     0 ACCEPT     tcp  --  any    any     192.168.1.14 \
anywhere             tcp dpt:ssh /* _exp_1357764374 */
     0     0 ACCEPT     tcp  --  any    any     192.168.1.14 \
anywhere             tcp dpt:ssh /* _exp_1357764374 */
     0     0 ACCEPT     tcp  --  any    any     192.168.1.14 \
anywhere             tcp dpt:ssh /* _exp_1357764374 */
     0     0 ACCEPT     tcp  --  any    any     192.168.1.14 \
anywhere             tcp dpt:ssh /* _exp_1357764374 */
     0     0 ACCEPT     tcp  --  any    any     192.168.1.14 \
anywhere             tcp dpt:ssh /* _exp_1357764374 */
     0     0 ACCEPT     tcp  --  any    any     192.168.1.14 \
anywhere             tcp dpt:ssh /* _exp_1357764374 */
     0     0 ACCEPT     tcp  --  any    any     192.168.1.14 \
anywhere             tcp dpt:ssh /* _exp_1357764375 */

Using the check option (-C) from iptables will allow fwknop to make sure not to insert duplicate rule (same timestamp). However, I do see any way to avoid adding the same access rule with different timestamps.

SPA packet size encryption method differentiation

The current message size test is a problem in some cases such as in command mode with long command strings being included within an SPA packet. One alternative would just be to pretty much ignore packet size and just try decrypting incoming packets according to the keys defined in the access.conf file. If no Rijndael key is defined in any stanza and only gpg is used, then decryption would only be attempted via gpg and vice versa.

This issue was reported by Ruhsam Bernhard.

[test suite] fix --diff mode 'no such file ...' error

Fix the following problem with the test suite:

./test-fwknop.pl --diff
No such file or directory at ./test-fwknop.pl line 783, line 21.

Log module for fwknop

What do you think about adding a log module for fwknop?

I mean I see sometimes if (options->verbose > 3) then print a message.

A log module could be registered :

Log_InitCtx(verbose, facility)

Then when there is something to print, it could be done by

Log_Msg(LOG_VERBOSITY_DEBUG, LOG_FACILITY_1, msg)

Debug information could be sent to stdout and errors to stderr for example.

Such a module could avoid reading the options->verbose context variable to know whether we have to print the message or not.

libcap-ng support

libcap-ng provides a way to drop privileges for certain operations, and fwknopd should support this.

Fix remaining gcc warnings on OpenBSD

There are still a few compilation warnings when compiling on OpenBSD - these should be fixed.

Rijndael keys are limited to 16 characters

Current fwknop-2.x code limits Rijndael keys to 16 chars whereas anything up to RIJNDAEL_MAX_KEYSIZE (32 chars) should be allowed.

This issue was reported by Michael T. Dean.

SPA packet size encryption method differentiation

The current message size test is a problem in some cases such as in command mode with long command strings being included within an SPA packet. One alternative would just be to pretty much ignore packet size and just try decrypting incoming packets according to the keys defined in the access.conf file. If no Rijndael key is defined in any stanza and only gpg is used, then decryption would only be attempted via gpg and vice versa.

This issue was reported by Ruhsam Bernhard.

Add HMAC support to the fwknop python extension

Before fwknop-2.5 is released, ensure that the fwknop python extension supports HMAC authentication.

Key generation support

Allow encryption and HMAC keys to be automatically generated and stored. This allows stronger keys to be used than normal user-provided passwords.

Use REDIRECT target for --nat-local implementation

Karthik Ganesan suggested to the fwknop mailing list the ability to use the iptables REDIRECT target on the fwknopd server side to implement --nat-local access. This would be a more natural way of accomplishing NAT to the local system instead of using the SNAT capability as well.

Add --save capability for saving stanzas

fwknop --save -D 10.0.0.1 -A tcp/22 -s -p 12345

... would create a stanza entry in .fwknoprc. This could then be executed as normal with:

fwknop -n

NB: Need to decide whether a stanza could be overwritten or not (ie. require manual editing of .fwknoprc).

iPhone client HMAC support

Add support to the iPhone client for the new HMAC modes.

Define of FIREWALL_TYPE by configure not possible

The current build system doesn't allow to set desired FIREWALL_TYPE during configure.
Currently it is hard coded to the first found binary following this trail:
iptables -> ipfw -> pf -> ipf

Respect setting of firewall with these options:
--with-iptables
--with-ipfw
--with-pf
--with-ipfw

Document HMAC support for the fwknop-2.5 release

Ensure that the new HMAC support is documented for the 2.5 release. This should include material that describes how to upgrade in a mixed fwknop environment (backwards compatibility, etc.).

Privilege separation support

Only two areas of fwknopd need to run as root: packet acquisition and firewall rule adjustment. Everything else should run as non-privileged user.