0

We are inheriting some older O.S's at another facility and apparently their support person has moved on. I have some Linux background but it is not with Ubuntu (Redhat). They are older operating systems - 9.10, 10.04.1 LTS and 13.10.

Is there a patch available for these? What is safest way to apply patches (if they are available). I will make a clone of the systems to test on.

How do I determine if there is a patch available without applying?

We will be moving them off these older O.S's down the road, in the mean time I was asked to patch for the glibc vulnerability. Any help would be appreciated, thanks.

Packman12
  • 1
  • 3
    For releases that old, there's no point. There's shellshock, poodle and any number of other vulnerabilities that they will be open to. At any rate, there's nothing from Ubuntu's side. You can look at the packaging to see what patches were applied for other releases and act accordingly. – muru Mar 07 '16 at 20:54

1 Answers1

2

If it's been without updates for more than a month or so, I treat any Internet-touching system as hacked. It's just not worth assuming there isn't a trojan or something equally horrible running on there. In your case you have systems that are years of serious security issues behind the curve.

So, no good news from me. You've got a bit of work to do I'm afraid.

  1. Work out what these machines did and backup unique data.

    If there is working data (eg websites, databases, etc) get ready to pick those apart with a fine comb. Abandoned Wordpress, Drupal, PHPBB, etc sites are wonderful things for hacking. You get all sorts of mucky shells laid in there and often —once hacked— admin credentials are injected into the databases.

    If these are just desktops or internal-only (by firewall) servers you have less to do.

  2. Nuke from orbit and reinstall a current LTS.

    Ubuntu 14.04 or wait a month or two and go 16.04. These have five years support from release so set a reminder.

    Don't upgrade. I'm serious. Not only is upgrading from 9.04 hard (you have to fake repo locations and upgrade multiple times, but so much has changed between these ancient versions and what we use today. It's simply easier to install afresh.

  3. Redeploy the services.

    Essentially restoring everything that was running in step one. Chances are you can do a better job of laying it out too. Perhaps integrate some CI or testing to automate the maintenance tasks your predecessor hated to do.

    Think of this as an opportunity ☺ There's other stuff you can cram into this cycle too. Hardware upgrades. Consolidation. All the sort of stuff you wouldn't want to try out on a live server.

It is always tempting to cut corners, especially when you have a job like this foisted on you. I've been there. Your predecessor was neglectful and you have an uphill battle ahead of you. Given your experience I wouldn't even bemoan you wanting to switch to a Red Hat derivative at this point. If it really makes your life easier, make it so.

Just make sure that you do a better job for the next guy.

Oli
  • 293,335