For GPG mode, added a new access.conf variable "GPG_ALLOW_NO_PW" to make it
possible to leverage a server-side GPG key pair that has no associated
password. This comes in handy when a system requires the user to leverage
gpg-agent / pinentry which can present a problem in automated environments as
required by the fwknopd server. Now, it might seem like a problem to remove
the passphrase from a GPG key pair, but it's important to note that simply
doing this is little worse than storing the passphrase in the clear on disk
anyway in the access.conf file. Further, this link help provides additional
detail:
http://www.gnupg.org/faq/GnuPG-FAQ.html#how-can-i-use-gnupg-in-an-automated-environment
Ensure that an attacker cannot force a replay attack by intercepting an
SPA packet and the replaying it with the base64 version of "Salted__"
(for Rindael) or the "hQ" prefix (for GnuPG). This is an important fix.
The following comment was added into the fwknopd code:
/* Ignore any SPA packets that contain the Rijndael or GnuPG prefixes
* since an attacker might have tacked them on to a previously seen
* SPA packet in an attempt to get past the replay check. And, we're
* no worse off since a legitimate SPA packet that happens to include
* a prefix after the outer one is stripped off won't decrypt properly
* anyway because libfko would not add a new one.
*/
Conflicts:
lib/cipher_funcs.h
When using the --nat-local argument on the fwknop client command line, the
fwknopd server needs to add an INPUT ACCEPT rule for the requested access
since the incoming connection is destined for a local socket. Added test
suite support to test --nat-local access.
[test suite] Minor bug fix to ensure that all file_find_regex() calls return
true if all regex's are matched and false if any regex does not match data in
the specified file.
Richard Haas reported the test suite failing on Mac OS X systems with the
existence check for the libfko library. Damien Stuart advised that the library
has a different extention '.dylib' on Mac OS X, so this change accounts for the
difference.
This commit adds a new configuration variable "FORCE_NAT" to the access.conf
file:
For any valid SPA packet, force the requested connection to be NAT'd
through to the specified (usually internal) IP and port value. This is
useful if there are multiple internal systems running a service such as
SSHD, and you want to give transparent access to only one internal system
for each stanza in the access.conf file. This way, multiple external
users can each directly access only one internal system per SPA key.
This commit also implements a few minor code cleanups.
This commit does two major things:
1) Two new access.conf variables are added "ACCESS_EXPIRE" and
"ACCESS_EXPIRE_EPOCH" to allow access stanzas to be expired without having
to modify the access.conf file and restart fwknopd.
2) Allow an access stanza that matches the SPA source address to not
automatically short circuit other stanzas if there is an error (such as when
there are multiple encryption keys involved and an incoming SPA packet is
meant for, say, the second stanza and the first therefore doesn't allow
proper decryption).
This commit does several things. First, a memory leak in fwknopd has been
fixed by ensuring to free access.conf stanzas. This bug was found with the
new test suite running in --enable-valgrind mode. Here is what some of the
valgrind output looked like to find the leak:
==19217== 11 bytes in 1 blocks are indirectly lost in loss record 3 of 5
==19217== at 0x4C2815C: malloc (vg_replace_malloc.c:236)
==19217== by 0x52F6B81: strdup (strdup.c:43)
==19217== by 0x10FC8B: add_acc_string (access.c:49)
==19217== by 0x1105C8: parse_access_file (access.c:756)
==19217== by 0x10B79B: main (fwknopd.c:194)
==19217==
==19217== 16 bytes in 1 blocks are indirectly lost in loss record 4 of 5
==19217== at 0x4C27480: calloc (vg_replace_malloc.c:467)
==19217== by 0x10FEC0: add_source_mask (access.c:88)
==19217== by 0x110100: expand_acc_source (access.c:191)
==19217== by 0x1104B0: parse_access_file (access.c:500)
==19217== by 0x10B79B: main (fwknopd.c:194)
==19217==
==19217== 183 (152 direct, 31 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 5
==19217== at 0x4C27480: calloc (vg_replace_malloc.c:467)
==19217== by 0x1103E4: parse_access_file (access.c:551)
==19217== by 0x10B79B: main (fwknopd.c:194)
==19217==
==19217== LEAK SUMMARY:
==19217== definitely lost: 152 bytes in 1 blocks
==19217== indirectly lost: 31 bytes in 3 blocks
==19217== possibly lost: 0 bytes in 0 blocks
==19217== still reachable: 8 bytes in 1 blocks
==19217== suppressed: 0 bytes in 0 blocks
Second, this commit changes how fwknopd acquires packet data with
pcap_dispatch() - packets are now processed within the callback function
process_packet() that is provided to pcap_dispatch(), the global packet
counter is incremented by the return value from pcap_dispatch() (since this is
the number of packets processed per pcap loop), and there are two new
fwknopd.conf variables PCAP_DISPATCH_COUNT and PCAP_LOOP_SLEEP to control the
number of packets that pcap_dispatch() should process per loop and the number
of microseconds that fwknopd should sleep per loop respectively. Without this
change, it was fairly easy to cause fwknopd to miss packets by creating bursts
of packets that would all be processed one at time with the usleep() delay
between each. For fwknopd deployed on a busy network and with a permissive
pcap filter (i.e. something other than the default that causes fwknopd to look
at, say, TCP ACK's), this change should help.
Third, the criteria that a packet must reach before data copying into the
buffer designed for SPA processing has been tightened. A packet less than
/greater than the minimum/maximum expected sizes is ignored before data is
copied, and the base64 check is done as well.
This commit makes it easier to determine exactly which commands fwknopd
runs in --verbose mode when interacting with the underlying firewall.
This commit also adds --verbose --verbose mode to the test suite.
