|
UNIX Hints & Hacks |
 |
||||||||||||||||||||||||||||||||||||
|
Chapter 1: Topics in Administration |
|
||||||||||||||||||||||||||||||||||||
|
There are various ways to keep remote users out of the system when you have tasks to perform that make that necessary. The following are a few ways to keep them out so you can get your work finished.
Flavors: AT&T, BSD
If the task being performed requires that you bring the system into a single-user state, you have nothing to worry about. In a single user state the network never gets initialized, so no users can get to the system. If you want to work in a single-user state and have the network initialized, you can always execute the networking command manually from a shell and apply one of the other examples that follow in conjunction with this example.
Flavors: AT&T, BSD
Although this probably isn't the best method, it works. If you want the system to remain in a multiuser state while you work and not allow any users to log in to the system, move the original system password file into place.
# cp /etc/passwd /etc/passwd.BAK # cp /etc/passwd.orig /etc/passwd
Step 1: While no one else is on the system, back up the current password file.
Step 2: Copy the original system password file into place.
|
Note - If the original system password file wasn't kept, strip out all user account entries from /etc/passwd. Make sure that step 1 has been executed first! |
If users are logged in while this procedure is executed, they will experience difficulties in accessing their files. This is because all the user information (UID, GID, shell, and so on) was removed from the password file and the system is confused as to who the user logged in is.
If no one is logged in to the system at the time of this procedure then there are no accounts in the password file that users can use to get into the system.
Flavors: AT&T, BSD
Another way to continue to work in a multiuser state and make sure no one can log in to the system is to disable the remote daemons in /etc/inetd.conf that allow users to gain access to the system. When a user connects to the system over the network, the system uses the inetd daemon to establish that connection. If the inetd daemons don't know about the connection that is trying to be established then the system will not make the connection.
# vi /etc/inetd.conf
Step 1: From a shell prompt, edit the inetd configuration file:
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind #shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L #ftp stream tcp nowait root /usr/sbin/wu.ftpd wu.ftpd -a -T350#telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
Step 2: Disable the remote connection daemons by commenting them out with the # character at the beginning of the line.
# ps -ax | grep inetd
77 ? S 0:00 /usr/sbin/inetd 14003 p0 S 0:00 grep inet
# kill -HUP 77
Step 3: Get the process ID of the inetd daemon and restart the daemon by issuing the kill -HUP command.
# ftp rocket ftp: connect: Connection refused
# telnet rocket Trying rocket... Connected to rocket. Escape character is '^]".
Connection closed by foreign host. #
Step 4: Attempt to connect to the machine with ftp or telnet from a remote system. Keep in mind that telnet (on the local system you made the changes on) still works.
It is very important to remember to reactivate these daemons after your changes have been made. I know it sounds ridiculous, but it is easy to overlook after working for hours making changes to the system.
Flavors: AT&T and BSD
There is a brute-force method for disabling all network connectivity to keep users off. It is not recommended, but it does work when the system must be taken off the network. Instead of pulling the network cable from the interface, you can simply disable the interface.
Again, this is not recommended, because so many other possible daemons are relying on the network being up. If NFS, DNS, or NIS/YP are running, the system can hang at certain times or lock up. There would also be problems with sendmail and remote sessions. Even though it appears that this pretty clumsy, there are times when it is effective. The UNIX command ifconfig takes the interface down in seconds.
Syntax:
ifconfig interface down ifconfig interface up
After the interface is taken down and your work is finished, the ifconfig command brings the interface back online when it receives the up argument or when the system is rebooted.
On AT&T-style systems there is a networking script in the /etc/init.d directory that gets executed at boot time. The script accepts a start and stop signal. When a stop signal is sent to the script, it will not only shut down the interface, it will also kill all the necessary networking related daemons as well.
# /etc/init.d/network stop
This is a more efficient way of disabling the network. Whenever possible, this method should be used instead of the previous ifconfig method.
Flavors: AT&T, BSD
There is a file called /etc/nologin that does not by default exist. When the file is created, with or without any size, it denies all remote access to a system. A message can be placed within the file describing why access is being denied.
At the moment the file is created, no new users are able to log in to the system. All the users that are logged in at the time the file was created remain on the system until they are killed off or exit on their own. When the file is removed, all remote access resumes.
If network configurations are not being tampered with, you don't plan to log out, or a reboot of the system is not required in your task, you can do everything yourself remotely from another system.
Step 1: Log in multiple shells into the system. (In case one hangs on you, there are other shells to work in.)
Step 2: Create the nologin file
Step 3: Kill everyone off the system
Step 4: Do your work
Step 5: Remove the nologin file
This works because nologin affects all new connects as mentioned previously. After you have your connections into the system, you are free to do your work undisturbed.
There are two ways to handle the nologin file. The first way locks users out:
# touch /etc/nologin
Using the touch command creates the file and no access is granted to anyone attempting to telnet in remotely. But locking the users out without telling them why is a little rude and you will probably get some phone calls wanting to know what's going on.
The second provides a message to the users:
# vi /etc/nologin
Step 1: Create and edit the file /etc/nologin:
The system is down right now for routine maintenance
and should be back online by 23:00.
Please check back at this time.
Thank you for your understanding,
the UNIX Admins
Step 2: Add a polite message to describe the actions that are taking place. (See the Real World Experience that follows for types of message content.)
The /etc/nologin file works on all flavors for locking out remote shell and telnet sessions from all systems. Some of the newer AT&T-type versions have added remote FTP sessions to this file as well. Test this on the flavor in your environment. If this is true, you won't have to apply example six to your environment.
Flavors: AT&T and BSD
There is a way to block the access of FTP connections into your system, besides using the method in example three. There is a file within the /etc directory called users. This file contains the list of user accounts that are not allowed to have FTP access into the system. If their name does not appear in the list, users are allowed to FTP in to the system. The file is processed by the FTP daemon each time a connection is established. There are no daemons to kill or restart after the file has been modified. It becomes active as soon as it is written.
# vi /etc/users
Step 1: Edit the FTP denial list /etc/users.
root ajlesser adjony dradler gtromero etc...
Step 2: Insert entries into the file. The format of the file is the user's account name.
This file might already exist with a single username in it. It is a good security practice not to have root-level FTP access into a system. So you might see the account root in this file.
If you have a large /etc/passwd file filled with users, you can execute the simple multishell command to build the list for you.
# cut -d":" -f1 /etc/passwd > /etc/users
This command cuts out the first field using the : as the delimiter in the password file. Next, this field in the password file is the user's account ID. Then the command sends the list of IDs to the FTP access file called users.
If you are running NIS/YP on the system, the command to get the global YP password file would be
# ypcat passwd | cut -d":" -f1 > /etc/users
This line reads the password file off the YP master server and outputs the first field, like in the previous example, to the FTP access file called users.
It is a good idea to review this file and check to make sure that everyone in the list needs to be blocked out from the procedures you will be performing on the system.
Many users love to ignore the notices of system outages and will attempt to log in to a system while you are trying to make changes, do backups, or perform updates to the system.
Any time you feel that users will be affected by certain changes that you might be doing to the system, it is a good idea to have users off the system. If you plan to install patches, run backups, create soft-links, move data or filesystems around, make mass changes to the password file, make network changes, or modify the system configurations, it is a good idea not to allow any users on the system.
There are some situations in a 24/7 shop where blocking access to the system cannot be allowed. In situations such as this, the only recourse is to work with the users closely and make sure they stay away from the areas that would affect them. This is sometimes the only possible solution. It also shows you are paying them more attention than others have in the past. If this is not a possible solution, there is no recourse but to schedule an outage or downtime for the system.
To keep your phone from ringing while you are trying to work during this time, provide the users with messages. More is always better; users love to be kept informed. Do not rely on emailing out a notification of when the system will not be available. Many users skim through the many emails that they receive and pass over this type of message. If a user attempts to log in to a system and gets a "Connection refused" error and there is no message set, it's guaranteed that he forgot or didn't know the system was going to be unavailable and your phone will be ringing.
In your message, don't be technical--keep it simple and to the point. The more difficult the message makes the problem sound, the longer they will think the repair is going to take. Try to provide an accurate guess of when you expect the system to be back on line. I try to give myself an extra 30 minutes in case a problem comes up.
|
Warning - Impatient users will write programs to monitor the system you are working on. The millisecond their programs tell them the system is up, the program will start running processes for that user. If you inadvertently allow access before you have finished your work, users might be in the system without you even knowing it. |
Man pages:
inetd, nologin, users, ypcat
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||||||||||||
|
Chapter 1: Topics in Administration |
|
||||||||||||||||||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.