Just a few quick notes:
> > Additionally, lets say you open port 80 for NAT. Now lets
> > assume that some
> > hacker has an exploit they can launch on port 80. With a
> > filtering firewall,
> > or an application firewall, it can do a better job of
> > examining the packets
> > and making sure they really are what's expected (HTTP instead of the
> > exploit).
>
> No. It can't. Well, not for HTTP, anyway. This is one of the biggest
> bugbears in the ALG world - you can get almost anything into
> / out of a
> network over HTTP. There's way too much trust in firewalls to secure
> insecure protocols, IMO. I don't know how many times I've heard people
> respond to my questions about the security of their WWW app
> with "But isn't
> that why we have the firewall?".
Heard time and time again... all you can do is repeat the mantra -
"packet filter, firewall, IDS...."
App-level HTTP filtering is just header sanity checking and not much else.
Try blocking '::$DATA' with your fave firewall.
So firewalling won't provide you with any extra protection over NAT in this
case.
Even so, NAT becomes obsolete for most security purposes once packet filter,
firewall and IDS is employed.
Anything not secured via these means is suffering from chronic vunerabilty -
IP stack bugs etc.
HTTP is a dog of a thing, anything can tunnel by spewing some crappy HTTP
header as app-layer 'passthru bait'.
Yet another reason not to allow users direct http access to the net. (I know
throwing an {authenticating} HTTP proxy won't guarantee
non-web traffic won't flow in/out 80/tcp, but it makes it a hell of a lot
harder)
>
> > NAT will just hand the exploit of to the machine,
> > compromising
> > security.
>
> So will pretty much every firewall I know. HTTP is close to the worst
> example you could have picked here. I concede your point for
> SMTP - most
> decent firewalls can at least do some control channel
> inspection and basic
> sanity checking on SMTP - it's not a very hard protocol.
> Maybe FTP as well -
> although it appears that FTP is much harder than many people
> thought. ;)
>
> >
> > Finally, NAT devices do nothing I am aware of to counter DDoS
> > attacks.
>
> Neither do most firewalls. They _can_ - sometimes. But then
> again there's no
> reason why a NAT device couldn't do this as well.
>
> [snip]
>
> > Also, a DDoS attack could take the NAT device
> > down, allowing
> > unintentional (hack) traffic through. Most firewalls are
> designed, if
> > compromised, to compromise in a shutdown state.
>
> Hang on - name an edge NAT device that's not fail-closed.
> It's the same
> concept - the box sits at your border. If the box goes down,
> so does the
> network.
>
> [snip]
>
> >
> > At least, these are what I understand as some fundamental
> > differences. :)
>
> I don't think you've raised any compelling arguments, so far
> - sorry. This
> is an interesting topic, though. I'd like to see some more traffic...
>From the responses which I agree with on the whole, I don't think any valid
reasons have been
given as to why a firewall is superior to a NAT box.
As to traffic Ben, well, it's really a holy war because neither holds any
clear overall advantages over the other
yet both are hotly touted by their respective followers as the "best thing
since..."... you can have that minefield :)
the fact remains that in certain situations where NAT is not the best
solution (many/varied inbound connections)
firewalling will afford a greated level of protection than 1-1 port/ip
mapping.
Where outgoing traffic it the only real need (internet access gateway), once
the NAT box itself is hardened) NAT fits the bill here very nicely.
later all
________.-~-.________
Ben Ryan
Network Engineer
Kiandra Systems Solutions Pty Ltd
Level 9, 455 Bourke Street
Melbourne, Vic. 3000
Australia
Cellphone - +61-(0)417-502-061
Work - +61-(0)3-9600-1639
Fax - +61-(0)3-9600-1656
email: - [EMAIL PROTECTED]
URL: - www.kiandra.com
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
