March 2008 - Posts

• The amazing Storm botnet

  I originally heard about the storm worm/botnet about 6 months ago but wrote it off as another b.s. botnet used by spammers for mediocre spreading of email. Recently I saw some newer articles and started looking into it again. This is when I realized how diabolical, beautiful and well crafted of a worm this beast actually is. Originally discovered in early 2007, the storm worm was thought to just be another worm that spread randomly infecting machines via e-mail. Upon further investigation, experts realized that this worm was something much more dangerous than a basic worm infecting machines. The storm worm uses an exploit in Windows XP to propogate to machines. No surprise there. The storm worm is actually multiple different programs rolled into one. It is actually a massive well crafted botnet consisting of anywhere from 160,000 to 50 million machines total. Recently, security experts have developed spiders to crawl the botnet and place the estimate more towards 160,000 computers rather than several million. Along with worm propogation the botnet also performs DDoS attacks, spamming, command and control servers, an e-mail address stealer along with many other duties. An interesting attribute that the botnet possesses is resistance to probing and inspection, almost like a defensive barrier that reacts to any outside intervention. Upon scanning and/or crawling the botnet, experts found that the botnet instantly recognizes that someone is trying to inspect it and retaliates with a DDoS attack. Whether this is an automated process or is being controlled by a user is unknown, although experts assume that it is the former. A very innovative feature indeed. With enough processing power to rival most of the worlds supercomputers it is a scary idea that such a resource is being controlled by criminal intent. When the botnet does commit a DDoS attack, it contains enough firepower to take an entire country offline. To quote wikipedia, "The webmaster of Artists Against 419 said that the website's server succumbed after the attack increased to over 400 gigabits per hour of data, the equivalent of over 170,000 ADSL-connected machines". This is an amazing amount of bandwidth and a scary prospect indeed. The botnet operates on a modified version of eDonkey's peer-to-peer networking which makes it almost impossible to take the botnet offline. Just like file-sharing p2p networks, no matter where you attempt to disassemble the network there are always other machines to take the place of patched ones. Only specific portions of the botnet are dedicated to certain tasks. A small portion provides DDoS attacks, another portion is strictly for spreading the worm to other machines while an even smaller portion is used as command centers to spread commands to the dormant machines. So you ask why can't you just find out where the commands and updated virus packages are being sent from? Good question. The controllers of the botnet are using a constantly changing DNS technique called "fast-flux", this allows the host machines to be almost impossible to find. Couple that with the fact that almost all communication within the botnet is encrypted and one can see the difficultly in analyzing such a beast. There are speculations that the size of the botnet has recently decreased but it still remains a very real threat to the internet as a whole. Especially being in the hands of criminals. I am considering setting up a dummy box to purposely get infected to "play" with the worm so to speak. Although, this could very well mean the death of my cable connection =) Posted Mar 16 2008, 09:45 AM by schambers with 4 comment(s) Filed under: virii

• PTOM: The Single Responsibility Principle

  After Chad and Ray I followed suit as well and am doing Pablo's Topic of the month post on the Single Responsibility Principle or SRP for short. In SRP a reason to change is defined as a responsibility, therefore SRP states, "An object should have only one reason to change". If an object has more than one reason to change then it has more than one responsilibity and is in violation of SRP. An object should have one and only one reason to change. Let's look at an example. In the example below I have a BankAccount class that has a couple of methods: 1: public abstract class BankAccount 2: { 3: double Balance { get; } 4: void Deposit(double amount) {} 5: void Withdraw(double amount) {} 6: void AddInterest(double amount) {} 7: void Transfer(double amount, IBankAccount toAccount) {} 8: } Let's say that we use this BankAccount class for a persons Checking and Savings account. That would cause this class to have more than two reasons to change. This is because Checking accounts do not have interest added to them and only Savings accounts have interest added to them on a monthly basis or however the bank calculates it. Some people may say that the class would even have 3 reasons to change because of the Deposit/Withdraw methods as well but I think you can definately get a little crazy with SRP. That being said, I believe it just depends on the context. So, let's refactor this to be more SRP friendly. 1: public abstract class BankAccount 2: { 3: double Balance { get; } 4: void Deposit(double amount); 5: void Withdraw(double amount); 6: void Transfer(double amount, IBankAccount toAccount); 7: } 8:  9: public class CheckingAccount : BankAccount 10: { 11: } 12:  13: public class SavingsAccount : BankAccount 14: { 15: public void AddInterest(double amount); 16: } So what we have done is simply create an abstract class out of BankAccount and then created a concrete CheckingAccount and SavingsAccount classes so that we can isolate the methods that are causing more than one reason to change. When you actually think about it, every single class in the .Net Framework is violating SRP all of the time. The GetHashCode() and ToString() methods are causing more than one reason to change, although you could say that these methods are exempt because they exist in the framework itself and out of our reach for change. I'm sure you can come up with a lot more instances where you have violated SRP, and even instances where it just depends on the context. As stated on Object Mentor: "The SRP is one of the simplest of the principle, and one of the hardest to get right". Here is a link to the SRP pdf on Object Mentor for more information. Posted Mar 15 2008, 09:06 AM by schambers with 14 comment(s) Filed under: PTOM

• Orlando Code Camp Presentation

  I will be doing a presentation at the Orlando Code Camp on next Saturday on March 22nd on Continuous Integration with TeamCity. I will be mainly cover the topic of Continuous Integration and how teams can benefit from it, then I will show how TeamCity works and dive into some of the details with this great tool. JetBrains just released 3.1 which improved TeamCity in various ways. If you are in the Orlando area you should definately try to get to the code camp. There is a lot of great topics lined up. Hope to see you there! Posted Mar 14 2008, 10:06 PM by schambers with no comments Filed under: ci presentations

• Separating Subversion Repositories using svndumpfilter

  About a year ago I setup a Ubuntu machine on an old P2 400 at home to use as a subversion repository. At the time I created one repository to house all of my projects. Over time I was adding more and more projects to it all under one master repository path. This was fine when there was 2 or 3 projects, but after growing to about 15 different projects, performing selective dumps and repository maintenance in general becomes a little cumbersome. I recently decided to break out the large repositories into their own repositories under the same subversion path (/var/svn/project). The original large repository was located at (/var/svn/repos). The idea here is that we will first dump the entire repository, and then pipe the output of the dump command to svndumpfilter which will extract only the path that we want. These two commands together is all that is needed to perform selective filtering of paths within a subversion repository and then dump the resulting output to the project.dump file. Unfortunately the svndumpfilter can only take either include or exclude in a command but not both, this limits it's usage in advanced scenarios, although it will work for what we are wanting to do here. Easy enough. With some piping we can perform all of this in one step: sean@svnbox:/var/svn$ sudo sh -c 'sudo svnadmin dump /var/svn/repos | svndumpfilter include projectfolder > project.dump' The reason for the sudo sh -c '' part, is so the piping of output of dump can be directed to master.dump with superuser permissions. In ubuntu everything is done with sudo instead of switching to root using su, therefore the first part of the command is evaluated using sudo, but the output being piped is evaluated using privileges of the shell. To make a long story short, if you are using ubuntu, you need to execute the command in it's own context thus, wrapping the command in it's own shell. If you were using any other distribution you could first switch to a root shell using su, then do the above command with the sh part. Now we can create the new repository, and load our filtered dumpfile into the new repository sean@svnbox:/var/svn$ sudo svnadmin create /var/svn/project | sudo svnadmin load project < project.dump The only thing that stinks now, is that since the single repository had a folder for each project, the project.dump now has a single folder in the root that is named project. To fix this, you just need to move your branches,tags and trunk folders into the root manually using svn mv or with tortoisesvn. In my case, I also had to edit /etc/apache2/mods-enabled/dav_svn.conf in order to accomodate the seperate repositories by adding the following: # from /etc/apache2/mods-enabled/dav_svn.conf # Remove/Comment out SVNPath # SVNPath /var/svn/repos # Added SVNParentPath SVNParentPath /var/svn SVNParentPath tells apache that there are multiple repositories hosted under /var/svn and that should be considered the root of your <Location> tag in the dav_svn.conf file. Clear as mud? In the future I will definately think twice about creating everything into one master repository, at the time I was just learning subversion and got started the quick and dirty way. In some cases however, it may make sense to have everything under one repository rather then break it out seperately. Hopefully this points someone in the right direction. Most of the above is documented very well in the SVN Book, so finding documentation on the above procedures and svndumpfilter should be easy. Posted Mar 13 2008, 08:00 AM by schambers with no comments