On 03/07/2018 05:55 PM, Robert White wrote:
On 03/07/2018 08:26 PM, zrm wrote:
You want to override the default address and port translation, but only
if that would have been possible given the configuration.
No, not quite.
You want to reestablish the connection.
SO:
(1) The connection you are _reestablishing_ was previously
_established_. That means, in the past iteration...
(1.a) The connection was automatically established via the default rules.
(1.b) The connection was previously established via a specific PCP request.
(2.a) The client is adversarial and is trying to circumvent the firewall
rules.
(2.b) The client is asking the PCP daemon to recreate a connection that
was valid with the previous configuration but not the current configuration.
It would be normal and desirable for the automatic NAT pools for ports
and addresses to be "kept away from" the likely PCP requests ports.
It's completely reasonable for a client to make an implicit outgoing
connection, then use PEER to query the assigned external address and
port of the existing connection, then if the gateway is reset use PEER
to recreate that state.
It would be possible to have ports that are only used for PCP, but it's
breakage to have ports that can be used for implicit connections and not
PCP.
RFC6887 Section 18: "All mappings that could be created by a specific
host using implicit mapping mechanisms are inherently considered to be
authorized."
So the PCP daemon still has to be able to validate the rules for making
non-PCP outgoing connections.
See the PCP service is configured by it's rules/files to create ranges
that are wholly immaterial compared to the firewall rules for non-PCP
participants.
There's a saying from a book I read once: "Always forbidden, but on
occasion mandatory".
So if you put in an invalid external IP address the PCP daemon _should_
reject it based on being unable to find an matching interface. But if it
_doesn't_ then the matching rule injected into the firewall will become
noise. It will never match because you'll never get packets with those
traits.
The fact that the address isn't on the machine doesn't make it invalid.
I could have five static IPs I'm using for outgoing SNAT and PCP
mappings but only one of them, or none, is on any interface of the router.
But how do you mean it won't match anything? If you add SNAT and DNAT
rules for an unauthorized external IP address, it would still allow the
client to spoof outgoing packets without receiving a reply, and would
even allow the replies to be received if the address is unauthorized for
use by the client but is still an address routed through this router.
For example,
suppose the system administrator has the following rules:
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -o inet0 -p tcp --dport 25 -j REJECT
iptables -A FORWARD -i lan0 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -o inet0 -j SNAT --to-source 1.2.3.4
Now we get a PCP PEER request that asks for tcp src 192.168.1.5:2345 dst
5.6.7.8:25 to be translated to external src 9.10.11.12:1024.
So let's say someone maps port 25 with PCP. Well when the first packet
comes through the forwarding rule then the connection is not yet
ESTABLISHED, so the reject rule would stop the packet anyway. This is
why we _DONT_ manhandle the connection tracking state.
But the PCP daemon should have _already_ not allowed that connection.
I don't see how creating the conntrack entry is the problem. That's what
PEER is. Isn't emulating the same effect with SNAT/DNAT/ACCEPT just as
problematic if approved when it shouldn't be?
The issue is how the PCP daemon can make itself aware of the rule that
outgoing connections to port 25 are not allowed, and so on for all the
other rules, without forcing the system administrator to duplicate every
single netfilter rule in the PCP daemon's configuration.
Meanwhile if we don't want _normal_ connections to succeed but we want
PCP controlled sessions on port 25, then we can use packet marking or
SNAT/DNAT match status (see conntrac --ctstate DNAT etc) to bypass the
restriction.
You are building a novel and complex system, but you've _got_ to rely on
the user to do some of the work otherwise you've built an inflexible system.
In your example both your existing post-routing SNAT rule and your PCP
config should _already_ restrict the connections to not use port 25 anyway.
The user normally doesn't want to have two separate configurations, one
with iptables/nft and the other with the PCP daemon, 95-100% of which
are exactly the same.
If clients shouldn't be able to e.g. make outgoing SMTP connections then
they shouldn't be able to make them with PCP or otherwise.
The ideal solution I was hoping for is for the PCP daemon to somehow
query the kernel whether a connection with particular parameters is
allowed and use that determination to approve a PEER request or not.
The alternative that I would prefer to avoid is to let the user
configure the rules in the PCP daemon's configuration and have the PCP
daemon automatically insert the equivalent iptables/nftables rules. That
way at least the administrator doesn't have to maintain two identical
sets of rules, but then the daemon has to process all the rules itself
when approving PCP requests (essentially duplicating/predicting what the
kernel would do), which is undesirably complicated.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
