Section 12.6 Firewalls with IP Chains and DMZ
12.6 Firewalls with IP Chains and DMZ
Certainly, you will want a firewall between the Internet and your systems. Linux makes a fine firewall platform. However, you also probably want a firewall between your public-use systems, such as your Web server and e-mail server, and the rest of your internal network, as well as between your public-use systems and the Internet. This is to protect your public-use systems from attacks and also to protect the rest of your systems in case your public use systems become compromised. Larger sites should have Intranet firewalls protecting different parts of their internal networks from each other in case of a breach, as discussed in "Intracompany Firewalls to Contain Fires" on page 84. A shop with only one or two systems may be happy using TCP Wrappers. A single system acting as a firewall can be used to protect both the internal network and the public-use systems simply by having three network cards. One Ethernet card would connect to the internal network. One Ethernet card would connect to any public-use systems, such as the Web server, public-use FTP server, and e-mail server. This usually is called a demilitarized zone or DMZ. The third card would connect to the Internet via the ISP or upstream provider and may be an Ethernet card, a T1 card, a T3 card, a modem providing PPP, etc. You will want at least kernel 2.2.11 and IP Chains 1.3.9.
The IP Chains facility has been available starting with the 2.2 kernel and is offered with 2.4 as well. Unfortunately, in the 2.4 kernel, developers did not bother to support port forwarding or a few protocols that had been supported under 2.2, such as Quake, Real Audio, and Cuseeme with IP Masquerading. IP Chains is available with all major distributions. The now rather obsolete older facility was called ipfwadm and will not be discussed here. (If you are worried about firewalls and are using an older kernel, then it is time to upgrade anyway to avoid various problems. If you are determined to stay with the older kernel and use ipfwadm then most of what is discussed here can be done with ipfwadm, too.) The basic concept is that you specify which packets will be allowed to continue on their journey. The restriction can be any combination of source and destination system IP addresses, protocol type, port numbers, whether the packet is the "SYN" packet that initiates a TCP/IP connection, and interfaces on which the packets came in. Why would anyone use TCP Wrappers instead? TCP Wrappers is easier to set up. A site having a single system, such as in many home installations, will not see a major advantage of IP Chains. The performance differences will be negligible when using anything less than a 10-Mbps feed. Even the ability to control ICMP is not significant as the kernel offers other ways to control the most important ICMP packet types, such as ECHO.
There are some settings that are important on the firewall system that typically are not done with ipchains; they are necessary to prevent certain attacks. These include:
Be sure to review "Intracompany Firewalls to Contain Fires" on page 84 for some considerations for additional custom rules that you may need. 12.6.1 What IP Chains Cannot DoIP Chains implements what is called a stateless firewall. This means that the decision to allow a packet through is made solely by its source and destination addresses, port number, and protocol. It lacks the feature of a stateful firewall that can accumulate a sequence of TCP packets, acknowledge each of them itself, and then decide whether to allow continued communication. This would allow protecting against a TCP SYN flood attack, also known as a Half-open attack because the attacker sends only one of the two TCP packets needed to complete an open-session sequence. A stateful firewall will send the proper acknowledgment to the first packet on behalf of whichever machine is a server for that TCP service. The firewall will wait for the final packet in this sequence to be received. Then, it will send a copy of the initial packet to the actual server, wait for its response, then send a copy of the final packet. If that final packet from the client does not come within a short period of time, the stateful firewall will forget that the first packet ever was received. This protects the servers against the SYN flood attack. Note that all recent Linux kernels can protect themselves against this attack if configured to do so. The Linux implementation that defends against this attack is rather clever, and there is no significant loss of efficiency even when under an intense attack. This attack is explained in "SYN Flood Attack Explained" on page 245, and the proper configuration to resist it is given in "Defeating SYN Flood Attacks" on page 245. Certainly, each Linux system that might receive TCP connections from untrusted systems should be configured to resist a SYN flood attack. Another feature present in some commercial firewalls that goes beyond the features of IP Chains is content filtering. This is where the firewall looks beyond the protocol headers, looks at the actual data in the packets, and does filtering based on the data. For example, one might filter out any e-mail that contains an attachment that a Microsoft mail client might interpret as a visual basic (.vbs) or .exe program to block viruses. Another possibility might be to block HTTP traffic whose content or URL is considered inappropriate by management, Human Resources, or the Legal Department for the workplace or during working hours. This would be the inappropriate disclosure of confidential data, threatening or harassing e-mail, searching for jobs in other companies, visiting sites unrelated to the organization's goals during working hours, and the like. Many organizations are interested in this feature because the law in some jurisdictions holds them liable for the actions of their employees or for competitive reasons, rather than because they have an interest in being a moral arbiter. Squid and Squidguard offer content filtering of URLs but not of the information in the pages themselves. This seems to be a philosophical decision rather than a technical one. Sendmail has a limited filtering capability at present. Some Intrusion Detection Systems, such as Snort, have a filtering capability. See "Stateful Firewalls" on page 510, "Using Sendmail to Block E-Mail Attacks" on page 393, and "The Snort Attack Detector" on page 598. For URL-based content filtering, Cerberian (www.cerberian.com) offers a well-designed commercial product that interfaces with Squid and connects to their huge database of categorized sites. You can block any combination of categories, such as gambling, shopping, various classes of naked people, leisure activities, etc. I have researched this product and am impressed with its capabilities. Another content-filtering product comes from Surf Control (www.surfcontrol.com), which offers a business version for UNIX computers. There are others. Consult your favorite search engine for links to other content-filtering products. On the surface, all of the URL-based content-filtering products are roughly equivalent, so we will let their respective marketing departments try to convince you of their superiority. The Cerberian product got the commercial product "Author's Choice" nod because it works with Squid, one of my favorite open-source projects. 12.6.2 IP Masquerading (NAT) Explained (For IP Chains)These days almost everyone's internal network is Masqueraded. This means that the IP addresses of the internal systems are private and not addressable from the Internet. Exceptions to this would be a typical DMZ, those few organizations with as many public IP addresses available as machines, and servers at an ISP's collocation facility. Even then, Masquerading of these systems that will not be offering services to the Internet offers them some security. Thus, understanding IP Masquerading is necessary for most SysAdmins and those with home networks. When an IP packet is received, the kernel goes down a list of rules until it finds a rule matching the packet; then it handles the packet in the manner that the rule specifies. If no matching rule is found, the default action is taken. It is called a chain instead of a list to confuse everyone, especially those that know that this type of data structure is called a list. This concept is similar to TCP Wrappers or lots of other configurable programs as diverse as login and nfsd. For example, when you log in, the login program reads your user name and then goes down the list of user names in /etc/passwd until it finds the matching one and, if the correct password is supplied, executes the rule. This includes setting your UID, GID, home directory, and shell. IP Chains allows Masquerading. This concept, while very powerful, frequently is misunderstood. It means simply that the firewall system can allow the systems behind it (i.e., on the organization's internal network) to pretend to be the firewall system. This means that if a system behind (or inside) the firewall sends a packet to a system outside of the firewall, it will appear to that outside system as if the packet originated from the firewall system itself. The firewall system will assign a port number temporarily to serve as the source of this packet. That outgoing packet's source address will be that of the firewall system itself rather than that of the originating system, from the point of view of the outside system. When the outside system sends its reply packet, it will have a destination address of the firewall system and a destination port number that the firewall is using as the temporary source. When the firewall receives this packet, it will determine which Masqueraded system and port are associated with this temporary source port and it will send the packet on to that system. Note that the inside system will see the packets as coming from the actual server system but the server system (and all systems along the way outside of the firewall) will see the packets as coming from the firewall system itself. This is illustrated in Figure 12.4. Figure 12.4. Masquerading packets.
In Figure 12.4, you see that research.pentacorp.com is on the Corporate Ethernet with a Masqueraded address. In other words, its address was not accessible, or routable, from the Internet. This protects it from almost all Internet attacks.[21]
In this figure, we have three machines, the Internet server at www.linuxjournal.com, the firewall at pentacorp.com, and the internal workstation at research.pentacorp.com. We will follow the request packet from research.pentacorp.com (r.p.c.) through the firewall (p.c.) to the Web server at linuxjournal.com (l.c.) and will follow the reply packet back to r.p.c.
The r.p.c. system is none the wiser that somebody has been mucking with its packets and neither is l.c. There are two common reasons for using IP Masquerading. The first, particularly common for home networks, is to avoid being trapped by many ISPs "not allowing" more than one home system. They do this simply by assigning you a single IP address and only allowing traffic from that address through their site. When you are using IP Masquerading, that is all that the ISP sees. The second reason for using Masquerading is for increased security at your site. Because you are using a private network address, a cracker cannot send packets to any of your systems behind the firewall because packets with private IP address destinations are not routed through the Internet. If you will be Masquerading an internal network, it is best to use one of the official network addresses assigned by IANA in RFC1597 for this purpose. This avoids any danger of accidentally conflicting with an actual network connected to the Internet. There is one private class-A network, 16 class-B networks, and 256 class-C networks available for this purpose. They are shown in Table 12.4.
Note that 172.16.*.* is the first class-B network, 172.17.*.* is the second, etc. The first class-C network is 192.168.0.*, the second one is 192.168.1.*, and so on. IP Chains allows the kernel to do one of three different things to a packet.
There are three different chains, or lists, of rules. At each stage, if the packet is not accepted then that is the end of the packet (except if the packet is rejected, the kernel will notify the sending system). The first chain or list is the input chain. Once a packet has been received by the kernel and its checksum checks out and it does not appear to be corrupted, it is subjected to input chain rules. If it is accepted, it is considered for de-Masquerading. If its destination IP is the firewall and the destination port is one of those allocated for Masquerading, the destination IP and port are changed to those of the machine being Masqueraded and the packet then is sent to be processed by the output chain. If the incoming packet is not being de-Masqueraded, then normal routing takes place. If routing indicates that the destination is the firewall itself, then it is sent to the port requested to be received by the process listening on that port. Packets generated by local processes go directly to the output chain for processing. If the routing table says that the packet should be routed to another machine, the packet then is processed by the forward chain. Any packet that originated from someplace other than the firewall system itself and whose destination is other than the firewall system will be subject to the forward chain rules. Packets that pass the forward chain and packets that are generated on the firewall itself then are processed according to the output chain rules. Those that pass go on their merry way. This is illustrated in Figure 12.5. Figure 12.5. Traversing the firewall using IP Chains.
As you see in Figure 12.5, each packet is subject to up to three IP Chains of rules. The versatility of this arrangement is not always clear at first. While some may worry about the performance implications of all of these tests, since the work is done entirely in the kernel, performance is excellent. Even a 486 should be able to service a T1 or E1.
12.6.3 IP Chains CommandsSome people may want to avoid this section and skip to "Basic IP Chains Firewall Usage" on page 527. While you could issue commands directly to the kernel using the setsockopt() system call, the vast majority of you will want to use the ipchains program. Only the most commonly used features will be covered here. The -P flag allows specifying the default policy for a chain if none of the rules in that chain are matched. The chain names are input, forward, and output. For any chain, the default policy or target may be ACCEPT, DENY, or REJECT. The syntax looks like ipchains -P chain target [options] To add a rule to the end of a chain, the -A flag is used. This is the most frequently used flag. The syntax looks like ipchains -A chain rule [options] A rule may include an interface specification, a source IP address and port, a destination IP address and port, a protocol specification, and a target or disposition for the packet. Each of these is introduced with a dash (-) and the type of item, followed by the value. The value may be preceded by a bang (!) to mean not that value. An interface is specified by -i or --interface, possibly followed by a bang (!), followed by the name of the interface as shown by ifconfig. If the name ends in +, it will act as a wildcard similarly to the way an asterisk (*) does for other programs. These are some typical interface specifications. -i eth0 -i ! ppp0 A source address is specified by -s or --source; a destination address is specified by -d or --destination. Each of these accepts an IP address, specified either by host name or by numeric dotted quad. The quad may be followed by a slash (/) and a number indicating the quantity of high-order bits that should be matched. Instead of this number, a dotted quad may be used with each 1 bit tested. The rest of the bits of the address are ignored and may be anything. This address may be followed by a port name, port number, range of port numbers, or ICMP message number or name. The range is indicated by separating a pair of ports with a colon (:). Port names are looked up in /etc/services. If either the low or high port numbers of a colon-separated range are omitted, it defaults to 0 or 65535, respectively. If no port is specified, then the rule applies to all. If the protocol type is ICMP, then the "port number" instead should be the numeric ICMP code. Some examples are -s www.pentacorp.com 80 -d mail.pentacorp.com ! smtp -s 192.168.0.0/16 1024:65535 Instead of including the source or destination ports with the respective addresses, any of --source-port, --sport, --destination-port, or --dport may be used. Finally, the --icmp-type flag may be used to specify an ICMP message name. The most commonly specified ones are listed in Table 12.5. There are alternate ways to block ICMP echos that may be preferable in some cases, discussed in "Kernel Protocol Switches" on page 80.
A fragment (i.e., the second or subsequent packets of a fragmented message) may be matched with -f. The first fragment may be matched with ! -f. The -t flag will alter the TOS that affects the delay, throughput, reliability, and cost in the handling of the packet. This is implemented by having multiple queues; the TOS determines which queue. Thus, telnet requests do not need to get stuck behind a massive queue of ftp data packets. The types of service, the arguments for -t to specify them, and the typical uses are listed in Table 12.6.
Possible rules to implement this are listed below. ipchains -A output -p tcp --dport telnet -t 0x01 0x10 ipchains -A output -p tcp --dport ftp -t 0x01 0x10 ipchains -A output -p tcp --dport payroll -t 0x01 0x04 ipchains -A output -p tcp --dport nntp -t 0x01 0x02 Finally, what to do if the packet matches this rule may be specified with the -j or --jump flags, each of which requires a target. That target normally is ACCEPT, DENY, REJECT, or MASQ, but may be a user-defined chain. The target names are case-sensitive. If there is no -j, then this rule will cause only side effects, such as logging and updating counts. The -y flag may be used with -A or -C, either to require or to set the packet's SYN bit that indicates it is the first packet of a three-way TCP open. The -F command causes all rules in the specified chain to be flushed (deleted). If no chain was specified, then all rules will be flushed. The -L command will list all rules in the specified chain or in all chains. The -C command is extremely helpful by allowing you to test the specified packet against the rules. The packet is specified in the same way as if you were specifying a rule. The -s, -d, and -i flags must be used. The -h command offers help. The -v flag causes verbosity. 12.6.4 Starting a Firewall ScriptNow, let us put this information to use. We will build a standard firewall for a small organization that could be a small company or a home network. We will follow the standard convention that eth0 will be the interface going to the Internet and eth1 will be the interface to the internal network. Many home networks are now connected to the Internet via DSL or cable modems, and the interface devices typically offer Ethernet on your side. (For those using PPP, the only difference is that the Internet interface will be ppp0 and the internal interface probably will be eth0.) The number one priority must be protection against crackers. Trying to "allow everything but what we fear" is too prone to errors, so we will "deny or reject everything but what we specifically allow." If this causes us to stop and scratch our heads occasionally when bringing up a new service or system, this is much preferable to our kicking ourselves because we let a cracker through. Thus, we will follow the standard procedure of blocking everything and letting in specific types of packets that we consider safe. I prefer to do this before network interfaces are brought up, to avoid race conditions where attackers are lying in wait. On distributions that use the System V style of startup scripts, such as Red Hat and Mandrake, the scripts will be in /etc/rc.d/rc3.d and S10network will be the script that starts networking.
Create a script called ipchains_pre in /etc/rc.d/init.d (or wherever startup scripts belong in your distribution) that contains the following commands to block all packets and flush (remove) any existing rules. We supply the full path name of ipchains; you may need to adjust this. #!/bin/sh IPC=/sbin/ipchains $IPC -P input DENY $IPC -P output REJECT $IPC -P forward REJECT # Danger: do not flush until policy is DENY or REJECT $IPC -F While in the /etc/rc.d/init.d directory, issue the following commands to set this up and activate it. chmod 755 ipchains_pre cd ../rc3.d ln -s ../init.d/ipchains_pre S09ipchains_pre ./S09ipchains_pre Congratulations. You have implemented your first IP Chains rules. On distributions that do not use the System V style of startup scripts, such as Slackware, the commands may be added to the beginning of /etc/rc.d/rc.inet1 or wherever appropriate. The S09ipchains_pre script denied all packets attempting to go into or out of the system. Now, we need to enable packets with acceptable qualities to move. First, pick a name for the script that the vast majority of ipchain commands will reside in. For this example, /etc/rc.d/rc.fw will be used. (Those that prefer more descriptive names are welcome, of course, to use /etc/rc.d/rc.firewall or any name of their choosing instead.) This file should be owned by root and have mode 700. Because a cracker can probe your system easily to determine what is allowed, preventing ordinary users from seeing this file will not have a major effect on security. The various scripts discussed elsewhere that offer various protections, such as source address verification and limitations on echos, may be combined in rc.fw if desired. For those blessed with a static IP address, rc.fw need be invoked only from /etc/rc.d/rc.local (in all distributions) or from near the end of /etc/sysconfig/network-scripts/ifup on Red Hat and its derivatives. For those that did something bad in a previous life and are condemned to using Dynamic Host Configuration Protocol (DHCP), this script also should be called when the IP address changes. This script will be easy to use, easy to change, and limit hard-wired values. It will be a Bourne shell script, though conversion to csh for those so inclined will be easy. The EXTBITS and INTBITS specify the number of high order bits that specify the network part of the address (i.e. 8 for a class-A network, 16 for a class-B network, 24 for a class-C network, and differing numbers for subnets). The LPD* entries are for the loopback device. This is a simulated device to allow network-based operations, such as X and internal testing of client/server systems, to work even on systems without networking hardware. Note that the addr/bits notation means that the high order bits of addr are significant for matching and that the values of the other bits are ignored during comparisons. Some of our principal variables are listed in Table 12.7. The start of rc.fw could look like the following to set up these variables. Note that you will compute the IP addresses using ifconfig. This allows you to avoid dealing with pump or other lower life forms. We use EXTIP and INTIP so that if you upgrade from a dial-up connection to DSL or cable, only two lines need to change. Note, too, that during this upgrade you will not need to alter this script to work with DHCP, which likely will be inflicted on you. So far, the script looks thusly.
#!/bin/sh # # /etc/rc.d/rc.fw: configure firewall rules # # Invoked from /etc/rc.d/rc.local or from near the # end of /etc/sysconfig/network-scripts/ifup # and from DHCP if DHCP used # echo "Starting Firewall" # IPC=/sbin/ipchains ORG=pentacorp.com #EXTIF=ppp0 #INTIF=eth0 EXTIF=eth0 INTIF=eth1 LPDIF=lo EXTBITS=16 INTBITS=16 LPDBITS=8 EXTIP="`/sbin/ifconfig $EXTIF|grep addr:\ |sed 's/.*addr:\([^ ]*\) .*/\1/'`" INTIP="`/sbin/ifconfig $INTIF|grep addr:\ |sed 's/.*addr:\([^ ]*\) .*/\1/'`" LPDIP=127.0.0.1 EXTNET="$EXTBC"/$EXTBITS INTNET="$INTBC"/$INTBITS LPDNET=127.255.255.255/$LPDBITS EXTBC="`/sbin/ifconfig $EXTIF|grep Bcast:\ |sed 's/.*Bcast:\([^ ]*\) .*/\1/'`" INTBC="`/sbin/ifconfig $INTIF|grep Bcast:\ |sed 's/.*Bcast:\([^ ]*\) .*/\1/'`" ANY="any/0" First, we will repeat the commands of ipchains_pre to flush (or remove) any existing rules, then set the policy (or default) to block all packets. This is needed in case this script is called more than once. Note that this implies that if pump detects a new DHCP lease with the same IP address, the script that it calls to invoke rc.fw should be smart enough not to call rc.fw. Otherwise, existing connections may be lost. $IPC -P input DENY $IPC -P output REJECT $IPC -P forward REJECT $IPC -F # Rules follow 12.6.5 Basic IP Chains Firewall UsageNow, we will build on the script that was started in the previous section. The -A flag instructs ipchains to add the rule to the end of the chain. There are other flags to insert rules in the middle of chains or to alter existing rules but those will not be needed here. We will allow any packets coming in on the loopback device with a proper source address and we will allow any going out to it with a proper destination address. There should be only packets with a source and destination of $LPDIP on this interface. Other addresses could be a misconfiguration or bug or could be an attempt at cracking; in any of these cases, blocking bad packets is the purpose of the firewall. The -A flag causes this rule to be added to the end of the chain. The -i flag specifies the interface to which this rule applies; for systems with more than one interface this is important. The -s flag indicates that the following argument should be used to match source IP addresses. The -d flag causes the following argument to be matched against the destination address. Finally, the -j flag specifies what the kernel should do with the packet if all of the conditions match. Capitalization is significant to -j. The -l flag causes the kernel to log each occurrence of that rule matching, using syslogd. It is a good idea to start by logging each rule that detects a security violation. The results will surprise you. If any of the conditions do not match, the kernel tests subsequent rules either until a match occurs or until the end of the chain is reached. If the end is reached, the policy is executed. This may result in the packet being executed (i.e., dropped or rejected). The rules for the loopback device follow. $IPC -A input -i $LPDIF -s $LPDIP -j ACCEPT $IPC -A output -i $LPDIF -d $LPDIP -j ACCEPT Use a similar philosophy for the internal network. It is more important here to block packets that have incorrect source addresses. On a large network, there is the chance that these originate from someone operating from an internal system trying to crack someone else on the Internet. As good net citizens (who also do not want to receive visits from the Men in Black), we will be very careful about this. This is known as Egress filtering; it is explained more thoroughly in "Egress Filtering" on page 81. The rules follow. $IPC -A input -i $INTIF -s $INTNET -j ACCEPT $IPC -A output -i $INTIF -d $INTNET -j ACCEPT As you can see, packets coming in from the internal interface must have an internal source address and packets destined for it must have a destination address that is internal, or they will end up in the bit bucket. 12.6.6 Blocking External EvilDeciding what to block is more of an art than a science and there is no one right way to do it; you definitely should alter these rules as needed for your installation. There is nothing wrong with having redundant rules when trying to block evil packets; the performance penalty is insignificant unless you have a T3 (44.736 Mbaud). First, you will need to block external packets that have a source address claiming to be from internal systems; this is a common attack technique that used to be quite successful. Source address verification will block this on a correctly configured system but an error in routing will prevent that check. We will have it here to add to our Rings of Security; source address verification was discussed in "Blocking IP Spoofing" on page 134. The rules are similar to those of the internal interface except that we will invert them and block them. The reason for this is that even if they pass this test, we will have more tests that they must pass. In the first rule, we will DENY bad packets (or throw them away without notifying the sender). The reason we do not notify the sender is because the sender is either evil or badly misconfigured; there is no reason to tell him. Not telling him cuts in half the bandwidth that he was wasting. This savings in bandwidth is significant if we fall under a DoS attack where the sender tries to bury us in junk packets. The DENY also prevents an attacker from using you to attack a third party by supplying a fake source address of the third party to be attacked. (Such an attack would show as coming from you, a really bad thing.) Any bad packets destined for the Internet also will be denied. Any traffic from the Internet that does not specify a destination that is on your internal network also will be denied as yet another third party attack. Internally generated traffic destined for the Internet with bad destination addresses will be rejected as well. This means that the sending machine will be notified. If we wrote our rules correctly, this will necessarily be an internal machine because externally originating packets already have been denied. If the sender truly is a misconfiguration, the REJECT will prevent that machine's retry algorithms from repeatedly sending this bad packet. Thus, REJECT will cause less bandwidth to be used than DENY. $IPC -A input -i $EXTIF -s $INTNET -j DENY -l $IPC -A input -i $EXTIF -s $LPDNET -j DENY -l $IPC -A input -i $EXTIF ! -d $INTNET -j DENY -l Next, we will want to block broadcast packets. Externally originating packets should never be broadcasting, with the possible exception of your ISP's DHCP broadcasts. Those that are broadcasting are almost guaranteed to be crackers attempting Smurf attacks or other evil. One possibility is that the cracker is trying to use our network as an amplifier, that is, getting all of our machines to generate traffic to a third party, who is the intended victim. Another common possibility is that the cracker does not know what our machines' IP addresses are so he will use a broadcast to see what IP addresses respond. Smurf attacks and amplifiers are discussed in "Packet Storms, Smurf Attacks, and Fraggles" on page 246. The rules are unsurprising. $IPC -A input -i $EXTIF -d $INTBC -j DENY -l So far, we have not let any packets come in from the Internet. At this point, we list evil sites that we want to block. Someone from crackers.com has tried to break in; the IP address is 207.68.156.69 and we certainly do not want anyone at www.rootkit.com to bother us. We are suing the Sticky Fingers Corporation for hiring away too many of our engineers, so we do not allow our people to contact them. Their class-B network is 208.184.0.0; we do a REJECT rather than a DENY, for fun. The appropriate entries are below. $IPC -A input -i $EXTIF -s 207.68.156.69 -j DENY -l $IPC -A input -i $EXTIF -s www.rootkit.com -j DENY -l $IPC -A input -i $EXTIF -s 208.184.0.0/16 -j REJECT -l $IPC -A output -i $EXTIF -d 208.184.0.0/16 -j REJECT -l Large sites will accumulate a large list of these and may want to place these commands in a separate file and include it from rc.fw. If we call this file fw.trouble, then the following line will read it. . /etc/rc.d/fw.trouble This would be a good place to block some exploits explicitly, even though the default actions should catch them. This includes blocking X (except through SSH). Each X display uses a separate TCP port, starting with 6000. The highest theoretical port could be 6063, but SSH starts allocating encrypted X ports at 6010. Fortunately, the SSH connection always is local to a given machine; it enables locally running X-enabled programs to connect to the local SSH client. This means that it is safe to block X ports between 6000 and 6063, including SSH ports that start at 6010. NFS and friends and TCP DNS requests (that could be used to download information about your internal systems) should be blocked, as should access to Socks (the proxy server). Socks is available at www.socks.nec.com/ The rsh and related protocols absolutely must not be allowed. Even if policy forbids them, someone will create a setup for easy access from his home system. By blocking rsh at the firewall this will not be a security problem. You should also block syslogd and printer services. The rules follow; use --dport and --sport to specify ranges of destination and source ports. While there is not a need to block UDP X ports, it could not hurt either. $IPC -A input -i $EXTIF -p TCP --dport 6000:6063 -j DENY -l $IPC -A output -i $EXTIF -p TCP --sport 6000:6063 -j DENY -l $IPC -A input -i $EXTIF -p TCP --dport 2049 -j DENY -l $IPC -A output -i $EXTIF -p TCP --sport 2049 -j DENY -l $IPC -A input -i $EXTIF -p TCP --dport 111 -j DENY -l $IPC -A output -i $EXTIF -p TCP --sport 111 -j DENY -l $IPC -A input -i $EXTIF -p TCP --dport 53 -j DENY -l $IPC -A output -i $EXTIF -p TCP --sport 53 -j DENY -l $IPC -A input -i $EXTIF -p TCP --dport 1080 -j DENY -l $IPC -A output -i $EXTIF -p TCP --sport 1080 -j DENY -l $IPC -A input -i $EXTIF -p TCP --dport 512:515 -j DENY -l $IPC -A output -i $EXTIF -p TCP --sport 512:515 -j DENY -l Now, it is time to consider UDP packets. Recall that because there is no hard-to-guess sequence number for TCP, UDP packets are trivial to spoof. Thus, you cannot trust the source address in any UDP packet. This is discussed in detail in "Why UDP Packet Spoofing Is Successful" on page 242. This is one of the reasons that few services use UDP. One that does is NFS, and you certainly do not want anyone using it over the Internet unless you operate a public NFS server. In almost all cases, anonymous FTP is preferable because it makes it much harder for an attacker to use a fake source address. Our example company has two DNS servers, dns.pentacorp.com, which is available to external sites and cid.pentacorp.com, which talks only to our internal systems. If you are burdened with your ISP thrusting DHCP upon you, then you need to let in this evil UDP protocol. Hopefully, your ISP has its firewalls configured to prevent other customers and outside crackers from injecting these packets. If you are on a cable modem in a LAN configuration with 100 of your neighbors, then any of them can spoof these. The only solution to this spoofing is to rely on this address rarely changing and manually updating it. In this case, you simply would not run the DHCP client normally. We also discover that we have an engineer who likes to use talk from his system, chatty, to a vendor at the Money40 company. The associate at the vendor uses a host system called fleece. Use the target ACCEPT to accept the packet. Any source or destination address may be followed by a port name defined in /etc/services or by a port number. The rules for all of this are as follows. $IPC -A input -i $EXTIF -p UDP -d dns.$ORG 53 -j ACCEPT $IPC -A input -i $EXTIF -p UDP -s dhcp.isp.com 68 -j ACCEPT $IPC -A input -i $EXTIF -p UDP -s fleece.money40.com \ -d chatty.$ORG ntalk -j ACCEPT $IPC -A input -i $EXTIF -p UDP -j DENY -l We grant public access to our Web, anonymous FTP, and mail servers. For FTP data transfer, we can allow remote systems to access our FTP server's data port and also allow passive mode, used by most Web browsers, which requires access to our unprivileged ports. We can also allow our travelling people to use SSL-protected pop3 and imap; one engineer wants to do this from his Linux box, arrow. Since no UDP packets get past the previous rules, we do not need to worry about them further. Some will want to add -l to these rules to detect attacks. $IPC -A input -i $EXTIF -p TCP -d www.$ORG www -j ACCEPT $IPC -A input -i $EXTIF -p TCP -d www.$ORG https -j ACCEPT $IPC -A input -i $EXTIF -p TCP -d ftp.$ORG ftp -j ACCEPT $IPC -A input -i $EXTIF -p TCP -d ftp.$ORG ftp-data -j ACCEPT $IPC -A input -i $EXTIF -p TCP -d ftp.$ORG 1024:65535 -j ACCEPT $IPC -A input -i $EXTIF -p TCP -d mail.$ORG smtp -j ACCEPT $IPC -A input -i $EXTIF -p TCP -d mail.$ORG spop3 -j ACCEPT $IPC -A input -i $EXTIF -p TCP -d mail.$ORG simap -j ACCEPT $IPC -A input -i $EXTIF -p TCP -d arrow.$ORG spop3 -j ACCEPT When one of your people connects to a remote site via TCP, the remote site may use the auth protocol (ident) to query your system for the user name or UID of the person requesting the remote service. This allows the remote system to verify that the request was not spoofed, though spoofing is hard to do with TCP. While useful, by allowing remote sites to increase their security, you are also allowing any cracker to probe your network and attempt to crack your systems through auth vulnerabilities. This is where proxy servers and Masquerading can help. I would lean toward not allowing this service and, for those that do, ensuring that their auth servers give out only UIDs, not user names. The ident service is discussed in detail in "The ident Service" on page 231, including discussion on using an ident daemon that provides fake user names to prevent crackers from using the account names to launch password-guessing attacks. If you operate proxy servers, you may want to allow ident only to them. The rule to enable it, if you choose to do so, is as follows. $IPC -A input -i $EXTIF -p TCP auth -j ACCEPT We choose to grant SSH access to any machine. We will specify the port number, numerically, and the protocol as an extra precaution because we are granting access to any machine. Some of you will want to list individual machines instead. $IPC -A input -i $EXTIF -p TCP --dport 22 -j ACCEPT So far, for Internet traffic, we have allowed access only to specific machines or ports. Finally, we choose to allow in "return" packets from TCP connections initiated from our internal network. Recall from "TCP Sequence Spoofing Explained" on page 243 that only the packet that starts a TCP connection has the SYN bit set. The ipchains program accepts the --syn or -y flag to specify packets with just the SYN bit set. This flag may be preceded by a ! to mean "not these packets." We will allow our internal systems to send packets to the Internet here. The standard entries to do this would be as follows. $IPC -A input -i $EXTIF -p TCP ! --syn -d $INTNET -j ACCEPT $IPC -A output -i $EXTIF ! -p ICMP -s $INTNET -j ACCEPT Understand that this allows any cracker to probe your network and learn the IP addresses of all of your systems and to learn what services they support. This is because a cracker merely needs to send one of these noninitial packets to each IP address and see which ones say "sorry, we have not established a connection" in order to discover them. Then, he does this to each port of these discovered systems. This is what crackers use nmap for; it is discussed in "The nmap Network Mapper" on page 592. Some sites will set up proxy servers for services such as www and ftp to combat this. This means that internal systems will connect to a server and ask it to forward a request, such as getting a www page. The proxy server then forwards the reply (i.e., the Web page) to the user's system. If all services that users want have proxies, then all direct traffic from users' systems to the Internet may be blocked, yielding a much more secure firewall. The Socks service is one that is a proxy server for www. For those of you with home networks, configuring your system that connects to the network as a proxy server also gets around the issue of ISPs allowing the user only a single system so that those with more than one machine can be charged commercial rates. IP Masquerading is an alternative. ICMP is used for "control" messages. It is neither TCP or UDP, but it is a peer to these protocols. Source Quench is used to tell a sender that it is sending faster than can be received. It is ICMP message type 4. The Parameter Problem Status indicates a problem with the packet, probably a bad checksum. These messages should be passed with $IPC -A input -i $EXTIF -p ICMP -s $ANY 4 -d $INTNET -j ACCEPT $IPC -A output -i $EXTIF -p ICMP -s $INTNET 4 -d $ANY -j ACCEPT $IPC -A input -i $EXTIF -p ICMP -s $ANY 12 -d $INTNET -j ACCEPT $IPC -A output -i $EXTIF -p ICMP -s $INTNET 12 -d $ANY -j ACCEPT ICMP type 3 messages are used for two important functions: when a destination is unreachable and when fragmentation is needed. Since crackers use these to map your site (find out what IP addresses your systems are on and what services they offer), it would be desirable to block them. Their techniques are discussed in "Tunneling Through Firewalls" on page 77. Unfortunately, completely blocking these messages would disrupt operations. IP Masquerading is a solution. We can choose allow type 11 (i.e., time exceeded) messages to come in so that our traceroute requests will work. The firewall rules follow. $IPC -A input -i $EXTIF -p ICMP -s $ANY 3 -d $INTNET -j ACCEPT $IPC -A input -i $EXTIF -p ICMP -s $ANY 11 -d $INTNET -j ACCEPT $IPC -A output -i $EXTIF -p ICMP -s $INTNET 3 -d $ANY -j ACCEPT Some of you may instead want to experiment with the following. The $ISP should be the IP address of your ISP's system that may be used to monitor connectivity to diagnose errors. It would be used by traceroute, to which you may or may not want to offer general access. These rules would be as follows. $IPC -A input -i $EXTIF -p ICMP -s $ANY 3 -d $INTNET -j ACCEPT $IPC -A output -i $EXTIF -p ICMP -s $INTNET 3 -d $ISP -j ACCEPT $IPC -A output -i $EXTIF -p ICMP -s $INTNET fragmentation-needed \ -d $ANY -j ACCEPT Most sites want to allow their people to ping outside systems to test for problems. Be aware that the ping-reply packet that comes back also can and has been used by crackers. This is how the dreaded TFN2000 DDoS Trojan communicates. This Trojan is explained in "Stealth Trojan Horses" on page 400. It is hard to defend against but solutions include using IP Masquerading, searching for your systems that have Ethernet cards in Promiscuous mode (e.g., what TFN2000 uses to listen for echo replies), and installing a stateful firewall. A stateful firewall, which is beyond the scope of this book, will receive the echo reply, note that the host listed as its destination has not sent an echo request (or ping) recently, conclude that it is from a cracker, and drop it. The echo request is type 8; the echo reply is type 0. The appropriate rules are listed. $IPC -A output -i $EXTIF -p ICMP -s $INTNET 8 -d $ANY -j ACCEPT $IPC -A input -i $EXTIF -p ICMP -s $ANY 0 -d $INTNET -j ACCEPT You may want to allow some sites to ping you, for example a vendor with whom you work closely or an employee working from a home system. $IPC -A input -i $EXTIF -p ICMP -s fleece.money40.com 8 \ -d chatty.$ORG -j ACCEPT $IPC -A output -i $EXTIF -p ICMP -d fleece.money40.com 0 \ -s chatty.$ORG -j ACCEPT Lastly, while the policy will reject any packets that the above rules do not accept, this rejection will not be logged; generally, you want to know what evil is being turned away. You will not want to be bothered for certain kinds of frequent attacks, such as packets with impossible source addresses. These would include private addresses, such as 10.*.*.*, which cannot be traced anyway. The solution is to add a final rule to each chain to deny or reject all, with logging enabled. The rules for this are simple. $IPC -A input DENY -l $IPC -A output REJECT -l The complete set of rules is shown in Table 12.8. The file, rc.fw, is available on the CD-ROM.
The company that funded the GPL'ed Linux IP Chains also sells a Linux-based firewall box that you may want to purchase. Their URL is www.watchguard.com There is a stateful firewall at ftp://ftp.interlinx.bc.ca/pub/spf 12.6.7 IP MasqueradingIP Masquerading is a wonderful feature that allows your Linux firewall to hide your internal network from the outside world. There are two good reasons for wanting to do this. The first is that you have only one externally visible IP address to work with. The other reason is increased security. When people from the outside world cannot see your network, they cannot attack it as long as they cannot break your firewall. Assume that one of your systems sends out a request, say, to connect to port 80 on www.pentacorp.com. The firewall system's kernel instead sends out a packet with its own address (on the external interface) as the source address. Also, it will allocate a temporary port as the source port. When Pentacorp's Web server responds, its packet will have the destination address of your firewall and the destination port number of your temporary port. Because the Masquerading code in the kernel maintains a table of Masquerades, it then will send out a packet to your system behind it that originated the request. The destination port will be the same as the source port in the original request. This happens fast and transparently to all parties. Note that systems behind the firewall cannot be servers directly because, well, they are hidden but there is software that can map ports on the firewall to systems behind it. Systems behind the firewall can be servers by using the redir program on the firewall; SSH has this redirection built into it, though the encryption and decryption will waste cycles. The 2.2 and later kernels offer this redirection capability, too. They call it port forwarding. Enabling it is very easy. The rules that were discussed in "Blocking External Evil" on page 528 may remain the same. The addresses have been changed to protect the innocent. Instead of our addresses on our internal network being obtained from our ISP (or upstream provider), we pick a private network address. For this example, we will use the official private class-C network address 192.168.1.*. You can use it, too. By convention, a router is host 1 so, assuming our external interface is eth0 and our internal interface is eth1, our eth1 address will be 192.168.1.1. On Red Hat and its progeny, you would put the following in the ifcfg-eth1 file in /etc/sysconfig/network-scripts. DEVICE=eth1 BROADCAST=192.168.1.255 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 ONBOOT=yes Next, add the magic words to rc.fw to activate Masquerading and enable Forwarding. ipchains -A forward -s 192.168.1.0/24 -j MASQ echo 1 > /proc/sys/net/ipv4/ip_forward Add the following routing instruction to rc.fw. route add -net 192.168.1.0 netmask 255.255.255.0 $INTIF If you would rather place the instruction in the /etc/sysconfig/static-routes file, it would be eth1 net 192.168.1.0 netmask 255.255.255.0 Finally, you need to "bounce" the interface and invoke your updated firewall script via /etc/sysconfig/network-scripts/ifdown eth1 /etc/sysconfig/network-scripts/ifup eth1 /etc/rc.d/rc.fw Some protocols, such as FTP (i.e., the active mode used by command-line tools but not browsers), RealAudio, and Quake, will take extra effort. To enable FTP, add the following command to rc.fw and it will take care of the problem. insmod ip_masq_ftp The official Masquerading Web site is http://ipmasq.cjb.net/. 12.6.8 Creating a DMZWe already have covered most of the issues involved in creating a DMZ (i.e., a demilitarized zone). Much of the reasoning and physical organization have been discussed in "Intracompany Firewalls to Contain Fires" on page 84. Usually, an organization large enough to bother with a DMZ and separate servers for FTP, WWW, etc. will not use IP Masquerading, so we could assume that it is not being used for this section. (For those that do want this combination, replace the $INTNET rules with those for IP Masquerading.) Most of the IP Chains work already has been done in "Blocking External Evil" on page 528; let's start with that configuration. The rules granting access to the systems typically found on the DMZ, such as www.pentacorp.com and ftp.pentacorp.com, from the Internet still will work. In that section, we assumed that these systems were on $INTNET and, thus, that they had outgoing access to the Internet and also that other internal systems could be accessed from them. Recall that packets intended to these systems both from the Internet and the internal network already have rules to get them into the firewall. We will need additional rules to get packets from the firewall to the DMZ net and rules to get them from the DMZ to their intended destinations. Now, we need to create those rules since they are on a separate interface. Following convention, the DMZ interface will be eth2. Again, we will build on our existing work. Your organization has a class-B network. You will use subnetting to split the lower 16 bits allocated for host bits so that the uppermost of these lower 16 bits will determine whether the destination is on the internal or DMZ network. Flipping our coin, if this bit is 1, it will mean the DMZ network, and if it is 0, the internal network. (Certainly, those wanting many subnets can allocate more bits to specify the subnet and can create multiple subnets. Since the rules for $INTNET are simple, you could add more network cards to the firewall and split out the different subnets here.) If we are working with Red Hat and its progeny, we will want to edit ifcfg-eth1 in /etc/sysconfig/network-scripts; Slackware users will want to edit /etc/rc.d/rc.inet1. Our netmask will change from 255.255.0.0 to 255.255.128.0 Similarly, our network and broadcast addresses will gain a network bit and lose a host bit. For Red Hat and friends, or possibly enemies, we then copy ifcfg-eth1 to ifcfg-eth2. Then, in ifcfg-eth2, we increase the value of the network number by 1. In other words, if the entire class-B network has a network and netmask of 216.247.0.0 255.255.0.0 then the new eth1 will have a network and netmask of 216.247.0.0 255.255.128.0 and eth2 will have a network and netmask of 216.247.128.0 255.255.128.0 In rc.fw, the setting of INTBITS must change to INTBITS=17 The following lines will need to be put into the new file rc.fwdmz, to be sourced from rc.fw via the Bourne shell's . command. DMZIF=eth2 DMZBITS=17 DMZIP="`/sbin/ifconfig $DMZIF|grep addr:\ |sed 's/.*addr:\([^ ]*\) .*/\1/'`" DMZBC="`/sbin/ifconfig $DMZIF|grep Bcast:\ |sed 's/.*Bcast:\([^ ]*\) .*/\1/'`" DMZNET="$DMZBC"/$DMZBITS Recall that evil packets from the Internet (and from the internal network) already have been denied so the OUTPUT rule allows anything to the DMZ. We allow the appropriate services to respond to queries. Because there have been many security problems with FTP, we choose not to allow our people access to the public FTP server; we choose to provide a separate internal one instead. In our initial example, the one that we are building on, one of our engineers receives e-mail directly on his Linux box, arrow. Thus, we allow a path from the mail server to it. Since sendmail, too, has had its share of security problems, we are restrictive about access from the mail server to our internal network. The rules to be added appear as follows; the file rc.fwdmz, on the CD-ROM, contains these rules and the initialization that was presented just previously. The version on the CD-ROM is incorrect; change REJECT -l to ACCEPT to correct the CD-ROM version. $IPC -A input -i $EXTIF -p ICMP -d $DMZNET -j ACCEPT $IPC -A output -i $EXTIF -p ICMP -s $DMZNET -j ACCEPT $IPC -A output -i $DMZIF -d $DMZNET -j ACCEPT $IPC -A input -i $DMZIF -p ICMP -s $DMZNET -j ACCEPT $IPC -A input -i $DMZIF -p UDP -s dns.$ORG 53 -j ACCEPT $IPC -A input -i $DMZIF -p TCP --sport 22 ! --syn -j ACCEPT $IPC -A input -i $DMZIF -p TCP -s www.$ORG www ! --syn -j ACCEPT $IPC -A input -i $DMZIF -p TCP -s www.$ORG https ! --syn -j ACCEPT $IPC -A input -i $DMZIF -p TCP -s mail.$ORG smtp ! -d $INTNET -j ACCEPT $IPC -A input -i $DMZIF -p TCP -s mail.$ORG spop3 ! --syn -j ACCEPT $IPC -A input -i $DMZIF -p TCP -s mail.$ORG simap ! --syn -j ACCEPT $IPC -A input -i $DMZIF -p TCP -s mail.$ORG smtp \ -d arrow.$ORG smtp -j ACCEPT There may be many Linux and UNIX boxes (and others) receiving e-mail directly. If there are a large number, it might be preferable to allow traffic to this destination port generally. This will allow crackers to map your network. While the alternative is to list systems individually, they still will be able to discover these. Think of these individual systems running sendmail on port 25 as mail servers. One cannot hide a server; the alternative, and a good one, simply is to have everyone be someone@pentacorp.com and have the mail server route incoming mail to the individual systems. On these systems, you then would configure sendmail (or the individual mail readers/senders) to show the organizational e-mail address as the "From:" address. For those that do want to enable general incoming e-mail access from the DMZ, replace the last rule in the previous block of code with the following. Note that mail.pentacorp.com can attack, I mean access, each internal system's mail port. Details like this (i.e., limiting access to the mail port on each system) can have a tremendous effect on the level of security. For each rule you consider, ask yourself "Can it be made more restrictive?" $IPC -A input -i $DMZIF -p TCP -s mail.$ORG --dport smtp -j ACCEPT 12.6.9 Stateful Firewalls
The firewall techniques that the previous sections discuss offer excellent protection from many common types of attacks and definitely should be used. Unfortunately, with these holes plugged, enemies of the organization will now make use of smaller holes. A number of these holes involve sending packets whose source and destination addresses and ports are valid but undesirable and they should be blocked. One of these potential holes is the violation of protocols, such as the use of echo replies for network mapping and for activating DDoS zombies. Another threat that has been increasing is the use of traditionally open ports, such as TCP ports 23 and 80 (i.e., telnet and www) to run services unrelated to these ports' intended purposes in order to circumvent written policy and firewall rules. While even Squid (a popular Open Source Web page caching program) can block access to undesirable sites, some people will use redirecting Web sites that are not blocked (unless you specifically block them) to route requests to undesirable sites. Microsoft offers products based on SOAP as a way to avoid dealing with firewalls limiting access to approved traffic. A typical SOAP request is disguised to look like an ordinary http request. The following is an example that Microsoft quotes.[22]
http://skonnard.com/soaplike/businessobj.asp?param1=hello+world Fortunately, the SOAP specification uses the content-type header value text/xml-SOAP; this allows easy blocking with the Squid tools discussed in the next section. (SOAP and some of these other tunneling techniques were discussed in "Stopping End Runs Around Firewalls" on page 74.) There also is Squidguard. Lastly, there is Junkbuster that specifically is designed to shield the person browsing from ads, intrusive cookies, or Web sites getting information about them. These are available at the following locations and on the CD-ROM. www.squid-cache.org/ www.squidguard.org/ www.junkbusters.com/ The Linux 2.4 kernel, released in mid-2000, offers a stateful firewall capability with IP Tables, also known as NETFILTER. It allows you to control the rate of various packets being accepted and to shunt certain packets off to user-level programs for further analysis to allow stateful firewalls. Also, there is Phoenix Adaptive Firewall and Checkpoint. While Phoenix is an expensive commercial product costing about $3,000, it is the first firewall to be ICSA certified for Linux. This makes it a good Linux solution for big and stuffy shops and an excellent alternative to products running on closed-source alternatives. Various stateful firewall possibilities are discussed at these locations. www.netfilter.org/ www.seifried.org/lasg/network-servers/proxy/index.html www.obfuscation.org/ipf/ipf-howto.txt http://coombs.anu.edu.au/~avalon/ip-filter.html 12.6.10 SSH Dangers
The firewall rules typically would block most service requests into the internal network. Certainly, the default should be to block all external requests to your internal network, then to let in specific services. Under special conditions, you may want to allow general access to particular hardened systems that are on your internal network, though it is preferable to have all such systems in the DMZ. Generally, it should be OK to allow ssh requests to your internal systems in order to allow your employees to work from home. Understand that if your organization is a large entity, the probability is good that at least some of your employees' home systems will be compromised, usually from exploits unrelated to company activities. Employees who are less knowledgeable about security and using operating systems less secure than Linux are at the greatest risk. Home systems that have continuous connections, such as those with cable modems and DSL, are at the greatest risk of suffering a break-in. Cable modems have the additional risk of being networked with other nearby subscribers in what should be thought of as a LAN. The question is: If a home system is broken, will the cracker simply look around and hide behind it to attack other random systems or will he be sophisticated enough to monitor your employee's activities and discover the SSH passkey, then invade your organization's systems? While I have not seen any reports of the latter, it is a real danger. The more attractive your site is to crackers and the larger it is, the more likely this is to happen. A cracker could even target your employees' home systems for such an attack. This targeting is not hard to do. A cracker merely needs to search the Web and News groups for your organization's name and search these pages for employee names. Then, he would do the same search on the employees' names looking for e-mail addresses unrelated to your organization. These would be the employees' home e-mail addresses. With some ISPs, the e-mail address may be mapped directly to the fully-qualified host name of the subscriber's home system when connected. Then the cracker merely needs to find one employee who has not bothered to secure his system. This is the risk you must contend with if you allow employees to connect from their home systems. Clearly, the more employees you let in, the greater the risk of this sort of attack, and the greater the risk of a cracker breaking into an employee's system and attacking your organization's network. This alone would be justification for denying even SSH. Except for those installations that need high security, it might be reasonable for you to evaluate the security of the home system of each employee that requests SSH access to her office system. It is very important to have written management approval to conduct this home-system security audit as some users might complain and this otherwise could result in problems for the SysAdmin. Additionally, there may be laws in your area that affect this activity that need to be reviewed. This audit might involve a list of questions the employee must answer, either verbally or in electronic or written form. It is suggested that you e-mail the list of questions to the employee, and offer him the option of responding electronically or in writing, print out the responses, and have the employee review and sign the printout. This signature also should guarantee that the employee will contact a SysAdmin prior to doing anything that reduces home security and therefore possibly affects the organization's security. SysAdmins will want to check the security of each home system by seeing what ports are open, asking the user what services are supported and what systems are allowed to use them, examining what versions of critical software are running, and looking at how secure the passwords are. For home Linux systems, SysAdmins should be particularly interested in what versions of telnet, FTP, sendmail (unless blocked by the ISP), and named are in use. In short, review those programs where buggy versions allow break-ins (as discussed in "Quick Fixes for Common Problems" on page 17). Certainly, by allowing this SSH connection, or a similar connection such as TCP Wrapper access, between the organization's network and a user's home system, you are adding the user's home system to the organization's network. It is important, therefore, to educate each home user on security. It also is important to conduct a security audit of any affected home systems. This audit should be conducted similarly to that of company-owned systems. The use of intra-company firewalls and similar techniques will become important at this point; they are discussed in "Intracompany Firewalls to Contain Fires" on page 84. Even those of you running other operating systems could benefit from some of the information in the book. Also, you may want to write up some notes on security to be supplied to users seeking SSH access. You might even want to have a quiz on the material before granting access. While this might seem excessive, the organization's security depends on it. The alternative would be to forbid SSH access, and certainly you will be blamed if someone breaks into the organization's network this way. 12.6.11 Encrypted Mail Access
A major question that needs to be answered is whether there should be a single mail server that accumulates e-mail and allows client systems to download e-mail via POP3 or IMAP. The other option is to allow e-mail to be delivered directly to users' own systems via SMTP. If the clients are Windows and Macs then POP3 and IMAP are popular and reasonably safe. Certainly, the Windows users will be vulnerable to the various e-mail viruses and worms regardless of how they receive e-mail. (See "Using Sendmail to Block E-Mail Attacks" on page 393 for some help fighting known viruses and worms, though the real solution is disabling the execution of foreign code.) Even if the clients are Linux and UNIX boxes, this is a safe and easy solution. Also, it protects even these clients against Sendmail vulnerabilities. Certainly, POP3 and IMAP requests originating from outside of the organization should be blocked by the firewall unless wrapped in SSL or a similar secure protocol. Many of the new mail readers can receive SSL-wrapped mail from POP3 or IMAP mailboxes. This would involve allowing the spop3 and simap services, sometimes called pop3s and imaps. These would be TCP ports 995 and 993, respectively. If the IP address of your mail server is 216.247.56.62, then the following IP Chains commands will allow access. $IPC -A input -i $EXTIF -p tcp -j ACCEPT -s 0.0.0.0/0 \ -d 216.247.56.62/32 995 $IPC -A input -i $EXTIF -p tcp -j ACCEPT -s 0.0.0.0/0 \ -d 216.247.56.62/32 993 You may want to allow e-mail directly to some of your Linux and UNIX client boxes whose sendmail versions are kept up-to-date. In either case, the firewall rules would block all incoming service requests to the Web server except http, https, and ssh requests. Similarly, the firewall would block all services to the external DNS server[23] and mail server except the specific services and ssh.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-j ACCEPT $IPC -A output -i $LPDIF -d $LPDIP 
| Top |
EAN: N/A
Pages: 260
- Chapter III Two Models of Online Patronage: Why Do Consumers Shop on the Internet?
- Chapter VI Web Site Quality and Usability in E-Commerce
- Chapter X Converting Browsers to Buyers: Key Considerations in Designing Business-to-Consumer Web Sites
- Chapter XI User Satisfaction with Web Portals: An Empirical Study
- Chapter XII Web Design and E-Commerce