[client] disable IP resolution in AFL_FUZZING mode
[fwknop.git] / 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.