6

It's obviously a best practice to run an up to date distro, or at least one that is still getting security updates. If a particular piece of software requires an older distro like CentOS 4.4 (mandated by the vendor to keep getting support), should this be a significant security concern for us, assuming we have the server itself behind a well-secured firewall?

4
  • 5
    What if you just don't tell the vendor that you're no longer using CentOS 4.4? Have you tried running the software on a newer distro? Then again, if they aren't able to support their software running on anything newer than a 5-1/2-year-old EOL'd OS, maybe it's time to start looking for a different vendor that has its act together.
    – rob
    Apr 28, 2012 at 0:30
  • 7
    What vendor is this? I need to know so I can avoid them like the plague. Apr 28, 2012 at 2:29
  • 1
    right, you'd imagine that the software just needs specific versions of some libraries, and that the vendor is just being lazy in not specifying them properly, and/or not testing the software with newer versions.. I agree with Joel. Name and shame :P
    – naught101
    Apr 28, 2012 at 10:55
  • The vendor is Fonality and the product is Trixbox Pro.
    – Eric
    May 15, 2012 at 23:56

3 Answers 3

11

It depends on what software will be running on this box, if it will be exposed to other parts of your network, or exposed to the internet, etc.

CentOS 4 was EOL'd in February. There will be no security updates for it any longer, but there will be plenty of security vulnerabilities. Do not use it unless you are willing to perform the required work to keep the system up to date. Speaking generally, the security of a modern system like CentOS 5 or CentOS 6 will be better then CentOS 4.

If you keep this unpatched system on your network, there is a risk that a cracker may compromise that system inside your network and use it as a springboard to attach other systems on your network.

The CentOS 4 EOL was announced a long time ago so that vendors would have time to update their software. Your vendor failed to do this, which calls their competence into question. They had plenty of time to migrate from CentOS 4 to CentOS 5, and CentOS 5 will receive security updates until 2017. Your vendor could have gotten themselves out of this sticky situation years ago.

CentOS 4 is over 7 years old. CentOS 6 was released over 6 months ago.

If you absolutely cannot move off of CentOS 4, note that:

  • CentOS 4.4 is very old and contains a number of security vulnerabilities. At least patch it to be CentOS 4.9. Review the various databases of security vulnerabilities for your software, patch if necessary, or mitigate the risk.
  • Be willing to maintain the system on your own.
  • RHEL does offer a paid option to help keep the software up to date. Here is what the CentOS 4 EOL announcement says:

    For users who are unable to migrate off the EL 4 code base before its end-of-life date, the upstream provider intends to offer a limited, optional extension program. The CentOS Project recommends that you contact their sales team for a price quote for their extended service if you can not move to a newer code base before February 29th, 2012.

2
  • 2
    You'd be better off soliciting for price quotes on someone who can help you migrate to a newer version of your OS and making the process less painful for the next time, than to pay a vendor to keep supporting your aging version. That's just avoiding the inevitable, because migrating you shall...
    – aseq
    Apr 28, 2012 at 0:13
  • @aseq: your comment completely ignores the context of the OP...
    – naught101
    Apr 28, 2012 at 10:56
9

You're between a rock and a hard place.

My view may not be popular, but...

That version of CentOS was end of lifed, so any new vulnerabilities will not be patched.

BUT if you want support from your vendor, you need to run that insecure software.

SO

A) Is it secure? That depends on what you're running and who has access. I would say that if you are running NOTHING but an abstract access to a particular bit of software within your company and you have no users inside the company that are troublemakers and the computer isn't accessed by anything but the console outside of that application, and the application isn't run as a root user, then you might be somewhat secure. Or "secure enough." In practical terms.

B) Your vendor is VERY irresponsible for not upgrading the software and forcing the release to a point where the platform is end of lifed...and they still haven't released a new version.

C) I'd be monitoring the ever-living !@#% out of that server. Run stealth against it from trusted hosts. Run tripwire. Backups regularly. Malware scans as up to date as possible. You need to find out what if anything alters that machine when a file shouldn't be altered.

For YOUR described case, the answer is no, it's not secure, but you can take steps to make it reasonably checked for issues. You don't get into what this application is (I'd almost want to beg you to name it if it's something others might run into, since others should avoid this vendor...) but my approach would be to essentially advocate that since you have to leave the door to your house unlocked, you should put in as many security cameras recording to a remote facility as possible for evidence if a burglar were to break in. That is, use stealth to monitor files, use intrusion detection, use checksums, cut out all unnecessary services, get rid of compilers on the server if they're there, etc. and pressure your vendor to UPDATE their software or support it on a more updated platform.

Practically speaking you can only mitigate the risk.

3
  • +1 good use of a cliche :-)
    – johnshen64
    Apr 27, 2012 at 23:10
  • I would say this advice is applicable regardless of whether a product is EOL'd.
    – rob
    Apr 28, 2012 at 0:41
  • Right. +1 for a). Security isn't categorical.
    – naught101
    Apr 28, 2012 at 10:58
3

centos 4.4 has been end of lifed, meaning if there are any future holes discovered, no patch will be provided. it is really up to your company's security team to decide in this case, however, and what compliance you are subject to. if the vendor cannot provide an upgrade path, you may have to look for an alternative, if keeping it would violate some sort of policy or compliance requirements, esp. if you are subject to PCI.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .