Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
I installed AIDE and did a quick test of AIDE and after initializing the db and applying the recent cups update, I found that 1700+ files had changed. Those are a lot of changes to wade through to determine if they are legit or not. If that is all that AIDE can do, then it is not "manageable."
Seems to me that any IDS must be tied to the yum update process so that one is not dealing with hundreds/thousands of changes that were brought in by a yum update that I choose to apply.
Is OSSEC any less noisy?
DaveM
David McGuffey wrote:
Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
<snip> We've just started with OSSEC at work. I'm told they'd tried AIDE before I started, and it gave a *humongous* number of warnings. OSSEC is bad enough, when I do a yum update, for example.
mark
On Sat, Nov 28, 2009 at 6:57 PM, David McGuffey davidmcguffey@verizon.net wrote:
Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
I installed AIDE and did a quick test of AIDE and after initializing the db and applying the recent cups update, I found that 1700+ files had changed. Those are a lot of changes to wade through to determine if they are legit or not. If that is all that AIDE can do, then it is not "manageable."
Seems to me that any IDS must be tied to the yum update process so that one is not dealing with hundreds/thousands of changes that were brought in by a yum update that I choose to apply.
Is OSSEC any less noisy?
DaveM
When you are first installing any IDS (I am using AIDE), you need to give a few days to shake things out. You need to start from a known secure state, which is presumably what you have just after an install. If you just installed AIDE and it found 1700+ files "changed", then you should be able to safely assume that all of those changes are expected and acknowledge them. If you can't make that assumption, then you have bigger problems.
You definitely do not want an IDS tied in with yum, as that would defeat much of the purpose of an IDS. The whole point is for it to pickup files that changed. If things are changing without your explicit sayso and knowledge, then you have a problem. If there were a way for a package to communicate to the IDS to say "this change is fine, ignore it", then every single exploit would just do that.
What you need is a process, not a technical solution. Make sure that running the AIDE update is the next step after you install or update a package. Run the AIDE check nightly and review the output every day. Make sure the output matches anything you specifically did the day before, or things you expect, such as updates to /etc/shadow when someone changes their password.
There's no way for the computer to know whether a change is right or wrong, so you must always review it with human eyes.
David McGuffey wrote:
Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
I installed AIDE and did a quick test of AIDE and after initializing the db and applying the recent cups update, I found that 1700+ files had changed. Those are a lot of changes to wade through to determine if they are legit or not. If that is all that AIDE can do, then it is not "manageable."
Seems to me that any IDS must be tied to the yum update process so that one is not dealing with hundreds/thousands of changes that were brought in by a yum update that I choose to apply.
Is OSSEC any less noisy?
DaveM
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I run both of these on my servers. AIDE is noisy, however it is simple to scroll through the list of files that it shows and determine that the folders with all the changes relate to the yum update or install that I know about. After a yum update, I run another aide --init and cp the new db over the old one - I do this once a week after the logrotate takes place, thus most days have only two ~ ten files to look at. BUT the real outcome is I get to sleep easy knowing that something will know about every file change. OSSEC can also be noisy but it also adds some other useful monitoring and emails me when certain events occur. Most of these event I know about, thus I delete the email and life is good. The real benefit is that if the number of log messages suddenly grows I get warned, if I get 10 tries from one IP address to dovecot using different hostnames I get warned etc... I get to choose the level of response, by applying my experience and expectations to the mix. I do not think there is any tool you can just set and forget for IDS functions. HTH
On Sun, Nov 29, 2009 at 7:55 AM, Rob Kampen rkampen@kampensonline.comwrote:
David McGuffey wrote:
Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
I installed AIDE and did a quick test of AIDE and after initializing the db and applying the recent cups update, I found that 1700+ files had changed. Those are a lot of changes to wade through to determine if they are legit or not. If that is all that AIDE can do, then it is not "manageable."
Seems to me that any IDS must be tied to the yum update process so that one is not dealing with hundreds/thousands of changes that were brought in by a yum update that I choose to apply.
Is OSSEC any less noisy?
DaveM
Also, check out http://ftimes.sourceforge.net/FTimes/index.shtml
Even if you choose another tool, I recommend reading their paper. http://ftimes.sourceforge.net/FTimes/Papers.shtml
And the related tools hashdig and XMagic are worth a look.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I run both of these on my servers. AIDE is noisy, however it is simple to scroll through the list of files that it shows and determine that the folders with all the changes relate to the yum update or install that I know about. After a yum update, I run another aide --init and cp the new db over the old one - I do this once a week after the logrotate takes place, thus most days have only two ~ ten files to look at. BUT the real outcome is I get to sleep easy knowing that something will know about every file change. OSSEC can also be noisy but it also adds some other useful monitoring and emails me when certain events occur. Most of these event I know about, thus I delete the email and life is good. The real benefit is that if the number of log messages suddenly grows I get warned, if I get 10 tries from one IP address to dovecot using different hostnames I get warned etc... I get to choose the level of response, by applying my experience and expectations to the mix. I do not think there is any tool you can just set and forget for IDS functions. HTH
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, Nov 29, 2009 at 9:55 AM, Rob Kampen rkampen@kampensonline.com wrote:
David McGuffey wrote:
Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
I installed AIDE and did a quick test of AIDE and after initializing the db and applying the recent cups update, I found that 1700+ files had changed. Those are a lot of changes to wade through to determine if they are legit or not. If that is all that AIDE can do, then it is not "manageable."
Seems to me that any IDS must be tied to the yum update process so that one is not dealing with hundreds/thousands of changes that were brought in by a yum update that I choose to apply.
Is OSSEC any less noisy?
DaveM
I run both of these on my servers. AIDE is noisy, however it is simple to scroll through the list of files that it shows and determine that the folders with all the changes relate to the yum update or install that I know about. After a yum update, I run another aide --init and cp the new db over the old one - I do this once a week after the logrotate takes place, thus most days have only two ~ ten files to look at. BUT the real outcome is I get to sleep easy knowing that something will know about every file change. OSSEC can also be noisy but it also adds some other useful monitoring and emails me when certain events occur. Most of these event I know about, thus I delete the email and life is good. The real benefit is that if the number of log messages suddenly grows I get warned, if I get 10 tries from one IP address to dovecot using different hostnames I get warned etc... I get to choose the level of response, by applying my experience and expectations to the mix. I do not think there is any tool you can just set and forget for IDS functions. HTH
It should also be mentioned that all these tools do is look for changes to files. Using them them as an IDS is only a matter of how you choose to perceive the reports that are generated. They can and should also easily be used for configuration management (monitoring systems for unauthorized changes), and can play a big role in generating an audit trail of changes made on a system.
This is also why you can't "set and forget". The intended use for the reports happens on the user side, not the tech side.
On Sat, 2009-11-28 at 18:57 -0500, David McGuffey wrote:
Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
I installed AIDE and did a quick test of AIDE and after initializing the db and applying the recent cups update, I found that 1700+ files had changed. Those are a lot of changes to wade through to determine if they are legit or not. If that is all that AIDE can do, then it is not "manageable."
Seems to me that any IDS must be tied to the yum update process so that one is not dealing with hundreds/thousands of changes that were brought in by a yum update that I choose to apply.
Is OSSEC any less noisy?
More so as far as I can tell.
Don't forget that prelinking will cause files to regularly change their hash value whether they have been updated or not. Aide does have a patch to cater for prelinking (as far as I know it is not in the current release so you'll have to search their archives for it). OSSEC does not know about prelinking, so will frequently report files having changed.
Shameless plug: You could take a look at rootkit hunter (http://sourceforge.net/projects/rkhunter/), its file properties test knows about prelinking and can use the local RPM database to verify files, so an updated file won't be flagged as having changed unless someone has deliberately changed it.
Another alternative is Samhain. As far as I remember it can handle prelinking, but will report updated files as having been changed.
John.
On Sun, 2009-11-29 at 20:31 +0000, John Horne wrote:
On Sat, 2009-11-28 at 18:57 -0500, David McGuffey wrote:
Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
I installed AIDE and did a quick test of AIDE and after initializing the db and applying the recent cups update, I found that 1700+ files had changed. Those are a lot of changes to wade through to determine if they are legit or not. If that is all that AIDE can do, then it is not "manageable."
Seems to me that any IDS must be tied to the yum update process so that one is not dealing with hundreds/thousands of changes that were brought in by a yum update that I choose to apply.
Is OSSEC any less noisy?
More so as far as I can tell.
Don't forget that prelinking will cause files to regularly change their hash value whether they have been updated or not. Aide does have a patch to cater for prelinking (as far as I know it is not in the current release so you'll have to search their archives for it). OSSEC does not know about prelinking, so will frequently report files having changed.
Shameless plug: You could take a look at rootkit hunter (http://sourceforge.net/projects/rkhunter/), its file properties testof knows about prelinking and can use the local RPM database to verify files, so an updated file won't be flagged as having changed unless someone has deliberately changed it.
Another alternative is Samhain. As far as I remember it can handle prelinking, but will report updated files as having been changed.
Thanks.
I'm not looking for a "tech" solution so I can sit on my butt and let the tools do their magic. What bothered me was that I did the install, configured the load the way I wanted it, ran AIDE to init the db. A couple of days later, the CentOS list informed us that cups needed to be updated. I did the update and immediately ran AIDE to see what changed. That cups update changed nearly 1,700 files.
That caused me to think...there should be a way to tie the IDS to the patching (that I deliberately authorized), so that the changes related to the patching are either ignored, or collected at the end of the report under the header something like:
"The following changes appear to be tied to authorized patching activity...if you did not authorize these changes, then find out why they changed..."
I still want to see the changes, but it would be nice to see the ones I authorized through the update service to be partitioned off from the ones that seem to have no reasonable explanation.
DaveM
On Nov 29, 2009, at 3:52 PM, David McGuffey davidmcguffey@verizon.net wrote:
On Sun, 2009-11-29 at 20:31 +0000, John Horne wrote:
On Sat, 2009-11-28 at 18:57 -0500, David McGuffey wrote:
Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
I installed AIDE and did a quick test of AIDE and after initializing the db and applying the recent cups update, I found that 1700+ files had changed. Those are a lot of changes to wade through to determine if they are legit or not. If that is all that AIDE can do, then it is not "manageable."
Seems to me that any IDS must be tied to the yum update process so that one is not dealing with hundreds/thousands of changes that were brought in by a yum update that I choose to apply.
Is OSSEC any less noisy?
More so as far as I can tell.
Don't forget that prelinking will cause files to regularly change their hash value whether they have been updated or not. Aide does have a patch to cater for prelinking (as far as I know it is not in the current release so you'll have to search their archives for it). OSSEC does not know about prelinking, so will frequently report files having changed.
Shameless plug: You could take a look at rootkit hunter (http://sourceforge.net/projects/rkhunter/), its file properties testof knows about prelinking and can use the local RPM database to verify files, so an updated file won't be flagged as having changed unless someone has deliberately changed it.
Another alternative is Samhain. As far as I remember it can handle prelinking, but will report updated files as having been changed.
Thanks.
I'm not looking for a "tech" solution so I can sit on my butt and let the tools do their magic. What bothered me was that I did the install, configured the load the way I wanted it, ran AIDE to init the db. A couple of days later, the CentOS list informed us that cups needed to be updated. I did the update and immediately ran AIDE to see what changed. That cups update changed nearly 1,700 files.
That caused me to think...there should be a way to tie the IDS to the patching (that I deliberately authorized), so that the changes related to the patching are either ignored, or collected at the end of the report under the header something like:
"The following changes appear to be tied to authorized patching activity...if you did not authorize these changes, then find out why they changed..."
I still want to see the changes, but it would be nice to see the ones I authorized through the update service to be partitioned off from the ones that seem to have no reasonable explanation.
Seems to be that a yum plugin could be written that would accomplish this. Consider - it would only allow signed rpm updates, and ask for permission (or use a key) to update to LIDS database...
Hi Ian,
On 11/30/2009 01:07 AM, Ian Forde wrote:
I still want to see the changes, but it would be nice to see the ones I authorized through the update service to be partitioned off from the ones that seem to have no reasonable explanation.
Seems to be that a yum plugin could be written that would accomplish this. Consider - it would only allow signed rpm updates, and ask for permission (or use a key) to update to LIDS database...
You are mostly on the right track, however, that wont work across the whole machine.
imho, the magic potion is to offload the machine state elese where and use the compare-with-pre-state on a different 'central' machine. Where knowledge like pacakge-ver and package-payload can also be tracked.
- KB
On Sun, Nov 29, 2009 at 6:52 PM, David McGuffey davidmcguffey@verizon.net wrote:
On Sun, 2009-11-29 at 20:31 +0000, John Horne wrote:
On Sat, 2009-11-28 at 18:57 -0500, David McGuffey wrote:
Starting with a fresh load and after I finish hardening the load following the Center for Internet Security (CIS) guidance, I'm wondering whether AIDE or OSSEC would be a better intrusion detection system.
I installed AIDE and did a quick test of AIDE and after initializing the db and applying the recent cups update, I found that 1700+ files had changed. Those are a lot of changes to wade through to determine if they are legit or not. If that is all that AIDE can do, then it is not "manageable."
Seems to me that any IDS must be tied to the yum update process so that one is not dealing with hundreds/thousands of changes that were brought in by a yum update that I choose to apply.
Is OSSEC any less noisy?
More so as far as I can tell.
Don't forget that prelinking will cause files to regularly change their hash value whether they have been updated or not. Aide does have a patch to cater for prelinking (as far as I know it is not in the current release so you'll have to search their archives for it). OSSEC does not know about prelinking, so will frequently report files having changed.
Shameless plug: You could take a look at rootkit hunter (http://sourceforge.net/projects/rkhunter/), its file properties testof knows about prelinking and can use the local RPM database to verify files, so an updated file won't be flagged as having changed unless someone has deliberately changed it.
Another alternative is Samhain. As far as I remember it can handle prelinking, but will report updated files as having been changed.
Thanks.
I'm not looking for a "tech" solution so I can sit on my butt and let the tools do their magic. What bothered me was that I did the install, configured the load the way I wanted it, ran AIDE to init the db. A couple of days later, the CentOS list informed us that cups needed to be updated. I did the update and immediately ran AIDE to see what changed. That cups update changed nearly 1,700 files.
That caused me to think...there should be a way to tie the IDS to the patching (that I deliberately authorized), so that the changes related to the patching are either ignored, or collected at the end of the report under the header something like:
"The following changes appear to be tied to authorized patching activity...if you did not authorize these changes, then find out why they changed..."
I still want to see the changes, but it would be nice to see the ones I authorized through the update service to be partitioned off from the ones that seem to have no reasonable explanation.
DaveM
Are you running AIDE on a scheduled basis? It should probably be running from cron at least once a day, which will give you the partitioning you are looking for based on time. You'll know when the changes happen within a 24 hour period, which should help you track down what caused them. If it's something like prelink, then you can decide what to do about it.
We did the install on our servers, and then had to spend some time tuning to make sure it was only getting the things we need. We now run AIDE every day, and the reports are usually only about a few files, if any.
-
Alan Sparks -
Brian Mathis -
David McGuffey -
drew einhorn -
Ian Forde -
John Horne -
Karanbir Singh -
mark -
Rob Kampen