Author Archive: Mark Ridlen

August 5, 2010

Security Myths part 2

Security Myth #4: A hardware firewall will stop the evil hackers from the internet. They also stop viruses and spam emails.

The Facts: A hardware firewall will filter your traffic based on a set of rules. If properly configured, this will certainly harden your system from certain types of attacks. However, if you want to stop intrusion attempts on your server, you probably want to implement brute force protection or intrusion detection (IDS). Most operating systems nowadays include brute force protection in one form or another (although it may not be turned on by default). If you want an IDS, there are several options available. Here at SoftLayer, we offer McAfee Host Intrusion Protection System (or HIPS for short) for Windows systems. This will offer you some additional protection against intrusion attempts, but it is no substitute for a well patched system with strong passwords. This is especially important to know if you contract with an outside agency to configure your firewall for you. It’s easy to delude yourself into a “set it and forget it” attitude toward security. I can’t tell you how many administrators I’ve talked to that have asked “how did I get hacked? I had a firewall!”

The Side Effects:

  • Having a hardware firewall means an additional step to allow access to ports. Can be time consuming.
  • Having a hardware firewall can potentially mean an additional point of failure.
  • Too many rules can mean degraded performance.

Security Myth #5: I run a Unix/Linux based system, so I can’t get hacked.

The Facts: I have seen a fair share of Unix based systems get hacked, simply because the user is unfamiliar with the OS. Running everything from within a control panel is convenient, but make sure you or one of your administrators is familiar with command line access.

The Side Effects:

  • Running a control panel can cause more security holes

Security Myth #6: I have my Wordpress (or other web application) patched to the latest version, so I should be fine.

The Facts: WordPress is a piece of cake to install. You don’t even need to know how to code in HTML. This means you can install it and have it working properly, and still forget to correct your filesystem permissions. You need to make sure that you read the installation documentation and complete all steps. If you just stop reading once the application starts working, you could potentially forget to correct your permissions and someone could gain access as an administrative user. I ran into a situation one time where a user was utilizing a web interface to manage an online marketplace. I was shocked to find out that the link he sent me allowed me in without the use of a password! Make sure that your application doesn’t use the default password or a blank password.

The Side Effects:

  • Having the latest version is great, but make sure you take a 360 degree look around to make sure nothing is out of place

Security Myth #7: I am getting SPAM messages, but I have a firewall.

The Facts: A firewall does not filter SPAM messages. You might look into the free SpamAssassin software that will filter email for potential SPAM.

July 27, 2010

Security Myths Part 1

The world of IT security is full of partial truths and paranoia - some of which is completely justified. Sometimes, steps are taken that actually are beneficial, but without knowing the reason behind the precautions, many administrators are lulled into a false sense of security. Here are some common misconceptions that I see in action frequently:

Security Myth #1: If I set my password strong enough, my system will be secure.

The Facts: There are many ways to compromise a system. For example: exploitable code on your website, lax filesystem permissions, and publicly accessible services running on your system (such as email or chat). In fact, having a long secure password is often like having a steel security door with retinal scan technology on a grass hut. Don’t get me wrong, having strong passwords is a great thing, but don’t forget to look at the rest of your system!

The Side Effects:

  • Longer passwords take longer to type (obviously).
  • You are more likely to forget a longer password.
  • You are more likely to mistype a longer password (and get locked out).
  • If you force this policy on your end users they are more likely to write the password down (bad).

Security Myth #2: If I replace letters with their corresponding l33t speak numbers (e.g. hello -> h3110), it will make my password more secure.

The Facts: Technically, yes it will make your password more secure, but only marginally. Simple character substitution is a common feature among brute force tools. This will slow down the brute force attack, but your system may still eventually be compromised by a hybrid dictionary attack. You might also consider configuring the brute force protection options on your server.

The Side Effects: There are no side effects - in fact, this is a far greater idea than simply using a dictionary word. However, it is best to also add some additional numbers or letters to throw off brute force tools. Many brute forcers also allow for pre-pending or post-pending a string of numbers (e.g. 123hello or hello123). It is better to place random numbers or characters in the middle of your password so that it is not vulnerable to a dictionary attack (e.g. hagen!23daas). Another alternative to a secure and easy to remember password is make an acronym of a famous phrase or quote. For example: “sticks and stones may break my bones” -> “S&smbMb!$”.

Security Myth #3: If I change the port number for RDP/SSH/Plesk or turn off ping response, my server will be safe.

The Facts: This is the myth of “security through obscurity.” Changing your port number or turning off ping will only reduce attacks from computer worms and extremely lazy hackers. Say for example that you run a website on your server. Anyone who knows the URL of the website can easily find your IP address (by ping or nslookup). Then all they have to do is port scan that IP address (using a port scanning tool such as nmap or SuperScan) to see which ports are open. If your passwords are secure enough, you needn’t worry too much about the brute force attacks from the internet. You should only consider this a secondary safeguard just in case the server happens to have a vulnerable service running on it. Your first priority is making sure your system is properly patched and updated.

The Side Effects:

  • It is very difficult to track or troubleshoot packet loss on servers that have ICMP blocked.
  • Changing ports may confuse your users.
  • You will need to remember to include this port information in any technical support request.
  • Many automated systems or scripts will require custom configuration.
June 24, 2010

HTML 5 Video

If you haven't heard the buzz about HTML5, you should check out the many features and improvements. It has support for cool stuff like SVG and MathML, but one of the most impressive things it can accomplish is embedding streaming videos with no required flash player or java applet. The old way of video streaming usually involves first converting your video into the proprietary flash ".flv" format. Then you add many lines of ugly code, filled with frequently redundant information, like this example courtesy of YouTube:

<object width="480" height="385">
<param name="movie" value=";hl=en_US&amp;fs=1&amp;"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed src=";hl=en_US&amp;fs=1&amp;" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed>

In HTML5, all this can be replaced by something as clean and simple as the tag. Here is an example of what it looks like in action:

<video width="640"  height="360" src="./movies/movie1.mp4"  controls autobuffer>

Much cleaner, right?

Sadly, this is not without its caveats. First of all HTML5 is not yet a finalized standard, so the various browsers will handle it differently. Secondly, Internet Explorer does not yet support HTML5 (surprise, surprise!), although the upcoming IE9 will provide support for it. This brings me to the first major hurdle:

Currently, there is no universal codec/container combination that will satisfy all HTML5 browsers.

This means that if you desire to use HTML5 video, you will need to encode your video at least twice. The two "official" combinations are Ogg/Theora/Vorbis and MP4/H.264/AAC. The Ogg combo works on Firefox and Opera, whereas the MP4 combo works with Safari, iPhone, Android, and the upcoming IE9.

Check out for more detailed information.

Once you have your videos encoded and uploaded, you'll need to set it up in your code. The guide recommends having 3 codecs (with webm, which is a soon-to-be standard) and Flash fallback, but in the future various browsers should have a more uniform codec support:

<video id="movie" width="320" height="240" preload controls>
<source src="pr6.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' />
<source src="pr6.webm" type='video/webm; codecs="vp8, vorbis"' />
<source src="pr6.ogv" type='video/ogg; codecs="theora, vorbis"' />
<object width="320" height="240" type="application/x-shockwave-flash"
<param name="movie" value="flowplayer-3.2.1.swf" />
<param name="allowfullscreen" value="true" />
<param name="flashvars" value='config={"clip": {"url": "", "autoPlay":false, "autoBuffering":true}}' />
<p>Download video as <a href="pr6.mp4">MP4</a>, <a href="pr6.webm">WebM</a>, or <a href="pr6.ogv">Ogg</a>.</p>

You'll notice the optional mime types and codecs as additional attributes. This is really just error proofing your code. It will make sure that it will have browser interoperability, and browsers won't have to download the videos to tell what codecs they are using (which saves you bandwidth—and when you are serving up videos, your bandwidth is a precious commodity!).

So much for the clean and simple solution, eh? So what is the upshot here? Well, first and foremost, it's an open standard. You no longer have to rely on the proprietary Flash plugin to do something that the browser should be able to natively support. Secondly, Flash is not universally supported, and with the growing prominence of iPhone video streaming, you'll be missing out on a huge demographic. Thirdly, HTML5 video is friendlier with overhead resources. So while it's not perfectly simple yet, it's still worthwhile to start adopting.


Subscribe to Author Archive: %