Michael Cozzi wrote:
>Simon Hobson wrote:
>>  <soapbox mode>
>>  NAT is also fundamentally broken in ANY implementation, it is BAD, to
>>  be avoided whenever you have enough public IPs to avoid it. It's an
>>  evil cludge invented to avoid having to fix the real problem (lack of
>>  addresses), and a second effect of it's invention has been to delay
>>  implementation of the proper fix because too many people think it IS
>  > the fix.



>     Forgive me for posting on this topic, I want to clarify a few things
>in the hopes that novices will take notice.
>
>     For all the arguing you kids are doing regarding NAT, the following
>remains true and "less than expert" admins should know about it.
>
>     NAT, for all it's faults, does a decent job of keeping outsiders
>from connecting to an internal network. Having access to a true class c
>that you can use for lan/wan purposes on face value seems nice. But when
>security mistakes are made in that context it can lead to unfettered
>access to to the internal infrastructure. Not only that, but you also
>multiply the number of security breach possibilities because now your
>internal network electronics, printers, fax machines, IP cameras, <name
>your esoteric device here> have to be hardened to the same level of a
>server (which would be behind a firewall anyhow).
>
>     I don't know about anyone else, but I certainly don't relish the
>idea of having to add IP cameras, printers, and Windows machines to the
>weekly security audit .... I've got 36 servers to watch- that's enough
>security worry. I certainly wouldn't want the *majority* of IT people
>I've worked with saddled with making sure a firewall was adequately
>protecting a UPS. They just don't have the protocol knowledge.

What's the difference, security wise between :
DNAT  net   loc:a.b.c.d
and
ALLOW net   loc:a.b.c.d
assuming you have a default policy net->loc of drop ?

One rule allows packets from the net to the device, the other rule 
allows packets from the net to the device.

I do agree with you that NAT does make a fairly good packet level 
firewall - but then so does a firewall with a default policy of drop. 
I'd even go so far as to suggest that the only reason the botnet 
problem isn't a lot worse is that too many (from the bot herders pov) 
are behind default firewalls.

>     So be careful here, some guy with good intentions is going to take
>your "technically correct" opinions, misconfigure a firewall for 240
>devices on a class c, and 3 million people will have lost their credit
>card info- all because some cracker figured out how to script a
>dictionary attack through a Logitech Webcam.

I think you slightly dampen your argument there. If a novice with no 
knowledge of firewalls is responsible for security of 3 million sets 
of credits card details then someone higher up has some serious 
questions to answer - and issues with the firewall are the least of 
their worries !


The sad thing is that whilst it's good to have this discussion, the 
people who need to see it are almost certainly never going to :-(

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to