Iptables: Leroy D. Cressy V 0.04 May 15, 2004
Iptables: Leroy D. Cressy V 0.04 May 15, 2004
Iptables: Leroy D. Cressy V 0.04 May 15, 2004
Copyright c 2004 LeRoy D. Cressy Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. Editors: Rita J. Cressy Sibylla C. Cressy
Contents
1 Introduction 1.1 Other Sources of Information . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Debian Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 What Firewalls Will Not Prevent . . . . . . . . . . . . . . . . . . . . . . . . 1.4 What rewalls are capable of doing . . . . . . . . . . . . . . . . . . . . . . 2 Patching Your Kernel Source Code 2.1 Using Patch-O-Matic 3 Compiling the Kernel 4 Iptables 4.1 Default Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 2 4 5 5 5 7 8 9
1 INTRODUCTION
5.1 Packet Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6 Writing a Firewall Script 7 GNU Free Documentation License 21 23
7.1 APPLICABILITY AND DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . 23 7.2 VERBATIM COPYING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.3 COPYING IN QUANTITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.4 MODIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.5 COMBINING DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.6 COLLECTIONS OF DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . 28 7.7 AGGREGATION WITH INDEPENDENT WORKS . . . . . . . . . . . . . . . 28 7.8 TRANSLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.9 TERMINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.10 FUTURE REVISIONS OF THIS LICENSE . . . . . . . . . . . . . . . . . . . 29
1 Introduction
1.1 Other Sources of Information
http://iptables-tutorial.frozentux.net/iptables-tutorial.html This is an excellent tutorial that goes a lot deeper than this hour-long talk. http://www.netlter.org/documentation/ This is the site where you will nd information on every aspect of iptables in various languages.
1 INTRODUCTION
ipmenu A cursel iptables/iproute2 GUI kernelpatchttl TTL matching and setting acidlab Analysis Console for Intrusion Databases arptables ARP table administration ebtables Ethernet bridge frame table administration ferm maintain and setup complicated rewall rules aif An easy to use, yet complex rewall ltergen packet lter generator for various rewall systems reierclientgtk Interactive rewall rule creation tool GTK client reierclientqt Interactive rewall rule creation tool QT client reierserver Interactive rewall rule creation tool server rehol An easy to use but powerful iptables stateful rewall rewalleasy Easy to use packet lter rewall (usually zero cong) fwanalog iptables logle report generator (using analog) fwbuildeript Linux iptables policy compiler for Firewall Builder fwbuilderiptables Linux iptables policy compiler for Firewall Builder fwlogwatch Firewall log analyzer
gnomelokkit basic interactive rewall conguration tool (GNOME interface) guarddog rewall conguration utility for KDE guidedog NAT/masquerading/port-forwarding conguration tool for KDE ipac IP accounting conguration and statistics tool ipacng IP Accounting for iptables( kernel 2.4) iptables IP packet lter administration tools for 2.4.xx kernels iptablesdev development les for iptables libipq and libiptc iptstate Toplike state for netlter/iptables kernelpatchulog Netlter userspace logging patch. knetlter A GUI for conguring the 2.4 kernel IP Tables lokkit basic interactive rewall conguration tool (console interface) netstatnat A tool that display NAT connections
1 INTRODUCTION
psad The Port Scan Attack Detector reaim Enable AIM and MSN le transfer on Linux iptables based NAT shorewall Shoreline Firewall (Shorewall) shorewalldoc Shoreline Firewall (Shorewall) Documentation uif Advanced iptables-rewall script ulogd The Netlter Userspace Logging Daemon webminrewall iptables control module for webmin wogs The modular rewall log analyzer of the WallFire project
As you can see there are a plethora of packages available for those who dont want to or care to write a script themselves. Some of these packages can be used as a guide for writing you own script rules. With all of the packages that are available why would you want to write your own script? My reason is that when I rst started using iptables there wasnt a decent script available, and now I am just maintaining the rewall script that is several years old and still blocks most of the stuff that I dont want to come through on my network.
After unpacking the tarball read the README le and block the line: KERNEL_DIR=<<where-you-built-your-kernel>> ./runme pending
Paste it into an xterm editing the place where your kernel source code is located as indicated. KERNEL_DIR=/usr/local/src/linux/v2.4/linux-2.4.23 ./runme pending
Before you run this script you should have a backup of your kernel source or the original tarball. This script changes the kernel source code. As you run the script you will notice that there are numerous patches already installed. As of December 31, 2003, patch-o-matic does not work with the 2.6.0 kernel. Heed the warning about not applying all of the patches. After running pending, you can run base and extra portions of patch-o-matic. The problem with the 2.6.x kernel is that the subdirectory cong les have changed from Cong and Cong.help to Kcong which produces the following error. Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] y Testing patch submitted/01_2.4.19.patch... Warning - no help text file could be found in either /usr/local/src/linux/v2.6/linux-2.6.0/net/ipv4/netfilter/Config.help or /usr/local/src/linux/v2.6/linux-2.6.0/Documentation/Configure.help Failed to patch copy of /usr/local/src/linux/v2.6/linux-2.6.0
There is a patch-o-matic converter at http://www.stearns.org/pom26convert/ along with others that are in testing. Hopefully, one of these will be on the netlter site in the near future.
One of the nice things is that the help is always displayed at the bottom of the window instead of having to click on the help button. The key strokes of using y, m, or n are the same as in the past. Of course you still use menucong for a text based conguration. With all of the patches that you have added to the kernel along with what is already part of the kernel source code there are a lot of options that you can put into your rewall kernel. Another item to consider for rewalls is not using modules. Though it has not happened yet, there is a possibility that someone could write a
4 IPTABLES
module that would infect a running kernel. With module support turned off I feel that the potential of this happening is eliminated. If you are using one of the pre made iptables scripts, run the script by hand to make sure that all options that the script requires are compiled in your kernel. If you get any error messages from running the script then you need to remake the kernel. I have never used one of these packages, but it is possible that the standard kernel does not have all of the netlter patches that the iptables script requires. Personally, I will stick with the 2.4 kernel for a rewall until 2.6 becomes rock solid. Presently, I have one machine that I am testing with the 2.6 kernel and there seems to be some problems. Already 2.6.0 has been patched with some serious security xes. If you want to use the cryptography features in the kernel, I would suggest using the 2.6 kernel.
4 Iptables
Here we come to the interesting portion of the creation of a rewall. We have patched and compiled a custom kernel with all of the drivers included for our specic hardware along with all of the netlter items that we think we will need included in the kernel. A iptables rewall script is a shell script that is run as a system startup script usually located in /etc/init.d/. Depending on the distribution that you are using there will be a symbolic link in /etc/rc2.d/ or whatever the default runtime is specied in /etc/inittab. Since we are creating a shell script it is wise to create several variables at the beginning of the script like: Real IP Address Internet eth DMZ eth LAN eth LAN network DMZ network Cong le You can use these variables to make your code portable for numerous machines making your life easier. RealIP="66.92.109.218" Internet="eth0" DMZ="eth1" LAN="eth2" conf="/usr/local/etc/firewall.conf"
4 IPTABLES
As you can see you have the option of either setting up and parsing a cong le or by having the variables directly in the script. You as the author of this script should decide on what method you want to use. There are some security concerns that you might want to consider in creating your script. For instance, do you want the Ethernet card that is connected to the Internet to be up? Couldnt this lead to an attack against the system prior to the completion of the shell script? Or as part of the shell script we drop all packets from the Internet opening up the ports one at a time as the shell script runs. The choice is yours, but I would not accept any packets from the Internet until I am ready. One of the problems with either dropping all packets or running ifdown on the various Ethernet cards would be with remote administration. Lets say if you are about 100 miles away from the box that you are running your script on and there is a bug in the script which causes the system to hang or not bring up the Internet connection you are out of luck. So please use a little caution and thought on the creation of your script. Another concern is that you should severely limit who and where can log in to the rewall via ssh. Also, I like all packets from the Internet to be either forwarded via NAT or dropped. Nothing from the Internet should have direct access to the rewall. This includes yourself. I realize that this makes it a little harder for you to remote administer the box in question, but if you are selling a secure rewall to a client you want it to be as secure as possible. I port forward all ssh connections from the Internet to a box on the DMZ network. The more restrictive that you can make your system the better it will be for your client. Since last year the netlter code has grown, so there are more options and targets that you can use. One of the newer targets is TARPIT where the packets gets stuck in a TARPIT instead of just dropping the packet. There are more matches now along with various states for a more robust stateful rewall.
4 IPTABLES
10
4 IPTABLES
11
DNAT Destination NAT which changes the destination address of a packet. Suppose your Apache web server is behind a rewall on a private network. You only have one real IP address and all of your other boxes are on a private network. iptables -t nat -A PREROUTING -j DNAT --to 192.168.10.1 -i eth0 -p tcp --dport 80 \
REDIRECT REDIRECT is a special case of NAT: all incoming connections are mapped onto the incoming interfaces address, causing the packets to come to the local machine instead of passing through. This is useful for transparent proxies. NETMAP NETMAP is an implementation of static 1:1 NAT mapping of network addresses. It maps the network address part, while keeping the host address part intact. It is similar to Fast NAT, except that Netlters connection tracking doesnt work well with Fast NAT. SAME This option adds a SAME target, which works like the standard SNAT target, but attempts to give clients the same IP for all connections. TOS This option adds a TOS target, which allows you to create rules in the mangle table which alter the Type Of Service eld of an IP packet prior to routing. ECN This option adds a ECN target, which can be used in the iptables mangle table. You can use this target to remove the ECN bits from the IPv4 header of an IP packet. This is particularly useful, if you need to work around existing ECN blackholes on the internet, but dont want to disable ECN support in general. DSCP This option adds a DSCP match, which allows you to match against the IPv4 header DSCP eld (DSCP codepoint). The DSCP codepoint can have any value between 0x0 and 0x4f. MARK This option adds a MARK target, which allows you to create rules in the mangle table which alter the netlter mark (nfmark) eld associated with the packet prior to routing. This can change the routing method (see Use netlter MARK value as routing key) and can also be used by other subsystems to change their behavior. CLASSIFY This option adds a CLASSIFY target, which enables the user to set the priority of a packet. Some qdiscs can use this value for classication, among these are: atm, cbq, dsmark, pfo fast, htb, prio
4 IPTABLES
12
TCPMSS This option adds a TCPMSS target, which allows you to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interfaces MTU minus 40). This is used to overcome criminally braindead ISPs or servers which block ICMP Fragmentation Needed packets. The symptoms of this problem are that everything works ne from your Linux rewall/router, but machines behind it can never exchange large packets: 1) Web browsers connect, then hang with no data received. 2) Small mail works ne, but large emails hang. 3) ssh works ne, but scp hangs after initial handshaking. Workaround: activate this option and add a rule to your rewall conguration like: iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu \
4 IPTABLES
13
TOS TOS matching allows you to match packets based on the Type Of Service elds of the IP packet. Recent This match is used for creating one or many lists of recently used addresses and then matching against that/those list(s). Short options are available by using iptables -m recent -h Ofcial Website: http://snowman.net/projects/ipt recent/ Ecn This option adds a ECN match, which allows you to match against the IPv4 and TCP header ECN elds. DSCP This option adds a DSCP match, which allows you to match against the IPv4 header DSCP eld (DSCP codepoint). The DSCP codepoint can have any value between 0x0 and 0x4f. AH/ESP These two match extensions (ah and esp) allow you to match a range of SPIs inside AH or ESP headers of IPSec packets. Length This option allows you to match the length of a packet against a specic value or range of values. TTL This adds CONFIG IP NF MATCH TTL option, which enabled the user to match packets by their TTL value. Tcpmss This option adds a tcpmss match, which allows you to examine the MSS value of TCP SYN packets, which control the maximum packet size for that connection. Helper Helper matching allows you to match packets in dynamic connections tracked by a conntrack-helper, ie. ip conntrack ftp Connection State Connection state matching allows you to match packets based on their relationship to a tracked connection (ie. previous packets). This is a powerful tool for packet classication. Connection Tracking This is a general conntrack match module, a superset of the state match. It allows matching on additional conntrack information, which is useful in complex congurations, such as NAT gateways with multiple internet links or tunnels.
4 IPTABLES
14
Owner Packet owner matching allows you to match locally-generated packets based on who created them: the user, group, process or session.
The only options that I use normally outside of a script is: L, list List all rules in the selected chain. If no chain is selected, all chains are listed. It is legal to specify the -Z (zero) option as well, in which case the chain(s) will be atomically listed and zeroed. The exact output is affected by the other arguments given. t, table This option species the packet matching table which the command should operate on. If the kernel is congured with automatic module loading, an attempt will be made to load the appropriate module for that table if it is not already there. v , verbose Verbose output. This option makes the list command show the interface address, the rule options (if any), and the TOS masks. The packet and byte counters are also listed, with the sufx K, M or G for 1000, 1,000,000 and 1,000,000,000 multipliers respectively (but see the -x ag to change this). For appending, insertion, deletion and replacement, this causes detailed information on the rule or rules to be printed. n, numeric Numeric output. IP addresses and port numbers will be printed in numeric format. By default, the program will try to display them as host names, network names, or services (whenever applicable). line-numbers When listing rules, add line numbers to the beginning of each rule, corresponding to that rules position in the chain.
4 IPTABLES
x, exact
15
Expand numbers. Display the exact value of the packet and byte counters, instead of only the rounded number in Ks (multiples of 1000) Ms (multiples of 1000K) or Gs (multiples of 1000M). This option is only relevant for the -L command. modprobe=<command> When adding or inserting rules into a chain, use command to load any necessary modules (targets, match extensions, etc). 4.4.2 Commands
A, append Append one or more rules to the end of the selected chain. When the source and/or destination names resolve to more than one address, a rule will be added for each possible address combination. D, delete Delete one or more rules from the selected chain. There are two versions of this command: the rule can be specied as a number in the chain (starting at 1 for the rst rule) or a rule to match. R, replace Replace a rule in the selected chain. If the source and/or destination names resolve to multiple addresses, the command will fail. Rules are numbered starting at 1. I, insert Insert one or more rules in the selected chain as the given rule number. So, if the rule number is 1, the rule or rules are inserted at the head of the chain. This is also the default if no rule number is specied. L, list List all rules in the selected chain. If no chain is selected, all chains are listed. It is legal to specify the Z (zero) option as well, in which case the chain(s) will be atomically listed and zeroed. The exact output is affected by the other arguments given. F, ush Flush the selected chain. This is equivalent to deleting all the rules one by one. Z, zero Zero the packet and byte counters in all chains. It is legal to specify the L, list (list) option as well, to see the counters immediately before they are cleared. (See above.)
4 IPTABLES
N, new-chain
16
Create a new user-dened chain by the given name. There must be no target of that name already. X, delete-chain Delete the specied user-dened chain. There must be no references to the chain. If there are, you must delete or replace the referring rules before the chain can be deleted. If no argument is given, it will attempt to delete every non-builtin chain in the table. P, policy Set the policy for the chain to the given target. See the section TARGETS for the legal targets. Only non-user-dened chains can have policies, and neither built-in nor user-dened chains can be policy targets. E, rename-chain Rename the user specied chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. h Help Give a (currently very brief) description of the command syntax. 4.4.3 Parameters
The following parameters make up a rule specication (as used in the add, delete, insert, replace and append commands). p, protocol [!] protocol The protocol of the rule or of the packet to check. The specied protocol can be one of tcp, udp, icmp, or all, or it can be a numeric value, representing one of these protocols or a different one. A protocol name from /etc/protocols is also allowed. A ! argument before the protocol inverts the test. The number zero is equivalent to all. Protocol all will match with all protocols and is taken as default when this option is omitted. s, source [!] address[/mask] Source specication. Address can be either a hostname, a network name, or a plain IP address. The mask can be either a network mask or a plain number, specifying the number of 1s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0. A ! argument before the address specication inverts the sense of the address. The ag src is a convenient alias for this option. d, destination [!] address[/mask] Destination specication. See the description of the s (source) ag for a detailed description of the syntax. The ag dst is an alias for this option.
5 PACKET FLOW
j, jump target
17
This species the target of the rule; i.e., what to do if the packet matches it. The target can be a user-dened chain (other than the one this rule is in), one of the special builtin targets which decide the fate of the packet immediately, or an extension (see EXTENSIONS below). If this option is omitted in a rule, then matching the rule will have no effect on the packets fate, but the counters on the rule will be incremented. i, in-interface [!] [name] Optional name of an interface via which a packet is received (for packets entering the INPUT, FORWARD and PREROUTING chains). When the ! argument is used before the interface name, the sense is inverted. If the interface name ends in a +, then any interface which begins with this name will match. If this option is omitted, the string + is assumed, which will match with any interface name. o, out-interface [!] [name] Optional name of an interface via which a packet is going to be sent (for packets entering the FORWARD, OUTPUT and POSTROUTING chains). When the ! argument is used before the interface name, the sense is inverted. If the interface name ends in a +, then any interface which begins with this name will match. If this option is omitted, the string + is assumed, which will match with any interface name. [!] f, fragment This means that the rule only refers to second and further fragments of fragmented packets. Since there is no way to tell the source or destination ports of such a packet (or ICMP type), such a packet will not match any rules which specify them. When the ! argument precedes the f ag, the rule will only match head fragments, or unfragmented packets. c, set-counters PKTS BYTES This enables the administrater to initialize the packet and byte counters of a rule (during INSERT, APPEND, REPLACE operations)
5 Packet Flow
We have already seen the beginnings of our script where we turn off IP forwdarding, and initialize our chains. One thing to remember is to turn on IP forwarding at the end of your script. The thing to remember is the sequence of events on how iptables works. http://iptables-tutorial.frozentux.net/iptables-tutorial.html has an excellent discussion on how a packet traverses iptables. In short, here is a diagram of what happens when a packet enters the rewall.
5 PACKET FLOW
18
Mangle Table
PREROUTING chain This is the rst table that a packet encounters. If there are any packet mangeling rules, this is where the packet gets changed in the prerouting chain
Nat Table
PREROUTING Chain Lets say that your web server is on a private network behind the rewall. All port 80 packets should have their destination changed to the private IP address of the web server. This is accomplished with using DNAT Target. Other items I have found useful is that you can use the DROP Target here to drop some packets early in the game. Like if you are port forwarding email to your email server, you can drop some email packets in your rewall script, thus making your rewall script a windows virus scanner and blocker.
Filter Table
INPUT FORWARD OUTPUT Chains This is the default table where most of the ltering takes place. This is where you normally ACCEPT, REJECT, or DROP packets. If a packet has been prerouted to another box, it never gets to the Filter table. DO NOT use the input chain for any packets that have been forwarded via the Nat table! Any packets that are forwarded are only handled by the forward chain of the Filter table. Thus any ports that are forwarded to another box, it is best to test those packets prior to changing the destination.
Mangle Table
POSTROUTING Chain
Nat Table
POSTROUTING Chain This is where the targets SNAT and MASAQUERADE are accomplished. If we have a private network, this is where the private IP Address gets changed to the real IP Address.
5 PACKET FLOW
19
5 PACKET FLOW
20
Network
mangle PREROUTING
nat PREROUTING
DNAT
NO
Routing?
YES
mangle FORWARD
DROP ACCEPT REJECT
filter FORWARD
mangle POSTROUTING
nat POSTROUTING
SNAT MASQUERADE
Network
21
As you can see from the above owchart if a packet is to be routed to another box, using the lter input chain to drop a packet will not work. There are several approaches that you can use to make sure all packets are checked. The rst option would be to create a new chain that has both input and forward point to it. An alternative method is to lter packets prior to the routing decision in the nat prerouting chain. According to the various iptables documentation this is not the best method. I like creating a chain called block and making both input and forward jump to it. iptables -A INPUT -j block iptables -A FORWARD -j block This causes both the INPUT and the FORWARD chains of the lter table use the same rules. This method came from the early documentation by Rusty. Also you do not have to be concerned if a packet is being forwarded or not when you create your rules.
########################################### # # # NAT # # #
22
# Set up the ip forwarding for the local network to get to the outside: # Use /etc/services for the destination port iptables -t nat -A POSTROUTING -o $Internet -p tcp -s $LAN_IP/16 --dport 20 -j SNAT --to $RealIP iptables -t nat -A POSTROUTING -o $Internet -p tcp -s $LAN_IP/16 --dport 21 -j SNAT --to $RealIP iptables -t nat -A POSTROUTING -o $Internet -p tcp -s $LAN_IP/24 --dport 22 -j SNAT --to $RealIP
\ \ \
# Block these nasties from being forwarded # Firewall acting as a virus scanner. Notice that these are being dropped # on all ports, states, addresses, and interfaces. # Also you should notice that our log file will tell us that we are are being # attacked. # For this to work you need the string match included in your kernel. iptables -t nat -A PREROUTING -p tcp --dport http -m state \ --state NEW,ESTABLISHED,RELATED -m string --string "/default.ida" \ -m limit --limit 1/hour -j LOG --log-prefix "CodeRed virus " iptables -t nat -A PREROUTING -p tcp --dport http -m state \ --state NEW,ESTABLISHED,RELATED -m string --string "/default.ida" \ -j DROP # Block Port Scans iptables -t nat -A PREROUTING -m psd -m limit --limit 1/hour -j LOG --log-prefix "Port Scan " iptables -t nat -A PREROUTING -s ! 192.168.1.1 -i ! $LAN -m psd -j DROP # Forward These iptables -t nat -A PREROUTING -i $Internet -p tcp --dport 80 -m limit --limit 1/hour -j LOG --log-level info --log-prefix "Forward WWW Request " iptables -t nat -A PREROUTING -i $Internet -p tcp --dport 80 -j DNAT --to $WebIP \ \ \ \
23
These few lines of code are just examples for you to get started. You should DROP everything that is not specically allowed. If you only have one real IP address, the only thing that you might allow access to your rewall is DNS if you are running named. Everything else gets forwarded or dropped. The fewer things that you allow the safer you will be. When writing your rewall include a log entry for every rule with a good logprex statement. This will not only help in the debugging process, but will also show you what your rewall is doing. This is very vital for accepted packets. You might nd that you are allowing packets through that you do not want. Also keep tabs on your /var/log/messages le.
PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modications made by others. This License is a kind of copyleft, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
24
of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The Document, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as you. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A Modied Version of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modications and/or translated into another language. A Secondary Section is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Documents overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The Invariant Sections are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not t the above denition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The Cover Texts are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A Transparent copy of the Document means a machine-readable copy, represented in a format whose specication is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent le format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modication by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not Transparent is called Opaque. Examples of suitable formats for Transparent copies include plain ASCII without AT X input format, SGML or XML using a publicly markup, Texinfo input format, L E available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modication. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
25
The Title Page means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, Title Page means the text near the most prominent appearance of the works title, preceding the beginning of the body of the text. A section Entitled XYZ means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specic section name mentioned below, such as Acknowledgements, Dedications, Endorsements, or History.) To Preserve the Title of such a section when you modify the Document means that it remains a section Entitled XYZ according to this denition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
26
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using publicstandard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
7.4 MODIFICATIONS
You may copy and distribute a Modied Version of the Document under the conditions of sections 7.2 and 7.3 above, provided that you release the Modied Version under precisely this License, with the Modied Version lling the role of the Document, thus licensing distribution and modication of the Modied Version to whoever possesses a copy of it. In addition, you must do these things in the Modied Version: 1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. 2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modications in the Modied Version, together with at least ve of the principal authors of the Document (all of its principal authors, if it has fewer than ve), unless they release you from this requirement. 3. State on the Title page the name of the publisher of the Modied Version, as the publisher. 4. Preserve all the copyright notices of the Document. 5. Add an appropriate copyright notice for your modications adjacent to the other copyright notices. 6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modied Version under the terms of this License, in the form shown in the Addendum below. 7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Documents license notice. 8. Include an unaltered copy of this License.
27
9. Preserve the section Entitled History, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modied Version as given on the Title Page. If there is no section Entitled History in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modied Version as stated in the previous sentence. 10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the History section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. 11. For any section Entitled Acknowledgements or Dedications, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. 12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. 13. Delete any section Entitled Endorsements. Such a section may not be included in the Modied Version. 14. Do not retitle any existing section to be Entitled Endorsements or to conict in title with any Invariant Section. 15. Preserve any Warranty Disclaimers. If the Modied Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modied Versions license notice. These titles must be distinct from any other section titles. You may add a section Entitled Endorsements, provided it contains nothing but endorsements of your Modied Version by various partiesfor example, statements of peer review or that the text has been approved by an organization as the authoritative denition of a standard. You may add a passage of up to ve words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modied Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modied Version.
28
29
form. Otherwise they must appear on printed covers that bracket the whole aggregate.
7.8 TRANSLATION
Translation is considered a kind of modication, so you may distribute translations of the Document under the terms of section 7.4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled Acknowledgements, Dedications, or History, the requirement (section 7.4) to Preserve its Title (section 7.1) will typically require changing the actual title.
7.9 TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
30