Thread: Tutorial Block Big Brother
View Single Post
Old 02-09-2013, 03:51 AM   #15
knc1
Helpdesk Junkie
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 7,001
Karma: 6327868
Join Date: Feb 2012
Device: Too many.
Quote:
Originally Posted by twobob View Post
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. ;)
knc1 is offline   Reply With Quote