Securing your System (EdLUG Workshop)

George Ross March 14, 2000 1. Know your users

2. Formulate a clear security policy

3. Get it agreed in writing (if you can!)

4. Then it’s just the usual trade-off: security against convenience against cost.

5. Keep up with the patches and updates.

6. Don’t assume you’re too small to be noticed. Baby Bear has a machine-gun.

\overline{Books 2}

There are quite a few good books available:

Practical UNIX and Internet Security by Simson Garfinkel and Gene Spafford (O’Reilly).

Building Internet Firewalls by D. Brent Chapman and Elizabeth D. Zwicky (O’Reilly).

Firewalls and Internet Security — Repelling the Wily Hacker by William R. Cheswick and Steven M. Bellovin (Addison-Wesley).

Linux System Security by Mann and Mitchell (Prentice Hall).

Topic-specific books: DNS and bind, sendmail, web, … EVERYONE should read bugtraq. There’s an

archive at http://www.securityfocus.com/

(follow the “forums” link). To subscribe, send an e-mail message to

LISTSERV@SECURITYFOCUS.COM

with a message body of:

SUBSCRIBE BUGTRAQ Lastname, Firstname

There are also distribution-specific lists, such as

linux-security@redhat.com. And don’t forget

about the newsgroups.

Some useful web sites:

http://www.ja.net/CERT/cert.html http://www.cert.org/ http://www.securityfocus.com/ (the BUGTRAQ archive) http://www.opensec.net/ (a pretty good collection of security tools) http://www.linuxdoc.org/ (the starting place for all kinds of Linux documentation)

And don’t forget the distribution web sites.

(Scope: we don’t have time to cover everything in any kind of depth. Some things, such as the web, are just so big that it’s not even worth starting on them here.)

Step 1: Make sure your installation is up-to-date. Apply the latest (stable) patches. Get hold of the current versions of applications. And track the mailing lists and keep up-to-date.

Step 2: Lock down your bios and lilo.

Step 3: Find out what you are running, and turn off everything you don’t actually need. If it’s not there it can’t be broken into.

Step 4: Control what you have decided needs to run. Restrict access as tightly as you can.

Step 5: Read your log files!

\overline{lsof 6}

How do you find out what’s running on your machine? Use ps. Trawl your boot files (probably

in /etc/rc.d/). And use lsof.

lsof: list open files. But it can also show open sockets. Use lsof -iTCP -iUDP to display network connections:

[may]root: lsof -iTCP -iUDP
COMMAND    PID USER   FD   TYPE     DEVICE   SIZE/OFF NODE NAME
portmap    238  bin    3u  inet 0x03ada018        0t0  UDP *:sunrpc
portmap    238  bin    4u  inet 0x03adac0c        0t0  TCP *:sunrpc (LISTEN)
ypserv     256 root    1u  inet 0x03931018        0t0  UDP *:1021
ypserv     256 root    2u  inet 0x03931414        0t0  TCP *:1018 (LISTEN)
...
sshd      2541 root    3u  inet 0x01bbc810        0t0  TCP *:22 (LISTEN)
xfs       2581 root    3u  inet 0x0192c018        0t0  TCP *:xfs (LISTEN)
xfs       2581 root    5u  inet 0x0141b414 0x624622dc  TCP
                       localhost:xfs->localhost:nterm (ESTABLISHED)
X         2808 gdmr    0u  inet 0x03769810        0t0  TCP *:X0 (LISTEN)
X         2808 gdmr    5u  inet 0x0141b018 0xef2bde4e  TCP
                       localhost:nterm->localhost:xfs (ESTABLISHED)

Scanners 7

Another good way is to scan your machine to see how it responds (if you don’t, you can be sure that as soon as it’s on a network anywhere then someone else will!).

[may]root: nmap -O 127.0.0.1
Starting nmap V. 2.3BETA4 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on localhost (127.0.0.1):
Port    State       Protocol  Service
7       open        tcp       echo
21      open        tcp       ftp
22      open        tcp       ssh
23      open        tcp       telnet
25      open        tcp       smtp
53      open        tcp       domain
111     open        tcp       sunrpc
113     open        tcp       auth
515     open        tcp       printer
635     open        tcp       unknown
1017    open        tcp       unknown
1018    open        tcp       unknown
1019    open        tcp       unknown
2049    open        tcp       nfs
6000    open        tcp       X11
7100    open        tcp       font-service
TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
Remote operating system guess: Linux 2.0.35-37

Have scanning parties with your friends? Or with other system administrators of your acquaintance. Make very sure it’s agreed clearly in advance.

nmap followup 8

Once you’ve got your nmap output, use lsof to confirm what’s on the end of those mysterious ports:

[may]root: lsof -i TCP:635
COMMAND    PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
rpc.mount 1723 root    5u  inet 0x020cd810      0t0  TCP *:635 (LISTEN)
[may]root: lsof -i TCP:1017
COMMAND  PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
amd     1303 root    5u  inet 0x02238810      0t0  TCP *:1017 (LISTEN)
[may]root: lsof -i TCP:1018
COMMAND PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
ypserv  256 root    2u  inet 0x0392e414      0t0  TCP *:1018 (LISTEN)
[may]root: lsof -i TCP:1019
COMMAND PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
ypbind  264 root    5u  inet 0x0392ec0c      0t0  TCP *:1019 (LISTEN)
ypbind  266 root    5u  inet 0x0392ec0c      0t0  TCP *:1019 (LISTEN)

Many, but by no means all, network services are started by inetd, controlled by /etc/inetd.conf:

name    dgram   udp     wait    root    /usr/sbin/in.tnamed   in.tnamed
time    stream  tcp     nowait  root    internal
time    dgram   udp     wait    root    internal
daytime stream  tcp     nowait  root    internal
daytime dgram   udp     wait    root    internal
identw  stream  tcp     wait    sys     \
        /usr/local/etc/in.identd in.identd -w -t60
smtp    stream  tcp     nowait  root    \
        /usr/local/etc/tcpd /usr/lib/sendmail -bs -C/var/obj/conf/sendmail.cf
amanda  dgram   udp     wait    root    \
        /usr/local/etc/tcpd /usr/local/lib/amanda/amandad

Check what’s in yours. Anything that’s listed could be started up by packets from the network. Make sure that you only include what you actually need. Remember: anything that you run that you don’t have to could be a toehold for a cracker.

Be particularly wary of services, such as pop or imap, which sound as though they might be useful. Think about how you really access those facilities. If in doubt, turn them off and see what happens.

But… do remember that not all network daemons are started in this way, so if lsof shows something that you can’t find here you’ll have to trawl through your other startup files to find it.

TCP wrappers are so-called because they “wrap” around inetd-started services. They check the daemon name and the connection source against two configuration files, /etc/hosts.allow and /etc/hosts.deny, and only start the daemon up if the connection is permitted. For example:

    in.ftpd : localhost .dcs.ed.ac.uk
    in.telnetd : localhost .ed.ac.uk
    sshd : localhost .ed.ac.uk
    sshdfwd-X11 : localhost .dcs.ed.ac.uk
    sendmail : localhost
    rpc.mountd : 129.215.0.0/255.255.0.0
    portmap : 129.215.0.0/255.255.0.0

and

    ALL : ALL : banners /etc/tcpd.banners/deny

Alternatively, the wrapper library can be explicitly linked into daemon code (for example, sshd,

ypserv, mountd). In this case the hosts.allow

and hosts.deny files are consulted in the usual way.

There are, however, some things that the TCP wrappers can’t do:

• They can’t control things that aren’t started by inetd unless they’ve been explicitly linked in.

• They can’t control “internal” inetd services.

• They’re only invoked when inetd first starts a service, so if the daemon waits around for further connections there won’t be any more checks done.

The only real answer in this case is IP-level filtering. That’s the subject of the third part of this workshop.

Book: Applied Cryptography (second edition) by Bruce Schneier.

Two basic encryption styles: symmetric (3DES, IDEA, BLOWFISH, …) which use a shared secret key to control a reversible transformation of the data; and public key, based on a mathematical procedure which is easy to run in one direction based on the “public” part of the key but hard to reverse without information contained in the “private” part.

(“Security through obscurity” uses a vague weak secret. Cryptography uses well-defined secrets, and should be secure even if everything else is known.)

The only way to crack good well-known algorithms is (should be!) to find the key. If the keyspace is large enough then this can be expected to take longer than the lifetime of the Universe.

Encryption: anyone can encrypt using the public key, but only the private key owner can decrypt.

Signing: dual problem, only the private key owner can encrypt something so that the public key can decrypt it.

Often a random ephemeral symmetric “session key” protects bulk data, and is itself protected using public key methods. This gives better time and space efficiency. Examples: PGP, ssh.

A “message digest” is a one-way function of some data that essentially provides a compact hard-to-forge fingerprint. Examples: MD5, SHA1.

Network traffic must be assumed to be snoopable. If someone controls an intermediate router then active session-hijacks are also possible. Even one-time passwords are vulnerable. Only real answer: end to end encryption.

ssh is a cryptographically strong drop-in replacement for rsh and rlogin. Each host has its own public/private key-pair. Only “known” hosts can communicate without the user being informed and agreeing. Hijacks won’t work because the session state is opaque. Optionally the user can install a personal key-pair to replace remote password authentication (be aware of revokation issues). There are several versions around: read the licences carefully.

To protect your email consider PGP. “Web of trust” assures ownership of keys. Provides for encryption, signatures, or both. Individual messages are encrypted with a session key, which is itself encrypted with all the recipients’ public keys. Signatures are done by encrypting a message digest with the sender’s private key.

Some installations fire up a web server by default. You really don’t want to have one of these running unless you’re prepared to put in the work to configure it. And beware of buggy cgi scripts. This is much too big a topic to cover here.

You may find sendmail running. If you’re sure you need it, and you may well not, make sure you configure it properly. See the “bat” book (Costales with Allman, O’Reilly).

You may even find the Simple Network Management Protocol (snmp) daemon started up by default. You almost certainly want to turn it off. Read access can give away a lot of information about your systems. Allowing write access practically hands over control.

SNMPv1 security was basic: it used cleartext “community” strings.

Almost no-one understood SNMPv2 security!

SNMPv3 will probably be better, but it’ll be a while before it’s widely implemented.

X has an all-or-nothing approach to security. If you can connect to someone’s X server at all then you have full unrestricted access to all its functionality.

Access control is usually based on one of two methods:

• host-based, where anyone on a list of “trusted” hosts can connect

• cookie-based, where anyone who can quote the right magic token can connect

ssh connections provide some protection through the use of ephemeral cookies. However, the X server is still wide open while the main connection is up. Be wary of allowing X forwarding to machines that you don’t trust, as you may have opened an encrypted tunnel ready for the cracker to exploit.

The truely paranoid may want to run part of their X sessions through the Xnest server. This can put a fence around its clients, so that they can interfere with each other but not with anything connecting to the main X server or to another Xnest server.