Good evening,
Today is friday the 22nd of September 2017. The time is 22:33:41 and it's week number 38.

(2011-02-09) It's a server, damn it...

... and not a clown car!

(Picture above) Let's hope this is not the desktop of your public web server.

This post relates mostly to Microsoft Windows, but the general topic of this discussion should be valid for most operating systems.

The days of Nimda, Blaster and Sasser are long gone and good riddance to them. Don’t get me wrong, there have been many worm attacks since and there will be more of them in the future. It’s just that worms spreading from system to system have joined the back of the queue. Old system administrators like me fondly (not really) remember running with CD-roms trying to disinfect PCs after pulling the plug on the network. Last time I had to do that was somewhere around 2002 or maybe it was 2003.

A few years later I was dumbfounded when vulnerabilities came out that could be used by worms and no wide-spread attacks ever appeared. If you take a look at the exploits being used on the Internet you might see a pattern emerging: more and more of the attacks mix types. That is, they use more than one attack vector and often combine different kinds of exploits. The reason is probably two-fold: better security defaults on servers and the need of a flexible approach to circumvent security. The first one is simply that products are better secured out of the box with less attack surface. Most operating systems either firewall listening ports or don’t have any open ports when installed. Services are better secured out of the box as well. The mixed approach simply means that “modern” attack code exploit vulnerabilities in conjunction with other vulnerabilities and also tries to avoid the most obvious network attacks. An all out “scan and attack everything you see on the network” is likely to be thwarted by firewalls on the hosts and intrusion detection systems. Remember the download.ject-attack? It exploited a vulnerability in Microsoft IIS to plant exploit code that attacked any un-patched clients surfing to the infected web server. That was frightening back in 2004. 1] But today that’s a pretty common way for an exploit to work. By exploit I mean a program that uses one or many vulnerabilities to attack one or many systems. What it does with exploited systems and how it gets there defines what it should be called, but terms like “virus”, “worm”, “backdoor” or “malware” are sometimes too precise. Real exploits have blurred the lines between those terms for a long time now.

But this is really nothing new; those mixed attacks have “evolved” from simple things like worms scanning for open ports to “morphs” that use different approached to “attack the desktop rather than system”. The most obvious attack vector nowadays is through a web browser and that has been the truth for many years now. All browsers I know of have had a number of vulnerabilities and the ways most of them use plug-ins aren’t helping either. So long story short: a server that often have people logged on at the console is a more “juicy” target than one that is administered remotely. And don’t think “Remote Desktop” or “Terminal Services” won’t count, they do! Whether you connect to a server with RDP, a shell over SSH or actually sit on the console doesn’t matter that much. There is some confusion with the nomenclature when it comes to logons, so let me sort them out. In Windows, when you logon to the desktop, it counts as an “interactive logon” regardless if you do it locally, over remote desktop or over remote desktop in console mode. In contrast: access to a Windows server through, let’s say, a web service counts as a network logon and will not give you a desktop. This is quite a bit of an oversimplification, I know.

Citrix and terminal servers pretty much have to allow interactive logons or they wouldn’t work, but way too often people logon to normal production servers interactively. And it gets worse, many administrators I have known (including me at times) like using the servers as extended desktops.

The solution is easy but painful:
- Don’t allow the server network to access the Internet unless needed. And if so, only to selected sites or services.
- Don’t administer the server from itself on a day-to-day basis. Remote administration is preferable.
- Logout when you’re done.
- Don’t surf to the Internet from any server unless it’s a part of its operation.
- Don’t leave a pile of unorganized scripts and programs strewn all over the server.
- Don’t install software that is meant to be used on a workstation.
- Respect network flow rules and network zones!

Those tips are just meant to foster a more secure approach towards administration of servers. There are many best practices and processes that should be implemented. So in short: treat your server as a workstation and it shall be attacked like a workstation.


Posted: 2011-02-09 by Erik Zalitis
Changed: 2011-02-09 by Erik Zalitis

News archive