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