Release Date : 6th April 1999
Previous Versions: none

Linux Mini Administration HOWTO.
By Kostas Petrakis aka Pestilence.

This was written mostly as a small guide to some NT based co-workers here at
my work so that they could check a few stuff on Linux systems if needed.
Also i decided to write this because there are lots of administration howto's
out there which are also kinda old.
This paper in not a super-detailed paper, for this purpose there are other
papers mentioned in the end of this HOWTO. This paper was intented to give a
small clue of what people should check before they decide to allow services to
run on their systems, or fully connect to the Internet.

More and more people everyday connect their systems to the Internet, and more
people are seriously thinking of buying either a leased line, or a cable modem
and stay 24-7 on-line.
There are allot of systems on-line some of them are tight secured, and
others are openwide yelling to be hacked.
This text is intented to give a small idea of what someoone should check at
his system before he goes on-line, or what to secure once he is on-line.

SERVICES

Many servers over the Internet offer a wide of services to their users and
customers, what comes here is a big risk since time has prooved that allot
of services are usually buggy and easily exploitable providing root access, or
other kinds of access to remote or local users.
An administrator of either a  home system, or a company, should be
able to keep on track of this bugs and try to keep his software as more up to
date as he can. This can be done by subscribing to several security mailing
lists, such as Bugtraq, or Cert (Links included in the end of this document).
Another major issue on services are the configurations of each service.
Services usually follow a "guideline" of operation, which is usually declared
in the configuration section of each service. Most buggy services have
prooved to be: sendmail, web servers, ftp servers, and generally all
services that have to do with interaction between the user and the file
system. People oftenly like to bypass the configuration of services, and like
to leave them the way they where installed, without even taking a look at what
configurations are offering, this is a major mistake oftenly found to Junior
administrators, or newcomers to the Unix world. 

WEB SERVERS

Web servers keep their configuration files under the directory /etc/httpd/conf
(default installation from the Linux distribution, which we encourage you to
update to the most recent), or to /usr/local/apache/conf if recompiled, and you
leave the paths intact.
Take a good look at the configuration, sometimes you will see it has entrys
you wouldn't want to, the one you should surely check is under what user does
httpd operate, make sure httpd runs under user:nobody and group:nobody. Check
that the log directory is not user writable, you dont want users "playing" with
your log files now do you?.
The biggest security thread though lately with httpd, is it's CGI's.
CGI's are small programs written either in perl, or C, which are used by the
webserver, and are usually the most dangerous.
CGI's if coming from some unknown or not that reliable source should be
checked for possible problems in their code which would risk the security of
your webserver. The security risks a CGI could possibly create are the
following:
1) Expose Information of your Webserver and its local filesystem/ users.
2) Search Scripts are the most dangerous, since a small missconfiguration,
would allow remote users to search your entire filesystem, and reveal high
risk information to them. Even if you dont run your webserver as root, you
still have chances to run in big trouble.
Try not to give access to users (if you allow user webpages, or have
virtualhosts) to their cgi-bin directories, instead let them mail you and ask
you to check a cgi script they want to use, or even better give them a list of
CGI's they can use, that you trust.
Avoid suid privilleged scripts, they are high risk and there is rarely the
need for a script to be under such privilleges.
Try to have scripts that validate the contect submmited by forms, validation
of data is a more secure way to control what is being passed to your system.
Avoid scripts that will allow remote systems to use them (Matt's scripts allow
this feature).
And finally avoid all scripts that have to do with web interfaces on
services...this scripts usually are of super high risk!
More on web security can be found following the links below.

FTP

FTP servers, are another high Risk on systems, generally it would be wise to
avoid the use of FTP if there is no need, or if there is a need you should
avoid having anonymous ftp enabled.
FTP servers are used for file transfers between hosts. More oftenly they are
used to give users of systems access to their websites.
If you are from the persons that love, or like to contribute to the Linux
community either with having a public ftp server offering mirroring services,
or using the ftp server to release your software you should be very carefull,
of what you give, and what you allow remote users to have.
The default ftp daemon that comes with the Linux installation is wu-ftp, this
server is simple, and good, but unfortunately several bugs where discovered,
and it seems updates are not that often to it. So i recommend the use of a
more advanced FTP server, which will allow you to have more detailed
configuration files. One ftp server i like allot and use oftenly is ProFTPd,
this server has an apache like configuration file, and allows the admin to
have full control over it.
Its widely used on major sites such as Linuxberg, Freshmeat, it updates
frequently and they have a very good responce time over bugs found on it.
It's site offers a very good documentation, and the configuration of it is
really easy even from the average users who want to give partial access to
remote users.
It can run as a standalone daemon, or through inetd with the use also of
tcp-wrappers.
For instance lets have a look how ProFTPd is configured to allow remote users
to upload to a directory, but deny them to download from that dir (good to
deny warez usage of your ftp server) and also deny them the creation of
subdirectories.
<Anonymous /home/ftp>

              User ftp
              Group ftp
              UserAlias anonymous ftp

              <Directory *>

                     <Limit WRITE>
                     DenyAll
                     </Limit>

              </Directory>

              <Directory incoming>

                     <Limit STOR>
                     AllowAll
                     </Limit>
                     <Limit READ>
                     DenyAll
                     </Limit>

              </Directory>

        </Anonymous>
This is what the entry looks like in proftpd.conf, this denies the remote
anonymous users to write to any directory except of incoming, in that
directory anonymous users are allowed to upload files, but they are denyed of
reading the directory, deletetion of files, or the creation of
subdirectories. If you are more paranoid and even if you have limited the usage
of ftp only to valid users but you need more security, you can make use of a
nice firewall, this though requires that most of your ftp users are local
users, and remote users that are allowed usage of the ftp server have static
IP's. To do so, you would setup a firewall allowing access from your subnet,
and the remote users and would DENY everyone else trying to connect to it.

SHADOW PASSWORDS

One of the most important things is the password management. Passwords are
held in the /etc/passwd file (in case you didn't know...). Leaving password
files like that is a high security risk, and even if you don't allow access to
the system to any user, should be more secure.
Password files can be more secure with the usage of shadow, since password
files are user readable you should switch to shadow (i don't understand why
some distributions of Linux don't install by default shadowing), anyway as we
said /etc/passwd is world readable, this means that any user with access to
your system is able to read the password file. The encryption of password
files is really weak, and a simple user with a password cracker would be able
to crack a few passwords in a few minutes. Its highly advisable to all users either with local
boxes or company administrators to switch to shadowing.
To use shadowing on your system you only have to run the pwconv command
usually residing in the /usr/sbin directory. This will create a seperate file
in the /etc dir called shadow, which holds the encrypted passwords, and will
replace the password field in the /etc/passwd file with a "x" e.g

pestilence:x:500:500::/home/pestilence:/bin/bash

This is the entry in passwd after the usage of shadow.
The original password is kept in /etc/shadow which is readble only by root,
thus denying now the local users to "take a look" at your passwords.
For more security, if you use a radius server with the companion of a cisco
router for authentication, it would be wise to deny access to users at your
system, to do this simply change the shell entrys in the passwd file to some
non-existened shell.

POP

POP is used to allow users to retrieve their e-mail remotely. There aren't much
of pop daemons, but its preffered not to use the default that comes with the
installation (ipop3d), i would advise you to use one such as qpopper, which
runs through inetd and can be used with TCP Wrappers.
POP is a service that usually is wide open, this means that users that have
accounts on your system, but use also on some other ISP can connect to your
system and retrieve their mail.
Usually it's left like that, but if you are really paranoid you can block all
remote systems and allow only local users to connect and retrieve their mail.
Just 1 thing must be sure, don't install a pop daemon that doesn't get the
needed support by it's authors, or doesn't produce some kind of detailed logs
(such as failed password entry attempts, or connections).

SENDMAIL

Here things get a bit more complicated, sendmail is the daemon used to send
and receive e-mails between hosts.
Sendmail uses several configuration files, with its main config file being
sendmail.cf.
Through this file you declare the files to be used for various purposes, such
as the list with the allowed domains to use sendmail (ip-allow, name-allow),
and the relay list, which contains the domains of virtualhosts you host.
Lets take a closer look to sendmail.
Unfortunately sendmail is propably one of the most buggy services on the
Internet, up to now nearly all versions of it have either a remote, or local
exploitation.
Because of this problems you should be really carefull with sendmail, a small
missconfiguration might cause you a big headache later.
The main files you should be carefull with are:
ip-allow --> here you enter all the IP's you want to allow to use your
sendmail...don't leave it blank, otherwise you will have the whole Internet
using your sendmail to mail.
name-allow --> same as above but here you enter the hostnames of the systems
(usually used when VirtualHosting is being done on your systems).
relay --> This file contains the host to wich we allow relaying...this also
shouldn't be left empty.
sendmail.cw --> this file holds all the aliases for your system, this is again
used if you host several virtual domains.
Don't forget to oftenly upgrade your sendmail...yes i know this is kinda like
a small pain in the ass, but it's also your only way to prevent the damage
that a newly discovered bug can produce.

DNS

DNS is the service used to resolve the ip address of a host to a valid
hostname.
All big networks with their own domain use DNS, DNS has been subject to heavy
remote exploitations in the past, and also is a service than can be used to
give away allot of usefull info to intruders (such as your network systems,
intruders combining the BIND version can sometimes guess the remote O/S and
it's version). It's high advisable to move to BIND 4.9.7 or the 8.X series, if
you are still running a 4.9.6 series of it, then you are vulnerable to a
remote root exploitation.
Make sure you have configured DNS properly, otherwise you might experience
problems. Also the use of a firewall (for the interactivy between the primary
and the secondary nameserver) would be highly recommended.

LOGGING

One of the most important aspects of system administration, is extensive
logging, and also constant monitoring of the systems.
Linux logs use various loggers, all of the logs are kept under /var/log.
Let's take a better look at the loggers of Linux:
messages --> here the system ouputs various kernel, and service messages with
the use of sysklogd
secure --> here the system logs connection attempts to various ports from
local, or remote hosts.
mailog --> The sendmail daemon logs nearly everything here.
xferlog --> the ftp daemon outputs its messages here.
wtmp --> When a user logs, or the system reboots this file changes, it's a
binary file and you can't "cat" it or "tail" it, to get access to it you use
the "last" command. This command outputs formated the data kept in wtmp.
System logs allthough are kept under root privilleges doesn't mean once hacked
they cant be modified, there are various tools in the trade which allow users
to erase specific strings from them and thus hide their appearance on your
systems. A way to make it more difficult to erase their presence from the logs
(allthough this doesn't mean they cant still erase), is to use remote logs, 
sysklogd has a feature, which allows system admins to log also on remote
systems. I would reccomend this method, since it allows you to have a seperate
log file on a remote system, and since the hacking scene has allot of newbies
they nearly never check for remote logs.
Allthough the logging facility of Unix systems is good, its not designed to
heavy log. To have a better chances of detecting suspicious moves, i recommend
log daemons for this specific task...detect and log, such loggers are iplog
(which i widely use on my systems). Iplog is a set of 3 log daemons:
tcplog --> logs and detects all tcp connections, it's also able to detect and
log, scans using nmap.
udplog --> logs all udp traffic
icmplog --> logs all icmp traffic
Always try to enable seperate logs for all your daemons (e.g qpopper -->
/var/log/pop), this makes the monitoring process more easy.
Get logcheck,this program will scan your regular logs for security
violations, Unusuall system events, etc.
Try to monitor regulary your systems logs...don't let them pass by, before the
storm there are always some drops of rain...so you might be lucky and stop the
intruders before they gain access. Make some shell script for your logs, and
make them scan your logs for specified strings, enable their usage with the
cron daemon, and make them check the logs in small period of time, so you can
have a nice organized report in small time periods, without confusing your
head in the (usually) huge system logs.

XWINDOWS

Xwindows is another security headache.
Unfortunately Xwindows are allot of risk, so i would advise if you use a
system as a server, not to use Xwindows, as you risk your security with their
usage.
If though you need to make use of them, make sure to setup some security, use
some firewall, and don't forget of the "xhost -" command which will disable
remote access to your X facility.

TELNET

If there isn't a real necesity of it, disable it. Allthough telnet by itself
isn't that much of a security risk, it can be usefull to future intruders to
work their way in e easily. If you need telnet, try to setup a firewall to
restrict access to it.
A simple move also to the total newbies would be to change you /etc/issue.net
file, issue.net usually contains the type of O/S you run, and it's used as a
banner to telnet connections. Allthough there are toold in the trade to detect
what a remote systems O/S is (nmap, quesso), there are also plenty of windows
hacker wannabes which usually will just telnet to check what O/S your
running...deny (even if it's really easy to determine the remote O/S) them
knowledge on your system.

KERNEL OPTIONS

On the 2.2.x series of kernels there are a few interesting options using
booleans under your /proc/sys/net/ipv4 folder, this are icmp_echo_ignore_all,
icmp_echo_ignore_broadcasts .etc, this files are used to specify some
networking "reactions" of your system...it is advised (not necessary though)
to:
echo 1 > 
those files, this will prevent ping replys to ping requests, and also will
help you avoid smurf attacks over your network.
tcp_syncookies is also advised to be echoed to 1, if your system is a widely
used server.
While compiling the 2.2.x kernel don't forget to include as many networking
options as you can, such as routing messages, firewall support, etc.
This will help you setup a more effectively working network.

SNIFFERS

Allthough sniffers aren't necessary to run all the time, it's wise to use them
time to time.
Network sniffers catch and display the datagrams moving around your network,
it's usually a helpfull way to detect problems in your network.
Latest kernels have also the abillity to detect if some device has entered
promiscous mode (sniffer activated on some device). Make sure simple users dont
have access to the sniffer, otherwise you will have big time troubles (since
usually most services use plain text passwords).
There is a big collection of good sniffers, so i wont discuss any of them...i
usually fire up X and run Ethereal if there is a big need to do so.

AUDITING TOOLS

This tools are widely used by hackers to scan networks for known problems...so
if hackers use them, you should also use them.
Nessus is at the moment the best tool for such a task, its nearly
updated everyday and currently it supports 209 security checks.
Always run a scan on your network, check if you missed something, don't allow
intruders gain advantage of something you forgot.
This tools should be used very often on ALL your systems.

TEMPORARY SYSTEMS

Allot of times before i install a server, i temporary connect it to the
network so i can ftp and fetch all the needed files.
Since this systems are getting ready to either replace an existing server, or
be a part of the network as new a server, you should be very carefull.
Intruders dont always scan a single system, they might scan a whole subnet to
get information on every system you have running on your network. So even if
that system is a temporary one, don't bypass it's configuration, configure it
to be as secure as it can be, and try to deny every kind of connection to it
(use a firewall or something).

## /etc/inetd.conf ##

Through this file some of the systems services are handled. The default file
has many useless and unwanted services open. You should modify this file
immediately after you install your system.
Close nearly all ports, and leave open only those you need, echo, time, date
and such ports are rarely used, and are not needed by any programs, so make
sure you disable them.
Services in inetd.conf have the abillity to work with tcp_wrappers. We are
going to explain tcp_wrappers in the next section.

TCP WRAPPERS

Tcp Wrappers are files that are used to restrict access to your system(
allthough i prefer using a firewall for this kind of work). If you are new to
the firewall world, and need really quickly to restrict access to some
services use them, but then go and read the firewall HOWTO :).
The best way would be to use both a firewall and tcp wrappers.
Tcp wrappers use the files: /etc/hosts.allow and /etc/hosts.deny, hosts.allow
holds all the ip addresses of the systems or subnets you want to allow access
to services, and hosts.deny include hosts that are denyed to access services.
WARNING: Not all services use tcp wrappers, for instance sendmail is now a
stand alone daemon, so tcp wrappers wont work with it, make sure you see if a
service supports tcp wrappers before feeling "kinda" secure.

FIREWALLS

Firewalls are something that every administrator loves to have on his network,
firewalling can have many different faces.
1) Connect a Internal Network through a single system (also called
masquerading, but it also can act as a firewall, denying the remote users to
log into the internal Network).
2) A system which through a program such as ipfwadm (for the 2.0.x kernels)
and ipchains (for the 2.2.x kernels) can block and filter connections to user
specified ports.
A firewall acts as a wall between your system and the Internet, you configure
it the way you like it, and it acts that way.
For instance on my system (kernel 2.2.4) when i want to block users connecting
to my telnet port, i would issue the following command:
ipchains -A input -p tcp -s 0/0 -d 194.xxx.xx.xx telnet -j DENY -l
Let's take a better look at this commmand:
-A input --> ipchains after installation come with 3 preinstalled chains
(input/output/forward, meaning the input data, output data, and finally
forwarding data), with the -A flag we tell ipchains to Append our "rule" to
the chain.
-p tcp --> here we specify the protocol, i think the protocol i
mention is obvious...other protocols include udp, and icmp
-s 0/0 --> -s stands for source IP/host/subnet, you can either specify a whole
subnet or a single IP, 0/0 stands for everyone...so we tell ipchains to match
any ip address to this rule
-d 194.xxx.xx.xx --> -d stands for destination IP/host/Network, here we
specified a single IP (xxx used for privacy reasons, change them to your IP
address)this ip is the IP of the destination host, meaning the host that
receives all the data, usually you would specify your system, unless you have
a router-box
telnet --> after the destination host you specify the port, or
service, ipchains can understand services which already exist in the
/etc/service file, otherwise you need to specify a port / range of ports. For
instance if we wanted to block ports from 6000 up to 6010 we would type:
6000:6010 
-j DENY --> here we declare to ipchains what to do with
datagrams that match this rules, simply here we DENY them, other methods
include ACCEPT and REJECT
-l --> -l stands for logging, enabling this options ipchains will output
through the kernel into /var/log/messages every packet that matches this
rules...be aware that this produces usually some heavy logs.
Remember that when you create a rule think wisely, this service may be
needed, or some other hosts must have access to it, by blocking a needed
service you might create some problems.
Always remember that when you want to block a service, but you want to give
access to certain systems/networks, you have to declare first the ACCEPT
rules, and then the DENY, otherwise all hosts will be denyed, since ipchains
compares the datagrams with the chains in a descenting order.
For example say we own pestilence.foo.com and we want to grant access to the
ftp service to cool.foo.com, but DENY everyone else. We would type the
following:
ipchains -A input -p tcp -s cool.foo.com -d pestilence.foo.com ftp -j ACCEPT
ipchains -A input -p tcp -s 0/0 -d pestilence.foo.com ftp -j DENY -l

Now cool.foo.com has access to out ftp, but the rest of the Internet doesn't.
For more information on firewalling take a look at the HOWTO.

Comments, suggestion
pestilence@netplan.gr

flames > /dev/null /* keep them to you :p */

Further References
Here are links that every admin should visit...

http://www.genocide2600.com/~tattooman  /* The biggest Security archive of
Planet earth...just name it...tattoo has it...*/
http://howto.linuxberg.com /* All the known Linux HOWTO's */
http://www.geek-girl.com/bugtraq/index.html /* All BUGTAQ postings are there*/
http://www.technotronic.com /* Another security related site, worth looking */
http://www.rewted.org /* Same as above */
http://www.freshmeat.net /* Nearly every known Linux app indexed */
http://www.linuxberg.com /* The Linux tucows site */

/* and finally some news produced in a way you never saw: (thats for the
fun...)*/ 
http://www.innerpulse.com