Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

accept Allows matching datagrams to be received, forwarded, or transmitted deny Blocks matching datagrams from being received, forwarded, or transmitted reject Blocks matching datagrams from being received, forwarded, or transmitted, and sends the host that sent the datagram and ICMP error message Parameters At least one of the following must be supplied. Use the parameters to specify to which datagrams this rule applies: -P protocol Can be TCP, UDP, ICMP, or all. Example: -P tcp -S address[/mask] [port] Source IP address that this rule will match. A netmask of “/32″ will be assumed if you don’t supply one. You may optionally specify which ports this rule will apply to. You must also specify the protocol using the -P argument described above for this to work. If you don’t specify a port or port range, “all” ports will be assumed to match. Ports may be specified by name, using their /etc/services entry if you wish. In the case of the ICMP protocol, the port field is used to indicate the ICMP datagram types. Port ranges may be described; use the general syntax: lowport:highport. Here is an example: -S 172.29.16.1/24 ftp:ftp-data -D address[/mask] [port] Specify the destination IP address that this rule will match. The destination address is coded with the same rules as the source address described previously. Here is an example: -D 172.29.16.1/24 smtp -V address Specify the address of the network interface on which the packet is received (-I) or is being sent (-O). This allows us to create rules that apply only to certain network interfaces on our machine. Here is an example: -V 172.29.16.1 -W name Specify the name of the network interface. This argument works in the same way as the -V argument, except you supply the device name instead of its address. Here is an example: -W ppp0 Optional arguments These arguments are sometimes very useful: -b This is used for bidirectional mode. This flag matches traffic flowing in either direction between the specified source and destination. This saves you from having to create two rules: one for the forward direction of a connection and one for the reverse. -o This enables logging of matching datagrams to the kernel log. Any datagram that matches this rule will be logged as a kernel message. This is useful to enable you to detect unauthorized access. -y

But how does this affect us? Take a look at our rule for port 20, the FTP-data port. The rule as we have it now assumes that the connection will be made by our client to the server. This will work if we use passive mode. But it is very difficult for us to configure a satisfactory rule to allow FTP active mode, because we may not know in advance what ports will be used. If we open up our firewall to allow incoming connections on any port, we are exposing our network to attack on all services that accept connections. The dilemna is most safely resolved by insisting that our users operate in passive mode. Most FTP servers and many FTP clients will operate this way. The popular ncftp client also supports passive mode, but it may require a small configuration change to make it default to passive mode. Many World Wide Web browsers such as the Netscape browser also support passive mode FTP, so it shouldn’t be too hard to find appropriate software to use. Alternatively, you can avoid the issue entirely by using an FTP proxy server that accepts a connection from the internal network and establishes connections to the outside network. In building your firewall, you will probably find a number of these sorts of problems. You should always give careful thought to how a service actually operates to be sure you have put in place an appropriate ruleset for it. A real firewall configuration can be quite complex. Summary of ipfwadm Arguments The ipfwadm has many different arguments that relate to IP firewall configuration. The general syntax is: ipfwadm category command parameters [options] Let’s take a look at each of these. Categories One and only one of the following must be supplied. The category tells the firewall what sort of firewall rule you are configuring: -I Input rule -O Output rule -F Forwarding rule Commands At least one of the following must be supplied and applies only to those rules that relate to the supplied category. The command tells the firewall what action to take. -a [policy] Append a new rule -i [policy] Insert a new rule -d [policy] Delete an existing rule -p policy Set the default policy -l List all existing rules -f Flush all existing rules The policies relevant to IP firewall and their meanings are:

The ipfwadm command will attempt to translate the port number into a service name using the /etc/services if an entry exists there. The default output is lacking in some important detail for us. In the default listing output, we can’t see the effect of the -y argument. The ipfwadm command is able to produce a more detailed listing output if you specify the -e (extended output) argument too. We won’t show the whole output here because it is too wide for the page, but it includes an opt (options) column that shows the -y option controlling SYN packets: # ipfwadm -F -l -e P firewall forward rules, default policy: accept pkts bytes type prot opt tosa tosx ifname ifaddress source … 0 0 deny tcp –y-0xFF 0×00 any any anywhere … 0 0 acc tcp b—0xFF 0×00 any any 172.16.1.0/24 … A More Complex Example The previous example was a simple one. Not all network services are as simple as the WWW service to configure; in practice, a typical firewall configuration would be much more complex. Let’s look at another common example, this time FTP. We want our internal network users to be able to log into FTP servers on the Internet to read and write files. But we don’t want people on the Internet to be able to log into our FTP servers. We know that FTP uses two TCP ports: port 20 (ftp-data) and port 21 (ftp), so: # ipfwadm -a deny -P tcp -S 0/0 20 -D 172.16.1.0/24 -y # ipfwadm -a accept -P tcp -S 172.16.1.0/24 -D 0/0 20 -b # # ipfwadm -a deny -P tcp -S 0/0 21 -D 172.16.1.0/24 -y # ipfwadm -a accept -P tcp -S 172.16.1.0/24 -D 0/0 21 -b Right? Well, not necessarily. FTP servers can operate in two different modes: passive mode and active mode.61 In passive mode, the FTP server listens for a connection from the client. In active mode, the server actually makes the connection to the client. Active mode is usually the default. The differences are illustrated in Figure 9.3. Figure 9.3: FTP server modes Many FTP servers make their data connection from port 20 when operating in active mode, which simplifies things for us a little, but unfortunately not all do.62 61 FTP active mode is somewhat nonintuitively enabled using the PORT command. FTP passive mode is enabled using the PASV command. 62 The ProFTPd daemon is a good example of an FTP server that doesn’t, at least in older versions.

Table 9.1: Common Netmask Bit Values Netmask Bits 255.0.0.0 8 255.255.0.0 16 255.255.255.0 24 255.255.255.128 25 255.255.255.192 26 255.255.255.224 27 255.255.255.240 28 255.255.255.248 29 255.255.255.252 30 We mentioned earlier that ipfwadm implements a small trick that makes adding these sorts of rules easier. This trick is an option called -b, which makes the command a bidirectional rule. The bidirectional flag allows us to collapse our two rules into one as follows: # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b An important refinement Take a closer look at our ruleset. Can you see that there is still one method of attack that someone outside could use to defeat our firewall? Our ruleset allows all datagrams from outside our network with a source port of 80 to pass. This will include those datagrams with the SYN bit set! The SYN bit is what declares a TCP datagram to be a connection request. If a person on the outside had privileged access to a host, they could make a connection through our firewall to any of our hosts, provided they use port 80 at their end. This is not what we intended. Fortunately there is a solution to this problem. The ipfwadm command provides another flag that allows us to build rules that will match datagrams with the SYN bit set. Let’s change our example to include such a rule: # ipfwadm -F -a deny -P tcp -S 0/0 80 -D 172.16.10.0/24 -y # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b The -y flag causes the rule to match only if the SYN flag is set in the datagram. So our new rule says: “Deny any TCP datagrams destined for our network from anywhere with a source port of 80 and the SYN bit set,” or “Deny any connection requests from hosts using port 80.” Why have we placed this special rule before the main rule? IP firewall rules operate so that the first match is the rule that is used. Both rules would match the datagrams we want to stop, so we must be sure to put the deny rule before the accept rule. Listing our rules After we’ve entered our rules, we ask ipfwadm to list them for us using the command: # ipfwadm -F -l This command will list all of the configured forwarding rules. The output should look something like this: # ipfwadm -F -l IP firewall forward rules, default policy: accept type prot source destination ports deny tcp anywhere 172.16.10.0/24 www -> any acc tcp 172.16.1.0/24 anywhere any -> www

Using ipfwadm The ipfwadm command was the configuration tool for the second generation Linux IP firewall. Perhaps the simplest way to describe the use of the ipfwadm command is by example. To begin, let’s code the example we presented earlier. A na ve example Let’s suppose that we have a network in our organization and that we are using a Linux-based firewall machine to connect our network to the Internet. Additionally, let’s suppose that we wish the users of that network to be able to access web servers on the Internet, but to allow no other traffic to be passed. We will put in place a forwarding rule to allow datagrams with a source address on our network and a destination socket of port 80 to be forwarded out, and for the corresponding reply datagrams to be forwarded back via the firewall. Assume our network has a 24-bit network mask (Class C) and an address of 172.16.1.0. The rules we might use are: # ipfwadm -F -f # ipfwadm -F -p deny # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 # ipfwadm -F -a accept -P tcp -S 0/0 80 -D 172.16.1.0/24 The -F command-line argument tells ipfwadm that this is a forwarding rule. The first command instructs ipfwadm to “flush” all of the forwarding rules. This ensures we are working from a known state before we begin adding specific rules. The second rule sets our default forwarding policy. We tell the kernel to deny or disallow forwarding of IP data- grams. It is very important to set the default policy, because this describes what will happen to any datagrams that are not specifically handled by any other rule. In most firewall configurations, you will want to set your default policy to “deny,” as shown, to be sure that only the traffic you specifically allow past your firewall is forwarded. The third and fourth rules are the ones that implement our requirement. The third command allows our data- grams out, and the fourth rule allows the responses back. Let’s review each of the arguments: -F This is a Forwarding rule. -a accept Append this rule with the policy set to “accept,” meaning we will forward any datagrams that match this rule. -P tcp This rule applies to tcp datagrams (as opposed to UDP or ICMP). -S 172.16.1.0/24 The Source address must have the first 24 bits matching those of the network address 172.16.1.0. -D 0/0 80 The destination address must have zero bits matching the address 0.0.0.0. This is really a shorthand notation for “anything.” The 80 is the destination port, in this case WWW. You may also use any entry that appears in the /etc/services file to describe the port, so -D 0/0 www would have worked just as well. ipfwadm accepts network masks in a form with which you may not be familiar. The /nn notation is a means of describing how many bits of the supplied address are significant, or the size of the mask. The bits are always counted from left to right; some common examples are listed in Table 9.1.

Figure 9.2: The stages of IP datagram processing The IP datagram is received. (1) The incoming IP datagram is examined to determine if it is destined for a process on this machine. If the datagram is for this machine, it is processed locally. (2) If it is not destined for this machine, a search is made of the routing table for an appropriate route and the datagram is forwarded to the appropriate interface or dropped if no route can be found. (3) Datagrams from local processes are sent to the routing software for forwarding to the appropriate interface. (4) The outgoing IP datagram is examined to determine if there is a valid route for it to take, if not, it is dropped. The IP datagram is transmitted. (5) In our diagram, the flow 1 3 5 represents our machine routing data between a host on our Ethernet network to a host reachable via our PPP link. The flows 1 2 and 4 5 represent the data input and output flows of a network program running on our local host. The flow 4 3 2 would represent data flow via a loopback connection. Naturally data flows both into and out of network devices. The question marks on the diagram represent the points where the IP layer makes routing decisions. The Linux kernel IP firewall is capable of applying filtering at various stages in this process. That is, you can filter the IP datagrams that come in to your machine, filter those datagrams being forwarded across your machine, and filter those datagrams that are ready to be transmitted. In ipfwadm and ipchains, an Input rule applies to flow 1 on the diagram, a Forwarding rule to flow 3, and an Output rule to flow 5. We’ll see when we discuss netfilter later that the points of interception have changed so that an Input rule is applied at flow 2, and an Output rule is applied at flow 4. This has important implications for how you structure your rulesets, but the general principle holds true for all versions of Linux firewalling. This may seem unnecessarily complicated at first, but it provides flexibility that allows some very sophisticated and powerful configurations to be built. Original IP Firewall (2.0 Kernels) The first generation IP firewall support for Linux appeared in the 1.1 series kernel. It was a port of the BSD ipfw firewall support to Linux by Alan Cox. The firewall support that appeared in the 2.0 series kernels and is the second generation was enhanced by Jos Vos, Pauline Middelink, and others.

TOS target support MARK target support LOG target support ipchains (2.2-style) support ipfwadm (2.0-style) support The ipfwadm Utility The ipfwadm (IP Firewall Administration) utility is the tool used to build the firewall rules for all kernels prior to 2.2.0. Its command syntax can be very confusing because it can do such a complicated range of things, but we’ll provide some common examples that will illustrate the most important variations of these. The ipfwadm utility is included in most modern Linux distributions, but perhaps not by default. There may be a specific software package for it that you have to install. If your distribution does not include it, you can obtain the source package from ftp.xos.nl in the /pub/linux/ipfwadm/ directory, and compile it yourself. The ipchains Utility Just as for the ipfwadm utility, the ipchains utility can be somewhat baffling to use at first. It provides all of the flexibility of ipfwadm with a simplified command syntax, and additionally provides a “chaining” mechanism that allows you to manage multiple rulesets and link them together. We’ll cover rule chaining in a separate section near the end of the chapter, because for most situations it is an advanced concept. The ipchains command appears in most Linux distributions based on the 2.2 kernels. If you want to compile it yourself, you can find the source package from its developer’s site at http://www.rustcorp.com/linux/ipchains/. Included in the source package is a wrapper script called ipfwadm-wrapper that mimics the ipfwadm command, but actually invokes the ipchains command. Migration of an existing firewall configuration is much more painless with this addition. The iptables Utility The syntax of the iptables utility is quite similar to that of the ipchains syntax. The changes are improvements and a result of the tool being redesigned to be extensible through shared libraries. Just as for ipchains, we’ll present iptables equivalents of the examples so you can compare and contrast its syntax with the others. The iptables utility is included in the netfilter source package available at http://www.samba.org/netfilter/. It will also be included in any Linux distribution based on the 2.4 series kernels. We’ll talk a bit about netfilter’s huge step forward in a section of its own later in this chapter. Three Ways We Can Do Filtering Consider how a Unix machine, or in fact any machine capable of IP routing, processes IP datagrams. The basic steps, shown in Figure 9.2 are:

The IP filtering ruleset is made up of many combinations of the criteria listed previously. For example, let’s imagine that you wanted to allow World Wide Web users within the Virtual Brewery network to have no access to the Internet except to use other sites’ web servers. You would configure your firewall to allow forwarding of: datagrams with a source address on Virtual Brewery network, a destination address of anywhere, and with a destination port of 80 (WWW) datagrams with a destination address of Virtual Brewery network and a source port of 80 (WWW) from a source address of anywhere Note that we’ve used two rules here. We have to allow our data to go out, but also the corresponding reply data to come back in. In practice, as we’ll see shortly, Linux simplifies this and allows us to specify this in one command. Setting Up Linux for Firewalling To build a Linux IP firewall, it is necessary to have a kernel built with IP firewall support and the appropriate configuration utility. In all production kernels prior to the 2.2 series, you would use the ipfwadm utility. The 2.2.x kernels marked the release of the third generation of IP firewall for Linux called IP Chains. IP chains use a program similar to ipfwadmcalled ipchains. Linux kernels 2.3.15 and later support the fourth generation of Linux IP firewall called netfilter. The netfilter code is the result of a large redesign of the packet handling flow in Linux. The netfilter is a multifaceted creature, providing direct backward-compatible support for both ipfwadm and ipchains as well as a new alternative command called iptables. We’ll talk about the differences between the three in the next few sections. Kernel Configured with IP Firewall The Linux kernel must be configured to support IP firewalling. There isn’t much more to it than selecting the appropriate options when performing a make menuconfig of your kernel.60 We described how to do this is in Chapter 3, Configuring the Networking Hardware”. In 2.2 kernels you should select the following options: Networking options —> [*] Network firewalls [*] TCP/IP networking [*] IP: firewalling [*] IP: firewall packet logging In kernels 2.4.0 and later you should select this option instead: Networking options —> [*] Network packet filtering (replaces ipchains) IP: Netfilter Configuration —> . Userspace queueing via NETLINK (EXPERIMENTAL) IP tables support (required for filtering/masq/NAT) limit match support MAC address match support netfilter MARK match support Multiple port match support TOS match support Connection state match support Unclean match support (EXPERIMENTAL) Owner match support (EXPERIMENTAL) Packet filtering REJECT target support MIRROR target support (EXPERIMENTAL) . Packet mangling Firewall packet logging is a special feature that writes a line of information about each datagram that matches a particular firewall rule out to a special device so you can see them.

Figure 9.1: The two major classes of firewall design The Linux kernel provides a range of built-in features that allow it to function quite nicely as an IP firewall. The network implementation includes code to do IP filtering in a number of different ways, and provides a mechanism to quite accurately configure what sort of rules you’d like to put in place. The Linux firewall is flexible enough to make it very useful in either of the configurations illustrated in Figure 9.1. Linux firewall software provides two other useful features that we’ll discuss in separate chapters: IP Accounting (Chapter 10, IP Accounting) and IP masquerade (Chapter 11, IP Masquerade and Network Address Translation). What Is IP Filtering? IP filtering is simply a mechanism that decides which types of IP datagrams will be processed normally and which will be discarded. By discarded we mean that the datagram is deleted and completely ignored, as if it had never been received. You can apply many different sorts of criteria to determine which datagrams you wish to filter; some examples of these are: Protocol type: TCP, UDP, ICMP, etc. Socket number (for TCP/UPD) Datagram type: SYN/ACK, data, ICMP Echo Request, etc. Datagram source address: where it came from Datagram destination address: where it is going to It is important to understand at this point that IP filtering is a network layer facility. This means it doesn’t understand anything about the application using the network connections, only about the connections themselves. For example, you may deny users access to your internal network on the default telnet port, but if you rely on IP filtering alone, you can’t stop them from using the telnet program with a port that you do allow to pass trhough your firewall. You can prevent this sort of problem by using proxy servers for each service that you allow across your firewall. The proxy servers understand the application they were designed to proxy and can therefore prevent abuses, such as using the telnet program to get past a firewall by using the World Wide Web port. If your firewall supports a World Wide Web proxy, their telnet connection will always be answered by the proxy and will allow only HTTP requests to pass. A large number of proxy-server programs exist. Some are free software and many others are commercial products. The Firewall-HOWTO discusses one popular set of these, but they are beyond the scope of this book.

Denial of service Denial of service attacks cause the service or program to cease functioning or prevent others from making use of the service or program. These may be performed at the network layer by sending carefully crafted and malicious datagrams that cause network connections to fail. They may also be performed at the application layer, where carefully crafted application commands are given to a program that cause it to become extremely busy or stop functioning. Preventing suspicious network traffic from reaching your hosts and preventing suspicious program commands and requests are the best ways of minimizing the risk of a denial of service attack. It’s useful to know the details of the attack method, so you should educate yourself about each new attack as it gets publicized. Spoofing This type of attack causes a host or application to mimic the actions of another. Typically the attacker pretends to be an innocent host by following IP addresses in network packets. For example, a well- documented exploit of the BSD rlogin service can use this method to mimic a TCP connection from another host by guessing TCP sequence numbers. To protect against this type of attack, verify the authenticity of datagrams and commands. Prevent datagram routing with invalid source addresses. Introduce unpredictablility into connection control mechanisms, such as TCP sequence numbers and the allocation of dynamic port addresses. Eavesdropping This is the simplest type of attack. A host is configured to “listen” to and capture data not belonging to it. Carefully written eavesdropping programs can take usernames and passwords from user login network connections. Broadcast networks like Ethernet are especially vulnerable to this type of attack. To protect against this type of threat, avoid use of broadcast network technologies and enforce the use of data encryption. IP firewalling is very useful in preventing or reducing unauthorized access, network layer denial of service, and IP spoofing attacks. It not very useful in avoiding exploitation of weaknesses in network services or programs and eavesdropping. What Is a Firewall? A firewall is a secure and trusted machine that sits between a private network and a public network.59 The fire- wall machine is configured with a set of rules that determine which network traffic will be allowed to pass and which will be blocked or refused. In some large organizations, you may even find a firewall located inside their corporate network to segregate sensitive areas of the organization from other employees. Many cases of computer crime occur from within an organization, not just from outside. Firewalls can be constructed in quite a variety of ways. The most sophisticated arrangement involves a number of separate machines and is known as a perimeter network. Two machines act as “filters” called chokes to allow only certain types of network traffic to pass, and between these chokes reside network servers such as a mail gateway or a World Wide Web proxy server. This configuration can be very safe and easily allows quite a great range of control over who can connect both from the inside to the outside, and from the outside to the inside. This sort of configuration might be used by large organizations. Typically though, firewalls are single machines that serve all of these functions. These are a little less secure, because if there is some weakness in the firewall machine itself that allows people to gain access to it, the whole network security has been breached. Nevertheless, these types of firewalls are cheaper and easier to manage than the more sophisticated arrangement just described. Figure 9.1 illustrates the two most common firewall configurations. The term firewall comes from a device used to protect people from fire. The firewall is a shield of material resistant to fire that is placed between a potential fire and the people it is protecting.