Category: Computers

A server that I administer from time to time has been running out of space. I manually deleted all of the logs and freed up a ton of space. I turns out that there are lots of wget calls on this server and as more customers were added the number of lines in the Apache logs increased tremendously.

The access log was rotated weekly but it gets to be very large and on an old machine with only 70GB total, it adds up. I changed the log rotation in /etc/logrotate.d/apache2 to daily from weekly and keep them for 1 day instead of 26 weeks. The free space has remained at 10% since I made the change.

/var/log/apache2/*.log {
        daily
  missingok
  rotate 1
  compress
  delaycompress
  notifempty
  create 640 root adm
  sharedscripts
  postrotate
    if [ -f "`. /etc/apache2/envvars ; echo ${APACHE_PID_FILE:-/var/run/apache2.pid}`" ]; then
      /etc/init.d/apache2 reload > /dev/null
    fi
  endscript
}

My accountant sent me my tax returns as password protected PDF files. There isn’t any way to get them out of Adobe Acrobat Reader without the password. There are lots of on-line solutions, but that means giving someone else access to your data. There are also programs that you can download, but it’s hard to know if you can trust them. Instead just drop your PDF onto Safari. Enter the password, then use File –> Print to print to PDF.

If you want to add a new password, open the file in Preview and then use the Export as PDF command. Click on the Show Details button and check the box for encryption. You can add your own password here. The encrypted files will open in Reader and Preview.

I was worried that updating my page to only accept secure https connections might lock out some customers who are still using Windows XP and old IE browsers. I was a bit worried when,
after updating my SSL ciphers I am still getting errors like this:

SSL Library Error: error:14080152:SSL routines:SSL3_ACCEPT:unsafe legacy renegotiation disabled
[client 180.76.15.31:51166] AH02225: Re-negotiation request failed
[client 134.249.131.0:51259] AH02225: Re-negotiation request failed
[client 134.249.131.0:51123] AH02225: Re-negotiation request failed
[client 1.39.57.169:37633] AH02225: Re-negotiation request failed

However, looking up the first ip with whois yields a netname of Baidu, the next two are located in the Ukraine, and one from India. There are a whole bunch of these, so I’m guessing it’s some spammers looking for forms that they can fill in with links. I just had 643 catalog requests a few days ago that defeated my rudimentary spam checking tool, so that’s what I’m going with for now.

After refactoring a site and implementing https for all pages on it, I started looking closely at the logs. I was getting lots of error messages with things like, ‘routines:SSL3_ACCEPT:unsafe legacy renegotiation’ and ‘Re-negotiation failed’, so I started looking into it. I was also vaguely aware of BEAST and RC4 weaknesses so I wanted to secure the Apache server as much as possible as well.

The first thing I found was a reference to the Mozilla Server Side TLS Config Generator. It gives a very long list of ciphers that are appropriate for your web server and client needs.

It also suggests using mod_headers to implement HSTS, which according to Wikipedia, “HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking.”

I didn’t see headers in my mods-available list and looking at the output of phpinfo();, it does not appear to have been implemented. To install mod_headers on Ubuntu you just need to run a simple command.

sudo a2enmod headers
sudo service apache2 restart

Now my mods look like this:

My old SSLCipherSuite was very short,
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!SSLv2:+EXP:+eNULL
The new one is a monster

SSLCipherSuite          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

I have no idea what most of these are, but I’m sure the good folks at Mozilla do.

The last thing they recommend is that you implement OCSP Stapling. The details are complicated, but it basically speeds up the verification of the certificate.

After adding the new lines in the appropriate place in my sites-available file for the site, I restarted Apache and everything is running fine. In the fifteen minutes it took to write this up, I have had no negotiation messages in the error log.

Once you have implemented the changes, test your site at SSLabs. I got an A+.

I recently inherited a system and wanted to be edit all of the website files. I changed the group to admin and added myself to the group. Then I wanted to change all of the directories so I could have access to them, and change all of the file permissions so the group had read-write access and others (including Apache) had only read access. The command to do that is:

sudo chmod -R u+rwX,go+rwX,o-w .

-R recursively change
u+rwX users to read and write, and if it is a directory, also execute
go+rwX same as users for group and others
o-w then remove the write permission for others
. start here