• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

ipfw

ipfw

ipfw Controlling utility for IP firewall.
ipfw [-q] [-p <preproc> [-D <macro>[=<value>]] [-U
									<macro>] <file>

ipfw [-f | -q] flush

ipfw [-q] zero [<number> ...]

ipfw delete <number> ...

ipfw [-aftN] list [<number>...]

ipfw [-ftN] show [<number>...]

ipfw [-q] add [<number>] <action> [log] <proto>
								from <src> to <dst>
[via <name> | <ipno>] [<options>]

If used as shown in the first line, a <file> is read line by line and applied as arguments to ipfw.
A preprocessor can be specified using -p <preproc> where <file> is to be piped through. Typical preprocessors include m4 and cpp. Optional -D and -U macro specification can be given to pass on to the preprocessor.
Each incoming and outgoing packet is sent through the ipfw rules. In the case of a host acting as a gateway, packets that are forwarded by the host are processed twice: once when entering and once when leaving. Each packet can be filtered based on the following associated information:
Receive Interface (recv) Interface over which packet was received.
Transmit Interface (xmit) Interface over which packet would be transmitted.
Incoming (in) Packet was just received.
Outgoing (out) Packet would be transmitted.
Source IP Address Sender's IP address.
Destination IP Address Target's IP address.
Protocol IP protocol, including but not limited to IP (ip), UDP (udp), TCP (tcp), or ICMP (icmp).
Source Port Sender's UDP or TCP port.
Destination Port Target's UDP or TCP port.
Connection Setup Flag (setup) Packet is a request to set up a TCP connection.
Connection Established Flag (established) Packet is part of an established TCP connection.
All TCP Flags (tcpflags) One or more of the TCP flags: close connection (fin), open connection (syn), reset connection (rst), push (psh), acknowledgement (ack), urgent (urg).
Fragment Flag (frag) Packet is a fragment of an IP packet.
IP Options (ipoptions) One or more IP options: strict source route (ssrr), loose source route (lsrr)), record route (rr), timestamp (ts).
ICMP Types (icmptypes) One or more of the ICMP types: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17), address mask reply (18).
Note that it could be dangerous to filter on source IP address or source TCP/UDP port because either or both could be spoofed.
The ipfw utility works by going through the rule list for each packet until a match is found. All rules have two associated counters: a packet count and a byte count. These are updated when a packet matches the rule.
Rules are ordered by line number, from 1 to 65534. Rules are tried in increasing order, with the first matching rule being the one that applies. Multiple rules may have the same number and are applied in the order they were added.
If a rule is added without a number, it is numbered 100 higher than the highest defined rule number, unless the highest rule number is 65435 or greater, in which case the new rules are given that same number.
One rule is always present: 65535 deny all from any to any.
This rule, not to allow anything, is the default policy.
If the kernel option IPFIREWALL_DEFAULT_TO_ACCEPT has been enabled, the default rule is 65535 allow all from any to any.
The preceding rule is the default rule in OS X.
add Adds a rule.
delete Deletes the first rule with number <number>, if any.
list Prints out the current rule set.
show Equivalent to ipfw -a list.
zero Zeroes the counters associated with rule number <number>.
flush Removes all rules.
The following options are available:
-q Uses quiet mode when adding, flushing, or zeroing (Implies -f). Useful for adjusting rules by executing multiple ipfw commands in a script.
-f Does not ask for confirmation for commands that can cause problems if misused (for example, flush).
-a Shows counter values while listing. See also show.
-t Shows last match timestamp while listing.
-N Tries to resolve addresses and service names in output.
Available options for <action>:
allow Allows packets that match rule. The search terminates. Aliases are accept.q, pass, and permit.
deny Alias is drop.Discards packets that match rule. The search terminates.
reject (Deprecated) Discards packets that match rule, and tries to send an ICMP host unreachable notice. The search terminates.
unreach <code> Discards packets that match rule, and tries to send an ICMP unreachable notice with code <code>, where <code> is a number from 0 to 255, or one of these aliases: net, host, protocol, port, needfrag, srcfail, net-unknown, host-unknown, isolated, net-prohib, host-prohib, tosnet, toshost, filter-prohib, host-precedence, precedence-cutoff. The search terminates.
reset TCP packets only. Discards packets that match rule, and tries to send a TCP reset (RST) notice. The search terminates.
count Updates counters for all packets that match rule. The search continues with the next rule.
divert <port> Diverts packets that match rule to divert (4) socket bound to port <port>. The search terminates.
tee <port> Sends a copy of packets matching rule to the divert (4) socket bound to port <port>. The search terminates.
fwd <ipaddr> [,<port>] Changes to the next hop on matching packets to <ipaddr>, which can be a dotted quad address or hostname. If <ipaddr> is not directly reachable, the route as found in the local routing table for that IP address is used instead. If <ipaddr> is a local address, when a packet enters the system from a remote host, it is diverted to <port> on the local machine, keeping the local address of the socket set to the original IP address for which the packet was destined. This is intended for use with transparent proxy servers. If <ipaddr> is not a local address, then <port>, if specified, is ignored, and the rule applies only to packets leaving the system. If <port> is not given, the port in the packet is used instead. The kernel must have been compiled with option IPFIREWALL_FORWARD.
skipto <number> Skips all subsequent rules numbered less than <number>. The search continues with the first rule numbered <number> or higher.
If a packet matches more than one divert and/or tee rule, all but the last are ignored.
If the kernel was compiled with IPFIREWALL_VERBOSE, when a packet matches a rule with the log keyword, a message is printed on the console. If the kernel was compiled with IPFIREWALL_VERBOSE_LIMIT, logging ceases after the number of packets specified by the option is received for that particular entry. Logging can then be reenabled by clearing the packet counter for that entry.
Console logging and the log limit are adjustable dynamically through the sysctl (8) interface.
Available options for <proto> are
ip Matches all packets. The same as the alias all.
tcp Matches only TCP packets.
udp Matches only UDP packets.
icmp Matches only ICMP packets.
<number|name> Matches only packets for the specified protocol. See /etc/protocols for a complete list.
<src> and <dst> have the form:
									<address/mask> [<ports>]

 
<address/mask> may be specified as
ipno Has the form 1.2.3.4—only this exact number matches the rule.
ipno/bits Has the form 1.2.3.4/24—in this case, all IP numbers from 1.2.3.0 to 1.2.3.255 match.
ipno:mask Has the form 1.2.3.4:255.255.240.0—in this case, all IP numbers from 1.2.0.0 to 1.2.15.255 match.
The sense of match can be inverted by preceding an address with the not modifier, causing all other addresses to match instead. This does not affect the selection of port numbers.
Rules can apply to packets when they are incoming or outgoing or both. The keyword in indicates that the rule should match only incoming packets. The keyword out indicates that the rule should match only outgoing packets.
To match packets going through a certain interface, specify the interface with via.
via <ifX> Matches packets going through the interface <ifX>.
via <if*> Matches packets going through the interface <if*>, where * is any unit.
via any Matches packets going through some interface.
via ipno Matches packets going through the interface having the IP address <ipno>.
The keyword via causes the interface to always be checked. If recv or xmit is used instead, only the receive or transmit interface (respectively) is checked. By specifying both, it is possible to match packets based on both receive and transmit interfaces. For example:
ipfw add 100 deny ip from any to any out recv en0 xmit en1

The recv interface can be tested on either incoming or outgoing packets, whereas the xmit interface can be tested only on outgoing packets. So, out is required (and in is invalid) whenever xmit is used. Specifying via together with xmit or recv is invalid.
Options available for <options>:
frag Matches if the packet is a fragment and it is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications.
in Matches if the packet was on the way in.
out Matches if the packet was on the way out.
ipoptions <spec> Matches if the IP header contains the comma-separated list of options specified in <spec>. The supported IP options are ssrr (strict source route), lsrr (loose source route), rr (record packet route), and ts (timestamp). The absence of a particular option may be denoted with a !.
established TCP packets only. Matches packets that have the RST or ACK bits set.
setup TCP packets only. Matches packets that have the SYN bit set but no ACK bit.
tcpflags <spec> Matches if the TCP header contains the comma-separated list of flags specified in <spec>. The supported TCP flags are fin, syn, rst, psh, ack, and urg. The absence of a particular flag may be denoted by a !. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset.
icmptypes <types> Matches if the ICMP type is in the list <types>. The list may be specified as any combination of ranges or individual types separated by commas.
Important points to consider when designing your rules:
Remember that you filter both packets going in and out. Most connections need packets going in both directions.
Remember to test very carefully. It is a good idea to be at the console at the time.
Don't forget the loopback interface.



PREVIEW

                                                                          

Not a subscriber?

Start A Free Trial


  
  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint