1620.html

著名的linux英雄站点的文档打包

        7.2.10. PREROUTING chain of the nat table<br>
7.2.11. Starting SNAT and the POSTROUTING chain<br>
8. Example scripts<br>
<br>
    8.1. rc.firewall.txt script structure<br>
<br>
    8.1.1. The structure<br>
    8.2. rc.firewall.txt<br>
    8.3. rc.DMZ.firewall.txt<br>
    8.4. rc.DHCP.firewall.txt<br>
    8.5. rc.UTIN.firewall.txt<br>
    8.6. rc.test-iptables.txt<br>
8.7. rc.flush-iptables.txt<br>
A. Detailed explanations of special commands<br>
<br>
    A.1. Listing your active rule-set<br>
A.2. Updating and flushing your tables<br>
B. Common problems and questions<br>
<br>
    B.1. Problems loading modules<br>
    B.2. State NEW packets but no SYN bit set<br>
    B.3. Internet Service Providers who use assigned IP addresses<br>
    B.4. Letting DHCP requests through iptables<br>
B.5. mIRC DCC problems<br>
C. ICMP types<br>
D. Other resources and links<br>
E. Acknowledgments<br>
F. History<br>
G. GNU Free Documentation License<br>
<br>
    0. PREAMBLE<br>
    1. APPLICABILITY AND DEFINITIONS<br>
    2. VERBATIM COPYING<br>
    3. COPYING IN QUANTITY<br>
    4. MODIFICATIONS<br>
    5. COMBINING DOCUMENTS<br>
    6. COLLECTIONS OF DOCUMENTS<br>
    7. AGGREGATION WITH INDEPENDENT WORKS<br>
    8. TRANSLATION<br>
    9. TERMINATION<br>
    10. FUTURE REVISIONS OF THIS LICENSE<br>
How to use this License for your documents<br>
H. GNU General Public License<br>
<br>
    0. Preamble<br>
    1. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION<br>
2. How to Apply These Terms to Your New Programs<br>
I. Example scripts code-base<br>
<br>
    I.1. Example rc.firewall script<br>
    I.2. Example rc.DMZ.firewall script<br>
    I.3. Example rc.UTIN.firewall script<br>
    I.4. Example rc.DHCP.firewall script<br>
    I.5. Example rc.flush-iptables script<br>
I.6. Example rc.test-iptables script<br>
<br>
List of Tables<br>
3-1. Forwarded packets<br>
3-2. Destination local host (our own machine)<br>
3-3. Source local host (our own machine)<br>
4-1. User-land states<br>
4-2. Internal states<br>
6-1. Tables<br>
6-2. Commands<br>
6-3. Options<br>
6-4. Generic matches<br>
6-5. TCP matches<br>
6-6. UDP matches<br>
6-7. ICMP matches<br>
6-8. Limit match options<br>
6-9. MAC match options<br>
6-10. Mark match options<br>
6-11. Multiport match options<br>
6-12. Owner match options<br>
6-13. State matches<br>
6-14. TOS matches<br>
6-15. TTL matches<br>
6-16. DNAT target<br>
6-17. LOG target options<br>
6-18. MARK target options<br>
6-19. MASQUERADE target<br>
6-20. REDIRECT target<br>
6-21. REJECT target<br>
6-22. SNAT target<br>
6-23. TOS target<br>
6-24. TTL target<br>
6-25. ULOG target<br>
C-1. ICMP types<br>
About the author<br>
<br>
I am someone with too many old computers on his hands. I have my own LAN and want all my machines to be connected to the Internet, whilst at the same time making my LAN fairly secure. The new iptables is a good upgrade from the old ipchains in this regard. With ipchains, you could make a fairly secure network by dropping all incoming packages not destined for given ports. However, things like passive FTP or outgoing DCC in IRC would cause problems. They assign ports on the server, tell the client about it, and then let the client connect. There were some toothing problems in the iptables code that I ran into in the beginning, and in some respects I found the code not quite ready for release in full production. Today, I'd recommend everyone who uses ipchains or even older ipfwadm etc .,to upgrade - unless they are happy with what their current code is capable of and if it does what they need it to.<br>
How to read<br>
<br>
This document was written purely so people can start to grasp the wonderful world of iptables. It was never meant to contain information on specific security bugs in iptables or Netfilter. If you find peculiar bugs or behaviors in iptables or any of the subcomponents, you should contact the Netfilter mailing lists and tell them about the problem and they can tell you if this is a real bug or if it has already been fixed. There are very rarely actual security related bugs found in iptables or Netfilter, however, one or two do slip by once in a while. These are properly shown on the front page of the Netfilter main page, and that is where you should go to get information on such topics.<br>
<br>
The above also implies that the rule-sets available with this tutorial are not written to deal with actual bugs inside Netfilter. The main goal of them is to simply show how to set up rules in a nice simple fashion that deals with all problems we may run into. For example, this tutorial will not cover how we would close down the HTTP port for the simple reason that Apache happens to be vulnerable in version 1.2.12 (This is covered really, though not for that reason).<br>
<br>
This document was simply written to give everyone a good and simple primer at how to get started with iptables, but at the same time it was created to be as complete as possible. It does not contain any targets or matches that are in patch-o-matic for the simple reason that it would require too much effort to keep such a list updated. If you need information about the patch-o-matic updates, you should read the info that comes with it in patch-o-matic as well as the other documentations available on the Netfilter main page.<br>
Conventions used in this document<br>
<br>
The following conventions are used in this document when it comes to commands, files and other specific information.<br>
<br>
    *<br>
<br>
      Code excerpts and command-outputs are printed like this, with all output in fixed width font and user-written commands in bold typeface:<br>
<br>
[blueflux@work1 neigh]$ ls<br>
default  eth0  lo<br>
[blueflux@work1 neigh]$<br>
     <br>
<br>
    *<br>
<br>
      All commands and program names in the tutorial are shown in bold typeface.<br>
    *<br>
<br>
      All system items such as hardware, and also kernel internals or abstract system items such as the loopback interface are all shown in an italic typeface.<br>
    *<br>
<br>
      computer-output is formatted in this way in the text.<br>
    *<br>
<br>
filenames and paths in the file-system are shown like /usr/local/bin/iptables.<br>
<br>
Chapter 1. Introduction<br>
1.1. Why this document was written<br>
<br>
Well, I found a big empty space in the HOWTO's out there lacking in information about the iptables and Netfilter functions in the new linux 2.4.x kernels. Among other things, I'm going to try to answer questions that some might have about the new possibilities like state matching. Most of this will be illustrated with an example rc.firewall.txt file that you can use in your /etc/rc.d/ scripts. Yes, this file was originally based upon the masquerading HOWTO for those of you who recognize it.<br>
<br>
Also, there's a small script that I wrote just in case you screw up as much as I did during the configuration available as rc.flush-iptables.txt.<br>
1.2. How it was written<br>
<br>
I've consulted Marc Boucher and others from the core Netfilter team. Many heartfelt thanks to them for their work and for their help on this tutorial, that I wrote and maintain for boingworld.com. This document will guide you through the setup process step by step and hopefully help you to understand some more about the iptables package. I will base most of the stuff here on the example rc.firewall file, since I find that example a good way to learn how to use iptables. I have decided to just follow the basic chains and from there go down into each and one of the chains traversed in each due order. That way the tutorial is a little bit harder to follow, though this way is more logical. Whenever you find something that's hard to understand, just come back to this tutorial.<br>
1.3. Terms used in this document<br>
<br>
This document contains a few terms that may need more detailed explanations before you read them. This section will try to cover the most obvious ones and how I have chosen to use them within this document.<br>
<br>
Stream - This term refers to a connection that sends and receives packets that are related to eachother in some fashion. Basically, I have used this term for any kind of connection that sends 2 packets or more in both directions. In TCP this may mean a connection that sends a SYN and then replies with an SYN/ACK, but it may also mean a connection that sends a SYN and then replies with an ICMP Host unreachable. In other words, I use this term very loosely.<br>
<br>
State - This term refers to which state the packet is in, either according to RFC 793 - Transmission Control Protocol or according to userside states used in Netfilter/iptables. Note that the used states internally, and externally, do not fully follow the RFC 793 specification. The main reason is that Netfilter has to guess itself to the proper states.<br>
<br>
User space - With this term I mean everything and anything that takes place outside the kernel. For example, invoking iptables -h takes place outside the kernel, while iptables -A FORWARD -p tcp -j ACCEPT takes place (partially) within the kernel, since a new rule is added to the ruleset.<br>
<br>
Kernel space - This is more or less the opposite of User space. This implies the actions that take place within the kernel, and not outside of the kernel.<br>
<br>
Userland - See User space.<br>
Chapter 2. Preparations<br>
<br>
This chapter is aimed at getting you started and to help you understand the role Netfilter and iptables play in linux today. This chapter should hopefully get you set up and finished to go with your experimentation, and installation of your firewall. Given time and perseverance, you'll then get it to perform exactly as you want it to.<br>
2.1. Where to get iptables<br>
<br>
The iptables user-space package can be downloaded from the Netfilter homepage. The iptables package also makes use of kernel space facilities which can be configured into the kernel during make configure. The necessary steps will be discussed a bit further down in this document.<br>
2.2. Kernel setup<br>
<br>
To run the pure basics of iptables you need to configure the following options into the kernel while doing make config or one of its related commands:<br>
<br>
CONFIG_PACKET - This option allows applications and utilities that needs to work directly to various network devices. Examples of such utilities are tcpdump or snort.<br>
<br>
CONFIG_NETFILTER - This option is required if you're going to use your computer as a firewall or gateway to the Internet. In other words, this is most definitely required if for anything in this tutorial to work at all. I assume you will want this, since you are reading this.<br>
<br>
And of course you need to add the proper drivers for your interfaces to work properly, i.e. Ethernet adapter, PPP and SLIP interfaces. The above will only add some of the pure basics in iptables. You won't be able to do anything productive to be honest, it just adds the framework to the kernel. If you want to use the more advanced options in Iptables, you need to set up the proper configuration options in your kernel. Here we will show you the options available in a basic 2.4.9 kernel and a brief explanation :<br>
<br>