Nimda, Other Worms and Life on the Internet
It's day three of the Nimda worm as I write this. My personal web server is getting multiple worm hits per second--a lot of traffic for a machine that usually gets only a few hundred hits per day. We can, of course, thank the vulnerability of IIS for this new creature designed to increase total web traffic.
It would nice to say Microsoft is wholly to blame for this, but doing so would be like saying George Bush is wholly to blame for all the problems in the world. In both cases, we each need to take some responsibility. Some of us voted for Bush, and some of us elected to use Microsoft software.
The good news is that we have choices. With education we can get past the marketing hype and make the best choices for everyone involved. If, however, we just believe what we are told, we are all going to be in deep dodo.
The word that comes to mind is diversity. Whether we are selecting leaders, planting crops or selecting software, diversity is always going to be a good thing. In each case diversity will protect us because it makes it harder for an adversary to do damage.
If all web servers were running ISS and all desktops were running MS Windows, Nimda would likely have brought the whole Internet to its knees. Fortunately, the majority of the web servers run Linux or some UNIX variant as an OS and an assortment of server software. Thus, to successfully attack most web servers, the adversary would have to create either an assortment of worms for each potential OS/server combination, or one giant worm with all the features to attack all servers.
Before you say "but Linux and/or Apache is better", let me stop you. They very likely are better than NT/ISS, but they are not bug-free. If Linux/Apache was the only target, someone would be out there creating a worm to attack it. In my world, I would want to see FreeBSD/Apache on Sparc hardware, Linux/Apache on PPC, etc. to help maintain diversity.
The other reason Linux, Apache and *BSD have a big advantage is the code is open for peer review. While the marketing departments of large proprietary software companies keeps telling the world that this is bad because a potential cracker can see how to break the code, the reality is that pride of ownership seems to far outweigh this potential problem.
What do I mean by pride of ownership? Individual programmers care that their code works. They view a bug report as positive; someone took the time to find a problem and let them know about it. I remember, for example, finding what I thought was a bug in the serial driver in Linux back in 1993. While I used to be a professional software tester before I got into publishing, I still somewhat sheepishly sent e-mail to Ted T'so suggesting that I might have found a problem. Ted's response was to send me a patch to try (which worked).
On the other end of the spectrum, I was told by the employee of what was a large proprietary software vendor that they had an internal bug list, but they wouldn't disclose its content. When someone reported a bug they would deny it was on the list, but increment the count of that bug on the internal list.
One final thing that seems to come with the Open Source community is creativity. LaBrea is one good example. If you haven't heard of LaBrea, go to http://www.hackbusters.net/LaBrea. LaBrea is a tar pit (if you know Spanish you probably guessed this) for worms. It is not specific to any one worm, but is designed to slow down anything that behaves like a worm by pretending that it is a computer that the worm to talk to.
The future? If we support more diversity and more innovation, it's bright. If, for example, the majority of the computers on the web simply started ignoring infected machines, worms would be a lot less fun to write. Be innovative and, if that innovation involves Linux, tell us about it.
Phil Hughes is the Publisher of Linux Journal.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python