SunService Tip Sheet: Network Security
INFODOC ID: 13335 SYNOPSIS: NETWORK SECURITY PSD/FAQ DETAIL DESCRIPTION: 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, 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. PRODUCT AREA: Gen. Network PRODUCT: Security SUNOS RELEASE: any HARDWARE: n/a
No comments:
Post a Comment