How to use IP Tables ******************************************************************* *** IPTABLES TUTORIAL I. Definitions and similarities to ipchains II. Chain types and options III. Command line examples ******************************************************************* *** With the release of the 2.4 kernel, everyone who was used to using ipchains to configure their firewall will now be looking at iptables. In this newsletter, I'll go through the basics of how iptables is used. I. What Are These "Chains"? Just like its predecessor "ipchains", iptables uses a set of chain rules. The three default chains are named INPUT, OUTPUT, and FORWARD. A chain is just a simple checklist of rules and specifies what to do with each of the packets. The chain rules will either ACCEPT a packet or DROP a packet (note the "drop" syntax rather than "deny"). If the packet doesn't have anymore rules left in the chain, the system will consult the chain policy to decide what to do. Most systems are setup with a policy of deny. So if the packet doesn't match any rules that "allow" it through, then it will "drop" it. The first decision the kernel has to make upon receipt of a packet is "Where is the destination?" If the destination is for the box itself it will consult the rules for the INPUT chain. If the destination is for another network interface (and you have IP Forwarding enabled), the packet is compared against the FORWARD chain. As long as the packet gets an "ACCEPT" by one of the chain rules the packet will be forwarded on. If the linux box itself needs to send network packets, it will consult the OUTPUT chain and if the packet is ACCEPT-ed by one of the rules it will be sent out to the appropriate interface. One of the key concepts for people transitioning from ipchains is to realize that the INPUT and OUTPUT chains actually refer to the local machine rather than to all incoming and outgoing packets. Another point to consider is the use of "-o" to specify the interface. We used to use "-i" in ipchains to refer to the interface. In iptables "-i" is only used when referring to the incoming interface (so on the INPUT and FORWARD chains it is ok). So you are pretty much going to want to use "-o" where you used to use the "-i". This will refer to both the FORWARD and OUTPUT interface.
II. Chain types and options As I mentioned, you have three basic chains: INPUT OUTPUT FORWARD However, you can create your own chains by using: iptables -N The above will create a new chain. Here are some more options to manipulate your chains: -N Create a new chain -X Delete an EMPTY chain -P Change the Policy for a built-in chain -L Lists the chain rules -F Flushes the rules of a chain -Z Sets the counters to zero on all the rules in a chain III. Command line examples Now for some options you can use to configure rules inside your chains: -A Append a new rule -I Insert a new rule -R Replace a rule at a certain position -D Delete a rule at a certain position For example: iptables -A INPUT -p tcp -j ACCEPT This rule would accept all tcp traffic. This is a little to broad isn't it? Let's take a look at how we can specify some other options. Taking it one step further: -j Specify the target (--jump) -i Specify the input interface (--in-interface) -o Specify the output interface (--out-interface) -p Specify the protocol (--proto) -s Specify the source (--source) -d Specify the destination (--destination)! Specifies an inversion (match addresses NOT equal to) Now we are talking! Let's try it:
iptables -A FORWARD -s 192.168.1.0/24 -p tcp -j ACCEPT This rule will allow traffic to be forwarded, as long as the protocol was tcp, and the source was a machine on the 192.168.1.0 subnet Some useful tcp options: --sport Filters on the source port --dport Filters on the destination port This is handy. Let's try it out! This rule would allow traffic going to the www port (80) to be forwarded on. iptables -A FORWARD -p tcp --dport 80 -j ACCEPT Change destination addresses of web traffic to 5.6.7.8, port 8080. iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to 5.6.7.8:8080 --tcp-flags This allows you to filter on specific TCP flags. The first option after "--tcp-flags" specifies which flags are to be examined, and the second option specifies which flags are to be set. Here is an example of the --tcp-flags in use: iptables -A INPUT -p tcp --tcp-flags ALL SYN -j DENY Note: The list of possible flags is as follows SYN,ACK,FIN,RST,URG,PSH One of the other nice features is the ability to use the "! --syn" option. This is equivalent to typing: --tcp-flags SYN,RST,ACK SYN This would be useful in setting up your firewall to accept only connections that were initiated internally. Iptables Basics NHF Written By: Prince_Kenshi I'm sure many of you have been wondering how to use iptables to set up a basic firewall. I was wondering the same thing for a long time until I recently figured it out. I'll try to explain the basics to at least get you started. First you need to know how the firewall treats packets leaving, entering, or passing through your computer. Basically there is a chain for each of these. Any packet entering your computer goes through the INPUT chain. Any packet that your computer sends out
to the network goes through the OUTPUT chain. Any packet that your computer picks up on one network and sends to another goes through the FORWARD chain. The chains are half of the logic behind iptables themselves. Now the way that iptables works is that you set up certain rules in each of these chains that decide what happens to packets of data that pass through them. For instance, if your computer was to send out a packet to http://www.yahoo.com/ to request an HTML page, it would first pass through the OUTPUT chain. The kernel would look through the rules in the chain and see if any of them match. The first one that matches will decide the outcome of that packet. If none of the rules match, then the policy of the whole chain will be the final decision maker. Then whatever reply Yahoo! sent back would pass through the INPUT chain. It's no more complicated than that. Now that we have the basics out of the way, we can start working on putting all this to practical use. There are a lot of different letters to memorize when using iptables and you'll probably have to peek at the man page often to remind yourself of a certain one. Now let's start with manipulation of certain IP addresses. Suppose you wanted to block all packets coming from 200.200.200.1. First of all, -s is used to specify a source IP or DNS name. So from that, to refer to traffic coming from this address, we'd use this: iptables -s 200.200.200.1 But that doesn't tell what to do with the packets. The -j option is used to specify what happens to the packet. The most common three are ACCEPT, DENY, and DROP. Now you can probably figure out what ACCEPT does and it's not what we want. DENY sends a message back that this computer isn't accepting connections. DROP just totally ignores the packet. If we're really suspicious about this certain IP address, we'd probably prefer DROP over DENY. So here is the command with the result: iptables -s 200.200.200.1 -j DROP But the computer still won't understand this. There's one more thing we need to add and that's which chain it goes on. You use -A for this. It just appends the rule to the end of whichever chain you specify. Since we want to keep the computer from talking to us, we'd put it on INPUT. So here's the entire command: iptables -A INPUT -s 200.200.200.1 -j DROP This single command would ignore everything coming from 200.200.200.1 (with exceptions, but we'll get into that later). The order of the options doesn't matter; the -j DROP could go before -s 200.200.200.1. I just like to put the outcome part at the end of the command. Ok, we're now capable of ignoring a certain computer on a network. If you wanted to keep your computer from talking to it, you'd simply change INPUT to OUTPUT and change the -s to -d for destination. Now that's not too hard, is it?
So what if we only wanted to ignore telnet requests from this computer? Well that's not very hard either. You might know that port 23 is for telnet, but you can just use the word telnet if you like. There are at least 3 protocols that can be specified: TCP, UDP, and ICMP. Telnet, like most services, runs on TCP so we're going with it. The -p option specifies the protocol. But TCP doesn't tell it everything; telnet is only a specific protocol used on the larger protocol of TCP. After we specify that the protocol is TCP, we can use --destination-port to denote the port that they're trying to contact us on. Make sure you don't get source and destination ports mixed up. Remember, the client can run on any port, it's the server that will be running the service on port 23. Any time you want to block out a certain service, you'll use --destination-port. The opposite is --source-port in case you need it. So let's put this all together. This should be the command that accomplishes what we want: iptables -A INPUT -s 200.200.200.1 -p tcp --destination-port telnet -j DROP And there you go. If you wanted to specify a range of IP's, you could use 200.200.200.0/24. This would specify any IP that matched 200.200.200.*. Now it's time to fry some bigger fish. Let's say that, like me, you have a local area network and then you have a connection to the internet. We're going to also say that the LAN is eth0 while the internet connection is called ppp0. Now suppose we wanted to allow telnet to run as a service to computers on the LAN but not on the insecure internet. Well there is an easy way to do this. We can use -i for the input interface and -o for the output interface. You could always block it on the OUTPUT chain, but we'd rather block it on the INPUT so that the telnet daemon never even sees the request. Therefore we'll use -i. This should set up just the rule: iptables -A INPUT -p tcp --destination-port telnet -i ppp0 -j DROP So this should close off the port to anyone on the internet yet kept it open to the LAN. Now before we go on to more intense stuff, I'd like to briefly explain other ways to manipulate rules. The -A option appends a rule to the end of the list, meaning any matching rule before it will have say before this one does. If we wanted to put a rule before the end of the chain, we use -I for insert. This will put the rule in a numerical location in the chain. For example, if we wanted to put it at the top of the INPUT chain, we'd use "-I INPUT 1" along with the rest of the command. Just change the 1 to whatever place you want it to be in. Now let's say we wanted to replace whatever rule was already in that location. Just use -R to replace a rule. It has the same syntax as -I and works the same way except that it deletes the rule at that position rather than bumping everything down. And finally, if you just want to delete a rule, use -D. This also has a similar syntax but you can either use a number for the rule or type out all the options that you would if you created the rule. The number method is usually the optimal choice. There are two more simple options to learn though. -L lists all the rules set so far. This is obviously helpful when you forget where you're at. AND -F flushes a certain chain. (It removes all of the rules on the chain.) If you don't specify a chain, it will basically flush everything.
Well let's get a bit more advanced. We know that these packets use a certain protocol, and if that protocol is TCP, then it also uses a certain port. Now you might be compelled to just close all ports to incoming traffic, but remember, after your computer talks to another computer, that computer must talk back. If you close all of your incoming ports, you'll essentially render your connection useless. And for most non-service programs, you can't predict which port they're going to be communicating on. But there's still a way. Whenever two computers are talking over a TCP connection, that connection must first be initialized. This is the job of a SYN packet. A SYN packet simply tells the other computer that it's ready to talk. Now only the computer requesting the service sends a SYN packet. So if you only block incoming SYN packets, it stops other computers from opening services on your computer but doesn't stop you from communicating with them. It roughly makes your computer ignore anything that it didn't speak to first. It's mean but it gets the job done. Well the option for this is --syn after you've specified the TCP protocol. So to make a rule that would block all incoming connections on only the internet: iptables -A INPUT -i ppp0 -p tcp --syn -j DROP That's a likely rule that you'll be using unless you have a web service running. If you want to leave one port open, for example 80 (HTTP), there's a simple way to do this too. As with many programming languages, an exclamation mark means not. For instance, if you wanted to block all SYN packets on all ports except 80, I believe it would look something like this: iptables -A INPUT -i ppp0 -p tcp --syn --destination-port! 80 -j DROP It's somewhat complicated but it's not so hard to comprehend. There's one last thing I'd like to cover and that's changing the policy for a chain. The chains INPUT and OUTPUT are usually set to ACCEPT by default and FORWARD is set to DENY. Well if you want to use this computer as a router, you would probably want to set the FORWARD policy to ACCEPT. How do we do this you ask? Well it's really very simple. All you have to do is use the -P option. Just follow it by the chain name and the new policy and you have it made. To change the FORWARD chain to an ACCEPT policy, we'd do this: iptables -P FORWARD ACCEPT Nothing to it, huh? This is really just the basics of iptables. It should help you set up a limited firewall but there's still a lot more that I couldn't talk about. You can look at the man page "man iptables" to learn more of the options (or refresh your memory when you forget). You can find more advanced documents if you want to learn some of the more advanced features of iptables. At the time of this writing, iptables documents are somewhat rare because the technology is new but they should be springing up soon. Good luck.
Netfilter Log Format Here is a quick reference for the format used by the netfilter log messages. This is all derived from the source of the netfilter kernel modules (Linux kernel 2.4.2). Below is a hypothetical log message generated by netfilter. It is based on a real log entry but I have added all possible IP and TCP flags as well as a fragment offset for illustrative purposes. Note: If you want to cut-n-paste this into the Netfilter Log Analyzer, then you will have to edit out the fragment offset or set it to zero. Apr 16 00:30:45 megahard kernel: NF: D(I,Priv) IN=eth1 OUT= MAC=00:80:8c:1e:12:60:00:10:76:00:2f:c2:08:00 SRC=211.251.142.65 DST=203.164.4.223 LEN=60 TOS=0x00 PREC=0x00 TTL=44 ID=31526 CE DF MF FRAG=179 OPT (072728CBA404DFCBA40253CBA4032ECBA403A2CBA4033ECBA40 2C1180746EA18074C52892734A200) PROTO=TCP SPT=4515 DPT=111 SEQ=1168094040 ACK=0 WINDOW=32120 RES=0x03 URG ACK PSH RST SYN FIN URGP=0 OPT (020405B40402080A05E3F3C40000000001030300) The items are explained in sequence: Apr 16 00:30:45 syslog prefix. It is not present if you read log messages megahard kernel: from the console. NF: D(I,Priv) Enabled with: --log-prefix 'prefix' An arbitrary, user defined log prefix. Including the spaces. A trailing space is necessary to keep the prefix separate from the next token; this is a bug in netfilter. IN=eth1 OUT= MAC= 00:80:8c:1e:12:60: 00:10:76:00:2f:c2: 08:00 SRC=211.251.142.65 Source IP address Interface the packet was received from. Empty value for locally generated packets. Interface the packet was sent to. Empty value for locally received packets. Destination MAC=00:80:8c:1e:12:60, Source MAC=00:10:76:00:2f:c2, Type=08:00 (ethernet frame carried an IPv4 datagram) DST=203.164.4.223 Destination IP address LEN=60 TOS=0x00 Total length of IP packet in bytes Type Of Service, "Type" field. Increasingly being replaced by DS and ECN. Refer to the IP header info below.
PREC=0x00 TTL=44 ID=31526 CE DF MF FRAG=179 OPT (0727..A200) PROTO=TCP SPT=4515 DPT=111 SEQ=1168094040 ACK=0 WINDOW=32120 RES=0x03 Type Of Service, "Precedence" field. Increasingly being replaced by DS and ECN. Refer to the IP header info below. remaining Time To Live is 44 hops. Unique ID for this IP datagram, shared by all fragments if fragmented. Presumably the "ECN CE" flag (Congestion Experienced). This seems to be wrong because according to RFC2481, the CE bit is located in the TOS field. Refer to the IP header info below. "Don't Fragment" flag. "More Fragments following" flag. Fragment offset in units of "8-bytes". In this case the byte offset for data in this packet is 179*8=1432 bytes. Enabled with: --log-ip-options IP options. This variable length field is rarely used. Certain IP options, f.e. source routing, are often disallowed by netadmins. Even harmless options like "Record Route" may only be allowed if the transport protocol is ICMP, or not at all. Protocol name or number. Netfilter uses names for TCP, UDP, ICMP, AH and ESP. Other protocols are identified by number. A list is in your /etc/protocols. A complete list is in the file protocol-numbers Source port (TCP and UDP). A list of port numbers is in your /etc/services. A complete list is in the file port-numbers Destination port (TCP and UDP). See SPT above. Enabled with: --log-tcp-sequence Receive Sequence number. By cleverly chosing this number, a cryptographic "cookie" can be implemented while still satisfying TCP protocol requirements. These "SYN-cookies" defeat some types of SYN-flooding DoS attacks and should be enabled on all systems running public TCP servers. echo 1 > /proc/sys/net/ipv4/tcp_syncookies Same as the Receive Sequence number, but for the other end of the TCP connection. The TCP Receive Window size. This may be scaled by bitshifting left by a number of bits specified in the "Window Scale" TCP option. If the host supports ECN, then the TCP Receive Window size will also be controlled by that. Reserved bits. The ECN flags "CWR" and "ECNE" will
URG ACK PSH RST SYN FIN URGP=0 show up in the two least significant bits of this field. Refer to the TCP header info below. Urgent flag. See URGP below. Acknowledgement flag. Push flag. RST (Reset) flag. SYN flag, only exchanged at TCP connection establishment. FIN flag, only exchanged at TCP disconnection. The Urgent Pointer allows for urgent, "out of band" data transfer. Unfortunately not all protocol implementations agree, so this facility is hardly ever used. OPT (020405...300) enabled with: --log-tcp-options TCP options. This variable length field gets a lot of use. Important options include: Window Scaling, Selective Acknowledgement and Explicit Congestion Notification. Refer to the TCP header info below. Unfortunately the rule number in the chain which matched the packet is for architectural reasons not available in netfilter logs. You will have to "cook your own" by using the user-prefix feature. Issues with netfilter log format Also suggests an alternative log format. The ULOG module looks like a suitable future remedy. Protocol Header Information IP Header Format as defined in RFC-791: 0 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 IP Hdr.Length TOS / DS,ECN Total Length Version Identification - DF MF Fragment Offset Time To Live Protocol Number Header Checksum
The header of an IP packet consists of 5 or more words of 32 bits (4 bytes) each. The minimum header length (no options) is therefore 20 bytes. The Version field for the shown type of packet is 4 = IPv4 (Internet Protocol version 4). The header Length field is the header length in 32bit words, this would be 5 without options, and at most 15 with options. The Total Length is in bytes and includes the 32 bit Source Address 32 bit Destination Address Options (0 to 10 Words of 32 Bits) IP Payload (including header of heigher protocol)
header. Data length can then be calculated from the supplied values. TOS / DS / ECN: This field has had an unstable 0 1 2 34 5 6 7 history. This is briefly explained in RFC2481, TOS Precedence Type - section 19 (near the end). DS,ECN DS Codepoint ECT CE Many sites are starting to implement Differentiated Services DS [RFC2474] in their routers. DS uses codepoints which are stored in bits 0 to 5 of the old TOS field. The content and meaning of this field can change at network boundaries. If the host is ECN [RFC2481] capable and the payload is a TCP packet, then up to two flag bits will be needed in the old TOS field. Bit 6 becomes the ECT (ECN-capable Transport) flag, and Bit 7 becomes the CE (Congestion Experienced) flag. IP datagrams can be fragmented if the link layer cannot fit it into a single link layer data unit. The fragment offset is specified in units of 8-bytes, thus allowing the available 13 bits to cover the necessary values for up to 64K of data. IP packets usually carry a higher level protocol such as TCP. In the case of TCP, the PROTO field would be set to 6 and the TCP Protocol Data Unit (PDU) is carried in the IP Payload field of the packet. See below. TCP Header Format (as defined in RFC-793): 0 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 Source Port Destination Port Sequence Number Acknowledgement Number Data Offset - - - - Window Checksum Urgent Pointer Options (0 to 10 Words of 32 Bits) TCP Payload The header of a TCP packet consists of 5 or more words of 32 bits (4 bytes) each. The minimum header length (no options) is therefore 20 bytes. The Data Offset field is the header length in 32bit words, this would be 5 without options, and at most 15 with options.
Explicit Congestion Notification (ECN) [RFC2481] adds 2 new flags to the TCP header: Congestion Window Reduced (CWR) and ECN-Echo (ECNE). ECN also requires 1 or 2 additional flags in the IP header. Commonly, the TCP header will carry options related to enhancements of the TCP protocol. Important options are Window Scaling, Selective Acknowledgement (SACK) [RFC2018, RFC2883] and Explicit Congestion Notification (ECN) [RFC2481]. TCP data payload length is the IP payload length minus the TCP header length. TCP packets usually carry an application level data stream, f.e. HTTP, FTP, Telnet, SSH, etc. UDP Header format (as defined in RFC-768): 0 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 Source Port Destination Port Total Length Checksum (optional) UDP Payload The header of a UDP packet consists of 2 words of 32 bits (4 bytes) each. The header length is therefore always 8 bytes. The Total Length field includes the UDP header and is measured in bytes. UDP packets usually carry an application level datagram as their payload, f.e. DNS, NTP, NFS, etc. Commands to see which ports are in use on your (Linux) system: lsof -i netstat -tupan rpcinfo -p You need to be root to get the full information