Make your own free website on

SunService Tip Sheet: Network Security



Product Support Document (PSD) for Network Security

Revision 1.1
Date: April 18, 1996

1.0: About Network Security
  1.1: Network Security Definitions
2.0: Network Security Debugging
3.0: Common How Tos
  3.1: How to Prevent Remote Root Logins Under SunOS
  3.2: How to Prevent Remote Root Logins Under Solaris
  3.3: How to Turn Off Specific Network Services
  3.4: How to Insure the Security of NFS Partitions
  3.5: How to Insure the Security of NIS Maps
  3.6: How to Insure the Security of NIS+ Maps
  3.7: How to Keep Up to Date with the Latest Security Problems
  3.8: How to Take Additional Steps to Secure Your Site
4.0: Frequently Asked Questions
5.0: Network Security Patches
  5.1: Miscellaneous Networking Patches
  5.2: DNS Patches
  5.3: FTP Patches
  5.4: Inetd Patches
  5.5: NFS Patches
  5.6: NIS Patches
  5.7: nscd Patches
  5.8: Sendmail Patches
6.0: Known Bugs & RFEs
7.0: References
8.0: Supportability
9.0: Additional Support

1.0 About Network Security

 1.0: About Network Security


As the internet gets continually bigger, the question of network
security becomes an ever larger one. What follows are some tips and
guidelines that you can use to get yourself started with network
security. If network security is an extremely critical issue at your
site, consider working with the Consulting services
described in Section 9.0, because this document can really only touch the
surface of a very important subject.

This PSD tries to impart the following information: first, what can be
done on a brand-new Sun to setup basic network security  second, what
public-domain or SunSoft programs can be used to improve security
even further. It does not discuss security issues unrelated to
the network (e.g. setuid programs, file permissions, restricted shells,
etc), but you should consider these matters when you are
working to secure your system.

 1.1: Network Security Definitions


A lot of varied ground is covered in this PSD.  The following terms are
important to some parts of it:

FIREWALL: A machine positioned in between your internal network and
external networks (usually the internet). The most strict firewalls
prevent any packets from being transmitted from the internal to
external networks, depending on PROXY SERVERS for needed
functionality. Less strict firewalls only prevent certain types of
insecure packets (i.e., X11 packets) from being passed.

PROXY SERVER: A daemon run on a firewall, which acts as a sort of
go-between, accepting packets from the internal network and
connecting them up to services on the external network, as appropriate
(or vice-versa). Proxy servers are useful because they allow
connections to go beyond a firewall, but still hide all information on
the internal network from external users.

FILTERING ROUTER: Really, a type of firewall. Filtering routers can be
programmed to block certain types of packets (X11, sendmail, telnet,

 2.0: Network Security Debugging


The best way to "debug" network security is to read this Tip Sheet
and take a look at the programs noted in section 3.8. In
particular: security scanners can point out security holes in your
current setup, while firewalls and TCP/IP wrappers can be set up to
provide a high level of logging, giving lots of information about
security-related network activity.

3.0 Common How Tos

 3.1: How to Prevent Remote Root Logins Under SunOS


Remote root login permissions are controlled by the /etc/ttytab file
under SunOS. To change remote root login permissions, you must modify
every single 'network' line in the /etc/ttytab files.

Root access over the network is denied if all of the network ttys are
labelled unsecure:

  ttyp0   none                            network         off unsecure

After making changes to the ttytab, you must HUP process 1:

  # kill -HUP 1

Alternatively, you can reboot the machine.

 3.2: How to Prevent Remote Root Logins Under Solaris


In the file /etc/default/login, there is a CONSOLE line.

If there is no comment in front of the CONSOLE line, root can only
login from the console:


Changes to this file will take effect at once.

 3.3: How to Turn Off Specific Network Services


Network programs can be started from a variety of places. You must
know how they are started in order to turn them off.

The majority of network services that you will wish to disable are
enabled in the /etc/inetd.conf file. To disable one of these services,
simply comment out the appropriate line. For example, to disallow
logins you would want to disable the following three services:

  #telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd    in.telnetd
  #shell   stream  tcp     nowait  root    /usr/sbin/in.rshd       in.rshd
  #login   stream  tcp     nowait  root    /usr/sbin/in.rlogind    in.rlogind

ftpd, tftpd, fingerd and many other internet services can all be
disabled in a similar manner. Afterwards, you must restart the inetd:

  # kill -HUP inetd-pid

Most other network services (sendmail, rpc.nisd, etc) are initiated
from the rc files. If a network service does not appear in the inetd,
you should search through your rc files, find where it is started, and
then comment out the daemon so that it does not start on bootup.
You'll of course have to kill the currently running daemon to disable
the service immediately.

 3.4: How to Insure the Security of NFS Partitions


When you are exporting NFS partitions, if you don't have a firewall or
filtering router that prevents NFS packets from leaving your domain,
you should make sure to restrict access rights to that partition. This
is done by restricting the rw or ro option to a specific machine, a
list of machines or a netgroup. Examples of using the rw and ro
options in this way follow:


These options should be incorporated into your export file in a way
appropriate to your network. For example, under, SunOS, you might use
the following:

  %% cat /etc/exportfs
  /export       -ro=machine1

Under Solaris, you might use the following:

  %% cat /etc/dfs/dfstab
  share -F nfs -o ro=netgroup /export

Note that it is most convenient to set up a netgroup that contains a
listing of all of your machines and then export all of your NFS
partitions to that netgroup. SunService has a NIS PSD that gives good
information on how to set up a netgroup.

 3.5: How to Insure the Security of NIS Maps


By default, NIS is not particularly secure. Anyone can grab a copy of
NIS maps by simply figuring out the name of your NIS domain. Thus, the
first step in securing NIS to use a nonintuitive name for your
defaultdomain. Something that is not a derivation of your domain name
or machine name is best.

Newer versions of NIS allow you to further secure things via the
securenets file. If you are using SunOS 4.1.3_U1 or lower or NSkit
1.0 or lower, you need to apply the appropriate patch before the
securenets file can be used. SunOS 4.1.4 and newer versions of NSkit
already have this available by default.

The contents of the /var/yp/securenets file should be a number of
lines that each read:

  netmask address

For example, if you only wanted the machines and to be able to retrieve your NIS maps, you could enter
the two lines:

If you wanted everyone on the network to be able to
retrieve your maps, you could enter the line:

 3.6: How to Insure the Security of NIS+ Maps


NIS+ provides much better security than NIS and is highly suggested
if you are worried about the security of your network. You can control
who can access your maps with the NIS+ access rights. Type nisdefaults
to examine the default values for your NIS+ domain:

  %% nisdefaults -r

Type niscat -o to determine the rights on an individual table:

  %% niscat -o passwd
  Access Rights : ----rmcdr---r---

Remember that these access rights are laid out in the format: nobody,
owner, group, world, and that each of these four user groups has four
access rights: read, modify, create, destroy. In the above examples,
owner has all rights, while group and world have only read rights.
Nobody has no rights.

The above setup is secure under NIS+, since only people who are
authenticated into your domain are able to look at your tables. You
should only worry if you have extended rights to the nobody group.
This might be required if you need to extend rights to NIS clients or
to unauthenticated clients, but you should be aware that it reduces
your security.

If you need to change your access rights, you should use the nischmod
command. NIS+ is very powerful and you can give rights to entire
objects or individual table entries. Consult the nischmod for
information on how to do this.

 3.7: How to Keep Up to Date with the Latest Security Problems


Though this document explains how to make your network services more
secure, there are constantly new issues cropping up. If you want to
make sure that your network remains secure in the future, you need to
keep up with these new problems. Fortunately, there is an excellent
third-party mailings list on the net that tells of network security
problems as they become known.

The CERT (Computer Emergency Response Team) Coordination Center
publishes CERT advisories that tell of the newest network security
problems for all OSes. You can subscribe to it by mailing:

 3.8: How to Take Additional Steps to Secure Your Site


Sections 3.1 through 3.6 of this document describe how to make your
system as secure as possible, using the tools that came with it.
Following those basic guidelines should provide more than enough
security for most sites.

However, there are some cases where you might want to implement
additional levels of security, even preventing certain services from
arriving at your site, in the name of making your network security
even more ironclad. Addressed here are certain public-domain or Sun
products that are especially helpful. There are also many third-party
security programs available from other vendors.


Firewalls are the ultimate in security, because they can totally
isolate you from most of the network. Sun sells a Firewall product
named Firewall-1. Consult with your local Sun Sales office for info on
how to purchase Firewall-1.

A separate PSD exists on the FW-1 Product.

Security Scanners

Certain Security Scanners have been written that check for a number
of common security problems. In general, if you've secured everything
as noted in 3.1-3.6 and applied the patches described in section 5.0,
you won't have any problems. However, you mightcan still wish to try these

Cops checks for all kinds of common problems (including many
non-network related ones) on a single machine:

ISS (the Internet Security Scanner) can probe for common security
problems on an entire network of machines:

TCP/IP Wrappers

These public domain wrappers can be used to log the use of certain
TCP/IP programs (i.e., telnetd) and also to prevent access from certain
sites or networks. They are available from:

Other Programs

A number of other public domain network security programs are
available from:

You can also be interested in joining the CERT Tools mailing list,
that announces the release of new security tools. You can request
membership on the CERT Tools mailing list by dropping a line to:

 4.0: Frequently Asked Questions


Q: Why should I worry about security?

A: There are crackers out on the net and in time just about every
single site gets hit by them. Fortunately, if your site has a minimum
level of security (i.e., no gaping security holes), the crackers will
move on. Although the advice in this document will not necessarily
make your site impregnable, it will provide sufficient security to
keep 99.9%% of potential attackers out.

Q1: What issues should I consider when setting up security at my site?
Q2: How for should I go with implementing security policies on my network?

A: When considering security at your site, you need to balance level
of security with ease of use. Although a lot of basic security can be
accomplished with no inconvenience to your users, when you start
working with firewalls, TCP wrappers and filtering routers, you will
be taking some functionality away from your users. Based on the
visibility of your site and the confidentiality of its data, you must
determine how much is enough and how much is too much. This varies
from site to site, but a Security Consultant might be able to give you
a little more direction in making this decision.

Q: What services might I want to disable?

TFTP should absolutely be disabled if you don't have diskless clients
taking advantage of it.

Many sites will also disable finger, so that external users can't
figure out the user names of your internal users.

Everything else pretty much depends on the needs of your site. Do
people need to login from outside your network? FTP? If services are
not being used, disabling them can prevent later unauthorized use.

5.0 Network Security Patches

 5.0: Network Security Patches


The followings patches specifically fix some manner of security
problem in the listed network program. In no way is this a complete
list of network patches, but simply a list of those that can have
impact upon site security.

 5.1: Miscellaneous Networking Patches


100567-04 SunOS 4.1,4.1.1, 4.1.2, 4.1.3: mfree and icmp redirect security
101587-01 SunOS 4.1.3_U1: security patch for mfree and icmp redirect

  Makes a machine resistant to ICMP spoofing.

 5.2: DNS Patches


102167-03 SunOS 5.3: dns fix
102165-03 SunOS 5.4: fixes

  Make DNS more resistant to spoofing. These do not upgrade in.named
  to Bind 4.9.3 and thus some security holes remain. These should be
  corrected in the near future.

 5.3: FTP Patches


101640-03 SunOS 4.1.3: in.ftpd logs password info when -d option is used.

  Fixes an error that caused in.ftpd to log passwords when run with
  the -d option.

 5.4: Inetd Patches


101786-02 SunOS 5.3: inetd fixes
102922-03 SunOS 5.4: inetd fixes
102923-03 SunOS 5.4_x86: inetd fixes

  Mostly related to performance problems, but also fixes a minor
  security hole.

 5.5: NFS Patches


102177-04 SunOS 4.1.3_U1: NFS Jumbo Patch
102394-02 SunOS 4.1.4: NFS Jumbo Patch

  Fix various NFS security holes.

 5.6: NIS Patches


100482-07 SunOS 4.1 4.1.1 4.1.2 4.1.3: ypserv and ypxfrd Jumbo Patch
101435-02 SunOS 4.1.3_U1: ypserv and ypxfrd fix
101363-09 NSkit 1.0: Jumbo Patch

  These patches are required to allow the usage of the securenets file
  in these older releases of NIS.

102034-01 SunOS 5.3: portmapper security hole

  Fixes for NIS-related portmapper security holes.

102707-02 SunOS 5.3: jumbo patch for NIS commands
102704-02 SunOS 5.4: jumbo patch for NIS commands
102705-02 SunOS 5.4_x86: jumbo patch for NIS commands

  These patches fix ypxfr related NIS problems that became apparent
  with NSKit 1.2.

103053-01 SunOS 5.4, 5.3: Jumbo patch for NSKIT v1.2

  A patch specifically for NSKit 1.2, fixing a few more security

 5.7: nscd Patches


103279-02 SunOS 5.5: nscd breaks password shadowing with NIS+

  Keeps nscd from violating NIS+ shadow passwd security.

 5.8: Sendmail Patches


100377-22 SunOS 4.1.3: sendmail jumbo patch
101665-07 SunOS 4.1.3_U1: sendmail jumbo patch
102423-04 Sunos 4.1.4: Sendmail jumbo patch

  Fix a variety of older sendmail problems. These patches do not bring
  the SunOS sendmail up to version 8.6.10+ and so certain new
  sendmail problems are not yet addressed. They will be in the near

101739-12 SunOS 5.3: sendmail jumbo patch - security
102066-11 SunOS 5.4: sendmail jumbo patch - security
102064-10 SunOS 5.4_x86: sendmail jumbo patch - security

  These patches bring Solaris sendmail up to version 8.6.10+, fixing
  all known sendmail security holes.

6.0 Known Bugs And  RFEs

 6.1: Bugs


1238679   DNS spoofing is possible per Cern ca-96.02

  This documents the existing DNS security hole noted above, which is
  present in releases of BIND prior to 4.9.3. An upgrade of the SunOS
  and Solaris BINDs to 4.9.3 is currently in process and should be
  accomplished within the next few months.

1237810   4.1.x Unix sendmail vulnerability according to CIAC Bulletin G-

  This documents the fact that 4.1.X sendmail has some security holes
  because it has not been upgraded to 8.6.10+. An upgrade of the SunOS
  sendmail to 8.6.10+ is currently in process and should be
  accomplished within the next few months.

7.0 References

 7.1: Important Man Pages


No specific man pages refer to internet security.

 7.2: Sunsolve Documents


The following sunsolve documents provide some information not included

7.2.1: Infodocs

2105      convert existing NIS(yp) network to secure C2 domain
12793     What are the security ramifications of running TFTP?

7.2.2: SRDBs

6010      C2 security and Solaris 2.x

 7.3: Sun Educational Services


There are no classes specifically on network security.

 7.4: Solaris Documentation


There is no Solaris documentation specifically on network security.

 7.5: Third Party Documentation


The following books are not necessarily restricted to the network
aspect of security, but do provide some information on it.

_Computer Security Basics_, published by O'Reilly & Associates

_Practical UNIX Security_, published by O'Reilly & Associates

 7.6: RFCs


1244    the Site Security Handbook
1281    Guidelines for the Secure Operation of the Internet

 8.0: Supportability


SunService is not responsible for helping design security policies at
your site. It is hoped that this document will help you to maintain
robust network security at your site on your.

We can help resolve problems where a Sun program has a security
problem with it, but in such cases the contact must be a system
administrator with a good understanding of the security issues.

 9.0: Additional Support


For additional help determining security policies at your site, please
contact your local SunService office for possible consulting
offerings. Sun's Customer Relations organization can put you in touch
with your local SunIntegration or Sales office. You can reach Customer
Relations at 800-821-4643.

PRODUCT AREA: Gen. Network
PRODUCT: Security