Blog

Gosh, darn script kiddies!

Has your site ever been compromised through an embarrassing security hole? A few months back, a forgotten virtual machine in the DMZ part of a client's network was compromised... several times, by different people... It was amusing seeing how many modifications they made to some tables in a few databases, what they wrote, we got a pretty good kick out of it.

But it definitely got us thinking, these script kiddies go around all day, abusing zombie servers and google to find new victims, trying to hit a jackpot, hoping to find SSNs, credit card numbers or something similar. So, what can we do stop them? Well, secure that server, sure, but what else?

We could also alert people with holes in their machines, but hey, can we afford to do that? Yeah! We can, at least for visible holes those script kiddies exploit!

And on we go...

What's their modus-operandi? They look for a popular vulnerability, easy to exploit, and easy to find, with Google (the reason Google continuously makes the top-100 list of preferred security assessment tools as you can see here).

And this is exactly what we are doing, crawl the web for known security issues, try to assess if the hole is present in a particular server, try to identify the proper person to contact, either by email addresses published in websites hosted there or through the whois records, and alert them with proper information to fix this bug.

Simple enough! Yes, but we believe this could go a great length at stopping this type of attacks.

Stay tuned for more!

Hello server-owner!

We are writing you from Server Protectors to let you know that we have identified a potential security hole in your server with IP $ip. You might want to address this security issue as soon as possible since this issue can be easily found using the following query on google, $query.

CVE: $cve_data
URL affected: $url
Date: $date

You can read about why you are getting this in Server Protectors to crawl the web to alert vulnerable site owners.

How can you reduce bandwidth consumed by your website by about 30% and considerably speed it up in about 5 minutes?

mod_deflate is a great apache2 module which provides on the fly compression of your website contents. If you have deployed your webserver in the past four years chances are your are already using it. However, mod_deflate by default will only compress your text/html, text/plain and text/xml.

While it's a good idea to whitelist the type of files that are compressed (no reason to attempt to decompress a file that is already compressed, such as image files, zips, etc), we are leaving out some important files we should compress too.

With the virus-like spread of scriptaculous, jQuery and a wide set of javascript tools, and the rather complex css files we are using nowadays it makes a lot of sense adding compression support for those types of files.

And its such an easy feat too! Just add the following to your webserver configuration:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/javascript text/css

And restart with

[ -e /etc/init.d/httpd ] && /etc/init.d/httpd restart
[ -e /etc/init.d/apache2 ] && /etc/init.d/apache2 restart

and that's it! All your website's files are now being transmitted using compression.

Want to see how much you gained from this? Add the following to your configuration and see the compression ratio achieved.

DeflateFilterNote Input input_info
DeflateFilterNote Output output_info
DeflateFilterNote Ratio ratio_info
LogFormat '"%r" %{output_info}n/%{input_info}n (%{ratio_info}n%%)' deflate
CustomLog /var/log/apache2/deflate_log deflate

And have a look at the /var/log/apache2/deflate_log file to see the compression rate.

Trade off

So what is the trade of of doing this? Just a little CPU time, you might want to check your system load to make sure your system's bottleneck is not the CPU before doing this.

Enjoy!

We have recently helped a customer with a problem in their MySQL database and thought we should share that with everybody.

The problem was that due to a server move at their hosting company, their data in MySQL became scattered throughout different databases with the same structure. As a result of this the first host, host1, had data from before the move, a few days *after* the move up to two days ago (when the user realized that data was not being stored in localhost but on their previous server) and, the second host had data from before the move and data since the last 2 days.

In order to merge that data we created a backup of each database on one of the mysql installations:

for i in database1 database2 database3 databas4; do
        mysqldump -n -t -q $i > host1_$i.sql
done

Once those were created we took those files to the now active host, host2 and issued the following:

sed -i'' -e 's/^INSERT/REPLACE/'  host1_database1.sql host1_database2.sql host1_database3.sql host1_databas4.sql

What that statement does is change the INSERT INTO statements to REPLACE INTO statements, REPLACE provides a way to insert data that could be duplicated on a table, deleting a row if it already existed on that table before doing the insert. This will effectively leave on the database the data that was not on the backup and insert in a way that appears only once the data that was on the backup (regardless of the data being or not on the original database).

After that its a matter of putting the data in

mysql> use database1
mysql> \. host1_database1.sql
mysql> use database2
mysql> \. host1_database2.sql
mysql> use database3
mysql> \. host1_database3.sql
mysql> use database4
mysql> \. host1_databas4.sql

And that's it! Data is now merged! Remember to create a backup of your current database before doing this!

We have reached a very important milestone today, we have delivered the 1,000 purchase of SECS! We are very excited about this and appreciate the support our customers give us! Thank you!