By default, fwknopd will now exit if the interface that it is
sniffing goes down (patch contributed by Github user 'sgh7'). If this
happens, it is expected that the native process monitoring feature in
things like systemd or upstart will restart fwknopd. However, if fwknopd
is not being monitored by systemd, upstart, or anything else, this
behavior can be disabled with the EXIT_AT_INTF_DOWN variable in the
fwknopd.conf file. If disabled, fwknopd will try to recover when a
downed interface comes back up.
The RULES_CHECK_THRESHOLD variable defines the number of times firewall rule
expiration times must be checked before a "deep" check is run. This allows
fwknopd to remove rules that contain a proper '_exp_<time>' even if a third party
program added them instead of fwknopd. The default value for this variable is 20,
and this typically results in this check being run every two seconds or so. To
disable this type of checking altogether, set this variable to zero.
Github user Scotte noticed that in his setup a 'VSS-Monitoring ethernet trailer'
was being added to incoming Ethernet frames that contained SPA packets. This
caused base64 decoding to break because the packet data length was calculated
from what libpcap returned for the frame (so these bytes became included in the
SPA payload itself). This issue was reported as #163 on github.
This commit has fwknopd calculate the SPA payload length using the length field
in the IP header so that any trailing bytes in the Ethernet frame are not
included. This solution also applies to the Ethernet Frame Check Sequence issue
(#126).
This is a significant commit that allows fwknopd to delete expired rules
from the firewall policy regardless of whether fwknopd is tracking them.
That is, a third party program could insert rules into the fwknopd
chains (iptables for now, but this will be extended to the other
firewalls) in order to take advantage of fwknopd rule deletion.
This commit fixes a bug where zero_cmd_buffers() was being called against the
wrong buffer as SPA rules were supposed to be deleted. Although multiple
iterations of check_firewall_rules() would have compensated, some rules would
not have been deleted as quickly as they should have in multi-rule scenarios.
This is a significant commit for issue #162 where fwknopd is not properly
detecting rules (particularly NAT rules) on systems running older versions
of iptables where -C support is not offered. A new capability of searching
the output of an external command and getting the first matching line was
added with the search_extcmd_getline() function.
This commit fixes the following warning during compilation on Mac OS X:
gcc -DHAVE_CONFIG_H -I. -I.. -I ../lib -I ../common -DSYSCONFDIR=\"/etc\" -DSYSRUNDIR=\"/var\" -g -O2 -Wall -Wformat -Wformat-security -fstack-protector-all -fstack-protector -fPIE -D_FORTIFY_SOURCE=2 -MT fwknopd-incoming_spa.o -MD -MP -MF .deps/fwknopd-incoming_spa.Tpo -c -o fwknopd-incoming_spa.o `test -f 'incoming_spa.c' || echo './'`incoming_spa.c
incoming_spa.c:736:23: warning: absolute value function 'abs' given an argument of
type 'long' but has parameter of type 'int' which may cause truncation of
value [-Wabsolute-value]
ts_diff = abs(now_ts - spadat.timestamp);
^
incoming_spa.c:736:23: note: use function 'labs' instead
ts_diff = abs(now_ts - spadat.timestamp);
^~~
labs
1 warning generated.
Having extra '/run' subdirectory hardcoded into paths used for options
'digest-file', 'pid-file', 'run-dir' is counterintuitive and can lead to
bogus directory layouts when 'localstatedir' differs from the default
value.
For example, if 'localstatedir' is set to '/run', which is a common and
recommended substitute for /var/run in many distros nowadays, then
fwknop files will be placed under /run/run/fwknop.
This changeset removes extra '/run' subdirectory from all relevant paths
by changing DEF_RUN_DIR. Default value of 'localstatedir' is changed to
'/var/run' so users who relied on the previous behaviour won't have to
bother changing anything.
This is tested and works. Gentoo have this patch applied since 2.6.0.
