Linux Network Administrators Guide Prev Chapter 13. The Network Information System Next Using NIS with Shadow Support Using NIS in conjunction with shadow password files is somewhat problematic. First we have some bad news: using NIS defeats the goals of shadow passwords. The shadow password scheme was designed to prevent nonroot users from having access to the encrypted form of the login passwords. Using NIS to share shadow data by necessity makes the encrypted passwords available to any user who can listen to the NIS server replies on the network. A policy to enforce users to choose good passwords is arguably better than trying to shadow passwords in an NIS environment. Let’s take a quick look at how you do it, should you decide to forge on ahead. In libc5 there is no real solution to sharing shadow data using NIS. The only way to distribute password and user information by NIS is through the standard passwd.* maps. If you do have shadow passwords installed, the easiest way to share them is to generate a proper passwd file from /etc/shadow using tools like pwuncov, and create the NIS maps from that file. Of course, there are some hacks necessary to use NIS and shadow passwords at the same time, for instance, by installing an /etc/shadow file on each host in the network, while distributing user information, through NIS. However, this hack is really crude and defies the goal of NIS, which is to ease system administration. The NIS support in the GNU libc library (libc6) provides support for shadow password databases. It does not provide any real solution to making your passwords accessible, but it does simplify password management in environments in which you do want to use NIS with shadow passwords. To use it, you must create a shadow.byname database and add the following line to your /etc/nsswitch.conf : # Shadow password support shadow: compat If you use shadow passwords along with NIS, you must try to maintain some security by restricting access to your NIS database. See the section called NIS Server Security earlier in this chapter. Prev Home Next Using the passwd and group Maps Up The NetworkFile System
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
Prev Home Next Using NIS with Shadow Support Mounting an NFS Volume
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
mount will try to connect to the rpc.mountd mount daemon on vlager via RPC. The server will check if vale is permitted to mount the directory in question, and if so, return it a file handle. This file handle will be used in all subsequent requests to files below /users. When someone accesses a file over NFS, the kernel places an RPC call to rpc.nfsd (the NFS daemon) on the server machine. This call takes the file handle, the name of the file to be accessed, and the user and group IDs of the user as parameters. These are used in determining access rights to the specified file. In order to prevent unauthorized users from reading or modifying files, user and group IDs must be the same on both hosts. On most Unix implementations, the NFS functionality of both client and server is implemented as kernel-level daemons that are started from user space at system boot. These are the NFS Daemon (rpc.nfsd ) on the server host, and the Block I/O Daemon (biod ) on the client host. To improve throughput, biod performs asynchronous I/O using read-ahead and write-behind; also, several rpc.nfsd daemons are usually run concurrently. The current NFS implementation of Linux is a little different from the classic NFS in that the server code runs entirely in user space, so running multiple copies simultaneously is more complicated. The current rpc.nfsd implementation offers an experimental feature that allows limited support for multiple servers. Olaf Kirch developed kernel-based NFS server support featured in 2.2 Version Linux kernels. Its performance is significantly better than the existing userspace implementation. We’ll describe it later in this chapter. Preparing NFS Before you can use NFS, be it as server or client, you must make sure your kernel has NFS support compiled in. Newer kernels have a simple interface on the proc filesystem for this, the /proc/filesystems file, which you can display using cat: $ cat /proc/filesystems minix ext2 msdos nodev proc nodev nfs If nfs is missing from this list, you have to compile your own kernel with NFS enabled, or perhaps you will need to load the kernel module if your NFS support was compiled as a module. Configuring the kernel network options is explained in the Kernel Configuration section of Chapter 3. Notes [1] Rick can be reached at jrs@world.std.com. [2] Actually, you can omit the t nfs argument because mount sees from the colon that this specifies an NFS volume.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services
Linux Network Administrators Guide Prev Next Chapter 14. The NetworkFile System Table of Contents Preparing NFS Mounting an NFS Volume The NFS Daemons The exports File Kernel-Based NFSv2 Server Support Kernel-Based NFSv3 Server Support The Network File System (NFS) is probably the most prominent network service using RPC. It allows you to access files on remote hosts in exactly the same way you would access local files. A mixture of kernel support and user-space daemons on the client side, along with an NFS server on the server side, makes this possible. This file access is completely transparent to the client and works across a variety of server and host architectures. NFS offers a number of useful features: l Data accessed by all users can be kept on a central host, with clients mounting this directory at boot time. For example, you can keep all user accounts on one host and have all hosts on your network mount /home from that host. If NFS is installed beside NIS, users can log into any system and still work on one set of files. l Data consuming large amounts of disk space can be kept on a single host. For example, all files and programs relating to LaTeX and METAFONT can be kept and maintained in one place. l Administrative data can be kept on a single host. There is no need to use rcp to install the same stupid file on 20 different machines. It’s not too hard to set up basic NFS operation on both the client and server; this chapter tells you how. Linux NFS is largely the work of Rick Sladkey, who wrote the NFS kernel code and large parts of the NFS server.[1] The latter is derived from the unfsd user space NFS server, originally written by Mark Shand, and the hnfs Harris NFS server, written by Donald Becker. Let’s have a look at how NFS works. First, a client tries to mount a directory from a remote host on a local directory just the same way it does a physical device. However, the syntax used to specify the remote directory is different. For example, to mount /home from host vlager to /users on vale, the administrator issues the following command on vale:[2] # mount -t nfs vlager:/home /users
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
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. Prev Home Next Passive Collection of Accounting Data Configuring the Kernel for IP Masquerade
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services
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 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.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
Linux Network Administrators Guide Prev Next Chapter 11. IP Masquerade and Network Address Translation Table of Contents Side Effects and Fringe Benefits Configuring the Kernel for IP Masquerade Configuring IP Masquerade Handling Name Server Lookups More About 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 Linux-based 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,
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
Networking options —> [*] Network firewalls [*] TCP/IP networking … [*] IP: accounting or in 2.4 series kernels: Networking options —> [*] Network packet filtering (replaces ipchains) Prev Home Next A Sample Firewall Configuration Configuring IP Accounting
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
Linux Network Administrators Guide Prev Next Chapter 10. IP Accounting Table of Contents Configuring the Kernel for IP Accounting Configuring IP Accounting Using IP Accounting Results Resetting the Counters Flushing the Ruleset Passive Collection of Accounting Data 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. 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:
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
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. Prev Home Next More Advanced PPP Configurations What Is a Firewall?
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services