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
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<link rel="stylesheet" type="text/css" href="css.css">
<TITLE>FireHOL, Frequently Asked Questions</TITLE>
<meta name="author" content="Costa Tsaousis">
<meta name="description" content="
Home for FireHOL, an iptables stateful packet filtering firewall builder for Linux (kernel 2.4),
supporting NAT, SNAT, DNAT, REDIRECT, MASQUERADE, DMZ, dual-homed, multi-homed and router setups,
protecting and securing hosts and LANs in all kinds of topologies. Configuration is done using
simple client and server statements while it can detect (and produce) its configuration
automatically. FireHOL is extremely easy to understand, configure and audit.
">
<meta name="keywords" content="iptables, netfilter, filter, firewall, stateful, port, secure, security, NAT, DMZ, DNAT, DSL, SNAT, redirect, router, rule, rules, automated, bash, block, builder, cable, complex, configuration, dual-homed, easy, easy configuration, example, fast, features, flexible, forward, free, gpl, helpme mode, human, intuitive, language, linux, masquerade, modem, multi-homed, open source, packet, panic mode, protect, script, service, system administration, wizard">
<meta http-equiv="Expires" content="Wed, 19 Mar 2003 00:00:01 GMT">
</HEAD>
<BODY bgcolor="#FFFFFF">
<center>
<script type="text/javascript"><!--
google_ad_client = "pub-4254040714325099";
google_ad_width = 728;
google_ad_height = 90;
google_ad_format = "728x90_as";
google_ad_channel ="";
google_page_url = document.location;
google_color_border = "336699";
google_color_bg = "FFFFFF";
google_color_link = "0000FF";
google_color_url = "008000";
google_color_text = "000000";
//--></script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</center>
<p>
<center><a name="contents"><h2>Table of Contents</h2></a></center>
<ul>
<li>General
<ul>
<li><A HREF="#why">How did you come with this idea?</a></li>
<li><A HREF="#trust">Who are you and why should I trust you for handling my firewall?</a></li>
<li><A HREF="#optimization">Is the produced iptables firewall optimized?</a></li>
<li><A HREF="#speed">FireHOL is toooooooooo slow!</a></li>
</ul>
</li>
<li>Installation
<ul>
<li><A HREF="#install">I installed FireHOL but where the hell is it located? I cannot run it!</a></li>
<li><A HREF="#external_commands">Is there a list of the system commands FireHOL needs?</a></li>
</ul>
</li>
<li>Configuration
<ul>
<li><A HREF="#help">I really need help designing the configuration. Could you help?</a></li>
<li><A HREF="#mangling">How can I mangle the packets (set TOS, MARK, etc)?</a></li>
<li><A HREF="#services_in_helpers">Why I cannot use the service definitions in helpers?</a></li>
</ul>
</li>
</ul>
<p>
<!-- GENERAL ------------------------------------------------------------- -->
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b><A NAME="why">How did you come with this idea?</a></td></tr></table>
<br>
When you have to manage several dozens of Linux systems and you have a team of engineers to do the job, then for the firewalling
of all those you have to find solutions so that:
<ul>
<li> <b>Each member of your team can setup firewalling in a consistent way.</b>
In the past, I have seen all kinds of misconfigurations in iptables, even when I was building the rules.
Iptables is not easy, it provides many alternatives for doing the job and each engineer knows or likes
just a few of them.
<br> </li>
<li> <b>Each member of your team knows exactly how each service operates, which ports it needs, how to
prevent various attacks, etc.</b> Again this is not easy stuff. Some techies are more experienced than
others and many have very limited knowledge of the underlying stuff. To see the complication, if I tell
you to setup a firewall for an FTP server supporting active and passive mode, how much time do you need
to find the exact iptables rules and successfully configure the firewall?
<br> </li>
<li> <b>Each member of your team can examine and modify the firewalling rules that another member build some time ago.</b>
This is really nightmare. If I give you 200 iptables rules, how much time do you need to figure out what
is happening and make a few changes?
<br> </li>
<li> <b>For Quality Assurance, ensure that there is an easy way for auditing the firewall quickly.</b>
This is very important. Firewalling is the place that tells you exactly what is allowed and what is not.
</li>
</ul>
I believe that FireHOL solves all these problems in an ideal way. Of course there are many wonderful iptables generators
out there, many of them with many more features than FireHOL, with GUIs, centralized configuration of many systems, etc.
But consider the following:
<p>
<ul>
<li> <b>FireHOL abstracts the service definitions from the firewall rules.</b>
In FireHOL you say "I run a FTP server here" and you don't care what FTP means
for iptables. FireHOL takes care of this detail, so the engineers can focus on what they already know:
The machine runs a FTP server.
<br> </li>
<li> <b>FireHOL minimizes the configuration directives.</b>
Do you know how many iptables statements is this:
<p>
<b>route "smtp http ftp" accept src not "a.client b.client c.client" dst "a.server b.server c.server"</b>
<p>
It is <b>92</b> iptables statements and it would be more than 1000 if in the clients list there was the
<A HREF="commands.html#UNROUTABLE_IPS">UNROUTABLE_IPS</a> variable!!!
</li>
<li> <b>The FireHOL's configuration file is the best place to look for what a server does.</b>
This is actually the first thing I use to audit the configuration of my servers.
I just take a look at the firewall configuration. Even if something more is running, I am sure that
it cannot be accessed from the outside world.
<p>
Also, this is why I like the <a href="commands.html#client">client</a> statement so much. Personally,
I expect all production systems to be configured with client statements that specifically allow only
client requests that are really needed. Although it is pretty helpfull for workstations, I consider
<b>client all accept</b> as a security thread for production servers.
</li>
</ul>
For all the above, I consider FireHOL as the most <b>functional</b> way for working with iptables firewalls.
<p>
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b><A NAME="trust">Who are you and why should I trust you for handling my firewall?</a></td></tr></table>
<br>
Well, don't trust me. I don't want you to do so and you are not supposed to do so. I have made the most to make it
possible for you to audit the generated firewall. You have the <b>explain</b> feature where FireHOL interactivelly
produces iptables statements for the configuration directives you enter, the <b>debug</b> feature where FireHOL
produces all the iptables statements for the entire configuration for you to examine, and extensive <b>automatically</b>
generated documentation for all the <a href="services.html?">services</a> supported.
<p>
Don't trust me. You are supposed to audit FireHOL services at least once, and if you agree, trust <b>it</b>, not me.
<p>
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b><A NAME="optimization">Is the produced iptables firewall optimized?</a></td></tr></table>
<br>
You have to understand that FireHOL is a generic tool. As such, you gain something and you loose something.
Except the fact that all FireHOL configuration rules take one iptables chain (that is one "jump") the produced
rules are fully optimized. In many cases, this "jump" optimizes the firewall even further (for example in interface
and router statements), while in other cases the "jumps" could be moved to a place where they are really necessary
(it is not possible to avoid them).
The good thing is that these "jumps" are not so expensive. So, although there is some room for improvement, I have
reports from users saying that a huge FireHOL firewall did not introduced a noticable increase in CPU utilization
compared to a hand made firewall, for the same traffic.
<p>
For the moment, I prefer to keep all the "jumps" there, since it makes the iptables rules a lot more clear and
easy to understand. If you believe that I should work on this and you can prove that the "jumps" that could
be moved deeper are really expensive at the place they are now, send me a note and I'll do my best.
<p>
If you are so interested about performance, you should know that FireHOL places all rules in the iptables firewall,
in the same order they appear in the configuration file. So placing your most heavy interface at the top, and within
this interface the most heavy service first will really save a lot of processing for iptables.
<p>
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b><A NAME="speed">FireHOL is toooooooooo slow!</a></td></tr></table>
<br>
This is partially true and partially false. FireHOL runs in two phases: <b>Configuration Processing</b> and <b>Firewall Activation</b>.
<p>
Processing of FireHOL configuration files is somewhat slow since all processing
is done by BASH (I have not programmed a parser, BASH runs the configuration as if it was a BASH script). This processing however,
even if it takes several seconds, it does not affect your security, since the running firewall is not touched during this phase.
<p>
Firewall activation is again slow in a few situations, especially if you have lists of hosts that should be allowed or rejected
(like <a href="commands.html#UNROUTABLE_IPS">UNROUTABLE_IPS</a>). During the processing phase, FireHOL produces a list of the iptables commands to
be executed at the activation phase. This list of iptables commands, first clears the running firewall and then it runs
iptables commands, one-by-one, until all have executed. As an example, my personal machine configuration file is about 50 lines.
These 50 lines produce about 900 iptables statements. For BASH these 900 iptables statements are also followed by another
statement to check if the command succeded or failed, which totals to about 1800 BASH statements to be executed. In my machine
these 1800 commands take about 8 seconds to be executed. During these 8 seconds the firewall is from totally empty (all traffic
allowed) to simply incomplete (some traffic is allowed or dropped explicitly, all other is allowed to pass).
<p>
I have written FireHOL in such a way that you can restart the firewall any time you like without disrupting the running
traffic. Try it. Start downloading a file, and in the middle of it, restart FireHOL. No change. The download proceeds without
any disruption. The only chance for traffic disruption is when you have NAT rules. For just a fraction of the total activation
time (normally less than a second, since NAT rules are the first to be executed - i.e. the first few of the huge
iptables list) your system will run without them, meaning that no <b>new</b> NATed traffic will be accepted (established
connections will work). Again, this will be just for a fraction of a second.
<p>
I see you now thinking: OK, but what happens if someone connects to my systems to unwanted services during the activation
time? Well, FireHOL's beauty is that it explicitly allows the connections in both ways of the firewall. Most of the other
iptables generators allow all established connections to pass unchecked. FireHOL doesn't. It allows the established connections that match
the services you have allowed. Nothing more. This means that even if someone is lucky enough to connect to a non-allowed
service during the activation time, he will simply be blocked as soon as the firewall activation completes.
This gives a window of just a few seconds at which someone could be able to connect to and use private services. Even if he
manages to get access within these few seconds, his socket will simply timeout after FireHOL completes.
<p>
<!-- INSTALLATION -------------------------------------------------------- -->
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b><A NAME="install">I installed FireHOL but where the hell is it located? I cannot run it!</a></td></tr></table>
<br>
FireHOL has been designed to be a startup service. Its exact location depends on the distribution you are using.
Most probably you will find FireHOL in /etc/init.d and in RedHat systems you can also access it with the <b>service</b>
command.
<p>
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b><A NAME="external_commands">Is there a list of the system commands FireHOL needs?</a></td></tr></table>
<br>
As of v1.121 and later, you can find a list of such commands at the top of the FireHOL program file.
Currently, FireHOL uses the system path to find these commands and will exit
with an error if some command is missing or exists multiple times.
<p>
<!-- CONFIGURATION -------------------------------------------------------- -->
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b><A NAME="help">I really need help designing the configuration. Could you help?</a></td></tr></table>
<br>
You can use the <b>helpme</b> feature of FireHOL to get a configuration file quickly. The <b>helpme</b> feature
reads various system parameters of your system and generates a configuration file especially for the host it
runs. <b>Helpme</b> is safe to use: it does not alter your running firewall, it does not modify anything on your
system. Just try it (give the keyword <b>helpme</b> as a command line argument to FireHOL).
<p>
In general, I will try to avoid helping you on manual configuring your <b>specific</b> firewall; I commit however
on making <b>helpme</b> detect correctly every single case. I believe, this will benefit all the community, not
just you.
<p>
In any case, I guess I have done a good job in designing FireHOL the way you expect it to work, and that the documentation is
helpful enough, since all the <a href="support.html?">support</a> tools are pretty silent. Of course you are welcome to ask anything you might
need regarding FireHOL.
<p>
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b><A NAME="mangling">How can I mangle the packets (set TOS, MARK, etc)?</a></td></tr></table>
<br>
For MARKing packets, you can use the <a href="commands.html#mark">mark</a> helper.
For all the other iptables features that FireHOL does not support directly,
you can put normal iptables statements anywhere in the configuration file, using the <a href="commands.html#iptables">iptables</a>
helper. If you really like the FireHOL optional rule parameters for doing this job, just send me an e-mail and I'll write a few
helper statements especially for TOS, or whatever.
<p>
<table border=0 cellpadding=10 cellspacing=0 width="100%">
<tr><td bgcolor="#EEEEEE"><b><A NAME="services_in_helpers">Why I cannot use the service definitions in helpers?</a></td></tr></table>
<br>
As you have noted, the <a href="services.html?">service definitions</a> cannot be used in helper statements (mainly NAT).
The reason is that currently FireHOL's core logic is limited to one iptables table (filter). To extend this to all iptables tables
a new core logic is needed that should be based on something that can be shared across all iptables tables. The only such thing
today is MARKs. MARKs are also used for QoS unifying all major traffic management applications.
<p>
I have made a few experiments with MARKs but I stuck because there are bugs in the iptables logic when using MARKs. These bugs
exist in most kernels distributed today with the main Linux distributions.
<p>
<hr noshade size=1>
<table border=0 width="100%">
<tr><td align=center valign=middle>
<A href="http://sourceforge.net"><IMG src="http://sourceforge.net/sflogo.php?group_id=58425&type=5" width="210" height="62" border="0" alt="SourceForge Logo"></A>
</td><td align=center valign=middle>
<small>$Id: faq.html,v 1.5 2004/10/31 23:43:25 ktsaou Exp $</small>
<p>
<b>FireHOL</b>, a firewall for humans...<br>
© Copyright 2004
Costa Tsaousis <a href="mailto: costa@tsaousis.gr"><costa@tsaousis.gr></a>
</body>
</html>
|
