Текст книги "Iptables Tutorial 1.2.2"
Автор книги: Oskar Andreasson
Жанр:
Интернет
сообщить о нарушении
Текущая страница: 24 (всего у книги 30 страниц)
Internet Service Providers who use assigned IP addresses
I have added this since a friend of mine told me something I have totally forgotten. Certain stupid Internet Service Providers use IP addresses assigned by IANA for their local networks on which you connect to. For example, the Swedish Internet Service Provider and phone monopoly Telia uses this approach for example on their DNS servers, which uses the 10.x.x.x IP address range. A common problem that you may run into when writing your scripts, is that you do not allow connections from any IP addresses in the 10.x.x.x range to yourself, because of spoofing possibilities. Well, here is unfortunately an example where you actually might have to lift a bit on those rules. You might just insert an ACCEPT rule above the spoof section to allow traffic from those DNS servers, or you could just comment out that part of the script. This is how it might look:
/usr/local/sbin/iptables -t nat -I PREROUTING -i eth1 -s
10.0.0.1/32 -j ACCEPT
I would like to take my moment to bitch at these Internet Service Providers. These IP address ranges are not assigned for you to use for dumb stuff like this, at least not to my knowledge. For large corporate sites it is more than o.k., or your own home network, but you are not supposed to force us to open up ourselves just because of some whim of yours. You are large Internet providers, and if you can't afford buying some 3-4 IP addresses for your DNS servers, I have a very hard time trusting you.
Letting DHCP requests through iptables
This is a fairly simple task really, once you get to know how DHCP works, however, you must be a little bit cautious with what you do let in and what you do not let in. First of all, we should know that DHCP works over the UDP protocol. Hence, this is the first thing to look for. Second, we should check which interface we get and send the request from. For example, if our eth0 interface is set up with DHCP, we should not allow DHCP requests on eth1. To make the rule a bit more specific, we only allow the actual UDP ports used by DHCP, which should be ports 67 and 68. These are the criteria that we choose to match packets on, and that we allow. The rule would now look like this:
$IPTABLES -I INPUT -i $LAN_IFACE -p udp –dport 67:68 –sport
67:68 -j ACCEPT
Do note that we allow all traffic to and from UDP port 67 and 68 now, however, this should not be such a huge problem since it only allows requests from hosts doing the connection from port 67 or 68 as well. This rule could, of course, be even more restrictive, but it should be enough to actually accept all DHCP requests and updates without opening up too large of holes. If you are concerned, this rule could of course be made even more restrictive.
mIRC DCC problems
mIRC uses a special setting which allows it to connect through a firewall and to make DCC connections work properly without the firewall knowing about it. If this option is used together with iptables and specifically the ip_conntrack_irc and ip_nat_irc modules, it will simply not work. The problem is that mIRC will automatically NAT the inside of the packets for you, and when the packet reaches the firewall, the firewall will simply not know how and what to do with it. mIRC does not expect the firewall to be smart enough to take care of this by itself by simply querying the IRC server for its IP address and sending DCC requests with that address instead.
Turning on the "I am behind a firewall" configuration option and using the ip_conntrack_irc and ip_nat_irc modules will result in Netfilter creating log entries with the following content "Forged DCC send packet".
The simplest possible solution is to just uncheck that configuration option in mIRC and let iptables do the work. This means, that you should tell mIRC specifically that it is not behind a firewall.
Appendix C. ICMP types
This is a complete listing of all ICMP types. Note the reference pointing to the RFC or person who introduced the type and code. For a complete and absolute up to date listing of all ICMP types and codes, look at the icmp-parameters document at Internet Assigned Numbers Authority.
Note Iptables and netfilter uses ICMP type 255 internally since it is not reserved for any real usage, and most likely will never have any real usage. If you set a rule to match iptables -A INPUT -p icmp –icmp-type 255 -j DROP, this will DROP all ICMP packets. It is in other words used to match all ICMP types.
Table C-1. ICMP types
| TYPE | CODE | Description | Query | Error | Reference |
|---|---|---|---|---|---|
| Echo Reply | x | RFC792 | |||
| 3 | Network Unreachable | x | RFC792 | ||
| 3 | 1 | Host Unreachable | x | RFC792 | |
| 3 | 2 | Protocol Unreachable | x | RFC792 | |
| 3 | 3 | Port Unreachable | x | RFC792 | |
| 3 | 4 | Fragmentation needed but no frag. bit set | x | RFC792 | |
| 3 | 5 | Source routing failed | x | RFC792 | |
| 3 | 6 | Destination network unknown | x | RFC792 | |
| 3 | 7 | Destination host unknown | x | RFC792 | |
| 3 | 8 | Source host isolated (obsolete) | x | RFC792 | |
| 3 | 9 | Destination network administratively prohibited | x | RFC792 | |
| 3 | 10 | Destination host administratively prohibited | x | RFC792 | |
| 3 | 11 | Network unreachable for TOS | x | RFC792 | |
| 3 | 12 | Host unreachable for TOS | x | RFC792 | |
| 3 | 13 | Communication administratively prohibited by filtering | x | RFC1812 | |
| 3 | 14 | Host precedence violation | x | RFC1812 | |
| 3 | 15 | Precedence cutoff in effect | x | RFC1812 | |
| 4 | Source quench | RFC792 | |||
| 5 | Redirect for network | RFC792 | |||
| 5 | 1 | Redirect for host | |||
| 5 | 2 | Redirect for TOS and network | RFC792 | ||
| 5 | 3 | Redirect for TOS and host | RFC792 | ||
| 8 | Echo request | x | RFC792 | ||
| 9 | Router advertisement – Normal router advertisement | RFC1256 | |||
| 9 | 16 | Router advertisement – Does not route common traffic | RFC2002 | ||
| 10 | Route selection | RFC1256 | |||
| 11 | TTL equals 0 during transit | x | RFC792 | ||
| 11 | 1 | TTL equals 0 during reassembly | x | RFC792 | |
| 12 | IP header bad (catchall error) | x | RFC792 | ||
| 12 | 1 | Required options missing | x | RFC1108 | |
| 12 | 2 | IP Header bad length | x | RFC792 | |
| 13 | Timestamp request (obsolete) | x | RFC792 | ||
| 14 | Timestamp reply (obsolete) | x | RFC792 | ||
| 15 | Information request (obsolete) | x | RFC792 | ||
| 16 | Information reply (obsolete) | x | RFC792 | ||
| 17 | Address mask request | x | RFC950 | ||
| 18 | Address mask reply | x | RFC950 | ||
| 20-29 | Reserved for robustness experiment | Zaw-Sing Su | |||
| 30 | Traceroute | x | RFC1393 | ||
| 31 | Datagram Conversion Error | x | RFC1475 | ||
| 32 | Mobile Host Redirect | David Johnson | |||
| 33 | IPv6 Where-Are-You | x | Bill Simpson | ||
| 34 | IPv6 I-Am-Here | x | Bill Simpson | ||
| 35 | Mobile Registration Request | x | Bill Simpson | ||
| 36 | Mobile Registration Reply | x | Bill Simpson | ||
| 39 | SKIP | Tom Markson | |||
| 40 | Photuris | RFC2521 |
Appendix D. TCP options
This appendix is a simple and brief list of all the TCP options that are officially recognized. These references and numbers were all retreived from the Internet Assigned Numbers Authority website. The master file can be found at this location. The full contact details of the people referenced in this document has been removed, so to create less workload for them hopefully.
Table D-1. TCP Options
| Copy | Class | Number | Value | Name | Reference |
|---|---|---|---|---|---|
| EOOL – End of Options List | [RFC791, JBP] | ||||
| 1 | 1 | NOP – No Operation | [RFC791, JBP] | ||
| 1 | 2 | 130 | SEC – Security | [RFC1108] | |
| 1 | 3 | 131 | LSR – Loose Source Route | [RFC791, JBP] | |
| 2 | 4 | 68 | TS – Time Stamp | [RFC791, JBP] | |
| 1 | 5 | 133 | E-SEC – Extended Security | [RFC1108] | |
| 1 | 6 | 134 | CIPSO – Commercial Security | [???] | |
| 7 | 7 | RR – Record Route | [RFC791, JBP] | ||
| 1 | 8 | 136 | SID – Stream ID | [RFC791, JBP] | |
| 1 | 9 | 137 | SSR – Strict Source Route | [RFC791, JBP] | |
| 10 | 10 | ZSU – Experimental Measurement | [ZSu] | ||
| 11 | 11 | MTUP – MTU Probe | [RFC1191]* | ||
| 12 | 12 | MTUR – MTU Reply | [RFC1191]* | ||
| 1 | 2 | 13 | 205 | FINN – Experimental Flow Control | [Finn] |
| 1 | 14 | 142 | VISA – Experimental Access Control | [Estrin] | |
| 15 | 15 | ENCODE – ??? | [VerSteeg] | ||
| 1 | 16 | 144 | IMITD – IMI Traffic Descriptor | [Lee] | |
| 1 | 17 | 145 | EIP – Extended Internet Protocol | [RFC1385] | |
| 2 | 18 | 82 | TR – Traceroute | [RFC1393] | |
| 1 | 19 | 147 | ADDEXT – Address Extension | [Ullmann IPv7] | |
| 1 | 20 | 148 | RTRALT – Router Alert | [RFC2113] | |
| 1 | 21 | 149 | SDB – Selective Directed Broadcast | [Graff] | |
| 1 | 22 | 150 | NSAPA – NSAP Addresses | [Carpenter] | |
| 1 | 23 | 151 | DPS – Dynamic Packet State | [Malis] | |
| 1 | 24 | 152 | UMP – Upstream Multicast Pkt. | [Farinacci] |
Appendix E. Other resources and links
Here is a list of links to resources and where I have gotten information from, etc :
• ip-sysctl.txt – from the 2.4.14 kernel. A little bit short but a good reference for the IP networking controls and what they do to the kernel.
• InGate – InGate is a commercial firewall producer that uses Linux as the base for their firewall products. Their productrange goes from basic firewalls to SIP gateways and QoS machines.
• RFC 768 – User Datagram Protocol – This is the official RFC describing how the UDP protocol should be used, in detail, and all of it's headers.
• RFC 791 – Internet Protocol – The IP specification as still used on the Internet, with additions and updates. The basic is still the same for IPv4.
• RFC 792 – Internet Control Message Protocol – The definitive resource for all information about ICMP packets. Whatever technical information you need about the ICMP protocol, this is where you should turn first. Written by J. Postel.
• RFC 793 – Transmission Control Protocol – This is the original resource on how TCP should behave on all hosts. This document has been the standard on how TCP should work since 1981 and forward. Extremely technical, but a must read for anyone who wants to learn TCP in every detail. This was originally a Department of Defense standard written by J. Postel.
• RFC 1122 – Requirements for Internet Hosts – Communication Layers – This RFC defines the requirements of the software running on a Internet host, specifically the communication layers.
• RFC 1349 – Type of Service in the Internet Protocol Suite – RFC describing some changes and clarifications of the TOS field in the IP header.
• RFC 1812 – Requirements for IP Version 4 Routers – This RFC specifies how routers on the Internet should behave and how they are expected to handle different situations. Very interesting reading.
• RFC 2401 – Security Architecture for the Internet Protocol – This is an RFC talking about the IPSEC implementation and standardisation. Well worth reading if you are working with IPSEC.
• RFC 2474 – Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers – In this document you will find out how the DiffServ works, and you will find much needed information about the TCP/IP protocol additions/changes needed for the DiffServ protocol to work.
• RFC 2638 – A Two-bit Differentiated Services Architecture for the Internet – This RFC describes a method of implementing two different differentiated service architecture into one. Both where described originally by D. Clark and van Jacobsen at the Munich IETH meeting 1997.
• RFC 2960 – Stream Control Transmission Protocol – This is a relatively new protocol developed by several large telecoms companies to complement UDP and TCP as a layer 3 protocol with higher reliability and resilience.
• RFC 3168 – The Addition of Explicit Congestion Notification (ECN) to IP – This RFC defines how ECN is to be used on a technical level and how it should be implemented in the TCP and IP protocols. Written by K. Ramakrishnan, S. Floyd and D. Black.
• RFC 3260 – New Terminology and Clarifications for Diffserv – This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications.
• RFC 3286 – An Introduction to the Stream Control Transmission Protocol – RFC introducing the Stream Control Transmission Protocol, a relatively new layer 3 protocol in the TCP/IP stack. Developed by several large telecom companies.
• ip_dynaddr.txt – from the 2.4.14 kernel. A really short reference to the ip_dynaddr settings available via sysctl and the proc file system.
• iptables.8 – The iptables 1.3.1 man page. This is an HTMLized version of the man page which is an excellent reference when reading/writing iptables rule-sets. Always have it at hand.
• Ipsysctl tutorial – Another tutorial I have written about the IP System Control in Linux. A try to make a complete listing of all the IP variables that can be set on the fly in Linux.
• Policy Routing Using Linux – This is an excellent book that has now been opened up on the Internet regarding Policy routing in Linux. It is well written and most definitely worth buying. Written by Matthew G. Marsh.
• Security-Enhanced Linux – The official site of the Security-Enhanced Linux (SELinux) system developed as a proof of concept by the National Security Agency (NSA). SELinux is a fine grained Mandatory Access Control system, which lets you have a much higher control on who can do what and what processes has what privileges, et cetera.
• Firewall rules table – A small PDF document gracefully given to this project by Stuart Clark, which gives a reference form where you can write all of the information needed for your firewall, in a simple manner.
• http://l7-filter.sourceforge.net/ – The l7-filter project is basically a set of patches and files to make iptables and netfilter able to handle layer 7 filtering, mainly for QoS and traffic accounting. It works less reliably for filtering however, since it will allow the first couple of packets through before actually blocking traffic.
• http://www.netfilter.org/ – The official Netfilter and iptables site. It is a must for everyone wanting to set up iptables and Netfilter in linux.
• http://www.insecure.org/nmap/ – Nmap is one of the best, and most known, port scanners available. It is very useful when debugging your firewall scripts. Take a closer look at it.
• http://www.netfilter.org/documentation/index.html#FAQ – The official Netfilter Frequently Asked Questions. Also a good place to start at when wondering what iptables and Netfilter is about.
• http://www.netfilter.org/unreliable-guides/packet-filtering-HOWTO/index.html – Rusty Russells Unreliable Guide to packet filtering. Excellent documentation about basic packet filtering with iptables written by one of the core developers of iptables and Netfilter.
• http://www.netfilter.org/unreliable-guides/NAT-HOWTO/index.html – Rusty Russells Unreliable Guide to Network Address Translation. Excellent documentation about Network Address Translation in iptables and Netfilter written by one of the core developers, Rusty Russell.
• http://www.netfilter.org/unreliable-guides/netfilter-hacking-HOWTO/index.html – Rusty Russells Unreliable Netfilter Hacking HOW-TO. One of the few documentations on how to write code in the Netfilter and iptables user-space and kernel space code-base. This was also written by Rusty Russell.
• http://www.linuxguruz.org/iptables/ – Excellent link-page with links to most of the pages on the Internet about iptables and Netfilter. Also maintains a list of iptables scripts for different purposes.
• Policy Routing using Linux – The best book I have ever read on Policy routing nad linux. This is an absolute must when it comes to routing in linux. Written by Matthew G. Marsh.
• Implementing Quality of Service Policies with DSCP – A link about the cisco implementation of DSCP. This shows some classes used in DSCP, and so on.
• IETF SIP Working Group – SIP is one of the "next big things" it seems. Basically it is the defacto standards for Internet telephony today. It is horribly complex as you can see from the amount of documentation on the working groups homepage, and should hopefully be able to cope with pretty much any needs of session initiation in the future. It is used mainly to setup peer to peer connections between known users, for example to connect to [email protected] and setup a phone connection to that user. This is the IETF Working group handling all SIP work.
• IETF TLS Working Group – TLS is a transport layer security model that is one of the most common host to server based security mechanisms. The current version is running is 1.1 and work is ongoing to get 1.2 out the door with support for newer and better cryptos as of this writing. This is a standardized way of sending and receiving public keys for servers and handling trusted certificate agents etc. For more information, read the RFC's on this page.
• IPSEC Howto – This is the official IPSEC howto for Linux 2.6 kernels. It describes how IPSEC works in the 2.6 kernels and up, however, it is not the place to find out exactly how the Linux 2.2 and 2.4 kernels worked when it comes to IPSEC. Go to the FreeS/WAN site for that information.
• FreeS/WAN – This is the official site for FreeS/WAN, an IPSEC implementation for the Linux 2.2 and 2.4 kernel series. This site contains documentation and all necessary downloads for the IPSEC implementation. This effort has been discontinued due to several reasons discussed on the page, but efforts will still be put into bugfixes, documentation and the forums. For an IPSEC implementation for Linux 2.6 kernels, please look at the IPSEC Howto site and the information there.
• http://www.islandsoft.net/veerapen .html -Excellent discussion on automatic hardening of iptables and how to make small changes that will make your computer automatically add hostile sites to a special ban list in iptables .
• /etc/protocols – An example protocols file taken from the Slackware distribution. This can be used to find out what protocol number different protocols have, such as the IP, ICMP or TCP protocols have.
• /etc/services – An example services file taken from the Slackware distribution. This is extremely good to get used to reading once in a while, specifically if you want to get a basic look at what protocols runs on different ports.
• Internet Assigned Numbers Authority – The IANA is the organisation that is responsible for fixing all numbers in the different protocols in an orderly fashion. If anyone has a specific addition to make to a protocol (for example, adding a new TCP option), they need to contact the IANA, which will assign the numbers requested. In other words, extremely important site to keep an eye on.
• RFC-editor.org – This is an excellent site for finding RFC documents in a fast and orderly way. Functions for searching RFC documents, and general information about the RFC community (I.e., errata, news, et cetera).
• Internet Engineering Task Force – This is one of the biggest groups when it comes to setting and maintaining Internet standards. They are the ones maintaining the RFC repository, and consist of a large group of companies and individuals that work together to ensure the interoperability of the Internet.
• Linux Advanced Routing and Traffic Control HOW-TO – This site hosts the Linux Advanced Routing and Traffic Control HOWTO. It is one of the biggest and best documents regarding Linux advanced routing. Maintained by Bert Hubert.
• Paksecured Linux Kernel patches – A site containing all of the kernel patches written by Matthew G. Marsh. Among others, the FTOS patch is available here.
• ULOGD project page – The homepage of the ULOGD site.
• The Linux Documentation Project is a great site for documentation. Most big documents for Linux is available here, and if not in the TLDP, you will have to search the net very carefully. If there is anything you want to know more about, check this site out.
• Snort – this is an excellent open source "network intrusion detection system" (NIDS) which looks for signatures in the packets that it sees, and if it sees a signature of some kind of attack or break-in it can do different actions that can be defined (notifying the administrator, or take action, or simply logging it).
• Tripwire – tripwire is an excellent security tool which can be used to find out about host intrusions. It makes checksums of all the files specified in a configuration file, and then it tells the administrator about any files that has been tampered with in an illegit way every time it is run.
• Squid – This is one of the most known webproxies available on the market. It is open source, and free. It can do several of the filtering tasks that should be done before the traffic actually hits your webserver, as well as doing the standard webcaching functions for your networks.
• http://kalamazoolinux.org/presentations/20010417/conntrack.html – This presentation contains an excellent explanation of the conntrack modules and their work in Netfilter. If you are interested in more documentation on conntrack, this is a "must read".
• http://www.docum.org – Excellent information about the CBQ, tc and the ip commands in Linux. One of the few sites that has any information at all about these programs. Maintained by Stef Coene.
• http://lists.samba.org/m ailman/listinfo/netfilter– The official Netfilter mailing-list. Extremely useful in case you have questions about something not covered in this document or any of the other links here.
And of course the iptables source, documentation and individuals who helped me.
