Ability to send SPA packets over DNS:
The fwknop client should allow the construction of SPA packets in the form
of DNS queries so that the fwknopd daemon can return to a log parsing
model of acquiring packet data. This would also facilitate easier
integration with Tor. This idea was suggested by Jacob Appelbaum.
Java SPA UI that can build SPA packets without using the fwknop client.
The SPA packet format is relatively straightforward, and it is should be
possible to build valid encrypted SPA packets without using the perl
Crypt::Rijndael module. In particular, it should be possible to construct
a Java UI that is capable of generating the appropriate SPA packet that an
fwknopd server can decrypt and decode. This would allow a UI to be
developed to complement the upcoming Delphi UI (which is already in
Integration with the PF firewall on OpenBSD:
The fwknopd daemon needs to be integrated with the PF firewall on OpenBSD
systems. This should be accomplished similarly to the code additions in
the 1.8, 1.8.1, and 1.8.2 releases (see all of the functions implemented
in fwknopd that have "ipfw" in their name, such as ipfw_add_ip_rule(),
ipfw_delete_ip_rule(), and timeout_ipfw_access()). The PF firewall offers
state tracking capabilities, so it should be possible to implement a
strategy similar to iptables firewalls for keeping a session open after
it an initial ACCEPT rule is deleted.
Ability to ignore IP addresses that have flooded fwknop with bogus or replayed
A threshold mechanism for the acceptance of SPA packets could be used to
weed out potential wrongdoers. There would need to also be a whitelisting
mechanism to augment this as a precaution against spoofed SPA packets used
as a DoS attack (forcing fwknopd to exclude networks of the attacker's
choosing from accepting valid SPA packets).
Web SPA proxy:
This could turn into a substantial development effort, but the idea is to
allow an SSL-protected webserver to generate SPA packets (by executing the
fwknop client) on behalf of web clients. By using the fwknop "-a" command
line argument, the web server can build SPA packets against a remote
fwknopd server such that the client address is allowed through. This
effort would largely be a web development effort to build a website, but
it could be a nice feature since not everyone has the ability to run the
fwknop client itself.
Develop a performance and benchmarking capability to find the current
bottlenecks in the fwknopd server:
There is no current capability for generating large numbers of valid SPA
packets in order to benchmark the fwknopd daemon. Collecting the actual
statistics on how fwknopd is running is relatively easy by running under
"perl -d:DProf" and using dprofpp, but a new piece of code needs to be
created to drive the fwknop client to generate thousands of SPA packets
to see where fwknopd has performance issues. One design decision in
fwknopd that persists today is that SPA packet decryption is attempted
before calculating the MD5 sum, and that is probably backwards. This
new benchmarking capability would make it easy to vividly show whether
this decision has negative performance implications. This task may be
fairly easy by writing a script that drives the fwknop client with the
"--get-key <file>" command line argument to have fwknop read the key or
password from a file.
External authentication support (LDAP, Kerberos, Radius, etc.):
Frequently there are existing authentication mechanisms in place that it
would be useful to interface with. This can add an additional layer to
SPA communications by allowing access to be granted by fwknopd only after
it has received a valid authentication response via this external
mechanism. The first effort at interfacing with such a mechanism was in
fwknop-0.9.6 with the integration of UNIX crypt(). Adding support for
other mechanisms such as LDAP, Kerberos, and Radius would be a great
addition to fwknop.
Update fwknopd to get decryption passwords from a UNIX domain socket after
This feature will make it possible to run fwknopd without having any
passwords or keys within /etc/fwknop/access.conf, at the expense of not
being able to decrypt SPA messages if there is a reboot until the keys and
passwords are entered in again. But, assuming the user is aware of this,
it might be something that is useful in some deployments.
- Doc links in email messages linking back to help docs on cipherdyne.org
- Integrate with clients programs besides SSH.
- Integrate with other packet filtering architectures and products.
- Add ability to re-import an updated config with --HUP option.
- SPA proxy support.
- Solve the key management issue by interfacing with various existing
authentication systems (LDAP, Radius, Unix crypt(), etc.).
- Update IPTables::ChainMgr to be able to manage an iptables ruleset on a
- Reverse shell from fwknop server.
- Verbose status information for fwknop server that shows stats on the
number of authentication requests, currently allowed addresses, etc.
- Re-implement p0f for the pcap modes, and use to pre-filter before
attempting to decrypt (for better performance).
- External updating of web view into fwknop status information. Then by
allowing SSL encrypted sessions only with the webserver, a user can get
a view into what is actually happening on the server side.
- Tie in with pcap to detect when the first session actually established
after allowing access through the packet filter, and then shutting the
access off immediately after instead of requiring a timeout?
- Check to see if a service is actually listening before providing access.
- Secure IP auto resolution instead of cleartext http://www.whatismyip.com/.
One way to accomplish this may be to build a custom cgi script on
cipherdyne.org that returns a GPG-signed message that includes the source
- Scp patch.
- Privilege separation to reduce code that executes as root.
- ssh-agent integration.
- Verbosity settings on outgoing email messages.
- In command mode, the ability to run commands as users other than root.
- Ability to re-sync with an NTP server if an SPA packet is too old.
- Automated state rule additions.
- XML config?
- Firefox SPA extension.
- Finish fwknop tutorial.
- Payload offset to look for valid SPA data.