Knowledgebase

CentOS and backporting question

Posted by internetbug256, 08-21-2008, 02:26 PM
Hi there. I am running this dedicated server with CentOS 4.5. We run a yum update every month or so just to be sure it's all up to date. The nightmare started since we are being audited by a very (very) well known company, which determines (on every scan they do) that our server is vulnerable because they "read" the stamps our webserver returns (Apache). Since the backporting technique does not update versions, these stamps return a "false positive" for them. I've been trying to convinve them by showing the yum logs and some other stuff, without much luck so far. So my question is: do you people know of any way to see or detect (assuming full root access) the versions and backporting level for each application? What I need is some command I could run that could say without doubt something like "hey, you are running PHP 5.1.6, but backported and secured as if you were running 5.2.3", or something like that. Same question in other words: do you know of any way to demonstrate the backported software installed, other than the yum logs? Thank you, community Gabriel

Posted by stephanhughson, 08-22-2008, 05:55 AM
If all the patches to Apache have been applied as CentOS and Redhat do, but they don't believe you, then that's their problem in my opinion... I could run a generic security scanning tool that looks for version returned by Apache, it's easy. If they don't accept your explanation of why the result is invalid, I would take the angle that it's up to them to prove that you are vulnerable, that's what they are being paid for. Assuming that they've got a skilled penetration tester testing your IP addresses instead of some new-start with a network scanning tool written by someone else, they should be able to into detail of what you are vulnerable to and also prove it. If they're basing the version number on what is returned by the server in the headers, I would recommend just taking that version number out. You can hide it in Apache. Then they'll have to do some real work... Same with PHP.

Posted by jseymour, 08-22-2008, 06:34 AM
I agree that you should get a detailed list of what is vulnerable, not based on version number, but on type or protocol involved. On our last nessus scans of our corporate servers we did come across some things that were set as default on CentOS that needed to be changed mainly on our apache web servers. It was stuff like disable Trace and Track as well as Weak Cyphers. This just required some config file editing to fix. All bug fix patches are as said backported, so the basics should be fine, but you could still face some configuration issues as stated above.

Posted by stephanhughson, 08-22-2008, 06:50 AM
I should add, that if you choose to hide the information and want a tester to test you, you'll have to allow them to try exploits/vulnerabilities etc. Otherwise they're not going to know. I think basically, if they say version is out of date, they can only put "This *may* suffer from the following vulnerabilites". If you know you have a secure version, that's the end of the matter. It's not down to you to prove anything surely.

Posted by internetbug256, 08-22-2008, 07:55 AM
Thanks for all the replies. Yes, I do have a detailed list of all detected "vulnerabilities", but all of them are assumed based on the "detected" version running, never on the real one, nor the backported one, even less on a real exploit attempt. So yes, you are right about "it's up to them", but unfortunately the audit company reports to a provider of us, and we need to be compliant with the provider in order to keep being its client, so... I can't just tell them "find a smarter way to do this". Anyway, you opinion is welcome, and it will feed my last report to them. So, jseymour, if i tell you "prove to me that your Apache running in your CentOS is up to date", what would you do? Just show yum logs? Thanks Gabriel

Posted by jseymour, 08-22-2008, 08:03 AM
From what I can see, yum logs, and a personal configuration review to make sure none of the vulnerabilities are from configs. These audits should never be solely on versions, as enterprise software always lags behind on versions. I will check some more of my notes at work and reply if I find anything else that may help you. You may also consider eventually moving to the latest CentOS version. We run 5.2 without much problem, but still have to run 4.x due to application compat problems (like netbackup and such that do not support 5x yet.) But we do audit ourselves, so the only explaining we have to do is to our technology board. Also check to make sure nothing is excluded from update in yum.conf. You should be at 4.6 with the current CentOS 4x version. Last edited by jseymour; 08-22-2008 at 08:14 AM.

Posted by jseymour, 08-22-2008, 05:26 PM
Hmm, forgot to say this morning, If you are using apache 1x, do as the people at apache.org say, don't use it. Upgrade to at least 2.0x. 1.x even though still somewhat supported (for some bug fixes) is really now old and should be replaced if you ever want a good green security scan.

Posted by internetbug256, 08-22-2008, 05:35 PM
Thanks for the advice. I am on Apache 2.x already. Is it so common that administrators "hide" Apache signatures in order to avoid hackers to know what's inside? Doesn't this action encourage hackers to explore even more something that has been hidden so much? I wonder if the remedy is worst than the disease... (by the way, sorry for my english. Spanish speaker here, from Argentina) Gabriel

Posted by jseymour, 08-22-2008, 05:40 PM
Your probably right in that respect, having to hide our software. But it is still better not to give any extra information to make it easier for the cracker. All we can do is our best to prevent, can never be 100% secure unless the computer is off the network in a locked room. BTW your English is fine.

Posted by stephanhughson, 08-22-2008, 09:25 PM
Some people would call it "security by obscurity" which if that's all your doing, is bad. For example, if your system is actually vulnerable, but you hide the version number, that's really bad! It might work, but probably not as they'll try the exploit anyway. If you are just hiding the version number I don't think that's asking for trouble or drawing attention to your server. Hackers won't target you for that in my opinion, they'll just move on to an easier target. They won't think "oh wow! No version listed, this looks like an interesting server to hack.". Unless they really want your server in certain, most of the time they just want *a* server, any will do. What I've seen in the past is that they just sweep a range of IP addresses trying the same exploit on all the servers that answer, whether they are Apache or not! So to summarise, it's worth doing but they might try the exploit anyway, so don't just rely on that, make sure you are always patched and up to date.

Posted by jseymour, 08-23-2008, 04:38 AM
Yes, purely security by obscurity is not good. But it is still good practice not to advertise versions along with secure setup. The secure setup is the main part in protection though.

Posted by internetbug256, 08-27-2008, 03:23 PM
Sure I wont rely on obscurity! But at the same time I am not pleased with making this move (hide the stamps). I know it will be subject fo discussion next time they run a scan on our server. Well, I think that my questions have been answered: #1 = no way to show how up to date are we with yums in other way that showing yum logs. #2 = You, colleagues, have the same opinion about the whole issue. #3 = By keeping Yum updated we KNOW that our server is secured. Thank you so much to all of you. Gabriel

Posted by jseymour, 08-27-2008, 05:20 PM
Just running the updates are not enough. Configuration issues can also lead to the software being vulnerable. Both sides must be met to keep the server as secure as possible. Part of the job of scanning is looking for configuration problems, these should be reported to you also.



Was this answer helpful?

Add to Favourites Add to Favourites

Print this Article Print this Article

Also Read


Language:

Client Login

Email

Password

Remember Me

Search