Tải bản đầy đủ - 0 (trang)
15 Troubleshooting a POP3, POP3s, or IMAP Server

15 Troubleshooting a POP3, POP3s, or IMAP Server

Tải bản đầy đủ - 0trang

This should spew forth bales of SSL certificate information so you can verify that it is

indeed using your SSL certificate, and using the right one. Then, you can go ahead

and run the usual POP3 commands:

+OK Hello there.

user carla

+OK Password required.

pass password

+OK logged in.



Once you have successfully connected directly on the server, try logging in from a

remote PC:

$ telnet xena.alrac.net 110

$ openssl s_client -connect xena.alrac.net:995



IMAP can also be tested with telnet and openssl s_client:

$ telnet localhost 143

Trying 127.0.0.1...

Connected to localhost.localdomain.

Escape character is '^]'.

* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT

THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready.

a001 login carla password

a001 OK LOGIN Ok.

a002 examine inbox

* FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)

* OK [PERMANENTFLAGS ( )] No permanent flags permitted

* 0 EXISTS

* 0 RECENT

* OK [UIDVALIDITY 1085106842] Ok

* OK [MYRIGHTS "acdilrsw"] ACL

a002 OK [READ-ONLY] Ok

a003 logout

* BYE Courier-IMAP server shutting down

a003 OK LOGOUT completed

Connection closed by foreign host.

$ openssl s_client -connect localhost:993

[...]



Following along with tcpdump as you run your other tests is helpful:

# tcpdump -pi eth0 port 110



And always check logfiles.



Discussion

To exit a telnet session early, hit Ctrl-], then Q.

Why use telnet? Because it can talk directly to the server, and find out quickly if the

server is operating correctly. Bypassing intermediaries is always a good first step.



550



|



Chapter 19: Troubleshooting Networks



Follow the previous recipe to send yourself some messages from your SMTP server

and see if your POP3 server receives them. If they are on the same machine, and the

POP3 server does not receive the messages, then you know you have a configuration

problem. If they are on separate machines, then it could be either a connection problem, or a configuration problem. Always make sure your servers are operating

correctly before looking for other problems.

Some admins think that operating behind a NAT firewall excuses them from paying

close attention to access controls on their internal servers. This is not good thinking—always restrict your server access controls as narrowly as possible.



See Also

• RFC 1939 lists all POP3 commands

• RFC 3501 lists all IMAP commands

• Recipe 19.7

• Recipe 19.10

• Chapter 20, “Building a Postfix Mail Server,” and Chapter 21, “Managing Spam

and Malware,” in Linux Cookbook, by Carla Schroder (O’Reilly)

• man 1 telnet



19.16 Creating SSL Keys for Your Syslog-ng Server on

Debian

Problem

You want to set up a secure Syslog-ng server, and you know you need stunnel and

OpenSSL to do this. Creating and managing OpenSSL certificates makes you break

out in a rash—it’s confusing, and it always takes you too long. Isn’t there some kind

soul who will show you the way? You’re running Debian, or one of its descendants,

or pretty much any Linux except Fedora or Red Hat.



Solution

Just follow along, and you’ll be fine. What we’re going to do is create an OpenSSL

Certification Authority, and server and client encryption keys to use with stunnel.

stunnel provides the transport for our Syslog-ng traffic, and OpenSSL does the

encryption and authentication.

You should have OpenSSL already installed; if not, you know what to do.

We’ll take this slowly because managing SSL certificates is confusing, and stunnel

complicates matters by requiring a special keyfile format.



19.16



Creating SSL Keys for Your Syslog-ng Server on Debian |



551



Although stunnel is going to use these certificates, I’m naming them “syslog-ng*”

because they’re for authenticating Syslog-ng traffic. We will create the Certificate

Authority (CA) and public-/private-key pairs in the /etc/syslog-ng/ directory on the

server. After they are created, I’ll store them in /etc/syslog-ng/keys on the server and

the clients. Wherever you want to keep your stuff, first make sure that the directories exist.

Now, find your CA.sh script, which is part of OpenSSL, and edit these two lines:

DAYS="-days 3650"

CATOP=./syslog-ng-CA



# 10 years



The default lifetime of your new Certificate Authority (CA) is one year, so adjust this

to suit. CATOP is the top-level directory of your new CA.

Now, edit openssl.cnf so that the top-level directory for the CA and number of

default days agree with CA.sh:

[ CA_default ]

dir

= ./syslog-ng-CA

# Where everything is kept

[...]

default_days

= 3650

# how long to certify for



And, edit your personal information:

countryName_default

= US

stateOrProvinceName_default

= OR

0.organizationName_default

= Alrac's Fine Hooves



Make sure these lines are commented out:

[ req_attributes ]

#challengePassword

#challengePassword_min

#challengePassword_max

#unstructuredName



= A challenge password

= 4

= 20

= An optional company name



Now, let’s change to the SSL certificate-creation directory:

# cd /etc/syslog-ng



Create the new CA:

# /usr/lib/ssl/misc/CA.sh -newca

CA certificate filename (or enter to create)



Hit Enter:

Making CA certificate ...

Generating a 1024 bit RSA private key

..++++++

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

writing new private key to './syslog-ng-CA/private/./cakey.pem'



Create a good strong passphrase, and don’t lose it—you need it every time you create a new key pair:



552



|



Chapter 19: Troubleshooting Networks



Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

----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) [US]:

State or Province Name (full name) [OR]:

Locality Name (eg, city) []:Portland

Organization Name (eg, company) [Alracs Fine Hooves]:

Organizational Unit Name (eg, section) []:HoofRanch

Common Name (eg, YOUR name) []:syslog-ng

Email Address []:alrac@hoofranch.net



You need the passphrase you just created:

Enter pass phrase for ./syslog-ng-CA/private/./cakey.pem:

Check that the request matches the signature

Signature ok

Certificate Details:

Serial Number: 0 (0x0)

Validity

Not Before: Jul 16 19:05:29 2007 GMT

Not After : Jul 15 19:05:29 2010 GMT

Subject:

countryName

= US

stateOrProvinceName

= OR

organizationName

= Alrac's Fine Hooves

organizationalUnitName

= HoofRanch



Use the fully qualified domain name of your server for the common name, or clients

will emit complaints:

commonName

= xena.alrac.net

emailAddress

= alrac@hoofranch.net

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Comment:

OpenSSL Generated Certificate

X509v3 Subject Key Identifier:

27:F4:BE:F9:92:8A:2B:84:8F:C7:C8:88:B9:4E:8A:A7:D9:3F:FE:93

X509v3 Authority Key Identifier:

keyid:27:F4:BE:F9:92:8A:2B:84:8F:C7:C8:88:B9:4E:8A:A7:D9:3F:FE:93

Certificate is to be certified until Jul 15 19:05:29 2010 GMT (1095 days)

Write out database with 1 new entries

Data Base Updated



19.16



Creating SSL Keys for Your Syslog-ng Server on Debian |



553



You should see /etc/syslog-ng/syslog-ng-CA populated with a number of files and subdirectories.

Now, we will create the server and client key pairs. In this example, the server is

Xena and the client is Uberpc. First, we create the signing requests:

# openssl req -new -nodes -out syslogserver-xena_req.pem -keyout \

syslogserver-xena.pem

# openssl req -new -nodes -out uberpc_req.pem -keyout uberpc.pem



The next step is to sign the requests and create the new key pairs. First, the server:

# openssl ca -out syslogserver-xena_cert.pem -infiles \

syslogserver-xena_req.pem

Using configuration from /usr/lib/ssl/openssl.cnf

Enter pass phrase for ./syslog-ng-CA/private/cakey.pem:

Check that the request matches the signature

Signature ok

Certificate Details:

Serial Number: 1 (0x1)

Validity

Not Before: Jul 16 19:27:01 2007 GMT

Not After : Jul 13 19:27:01 2017 GMT

Subject:

countryName

= US

stateOrProvinceName

= OR

organizationName

= Alrac's Fine Hooves

organizationalUnitName

= HoofRanch

commonName

= xena.alrac.net

emailAddress

= alrac@hoofranch.net

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Comment:

OpenSSL Generated Certificate

X509v3 Subject Key Identifier:

96:DE:84:A1:55:46:78:55:54:B1:4F:B7:E3:CE:EB:26:5A:90:7F:EA

X509v3 Authority Key Identifier:

keyid:27:F4:BE:F9:92:8A:2B:84:8F:C7:C8:88:B9:4E:8A:A7:D9:3F:FE:93

Certificate is to be certified until Jul 13 19:27:01 2017 GMT (3650 days)

Sign the certificate? [y/n]:y



1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated



And then Uberpc:

# openssl ca -out uberpc_cert.pem -infiles uberpc_req.pem



OK, we’re almost there. You should now have these files:

syslogserver-xena_cert.pem

syslogserver-xena_req.pem



554



|



Chapter 19: Troubleshooting Networks



syslogserver-xena.pem

uberpc_cert.pem

uberpc_req.pem

uberpc.pem



You can delete the req.pem files because they’re not needed anymore. uberpc.pem

and syslogserver-xena.pem are the private keys. Never ever share these. They are

plaintext files, so you can open them and confirm that they say -----BEGIN RSA

PRIVATE KEY-----.

Open uberpc_cert.pem and copy the public certificate, which is the bit between:

-----BEGIN CERTIFICATE---------END CERTIFICATE-----



into a new file. You need to do this for every client—copy all of their public certificates into a single file on the Syslog-ng server, which in this recipe I call /etc/syslog-ng/

clientkeys.

Now, copy Uberpc’s public certificate into uberpc.pem, like this:

-----BEGIN RSA PRIVATE KEY----[encoded key]

-----END RSA PRIVATE KEY----[empty line]

-----BEGIN CERTIFICATE----[encoded certificate]

-----END CERTIFICATE----[empty line]



Delete all of the plaintext certificate information. Then, do the same thing to the

server’s key pair, because stunnel is fussy about the format, and it must be done this

way. So now, syslogserver-xena.pem and uberpc.pem contain their own public and

private keys, and nothing else.

Now, you can copy Uberpc’s keyfile into its permanent home:

# scp uberpc.pem root@uberpc:/etc/syslog-ng/keys/



If you have disabled root logins over SSH, I shall leave it to your own ingenuity to figure out how to transfer this file.

And do the same for the server:

root@xena:/etc/syslog-ng# scp syslogserver-xena.pem keys/



Finally, protect the private keys by changing them to mode 0400, or read-only by the

owner:

# chmod 0400 uberpc.pem

# chmod 0400 syslogserver-xena.pem



For every new client, follow these steps:

# openssl req -new -nodes -out newclient_req.pem -keyout newclient.pem

# openssl ca -out newclient_cert.pem -infiles newclient_req.pem



19.16



Creating SSL Keys for Your Syslog-ng Server on Debian |



555



• Concatenate the private and public key into a single file

• Copy the keyfile to the new client

• Adjust the permissions

• Copy the public certificate to the server

Well, that was a bit like work. But now you know how to do it.



Discussion

Of course, you have the option of not encrypting your Syslog-ng traffic; it will work

fine without it. You know that it is trivially easy to sniff traffic on a network with

commonly available tools, and any network with wireless access points is extravulnerable, so leaving it in the clear is risky.

I like to use the CA.sh script to create the Certificate Authority because it takes care

of the gnarly job of creating all the necessary files. You can use it to create several different types of certificates, but it’s almost as easy to use the openssl command, which

has more flexibility. The CA.pl script does the same thing, except it’s a Perl script

instead of a Bash script.

This is what the options mean in the signing request:

req -new -nodes



Create a new signing request for a private key, with no passphrase.

-out



The out filename, or name of your new signing request. This can be anything

you want, as long as you use the .pem extension.

-keyout



The name of your new private key.

This is what the options mean when you sign the private keys:

ca -out



Use your CA to sign a new private key, and give it the name of your choice.

-infiles



Use this signing request, which must be an existing file.

There is often confusion over keys and certificates. A certificate binds a public key

with a distinguished name. Certificates are signed with the issuer’s private key, and

each one is given a serial number. You can see all this in the example in this recipe,

and in your own certificates. All kinds of encryptions and hashes are used to verify

that a particular public key did indeed come from a particular CA.

If you trust the issuer, then presumably, you can trust all keys created from the same

CA. Private CAs are perfect for jobs like this—we know who we are, so we don’t

need a third-party CA to vouch for us.



556



|



Chapter 19: Troubleshooting Networks



See Also

• man req

• man ca

• man openssl

• Network Security with OpenSSL, by John Viega et al. (O’Reilly)



19.17 Creating SSL Keys for Your Syslog-ng Server on

Fedora

Problem

You want to set up a secure Syslog-ng server, and you know you need stunnel and

OpenSSL to do this. OpenSSL on Fedora doesn’t look like OpenSSL on any other

Linux distribution—where is everything? No CA.sh or CA.pl, it uses the /etc/pki

directory, and it just looks all weird. What do you do?



Solution

Calm down, because Fedora has a nice Makefile for creating your Public Key Infrastructure (PKI) for stunnel. In fact, it is very easy. Change to its directory, and run it

with no options to see what it does:

# cd /etc/pki/tls/certs

# make

This makefile allows you to create:

0 public/private key pairs

0 SSL certificate signing requests (CSRs)

0 Self-signed SSL test certificates

[...]



Create the server and one client certificate like this:

# make syslogserver-xena.pem

# make uberpc.pem



Use the fully qualified domain name of your server for the common name, or clients

will emit complaints.

Open uberpc.pem and copy the public certificate, which is the bit between:

-----BEGIN CERTIFICATE---------END CERTIFICATE-----



into a new file. You need to do this for every client—copy all of their public certificates into a single file on the Syslog-ng server, which in this recipe I call /etc/syslog-ng/

clientkeys.



19.17 Creating SSL Keys for Your Syslog-ng Server on Fedora |



557



Now, you can copy Uberpc’s keyfile into its permanent home:

# scp uberpc.pem root@uberpc:/etc/syslog-ng/keys/



If you have disabled root logins over SSH, I shall leave it to your own ingenuity to figure out how to copy this file.

And do the same for the server:

root@xena:/etc/syslog-ng# scp syslogserver-xena.pem keys/



Finally, protect the private keys by changing them to mode 0400, or read-only by the

owner:

# chmod 0400 uberpc.pem

# chmod 0400 syslogserver-xena.pem



For every new client, follow these steps:

• Create a new, unique keyfile

• Copy the keyfile to the new client

• Adjust the permissions

• Copy the client’s public certificate to the server

And that’s all there is to it.



Discussion

Of course, you have the option of not encrypting your Syslog-ng traffic; it will work

fine without it. You know that it is trivially easy to sniff traffic on a network with

commonly available tools, and any network with wireless access points is extravulnerable, so leaving it in the clear is risky.

Fedora’s keyfiles are created by the Makefile in the exactly correct format for stunnel,

so you don’t have to muck around like you do on Debian.



See Also

• man req

• man ca

• man openssl

• Network Security with OpenSSL, by John Viega et al. (O’Reilly)



19.18 Setting Up stunnel for Syslog-ng

Problem

You have your SSL infrastructure set up, and now you want to configure stunnel to

use with your Syslog-ng server.



558



|



Chapter 19: Troubleshooting Networks



Solution

You’ll need to install stunnel on the clients and server. Install it on Debian with this

command:

# aptitude install stunnel4



On Fedora, use this command:

# yum install stunnel



Now, edit your server /etc/stunnel/stunnel.conf file to look like this. The cert names

come from the previous two recipes:

cert =

CAfile

client

verify

setgid

setuid



/etc/syslog-ng/syslogserver-xena.pem

= /etc/syslog-ng/clientkeys

= no

= 3

= stunnel4

= stunnel4



[syslog-ng]

#server address

accept = 192.168.1.50:5140

connect = 127.0.0.1:514



The stunnel4 user and group are created by the Debian installer. If your system does

not create an unprivileged user and group for stunnel, you should create them yourself:

# groupadd stunnel

# useradd -d /var/run/stunnel -m -g stunnel -s /bin/false stunnel



The stunnel client configuration file looks like this:

cert =

client

verify

setuid

setgid



/etc/syslog-ng/uberpc.pem

= yes

= 3

= stunnel4

= stunnel4



[syslog-ng]

accept = 127.0.0.1:514

#server address

connect = 192.168.1.50:5140



Now, you’re ready to move on to actually configuring Syslog-ng.



Discussion

This is as simple a setup as it is possible to use. By default, stunnel will listen on all

interfaces, so if that is the behavior you want, it’s not necessary to specify IP

addresses. You do need to list which ports you want it to listen to, so check /etc/

services for open ports, and enter the ones you are using.



See Also

• man 8 stunnel

19.18 Setting Up stunnel for Syslog-ng |



559



19.19 Building a Syslog Server

Problem

You want to have a central network logging server, but the mossy old Linux syslog

isn’t really up to the job. It’s OK for host logging, but it’s not as flexible as it could

be, and its remote logging capability is not built-in—it’s a bit of a hack job, really.

You want a modern log server that is designed for network logging, has encryption,

and that lets you fine-tune your settings.

You have your SSL certificates and stunnel all configured and ready to go, so now

you want to set up Syslog-ng itself.



Solution

Install Syslog-ng on Debian with this command:

# aptitude install syslog-ng



And on Fedora with this command:

# yum install syslog-ng



These will automatically remove the old syslog and set up a default configuration

that mimics a standard syslog installation.

You must install Syslog-ng, OpenSSL, and stunnel on all client hosts as well, so if you

haven’t done this yet, see the previous three recipes.

We don’t want to make a lot of changes to the existing /etc/syslog-ng/syslog-ng.conf

file, so let’s start with the options section on the Syslog-ng server:

options {

sync (0);

log_fifo_size (2048);

time_reopen(10);

time_reap(360);

create_dirs (yes);

perm (0640);

dir_perm (0750);

chain_hostnames(0);

use_dns(no);

use_fqdn(no);

};



Add these lines to the source section to tell Syslog-ng to listen for messages via

stunnel, and to give each remote host its own file in /var/log/hosts/:

source stunnel {tcp(ip("127.0.0.1")port(514) max-connections(1));};

destination d_clients {file("/var/log/hosts/$HOST/$DATE_$FACILITY"); };

log {source(stunnel); destination(d_clients);};



560



|



Chapter 19: Troubleshooting Networks



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

15 Troubleshooting a POP3, POP3s, or IMAP Server

Tải bản đầy đủ ngay(0 tr)

×