1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Greg Mader">
<meta name="GENERATOR" content="Mozilla/4.6 [en] (WinNT; U) [Netscape]">
<title>Preparing to use Mason</title>
</head>
<body>
<h1>
<font size=+2>Preparing to use Mason</font></h1>
<h3>
1. Introduction.</h3>
<p><br>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 <a href="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html">IPCHAINS
HOWTO</a>. 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 href="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO-7.html">A
Serious Example</a>". So, with gleaming optimisim, I gave copied their
example, and made changes to only the ip address and interface names.
<br>
<h3>
2. One Change at a Time!</h3>
The optimisim faded quickly, as I realized that I couldn't get the machines
to talk.
<p><font face="Courier New,Courier">Router ( To Internet)</font>
<br><font face="Courier New,Courier">
| 209.83.9.193</font>
<br>
|
<br><font face="Courier New,Courier">External Network (To router)</font>
<br><font face="Courier New,Courier">
|</font>
<br><font face="Courier New,Courier">
|</font>
<br><font face="Courier New,Courier"> eth1 |</font>
<br><font face="Courier New,Courier"> ---------------</font>
<br><font face="Courier New,Courier">| 209.83.9.194 |
Server Network (DMZ)</font>
<br><font face="Courier New,Courier">|
|eth2</font>
<br><font face="Courier New,Courier">|
|-------------------------------------------------</font>
<br><font face="Courier New,Courier">|
|209.83.9.195 |
|
|</font>
<br><font face="Courier New,Courier">|
|
|
|
|</font>
<br><font face="Courier New,Courier">| 192.168.1.0 |
|
|
|</font>
<br><font face="Courier New,Courier"> ---------------
-------- ------------
-------</font>
<br><font face="Courier New,Courier">
| eth0
| mail | |workstation |
| WWW |</font>
<br><font face="Courier New,Courier">
|
-------- ------------
-------</font>
<br><font face="Courier New,Courier">
|
209.83.9.198 209.83.9.199 209.83.9.196</font>
<br><font face="Courier New,Courier">
|</font>
<br><font face="Courier New,Courier">Internal Network (198.168.1.X)</font>
<br>
<p>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.
<p>I went back to very simple rules for the chains.
<p><font face="Courier New,Courier">/sbin/ipchains -F</font>
<br><font face="Courier New,Courier">/sbin/ipchains -X</font>
<br><font face="Courier New,Courier">/sbin/ipchains -P input ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -P output ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -P forward DENY</font><font face="Courier New,Courier"></font>
<p>(This flushes the rule set, and sets new base rules)
<br><font face="Courier New,Courier"></font> <font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -i
eth0 -s 192.168.1.0/24 -j MASQ</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -s
209.83.9.194 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -s
209.83.9.198 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -s
209.83.9.199 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -s
209.83.9.196 -j ACCEPT</font>
<br>(This sets up new rules to forward packets from these machines to the
internet.)
<br>
<p>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?
<br>
<h3>
3.Thank you, Mr. Stearns.</h3>
<p><br><a href="ftp://mason.stearns.org">Bill Stearns</a> 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:
<br><font face="Courier New,Courier">/sbin/ipchains -F</font>
<br><font face="Courier New,Courier">/sbin/ipchains -X</font>
<br><font face="Courier New,Courier">/sbin/ipchains -P input ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -P output ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -P forward DENY</font><font face="Courier New,Courier"></font>
<p>(This flushes the rule set, and sets new base rules)
<br><font face="Courier New,Courier"></font> <font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -i
eth0 -s 192.168.1.0/24 -j MASQ</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -s
209.83.9.194 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -d
209.83.9.194 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -s
209.83.9.198 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -d
209.83.9.198 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -s
209.83.9.199 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -d
209.83.9.199 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -s
209.83.9.196 -j ACCEPT</font>
<br><font face="Courier New,Courier">/sbin/ipchains -A forward -p all -d
209.83.9.196 -j ACCEPT</font>
<br>(This sets up new rules to forward packets from these machines to the
internet.)
<p>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.
<p><font face="Courier New,Courier">/sbin/arp -s 209.83.9.198 00:A0:CC:26:B5:67
pub</font>
<br><font face="Courier New,Courier">/sbin/arp -s 209.83.9.199 00:A0:CC:26:B5:67
pub</font>
<br><font face="Courier New,Courier">/sbin/arp -s 209.83.9.196 00:A0:CC:26:B5:67
pub</font><font face="Courier New,Courier"></font>
<p>The (<font face="Courier New,Courier">00:A0:CC:26:B5:67)</font>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.
<p>With this fix, I could now see our webserver from the outside, send
and receive email, and interoperate. I contacted our ISP, <a href="http://www.chorus.net">Chorus</a>
, 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.
<br>
<br>
<h3>
4. Conclusions.</h3>
This example of what I went through demonstrates an important rule:
<br>
<li>
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.</li>
<p><br>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 <a href="ftp://mason.stearns.org">Mason</a>,
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.
<p>Greg Mader
<br>gmader@geoanalytics.com
<br>
</body>
</html>
|
