Quote:
Originally Posted by twobob
re parsing ;)
|
Are you meaning that: iptables --check that was posted above?
It is there with that design, or at least all that is practical to include.
At the top of each chain are two counters ;
If the chain rules are intended to account for everything, then they should always be zero:zero.
Notice that the OUTPUT chain counters are not zero:zero
Which means the "audit" counts on each rule do not total up to the number of packets:bytes that entered the chain (the top count is the number un-accounted for.)
Which means that top count of packets and bytes where handled by the "default" policy of the chain - in this case "drop".
Which is not necessarily "wrong" - just not included in the itemized counts.
There are (well "was supposed to be") a total accounting of all traffic by interface:protocol that was expected on the network.
Which is in each case followed by a "catch-all" counter of that which wasn't expected.
To "check" the rule-set, duplicate that final "catch-all" rule with the exception of the target, instead, use the non-terminating target of "log".
And then, the order matters.
**That** is very hard to "check" other than by eye.
Plus, it depends on the routing rules in place when the packet hit the firewall.
See the pretty packet-flow chart in the linked off-site reference.
The "mis-placed" rule would have allowed packets to escape the drop filter ****IF**** there had been a routing rule that allowed it.
There isn't (wasn't).
The two "missing" rules are the reason that the output chain is reporting un-audited packets.
So fixing 13039 with 13040 can wait until I have had a night's sleep.
No harm, no foul. ;)