Other Firewall survey

[cy@]

A quick question for ipfilter, pf and ipfw users.

How many of you use one of the firewalls (ipfilter, pf, or ipfw) NAT without firewall rules?

 

[mer]

NAT only without firewalling? Interesting.
Count me as "I don't do that".

 

[smithi]

A quick question for ipfilter, pf and ipfw users.

How many of you use one of the firewalls (ipfilter, pf, or ipfw) NAT without firewall rules?

Well, I don't see how you can use ipfw NAT (or natd) without an ipfw rule to implement that?

Or do you mean, apart from that, no additional rules?

 

[YYY__]

Why not a poll thread? I use firewall_type, which is the same as a set of preset rules. I leave NAT for the router. What's the question behind it? VPN?

 

[Alain De Vos]

Using ipfw without nat.

 

[monwarez]

I usually use ipfw for filtering, and pf for redirect/nat rules for my jails.

 

[cy@]

Seems everyone so far uses firewall rules with their NAT rules.

I came across a user who uses NAT rules only. Seems someone (probably me) needs to write a handbook article or wiki page discussing correct NAT setup. Probably a good education opportunity.

 

[smithi]

Seems everyone so far uses firewall rules with their NAT rules.
I came across a user who uses NAT rules only.

As above, ipfw NAT (or natd(8) - I've used both) requires at least one ipfw rule to install NAT, and if packets don't match the NAT or DIVERT rule, ipfw's default rule (deny or allow) applies.

What was the user you mention using? Link please?

 

[cy@]

As above, ipfw NAT (or natd(8) - I've used both) requires at least one ipfw rule to install NAT, and if packets don't match the NAT or DIVERT rule, ipfw's default rule (deny or allow) applies.

What was the user you mention using? Link please?

With ipfw you still should also have a rule that tracks state so that the TCP session remains in the window. Otherwise spoofed and injected packets can cause a DoS.

Whatever documentation is written should cover ipfw, ipfilter and pf. The concepts are the same though.

 

[Jose]

I use firewalling (packet filtering) without NAT, but not NAT without filtering. I use pf on three BSDs.

 

[zirias@]

I came across a user who uses NAT rules only.

Nothing inherently wrong with that if a firewall indeed isn't needed (for whatever reason, maybe you're doing NAT somewhere inside some already protected network and decide that's sufficient....)

Of course that's kind of unlikely and instead just the old fallacy lurking that NAT would "protect" hosts behind it by not allowing connections to them. Which is wrong in general and just a common side-effect of how NAT typically works, that should never be relied on. I've even seen people wanting to have NAT with IPv6 "for security".

Implementation specifics aside, the key lesson should be that the goal of NAT is to route as many packets as possible to their correct destination (which might even include some heuristics), while the goal of packet filtering (what a firewall typically does) is pretty much the opposite: Make very sure only specifically allowed packets are routed.

 

[cy@]

Nothing inherently wrong with that if a firewall indeed isn't needed (for whatever reason, maybe you're doing NAT somewhere inside some already protected network and decide that's sufficient....)

Of course that's kind of unlikely and instead just the old fallacy lurking that NAT would "protect" hosts behind it by not allowing connections to them. Which is wrong in general and just a common side-effect of how NAT typically works, that should never be relied on. I've even seen people wanting to have NAT with IPv6 "for security".

Implementation specifics aside, the key lesson should be that the goal of NAT is to route as many packets as possible to their correct destination (which might even include some heuristics), while the goal of packet filtering (what a firewall typically does) is pretty much the opposite: Make very sure only specifically allowed packets are routed.

Well, actually there is a problem with using NAT only.

When using NAT only, firewalls do not verify TCP streams, i.e. TCP window. It's easy to cause a DoS on an already established TCP session. Whereas a firewall with rules that,

a) block all ingress packets,
b) set up NAT for the TCP session
c) create state for the just initiated session

will deny such a DoS attack.

Using NAT only will not check and verify TCP sequence numbers.

Remember, NAT only alters the source IP address and port on egress packets and destination IP and port on ingress packets. That's all. It's easy to disrupt this. But a stateful packet inspection will block out-of-band packets before they can cause the DoS.

 

[zirias@]

cy@ I see no contradiction to what I wrote ... at least, I don't assume you're trying to tell that anything of this is worse with NAT, compared to a scenario without it (assuming it wasn't needed) and still no "firewalling"?

 

[cy@]

cy@ I see no contradiction to what I wrote ... at least, I don't assume you're trying to tell that anything of this is worse with NAT, compared to a scenario without it (assuming it wasn't needed) and still no "firewalling"?

One needs both. Applying a NAT rule without firewall rules may result in a DoS.

 

[zirias@]

One needs both. Applying a NAT rule without firewall rules may result in a DoS.

I'd really like to clarify that: Do you mean that NAT causes that issue? Compared to a scenario without any kind of "firewall" active?

 

[mer]

Do you mean that NAT causes that issue?

I think he means "NAT without firewall rules allows the DOS".

 

[zirias@]

I think he means "NAT without firewall rules allows the DOS".

That's obvious. But would the same attack not work without NAT?

 

[cy@]

I'd really like to clarify that: Do you mean that NAT causes that issue? Compared to a scenario without any kind of "firewall" active?

NAT doesn't cause the issue. NAT without firewall rules does not check if TCP sessions are in the window. NAT simply translates IP addresses and port numbers regardless of the state of the TCP session.

Stateless firewall rules also do not check the state of a TCP session either. At most stateless firewall rules may check TCP flags if the rule is constructed that way.

Stateful firewall rules keep track of TCP state. If a TCP packet has the wrong TCP sequence number or the packet is not within the TCP window, the packet is rejected (blocked). One needs stateful inspection to protect against out-of-band (spoofed) packets from interfering with the TCP session.

NAT, like stateless firewall rules, offer some protection but stateless firewall rules or NAT without firewall rules cannot protect from spoofed TCP packets injected into a TCP stream. This is why almost all firewalls today offer stateful packet inspection.

 

[cy@]

I think this settles it. The report of a user with NAT rules and without firewall rules is the exception. Suggests there needs some work to write an article or wiki page discussing the ingredients to creating a successful firewall ruleset.

 

[zirias@]

I think this settles it.

Pretty much so. So there's indeed no contradiction, just a misunderstanding it seems. I tried to express exactly the same thing: NAT is not meant to "protect" anything (but an ugly workaround for having too few addresses available).

 

[quakerdoomer]

A quick question for ipfilter, pf and ipfw users.

How many of you use one of the firewalls (ipfilter, pf, or ipfw) NAT without firewall rules?

I fall in the opposite category, only rules, no NAT - but it's an internal FW.

 

[PMc]

Seems everyone so far uses firewall rules with their NAT rules.

I came across a user who uses NAT rules only. Seems someone (probably me) needs to write a handbook article or wiki page discussing correct NAT setup. Probably a good education opportunity.

There is also ng_nat(4) that can be wired in practically anywhere, with or without firewall.

I have a kernel patch to use ng_ipfw(4) from VIMAGE jails, so yesterday I moved everything to ng_nat, for the fun of it.
I also have now a definite finding (and preliminary workaround) for PR 269770 The outcome is that our NAT (all of them) is broken and may just stop translating portforwards.

BTW, there is a nice use-case for NAT being entirely independent from firewalling: say you have a machine running as 192.168.23.45, and also a tunnel to some other network. The tunnel piers are configured as 10.0.0.1+2
Now when this machine itself does connect to the other network, it uses by default it's local address 10.0.0.1 instead of 192.168.23.45 - but that one is not routed anywhere else, and it is quite a pain to route that address everywhere concerned, and/or tell every concerned tool to use explicit source address. I found it simpler to insert a NAT into the flow. Just works:

# ipfw show | grep ngnat.locl
01785  166921   12368127 netgraph 2 // lan.locnat[FILTER][ngnat.locl.in]
02325    2711     427420 netgraph 2 // oper.locnat[FILTER][ngnat.locl.in]
04655     785      51536 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[49]
04765       0          0 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[48]
04885  314518  467620621 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[26]
05175       0          0 netgraph 1 // lan.locnat[FILTER][ngnat.locl.out]
05475    2717     254848 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[40]
05615       0          0 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[39]
05725       0          0 netgraph 1 // oper.locnat[FILTER][ngnat.locl.out]