BEAST and CRIME SSL/TLS vulnerability

I recently ran a vulnerability scan against my web servers and the BEAST and CRIME vulnerabilities.

RHEL5 Apache

Simple PCI DSS compliant and compatible setup for RHEL5 Apache with 3DES as last resort against BEAST:

SSLHonorCipherOrder On

SSLProtocol All -SSLv2

SSLCipherSuite RC4-SHA:AES256-SHA:AES128-SHA:DES-CBC3-SHA

Simple CRIME reduction for same setup:

echo >>/etc/sysconfig/httpd export OPENSSL_NO_DEFAULT_ZLIB=1

You can test your websites URL here: https://www.ssllabs.com/ssltest/

Lighttpd

Edit the lighttpd.conf file and add  the following for BEAST:

ssl.cipher-list = “ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM”
ssl.honor-cipher-order = enable

Splunk Node

This works for Splunk 4.3 or higher, there is no setting for versions below 4.3 for Ciphers. Edit the web.conf file and add the following:

<nowiki>

enableSplunkWebSSL = true

supportSSLV3Only = true

cipherSuite = RC4+RSA:AES256-SHA:AES128-SHA:DES-CBC3-SHA:+HIGH:!MEDIUM:!LOW

</nowiki>

For the CRIME vulnerability edit server.conf. My forwarders don’t need web enabled!

<nowiki>

[httpServer]
disableDefaultPort = true

supportSSLV3Only = true

</nowiki>

Upgrade PERC 5/i Integrated Firmware

I recently had to upgrade the firmware on one of my Dell systems. It doesn’t mention it in the release notes but this WILL REQUIRE A REBOOT!

Instructions taken from here: http://ftp.us.dell.com/SAS-RAID/R189337.txt

Once you download the update file make sure to verify the signature. Here are the instructions from Dell: http://support.dell.com/support/edocs/software/smdrac3/idrac/idrac1.11/en/ug/html/chap02.htm

1. Download the appropriate .BIN file from http://support.dell.com and enter you serial number. Browse to SAS RAID Controller section.
2. Scp the file to the system you want to update
3. I ran ./RAID_FRMW_*.BIN –version to see what required packages are necessary.  For my system, it was just compat-libstdc++-33.3.2.3.
4. Make sure to stop the Server Administrator: omconfig system webserver action=stop
5. Stop the Storage Management service: /etc/init.d/dataeng stop
6. Upgrade the firmware: ./RAID_FRMW*.BIN

Multiple MySQL servers on RHEL5

Install MySQL 5

I did this with the standard RHEL rpm install.  yum install mysql-server

I left the install with all defaults in the my.cnf

Install MySQL4

The trick here is to configure MySQL 4 with a new UNIX socket path and a new port number. Note this is only one way to do it. If you had multiple IP addresses on a system you could configure MySQL to listen on a specific IP and port. In addition, if you needed multiple instances of MySQL 5 you could re-use the initial mysql instance and spawn off a new instance on a new port and socket.

So I downloaded mysql-4.XXX.tar.gz.  I extracted it and moved into that directory: cd /usr/local/mysql-XXX

I chose to install into /usr/local/mysql, on port 3308.

I ran this command before my ./configure below. Not sure if it was necessary or not:

CFLAGS=”-O3″ CXX=gcc CXXFLAGS=”-O3 -felide-constructors -fno-exceptions -fno-rtti”

Here are my configure options:

sudo ./configure –prefix=/usr/local/mysql –exec-prefix=/usr/local/mysql –with-unix-socket-path=/usr/local/mysql/mysql.sock –with-tcp-port=3308 –with-plugins=all

Then I ran a make all install.  I had issues with running mysql_install_db and it was not creating the tables correctly. I found this post (http://forums.mysql.com/read.php?11,51024,100061#msg-100061) and ran the command as follows:

./mysql_install_db –user=mysql –ldata=/usr/local/mysql/data

I had to copy the my.cnf from /usr/local/mysql-XXX/support-scripts/my-medium.cnf and put it into /usr/local/mysql/etc/my.cnf

I updated the my.cnf as follows:

[client]

#password       = your_password

port            = 3308

socket          = /usr/local/mysql/mysql.sock

# Here follows entries for some specific programs

# The MySQL server

[mysqld]

port            = 3308

socket          = /usr/local/mysql/mysql.sock

datadir         = /usr/local/mysql/data

skip-locking

Comment out bin-log as this is also a replication slave I am playing with.

[mysqld_safe]

log-error=/var/log/mysqldv4.log

pid-file=/usr/local/mysql/var/run/mysqld.pid

Then I HAD TO stop the mysql version 5 server before I could start the mysql 4 server.

I was then able to start the MySQL 4 server with the following command:

sudo /usr/local/mysql/bin/mysqld_safe –defaults-file=etc/my.cnf &

Note: If you are using the –defaults-file it needs to be the first option.  mysqld_safe will not recognize other options after it.

Finally I created a symlink from /usr/local/mysql/bin/mysql to /usr/bin/mysql-v4 for easy access to my mysql 4 server.

Now on to configuring my MySQL slave

Sendmail + SpamAssassin + SpamAss-Milter + Milter-GreyList

Overview

It’s been a while since my last post. I recently had to implement a SpamAssassin at work. Our setup is such that we have a Sendmail backup mail server that collects the overflow of our primary spam filter solution, therefore the standard installation where SpamAssassin delivers the mail locally would not work for our layout.

I needed a solution in which I didn’t have to mark certain messages as spam and others as not spam since the SpamAssassin server was a relay.

Initially I set up SpamAssassin with spamass-milter for RHEL 5. The amount of spam messages sent from the backup mail server to our primary spam filter was about 120,000-150,000 spam messages a day. So I looked further into a solution that I would not have to filter through. I found the Milter-Greylist for RHEL 5.

Once I implemented the GreyListing, the messages from our secondary mail filter to the primary fell from 120,000 to 1,000. For the next several days the spam started increasing by about a thousand each day. So I did further reading to discover in order to use the GreyListing properly, you needed to also include at least one Black List. The premise being that if you delay the emails received with the GreyList for 30 minutes (by default) then by the time the Spammers resend the mail, they will have been Black Listed.

Below are the steps I used to configure and install the above components and what I how I believe it works. Please don’t quote me on it as I am not positive about all of the information as far as what service gets hit first and such.

SpamAssassin & SpamAss-Milter

SpamAssassin was installed by default in my system but if is is not already in yours, you can use the yum command or the up2date command to install from the RedHat Network. To verify if it is installed already,

yum install spamassassin (RHEL 5)

up2date install spamassassin (RHEL 3/4)

Once spamassassin is installed I configured the SpamAssassin init script configuration file to run with the following important commands.

-m5 Allow maximum number of children

-u Username (other than root)

-s Syslog facility

-r Specify PID file

For a list of complete options please consult your man page to determine what settings are appropriate for your environment.

The SpamAssassin configuration file is local.cf. The location of the file will depend on your distribution of Linux. For RHEL 5 it is located under /etc/mail/spamassassin/. You will need to read about the configuration options and decide what is best for your environment.

The bayes system only applies to local users mail. The report_safe option encapsulates spam in an attachment. The required score is how many hits befroe a message is considered spam. Trusted networks are networks excluded for your environment.

In addition for relayed mail, you need some sort of mail filter (Milter) to filter the mail through SpamAssassin and Sendmail.

Install spamass-milter

wget LONG_URL/spamass-milter-*.rpm

rpm -ivh spamass-milter*.rpm

The only things I edited for the spamass-milter was the init script /etc/rc.d/init.d/spamass-milter. I changed the user to the same user that spamassassin was running as.

You can start the spamassassin service and the spamass-milter service and not affect the operation of mail. You need to edit the sendmail.cf file and restart sendmail in order to filter mail through the spamassassin process.

service spamassassin start

service spamass-milter start

Edit the sendmail.cf file. We use the m4 macro so the only line I added was the following to include the spamassassin input mail filter.

INPUT_MAIL_FILTER(`spamassassin’,`S=local:/var/run/spamass-milter/spamass-milter.sock,F=,T=C:15m;S:4m;R:4m;E:10m’)dnl

This entry creates a mail filter that gets sent to the local UNIX socket which is a wrapper for the spamassassin service.

The F flag is a filter flag which can have either R or T set.

R = Reject connection if filter is unavailable

T = Temporary fail connection if filter is unavailable

If neither option is set (as above), the message is passed through sendmail in case of filter errors as if failing filters were NOT present.

Finally you can override the default timeouts used by sendmail when talking to the filters, using the T=equate option.

C = Timeout for connecting to a filter

S = Timeout for sending information from MTA to filter

R = Timeout for reading a reply from filter

E = Overall timeout

If the T option is NOT specified, the default values are:

T=C:5m;S=10s;R=10s;E=5m

NOTE: If INPUT_MAIL_FILTERS are NOT defined in the sendmail.cf file, no filters will be used.

Finally you need to recompile the sendmail.cf file with the m4 macro and restart the sendmail service.

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

service sendmail restart

You can view that SpamAssassin is working by tailing the maillog. You should see messages that say “Blocked by SpamAssassin”. You could also telnet to port 25 and include a mail message with the following content in the DATA portion of the message.

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

Grey Listing

As mentioned above, the spamassasis only blocked about 10,000 spam messages a day still allowing 90,000+ through. Upon further investigation I found Grey-Listing.

milter-greylist is a stand-alone milter written in C that implements the greylist filtering method as proposed by Evan Harris.

Grey listing works by assuming that, unlike legitimate MTA, spam engines will not retry sending their junk mail on a temporary error. The filter will always reject mail temporarily on a first attempt, then accept it after some time has elapsed by default 30 minutes.

If spammers ever try to resend rejected messages, we can assume they will not stay idle between the two sends (if they do, the spam problem would just be solved). Odds are good that the spammer will send a mail to a honey pot address and get blacklisted in several real-time distributed black lists before the second attempt.

I chose to implement this on our secondary backup mail server because it was forwarding between 120,000 – 150,000 spam emails to our primary mail server per day. The Spamassassin filter wasn’t blocking enough spam. After the milter-greylist was installed the spam emails were reduced to 1,000 – 2,000 per day. In addition, this took a huge load off of our backup mail server as the Spamassassin is a HUGE CPU hog and the Greylist-Milter is a much lighter milter as far as CPU consumption.

1. Install milter-greylist
wget http://long-url/milter-greylist.rpm
rpm -ivh milter-greylist.rpm

2. Configuration, Edit /etc/mail/greylist.conf and add the following:
list “my network” addr { CIDR/Network CIDR/Network … }
list “broken mta” addr { CIDR/Network CIDR/Network … }
list “grey users” rcpt { email@address email@address … }
3. Add acl support
acl whitelist list “my network”
acl whitelist list “broken mta”
acl greylist list “grey users”
acl greylist default (The default delay is 30 minutes)

4. Test greylist.conf
milter-greylist -c

5. Start service
service milter-greylist start

6. Edit sendmail.mc to work with greylist milter
dnl # GREYLIST MILTERdnl
INPUT_MAIL_FILTER(`greylist’,`S=local:/var/milter-greylist/milter-greylist.sock’)dnl
define(`confMILTER_MACROS_CONNECT’, `j, {if_addr}’)dnl
define(`confMILTER_MACROS_HELO’, `{verify}, {cert_subject}’)dnl
define(`confMILTER_MACROS_ENVFROM’, `i, {auth_authen}’)dnl
define(`confMILTER_MACROS_ENVRCPT’, `{greylist}’)dnl

Black Listing

You must enable black listing for GreyListing to work.
1. Edit /etc/mail/sendmail.mc file
FEATURE(‘blacklist_recipients’)dnl
FEATURE(‘dnsbl’,’bl.spamcop.net’)dnl

Make sure to periodically check that your dns blacklist is still being maintained!