blacklistd and IPv6 mapped IPv4 addresses

[Christos Zoulas]

Hi,

I noticed that some servers (proftpd) report their IPv4 connections
as IPv6 mapped addresses: ::ffff:x.y.z.w. Adding these addresses to npf,
works just fine (after I fixed the parser), but the packet filter does not
block connections from them because the rule does not match. Presumably
because the connections are processed by the IPv4 part of the stack and
there is no rule to match that.

What should blacklistd do? Recognize the mapped v4 addresses and convert
them to real v4 addresses and send those to the packet filter? Is that
guaranteed to work across different OS's? Or send both the v4 and mapped
v6 variants to the packet filter?

Or is it the responsibility of the packet filter to know that this is
a mapped v4 address and DTRT?

Thanks,

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Taylor R Campbell]

Date: Fri, 22 Jan 2016 17:18:35 -0500
From: ***@zoulas.com (Christos Zoulas)

What should blacklistd do? Recognize the mapped v4 addresses and convert
them to real v4 addresses and send those to the packet filter? Is that
guaranteed to work across different OS's? Or send both the v4 and mapped
v6 variants to the packet filter?

Or is it the responsibility of the packet filter to know that this is
a mapped v4 address and DTRT?

Certainly it should not be the application's responsibility, at least,
to conditionally handle v4-mapped addresses specially -- they should
just send on exactly what the system sent them as easily as possible.
Any other responsibility for the application is likely to be an
error-prone burden.

I expect it to be easy and low-cost to teach blacklistd to recognize
AF_INET6 with a v4-mapped address, and to tell the packet filter to
block AF_INET packets with the enclosed address.

It may be more trouble to teach the packet filter, or the compiler for
the packet filter in the case of npfctl, to do that itself. The
run-time cost of doing this for rules that are statically written with
AF_INET6 and v4-mapped addresses is likely negligible -- there is no
cost if you don't try to write such rules. But I can imagine an
operator naively expecting

block in final proto tcp from ::ffff:1.2.3.4/128 to any port 21

to generalize to

block in final proto tcp from mytable to any port 21

Making that generalization to work seems likely to me to incur a
nontrivial run-time cost. Not to mention that as stated, this rule
doesn't match what will be found in any packet on the wire -- the
kernel already rejects all v4-mapped addresses coming in on the wire
(although only after the packet filter has had a chance to run).

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Christos Zoulas
I noticed that some servers (proftpd) report their IPv4 connections
as IPv6 mapped addresses: ::ffff:x.y.z.w. Adding these addresses to
npf, works just fine (after I fixed the parser), but the packet
filter does not block connections from them because the rule does not
match.

Does proftpd actually use an AF_INET6 socket with the v4mapped address,
or is it using AF_INET sockets and just printing them that way?

My own take on the POLS here is that a v4 filter entry should stop any
matching v4 packets; a v4mapped v6 filter entry should stop any attempt
to receive matching traffic on a v4mapped v6 socket but should not
interfere with a native v4 socket. (I think v4mapped v6 is supposed to
never appear on the wire, right? If it does appear on the wire, IMO
the v6 filter should block it completely but the v4 filter should block
it only for v4 sockets.)

That is, however, written deliberately suppressing the knowledge that
it may be difficult to do. I think it would be an acceptable
approximation for the filters to block only when they match the packets
on the wire, which in this case means either (a) that proftpd should be
reporting v4 connections in v4 format even if it's handling them via
v4mapped v6 sockets or (b) blacklistd should recognize them and add v4
entries. Which one is better depends on how you squint your mind.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Mouse

Post by Christos Zoulas
I noticed that some servers (proftpd) report their IPv4 connections
as IPv6 mapped addresses: ::ffff:x.y.z.w. Adding these addresses to
npf, works just fine (after I fixed the parser), but the packet
filter does not block connections from them because the rule does not
match.

Does proftpd actually use an AF_INET6 socket with the v4mapped address,
or is it using AF_INET sockets and just printing them that way?
My own take on the POLS here is that a v4 filter entry should stop any
matching v4 packets; a v4mapped v6 filter entry should stop any attempt
to receive matching traffic on a v4mapped v6 socket but should not
interfere with a native v4 socket. (I think v4mapped v6 is supposed to
never appear on the wire, right? If it does appear on the wire, IMO
the v6 filter should block it completely but the v4 filter should block
it only for v4 sockets.)

A host on a v6 only network might put v4mapped addresses on the
wire when talking to remote v4 systems via some kinds of gateways.

It might be interesting to let a v4 sockets process a v6 socket address
buffer provided that it contains a v4mappped address.

David

[Gert Doering]

Hi,

Post by David Laight
A host on a v6 only network might put v4mapped addresses on the
wire when talking to remote v4 systems via some kinds of gateways.

These gateways (NAT64, DNS64) usually do not not use ::ffff:<v4> but
<prefix>::<v4>.

I'm fairly sure that there is an RFC that actually explicitely forbids
v4-mapped addresses from showing up on the wire - it's an internal
representation.

gert

[ignatios]

Post by Mouse
I think v4mapped v6 is supposed to
never appear on the wire, right? If it does appear on the wire, IMO
the v6 filter should block it completely but the v4 filter should block
it only for v4 sockets.)

I'd expect that, too. However, @work our network is delivered to our
department over a MPLS core. Those routers do not have v6 addresses
themselves, and ICMPv6 messages generated as error respons do have
::FFFF:a.b.c.d as their *source* address.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de