CynderX-=-Security

Discussion in 'Computer Security' started by Cynder, Jan 20, 2004.

  1. Cynder

    Cynder Guest

    NOTE:

    Building yourself a DMZ...
    @ Articles -> Security Mar 07 2003, 04:13 (UTC+0)
    danielrm26 writes: Building yourself a DMZ...
    By danielrm26
    03.06.03
    -------------

    Eventually, if you get interested enough in Security, you are going to
    wonder what a DMZ is and why you should or should not have one. DMZ is
    an acronym that stands for De-Militarized Zone, and in the 'real'
    world it is the location between two hostile entities such as North
    and South Korea. In the Security community, however, it is a separate,
    untrusted network where boxes serving public services should be
    placed. It is a buffer zone between a completely untrusted network
    (like the Internet) and a relatively trusted network (like your
    private LAN). The primary reason for implementing a DMZ is to keep
    your public and private assets separated so that a compromise in the
    public area does not automatically result in a compromise of your
    private assets as well.

    There are two main ways to implement a DMZ. The first is using three
    NICs, as follows:

    1 NIC for the WAN (your gateway to the Internet; everything comes and
    goes through this NIC)
    1 NIC for the LAN (behind this NIC is where you have all your private
    assets, i.e. file servers, domain controllers, questionable material
    collections, etc.)
    1 NIC for the DMZ (this is where you put any machine that you want to
    allow people on the Internet to connect to, i.e. web servers, ftp
    servers, mail servers, game servers, etc.)

    This is one method of creating a DMZ, but it is not the preferred
    method. This configuration allows the security of both your DMZ and
    your LAN to lie in one system. If your machine that has all three of
    those NICs in it is compromised, so is your DMZ and your private
    network as well. Basically, you are allowing the Internet to 'touch'
    the very same machine that determines how secure your internal LAN is,
    and this is not a good thing.

    The better way to do this is with three separate networks - the
    Internet, your DMZ, and your LAN. This is accomplished by using two
    firewalls - one on the border of your WAN (which handles your
    connection usually), and one on the border of your internal network.
    Let's say that you have a broadband router (like a Netgear or Linksys)
    and a Linux-based firewall (like Astaro or Smoothwall). What you do is
    you put your router on your border (right behind your modem), and you
    connect the LAN side of that router to a hub or switch. To that hub or
    switch (your DMZ hub/switch) you use one of the ports to connect your
    bastion host/public server(s). This machine (or machines) run the
    services that you want people to be able to connect to from the
    outside. This may be a web site, an FTP server, or a multiplayer game
    like WCIII or Counterstrike. You want this machine to be hardened to
    some degree (preferably very well), meaning that it is completely
    patched and is not running anything that is vulnerable. As a general
    rule though, you want anything put in the DMZ to be resistant to
    attacks from the Internet since public access is the reason that you
    are putting it out there in the first place. How to harden the servers
    you put in your DMZ is outside the scope of this article, but suffice
    it to say that you want to lock them down - no services running that
    don't need to be, all updates applied, etc.

    Now, to that same switch (the DMZ switch) you are going to attach
    another network cable that goes to your internal firewall (your Linux
    firewall). It is important to note that you want your strongest
    firewall closest to your LAN; or, putting it another way, you want
    your weakest firewall on your border. This may seem counterintuitive
    but it's usually the right way to do things. Basically, you want the
    most powerful and most configurable firewall protecting your LAN - not
    your DMZ. As for your internal firewall, it's going to have two NICs
    in it - one for the DMZ side and one for the private LAN side. Connect
    the cable coming from your DMZ switch to the DMZ side of the internal
    firewall (the external interface), and on the other side of the
    firewall (the private LAN side) you connect a cable to another
    hub/switch that all of your LAN computers will connect to.

    If that was confusing, think of it this way:

    ------------------------------------------------------------------
    Internet -> Modem
    Modem -> Router
    Router -> DMZ Switch
    DMZ Switch -> WEB/FTP/Game Server
    DMZ Switch -> Firewall External NIC
    Firewall Internal NIC -> LAN Switch
    LAN Switch -> LAN Systems
    ------------------------------------------------------------------

    So let's take a look at the Security that is offered by this setup. At
    the border you have NAT translation going on that passes only the
    ports that you need to in order for the public to use the servers in
    your DMZ. Let's say you are running a web server, an FTP server, and a
    game server for a game called FooAttack. On your border
    router/firewall you pass ports 80, 21, and 5347 (the FooAttack server
    port). All other attempted connections to your external IP address
    drop dead at your border; only those three ports passed above are
    allowed through because of NAT. The nature of NAT dictates that only
    return traffic (traffic is part of a connection that originated from
    the inside of the NAT device) will be allowed back into the NAT'd
    network. This side effect of NAT, while not its original or main goal,
    is a fairly powerful Security feature. If your border device supports
    filtering of any sort in addition to NAT then you can further lockdown
    your network by restricting who can and cannot connect to the hosts in
    your DMZ.

    That first border layer, while being good, is just one piece of the
    overall DMZ Security posture. The real beauty of this setup lies in
    what happens if someone *does* get a hold of a machine in your DMZ.
    Imagine that you have the setup like I laid out above, but unbeknownst
    to you there is a major vulnerability in the web server you are
    running. So here you are offering web content to the entire Internet
    and someone runs the proper exploit vs. your machine and roots it. Now
    what?

    Now nothing. Your second and more powerful firewall (the one that they
    are still *outside* of) - does not pass *any* traffic from the DMZ
    inside to the LAN. (In fact, you should have it where it won't even
    answer ICMP requests from DMZ machines, so the odds are they won't
    even know it's there.) And now, rather than being able to bounce
    around on your juicy internal LAN like they planned, they are stuck in
    the middle of a completely untrusted and unprivileged network that
    doesn't have anything on it other than what you intended for public
    viewing anyway.

    This is a DMZ.

    Even if they did know where the internal firewall was it wouldn't even
    entertain the notion of passing connection attempts from the DMZ. This
    internal layer of protection is NAT'd just like your first layer, only
    there are no ports being passed inside like from the Internet to the
    DMZ. Your second firewall actually has no idea what to do with packets
    that are designed to initiate new connections with it, so it just
    drops them. The only traffic that is going to make it through that
    firewall is traffic that you specifically request be allowed through
    by talking to a machine outside of that firewall, i.e. when you go to
    /., it will allow the web content to come *back* to you so you can
    view the page, but if someone tries to initiate a new connection to
    you, they get dropped. Both NAT and SPI afford this protection to you,
    each in different ways.

    So, to sum it all up, imagine someone is scanning around looking for
    web daemons to tear up and they find yours. Most inexperienced
    attackers would assume that you are running something on your public
    IP address, as if you have your main workstation is sitting right on
    the Internet and it is running a web daemon. So, they connect to it,
    get a web page, and then scurry to dig up their favorite HTTP exploit
    tool that someone else wrote. What they don't know is that they are
    actually connecting to a private IP in your DMZ. It has no 'real' IP
    address as far as the Internet is concerned. If you didn't pass that
    port at the border device then they wouldn't have seen anything at all
    with their scan. But let's say they do see your web daemon because you
    are passing port 80 through to your DMZ host running a web site, and
    it turns out it has a vulnerability in it. They run their exploit and
    get root on your box. This causes them tremendous joy, and they hurry
    to tell all their buddies because they think they're Alan Cox. The
    thing is, they have little to celebrate. All they have is a barebones
    server with nothing of value on it - no vital info, no browsing
    history, no personal information, nothing. In fact, all you have on
    there is content that you wanted the public to see in the first place
    (which is also safely backed up on your internal network and/or
    removable media). So, they have root on the machine and ping around in
    your DMZ and soon find that there isn't much there. If they are smart
    they will do an ifconfig (or ipconfig if you swing that way) and find
    out they are on a private subnet - but this gains them nothing. The
    odds are that from there they'll either load some trash onto your
    system or try and destroy it. Either way, it doesn't matter. The
    moment you detect what has happened (tripwire, puresecure, etc) you
    simply pull the plug, reinstall the box, and restore the backup.
    Within a few minutes you have a brand-new system ready to go back
    online, and at no point during the process was your private LAN in
    danger. This is the benefit of running a true DMZ.

    Hopefully this basic description of the general concept has been
    helpful to someone. If you have any questions about DMZs or any other
    Security topics, feel free to email me at hotmail.

    -danielrm26


    (c) New Order / http://neworder.box.sk/
     
    Cynder, Jan 20, 2004
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. AM
    Replies:
    4
    Views:
    890
  2. Replies:
    0
    Views:
    777
  3. Rick Sears
    Replies:
    0
    Views:
    523
    Rick Sears
    Jul 29, 2003
  4. COMSOLIT Messmer

    IT-Security, Security, e-security

    COMSOLIT Messmer, Sep 5, 2003, in forum: Computer Support
    Replies:
    0
    Views:
    636
    COMSOLIT Messmer
    Sep 5, 2003
  5. Ablang
    Replies:
    2
    Views:
    603
    Gimpy
    Jun 10, 2006
Loading...

Share This Page