Fcsi601 Linux Firewall Nat
Upcoming SlideShare
Loading in...5
×
 

Fcsi601 Linux Firewall Nat

on

  • 1,767 views

firewall tutorial in linux

firewall tutorial in linux

Statistics

Views

Total Views
1,767
Views on SlideShare
1,767
Embed Views
0

Actions

Likes
0
Downloads
87
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Fcsi601 Linux Firewall Nat Fcsi601 Linux Firewall Nat Presentation Transcript

    • Firewalls and Linux 1 03/06/2003
    • What is a Firewall? A set of programs residing on a "gateway server" that protect the resources of an internal network A network device or an host that connect 2 or more networks A device able to monitor each packet to determine whether to forward it toward its destination A device able to evaluates packets with the objective to Control, Modify and Filter network traffic 2 03/06/2003
    • Firewall types Hardware: Cisco Pix Software Tiny Personal Firewall Norton Personal Firewall ... With Netfilter is possible to use a “Linux Box” as Firewall based on IPTABLES. 3 03/06/2003
    • Example: What you need to build a Linux Firewall? 1 PC with (Pentium II 300, 64MB RAM, 1GB HD) enought network interfaces to manage your topology A Linux distribution with Iptables (like RedHat 7.3, 8.0 or 9.0, Mandrake 9.1) or Smoothwall distribution (http://www.smoothwall.org), requires Pentium 100 with 16Mb RAM and 512Mb hard disk 4 03/06/2003
    • Case Study: I want to share my Dialup/ADSL connection to my lab. (I) 5 03/06/2003
    • Case Study: I want to share my Dialup/ADSL connection to my lab. (II) 6 03/06/2003
    • Simple network configuration with MASQUERADING (I) Public IP Addresses are not infinites. Masquerading allows to use only one IP public address (also if dynamically assigned) to connect a lot of hosts using private addresses Is very usefull with all kind of internet connections The gateway “masquerade” the internal private addresses using it’s own ip address as source ip address for packets going outside the private network 7 03/06/2003
    • Public and Private IP Addresses Some IP addresses (like 192.168.0.0/16, 10.0.0.0/8 and subnetworks) are “declared” (by IANA) “private” and cannot be used to send packet to Internet Make possible to use the same IP addresses in different local networks. Allow (with masquerading) more that 232-1 hosts to be connected to the internet with IPv4 addresses. 8 03/06/2003
    • Simple network configuration with MASQUERADING (II) Host1 with IP 192.168.0.10 try to open the Web-page http://217.58.102.76 Gateway G1 receive from Host1 (source 192.168.0.10) a packet with destination 217.58.102.76 port 80 G1 change 217.58.102.76 with it’s own public IP (ex: 213.110.140.18) and forward it to Internet using 33120 as source port G1 receive the reply from 213.110.140.18 to port 33120. G1 knows that this packet, coming from port 33120 has as real destination Host1 G1 change the destination IP address from 213.11.140.18 to 192.168.0.10 and forward the packet to the Trusted private network Host1 is now able to send and receive packets to external servers 9 03/06/2003
    • MASQUERADING Connection from trusted networks to other hosts on Internet can be established only from Host in our LAN An external Host cannot send a packet directly to an Host inside our Trusted network (because they have no public addresses) We miss the possibility to have a reachable server (reachable from the all internet) inside our network 10 03/06/2003
    • Why we need to publish services? We need another network reachable from Internet to publish our services Manage a domain with DNS – DNS Requests from other networks must reach internal DNSs (port 53) Allow remote clients to upload/download from an ftp (or sftp) server – Setup an ftp server to share files with clients outside your local private network (port 21) Publish a Website – Allow the whole Internet users to visit your Institute or company website (port 80) Manage hosts remotely – Activate ssh (port 22) to allow remote administration 11 03/06/2003
    • Firewall: Common topology for small networks Trusted network(s): Include end-user workstations DMZ network(s): Include servers giving services to the Internet Internet connection(s): Internet Service Provider (ISP) connection 12 03/06/2003
    • Trusted Network Connect end-user hosts Every host has a private IP address (like 192.168.0.0/16 and subnets) Every host can send packet to internet but cannot receive packets not related to previously established connections A lot of Trusted networks can be created under the same firewall 13 03/06/2003
    • Demilitarized (DMZ) Network Hosts with services (these kind of hosts are usually called servers) for external networks are inside DMZ network Servers inside DMZ have private IP addresses (ex: 10.0.0.0/8 and subnetworks) Firewall use NAT/PAT to allow external networks to use internal services 14 03/06/2003
    • Internet connection Allow one or more LANs to connect to Internet A Linux box used as firewall is also the gateway interconnecting: Trusted networks with Internet DMZ networks with Internet Trusted networks with DMZ networks if needed 15 03/06/2003
    • Netfilter and Iptables With kernel 2.4 you can run Netfilter. This allow us to setup, maintain and analyze packet filtering rules. Is an evolution of previous tools, ipchains and ipfwadm. Netfilter supports: – Standard packet filtering – Statfull inspection – Maquerading – Complete address translation (NAT/PAT) – Load balancing – Traffic shaping – Allow user-level module creation 16 03/06/2003
    • Standard packet filtering With previous solution (ipchains and ipfwadm) packet filtering was stateless. Each packet was forwarded or dropped depending only on source and destionation addresses and source and destination ports. This approach does not allow some protocol to traverse the firewall without all port >1024 open. 17 03/06/2003
    • An example: Ports >1024! (I) Objective: allow a network application (based on sockets), to be accessible by hosts outside your local LAN: – The software is made by a main process that receive connection requests on port 999. – Then the main process create a new process for each new connection. New processes waits for client data on ports from 40001 to 41000. – The main process send a reply to the client (in the payload of an UDP packet) with port to use to connect to the dedicate process – The client receive the packet, read the port (ex:40001) and send the next packet to port 40001 of the same server – A statless firewall REJECT the packet cause port>1024 are closed With a stateless firewall, if you want to allow your server to work properly with hosts outside your LAN you must open all port>1024 A statfull Firewall allow to leave ports >1024 closed 18 03/06/2003
    • Mastering IPTABLES mini Howto Learn basics about TCP/IP Undestand connection tacking system Learn iptables chains and tables scheme Learn iptables syntax Use a simple network and test it many times Enjoy iptables 19 03/06/2003
    • Good thinks about IPTABLES Connection tracking – A mechanism that monitor packet, storing information about connections. This allow to undestand if a packet is relative to a known connection Additional modules – Is possible to load a module and use it’s feature to add a rule to a table – New modules can be developed to introduce new functionalities Optional userland modules – Everyone can develop a module to be not in kernel mode to match specific needs 20 03/06/2003
    • Different set of packets To undestand how iptables works is important to undestand the different types of packets the firewall will manage: Forwarded: coming from other hosts, destinated to other hosts Input: destinated for localhost Output: generated by localhost How IPTABLES works on them? 21 03/06/2003
    • Chains and Tables (I) A packet passes through Tables and Chains before to be: – forwarded, sent to destination – passed to a local process – dropped, rejected – ... Depending on packet type (forwarded, input, output) it traverse different chains. 22 03/06/2003
    • Chains and Tables (II) IPTABLES uses 5 default chains: – PREROUTING: packet coming from other hosts – FORWARD: packet to be forwarded – INPUT: packet destinated to localhost – OUTPUT: packet generated by localhost – POSTROUTING: packet going out to other hosts 23 03/06/2003
    • Chains and Tables (III) Every chain “contains” one or more tables. New custom chains can be created Every packet goes into some chains, depending on it’s type (forwarded, input, output) To traverse a chain, a packet traverse all default tables inside the specified chain Tables are: – Mangle – Filter – NAT 24 03/06/2003
    • The big picture: traversing of tables and chains 25 03/06/2003
    • Forwarded packets path: 1. On the wire 2. Firewall interface 3. PREROUTING chain Mangle table NAT table 4. Routing decision 5. FORWARD chain Filter table 6. POSTROUTING chain NAT chain 7. Outgoing interface on the wire again 26 03/06/2003
    • Input packets path: 1. On the wire 2. Firewall interface 3. PREROUTING chain Mangle table NAT table 4. Routing decision 5. INPUT chain FILTER table 6. Local application/process 27 03/06/2003
    • Output packets path: 1. Local application/process 2. OUTPUT chain Mangle table NAT table FILTER table 3. Routing decision 4. POSTROUTING chain NAT table 5. Correct local interface on the wire 28 03/06/2003
    • MANGLE table Allow to change parameters – TOS: Type Of Service, allow to implement routing policies using iptables – TTL: Time To Live. Send packet to the Internet Service Provider with the same TTL (making more difficult for some ISP to check if you are using the connecti – MARK: used by iproute2 to make different routing decision (bandwidth limiting and class based queuing) 29 03/06/2003
    • Network Address Translation (NAT) table (I) Destination NAT (DNAT): Allow to change destination address. Usefull to receive packets from Internet redirecting them to Internal LAN services (like services running on servers inside DMZ network) Source NAT (SNAT): Allow to hide internal DMZ network. The Firewall change the source addess of outgoing packets using it’s own internet IP address (a public one) NOTE: This allow DMZ and Trusted networks to use private Internet addresses like 10.0.0.0/8 and 192.168.0.0/16. 30 03/06/2003
    • Network Address Translation (NAT) table (II) MASQUERADING: Firewall hide all hosts inside Trusted network, using it’s own internet address (a public one). This allow you to connect many hosts using only one Public Internet address. In the opposite direction you hide hosts inside Trusted network. With Masquerading is not possible for hosts from Internet to start a new (not RELATED) connection to the Trusted network. 31 03/06/2003
    • Statefull vs. Stateless Firewalls Statless firewalls can make filter decision based only on: – source/destination addresses and ports Statfull firewall associate a packet to a state and can make decision base on: – source/destination addesses and ports – state of the packet 32 03/06/2003
    • Connection tracking (I) IPTABLES with connection tracking Use your Linux box become a statfull Firewall “ALLOW TO WRITE TIGHTER RULES” “YOU DON’T NEED TO OPEN ALL PORTS > 1024” 33 03/06/2003
    • Connection tracking (II) PREROUTING chain make decision about packet states, possible states are: – NEW: the packet is new in the connection – ESTABLISHED: the packet is part of an established connection – RELATED: the packet is NEW in the connection but the connection is related to an already ESTABLISHED connection ex: ICMP message are related to the relative connection ex: FTP-DATA stream is related to the FTP-CONTROL one ex: More complicated TCP/UDP protocols needs additional modules to be undestood as related – INVALID: Packet that cannot be identified and does not have a valid state. Is good practice to always DROP INVALID packets 34 03/06/2003
    • TCP connections (I) The client send a SYN packet, the firewall catalog it as relative to a new connection. The server sends the SYN/ACK reply, and the connection become ESTABLISHED. 35 03/06/2003
    • UDP connections UDP is a connectionless protocol, but the kernel can maintain information about connection status. This allow to see the UDP connection like for TCP. The Server reply the first packet, so the connection is considered ESTABLISHED 36 03/06/2003
    • ICMP connections (I) When the Client reply to the Echo Request the packet is considered ESTABLISHED. After that the connection tracking system delete info about this connection, because we expect no more legal traffic relative to this ICMP request. 37 03/06/2003
    • ICMP connections (II) An ICMP can be relative to another UDP or TCP connection. Connection tracking allow to see the ICMP Net Unreachable as related to another connection. 38 03/06/2003
    • Other connections, active FTP (I) FTP has a ftp-control channel (port 21) and a ftp-data channel (port 20). For active FTP the client connect to the server on ftp-control port, then in the payload sends information about IP and port to connect to A firewall should allow the server to connect to this client using information about IP and port Connection tracking use a special module that scans through the data in the control connection allowing the server connection (SYN) to the client to be RELATED 39 03/06/2003
    • Other connections, active FTP (II) 40 03/06/2003
    • Other connections, passive FTP (I) In passive FTP the client asks for data The server sends (inside ftp-control channel) information about IP and port to connect to The client open a connection to this IP and port from it’s data port (20) and then retrieve the requested data Again the connection tracking module allow to see the new connection SYN as RELATED to the ftp-control channel 41 03/06/2003
    • Other connections, passive FTP (II) 42 03/06/2003
    • New Tables and Jumps A new custom chain can be created: #iptables –N custom_chain With a “Jump” a packet can be sent to a chain: #iptables –A INPUT –p UDP –j custom_chain All UDP packets will pass throught custom_chain Allow to parse only specific packets with a specific set of rules After traversing a chain the packet comes back to the originating chain, starting from the rule that follows the Jump 43 03/06/2003
    • Command line and Shorewall (I) 44 03/06/2003
    • Command line and Shorewall (II) APPEND #iptables –A FORWARD –p ALL –d 10.0.0.1 –j ACCEPT DELETE #iptables -D INPUT --dport 80 -j DROP, iptables -D INPUT 1 REPLACE #iptables -R INPUT 1 -s 192.168.0.1 -j DROP POLICY #iptables -P INPUT DROP CREATE CHAIN #iptables -N allowed FLUSH #iptables -F INPUT LIST #iptables -L INPUT 45 03/06/2003
    • TARGETS A rule checks a packet by protocol, source/destination addresses, source/destination ports, state and many other parameters. If it matches, the TARGET specify an action to take TARGETS are: – ACCEPT, DROP, REJECT – DNAT, SNAT, MASQUERADE – LOG, ULOG, MARK – MIRROR, QUEUE, REDIRECT, RETURN – TOS, TTL 46 03/06/2003
    • ACCEPT “As soon as the match specification for a packet has been fully satisfied, the rule is accepted and will not continue traversing the current chain or any other ones in the same table. Note however, that a packet that was accepted in one chain might still travel through chains within other tables, and could still be dropped there. There is nothing special about this target whatsoever, and it does not require, nor have the possibility of, adding options to the target. To use this target, we simply specify -j ACCEPT” (iptables tutorial 1.1.18). 47 03/06/2003
    • Case Study: PING (I) [root@firewall]#iptables –F [root@firewall]#iptables –P INPUT DROP [root@firewall]#iptables –P OUTPUT DROP [root@firewall]#iptables –P FORWARD DROP [root@firewall]#iptables –A FORWARD –p icmp --icmp-type echo-request –d 192.168.0.10 –j ACCEPT [user@192.168.1.1]#ping 192.168.0.10 PING 192.168.0.10 (192.168.0.10) from 192.168.1.1: 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=254 time=0.360 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=254 time=0.319ms [user@192.168.0.10]#tcpdump –n 12:07:00.061966 192.168.1.1 > 192.168.0.10: icmp: echo request 12:07:00.062148 192.168.0.10>192.168.1.1: icmp: echo reply 48 03/06/2003
    • DROP “The DROP target does just what it says, it drops packets dead and will not carry out any further processing. A packet that matches a rule perfectly and is then Dropped will be blocked. Note that this action might in certain cases have an unwanted effect, since it could leave dead sockets around on either host. A better solution in cases where this is likely would be to use the REJECT target, especially when you want to block port scanners from getting too much information, such on as filtered ports and so on. Also note that if a packet has the DROP action taken on it in a subchain, the packet will not be processed in any of the main chains either in the present or in any other table. The packet is in other words totally dead. As we've seen previously, the target will not send any kind of information in either direction, nor to intermediaries such as routers.” (iptables tutorial 1.1.18). 49 03/06/2003
    • Case study: PING (II) [fw]#iptables –P INPUT ACCEPT [fw]#iptables –P OUTPUT ACCEPT [fw]#iptables –P FORWARD ACCEPT [fw]#iptables –F [fw]#iptables –A FORWARD –p icmp --icmp-type echo-request –d 192.168.0.10 –j DROP [user@192.168.1.1]#ping 192.168.0.10 PING 192.168.0.10 (192.168.0.10) from 192.168.1.1: 56(84) bytes of data. CTRL^C [user@192.168.0.10]#tcpdump –n CTRL^C 50 03/06/2003
    • REJECT “The REJECT target works basically the same as the DROP target, but it also sends back an error message to the host sending the packet that was blocked. The REJECT target is as of today only valid in the INPUT, FORWARD and OUTPUT chains or their sub chains. After all, these would be the only chains in which it would make any sense to put this target. Note that all chains that use the REJECT target may only be called by the INPUT, FORWARD, and OUTPUT chains, else they won't work. There is currently only one option which controls the nature of how this target works, though this may in turn take a huge set of variables. Most of them are fairly easy to understand, if you have a basic knowledge of TCP/IP.” (iptables tutorial 1.1.18). 51 03/06/2003
    • Case study: REJECT [fw]#iptables –P INPUT ACCEPT [fw]#iptables –P OUTPUT ACCEPT [fw]#iptables –P FORWARD ACCEPT [fw]#iptables –F [fw]#iptables –A FORWARD –p icmp --icmp-type echo-request –d 192.168.0.10 –j REJECT [user@192.168.1.1]#ping 192.168.0.10 PING 192.168.0.10 (192.168.0.10) from 192.168.1.1: 56(84) bytes of data. From 192.168.0.254 icmp_seq=1 Destination port Ureachable From 192.168.0.254 icmp_seq=1 Destination port Ureachable [user@192.168.0.10]#tcpdump –n CTRL^C 52 03/06/2003
    • DNAT “The DNAT target is used to do Destination Network Address Translation, which means that it is used to rewrite the Destination IP address of a packet. If a packet is matched, and this is the target of the rule, the packet, and all subsequent packets in the same stream will be translated, and then routed on to the correct device, host or network. This target can be extremely useful, for example, when you have an host running your web server inside a LAN, but no real IP to give it that will work on the Internet. You could then tell the firewall to forward all packets going to its own HTTP port, on to the real web server within the LAN. We may also specify a whole range of destination IP addresses, and the DNAT mechanism will choose the destination IP address at random for each stream. Hence, we will be able to deal with a kind of load balancing by doing this.” (iptables tutorial 1.1.18). 53 03/06/2003
    • Case Study: DNAT (I) 213.178.208.130 54 03/06/2003
    • Case Study: DNAT (II) “DNAT to HTTP” [root@firewall]# iptables –t nat –A PREROUTING –p TCP –i eth1 -d 217.58.102.74 - -dport 80 -j DNAT --to-destination 10.0.0.10 “DNAT to DNS” [root@firewall]# iptables –t nat –A PREROUTING –p TCP –i eth1 -d 217.58.102.75 - -dport 53 -j DNAT --to-destination 10.0.0.11 [root@firewall]# iptables –t nat –A PREROUTING –p UDP –i eth1 -d 217.58.102.75 - -dport 80 -j DNAT --to-destination 10.0.0.11 “DNAT to SMTP” [root@firewall]# iptables –t nat –A PREROUTING –p TCP –i eth1 -d 217.58.102.76 - -dport 25 -j DNAT --to-destination 10.0.0.12 “DNAT to POP3” [root@firewall]# iptables –t nat –A PREROUTING –p TCP –i eth1 -d 217.58.102.75 - -dport 113 -j DNAT --to-destination 10.0.0.12 55 03/06/2003
    • Case Study: DNAT (III) [213.178.208.130]#telnet 217.58.102.74 80 Trying 217.58.102.74... Connected to host74-102.pool21758.interbusiness.it (217.58.102.74). Escape character is ' . ^]' [fw]# tcpdump -i eth1 dst host 10.0.0.10 tcpdump: listening on eth1 21:59:05.665687 213.178.208.130.37795 > 10.0.0.10.http: S 1475560217:1475560217(0) win 5840 <mss 1460,sackOK,timestamp 87998393 0,nop,wscale 0> (DF) [tos 0x10] 21:59:05.749653 213.178.208.130.37795 > 10.0.0.10.http: . ack 1855920720 win 5840 <nop,nop,timestamp 87998402 126118625> (DF) [tos 0x10] [10.0.0.10]#tcpdump -n host 213.178.208.130 tcpdump: listening on eth0 22:06:13.467533 213.178.208.130.37795 > 10.0.0.10.http: S 1475560217:1475560217(0) win 5840 <mss 1460,sackOK,timestamp 87998393 0,nop,wscale 0> (DF) [tos 0x10] 22:06:13.467587 10.0.0.10.http > 213.178.208.130.37795: S 1855920719:1855920719(0) ack 1475560218 win 5792 <mss 1460,sackOK,timestamp 126118625 87998393,nop,wscale 0> (DF) 22:06:13.551483 213.178.208.130.37795 > 10.0.0.10.http: . ack 1 win 5840 <nop,nop,timestamp 87998402 126118625> (DF) [tos 0x10] 56 03/06/2003
    • SNAT “The SNAT target is used to do Source Network Address Translation, which means that this target will rewrite the Source IP address in the IP header of the packet. This is what we want, for example, when several hosts have to share an Internet connection. We can then turn on ip forwarding in the kernel, and write an SNAT rule which will translate all packets going out from our local network to the source IP of our own Internet connection. Without doing this, the outside world would not know where to send reply packets, since our local networks mostly use the IANA specified IP addresses which are allocated for LAN networks. If we forwarded these packets as is, no one on the Internet would know that they where actually from us. The SNAT target does all the translation needed to do this kind of work, letting all packets leaving our LAN look as if they came from a single host, which would be our firewall.” “The SNAT target is only valid within the nat table, within the POSTROUTING chain. This is in other words the only chain in which you may use SNAT. Only the first packet in a connection is mangled by SNAT, and after that all future packets using the same connection will also be SNATted.” (iptables tutorial 1.1.18). 57 03/06/2003
    • MASQUERADE “The MASQUERADE target is used basically the same as the SNAT target, but it does not require any --to-source option. The reason for this is that the MASQUERADE target was made to work with, for example, dial-up connections, or DHCP connections, which gets dynamic IP addresses when connecting to the network in question.” “This means that you should only use the MASQUERADE target with dynamically assigned IP connections, which we don't know the actual address of at all times. If you have a static IP connection, you should instead use the SNAT target”. “When you masquerade a connection, it means that we set the IP address used on a specific network interface instead of the --to-source option, and the IP address” “Is automatically grabbed from the information about the specific interface. The MASQUERADE target also has the effect that connections are forgotten when an Interface goes down, which is extremely good if we, for example, kill a specific interface” (iptables tutorial 1.1.18). 58 03/06/2003
    • Case Study: SNAT or MASQUERADING (I) [fw]#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT --to-source 217.58.102.77 SNAT [fw]#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE MASQUERADING [root@192.168.0.10]# telnet 140.105.16.57 80 Trying 140.105.16.57... Connected to 140.105.16.57. Escape character is ' . ^]' [root@140.105.16.57]# tcpdump -n host 217.58.102.77 tcpdump: listening on eth0 09:40:44.405824 217.58.102.77.32947 > 140.105.16.57.http: S 3222243845:3222243845(0) win 5840 <mss 1460,sackOK,timestamp 1968354 0,nop,wscale 0> (DF) [tos 0x10] 59 03/06/2003
    • LOG, ULOG “The LOG target is specially designed for logging detailed information about packets. These could for example be considered as illegal. Or, logging can be used purely for bug hunting and error finding.” “The LOG target will return specific information on packets, such as most of the IP headers and other information considered interesting. It does this via the kernel logging facility, normally syslogd. This information may then be read directly with dmesg, or from the syslogd logs, or with other programs or applications.” “This is an excellent target to use in debug your rule-sets, so that you can see what packets go where and what rules are applied on what packets. Note as well that it could be a really great idea to use the LOG target instead of the DROP target while you are testing a rule you are not 100% sure about on a production firewall, since a syntax error in the rule-sets could otherwise cause severe connectivity problems for your users.” “Also note that the ULOG target may be interesting if you are using really extensive logging, since the ULOG target has support direct logging to MySQL databases and suchlike” (iptables tutorial 1.1.18). 60 03/06/2003
    • MARK “The MARK target is used to set Netfilter mark values that are associated with specific packets. This target is only valid in the mangle table, and will not work outside there.” “The MARK values may be used in conjunction with the advanced routing capabilities in Linux to send different packets through different routes and to tell them to use different queue disciplines (qdisc), etc.” “Note that the mark value is not set within the actual package, but is a value that is associated within the kernel with the packet. In other words, you can not set a MARK for a packet and then expect the MARK still to be there on another host. If this is what you want, you will be better off with the TOS target which will mangle the TOS value in the IP header.” (iptables tutorial 1.1.18). 61 03/06/2003
    • QUEUE, REDIRECT, RETURN “The QUEUE target is used to queue packets to User-land programs and applications. It is used in conjunction with programs or utilities that are extraneous to iptables and may be used, for example, with network accounting, or for specific and advanced applications which proxy or filter packets.” “The REDIRECT target is used to redirect packets and streams to the machine itself. This means that we could for example REDIRECT all packets destined for the HTTP ports to an HTTP proxy like squid, on our own host. Locally generated packets are mapped to the 127.0.0.1 address. In other words, this rewrites the destination address to our own host for packets that are forwarded, or something alike. The REDIRECT target is extremely good to use when we want, for example, transparent proxying, where the LAN hosts do not know about the proxy at all.” “The RETURN target will cause the current packet to stop traveling through the chain where it hit the rule. If it is the subchain of another chain, the packet will continue to travel through the superior chains as if nothing had happened. If the chain is the main chain, for example the INPUT chain, the packet will have the default policy taken on it. The default policy is normally set to ACCEPT, DROP or similar.” (iptables tutorial 1.1.18). 62 03/06/2003
    • TOS, TTL “The TOS target is used to set the Type of Service field within the IP header. The TOS field consists of 8 bits which are used to help in routing packets. This is one of the fields that can be used directly within iproute2 and its subsystem for routing policies. Worth noting, is that that if you handle several separate firewalls and routers, this is the only way to propagate routing information within the actual packet between these routers and firewalls. As previously noted, the MARK target - which sets a MARK associated with a specific packet - is only available within the kernel, and can not be propagated with the packet. If you feel a need to propagate routing information for a specific packet or stream, you should therefore set the TOS field, which was developed for this.” The TTL target is used to modify the Time To Live field in the IP header. One useful application of this is to change all Time To Live values to the same value on all outgoing packets. One reason for doing this is if you have a bully ISP which don't allow you to have more than one machine connected to the same Internet connection, and who actively pursue this. Setting all TTL values to the same value, will effectively make it a little bit harder for them to notify that you are doing this. We may then reset the TTL value for all outgoing packets to a standardized value, such as 64 as specified in Linux kernel. (iptables tutorial 1.1.18). 63 03/06/2003
    • Bibliography Iptables tutorial 1.1.18, Oskar Andreasson “Firewall con Linux” – poletti@niscent.com 64 03/06/2003