mrash / fwknop

Single Packet Authorization > Port Knocking

Home Page:http://www.cipherdyne.org/fwknop/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error removing rules from firewall ruleset (Version 2.6.10, FreeBSD 11.2, PF)

fishcreek opened this issue · comments

Hello,

I have tested fwknop-2.6.10 on FreeBSD 11.2. I configured the FreeBSD port for PF and did a make install. Then I created the anchor fwknop, exchanged keys and choosed the following config:

egrep -v '^#|^$' /usr/local/etc/fwknop/fwknopd.conf
VERBOSE 1;
PCAP_INTF igb1;
ENABLE_PCAP_PROMISC Y;

I started the service as forground process
fwknopd -f --syslog-enable

When I started the fwknop client and sent and Access message a corresponding
firewall rule was added to the anchor. After expiration the firewall was cleared.
(Debug level 10 shows the command: /sbin/pfctl -a fwknop -F all )
Next test was to call the client from different terminals with a higher frequency (about 10 times).
If you watch the anchor with pfctl you can see different rules being added and removed
but after the last rule the fwknopd service prints an error message: (LOG LEVEL 10)

Did not find expire comment in rules list 0.
run_extcmd() (without execvpe()): running CMD: /sbin/pfctl -a fwknop -s rules 2> /dev/null
run_extcmd(): returning 0, pid_status: 0

This message is also written to the system log file and causes the following output:
Mar 6 19:30:51 bsdrouter5 fwknopd[14029]: Did not find expire comment in rules list 0.
Mar 6 19:31:22 bsdrouter5 last message repeated 150 times
Mar 6 19:32:00 bsdrouter5 last message repeated 184 times

This error message is repeated endlessly, a fwknopd --fw-flush doesn't even help.
The "clear all rules" pfctl-command is never send, it seems as if the internal rules state
of the service is confused. You have to restart the service to stop this behavior.

BTW: I tried to start the test suit of the FreeBSD port to test the integrity of my build
but received a lot of errors starting with

/usr/ports/security/fwknop/work/fwknop-2.6.10/test]$ ./test-fwknop.pl
Subroutine main::getcwd redefined at ./test-fwknop.pl line 15.
Bareword found where operator expected at ./test-fwknop.pl line 8623, near "output/ test"
(Might be a runaway multi-line // string starting on line 8548)
Scalar found where operator expected at ./test-fwknop.pl line 8627, near "last to $output_dir"
(Do you need to predeclare last?)
...

Any Help appreciated!
Thanks

commented

Don't know how helpful this can be but I happened to stumble upon the same error message with fwknopd 2.6.9-4 on OpenWRT 18.06.2:

Tue Jul 23 16:33:01 2019 daemon.debug fwknopd[1075]: check_firewall_rules() CMD: '/usr/sbin/iptables -t filter -L FWKNOP_INPUT --line-numbers -n' (res: 0, ipt_output_buf: Chain FWKNOP_INPUT (1 references) num  target     prot opt source               destination         )
Tue Jul 23 16:33:01 2019 daemon.debug fwknopd[1075]: RES=0, CMD_BUF: /usr/sbin/iptables -t filter -L FWKNOP_INPUT --line-numbers -n RULES LIST: Chain FWKNOP_INPUT (1 references) num  target     prot opt source               destination
Tue Jul 23 16:33:01 2019 daemon.debug fwknopd[1075]: Did not find expire comment in rules list 0

The message repeats for rules lists 2 and 3 as well but curiously not 1. Unfortunately I do not know what these rules are. I do not see anything obvious in the list of firewall rules.

The messages stop at a certain moment, presumably right when I logged in from a machine in the local net which bypasses fwknopd.

Let me know if I can provide any more information!

I can reproducible produce this error with fwdrop 2.6.10 from the FreeBSD ports collection (options: PF/no gpgme), compiled on FreeBSD 11.2 and running fwdropd on a pfSense VM by sending two successful SPA packets to the fwdropd, generating two PF rules.

What happens is when the first expiring rule is due for deletion, fwdropd deletes both PF rules. Thus, the second rule can no longer be deleted when it expires (it's already gone), producing the Did not find expire comment in rules list 0. error repeatedly.

It must be a bug in the rule deletion code: Only the first rule should be deleted when it is due for deletion, not both rules.