Comments on: msec future and plans http://dodonov.net/blog/2009/09/02/msec-future-and-plans/ One blog to rule them all. Kinda. Wed, 07 Jul 2010 06:34:56 +0000 hourly 1 http://wordpress.org/?v= By: Vincent Danen http://dodonov.net/blog/2009/09/02/msec-future-and-plans/comment-page-1/#comment-16994 Vincent Danen Thu, 03 Sep 2009 01:56:36 +0000 http://dodonov.net/blog/?p=543#comment-16994 <p>Tommaso: don't use msec for this. Use AIDE. msec can only really do some rudimentary checking and instead of reinventing what Tripwire and AIDE do, you should use them. AIDE works wonders, but you have to keep on top of them. An attacker <em>always</em> has a window of opportunity unless you follow some really basic rules. I.e. run an AIDE report before doing a urpmi/yum upgrade, upgrade the files, then re-run AIDE. Of course, this is still a race condition because AIDE (or any other tool) can't know that a binary was modified (essentially) twice before the next scan. But you can narrow the window of opportunity quite a bit by doing it that way.</p> <p>And yeah, Eugene, we need to discuss rsec+msec integration and get something that helps/works with both projects. Then we can dominate sectool and the rest. =)</p> Tommaso: don’t use msec for this. Use AIDE. msec can only really do some rudimentary checking and instead of reinventing what Tripwire and AIDE do, you should use them. AIDE works wonders, but you have to keep on top of them. An attacker always has a window of opportunity unless you follow some really basic rules. I.e. run an AIDE report before doing a urpmi/yum upgrade, upgrade the files, then re-run AIDE. Of course, this is still a race condition because AIDE (or any other tool) can’t know that a binary was modified (essentially) twice before the next scan. But you can narrow the window of opportunity quite a bit by doing it that way.

And yeah, Eugene, we need to discuss rsec+msec integration and get something that helps/works with both projects. Then we can dominate sectool and the rest. =)

]]> By: eugeni http://dodonov.net/blog/2009/09/02/msec-future-and-plans/comment-page-1/#comment-16992 eugeni Wed, 02 Sep 2009 12:57:10 +0000 http://dodonov.net/blog/?p=543#comment-16992 <p>Great, thanks for you comments, I'll try to answer them quickly:</p> <p>@motitos</p> <p> - keep security reports for more than two days. Those are kept essentially to compare the results of 'previous' run to 'current' one. They are called something.'yesterday' and something.'today' for historical reasons. But the results of all runs are stored in /var/log/security.log too. For 2010.0, I'll add a feature which would allow you to view the results for every day. </p> <p> - saving the results in a file instead of mailing it - it is already done (the results are saved in /var/log/security.log). The only disadvantage is that you must read it by hand. The fix for previous comment would improve this as well.</p> <p>@Tommaso Massimi:</p> <p> - comparing files against rpm database. There is a feature in msec which also stored the list of all suid and guid files, comparing their md5 on every run. But you are right, it won't find ordinary files which were changed by a cracker - msec will just noticed that files were changed. I'll have to think on something for it.</p> <p>@Olivier FAURAX:</p> <p> - msec report formatting. This is something I wanted to do for 2009.1, but had no time. The 'updated packages' part is a lot cleaner indeed, I'll try to implement it shortly.</p> <p>As for summary part, it is an excellent suggestion, I'll add it to the TODO list.</p> Great, thanks for you comments, I’ll try to answer them quickly:

@motitos

– keep security reports for more than two days. Those are kept essentially to compare the results of ‘previous’ run to ‘current’ one. They are called something.’yesterday’ and something.’today’ for historical reasons. But the results of all runs are stored in /var/log/security.log too. For 2010.0, I’ll add a feature which would allow you to view the results for every day.

– saving the results in a file instead of mailing it – it is already done (the results are saved in /var/log/security.log). The only disadvantage is that you must read it by hand. The fix for previous comment would improve this as well.

@Tommaso Massimi:

– comparing files against rpm database. There is a feature in msec which also stored the list of all suid and guid files, comparing their md5 on every run. But you are right, it won’t find ordinary files which were changed by a cracker – msec will just noticed that files were changed. I’ll have to think on something for it.

@Olivier FAURAX:

- msec report formatting. This is something I wanted to do for 2009.1, but had no time. The ‘updated packages’ part is a lot cleaner indeed, I’ll try to implement it shortly.

As for summary part, it is an excellent suggestion, I’ll add it to the TODO list.

]]> By: Olivier FAURAX http://dodonov.net/blog/2009/09/02/msec-future-and-plans/comment-page-1/#comment-16987 Olivier FAURAX Wed, 02 Sep 2009 08:22:23 +0000 http://dodonov.net/blog/?p=543#comment-16987 <p>Hello !</p> <p>In report, rather than : - Newly installed package : apache-base-2.2.11-10.2mdv2009.11243927306 - No longer present package : apache-base-2.2.11-10.1mdv2009.11242321687</p> <p>I would like prefer : - Updated package : apache-base (2.2.11-10.2mdv2009 -> 2.2.11-10.1mdv2009)</p> <p>https://qa.mandriva.com/show_bug.cgi?id=51372</p> <p>I think that the report should be very clean, perhaps with a summary at the top. Ex: Summary of msec report * 23 world-writable files (+3) * 46 files with wrong permissions (-12) ...</p> Hello !

In report, rather than : - Newly installed package : apache-base-2.2.11-10.2mdv2009.11243927306 - No longer present package : apache-base-2.2.11-10.1mdv2009.11242321687

I would like prefer : - Updated package : apache-base (2.2.11-10.2mdv2009 -> 2.2.11-10.1mdv2009)

https://qa.mandriva.com/show_bug.cgi?id=51372

I think that the report should be very clean, perhaps with a summary at the top. Ex: Summary of msec report * 23 world-writable files (+3) * 46 files with wrong permissions (-12) …

]]> By: Tommaso Massimi http://dodonov.net/blog/2009/09/02/msec-future-and-plans/comment-page-1/#comment-16986 Tommaso Massimi Wed, 02 Sep 2009 08:13:38 +0000 http://dodonov.net/blog/?p=543#comment-16986 <p>Msec reports each dey the list of files changed on the system, but the check is performed against the original files coming from rpm packages.</p> <p>Acting in this way, if an cracker change a file that was already changed, msec doesn't recognize the event.</p> <p>It would be nice if msec could be improved to cover this case Regards</p> Msec reports each dey the list of files changed on the system, but the check is performed against the original files coming from rpm packages.

Acting in this way, if an cracker change a file that was already changed, msec doesn’t recognize the event.

It would be nice if msec could be improved to cover this case Regards

]]> By: motitos http://dodonov.net/blog/2009/09/02/msec-future-and-plans/comment-page-1/#comment-16985 motitos Wed, 02 Sep 2009 05:49:55 +0000 http://dodonov.net/blog/?p=543#comment-16985 <p>First of all, good job! I think that msec has improved a lot.</p> <p>Since you say that suggestions are welcome, I would like to request simple things, which are msec related, but I'm unsure if they are beyond msec and more in the Mandriva general structure.</p> <p>1) Keep the security reports in /var/log/security more than two days. Right now, you have to watch them every single day, which could be annoying in your day off or in your holidays.</p> <p>2) Not everybody wants an email server in their machine. Is it possible to generate an alert file, and let the user choose where to store it? In addition, it could be included in the logrotate routine.</p> <p>Bye! motitos</p> First of all, good job! I think that msec has improved a lot.

Since you say that suggestions are welcome, I would like to request simple things, which are msec related, but I’m unsure if they are beyond msec and more in the Mandriva general structure.

1) Keep the security reports in /var/log/security more than two days. Right now, you have to watch them every single day, which could be annoying in your day off or in your holidays.

2) Not everybody wants an email server in their machine. Is it possible to generate an alert file, and let the user choose where to store it? In addition, it could be included in the logrotate routine.

Bye! motitos

]]>