[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pfctl log|log-all
On Tue, 4 Jun 2002, Dries Schellekens wrote:
> On Mon, 3 Jun 2002, Yacketta, Ronald wrote:
> > Folks,
> > I have the pflog0 device and the /dev/pf device but yet I am not getting
> > any log information in /var/log/pflog when I add the log or log-all flag
> > to any rule in pf.conf
> > Any ideas why nothing is being logged? I can tcpdump the interface and
> > see traffic for that specific port
> Try apropos pflog, you'll see pflogd(8) packet filter logging daemon.
I believe I have observed the same thing as Mr Yacketta. In an
attempt to log certain traffic, I added "log" keywords to ineffective
rules I knew would not be triggered, i.e. would be "nops". I wanted
the side-effect of logging. No soap: (3.1-stable, recently updated).
Consider this elementary ruleset:
@0 scrub in on ppp0 all
@1 pass in log on ppp0 all
@2 pass out on ppp0 all keep state
@3 block in log on ppp0 all
Rule @1 is added in the hope of logging all inbound packets. In
practice, it will log NOTHING. Any logging from that ruleset will
come from rule @3. My impression is that only the *last matching
rule*, i.e. the "decisive" rule, will generate a log entry. (I
actually tested those rules, generating traffic from outside in an
ssh session, probing port 44 with telnet, and by triggering a
connection attempt to the auth port by retrieving mail from a
popserver. Only the port 44 and identd blocked packets were logged.
Suppose a rule @4 were added, allowing icmp echo requests to come in.
@1 would still not log those.)
It is easy to "intuit" pflog's behavior from the simple 4 rule set
exhibited above. It is not so easy from a longer, complicated set.
"Why is rule 432 not logging?" Also bear in mind that rules matching
a state, in this example from rule @2, are going to short-circuit
all rules. Presumably inbound traffic statisfying a state established
in rule @2 could be logged by adding a log side-effect to rule @2.
The "log" side-effect logs only pf's decisive actions, not its
tentative tagging of packets. (Rule @1 really seems to say, "All
inbound packets are *potentially* passable, verify this *later*;
if we turn out to be the authoritative, decisive rule for this
packet, then log that." So if rule @3 were weaker, say only blocking
tcp, then an icmp or udp packet passed by @1 *would* be logged.
Another way to look at it: an incoming packet that matches a rule
is given a ticket saying "Rule @n matches me". It continues down
the ruleset, everytime it matches a rule, the ticket is taken away
and a new one given. When it exits the rule set (by falling off
the end, or by matching a "quick" rule), its final ticket is examined,
and the indicated action and side effects taken. Rules matching a
state are shunted around all this, being elite, special cases.
("Step right this way, Your Excellency, no waiting in line...")
The conclusion seems to be implicit in Mr Yacketta's post: use
logging in pflog to track pf activity, specifically pf *decisions*.
To log interface activity, use tcpdump.
Calling the "log" modifier a "side-effect" emphasizes this behavior.
Perhaps if different logging behavior were wanted a new "major" command
(at the level of pass and block) could be added in some future edition
of pf/pfctl. One would then write rules like "log in on ppp0 all".
The example is silly, but my original attempt was to log certain
packets with more restrictions (i.e. tcp with SYN set, other flags,
tcp options, DF, and so on) but have them handed over to *other* rules for
disposition. That seems less silly. But this job is probably better
handled not by pf [keep it lean] but by a specialized sniffer like
"snort". Specialized job ==> Specialized tool.