<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride All
    ...
  </Directory>
  ...
</VirtualHost>

In order to prevent the htaccess lookups on the filesystem without losing the htaccess functionality – at least at the DocumentRoot level- I transformed the configuration to the following:

<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride None
    Include /home/example.org/public_html/.htaccess
    ...
  </Directory>
  ...
</VirtualHost>

Let’s see what we have accomplished with this:

1. httpd does not waste any time looking for and parsing htaccess files resulting in faster request processing,
2. the virtual host administrator can still override the configuration options of the document root manually or through the web interface of the web application.

Seems like a win-win situation performance and functionality wise.

But, as usual, there is no win-win situation without a downside. In this case, the above trick weakens the server’s security. Let’s see how.

Although the configuration of a directory can be set in both httpd.conf and the directory’s htaccess file, not all directives can be used in both contexts. htaccess files support a subset of the directives that can be used in the Directory context within httpd.conf. By including the htaccess file in httpd’s configuration the vhost admin is no longer restricted to that subset of directives.

This means that by implementing the above configuration the virtual host administrator is granted more privileges regarding the configuration of the virtual host. This also means that a potential attacker, that would exploit a vulnerability of the web application, would be granted the same privileges once he got write access to that htaccess file.

So, although this trick may seem like a good idea at first, it is in fact a rather bad idea and should never be used in production, unless you trust the virtual host administrator and the web application. I do not intend to use such a configuration and I do not recommend it. There are by far better ways to speed up Apache.

Your comments and suggestions are welcome.

Related Articles

• .htaccess Cheat Sheet
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Use mod_deflate to Compress Web Content delivered by Apache
• Script for Apache Error Report
• Using the mod_dav_svn SVNParentPath directive with multiple authz files

The problem lies in the way that block ciphers are used in SSL/TLS. Block ciphers are generally operated in one of several modes that define how encrypted blocks are manipulated to ensure complete confidentiality. Cipher Block Chaining, or CBC mode, is used in SSL for all block ciphers, including AES and Triple-DES. The BEAST attack relies on a weakness in the way CBC mode is used in SSL and TLS. Non-CBC cipher suites, such as those using the RC4 stream encryption algorithm, are not vulnerable.

There have been several suggested mitigations that can be put into play from the perspective of the client, such as reorganizing the way the data is sent in the encrypted stream. Servers can protect themselves by requiring a non-CBC cipher suite. One such cipher suite is rc4-sha, which is widely supported by clients and servers.

Researchers have concluded that the RC4 (Alleged RC4) based cipher suites are not vulnerable to the BEAST attack, while CBC (Cipher Block Chaining mode) based cipher suites are. This involves both the TLS 1.0 and the SSL 3.0 protocols. On the contrary, TLS 1.1 and 1.2 have not been found to be vulnerable, but their use is very limited since they haven’t been adopted by the majority of HTTP clients and servers yet.

So, the use of RC4 based ciphers is all that is left for the moment. The security experts have released a list of cipher suites that is suitable for use in the configuration of the mod_ssl module for httpd:

SSLHonorCipherOrder on
SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL

They have also released a one-liner list of ciphers suitable for use in the relevant fields of the Local Group Policy Editor in Windows Server boxes.

However, there is no info about configuring the mod_gnutls module for apache to use RC4 based ciphers, so, as a dedicated user of mod_gnutls, I decided to release this tip. All you have to do is set the preferred ciphers in the GnuTLSPriorities directive. In this example we use the TLS 1.0 protocol:

GnuTLSPriorities NONE:+VERS-TLS1.0:+ARCFOUR-128:+RSA:+SHA1:+COMP-NULL

Visiting a secure web site that has been configured using any of the methods described above and by checking the information of the secure connection to that website, you should see the following message:

Firefox message about using RC4 encryption cipher

This means that everything is working correctly.

As always, comments and suggestions are welcome and appreciated.

Related Articles

• Critical vulnerability in Adobe Reader
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• mod_gnutls binary for Apache
• Using SSH for networking
• How to configure and use LIRC

So, TOR can provide anonymity as far as the user’s ISP is concerned, but is it a secure way to communicate with remote services? If no extra encryption is used, then it is quite obvious that using remote services through the TOR network is totally insecure. Here is why.

The TOR exit-node is a key point in the communication between the user and the remote service. This is where the user’s data exits the TOR tunnel and continues its way to the remote service through the 3rd party ISP’s network. It is also the place where data from the remote service leaves the 3rd party ISP’s network and enters the TOR tunnel in order to reach the end user. If no encryption is used, it is possible for the exit-node operator to sniff this network traffic. This means that it is technically possible for an evil exit-node operator to:

• know which web pages the user visits
• read the messages the user exchanges through unencrypted IM networks
• read the emails the user sends
• if the user authenticates to any services without encryption, the evil exit-node operator could for example find out his mailbox or FTP account password or the passwords the user uses for authentication to web sites
• even if the authentication to a web service has taken place through an encrypted SSL tunnel, if the rest of the communication with this specific web service is not encrypted, the evil operator could grab a copy of the user’s session cookie for this service and access it pretending to be him

These are some of the nasty things that can happen when you access remote services through a proxy server which you do not control.

Is there any guarantee that exit node operators do not sniff network traffic?

Even if the exit-node operators are cool, who can guarantee that the network traffic is not monitored within the 3rd party ISP‘s network? If the user accesses personalized services without encryption, then, even if the user’s real IP and thus his real name is not known, various pieces of collected data can be combined together and possibly reveal his real identity. This process is widely known as re-identification.

Is there any guarantee that the ISP providing internet access to a TOR exit node does not collect and sell information to “marketers and identity thieves”?

I consider the TOR project quite important. But, since typical internet users are urged to use the TOR network in order to browse the internet, the involved risks have to be explained in detail.

On the other hand, I’d like to urge internet users to spend some time to familiarize themselves with the basics of the HTTP protocol, the concepts of HTTP authentication and cookie based authentication and the importance of encrypted HTTP connections through SSL or TLS tunnels. Since the internet has become part of your lives, regardless of your profession, you need to be educated about these things, so as to be able to realize when your communication with the various internet services is vulnerable. You don’t have to be gurus, but rather get an idea of what is going on.

So far, it is quite clear that the only way to stay on the safe side while using anonymizing proxies on which you usually do not have full control, like TOR, is to connect to any remote services using encrypted connections only, usually through SSL or TLS tunnels. Personally, I never use anonymizing networks or third party proxies. This is because I never really had the need to hide my real location. Furthermore, I find it pointless as I don’t believe that such a thing as anonymity is really feasible. If I had to use TOR, I would try to find a way to connect to the remote service over an encrypted connection. In general, whenever I need a secure SOCKS proxy, for example when I have to use a public network to access personalized internet services, which do not offer full SSL access, I use OpenSSH client’s -D switch while logging in to a SSH server which I own and fully control and thus I have all the security I need.

Related Articles

• Auto-closing SSH tunnels
• Set up the VNC Server in Fedora
• SSH Tunnels Headaches
• Netcat – a couple of useful examples
• Using SSH for networking

The importance of the GPG/PGP key expiration date

Most people set their GPG keys to never expire. There is no problem with that. Unless they lose the private key or it gets stolen or they just forget its passphrase. In such a case, the public key, which has probably been published to several key servers around the world and retrieved by an arbitrary number of other people, is practically useless and, apart from removing it from some of the keyservers, they can do absolutely nothing else about it, unless, of course, they had previously generated a revocation certificate for the public key and they still have access to this certificate. In those not so rare cases that the revocation certificate is not available, the only way to let those who have already grabbed a copy of the public key know that they should not use that key any more is by notifying them directly, which is not always possible since the actual number of the holders of that specific public key is not known.

Setting an expiration date on your keys is a very good security measure. It lets the holders of the public key know the key’s end-of-life date. On the other hand, you can always extend the key’s expiration date and send the updated key to the key servers. When others find out that your public key has expired, the very first thing they do will be to refresh it from a key server, in which case they’ll retrieve your updated public key. Even if you lose the private key or forget the passphrase or even lose the revocation certificate too, a time will come that the public key will expire, which indicates that it is invalid and should not be trusted any more. This is important.

Change the expiration date of a GPG key

In this section I describe how to extend or reset a key’s expiration date using gpg from the command line. There are probably several graphical front-ends out there that might simplify this procedure, but, since graphical frontends are not usually cross-platform, I choose to use the command-line gpg utility. So, here is how we do it.

First of all, you have to know the ID of the key you need to edit:

$ gpg --list-keys
pub   1024D/B989893B 2007-03-07 [expired: 2009-12-31]
uid                  George Notaras <gnotaras@example.org>
sub   4096g/320D81EE 2007-03-07 [expired: 2009-12-31]

The ID in question is B989893B, so we edit the key with that ID:

$ gpg --edit-key B989893B

You should have entered the gpg shell by now. To see a list of the available commands you can always invoke the help command.

First of all, list the keys so you know what you are editing:

gpg> list
pub  1024D/B989893B  created: 2007-03-07  expired: 2009-12-31  usage: SCA
                     trust: ultimate       validity: ultimate
sub  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

By default, no subkey (sub) is selected, which means that we work on the primary key (pub). It is possible to select the subkey you will be working on by invoking the key command followed by the number (index) of the subkey you wish to select. If no arguments or index ’0′ is passed to the key command, any subkey is deselected and you will be working on the primary key.

gpg> key 0
pub  1024D/B989893B  created: 2007-03-07  expired: 2009-12-31  usage: SCA
                     trust: ultimate       validity: ultimate
sub  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

Now use the expire command to set an expiration time for the primary key.

gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 2y
Key expires at 10/28/12 03:51:07
Is this correct? (y/N) y
You need a passphrase to unlock the secret key for
user: "George Notaras <gnotaras@example.org>"
1024-bit DSA key, ID XXXXXXXX, created 2007-03-07
pub  1024D/B989893B  created: 2007-03-07  expires: 2012-10-28  usage: SCA
                     trust: ultimate       validity: ultimate
sub  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

The output above indicates that the expiration date of the primary public key has been set to 2012-10-28. Note that, the expiration date has also been changed on your primary private key of the keypair. You can issue the toggle command to verify the private key’s expiration date. Don’t worry about that. It is the private subkeys, which never expire, that are actually used when you decrypt and sign data. Read more on this in a special note at the end of this section. For now, just issue the toggle command once again to return to public key editing mode.

In this example case, there is one public subkey on which we need to set a new expiration date. That’s key number 1. We select that with the key command:

gpg> key 1
pub  1024D/B989893B  created: 2007-03-07  expires: 2012-10-28  usage: SCA
                     trust: ultimate       validity: ultimate
sub*  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

Set a new expiration time on that subkey by invoking the expire command:

gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 2y
Key expires at 10/28/12 03:02:43
Is this correct? (y/N) y
You need a passphrase to unlock the secret key for
user: "George Notaras <gnotaras@example.org>"
1024-bit DSA key, ID XXXXXXXX, created 2007-03-07
pub  1024D/B989893B  created: 2007-03-07  expires: 2012-10-28  usage: SCA
                     trust: ultimate       validity: ultimate
sub* 4096g/320D81EE  created: 2007-03-07  expires: 2012-10-28  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

Now it seems that everything is set up fine. You have changed the expiration dates of your keys. You can always use the list command to list the keys. Use the toggle command to toggle between public and private key editing mode.

As a final step you need to save your changes. Invoke the save command.

gpg> save

So, now you can update the public key that is stored on the various keyservers. To achieve this use the following command. In this example, the keyserver at pgp.mit.edu is used.

$ gpg --keyserver pgp.mit.edu --send-keys B989893B
gpg: sending key B989893B to hkp server pgp.mit.edu

Enjoy.

Important Note

If you tried to use the expire command in private key editing mode, you would notice that it is not possible to change the expiration date of any subkeys in this mode. Actually, the private subkeys never expire. Although, I haven’t investigated this, common sense indicates that, since private subkeys are used to sign and decrypt data and that they are not meant to be distributed, it wouldn’t make any sense if they expired.

Theoritically speaking, the owner of an expired private key should still have the ability to decrypt data and also be able to sign data, even if all public subkeys of the current keypair have expired, since it is always possible to reset the expiration date on the currently expired public keys.

As I mentioned earlier, I haven’t investigated this, but I think that non-expiring private keys make a lot of sense.

Final Thoughts

This article described in detail how to change the expiration date of GPG/PGP keys. This should be a standard key maintenance procedure if you set an expiration date on your keys.

Setting an expiration date on your keys is not mandatory as long as you have taken other measures to protect the private key and the public key’s revocation certificate by backing it up and storing it at another location. But, in general, it is a good habit as explained in this article’s introduction. I by no means am a GPG/PGP expert. I wrote this guide because I realized that most people do not set an expiration date on their keys because they do not know how to change it and extend the key’s life or because they have not realized the importance of the expiration date or simply because they do not care. I hope you find this tutorial useful and start setting an expiration date on your keys from now on.

Related Articles

• Be your own Certificate Authority (CA)
• Setup the SSH server to use keys for authentication
• A change of plans regarding a web-based VCS manager

The permissive mode exists mainly for testing. In this mode, the auditing mechanism generates notices (AVC Denials) about the action/event that was blocked, but without actually blocking that action/event. It is just a way to check what would have happened if SELinux had been running in enforcing mode. There are two ways to switch SELinux to permissive mode. One is to configure it through its configuration file (/etc/selinux/config on EL) to start in permissive mode on boot and the other is to use the aforementioned utility, setenforce, to switch modes while the system is live.

When performing tests on a live system, I usually take all precautions to minimize the risk of failure and usually, if possible, I am around to monitor the progress of the test. But, this time I had to use the custom SELinux policy for some days to see if it is actually effective or it needs further fine-tuning.

The Mistake: I used setenforce to set SELinux into permissive mode (/usr/sbin/setenforce 0). setenforce is for temporary changes and it is definitely not suitable for testing the policy for a long period of time. This is because if for any reason the system reboots, SELinux will be set back into the mode that is defined into its configuration file. The mode set by setenforce does not survive a reboot. So, if the custom policy happens to be incomplete, it will block the server’s normal operation after the reboot. And such reboots can happen…

This is exactly what I experienced yesterday. The datacenter on which my virtual server is hosted had problems with its main power supply. This caused one hour of downtime. But G-Loaded’s outage was a lot greater, because my custom SELinux policy was incomplete. SELinux was started in enforcing mode, so my faulty policy blocked my www service.

This should be a lesson to anyone who performs tests on live systems. The Right Thing™ was simple: boot the server into permissive mode and do as many tests as desired. I can blame the datacenter for the one-hour downtime, but for the 7-hour unavailability of G-Loaded I am the only one to blame.

Related Articles

• SELinux audit reports script
• Using a switch to prevent system shutdown/reboot/suspend
• Server upgraded to Fedora 6
• Use the Alternatives System to switch to a custom Firefox release
• How to integrate seaudit-report in logwatch

Two days ago, I decided to upgrade the program to the latest version and, during installation and without giving it much thought, I installed the application’s plugin system and a plugin called “Document Monitor” or something like that. This morning my system experienced another Notepad++ freeze, but this time a Virtual Machine, which run under VirtualBox, froze too. There was heavy disk I/O at that time. The virtual system was meant to be an RPM Build Server, so I re-deployed it just to be sure that everything was all right without risking any data loss during the freeze.

After that, I disabled Notepad++’s plugin system entirely and do not intend to use any of the plugins ever again. I continue to use the core editor, but I am also looking for alternatives. So far, PSpad (freeware) and TwistPad (commercial editor at a very reasonable price) are among the candidates. I mainly use a text editor for plain text and HTML documents, Python, PHP and BASH scripts. Any other suggestions are welcome and appreciated.

Related Articles

• Mozilla Thunderbird speed up
• Dictionary Lookups Anywhere
• Zim – a Desktop Wiki
• The Read-It-Later extension
• Break-Out-Of-Frames WordPress Plugin

All current certificate owners will be offered a free one-year digital certificate for email encryption/signing by Verisign. Renewals of those certificates will cost $19.95 per email address (at the time of writing), while using Thwate’s program you could just pay an initial fee in order to verify your identity and then get your name to appear on all your digital certificates that had been issued by that service for your email addresses.

Although I believe that taking back what you have given is usually either a sign of greed and irresponsibility or proof of bad planning, I do understand Thawte’s given reasons for such a decision:

[...] for the ever-expanding standards and technology requirements will outpace our ability to maintain these services at the high level of quality we require [...]

When it comes to secure authentication or digital identification, quality is not negotiable. On the other hand, what is questionable is the high price of the certificate renewals, which do not involve any kind of paperwork and could also require no human intervention at all, provided that the initial verification of the certificate owner’s identity and the renewal procedure itself are being done correctly.

I am quite certain that there are other Certificate Authorities that offer free email certificates or email certificate programs at reasonable prices, but I didn’t have the time to check. Perhaps, a reader who has done some research on this could contribute some info.

I’ll be posting about this topic again soon. Stay tuned!

Related Articles

• Root Certificate Programs – The root of all trust
• Be your own Certificate Authority (CA)
• High traffic on the email server
• Email Notifications from a Linux System
• Project CodeTRAX discontinued

Second, but equally important, is the deletion of user accounts created automatically by bots. The characteristic of those accounts is that they have never posted any posts. All the advertising information existed in the user profile fields. After inspecting the database structure for a while, I deleted all the users with zero number of posts from the bb_users table using the following MySQL query:

DELETE FROM bb_users WHERE id IN (
  SELECT id FROM (
    SELECT DISTINCT(u.id)
    FROM bb_users AS u LEFT JOIN bb_posts AS p ON p.poster_id=u.id LEFT JOIN bb_usermeta AS m ON m.user_id=u.id
    WHERE m.meta_value LIKE "%\"member\"%" AND p.post_time IS NULL
  ) AS bb_non_posters
);

Then I deleted all the user metadata for non-existent users from the bb_usermeta table using the following query:

DELETE FROM bb_usermeta WHERE umeta_id IN (
  SELECT umeta_id FROM (
    SELECT m.umeta_id
    FROM bb_usermeta AS m LEFT JOIN bb_users AS u ON u.id=m.user_id
    WHERE u.id IS NULL
  ) AS bb_unlinked_meta
);

The above will eventually delete all user accounts and their meta data when no posts have been published by those users. That means that even legitimate users with no posts will be deleted, but such users are very rare. If your account has been deleted, please make a new one.

Normally, further clean up of the tags tables should be performed, but since those users hadn’t posted anything, it is very unlikely that they had created any tags, so I think the above are just enough.

Using the above queries I got rid of thousands of user accounts created by bots. Make sure you have backed up your database before attempting any manipulation of the data.

Related Articles

• Permanently remove deleted posts and topics in bbPress
• User management from the command line
• Lock out a user after N failed login attempts
• Modifying Your Name In The WordPress Comments
• Bot-Allow-Content and CC-Configurator plugin updates

I use the bike to move around in the city, go to the university, library, gym, etc. During the last five months, it had become a necessity. But there is one really big problem. It is impossible to keep it indoors. I have to leave it outside, in the wild.

Now, I have bought a new MTB. I really wouldn’t like it to be stolen again. That would make me extremely pissed off. During the last two weeks, I’ve read various articles about bicycle theft, about ways to properly protect a bike, et cetera. I even went out late one night, as if I was about to steal a bike, just trying to see things through a thief’s eyes and realize what the weaknesses of leaving a bike outdoors are.

I won’t be writing about any things you do not know already. A determined soul or a sophisticated thief will always get what he wants. There is nothing you can do about it. But, the good news is that sophisticated thieves are not really interested in bike theft, unless we are talking about a very expensive bike. On the other hand, a very expensive bike is very unlikely to be left outdoors at night. Sophisticated thieves are of course a problem, but not the real problem. The real problem in such cases is opportunist thieves. Usually, such thieves do not know whether the bike they have stolen is an expensive or a cheap one, whether it is in good condition or not, and they usually sell it for almost nothing afterwards. They are usually victims themselves. Junkies or people in great need for some money who would steal anything that is an easy target.

Below you will find a very small checklist with the things one should take into account in order to protect a bike which is left outside. These of course represent my own thoughts after evaluating all the things I’ve read and seen. If you can contribute to the list, be my guest. I will really appreciate it.

• Buy a real lock. Most of the locks I’ve seen in bike shops are not locks upon which you can rely for more than a few minutes. From what I’ve read, it is very easy even for opportunist thieves to bypass or destroy them and get your bike. I would say that 40-50 EUR should be the absolute minimum you should spend on a lock. Don’t waste your money on 10-15 EUR locks. Invest. Go to a motorcycle shop and buy the best lock you can afford. If you cannot afford a decent lock, buy a cheaper bike. It is (collectively) cheaper to upgrade your bike’s parts at a later time than to upgrade a lock. Opportunist thieves aim for easy targets. If they realize that the strength of the lock is beyond their abilities, they will not bother with your bike and go for an easier target. Of course, you should learn how to properly lock your bike. Even if you use the best of the locks, but attach the bike to a fixed object which is not reliable, then a thief would destroy the fixed object and get your bike. All locks can be opened. But some locks are a lot harder to be opened. Get a good lock and lock your bike wisely. It is the least you can do to protect it. I now use a lock from ABUS.
• A thief needs privacy. Do not give it to him. Locking up the bike in a shady corner may be an advantage for the thief as he will be able to work on the lock being unnoticed for a longer period of time. Make him feel uncomfortable with the spot at which you have locked your bike. Make him feel unsafe. A regular opportunist thief will not bother to steal the bike if he does not feel secure enough.

Of course, this list is not complete. There are many other things you can do to further protect the bike, but most of them really depend on the location and any other special conditions of the area you live in. Bike theft is a problem of all big cities. I will be glad to read your thoughts on what else should be done in order to protect a bike which is left outdoors at night.

Related Articles

No related articles.

Related Articles

• Adobe Reader 8 for Linux
• Evince instead of Adobe Reader in Linux
• Creative Commons v3.0 Licenses Launched
• How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability
• Best Practices of Software Licensing