General Security

© December 1998 Tony Lawrence

Internet security is a worry for anyone connecting to the rest of the world, whether you are a large corporation or just a home user browsing the web. Certainly there are other aspects of security: it is fact that most security breaches are engineered by someone who already has an account and password, and plain old physical security (Hey! Where's my machine!) is an issue too. There are also viruses to be concerned about, as these do threaten the security of our systems also. But it is worry about hackers that gives us queasy stomachs, that makes the hair on our neck stand up. There is something much more sinister about the thought of someone out there working at breaking in, trying this lock, then that.. it is unsettling never knowing if "they" know something "we" don't, if the hackers have discovered a new attack that no one else yet knows about, that some unseen person could be pawing through our data without our knowledge.

So what do we do about it? Ask in the newsgroups, and you'll be advised to install tcp-wrappers. That's not bad advice at all, and doing that is part of what I'll cover here, but there is more that you can do. Much more.

This and other articles in this "Security" series are going to focus on protecting machines from network attacks. The unspoken assumption is that it is the Internet that is the source of attacks, and I'm not going to bother very much with local security, but do keep in mind that local users are also potential threats. Fortunately, many of the actions you'll take to protect yourself from external hackers will also plug internal problems, but never lose sight of the fact that not every danger comes through your outside links.

These articles are not just for SCO, though some of the links contained within are SCO specific.

What do you really need?

Do you need to be connected to the Internet 100% of the time? For larger companies, that's probably a silly question, but for the rest of us, maybe not. Many of us can get by with "on-demand" connections. Consider the obvious: any time that you are not connected, your machines are (at least for that moment) safe from external intrusion. Consider also that if you are configured (as many PPP connections are) so that you get a new host name and new IP address everytime you connect, that in itself is more secure than having a dedicated IP address and host name.

If the connection is constant (as it would be for frame or T1 connections, etc.), do you need TCP/IP running all the time? Maybe you don't, or maybe you don't need it on the Internet Gateway machine after hours or on weekends. If not, consider a cron job that shuts off tcp/ip services entirely when they are not needed. If you are concerned about mail bouncing (or just causing "undeliverable- will retry" messages), have it come up often enough (every hour or so is plenty) to handle mail, and then bring it back down. A machine running no services is invulnerable- at least while it isn't "up".

Your head comes out of the water sometime

As useful as those ideas might be, the fact is that you do need to be connected sometime, and some of you need to be connected always. So we've got to do more to protect ourselves.

Spread it out

If it is at all possible, arrange your network so that one machine and only one machine is the gateway to the outside world. That's simple with PPP, and only requires another network card for a router configuration. That machine, the machine that connects to the outside world, should be doing as little else as possible. By that I mean that it should not be your print server, your file server, etc. The more services you can disable on a machine, the less potential for a breach. The less services present, the less information is available to hackers. The less information, the tougher their task becomes, and that is your goal: make it hard for them to get in.

For services that you do need to provide, their are several possibilities:

• Put them on the firewall machine
• Put them outside of the firewall entirely- directly exposed
• Put them inside the firewall on the local lan
• Put them parallel on another inside lan; this requires 3 or more network interfaces in the firewall. This is often referred to as a DMZ or DeMilitarized Zone configuration.

Obviously the first is the simplest and least expensive to implement- no extra machines, no complicated firewall rules. Of course it's also the least secure. The second takes the "sacrificial lamb" approach- the machines are considered expendable; if they get compromised, that's life. There might be some conditions where this makes sense, but usually it doesn't. Of course the machines wouldn't be just thrown out there without all the hardening possible- security patches, their own packet inspection, etc. Machines that aren't firewalls but do provide services to the outside world are sometimes called Bastion Hosts.

Putting the services inside the lan protects them with the firewall, but if access is gained, the attacker immediately has access to the rest of the lan. That's the advantage of the DMZ- breaking into the services machines still hasn't exposed the internal network.

Often, when security needs to be at its highest, multiple filtering firewalls may separate machines. For example, we might have a packet filtering router that is the first connection to the outside world. Our 3 headed (three NIC's) firewall connects to that. One of its interfaces flows to services machines (the Bastion Hosts), but goes through another packet filtering router or machine to get there, and the same thing happens on the inside lan interface.

Obviously you can get very complex, and very expensive. For a home user or a small office with neither the security concerns nor the budget to go to such lengths, the simpler configurations are more attractive. That's what we'll be looking at here.

An extreme case

At the moment, I'm typing this on a Unix box that has an on-demand PPP connection to an ISP. There are other machines networked (using "private" 10.x.x.x addresses) to this box, but they have no ability to get to the outside world: no proxy services are running.

• There are no entries in /etc/inetd.conf. Everything (yes, everything) is commented out.
• The portmapper service has been disabled by adding an "exit 0" to the beginning of its startup script.
• Certain other network programs such as "routed" have been commented out of the tcp/ip startup.
• The "rpc" programs have been disabled by adding "exit 0" at the beginning of /etc/rc2.d/S84rpcinit and so on.

What can this machine be used for? Quite a bit, actually. It doesn't accept telnet connections because the telnetd daemon has been commented out of /etc/inetd.conf, but I can telnet out to any other machine. The same is true for ftp: it will not answer an ftp request, but there is nothing to prevent me from going out with ftp. I can browse the web, download files, and even though smtpd is also commented out, I can use Netscape to pop and send email and to read News. It can't be a print server, and it can't be a file server, but it lets me access the net, and that's exactly what I need it to do.

So it actually isn't such a useless machine. It is, however, a very invisible machine. Not completely invisible, of course. It still answers pings, and there are still network programs running, but the vast majority have been completely shut off. Is it "safe"? No. It is safer. It gives out very little information about itself, and presents very few cracks for someone to squeeze through, but you are never "safe". All you are trying to do is make their job hard enough that maybe they'll give up.

Crippling a machine this extensively probably isn't an option for a lot of us. Still, it is very worth while to think about what services you can do without. Some services in particular are both dangerous and generally unnecessary: all of the "r" services (rlogin, rsh, rexec) certainly fall into that category. Yet for some situations, they may be necessary.

Do remember that any service detracts from your security, even if the service itself is 100% secure. The reason is that any service provides information to a would- be intruder. The more information they have about your machine, the more chance of exploiting a hole. If you don't need it, don't run it. If you aren't sure you need it, shut it off and see what breaks. If nothing breaks, leave it off.

Just don't forget you shut it off. I remind myself by echoing out a list of everything I'm NOT running everytime tcp/ip starts, so that if I ever do need one of them, I'll have at least a chance of knowing why things aren't working.

Example (from /etc/tcp):

                if [ -x /etc/routed -a ! -f /etc/gated.conf ]; then
                        # routed &
                        echo "no routed \c"
                fi
 

As bulletproof as possible

If we accept that some network services are either necessary or desirable, the next step is to make sure you have the most secure versions possible, and that your machine's permissions aren't going to let an otherwise "safe" (a relative term, of course) program turn into a hacker's gateway.

SCO publishes security bulletins which provide information about security issues and links to patches and supplements that will help close the doors. Get the patches and updates appropriate for your system, but keep in mind that security is constantly changing: remember to check back frequently for new information.

There is a SSE directory on SCO's FTP site for security enhancements.

If you can't kill it, wrap it

I'm going to digress for a moment and explain inetd. If you already understand inetd, skip ahead (nowadays many Unix/Linux OSes use Xinetd).

You probably understand that programs like ftp servers, telnet, etc, don't need to be waiting around in memory waiting for some other program that wants them. But why not? How do they get started on demand if they aren't listening for activity?

The answer is that each service is assigned a specific number. You can get a list of the services and numbers from /etc/services. Notice that both tcp and udp can use the same number; they are different protocols, so that's no problem.

The inetd daemon runs in background, listening for anything requesting service. When it "hears" something, it checks /etc/services to see what service belongs to that number, and then it looks in /etc/inetd.conf (actually, it has already read these files into memory, and will only re-read if it gets a HUP signal) to see how to run that program, or if it is supposed to run it at all (there are a few simple services that inetd handles itself; these are marked "internal" in inetd.conf).

If there is no uncommented entry for the service being requested, inetd does nothing. Otherwise, it spawns off the indicated daemon (or provides the function, for internal services). If the line is marked "wait", then the daemon can handle multiple connections; otherwise a new instance must be started for each new request.

TCP Wrappers

The tcp-wrappers program (/etc/tcpd) is a "wrapper" that gets installed in inetd.conf. An example is better than an explanation: Here's the telnet line from /etc/inetd.conf without tcp-wrappers:

telnet  stream  tcp     nowait  NOLUID  /etc/telnetd    telnetd
 

and here it is after:

telnet  stream  tcp     nowait  NOLUID  /etc/tcpd       telnetd
 

We know that when inetd receives a request on port 23 (tcp), it knows that this is "telnet" because of the entry in /etc/services. Before tcp-wrappers, inetd would start up a telnetd to handle the request. But with the modified inetd.conf, it is /etc/tcpd that gets started (with the argument "telnetd" so it knows what service is being requested). All /etc/tcpd does is decide whether or not to start the telnetd. If the request passes its rules, then tcpd will replace itself with telnetd and that is the end of its function.

Note that tcpd does not remain part of the connection. Once it has decided that the telnetd is allowed, tcpd is gone. That's important: tcpd is not monitoring anything after the telnet starts. Its work is entirely before that.

Rules

So what rules does it use? Well, if compiled as it should be (we'll get to that in a moment), it will automatically check that it can do a a DNS address to host name lookup, and then will take that host name, do a name to address lookup, and make sure they match. But it also will check two files (files that you create): /etc/hosts.deny, and /etc/hosts.allow. In these files, service by service, host by host, you can specify who gets access to what. So if you need inbound telnet, but only for a few machines, you can allow those machines and deny everything else.

Here's a sample hosts.allow:

# This allows talkd from any host in foo.com
talkd:  .foo.COM:       allow

# This allows telnet sessions into this machine from only bighost.foo.com
telnetd: bighost.foo.COM: allow
 

And this is a sample hosts.deny:

# This file will deny access to any service protected by tcpd in 
# /etc/inetd.conf if not already matched in /etc/hosts.allow
ALL: ALL: deny
 

So how do you get this? You can start by downloading TLS076A from ftp://stage.sco.com/TLS As of this writing, this is NOT the most current version, and it is designed and compiled for 3.2v4.2, but it does include some sample files and documentation that doesn't come with the raw source.

Don't be confused by the included source code- the tcpd binary is there and it will work. Of course if you want to recompile, go ahead.

What you really want (this was written in December of 1998- I do update these articles, but not always instantly, so the information that follows could be out of date) is version 7.6. You can get that from ftp://ftp.celestial.com/pub/sco-ports/ as source or in binary form. You can get the most current source from ftp.porcupine.org.

If you get the source, you'll need to edit the Makefile and uncomment the line that says:

REAL_DAEMON_DIR=/etc
 

Then you'll 'make sco-os5' (or whatever your platform is). Later on, you might want to come back, read the documentation completely, and possibly make more changes to the Makefile, but this is a beginning for the impatient.

You now have tcpd. Move it to /etc, and start by editing ONE service in /etc/ined.conf. Let's try telnet, for example, because it's easy. Make the telnet line look like:

telnet  stream  tcp     nowait  NOLUID  /etc/tcpd       telnetd
 

and then signal inetd (SCO: kill -1 `cat /etc/inetd.pid`)

Create /etc/hosts.deny to contain:

ALL: ALL: deny
 

Don't create /etc/hosts.allow yet.

Now telnet out to some other machine, and then try to telnet back. If you've done everything correctly, you will not be able to.

Neat? Do you feel safer now? OK, let's finish the job. You can't use tcpd on the "internal" services. Also, the services marked "wait" aren't well protected by tcpd, because only the first instance of them will be checked. I suppose it's still better to check the first than none at all, but it should be plain that tcpd is not a total solution to the general security problem. Other articles in this series will cover other tools and methods. For now, edit inetd.conf, installing /etc/tcpd where appropriate, which certainly includes ftp and telnet plus rlogin,rsh,rexec,finger,tftp,comsat,talk, and uucp if you don't have them commented out. Edit your hosts.allow and hosts.deny file to meet your needs, and don't forget to signal inetd to re-read its configuration.

IPFILTER

Ipfilter is available as TLS709, ftp://stage.sco.com/TLS. It's both a packet filter and a NAT translator (see IPFILTER Firewalls for OSR5).

Modem Security

Of course, the internet isn't always the only path that leads to your system. Dial-in modems can also give access. There are a couple of things you can do about that. One is to use "dial-back" modems- these are modems that can be set so that they don't actually accept calls, but instead dial back a pre-set number. Most can be configured with several numbers, each controlled by a login password that causes a particular number to be called back. This is entirely transparent to the OS: your getty never knows that anything unusual happened.

Another choice is to use dial up passwords. These are special passwords that will be requested whenever an attempt is made to login on any line listed in /etc/dialups. You create these passwords for each login shell in use using "passwd -m"- see "man passwd for complete details. You can, of course, combine this with the dialback modems mentioned above.

General Login Policy

It is not at all a bad idea to restrict root login to the console. If you need to be root on some other login, use "su". You do this by adding a "CONSOLE=" line to /etc/default/login. See "man login".

A mail server that is used to get mail by pop or imap doesn't need (and shouldn't) allow logins by users at all. Set their shells to /bin/true in /etc/passwd to completely prevent logins (obviously do not do this to root!).

Got something to add? Send me email.

---

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us