Linux Network Administrator Manual (9)
2000-07-29 10:25
Publisher: NetBull Readings: 1181 Translation: Zhao Wei GoHigh@shtdu.edu.cn Chapter 9 Various web applications After setting up IP and analyzer, we now turn over to discuss you want to offer on the Internet service. This chapter explains some simple network applications, including inetd servers, and programs in the Rlogin family. The remote procedure call interface based on the Network File System (NFS) and Network Information System (NIS) is also discussed. However, there are too many configuration contents of NFS and NIS, which will be described with independent chapters. Email and Network News (NetNews) will also be discussed with independent chapters. Of course, we can't discuss all web applications in this book. If you want to install a program that is not discussed here, for example, Talk, Gopher or XMosAIC, please refer to their manual to get details. 9.1 inetd Super Server Usually, the service is performed by a so-called background program {or port monitor} daem. A port monitor is a program that opens a port and waits for an entry connection. If a connection is coming, it creates a child process to accept this connection, while the parent process continues to listen to more requests. This concept has a disadvantage that for each service provided, you must run a port monitoring that monitors a port on a port, which usually means a waste of system resources like swap space. Thus, almost all UN * X installer run a "super server", which creates a socket for many services, and uses the SELECT (2) system call simultaneously listens all of these ports. When the remote system requests a service, the super server notes this and generates the server program for that port. Common super server is inetd, which is Internet Daemon. It is started when the system boot and acquires the list of services they want to manage from the boot file called /etc/inetd.conf. In addition to the server programs described above, there are many general services handled by inetd, called internal services. These include the Chargen that simply produces strings, returns Daytime in the system date time. One line in this file consists of the following fields: Service Type Protocol WAIT USER Server CMDline The meaning of each field is as follows: Service gives the name of the service. By looking up / etc / services file, the service name can be converted to a port number. This file will be described in the Services and Protocols files (10.3). Type specifies a socket type, or Stream (for Connection-Oriented Protocols) or DGRAM (for datastram protocols). Therefore, for TCP-based services always use stream, and UDP-based services always use DGRAM. The Transport Protocol used by the Protocol naming service. This must be the valid protocol name that can be found in the Protocols file, will also be explained below. Wait This option is only used for DGRAM socket. It can be WAIT or NOWAIT. If WAIT is specified, only one server program is executed for the specified port inetd.
Otherwise, after executing the specified server, it will immediately monitor on this port. This is useful for reading all entered datagrams and then exiting the "single thread" server program. Many RPC server programs are this type, so they need to be specified as WAIT. For the opposite type, the "Multi-Thread" server program allows unlimited number of routines to run concurrently; this is rarely used. This server program needs to be specified as NOWAIT. Stream socket should always use NOWAIT. User This is the user's login ID, and the user's process is running. This is usually a root user, but some services can use different accounts. It is a good idea to use the minimum privilege here, which means that you should not run a command in a privileged account. If the program does not need privileges, it will work properly. For example, NNTP News Server programs will run as News, while services that may cause security hazards (such as TFTP or Finger) are often run as Nobody. Server gives the full path to the server program being executed. Internal service with keyword INTERNAL tag. CMDLINE This is the command line (parameter) that passes the server program. This includes parameter 0 - command name. Usually, this is a server program name unless a different name is used, the program has different behavior. This field is empty for internal services. # # inetd services ftp stream tcp noetait root / usr / sbin / ftpd in.ftpd -l telnet stream tcp noait root / usr / sbin / telnetd in.telnetd -b / etc / ipsue #finger stream TCP NOWAIT BIN / USR / SBIN / finterd 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 Figure 9.1 a /etc/inetd.conf sample file. Figure 9.1 shows a sample file of inetd.conf. The finger service is commented, so this service does not exist. This is usually for security reasons because it may be used by intruders to get usernames on your system. TFTP is also commented.
TFTP Realizes Primitive File Transfer Protocol It allows no password checks to transfer any readable files directly from your system. This is especially harmful to the / etc / passwd file, and when you do not use the shadow password file, it will be even more. TFTP is usually used for diskless customers and X terminals to download code from a boot server. If you need to run TFTPD, add some directory names to the customer to get the directory of the customer by adding those directory names to the customer by adding those catalogs on the TFTPD command line. See the second TFTP line in the example. 9.2 TCPD Access Control Tools The application is designed to be able to defend several types of attacks because of a number of security risks that open a computer to network access. However, certain defense may be defects (the most thorough example is the RTM Internet worm), or the unreliable host that requests the specific service that can be accepted is not distinguished from the unreliable host that requests to be rejected. Above we have summarized Finger and TFTP services. Therefore, people want to limit these services to only "trusted hosts" to access, and use usually settings cannot be done, and for all customers are either given to all customers, or one customer cannot be used. To achieve this, a useful tool is TCPD, [1], called a so-called port monitor package (DAEMON WRAPPER). For TCP services you want to monitor and protected, this TCPD will call this TCPD instead of a server program. TCPD will request the request to record the Syslog Background program, check if the remote host is allowed to use, and only the real server program is performed only when checking. Note that this does not work for UDP-based services. For example, when you want to pack Finger Daemon, you must change the corresponding line in Indetd.conf to become # wrapfinger daemon finger stream tcp noet / usr / sbin / tcpd in.fingerD does not add any access control, which will be usually set. As in front of the customer, in addition to any request will be recorded in the Syslog's Auth facility. Access control is implemented by two files /etc/hosts.allow and /etc/hosts.deny. They contain entries that allow and prohibit access to specific services and hosts, respectively. When TCPD processes a service request from a client host named Biff.foobar.com, for example, a Finger service request, which scans Hosts.Allow and Hosts.deny (in this order) file to match this service and host entry . If you find a match entry in Hosts.allow, you will be accessed, regardless of any entry in Hosts.deny. If a matching entry is found in Hosts.deny, the request will be rejected by closing this connection. If you don't find the matching entry, you are also giving access. The entry in the access file looks like this: serviceList: hostlist [: shellcmd] ServiceList is a list of service names from / etc / services, or keyword all. Use "All Except Finger, TFTP" when matching all services in Finger and TFTP. HostList is a list of host names or IP addresses, or keywords all, local or unknown. ALL matches any host, and Local matches does not contain a bit name. [2] Unknown matches the host that failed any name or address query. A host that starts with a point and a domain name equal to this name. For example, .foobar.com matches Biff.foobar.com. There are also regulations on IP network addresses and subnet numbers. See the Hosts_Access (5) man page for more information.
In addition to the local host, you must restrict access to the finger and TFTP services, add the following line to the /etc/hosts.deny file, and /etc/hosts.allow file is empty: in.tftpd, in.fingerd : All except local, .your.domain Optional shellcmd field can contain a shell command that will be called when an entry matches. This is useful for settings that allow potential intruders to expose the traps: 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% H and% D parameters are expanded to customers separately by TCPD Host name and service name. See the Hosts_Access (5) man page for more information. 9.3 Services and Protocols files determined by the "Standard" service port number defined in the "Assigned NumBers" RFC. To make the server and client program to convert the service name into these numbers (values), each host is at least part of the table; it is stored in the file / etc / service. Each entry is the same as: service port / protocol [aliases] here, service specify the name of the service, Port Definition provides the port of the service, which transport protocol for protocol definitions. Usually protocol is one of the UDP or TCP. It is possible to provide a service for a variety of protocols. Similarly, as long as the protocol is different, it is possible to provide different services on the same port. The AliaSS field is used to specify another optional name for the same service. Typically, you don't have to change the Services files from your Linux system. However, we give a small exception in our documents.
# T services file: # # well-known services echo 7 / tcp # echo echo 7 / udp # discard 9 / TCP Sink Null # medad 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 (Contr telnet 23 / tcp # Virtual Terminal Protocol smtp 25 / tcp # Simple mail Transfer Protocol nntp 119 / tcp readnews # Network News Transfer Protoco # # 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 use syslog 514 / udp # remote system logging printer 515 / tcp spooler # remote print spooling route 520 / udp router routed # routing information protocol Note that, e.g., for TCP and the UDP, in Echo service is provided on port 7, and port 512 is used for two different services, ie COMSAT daemon (which is used to remind users to have new emails, see XBIFF (1x)), is used on TCP Remote execution (REXEC (1)). Similar to the Services file, the network library file needs to have a method to place the protocol - for example, those The-converted in the Services file becomes a protocol number that can be understood by the IP layer of other hosts. This is made by looking for the protocol name in the / etc / protocols file. This file contains an entry per line, each entry, includes a protocol name and a related number. Compared with the / etc / service file, you don't have to make any changes to this file. A sample file is given below: # # 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 9.4 Remote Procedure Call Customer - A very common mechanism for server applications is provided by RPC, Remote Procedure Call package. RPC is developed by Sun Microsystems, a collection of tools and library functions.
An important application based on RFC is an NFS-network file system, as well as NIS-network information systems, which will be introduced in later chapters. An RPC server consists of a collection of processes, and customers can call these processes by emitting a RPC request with process parameters to the server. The server will call the specified process on behalf of the customer. If you have any return values, it returns it. In order to be unrelated to the machine, all data exchanged between the customer and the server is converted to the so-called external data representation format (XDR), and the recipient is represented by the transformer. Sometimes, an improved interface for an improvement of an RPC application gives an incompatibility change. Of course, simply changing the server will result in all applications where the previous behavior cannot be used. Therefore, the RPC program has the corresponding version number, usually starting from 1 and with the count value of each new version of the RPC interface. Often, one server may also provide several versions; so the customer can specify which implementation they want to use by the version number in their request. Network communication between the RPC server and the customer has some strange. An RPC server provides a collection of one or more brother processes; each set is called a program, and uniquely specified by a program number (Program number). A list of mapping service names to the program number is usually stored in / etc / rpc. It is given in Figure 9.2 below. # # / Etc / rpc - miscellaenous 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 Figure 9.2 A / ETC / RPC Sample File In the TCP / IP network, the author of the RPC is the problem that the program number is mapped to a normal network service. They choose to provide TCP and UDP port services for each version of each program. Generally speaking, the RPC application will use UDP to send data, and only when data cannot be placed in a single UDP datagram, use TCP transfer data. Of course, the client must have a way to find which program number mapped to which port. If you use a profile to do this will look too flexible; because the RPC application does not use the reserved port, it is impossible to ensure that a port used by our database applications is not occupied by some other process. Therefore, the RPC application captures any port it can get and registered with so-called PortMapper Daemon. The latter acts as a proxy role for all RPC servers running on its machine: a customer who wants to contact a service number will first ask the portmapper on the server host, and PortMapper will return TCP that can reach this service. UDP port number. This method has a special disadvantage that it will bring a failure point that is the same as the inetd port monitor in the standard Berkeley service. However, this situation is even worse, because when PortMapper dies, all RPC port information will be lost; this usually means you have to manually restart all RPC server programs, or simply restart the entire machine.
In Linux, Portmapper is called rpc.portmap and in / usr / sbin. It is started from rc.inet2, others can determine that PortMapper doesn't have to do any configuration. 9.5 Configuring R Commands There are many commands to execute commands on the remote host. These are rlogin, RSH, RCP, and RCMD. They produce a shell on the remote host and allow the user to execute the command. Of course, the customer needs an account on the host that executes the command. So all of these commands must perform an authorized authentication process. Typically, the customer will inform the server user's login, the server then requests a password identified using the usual method. However, sometimes it is desirable to relax the authentication check for a particular user. For example, if you have to log in to other machines on your LAN frequently, you may want to be accepted for each password each time. Disabling Authorization Authentication is only available in situations where there are very few password databases that are synchronized, or for rare part of the privileged users who need to access many hosts due to management. Whenever you want to allow people to log in into your host without specifying a login ID or password, it is sure that you are not accidentally authorized to allow others to access your machine. There are two ways to disable authentication checkings for the R command. One method is that superuser allows specific or all users to log in on a specific or all host (the latter is definitely a bad point) without tangeting the port. This access is controlled by the /etc/hosts.equiv file. It contains a list of hosts and usernames equivalent to users on the local host. Another method is that a user allows other users to access her account on a particular host. These can be listed in the .rhosts file in the owner's home directory. This file must be palpped by the user or super user, taking into account the security, and cannot be a symbolic connection, otherwise it will be ignored. [3] When a customer requests a R service, you will search for her host and username in the /etc/hosts.equiv file, and then search in the.rhosts she wants to log in. RhoSTS. As an example, it is assumed that JANET works on GAUSS and attempts to log in into Joe on Euler. Below, we will see Janet as a customer user, while Joe as a local user. Now, when JANET Type the following row on the GAUSS, $ rlogin -l joe euler server will first check Hosts.Equiv If Janet is permitted free access, and if this check fails, it will look for the .rhosts file in the Joe home directory. she was. The hosts.equiv file on Euler looks like this: Gauss Euler -Public Quark.physics.groucho.edu andres each entry consists of a host name and an optional username. If there is only one host name on an entry, all users on the host will be accepted without any check. In the above example, when coming from GAUSS, Janet will be allowed to log in to her account JANET, which is also like this for any other user, except for the root user. However, if Janet wants to log in with JoE, she will get a prompt message that is usually the input password. If a host name follows a username, as the last line in the above example file, then in addition to the root account, this user will have no password access to all other accounts. There can also be a minus sign before the host name, just like the entry "-public". This suggests that all accounts on the public require authorized authentication, regardless of the individual users being accessed in their.rhosts files. The format of the .rhosts file is the same as the format of Hosts.equiv, but it means a bit different.
Consider the Joe of Joe on Euler: kHOSTS file: kHomp.cs.groucho.edu Gauss Janet's first entry license Joe free access when logging in in from Chomp.cs.groucho.edu, but does not affect (violation) Euler or Any other account on the Chomp. The second entry is slightly different, it agrees that Janet can freely access Joe's account when logging in from Gauss. Note that the customer's host name is obtained by reverse mapping caller's address to the name, so this feature is useless for the parser unknown. In the following cases, the customer's hostname is considered to match the name in the HOSTS file: Customer specification hostname (not an alias) matches the host name in the file. If the client host name is a wholly-owned domain name (such as the return value of the parser when you are running DNS), and the host name in the HOSTS file is not a character, then the host name expanded with the local domain name Compared. Note [1] is prepared by Wietse Venema, Wietse @ wzv.win.tue.nl. [2] Usually only a bit of the local hostname from / etc / hosts is not included. [3] In an NFS environment, you may need to protect it 444 properties because superusers are often very stringent to access files on disk loaded by NFS. [4] Note that when someone tries to log in with root, the hosts.equiv file will not be searched. source:
Linux free pigeon
