|
This second article in the series takes you through TCP wrappers, OpenSSH,
disabling unnecessary services and better monitoring of system activity by
using unique log files to monitor specific information.
Welcome back to an exciting odyssey in making your Linux box more secure.
In the previous article we dealt with various issues like BIOS security
passwords, securing your LILO prompt with a password, restricting the use
of "setuid" and "setgid" programs etc. We also dealt with common user
habits that compromise security on networks as well as some other aspects
of securing your Linux installation.
As we have mentioned earlier and repeat again, "The only secure machine is
one unplugged from the electrical point." Another point we would like to
stress upon is "Security is not a solution but a way of life."
Quotes apart, lets move on to the next leg of our journey.
A quick reminder before we begin, the words "daemons" and "services" are
interchangeable and mean the same.
Shunting out clear text passwords
We'll begin by covering a few elementary aspects of SSH, you should also
check out our more detailed article on SSH on the site.
Authentication over your local network using plain text passwords is passé.
SSH is a more secure replacement of the telnet and ftp services that you
run on your Linux server. SSH uses the public key - private key concept,
wherein the private key is generated on your machine and the public key
generated by you is distributed to those clients who would like to connect
to you remotely. Unlike telnet and ftp, SSH encrypts all the data that it
transfers over the network, hence even if someone intercepts the packets,
the information would be useless, as everything would be encrypted. This
enhances your security to a certain extent. SSH is an indispensable tool
for all those who regularly use telnet and ftp sessions either locally or
remotely to transfer data.
To install SSH you would require the following packages.
openssh-.rpm
openssh-server-.rpm
openssh-clients-.rpm
openssl-.rpm
For installation of the OpenSSH and OpenSSL packages and other details
refer the previous article on OpenSSH installation at our site.
Now lets see how we can use SSH to connect to a remote machine and initiate
an encrypted telnet session.
bash# ssh -l username my.machine.com
The command to copy files to a remote machine could be done by the
following command.
bash# scp /path/to/local/file my.machine.com:/path/to/remote/directory
SSH can also be used to encrypt your POP and IMAP sessions. It works as
follows, SSH encapsulates the IMAP and POP protocols in a process called
tunnelling to prevent any transfer of clear-text passwords over the
network. Implementing such a solution isn't too much of an overhead if you
begin thinking like the cracker next door.
Disabling unnecessary services
The Linux installation I worked with was a SuSE box with a custom
installation. But this will vary from installation to installation. Most of
the users prefer a generic mode of installation like the server or desktop
installation. These default installation procedures install and start
various services that one may never require on one's network. It's
therefore necessary that you take a look at the various processes that are
running on the system and make it a point to disable the services that you
will never make use of.
One command that will let you sieve through the various services and
processes running in your memory space is the "ps" command.
bash# pas aux | less
The following is the output of the above command on my machine. It is a
list of the various processes that were running on the machine at the time
this memory snapshot was taken.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 160 0.0 0.3 1644 148 ? S 09:01 0:00 /usr/sbin/nmbd -D
root 162 0.0 3.6 3292 1680 ? S 09:01 0:00 /usr/sbin/smbd -D
root 166 0.0 0.9 3312 432 ? S 09:01 0:00 /usr/sbin/squid -sYD
squid 167 0.0 4.6 5928 2144 ? S 09:01 0:01 (squid) -sYD
squid 168 0.0 1.0 1280 492 ? S 09:01 0:00 (dnsserver)
squid 169 0.0 1.0 1280 492 ? S 09:01 0:00 (dnsserver)
The first two processes are related to the SAMBA server on the Linux box.
/usr/sbin/nmbd are the NetBIOS over IP naming services for Windows machines
and /usr/sbin/smbd is the SMB server for both windows and UNIX machines.
The last three services are related to the SQUID caching proxy server on
the machine. Thus by going through the processes in your memory space you
get an idea about the services that are running on your machine. If there
are services that have been started by default and you have no use of those
services then we suggest that you disable those services rather than have
unknown loopholes in those daemons cause trouble.
Another place to check for the running services are through the "inetd"
daemon which can be configured through /etc/inetd.conf. To disable any
service running through the inetd daemon just comment out the particular
line. Also depending on the runlevel your machine is running various
startup scripts you will find the symlinks to them in /etc/rc.d/rc*
directories in any Linux distribution.
Take for instance runlevel 3 on the SuSE linux distribution, which is
multi-user with network and Xwindows. The startup scripts for this runlevel
are located in /etc/rc.d/rc3.d. Thus by adding or removing any symbolic
links in this particular directory one can add or remove any services in
this runlevel. The same holds true for the various runlevels and the
startup scripts for that are located in the /etc/rc.d/rc*d directories.
To edit these services in RedHat, use the "chkconfig" utility, which is
implemented using the following parameters.
bash# chkconfig --list <-- Lists all the services configured to run in
this runlevel.
bash# chkconfig --del service_name <-- To delete a service in a
particular runlevel.
On SuSE this can be accomplished by using the tool YaST. The procedure is
as follows, run the command "yast" as root. Enter System Administration -->
Change Configuration File --> Services to be started at boot.
Alternatively you could also edit /etc/rc.config by hand and run the script
"SuSEconfig". If you are a novice, you would be better of sticking with
YaST.
Using TCP wrappers
On many Linux distributions, the inetd daemon is used to start various
other services on the Linux machine. Let's see how the inetd daemon works.
The inetd daemon is started normally from the /etc/rc.d/init.d/inetd
startup script. The location of this script may differ among distributions.
The inetd daemon works by accepting connections for other services and then
redirecting the connection to the respective service. This is done by
spawning a new process of the service wanted. There are various pros and
cons to starting services through the inetd daemon, but we won't discuss
any of those over here. Some of the most common services that can be
started through the inetd daemon are nntp, smtp, pop, time, talk and smb.
The only issue out here is about configuring the inetd daemon to accept the
connection and pass on the connection to the particular service.
Edit the /etc/inetd.conf and comment out the services that you wouldn't
want running on your machine. The inetd daemon also allows you to restrict
connections made to the inetd server through two main files located on your
/etc directory. These files are /etc/hosts.allow and /etc/hosts.deny.
This mechanism of exhibiting control over the process of administering the
connections to the various services is what is known as TCP WRAPPERS.
Through these two files on your system you can control access to all the
services that run.
Before making any changes take a backup of both of the files. Now, edit the
file /etc/hosts.deny in your favourite text editor and delete all the
entries. Add the following to the file.
ALL:ALL
Close the file and save the changes to hard disk. Having done this you have
disabled access to all the services that you run through your inetd daemon.
If you would like to know about the failed connection attempts to your
machine then change the above entry to the following.
ALL:ALL:/bin/mail -s "%s connection attempt from %c" freeos@localhost
Close and save the file. What we have done is asked the inetd daemon to
monitor for any failed connection attempts to the servers that we are
running through the inetd daemon. In case any failed attempts are made, a
mail is sent to "freeos@localhost" with the name of the service to which
the connection was made and the IP address from which the connection
originated.
Let's now learn how to enable services to specific daemons. Edit the file
/etc/hosts.allow in your favourite text editor and the following line to
your file.
in.telnetd: 192.168.1.
in.ftpd: freeos.linuxlinks.com, mydom.yahoo.com
Though these entries are pretty obvious lets quickly go through each one of
them. The first entry is for the "in.telnetd" server, which is the telnet
server. The IP address range 192.168.1. allows any IP addresses from
192.168.1.1 - 192.168.1.255 to connect to the telnet server on this
machine. Similar to this is the next entry, the only difference being that
the restrictions apply to the "in.ftpd", the FTP server. Machines, which
are allowed connections to the FTP server, have been explicitly mentioned
out here. Thus we have firewalled the services that run through the inetd
service on your machine by making use of TCP WRAPPERS.
The changes will be evident once you have restarted the inetd service on
your machine.
Fine tuning your system logs
There are two main logging daemons running on your Linux machine -- "klogd"
and "syslogd". "klogd" is the kernel logging daemon and "syslogd" is the
logging daemon for system related services. The configuration file for
syslog is /etc/syslog.conf. Lets fine-tune this file to get syslogd to dump
more accurate information into the logs. This additional information can
always be useful in case of break in or if there is any other malfunction
of a particular service.
Our /etc/syslog.conf looks as follows.
# Start of the /etc/syslog.conf file# Monitor authentication attempts
auth.*;authpriv.* /var/log/authlog
#----------
#--> This is to dump all the authentication attempt related output to the
#file /var/log/authlog.
#----------# Monitor all kernel messages kern.* /var/log/kernlog
#--------------
# --> This is to dump all the kernel related messages to the
#file /var/log/kernlog.
#--------------# Monitor all warning and error messages
*.warn;*.err /var/log/syslog
#-------------
# --> All the errors and warning messages are appended to the file
#/var/log/syslog.
#-------------
# End of /etc/syslog.conf
Most of the distributions often have only one or two log files where all
the information regarding authentication messages, error messages, kernel
log messages are stored. We would certainly like to clean up the act and
have different information stored in specific files. The advantage of
having placed the different logged information in other files is that at
the time of retrieval it is easier to sort through the data as all the data
related to one particular activity is present in one file only. Having made
the changes to syslog.conf file, make sure you create an empty file of 0
bytes (touch filename) for files that are to be logged to. All files
mentioned in /etc/syslog.conf should be created at the locations mentioned
there as well as with the chosen filenames.
Only having logs in place to record all the activity is not enough, a good
system administrator also has to think of the devious minds at work trying
to erase all the signs of suspicious activity on your machine. This
requires you to ensure that file permissions are properly set.
Restrict access to log directory and syslog files for normal users using
the following commands.
bash# chmod 751 /var/log /etc/logrotate.d
bash# chmod 640 /etc/syslog.conf /etc/logrotate.conf
bash# chmod 640 /var/log/*log
source: http://www.freeos.com/articles/2896/
|
Subscribe to this comment's feed
Show/Hide comments
Show/Hide comment form