Monthly Archives: December 2012

IPTables

One of the interesting features of using CentOS was that IPTables are installed by default.  IPTables is a host based statefull firewall which can be useful for securing a small number of simple servers.  As the number of servers grows or the complexity of the rulebase increases, it would make sense to begin using a host based firewall solution which supports central management and logging.

IPTables rule files are stored under /etc/sysconfig and by default, it sends all logs as standard syslog to /var/log/messages.  The /etc/sysconfig directory contains two files:

  • iptables contains rules for IPv4 services
  • ip6tables contains the rules for IPv6 services

IPtables are managed using a command line syntax to insert, append or delete lines into the respective files.  The command syntax is discussed  in a number of posts, so I won’t go into that here.   The default rules allow everything out of the server and only lets ssh in.   Since the command line is cumbersome, I chose to set up my initial rulebase by replacing the default file with the new file.  Of course, until I was sure that the new rulebase worked, I kept a backup copy of the original rulebase just in case.  Future changes can then be made through the command line.

For a standard web server, I used the following two base files.  The configurations create a new chain called RH-Firewall-1-INPUT into which both the INPUT and FORWARD chains are redirected.  This rulebase also logs all dropped packets to the default file /var/log/messages with the prefix “Firewall-log: “. This makes it easy to view dropped packets by grepping for “Firewall” when viewing the log file.

iptables:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type destination-unreachable 
  -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
# Accept Pings
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-request -j ACCEPT
# Accept any established connections
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Accept ssh traffic. Restrict this to known ips if possible.
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 
  -m limit --limit 3/min --limit-burst 3 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 
  -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 
  -j ACCEPT
#Log and drop everything else
-A RH-Firewall-1-INPUT -j LOG --log-prefix "Firewall-Log: "
-A RH-Firewall-1-INPUT -j DROP
COMMIT

ip6tables:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p ipv6-icmp -j ACCEPT
# Accept any established connections
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Accept ssh traffic. 
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 
  -m limit --limit 3/min --limit-burst 3 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 
  -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 
  -j ACCEPT
#Log and drop everything else
-A RH-Firewall-1-INPUT -j LOG --log-prefix "Firewall-Log: "
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp6-adm-prohibited
COMMIT

The following commands are useful for managing and monitoring IPTable activity:

Viewing the rules with their respective line numbers (in case you want to delete or insert lines) –

# iptables --line-numbers -n -L

Viewing the rules with number of hits and bytes per rule (to see if the rule is actually working) –

# iptables -L RH-Firewall-1-INPUT -v -n -x

Stopping, starting and restarting –

# service iptables start/stop/restart

After making changes with the command line, do not forget to save the changes with the command before restarting the service –

# service iptables save

Some interesting notes:

  • PUTTY works with both IPv4 and IPv6 to ssh to a client.
  • Stopping, starting and restarting iptables has no impact on established sessions.  So if you are logged into a server via SSH, then you shouldn’t lose your session by restarting iptables.  Just in case there is an issue or if you are worried that you might lock yourself out of the server, you can use a simple shell script to stop iptables if the connection is lost (see below).
   #!/bin/bash
   #
   # Perform 6, 10 second loops to delay for one minute
   # Stop the script if everything goes as planned within 
   # the 60 seconds.
   #
   x=0
   y=60
   echo "Start"
   while [ $x -lt $y ];
    do
        echo $x
        x=$(($x + 10))
        sleep 10s
   done
   service iptables stop
   echo "All Done"
  • If at any time you edit the rules using the GUI, it will reset the entire file to the original default format removing all changes you made.

References:

http://wiki.centos.org/HowTos/OS_Protection

Apache SSL Server on CentOS

After getting Apache running on Ubuntu, I also got Apache running in CentOS 6.3.  This went as smoothly as it did on Ubuntu.  The following are the steps I took to get it running.  As usual, CentOS was installed as a VM under VMWare player.

Unlike with Ubuntu, Apache comes pre-installed on CentOS and so all that was required to get it running was to start the httpd daemon and configure it to start when the server is booted:

# /etc/init.d/httpd start
# chkconfig --levels 235 httpd on

To implement SSL, the same steps as under Ubuntu were required. First I installed OpenSSL and generated the key and self signed certificate:

# yum install mod_ssl openssl
# openssl genrsa -out ca.key 2048
# openssl req -new -key ca.key -out ca.csr
# openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

Of course for a real web site, the contents of the csr file is sent to a Certificate provider (Verisign, GeoTrust, etc.) who would then return the certificate to be included in the ca.crt file.  The steps below are then followed as shown.

I then moved the files to the correct location:

# cp ca.crt /etc/pki/tls/certs
# cp ca.key /etc/pki/tls/private/ca.key
# cp ca.csr /etc/pki/tls/private/ca.csr

Edited ssl.conf and updated the following two lines with the new key and certificate:

SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key

I then restarted httpd.  This allowed the local browser to access the web page via SSL  http worked with ipv6 without any special configuration. https had issues because the browser could not “obtain identification status for the site.” and therefore would not allow me to add the exception.  I fixed this by adding an entry in the /etc/hosts file with a name that matched the certificate:

192.168.239.138 www.ssltest.com
fdc1:b20c:c011:1:20c:29ff:fe1d:635f www6.ssltest.com

Finally, I created a test index file under: /var/www/html/vhosts/ssltest.com/httpdocs and edited /etc/httpd/conf/httpd.conf to have a virtual host www.ssltest.com:

NameVirtualHost *:80
NameVirtualHost *:443

<VirtualHost *:80>
     DocumentRoot /var/www/html
     ServerName www.localhost.com
     ErrorLog logs/ssltest.com-error_log
</VirtualHost>

<VirtualHost *:80>
     DocumentRoot /var/www/html/vhosts/ssltest.com/httpdocs
     ServerName www.ssltest.com
     ErrorLog logs/ssltest.com-error_log
</VirtualHost>

<VirtualHost *:80>
     DocumentRoot /var/www/html/vhosts/ssltest.com/httpdocs
     ServerName www6.ssltest.com
     ErrorLog logs/ssltest.com-error_log
</VirtualHost>

<VirtualHost *:443>
     SSLEngine on
     SSLCertificateFile /etc/pki/tls/certs/ca.crt
     SSLCertificateKeyFile /etc/pki/tls/private/ca.key
     DocumentRoot /var/www/html
     ServerName www.localhost.com
     ErrorLog logs/ssltest.com-error_log
</VirtualHost>

<VirtualHost *:443>
     SSLEngine on
     SSLCertificateFile /etc/pki/tls/certs/ca.crt
     SSLCertificateKeyFile /etc/pki/tls/private/ca.key
     DocumentRoot /var/www/html/vhosts/ssltest.com/httpdocs
     ServerName www.ssltest.com
     ErrorLog logs/ssltest.com-error_log
</VirtualHost>

<VirtualHost *:443>
     SSLEngine on
     SSLCertificateFile /etc/pki/tls/certs/ca.crt
     SSLCertificateKeyFile /etc/pki/tls/private/ca.key
     DocumentRoot /var/www/html/vhosts/ssltest.com/httpdocs
     ServerName www6.ssltest.com
     ErrorLog logs/ssltest.com-error_log
</VirtualHost>

The first virtual host was added as the default page to answer requests directed to the ip address (for example Error:404 or some such thing.  The error page was placed in the default html directory.   I also added both host entries to my Windows7 workstation and everything worked as expected.

Apache SSL Server

Got a basic web server with ssl running on Apache under Ubuntu 12.04 LTS with a self signed certificate.  Here are the steps I followed:

Installed Apache2:

$  sudo apt-get install apache2

Generated the certificate with openssl:

$ openssl genrsa -out ssltest.key 1024
$ openssl req -new -key ssltest.key -out ssltest.csr
$ openssl x509 -req -days 365 -in ssltest.csr -signkey ssltest.key 
  -out ssltest.cert

Moved the certificates to a dedicated directory:

$ sudo mkdir /etc/apache2/ssl
$ sudo mv /home/cbroccoli/*.cert /etc/apache2/ssl
$ sudo mv /home/cbroccoli/*.key /etc/apache2/ssl
$ sudo chmod 400 /etc/apache2/ssl/*.key (make key read-only)

Created an ssl configuration file for the new site by copying the default file in /etc/apache2/sites-available:

sudo cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-available/sslsite.ssl

Updated sslsite.ssl with the following lines:

     ServerName sslsite.com 
     ServerAlias *.sslsite.com
     ...
     SSLCertificateFile    /etc/apache2/ssl/ssltest.cert
     SSLCertificateKeyFile /etc/apache2/ssl/ssltest.key

Started the ssl module:

$ sudo a2enmod ssl

Enabled the site:

$ sudo a2ensite sslsite.ssl

Restarted apache:

$ sudo service apache2 reload

I then accessed the site with the IP address and got the error message that the certificate is not secure as expected.

Access via IPv6 required an additional minor configuration for both http and https access to the page.  In the file/etc/apache2/ports.conf, the following lines were added after the respective “Listen” lines which were already included.

Listen [fdc1:b20c:c011:1:20c:29ff:fe27:ec05]:80
...
Listen [fdc1:b20c:c011:1:20c:29ff:fe27:ec05]:443

By default, Apache see the wildcards (*) as only IPv4 addresses, so it needs these extra lines in addition to the lines with the wildcard.