Preparing to use Mason

 

1. Introduction.


Sometimes the hardest part in starting a new project is knowing what you want to do.  I knew that I wanted to set up a firewall, as I saw the example the IPCHAINS HOWTO. I had created a simple one at home, and I told my boss that this was the solution that we wanted to go with for setting up our company.  After a certain amount of convincing, and a lot of trust on his part, I was given the "Go Ahead" to replicate the chapter 7 model, "A Serious Example". So, with gleaming optimisim, I gave copied their example, and made changes to only the ip address and interface names.
 

2. One Change at a Time!

The optimisim faded quickly, as I realized that I couldn't get the machines to talk.

Router ( To Internet)
       | 209.83.9.193
                  |
External Network (To router)
       |
       |
  eth1 |
 ---------------
| 209.83.9.194 |             Server Network (DMZ)
|              |eth2
|              |-------------------------------------------------
|              |209.83.9.195   |             |                  |
|              |               |             |                  |
| 192.168.1.0  |               |             |                  |
 ---------------             --------       ------------       -------
        | eth0               | mail |      |workstation |      | WWW |
        |                    --------       ------------       -------
        |                  209.83.9.198    209.83.9.199    209.83.9.196
        |
Internal Network (198.168.1.X)
 

None of the machines could get to the outside world, the machines on the internal network couldn't get their mail, and I was perplexed. It was time to take a step backwards.

I went back to very simple rules for the chains.

/sbin/ipchains -F
/sbin/ipchains -X
/sbin/ipchains -P input ACCEPT
/sbin/ipchains -P output ACCEPT
/sbin/ipchains -P forward DENY

(This flushes the rule set, and sets new base rules)
 

/sbin/ipchains -A forward -p all -i eth0 -s 192.168.1.0/24 -j MASQ
/sbin/ipchains -A forward -p all -s 209.83.9.194 -j ACCEPT
/sbin/ipchains -A forward -p all -s 209.83.9.198 -j ACCEPT
/sbin/ipchains -A forward -p all -s 209.83.9.199 -j ACCEPT
/sbin/ipchains -A forward -p all -s 209.83.9.196 -j ACCEPT
(This sets up new rules to forward packets from these machines to the internet.)
 

The internal networked machines were now able to see out to the internet, but the mail and web servers were still not working right.  I didn't know enough about ipchains to even ask the right question. Why was masquerading working, but not the machines with real IP addresses?
 

3.Thank you, Mr. Stearns.


Bill Stearns took pity on me, and told me about a simple, strange rule in ipchains.  Masquerading a network only requires ONE rule, but forwarding public IP packets require TWO rules, one for incoming packets, and one for outgoing. This inconsistancy, while well known about, didn't jump out and make itself obvious.  My new rules looked like this:
/sbin/ipchains -F
/sbin/ipchains -X
/sbin/ipchains -P input ACCEPT
/sbin/ipchains -P output ACCEPT
/sbin/ipchains -P forward DENY

(This flushes the rule set, and sets new base rules)
 

/sbin/ipchains -A forward -p all -i eth0 -s 192.168.1.0/24 -j MASQ
/sbin/ipchains -A forward -p all -s 209.83.9.194 -j ACCEPT
/sbin/ipchains -A forward -p all -d 209.83.9.194 -j ACCEPT
/sbin/ipchains -A forward -p all -s 209.83.9.198 -j ACCEPT
/sbin/ipchains -A forward -p all -d 209.83.9.198 -j ACCEPT
/sbin/ipchains -A forward -p all -s 209.83.9.199 -j ACCEPT
/sbin/ipchains -A forward -p all -d 209.83.9.199 -j ACCEPT
/sbin/ipchains -A forward -p all -s 209.83.9.196 -j ACCEPT
/sbin/ipchains -A forward -p all -d 209.83.9.196 -j ACCEPT
(This sets up new rules to forward packets from these machines to the internet.)

Huzzah, it worked! I now had all of the machines able to see each other, and get out to the internet.  I couldn't see in to our web server, though, from the outside.  After more pondering, and another conversation with Bill, I found out that packets directed to our web server were getting lost at the router.  The web server hadn't changed addresses, but it was removed by one hop from the router.  Bill suggested that I try to fool the router by setting the external interface network card on the firewall to answer calls for the MAC hardware address of the web server.  This complicated sounding procedure is actually very easy.

/sbin/arp -s 209.83.9.198 00:A0:CC:26:B5:67 pub
/sbin/arp -s 209.83.9.199 00:A0:CC:26:B5:67 pub
/sbin/arp -s 209.83.9.196 00:A0:CC:26:B5:67 pub

The (00:A0:CC:26:B5:67)number is the MAC address for the external interface card.  When packets come in from the internet, the router would then send the packets to the MAC address of the external card.  The routing tables that linux uses then figure out that the packet actually does not belong to it, and forwards them to the correct machine.

With this fix, I could now see our webserver from the outside, send and receive email, and interoperate.  I contacted our ISP, Chorus , to help make this permanent.  The tech staff at our ISP created a static route, from their router, through ours, directly to the web, and email servers.  With this change, I could take out the arp commands, and the traffic would route correctly.
 
 

4. Conclusions.

This example of what I went through demonstrates an important rule:
 
  • Start simple.  The experts, like Paul Russell, make this stuff look easy.  Make sure you prototype a simple attempt before you try the full scale approach.


    • This basic set of rules is not secure, and does not take advantage of all of the power of ipchains.  It is only to get you started, and then I suggest that you look into Mason, a really cool firewall building tool that Bill wrote.  Mason will take you the rest of the way towards a secure, well thought out firewall.

    Greg Mader
    gmader@geoanalytics.com