Picking at a Virus-Ridden Corpse, Part II

According to J'e, we’re focusing more on the critters – worms and viruses than we should, sometimes at the expense of some other important security issues. On top of that, every user functions as a system administrator, like it or not – and not only is probably very bad at it, but is also needlessly connected to too much of your network. Further, users are becoming addicted to bloated HTML e-mail, and there can be lots of reasons that make it easy not to buy most users (students) antiviral software.

J'e’s lessons-learned are an unflinching, but useful and enlightening, out-of-the-box look at ourselves. As we mentioned in Part I, J'e’s perspectives here do not reflect difficulties or conditions at either his institution or any one particular institution. They are "a synthesized view that reflects the collective higher education experience."

—Terry Calhoun, IT Trends Commentator, Society for College and University Planning (SCUP), University of Michigan.
----------------------------------------------
Picking at a Virus-Ridden Corpse, Part II

J'e St Sauver
University of Oregon Computing Center

Last week we briefly looked at four lessons learned from the Blaster/Welchia/Nachi worm infestations that swept across much of higher education at the beginning of this academic year This week we look at six more.

1. Distribution of Out-of-Band Software Updates
Quick poll: put your hand up if your campus had to create a supplemental security CD to disinfect compromised systems which had been taken offline. Okay.

Now, keep your hand up if you ended up looking at creating yet another CD to handle additional new vulnerabilities discovered after the creation of that first CD? Hmm.

I believe that if you need to completely break your users’ connectivity to control infested systems, you are a charter member of the security-CD-of-the-month (or security-CD-of-the-day!) club.

If at all possible, you really need to be building your network in a way that will permit you to use VLANS creatively to control infested users, while not taking them entirely off the air. Infested users should not have unfettered access to your campus network nor to the global Internet, but they must have access to a local machine with key decontamination tools and the ability to access Windows Update servers.

And while we're talking about disabling network access, how many of you have just learned the hard way that having a single-sign-on authorization system isn't much fun if "breaking network access" also means "breaking e-mail access" and breaking access to other mission critical systems,"such as your teaching and learning system?

If you've gone to single-sign-on with no granularity to your authorization system, you've drunk the purple, powdered-drink mix along with all the other members of your strange, apocalyptic cult.

2. Issues with E-mail
Am I the only one who's fed up with receiving non-delivery notices about virus-infested e-mail that I didn't send?

If an antivirus gateway is smart enough to detect the type of virus that's present in a message it receives, it should also be smart enough to identify virus strains which are known to always forge the "From" header. Do not report non-delivery of virus infested e-mail to forged "senders!"

If you must report non-delivery of a message to someone, do header analysis and report it to the abuse-reporting contact for the net block that handed you the message. Don’t bug an innocent party who had the bad luck to get forged into a virus-laden message as the putative sender!

And if you do send a non-delivery notice, don’t include a complete 140K copy of the dang virus (even if you do "defang" it)!
While we're on the topic of e-mail, remind users that:

  • Some e-mail programs (particularly ones which are closely tied to the underlying operating system, like Outlook and Outlook Express) have historically been more vulnerable to virus attacks than other e-mail programs, and
  • Plain-text e-mail tends to be elegantly small in size and universally readable, unlike bloated html-ified e-mail, or attachments prepared in some proprietary word processing program

Rediscover the quiet efficiency and invulnerability of command-line plain-text e-mail! (Frank da Cruz of Columbia University d'es an eloquent job of making the case for returning to plain text e-mail in his Safe Network Computing: Windows Desktop" page.

3. Everyone's a System Administrator (And most of us discharge "our duties" poorly!)
Our most recent viral adventure made it pretty clear that everyone who has a computer is a system administrator, whether we want to be one or not, and that most of us aren't very good at that job.

Consider the user's side of a typical post-compromise security debriefing:

  • No, a strong password wasn't put on the administrator account.
  • No, routine backups weren't taken.
  • No, critical security patches weren't applied.
  • No, unneeded services weren't disabled.
  • No, shared disks and directories had not been secured.
  • No, we didn't all subscribe to security notification mailing lists (and even if we had, we wouldn't have understood the subtle security vulnerabilities which would get discussed, anyway).


The list of ways that press-ganged amateur system administrators failed to perform is long and depressingly varied, but those failures should hardly be a surprise or a disappointment: users really aren’t system administrators!

The customary solution to the problem of end-user-as-crummy-sysadmin is to suggest substitution of some level of central IT automation: "We'll use just one model of workstation, and then have central IT remotely update all those systems when they need it." Right.

A couple of "minor" problems arise from that model, problems which arise whenever we forget the fact that universities are not typical commercial corporations. Universities differ from corporations in at least two profound respects:

First, universities tend to be frugal when it comes to computing hardware, often following a hand-me-down model of system deployment. Systems never get thrown away, they just get passed down from the Brahmins, to the middle class, to the untouchables. Organization-wide procurement of a single centrally-selected standardized desktop, followed by disposal of all non-conforming systems, would be unthinkable in most higher education organizations, particularly in tight budgetary times.

Second, unlike corporate staff, who have relatively uniform and easy-to-define system requirements, university faculty, students, and staff have diverse computing needs.

Office staff may only need minimal systems, able to run e-mail and office productivity applications, but faculty may require beefier system, with the horsepower to run complex numerical simulations. Students might prefer to purchase a system that works well for computer games and music as well as for more serious work. One size d'es not fit all in the academic world, nor should it.

The other approach that always seems to come up is to simply suggest that users run their systems on autopilot, relying on Windows Update to automatically detect and apply critical patches they need. (This strategy was summarized well by a famous TV pitchman: "Set it, and forget it!") Before you decide to follow that approach, I'd strongly urge you to read the article Patch and Pray.

Or, heck, what about the simple problem that Windows Update will run at most once a day? Twenty-four hours can be a long time to wait when there's a virus in circulation. Why has Microsoft not modified Windows Update to run every time a system boots, or perhaps multiple times a day? And what about all those campus folks who connect via slow dial-in connections? Some patches take way too long to download if you're connecting via an older modem, and in the case of campuses which cap the length of modem sessions, large patch downloads may never get completed.

4. Antiviral Tools Need to be Site-Licensed for All Members of the University Community
Most schools have already come to understand that antiviral tools need to be site-licensed for everyone, but some have still have not made that leap. Large schools serving part-time student bodies can be particularly challenged in this respect.

Typically all schools cover at least the cost of antivirus software for their faculty and staff on institutional machines, sometimes on personal machines, but students will often be "on their own." Relying on students to buy their own antivirus software is foolhardy. Students are poor. If you don't provide them with current antivirus software, many of them simply won't run anything. All members of the campus community need to be immunized against viruses and worms. If you can't afford a commercial antivirus product, you should at least be looking at some of the free antivirus products that are out there.

5. Virtually No One's Really Serious About Desktop Workstation Security.
I'm willing to bet that the recent viruses resulted in hundreds, if not thousands, of compromised systems on each of your campuses.
No one's watching, so let's be perfectly candid: were all those compromised systems low-level formatted and reinstalled from scratch? No? Are you really, really, comfortable that all those patched-but-not-fully-reinstalled-from-scratch machines don't have any lingering, virus-created "back doors" that just haven't been noticed yet? No?

And if a virus on those machines had completely wiped out the hard drive on each of those infested systems, would each have had a current backup? Would you at least have had a backup of the important stuff that you can't otherwise re-create?

Trust me, virtually no one's really serious about desktop workstation security. If such people exist, they would have reinstalled from scratch, using backups that most of us probably didn't have.

6. It's Not Just the Viruses and Worms.
It is really easy to get tunnel vision and think that viruses/worms are the only security threat you face. They're not.
At the same time you're dealing with viruses and worms, you should also be thinking about the steps that you'll take to deal with at least one other major security vulnerability this year.

Maybe that's physical security: What could someone with a sledge hammer and five gallons of unleaded gasoline do to your physical infrastructure?
Or maybe this is the year to go after plain-text passwords on the wire: ssh makes a nice drop in replacement for yelnet, and you can comparatively easily TLS-enable most POP and IMAP clients and servers now, just to mention two areas where encryption has come a long way without much fanfare.

In Conclusion . . .
There are plenty more lessons we could learn from these most recent infestations, but let's just stop at 10. If we can do these ten, or even some of these ten, we'll be making great progress.

J'e St Sauver, Ph.D., is Director of User Services and Network Applications., University of Oregon Computing Center. He can be reached at j'[email protected]

We know that everyone is working hard and with inadequate resources. If you’ll read back a few issues, you’ll note that, about the way folks handled the mess when the students came back to campus, we wrote: "on campus after campus, the IT staff came through with shining colors." J'e’s main point may be that you should just occasionally ask yourself whether you are about to do the lazy/expeditious thing, or the right thing – not in terms of reacting to a crisis, but in light of what might be the consequences down the road.

Featured