Chapter 13.

Example Configurations
Table of Contents 13.1. Configuring a DMZ Interface Using NAT 13.1.1. Network Diagram 13.1.2. Adding the Optional Interface 13.1.3. Configuring the Optional Interface 13.1.4. Configuring the DMZ Interface Firewall Rules 13.1.5. Permitting select services from DMZ into the LAN 13.1.6. Configuring NAT 13.2. Locking Down DMZ Outbound Internet Access 13.3. Configuring a filtered bridge 13.3.1. General Configuration 13.3.2. WAN Configuration 13.3.3. OPT Interface Configuration 13.3.4. Enable Filtering Bridge 13.3.5. Configure Firewall Rules 13.3.6. Completing the Configuration

13.1. Configuring a DMZ Interface Using NAT

This section will explain how to add a DMZ interface to the two interface (LAN/WAN) base configuration from the Quick Start Guide. You must have a functioning two interface setup before starting on configuring your DMZ interface. The 1:1 NAT DMZ setup is most appropriate where you have multiple public IP's and wish to assign a single public IP to each DMZ host.

13.1.1. Network Diagram

Figure 13.1. Example Network Diagram

This depicts the network layout we will have after configuring our DMZ interface.

13.1.2. Adding the Optional Interface

Log into your m0n0wall's webGUI, and click "(assign)" next to Interfaces.

Click the

on this page to add your third interface.

Now restart your m0n0wall for the changes to take affect.

13.1.3. Configuring the Optional Interface

After your m0n0wall restarts, log back into the webGUI. Under Interfaces, you will see OPT1. Click on it.

Check the box at the top to enable the interface, give it a more descriptive name (I'll call it "DMZ"), and set up the desired IP configuration. The IP subnet must be different from the LAN subnet.

13.1.4. Configuring the DMZ Interface Firewall Rules

The main purpose of a DMZ is to protect the LAN from the publicly-accessible Internet hosts on your network. This way if one of them were to be compromised, your LAN still has protection from the attacker. So if we don't block traffic from the DMZ to the LAN, the DMZ is basically useless. First we will put in a firewall rule on the DMZ interface denying all traffic to the LAN while still

permitting all traffic to the WAN. Click Firewall -> Rules, and click the the bottom of the page.

at

Filling out this screen as shown below will permit all traffic out the DMZ interface to the internet, but prohibit all DMZ traffic from entering the LAN. It also only permits outbound traffic from the DMZ's IP subnet since only traffic from a source IP within your DMZ should come in on the DMZ interface (unless you have a routed DMZ, which would be strange). This prevents spoofed packets from leaving your DMZ.

Click Save after verifying your selections. Then click Apply Changes.

13.1.5. Permitting select services from DMZ into the LAN

You probably have some services on your LAN that your DMZ hosts will need to access. In our sample network, we need to be able to reach DNS on the two LAN DNS servers, cvsup protocol to our LAN cvsup-mirror server, and NTP for time synchronization to the time server that resides on the cvsupmirror server. Always use specific protocols, ports, and hosts when permitting traffic from your DMZ to your LAN. Make sure nothing that isn't required can get through.

Note
Don't forget that source ports (TCP and UDP) are randomly selected high ports, and not the same as the destination port. You'll need to use "any" for source port. My DMZ interface firewall rules now look like the following after permitting the required services from DMZ to LAN.

Note that I added a rule to deny any traffic coming in on the DMZ interface destined for the LAN. This was not required because of the way we configured the allow rule, however I like to put it in there to make it very clear where the traffic from DMZ to LAN is getting dropped. When entering your rules, remember they are processed in top down order, and rule processing stops at the first match. So if you had left the rule we added above as the top rule, it would drop packets from DMZ to LAN without getting to the permit rules you added. I recommend you design your rules similar

to how I have, with drop DMZ to LAN as the second last line, and permit DMZ to any except LAN as the last line.

13.1.6. Configuring NAT

Now you need to determine whether you'll use inbound or 1:1 NAT. If you have multiple public IP's, use 1:1 NAT. If you have only a single public IP, you'll need to use inbound NAT. If you have multiple public IP's, but more DMZ hosts than public IP's, you can use inbound NAT, or a combination of 1:1 and inbound. 13.1.6.1. Using 1:1 NAT For this scenario, we'll say we have a /27 public IP subnet. We'll say it's 2.0.0.0/27. m0n0wall's WAN interface has been assigned with IP 2.0.0.2. I will use 1:1 NAT to assign the public IP 2.0.0.3 to the DMZ mail server and 2.0.0.4 to the DMZ web server.

Go to the Firewall -> NAT screen and click the 1:1 tab. Click the two entries, one each for the mail server and web server.

. I will add

After adding the rules, click Apply changes. You'll now see something like the following.

13.1.6.2. Testing the 1:1 NAT Configuration You can test the 1:1 NAT we just configured by going to whatismyip.com on the machine configured for 1:1. If you don't have a GUI, lynx will work, or you can fetch or wget the URL and cat the resulting file. (fetch http://whatismyip.com && cat whatismyip.com | grep "IP is"). You should see the IP is the one you just configured in 1:1 NAT. If you get an IP other than the one you configured in 1:1, there is a problem with your configuration. 13.1.6.3. Using Inbound NAT If you have only one public IP, or more need more publicly-accessible servers than you have public IP addresses, you'll need to use inbound NAT. Go to the NAT screen, and on the Inbound tab, click

. For this example, we will assume you have only one public IP, and it is the interface address of the WAN interface. First, anything to the WAN IP to port 25 (SMTP) will go to the mail server in our DMZ.

Click Save, and click HTTP server.

to add the inbound NAT rule for the

Click "Apply changes" and your configuration will be working. It should look like the following.

13.2. Locking Down DMZ Outbound Internet Access

We've limited DMZ hosts' accessibility to the LAN, but we can lock it down a step further using egress filtering. Many DMZ hosts don't need to be able to talk out to the Internet at all, or possibly only while you are running updates or doing maintenance or need to download software. If we can keep our DMZ hosts from accessing the Internet, we can make an attacker's job much more difficult. Many exploits rely on the target being able to pull files from a machine the attacker controls, or in the case of a worm, from the infected host. I'll use Code Red and Nimda as an example. Infected hosts exploited the vulnerability, and the remote host pulled the infected admin.dll via TFTP from the already infected host. If you were running vulnerable web servers, but did not allow TFTP traffic outbound from your webservers, you could not have been infected. (reference) Attackers most always try to pull in a tool kit or root kit of some sort onto machines they exploit. There are ways around this, but it just makes it that much more difficult. This will merely slow down

a knowledgeable attacker (who'll find a way to get in one way or another), but it could stop a script kiddie dead in their tracks and keep some worms from infecting your network. This is not a replacement for proper patching and other security measures, it's just good practice in a defense-in-depth strategy.

How does this work?

You might be wondering how your servers will be able to serve content while not being able to talk out to the Internet. I'll use web servers as an example. When packets come in on the WAN interface through firewall rules you have entered to permit HTTP traffic, there is a state entry that permits any return traffic from that connection to traverse the firewall. Remember this only affects the ability to initiate connections outbound, not the ability to respond to incoming traffic requests.

Recommended configuration
As with all firewall rules, limit the accessibility as much as possible. Mail servers that must send outbound mail will need to initiate connections to destination TCP port 25 to any host. If the DNS servers your DMZ hosts use reside outside of the DMZ, you'll need to allow UDP port 53 to the DNS servers being used. I typically put in rules for upgrade purposes to permit outbound traffic to the ports required. For FreeBSD, TCP 5999 (cvsup) and TCP 80 (HTTP) will generally suffice. When I'm not upgrading the system, I use the "disable" checkbox to disable the rule, but leave it in place to easily enable it when needed. Just always remember to disable it when you're done updating the system.

13.3. Configuring a filtered bridge

A filtered bridge is a common way of configuring a DMZ segment. This can be used as a typical DMZ where you have hosts on the LAN interface, but is probably more frequently used to protect servers at a colocation facility where there are no LAN hosts.

Note
Remember you cannot access hosts on a bridged interface from a NAT'ed interface, so if you do have a LAN interface set up, you won't be able to access the hosts on the bridged interface from the LAN.

Network Diagram for this Configuration

The following diagram depicts the example configuration described in this section. The colocation facility has assigned you with the subnet 111.111.111.8/29, which includes usable IP's .9-.14. One of those is required for the colo's router, so you end up with 5 usable IP's. Figure 13.2. Filtered Bridge Diagram

13.3.1. General Configuration

After you have your network set up as shown, and the interfaces and LAN IP assigned appropriately, log into the webGUI to begin the initial configuration. First go to System -> General setup, and configure the hostname, domain, DNS servers, change the password, switch the webGUI to HTTPS, and set your time zone. Click Save, and reboot m0n0wall for the changes to take affect.

13.3.2. WAN Configuration

Log back into the webGUI and go to the Interfaces -> WAN page. For the example network, we'll assign the static IP 111.111.111.10/29, default gateway 111.111.111.9. Unless your WAN network is private IP's, check the "Block private networks" box. Click Save.

13.3.3. OPT Interface Configuration

Click Interfaces -> OPT. Name the interface to your liking (for the example, we'll use Servers for the name). In the "Bridge with" box, select WAN. Click Save.

13.3.4. Enable Filtering Bridge

Go to the System -> Advanced page and check the "Enable filtering bridge" box. Click Save.

13.3.5. Configure Firewall Rules

Go to the Firewall -> Rules screen.

Note
Chances are for any configuration, especially if you're restricting outbound connections, you'll need a much more involved ruleset than is depicted here. Open what you know you need open, and watch for dropped traffic in your logs to see what else you might need to open. It takes some effort to get your firewall locked down as tightly as it can possibly be, but the long term effect of increased security is well worth the time spent. 13.3.5.1. OPT Interface Rules Initially, you may want to configure a rule on the OPT interface permitting traffic to anywhere, then after things are working, tightening that rules as desired. For this example, we'll go ahead and implement locked down rules from the get go. The mail server on our bridged interface needs to send mail to any host on the Internet. Both servers

need to get to DNS servers at 111.111.110.2 and 111.111.109.2. We'll add disabled maintenance rules for HTTP and cvsup. 13.3.5.2. WAN Interface Rules Since this example portrays a firewall at a colocation facility, we need a remote administration rule to allow traffic from our trusted location's static IP access to administration functions of the servers, as well as the m0n0wall webGUI. For this example, we'll permit all traffic from the trusted location (IP 11.12.13.30). You may want to tighten this rule. If you don't have anything on the LAN segment, remember to allow remote administration from somewhere so you can get into the webGUI without being on site. We also need to add rules to permit SMTP traffic to the mail server and HTTP and HTTPS traffic to the web server. 13.3.5.3. LAN Interface Rules You can leave or remove the default LAN to any rule if you don't have hosts on the LAN interface. In the example, the LAN interface will be unplugged once the onsite configuration is completed. 13.3.5.4. Firewall Rules Completed

13.3.6. Completing the Configuration

Everything should be working as desired now, as long as the servers are configured appropriately. Test that the configuration works as desired, including all inbound and outbound rules. Once you're satisfied with the testing results, your setup is complete.

Chapter 14. Example IPSec VPN Configurations

Table of Contents 14.1. Cisco PIX Firewall 14.1.1. PIX Configuration 14.1.2. m0n0wall Configuration 14.2. Smoothwall 14.3. FreeS/WAN 14.4. Sonicwall 14.4.1. Sonicwall Configuration 14.4.2. m0n0wall Configuration 14.5. Nortel 14.6. Mobile User VPN with IPsec? 14.6.1. m0n0wall setup

14.6.2. Client setup m0n0wall can connect to any third party VPN device that supports standard IPsec site to site VPN's, which includes most any VPN device and firewall with IPsec VPN support. This chapter will provide instructions on connecting m0n0wall with a number of third party IPsec devices. Have you configured a VPN between m0n0wall and a device not listed here? Please document how you accomplished this. There is a section of the wiki dedicated to configurations for this chapter. Below you will find sample configurations for the following devices. Cisco PIX Firewall Smoothwall FreeS/WAN Sonicwall Nortel

14.1. Cisco PIX Firewall

The following describes how to configure a site to site IPsec VPN tunnel between a PIX Firewall and m0n0wall.

14.1.1. PIX Configuration

First we need to make sure the PIX has 3DES enabled.
pixfirewall# sh ver Cisco PIX Firewall Version 6.3(3) Cisco PIX Device Manager Version 2.0(2) Compiled on Wed 13-Aug-03 13:55 by morlee pixfirewall up 157 days 5 hours Hardware: PIX-515E, 32 MB RAM, CPU Pentium II 433 MHz Flash E28F128J3 @ 0x300, 16MB BIOS Flash AM29F400B @ 0xfffd8000, 32KB 0: ethernet0: address is 000b.4605.d319, irq 10 1: ethernet1: address is 000b.4605.d31a, irq 11 2: ethernet2: address is 0002.b3b3.2e54, irq 11 Licensed Features: Failover: Disabled VPN-DES: Enabled VPN-3DES-AES: Enabled

If the "VPN-3DES-AES" line above does not show "Enabled", you need to install the PIX 3DES key. This is now available free from Cisco here for all PIX firewalls (click 3DES/AES Encryption License). Do NOT use DES for a VPN if you want it to be cryptographically secure. DES is only slightly better than transmitting in clear text.

Next we'll see if any VPN configurations are in place on the PIX.
pixfirewall# sh isakmp policy Default protection suite encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Secure Hash Standard authentication method: Rivest-Shamir-Adleman Signature Diffie-Hellman group: #1 (768 bit) lifetime: 86400 seconds, no volume limit

If you only see the default policy, there are no VPN's configured. This document cannot be followed verbatim if you have current VPN's (though you should be able to figure it out, just be careful not to break your existing VPN's with any duplicate names). Allow IPSec connections to the PIX
pixfirewall(config)# sysopt connection permit-ipsec

Enable ISAKMP on the outside interface (where "outside" is the name of the internet-facing interface)
pixfirewall(config)# isakmp enable outside

isakmp policy command on PIX

pixfirewall(config)# isakmp policy ? Usage: isakmp policy %lt;priority> authen %lt;pre-share|rsa-sig> isakmp policy %lt;priority> encrypt %lt;aes|aes-192|aes-256|des|3des> isakmp policy %lt;priority> hash %lt;md5|sha> isakmp policy %lt;priority> group %lt;1|2|5> isakmp policy %lt;priority> lifetime %lt;seconds>

Now we need to configure the ISAKMP policy on the PIX. Enter the following commands in configure mode:
isakmp isakmp isakmp isakmp isakmp policy policy policy policy policy 10 10 10 10 10 authen pre-share encrypt 3des hash md5 group 2 lifetime 86400

This policy uses pre-shared keys as authenticator, 3DES encryption, md5 hashing, group 2, and 86400 second lifetime. Now we need to define the pre-shared key for this connection. (1.1.1.1 = public IP address of m0n0wall, qwertyuiop is the shared key, randomly generate something to use for your configuration)
isakmp key qwertyuiop address 1.1.1.1 netmask 255.255.255.255

Now we need to create an access list defining what traffic can cross this tunnel.
access-list monovpn permit ip 10.0.0.0 255.255.255.0 10.0.1.0 255.255.255.0 access-list monovpn permit ip 10.0.0.0 255.255.255.0 10.0.1.0 255.255.255.0

Define transform set for this connection called "monovpnset"

crypto ipsec transform-set monovpnset esp-3des esp-md5-hmac

Define security association lifetime

crypto ipsec security-association lifetime seconds 86400 kilobytes 50000

Now to set up the actual connection, the crypto map "monovpnmap". (where 1.1.1.1 is the public IP address of the m0n0wall device)
crypto crypto crypto crypto map map map map monovpnmap monovpnmap monovpnmap monovpnmap 10 10 10 10 ipsec-isakmp set peer 1.1.1.1 set transform-set monovpnset match address monovpn

These lines specify type of VPN (ipsec-isakmp), peer IP address (1.1.1.1), transform set to be used (monovpnset, defined above), and that packets matching the access list "monovpn" created above should traverse this VPN connection. Last step is to tell the PIX to not use NAT on the packets using this VPN connection and route them instead. First we'll see if anything is currently routed.
pixfirewall# sh nat nat (inside) 0 access-list no-nat

Look for "nat (interface) 0 ..." commands. The above means any traffic matching access list "no-nat" will routed, not translated. In this instance, we are adding to a current access list (if you use a DMZ, you likely have something similar to this set up).
access-list no-nat permit ip 10.0.0.1 255.255.255.0 10.0.1.0 255.255.255.0 access-list no-nat permit ip 10.0.1.0 255.255.255.0 10.0.0.0 255.255.255.0

If you do not have a "nat (interface) 0 ..." command in your "sh nat" output, you can use the above two lines to create a "no-nat" access list. You then have to apply it with the "nat (interface-name) 0 accesslist no-nat" command (replacing "interface-name" with the name of your LAN interface).

14.1.2. m0n0wall Configuration

Log into the m0n0wall web GUI, and under VPN, click IPSec. If the "Enable IPSec" box is not checked, check it and click Save. Click the + button to add a VPN tunnel. On the "Edit tunnel" screen, fill in as follows: Leave "Disable this tunnel" box unchecked. Interface "WAN" Local subnet: Type: "LAN subnet" Remote subnet: 10.0.0.0 /24 (fill in the subnet of the network behind the PIX here, rather th an the made-up 10.0.0.0/24) Remote gateway: public IP address of PIX Description: add one to describe the connection (e.g. "PIX VPN") Phase 1 Negotiation mode: Aggressive My identifier: "My IP Address"

Encryption algorithm: 3DES Hash algorithm: MD5 DH key group: 2 Lifetime: 86400 Pre-shared key: qwertyuiop (enter exactly what you defined as your pre-shared key on the PIX earlier) Phase 2 Protocol: ESP Encryption algorithms: only 3DES checked Hash algorithms: only MD5 checked PFS key group: 2 Lifetime: 86400

Note
In m0n0wall 1.2 beta versions, you may experience the connection dropping frequently with this configuration. If this happens, set the PFS key group in phase 2 to "off".

Note
If you don't specify a key lifetime in the m0n0wall config, the tunnel will work, but appear to go insane after a while. Supposedly Cisco's will negotiate a key lifetime, but I have not seen this work in my experience. This is also true of a Cisco VPN Concentrator. (anonymous wiki contribution)

14.2. Smoothwall
Rev. Tig posted the following information on connecting Smoothwall and m0n0wall via IPsec VPN in a post on the mailing list on September 30, 2004.
I could not find a working solution in the mailing list archives but here is how I have managed to create a VPN between Smoothwall Corporate with Smoothtunnel and m0n0wall and I thought I would share it here to same people going through the same headbashing experience I did :) This will be far to much of a teaching granny to suck eggs for most people on the list but it might help someone get up and running quickly. Variety is the spice of life and just to confuse matters the m0n0wall box was stuck behind NAT :) The office I was linking to was in a serviced building and hence the connection was a shared one with a private IP and public one port forwarded to it. I had never done this before so corrections are welcome :) I am not saying these are the best settings all I know is my VPN is up and running and it seems to be happy :) What I have created is a VPN between one subnet at one site running Smoothwall Corporate Server 3.0 with Smoothtunnel and a m0n0wall v1 box sitting behind NAT with a private IP at the other site. Any other versions of the software may need slightly different settings but hopefully this should put you in the right ballpark.

First off IPSEC over NAT, if at all possible don't :) If you have to or for some perverse reason you fancy a crack at this then read on, if you are just here for the Smoothwall bit scroll down :) IPSEC over NAT does work but it can be a case of sacrificing the odd network card to the deity of your choice, what I did in the end was ask their network guy to just send everything and I will let m0n0 do the firewalling, this is what I would recommend as then you don't have to hassle them every time you want a port opening, but from what I have gathered is that all you need are port 500 forwarding and IP protocols 50 and 51 to be routed but the firewall. Apparently your IPSEC traffic goes through port 500 but IP protocols 50 and 51 are needed for phase 1 (authentication) and phase 2 (key exchange). If I am wrong (this is quite possible there will be a load of mails below correcting me :) If m0n0 is behind NAT and you are certain the other end is right but there appears to be no attempts to authenticate then check here first. Now onto Smoothwall Corporate, now I know Rich Morrell posts on here so I have to be careful about what I say about the interface but that is just a personal taste thing :) Right here are the Smoothwall settings : Local IP : your RED IP address (if you are using Smoothhost then put the IP of your firewall in) Local ID type: Local IP Remote IP : the external IP of your NATted m0n0wall box. Remote ID type : Remote IP Authenticate by : Preshared Key Preshared Key : put your shared key here Use Compression : Off Enabled : On Local network : in this case it was 192.168.0.0/255.255.255.0 Local ID value : same as your Local IP Remote network: in this case it was 192.168.1.0/255.255.255.0 Remote ID value : the same as your Remote IP Initiate the connection : Yes I will use these networks in this example as it shows you a little gotcha in m0n0wall that threw me because I was not thinking :) Next block : Local Certificate : (your local certificate) Perfect Forward Secrecy : Yes Authentication type: ESP (it has to be AH will NOT work over NAT) Phase 1 crypto algo: 3DES Phase 1 hash algo : MD5 Key life : 480 (mins) Key tries : 0 (never give up) Right now the m0n0wall settings : Phase 1: Mode : tunnel (well you can't change it and why would you want to :) Interface : WAN Local Subnet : 192.168.1.0 / 24 (don't do what I did and select LAN :) Remote Subnet : 192.168.0.0 / 24 Remote IP : The RED IP of your Smoothwall box Negotiation Mode : Main My Identifier : IP Address : Your public IP (non NATed) for your

m0n0wall box Encryption Algo: 3DES Hash Algo : MD5 DH Key Group : 5 Lifetime : (blank) Preshared Key : put your shared key here. Phase 2: Protocol : ESP Encryption Algo: 3DES (only! untick the others) Hash Algo: MD5 (again only) PFS Key Group : 5 Lifetime : (blank) That is it, your can now bring the link up from Smoothwall by going into the VPN control tab and clicking UP!

14.3. FreeS/WAN
Josh McAllister provided the following sample ipsec.conf, which can be used to connect m0n0wall with FreeS/WAN in a site to site IPsec configuration.
# /etc/ipsec.conf - FreeS/WAN IPsec configuration file version 2.0 # conforms to second version of ipsec.conf specification

config setup interfaces=%defaultroute klipsdebug=none plutodebug=none uniqueids=yes # defaults for subsequent connection descriptions conn %default # How persistent to be in (re)keying negotiations (0 means very). keyingtries=0 #compress=yes conn block auto=ignore conn private auto=ignore conn private-or-clear auto=ignore conn clear-or-private auto=ignore conn clear auto=ignore conn packetdefault auto=ignore

conn josh type=tunnel left=ip.add.of.m0n0 leftsubnet=m0n0.side.subnet/24 leftnexthop=%defaultroute right=ip.add.of.freeswan rightsubnet=freeswan.side.subnet/24 rightnexthop=%defaultroute authby=secret auth=esp esp=3des-md5-96 pfs=no auto=start m0n0-side: Phase1 Neg. mode = main Enc. Alg = 3DES Hash Alg = MD5 DH key grp = 5 Phase2 Protocol = ESP Uncheck all Enc. Alg. Except 3des Hash alg = md5 PFS key group = off

14.4. Sonicwall
Contributed by Dino Bijedic < dino.bijedic (at) eracom-tech (dot) com> The following describes how to configure a site to site IPSec VPN tunnel between a Sonicwall (PRO 300) and m0n0wall. Editor's note: I would suggest using Main mode rather than Aggressive. Figure 14.1. Network diagram

14.4.1. Sonicwall Configuration

Log in to Sonicwall Click VPN -> Configure Add/Modify IPSec Security Association In Configure, select Security Association -> Add New SA Name: Name of connection (Monowall test) IPSec Gateway Name or Address: Type IP address of your m0n0wall (203.49.X.117) Security Policy Exchange: Aggressive Mode

Phase 1 DH Group: Group2 SA Life time (secs): 28800 Phase 1 Encryption/Authentication: 3DES & MD5 Phase 2 Encryption/Authentication: Strong Encryption and Authentication (ESP 3DES HM AC MD5) Share Secret: type your share secret (novitest) Destination Networks Select "Specify destination network below". The following screenshot shows what this screen will look like.

Click Add New Network You will get: Edit VPN Destination Network (Note: This is Popup window enable Popup in your browser) Network: type your destination network (192.168.200.0) Subnet mask: Type destination subnet mask (255.255.255.0)

Click Update Figure 14.2. Example of Sonicwall configuration

14.4.2. m0n0wall Configuration

Configure m0n0wall IPsec Edit Tunnel screen as follows. Interface: WAN Local subnet: LAN subnet Remote subnet: 192.168.2.0/24 Remote gateway: 61.95.x.99 Description: Sonicwall Negotiation mode: Aggressive My identifier: My IP address Encryption algorithm: 3DES Hash algorithm: MD5 DH key group: 2 Lifetime: 28800 Pre-shared key: novitest Protocol: ESP Encryption algorithms: 3DES Hash algorithms: MD5

PFS key group: off Lifetime: 28800 Click Save at the bottom of the page to complete the VPN configuration.

Setting Up a DMZ with Cisco Routers

Companion pages:

How To Use Your CGI-BIN About htaccess & XBitHack Trying Sun Solaris For Intel x86 Automate Cisco Device Monitoring CGI Scripts On Windows NT / IIS Find Out About Bad Links To Your Websites Beginners Guide To Linux (My new Web site!)

Our other Cisco router pages: Cisco VPN Routers with Windows PPTP Clients Automate the Monitoring of Cisco Devices Setting up a DMZ with Cisco routers not only helps protect your internal network, but the PAT (Port Address Translation) feature in the Cisco IOS means you can send traffic destined for a single IP address to muliple servers. It does this by routing traffic to the appropriate server based on the destination port number. Traffic destined for Port 25 is sent to your mail server, traffic destined for Port 80 is sent to your Web server, etc. In this way, multiple servers can share a single public (external) IP address. Because you can share a single public IP address, there's no need to pay your ISP for multiple addresses to host multiple Internet servers and services. However, this setup will

also work if you do have a public IP subnet with multiple addresses. Typically in this scenario, there will be some sort of ISDN router or DSL bridge provided by the ISP. The incoming connection can be anything from ISDN to DSL to cable to T1. In our example we're using a Cisco 806 router for the outside firewall. This model has two ethernet ports and a built-in hub. A good choice for DSL or cable connections. However, the configs given on this page should work with just about any Cisco router (although you may have to upgrade the IOS to one that has the "Firewall" feature set). Note in following diagram that the DMZ is itself a totally separate private network. Requests, and subsequent responses, for external Internet services from clients on the internal LAN simply traverse the DMZ.

Outside Filter Router (806) This router is primarily used to do two things. First it does NAT (Network Address Translation) on outgoing traffic (changes the source IP address of the packets from an internal LAN address to the address of the external interface). Second, it appropriately routes incoming traffic to either the internal LAN or does PAT (Port Address Translation) to one of the DMZ servers based on the destination port number (port 80 to the Debian box and port 25 to the Solaris box). See the 806 config below. With some platforms you may have to upgrade to a Firewall feature set IOS on this router to get the NAT/PAT fucntionality. Even if not, you'll want that feature set on it to guard against the usual DoS and other types of pattern-based attacks. Inside Filter Router (1720) This router is primarily used to implement policies. It is used to restrict who can get to what on the Internet by restricting outbound traffic to several well-known port numbers. Only two types of inbound traffic are allowed. Because TCP is a connection-oriented protocol, when a system on the internal LAN requests one of the allowed services from an Internet server (including one of the DMZ servers), a connection is established between them. One of the types of traffic allowed in from the "outside" is response traffic received over this connection (as denoted by the established keyword in the 1720 config below). The other type allowed in is traffic from a known, external (ISP) DNS server. It is assumed this traffic represents responses to DNS queries from systems on the internal LAN. (The DMZ servers would also be configured to use these external DNS servers.) See the 1720 config below. Cisco 806 routers are going for around $300 on eBay and 1720s for a couple hundred more. You don't need to have a 1720 to do this. Using two 806s will work just as well. It's just that the 1720 is a modular router with a couple WIC slots for a variety of interface needs (so it would likely be the better choice for the outside-filter router given the variety of broadband connections out there.) Two things to note with this setup. Users on the local LAN would have their POP e-mail

clients set to retrieve mail from the Solaris box (which is why port 110 is opened on the inside router). Also, they'll want to set their FTP client software to use "Passive" transfer mode. NOTE: These configs are from a lab setup and are presented for educational purposes only. They should NOT be used on production routers because they do not implement the security features necessary for securing Internet-connected routers. See the information below on the book "Hardening Cisco Routers" if you plan to set up production Internet-connected routers.

Outside (806) Filter Router Config (primarily does NAT and PAT)

version 12.2 no parser cache no service single-slot-reload-enable no service pad service timestamps debug uptime service timestamps log uptime service password-encryption enable secret 5 $1$QCbf$D7PDt6pAZek52ln8EFJt2/ ! hostname outside-filter ! ! no ip dhcp-client network-discovery no ip http server no ip domain-lookup ip subnet-zero ip classless ! ! ! DMZ interface interface Ethernet0 ip address 10.10.10.1 255.255.255.0 ip nat inside ! ! ISP interface interface Ethernet1 ip address 216.93.82.8 255.255.255.240 ip nat outside ! ! ! Default route to ISP's gateway ip route 0.0.0.0 0.0.0.0 216.93.82.1 ! Static route to inside filter router (internal LAN traffic) ip route 172.17.0.0 255.255.0.0 10.10.10.2 ! ! ! Allow traffic from internal LAN out access-list 1 permit 172.17.0.0 0.0.255.255

! ip nat inside source list 1 interface Ethernet1 overload ! Send incoming SMTP mail traffic Solaris box ip nat inside source static tcp 10.10.10.5 21 216.93.82.8 25 extendable ! Send incoming Web traffic to Debian box ip nat inside source static tcp 10.10.10.3 80 216.93.82.8 80 extendable ! ! line con 0 exec-timeout 30 0 stopbits 1 line vty 0 4 no login ! no scheduler allocate end

Inside (1720) Filter Router Config (primarily does traffic restrictions)

version 12.1 no service single-slot-reload-enable service timestamps debug uptime service timestamps log uptime no logging buffered memory-size iomem 25 enable secret 5 $1$NeV1$I3MvlMKWG2HnKKxYq2KjJ1 ! hostname inside-filter ! ! ip audit notify log ip audit po max-events 100 no ip finger no ip domain-lookup no ip http server ip subnet-zero ip classless ! ! ! DMZ interface interface FastEthernet0 ip address 10.10.10.2 255.255.255.0 ip access-group 101 in ! ! LAN interface interface Ethernet0 ip address 172.17.0.1 255.255.0.0 ip access-group 111 in ! ! ! Default route to inside (DMZ) interface

! of outside filter router ip route 0.0.0.0 0.0.0.0 10.10.10.1 ! ! ! Allow INbound responses from Internet DNS server access-list 101 permit udp host 216.93.82.5 172.17.0.0 0.0.255.255 ! Allow INbound responses from connection-oriented (TCP) requests access-list 101 permit tcp any 172.17.0.0 0.0.255.255 established ! ! Allow OUTbound requests to DNS, Web and SSL, ! Mail (both SMTP and POP), and FTP (both control and data) access-list 111 permit udp 172.17.0.0 0.0.255.255 any eq 53 access-list 111 permit tcp 172.17.0.0 0.0.255.255 any eq 80 access-list 111 permit tcp 172.17.0.0 0.0.255.255 any eq 443 access-list 111 permit tcp 172.17.0.0 0.0.255.255 any eq 25 access-list 111 permit tcp 172.17.0.0 0.0.255.255 any eq 110 access-list 111 permit tcp 172.17.0.0 0.0.255.255 any eq 21 access-list 111 permit tcp 172.17.0.0 0.0.255.255 any eq 20 ! ! line con 0 exec-timeout 30 0 transport input none line aux 0 line vty 0 4 login password LETMEIN ! no scheduler allocate end

If you're going to have any Cisco router interface connected to the Internet or any other type of "untrusted" network (trading partner extranet, etc.) I strongly suggest you get this book: Any kind of Internet connection is risky. If you connect Cisco routers to the Internet you'll want Hardening Cisco Routers. It's an administrator's book. Threats and the IOS commands needed to mitigate them are given. Each chapter has a checklist you can use to check your routers to make sure they comply with all of the points mentioned. Just the information on setting up your routers for secure remote access alone is worth the price of the book. It also shows you how to limit your router's SNMP exposure which, if you've looked at Cisco's "IOS Upgrade Planner" Web page lately, you know presents a big security threat to IOS devices. At $18 it's got to be the biggest bargain in the Cisco world. Another fine book in the O'Reilly tradition of real world info for real world situtations. (After you get the book be sure to check O'Reilly's Web site - www.oreilly.com - for the errata. There are a couple minor things and some reader comments that are important, more so with a book of this nature which focuses on securing routers.)

More info...

Did you find this page helpful ? If so, please use the Amazon book links to help pay the costs associated with making this page available.

Top of page

Contents, diagrams, and images Copyright 2004-2009 Keith Parkansky All rights reserved. "Bestdam Logger" and the BDL graphic logo are trademarks of Keith Parkansky. Certain graphics, symbols, and terms used on this site and in its documents are registered trademarks of their respective owners and are contained herein for identification purposes only. No endorsement of this site, its contents, or its documents by these owners is expressed or implied. LIABILITY IN NO EVENT WILL KEITH PARKANSKY BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.

You are previewing premium content. Become an Insider to read the full article. You are viewing Insider content. Browse other Insider articles

Lab 10: Setting Up a DMZ

Cisco Press
By David Hucaby, Network World October 22, 2008 03:09 PM ET
Object 1

Comment Print

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Excerpt from Cisco Firewall Video Mentor (Video Learning). Published by Cisco Press ISBN-10: 1-58720-198-4 ISBN-13: 978-1-58720-198-1 This Cisco Firewall Video Mentor lab shows you how to add a demilitarized zone (DMZ) interface to a firewall, whereas previous labs dealt with only inside and outside interfaces. The objectives of this lab are to configure address translation and access lists as security policies for the following scenarios: Connections initiated from a higher security level interface toward a lower one Connections initiated from a lower security level interface toward a higher one

Scenario
This lab contains several scenarios, presented in the following steps: Step Consider connections initiated from the inside interface 1. toward the DMZ, and configure the firewall accordingly. Step Consider connections initiated from the DMZ interface 2. toward the outside, and configure the firewall

accordingly. Step Consider connections initiated from the outside interface 3. toward the DMZ, and configure the firewall accordingly. Step Consider connections initiated from the DMZ interface 4. toward the inside, and configure the firewall accordingly. Step Double-check the DMZ access list for conflicting 5. entries.

Initial Configurations
The firewall begins with a simple configuration used in previous labs. Although the lab configurations take place on the "context-a" security context, they could just as easily be configured on a firewall running in single context mode. The firewall is configured with an inside and outside interface, with address translation and access lists configured for inside-to-outside connections, as well as outside-to-inside connections. The initial configuration commands for the firewall are shown in Example 10-1. Example 10-1 Initial Firewall Configuration
hostname context-a!interface intf0 nameif outside security-level 0 ip address 192.168.100.10 255.255.255.0 standby 192.168.100.11!interface intf1 nameif inside security-level 100 ip address 192.168.2.1 255.255.255.0 standby 192.168.2.2!nat (inside) 1 192.168.2.0 255.255.255.0global (outside) 1 interface outsideaccess-list acl_inside extended permit ip 192.168.2.0 255.255.255.0 anyaccess-group acl_inside in interface inside!static (inside,outside) 192.168.100.100 192.168.2.100 netmask 255.255.255.255access-list acl_outside extended permit tcp any host 192.168.100.100 eq wwwaccess-list acl_outside extended permit tcp any host 192.168.100.100 eq httpsaccess-group acl_outside in interface outside

Video Presentation Reference

Refer to the following descriptions of each step in Lab 10. A DMZ interface is added according to the network diagram shown in Figure 10-1, with the configuration shown in Example 10-2.

Figure 10-1 Adding a DMZ Interface to a Firewall

Example 10-2 Initial DMZ Interface Configuration

interface intf2 nameif dmz security-level 50 ip address 192.168.99.1 255.255.255.0 no shutdown

Step 1: Consider Connections from the Inside Toward the DMZ

In this step, address translation is configured across the inside and DMZ interfaces. Because the access list acl_inside was previously configured to permit all traffic from the inside subnet toward any destination address, no changes need to be made for traffic destined for the DMZ. Example 10-3 shows the configuration command that is entered. The firewall's initial configuration includes a definition for nat (inside) 3, so only the corresponding global command is needed. Example 10-3 Configuring Security Policies for Inside-to-DMZ Connections Firewall(config)# global (dmz) 3 interface dmz

Step 2: Consider Connections from the DMZ Toward the Outside

In this step, address translation is configured across the DMZ and outside interfaces. A series of global commands are already present in the firewall's initial configuration, requiring only a corresponding nat command to be added. The access list acl_dmz is created to permit any IP traffic from the DMZ subnet 192.168.99.0/24 to any destination address on the outside. Example 10-4 shows the configuration commands that are entered in this step. Example 10-4 Configuring Security Policies for DMZ-to-Outside Connections
Firewall(config)# nat (dmz) 3 192.168.99.0 255.255.255.0 Firewall(config)# access-list acl_dmz extended permit ip 192.168.99.0 255.255.255.0 anyFirewall(config)# access-group acl_dmz in interface dmz

Step 3: Consider Connections from the Outside Toward the DMZ

In this step, address translation is configured across the outside and DMZ interfaces with a static command. DMZ address 192.168.99.10 is mapped to outside address 192.168.100.110. In addition, the access list acl_outside is amended to include rules that permit inbound connections from any outside address to the mapped address 192.168.100.110 with destination ports TCP 80 and 443. Example 10-5 shows the configuration commands that are entered. Example 10-5 Configuring Security Policies for Outside-to-DMZ Connections
Firewall(config)# static (dmz,outside) 192.168.100.110 192.168.99.10 netmask 255.255.255.255! Firewall(config)# access-list acl_outside extended permit tcp any host 192.168.100.110 eq www Firewall(config)# access-list

acl_outside extended permit tcp any host 192.168.100.110 eq https

Step 4: Consider Connections from the DMZ Toward the Inside

This step shows you how to configure address translation across the DMZ and inside interfaces using a static command. Inside server address 192.168.2.99 is mapped to DMZ address 192.168.99.99. Rules are added to the acl_dmz access list to permit inbound connections from DMZ server 192.168.99.10 to the mapped address 192.168.99.99. Only connections to destination ports TCP 1433 and FTP are permitted. The commands shown in Example 10-6 are entered during the configuration. Example 10-6 Configuring Security Policies for DMZ-to-Inside Connections
Firewall(config)# static (dmz,inside) 192.168.2.99 192.168.99.99 netmask 255.255.255.255! Firewall(config)# access-list acl_dmz

In computer security, a DMZ, or De Militarized Zone, is a physical or logical subnetwork that contains and exposes an organization's external services to a larger untrusted network, usually the Internet. The term is normally referred to as a DMZ by information technology professionals. It is sometimes referred to as a perimeter network. The purpose of a DMZ is to add an additional layer of security to an organization's local area network (LAN); an external attacker only has access to equipment in the DMZ, rather than any other part of the network.

Contents
[hide] 1 Rationa le 2 Service s in the DMZ 2 . 1 W e b s e r v e r s 2 . 2 E m a i l s e r v e r s 2 . 3

[edit] Rationale
In a network, the hosts most vulnerable to attack are those that provide services to users outside of the local area network, such as e-mail, web and Domain Name System (DNS) servers. Because of the increased potential of these hosts being compromised, they are placed into their own sub-network in order to protect the rest of the network if an intruder were to succeed in attacking all of them. Hosts in the DMZ have limited connectivity to specific hosts in the internal network, although communication with other hosts in the DMZ and to the external network is allowed. This allows hosts in the DMZ to provide services to both the internal and external network, while an intervening firewall controls the traffic between the DMZ servers and the internal network clients. A DMZ configuration typically provides security from external attacks, but it typically has no bearing on internal attacks such as sniffing communication via a packet analyzer or spoofing such as e-mail spoofing.

[edit] Services in the DMZ

Any service that is being provided to users on the external network can be placed in the DMZ. The most common of these services are: web servers mail servers FTP servers VoIP servers

[edit] Web servers

Web servers that communicate with an internal database require access to a database server, which may not be publicly accessible and may contain sensitive information. The web servers can communicate with database servers either directly or through an application firewall for security reasons.

[edit] E-mail servers

E-mail messages and particularly the user database are confidential information, so they are typically stored on servers that cannot be accessed from the Internet (at least not in an insecure manner), but can be accessed from the SMTP servers that are exposed to the Internet. The mail server inside the DMZ passes incoming mail to the secured/internal mail servers. It also handles outgoing mail.

[edit] Proxy servers

For security, legal compliance and monitoring reasons, in a business environment, some enterprises install a proxy server within the DMZ. This has the following consequences: Obliges the internal users (usually employees) to use the proxy to get Internet access. Allows the company to reduce Internet access bandwidth requirements because some of the web content may be cached by the proxy server. Simplifies the recording and monitoring of user activities and block content violating acceptable

use policies.

[edit] Reverse proxy servers

A reverse proxy server, like a proxy server, is an intermediary, but is used the other way around. Instead of providing a service to internal users wanting to access an external network, it provides indirect access for an external network (usually the Internet) to internal resources. For example, a back office application access, such as an email system, could be provided to external users (to read emails while outside the company) but the remote user would not have direct access to his email server. Only the reverse proxy server can physically access the internal email server. This is an extra layer of security, which is particularly recommended when internal resources need to be accessed from the outside. Usually such a reverse proxy mechanism is provided by using an application layer firewall as they focus on the specific shape of the traffic rather than controlling access to specific TCP and UDP ports as a packet filter firewall does.

[edit] Architecture
There are many different ways to design a network with a DMZ. Two of the most basic methods are with a single firewall, also known as the three legged model, and with dual firewalls. These architectures can be expanded to create very complex architectures depending on the network requirements.

[edit] Single firewall

A single firewall with at least 3 network interfaces can be used to create a network architecture containing a DMZ. The external network is formed from the ISP to the firewall on the first network interface, the internal network is formed from the second network interface, and the DMZ is formed from the third network interface. The firewall becomes a single point of failure for the network and must be able to handle all of the traffic going to the DMZ as well as the internal network. The zones are usually marked with colors -for example, purple for LAN, green for DMZ, red for Internet (with often another color used for wireless zones).

[edit] Dual firewall

A more secure approach is to use two firewalls to create a DMZ. The first firewall (also called the "front-end" firewall) must be configured to allow traffic destined to the DMZ only. The second firewall (also called "back-end" firewall) allows only traffic from the DMZ to the internal network. Some recommend that the two firewalls be provided by two different vendors. If an attacker manages to break through the first firewall, it may take more time to break through the second one if it is made by a different vendor, and thus less likely to suffer from the same security vulnerabilities if any are found (whether from accidental misconfiguration less likely to occur the same way across the configuration interfaces of two different vendors, or from a security hole found to exist in one vendor's system but not the other). This architecture is, of course, more costly. The practice of using different firewalls from different vendors is sometimes described as a component of a "defense in depth" security strategy.

[edit] DMZ host

Some home routers refer to a DMZ host. A home router DMZ host is a host on the internal network that has all ports exposed, except those ports otherwise forwarded. By definition this is not a true DMZ (Demilitarized Zone), since it alone does not separate the host from the internal network. That is, the DMZ host is able to connect to hosts on the internal network, whereas hosts within a real DMZ are prevented from connecting with the internal network by a firewall that separates them, unless the firewall permits the connection. A firewall may allow this if a host on the internal network first requests a connection to the host within the DMZ. The DMZ host provides none of the security advantages that a subnet provides and is often used as an easy method of forwarding all ports to another firewall / NAT device.

[edit] See also

Bastion host

[edit] References
SolutionBase: Strengthen network defenses by using a DMZ by Deb Shinder at TechRepublic.

 Eric Maiwald. Network Security: A Beginner's Guide. Second Edition. McGraw-Hill/Osborne, 2003. Internet Firewalls: Frequently Asked Questions, compiled by Matt Curtin, Marcus Ranum and Paul Robertson Retrieved from "http://en.wikipedia.org/wiki/DMZ_(computing)"