I’ve bought an Dell Inspiron 9300 last week. I’ll mainly use the machine for Linux and Java development but I’ve kept a small Windows XP partition. More on Linux installation later, here’s a short rant about broken Windows applications:
I didn’t want to use the Symantec tools that came bundled with the system due to previous experiences, so I had to look for another antivirus & firewall solution. After reading a few reviews I decided to try G-Data AntiVirusKit InternetSecurity 2005 first. Installation went smooth but after the next reboot the taskbar didn’t repaint anymore and Explorer was unresponsive. The system was in pretty unusable state.
After booting into Safe Mode, I’ve changed the Data Execution Prevention (DEP) settings to only cover core Windows programs. Another reboot and G-Data started working! Well that’s quite disappointing, x86 processor with No-Execute (NX) and Execute Disable (XD) bits are available for more than two years now and XP SP2 isn’t exactly new either — still G-Data hasn’t managed to fix its code!
Lesson learned: If you have a processor that supports NX or XD (same thing, just different marketing names from AMD and Intel) and you plan to actually take advantage of that feature, you better should check twice which software you’re going to use — especially when using closed-source software. (Linux users should be on the safe side, I haven’t see an application having problems with NX for a long time.)
I’ve removed G-Data AntiVirusKit InternetSecurity 2005 and installed F-Secure Internet Security 2005 which seems to work fine with DEP enabled globally.
Shorewall is still alive! After Shorewall creator Tom Eastep announced his departure from the project several people stepped up to continue development on Sourceforge. The website and the CVS repository already have been moved to the new site, the mailing lists are still hosted on the list.shorewall.net.
Read more on the shorewall-devel list.
Yesterday Shorewall creator Tom Eastep announced the end of Shorewall development and support.
It is sad to hear that, Tom did a great job. Shorewall is one the best firewall tools available for Linux. I sincerely hope somebody will pick up the project and continue development. If I had the time I would do it myself.
January 22nd, 2006: There’s an updated version of this guide for WordPress 2 now: Securing WordPress 2 Admin Access With SSL
As one can guess from the look of this site, I’m using WordPress as my blog engine. At this time WordPress does not support HTTPS access to the admin area when the rest of the blog is served via normal HTTP. This is a bit unfortunate. I do not like logging in to my server over unencrypted connections, especially not when using public WLANs. Getting around this WordPress limitation requires quite a few steps:
The Goal
All communication involving passwords or authentication cookies should be done over HTTPS connections. wp-login.php
and the wp-admin
directory should only be accessible over HTTPS.
Normal reading access, as well as comments, tracebacks, and pingbacks still should go over ordinary HTTP.
The Plan
- Add an HTTPS virtual host that forwards requests to the HTTP virtual host
- Modify WordPress to send secure authentication cookies, so cookies never get sent over insecure connections accidentally
- Require a valid certificate on HTTPS clients. That means to log in to WordPress you need both a valid certificate and a valid password. If someone manages to get your password, he still can not login because he does not have a valid certificate.
The Implementation
Note: This documentation assumes a Debian sarge installation with Apache 2. Some things, in particular Apache module related ones, will be different on other systems.
The server used throughout the instructions is example.org/192.0.34.166. The server’s DocumentRoot
is /blog and WordPress resides in /blog/wp. The value of WordPress’ home
option is ‘http://example.org’ and the value of its site_url
option is ‘http://example.org/wp’.
- Prepare the SSL certificates:
- Generate your own certificate authority (CA) if you don’t have one already (I’m using the makefile from OpenSSL Certificate Authority Setup for managing mine) and import it into your browser.
- Generate a certificate for the SSL server and certify it with your private CA.
- Generate a certificate for your browser and certify it with your private CA. Most browsers expect a PKCS#12 file, so generate one with
$ openssl pkcs12 -export -clcerts \ -in blogclient.cert \ -inkey blogclient.key \ -out blogclient.p12
Then import
blogclient.p12
into your browser.
- Make WordPress SSL-ready:
Apply this patch to the WordPress code. It makes the following changes:- Use secure authentication cookies in
wp_setcookie()
- Make
check_admin_referer()
working with HTTPS URLs - Disable login over XML-RPC
- Use secure authentication cookies in
- Enable the necessary Apache modules:
- Install mod_proxy_html. It will be used to replace absolute ‘http://example.org’ HTTP URLs in the WordPress output with ‘https://example.org’ HTTPS URLs:
$ aptitude install libapache2-mod-proxy-html
The module gets enabled automatically after installation.
- Enable mod_proxy and mod_ssl
$ a2enmod proxy $ a2enmod ssl
Debian provides sane default configurations for both modules. You might want to take a look at the configuration files (
ssl.conf
andproxy.conf
) nevertheless. - If you are compressing WordPress output (that is if you enabled the ‘WordPress should compress articles (gzip) if browsers ask for them’ option) then also enable mod_headers:
$ a2enmod headers
- Install mod_proxy_html. It will be used to replace absolute ‘http://example.org’ HTTP URLs in the WordPress output with ‘https://example.org’ HTTPS URLs:
- Configure Apache to listen on the HTTPS port
$ cat > /etc/apache2/conf.d/ssl.conf << EOF <IfModule mod_ssl.c> Listen 443 </IfModule> EOF
- Modify the blog virtual host to limit access to
wp-login.php
andwp-admin
to the local host. Also completely deny access to files which should never be accessed directly. Here is an example:10-example.org
- Now setup the HTTPS virtual server:
20-example.org-ssl
If you are compressing WordPress output you have to enable theRequestHeader
line. - Enable the site and restart Apache
$ a2ensite 20-blog-ssl $ /etc/init.d/apache2 restart
- Remove the old WP cookies from your browser
- Test the new setup!
I have experienced some strange behavior with my ipt_recent netfilter rules after an uptime of about 25 days. The rules started to block much too early. After rebooting the machine I was able to reproduce the problem for five minutes. This clearly indicated a problem with jiffies (Linux initialized jiffies so that the first roll-over happens five minutes after booting).
A closer look at ipt_recent.c revealed that the time tests did not work like intended if one of the last hits was more than LONG_MAX
jiffies ago or if the list of last hits contained empty slots and jiffies is greater than LONG_MAX
.
To fix this, I replaced jiffies with seconds since ’00:00:00 1970-01-01 UTC’. I have sent the patch to linux-kernel and netfilter-devel. The patch also includes some 64-bit fixes.
May 12th, 2005: The patch has been added to Linux 2.6.12-rc4-mm1
September 8th, 2005: Please note that only the 64-bit parts of my patch have made it into 2.6.12. I’m working on an updated fix for the time comparison problems which will hopefully get accepted for 2.6.14 or later.
September 12th, 2005: These issues have CAN numbers now: CAN-2005-2872 and CAN-2005-2873 (which supersede CAN-2005-2802)
July 10th, 2006: The jiffies issue is fixed in the vanilla kernel now. Also note that 2.6.18 will contain a rewrite of ipt_recent.c.