Entries Tagged as 'Security'

How to disable TLSv1 on Sophos UTM9 WAF for PCI

As freaking annoying as it is that the Sophos UTM, a security appliance, doesn't pass a PCI compliance scan, what's worse is that the process for disabling TLSv1 for sites running behind the Sophos WAF is not documented anywhere currently that I can find.

So, in an effort to help the community at large, I decided to docuemnet how I fixed it.

First, I was able to find excellent docuemnetation by a community member on how to disable TLSv1 for the Sophos Admin interface:

https://juicytool.wordpress.com/2015/12/15/how-to-disable-tls-1-0-on-sophos-utm-for-pci-compliance/

This is helpful, but I also needed to know how to disable TLSv1 for sites that run behind the Sophos WAF.

After (a lot) of digging, I found that the sites running behind the Sophos WAF do so through the Sophos Service "reverseproxy". This is the service we need to edit to remove TLSv1 support.

The above documentation talks about hwo to go about logging into the command line on a Sophos UTM9, so I won't repeat it. Once you're logged in, you'll need to run the following commands:

sudo vim /var/storage/chroot-reverseproxy/usr/apache/conf/httpd.conf

Update these to lines:

SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:ECDH+3DES:DH+3DES:RSA+3DES:!aNULL:!MD5:!DSS
#SSLProtocol all -SSLv2 -SSLv3

to this

SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AES:!ADH:!AECDH:!MD5:!DSS:!3DES
SSLProtocol +TLSv1.1 +TLSv1.2

The restart the 'reverseproxy" service with the following command:

sudo /var/mdw/scripts/reverseproxy restart

Check that you can no longer acccess your site using TLSv1 with the following command (updating it with your own domain name):

openssl s_client -connect utdream.org:443 -tls1

You'll get a handshake failed error if TLSv1 has been properly disabled:

SSL handshake has read 0 bytes and written 0 bytes

How to disable TLSv1.0 for PCI Compliance in Apache 2.2

Just recently our PCI compliance scanner started complaining about TLSv1.0 being enabled on our web server, so I had to go figure out how to disable it. The following is what I ended up with in our VirtualHost config which did what I wanted it to:
 
<VirtualHost xx.xx.xx.xx:443>
        ::snip::
        SSLEngine on
        SSLProtocol +TLSv1.1 +TLSv1.2
        SSLCompression off
        SSLHonorCipherOrder On
        SSLCipherSuite ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:HIGH:!MD5:!aNULL:!EDH
        Header always append X-Frame-Options SAMEORIGIN
        ::snip::
</VirtualHost>

PCI Compliance TLSv1.0I simply removed the "all" option I had there previously and just manually enabled the TLSv1.1 and TLSv1.2. I also added the "Header" bit so that common browsers wouln't put our site in frames.

Now, checking our SSL certificate using the SSL Server Test we get an A rating. The downgrade from A+ being due to an upstream older SHA1 hash that we have no way to change and doesn't directly effect the security of our site, so as far as I'm concerned we look good.

The draw back is that older machines, such as those running Windows XP and versions of Android older than 4.2.2 will no longer be able to connect to us. Sorry about that. Since this is required for PCI compliance, there's not much we can do.

Fixing "JRun too busy or out of memory" for PCI compliance

One of our servers here at Vivio is routinely scanned for PCI compliance purposes. Until just recently, we've been using FuseGuard (A Web Application Firewal, or "WAF"), to block intrusion attempts to our web application. With new PCI standards that force us to allow PCI scans through our WAF (or IDS or whatever), we had to allow these requests through, but that brought to light another, different, problem.

During the PCI scan, our Apache logs would get a lot of the following error messages:

[notice] jrApache[13857: 62679]  returning error page for JRun too busy or out of memory

Initially we thought that since the message was coming from the JRun connector, that the issue had something to do with the connector. However, after quite a bit more research, we found it had to do with JRun itself, and the specific number of post parameters it's configured to accept. Any more then the default "100" post parameters, and you'll get the error you see above.

To change the number of post parameters, you will need to update your neo-runtime.xml file. For our case, ours was found here:

/opt/coldfusion9/lib/neo-runtime.xml
NEO XML Example

IMPORTANT: Editing this file isn't particularly easy. Opening it in VIM gives you a big wall of text.

By increasing the following parameter from 100 to 300, we were able to succesfully complete our PCI scan:

<var name='postParametersLimit'><number>300.0</number></var>

Hopefully this helps anyone else having this issue.

Apache 2.4 - 403 Forbidden (AH01630: client denied by server configuration)

I recently updated one of my development machines to Ubuntu 13.10 which now uses Apache 2.4 by default. In my case, I had updated a machine that was previously running Ubuntu version 13.04 and had been running Apache 2.2.

Apache 2.4After the upgrade, I was disturbed to find that none of my sites worked! I kept getting Apache 403 (Forbidden) error messages. I figured the upgrade had changed my configurations or something... but after fruitlessly messing with the config files (and seeing nothing wrong with them) I figured I'd look in the apache error log, which is located in /var/log/apache2/error.log by default on Ubuntu 13.10. To my surprise, I found lots of the following errors:

AH01630: client denied by server configuration: /path/to/my/sites

I had never seen that before. Then I noticed at the top of the log file "AH00163: Apache/2.4.6 (Ubuntu)". Ohhhhh....  So we're using the new 2.4 eh? After some google searches, I found out that Apache 2.4 comes with some security enhancements that attempt to make it more difficult for hackers to hide their files on a compromised system. That's neat, but I need to get my sites to work.

After reading a bit of the 2.4 Access Control Documentation, I found that a quick easy fix is to add a directory rule to your main apache config file (/etc/apache2/apache2.conf by default on Ubuntu):

<Directory /path/to/my/sites>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

Restart Apache, and boom, all sites are now loading just fine. The idea behind these rules is to make it so that hackers who, say, use SQL injection to access your PHP site, have a harder time hiding their files in obscure directories on your system, amond other things.

Hope this helps!
Jordan

 

How to validate an email message to see if it is spam, a virus, or a phishing attack.

Just recently I've been getting a few emails that appear to be from folks who are my Facebook friends, however, these emails are short and only contain a short message and a link to a web site. Being the untrusting cautious type that I am, I do not trust these emails, and neither should you. The following describes how to test an email message to see if it's from your friend or from someone attempting to do you harm.

Important: Never EVER click on a link in an email that you're not absolutely certain is safe.

The following is an email message I received that appeared to come from my Aunt. I have been marking these messages as "junk" in thunderbird, so Thunderbird has learned that I consider messages like these junk, but when I first started getting them, they looked like normal messages.

phishing email

The first thing I notice is that the email my "Aunt" is sending from looks like it is from someone named "Tracy". Why would my aunt be sending me email from Tracy's account? Yes, big red flag there.

Verify The Source

In the next few paragraphs I'm going to show you how to check ANY message you get to see where it came from. This is an incredibly accurate indication of if a message is safe to read or not.

First, you start out by looking at the email "Headers". The Headers are the bits of information that email servers tack on to an email message when it passes through them. SOME headers are created by the email client that sends it, so not all headers can be trusted, but most of the time the server traversal record can be used to make a fairly accurate decision about whether an email message is safe or not.

To view the message headers in Thunderbird, I clicked on "Other Actions", then selected "View Source" from the drop-down menu. Other email readers have different ways of showing you the headers, but in general it is pretty easy to find if you poke around a little.

thunderbird view source

So, now that we can see the source of the message, let's take a look at the server traversal record, which I've highlighted below:

email server traversal record

The server traversal record headers, like any other header, can be forged. However, it takes some effort to forge the server traversal records, so these headers are *usually* trustworthy. In my example above, you can see that this email message originated from 82.211.142.40, and sent the message by logging in to smtpauth03.mfg.siteprotect.com.

So, since the email message came from the 82.211.142.40 IP address, let's take a look at that and see where that IP is located. We can see where an IP is assigned by doing what's called a "Who Is" on the IP Address. I like using ARIN's web site for this purpose, which you can find over at http://whois.arin.net/ui.

The "Who Is" search box is up in the top right. Let's enter the IP Address there and see where it came from:

ARIN whois

The WhoIs will give us a lot of information about the IP Address, what networks it belongs to, and so forth, but the interesting information for most folks is at the very bottom of the results:

arin whois results

So, if my Aunt really did send this message, apparently she did so from Amsterdam, using someone elses email account. Yeah.... right....

Most likely, this is a case of a compromised email account (poor tracy) being used to send out phishing attacks. The web address in the email that was sent to me probably contained an "attack" of some sort - something Flash or Java-based probably - and the attacker probably got my name and the name of my Aunt from our public facebook accounts.

Hopefully you found some of the information here helpful, and you can use it yourself to check messages you get from your "friends" that contain nothing but links.

Hope this helps!

masquerade-peaceful