Start with a minimal installation of &TCD;, bootup the operating system, and login as root user. The ppp server provides the software required to establish and maintain a PPP link with another system and negociate Internet Protocol addresses for each end of the link. yum install ppp The name server provides the software required to translate domain names into IP address and IP addresses into domain names. With this software you can rembember addresses like instead of addresses like . There are other feautres (e.g., mail exchanger resolution, zone delegation, etc.) provided by this software that aren't used in the point-to-point configuration we describe in this chapter. yum install bind There is a bind-chroot packages, however, we aren't using it because SELinux is already enforced on the &TCD; filesystem and it provides far more security than the idea of bind-chroot package itself does. The mail server provides the software required to let you send/receive e-mail messages to/from others. The mail server is splitted in three basic components: The Mail Transfer Agent (postfix), The Mail Delivery Agent (Cyrus-Imapd) and an intermediary daemon named saslauthd to handle users' authentication. The mail transfer agent is the program your e-mail client sends e-mail messages to. The mail delivery agent, on the other hand, is the program your e-mail client reads e-mail message from (i.e., this is the place where your mailbox is stored in). The authentication daemon is used by the mail delivery agent to authenticate user's credentials (e.g., the information that let you access an specific mailbox). The authentication daemon can also be used by the mail transfer agent to authenticate users before sending mail to it, however, that is not set in this configuration (i.e., the mail transfer agent will receive mail from all its interfaces which are sent either to example.com domain name or server.example.com host name). yum install postfix cyrus-{imapd{,-utils},sasl{,-ldap,-md5,-plain}} By default, the sendmail program is used as mail transfer agent, not postfix. For the sake of that point-to-point configuration we are implementing, I decided to use postfix instead as default mail transfer agent, not sendmail. To effectively achieve this decition, it is required to use the alternatives command, as it shown below: alternatives --config mta This command will present you a menu to chose between available mail transfer agents, so it is there where you choose to use posfix as default option. Now that you've changed postfix the default mail transfer agent, you can saftly remove the sendmail package to avoid unused software to remain inside the computer. To do this, you can run the following command: yum remove sendmail In addition to mail server specific packages, we also provide mailing list support. Mailing lists provide e-mail addresses that users registered inside the ISP can write to. When you sed an e-mail to a mailing list, your message is distributed to all members of that list. In order for this to happen, people registered inside ISP need to subscribe themselves into that mailing list they want to receive messages from. The subscription of mailinglist will be available through a secured web application in the following url: yum install mailman The web server provides the software required to support web interfaces like those one previously mention to register new users inside the ISP and subscribe mailing lists. The web server provided in this configuration will accept requests both unencrypted and encrypted. yum install httpd mod_ssl crypto-utils In addition to mailing lists support, the web server will provide access to Subversion. Subvesion provides a way to manage files through version control. The main purpose of providing Subversion support here is sharing the version of &TCAR; I've been working on. yum install subversion mod_dav_svn The directory server provides the software required to unify user information. This server is access by other server whenever user information is required. You, as end user, can also use this server from your workstation to retrive a list of all users registered in the ISP. This list can be retrived by the web interface the ISP provides, or any application your workstation provide (e.g., most e-mail clients provide a way to configure LDAP servers to build address book from it.). yum openldap-servers python-ldap Once all required packages have been installed inside the server computer, it is time to configure them. This section describes how to configure the server computer to provide a public mail system. /etc/sysconfig/network-scripts/ifcfg-eth0 # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. TYPE=Ethernet DEVICE=eth0 HWADDR=00:1c:c0:f0:aa:05 BOOTPROTO=none NETMASK=255.255.255.0 IPADDR=192.168.0.1 ONBOOT=yes USERCTL=no IPV6INIT=no PEERDNS=yes This configuration specifies the way the server computer will handle incoming dial-up connections. /etc/ppp/options # Set the name of the local system for authentication purposes to # name. This is a privileged option. With this option, pppd will use # lines in the secrets files which have name as the second field when # looking for a secret to use in authenticating the peer. In # addition, unless overridden with the user option, name will be used # as the name to send to the peer when authenticating the local system # to the peer. (Note that pppd does not append the domain name to # name.) name "server.example.com" # Require the peer to authenticate itself before allowing network # packets to be sent or received. This option is the default if the # system has a default route. If neither this option nor the noauth # option is specified, pppd will only allow the peer to use IP # addresses to which the system does not already have a route. auth # Specifies that pppd should create a UUCP-style lock file for the # serial device to ensure exclusive access to the device. By default, # pppd will not create a lock file. lock # If pppd is acting as a server for Microsoft Windows clients, this # option allows pppd to supply one or two DNS (Domain Name Server) # addresses to the clients. The first instance of this option # specifies the primary DNS address; the second instance (if given) # specifies the secondary DNS address. (This option was present in # some older versions of pppd under the name dns-addr.) ms-dns 192.168.0.1 # Allow peers to connect from the given telephone number. A trailing # ‘*’ character will match all numbers beginning with the leading # part. Notice that this option (allow-number) is useful only to # incoming calls. When you want to realize an outgoing call, this # restrictions must be commentted out. ##### centos-pppd-admin will overwrite this part!!! (begin) ##### ##### centos-pppd-admin will overwrite this part!!! (end) ##### # Enable connection debugging facilities. If this option is given, # pppd will log the contents of all control packets sent or received # in a readable form. The packets are logged through syslog with # facility daemon and level debug. This information can be directed to # a file by # setting up /etc/syslog.conf appropriately (see syslog.conf(5)). debug # Terminate the connection when it has been available for network # traffic for 900 seconds (i.e. 15 minutes after the first network # control protocol comes up). maxconnect 900 # Specifies that pppd should disconnect if the link is idle for 60 # seconds (e.g., 1 minute). The link is idle when no data packets (i.e. # IP packets) are being sent or received. Note: it is not advisable # to use this option with the persist option without the demand # option. If the active-filter option is given, data packets which are # rejected by the specified activity filter also count as the link # being idle. idle 60 /etc/ppp/cha-secrets /etc/ppp/pap-secrets # client server secret IP addresses # Specify the client configuration. This is when this manchine calls # someone's else machine and tries to establish a point-to-point # connection. Most of this configuration is handled by the # `system-config-network' utility. # ####### redhat-config-network will overwrite this part!!! (begin) ########## ####### redhat-config-network will overwrite this part!!! (end) ############ # Specify the server configuration. This is when someone's else # machine calls this machine trying to establish a point-to-point # connection. This part of the configuration isn't handled by # `system-config-network' utility. To prenvent this configuration to # be lost the next time the `system-config-network' utility be used, # be sure to have this configuration backed up somewhere so it can be # resotred in such situations. # "client.example.com" "server.example.com" "mail4u" "192.168.0.2" /etc/named.conf # BIND DNS server 'named' configuration file for the Red Hat BIND # distribution. This file was initially taken from # `/usr/share/doc/bind-*/samples/named.conf' file and modified to fit # this server's needs. # # This machine exists to develop The CentOS Project Corporate Identity # through The CentOS Artwork Repository. Presently, this machine is # isolated from Internet. However, a modem has been attached[1] and # configured so people can establish point-to-point connections to # this machine and download working copies of The CentOS Artwork # Repository and help me to develop it. # # In this configuration there are only two IP addresses involved. The # one used in this server (192.168.0.1) and another for the client who # realize the point-to-point connection (192.168.0.2). This server is # named `server.example.com' and the client `client.example.com' or # something similar. # -------------------------------------------------------------------- # See the BIND Administrator's Reference Manual (ARM) for details, in: # file:///usr/share/doc/bind-*/arm/Bv9ARM.html # # Also see the BIND Configuration GUI: # /usr/bin/system-config-bind and its manual. # -------------------------------------------------------------------- options { # Those options should be used carefully because they disable port # randomization. // query-source port 53; // query-source-v6 port 53; # Put files that named is allowed to write in the data/ directory: directory "/var/named"; // the default dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; }; logging { # If you want to enable debugging, eg. using the 'rndc trace' # command, named will try to write the 'named.run' file in the # $directory (/var/named). By default, SELinux policy does not # allow named to modify the /var/named directory, so put the # default debug log file in data/ : channel default_debug { file "data/named.run" versions 5 size 20m; severity dynamic; }; }; # All BIND 9 zones are in a "view", which allow different zones to be # served to different types of client addresses, and for options to be # set for groups of zones. By default, if named.conf contains no # "view" clauses, all zones are in the "default" view, which matches # all clients. If named.conf contains any "view" clause, then all # zones MUST be in a view; so it is recommended to start off using # views to avoid having to restructure your configuration files in the # future. view "internal" { # This view will contain zones you want to serve only to # "internal" clients that connect via your directly attached LAN # interfaces - "localnets". match-clients { 192.168.0/24; }; match-destinations { 192.168.0/24; }; recursion no; # All views must contain the root hints zone. However, since this # machine is disconnected from Internet it is not possible for it # to reach root servers. So, this line is commented based that no # recursion is performed here. //include "named.rfc1912.zones"; # These are your "authoritative" internal zones, and would # probably also be included in the "localhost_resolver" view # above: zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; }; zone "0.168.192.in-addr.arpa" IN { type master; file "example.com.rr.zone"; allow-update { none; }; }; }; # The localhost_resolver is already configured in `/etc/hosts' and set # as first choise in `/etc/hosts.conf' file. However, if you change # the order in `/etc/hosts.conf' file to make bind the first choise, # then you need to include here the localhost_resolver in order to # resolve localhost (127.0.0.1) address. key "rndckey" { algorithm hmac-md5; secret "JjsCg0VcCjZILGD8FR9nnw=="; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndckey"; }; }; /var/named/example.com.zone $ORIGIN example.com. $TTL 86400 @ IN SOA example.com. hostmaster.example.com. ( 2011100404 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS dns.example.com. IN MX 10 mail.example.com. server IN A 192.168.0.1 client IN A 192.168.0.2 dns IN CNAME server mail IN CNAME server www IN CNAME server /var/named/example.com.rr.zone $ORIGIN 0.168.192.in-addr.arpa. $TTL 86400 @ IN SOA example.com. hostmaster.example.com. ( 2011100405 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS 192.168.0.1 1 IN PTR server.example.com. 2 IN PTR client.example.com. /etc/rndc.conf include "/etc/rndc.key"; options { default-key "rndckey"; default-server 127.0.0.1; default-port 953; }; /etc/rndc.key key "rndckey" { algorithm hmac-md5; secret "JjsCg0VcCjZILGD8FR9nnw=="; }; When configuring rndc controls, don't use the same secret shown in the example above. If you do so, the secret information will not be a secret anymore (since we already used it here). Instead, use the rndc-genconf command to generate a new one, and be sure it be placed correctly both in /etc/rndc.conf and /etc/named.conf configuration files. /etc/resolv.conf nameserver 192.168.0.1 /etc/host.conf order hosts,bind At this point you can start the named service and realize some tests to verify the named service is certainly working as expected. For example, consider the the following two commands: [root@server ~]# service named start Starting named: [ OK ] [root@server ~]# dig example.com mx ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> example.com mx ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3540 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN MX ;; ANSWER SECTION: example.com. 86400 IN MX 10 mail.example.com. ;; AUTHORITY SECTION: example.com. 86400 IN NS dns.example.com. ;; Query time: 0 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Wed Oct 5 10:33:24 2011 ;; MSG SIZE rcvd: 67 If everything is ok, configure the named service to start at boot time: chkconfig --level 345 named on If something goes wrong, look for named daemon entries inside the /var/log/messages file to know what is going on. When you are configuring the name server, it could result useful to you keeping an always visible terminal, running the following command on it: grep named /var/log/messages | tail -f - Based on default configuration provided by Postfix RPM inside &TCD; (release 5.5), look for the following options and leave the rest as is. /etc/postfix/main.cf myhostname = server.example.com mydomain = example.org inet_interfaces = $myhostname, localhost mynetworks = 192.168.0.0/24, 127.0.0.0/8 mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp local_destination_recipient_limit = 300 local_destination_concurrency_limit = 5 /etc/cyrus.conf Leave it as is. There is nothing to touch here for a small and basic configuration like that one we are implementing in this chapter. /etc/imapd.conf Leave it as is. There is nothing to touch here for a small and basic configuration like that one we are implementing in this chapter. The initial configuration of Cyrus IMAP server is set to use PLAIN authentication mechanisim (see sasl_mech_list option) against saslauthd daemon. This makes the password information to be vulnerable for man in the middle attacks. In order to protect the user authentication, you can use other authentication mechanisms like CRAM-MD5 or DIGEST-MD5 in the e-mail client in order to send the password information encrypted. Another solution would be to create an encrypted channel for communication between the e-email client and Cyrus IMAP server by mean of SSL encryption. When you use authentication mechanisms that encrypt user information before passing them to saslauthd daemon (e.g., DIGETS-MD5), you are protecting your data in the e-mail client before passing it to saslauthd daemon. Therefore, when the saslauthd daemon tries to validate the credentials you passed in against PAM, it fails. At my personal understanding, this happens becase PAM must receive the user information as it was entered by the user (i.e., plainly, without any encryption) in order to realize the verification against the system default authentication database (e.g., /etc/passwd, /etc/shadow), and saslauthd daemon is passing an encrypted version of the plain user information which obviously cannot match the hash produced by plain user information in first place. One alternative to the situation mentioned above could be to use PLAIN authentication mechanism over an SSL encrypted communication or excluding PAM mechanism from saslauthd daemon, and use LDAP mechanism instead. When LDAP mechanism is used as default authentication mechanism inside saslauthd daemon, it is possible for e-mail clients to send encrypted passwords to saslauthd daemon. In this configuration, the password stored in LDAP server must be encrypted using the same algorithm used to send the encrypted password from e-mail client to saslauthd daemon. Therefore, you need to force the user to use just one authentication mechanism, that one used to stored encrypted passwords inside the LDAP server. Otherwise, it would be very difficult to authenticate users that send passwords encrypted in a way different to that one stored in the LDAP server. Another configuration could be to keep e-mail clients using PLAIN authentication over an SSL connection against saslauthd daemon, and saslauthd using a PAM. But this time, PAM would be configured to extend its default system authentication by using an LDAP server. This way, it would be possible to isolate user accound administration and greatly control the kind of information a user might have. For example, the root user account would be in the system default authentication, however all service-specific user information would be in the LDAP server. This permits us to create a web application that interact with LDAP server in order to manage service-specific user information only avoiding any contant with system default authentication, the place where the root user is stored in. In this PAM configuration, the first match that fails means that the whole authentication process fails. /etc/pki/cyrus-imapd/cyrus-imapd.pem This file is a symbolic link to /etc/pki/tls/certs/cyrus-imapd.pem. This file contains a self-generated SSL certificate you probably want to update for setting your host name in the Common Name field of it. To create this file use the following command: openssl req -new -x509 -nodes -out /etc/pki/tls/certs/cyrus-imapd.pem -keyout /etc/pki/tls/certs/cyrus-imapd.pem -days 365 To initiate the Cyrus IMAP server, run the following command: service cyrus-imapd start In case something fails, look into the /var/log/maillog file, specifically those entries containing imap, pop, nntp and cyrus strings. It could be useful if, before initiating Cyrus IMAP server, you open a terminal and run the following command in it, just to see what is happening once Cyrus IMAP server is initiated: egrep '(cyrus|imap|pop)' /var/log/maillog | tail -f - Later, to test the STARTTLS negociation, you can run the following command: imtest -t "" server.example.com To administer mailboxes inside Cyrus Imapd, set a password to cyrus user (e.g., passwd cyrus), do login with it, and connect to Cyrus IMAP server using the cyradm command, as shown below: cyradm --user=cyrus --auth=login localhost ... ... ...