This is Info file Security-HOWTO.info, produced by Makeinfo version 1.68 from the input file /tmp/sgmltmp.Security-HOWTO26383.info.2. \input texinfo  File: Security-HOWTO.info, Node: NIS (Network Information Service) (formerly YP)-, Next: Firewalls, Prev: NFS (Network File System) Security-, Up: Network Security NIS (Network Information Service) (formerly YP)- ================================================ Network Information service (formerly YP) is a means of distributing information to a group of machines. The NIS master holds the information tables and converts them into NIS map files. These maps are then served over the network, allowing NIS client machines to get login, password, home directory and shell information (all the information in a standard `/etc/passwd' file). This allows users to change their password once and have it take effect on all the machines in the NIS domain. NIS is not at all secure. It was never meant to be. It was meant to be handy and useful. Anyone that can guess the name of your NIS domain (anywhere on the net) can get a copy of your passwd file, and use "crack" and "John the Ripper" against your users' passwords. Also, it is possible to spoof NIS and do all sorts of nasty tricks. If you must use NIS, make sure you are aware of the dangers. There is a much more secure replacement for NIS, called NIS+. Check out the NIS HOWTO for more information: http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html  File: Security-HOWTO.info, Node: Firewalls, Next: VPN's - Virtual Private Networks, Prev: NIS (Network Information Service) (formerly YP)-, Up: Network Security Firewalls ========= Firewalls are a means of controlling what information is allowed into and out of your local network. Typically the firewall host is connected to the Internet and your local LAN, and the only access from your LAN to the Internet is through the firewall. This way the firewall can control what passes back and forth from the Internet and your lan. There are a number of types of firewalls and methods of setting them up. Linux machines make pretty good firewalls. Firewall code can be built right into 2.0 and higher kernels. The `ipfwadm' or `ipchains' (in 2.2) user-space tools allows you to change, on the fly, the types of network traffic you allow. You can also log particular types of network traffic. Firewalls are a very useful and important technique in securing your network. But never think that because you have a firewall, you don't need to secure the machines behind it. This is a fatal mistake. Check out the very good `Firewall-HOWTO' at your latest metalab archive for more information on firewalls and Linux. http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html More information can also be found in the IP-Masquerade mini-howto: http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html More information on `ipfwadm' (The tool that lets you change settings on your firewall, can be found at it's home page: http://www.xos.nl/linux/ipfwadm/  File: Security-HOWTO.info, Node: VPN's - Virtual Private Networks, Prev: Firewalls, Up: Network Security VPN's - Virtual Private Networks ================================ VPN's are a way to establish a "virtual" network on top of some already existing network. This virtual network often is encrypted and passes traffic only to and from some known entities that have joined the network. VPN's are often used to connect someone working at home over the public internet to a internal company network by using a encrypted virtual network. If you are running a linux masquerading firewall and need to pass MS PPTP (Microsoft's VPN point to point product) packets, there is a linux kernel patch out to do just that. See: ip-masq-vpn. There are several linux VPN solutions available: * vpnd. See the vpnd home page. * Free S/Wan. at Free S/Wan. * ssh can be used to construct a VPN. * vps (virtual private server) at www.strongcrypto.com.  File: Security-HOWTO.info, Node: Security Preparation (before you go on-line), Next: What To Do During and After a Breakin, Prev: Network Security, Up: Top Security Preparation (before you go on-line) ******************************************** Ok, so you have checked over your system, and determined it's as secure as feasible, and you're ready to put it online. There are a few things you should now do in order to prepare for an intrusion, so you can quickly disable the intruder, and get back up and running. * Menu: * Make a Full Backup of Your Machine:: * Choosing a Good Backup Schedule:: * Backup Your RPM or Debian File Database:: * Keep Track of Your System Accounting Data:: * Apply All New System Updates-::  File: Security-HOWTO.info, Node: Make a Full Backup of Your Machine, Next: Choosing a Good Backup Schedule, Up: Security Preparation (before you go on-line) Make a Full Backup of Your Machine ================================== Discussion of backup methods and storage is beyond the scope of this document, but here are a few words relating to backups and security: If you have less than 650mb of data to store on a partition, a CD-R copy of your data is a good way to go (as it's hard to tamper with later, and if stored properly can last a long time). Tapes and other re-writable media should be write-protected as soon as your backup is complete, and then verified to prevent tampering. Make sure you store your backups in a secure off-line area. A good backup will ensure that you have a known good point to restore your system from.  File: Security-HOWTO.info, Node: Choosing a Good Backup Schedule, Next: Backup Your RPM or Debian File Database, Prev: Make a Full Backup of Your Machine, Up: Security Preparation (before you go on-line) Choosing a Good Backup Schedule =============================== A six-tape cycle is easy to maintain. This includes four tapes for during the week, one tape for even Fridays, and one tape for odd Fridays. Perform an incremental backup every day, and a full backup on the appropriate Friday tape. If you make some particularly important changes or add some important data to your system, a backup might well be in order.  File: Security-HOWTO.info, Node: Backup Your RPM or Debian File Database, Next: Keep Track of Your System Accounting Data, Prev: Choosing a Good Backup Schedule, Up: Security Preparation (before you go on-line) Backup Your RPM or Debian File Database ======================================= In the event of an intrusion, you can use your RPM database like you would use `tripwire', but only if you can be sure it too hasn't been modified. You should copy the RPM database to a floppy, and keep this copy off-line at all times. The Debian distribution likely has something similar. The files `/var/lib/rpm/fileindex.rpm' and `/var/lib/rpm/packages.rpm' most likely won't fit on a single floppy. But if Compressed, each should fit on a seperate floppy. Now, when your system is compromised, you can use the command: root# rpm -Va to verify each file on the system. See the `rpm' man page, as there are a few other options that can be included to make it less verbose. Keep in mind you must also be sure your RPM binary has not been compromised. This means that every time a new RPM is added to the system, the RPM database will need to be rearchived. You will have to decide the advantages versus drawbacks.  File: Security-HOWTO.info, Node: Keep Track of Your System Accounting Data, Next: Apply All New System Updates-, Prev: Backup Your RPM or Debian File Database, Up: Security Preparation (before you go on-line) Keep Track of Your System Accounting Data ========================================= It is very important that the information that comes from `syslog' has not been compromised. Making the files in `/var/log' readable and writable by only a limited number of users is a good start. Be sure to keep an eye on what gets written there, especially under the `auth' facility. Multiple login failures, for example, can indicate an attempted break-in. Where to look for your log file will depend on your distribution. In a Linux system that conforms to the "Linux Filesystem Standard", such as Red Hat, you will want to look in `/var/log' and check `messages', `mail.log', and others. You can find out where your distribution is logging to by looking at your `/etc/syslog.conf' file. This is the file that tells `syslogd' (the system logging daemon) where to log various messages. You might also want to configure your log-rotating script or daemon to keep logs around longer so you have time to examine them. Take a look at the `logrotate' package on recent Red Hat distributions. Other distributions likely have a similar process. If your log files have been tampered with, see if you can determine when the tampering started, and what sort of things appeared to be tampered with. Are there large periods of time that cannot be accounted for? Checking backup tapes (if you have any) for untampered log files is a good idea. Log files are typically modified by the intruder in order to cover his tracks, but they should still be checked for strange happenings. You may notice the intruder attempting to gain entrance, or exploit a program in order to obtain the root account. You might see log entries before the intruder has time to modify them. You should also be sure to seperate the `auth' facility from other log data, including attempts to switch users using `su', login attempts, and other user accounting information. If possible, configure `syslog' to send a copy of the most important data to a secure system. This will prevent an intruder from covering his tracks by deleting his login/su/ftp/etc attempts. See the `syslog.conf' man page, and refer to the `@' option. There are several more advanced `syslogd' programs out there. Take a look at http://www.core-sdi.com/ssyslog/ for Secure Syslog. Secure Syslog allows you to encrypt your syslog entries and make sure no one has tampered with them. Another `syslogd' with more features is syslog-ng. It allows you a lot more flexability in your logging and also can has your remote syslog streams to prevent tampering. Finally, log files are much less useful when no one is reading them. Take some time out every once in a while to look over your log files, and get a feeling for what they look like on a normal day. Knowing this can help make unusual things stand out.  File: Security-HOWTO.info, Node: Apply All New System Updates-, Prev: Keep Track of Your System Accounting Data, Up: Security Preparation (before you go on-line) Apply All New System Updates- ============================= Most Linux users install from a CD-ROM. Due to the fast-paced nature of security fixes, new (fixed) programs are always being released. Before you connect your machine to the network, it's a good idea to check with your distribution's ftp site (urlnam (ftp://ftp.redhat.com) for example) and get all the updated packages since you received your distribution CD-ROM. Many times these packages contain important security fixes, so it's a good idea to get them installed.  File: Security-HOWTO.info, Node: What To Do During and After a Breakin, Next: Security Sources, Prev: Security Preparation (before you go on-line), Up: Top What To Do During and After a Breakin ************************************* So you have followed some of the advice here (or elsewhere) and have detected a break-in? The first thing to do is to remain calm. Hasty actions can cause more harm than the attacker would have. * Menu: * Security Compromise Underway-:: * Security Compromise has already happened::  File: Security-HOWTO.info, Node: Security Compromise Underway-, Next: Security Compromise has already happened, Up: What To Do During and After a Breakin Security Compromise Underway- ============================= Spotting a security compromise under way can be a tense undertaking. How you react can have large consequences. If the compromise you are seeing is a physical one, odds are you have spotted someone who has broken into your home, office or lab. You should notify your local authorities. In a lab, you might have spotted someone trying to open a case or reboot a machine. Depending on your authority and procedures, you might ask them to stop, or contact your local security people. If you have detected a local user trying to compromise your security, the first thing to do is confirm they are in fact who you think they are. Check the site they are logging in from. Is it the site they normally log in from? No? Then use a non-electronic means of getting in touch. For instance, call them on the phone or walk over to their office/house and talk to them. If they agree that they are on, you can ask them to explain what they were doing or tell them to cease doing it. If they are not on, and have no idea what you are talking about, odds are this incident requires further investigation. Look into such incidents , and have lots of information before making any accusations. If you have detected a network compromise, the first thing to do (if you are able) is to disconnect your network. If they are connected via modem, unplug the modem cable; if they are connected via ethernet, unplug the Ethernet cable. This will prevent them from doing any further damage, and they will probably see it as a network problem rather than detection. If you are unable to disconnect the network (if you have a busy site, or you do not have physical control of your machines), the next best step is to use something like `tcp[lowbar]wrappers' or `ipfwadm' to deny access from the intruder's site. If you can't deny all people from the same site as the intruder, locking the user's account will have to do. Note that locking an account is not an easy thing. You have to keep in mind `.rhosts' files, FTP access, and a host of possible backdoors). After you have done one of the above (disconnected the network, denied access from their site, and/or disabled their account), you need to kill all their user processes and log them off. You should monitor your site well for the next few minutes, as the attacker will try to get back in. Perhaps using a different account, and/or from a different network address.  File: Security-HOWTO.info, Node: Security Compromise has already happened, Prev: Security Compromise Underway-, Up: What To Do During and After a Breakin Security Compromise has already happened ======================================== So you have either detected a compromise that has already happened or you have detected it and locked (hopefully) the offending attacker out of your system. Now what? * Menu: * Closing the Hole:: * Assessing the Damage:: * Backups Backups Backups!:: * Tracking Down the Intruder-::  File: Security-HOWTO.info, Node: Closing the Hole, Next: Assessing the Damage, Up: Security Compromise has already happened Closing the Hole ---------------- If you are able to determine what means the attacker used to get into your system, you should try to close that hole. For instance, perhaps you see several FTP entries just before the user logged in. Disable the FTP service and check and see if there is an updated version, or if any of the lists know of a fix. Check all your log files, and make a visit to your security lists and pages and see if there are any new common exploits you can fix. You can find Caldera security fixes at http://www.caldera.com/tech-ref/security/. Red Hat has not yet seperated their security fixes from bug fixes, but their distribution errata is available at http://www.redhat.com/errata Debian now has a security mailing list and web page. See: http://www.debian.com/security/ for more information. It is very likely that if one vendor has released a security update, that most other Linux vendors will as well. There is now a linux security auditing project. They are methodically going through all the user space utilities and looking for possible security exploits and overflows. From their announcement: "We are attempting a systematic audit of Linux sources with a view to being as secure as OpenBSD. We have already uncovered (and fixed) some problems, but more help is welcome. The list is unmoderated and also a useful resource for general security discussions. The list address is: security-audit@ferret.lmh.ox.ac.uk To subscribe, send a mail to: security-audit-subscribe@ferret.lmh.ox.ac.uk" If you don't lock the attacker out, they will likely be back. Not just back on your machine, but back somewhere on your network. If they were running a packet sniffer, odds are good they have access to other local machines.  File: Security-HOWTO.info, Node: Assessing the Damage, Next: Backups Backups Backups!, Prev: Closing the Hole, Up: Security Compromise has already happened Assessing the Damage -------------------- The first thing is to assess the damage. What has been compromised? If you are running an Integrity Checker like `Tripwire' you can make a `Tripwire' run and it should tell you. If not, you will have to look around at all your important data. Since Linux systems are getting easier and easier to install, you might consider saving your config files and then wiping your disk(s) and reinstalling, then restoring your user files from backups and your config files. This will ensure that you have a new, clean system. If you have to backup files from the compromised system, be especially cautious of any binaries that you restore, as they may be Trojan horses placed there by the intruder. Re-installation should be considered mandatory upon an intruder obtaining root access. Additionally, you'd like to keep any evidence there is, so having a spare disk in the safe may make sense. Then you have to worry about how long ago the compromise happened, and whether the backups hold any damaged work. More on backups later.  File: Security-HOWTO.info, Node: Backups Backups Backups!, Next: Tracking Down the Intruder-, Prev: Assessing the Damage, Up: Security Compromise has already happened Backups Backups Backups! ------------------------ Having regular backups is a godsend for security matters. If your system is compromised, you can restore the data you need from backups. Of course, some data is valuable to the attacker too, and they will not only destroy it, they will steal it and have their own copies; but at least you will still have the data. You should check several backups back into the past before restoring a file that has been tampered with. The intruder could have compromised your files long ago, and you could have made many successful backups of the compromised file!!! Of course, there are also a raft of security concerns with backups. Make sure you are storing them in a secure place. Know who has access to them. (If an attacker can get your backups, they can have access to all your data without you ever knowing it.)  File: Security-HOWTO.info, Node: Tracking Down the Intruder-, Prev: Backups Backups Backups!, Up: Security Compromise has already happened Tracking Down the Intruder- --------------------------- Ok, you have locked the intruder out, and recovered your system, but you're not quite done yet. While it is unlikely that most intruders will ever be caught, you should report the attack. You should report the attack to the admin contact at the site where the attacker attacked your system. You can look up this contact with `whois' or the Internic database. You might send them an email with all applicable log entries and dates and times. If you spotted anything else distinctive about your intruder, you might mention that too. After sending the email, you should (if you are so inclined) follow up with a phone call. If that admin in turn spots your attacker, they might be able to talk to the admin of the site where they are coming from and so on. Good crackers often use many intermediate systems, some (or many) of which may not even know they have been compromised. Trying to track a cracker back to their home system can be difficult. Being polite to the admins you talk to can go a long way to getting help from them. You should also notify any security organizations you are a part of (CERT (http://www.cert.org/) or similar), as well as your Linux system vendor.  File: Security-HOWTO.info, Node: Security Sources, Next: Glossary, Prev: What To Do During and After a Breakin, Up: Top Security Sources **************** There are a LOT of good sites out there for Unix security in general and Linux security specifically. It's very important to subscribe to one (or more) of the security mailing lists and keep current on security fixes. Most of these lists are very low volume, and very informative. * Menu: * FTP sites:: * Web Sites:: * Mailing Lists:: * Books - Printed Reading Material::  File: Security-HOWTO.info, Node: FTP sites, Next: Web Sites, Up: Security Sources FTP sites ========= CERT is the Computer Emergency Response Team. They often send out alerts of current attacks and fixes. cert.org Replay has archives of many security programs. Since they are outside the US, they don't need to obey US crypto restrictions. replay.com Matt Blaze is the author of CFS and a great security advocate. Matt Blaze's stuff (ftp://ftp.research.att.com/pub/mab) `tue.nl' is a great security FTP site in the Netherlands. ftp.win.tue.nl  File: Security-HOWTO.info, Node: Web Sites, Next: Mailing Lists, Prev: FTP sites, Up: Security Sources Web Sites ========= * The Hacker FAQ is a FAQ about hackers: The Hacker FAQ * The COAST archive has a large number of Unix security programs and information: COAST * Rootshell.com is a great site for seeing what exploits are currently being used by crackers: rootshell.com exploits * BUGTRAQ puts out advisories on security issues: BUGTRAQ archives * CERT, the Computer Emergency Response Team, puts out advisories on common attacks on unix platforms: CERT home * Dan Farmer is the author of SATAN and many other security tools. His home site has some interesting security survey information, as well as security tools: Dan Farmers trouble.org * The Linux security WWW is a good site for Linux security information: Linux Security WWW * Reptile has lots of good Linux security information on his site: Reptiles Linux Security Page * Infilsec has a vulnerability engine that can tell you what vunerabilities affect a specific platform: Infilsec vunerability engine * CIAC sends out periodic security bulletins on common exploits: CIAC bulitins * A good starting point for Linux Pluggable Authentication modules can be found at http://www.kernel.org/pub/linux/libs/pam/. * The debian project has a web page for their security fixes and information. It is at http://www.debian.com/security/.  File: Security-HOWTO.info, Node: Mailing Lists, Next: Books - Printed Reading Material, Prev: Web Sites, Up: Security Sources Mailing Lists ============= Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org containing the message body subscribe bugtraq. (see links above for archives). CIAC: Send e-mail to: majordomo@tholia.llnl.gov In the BODY (not subject) of the message put (either or both): subscribe ciac-bulletin Redhat has a number of mailing lists, the most important of which is the redhat-announce list. You can read about security (and other) fixes as soon as they come out. Send email to majordomo@redhat.com and put subscribe redhat-announce. The debian project has a security mailing list that covers their security fixes. see http://www.debian.com/security/ for more information.  File: Security-HOWTO.info, Node: Books - Printed Reading Material, Prev: Mailing Lists, Up: Security Sources Books - Printed Reading Material ================================ There are a number of good security books out there. This section lists a few of them. In addition to the security specific books, security is covered in a number of other books on system administration. Building Internet Firewalls By D. Brent Chapman [amp ] Elizabeth D. Zwicky 1st Edition September 1995 ISBN: 1-56592-124-0 Practical UNIX [amp ] Internet Security, 2nd Edition By Simson Garfinkel [amp ] Gene Spafford 2nd Edition April 1996 ISBN: 1-56592-148-8 Computer Security Basics By Deborah Russell [amp ] G.T. Gangemi, Sr. 1st Edition July 1991 ISBN: 0-937175-71-4 Linux Network Administrator's Guide By Olaf Kirch 1st Edition January 1995 ISBN: 1-56592-087-2 PGP: Pretty Good Privacy By Simson Garfinkel 1st Edition December 1994 ISBN: 1-56592-098-8 Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger [amp ] William VonStorch (Consulting Editor Eugene H. Spafford) 1st Edition August 1995 ISBN: 1-56592-086-4  File: Security-HOWTO.info, Node: Glossary, Next: Frequently Asked Questions, Prev: Security Sources, Up: Top Glossary ******** * `host:' A computer system attached to a network. * `firewall:' A component or set of components that restricts access between a protected network and the Internet, or between other sets of networks. * `bastion Host:' A computer system that must be highly secured because it is vulnerable to attack, usually because it is exposed to the Internet and is a main point of contact for users of internal networks. It gets its name from the highly fortified projects on the outer walls of medieval castles. Bastions overlook critical areas of defense, usually having strong walls, room for extra troops, and the occasional useful tub of boiling hot oil for discouraging attackers. * `dual-homed Host:' A general-purpose computer system that has at least two network interfaces. * `packet:' The fundamental unit of communication on the Internet. * `packet filtering:' The action a device takes to selectively control the flow of data to and from a network. Packet filters allow or block packets, usually while routing them from one network to another (most often from the Internet to an internal network, and vice-versa). To accomplish packet filtering, you set up rules that specify what types of packets (those to or from a particular IP address or port) are to be allowed and what types are to be blocked. * `perimeter network:' A network added between a protected network and an external network, in order to provide an additional layer of security. A perimeter network is sometimes called a DMZ. * `proxy server:' A program that deals with external servers on behalf of internal clients. Proxy clients talk to proxy servers, which relay approved client requests to real servers, and relay answers back to clients. * `denial of service:' A denial of service attack is when an attacker consumes the resources on your computer for things it was not intended to be doing, thus preventing normal use of your network resources for legimite purposes. * `buffer overflow:' Common coding style is to never allocate large enough buffers, and to not check for overflows. When such buffers overflow, the executing program (daemon or set-uid program) can be tricked in doing some other things. Generally this works by overwriting a function's return address on the stack to point to another location. * `IP spoofing:' IP Spoofing is a complex technical attack that is made up of several components. It is a security exploit that works by tricking computers in a trust-relationship that you are someone that you really aren't. There is an extensive paper written by daemon9, route, and infinity in the Volume Seven, Issue fourty-Eight issue of Phrack Magazine. * `authentication:' The property of knowing that the data received is the same as the data that was sent, and that the claimed sender is in fact the actual sender. * `non-repudiation:' The property of a receiver being able to prove that the sender of some data did in fact send the data even though the sender might later deny ever having sent it. * `superuser:' An informal name for `root'.  File: Security-HOWTO.info, Node: Frequently Asked Questions, Next: Conclusion, Prev: Glossary, Up: Top Frequently Asked Questions ************************** 1. Is it more secure to compile driver support directly into the kernel, instead of making it a module? Answer: Some people think it is better to disable the ability to load device drivers using modules, because an intruder could load a Trojan module or a module that could affect system security. However, in order to load modules, you must be root. The module object files are also only writable by root. This means the intruder would need root access to insert a module. If the intruder gains root access, there are more serious things to worry about than whether he will load a module. Modules are for dynamically loading support for a particular device that may be infrequently used. On server machines, or firewalls for instance, this is very unlikely to happen. For this reason, it would make more sense to compile support directly into the kernel for machines acting as a server. Modules are also slower than support compiled directly in the kernel. 2. Why does logging in as root from a remote machine always fail? Answer: See *Note Root Security:: . This is done intentionally to prevent remote users from attempting to connect via `telnet' to your machine as `root', which is a serious security vulnerability. Don't forget: potential intruders have time on their side, and can run automated programs to find your password. 3. How do I enable shadow passwords on my Red Hat 4.2 or 5.0 Linux box? Answer: Shadow passwords is a mechanism for storing your password in a file other than the normal `/etc/passwd' file. This has several advantages. The first one is that the shadow file, `/etc/shadow', is only readable by root, unlike `/etc/passwd', which must remain readable by everyone. The other advantage is that as the administrator, you can enable or disable accounts without everyone knowing the status of other users' accounts. The `/etc/passwd' file is then used to store user and group names, used by programs like `/bin/ls' to map the user ID to the proper username in a directory listing. The `/etc/shadow' file then only contains the username and his/her password, and perhaps accounting information, like when the account expires, etc. To enable shadow passwords, run `pwconv' as root, and `/etc/shadow' should now exist, and be used by applications. Since you are using RH 4.2 or above, the PAM modules will automatically adapt to the change from using normal `/etc/passwd' to shadow passwords without any other change. Since you're interested in securing your passwords, perhaps you would also be interested in generating good passwords to begin with. For this you can use the `pam[lowbar]cracklib' module, which is part of PAM. It runs your password against the Crack libraries to help you decide if it is too easily guessable by password cracking programs. 4. How can I enable the Apache SSL extensions? Answer: 1.Get SSLeay 0.8.0 or later from urlnam (ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL) 2.Build and test and install it! 3.Get Apache 1.2.5 source 4.Get Apache SSLeay extensions from here (ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.5+ssl_1.13.tar.gz) 5.Unpack it in the apache-1.2.5 source directory and patch Apache as per the README. 6.Configure and build it. You might also try Replay Associates which has many pre-built packages, and is located outside of the United States. 5. How can I manipulate user accounts, and still retain security? Answer: The Red Hat distribution, especially RH5.0, contains a great number of tools to change the properties of user accounts. * The `pwconv' and `unpwconv' programs can be used to convert between shadow and non-shadowed passwords. * The `pwck' and `grpck' programs can be used to verify proper organization of the `passwd' and `group' files. * The `useradd', `usermod', and `userdel' programs can be used to add, delete and modify user accounts. The `groupadd', `groupmod', and `groupdel' programs will do the same for groups. * Group passwords can be created using `gpasswd'. All these programs are "shadow-aware" - that is, if you enable shadow they will use `/etc/shadow' for password information, otherwise it won't. See the respective man pages for further information. 6. How can I password protect specific HTML documents using Apache? I bet you didn't know about http://www.apacheweek.org, did you? You can find information on user Authentication at http://www.apacheweek.com/features/userauth as well as other web server security tips from http://www.apache.org/docs/misc/security_tips.html  File: Security-HOWTO.info, Node: Conclusion, Next: Thanks to, Prev: Frequently Asked Questions, Up: Top Conclusion ********** By subscribing to the security alert mailing lists, and keeping current, you can do a lot towards securing your machine. If you pay attention to your log files and run something like `tripwire' regularly, you can do even more. A reasonable level of computer security is not difficult to maintain on a home machine. More effort is required on business machines, but Linux can indeed be a secure platform. Due to the nature of Linux development, security fixes often come out much faster than they do on commercial operating systems, making Linux an ideal platform when security is a requirement.  File: Security-HOWTO.info, Node: Thanks to, Prev: Conclusion, Up: Top Thanks to ********* Information here is collected from many sources. Thanks to the following that either indirectly or directly have contributed: following who either indirectly or directly have contributed: Rob Riggs rob@DevilsThumb.com S. Coffin scoffin@netcom.com Viktor Przebinda viktor@CRYSTAL.MATH.ou.edu Roelof Osinga roelof@eboa.com Kyle Hasselbacher kyle@carefree.quux.soltc.net David S. Jackson dsj@dsj.net Todd G. Ruskell ruskell@boulder.nist.gov Rogier Wolff R.E.Wolff@BitWizard.nl Antonomasia ant@notatla.demon.co.uk Nic Bellamy sky@wibble.net Eric Hanchrow offby1@blarg.net Robert J. Bergerrberger@ibd.com Ulrich Alpers lurchi@cdrom.uni-stuttgart.de David Noha dave@c-c-s.com The following have translated this HOWTO into various other languages! A special thank you to all of them for help spreading the linux word... Polish: Ziemek Borowski ziembor@FAQ-bot.ZiemBor.Waw.PL Japanese: FUJIWARA Teruyoshi fjwr@mtj.biglobe.ne.jp Indonesian: Tedi Heriyanto 22941219@students.ukdw.ac.id