secure

How do I protect my machines??

Leave it in the box.

Seriously, the only sure way to protect a machine is not to use it. If one uses a machine, there will always be a risk of the machine being compromised or infected with a virus. However, there are steps which one can take which will limit the amount of damage and could prevent certain forms of attack and infections.

The bare minimum form of protection is the application of vendor-provided patches as soon as the machine is installed and before the machine goes into production. See the various vendor's web sites for information regarding patches and updates.

The next step will be a bit more information generated and stored by the system. Process accounting is generally provided, but must be turned on for some operating systems. The information provided depends upon the version and operating system on the machine.

Okay, so you want to know who is connecting to your machines and where they are coming from. The two most popular tools for host based monitoring of connects are Tcpwrappers is another item which should be installed and its output logged correctly. tcpwrappers allow host and user based access control lists for various tcp services such as telnet, ftp, rlogin, rsh and tftp. It is also a good idea to protect the info handed out by rpcbind via Weitse Venema's rpcbind

A note about log information: syslog for major operating systems has the capability to not only log the data to the local system, but to a remote system as well. Due to the malicious and destructive nature of some hackers, I strongly suggest that both happen, or at a minimum, the information be logged to a remote site. The remote system should be a tight-ass box or boxes. (This isn't perfect either, but better than nothing).

I also suggest a different, custom-made /bin/login and ftp server. These two should log further information to different locations other than utmp/wtmp. They should at a minimum log who connected from where at what time and when they left. This information can be beneficial in responding to an incident. utmp and wtmp records are well known and easily modified. Specialized login programs can create records not so well known and modified(one can differ the syslog levels and locations of such files, granted a smart hacker will know of /etc/syslog.conf).

I'll come back to log information.

Next thing, restricting access and default permissions.

1) At boot time:

Go through /etc/init.d/rc* and /etc/rc* and see what is actually started when the machine boots. What do you really need? If you're unsure of something, read the man page for the various service and determine if you really need the functionality provided by the service. If you don't and are thinking "well maybe one day i'll use it" turn it off because more than likely you have no idea what the thing does nor how to operate it correctly. If you really are wondering, ask someone else or look the info up on the web from authorized sites -- namely the vendor's webpage.
Normally, a standard machine doesn't need to run routed, snmpdx, uucp, or aspppd.(In english -- routed -- how does this machine route packets? well, duh, you use the router for your subnet. snmpdx? are you really going to use the machine to monitor network performance or debug network problems at the netcom pro's level? uucp? we use sendmail now to transport mail, catch up with the times. aspppd? does the machine have a modem? are you going to dial in/out of it?)
nfs server? are you going to export filesystems from the machine? allow other machines to mount disk drives, etc? If your machine is an nfs client or needs the nfs client programs(statd and lockd), I'll cover how to secure this in a minute. If the machine isn't mounting disks and doesn't need the client programs running, then remove the script from /etc/rc*.d.
Some operating systems use autofs, cachefs and a variety of other OS specific improvements which may or may not work for you. More than likely, you can live without them and not see any real degradation in performance. If you _can_ live without them, then you have a few less programs to worry about patching and securing.

One thing that isn't started by default on some systems, but should be, is xntpd or ntpd -- the network time protocol daemon. This little program maintains clock synchronization -- a very very important thing to have in investigations. Typically the only thing needed to start this daemon is a config file located either at /etc/ntpd.conf or /etc/inet/ntpd.conf. Check the rc script for the specifics of your OS.

2) Via the network:

Check /etc/inetd.conf or /etc/inet/inetd.conf (in Solaris, /etc/inetd.conf is a symlink to /etc/inet/inetd.conf). You can turn off:

        tnamed
        chargen
        echo
        discard
        daytime
        rexec
        comstat
        finger
        uucp
        tftp
        rwall/wall
        sprayd

If you're not going to be running an ftp server, you should turn off:

ftpd

If you're going to be running ssh, which I strongly suggest, then you can turn off:
(there are mac and pc clients for ssh)

telnetd

If you're not going to use the vendor's remote administration tools, you can turn off rpc services such as

admind

If you're not going to be using the machines calendaring software, turn off:

rpc.cmsd

If you're not going to be using Tooltalk, part of some default vendor windowmanagers, turn off:

rpc.ttdbserverd

Anything which is tcp based and will remain in /etc/inetd.conf should be tcpwrapped. Basically this requires that once the tcpd program has been compiled and placed in /usr/sbin, then all that remains is changing the 2nd to the last column to:

/usr/sbin/tcpd

A note about identd, which I believe is listed in /etc/inetd.conf as well, it can be run as the user "sys" depending on how the permissions of the filesystems are layed out. You should investigate this since the user "sys" isn't as privileged as the user "root" and any holes in identd won't gain root access immediately.(Note, I say immediately b/c it could give a remote use local access, and with local access, the perp might be able to exploit other holes in your machine).

If you're not going to be using the machine as a font server, imap server, pop server, or if you have no idea what those things are, turn
them off.

Btw, when I say "turn off this service", I mean put a # at the beginning of the line containing the info in /etc/inetd.conf and once all modifications have been made to that file, send a HUP signal to the running inetd.

3) Local Filesystem:

This one is the most fun and most eh, frightening. =)
Once someone has local access to your machine, they have a whole other set of exploits they can attempt. Usually the will make use of holes in set-uid (suid) executables that basically give temporary root access for normal users. These progams can be discovered by doing:

find / /usr /var -xdev -perm +4000 -a -user root -ls

There will probably be around 20 to 80 such programs depending on the operating system. Most holes are exploited by either passing unexpected arguements to the program or by running the program under an abnormal environment. Again vendor patches is the key most of the time. However, if there are programs listed in this output which users will not or should not be using, then they should have their suid bits removed. And when I say "users" here, I also mean things the system would need to unknowingly run when the user fires off an app, typically window managers are run as the user, but they(the window manager) might need to access restricted parts of the system to function correctly, and when they need to access such parts, they run one of those suid executables(/usr/lib/pt_chmod comes to mind).
You should also be aware that if this list changes, either by the addition of a program or a file size change, without your knowledge, a perp might have left a backdoor in place to gain root access. In one incident I discovered a root shell(suid shell as root) as /usr/bin/eject.

It might be a good idea, for the suid programs which the users are allowed to run, to create a wrapper script which checks the size of the arguements and the environment variables that are passed to the programs. The real suid executables are placed in a repository, their suid bits removed, and the wrapper script is placed, with a suid bit, in the executables normal position, with the executables name. Thus, when the program is run incorrectly, it won't break and allow privileged access. One could also have the wrapper script log who ran the program with invalid arguements and environment.

Some things which are really bad mojo and ways to handle 'em:

.rhosts, rsh/rlogin -- DON'T USE THEM. use ssh instead. The r-suite of tools are based solely on host identity. If you're coming from machine foo with userid blah, sure, I'll let you in. Ssh however requires that not only do _you_ have the right set of keys, but also the machine you're coming in from. Ssh works like this: Hi, I'm blah, here's my driver's license and I'm driving minnie and here's her registration, I want to go to Wendy's. Oh look, Wendy's has their commerce license saying they're Wendy's. Yes Wendy, here's my info about me and my car.
If anything is changed you either get denied or a stern warning from ssh.

statd -- one of the NFS client programs
This little baby has had a number of holes over the years and exploit scripts have been available well before a vendor patch. Currently, with some operating systems (I have only tried this on Solaris machines, but I expect others can work the same way), statd can be run as a user other than "root". It involves changing a few ownerships on the local filesystem and modifying the rc script. On Solaris 2.5.1 through Solaris 7:

chown -R daemon /var/statmon
edit /etc/init.d/nfs.client and change:

/usr/lib/nfs/statd 2>/dev/null & (or whatnot)

to:

su - daemon -c /usr/lib/nfs/statd 2>/dev/null/foo

I imagine that other OS' might place their NFS client files under /etc, such as /etc/sm.bak or /etc/sm or some such. Perhaps changing their owners to daemon will allow statd to be run under daemon. Experimentation is suggested before putting the machine into production.

sendmail -- mail transport agent
This bad boy has been the demise of many a system. If you bought a machine years ago and haven't patched it, more than likely its running an ancient sendmail and has any number of doors to your machine for anyone to access. Due to the lag time between exploit knowledge and vendor patch, I suggest downloading and compiling sendmail on your own. Sendmail holes have gotten more scarce as the years have gone by, but the author(s) of sendmail are better at making source code patches available than the vendors are at making binary patches available. If you're not going to be receiving mail on the machine(that is if you're going to be getting your mail from a pop or imap server and are not going to be reading the mail from the local disk drive), I suggest turning sendmail off at boot time. You can run sendmail out of cron to send mail from the machine if necessary.

/etc/hosts.equiv, /etc/passwd, /.rhosts(tho like i said, don't use the r-suite)
Check these babies for lines such as:
            + +
    or
        +:+::::::

These typically mean let anyone in as they want. Really a bad bad thing, but you'll be surprised at what the vendors have left in those files when the machine comes out of the box. Oh, speaking of /etc/passwd, you'll want to remove users such as "Field Administrator" or "Engineer" or some such vendorized userid. These generally do not need access to your machines and their default passwords are typically well known to the hacker community. If there is an /etc/shadow file, you'll want to remove the users from there as well.

Okay, so now you've patched your machine and you've removed all of the bad permissions and turned everything off. Your machine is now secure. Not.

So what can you do now to be alerted when the hacker does break in? How will you know?

First thing, check the logs regularly for any abnormalities. And I mean all logs. Look at /etc/syslog.conf and see where you're dumping things if you haven't already. Most unices nowadays have a some file like /etc/syslog.conf which list where log files are being kept for different levels of syslog(man is your friend, man syslog and man syslog.conf).
More than likely you'll want to look at the "messages" and "syslog" files. If you're on a linux machine, you'll also want to look at the "maillog". The default behavior for tcpwrappers is to dump its information to the mail levels, on solaris that'd be to syslog and on linux that'd be to maillog. This behavior can be modified at compile time for tcpwrappers. You'll also want to note, not look at yet, where you're dumping your authentication logs, provided you're running your own login program.
Strange messages in these log files, core dumps, abnormally long lines, control characters, binary garbage, are clues that either the machine was attempted to be broken into, or it was broken into. Btw, you also want to note any successful su's, either to root or some other user, by unauthorized people(duh).
There is a utility called 'swatch' which can assist in going through log files. You can run this program on your secured syslog hosts which I'm sure you have, and it will mail you the abnormalities or do anything you want with them. You could also gen a simple perl script to do the same thing, but 'swatch' is tried and true.

Next, you'll want to check the filesystem for any abnormal changes. The easiest way to do this is by running a utility called "tripwire". There is the free version of tripwire, 1.3 I believe, from COAST. And then there is the commercial version for not only Unix but also Windows boxes. I'm going to discuss the free version. When tripwire is first run, hopefully on a clean machine, it will create a database from which it will perform future comparisons. This database, once written somewhere, should remain read-only -- either on a read-only disk drive or a read-only filesystem (and I don't mean on a read-only mounted NFS/unix filesystem, that can be changed). The location of this database is determined when tripwire is compiled. tripwire, in normal operation, will produce a report of what files have changed compared to the info stored in the database. If there is an authorized change to the filesystem, the database needs to be updated.
tripwire should be started from a tightly secured machine and pushed out to the clients, and the info redirected back to that tight box. This way the tripwire will run even if a hacker has compromised the client.

One thing you should definitely do, copy the following utilities to a removeable drive, either floppy or zip:

                    netstat
                    find
                    ps(both SysV and Berkeley versions if available)
                    sh
                    ls
                    strings (or whatever the program might be called on your OS)
                    sum
                    /usr/lib/libc(eh, the main C-library is what i'm striving for)
                    dd

If a machine is compromised, more than likely any or all of those utilities have been modified to the perp's advantage. If you store them on a removeable media and have the media away from the machine, it will help the investigation.

Okay, I've mentioned "highly secure" and "tight boxes" above. What are they? How are they different than my normal machines?
Basically, they have nothing on them but the services they definitely need in order to perform their function. They are not nfs clients or servers. They do not run window managers or X. They have nothing on in /etc/inetd.conf. They _might_ run ssh and have its config files allow connections only from a limited number of machines. If one can afford it, have a couple of syslog hosts, one which the user-client machines can see and one which only admin-servers can see. Have a couple of tripwire hosts, one for the user-clients and one for the admin-servers. user-clients -- machines which the normal population can log into and do their daily work. admin-servers, machines which only administrators have access to and which provide the services for the user-client machines.

                        -- herb 10 July 1999
                        this paper doesn't reflect the views nor ideas of my employer
                        last updated 14 July 1999