Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

In TCP/IP networks, the authors of RPC faced the problem of mapping program numbers to generic network services. They designed each server to provide both a TCP and a UDP port for each program and each version. Generally, RPC applications use UDP when sending data, and fall back to TCP only when the data to be transferred doesn’t fit into a single UDP datagram. Of course, client programs need to find out to which port a program number maps. Using a configuration file for this would be too unflexible; since RPC applications don’t use reserved ports, there’s no guarantee that a port originally meant to be used by our database application hasn’t been taken by some other process. Therefore, RPC applications pick any port they can get and register it with a special program called the portmapper daemon. The portmapper acts as a service broker for all RPC servers running on its machine. A client that wishes to contact a service with a given program number first queries the portmapper on the server’s host, which returns the TCP and UDP port numbers the service can be reached at. This method introduces a single point of failure, much like the inetd daemon does for the standard Berkeley services. However, this case is even a little worse because when the portmapper dies, all RPC port information is lost; this usually means you have to restart all RPC servers manually or reboot the entire machine. On Linux, the portmapper is called /sbin/portmap, or sometimes /usr/sbin/rpc.portmap. Other than making sure it is started from your network boot scripts, the portmapper doesn’t require any configuration. Configuring Remote Login and Execution It’s often very useful to execute a command on a remote host and have input or output from that command be read from, or written to, a network connection. The traditional commands used for executing commands on remote hosts are rlogin, rsh and rcp. We saw an example of the rlogin command in Chapter 1, Introduction to Networking in the section “Introduction to TCP/IP Networks”. We briefly discussed the security issues associated with it in “System Security” and suggested ssh as a replacement. The ssh package provides replacements called slogin, ssh, and scp. Each of these commands spawns a shell on the remote host and allows the user to execute commands. Of course, the client needs to have an account on the remote host where the command is to be executed. Thus, all these commands use an authentication process. The r commands use a simple username and password exchange between the hosts with no encryption, so anyone listening could easily intercept the passwords. The ssh command suite provides a higher level of security: it uses a technique called Public Key Cryptography, which provides authentication and encryption between the hosts to ensure that neither passwords nor session data are easily intercepted by other hosts. It is possible to relax authentication checks for certain users even further. For instance, if you frequently have to log into other machines on your LAN, you might want to be admitted without having to type your password every time. This was always possible with the r commands, but the ssh suite allows you to do this a little more easily. It’s still not a great idea because it means that if an account on one machine is breached, access can be gained to all other accounts that user has configured for password-less login, but it is very convenient and people will use it. Let’s talk about removing the r commands and getting ssh to work instead. Disabling the r; Commands Start by removing the r commands if they’re installed. The easiest way to disable the old r commands is to comment out (or remove) their entries in the /etc/inetd.conf file. The relevant entries will look something like this: # Shell, login, exec and talk are BSD protocols. shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd

Like the services file, the networking library needs a way to translate protocol names — for example, those used in the services file — to protocol numbers understood by the IP layer on other hosts. This is done by looking up the name in the /etc/protocols file. It contains one entry per line, each containing a protocol name, and the associated number. Having to touch this file is even more unlikely than having to meddle with /etc/services. A sample file is given in Example 12.3. Example 12.3: A Sample /etc/protocols File # # Internet (IP) protocols # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group multicast protocol tcp 6 TCP # transmission control protocol udp 17 UDP # user datagram protocol raw 255 RAW # RAW IP interface Remote Procedure Call The general mechanism for client-server applications is provided by the Remote Procedure Call (RPC) package. RPC was developed by Sun Microsystems and is a collection of tools and library functions. Important applications built on top of RPC are NIS, the Network Information System (described in Chapter 13, The Network Information System), and NFS, the Network File System (described in Chapter 14, The Network File System), which are both described in this book. An RPC server consists of a collection of procedures that a client can call by sending an RPC request to the server along with the procedure parameters. The server will invoke the indicated procedure on behalf of the client, handing back the return value, if there is any. In order to be machine-independent, all data exchanged between client and server is converted to the External Data Representation format (XDR) by the sender, and converted back to the machine-local representation by the receiver. RPC relies on standard UDP and TCP sockets to transport the XDR formatted data to the remote host. Sun has graciously placed RPC in the public domain; it is described in a series of RFCs. Sometimes improvements to an RPC application introduce incompatible changes in the procedure call interface. Of course, simply changing the server would crash all applications that still expect the original behavior. Therefore, RPC programs have version numbers assigned to them, usually starting with 1, and with each new version of the RPC interface, this counter will be bumped up. Often, a server may offer several versions simultaneously; clients then indicate by the version number in their requests which implementation of the service they want to use. The communication between RPC servers and clients is somewhat peculiar. An RPC server offers one or more collections of procedures; each set is called a program and is uniquely identified by a program number. A list that maps service names to program numbers is usually kept in /etc/rpc, an excerpt of which is shown in Example 12.4. Example 12.4: A Sample /etc/rpc File # # /etc/rpc -miscellaneous RPC-based services # portmapper 100000 portmap sunrpc rstatd 100001 rstat rstat_svc rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog ypserv 100004 ypprog mountd 100005 mount showmount ypbind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd bootparam 100026 ypupdated 100028 ypupdate

The optional shellcmd field may contain a shell command to be invoked when the entry is matched. This is useful to set up traps that may expose potential attackers. The following example creates a log file listing the user and host connecting, and if the host is not vlager.vbrew.com it will append the output of a finger to that host: in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \ echo “request from %d@%h: >> /var/log/finger.log; \ if [ %h != “vlager.vbrew.com:” ]; then \ finger -l @%h >> /var/log/finger.log \ fi The %h and %d arguments are expanded by tcpd to the client hostname and service name, respectively. Please refer to the hosts_access(5) manual page for details. The Services and Protocols Files The port numbers on which certain “standard” services are offered are defined in the Assigned Numbers RFC. To enable server and client programs to convert service names to these numbers, at least part of the list is kept on each host; it is stored in a file called /etc/services. An entry is made up like this: service port/protocol [aliases] Here, service specifies the service name, port defines the port the service is offered on, and protocol defines which transport protocol is used. Commonly, the latter field is either udp or tcp. It is possible for a service to be offered for more than one protocol, as well as offering different services on the same port as long as the protocols are different. The aliases field allows you to specify alternative names for the same service. Usually, you don’t have to change the services file that comes along with the network software on your Linux system. Nevertheless, we give a small excerpt from that file in Example 12.2. Example 12.2: A Sample /etc/services File # The services file: # # well-known services echo 7/tcp # Echo echo 7/udp # discard 9/tcp sink null # Discard discard 9/udp sink null # daytime 13/tcp # Daytime daytime 13/udp # chargen 19/tcp ttytst source # Character Generator chargen 19/udp ttytst source # ftp-data 20/tcp # File Transfer Protocol (Data) ftp 21/tcp # File Transfer Protocol (Control) telnet 23/tcp # Virtual Terminal Protocol smtp 25/tcp # Simple Mail Transfer Protocol nntp 119/tcp readnews # Network News Transfer Protocol # # UNIX services exec 512/tcp # BSD rexecd biff 512/udp comsat # mail notification login 513/tcp # remote login who 513/udp whod # remote who and uptime shell 514/tcp cmd # remote command, no passwd used syslog 514/udp # remote system logging printer 515/tcp spooler # remote print spooling route 520/udp router routed # routing information protocol Note that the echo service is offered on port 7 for both TCP and UDP, and that port 512 is used for two different services: remote execution (rexec) using TCP, and the COMSAT daemon, which notifies users of new mail, over UDP (see xbiff(1x)).

The tcpd Access Control Facility Since opening a computer to network access involves many security risks, applications are designed to guard against several types of attacks. Some security features, however, may be flawed (most drastically demonstrated by the RTM Internet worm, which exploited a hole in a number of programs, including old versions of the sendmail mail daemon), or do not distinguish between secure hosts from which requests for a particular service will be accepted and insecure hosts whose requests should be rejected. We’ve already briefly discussed the finger and tftp services. Network Administrator would want to limit access to these services to “trusted hosts” only, which is impossible with the usual setup, for which inetd provides this service either to all clients or not at all. A useful tool for managing host-specific access is tcpd, often called the daemon “wrapper.”69 For TCP services you want to monitor or protect, it is invoked instead of the server program. tcpd checks if the remote host is allowed to use that service, and only if this succeeds will it execute the real server program. tcpd also logs the request to the syslog daemon. Note that this does not work with UDP-based services. For example, to wrap the finger daemon, you have to change the corresponding line in inetd.conf from this: # unwrapped finger daemon finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd to this: # wrap finger daemon finger stream tcp nowait root /usr/sbin/tcpd in.fingerd Without adding any access control, this will appear to the client as the usual finger setup, except that any requests are logged to syslog’s auth facility. Two files called /etc/hosts.allow and /etc/hosts.deny implement access control. They contain entries that allow and deny access to certain services and hosts. When tcpd handles a request for a service such as finger from a client host named biff.foobar.com, it scans hosts.allow and hosts.deny (in this order) for an entry matching both the service and client host. If a matching entry is found in hosts.allow, access is granted and tcpd doesn’t consult the hosts.deny file. If no match is found in the hosts.allow file, but a match is found in hosts.deny, the request is rejected by closing down the connection. The request is accepted if no match is found at all. Entries in the access files look like this: servicelist: hostlist [:shellcmd] servicelist is a list of service names from /etc/services, or the keyword ALL. To match all services except finger and tftp, use ALL EXCEPT finger, tftp. hostlist is a list of hostnames, IP addresses, or the keywords ALL, LOCAL, UNKNOWN or PARANOID. ALL matches any host, while LOCAL matches hostnames that don’t contain a dot.70 UNKNOWN matches any hosts whose name or address lookup failed. PARANOID matches any host whose hostname does not resolve back to its IP address.71 A name starting with a dot matches all hosts whose domain is equal to this name. For example, .foobar.com matches biff.foobar.com, but not nurks.fredsville.com. A pattern that ends with a dot matches any host whose IP address begins with the supplied pattern, so 172.16. matches 172.16.32.0, but not 172.15.9.1. A pattern of the form n.n.n.n/m.m.m.m is treated as an IP address and network mask, so we could specify our previous example as 172.16.0.0/255.255.0.0 instead. Lastly, any pattern beginning with a “/” character allows you to specify a file that is presumed to contain a list of hostname or IP address patterns, any of which are allowed to match. So a pattern that looked like /var/access/trustedhosts would cause the tcpd daemon to read that file, testing if any of the lines in it matched the connecting host. To deny access to the finger and tftp services to all but the local hosts, put the following in /etc/hosts.deny and leave /etc/hosts.allow empty: in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .your.domain 69 Written by Wietse Venema, wietse@wzv.win.tue.nl. 70 Usually only local hostnames obtained from lookups in /etc/hosts contain no dots. 71 While its name suggests it is an extreme measure, the PARANOID keyword is a good default, as it protects you against mailicious hosts pretending to be someone they are not. Not all tcpd are supplied with PARANOID compiled in; if yours is not, you need to recompile tcpd to use it.

“multi-threaded” servers, allow an unlimited number of instances to run concurrently. These servers should specify nowait. stream sockets should always use nowait. user This is the login ID of the user who will own the process when it is executing. This will frequently be the root user, but some services may use different accounts. It is a very good idea to apply the principle of least privilege here, which states that you shouldn’t run a command under a privileged account if the program doesn’t require this for proper functioning. For example, the NNTP news server runs as news, while services that may pose a security risk (such as tftpor finger) are often run as nobody. server Gives the full pathname of the server program to be executed. Internal services are marked by the keyword internal. cmdline This is the command line to be passed to the server. It starts with the name of the server to be executed and can include any arguments that need to be passed to it. If you are using the TCP wrapper, you specify the full pathname to the server here. If not, then you just specify the server name as you’d like it to appear in a process list. We’ll talk about the TCP wrapper shortly. This field is empty for internal services. A sample inetd.conf file is shown in Example 12.1. The finger service is commented out so that it is not available. This is often done for security reasons, because it can be used by attackers to obtain names and other details of users on your system. Example 12.1: A Sample /etc/inetd.conf File # # inetd services ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd -b/etc/issue #finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless #login stream tcp nowait root /usr/sbin/rlogind in.rlogind #shell stream tcp nowait root /usr/sbin/rshd in.rshd #exec stream tcp nowait root /usr/sbin/rexecd in.rexecd # # inetd internal services # daytime stream tcp nowait root internal daytime dgram udp nowait root internal time stream tcp nowait root internal time dgram udp nowait root internal echo stream tcp nowait root internal echo dgram udp nowait root internal discard stream tcp nowait root internal discard dgram udp nowait root internal chargen stream tcp nowait root internal chargen dgram udp nowait root internal The tftp daemon is shown commented out as well. tftp implements the Trivial File Transfer Protocol (TFTP), which allows someone to transfer any world-readable files from your system without password checking. This is especially harmful with the /etc/passwd file, and even more so when you don’t use shadow passwords. TFTP is commonly used by diskless clients and Xterminals to download their code from a boot server. If you need to run tftpd for this reason, make sure to limit its scope to those directories from which clients will retrieve files; you will need to add those directory names to tftpd’s command line. This is shown in the second tftp line in the example.

Chapter 12 - Important Network Features After successfully setting up IP and the resolver, you then must look at the services you want to provide over the network. This chapter covers the configuration of a few simple network applications, including the inetd server and the programs from the rlogin family. We’ll also deal briefly with the Remote Procedure Call interface, upon which services like the Network File System (NFS) and the Network Information System (NIS) are based. The configuration of NFS and NIS, however, is more complex and are described in separate chapters, as are electronic mail and network news. Of course, we can’t cover all network applications in this book. If you want to install one that’s not discussed here, like talk, gopher, or http, please refer to the manual pages of the server for details. The inetd Super Server Programs that provide application services via the network are called network daemons. A daemon is a program that opens a port, most commonly a well-known service port, and waits for incoming connections on it. If one occurs, the daemon creates a child process that accepts the connection, while the parent continues to listen for further requests. This mechanism works well, but has a few disadvantages; at least one instance of every possible service you wish to provide must be active in memory at all times. In addition, the software routines that do the listening and port handling must be replicated in every network daemon. To overcome these inefficiencies, most Unix installations run a special network daemon, what you might consider a “super server.” This daemon creates sockets on behalf of a number of services and listens on all of them simultaneously. When an incoming connection is received on any of these sockets, the super server accepts the connection and spawns the server specified for this port, passing the socket across to the child to manage. The server then returns to listening. The most common super server is called inetd, the Internet Daemon. It is started at system boot time and takes the list of services it is to manage from a startup file named /etc/inetd.conf. In addition to those servers, there are a number of trivial services performed by inetd itself called internal services. They include chargen, which simply generates a string of characters, and daytime, which returns the system’s idea of the time of day. An entry in this file consists of a single line made up of the following fields: service type protocol wait user server cmdline Each of the fields is described in the following list: service Gives the service name. The service name has to be translated to a port number by looking it up in the /etc/services file. This file will be described later in this chapter in the section “The Services and Protocols Files”. type Specifies a socket type, either stream (for connection-oriented protocols) or dgram (for datagram protocols). TCP-based services should therefore always use stream, while UDP-based services should always use dgram. protocol Names the transport protocol used by the service. This must be a valid protocol name found in the protocols file, explained later. wait This option applies only to dgram sockets. It can be either wait or nowait. If wait is specified, inetd executes only one server for the specified port at any time. Otherwise, it immediately continues to listen on the port after executing the server. This is useful for “single-threaded” servers that read all incoming datagrams until no more arrive, and then exit. Most RPC servers are of this type and should therefore specify wait. The opposite type,

the TCP or UDP port is known by the term REDIRECT. SNAT, DNAT, and REDIRECT are targets that you may use with the iptables command to build more complex and sophisticated rules. The topic of Network Address Translation and its uses warrants at least a whole chapter of its own.68 Unfortunately we don’t have the space in this book to cover it in any greater depth. You should read the IPTABLESHOWTO for more information, if you’re interested in discovering more about how you might use Network Address Translation. … and perhaps even a whole book!

Setting Timing Parameters for IP Masquerade When each new connection is established, the IP masquerade software creates an association in memory between each of the hosts involved in the connection. You can view these associations at any time by looking at the /proc/net/ip_masquerade file. These associations will timeout after a period of inactivity, though. You can set the timeout values using the ipfwadm command. The general syntax for this is: ipfwadm -M -s and for the ipchains command it is: ipchains -M -S The iptables implementation uses much longer default timers and does not allow you to set them. Each of these values represents a timer used by the IP masquerade software and are in units of seconds. The following table summarizes the timers and their meanings: Name Description tcp TCP session timeout. How long a TCP connection may remain idle before the association for it is removed. tcpfin TCP timeout after FIN. How long an association will remain after a TCP connection has been disconnected. udp UDP session timeout. How long a UDP connection may remain idle before the association for it is removed. Handling Name Server Lookups Handling domain name server lookups from the hosts on the LAN with IP masquerading has always presented a problem. There are two ways of accomodating DNS in a masquerade environment. You can tell each of the hosts that they use the same DNS that the Linux router machine does, and let IP masquerade do its magic on their DNS requests. Alternatively, you can run a caching name server on the Linux machine and have each of the hosts on the LAN use the Linux machine as their DNS. Although a more aggressive action, this is probably the better option because it reduces the volume of DNS traffic travelling on the Internet link and will be marginally faster for most requests, since they’ll be served from the cache. The downside to this configuration is that it is more complex. “Caching-only named Configuration” in Chapter 6 describes how to configure a caching name server. More About Network Address Translation The netfilter software is capable of many different types of Network Address Translation. IP Masquerade is one simple application of it. It is possible, for example, to build NAT rules that translate only certain addresses or ranges of addresses and leave all others untouched, or to translate addresses into pools of addresses rather than just a single address, as masquerade does. You can in fact use the iptables command to generate NAT rules that map just about anything, with combinations of matches using any of the standard attributes, such as source address, destination address, protocol type, port number, etc. Translating the Source Address of a datagram is referred to as “Source NAT,” or SNAT, in the netfilter documentation. Translating the Destination Address of a datagram is known as “Destination NAT,” or DNAT. Translating

served private Internet network addresses for her network. She shares her accomodation with other students, all of whom have an interest in using the Internet. Because student living conditions are very frugal, they cannot afford to use a permanent Internet connection, so instead they use a simple dial-up PPP Internet connection. They would all like to be able to share the connection to chat on IRC, surf the Web, and retrieve files by FTP directly to each of their computers — IP masquerade is the answer. The student first configures a Linux machine to support the dial-up link and to act as a router for the LAN. The IP address she is assigned when she dials up isn’t important. She configures the Linux router with IP masquerade and uses one of the private network addresses for her LAN: 192.168.1.0. She ensures that each of the hosts on the LAN has a default route pointing at the Linux router. The following ipfwadm commands are all that are required to make masquerading work in her configuration: # ipfwadm -F -p deny # ipfwadm -F -a accept -m -S 192.168.1.0/24 -D 0/0 or with ipchains: # ipchains -P forward -j deny # ipchains -A forward -s 192.168.1.0/24 -d 0/0 -j MASQ or with iptables: # iptables -t nat -P POSTROUTING DROP # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE Now whenever any of the LAN hosts try to connect to a service on a remote host, their datagrams will be automatically masqueraded by the Linux masquerade router. The first rule in each example prevents the Linux machine from routing any other datagrams and also adds some security. To list the masquerade rules you have created, use the -l argument to the ipfwadm command, as we described in earlier while discussing firewalls. To list the rule we created earlier we use: # ipfwadm -F -l -e which should display something like: # ipfwadm -F -l -e IP firewall forward rules, default policy: accept pkts bytes type prot opt tosa tosx ifname ifaddress … 0 0 acc/m all —-0xFF 0×00 any any … The “/m” in the output indicates this is a masquerade rule. To list the masquerade rules with the ipchains command, use the -L argument. If we list the rule we created earlier with ipchains, the output will look like: # ipchains -L Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ——192.168.1.0/24 anywhere n/a Chain output (policy ACCEPT): Any rules with a target of MASQ are masquerade rules. Finally, to list the rules using iptables you need to use: # iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy DROP) target prot opt source destination MASQUERADE all –anywhere anywhere MASQUERADE Chain OUTPUT (policy ACCEPT) target prot opt source destination Again, masquerade rules appear with a target of MASQUERADE.

—Protocol-specific masquerading support will be built as mod- ules. [*] IP: ipautofw masq support [*] IP: ICMP masquerading Note that some of the masquerade support is available only as a kernel module. This means that you must ensure that you “make modules” in addition to the usual “make zImage” when building your kernel. The 2.4 series kernels no longer offer IP masquerade support as a kernel compile time option. Instead, you should select the network packet filtering option: Networking options —> [M] Network packet filtering (replaces ipchains) In the 2.2 series kernels, a number of protocol-specific helper modules are created during kernel compilation. Some protocols begin with an outgoing request on one port, and then expect an incoming connection on another. Normally these cannot be masqueraded, as there is no way of associating the second connection with the first without peering inside the protocols themselves. The helper modules do just that; they actually look inside the datagrams and allow masquerading to work for supported protocols that otherwise would be impossible to masquerade. The supported protocols are: Module Protocol ip_masq_ftp FTP ip_masq_irc IRC ip_masq_raudio RealAudio ip_masq_cuseeme CU-See-Me ip_masq_vdolive For VDO Live ip_masq_quake IdSoftware’s Quake You must load these modules manually using the insmod command to implement them. Note that these modules cannot be loaded using the kerneld daemon. Each of the modules takes an argument specifying what ports it will listen on. For the RealAudio(TM) module you might use:66 # insmod ip_masq_raudio.o ports=7070,7071,7072 The ports you need to specify depend on the protocol. An IP masquerade mini-HOWTO written by Ambrose Au explains more about the IP masquerade modules and how to configure them.67 The netfilter package includes modules that perform similar functions. For example, to provide connection tracking of FTP sessions, you’d load and use the ip_conntrack_ftp and ip_nat_ftp.o modules. Configuring IP Masquerade If you’ve already read the firewall and accounting chapters, it probably comes as no surprise that the ipfwadm, ipchains, and iptables commands are used to configure the IP masquerade rules as well. Masquerade rules are a special class of filtering rule. You can masquerade only datagrams that are received on one interface that will be routed to another interface. To configure a masquerade rule you construct a rule very similar to a firewall forwarding rule, but with special options that tell the kernel to masquerade the datagram. The ipfwadm command uses the -m option, ipchains uses -j MASQ, and iptables uses -j MASQUERADE to indicate that datagrams matching the rule specification should be masqueraded. Let’s look at an example. A computing science student at Groucho Marx University has a number of computers at home internetworked onto a small Ethernet-based local area network. She has chosen to use one of the re 66 RealAudio is a trademark of the Progressive Networks Corporation. 67 You can contact Ambrose at ambrose@writeme.com.