Category Archives: IT Security

Latest Read: Security 2020: Reduce Secuirty Risks This Decade

[openbook booknumber=”ISBN:978-0470639559″ templatenumber=”1″]

It must be a sign of the times when you pick up a book published two years ago and wonder if it is worth reading because it may already be outdated.  Things are moving at such a rapid pace, I always have the feeling that was true two years ago may no longer be valid today.  Luckily for me, the information presented in this book is still relevant and provided intereting food for thought.   One interesting feature of the book, is that interspersed throughout each chapter, the authors included short discussions from some of their contributors relating to the contents of the chapter.  Some of these discussions support the conclusions and some may offer alternative conclusions and opinions.  In both cases, I found the alternative points of view to be quite interesting, making the book more of a discussion and less of a one-sided lecture.

The book begins with a quick overview of the various topics in IT Security, from what Malware is to Botnets and the evolution of security solutions.  The chapter is very concise and covers a lot of ground quickly.  In chapters 2, 3 and 4, he book continues with a discussion of the external non-technical influences on security, followed by the technical influences and finally a discussion on various threats.  These three chapters cover a lot of ground, touching on almost every topic relevant to IT Security today and how they the authors feel they will evolve over the next decade.    

Chapter 5 then concentrates on Unified Communications and Collaboration solutions and the challenges these solutions pose to security professionals, since securing these types of services often “restrict the benefits these types of tools bring to the business.”   Within UCC the authors include topics such as email, VoIP, Shareoint, Webinars, storage of user generated content and digital rights management.  The author’s conclusion that UCC will evovle significantly over the coming decade and these change will have a significant impact on user behavior is definitely true.  The challenge of being able to effectively identify and provide an audit trail for activities in the UCC area is significant and still not solved effectively today.

The authors then take a step back and discuss the history of Inforation Security and how it has evolved over time.  Among other things, the authors argue that since adding point solutions to an infrastructure increases the complexity and cost of the overall IT security environment, the future will continue to see the convergence of tools into integratied solutions much like the melding of technologies into UTM solutions has done.  

Chapters 7 and 8 touch on the business and economics of Security, which ranges from internal IT budgets to macro-economic influences such as another recession. 

Chapters 9 and 10 bring it all together with some future scenarios and then the conclusion.  I found the future scenarios to be interesting and some could be considered useful, for example what if GPS stopped working.  Is this relevant to your business?  What services rely on it?  Because of this, I feel that the most valuable part of Chapter 9 was the idea that just writing down a few what-ifs with possible action plans, will give you a basis for quicker reation if one does actually come true.  By reading this book, you take one step in that direction, preparing for what might come.  Whether the authors have it right or wrong, the most important thing is to have performed the thought exercise, which may give you a head start when faced with one of these topics in the future.  

 Note:  This book review was submitted for CPE credit to ISC2 as part of my CISSP certification requirements.

 

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.