The issue is the additional computing now on offer, in particular the processing power of the chips now the norm on graphics cards.

The researchers have discovered that the number-crunching power of modern graphics cards could offer a new way of cracking passwords, with their power on par with multi-million dollar supercomputers built just a decade ago.

The research found seven character passwords ‘hopelessly inaccurate’ and with processing power increasing year on year, a combination of upper-case, lower-case, numerals and symbols in a 12 character password offered better protection.

Do you think passwords are becoming an unsafe security measure?

What we heard is that the systems acted totally normal, except for the fact that it ran ssh brute force attacks against several randomly chosen remote servers. So what happened?

The attacker used a vulnerability in phpMyAdmin, which once had been installed, used one or two times, and then forgotten (version 2.10.xx or so..). Sadly enough, whoever installed phpMyAdmin did not remove the setup.php file (which you are encouraged to do in the readme). This setup.php was the attackers starting point. He/she injected a ssh client running as root in /tmp/dd_ssh that started about 100 child processes.

The cleanup was as follows:

• Removed phpMyAdmin
• Removed all suspicious files in /tmp
• Restarted the network interfaces
• Changed all user passwords
• Installed fail2ban
• Changed /tmp to be non-executable

Suggestions for today:

• Keep your phpMyAdmin up to date
• Search for installations on all your servers NOW!
• Do NOT install in a folder named “phpmyadmin”, “sqladmin” or similar. Use a non-guessable name.
• Protect it at least using htaccess
• Last but not least: if you can access your server via ssh, there’s no need for phpMyAdmin. Setup a ssh tunnel, use your favourite mySQL GUI, and bingo, you’re safe.

We advise our clients not to install their own phpMyAdmin on their domains, and just use our versions that we supply.

Colossal new domain extension .co has just become available. The country code for Colombia, .co is also a great choice for company, commerce or community websites.

Demand for .co domains is sky high, but hopefully your preferred name is still available for registration. So don’t hang about, secure your .co – before someone else does.

Find your .co domain name now >

Applications Must Be Safe

A user must not be able to harm your site in any way by modifying a URL that points to your applications. In order to ensure your site’s safe, check all the GET variables coming from your visitors (We think it’s trivial to mention that the POST variables are a must to examine).

For example, imagine we have a simple script that shows all the products in a category.o Generally, it’s called like this:

app.php?target=showproducts&categoryid=123

But what will this application do if ScriptKiddie(tm) comes and types this in his browser:

app.php?target=showproducts&categoryid=youarebeinghacked

Well, many of the sites I’ve seen will drop some error message complaining about use of the wrong SQL query, invalid MySQL resource ID, and so on… These sites are not secure. And can anyone guarantee that a site-to-be-finished-yesterday will have all the parameter verifications –even in a programmer group having only 2 or 3 people?

Applications Must Be Search-Engine Friendly

It’s not generally known, but many of the search engines will not index your site in depth if it contains links to dynamic pages like the one mentioned above. They simply take the “name” part of the URL (that’s everything before the question mark, which contains the parameters that are needed for most of the scripts to run correctly), and then try to fetch the contents of the page. To make it clear, here are some links from our fictitious page:

app.php?target=showproducts&categoryid=123
app.php?target=showproducts&categoryid=124
app.php?target=showproducts&categoryid=125

Unfortunately, there’s a big chance that some of the search engines will try to download the following page:

app.php

In most cases calling a script like this causes an error – but if not, I’m sure it will not show the proper contents the link was pointing to. Just try this search at google.com:

“you have an error in your sql syntax” .php -forum

There are both huge bugs and security in the scripts listed — again, these scripts are not search-engine friendly.

Applications must be user-friendly

If you application uses links like:

http://www.down.com/?category=34769845698752354

then most of your visitors will find it difficult to get back to their favourite category (eg. Nettools/Messengers) every time they start from the main page of your site. Instead, they’d like to see URLs like this:

http://www.down.com/Nettools/Messengers

It’s even easier for the user to find (pick) the URL from the browsers’ drop-down list as they type into the Location field (though of course this only works if the user has visited that previously).

And what about you?

Now you have everything you need to answer the following questions:

• Is your site really safe enough?
• Can you protect your site from hackers?
• Are your Websites search-engine compatible?
• Are the URLs on your site ‘user friendly’ – are they easy to remember? …and would you like it to be?

What is the mod_rewrite Solution, Exactly?

But what does it exactly do? Hey! Here comes the whole point of this article!

mod_rewrite catches URLs that meet specific conditions, and rewrites them as it was told to.

For example, you can have a non-existing

http://www.mysite.co.uk/anything

URL that is rewritten to:

http://www.mysite.com/deep/stuff/very_complicated_url?text=

having_lots_of_extra_characters

Did you expect something more? Be patient…

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^/shortcut$ /complicated/and/way/too/long/url/here
</IfModule>

Of course this, too, should go into the .htaccessttpd.conf file.

After you restart Apache (you’ll get used to it soon!) you can type this into your browser:

http://mysite.co.uk/shortcut

If there’s a directory structure /complicated/and/way/too/long/url/here existing in your document root, you’re going to be “redirected” there, where you’ll see the contents of this directory (eg, the directory listing, index.html, whatever there is).

To understand mod_rewrite better, it’s important to know that this is not true redirection. “Classic” redirection is done with the Location: header of the HTTP protocol, and tells the browser itself to go to another URL. There are numerous ways to do this, for example, in PHP you could write:

<?
// this PHP file is located at http://localhost/shortcut/index.php
header
("Location: /complicated/and/way/too/long/url/here");
?>

This code shows the same page by sending a HTTP header back to the browser. That header tells the browser to move to another URL location instantly. But, what mod_rewrite does is totally different: it ‘tricks’ the browser, and serves the page as if it were really there – that’s why this is an URL rewriter and not a simple redirector (you can even verify the HTTP headers sent and received to understand the difference).

But it’s not just shortening paths that makes mod_rewrite the “Swiss Army Knife of URL manipulation”…

Rules

You’ve just seen how to specify a really simple RewriteRule. Now let’s take a closer look…

RewriteRule Pattern Substitution [Flag(s)]

RewriteRule is a simple instruction that tells mod_rewrite what to do. The magic is that you can use regular expressions in the Pattern and references in the Substitution strings. What do you think of the following rule?

RewriteRule /products/([0-9]+) /siteengine/products.php?id=$1

Now you can use the following syntax in your URLs:

http://mysite.co.uk/products/123

After restarting Apache, you’ll find this is translated as:

http://mysite.co.uk/siteengine/products.php?id=123

If you use only ‘fancy’ URLs in your scripts, there will be no way for your visitor to find out where your script resides (/siteengine in the example), what its name is (products.php), or what the name of the parameter to pass (productid) is! Do you like it? We’ve just completed two of our tasks, look!

• Search-engine compatibility: there are no fancy characters in the URL, so the engines will explore your whole site
• Security: ScriptKiddie(tm)-modified URLs will cause no error, as they’re verified with the regular expression first to be a number – URLs with no proper syntax can’t even reach the script itself.

Of course, you can create more complex RewriteRules. For example, here’s a set of rules:

RewriteRule ^/products$ /content.php
RewriteRule ^/products/([0-9]+)$ /content.php?id=$1
RewriteRule
^/products/([0-9]+),([ad]*),([0-9]{0,3}),([0-9]*),([0-9]*$)
/marso/content.php?id=$1&sort=$2&order=$3&start=$4

Thanks to these rules we can use the followings links in the application:

• Show an opening page that contains product categories: http://somesite.co.uk/products
• Product listing, categoryid is 123, page 1 (as default), default order: http://somesite.co.uk/products/123   http://somesite.co.uk/products/123,,,,
• Product listing, categoryid is 123, page 2, descending order by third field (d for descending, 3 for third field): http://somesite.hu/products/123,d,3,2

This is also an example of the use of multiple RewriteRules. When there’s a RegExp match, the proper substitution occurs, mod_rewrite stops running and Apache serves the page with the substituted URL. Should there be no match (after processing all the rules), a usual 404 page comes up. And of course you can also define one or more rules (eg. ^.*$ as last pattern) to specify which script(s) to run depending on the mistaken URL.

The third, optional part of RewriteRule is:

RewriteRule Pattern Substitution Flag(s)

With flags, you can send specific headers to the browser when the URL matches the pattern, such as:

• ‘forbidden‘ or ‘f‘ for 403 forbidden,
• ‘gone‘ or ‘g‘ for 410 gone,
• you may also force redirection, or force a MIME-type.

You can even use the:

• ‘nocase‘ or ‘NC‘ flag to make the pattern case-insensitive
• ‘next‘/N‘ to loop back to the first rule (‘next round‘ — though this may result in an endless loop, be careful with it!)
• ‘skip=N‘/'S=N‘ to skip the following N rules

…and so on.

We hope you feel like we’ve felt while playing around with this module for the first time!

Conditions

But that’s not all! Though RewriteRule gives you an opportunity to have professional URL rewriting, you can make it more customized using conditions.

The format of the conditions is simple:

RewriteCond Something_to_test Condition

Any RewriteCond condition affects the behaviour of the following RewriteRule, which is a little confusing, as RewriteCond won’t be evaluated until the following RewriteRule pattern matches the current URL.

It works like this: mod_rewrite takes all the RewriteRules and starts matching the current URL against each RewriteRule pattern. If there’s a RewriteRule pattern that matches the URL, mod_rewrite checks if there are existing conditions for this RewriteRule, and if the first one returns true. If it does, the proper substitution will occur, but if not, mod_rewrite looks for remaining conditions. When there are no more conditions, the subsequent RewriteRule is checked.

This way you can customize URL rewriting using conditions based on practically everything that’s known during a HTTP transfer in Apache — and a lot more! Basically you can use all of these variables in the Something_to_test string:

• HTTP header variables: HTTP_USER_AGENT, HTTP_REFERER, HTTP_COOKIE, HTTP_FORWARDED, HTTP_HOST, HTTP_PROXY_CONNECTION, HTTP_ACCEPT
• Connection & request variables: REMOTE_ADDR, REMOTE_HOST, REMOTE_USER, REMOTE_IDENT, REQUEST_METHOD, SCRIPT_FILENAME, PATH_INFO, QUERY_STRING, AUTH_TYPE
• Server internal variables: DOCUMENT_ROOT, SERVER_ADMIN, SERVER_NAME, SERVER_ADDR, SERVER_PORT, SERVER_PROTOCOL, SERVER_SOFTWARE
• System variables: TIME_YEAR, TIME_MON, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_SEC, TIME_WDAY, TIME
• mod_rewrite special values: API_VERSION, THE_REQUEST, REQUEST_URI, REQUEST_FILENAME, IS_SUBREQ

The condition can be a simple string or a standard regular expression, with additions like:

• <, >, = simple comparison operators
• -f if Something_to_test is a file
• -d if Something_to_test is a directory

As you can see, these are more than enough to specify a condition like this one (taken from the mod_rewrite manual):

RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
RewriteRule ^/$ /homepage.max.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
RewriteRule ^/$ /homepage.min.html [L]
RewriteRule ^/$ /homepage.std.html [L]

When a browser requests the index page, 3 things can happen:

• browser with a Mozilla engine the browser will be served homepage.max.html
• using Lynx (character-based browser) the homepage.min.html will open
• if the browser’s name doesn’t contain ‘Mozilla’ nor ‘Lynx’, the standard homepage.std.html file will be sent

You can even disable users from accessing images from outside your server:

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://localhost/.*$ [OR,NC]
RewriteCond %{HTTP_REFERER} !^http://mysite.co.uk/.*$ [OR,NC]
RewriteCond %{HTTP_REFERER} !^http://www.mysite.co.uk/.*$ [OR,NC]
RewriteRule .*\.(gif|GIF|jpg|JPG)$ http://mysite.co.uk/images/bad.gif [L,R]

But of course, there are endless possibilities, including IP- or time-dependant conditions, etc.

For Advanced Users

We mentioned user-friendliness in the introduction, and haven’t dealt with it. First, let’s imagine we’re having a huge download site that has the downloadable software separated into categories, each with a unique id (which is used in the SQL SELECTs). We could links like open.php?categoryid=23487678 to display the contents of a category.

To ensure that our URLs were easily memorized (eg. http://www.downloadsite.com/Nettools/Messengers) we could use:

RewriteRule ^/NetTools$ /test.php?target=3
RewriteRule ^/NetTools/Messengers$ /test.php?target=34

assuming the ID is 3 for the NetTools category and 34 for Messengers subcategory.

But our site is huge, as we’ve mentioned – who wants to hunt down all the IDs from the database, and then edit the config file by hand? No-one! Instead, we can use the mapping feature of mod_rewrite. Map allows us to provide a replacement-table – stored in a single text file — within a hash file (for fast lookups), or even served through an external program!

For better performance I’d generate a single text file using PHP, which contains the following:

NetTools            3
NetTools/Messengers 34
.
.
.
and so on.

The .htaccess file would contain:

RewriteMap categories txt:/path/to/file/categoryids.txt
RewriteRule ^(.*)$ open.php?categoryid=${categories:$1|0}

These lines tell mod_rewrite to read the categoryids.txt file upon Apache startup, and provide the ID for the URL for open.php. The |0 means that categoryid will be 0 if there’s no matching key in the textfile.

You can also choose to serve the IDs on-the-fly via a script or other executable code. The program is started by Apache on server startup, and runs until shutdown. The program must have buffered I/O disabled, read from the stdin, and write results to stdout — it’s that simple!

With RewriteMap you can do a lot more, including:

• load balancing through servers (using rnd:),
• creation of a Webcluster that has an homogenous URL layout,
• redirection to mirror sites without modifying your Web application,
• denial of user access based on a hostlist,

and so on.

Tips, Tricks and Advice

1. Before using mod_rewrite in a production server, I’d recommend setting up a testserver (or playground, whatever you prefer to call it).
2. During development, you must avoid using ‘old-fashioned’ URLs in your application.
3. There might still be need to verify data passed through the URL (passing non-existing — too large or small – IDs, for example, might be risky).
4. Writing ‘intelligent’ RewriteRules saved me coding time and helped me write simpler code. Using error_reporting(E_ALL); everywhere (and we recommend it!), but I find it boring to do the following for the ten thousandth time:if (isset($_GET['id']) && (validNumber($_GET['id']))
if (isset($_GET['todo']) && ($_GET['todo']=='deleteitem'))

   The following trick helped to get rid of the extra isset() expression by providing all the needed parameters each time in the RewriteRules:

   RewriteRule ^/products/[0-9]+$ products.php?id=$1&todo=

   I know, I know it’s not the answer to the meaning of life — but it’s hard to show how nice and clear a solution this might provide in such a short example.

Finally…

That’s all for our ‘brief’ overview of mod_rewrite. After you’ve mastered the basics, you’ll find you can easily create your own rules. If you like the idea of URL rewriting, may want to play with mod_rewrite – some ideas follow (note that the underlying PHP code is not important in this case):

http://www.mysite.co.uk/1/2/3/content.html
=> 1_2_3_content.html

=> content.php ? category=1

http://www.mysite.co.uk/1/2/3/

=> content.php ? category=1 & subcat1 = 2 & subcat2 = 3

http://www.mysite.co.uk/1/2/3/details

=> content.php ? category=1 & subcat1 = 2 & subcat2 = 3

http://www.mysite.co.uk/bookshop/browse/bytitle

=> library.php ? target=listbooks & order = title

http://www.mysite.co.uk/bookshop/browse/byauthor

=> library.php ? target=listbooks & order = author

http://www.mysite.co.uk/bookshop/product/123

=> library.php ? target=showproduct & itemid=123

http://www.mysite.co.uk/bookshop/helpdesk/2
=> library.php ? target=showhelp & page=2

=> library.php ? target=reg

Please, urge your clients to immediately apply the security patch released by Internet Brands Company at: http://bit.ly/9QIgDj

For more information about this security exploit, go to: http://bit.ly/9rKipU
Thank you

Much like the Gumblar attacks around the same time last year, we suggest that you keep the Web Applications running on your websites up to date. This  includes WordPress installations, or any other CMS which needs regular updates.

Here are a few things that you can keep in mind:

• Always keep strong FTP Passwords (changing these from time to time is a good practice)
• Scan your local system with a good AntiVirus and Malware remover to make sure the system is infection free (Especially the machine used to upload data)
• Avoid 777 permissions on any file or folder.

On our part, you can rest assured that we are taking all measures possible to avoid any such hack on our servers.

Fortunately, we do not have any instances of such an attack on our servers yet. While we are doing everything we can to safeguard you from such an attack, we will need you to be vigilant and proactive in taking all precautionary measures.

Do you know of any other awesome (free) screen savers out there?

http://www.reallyslick.com

The new prices for .COM and .NET will be £7.00

Important:

• These prices will be applicable from the 30th of June, 2010 at 14:30;
  
• The prices mentioned will be applicable on .COM and .NET Domains only. The prices for .BIZ, .INFO, .ORG and .NAME Domains will not be modified;
• These prices are applicable to all years of Registration, Renewal and Transfer-in.

For the curious hacker who has somehow gained access to your computer system this is the equivalent of locking your door and leaving the key under the doormat. Without even resorting to any specialised tools a hacker can discover your basic personal information – name, children’s name, birthdate, pet names, etc. and try all of those out as potential passwords.

To create a secure password that is easy for you to remember, follow these simple steps:

1. Do not use personal information. You should never use personal information as a part of your password. It is very easy for someone to guess things like your last name, pet’s name, child’s birth date and other similar details.
2. Do not use real words. There are tools available to help attackers guess your password. With today’s computing power, it doesn’t take long to try every word in the dictionary and find your password, so it is best if you do not use real words for your password.
3. Mix different character types. You can make a password much more secure by mixing different types of characters. Use some uppercase letters along with lowercase letters, numbers and even special characters such as ‘&’ or ‘%’.
4. Use a passphrase. Rather than trying to remember a password created using various character types which is also not a word from the dictionary, you can use a passphrase. Think up a sentence or a line from a song or poem that you like and create a password using the first letter from each word.For example, rather than just having a password like ‘yr$1Hes’, you could take a sentence such as “I like to read about security” and convert it to a password like ‘!l2rAs”. By substituting the number ’2′ for the word ‘to’ and using an exclamation point in place of the ‘I’, you can use a variety of character types and create a secure password that is hard to crack, but much easier for you to remember.
5. Use a password management tool. Another way to store and remember passwords securely is to use some sort of password management tool. These tools maintain a list of usernames and passwords in encrypted form. Some will even automatically fill in the username and password information on sites and applications.

Using the tips above will help you create passwords that are more secure, but you should still also follow the following tips:

• Use different passwords. You should use a different username & password for each login or application you are trying to protect. That way if one gets compromised the others are still safe. Another approach which is less secure, but provides a fair tradeoff between security and convenience, is to use one username and password for sites and applications that don’t need the extra security, but use unique usernames and more secure passwords on sites such as your bank or credit card companies.
• Change your passwords. You should change your password at least every 30 to 60 days. You should also not re-use a password for at least a year.
• Enforce stronger passwords: Rather than relying on every user of the computer to understand and follow the instructions above, you can configure Microsot Windows password policies so that Windows will not accept passwords that don’t meet the minimum requirements.

Below is a list of the top 5 tips that most WordPress administrators do not do, but should:

1. Don’t use the admin account – The default user account that is created with every installation of WordPress is the admin account. Unfortunately the entire world knows this, including hackers, and can easily launch a dictionary attack on your website to try and guess your password. If a hacker already knows your username that’s half the battle. It’s highly recommended to delete or change the admin account username.

2. Move your wp-config.php file – Did you know since WordPress 2.6 you can move your wp-config.php file outside of your root WordPress directory? Most users don’t know this and the ones that do don’t do it. To do this simply move your wp-config.php file up one directory from your WordPress root. WordPress will automatically look for your config file there if it can’t find it in your root directory.

3. Change the WordPress table prefix – The WordPress table prefix is wp_ by default. You can change this prior to installing WordPress by changing the $table_prefix value in your wp-config.php file, we recommend an unique value such as rtyujikj_. If a hacker is able to exploit your website using SQL Injection, this will make it harder for them to guess your table names and quite possibly keep them from doing SQL Injection at all.

4. Use Secret Keys – This is probably the most followed security tip on the list, but still amazed at how many people don’t do this. A secret key is a hashing salt that is used against your password to make it even stronger. Secret keys are set in your wp-config.php file. Simply visit https://api.wordpress.org/secret-key/1.1 to have a set of randomly generated secret keys created for you. Copy the 4 secret keys to your wp-config.php file and save. You can add/change these keys at any time, the only thing that will happen is all current WordPress cookies will be invalidated and your users will have to log in again.

5. htaccess lockdown – This is actually my favorite tip from my presentation. Using a .htaccess file you can lockdown your wp-admin directory by IP address. This means only IP addresses you specify can access your admin dashboard URLs. This makes it impossible for anyone else to try and hack your WordPress backend. To do this simply create a file called .htaccess and add the following code to your file, replacing xxx.xxx.xxx.xxx with your IP address:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Access Control"
AuthType Basic
order deny,allow
deny from all
#IP address to Whitelist
allow from xxx.xxx.xxx.xxx

You can add more “allow from” lines so make sure to add any IP addresses you plan on accessing your site from (ie Home, Work, etc). Remember most ISP use dynamic IPs, so your IP address may change on reconnecting to your ISP. If you get locked out just update your .htaccess file or delete it all together. This obviously is not a good tip if you allow open registrations as you need to allow your users access to wp-admin.

So, how many of these tips do you follow regularly?