MaxGirth
asked on
Implementing a DMZ
Thanks for taking a minute... Please bear with me, I'm a CCNA, but still somewhat green in practical application.
I need to implement a DMZ for my corporation, and have been tasked with doing the research.
I'd like to tell you what I have in mind, and perhaps some of you can tell me if I'm on the right track, or smokin' crack.
My perception of what a DMZ is, or should be...
In a sentence...
A DMZ is a somewhat less secure network, that exists (physically) between your private (secure) network, and a public network.
How can this be accomplished?
How about two routers, each with 2 serial interfaces.
Router A has serial 0 tied to the public network, and serial 1 tied to the DMZ
Router B has serial 1 tied to the DMZ, and serial 0 tied to the private network
Via programming, no traffic, of any kind, is passed directly between RouterA, serial 0, and Router B, serial 0.
Router B, serial 0 is, in theory, the ONLY point of access to/from the private network.
All outside access, network or remote, must authenticate within the DMZ first, and then may be allowed a shot at authenticating to the private network.
As far as the basic structure, is this fundamentally correct, or flawed?
Could the same thing be accomplished with a single router, having 4 serial interfaces, and proper programming?
I know that there are many other things to consider; authentication, remote access, NAT, bandwidth, etc...
To start, however, I just need to get a grip on the fundamental design aspects, starting with the h'ware, etc...
Thanks for being patient, and any responses are greatly appreciated.
I need to implement a DMZ for my corporation, and have been tasked with doing the research.
I'd like to tell you what I have in mind, and perhaps some of you can tell me if I'm on the right track, or smokin' crack.
My perception of what a DMZ is, or should be...
In a sentence...
A DMZ is a somewhat less secure network, that exists (physically) between your private (secure) network, and a public network.
How can this be accomplished?
How about two routers, each with 2 serial interfaces.
Router A has serial 0 tied to the public network, and serial 1 tied to the DMZ
Router B has serial 1 tied to the DMZ, and serial 0 tied to the private network
Via programming, no traffic, of any kind, is passed directly between RouterA, serial 0, and Router B, serial 0.
Router B, serial 0 is, in theory, the ONLY point of access to/from the private network.
All outside access, network or remote, must authenticate within the DMZ first, and then may be allowed a shot at authenticating to the private network.
As far as the basic structure, is this fundamentally correct, or flawed?
Could the same thing be accomplished with a single router, having 4 serial interfaces, and proper programming?
I know that there are many other things to consider; authentication, remote access, NAT, bandwidth, etc...
To start, however, I just need to get a grip on the fundamental design aspects, starting with the h'ware, etc...
Thanks for being patient, and any responses are greatly appreciated.
MaxGirth,
As a basis, I would suggest that you look at the chapters in the Computer Security Handbook, 4th Edition on Protecting WWW Sites and Internet assets (smile -- I wrote them). they also have several diagrams that may be helpful.
A DMZ is a separate network, which is isolated from the internal network. A DMZ is accessible from the outside (public) on a restrictive basis. The DMZ is secured from the internal network (if it accessible at all from the internal network) via an even more restrictive set of restrictions. You may also find some of my presentations, particularly recent ones for the IEEE in Tampa and Orlando to be relevant (http://www.rlgsc.com/presentations.html).
In some circumstances, a single router can be used, but it becomes even more critical to defend that router extremely carefully (it becomes a one point attack that can breach all defenses.) Before setting up a DMZ, the first question is to determine what application and operational needs the DMZ is going to support, that will drive the details of the design.
I hope that the above is helpful.
- Bob (aka RLGSC)
As a basis, I would suggest that you look at the chapters in the Computer Security Handbook, 4th Edition on Protecting WWW Sites and Internet assets (smile -- I wrote them). they also have several diagrams that may be helpful.
A DMZ is a separate network, which is isolated from the internal network. A DMZ is accessible from the outside (public) on a restrictive basis. The DMZ is secured from the internal network (if it accessible at all from the internal network) via an even more restrictive set of restrictions. You may also find some of my presentations, particularly recent ones for the IEEE in Tampa and Orlando to be relevant (http://www.rlgsc.com/presentations.html).
In some circumstances, a single router can be used, but it becomes even more critical to defend that router extremely carefully (it becomes a one point attack that can breach all defenses.) Before setting up a DMZ, the first question is to determine what application and operational needs the DMZ is going to support, that will drive the details of the design.
I hope that the above is helpful.
- Bob (aka RLGSC)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I'm mostly a "windows" admining kind of kid. I've deployed a couple of little PiX 501's.. but building and knowing the really detailed minutae of IP stateful filtering isn't my strong suit..
Regardless, I think the other Scott has kinda hit the nail on the head.
Figuring out what's going to (maybe) go in your DMZ, what it'll have to access "inside", etc.. is perhaps more important (imo) than the physical tools that get the design deployed.
For instance, in my little Microsoft world, there's a tidbit of the absurd that is called a "Front-End Exchange Server" -- which is allegedly supposed to be deployed in a DMZ.
Unfortunately, the Exchange Front end server(s) require that somewhere around 10 TCP ports are opened from the dmz to the "back end" server(s).. (including access to the directory, RPC, etc.. etc..)
DMZ sounds great, but is rather useless for that application..
So, decide what you're putting in there and *WHY* before you worry about the "how".. Watch out for applications that require any kind of Microsoft RPC/file system/directory "chatter"..
I've worked with the little PiX firewalls. They're quirky, but reliable. I've done a couple Sonicwalls.. I've found the Sonicwalls stupidly-simple to config, but flakey (both have req'd at least 1 power cycle over the past 12 months..). Sonicwall's support was second-rate..
If you can - let us know what kind of apps you're thinking of putting in your DMZ.. in my mind, that could be much more important than selecting the hardware..
-- Scott.
Regardless, I think the other Scott has kinda hit the nail on the head.
Figuring out what's going to (maybe) go in your DMZ, what it'll have to access "inside", etc.. is perhaps more important (imo) than the physical tools that get the design deployed.
For instance, in my little Microsoft world, there's a tidbit of the absurd that is called a "Front-End Exchange Server" -- which is allegedly supposed to be deployed in a DMZ.
Unfortunately, the Exchange Front end server(s) require that somewhere around 10 TCP ports are opened from the dmz to the "back end" server(s).. (including access to the directory, RPC, etc.. etc..)
DMZ sounds great, but is rather useless for that application..
So, decide what you're putting in there and *WHY* before you worry about the "how".. Watch out for applications that require any kind of Microsoft RPC/file system/directory "chatter"..
I've worked with the little PiX firewalls. They're quirky, but reliable. I've done a couple Sonicwalls.. I've found the Sonicwalls stupidly-simple to config, but flakey (both have req'd at least 1 power cycle over the past 12 months..). Sonicwall's support was second-rate..
If you can - let us know what kind of apps you're thinking of putting in your DMZ.. in my mind, that could be much more important than selecting the hardware..
-- Scott.
Fiwewall with 3 interfaces.
A- Outside
B- DMZ (web server)
C- Inside.
Nothing as access from the ouside to the inside, But the outside has only access to the port 80 (or other needed ones) on your DMZ interface. so people can have http access to your webserver. Naturaly, the inside has access to everything from the two other interfaces. You could also limit via ACL what the dmz has access on the 2 other interface. It's your choice. The less, the more secure.. The goal is to isolate the computer on your DMZ from your lan.