Merge from vendor branch SENDMAIL:
[dragonfly.git] / share / examples / ipfilter / examples.txt
1 IP Filter Examples
2
3      [Image] Permissions
4      [Image] Interface
5      [Image] Netmasks and hosts
6      [Image] IP Protocols
7      [Image] IP Options
8      [Image] IP Fragments
9      [Image] TCP/UDP Ports
10      [Image] ICMP type/code
11      [Image] TCP Flags (established)
12      [Image] Responding to a BAD packet
13      [Image] IP Security Classes
14      [Image] Packet state filtering
15      [Image] Network Address Translation (NAT)
16      [Image] Transparent Proxy Support
17      [Image] Transparent routing
18      [Image] Logging packets to network devices
19      [Image] Rule groups
20      Authenticating packets
21      Pre-authenticating packets
22
23   ------------------------------------------------------------------------
24
25 Permission Specifying.
26
27 To specify where to pass through or to block a packet, either block or pass
28 is used. In and out are used to describe the direction in which the packet
29 is travelling through a network interface. Eg:
30
31 # setup default to block all packets.
32 block in all
33 block out all
34 # pass packets from host firewall to any destination
35 pass in from firewall to any
36
37   ------------------------------------------------------------------------
38
39 Select network Interfaces
40
41 To select which interface a packet is currently associated with, either its
42 destination as a result of route processing or where it has been received
43 from, the on keyword is used. Whilst not compulsory, it is recommended that
44 each rule include it for clarity. Eg:
45
46 # drop all inbound packets from localhost coming from ethernet
47 block in on le0 from localhost to any
48
49   ------------------------------------------------------------------------
50
51 Netmasks and hosts
52
53 As not all networks are formed with classical network boundaries, it is
54 necessary to provide a mechanism to support VLSM (Variable Length Subnet
55 Masks). This package provides several ways to do this. Eg:
56
57 #
58 block in on le0 from mynet/26 to any
59 #
60 block in on le0 from mynet/255.255.255.192 to any
61 #
62 block in on le0 from mynet mask 255.255.255.192 to any
63 #
64 block in on le0 from mynet mask 0xffffffc0 to any
65
66 Are all valid and legal syntax with this package. However, when regenerating
67 rules (ie using ipfstat), this package will prefer to use the shortest valid
68 notation (top down).
69
70 The default netmask, when none is given is 255.255.255.255 or "/32".
71
72 To invert the match on a hostname or network, include an ! before the name
73 or number with no space between them.
74   ------------------------------------------------------------------------
75
76 Protocol
77
78 To filter on an individual protocol, it is possible to specify the protocol
79 in a filter rule. Eg:
80
81 # block all incoming ICMP packets
82 block in on le0 proto icmp all
83
84 The name of the protocol can be any valid name from /etc/protocols or a
85 number.
86
87 # allow all IP packets in which are protocol 4
88 pass in on le0 proto 4 all
89
90 There is one exception to this rule, being "tcp/udp". If given in a ruleset,
91 it will match either of the two protocols. This is useful when setting up
92 port restrictions. Eg:
93
94 # prevent any packets destined for NFS from coming in
95 block in on le0 proto tcp/udp from any to any port = 2049
96
97   ------------------------------------------------------------------------
98
99 Filtering IP fragments
100
101 IP fragments are bad news, in general. Recent study has shown that IP
102 fragments can pose a large threat to IP packet filtering, IF there are rules
103 used which rely on data which may be distributed across fragments. To this
104 package, the threat is that the TCP flags field of the TCP packet may be in
105 the 2nd or 3rd fragment or possibly be believed to be in the first when
106 actually in the 2nd or 3rd.
107
108 To filter out these nasties, it is possible to select fragmented packets out
109 as follows:
110
111 #
112 # get rid of all IP fragments
113 #
114 block in all with frag
115
116 The problem arises that fragments can actually be a non-malicious. The
117 really malicious ones can be grouped under the term "short fragments" and
118 can be filtered out as follows:
119
120 #
121 # get rid of all short IP fragments (too small for valid comparison)
122 #
123 block in proto tcp all with short
124
125   ------------------------------------------------------------------------
126
127 IP Options
128
129 IP options have a bad name for being a general security threat. They can be
130 of some use, however, to programs such as traceroute but many find this
131 usefulness not worth the risk.
132
133 Filtering on IP options can be achieved two ways. The first is by naming
134 them collectively and is done as follows:
135
136 #
137 # drop and log any IP packets with options set in them.
138 #
139 block in log all with ipopts
140 #
141
142 The second way is to actually list the names of the options you wish to
143 filter.
144
145 #
146 # drop any source routing options
147 #
148 block in quick all with opt lsrr
149 block in quick all with opt ssrr
150
151 [Image] NOTE that options are matched explicitly, so if I had lsrr,ssrr it
152 would only match packets with both options set.
153
154 It is also possible to select packets which DON'T have various options
155 present in the packet header. For example, to allow telnet connections
156 without any IP options present, the following would be done:
157
158 #
159 # Allow anyone to telnet in so long as they don't use IP options.
160 #
161 pass in proto tcp from any to any port = 23 with no ipopts
162 #
163 # Allow packets with strict source routing and no loose source routing
164 #
165 pass in from any to any with opt ssrr not opt lsrr
166
167   ------------------------------------------------------------------------
168
169 Filtering by ports
170
171 Filtering by port number only works with the TCP and UDP IP protocols. When
172 specifying port numbers, either the number or the service name from
173 /etc/services may be used. If the proto field is used in a filter rule, it
174 will be used in conjunction with the port name in determining the port
175 number.
176
177 The possible operands available for use with port numbers are:
178
179 Operand Alias   Parameters      Result
180 <       lt      port#           true if port is less than given value
181 >       gt      port#           true if port is greater than given value
182 =       eq      port#           true if port is equal to than given value
183 !=      ne      port#           true if port is not equal to than given value
184 <=      le      port#           true if port is less than or equal to given value
185 =>      ge      port#           true if port is greater than or equal to given value
186
187 Eg:
188
189 #
190 # allow any TCP packets from the same subnet as foo is on through to host
191 # 10.1.1.2 if they are destined for port 6667.
192 #
193 pass in proto tcp from fubar/24 to 10.1.1.2/32 port = 6667
194 #
195 # allow in UDP packets which are NOT from port 53 and are destined for
196 # localhost
197 #
198 pass in proto udp from fubar port != 53 to localhost
199
200 Two range comparisons are also possible:
201
202 Expression Syntax:
203 port1#  <>      port2#          true if port is less than port1 or greater than port2
204 port1#  ><      port2#          true if port is greater than port1 and less than port2
205
206 [Image] NOTE that in neither case, when the port number is equal to one of
207 those given, does it match. Eg:
208
209 #
210 # block anything trying to get to X terminal ports, X:0 to X:9
211 #
212 block in proto tcp from any to any port 5999 >< 6010
213 #
214 # allow any connections to be made, except to BSD print/r-services
215 # this will also protect syslog.
216 #
217 block in proto tcp/udp all
218 pass in proto tcp/udp from any to any port 512 <> 515
219
220 Note that the last one above could just as easily be done in the reverse
221 fashion: allowing everything through and blocking only a small range. Note
222 that the port numbers are different, however, due to the difference in the
223 way they are compared.
224
225 #
226 # allow any connections to be made, except to BSD print/r-services
227 # this will also protect syslog.
228 #
229 pass in proto tcp/udp all
230 block in proto tcp/udp from any to any port 511 >< 516
231
232   ------------------------------------------------------------------------
233
234 TCP Flags (established)
235
236 Filtering on TCP flags is useful, but fraught with danger. I'd recommend
237 that before using TCP flags in your IP filtering, you become at least a
238 little bit acquainted with what the role of each of them is and when they're
239 used. This package will compare the flags present in each TCP packet, if
240 asked, and match if those present in the TCP packet are the same as in the
241 IP filter rule.
242
243 Some IP filtering/firewall packages allow you to filter out TCP packets
244 which belong to an "established" connection. This is, simply put, filtering
245 on packets which have the ACK bit set. The ACK bit is only set in packets
246 transmitted during the lifecycle of a TCP connection. It is necessary for
247 this flag to be present from either end for data to be transferred. If you
248 were using a rule which as worded something like:
249
250 allow proto tcp 10.1.0.0 255.255.0.0 port = 23 10.2.0.0 255.255.0.0 established
251
252 It could be rewritten as:
253
254 pass in proto tcp 10.1.0.0/16 port = 23 10.2.0.0/16 flags A/A
255 pass out proto tcp 10.1.0.0/16 port = 23 10.2.0.0/16 flags A/A
256
257 A more useful flag to filter on, for TCP connections, I find, is the SYN
258 flag. This is only set during the initial stages of connection negotiation,
259 and for the very first packet of a new TCP connection, it is the only flag
260 set. At all other times, an ACK or maybe even an URG/PUSH flag may be set.
261 So, if I want to stop connections being made to my internal network
262 (10.1.0.0) from the outside network, I might do something like:
263
264 #
265 # block incoming connection requests to my internal network from the big bad
266 # internet.
267 #
268 block in on le0 proto tcp from any to 10.1.0.0/16 flags S/SA
269
270 If you wanted to block the replies to this (the SYN-ACK's), then you might
271 do:
272
273 block out on le0 proto tcp from 10.1.0.0 to any flags SA/SA
274
275 where SA represents the SYN-ACK flags both being set.
276
277 The flags after the / represent the TCP flag mask, indicating which bits of
278 the TCP flags you are interested in checking. When using the SYN bit in a
279 check, you SHOULD specify a mask to ensure that your filter CANNOT be
280 defeated by a packet with SYN and URG flags, for example, set (to Unix, this
281 is the same as a plain SYN).
282   ------------------------------------------------------------------------
283
284 ICMP Type/Code
285
286 ICMP can be a source of a lot of trouble for Internet Connected networks.
287 Blocking out all ICMP packets can be useful, but it will disable some
288 otherwise useful programs, such as "ping". Filtering on ICMP type allows for
289 pings (for example) to work. Eg:
290
291 # block all ICMP packets.
292 #
293 block in proto icmp all
294 #
295 # allow in ICMP echos and echo-replies.
296 #
297 pass in on le1 proto icmp from any to any icmp-type echo
298 pass in on le1 proto icmp from any to any icmp-type echorep
299
300 To specify an ICMP code, the numeric value must be used. So, if we wanted to
301 block all port-unreachables, we would do:
302
303 #
304 # block all ICMP destination unreachable packets which are port-unreachables
305 #
306 block in on le1 proto icmp from any to any icmp-type unreach code 3
307
308   ------------------------------------------------------------------------
309
310 Responding to a BAD packet
311
312 To provide feedback to people trying to send packets through your filter
313 which you wish to disallow, you can send back either an ICMP error
314 (Destination Unreachable) or, if they're sending a TCP packet, a TCP RST
315 (Reset).
316
317 What's the difference ? TCP/IP stacks take longer to pass the ICMP errors
318 back, through to the application, as they can often be due to temporary
319 problems (network was unplugged for a second) and it is `incorrect' to shut
320 down a connection for this reason. Others go to the other extreme and will
321 shut down all connections between the two hosts for which the ICMP error is
322 received. The TCP RST, however, is for only *one* connection (cannot be used
323 for more than one) and will cause the connection to immediately shut down.
324 So, for example, if you're blocking port 113, and setup a rule to return a
325 TCP RST rather than nothing or an ICMP packet, you won't experience any
326 delay if the other end was attempting to make a connection to an identd
327 service.
328
329 Some examples are as follows:
330
331 #
332 # block all incoming TCP connections but send back a TCP-RST for ones to
333 # the ident port
334 #
335 block in proto tcp from any to any flags S/SA
336 block return-rst in quick proto tcp from any to any port = 113 flags S/SA
337 #
338 # block all inbound UDP packets and send back an ICMP error.
339 #
340 block return-icmp in proto udp from any to any
341
342 When returning ICMP packets, it is also possible to specify the type of ICMP
343 error return. This was requested so that traceroute traces could be forced
344 to end elegantly. To do this, the requested ICMP Unreachable code is placed
345 in brackets following the "return-icmp" directive:
346
347 #
348 # block all inbound UDP packets and send back an ICMP error.
349 #
350 block return-icmp (3) in proto udp from any to any port > 30000
351 block return-icmp (port-unr) in proto udp from any to any port > 30000
352
353 Those two examples are equivalent, and return a ICMP port unreachable error
354 packet to in response to any UDP packet received destined for a port greater
355 than 30,000.
356   ------------------------------------------------------------------------
357
358 Filtering IP Security Classes
359
360 For users who have packets which contain IP security bits, filtering on the
361 defined classes and authority levels is supported. Currently, filtering on
362 16bit authority flags is not supported.
363
364 As with ipopts and other IP options, it is possible to say that the packet
365 only matches if a certain class isn't present.
366
367 Some examples of filtering on IP security options:
368
369 #
370 # drop all packets without IP security options
371 #
372 block in all with no opt sec
373 #
374 # only allow packets in and out on le0 which are top secret
375 #
376 block out on le1 all
377 pass out on le1 all with opt sec-class topsecret
378 block in on le1 all
379 pass in on le1 all with opt sec-class topsecret
380
381   ------------------------------------------------------------------------
382
383 Packet state filtering
384
385 Packet state filtering can be used for any TCP flow to short-cut later
386 filtering. The "short-cuts" are kept in a table, with no alterations to the
387 packet filter list made. Subsequent packets, if a matching packet is found
388 in the table, are not passed through the list. For TCP flows, the filter
389 will follow the ack/sequence numbers of packets and only allow packets
390 through which fall inside the correct window.
391
392 #
393 # Keep state for all outgoing telnet connections
394 # and disallow all other TCP traffic.
395 #
396 pass out on le1 proto tcp from any to any port = telnet keep state
397 block out on le1 all
398
399 For UDP packets, packet exchanges are effectively stateless. However, if a
400 packet is first sent out from a given port, a reply is usually expected in
401 answer, in the `reverse' direction.
402
403 #
404 # allow UDP replies back from name servers
405 #
406 pass out on le1 proto udp from any to any port = domain keep state
407
408 Held UDP state is timed out, as is TCP state for entries added which do not
409 have the SYN flag set. If an entry is created with the SYN flag set, any
410 subsequent matching packet which doesn't have this flag set (ie a SYN-ACK)
411 will cause it to be "timeless" (actually, the timeout defaults to 5 days),
412 until either a FIN or RST is seen.
413
414   ------------------------------------------------------------------------
415
416 Network Address Translation (NAT)
417
418 Network address translation is used to remap IP #'s from one address range
419 to another range of network addresses. For TCP and UDP, this also can
420 include the port numbers. The IP#'s/port #'s are changed when a packet is
421 going out through an interface and IP Filter matches it against a NAT rules.
422
423 Packets coming back in the same interface are remapped, as a matter of
424 course, to their original address information.
425
426 # map all tcp connections from 10.1.0.0/16 to 240.1.0.1, changing the source
427 # port number to something between 10,000 and 20,000 inclusive.  For all other
428 # IP packets, allocate an IP # between 240.1.0.0 and 240.1.0.255, temporarily
429 # for each new user.  In this example, ed1 is the external interface.
430 # Use ipnat, not ipf to load these rules.
431 #
432 map ed1 10.1.0.0/16 -> 240.1.0.1/32 portmap tcp 10000:20000
433 map ed1 10.1.0.0/16 -> 240.1.0.0/24
434
435   ------------------------------------------------------------------------
436
437 Transparent Proxy Suppoer
438
439 Transparent proxies are supported through redirection, which works in a
440 similar way to NAT, except that rules are triggered by input packets. To
441 effect redirection rules, ipnat must be used (same as for NAT) rather than
442 ipf.
443
444 # Redirection is triggered for input packets.
445 # For example, to redirect FTP connections through this box (in this case ed0
446 # is the interface on the "inside" where default routes point), to the local
447 # ftp port, forcing them to connect through a proxy, you would use:
448 #
449 rdr ed0 0.0.0.0/0 port ftp -> 127.0.0.1 port ftp
450
451   ------------------------------------------------------------------------
452
453 Transparent routing
454
455 Transparent routing can be performed in two ways using IP Filter. The first
456 is to use the keyword "fastroute" in a rule, using the normal route lookup
457 to occur or using a fixed route with "to". Both effect transparent routing
458 by not causing any decrement in the TTL to occur as it passes through the
459 kernel.
460
461 # Route all UDP packets through transparently.
462 #
463 pass in quick fastroute proto udp all
464 #
465 # Route all ICMP packets to network 10 (on le0) out through le1, to "router"
466 #
467 pass in quick on le0 to le1:router proto icmp all
468
469   ------------------------------------------------------------------------
470
471 Logging packets to the network
472
473 Logging packets to the network devices is supported for both packets being
474 passed through the filter and those being blocked. For packets being passed
475 on, the "dup-to" keyword must be used, but for packets being blocked, either
476 "to" (more efficient) or "dup-to" can be used.
477
478 To log packets to the interface without requiring ARP to work, create a
479 static arp cache for a meaningless IP# (say 10.0.0.1) and log packets to
480 this IP#.
481
482 # Log all short TCP packets to qe3, with "packetlog" as the intended
483 # destination for the packet.
484 #
485 block in quick to qe3:packetlog proto tcp all with short
486 #
487 # Log all connection attempts for TCP
488 #
489 pass in quick on ppp0 dup-to le1:packetlog proto tcp all flags S/SA
490
491   ------------------------------------------------------------------------
492
493 Rule groups
494
495 To aide in making rule processing more efficient, it is possible to setup
496 rule `groups'. By default, all rules are in group 0 and all other groups
497 have it as their ultimate parent. To start a new group, a rule includes a
498 `head' statement, such as this:
499
500 # Process all incoming ppp packets on ppp0 with group 100, with the default for
501 # this interface to block all incoming.
502 #
503 block in quick on ppp0 all head 100
504
505 If we then wanted to allow people to connect to our WWW server, via ppp0, we
506 could then just add a rule about WWW. NOTE: only packets which match the
507 above rule are processed by any group 100 rules.
508
509 # Allow connections to the WWW server via ppp0.
510 #
511 pass in quick proto tcp from any to any port = WWW keep state group 100
512
513   ------------------------------------------------------------------------
514 Return to the IP Filter home page
515 $FreeBSD: src/share/examples/ipfilter/examples.txt,v 1.1.2.1 2002/04/27 20:04:18 darrenr Exp $