Archive

Posts Tagged ‘apache’

Using sed to search and replace contents of next line in a file.

January 24th, 2012 No comments

This example will show you how easy it is using sed to find a particular line in a file and replace all or part of the next line. In this example, using htaccess we want to deny access to all clients except a particular dynamic IP (for your home connection for instance).

Your .htaccess file might look like this:

order deny,allow
deny from all

# allow from example.dyndns.org
allow from 8.8.4.4

And your sed code to update the allowed IP address might look like this:

sed -i -r "/# allow from example.dyndns.org/I{\
n; s/([0-9]{1,3}.){3}[0-9]{1,3}/8.8.8.8/\
}" .htaccess

Let’s look at it piece by piece.

  • /# allow from example.dyndns.org/I will search the file for this string. The I flag at the end makes the search case insensitive.
  • n; will tell sed to continue processing on the next line.
  • s/([0-9]{1,3}\.){3}[0-9]{1,3}/8.8.8.8/ will regex search for an IP and replace the match with your updated IP (in this case 8.8.8.8).
  • .htaccess is of course the input file to process.

Note that in .htaccess files, comments must be on a line of their own. End of line or inline comments are not permitted. In cases where you do not need to replace a part of the next line but rather all of it, our replacement becomes s/.*/8.8.8.8/

Categories: All, Linux

Securing WordPress Dashboard using .htaccess behind CloudFlare (or any other CDN)

September 7th, 2011 No comments

You may wish to increase the security of your WordPress blog by doing this, or you may not. It’s a matter of preference. Before today I never bothered, but since I wanted to figure out how it can be done, now it makes no sense to remove the extra security.

In all cases, there are 2 areas that can be locked down from 2 separate .htaccess files. These are:

  • /wordpress/.htaccess to secure the wp-login.php file (used to log in).
  • /wordpress/wp-admin/.htaccess to secure everything under the wp-admin directory.

I want to allow only a few IP addresses to be able to access these areas. This is how it’s done without a cloud:

# add the following lines to /wordpress/.htaccess
<Files wp-login.php>
    order deny,allow
    deny from all
    allow from 93.75.252.219
    allow from 110.170.50.32
</Files>
# add the following lines to /wordpress/wp-admin/.htaccess
order deny,allow
deny from all
allow from 93.75.252.219
allow from 110.170.50.32

Access to the login and admin areas of your website are now restricted to only the IPs you allow. If however, you are using a service like CloudFlare, the above will not work because apache can’t see your (the visitor’s) IP address. Let’s fix this:

# add the following lines to /wordpress/.htaccess
<Files wp-login.php>
    SetEnvIf X-FORWARDED-FOR 93.75.252.219 allowedip
    SetEnvIf X-FORWARDED-FOR 110.170.50.32 allowedip
    order deny,allow
    deny from all
    allow from allowedip
</Files>
# add the following lines to /wordpress/wp-admin/.htaccess
SetEnvIf X-FORWARDED-FOR 93.75.252.219 allowedip
SetEnvIf X-FORWARDED-FOR 110.170.50.32 allowedip
order deny,allow
deny from all
allow from allowedip

Apache is now reading your IP address and setting the allowedip environment variable which is then whitelisted on the last line.

Note that you should *not* rely on this security measure alone since an IP address you have whitelisted can and may be spoofed. Always monitor your access logs and combine this with other security methods (such as basic authentication for example) to further increase security.

Apache virtual hosts, _default_ and ServerName

December 2nd, 2009 3 comments

I’ve recently changed my VPS provider. I won’t go into why, that’s a separate post for when I find the time and nerves to write about it.

Given the opportunity of the move, I decided to split my VirtualHost configuration out of a single httpd.conf file into per virtual-host config files. This by chance, is something that I knew that I could do since 1696 but never really realized the advantages of doing so before now.

Anyway, the mistake I made was to assign ServerName in httpd.conf to either a named or aliased VirtualHost. This caused a conflict which was solved as soon as I changed ServerName to something totally irrelevant.

Categories: All, Linux