perl/legacy/fwknop/TODO

   1
   2 Ability to send SPA packets over DNS:
   3
   4     The fwknop client should allow the construction of SPA packets in the form
   5     of DNS queries so that the fwknopd daemon can return to a log parsing
   6     model of acquiring packet data.  This would also facilitate easier
   7     integration with Tor.  This idea was suggested by Jacob Appelbaum.
   8
   9
  10 Java SPA UI that can build SPA packets without using the fwknop client.
  11     The SPA packet format is relatively straightforward, and it is should be
  12     possible to build valid encrypted SPA packets without using the perl
  13     Crypt::Rijndael module.  In particular, it should be possible to construct
  14     a Java UI that is capable of generating the appropriate SPA packet that an
  15     fwknopd server can decrypt and decode.  This would allow a UI to be
  16     developed to complement the upcoming Delphi UI (which is already in
  17     development).
  18
  19
  20 Integration with the PF firewall on OpenBSD:
  21
  22     The fwknopd daemon needs to be integrated with the PF firewall on OpenBSD
  23     systems.  This should be accomplished similarly to the code additions in
  24     the 1.8, 1.8.1, and 1.8.2 releases (see all of the functions implemented
  25     in fwknopd that have "ipfw" in their name, such as ipfw_add_ip_rule(),
  26     ipfw_delete_ip_rule(), and timeout_ipfw_access()).  The PF firewall offers
  27     state tracking capabilities, so it should be possible to implement a
  28     strategy similar to iptables firewalls for keeping a session open after
  29     it an initial ACCEPT rule is deleted.
  30
  31
  32 Ability to ignore IP addresses that have flooded fwknop with bogus or replayed
  33 packets:
  34
  35     A threshold mechanism for the acceptance of SPA packets could be used to
  36     weed out potential wrongdoers. There would need to also be a whitelisting
  37     mechanism to augment this as a precaution against spoofed SPA packets used
  38     as a DoS attack (forcing fwknopd to exclude networks of the attacker's
  39     choosing from accepting valid SPA packets).
  40
  41 Web SPA proxy:
  42
  43     This could turn into a substantial development effort, but the idea is to
  44     allow an SSL-protected webserver to generate SPA packets (by executing the
  45     fwknop client) on behalf of web clients.  By using the fwknop "-a" command
  46     line argument, the web server can build SPA packets against a remote
  47     fwknopd server such that the client address is allowed through.  This
  48     effort would largely be a web development effort to build a website, but
  49     it could be a nice feature since not everyone has the ability to run the
  50     fwknop client itself.
  51
  52
  53 Develop a performance and benchmarking capability to find the current
  54 bottlenecks in the fwknopd server:
  55
  56     There is no current capability for generating large numbers of valid SPA
  57     packets in order to benchmark the fwknopd daemon.  Collecting the actual
  58     statistics on how fwknopd is running is relatively easy by running under
  59     "perl -d:DProf" and using dprofpp, but a new piece of code needs to be
  60     created to drive the fwknop client to generate thousands of SPA packets
  61     to see where fwknopd has performance issues.  One design decision in
  62     fwknopd that persists today is that SPA packet decryption is attempted
  63     before calculating the MD5 sum, and that is probably backwards.  This
  64     new benchmarking capability would make it easy to vividly show whether
  65     this decision has negative performance implications.  This task may be
  66     fairly easy by writing a script that drives the fwknop client with the
  67     "--get-key <file>" command line argument to have fwknop read the key or
  68     password from a file.
  69
  70
  71 External authentication support (LDAP, Kerberos, Radius, etc.):
  72
  73     Frequently there are existing authentication mechanisms in place that it
  74     would be useful to interface with.  This can add an additional layer to
  75     SPA communications by allowing access to be granted by fwknopd only after
  76     it has received a valid authentication response via this external
  77     mechanism.  The first effort at interfacing with such a mechanism was in
  78     fwknop-0.9.6 with the integration of UNIX crypt().  Adding support for
  79     other mechanisms such as LDAP, Kerberos, and Radius would be a great
  80     addition to fwknop.
  81
  82
  83 Update fwknopd to get decryption passwords from a UNIX domain socket after
  84 startup:
  85
  86     This feature will make it possible to run fwknopd without having any
  87     passwords or keys within /etc/fwknop/access.conf, at the expense of not
  88     being able to decrypt SPA messages if there is a reboot until the keys and
  89     passwords are entered in again.  But, assuming the user is aware of this,
  90     it might be something that is useful in some deployments.
  91
  92
  93
  94  - Doc links in email messages linking back to help docs on cipherdyne.org
  95  - Integrate with clients programs besides SSH.
  96  - Integrate with other packet filtering architectures and products.
  97  - Add ability to re-import an updated config with --HUP option.
  98  - SPA proxy support.
  99  - Solve the key management issue by interfacing with various existing
 100    authentication systems (LDAP, Radius, Unix crypt(), etc.).
 101  - Update IPTables::ChainMgr to be able to manage an iptables ruleset on a
 102    remote system.
 103  - Reverse shell from fwknop server.
 104  - Verbose status information for fwknop server that shows stats on the
 105    number of authentication requests, currently allowed addresses, etc.
 106  - Re-implement p0f for the pcap modes, and use to pre-filter before
 107    attempting to decrypt (for better performance).
 108  - External updating of web view into fwknop status information.  Then by
 109    allowing SSL encrypted sessions only with the webserver, a user can get
 110    a view into what is actually happening on the server side.
 111  - Tie in with pcap to detect when the first session actually established
 112    after allowing access through the packet filter, and then shutting the
 113    access off immediately after instead of requiring a timeout?
 114  - Check to see if a service is actually listening before providing access.
 115  - Secure IP auto resolution instead of cleartext http://www.whatismyip.com/.
 116    One way to accomplish this may be to build a custom cgi script on
 117    cipherdyne.org that returns a GPG-signed message that includes the source
 118    address.
 119  - Scp patch.
 120  - Privilege separation to reduce code that executes as root.
 121  - ssh-agent integration.
 122  - Verbosity settings on outgoing email messages.
 123  - In command mode, the ability to run commands as users other than root.
 124  - Ability to re-sync with an NTP server if an SPA packet is too old.
 125  - Automated state rule additions.
 126  - XML config?
 127  - Firefox SPA extension.
 128  - Finish fwknop tutorial.
 129  - Payload offset to look for valid SPA data.