Securing your Solaris server

By Jamie Wilson, Unix Insider |  Operating Systems

It's one of the most terrifying things a system administrator may have to face. After logging into your system, you discover some odd changes have been made. Users like rewt and toor have been added to your password file, both with UIDs of 0. Important system files, such as /bin/ls, /usr/sbin/inetd, and /bin/su, have very recent modification times. netstat -n shows a remote machine connected to your server on port 12345. Your server has been hacked, and, in this case, rooted. A server is rooted when its main Super-User account has been compromised. In this case, the box has been completely taken over and the only hope of restoration is to reinstall the server from scratch. Reinstalling the server, getting applications running properly again, and tracking down the culprits can be a very time-consuming experience, not to mention damaging to any organization. There are a few things an administrator can do to avoid such a compromise.



Disabling inetd and using standalone applications



Inetd is a daemon that runs and listens for network connections on specific ports. When a connection comes into that port, it will launch an application, such as an FTP or telnet server, on that port. The problem with inetd is that it's an easy way for intruders to run back doors on specified network ports. Systems that have been compromised often use inetd to set up a back door for future access that system administrators may not even notice. Furthermore, numerous applications are installed by default using inetd, such as in.rshd and in.talkd, which can create security holes.


The first step toward disabling inetd is to replace daemons that are spawned from inetd with daemons that can run in standalone mode, which means they start up and listen to ports by themselves. As a matter of fact, almost all the daemons in inetd, including in.telnetd, in.ftpd, and all of the remote commands, can be replaced by an SSH server. SSH can be downloaded from ftp://ftp.ssh.com/pub/ssh.


After compiling and installing SSH, you need only to run the sshd binary, usually located in /usr/local/sbin. This daemon will allow you to connect to the server using the appropriate SSH client commands, such as ssh, scp, and sftp. SSH provides further security by enabling encryption between the client and server, thereby preventing clear-text passwords from being transmitted over the network. All security-conscious systems administrators should only use SSH to connect to their servers and avoid using telnet to login.


If you don't want to use SSH for FTP transfers, you can install proftp, available from http://www.proftpd.net.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness