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.
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....)
Well, actually there is a problem with using NAT 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.
One needs both. Applying a NAT rule without firewall rules may result in a DoS.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"?
I think he means "NAT without firewall rules allows the DOS".
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.
