| Infodoc ID |
|
Synopsis |
|
Date |
| 13335 |
|
NETWORK SECURITY PSD/FAQ |
|
20 Sep 1996 |
Product Support Document (PSD) for Network Security
Revision 1.1
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,
etc).
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:
CONSOLE=/dev/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:
rw=machine1
rw=machine1,machine2,machine3
rw=netgroup
ro=machine1
ro=machine1,machine2,machine3
ro=netgroup
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 150.101.16.28 and
150.101.16.29 to be able to retrieve your NIS maps, you could enter
the two lines:
255.255.255.255 150.101.16.28
255.255.255.255 150.101.16.29
If you wanted everyone on the network 150.101.16.0 to be able to
retrieve your maps, you could enter the line:
255.255.255.0 150.101.16.0
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
----rmcdr---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:
cert-advisory-request@cert.org
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
---------
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
out.
Cops checks for all kinds of common problems (including many
non-network related ones) on a single machine:
ftp://ftp.cert.org/pub/tools/cops
ISS (the Internet Security Scanner) can probe for common security
problems on an entire network of machines:
ftp://ftp.cert.org/pub/tools/iss
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:
ftp://ftp.cert.org/pub/tools/tcp_wrappers
Other Programs
--------------
A number of other public domain network security programs are
available from:
ftp://ftp.cert.org/pub/tools
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:
cert-tools-request@cert.org
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: nss_dns.so.1 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
problems.
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
future.
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
here.
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.
Top
Sun Proprietary/Confidential: Internal Use Only
Feedback to SunSolve Team
