www.netfilter.org/ipchains/HOWTO-4.html -> people.netfilter.org/%7Erusty/ipchains/HOWTO-4.html
When a packet comes in say, through the Ethernet card the kernel uses the input chain to decide its fate. If it survives that step, then the kernel decides where to send the packet next this is called routing . If it is destined for another machine, it consults the forward chain. Finally, just before a packet is to go out, the kernel consults the output chain. Each rule says if the packet header looks like this, then heres what to do with the packet. If the rule doesnt match the packet, then the next rule in the chain is consulted. Finally, if there are no more rules to consult, then the kernel looks at the chain policy to decide what to do. In a security-conscious system, this policy usually tells the kernel to reject or deny the packet. For ASCII-art fans, this shown the complete path of a packet coming into a machine.
If the verdict of the chain is not DENY or REJECT , the packet continues on. Demasquerade: If the packet is a reply to a previously masqueraded packet, it is demasqueraded, and skips straight to the output chain. If you dont use IP Masquerading, you can mentally erase this from the diagram. Routing decision: The destination field is examined by the routing code, to decide if this packet should go to a local process see Local process below or forwarded to a remote machine see forward chain below. Local process: A process running on the machine can receive packets after the Routing Decision step, and can send packets which go through the Routing Decision step, then traverse the output chain.
The final and perhaps the most useful function allows you to check what would happen to a given packet if it were to traverse a given chain. What Youll See When Your Computer Starts Up Before any ipchains commands have been run be careful: some distributions run ipchains in their initialization scripts, there will be no rules in any of the built-in chains input, forward and output, and each of the chains will have a policy of ACCEPT. Operations on a Single Rule This is the bread-and-butter of ipchains;
There will be a pause before the program gives up waiting for a response that will never come. Firstly, since we know that it is the only rule in the input chain, we can use a numbered delete, as in: ipchains -D input 1 To delete rule number 1 in the input chain. The second way is to mirror the -A command, but replacing the -A with -D. This is useful when you have a complex chain of rules and you dont want to have to count them to figure out that its rule 37 that you want to get rid of.
If there are multiple identical rules in the same chain, only the first will be deleted. Filtering Specifications We have seen the use of -p to specify protocol, and -s to specify source address, but there are other options we can use to specify packet characteristics. Specifying Source and Destination IP Addresses Source -s and destination -d IP addresses can be specified in four ways.
You can specify them as ICMP names use ipchains -h icmp to list the names after the -s option, or as a numeric ICMP type and code, where the type follows the -s option and the code follows the -d option. The ICMP names are fairly long: you only need use enough letters to make the name distinct from any other. Here is a small table of some of the most common ICMP packets: Number Name Required by 0 echo-reply ping 3 destination-unreachable Any TCP/UDP traffic.
Specifying TCP SYN Packets Only It is sometimes useful to allow TCP connections in one direction, but not the other. For example, you might want to allow connections to an external WWW server, but not connections from that server. The naive approach would be to block TCP packets coming from the server. Unfortunately, TCP connections require packets going in both directions to work at all. The solution is to block only the packets used to request a connection. These packets are called SYN packets ok, technically theyre packets with the SYN flag set, and the FIN and ACK flags cleared, but we call them SYN packets. By disallowing only these packets, we can stop attempted connections in their tracks. The -y flag is used for this: it is only valid for rules which specify TCP as their protocol.
Handling Fragments Sometimes a packet is too large to fit down a wire all at once. When this happens, the packet is divided into fragments , and sent as multiple packets. The other end reassembles the fragments to reconstruct the whole packet. The problem with fragments is that some of the specifications listed above in particular, source port, destinations port, ICMP type, ICMP code, or TCP SYN flag require the kernel to peek at the start of the packet, which is only contained in the first fragment. If your machine is the only connection to an external network, then you can tell the Linux kernel to reassemble all fragments which pass through it, by compiling the kernel with IP: always defragment set to Y. Otherwise, it is important to understand how fragments get treated by the filtering rules. Any filtering rule that asks for information we dont have will not match. This means that the first fragment is treated like any other packet.
Usually it is regarded as safe to let second and further fragments through, since filtering will effect the first fragment, and thus prevent reassembly on the target host, however, bugs have been known to allow crashing of machines simply by sending fragments. Note for network-heads: malformed packets TCP, UDP and ICMP packets too short for the firewalling code to read the ports or ICMP code and type are treated as fragments as well. Only TCP fragments starting at position 8 are explicitly dropped by the firewall code a message should appear in the syslog if this occurs.
If a packet matches a rule, the following things happen: The byte counter for that rule is increased by the size of the packet header and all. If the rule requests it, the packets Type Of Service field is changed. If the rule requests it, the packet is marked not in 20 kernel series. The rule target is examined to decide what to do to the packet next. Specifying a Target A target tells the kernel what to do with a packet that matches a rule.
REJECT drops the packet, but if its not an ICMP packet generates an ICMP reply to the source to tell it that the destination was unreachable. For this to work, your kernel needs to be compiled with IP Masquerading enabled. For details on this, see the Masquerading-HOWTO and the Appendix Differences between ipchains and ipfwadm . This target is only valid for packets traversing the forward chain. The other major special target is REDIRECT which tells the kernel to send a packet to a local port instead of wherever it was heading. This can only be specified for rules specifying TCP or UDP as their protocol. Optionally, a port name or number can be specified following -j REDIRECT which will cause the packet to be redirected to that particular port, even if it was addressed to another port. The final special target is RETURN which is identical to falling off the end of the chain immediately. Any other target indicates a user-defined chain as described in Operations on an Entire Chain below. If that chain doesnt decide the fate of the packet, then once traversal on that chain has finished, traversal resumes on the next rule in the current chain. Consider two silly chains: input the built-in chain and Test a user-defined chain.
Rule2 matches, and its target is Test , so the next rule examined is the start of Test . Rule1 in Test matches, but doesnt specify a target, so the next rule is examined, Rule2. We return to the input chain, where we had just examined Rule2, so we now examine Rule3, which doesnt match either. So the packet path is: v __________________________ input / Test v --/ -- Rule1 / Rule1 -/- -- Rule2 / Rule2 - -v- Rule3 /-___________________________/ -- v See the section How to Organise Your Firewall Rules for ways to use user-defined chains effectively. Logging Packets This is a side effect that matching a rule can have;
Rob van Nieuwkerk, the author of the TOS-mangling code, puts it as follows: Especially the Minimum Delay is important for me. I switch it on for interactive packets in ...
|
http://csua.com/feed/