Questions and Answers
Bjorn Satdeva SAGE Job Descriptions In the November/December issue, I mentioned the Job Description models prepared by the SAGE Jobs Working group. At the time, no decision had been made on whether, when, or how the material would be distributed. Since then, the SAGE Board has agreed (by a 4-3 vote, which is surprising) to publish the Job Description document. The SAGE Jobs publication is therefore now available from the USENIX Office in Berkeley. It costs $5.00 for SAGE Members and $7.50 for non-members. For copies, and for membership information for either USENIX or SAGE, please contact: The USENIX Association, 2560 Ninth Street, Suite 215, Berkeley, CA 94710 USA; phone: (510) 528-8649; e-mail: office@usenix.org. The e-mail address of the editor, Tina Darmohray, is tmd@eticket.llnl.gov. LISA VII The yearly USENIX LISA System Administration conference (November 1-5) has also taken place since the last issue. This year the attendance almost doubled, at about 1100. Since the LISA conference is where the bleeding edge issues of UNIX System Administration are defined and discussed, it's worth taking a little time to look at some of the papers presented there. This year's conference differed from previous years' in its focus on solutions to problems related to human issues and several interesting papers tackled these issue. Rmy Evard's "Collaborative Networked Communications: MUD as Systems Tools" discussed experiences with using the computer game MUD as a communication tool for the system administration staff. Sally Hambridge and Jeffrey Sedayao's "Horses and Barn Doors: Evolution of Corporate Guidelines for Internet Usage" dealt with some of the experiences and mistakes with Internet access policies at Intel over the years. Laura de Leon, Mike Rodriquez, and Brent Thompson's "Our Users Have Root!" described an environment where the users all have the root password to their own machines, but the system administrator does not. Technical issues were not ignored, however. Todd Miller, Christoper Stirlin, and Evi Nemeth's "satool -- A System Administrator's Cockpit, An Implementation" described a tool which monitors a large number of machines in a distributed environment. Stephen E. Hansen and E. Todd Atkins' "Automated System Monitoring with Swatch" discussed another monitoring tool. Gary L Schaps and Peter Bishop, in "A Practical Approach to NFS Response Time Monitoring" reviewed available tools for researching NFS response time. James da Silva and Olafur Gudmundson contributed "The Amamda Network Backup Manager," desribing a tool for network wide backups. Finally, Karl L Swartz's "Forecasting Disk Resource Requirements for a Usenet Server" presented a model which permits forecasting of disk resource requirements for a full newsfeed. These are just a few of the very good papers presented at the conference, and I include them here to give a general flavor of the proceedings. In fact, this year, we received so many paper proposals that we had to reject papers we really wanted to accept. While this in some ways unfortunate, it helps to ensure that the papers which make it into the conference are of very high quality. If you were unable to attend, I recommend that you get the proceedings for the LISA VII conference (and previous years' proceedings as well, at least since LISA III or IV). I find that one of the outcomes of attending a LISA conference is that I return with enough ideas to keep me busy for the next couple of years -- the only problem is that I have just one year until the next LISA! Next year's LISA conference will take place in San Diego, in Southern California, sometime in the fall. The program chair is Dinah McNutt (dinah@tivoli.com). LISA proceedings can be ordered from the USENIX conference office, 22672 Lambert Street, Suite 613, El Toro, CA 92630 USA; phone: (714) 588-8649; FAX: (714) 588-9706, e-mail: conference@usenix.org. The Firewall Tool Kit and S/Key The Fire Wall Tool Kit (fwtk), a new set of tools intended to greatly simplify the process of building a Internet firewall, has been released to the net. Written by Marcus J. Ranum, of Trusted Information Systems, the kit consists of a number of individual tools which can be used to increase security on existing firewall or to simplify implementation of proxy service on firewalls that consist of just a single bastion host. For a description of some of the major components of the toolkit, see the sidebar, "Overview of the Firewall Tool Kit." The toolkit is available by anonymous ftp from ftp.tis.com; and there is a mailing list where various issues in compiling, configuring, and supporting the toolkit are discussed. To subscribe to this mailing list, send a subscription request to fwall-users-request@tis.com. The Fire Wall Tool Kit's authentication server provides support for some popular one-time password or challenge/response systems, including Security Dynamics' SecurID, Digital Pathways' SNK004 Secure Net Key, and Bellcore's S/Key. The two former are commercial packages using a challenge/response system, while the latter is a publicly available one-time password-based system. While S/Key is perhaps not suitable for larger sites, where many people are allowed to telnet in from the Internet, it offers a cost-effective solution for smaller sites and sites where the users only occasionally need to telnet in. S/Key is available from thumper@belcore.com, and it also has a mailing list. To subscribe to the S/Key users mailing list, send a request to skey-users-request@bellcore.com. New LISA Local Group A new local LISA Group, the EnglishBay LISA has been formed in Vancouver, Canada. The group is planing to meet the third Wednesday of the month at a place to be determined. The next meeting is scheduled for 19 January 1994 at 7 PM. For more information, contact Peter Van Epp from Simon Fraser University, Burnaby, B.C., Canada, at vanepp@sfu.ca. And now to this month's questions.
The GNU people also have a tracking system. This system is primarily used for bug tracking inside the GNU project, but according to the GNU people, it should be adequate for a system administration work tracking system. I haven't yet had time to check this tool out, so I can't vouch for its suitability for this purpose.
Today's TCP/IP networks use three different kinds of addresses, referred to as class A, B, and C addresses (there are actually four, but the class D address does not belong in this discussion). The main difference between the three classes of address has to do with the number of bits used for the network address and host address, respectively. All three types of addresses use 32 bits, but a class A address uses 8 bits for the network address and 24 for the host address, a class B address uses 16 bits for each, and a class C address uses 24 bits for the network and 8 bits for the host address. The address classes can easily be distinguished by the TCP/IP software, because a class A address always starts with a bit 0, a class B address with the two bits 1 0, and a class C address with the three bits 1 1 0. In other words, if an IP address has a first byte less than 128, it is a class A address; if it is in the range from 128 to 191, it is a class B address; and if it is in the range from 192 to 223, it is a class C address. If an organization has been assigned a network address for the purpose of connecting to the Internet, but needs more than one internal networks it can chose to split its host address space into several networks. This is less complicated than it sounds: it actually is just a matter of expanding the number of bits in the full address, which is interpreted locally as part of the network address. I'll use a class C address as an example to clarify some of the details (even though subnets are much more common in installations using class B addresses, using a class C address here helps makes the explanation clearer, as there will be no room for misunderstandings based on the address type). In a class C address, the network address takes 24 bits, and the host address takes 8 bits. However, an organization can decide internally to extend the number of network bits, at the cost of the number of host addresses. Say, for example, that you want to split the class C address into 16 subnets, each with 16 host addresses -- or, more specifically, the network address is 28 bits, and the host address is 4 bits, still at a total of 32 bits. You tell the computer that you're using a larger than usual network address when you configure the network with the "ifconfig" command. Normally, you would specify the subnet mask as 225.225.225.0, which is the 24 bits of network address and 8 bits of host address (with 225 being equal to FF hex, or all eight bits equal to one). What you'll need to do to establish your subnets to split the last byte (the zero) into the network part (the four most significant bits) and the host part (the four least significant bits), or in other words, a network mask of 255.255.255.240. The negative side of this of this is that subnet numbering gets really ugly from a human perspective, as the network numbers and broadcast addresses are no longer clean and easily recognizable. In a traditional network address, host address zero is the address of the network itself, and address 225 is the broadcast address: in other words, a host address of all zeros is the network, and an address of all ones is the broadcast address. In the subnets described above, the situation is similar, but the numbers don't come out neatly. Figure 1 shows the subnetting of the class C address 195.237.119.0. If the networks are named after the least significant byte, then network 0 will have an address of 195.237.119.0 and a broadcast address of 195.237.119.15, while 195.237.119.1 to 195.237.119.14 will be available for host addresses. Similarly, network 16 will have a network address of 195.237.119.16, host addresses 195.237.119.17 to 195.237.119.30, and a broadcast address of 195.237.119.31. While this may sound complicated, if you look at Figure 1, it should become clear. You will need to specify the netmask everywhere you are configuring the network, as in the ifconfig command, and in your routing configuration. It is in fact good practice to do so, even if subnets are not used.
A better solution is to modify login to pause for about five seconds after a bad login before printing the login banner again, and to disconnect if the more than three to five unsuccessful login attempts. This will not prevent brute force attacks, where a remote computer is programmed to attempt logins as fast as possible, but will make such attacks highly unpractical, without inconveniencing your legitimate users too much. For more stringent security, you will need to install some kind of a challenge/response system, as such a system is very difficult, if not impossible, to break. If it's not otherwise available, you can get the login program from the BSD Net2 distribution.
About the Author
Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.
|
I want to configure one of our Sun workstations to
use
UUCP, allowing for both dial-in and dial-out connections.
I have configured
the system as described in the Sun System Administration
Manual, and
it works OK in the beginning, when the system is newly
re-booted.
However, after a few hours, it is no longer possible
to dial in, and
at times, the dial-out is also affected. What have I
done wrong? PS:
It is running SunOS 4.1.1.
Probably nothing! Apply Sun's tty jumbo patch, and
the
problem will in all likelihood go away.