OT: DMZ explained?

[Rick Bowers]

Thanks! That was the type of response I was looking for. It helps 
clear up my understandings/misunderstandings.

>Also, be cautious with believing that a proprietary protocol is any more
>secure than MS-networking.  Given a little playtime, many such protocols can
>be poked and prodded at to give up something, if only a DoS.  Many of the
>vulnerabilities today are format string exceptions, which allow an attacker
>to poke and prod through various places in memory space.  This actually can
>allow the creation of exploits without reverse engineering the code.

Yep! Understood. That's why I added (as much as possible).

~Rick

At 1/12/2007 04:27 PM, you wrote:
>On Friday 12 January 2007 14:58, Rick Bowers wrote:
> >  But, they only gave me access through the firewall to port 80 on the web
> > server (AFTER access failed and I had them open THAT port). So they gave me
> > this:
> >
> >             |-------------DMZ-------------|
> >  [Firewall]<-----port 80----->[web server]<-----port nn-----> [data server]
> >      |
> >      |<-----various ports----->[other servers on the internal network]
> >
> >  Now, I thought a DMZ contained a host (or hosts) that pretty much had full
> > access to the outside world. They, in turn, can limit access to hosts
> > connected to them. Is it normal to restrict DMZ-based hosts to specific
> > ports? And that tightly (i.e. port 80 ONLY)?
>
>DMZs are untrusted networks, created to contain any badness may get in there.
>In reality, many companies may provide full access outbound, but that is not
>generally advisable.  Many malicious attacks can be thwarted (or hampered) by
>restricting outbound access as well as internal access.
>
>As a matter of policy, no connections should originate from the Internet and
>be allowed internal... all such connections should go to a DMZ-contained
>system.
>
>It is also recommended only to allow the traffic that is 
>necessary.  The basic
>tenet goes something like this:
>* Start with NO access
>* Add only what is necessary.
>
>Also, be cautious with believing that a proprietary protocol is any more
>secure than MS-networking.  Given a little playtime, many such protocols can
>be poked and prodded at to give up something, if only a DoS.  Many of the
>vulnerabilities today are format string exceptions, which allow an attacker
>to poke and prod through various places in memory space.  This actually can
>allow the creation of exploits without reverse engineering the code.
>
> >  In the setup I was provided, why are they claiming my web server is "in
> > the DMZ"? Isn't it really just another host on the internal network with
> > access only to port 80?
>
>If they are using the term appropriately, the picture looks a little 
>more like
>this (there are many renditions, including multiple firewalls, etc...):
>
>/----------\
>| Internet |
>\----------/
>         |
>         |
>         |  No machines allowed outside the firewall
>         |
>         |          /---\
>         |FW|--------|DMZ|
>         |          \---/
>         |
>         |
>         |
>         |
>/--------------\
>| internal net |
>\--------------/
>
> >
> >  And why did they limit my internal [data server] to ONLY access on my
> > specified port? Why not open it up to full access? It is inside the
> > firewall...
>
>Sometimes security is about protecting assets from Internal employees and
>contractors.  Most security breeches are from an insider.
>Sometimes security is about nonrepudiation.  If an insider has unnecessary
>access to a DMZ server, they could do really nasty stuff, and plant evidence
>on a DMZ box to indicate an external hacker.  That may seem a bit far
>fetched, but the principle of Least Permissions rings true.  Many security
>design decisions are simply to help thwart the unknown.  A couple years back
>I had to tell the server guys at a big company that they couldn't virtualize
>different security levels on the same hardware.  The concept was from
>Telecom... physical separation of differing security domains, with an
>official security device controlling access between them.  At present we are
>seeing quite a few well-funded and well-trained folks poking at the virtual
>machines themselves.
>
> >  From everything I've read, a DMZ is implemented more as a 3-legged
> > configuration, not an in-line configuration. For example, my home network
> > is setup something like this:
> >
> >                    |--------------------DMZ--------------------|
> >  [router/firewall]<-----192.168.x.10----->[web/ftp/mail server]
> >          |
> >          |<-----192.168.x.y----->[other servers on the internal network]
> >
> >
> >  My question: Does the way they setup my configuration make sense?
>
>yes.
>
>
>Now, a bit of business sense that has taken me years to acknowledge, 
>longer to
>accept, and I bear the scars to prove it.
>
>Security is a business decision.  Some companies are in the business of being
>secure.  Others have to actually operate to make money.  Every company has to
>make decisions about what risks are work protecting against, and how much
>pain each "solution" is able to cause.  Every company has a different
>culture, and that culture helps dictate how security is implemented.
>One of the best companies I've seen has a very customer-service approach to
>security... while making the tough decisions about what to allow.  But it
>took them many years to get there, stemming back to a telecom-lead security
>approach of "Not just NO, but FNPH" (please do not ask me to explain that
>one).
>
>Good luck!
>
>
>--
>Matthew Carpenter
>Senior Security Analyst
>Intelguardians Network Intelligence, LLC
>http://www.intelguardians.com
>
>
>_______________________________________________
>Linux-users mailing list ( Linux-users at linux-sxs.org )
>Unsub/Password/Etc: 
>http://mail.linux-sxs.org/cgi-bin/mailman/listinfo/linux-users
>
>Need to chat further on this subject? Check out #linux-users on 
>irc.linux-sxs.org !