Migrate NIS users and groups into LDAP

yum install openldap-servers

cd /usr/share/openldap/migration

run the migration scripts

verify document signatures

Verify the signature
#gpg --output document --decrypt document.sig

sign documents

Sign the document
#gpg --output document.sig --sign document

decrypt documents

Decrypt a document

#gpg --output document --decrypt document.gpg

encrypt documents

To encrypt you will need to have the persons public key available to you so you can import it

#gpg --import public-key.gpg

Encrypt a document

#gpg --output document.gpg --encrypt --recipient username@example.com document

generate key pairs

Generate the key pairs using the following command
#gpg --gen-key

use the Real-time Blackhole List (RBL) via DNS

Sendmail

Edit /etc/mail/sendmail.mc and add

FEATURE(`dnsbl', `dnsbl.example.com', `you have been rejected mofo')dnl

#make -C /etc/mail

#service sendmail restart

Postfix

#postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_rbl_client dnsbl.example.com"

#service postfix restart

blackhole lists (RBL)

Blackhole list

blackhole { address_match_list };

blackhole defines a address_match_list of hosts that the server will NOT respond to, or answer queries for. The default is 'none' (all hosts are responded to). This statement may only be used in a global options clause.

Blackhole Zone

Create a new master zone called dnsbl.example.com and edit it so it looks like this


$TTL 1H
@       SOA     auth1.example.com.      root.auth1.example.com. (       2
                                                3H
                                                1H
                                                1W
                                                1H )
                IN      NS      auth1.example.com.
                IN      A       172.16.118.136
128.25.168.192  IN      A       127.0.0.2
                IN      TXT     "Spam MOFO"

Add entries like the one in red for all of the spam sources

filter mail based on message characteristics

Postfix

The following can be used for filtering
/etc/postfix/access
/etc/postfix/header_checks

Sendmail

use TLS for secure communication

You can use the ca created in configure a certificate authority (CA) and sign certificate requests

Postfix

Create the SSL directory

#mkdir /etc/postfix/ssl

##cd /etc/postfix/ssl

Create the Key and Request

#openssl req -new -nodes -keyout client.example.com.key -out mail.example.com.csr

Sign the Request

#cp mail.example.com.csr /etc/pki/tls/misc/newreq.pem

#cd /etc/pki/tls/misc/

#./CA.pl -sign

Copy cert to SSL dir

#cp  newcert.pem /etc/postfix/ssl/mail.example.com.crt

Copy the cacert

#cp /etc/pki/CA/cacert.pem ssl/

Use postconf to configure TSL settings

#postconf -e "smtpd_use_tls = yes"

#postconf -e "smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem"

#postconf -e "smtpd_tls_cert_file = /etc/postfix/ssl/mail.example.com.crt"

#postconf -e "smtpd_tls_key_file = /etc/postfix/ssl/mail.example.com.key"

Restart postfix

#service postfix restart

Sendmail

Install sendmail-mc
#yum install sendmail-mc -y

Create the SSL directory

#mkdir /etc/mail/ssl

##cd /etc/mail/ssl

Create the Key and Request

#openssl req -new -nodes -keyout client.example.com.key -out mail.example.com.csr

Update permissions on the key file
#chmod 400 mail.example.com.key

Sign the Request

#cp mail.example.com.csr /etc/pki/tls/misc/newreq.pem

#cd /etc/pki/tls/misc/

#./CA.pl -sign

Copy cert to SSL dir

#cp  newcert.pem /etc/mail/ssl/mail.example.com.crt

Update sendmail config
#cd /etc/mail

Edit sendmail.mc and add the following


define(`confCACERT_PATH', `/etc/mail/ssl')dnl
define(`confCACERT', `/etc/pki/CA/cacert.pem')dnl
define(`confSERVER_CERT', `/etc/mail/ssl/auth1.example.com.crt')dnl
define(`confSERVER_KEY', `/etc/mail/ssl/auth1.example.com.key')dnl

Update sendmail

#make -C .

Restart sendmail

#service sendmail restart

TSIG

Configure TSIG for zone transfers

On the master

Create the key
#dnssec-keygen -a HMAC-MD5 -b 128 -n HOST master-slave

Get the key value
#cat Kmaster-slave*key
master-slave. IN KEY 512 3 157 ts7byllvrX5r4Il3t177Ug==

Create a key file to include in named.conf
#vim master-slave.key


key master-slave {
        algorithm hmac-md5;
        secret ts7byllvrX5r4Il3t177Ug==;
};

Change the permissions on the file
#chmod 640 master-slave.key
#chown :named master-slave.key

Link to /etc if in chroot
#ln -s /var/named/chroot/etc/master-slave.key /etc/master-slave.key

Make sure the key has the correct context
#chcon master-slave.key --reference rndc.key

Update named.conf so that the key is included by adding the following
include "/etc/master-slave.key";

Configure the server to allow transfers using the key

allow-transfer { key master-slave; };

Restart the named service on the master
#service named restart

On the slave

Create a key file to include in named.conf
#vim master-slave.key


key master-slave {
        algorithm hmac-md5;
        secret ts7byllvrX5r4Il3t177Ug==;
};

Change the permissions on the file
#chmod 640 master-slave.key
#chown :named master-slave.key

Link to /etc if in chroot
#ln -s /var/named/chroot/etc/master-slave.key /etc/master-slave.key

Make sure the key has the correct context
#chcon master-slave.key --reference rndc.key

Update named.conf so that the key is included by adding the following
include "/etc/master-slave.key";

Add the master server in and configure to use the required key

server SERVERIP {

        keys master-slave;

};

Restart bind

#service named restart

Testing

You can use the dig command to test zone transfers

Without tsig

#dig @MASTERIP example.com axfr

With tsig

dig -y master-slave:ts7byllvrX5r4Il3t177Ug== @MASTERIP example.com axfr

master domain

Use /usr/share/doc/bind-*/sample/etc/named.conf to see examples of configuration

Install the bind packages
#yum install bind-chroot system-config-bind -y

Run the bind configuration utility which will create the config files for you.
#system-config-bind

Create a new master zone

configure httpd to use passwords and/or network location to restrict access to content

Install apache
#yum install httpd -y

#######################################################################
USING PASSWORDS TO RESTRICT ACCESS
#######################################################################

Edit the apache config

#vim /etc/httpd/conf/httpd.conf

<Directory "/var/www/html/protected">

    AllowOverride Authconfig

</Directory>

Create the protected area

#mkdir /var/www/html/protected
#echo "Only authorised personal can see this" > /var/www/html/protected/index.html

Use htpasswd to create an auth file
#htpasswd -c -m /var/www/userfile username

Create the following file with the following config
#vim /var/www/html/protected/.htaccess

AuthName "Access to protected area"
AuthType Basic
AuthUserFile /var/www/userfile
require valid-user

Restart apache

#service httpd restart

You should then be prompted when you try and access http://servername/protected

#######################################################################
USING NETWORK LOCATION TO RESTRICT ACCESS
#######################################################################

Edit the apache config

#vim /etc/httpd/conf/httpd.conf

Directory "/var/www/html/protected">

    Order allow,deny

    Allow from .example.com

    Deny from All

</Directory>

Restart apache

#service httpd restart

configure httpd to use a SSL certificate signed by a certifying authority

You will need to use the CA created using configure-certificate-authority-ca

Install apache and mod_ssl packages
#yum install httpd mod_ssl -y

Create a key
#openssl genrsa -out server.example.com.key 1024

Create a certificate signing request
#openssl req -new -key server.example.com.key -out server.example.com.csr

Sign the certificate with the CA
#cp server.example.com.csr /etc/pki/CA/newreq.pem
#/etc/pki/tls/misc/CA.pl -sign

Copy the signed cert somewhere into the /var/www tree somewhere or make sure that it has the correct security context
#mkdir /var/www/certs
#mv /etc/pki/CA/newreq.pem /var/www/certs/server.example.com.crt
#mv server.example.com.key /var/www/certs/server.example.com.key

Edit /etc/httpd/conf.d/ssl.conf

SSLCertificateFile /var/www/certs/server.example.com.cert
SSLCertificateKeyFile /var/www/certs/server.example.com.key

Restart apache
#service httpd restart

Test connection!

configure a certificate authority (CA) and sign certificate requests

Install the perl openssl package
# yum install openssl-perl

Change to the directory where the CA.pl script is located
# cd /etc/pki/tls/misc/

Create the CA
# ./CA.pl -newca

Make the CA Certificate available using http or some other method.

Configure POP/IMAP to use SSL/TLS for secure communication

This needs to be done after creating the certificate authority

#yum install dovecot -y

Edit /etc/dovecot.conf to allow on the protocols you require by changing the protocols value

Edit /etc/pki/dovecot/dovecot-openssl.cnf with the relevant information

Delete the old certificates

#rm /etc/pki/dovecot/private/dovecot.pem

#rm /etc/pki/dovecot/certs/dovecot.pem

Run the mkcert script
#/usr/share/doc/dovecot-1.0.7/examples/mkcert.sh

Restart dovecot
#service dovecot restart

Open the required ports on the firewall

ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:imaps
ACCEPT     udp  --  anywhere             anywhere            state NEW udp dpt:imaps
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:pop3s
ACCEPT     udp  --  anywhere             anywhere            state NEW udp dpt:pop3s

You can test this using mutt, copy the ca certificate to the .mutt directory in the users home directory and run mutt

#mutt -f imaps://user@server

Check the maillog of the server 

Sep  4 13:32:40 auth1 sendmail[6037]: q84KWdRd006036: to=<adam@auth1.example.com>, ctladdr=<root@auth1.example.com> (0/0), delay=00:00:01, xdelay=00:00:00, mailer=local, pri=30529, dsn=2.0.0, stat=Sent

Sep  4 13:34:02 auth1 dovecot: imap-login: Login: user=<user>, method=PLAIN, rip=::ffff:172.16.118.135, lip=::ffff: TLS

implement host based access restrictions

Use tcp wrappers or iptables

support FTP only users

use the nolgin shell

configure NFSv4 server

You need to use the nohide option when using gss/krb5 to see anything that was mounted using bind


/exports             gss/krb5p(rw,sync,fsid=0,no_subtree_check)
/exports/home   gss/krb5p(rw,sync,nohide,no_subtree_check)

configure Kerberos to provide user authentication

Install kerberos server packages

[root@auth1 /]# yum install krb5-server

Add the following rules to iptables


-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 88 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 88 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 464 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 464 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 749 -j ACCEPT

Edit the kdc conf file

[root@auth1 /]# vim /var/kerberos/krb5kdc/kdc.conf

[kdcdefaults]

 v4_mode = nopreauth

 kdc_tcp_ports = 88

[realms]

 auth1.EXAMPLE.COM = {

  #master_key_type = des3-hmac-sha1

  default_priniciple_flags = +preauth

  acl_file = /var/kerberos/krb5kdc/kadm5.acl

  dict_file = /usr/share/dict/words

  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab

  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3

 }

Initialise the database

[root@auth1 /]# kdb5_util create

Log in as kadmin.local and create the princs

[root@auth1 /]# kadmin.local

configure an NIS server to provide directory services

[root@ds1 ~]# yum install ypserv

[root@ds1 ~]# chkconfig portmap on

add the following to iptables

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT

add the following to /etc/sysconfig/network

YPSERV_ARGS="-p 841"

add the following to iptables

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 808 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 808 -j ACCEPT

Set the NIS domain name

[root@auth1 ~]# nisdomainname NISDOMAINNAME

Start NIS

[root@auth1 ~]# service ypserv start

Initialise maps

[root@auth1 /]# /usr/lib/yp/ypinit -m

check access to maps

[root@client ~]#  ypcat  -d auth1.example.com -h auth1.example.com passwd

Lock down using securenets

[root@auth1 /]# vim /var/yp/securenets

SUBNETMASK NETWORKADDRESS

Authenticate to the Directory Server using kerberos

7.12. Using Kerberos GSS-API with SASL

Kerberos v5 must be deployed on the host for Directory Server to utilize the GSS-API mechanism for SASL authentication. GSS-API and Kerberos client libraries must be installed on the Directory Server host to take advantage of Kerberos services.

7.12.1. Authentication Mechanisms for SASL in Directory Server

Directory Server support the following SASL encryption mechanisms:

• EXTERNAL. EXTERNAL, as with TLS/SSL, performs certificate-based authentication. This method uses public keys for strong authentication.
• CRAM-MD5. CRAM-MD5 is a simple challenge-response authentication method. It does not establish any security layer, unlike GSS-API. Both DIGEST-MD5 and GSS-API are much more secure, so both of those methods are recommended over CRAM-MD5.
• DIGEST-MD5. DIGEST-MD5 is a mandatory authentication method for LDAPv3 servers. While it is not as strong as public key systems or Kerberos authentication methods, it is preferred over plain text passwords and does protect against plain text attacks.
• Generic Security Services (GSS-API). Generic Security Services (GSS) is a security API that is the native way for UNIX-based operating systems to access and authenticate Kerberos services. GSS-API also supports session encryption, similar to TLS/SSL. This allows LDAP clients to authenticate with the server using Kerberos version 5 credentials (tickets) and to use network session encryption.
  For Directory Server to use GSS-API, Kerberos must be configured on the host machine. See Section 7.12, “Using Kerberos GSS-API with SASL”.

  NOTE

  GSS-API and, thus, Kerberos are only supported on platforms that have GSS-API support. To use GSS-API, it may be necessary to install the Kerberos client libraries; any required Kerberos libraries will be available through the operating system vendor.

CRAM-MD5, DIGEST-MD5, and GSS-API are all shared secret mechanisms. The server challenges the client attempting to bind with a secret, such as a password, that depends on the mechanism. The user sends back the response required by the mechanism.

NOTE

DIGEST-MD5 requires clear text passwords. The Directory Server requires the clear text password in order to generate the shared secret. Passwords already stored as a hashed value, such as SHA1, cannot be used with DIGEST-MD5.

7.12.2. About Kerberos in Directory Server

On Red Hat Enterprise Linux, the supported Kerberos libraries are MIT Kerberos version 5.

The concepts of Kerberos, as well as using and configuring Kerberos, are covered at the MIT Kerberos website,http://web.mit.edu/Kerberos/.

7.12.2.1. About Principals and Realms

A principal is a user in the Kerberos environment. A realm is a set of users and the authentication methods for those users to access the realm. A realm resembles a fully-qualified domain name and can be distributed across either a single server or a single domain across multiple machines. A single server instance can also support multiple realms.

NOTE

Kerberos realms are only supported for GSS-API authentication and encryption, not for DIGEST-MD5.

Realms are used by the server to associate the DN of the client in the following form, which looks like an LDAP DN:

uid=user_name/[server_instance],cn=realm,cn=mechanism,cn=auth

For example, Mike Connors in the engineering realm of the European division of example.com uses the following association to access a server in the US realm:

uid=mconnors/cn=Europe.example.com,cn=engineering,cn=gssapi,cn=auth

Babara Jensen, from the accounting realm of US.example.com, does not have to specify a realm when to access a local server:

uid=bjensen,cn=accounting,cn=gssapi,cn=auth

If realms are supported by the mechanism and the default realm is not used to authenticate to the server, then the realm must be specified in the Kerberos principal. Otherwise, the realm can be omitted.

NOTE

Kerberos systems treat the Kerberos realm as the default realm; other systems default to the server.

7.12.2.2. About the KDC Server and Keytabs

Kerberos is a protocol which allows users or servers to authenticate to a server securely over an insecure connection. As with protocols like TLS and SSL, Kerberos generates and issues session keys which encrypt information. A Kerberos server, then, has two functions: as an authenticating server to validate clients and as a ticket granting server.

Because of this, the Kerberos server is called a key distribution center or KDC.

See the operating system documentation for information on installing and configuring a Kerberos server.

When a client authenticates to the Directory Server using GSS-API, the KDC sends a session key, followed by a ticket granting ticket (TGT). The TGT contains the client's ID and network address, a validity period, and the session key. The ticket and the ticket's lifetime are parameters in the Kerberos client and server configuration. In many systems, this TGT is issued to the client when the user first logs into the operating system.

Command-line utilities provided with the operating system — including kinit, klist, and kdestroy — can acquire, list, and destroy the TGT. These tools usually use a file called a keytab to the issued keys. This file is created by the Kerberos administrator by exporting the key from the KDC.

In order to respond to Kerberos operations, the Directory Server requires access to its own cryptographic key. The Kerberos key is written in the keytab file. The keytab gives the credentials that the Directory Server uses to authenticate to other servers. Directory Server assigns a keytab through the KRB5_KTNAME environment variable in its startup script (/etc/sysconfig/dirsrv):

KRB5_KTNAME=/etc/dirsrv/ds.keytab ; export KRB5_KTNAME

NOTE

The Directory Server must be able to access the host keytab and the krb5.conf file for GSS-API authentication in SASL. For this host keytab file to be properly labeled in SELinux in the dirsrv_config_tcontext, the file must be in the /etc directory.

Only the host keytab and krb5.conf must be in /etc. The user key tabs can still be in any directory.

When the Directory Server authenticates to the server, it is as if it is running a kinit command to initiate the connection:

kinit -k -t /etc/dirsrv/ds.keytab ldap/FQDN@REALM

The Directory Server uses the service name ldap. Its Kerberos principal is ldap/host-fqdn@realm, such as ldap/ldap.corp.example.com/EXAMPLE.COM. The host-fqdn must be the fully-qualified host and domain name, which can be resolved by all LDAP and Kerberos clients through both DNS and reverse DNS lookups. A key with this identity must be stored in the server's keytab in order for Kerberos to work.

Whatever server the Directory Server is authenticating to must have a SASL mapping that maps the Directory Server's principal (its user entry, usually something like ldap/server.example.com@EXAMPLE.COM) to a real entry DN in the receiving server.

On Red Hat Enterprise Linux, the client-side Kerberos configuration is in the /etc/krb5.conf.

NOTE

The Directory Server must be able to access the krb5.conf file for GSS-API authentication in SASL. For these files to be properly labeled in SELinux in the dirsrv_config_t context, the file must be in the /etcdirectory.

For information on setting up the service key, see the Kerberos documentation.

Example 7.4, “KDC Server Configuration” shows a KDC server configured with the company.example.com realm.

Example 7.4. KDC Server Configuration

[libdefaults] 
     ticket_lifetime = 24000 
     default_realm = COMPANY.EXAMPLE.COM 
     dns_lookup_realm = false 
     dns_lookup_kdc = false 
     ccache_type = 1 
     forwardable = true 
     proxiable = true 
     default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc 
     default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc 
     permitted_enctypes = des3-hmac-sha1 des-cbc-crc 
[realms] 
  COMPANY.EXAMPLE.COM = { 
     kdc = kdcserver.company.example.com:88 
     admin_server =adminserver.company.example.com:749 
     default_domain = company.example.com 
  } 
[appdefaults] 
  pam = { 
     debug = true 
     ticket_lifetime = 36000 
     renew_lifetime = 36000 
     forwardable = true 
     krb4_convert = false 
  } 
[logging] 
  default = FILE:/var/krb5/kdc.log 
  kdc = FILE:/var/krb5/kdc.log 
  admin_server = FILE:/var/log/kadmind.log

7.12.3. Configuring SASL Authentication at Directory Server Startup

SASL GSS-API authentication has to be activated in Directory Server so that Kerberos tickets can be used for authentication. This is done by supplying a system configuration file for the init scripts to use which identifies the variable to set the keytab file location. When the init script runs at Directory Server startup, SASL authentication is then immediately active.

The default SASL configuration file is in /etc/sysconfig/dirsrv.

If there are multiple Directory Server instances and not all of them will use SASL authentication, then there can be instance-specific configuration files created in that directory named dirsrv-instance. For example, dirsrv-example. The default dirsrv file can be used if there is a single instance on a host.

To enable SASL authentication, uncomment the KRB5_KTNAME line in the /etc/sysconfig/dirsrv (or instance-specific) file, and set the keytab location for the KRB5_KTNAME variable. For example:

# In order to use SASL/GSSAPI the directory
# server needs to know where to find its keytab
# file - uncomment the following line and set
# the path and filename appropriately
KRB5_KTNAME=/etc/dirsrv/krb5.keytab ; export KRB5_KTNAME

7.12.4. Using an External Keytab

A default keytab file is specified in the Directory Server start script and is used by the Directory Server automatically. However, it is possible to specify a different keytab file, referencing a different principal, by manually running kinit and then specifying the cached credentials.

To specify the cached kinit credentials, add the principal as the KRB5CCNAME line in /etc/sysconfig/dirsrv:

KRB5CCNAME=/tmp/krb_ccache ; export KRB5CCNAME
kinit principalname   
# how to provide the password here is left as an exercise
# or kinit -k -t /path/to/file.keytab principalname
chown serveruid:serveruid $KRB5CCNAME 
# so the server process can read it
# start a cred renewal "daemon"
( while XXX ; do sleep NNN ; kinit ..... ; done ) &
# the exit condition XXX and sleep interval NNN are left as an exercise
...

The server has no way to renew these cached credentials. The kinit process must be run manually, external to Directory Server processes, or the server could begin receiving SASL bind failures when the server attempts to use expired credentials.