[Dshield] Architecture approach
chris.meidinger at badenIT.de
Fri Aug 12 04:48:00 GMT 2005
> I'm certainly not top dog on this list, however I will say that the reason
Luckily this list doesn't have a top dawg :)
> for NATing is to conserve IPv4 space. Contrary to many peoples belief,
> NATing doesn't 'hide' anything. In my personal opinion NATing a web server
Whether NAT hides anything depends on what you NAT. Some people call differentiate between NAT (Network Address Translation) and PAT (Port Address Translation). Personally, I consider both to be NAT. What I'm getting at is, if you NAT a single port to a webserver in rfc1918 address space, you are 'hiding' everything except the single service on that web server that needs to be open.
If, however, you NAT a complete IP address then no, you are not hiding much.
> or any public server for that matter is a waste of time and resources.
> Packet filtering in front of a server is obviously useful. NATing also
> creates overhead that you DON'T want on a web server.
A reasonable firewall should be able to handle it - the firewall will *always* need to be of a dimension that it can handle the load which will be reaching it.
> As far as pinging a firewall just deny ICMP, which is common practice
> anyway. You may want to take a peek at
Any firewall will have a spot in the rules about ICMP to self, you just need to configure that part.
> http://www.adldatacomm.net/icmp.html How would a private IP address work on
> the outside of the firewall? Where is it going to route to?
It is concievable, but complicated. It is possible to do:
INET < - > Public (probably) /30 Network < - > Router < - > Private (probably /28 Network) < - > Firewall
This way systems can sit outside the firewall and still be invisible because they are not routable. Making the firewall completly unroutable would cut you off from the world, but making the external interface part of a private subnet, and properly NATting on the router is perfectly reasonable.
> As I said I'm certainly not top dog here but that's the way I see it. I'm
> not familiar with the Big IP product so I can't comment on that.
Never used them either ...
> -----Original Message-----
> From: list-bounces at lists.dshield.org
> [mailto:list-bounces at lists.dshield.org]On Behalf Of
> mlinfosec at comcast.net
> Sent: Thursday, August 11, 2005 1:57 PM
> To: General DShield Discussion List
> Subject: [Dshield] Architecture approach
> I had a quick question regarding public web routing/ip
> architecture. Is there any advantage to using private
> addressing on the outside of the firewall that is protecting
> you web server.
As I said, this is primarily going to be an advantage for systems in the dirty dmz between firewall and border router. You can do all you NAT on a router rather than on the firewall, but I personally see this as more administration overhead that security improvement.
> Someone mentioned that then the firewall
> cannot be pinged, etc. (You can write rules to stop that). I
There is no reason the firewall could not be pinged - It is probably easier to set the firewall up to ignore certain ICMP codes than to have your border router do NAT. If your border router only NATs certain ports, then your firewall could not be pinged. However, doing that would at some point turn your border router into a firewall, and the whole game starts again.
> like to use public addresses on that segment, in case I need
> to test things that need a publically routeable address. I
As do I.
> was always under the impression you used NATing to *hide* the
> address of the webserver. What is "best practice"? I am
Personally, I see the advantage in NATting to a webserver to be that you can very effectively ensure that *nothing* outside of port 80 traffic gets there from the outside world unless there is a specific rule to allow it.
> assuming that your web servers would then need to have public
> addressing and static routes in the external router to your
> firewall, which would also have a route to the public IP
> address (of your web server).
The router would need static routes, but pretty much every router needs a couple of static routes.
> Which brings me to my next point. I am planning on using F5
> Big IP 1500s to load balance my web traffic. I want to
> terminate the SSL sessions on the 1500. Do they have to have
> public IPs to work? I also understand I may need to use 1
> cert for each web server behind the F5s. Can anyone confirm?
> Any help is appreciated in advance.
Well, it's 6 am and I haven't had coffee yet, so I hope this made some amount of sense.
More information about the list