Reviewing IPFW Rules

To see your IPFW rules, run ipfw list:

...............................................................................................

# ipfw list

00100 pipe 1 ip from 192.168.99.100 80 to any

65535 allow ip from any to any

#

...............................................................................................

This listing shows our IPFW rule directing traffic to our dummynet rule. It doesn't show the dummynet rule, however. Pipes are stored in a separate list.

To view the pipes, run ipfw pipe list:

...............................................................................................

...............................................................................................

Note The output from ipfw pipe list is far wider than 80 characters. If possible, use a terminal emulator and make your window very, very wide.

These four lines describe both our dummynet rule and the associated IPFW rule. Much of this is in−depth information that we don't need to understand—it simply displays dummynet's heritage as a traffic−problem simulation tool. The first entry (v) is the dummynet rule number, followed by the rule on how dummynet permits traffic (w). The next interesting item is the source IP address (x)—in this case, our Web server. At the moment I took this snapshot, one particular destination IP address (y) is having traffic to it throttled.

Dummynet Queues

Dummynet works by putting packets in a queue, and then handling these queued packets in order. If you're trying to throttle a high−traffic site, this queue can fill up, so if your Web server starts occasionally locking up for a few seconds after you implement dummynet, you're probably overflowing the packet queue.

To fix this problem, modify your pipe rule to include a queue size, and increase it to the largest possible queue size of 1000KB:

...............................................................................................

ipfw add pipe 1 config bw 128Kbit/s queue 1000Kbytes

...............................................................................................

This larger queue uses kernel memory, however, so don't go slapping it in willy−nilly.

297

Directional Traffic Shaping

One thing to remember is that you cannot throttle incoming traffic. If someone posts a bootleg copy of the next Star Wars movie on your Web server, you're going to have a truly ridiculous number of incoming requests a second. No amount of configuration can prevent 30 million people clicking on a link to request pages from your server. The best you can do is restrict how you respond to these requests. This means that all you can do is limit your responses by throttling your outbound connections. In most cases this is okay, since, after all, you're the one serving Web pages or sending mail!

If you use a dummynet rule that tries to control incoming traffic, you'll slow down connections without really affecting incoming traffic at all. As a result, you'll build up connection queues on your server, and only hurt yourself. If you're being flooded with traffic, either refuse this sort of traffic entirely (see Chapter 8), find the demanded content and remove it, or contact your ISP for help.

Public−Key Encryption

Many security features in server daemons rely upon public−key encryption to ensure confidentiality, integrity, and authenticity. Many different Internet services also use public−key encryption. You need to have a basic grasp of public−key encryption to be able to run services like secure Web pages (https) and secure POP3 mail (pop3ssl).

Note If you're already familiar with public−key encryption, you can probably skip this section.

Encryption systems use a key to transform messages from readable versions (cleartext) to and from encoded versions (ciphertext). Although the words cleartext and ciphertext include the word text, they aren't restricted to text; they also include graphics files, binaries, and any other data you might send. All cryptosystems have three main purposes: to maintain integrity and confidentiality and to ensure nonrepudiation. Integrity means that the message has not been tampered with. Confidentiality means that the message can only be read by the intended audience. And nonrepudiation means that the author cannot later claim that he or she didn't write that message.

Older ciphers relied on a single key, and if you had the key, you could both encrypt and decrypt messages. (You might have had to jump through a lot of hoops to transform the message, as with the Enigma engine that drove the Allies nuts during World War Two, but the key made it possible.) A typical example is any code that requires a key or a password. The one−time message pads popularized in spy movies are archetypal single−key ciphers.

Unlike single−key ciphers, public−key (or asymmetric) encryption systems use two keys: both a private and a public one. Messages are encrypted with one key and decrypted with the other. (The mathematics to explain this are really quite hairy, but it does work—the system is based upon the behavior of really, really, really large numbers.) Generally, the key owner keeps the private key secret, but the public key is handed out to the world at large, for anyone's use. The key owner uses the private key, while everyone else uses the public key. The key owner can encrypt messages that anyone can open, while anyone in the public can send a message that only the key owner can read.

Public−key cryptography fills our need for integrity, confidentiality, and nonrepudiation nicely. If an author wants anyone to be able to read his message, while ensuring that it isn't tampered with, he can encrypt the message with his private key, and anyone with the public key can decrypt and read

298

the message. (Tampering with the encoded message would render it illegible.)

Encrypting messages this way also guarantees that the author has the private key. If an author wants to send a message that can only be read by its intended reader, she can encrypt it with the reader's public key, but only the person with the matching private key can read it.

This system works well as long as the private key is kept private. Once that private key is stolen, lost, or made public, it's useless. A careless person who has his private key stolen could even find others signing documents for him. Be careful with your keys, unless you want to learn that someone used your certificate to order half a million dollars' worth of high−end graphics workstations and have them overnighted to an abandoned−house maildrop on the other side of the country![1]

Note Absolute BSD is not an in−depth guide to cryptography. Much of what's in here is a generalization. If you're really, really interested in crypto, check out Bruce Schneier's Applied Cryptography (John Wiley & Sons). Bring a calculator, and a spare brain to use when yours fills up.

Certificates

One interesting note about public−key encryption is that the author and the audience don't have to be people—they can be programs. SSH, the Secure Sockets Layer (SSL) portion of Apache, which is the secure POP3 service, uses public−key encryption, as do many other programs. Public−key cryptography is a major component of the signed certificates used by secure Web sites. When you open Netscape to buy something online, you might not realize that the browser is frantically encrypting and decrypting Web pages behind the scenes. This is why your computer might complain about "invalid certificates"; someone's public key has either expired or has gone bad. (We'll learn more about how to use certificates in Chapter 14 and 15.)

Many companies, such as VeriSign, provide a public−key signing service. These companies are called Certificate Authorities (CAs). Other companies that need a certificate signed provide proof of their identity (such as corporate papers and business records), and these public−key signing companies use their certificate to sign the company's certificate. By signing the certificate, the Certificate Authority says, "I have inspected this person's credentials, and he (or she, or it) is who he claims he is." But they're not guaranteeing anything else: The person can use the certificate to build a Web site that sells fraudulent or dangerous products, or could even use it to encrypt a ransom note. Signed certificates guarantee certain types of technical security, not personal integrity or even unilateral technical security. If someone breaks into the server, you're still in trouble.

Web browsers and other certificate−using software include certificates for the major CAs. When the browser receives a certificate signed by a Certificate Authority, it accepts the certificate. Essentially, the Web browser says, "I trust the Certificate Authority, and the Certificate Authority trusts this company, so I will trust this company." So long as you trust the certificate authority, the process works.

Create a Request

To get a certificate to secure one of your server programs, you need to generate a certificate request. You then submit this request to a central Certificate Authority for signing. The request itself is fairly simple. While the command line is long, you just need to answer a few questions. (Since you will use these commands only once, we won't dissect them; see openssl(1) for more details, if you're interested).

299

Note Your certificate request must be treated as secret because a hacker can use this as a stepping−stone into your network. Be sure that the file can only be read by root!

Let's walk through a certificate request. Enter this verbatim:

...............................................................................................

# openssl req −new −nodes −out req.pem −keyout cert.pem

...............................................................................................

In response you should see this:

Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key

.................++++++

...++++++

writing new private key to 'cert.pem'

−−−−−

You are about to be asked to enter information that will be incorporated into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank

For some fields there will be a default value, If you enter '.', the field will be left blank.

−−−−−

Country Name (2 letter code) [AU]:US

State or Province Name (full name) [Some−State]:MI

...............................................................................................

Enter the two−letter code for the country and state or province you live in (US and MI, respectively, in this example), as shown in bold here. If you don't know the two−letter codes, ask someone who leaves the server room on occasion. (They are also defined in the ISO 3166 standard, so a quick Web search will find it.)

...............................................................................................

Locality Name (eg, city) [ ]:Detroit

...............................................................................................

A simple city name is sufficient for the Locality. If you're in a branch office, you might want to use the city where your headquarters is located.

...............................................................................................

Organization Name (eg, company) [Internet Widgits Pty Ltd]:BlackHelicopters Foundation

Organizational Unit Name (eg, section) [ ]:Network Support

...............................................................................................

The preceding requests are for your company name and the department you're from. If you don't have a company (I don't), just make something up.

...............................................................................................

Common Name (eg, YOUR name) [ ]:magpire.blackhelicopters.org

...............................................................................................

The preceding line is the part that trips up most administrators. The "YOUR" in the text means the server's name, not the admin's name. If you don't put a server name here, the request will be useless.

...............................................................................................

300

Email Address [ ]:mwlucas@blackhelicopters.org

...............................................................................................

Since this is a personal certificate for my own Web server, I don't need to worry about the email address. If this request is for a company, put a generic corporate address here, like webmaster@AbsoluteBSD.com.

...............................................................................................

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password [ ]:RodentsRule

...............................................................................................

This challenge password is also known as a passphrase. Again, this needs to be a secret, because anyone with your passphrase can masquerade as you! The passphrase here isn't a very good one; it doesn't have any non−alphanumeric characters, such as dashes, commas, or exclamation points, and it doesn't even have any numbers mixed in with it. For your real certificate requests (or anything on your network), please use a password that sucks less than this.

...............................................................................................

An optional company name [ ]:

...............................................................................................

By this time you've filled in quite enough company names, I'm sure, so just press ENTER. After doing so, you'll find a file req.pem in your current directory. It should look something like this:

...............................................................................................

−−−−−BEGIN CERTIFICATE REQUEST−−−−− MIICIDCCAYkCAQAwgcAxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNSTEQMA4GA1UE BxMHRGV0cm9pdDEkMCIGA1UEChMbQmxhY2tIZWxpY29wdGVycyBGb3VuZGF0aW9u MRgwFgYDVQQLEw9OZXR3b3JrIFN1cHBvcnQxJTAjBgNVBAMTHG1hZ3BpcmUuYmxh Y2toZWxpY29wdGVycy5vcmcxKzApBgkqhkiG9w0BCQEWHG13bHVjYXNAYmxhY2to ZWxpY29wdGVycy5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANCjXf0h WX/nlKb5Sc9m7Nofvc3Nck5j7XzNnd50UIc93Jj+Egw/KnlrniptpNicvqzQJ6zs 7jOk1uMUMbHfllxU0UtRGfLthCvfstB40ZzdMYUAfAT1r15i7fnaCRagshekel0h deadbeefTCk6mC7OYcsGuqrVuQkEcA/kPDxdAgMBAAGgHzAdBgkqhkiG9w0BCQcx EBMOR2VyYmlsc0FyZUNvb2wwDQYJKoZIhvcNAQEEBQADgYEAwC7lNqZbHFKaOjiw h35gU6TAC8NE0DRLuEulLWClEIPsTK6HHV7KU4uOq42HEunf61dpPaPkG03htoeu y0c5Rjk9F11cvRbBjpajv+T1lxTBGveuhatsn43d9Epi3glrcpueisd87LMxtnht OBf9nz6GaH+2o2BsGxwH3yws5o0=

−−−−−END CERTIFICATE REQUEST−−−−−

...............................................................................................

You'll also find a cert.pem file that looks much like this:

...............................................................................................

−−−−−BEGIN RSA PRIVATE KEY−−−−− MIICXAIBAAKBgQDQo139IVl/55Sm+UnPZuzaH73NzXJOY+18zZ3edFCHPdyY/hIM Pyp5a54qbaTYnL6s0Ces7O4zpNbjFDGx35ZcVNFLURny7YQr37LQeNGc3TGFAHwE 9a9eYu352gkdSbY5YlPr+7K63bRkskwpOpguzmHLBrqq1bkJBHAP5Dw8XQIDAQAB AoGAO8olXC4bdOELo5IbCdmoFJY2EW1HzZkrbLGMBTz1+tvKhPmCeIn9hRBHIkeL jxvUNLfuNssrNBeQEUEvQJcfgk+QW8zq5UV6xin7Rb1JYu+1TzyBt1QMAx99cDEq WW0oqvYIz1IzQq6FA5/J93Kj3yJ7I6NOCs8c9BxYvnjd6WECQQD0ARUKZhwLD7gQ HM3aIMXV7h0nzqj1Ygz2Rw/GEj+eWiam9NDlxIjqCuXAp34rDcyp++ZFX8flOJQ+ yHOt7625AkEA2uUvUhob0vTAFBofrFHigRQRD8YFDbXIPLtrXxqAmuD1SyABBgBy yGpsmXwdBP/lxR1xu4n+Mu2KVPiNZpZ1xQJASlNGEHvYEPqBy86qWcZf3PGCSgzm ZJCweBhfUqteW6MEYRjzxPmf5wLYx119zimO7TyBASLS5hzc817l9daraQJBAJ6B 8YdRcq6LHwAvfpoI3a08u7IhYY1xAiPAT9sZVOFSXy3cagFPl867ChMGxfjV2Suo y6/TGCkGy/IF3lbYQ0UCQGABvzCfcw3/xVY7co6k8kSu1Mf1dj/MYZh0oI7qrbUN

301