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?
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.
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.
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.
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.