Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

We have a small Ethernet network using one of the reserved network addresses. The network has a Linux-based masquerade router providing access to the Internet. One of the workstations on the network (192.168.1.3) wishes to establish a connection to the remote host 209.1.106.178 on port 8888. The workstation routes its datagram to the masquerade router, which identifies this connection request as requiring masquerade services. It accepts the datagram and allocates a port number to use (1035), substitutes its own IP address and port number for those of the originating host, and transmits the datagram to the destination host. The destination host believes it has received a connection request from the Linux masquerade host and generates a reply datagram. The masquerade host, upon receiving this datagram, finds the association in its masquerade table and reverses the substution it performed on the outgoing datagram. It then transmits the reply datagram to the originating host. The local host believes it is speaking directly to the remote host. The remote host knows nothing about the local host at all and believes it has received a connection from the Linux masquerade host. The Linux masquerade host knows these two hosts are speaking to each other, and on what ports, and performs the address and port translations necessary to allow communication. This might all seem a little confusing, and it can be, but it works and is really quite simple to configure. So don’t worry if you don’t understand all the details yet. Side Effects and Fringe Benefits The IP masquerade facility comes with its own set of side effects, some of which are useful and some of which might become bothersome. None of the hosts on the supported network behind the masquerade router are ever directly seen; consequently, you need only one valid and routable IP address to allow all hosts to make network connections out onto the Internet. This has a downside; none of those hosts are visible from the Internet and you can’t directly connect to them from the Internet; the only host visible on a masqueraded network is the masquerade machine itself. This is important when you consider services such as mail or FTP. It helps determine what services should be provided by the masquerade host and what services it should proxy or otherwise treat specially. Second, because none of the masqueraded hosts are visible, they are relatively protected from attacks from outside; this could simplify or even remove the need for firewall configuration on the masquerade host. You shouldn’t rely too heavily on this, though. Your whole network will be only as safe as your masquerade host, so you should use firewall to protect it if security is a concern. Third, IP masquerade will have some impact on the performance of your networking. In typical configurations this will probably be barely measurable. If you have large numbers of active masquerade sessions, though, you may find that the processing required at the masquerade machine begins to impact your network throughput. IP masquerade must do a good deal of work for each datagram compared to the process of conventional routing. That 386SX16 machine you have been planning on using as a masquerade machine supporting a dial-up link to the Internet might be fine, but don’t expect too much if you decide you want to use it as a router in your corporate network at Ethernet speeds. Last, some network services just won’t work through masquerade, or at least not without a lot of help. Typically, these are services that rely on incoming sessions to work, such as some types of Direct Communications Channels (DCC), features in IRC, or certain types of video and audio multicasting services. Some of these services have specially developed kernel modules to provide solutions for these, and we’ll talk about those in a moment. For others, it is possible that you will find no support, so be aware,it won’t be suitable in all situations. Configuring the Kernel for IP Masquerade To use the IP masquerade facility, your kernel must be compiled with masquerade support. You must select the following options when configuring a 2.2 series kernel: Networking options —> [*] Network firewalls [*] TCP/IP networking [*] IP: firewalling [*] IP: masquerading

Chapter 11 - Masquerade and Network Address Translation You don’t have to have a good memory to remember a time when only large organizations could afford to have a number of computers networked together by a LAN. Today network technology has dropped so much in price that two things have happened. First, LANs are now commonplace, even in many household environments. Certainly many Linux users will have two or more computers connected by some Ethernet. Second, network resources, particularly IP addresses, are now a scarce resource and while they used to be free, they are now being bought and sold. Most people with a LAN will probably also want an Internet connection that every computer on the LAN can use. The IP routing rules are quite strict in how they deal with this situation. Traditional solutions to this problem would have involved requesting an IP network address, perhaps a class C address for small sites, assigning each host on the LAN an address from this network and using a router to connect the LAN to the Internet. In a commercialized Internet environment, this is quite an expensive proposition. First, you’d be required to pay for the network address that is assigned to you. Second, you’d probably have to pay your Internet Service Provider for the privilege of having a suitable route to your network put in place so that the rest of the Internet knows how to reach you. This might still be practical for companies, but domestic installations don’t usually justify the cost. Fortunately, Linux provides an answer to this dilemma. This answer involves a component of a group of advanced networking features called Network Address Translation (NAT). NAT describes the process of modifying the network addresses contained with datagram headers while they are in transit. This might sound odd at first, but we’ll show that it is ideal for solving the problem we’ve just described and many have encountered. IP masquerade is the name given to one type of network address translation that allows all of the hosts on a private network to use the Internet at the price of a single IP address. IP masquerading allows you to use a private (reserved) IP network address on your LAN and have your Linuxbased router perform some clever, real-time translation of IP addresses and ports. When it receives a datagram from a computer on the LAN, it takes note of the type of datagram it is, “TCP,” “UDP,” “ICMP,” etc., and modifies the datagram so that it looks like it was generated by the router machine itself (and remembers that it has done so). It then transmits the datagram onto the Internet with its single connected IP address. When the destination host receives this datagram, it believes the datagram has come from the routing host and sends any reply datagrams back to that address. When the Linux masquerade router receives a datagram from its Internet connection, it looks in its table of established masqueraded connections to see if this datagram actually belongs to a computer on the LAN, and if it does, it reverses the modification it did on the forward path and transmits the datagram to the LAN computer. A simple example is illustrated in Figure 11.1. Figure 11.1: A typical IP masquerade configuration

You should then enable promiscuous mode on your Ethernet interface using the ifconfig command. Now you can establish accounting rules that allow you to collect information about the datagrams flowing across your Ethernet without involving your Linux in the route at all.

Just as for the ipchains command, you can use the -x argument to show the output in expanded format with unit figures. Resetting the Counters The IP accounting counters will overflow if you leave them long enough. If they overflow, you will have difficulty determining the value they actually represent. To avoid this problem, you should read the accounting data periodically, record it, and then reset the counters back to zero to begin collecting accounting information for the next accounting interval. The ipfwadm and ipchains commands provide you with a means of doing this quite simply: # ipfwadm -A -z or: # ipchains -Z or: # iptables -Z You can even combine the list and zeroing actions together to ensure that no accounting data is lost in between: # ipfwadm -A -l -z or: # ipchains -L -Z or: # iptables -L -Z -v These commands will first list the accounting data and then immediately zero the counters and begin counting again. If you are interested in collecting and using this information regularly, you would probably want to put this command into a script that recorded the output and stored it somewhere, and execute the script periodically using the cron command. Flushing the Ruleset One last command that might be useful allows you to flush all the IP accounting rules you have configured. This is most useful when you want to radically alter your ruleset without rebooting the machine. The -f argument in combination with the ipfwadm command will flush all of the rules of the type you specify. ipchains supports the -F argument, which does the same: # ipfwadm -A -f or: # ipchains -F or: # iptables -F This flushes all of your configured IP accounting rules, removing them all and saving you having to remove each of them individually. Note that flushing the rules with ipchains does not cause any user-defined chains to be removed, only the rules within them. Passive Collection of Accounting Data One last trick you might like to consider: if your Linux machine is connected to an Ethernet, you can apply accounting rules to all of the data from the segment, not only that which it is transmitted by or destined for it. Your machine will passively listen to all of the data on the segment and count it. You should first turn IP forwarding off on your Linux machine so that it doesn’t try to route the datagrams it receives.65 n the 2.0.36 and 2.2 kernels, this is a matter of: # echo 0 >/proc/sys/net/ipv4/ip_forward This isn’t a good thing to do if your Linux machine serves as a router. If you disable IP forwarding, it will cease to route! Do this only on a machine with a single physical network interface.

Using IP Accounting Results It is all very well to be collecting this information, but how do we actually get to see it? To view the collected accounting data and the configured accounting rules, we use our firewall configuration commands, asking them to list our rules. The packet and byte counters for each of our rules are listed in the output. The ipfwadm, ipchains, and iptables commands differ in how accounting data is handled, so we will treat them independently. Listing Accounting Data with ipfwadm The most basic means of listing our accounting data with the ipfwadm command is to use it like this: # ipfwadm -A -l IP accounting rules pkts bytes dir prot source destination ports 9833 2345K i/o all 172.16.3.0/24 anywhere n/a 56527 33M i/o all 172.16.4.0/24 anywhere n/a This will tell us the number of packets sent in each direction. If we use the extended output format with the -e option (not shown here because the output is too wide for the page), we are also supplied the options and applicable interface names. Most of the fields in the output will be self-explanatory, but the following may not: dir The direction in which the rule applies. Expected values here are in, out, or i/o, meaning both ways. prot The protocols to which the rule applies. opt A coded form of the options we use when invoking ipfwadm. ifname The name of the interface to which the rule applies. ifaddress The address of the interface to which the rule applies. By default, ipfwadm displays the packet and byte counts in a shortened form, rounded to the nearest thousand (K) or million (M). We can ask it to display the collected data in exact units by using the expanded option as follows: # ipfwadm -A -l -e x Listing Accounting Data with ipchains The ipchains command will not display our accounting data (packet and byte counters) unless we supply it the -v argument. The simplest means of listing our accounting data with the ipchains is to use it like this: # ipchains -L -v Again, just as with ipfwadm, we can display the packet and byte counters in units by using the expanded output mode. The ipchains uses the -x argument for this: # ipchains -L -v x Listing Accounting Data with iptables The iptables command behaves very similarly to the ipchains command. Again, we must use the -v when listing tour rules to see the accounting counters. To list our accounting data, we would use: # iptables -L -v

Accounting of ICMP Datagrams The ICMP protocol does not use service port numbers and is therefore a little bit more difficult to collect details on. ICMP uses a number of different types of datagrams. Many of these are harmless and normal, while others should only be seen under special circumstances. Sometimes people with too much time on their hands attempt to maliciously disrupt the network access of a user by generating large numbers of ICMP messages. This is commonly called ping flooding. While IP accounting cannot do anything to prevent this problem (IP firewalling can help, though!) we can at least put accounting rules in place that will show us if anybody has been trying. ICMP doesn’t use ports as TCP and UDP do. Instead ICMP has ICMP message types. We can build rules to account for each ICMP message type. To do this, we place the ICMP message and type number in place of the port field in the ipfwadm accounting commands. We listed the ICMP message types in “ICMP datagram types”, so refer to it if you need to remember what they are. An IP accounting rule to collect information about the volume of ping data that is being sent to you or that you are generating might look like: # ipfwadm -A both -a -P icmp -S 0/0 8 # ipfwadm -A both -a -P icmp -S 0/0 0 # ipfwadm -A both -a -P icmp -S 0/0 0xff or, with ipchains: # ipchains -A forward -p icmp -s 0/0 8 # ipchains -A forward -p icmp -s 0/0 0 # ipchains -A forward -p icmp -s 0/0 -f or, with iptables: # iptables -A FORWARD -m icmp -p icmp –sports echo-request # iptables -A FORWARD -m icmp -p icmp –sports echo-reply # iptables -A FORWARD -m icmp -p icmp -f The first rule collects information about the “ICMP Echo Request” datagrams (ping requests), and the second rule collects information about the “ICMP Echo Reply” datagrams (ping replies). The third rule collects information about ICMP datagram fragments. This is a trick similar to that described for fragmented TCP and UDP datagrams. If you specify source and/or destination addresses in your rules, you can keep track of where the pings are coming from, such as whether they originate inside or outside your network. Once you’ve determined where the rogue datagrams are coming from, you can decide whether you want to put firewall rules in place to prevent them or take some other action, such as contacting the owner of the offending network to advise them of the problem, or perhaps even legal action if the problem is a malicious act. Accounting by Protocol Let’s now imagine that we are interested in knowing how much of the traffic on our link is TCP, UDP, and ICMP. We would use rules like the following: # ipfwadm -A both -a -W ppp0 -P tcp -D 0/0 # ipfwadm -A both -a -W ppp0 -P udp -D 0/0 # ipfwadm -A both -a -W ppp0 -P icmp -D 0/0 or: # ipchains -A forward -i ppp0 -p tcp -d 0/0 # ipchains -A forward -i ppp0 -p udp -d 0/0 # ipchains -A forward -i ppp0 -p icmp -d 0/0 or: # iptables -A FORWARD -i ppp0 -m tcp -p tcp # iptables -A FORWARD -o ppp0 -m tcp -p tcp # iptables -A FORWARD -i ppp0 -m udp -p udp # iptables -A FORWARD -o ppp0 -m udp -p udp # iptables -A FORWARD -i ppp0 -m icmp -p icmp # iptables -A FORWARD -o ppp0 -m icmp -p icmp With these rules in place, all of the traffic flowing across the ppp0 interface will be analyzed to determine whether it is TCP, UDP, or IMCP traffic, and the appropriate counters will be updated for each. The iptables example splits incoming flow from outgoing flow as its syntax demands it.

How do we do this with the ipchainsor iptables commands, since they allow only one argument in their port specification? We can exploit user-defined chains in accounting just as easily as in firewall rules. Consider the following approach: # ipchains -N a-essent # ipchains -N a-noness # ipchains -A a-essent -j ACCEPT # ipchains -A a-noness -j ACCEPT # ipchains -A forward -i ppp0 -p tcp -s 0/0 ftp-data:ftp -j a-essent # ipchains -A forward -i ppp0 -p tcp -s 0/0 smtp -j a-essent # ipchains -A forward -i ppp0 -p tcp -s 0/0 www -j a-essent # ipchains -A forward -j a-noness Here we create two user-defined chains, one called a-essent, where we capture accounting data for essential services and another called a-noness, where we capture accounting data for nonessential services. We then add rules to our forward chain that match our essential services and jump to the a-essent chain, where we have just one rule that accepts all datagrams and counts them. The last rule in our forward chain is a rule that jumps to our a-noness chain, where again we have just one rule that accepts all datagrams and counts them. The rule that jumps to the a-noness chain will not be reached by any of our essential services, as they will have been accepted in their own chain. Our tallies for essential and nonessential services will therefore be available in the rules within those chains. This is just one approach you could take; there are others. Our iptables implementation of the same approach would look like: # iptables -N a-essent # iptables -N a-noness # iptables -A a-essent -j ACCEPT # iptables -A a-noness -j ACCEPT # iptables -A FORWARD -i ppp0 -m tcp -p tcp –sport ftp-data:ftp -j a- essent # iptables -A FORWARD -i ppp0 -m tcp -p tcp –sport smtp -j a-essent # iptables -A FORWARD -i ppp0 -m tcp -p tcp –sport www -j a-essent # iptables -A FORWARD -j a-noness This looks simple enough. Unfortunately, there is a small but unavoidable problem when trying to do accounting by service type. You will remember that we discussed the role the MTU plays in TCP/IP networking in an earlier chapter. The MTU defines the largest datagram that will be transmitted on a network device. When a datagram is received by a router that is larger than the MTU of the interface that needs to retransmit it, the router performs a trick called fragmentation. The router breaks the large datagram into small pieces no longer than the MTU of the interface and then transmits these pieces. The router builds new headers to put in front of each of these pieces, and these are what the remote machine uses to reconstruct the original data. Unfortunately, during the fragmentation process the port is lost for all but the first fragment. This means that the IP accounting can’t properly count fragmented datagrams. It can reliably count only the first fragment, or unfragmented datagrams. There is a small trick permitted by ipfwadm that ensures that while we won’t be able to know exactly what port the second and later fragments were from, we can still count them. An early version of Linux accounting software assigned the fragments a fake port number, 0xFFFF, that we could count. To ensure that we capture the second and later fragments, we could use a rule like: # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 0xFFFF The IP chains implementation has a slightly more sophisticated solution, but the result is much the same. If using the ipchains command we’d instead use: # ipchains -A forward -i ppp0 -p tcp -f and with iptables we’d use: # iptables -A FORWARD -i ppp0 -m tcp -p tcp -f These won’t tell us what the original port for this data was, but at least we are able to see how much of our data is fragments, and be able to account for the volume of traffic they consume. In 2.2 kernels you can select a kernel compile-time option that negates this whole issue if your Linux machine is acting as the single access point for a network. If you enable the IP: always defragment option when you compile your kernel, all received datagrams will be reassembled by the Linux router before routing and retransmission. This operation is performed before the firewall and accounting software sees the datagram, and thus you will have no fragments to deal with. In 2.4 kernels you compile and load the netfilter forward-fragment module.

These rules will count all datagrams with a source address belonging to one of the department networks and a destination address belonging to the other. Accounting by Service Port Okay, let’s suppose we also want a better idea of exactly what sort of traffic is being carried across our PPP link. We might, for example, want to know how much of the link the FTP, smtp, and World Wide Web services are consuming. A script of rules to enable us to collect this information might look like: #!/bin/sh # Collect FTP, smtp and www volume statistics for data carried on our # PPP link using ipfwadm # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 smtp ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 www or: #!/bin/sh # Collect ftp, smtp and www volume statistics for data carried on our # PPP link using ipchains # ipchains -A input -i ppp0 -p tcp -s 0/0 ftp-data:ftp ipchains -A output -i ppp0 -p tcp -d 0/0 ftp-data:ftp ipchains -A input -i ppp0 -p tcp -s 0/0 smtp ipchains -A output -i ppp0 -p tcp -d 0/0 smtp ipchains -A input -i ppp0 -p tcp -s 0/0 www ipchains -A output -i ppp0 -p tcp -d 0/0 www or: #!/bin/sh # Collect ftp, smtp and www volume statistics for data carried on our # PPP link using iptables. # iptables -A FORWARD -i ppp0 -m tcp -p tcp –sport ftp-data:ftp iptables -A FORWARD -o ppp0 -m tcp -p tcp –dport ftp-data:ftp iptables -A FORWARD -i ppp0 -m tcp -p tcp –sport smtp iptables -A FORWARD -o ppp0 -m tcp -p tcp –dport smtp iptables -A FORWARD -i ppp0 -m tcp -p tcp –sport www iptables -A FORWARD -o ppp0 -m tcp -p tcp –dport www There are a couple of interesting features to this configuration. Firstly, we’ve specified the protocol. When we specify ports in our rules, we must also specify a protocol because TCP and UDP provide separate sets of ports. Since all of these services are TCB-based, we’ve specified it as the protocol. Secondly, we’ve specified the two services ftp and ftp-data in one command. ipfwadm allows you to specify single ports, ranges of ports, or arbitrary lists of ports. The ipchains command allows either single ports or ranges of ports, which is what we’ve used here. The syntax “ftp-data:ftp” means “ports ftp-data (20) through ftp (21),” and is how we encode ranges of ports in both ipchains and iptables. When you have a list of ports in an accounting rule, it means that any data received for any of the ports in the list will cause the data to be added to that entry’s totals. Remembering that the FTP service uses two ports, the command port and the data transfer port, we’ve added them together to total the FTP traffic. Lastly, we’ve specified the source address as “0/0,” which is special notation that matches all addresses and is required by both the ipfwadm and ipchains commands in order to specify ports. We can expand on the second point a little to give us a different view of the data on our link. Let’s now imagine that we class FTP, SMTP, and World Wide Web traffic as essential traffic, and all other traffic as nonessential. If we were interested in seeing the ratio of essential traffic to nonessential traffic, we could do something like: # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data smtp www # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 1:19 22:24 26:79 81:32767 If you have already examined your /etc/services file, you will see that the second rule covers all ports except (ftp, ftp-data, smtp, and www).

allow you to configure rules in the forward chain that the older implementation did not. We’ll see the difference that makes in some examples a little later. The commands are much the same as firewall rules, except that the policy rules do not apply here. We can add, insert, delete, and list accounting rules. In the case of ipchains and iptables, all valid rules are accounting rules, and any command that doesn’t specify the -j option performs accounting only. The rule specification parameters for IP accounting are the same as those used for IP firewall. These are what we use to define precisely what network traffic we wish to count and total. Accounting by Address Let’s work with an example to illustrate how we’d use IP accounting. Imagine we have a Linux-based router that serves two departments at the Virtual Brewery. The router has two Ethernet devices, eth0 and eth1, each of which services a department; and a PPP device, ppp0, that connects us via a high-speed serial link to the main campus of the Groucho Marx University. Let’s also imagine that for billing purposes we want to know the total traffic generated by each of the departments across the serial link, and for management purposes we want to know the total traffic generated between the two departments. The following table shows the interface addresses we will use in our example: iface address netmask eth0 172.16.3.0 255.255.255.0 eth1 172.16.4.0 255.255.255.0 To answer the question, “How much data does each department generate on the PPP link?”, we could use a rule that looks like this: # ipfwadm -A both -a -W ppp0 -S 172.16.3.0/24 -b # ipfwadm -A both -a -W ppp0 -S 172.16.4.0/24 -b or: # ipchains -A input -i ppp0 -d 172.16.3.0/24 # ipchains -A output -i ppp0 -s 172.16.3.0/24 # ipchains -A input -i ppp0 -d 172.16.4.0/24 # ipchains -A output -i ppp0 -s 172.16.4.0/24 and with iptables: # iptables -A FORWARD -i ppp0 -d 172.16.3.0/24 # iptables -A FORWARD -o ppp0 -s 172.16.3.0/24 # iptables -A FORWARD -i ppp0 -d 172.16.4.0/24 # iptables -A FORWARD -o ppp0 -s 172.16.4.0/24 The first half of each of these set of rules say, “Count all data traveling in either direction across the interface named ppp0 with a source or destination (remember the function of the -b flag in ipfwadm and iptables) address of 172.16.3.0/24.” The second half of each ruleset is the same, but for the second Ethernet network at our site. To answer the second question, “How much data travels between the two departments?”, we need a rule that looks like this: # ipfwadm -A both -a -S 172.16.3.0/24 -D 172.16.4.0/24 -b or: # ipchains -A forward -s 172.16.3.0/24 -d 172.16.4.0/24 -b or: # iptables -A FORWARD -s 172.16.3.0/24 -d 172.16.4.0/24 # iptables -A FORWARD -s 172.16.4.0/24 -d 172.16.3.0/24

Chapter 10 - IP Accounting In today’s world of commercial Internet service, it is becoming increasingly important to know how much data you are transmitting and receiving on your network connections. If you are an Internet Service Provider and you charge your customers by volume, this will be essential to your business. If you are a customer of an Internet Service Provider that charges by data volume, you will find it useful to collect your own data to ensure the accuracy of your Internet charges. There are other uses for network accounting that have nothing to do with dollars and bills. If you manage a server that offers a number of different types of network services, it might be useful to you to know exactly how much data is being generated by each one. This sort of information could assist you in making decisions, such as what hardware to buy or how many servers to run. The Linux kernel provides a facility that allows you to collect all sorts of useful information about the network traffic it sees. This facility is called IP accounting. Configuring the Kernel for IP Accounting The Linux IP accounting feature is very closely related to the Linux firewall software. The places you want to collect accounting data are the same places that you would be interested in performing firewall filtering: into and out of a network host, and in the software that does the routing of datagrams. If you haven’t read the section on firewalls, now is probably a good time to do so, as we will be using some of the concepts described in Chapter 9, TCP/IP Firewall. To activate the Linux IP accounting feature, you should first see if your Linux kernel is configured for it. Check to see if the /proc/net/ip_acct file exists. If it does, your kernel already supports IP accounting. If it doesn’t, you must build a new kernel, ensuring that you answer “Y” to the options in 2.0 and 2.2 series kernels: Networking options —> [*] Network firewalls [*] TCP/IP networking … [*] IP: accounting or in 2.4 series kernels: Networking options —> [*] Network packet filtering (replaces ipchains) Configuring IP Accounting Because IP accounting is closely related to IP firewall, the same tool was designated to configure it, so ipfwadm, ipchainsor iptables are used to configure IP accounting. The command syntax is very similar to that of the firewall rules, so we won’t focus on it, but we will discuss what you can discover about the nature of your network traffic using this feature. The general syntax for IP accounting with ipfwadmis: # ipfwadm -A [direction][command][parameters] The direction argument is new. This is simply coded as in, out, or both. These directions are from the perspective of the linux machine itself, so in means data coming into the machine from a network connection and out means data that is being transmitted by this host on a network connection. The both direction is the sum of both the incoming and outgoing directions. The general command syntax for ipchains and iptablesis: # ipchains -A chain rule-specification # iptables -A chain rule-specification The ipchains and iptables commands allow you to specify direction in a manner more consistent with the firewall rules. IP Firewall Chains doesn’t allow you to configure a rule that aggregates both directions, but it does