Call for review: How to log REJECTED packets


#1

Dear friends,

I wrote this short HOWTO:
https://lede-project.org/docs/howto/log-rejected-packets

Please review. You may use this forum link or write directly on the wiki. After a week or two, review will end and I will remove the link to review in the HOWTO. You are welcome to help and improve this documentation!

Kind regards,
French fries


#2

Just my humble two cents: I think you should explain the difference between DROPing and REJECTing packets, or someone might change his configuration blindly.


#3

Done.

There is also quite a nasty side effect. As iptables outputs messages via kernel, it displays on the serial console port in continuous streams. I noticed this several times on other systems and don't know how to disable logging to screen.


#4

I had a look at iptables and again the LOG is a very simple implementation.

In LEDE, logging is done in two lines:

iptables -L | grep LOG
LOG all -- anywhere anywhere limit: avg 5/sec burst 5 /* !fw3 / LOG level warning prefix "REJECT(dest wan)"
LOG all -- anywhere anywhere limit: avg 5/sec burst 5 /
!fw3 */ LOG level warning prefix "REJECT(src wan)"

This is iptables current implementation and this sounds normal.

On the converse, here is an example of a logging rule generated by fwbuilder on port iperf3 (5201:5203);

host-sony-vaio / Policy / rule 6
$IPTABLES -N In_RULE_6
$IPTABLES -A INPUT -i enp0s29u1u1 -p tcp -m tcp --dport 5201:5203 -m state --state NEW -j In_RULE_6
$IPTABLES -A INPUT -i eth0 -p tcp -m tcp --dport 5201:5203 -m state --state NEW -j In_RULE_6
$IPTABLES -A In_RULE_6 -j LOG --log-level info --log-prefix "VAIO 6 -- ACCEPT "
$IPTABLES -A In_RULE_6 -j ACCEPT
$IPTABLES -N Cid26872X7681.0
$IPTABLES -A OUTPUT -o enp0s29u1u1 -p tcp -m tcp --dport 5201:5203 -m state --state NEW -j Cid26872X7681.0
$IPTABLES -N Out_RULE_6
for i_enp0s29u1u1 in $i_enp0s29u1u1_list
do
test -n "$i_enp0s29u1u1" && $IPTABLES -A Cid26872X7681.0 -d $i_enp0s29u1u1 -j Out_RULE_6
done
for i_eth0 in $i_eth0_list
do
test -n "$i_eth0" && $IPTABLES -A Cid26872X7681.0 -d $i_eth0 -j Out_RULE_6
done
$IPTABLES -N Cid26872X7681.1
$IPTABLES -A OUTPUT -o eth0 -p tcp -m tcp --dport 5201:5203 -m state --state NEW -j Cid26872X7681.1
for i_enp0s29u1u1 in $i_enp0s29u1u1_list
do
test -n "$i_enp0s29u1u1" && $IPTABLES -A Cid26872X7681.1 -d $i_enp0s29u1u1 -j Out_RULE_6
done
for i_eth0 in $i_eth0_list
do
test -n "$i_eth0" && $IPTABLES -A Cid26872X7681.1 -d $i_eth0 -j Out_RULE_6
done
$IPTABLES -A Out_RULE_6 -j LOG --log-level info --log-prefix "VAIO 6 -- ACCEPT "
$IPTABLES -A Out_RULE_6 -j ACCEPT

$IP6TABLES -N In_RULE_6
$IP6TABLES -A INPUT -i enp0s29u1u1 -p tcp -m tcp --dport 5201:5203 -m state --state NEW -j In_RULE_6
$IP6TABLES -A INPUT -i eth0 -p tcp -m tcp --dport 5201:5203 -m state --state NEW -j In_RULE_6
$IP6TABLES -A In_RULE_6 -j LOG --log-level info --log-prefix "VAIO 6 -- ACCEPT "
$IP6TABLES -A In_RULE_6 -j ACCEPT
$IP6TABLES -N Cid26872X7681.0
$IP6TABLES -A OUTPUT -o enp0s29u1u1 -p tcp -m tcp --dport 5201:5203 -m state --state NEW -j Cid26872X7681.0
$IP6TABLES -N Out_RULE_6
for i_enp0s29u1u1_v6 in $i_enp0s29u1u1_v6_list
do
test -n "$i_enp0s29u1u1_v6" && $IP6TABLES -A Cid26872X7681.0 -d $i_enp0s29u1u1_v6 -j Out_RULE_6
done
for i_eth0_v6 in $i_eth0_v6_list
do
test -n "$i_eth0_v6" && $IP6TABLES -A Cid26872X7681.0 -d $i_eth0_v6 -j Out_RULE_6
done
$IP6TABLES -N Cid26872X7681.1
$IP6TABLES -A OUTPUT -o eth0 -p tcp -m tcp --dport 5201:5203 -m state --state NEW -j Cid26872X7681.1
for i_enp0s29u1u1_v6 in $i_enp0s29u1u1_v6_list
do
test -n "$i_enp0s29u1u1_v6" && $IP6TABLES -A Cid26872X7681.1 -d $i_enp0s29u1u1_v6 -j Out_RULE_6
done
for i_eth0_v6 in $i_eth0_v6_list
do
test -n "$i_eth0_v6" && $IP6TABLES -A Cid26872X7681.1 -d $i_eth0_v6 -j Out_RULE_6
done
$IP6TABLES -A Out_RULE_6 -j LOG --log-level info --log-prefix "VAIO 6 -- ACCEPT "
$IP6TABLES -A Out_RULE_6 -j ACCEPT

fwbuilder sets a target prefix for each rejected packet, which is impossible in LEDE "zone" implementation.
Logging is way more refined, with a label/number for each rule and the corresponding number in logging.

To support proper logging, LEDE firewall would need to be vastly modified, which is currently not possible.


#5

I wrote a detailed paragraph about OpenWRT/LEDE limitations:
https://lede-project.org/docs/howto/log-rejected-packets#logging_limitation_in_openwrt_and_lede


#6

I tried to acces the sugested link to HOWTO, but the result is:

This topic does not exist yet


#7

The wiki has been reorganized some. The documentation overview is
https://openwrt.org/docs/start
with hyperlinks to the current links.

For packet logging try these:
https://openwrt.org/docs/guide-user/firewall/log_rejected_packets
or
https://openwrt.org/inbox/firewall/netfilter_iptables/iptables_log_targets


#8

I'd also be careful in realizing that logging dropped/rejected traffic on a resource-constrained device can turn a normal annoyance into a DoS situation. Even the usual and constant script-kiddie login or port-scan attempts can quickly cause a 64 kB buffer to roll, potentially causing loss of valuable log information.

ffries is long gone, perhaps in search of an OS with an automated "firewall builder" with greater sophistication than OpenWrt provided.


#9

Thanks dturvene