* Covers the entire open source Web platform known as LAMP, which includes Linux, Apache, MySQL, and PHP, the basis for many dynamic data-driven Web sites
* Seven convenient minibooks provide easy reference on open source and team development, working with Linux and Apache, automating Web sites with Perl, developing front-end applications with Tcl/TK, creating dynamic Web pages with PHP, accessing Web databases with MySQL, and processing Web files with regular expressions
* Includes valuable, hard-to-find coverage of collaboration, file sharing, and version control with CVS
* PHP is running on over nine million sites, with an average increase of 6.5 percent monthly over the past two years; Apache Web servers handle seventy percent of Web content
Introduction.
Book I: Configuring Linux and Windows for Apache.
Chapter 1: Configuring Linux.
Chapter 2: Configuring Windows.
Chapter 3: Ten Third-Party Packages That Enhance Security.
Book II: Building an Apache Web Site.
Chapter 1: Introducing the Apache Web Server.
Chapter 2: Installing Apache.
Chapter 3: Configuring Apache.
Chapter 4: Apache Modules.
Chapter 5: Ten Security Tips.
Book III: Perl Web Site Automation.
Chapter 1: Introducing Perl.
Chapter 2: Simple Data Types.
Chapter 3: Comparing and Testing Variables.
Chapter 4: Controlling the Structure of Your Program.
Chapter 5: Processing Text Files and Directories.
Chapter 6: Advanced Perl Coding.
Chapter 7: Perl and CGI Scripts.
Chapter 8: Ten Useful Perl Functions.
Book IV: Tcl/Tk Front End Development.
Chapter 1: What Are Tcl and Tk?
Chapter 2: Processing Variables and Expressions.
Chapter 3: Controlling the Structure.
Chapter 4: Building Procedures.
Chapter 5: Manipulating Files.
Chapter 6: Programming with the Tcl Packages.
Chapter 7: Designing GUIs with Tk.
Chapter 8: Arranging Controls, Drawing Pictures, and Handling Text.
Chapter 9: Displaying Standard Dialog Boxes in Tk.
Chapter 10: Ten Useful Tcl/Tk Tools.
Book V: PHP Web Pages for Dynamic Content.
Chapter 1: What You Can Do with PHP.
Chapter 2: Writing Server-Side Scripts.
Chapter 3: Storing Information.
Chapter 4: Controlling the Program Flow.
Chapter 5: Arrays and Functions.
Chapter 6: Interacting with HTML.
Chapter 7: Advanced Programming with PHP.
Chapter 8: Creating Graphics.
Chapter 9: Modeling Data with Classes.
Chapter 10: Ten Ways to Enhance Your Web Site.
Book VI: MySQL Databases on the Web.
Chapter 1: What Is MySQL?
Chapter 2: Managing Databases and Tables.
Chapter 3: Relating Your Data.
Chapter 4: Accessing MySQL from PHP.
Chapter 5: Querying with SQL and PHP.
Chapter 6: Accessing MySQL from Perl.
Chapter 7: Creating a Username System for Your Web Site.
Chapter 8: Ten Ways to Enhance a Web Site with Databases.
Book VII: Processing Web Files with Regular Expressions.
Chapter 1: Why Use Regular Expressions?
Chapter 2: Following the Syntax of Regular Expressions.
Chapter 3: Customizing, Searching, and Replacing.
Chapter 4: Grouping and Capturing.
Chapter 5: Joining, Splitting, and Making Up.
Chapter 6: Processing Multiple Lines and Files.
Chapter 7: Processing HTML Files.
Chapter 8: Ten Regular Expression Gotchas.
Book VIII: Appendixes.
Appendix A: Managing Files with CVS.
Appendix B: Understanding Open-Source Licenses.
Index.
In This Chapter
To make your Linux system secure enough to resist being compromised, you should focus on two general areas:
* The Linux system itself, which is the focus of this chapter
* The security of the network to which the Linux system is connected
You need to secure the Linux system before attaching it to the network. It is difficult to ensure the security of a system if it has been connected to a public network before you begin configuring it for secure operation. Because this chapter focuses on prevention, you need to begin with a clean slate - in other words, a system that you are certain has not been turned into a hacker's willing pawn.
If your Linux system will be exposed to the Internet, you want to protect it from as much foul play as possible. You also want to protect your private network resources from the Internet and the Linux system allowing public access. To do this, you need to design a detailed security plan and develop what is commonly called an isolation LAN or demilitarized zone (DMZ) on your network. The simplest form of a secure LAN consists of two routers, as shown in Figure 1-1.
The outside router controlsaccess to systems within the secure LAN and restricts (generally blocks entirely) connections that originate from hosts on the internet that are targeting either the private network or the inside router. The inside router is designed to allow private LAN traffic to pass outside the network and act as a second barrier between the private network and the internet. It blocks all inbound connections and specifically blocks connections initiated by hosts on the secure LAN and the outside router itself. This ensures that if a secure LAN host or the outside router is compromised, intruders will not have gained access to the private network. Even with a secure LAN configuration, your Linux host needs to be securely configured. Although the secure LAN goes a long way towards protecting your private network resources, your hosts on the secure LAN are exposed to the Internet.
Getting a Handle on TCP and UDP Services
When you finish your Linux installation and before installing any other software, you need to remove the default network services that won't be used. By default, the services running on your new Linux installation are providing what the install package's creator deems commonly used services. Because your system will provide Web services (exclusively if possible) and because it may be directly connected to the Internet, you will want to remove many of the default services. Any service can provide an unscrupulous remote user with a potential avenue into your system. If the service is available to network users and is running, you should consider it a potential weakness. Even though many hours are spent testing and identifying flaws in the Linux system, testing can't catch everything. However, you can minimize potential threats by removing unneeded services.
Inetd
Identifying and controlling services, network services in particular, is fairly straightforward on most current versions of Linux, including Red Hat, Mandrake, and SuSE. Within the /etc directory, you will find a file called inetd.conf. This file is used at system startup to load most of the system's networking services. Rather than have a large number of active processes listening for network connections, the inetd "super server" plays traffic cop between service requests and available services, which results in a more efficient use of system resources. Basically, inetd is a server service that listens for requests that relate to TCP and UDP connections. Any requests for services are then passed to the appropriate service if one is available. If no service is available, the request is dropped. For example, if a Linux server is allowing Web and FTP connections for hundreds of users, inetd allows the creation of sessions for each individual connection rather than have numerous instances of the ftpd or httpd processes idling all the time waiting for users to connect. This frees up memory and CPU time for other uses.
The inetd process relies on a corresponding conf file to determine which processes are available for use. Figure 1-2 shows an example of an inetd.conf file.
What you find in the inetd file varies depending on the distribution you use, but how you can control it is the same across most distributions. You can open the file with the text editor of your choice and add or remove entries as needed. For example, the inetd server ignores any line with the # symbol. Using the # symbol is also known as "commenting out" the code that follows.
"Commenting out" allows you to disable startup services without removing the configuration. This is useful if you have a service you will use only occasionally and you want to start it manually instead of at startup. You can also temporarily disable one of the services by inserting the # symbol and restarting the inetd. As the phrase "comment out" suggests, you can also use this symbol to insert comments into the file. For example you might want to note why you added or removed a particular entry. The process for restarting inetd varies in some distributions, but in general, you can go to the directory where the inetd is stored (/etc/rc.d/inet.d on Red Hat) and type the inetd restart command. You need to run this command as root or with root privileges. If this command doesn't work on your distribution, search that product's support information for the relevant process to restart the inetd process.
The inetd.conf file contains six attributes for each item. Here are the attributes from left to right as shown in Figure 1-2:
* The service name: In the example, the first line has a service named ftp, indicating it is an ftp service. The name of the service is taken from the corresponding entry in the /etc/services file.
* The socket type: The socket type can be either stream or datagram. In most cases, it's stream.
* The protocol type: This can be specified as either TCP or UDP.
* The wait/nowait option: This option determines if a new process is spawned for each request (nowait) or if each request is processed sequentially one at a time (wait).
* The user whose rights are used to execute the service: The user is root in the example.
* The path to the command that launches the daemon: The path is /usr/local/tcpd in the example. A daemon is a program that waits in the background until called upon by a user to actually do something.
The seventh field is optional. If you don't need to specify any execution arguments, feel free to omit this field.
TIP
Many Linux distributions include graphical tools for configuring the startup services. Typically these configuration applets contain a list of startup services and corresponding check boxes. To disable a service, you simply clear the corresponding check box. In most cases, you need to manually shut down the service by using a command in a terminal window or by restarting the system. For more information about the specific tools available, consult the developers of your desktop environment (KDE or Gnome).
Xinetd
On many current distributions, the xinetd daemon is used instead of inetd. Conceptually, xinetd does the same thing inetd does. However, for the most part, this similarity is only skin deep. The processes for configuring files and for the construction of the configuration files are quite different. There are some other critical operational differences. For example, any user can use xinetd to start servers that do not need privileged ports. This is possible because, unlike inetd, xinetd does not require that the services in its configuration file (xinet.d) also appear in /etc/services.
In the list below, the key enhancements (what xinetd does that inetd does not) are outlined.
* Access control works on multi-threaded and single-threaded services.
* Xinetd kills those services that no longer meet the existing access control criteria and those that have been removed from the xinet.d configuration file.
* It can place limits on the number of processes a single host can spawn, the number of servers a particular service can start, and the size of log files. These configurable limitations go a long way towards preventing denial-of-service attacks, which attempt to disrupt the system by overutilizing available resources.
As noted earlier, the configuration file (/etc/xinetd.conf) for the xinetd service is also notably different than the file used by inetd. The example below (Figure 1-3) shows telnet, IMAP, and the default entries. By itself, this configuration is not entirely useful; I've included it because it illustrates the differences between the layout of inetd and xinetd.
TIP
If you would like to convert an inet.d configuration file to be compatible with xinetd, you can make use of one of a couple of conversion tools. Both itox and xconv.pl come with full distributions of xinetd and are relatively painless to use. For guidance, check out the information located here (under the configuration section): linuxfocus.org/English/ November2000/ article175.shtml.
No Sharing: NFS/RPC
Unless you're dying for someone to turn your Linux server into the technological equivalent of Typhoid Mary, avoid the Remote Procedure Call (RPC) and Network File Service (NFS). Keep in mind I'm talking about a Linux server exposed to the Internet. RPC and NFS can be very useful on a private network but have no business on at-risk systems. Both services are designed to allow remote users to access resources:
* RPC allows the sharing of processing resources among computers. With RPC, a single program can use the resources of several computers collectively in a clustery arrangement.
* NFS is used to facilitate disk access. Remote users who have the appropriate access rights can mount and access data on an NFS-enabled hard disk.
It is painfully easy to misconfigure these services, NFS in particular, in a manner that creates huge holes. For example, a misconfigured NFS implementation allows anyone to mount and access data on the NFS-capable drive.
The portmapper controls the use of NFS and RPC. The portmapper is another daemon and is typically housed at /etc/rc.d/rc.inet2, though the location can vary depending on the distribution. If you do not know the location, you can try running the find command on the /etc directory. For example, the following line finds instances of words containing map:
find /etc -name "*map*" -print | more
You can replace the *map* argument with *nfs*, *port*, or *rpc* to thoroughly scan the /etc/rc.d directories for the startup locations of the NFS and RPC services. Like other configuration files, find the relevant entries and place a # in front of the execution lines or simply delete the entries. After the services have been disabled, you need to restart the system to unload them.
REMEMBER
If you want to access your server remotely, Telnet is not a good option because it has no system for protecting information passed between the connecting client and the server. Instead, you should use the Secure Shell (SSH) client-server utility. SSH encrypts all the data that passes between the client and the server. Not only is the logon information protected, but the data transferred is protected as well. Virtually all modern Linux distributions include an SSH implementation, but if it is not present, you can download it. To install SSH, you can download the source, run the ./configure script, and then run the make and make install commands. For more information on the installation process for SSH, see openssh.com.
Misleading Binaries (SUID/GUID Binaries)
In addition to network services, some of the programs on your Linux system can be real liabilities because they need root privileges to do much. Some programs use a specialized bit (set on the binary itself) - called either Set User ID (SUID) or Group User ID (GUID) - to gain more privileges than the user who might run the program or use its services. For example, if users want to send e-mail, they need to use the services of an SMTP server such as Sendmail. However, they probably won't have all the rights needed to perform all the tasks that the mail server needs to do. To perform the needed tasks, Sendmail often runs with the Set User ID bit set to use root account privileges.
Any program that uses SUID/GUID to run with elevated privileges is a liability. If a malicious user gains control of the application, that user may be able to interact with the system using the elevated system rights provided by the SUID/GUID setting. Fortunately, you can easily identify the binaries that have been configured to use the SUID/GUID funtionality. If you check the file attributes of a binary and see an s where you would normally see an r or x (r-sr-xr-x, for example), you have a binary using SUID/GUID. So how do you find and, if not needed, disable these binaries? The easiest method is to use the find command to search the entire system and build a list of the SUID/GUID-enabled applications. Here's an elegant solution that uses the find command with the option to dump the output to a text file:
find / \( -perm -4000 -o -perm -2000 \) -exec ls -ldb {} \; >> /tmp/suids
This command creates the text file suids in the /tmp directory with information about all the binaries using the SUID/GUID capability. You can find and delete any binaries that you know you don't need. If you determine that some of the binaries may prove useful, you can refine their access rules (by using the CHMOD command) so that not just anyone can run them. This is especially useful if one of the remaining binaries needs to be granted root access.
TIP
Here are a couple handy ways to help you determine if you need a particular service or program:
* Visit the home page of your Linux distribution and search for the program.
* Search for "man program/service" using a search engine like Yahoo! or Google. The manual (man) pages typically reveal a wealth of information about the program/service and its usage.
Protection with Firewalls
Although many third-party security products, including firewalls, are available for Linux, several handy features are included with the operating system out of the box. Having a firewall on your Linux system is exceptionally important if the system is outside any other firewalls.
Continues...
Excerpted from Apache, MySQL, and PHP Web Development All-in-One Desk Reference For Dummies by Jeff Cogswell Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Overview
* Covers the entire open source Web platform known as LAMP, which includes Linux, Apache, MySQL, and PHP, the basis for many dynamic data-driven Web sites
* Seven convenient minibooks provide easy reference on open source and team development, working with Linux and Apache, automating Web sites with Perl, developing front-end applications with Tcl/TK, creating dynamic Web pages with PHP, accessing Web databases with MySQL, and processing Web files with regular expressions
* ...