Maybe youre looking for a way to keep track of what your sysadmin team does as

Maybe youre looking for a way to keep track of what

This preview shows page 157 - 160 out of 278 pages.

Maybe you're looking for a way to keep track of what your sysadmin team does as root, so you can quickly find out what happened when something goes wrong. Even if you're the only administrator, it's possible to make a bad error as root without realizing it. An audit trail allows you to go back and see exactly what you did type during that 3:00 AM hacking session. As mentioned in [Hack #61] , giving access to a shell with sudo means that you lose your audit trail the moment the root shell executes. One answer to this problem is sudoscript. Another scenario where sudoscript is useful is one similar to the situation that caused me to write sudoscript in the first place. I was a sysadmin in a small startup whose engineers all had the root password. The IT crew all used sudo, but they had tried without success to convince the engineers to use it. Upon investigation, I discovered that the principal reason for this was the prohibition on running shells with sudo. In fact, the sysadmins used the "everything-but-shells" method the sudoers manpage warns against [Hack #61] . It quickly became clear that I wasn't going to be able to argue that sudo, as implemented, was equivalent to having a root shell; positions had hardened long before I showed up. So, I wrote sudoscript to bring these engineers back into the IT department's supported circle. It worked, and having the audit trail saved my bacon several times. 6.10.1 sudoscript Overview sudoscript is a pair of Perl scripts. One is called sudoshell , or just ss. Contrary to its name, sudoshell is not a shell like tcsh or bash. Instead, it is a frontend script that uses authorization from sudo to run as root
Image of page 157
< Day Day Up > < Day Day Up >
Image of page 158
Hack 63 Restrict an SSH server Control your ssh scripts by placing them in a jail. Using SSH increases the security of file transfers and network logins. Many network tasks, however, don't really need the shell associated with a user account—remote backups, for example. After all, a shell brings with it commands and an entry point into a system's directory structure. That's somewhat scary when you consider that many of your SSH tasks are scripted. Configuring a restricted SSH shell such as scponly can mitigate this risk. Not only does it provide noninteractive (read scripted) logins into the SSH server, it limits the set of available commands. Additionally, it provides a chroot option, allowing you to restrict the scponly user account to its own directory structure. 6.11.1 Installing scponly Before installing this port, read through the available options in its Makefile : # cd /usr/ports/shells/scponly # more Makefile Depending on the scripts you plan on using, consider disabling wildcard processing (which can help prevent accidents like rm -R *). You can also enable rsync support, which is ideal if you're using rsnapshot for backups [Hack #35] . If you want to restrict the account to its own directory, preventing your scripts from accessing anything else on the SSH server, include the chroot option.
Image of page 159
Image of page 160

You've reached the end of your free preview.

Want to read all 278 pages?

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture