This is about general security in the late 1990's and is only left here for historical purposes.
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
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
- Put them on the firewall machine
- Put them outside of the firewall entirely- directly
- 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
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
Years ago, routers were how you did packet filtering, because
computers weren't fast enough. That's obviously changed, but it
doesn't necessarily mean packet filtering routers aren't useful- in
fact, you can use both and gain security.
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
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
- 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"
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
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
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.
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
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
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
as source or in binary form. You can get the most current source
If you get the source, you'll need to edit the Makefile and
uncomment the line that says:
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
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
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
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).
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
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!).
If this page was useful to you, please help others find it:
More Articles by Tony Lawrence
- Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-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. We appreciate comments and article submissions.
Publishing your articles here
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.