Fedora 6 and Red Hat Enterprise Linux Bible

If your organization's Internet service is currently used for outgoing connections, you must consider different security issues if you intend to allow incoming connections. The following are some differences:

You have many different ways to connect your Fedora or Red Hat Enterprise Linux server to the Internet and offer its services to the public. In the following sections, I describe what you need to get your server up and running on the Internet.

Choosing an ISP

Although every ISP expects to see outgoing traffic on your Internet connection, not all of them expect incoming traffic (that is, traffic that someone initiates from outside your network). Although your ISP - which may be your local phone company, your cable TV company, or an independent ISP - may expect you to download files from remote servers, it may not expect people to download large files from you.

Assuming that you're going to house the server in your place of work or residence, you need to obtain the following information from a potential ISP:

Checking Terms of Service

Any ISP that handles more than a few users has a document that describes what you can do with the Internet connection that it provides you. That document probably carries a name such as Terms of Service or User Agreement. If you can't find it on the ISP's Web site, you will almost certainly see it after you click a link to sign up for an account.

Typically, an ISP requires you to sign up for a business account if you want to do any kind of business on your Internet service. Here are some excerpts from agreements for several ISPs:

… you are not permitted to use your Internet connection to sell or advertise goods or services. This is permitted only to those who have purchased a business account or a virtual server ."

" Dialup clients are not to use their dialup connection for active or constantly connected Web/FTP/mail or other server services. "

" Anyone wanting to promote a business or sell a product must use a business account. "

Internet access is the volume business for most ISPs, and they consider business accounts for those who want to manage their own Web presence as premium services. Although you can technically use a personal account to set up a server (TCP/IP doesn't care what goes across the wire), the ISP's Terms of Service or Acceptable Use Policy may not permit you to do so. Although your DSL connection may easily handle a handful of hits a day on your Web server, offering that service can result in the termination of your account by the ISP. Check into what the ISP considers acceptable use before you use any Internet account to set up a public server.

Getting Static IP Addresses

Most dialup and DSL Internet-access accounts use dynamic IP addresses, so whenever you connect to your Internet service, the provider assigns the IP address to that connection. After you disconnect, the ISP can reclaim that IP address to assign to someone else. The next time you connect, it is possible that you will get a different IP address.

For a server to have constant, reliable presence on the Internet, it will typically have one or more static IP addresses . Most ISPs charge an additional fee for static IP addresses. Each static IP address typically costs between $5 and $20 per month.

Note 

You can assign a public DNS hostname to a server without a static IP address using Dynamic DNS. Dynamic DNS involves running software on your server that monitors your IP address and notifies the Dynamic DNS provider when that IP address changes.

The number of static IP addresses that you need varies, depending on how you configure your servers. Most likely, you want at least two static IP addresses, one for each of two DNS servers (if you're configuring DNS). In a small organization, those same servers may also offer your Web server, mail server, and other services as well. In general, you want one static IP address for each computer that you make publicly accessible to the Internet.

Tip 

You can do some tricks with services such as port forwarding (iptables in Chapter 14) and virtual hosting (Apache Web server in Chapter 21) that enable multiple physical computers to offer services or give the appearance of having multiple computers on a single static IP address. These tricks can reduce the number of IP addresses you need to buy. (To simplify the discussion here, however, I'm describing a case where each public server has its own static, public IP address.)

Choosing a Connection Speed

Another difficulty with keeping your servers in your own home or business is choosing how fast an Internet connection you need. Although most data centers at ISPs offer more than enough bandwidth for your needs, high-speed Internet connections may not be available to your location - or may prove prohibitively expensive.

Although it's technically possible, using a dialup connection (up to 56 Kbps) to support an Internet server is generally considered unacceptable. Always-on connection services that you may want to consider include the following:

If your business can afford it, you might want dedicated T-1 or T-3 lines for your business. A T-1 connection can operate at data rates of 1.444 Mbps. A T-3 line can support rates of 43 Mbps. Check with your local ISPs for available connection types and pricing.

Getting a Domain Name

Domain names are available from dozens of different domain registrars these days. You can check the availability of domain names from any of these registrar's Web sites, such as GoDaddy ( godaddy.com ) or Network Solutions ( networksolutions.com ). Or you can use the whois command that comes with Fedora and RHEL.

The top-level domain (TLD) in which you register your own domain should reflect the type of business or organization that you represent. Commercial businesses typically use the .com TLD. Newer TLDs, however, such as .biz and . info , are now available for domains that represent a business community or for information about businesses and individuals.

Other common TLDs are .net (originally for network services companies) and .org (originally intended for organizations). Although those domains were intended for special purposes, there are really no restrictions on who can get and use those domain names.

Institutions of higher education in the United States use the .edu TLD. A TLD that has recently become available for public use is the .us TLD, for organizations within the United States (public K-12 schools in the U.S. typically use the .us TLD). Countries outside of the United States each already have their own TLD.

Checking Domain Name Availability

With an active Internet connection, you can use the whois command in Red Hat Linux to check if a domain name is available in the .com, .net, .org , or .edu domains. Following is an example of using whois to check the availability of the domain handsonhistory.com :

$ whois handsonhistory.com [Querying whois.internic.net] . . . Registrant: Hands-On-History (HANDSONHISTORY-DOM) PO Box 943 Port Angeles, NJ 98221 US Domain Name: HANDSONHISTORY.COM . . . Technical Contact: Support domains@XMISSION.COM Xmission Domain (XDS) 51 East 400 South, Suite #200 Salt Lake City , UT 84111 US 801-539-0852 fax: 999 999 9999 Record expires on 17-May-2012. Record created on 18-May-1998. Database last updated on 7-Mar-2006 01:21:40 EST. Domain servers in listed order: NS.XMISSION.COM 198.60.22.2 NS1.XMISSION.COM 198.60.22.22

If the name were available, you'd see the message No match for HANDSONHISTORY.COM . Because the name is already taken, you can see information about the domain name registrar, name servers containing address records for the domain, and a variety of contact information.

Reserving a Domain Name

At one point, Network Solutions was the only company from which you could get a domain name in the most popular U.S. domains ( .com , .net , and .org ). Now, there are new TLDs and dozens of domain registrars from which you can select a domain name.

You can have your ISP obtain your domain name for you, or you can go to one of the domain registrars yourself and register online to get your domain name.

Note 

Because prices and services can vary so widely, I recommend that you shop around for a domain registrar. The Internet Corporation for Assigned Names and Numbers (ICANN) maintains a list of accredited registrars at www.icann.org/registrars/accredited-list.html. The list contains links to registrar sites and a list of the TLDs that they support.

Although each registrar offers different domain and hosting- related services, the following list describes the information that you want to collect before you register your domain (and if you don't have all this information at the moment, don't worry - you can go back and fill in most of it later):

To pay for the domain name, the service expects you to provide a credit card number. Some registrars accept other forms of payment, although credit cards are the most popular means.

Configuring Your Public Server

With a domain name, a suitable Internet connection, and one or more static IP addresses, you need to prepare your server to share it on the Internet. In addition to choosing the types of services you want to offer, you must be more thoughtful about the security of your servers.

Configuring Networking

Whether you're configuring your computer for browsing the Web or offering up a server, procedures for creating network interfaces are very similar. See Chapters 15 and 16 for information on configuring TCP/IP for your computer. Following is a quick review of what you need to do to get a live connection to the Internet that's suitable for your server:

Note 

Changing your hostname after you install Fedora or RHEL can sometimes cause problems. Services such as printing and the X server (for your graphical desktop) sometimes fail after you change your hostname. Check to make sure that printing and other network services are still working after you change your hostname. Sometimes restarting the network interface can solve the problem.

After you set up your network interfaces and related information for your server, test the Internet connection by using the ping command, as described in Chapter 16. Next, if DNS is already configured for your domain, try to ping your server by name to see whether those in the outside world can reach you by name. Make sure that the static IP address that appears in response matches the static IP address that you were assigned.

Configuring Servers

Some services are more appropriate for public exposure than others. You probably don't want to offer your print server, for example, to anyone on the Internet. Similarly, file sharing with Samba or NFS isn't appropriate to share those services natively across the public Internet. (To access those services over an Internet connection, however, you could run them over a virtual private network.)

If you're creating your first public server, you may want to consider setting up at least the following basic types of servers:

Of course, you can share any type of server that you choose. Web, FTP, and mail servers, however, are designed for sharing publicly. The basic configuration for these types of servers isn't that difficult. Securing and monitoring these - or any - public servers, however, requires special effort, as the following sections describe.

Managing Security

Before you set up your Fedora or RHEL system as a server, you can use it simply to make outgoing connections to the Internet. You can use your firewall (iptables) to close off the ports on your interface to the Internet (making your computer quite secure). Now, however, you need to open some of the ports on that interface to accept incoming requests. With more ports open , you must also become more consistent in monitoring those ports. You can use SELinux to set boundaries around your Internet services.

Opening Your Firewall

Making your server public doesn't mean leaving your computer wide open. By using firewall rules, you can set your computer to allow outsiders to open connections to certain ports and block requests on other ports. Assuming that you set up your firewall to block incoming connections, here's a list of services (and the associated port numbers) that you may want to consider accepting through your firewall from your external interface to the Internet:

To see which ports are assigned to which services by default, refer to the /etc/services file. See http://www.iana.org/assignments/port-numbers for a full list of service ports. In most cases, a configuration file for a service indicates the default port number the service listens on. One way of making a service more private is to change the port number that a service listens on. Then the user must know to ask for the service at that particular port. To see which ports are currently exposed on your system, you can use the nmap command.

Chapter 14 describes how to change your firewall to accept requests for these services. I start with the iptables example in that chapter when I create the DNS example later in this chapter. You can use that description as a model for setting up a firewall to go with DNS. In the DNS example, you have separate computers for mail, FTP, and Web services. For a low-volume server, however, you can have them all on the same computer.

Enabling SELinux

Security Enhanced Linux (SELinux) is enabled by default in Fedora and RHEL starting with version 4. As it is implemented with targeted policies, most popular server types (including Web, FTP, and DNS) have policies set that restrict what intruders can do if they manage to break into the service. You should look over how policies are set on the Security Level Configuration ( system-config-securitylevel command) for services you are offering. Refer to Chapter 10 for more information on SELinux.

Checking Logs and System Files

By making your servers public, you also make them more open to attacks. Although firewalls are a good first line of defense, you still need to watch the activity on those ports that you leave open. A consistent program of monitoring traffic and checking changes to your server, therefore, becomes more critical. The following are a few techniques that you can use to help secure your servers:

I describe these and other security techniques in Chapter 14.

Keeping Up with Updates

You can expect to find and correct security issues continuously. You must keep up with software updates that are published to plug security holes. Although some of these updates address theoretical security problems, others are created in response to real break-ins or denial-of-service attacks that are known to exploit weaknesses in the components that come with your operating system.

For Red Hat Enterprise Linux systems, using the Red Hat Network (and its up2date facility) is the best way of getting security updates that are approved for Red Hat Enterprise Linux. For Fedora, you can use the Package Updater window (Pup) or yum to download and install updates from Fedora mirror sites that carry those updates (see Chapter 5 for information on using Pup and yum). You should also check CERT and other organizations (which I describe in Chapter 14) for security alerts.

After your server is secure and correctly configured, your last step is to start the server on the Internet with a domain name that points to it. Either ask your service provider to configure DNS for you, or set up your own DNS server, as I describe in the following section.

Категории