Marc:


I'm not exactly sure which of the problems you
are referring to , but how does one using a given
system sniff traffic BEFORE that system has even
come up fully? Again , 2 packets pass out before
PF is enabled and usually at least 3 others pass out
after PF has been enabled. I know that my system is
generating and sending out these packets , and that , in
all probability all of these packets are icmp6 packets.
I see no logic or security in sending out these packets before
/etc/pf.conf has been loaded. On this particular issue ,
are you saying that you believe it to be a Wise and Prudent
thing to do , to bring a system online for any length of
time without firewall-rules loaded? This kind of concept
seems more reminiscent of those prevalent in Microsoftland.
"If it's not an imminent problem , and does not affect our
reputation at this particular second in time , it must be
correct. Take no action".


I am FAR MORE concerned about the 3 or more packets that
regularly pass out of my system at each boot and reboot.
These packets are SPECIAL and PRIVILEGED , they can pass
out through PF regularly as if PF did-not-exist-for-them.
PF cannot log these 3 packets. PF cannot control these
packets in any way , the most I can get from PF is as a
pfctl -si statistic. The equivalent of "PF has failed to
stop these packets , PF has failed to log these packets , PF
has passed these packets out despite any firewall you thought
you were using". If I use PF to directly protect me from
WAN traffic , what is to stop someone from bombarding me with
infinite numbers of these packets (and any other similarly
affected "SPECIAL" and "PRIVILEGED" packets). PF cannot block
these packets , PF cannot even log these packets. PF has no
defense against these packets. The only thing PF might be able
to give me is pfctl -si statistics , informing me of exactly how
many unstoppable/unidentified IPv6 packets it was unable to stop.
Very helpful.


Ok Marc , please explain to me how , if all things are equal , my
system would not be more secure (subject to LESS possible attack
vectors and permutations lets say) if I were using an IPv4-ONLY OpenBSD
kernel and you were using an IPv4/IPv6 OpenBSD kernel? Just how many of
these successful present and FUTURE IPv6-based attacks am I likely to suffer
relative to yourself?


If I don't use something , if I don't need something , I don't install
it or I disable it. This is a more secure practice than installing or
enabling that which is not used (or desired). I don't use Microsoft
products , I don't have a "registry" on my OpenBSD system. Will anyone
EVER be launching a successful "registy attack" against me? Should I
worry? <g>


If you need IPv6 for some reason Marc , by all means use it. I do not
need it and prefer not to have IPv6 packets speeding out through my
firewall when my IPv4 packets cannot. Maybe i'm just an old-fashioned
sort of person that way , I feel that IPv6 and IPv4 packets should be
dealt with in similar ways. No special treatment.


As with the first 2 packets that pass out , the second 3 do so before
the machine has come up fully. Cannot be logged , cannot be sniffed.
Of the remaining 2 packets that try to pass out and are blocked , one
day 2 may appear as they should in pflog , on another day 0 will have
been logged , and on still other days PF is only able to log 1 packet.
Maybe there's a hidden pattern here , maybe PF can only log these same
packets reliably on every 3rd or 6th day? Has this bizarre behavior been
pencilled into the PF Manual when I wasn't looking? Or should I be chanting
some magical incantation to get PF to treat IPv6 packets sanely?

On Wed, 31 Jan 2007 10:58:48 -0700 (MST), Borked Pseudo Mailed wrote:
>I am FAR MORE concerned about the 3 or more packets that
>regularly pass out of my system at each boot and reboot.
>These packets are SPECIAL and PRIVILEGED , they can pass
>out through PF regularly as if PF did-not-exist-for-them.

There's much more that pf cannot filter. What about arp, as mentioned
before? And this thread might also be worth a look:
http://marc.theaimsgroup.com/?l=open...P+requests&q=b

--
Maurice

Borked Pseudo Mailed wrote:
[...]

> I am FAR MORE concerned about the 3 or more packets that
> regularly pass out of my system at each boot and reboot.
> These packets are SPECIAL and PRIVILEGED , they can pass
> out through PF regularly as if PF did-not-exist-for-them.
> PF cannot log these 3 packets. PF cannot control these
> packets in any way , the most I can get from PF is as a
> pfctl -si statistic. The equivalent of "PF has failed to
> stop these packets , PF has failed to log these packets , PF
> has passed these packets out despite any firewall you thought
> you were using". If I use PF to directly protect me from
> WAN traffic , what is to stop someone from bombarding me with
> infinite numbers of these packets (and any other similarly
> affected "SPECIAL" and "PRIVILEGED" packets). PF cannot block
> these packets , PF cannot even log these packets. PF has no
> defense against these packets. The only thing PF might be able
> to give me is pfctl -si statistics , informing me of exactly how
> many unstoppable/unidentified IPv6 packets it was unable to stop.
> Very helpful.
>
Have you tried to see if tweaking the /etc/rc file magically gets you
what you want?

If PF is enabled, it is started with a set of rules early on in the
startup process.

I imagine that this /might/ have something to do with the behaviour you
are seeing:

....
if ifconfig lo0 inet6 >/dev/null 2>&1; then
RULES="$RULES\npass out inet6 proto icmp6 all icmp6-type neighbrsol"
RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type neighbradv"
RULES="$RULES\npass out inet6 proto icmp6 all icmp6-type routersol"
RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type routeradv"
....

These might the neighbour discovery packets we've been told about. The
type names match up reasonably with the neighbour discovery notes in RFC
2461. The only one missing is "Redirect", which probably doesn't make a
whole lot of sense as these would likely be coming in on an interface
from another host in response to one or more of these four discovery
packets.

I have no idea what the fallout might be if you comment these out, but I
suspect if you do so, you will not see the traffic you mention.

Borked Pseudo Mailed <nobody@pseudo.borked.net> writes:

> I'm not exactly sure which of the problems you
> are referring to , but how does one using a given
> system sniff traffic BEFORE that system has even

Since the worry is about network traffic it seems to me that
the thing to do is use an *external* network sniffer. The sniffer
can be software on another computer on the network (tcpdump or
something similar) or a dedicated hardware device. Perhaps this
is only obvious to me due to by background/training. Don't know.
If I'm having problems with a system (even if the only problem is
my understanding) I tend to not trust that system and want to use
another to verify all findings.

> come up fully? Again , 2 packets pass out before
> PF is enabled and usually at least 3 others pass out
> after PF has been enabled. I know that my system is
> generating and sending out these packets , and that , in
> all probability all of these packets are icmp6 packets.

If you know with certainty that your system is generating and
sending out the packets why don't you know with certainty what
type of packets they are? If you don't know with certainty
what type of packets they are how can you be certain that
they are an IPv6/icmp6/inet6 vulnerability?

But this is really much ado about nothing. If you don't want
IPv6 in your kernel build a kernel that doesn't have it. It'll
take you about 30 seconds editing plus compile time. Just realize
that, like all all users of custom kernels, you are on your own
should there be any problems.

// marc