Arguing against using public IP space

Wed Nov 16 16:44:00 UTC 2011

On Nov 15, 2011, at 7:08 PM, Jay Ashworth wrote:

> ----- Original Message -----
>> From: "Mark Andrews" <marka at isc.org>
> 
>> In message
>> <29838609.2919.1321392184239.JavaMail.root at benjamin.baylink.com>, Ja
>> y Ashworth writes:
>>>>>> If your firewall is not working, it should not be passing
>>>>>> packets.
>>>>> 
>>>>> And of course, things always fail just the way we want them to.
>>>> 
>>>> Your stateful firewall is no more likely to fail open than your
>>>> header-mutilating device.
>>> 
>>> Please show your work.
>> 
>> Prove to me that all NAT won't pass packets not addressed directly
>> to it. Show your work.
> 
> I did not *assert* that.  So I don't have to prove that. 
> 
> What I *asserted* was that inbound 1:N DNAT *reduces the probability of 
> an attacker being able to target a specific inbound attack to a specific 
> computer*.  QED.
> 

No, it is not QED... You have not proven that it reduces said probability
vs. a stateful firewall without header mutilation.

So, again, please show your work and prove your assertion or accept
that your assertion is no more or less credible than the assertion that
it does not.

>> Given that most NATs only use a small set of address on the inside
>> it is actually feasible to probe through a NAT using LSR. Most
>> attacks don't do this as there are lots of lower hanging fruit but
>> if it is a targeted attack then yes you can expect to see LSR based
>> attacks which depending apon how the NAT is built may pass through
>> it without even being noticed.
> 
> Someone else has already addressed "low-hanging fruit", so I won't.  I do 
> concur, though: if you have specific examples of boxes which, as you allege, 
> respect LSR to 1918 internal addresses, please, name and shame.
> 

He probably likes his job too much to do that. I don't know the specifics or
the internals of specific boxes, so, I can't point you at one, but, I will point
out that Mark works for a manufacturer of MANY of the worlds cheapest
NAT gateways and given the other code quality issues observed in these
brand-L products in the wild, universal lack of such NAT vulnerabilities in
them would truly come as a surprise.

>> Now can we put to bed that NAT provides any real security. If you
>> want security add and configure a firewall. That firewall can be
>> in the same box as the NAT. It can use the same state tables as
>> the NAT but it is the firewall, not the NAT functionality, that
>> provides the protection.
> 
> Nope; I'm afraid we still can't.  As long as you continue to strawman that
> I/we are even *alleging* that NAT "provides" security (rather than 
> "contributing" to it, we're just going to keep talking past each other, Mark.
> 
NAT neither provides nor contributes to security.

NAT detracts from security by destroying audit trails and interrupting/obfuscating
attack source identification, forensics, etc.

Owen