Racker Hacker

It’s always been a bit of a challenge to disable TRACE and TRACK methods with Plesk. The only available options were to create a ton of vhost.conf files or adjust the httpd.include files and prevent modifications with chattr (which is a bad idea on many levels).

Luckily, Parallels has made things easier with a new knowledge base article.

I spoke to a customer recently who was concerned about their Red Hat Enterprise Linux 2.1 server and its Red Hat support status. After some digging, I found these items on Red Hat’s security site:

Red Hat Enterprise Linux (version 5)
End of Full Support: Mar 31, 2010
End of Maintenance Support: Mar 31, 2014

Red Hat Enterprise Linux (version 4)
End of Full Support: May 15, 2008
End of Maintenance Phase: Feb 29, 2012

Red Hat Enterprise Linux (version 3)
Full Support (including hardware updates): April 30, 2006
Maintenance Support: Oct 31, 2010

Red Hat Enterprise Linux (version 2.1)
Full Support (including hardware updates): Nov 30, 2004
Maintenance Support: May 31, 2009

Here’s the difference between the levels of support:

Full Support
Start Date: General Availability
End Date: 3 Years from General Availability date
Description: During the Full Support phase, new hardware support will be provided at the discretion of Red Hat via Updates, Additionally, all available and qualified errata will be applied to the Enterprise products via Updates (or as required for Security level errata.) And finally, updated ISO images will only be provided during Phase 1: Full Support.

Maintenance
Start Date: 3.5 years from General Availability (end of Deployment)
End Date: 7 years from General Availability
Description: During the Maintenance phase, only Security errata and select mission critical bug fixes will be released for the Enterprise products.

Data was gathered from http://www.redhat.com/security/updates/errata/

There may be some situations where you want to encrypt FTP traffic with SSL certificates rather than using SFTP with SSH. Using vsftpd with SSL encryption is quite easy, and here’s how it’s done:

First, you’ll need to make a new self-signed SSL certificate (if you don’t have a key and certificate available already):

openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout server.key -out server.crt

Once you have the key and certificate made, you’ll need to concatenate them into a PEM file:

# cat server.key > /etc/vsftpd/server.pem
# cat server.crt >> /etc/vsftpd/server.pem

Now, simply adjust the vsftpd configuration file to enable SSL encryption:

ssl_enable=YES
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=YES
rsa_cert_file=/etc/vsftpd/server.pem

Once that’s complete, restart vsftpd and you will be able to connect to your FTP server using SSL/TLS encryption.

Further Reading:
Manpage of vsftpd.conf

Create a strong CSR and private key
openssl req -new -nodes -newkey rsa:2048 -out server.crt -keyout server.key

Parsing out the data within a certificate
openssl asn1parse -in server.crt

Checking a certificate/key modulus to see if they correspond
openssl rsa -in server.key -modulus -noout | openssl md5
openssl x509 -in server.crt -modulus -noout | openssl md5

Convert a key from PEM -> DER
openssl rsa -inform PEM -in key.pem -outform DER -out keyout.der

Convert a key from DER -> PEM
openssl rsa -inform DER -in key.der -outform PEM -out keyout.pem

Remove the password from an encrypted private key
openssl rsa -in server.key -out server-nopass.key

Reviewing a detailed SSL connection
openssl s_client -connect 10.0.0.1:443

Here’s a pretty weird kernel panic that I came across the other day:

Enforcing mode requested but no policy loaded. Halting now.
Kernel panic - not syncing: Attempted to kill init!

This usually means that you’ve set SELINUX in enforcing mode within /etc/sysconfig/selinux or /etc/selinux/selinux.conf but you don’t have the appropriate SELINUX packages installed. To fix the issue, boot the server into the Red Hat rescue environment and disable SELINUX until you can install the proper packages that contain the SELINUX targeted configuration.

This kernel panic appeared on a Red Hat Enterprise Linux 4 Update 5 server.

I was recently working on a server where a user on the server was concerned with these log messages:

Oct 7 20:59:33 web named[13698]: client 111.222.333.444#50389: updating zone ‘domain.com/IN’: update failed: ‘RRset exists (value dependent)’ prerequisite not satisfied (NXRRSET)
Oct 7 20:59:34 web named[13698]: client 111.222.333.444#50392: update ‘domain.com/IN’ denied
Oct 7 21:59:35 web named[13698]: client 111.222.333.444#50422: updating zone ‘domain.com/IN’: update failed: ‘RRset exists (value dependent)’ prerequisite not satisfied (NXRRSET)
Oct 7 21:59:35 web named[13698]: client 111.222.333.444#50425: update ‘domain.com/IN’ denied
Oct 7 22:59:20 web named[13698]: client 111.222.333.444#50458: updating zone ‘domain.com/IN’: update failed: ‘RRset exists (value dependent)’ prerequisite not satisfied (NXRRSET)

The messages here are actually showing that named is doing its job well. Some user was attempting to dynamically update a DNS zone repeatedly, but named was rejecting the updates since they were not coming from a valid sources.

Further reading:
Zytrax.com: DNS BIND Zone Transfers and Updates
Internet Systems Consortium: Dynamic Updates

When you create a CSR and private key to obtain an SSL certificate, the private key has some internal data called a modulus. This is integral to the security of your SSL encryption, but for this specific post, we will focus on one specific aspect.

If your private key and certificate do not contain the same modulus, then Apache will sometimes refuse to start or it may not respond properly to SSL requests. You can check the modulus of your private key and SSL certificate with these commands:

# openssl rsa -noout -modulus -in server.key | openssl md5
# openssl x509 -noout -modulus -in server.crt | openssl md5

If the MD5 checksums match, then the certificate and key will work together. However, if they are different, then you cannot use them together. Generally, this means that you used the wrong CSR (that corresponded to some other private key) when you obtained/created your SSL certificate.

Lots of PCI Compliance and vulnerability scan vendors will complain about TRACE and TRACK methods being enabled on your server. Since most providers run Nessus, you’ll see this fairly often. Here’s the rewrite rules to add:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

These directives will need to be added to each VirtualHost.

Further reading:
Apache Debugging Guide

Rackerhacker has just been upgraded to Wordpress 2.2.2. If you haven’t updated it your own blog yet, you will want to download the new version and upgrade it soon.

If you want to know why, you can review the fixes and code changes.

Plesk has a (somewhat annoying) default firewall configuration that you can adjust from within the Plesk interface. However, if you want to add additional rules, you may find that you can’t add the rules you want from the interface. If you add them from the command line, Plesk will overwrite them when it feels the urge, even if you run service iptables save as you’re supposed to.

You can override this by making /etc/sysconfig/iptables immutable with chattr. Just run the following:

# chattr +i /etc/sysconfig/iptables

Now, Plesk can’t adjust your iptables rules without your intervention. Well, that is until SWSoft figures out how to run chattr when Plesk can’t edit certain configuration files.