Linux System Administration phần 9 potx

Your firewall can be as restrictive or open as you wish. Perhaps you simply want to prevent people outside your firewall from being able to Telnet into your system. You may do this by having the firewall reject incoming packets that are required to set up such connections. In an alternate scenario, you might want to filter packets from inside your local area network to prevent anyone from reaching a given IP address. How restrictive your firewall is depends upon the rules you set in IP chains or IP tables. The functionality for a packet−filtering firewall is built into the Linux kernel, although you must recompile with certain network kernel options turned on. This is outlined in the Firewall−HOWTO, maintained by Mark Grennan. Basically, in selecting options, you need to include routing, defragmentation, IP masquerading, and multicast routing (if you intend to do multicasting). Older kernels in the 1.x.x era used a package called ipfwadm, which is no longer supported. Kernels since 2.2.13 use IP chains instead; we'll talk about that in the "IP Chains" section below. The 2.4 kernels use a new firewall utility, known as iptables. Read the Firewall and Proxy Server HOWTO if you are building a firewall! It will probably be helpful to read the Linux Networking HOWTO and the Linux IPCHAINS HOWTO as well. Most HOWTOs can be found on Red Hat's site at http://www.redhat.com/mirrors/LDP/HOWTO/. For information on IP tables, look for information under the heading of NetFilter on http://netfilter.samba.org/. A filtering firewall does not require high−end computer power. If you have an old 486DX66 or better with at least 16MB of memory, 300–500MB of hard drive space, and network connections, you will do fine. In reality, more often the system is at least a Pentium or a Pentium II with 32−64MB of memory and a 20GB hard drive; the point is that you don't have to max out the specifications if the system is only to be used as a filtering firewall since the work of filtering packets doesn't heavily tax a system. More memory will be beneficial if the system requires extremely large IP tables rulesets or if a great deal of state information will be kept. IP Chains The IP Chains package makes managing the kernel's inherent firewall capabilities simpler. An IP chain is a set of rules to be considered when a data packet is attempting to pass through the firewall. The default IP Chains configuration includes three permanent chains: input, output, and forward. The input chain governs incoming packets, the forward chain manages packets destined for another host, and outgoing packets are subjected to the rules of the output chain. You may add and edit other chains as needed. The IP Chains process is fairly simple and is illustrated in Figure 15.3. 389 Figure 15.3: The IP Chains process In an alternate scenario when the loopback interface is used for debugging, a packet that is sent from a local process and destined for a local process passes through the output chain right into the input chain. Rules and Rulesets An IP Chains rule can specify the packet source with the −s option, the protocol with the −p option, the destination with the −d option, the chain to which packets are to be sent if the rule matches with the −j (jump) option, and the port. There are two types of rules: those that affect an entire chain and those that affect the rules within a chain. These options affect an entire chain: −N Create a new chain. −X Delete an empty chain. −P Change the policy for a built−in chain. −L List the rules in a chain. −F Flush the rules out of a chain. −Z Zero the packet and byte counters on all rules within a chain. These options affect rules within a chain: 390 −A Append a new rule to a chain. −I Insert a new rule at some position within a chain. −R Replace a rule at some position within a chain. −D Delete a rule at some position within a chain if passed a numeric value or delete the first rule that matches if passed a rule to match. Now let's look at a few sample rules. This rule denies all packets from 192.168.0.11: ipchains −A input −s 192.168.0.11 −j DENY This rule denies all packets that are not from 192.168.0.11: ipchains −A input −s !192.168.0.11 −j DENY This displays a list of all rules for the input chain: ipchains −L input Both of the following rules delete the seventh rule in the input chain, the first by matching the rule number and the second by matching the rule itself: ipchains −D input 7 ipchains −D input −s 192.168.1.11 −j DENY Finally, this rule flushes the input chain: ipchains input −F Now perhaps we want to deny FTP to the outside world but allow it on our internal network. We do this by adding a rule to the input chain that rejects FTP requests that come in on eth0 but accepts those coming in on eth1. To do this, we must run two separate ipchains commands: ipchains −A input −p tcp −i eth0 −−dport ftp −j REJECT ipchains −A input −p tcp −i eth1 −−dport ftp −j ACCEPT Once your ipchains file is properly set up, you will need to make it run at each bootup. Red Hat offers the ipchains−save and ipchains−restore binaries for this purpose. Run ipchains−save redirecting its output to /etc/ipchains.conf in order to save your rules to the ipchains.conf file: ipchains−save > /etc/ipchains.conf Next add the ipchains−restore command to /etc/rc.d/rc.local so that it will run automatically at bootup. You could just as easily add the ipchains commands that we stored in /etc/ipchains.conf to /etc/rc.d/rc.local, but if you expect to make a lot of changes to the ipchains configuration, the first method is more versatile. Listing 15.7 contains an example ipchains file. This file is set up to do IP masquerading for the 192.168.1 internal network. Listing 15.7: A Sample ipchains File #!/bin/bash /bin/echo −n "Setting up IP Chains: ipchains" /bin/echo "." 391 # # New ipchains commands for somedomain.com # # Define some variables # Any system anywhere export ANY="0.0.0.0/0" # The Internet connection export INET="−W eth0" # The local network port export LETH="−V 192.168.1.1 −W eth1" # The local network export LNET="192.168.1.1/255.255.255.0" # The firewall (this system on the local network) export FWALL="192.168.1.1/32" # The firewall's Internet address (if known or determinable) export INET_IP="225.126.21.1" # Some ipfwadm flags for the TCP protocol export OpenNewConn="−y" export ConnEstablished="−k" # Flush Old Rules /sbin/ipchains input −F /sbin/ipchains output −F # Load masquerade support modules /sbin/modprobe ip_masq_ftp /sbin/modprobe ip_masq_irc /sbin/modprobe ip_masq_raudio # Create forwarding chain and set reject as default /sbin/ipchains −N forward /sbin/ipchains −A forward −j reject −S #LNET −d $LNET /sbin/ipchains −A forward −j reject −S #LNET −d 10.0.0.0/8 /sbin/ipchains −A forward −j reject −S #LNET −d 172.16.0.0/12 /sbin/ipchains −A forward −j reject −S #LNET −d 192.168.0.0/16 # Masquerade these ip's w/ default as all /sbin/ipchains −A forward −j MASQ −s 192.168.1.1/32 −i eth0 −d $ANY /sbin/ipchains −A forward −j MASQ −s 192.168.1.2/32 −i eth0 −d $ANY /sbin/ipchains −A forward −j MASQ −s 192.168.1.3/32 −i eth0 −d $ANY /sbin/ipchains −A forward −j MASQ −s 192.168.1.4/32 −i eth0 −d $ANY /sbin/ipchains −A forward −j MASQ −s 192.168.1.5/32 −i eth0 −d $ANY /sbin/ipchains −A forward −j MASQ −s 192.168.1.6/32 −i eth0 −d $ANY /sbin/ipchains −A forward −j MASQ −s 192.168.200.206/32 −i eth0 −d $ANY # Sets telnet and ftp to be instant, and ftp−data to have fast # throughput /sbin/ipchains −A output −p tcp −d 0.0.0.0/0 telnet −t 0x01 0x10 /sbin/ipchains −A output −p tcp −d 0.0.0.0/0 ftp −t 0x01 0x10 /sbin/ipchains −A output −p tcp −s 0.0.0.0/0 ftp−data −t 0x01 0x08 # Default policy: allow all traffic unless explicitly blocked #/sbin/ipchains −N input #/sbin/ipchains −A input −P accept #/sbin/ipchains −N ouput #/sbin/ipchains −A output −P accept # Tell the kernel to allow ip forwarding /bin/echo "1" > /proc/sys/net/ipv4/ip_forward Administrator's Logbook: IP Chains 392 System: E12345678 Added the following rule to prevent message traffic from 192.168.1.23 from being passed on: ipchains −A input −s 192.168.1.23 −j DENY Added the following rules to deny ftp requests coming in from the outside world (eth0) but accept internal network (eth1) FTP requests: ipchains −A input −p tcp −i eth0 −−dport ftp −j REJECT ipchains −A input −p tcp −i eth1 −−dport ftp −j ACCEPT IP Tables The IP Tables package, more often called Netfilter, is a bit more sophisticated than IP Chains. IP Chains establish a stateless firewall that doesn't concern itself with the ordering of packets received. There is no mechanism for noticing that a packet arrived out of order or that a packet that was expected wasn't received. The IP Tables package is a stateful firewall, which adds tracking of open connections in a state table. There are three default tables: filter, nat, and mangle. We will discuss the filter and nat tables here. The default filter table includes these permanent chains: INPUT, OUTPUT, and FORWARD. Building on our IP Chains explanation, the use of these chains is rather intuitive except for a couple of differences: whereas all incoming datagrams are sent to the IP Chains input chain, only datagrams destined for the localhost are sent to the Netfilter INPUT chain; datagrams destined for other hosts are sent to the FORWARD chain. Another key difference is that the IP Chains output chain sees all outgoing packets regardless of where they originated. Netfilter's OUTPUT chain only looks at packets originating in the localhost destination, ignoring those datagrams being routed from a different host. For masquerading, you'll need to use the nat table. This table has two chains: PREROUTING and POSTROUTING. Use −t nat to specify that you want to affect the nat table. You may still add and edit other chains as needed. The IP Tables process is illustrated in Figure 15.4. 393 Figure 15.4: The IP Tables process Walking through the process, we see that a packet enters the system and is checked by checksum to see if it is corrupted. If it is, it is denied; otherwise it is passed on to the sanity check, which checks to see whether the packet is properly formatted. If it isn't, it is denied. If the packet passes this test, it is evaluated as either a local packet or an external packet. Local packets are sent on to the INPUT chain, which evaluates it against the INPUT chain ruleset, which drops, rejects, or sends it through that process to the OUTPUT chain. External packets, those bound for external hosts, are sent to the FORWARD chain. Once sent on to the FORWARD chain, the packet is checked against that chain's ruleset and dropped, rejected, or sent on to the OUTPUT chain. The Netfilter method is quite streamlined when compared to the IP Chains method that we discussed above. In order to use IP Tables, you need to build the kernel with Netfilter support (must be kernel 2.3.15 or later) or include it as a module. Rules and Rulesets Rules for IP Tables look a little different than IP Chains rules. First let's examine the syntax: A Netfilter rule can specify the packet source with the −s option, the protocol with the −p option, the destination with the −d option, the chain to which packets are to be sent if the rule matches with the −j (jump) option, and the port. There are three types of rules now: those that affect an entire table, those that affect an entire chain, and those that affect the rules within a chain. Use −t to specify a table name. The default table is the filter table, but you'll use the nat table to affect masquerading. 394 The nat table has two chains: PREROUTING for incoming interfaces and POSTROUTING for outgoing interfaces. This option affects an entire table: −t Names a specific table to act upon. These options affect an entire chain: −N Create a new chain. −X Delete an empty chain. −E Rename a chain. −P Change the policy for a built−in chain. −L List the rules in a chain. −F Flush the rules out of a chain. −Z Zero the packet and byte counters on all rules within a chain. These options affect rules within a chain: −A Append a new rule to a chain. −I Insert a new rule at some position within a chain. −R Replace a rule at some position within a chain. −D Delete a rule at some position within a chain if passed a numeric value or delete the first rule that matches if passed a rule to match. Now let's look at the sample rules we used with IP Chains above, rewritten in IP Tables syntax. This rule drops all packets from 192.168.0.11: iptables −A INPUT −s 192.168.0.11 −j DROP This rule drops all packets that are not from 192.168.0.11: iptables −A INPUT −s !192.168.0.11 −j DROP This displays a list of all rules for the input chain: iptables −L INPUT To list the rules in the nat table, add the −t flag instead of a chain name. iptables −L −t nat Both of the following rules delete the seventh rule in the input chain, the first by matching the rule number and the second by matching the rule itself: iptables −D INPUT 7 iptables −D INPUT −s 192.168.1.11 −j DROP Finally, this rule flushes the input chain: iptables INPUT −F To flush the rules of the nat table only: 395 iptables −F −t nat Now perhaps we want to deny FTP to the outside world but allow it on our internal network. Assuming that we have two network cards, eth0 and eth1, and that eth0 is the one that connects to the Internet, we do this by adding a rule to the input chain that rejects FTP requests that come in on eth0 but accepts those coming in on eth1. To do this, we must run two separate iptables commands: iptables −A INPUT −p tcp −i eth0 −−source−port ftp −j REJECT iptables −A INPUT −p tcp −i eth1 −−source−port ftp −j ACCEPT Once your Netfilter file is properly set up, you will need to make it run at each bootup. Red Hat offers the iptables−save and iptables−restore binaries for this purpose. Run iptables−save redirecting its output to /etc/iptables.conf in order to save your rules to the iptables.conf file: iptables−save > /etc/iptables.conf To restore from /etc/iptables.conf, run iptables−restore with redirection from /etc/iptables.conf: iptables−restore < /etc/iptables.conf Next add the ipchains−restore command to /etc/rc.d/rc.local so that it will run automatically at bootup. You could just as easily add the Netfilter commands that we stored in /etc/iptables.conf to /etc/rc.d/rc.local, but if you expect to make a lot of changes to the configuration, the first method is more versatile. Still better is adding an IP Tables script to /etc/init.d or wherever your distribution puts its startup scripts. Red Hat 7.3 does this by default with the script shown in Listing 15.8: Listing 15.8: A Sample Netfilter Startup File #!/bin/sh # # Startup script to implement /etc/sysconfig/iptables pre−defined rules. # # chkconfig: 2345 08 92 # # description: Automates a packet filtering firewall with iptables. # # by bero@redhat.com, based on the ipchains script: # Script Author: Joshua Jensen <joshua@redhat.com> # −− hacked up by gafton with help from notting # modified by Anton Altaparmakov <aia21@cam.ac.uk>: # modified by Nils Philippsen <nils@redhat.de> # # config: /etc/sysconfig/iptables # Source 'em up . /etc/init.d/functions IPTABLES_CONFIG=/etc/sysconfig/iptables if [ ! −x /sbin/iptables ]; then exit 0 fi KERNELMAJ=`uname −r | sed −e 's,\ *,,'` KERNELMIN=`uname −r | sed −e 's,[^\.]*\.,,' −e 's,\ *,,'` if [ "$KERNELMAJ" −lt 2 ] ; then 396 exit 0 fi if [ "$KERNELMAJ" −eq 2 −a "$KERNELMIN" −lt 3 ] ; then exit 0 fi if /sbin/lsmod 2>/dev/null |grep −q ipchains ; then # Don't do both exit 0 fi iftable() { if fgrep −qsx $1 /proc/net/ip_tables_names; then iptables −t "$@" fi } start() { # don't do squat if we don't have the config file if [ −f $IPTABLES_CONFIG ]; then # If we don't clear these first, we might be adding to # pre−existing rules. action $"Flushing all current rules and user defined chains:" iptables −F action $"Clearing all current rules and user defined chains:" iptables −X chains=`cat /proc/net/ip_tables_names 2>/dev/null` for i in $chains; do iptables −t $i −F; done && \ success $"Flushing all current rules and user defined chains:" || \ failure $"Flushing all current rules and user defined chains:" for i in $chains; do iptables −t $i −X; done && \ success $"Clearing all current rules and user defined chains:" || \ failure $"Clearing all current rules and user defined chains:" for i in $chains; do iptables −t $i −Z; done echo $"Applying iptables firewall rules: " grep −v "^[[:space:]]*#" $IPTABLES_CONFIG | grep −v '^[[:space:]]*$' | /sbin/iptables−restore −c && \ success $"Applying iptables firewall rules" || \ failure $"Applying iptables firewall rules" echo touch /var/lock/subsys/iptables fi } stop() { chains=`cat /proc/net/ip_tables_names 2>/dev/null` for i in $chains; do iptables −t $i −F; done && \ success $"Flushing all chains:" || \ failure $"Flushing all chains:" for i in $chains; do iptables −t $i −X; done && \ success $"Removing user defined chains:" || \ failure $"Removing user defined chains:" echo −n $"Resetting built−in chains to the default ACCEPT policy:" iftable filter −P INPUT ACCEPT && \ 397 iftable filter −P OUTPUT ACCEPT && \ iftable filter −P FORWARD ACCEPT && \ iftable nat −P PREROUTING ACCEPT && \ iftable nat −P POSTROUTING ACCEPT && \ iftable nat −P OUTPUT ACCEPT && \ iftable mangle −P PREROUTING ACCEPT && \ iftable mangle −P OUTPUT ACCEPT && \ success $"Resetting built−in chains to the default ACCEPT policy" || \ failure $"Resetting built−in chains to the default ACCEPT policy" echo rm −f /var/lock/subsys/iptables } case "$1" in start) start ;; stop) stop ;; restart) # "restart" is really just "start" as this isn't a daemon, # and "start" clears any pre−defined rules anyway. # This is really only here to make those who expect it happy start ;; condrestart) [ −e /var/lock/subsys/iptables ] && start ;; status) tables=`cat /proc/net/ip_tables_names 2>/dev/null` for table in $tables; do echo $"Table: $table" iptables −t $table −−list done ;; panic) echo −n $"Changing target policies to DROP: " iftable filter −P INPUT DROP && \ iftable filter −P FORWARD DROP && \ iftable filter −P OUTPUT DROP && \ iftable nat −P PREROUTING DROP && \ iftable nat −P POSTROUTING DROP && \ iftable nat −P OUTPUT DROP && \ iftable mangle −P PREROUTING DROP && \ iftable mangle −P OUTPUT DROP && \ success $"Changing target policies to DROP" || \ failure $"Changing target policies to DROP" echo iftable filter −F INPUT && \ iftable filter −F FORWARD && \ iftable filter −F OUTPUT && \ iftable nat −F PREROUTING && \ iftable nat −F POSTROUTING && \ iftable nat −F OUTPUT && \ iftable mangle −F PREROUTING && \ iftable mangle −F OUTPUT && \ 398 [...]... traceroute Command $ /usr/sbin/traceroute www .linux. org traceroute to www .linux. org ( 198 .182. 196 .56), 30 hops max, 40 byte packets 1 dsl−254−070.dsl−isp.net (216.254.70.1) 30. 599 ms 46. 390 ms 33.701 ms 2 border9.fe4−0.speakeasy−6.nyc.pnap.net (2 09. 191 .175. 196 ) 25.710 ms 37.445 ms 26.314 ms 3 core2.fe0−0−fenet1.nyc.pnap.net (2 09. 191 .128.66) 26.032 ms 415 25.860 ms 25.5 97 ms 4 POS3−3.GW12.NYC4.ALTER.NET (157.130.253.217)... uu−peer−oc12.core.ai.net (205.134.160.2) 47.416 ms 48.6 39 ms 44.5 09 ms 11 border−ai.invlogic.com (205.134.175.254) 42.543 ms 54.816 ms 63.588 ms 12 router.invlogic.com ( 198 .182. 196 .1) 58.183 ms 58. 595 ms 73.077 ms 13 www .linux. org ( 198 .182. 196 .56) 117.648 ms 153.763 ms 111. 498 ms Tuning the System Most of the default settings in a typical operating system Linux included—are set conservatively in an effort... 38.132 ms 25 .96 9 ms 5 505.ATM2−0.XR1.NYC4.ALTER.NET (152.63.22.66) 26.275 ms 25.030 ms 26.302 ms 6 1 89. at−1−0−0.TR1.NYC8.ALTER.NET (152.63.21 .90 ) 27.014 ms 27.310 ms 26.042 ms 7 124.at−6−0−0.TR1.DCA6.ALTER.NET (152.63.2.165) 35.3 69 ms 35. 692 ms 34.126 ms 8 187.at−6−0−0.XR1.TCO1.ALTER.NET (152.63.34.17) 31 .94 8 ms 31.754 ms 34.152 ms 9 193 .ATM9−0−0.GW1.TCO1.ALTER.NET (146.188.160.41) 33.437 ms 35 .94 0 ms 33.455... −j MASQUERADE [0:0] −A POSTROUTING −s 192 .168.1.6 −j MASQUERADE COMMIT # Completed on Sun Mar 24 08:35:38 2002 # Generated by iptables−save v1.2.4 on Sun Mar 24 08:35:38 2002 *filter :INPUT ACCEPT [387120:48 095 941] :FORWARD ACCEPT [1041504:20 093 3 897 ] :OUTPUT ACCEPT [ 492 803:5 492 1745] [3:108] −A INPUT −p icmp −m icmp −−icmp−type 8 −m limit −−limit 1/sec −j ACCEPT 399 [0:0] −A INPUT −i eth0 −p tcp −m limit... which was described in Chapter 11 Filesystem Tuning Filesystem settings are typically set quite conservatively to avoid putting the user's system at risk Many settings can be tweaked to optimize the filesystem Since many distributions of Linux use the ext3 filesystem, we'll be looking at ways to improve filesystem performance within an ext3 filesystem Chapter 6, "Filesystems and Disk Management," is devoted... If your system makes heavy use of such memory−intensive programs, it's important that you have enough of both memory and fast memory Memory is measured in megabytes (MB) You can find how much your system has, and roughly how it's being used, with the free command, thus: $ free total Mem: 95 772 −/+ buffers/cache: Swap: 136512 used 86748 44788 7000 free 90 24 5 098 4 1 295 12 shared 54480 buffers 5 796 cached... [1508811:283630700] :OUTPUT ACCEPT [ 492 803:5 492 1745] COMMIT # Completed on Sun Mar 24 08:35:38 2002 # Generated by iptables−save v1.2.4 on Sun Mar 24 08:35:38 2002 *nat :PREROUTING ACCEPT [11027:58 795 4] :POSTROUTING ACCEPT [26364:1785343] :OUTPUT ACCEPT [26284:1782075] [0:0] −A POSTROUTING −s 192 .168.1.3 −j MASQUERADE [0:0] −A POSTROUTING −s 192 .168.1.4 −j MASQUERADE [2:113] −A POSTROUTING −s 192 .168.1.5 −j MASQUERADE... used and free don't add up to the 128MB that the system has, because some memory is used to contain the kernel and shadow the BIOS Linux Memory Usage Many new system administrators misunderstand the high usage of memory on a Linux system and, when they see statistics like those illustrated here, believe they need to add more physical memory In reality, Linux makes very good use of the physical memory... non−journaling filesystem might have a setting like 15,552,000 seconds (6 months) To set it to 9 months, use tune2fs like this: # /sbin/tune2fs −i 23328000 /dev/hdb3 If filesystem checking is enabled, you might wish to increase these numbers on a filesystem that is seldom written to or is mounted read−only This will prevent you from having to wait while the system performs an unnecessary filesystem check... bare minimum system that should be used More common are Pentium III or Pentium IV proxy servers with 128–264MB of memory, two network cards, and 20–30GB hard drives Proxy servers are useful, but their usefulness is limited to a small subset of the available network services Proxy servers are primarily used for HTTP Linux systems can run a wide variety of network services, and most Linux systems run . ACCEPT [387120:48 095 941] :FORWARD ACCEPT [1041504:20 093 3 897 ] :OUTPUT ACCEPT [ 492 803:5 492 1745] [3:108] −A INPUT −p icmp −m icmp −−icmp−type 8 −m limit −−limit 1/sec −j ACCEPT 399 [0:0] −A INPUT. /proc/sys/net/ipv4/ip_forward Administrator's Logbook: IP Chains 392 System: E12345678 Added the following rule to prevent message traffic from 192 .168.1.23 from being passed on: ipchains −A input −s 192 .168.1.23 −j DENY Added the. rule drops all packets from 192 .168.0.11: iptables −A INPUT −s 192 .168.0.11 −j DROP This rule drops all packets that are not from 192 .168.0.11: iptables −A INPUT −s ! 192 .168.0.11 −j DROP This displays