Author Archives: Rudy Amid

WWW Prefix Is Superfluous

HTTP WWW

When Tim Berners-Lee made famous the “World Wide Web” by introducing the HTTP protocol, he set the standard that all web sites would start with “www” as a host name prefix. It was supposed to indicate it’s a web site, for everyone who hadn’t seen this new way of using the Internet.

That was the early 90’s.

Now, 20+ years later, the World Wide Web is as ubiquitous as e-mail or postal code addresses. Everyone knows what to do when they open a browser.  Even better, when someone receives an email with a web link (URL) in it, even though it’s not safe to click on any random links via email if source of information is not checked.

So why do web developers and content managers still tag on the prefix www into their host names?  Perhaps, out of habit because that’s how they learned to use the Internet from 20 years ago.  Maybe the fault is with e-mail servers, like Microsoft Exchange, creating automatic hyperlinks whenever “www.” is in the text, which makes it easier for mailing list managers to create content without deliberately hyperlinking URLs.

Whatever is the reason, people need to stop adding the prefix www when entering a web address. It’s a pain to setup on the server and network sides because DNS have to contain both entries (as alias or A records), web servers need to accept both host names, and SSL certificates have to be requested with www as a common name.

Besides, without the www prefix, it’s easier to tell someone (written or verbal) of the website’s shorter address. Nowadays, the prefix is superfluous and unnecessary.

Re-purpose An Old Google Search Appliance

I managed to get my hands on a pair of old Google Search Appliance (GB-7007) boxes. I wanted to see if I could re-purpose them for some other task other than a search engine.  Under that bright yellow “Google” hood, it’s a Dell motherboard, with over 40GB memory and 2 Quad-cores CPU’s.  Since it’s a standard PC, it’s a matter of finding the right BIOS.

This is where the service tag comes in handy.  Using Dell Product Support page, I was able to identify the box’s Dell server product.  In my case, it’s the PowerEdge R710.  I found the BIOS update through the PowerEdge R710 support page and downloaded it to a bootable USB drive.

Before proceeding with the BIOS update, I read Dave Hope‘s post on getting his GSA reconfigured.  He suggested to remove the jumper labelled PWRD_EN, which disabled the password to get into the BIOS.  After changing the boot order, I used the USB drive and went through the update.  As Dave also noted, the executable may complain it can not erase the Google Search Appliance BIOS, but can be forced to do an update anyway using the switch “/forcetype”.

Now it’s just a matter of running diagnostics and finally boot a CentOS or Ubuntu DVDs to re-install a new Linux OS.

Heartbleed: A Scrambled Egg with Lots of Ham

CVE-2014-0160The sensational headline news this week was “Heartbleed” security flaw, which was covered by most mainstream and tech sites.  It was an old bug that was accidentally introduced, and just discovered recently1. The report got IT professionals scrambling to fix their systems.

At first glance, the bug is benign enough, with chances of hacking the passwords or SSL keys rather slim. However, like any other hacking issues, if someone is determined (and clever) enough to exploit this bug, they may just get a bunch of useful data. Whether or not they can use the hacked data to steal client information, or use it for a phishing site, it’s unclear. Just the thought of the potential leak scares the daylights out of everyone! It’s also proof that the marketing behind this bug was very effective.

Regardless, the actions need to be taken are as follows:

  1. Check with Qualys SSL Analyzer to determine if your site is vulnerable.
  2. If vulnerable, upgrade OpenSSL to version 1.0.1g, or alternatively recompile OpenSSL without the “heartbeat” option (-DOPENSSL_NO_HEARTBEATS).
  3. Recompile or restart the web server to reload the latest OpenSSL libraries.
  4. Test the site(s) with the Qualys SSL Analyzer again.  Also check if site is functional.
  5. With the new OpenSSL, generate a new SSL key, and re-key a new certificate.  Install the new key/certificate in the web server(s).
  6. Urge the users to change their passwords – which they occasionally have to do, anyway.  This step is tricky considering the PR scare that it’s going to generate when admitting the site is vulnerable.  However, the notification is the responsible thing to do.

When the dust settles, we can look back and use this as an important reminder how fragile the Internet is.  Customers are expected to be cautious of their data being transmitted over the Internet, no matter how secure a company claim they’re being kept.

  1. Introduced in 2011 and found out in February 2014 []