Re: Order of Firewall<->NAT - Summation

[Bob <rcwash () us ibm com>]

Rocky Stefano wrote:
> How would your configuration deal with user installed trojans 

Security is like lasagna - the more layers, the better :-).

The purpose of the experiment is to harden against external
cracker/script attacks.  This configuration does nothing to protect
against virus's/worms attached to email, hostile web pages, user
sabotage/cluelessness, DDOS or even physical access.

But those security risks aren't usually addressed with a firewall.  And
this *is* the Firewall Wizard's mailing list :-).  So I an concentrating
on the packet filtering aspects at this point.  There are other
well-known tools to address the other risks (anti-virus programs,
personal desktop firewalls, tripwire, etc.).

> or exploits on known good ports like 80 through IIS? 

Well, in this specific case, there are no "known good ports."  I'm not
offering out ANY services from the NAT or the LAN.  Nada.  None.  So I
can set the IPFilter on the NAT machine to "default deny in"
everything.  Or even allow everything in and let the TCP/IP stack throw
everything out once it's been determined that there is no service for
that packet.  Either way, noone gets backstage unless they had their
hand stamped on the way out (keep state).

What if you need to offer a service?  I am toying with the idea of
putting an NTP server on the NAT machine (anyone know of any exploits I
should be concerned about?)  And it is reasonable to think about a small
web server.

In such a case, all the standard caveats apply.  A packet filter won't
protect your service, so run a service with a good reputation for
security (i.e., nothing from Microsoft) and keep up on the patches. 
Concider security proxies, if they exist, for the service which would
scan for exploits, trojans, etc.

A new variation on this is the clamping down on port 80 by the consumer
broadband industry.  Cable modem and DSL providers have always forbidden
users from setting up web servers, but have until recently relied on the
narrow upload bandwidth to enforce the policy.  With the advent of Code
Red, more providers are simply filtering *ALL* incoming packets to port
80.  So now if a consumer wants to set up a small Apache service just to
publish their security white paper, they must place it on an unusual
port number, such as 8000, etc.

> You still need an IDS

That would be the job of the <Firewall/bridge>.  Since the NAT is acting
as a firewall, *ANY* unrequested traffic (not in responce to an outgoing
packet) would indicate that the NAT was compromised.  And similarly, any
suspicious traffic from the LAN would indicate an infested client.

Thanks for the responce!

Bob Washburne

> -----Original Message-----
> From: firewall-wizards-admin () nfr com
> [mailto:firewall-wizards-admin () nfr com]On Behalf Of Bob Washburne
> Sent: August 26, 2001 12:38 PM
> To: firewall-wizards () nfr com
> Subject: [fw-wiz] Order of Firewall<->NAT - Summation
>
> A while back we had a thread about whether it was better to place a
> firewall before or after the NAT.  The following is the summation of the
> pros, cons and issues.
>
> In the setup I am experimenting with it was proposed to have two
> separate systems used to secure a LAN from the Internet.  The
> configuration is to look something like this:
>
> Internet <--> NAT <--> Firewall <--> LAN
>
> The NAT machine is a 486 DX2 66 running Open BSD and nothing else.
>
> The Firewall is a P166 running Open BSD and configured as a bridge.
>
> The LAN uses a non-routable IP subnet.
>
> This configuration has the following advantages:
> -) Have non-routable IP addresses, the LAN cannot be directly
> accessed/attacked from the Internet.
> -) Being a bridge, the firewall has no IP address and so cannot be
> accessed/attacked from the Internet.
> -) The NAT has no services, so any packet sent directly to it (i.e., not
> sent in responce to a translated packet from the LAN and thus a
> potential attack) is simply discarded.
> -) The only way for an attacker to access the LAN is to crack the NAT
> and launch from there.
>
> But the question arose as to whether it was better to place the firewall
> forward between the NAT and the Internet rather than behind the NAT.
> I.E., is this:
>
> Internet <--> Firewall <--> NAT <--> LAN
>
> better than this:
>
> Internet <--> NAT <--> Firewall <--> LAN
>
> In one sence, it makes no difference.  Since the NAT machine offers no
> services it simply drops all packets sent directly to it as if it were a
> firewall.  So the packets leaving the NAT would be the same no matter
> which side the Firewall was on.
>
> In another sence, it make no difference since the Open BSD NAT requires
> that IPFiltering be enabled.  So you have an IPFilter out in front of
> the NAT whether or not you want it.
>
> But there does seem to be two issues which differ depending on the
> Firewall placement.
>
> 1) IDS.  If you place the Firewall in front, then you will see all the
> traffic hitting your system.  Good if you need to justify your work to
> management ("See what we are protecting against!").  If you place the
> Firewall to the rear then the only traffic you will see is what came
> through the NAT.  Good if you only want to see what's getting through.
>
> 2) Potential port DOS.  Let's take the situation where something like
> Code Red gets through as an email attachment and the user is foolish
> enough to run it.  The virus/worm now tries to send packets on port 1337
> back to Central Control.  But your Firewall is tightly configured and
> the packets are summarily sent to the bit-bucket.
>         If the Firewall is behind the NAT, then the NAT never sees the packet
> and all is well.  But if the Firewall is in front of the NAT, then the
> NAT dutifully translates the packet and reserves a port for the
> responce.  A responce which will never come because the Firewall killed
> the packet on its way out the door.  So that port number is tied up for
> a while.
>         Now, the NAT will eventually time out and release the port it used back
> to the pool.  But if the virus/worm is insistant enough it is
> concievable that all the ports available to the NAT could be taken up
> before they start to time out and you have Denial of Service.
>         I grant that this is an unlikely situation, but I am stretching to find
> any substantive difference in the Firewall placement.
>
> I believe the bottom line is that with Open BSD you must set up a
> firewall on the NAT machine and so you will have the full packet
> visability/recording if you wish to use it.  The seperate Firewall after
> the NAT should be almost useless, acting only as a miner's canary to
> tell you when something bad has happened.  If someone should crack into
> the NAT, then the firewall would detect, stop and report any attempt to
> access the LAN.  If something got through to the LAN and tried to report
> out, the Firewall would detect, stop and report that activity as well.
>
> So the Firewall itseld would act as an IDS without the need for
> installing any IDS software.
>
> Can anyone think of anything to add to this?
>
> Thanks for all the input.
>
> Bob Washburne
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards