Hi Mike,

I think for myself and Breun (as he opened a post in asl about it) the option of having asl set the rootlogins=yes in rkhunter.conf as in the older releases.

Why have the allow rootlogins option in the asl config, it's not being used.

I understand people may want forced rootchecks and you get tickets on this, but likewise you should have the option of allowing rootlogin, is that not why this option is the asl config? If someone says yes or no have to assume they know what they are doing.

My only five things I want to see options in asl for are:

1 - rkhunter allow rootlogins yes to shut it up.

2 - remove asl dependency on denyhosts hard version number. You should be able to run a OS denyhosts version. As long as it's there asl can configure it. Obviously if you plan a special denyhosts to do stuff, it should be an add on to denyhosts, or a new asl package like paxtest.

3 - php safe mode. If you set safe mode to off, and if you have php-5.3x do not generate a security warning. As you know safe mode is fully depreciated in 5.3x so producing a warning is just silly and pointess and only shows a vulnerability that does NOT exist.

4 - server type = custom in asl config. Please preserve this in updates. Why overwrite it it's been changed for a resason. In my case if I forget to edit asl config or I happen to update asl close to the hour cups and services I use get killed. I then have to put it all back.

5 - option to tweak reports. If I run x windows or non asl kernel, I should be able to supress the alert on it. Yes it may be a vulnerability, however if I set something in a config file I am aware of this. I think the GUI should aleert me to a real alert I am not aware of than having to way though alerts.

Yes I got around these with scripts and cron. But I would love to see these 'fixed'.

Don't get me wrong. You do a great job you really do. But not everyone runs servers ad you may have intended the product for. Adding some custom features to tweak to suit your individual needs makes for a powerful product.

These changes are small as most exist in asl config now. Really add one line 'is php-5.3x installed = yes / no and it's all there. Sure it would be nice to detect the php version and act automatically, but interium add a config.

I am fortunate enough to be able to get around these but others may not.

Again you do have a great product, I just want it even better!

Hi Mike,

For the rules, an option in asl config for either delayed or current rules. I would love to test new rules for you, I live in testing repos, so throw rules as well I am game

Also can a rollback be put in? Like yum downgrade, maybe in the GUI?

Yes I understand the logic of being able to supress any of the alerts, someone cries about it then breaking.

However again if you do this it's your issue (the client) not atomic!

Thanks for the prompt response!

Everything I wished for and more! Sorry to repeat myself, but God your good!

Thanks a lot for your dedicated work!

To rollback rules, or something else? (or both - and whats the something else *grin*)

Hi Mike,

No just the rules, I think it's really good if toot running the 'testing' super current rules.

Thanks for clarifying David.

OK, updated list:

1) Support older versions of ASL for longer. ( i.e. rules only - for 7 to 14 days ) (Comment from Mike: I think the solution on this one is to make it possible for people to run older versions. If you are running an older version, thats your business. Maybe we fork the rules if we need to put something out thats ASL version specific. Point taken.)

2) Option to update rules, but not ASL automatically. Another request was to make this the default behavior. (Comment: Done, we are adding this in as we speak and it will be in a future version of ASL soon)

3) Add in ability to roll back to older versions of rules (you can do this now, but the process is manual, so I'm assuming a GUI point/click method is what we are aiming at here, correct me if I am wrong)

4) On detection of "old/incompatible" asl version<->rules send an e-mail notification to admin informing them of the update instead of running it. (and extension of #1 and #2 above?) (Comment: a little more work... something we need to think about how to manage, forking will tie into this at some point, see #5 below)

5) Fork the rules when new versions require features in newer version of ASL. (Original request: When a new ASL version or component comes out, do not immediately release rules that only work with it. Wait 7 to 14 days before doing so. In the meantime continue to release rules that work with both old and new.) I think forking might make more sense. (Comment on this one: Not all rules will work with older version of mod_security, for example, so running older versions will mean that some features will not work, so keep that in mind: old = potentially vulnerable if we fork - nevertheless, yep, we will do this too).

6) Allow ASL to be configured to not only allow root logins but to not warn or send any alerts that the system is configured in this way. (Comment: This one makes me nervous, I dont want someone to disable an alert without some work... feedback appreciated on this one, I can see this potentially backfiring) Davids comment: rkhunter allow rootlogins yes to shut it up.

7) Allow ASL to be configured to hide specific vulnerabilities and to report the system as not vulnerable (for example, if you are running a vulnerable kernel allow the user to disable the alert and hide the vulnerability). (Comment: we're probably going to add in an option to configure the system to make it impossible for someone to ignore a vulnerability report, our compliance and government customers can't have a system that doesnt tell them the cold hard truth all the time, its mandated for them.)

add a weekly cron job that updates components, timed to happen when ASL support is officially open (i.e. not a weekend). Note: Delay ASL releases to only happen during the week, presumably on a Monday. (comment: done, we'll delay ASL releases to Mondays or something like that. We'll probably make the final available right away on the testing channels for those that prefer to use the final build when it comes out of Beta)

9) Delay release of new rules 7 to 14 days later that require new ASL features, start to release rules that require the new version. (Comment: Appreciate the sentiment on this, but I dont think its necessary. Forking makes more sense to me where, theres no need to delay new feature that closes a serious vulnerability, if users want to keep running older versions forking makes more sense rather than forcing everything to stay vulnerable for two weeks)

10) remove asl dependency on denyhosts hard version number. You should be able to run a OS denyhosts version. As long as it's there asl can configure it. Obviously if you plan a special denyhosts to do stuff, it should be an add on to denyhosts, or a new asl package like paxtest.

11) - php safe mode. If you set safe mode to off, and if you have php-5.3x do not generate a security warning. As you know safe mode is fully depreciated in 5.3x so producing a warning is just silly and pointess and only shows a vulnerability that does NOT exist.

12) - server type = custom in asl config. Please preserve this in updates. Why overwrite it it's been changed for a resason. In my case if I forget to edit asl config or I happen to update asl close to the hour cups and services I use get killed. I then have to put it all back.

13) - option to tweak reports. If I run x windows or non asl kernel, I should be able to supress the alert on it. Yes it may be a vulnerability, however if I set something in a config file I am aware of this. I think the GUI should aleert me to a real alert I am not aware of than having to way though alerts. Comment: I assume this to mean you should be alerted to *new* vulnerabilities? In other words, if you tell ASL to not care if you have a vulnerable stack kernel issue, but we add in a new check for heap vulnerabilities you want to be alerted to that, and then you can say "yes I dont care" and silence that one too?

Anything else?

Hi Mike,

Thanks for ordering it all!

1 - For me I always am current so not bothered. As long as there is an instant upgrade path available if you choose it preferably configurable.

2 - I would like an option in the config file for this, expand on the updates tag there now, hourly, weekly, off or manual.

3 - GUI yes. Also look into a way so you can get the first release set of rules the ones you mentioned before. Again an option, maybe latest and normal setting?

4 and 5 - again maybe a way to set a config option for latest, current and delayed rules, this allows you to 3 levels. Latest the ones you write up now only released to small number. Means you can get them tested and with GUI rollback tool easy. Normal the rules as they are now paired for stable current asl. Finally delayed for the ones wanting to hang on old versions.

6 - just ability to configure rkhunter.conf and ofcourse actually allow a root login (not get it disabled). Root login could be emailed in a weekly security summary (cron.weekly task) along with other supressed events (further down).

7 and 13 - yes just ability to tweak the GUI. True vulnerabilities can still be emailed weekly. Should future checks for new vul be added those also have ability to be tweaked. Basically the alerts each one should be tweakable example (php events - popen, etc, root login, asl kernel, grc not there (not asl kernel), etc,etc. I suggest a setting in asl config so there are two on each - 'allow popen yes no'. Means allow popen and no to report it. Or maybe a seperate report.conf file showing all the same tests and you put a yes or no to report (what ever is easier for you).

10 - yes. It always worked before. Assume a standard denyhosts asl can configure (etc/denyhosts.conf). Just I found selinux issues as there are OS patches setting correct context on hosts.deny and backup as well as tweaks.

11 - should be automatic but can tie into 7 and 13. No need writing too much code trying to test, after all I hope the admin knows what php version is running

12 - yes please just preserve the setting. ASL now has custom option where it does not go off killing all the services like cups, x windows, messagebus (and please don't take away ), but don't hard overwrite back to webserver in config on updates. You can warn on asl -s -f or in a weekly report.

Thanks again!

that all sounds great. Thanks to everybody making ASL better.
I'm experiencing no update even though "AUTOMATIC_UPDATES" is set to "daily".

I'm little bit confused now. Should it or should it not do it automatically?
Or do I have another error?

asl -v
ASL Version 2.2.5: CentOS 5 (SUPPORTED)


asl -u
Checking for updates..
Updating ASL: update failed [FAIL]

I think you'll need to upgrade to ASL 2.2.6.

thanks breun

Hi Mike,

I got one more thing to add. asl-web and the browser warning for an iPhone.

Safari is the only browser for the iPhone so can the warning be dropped for an iPhone.

Thanks!

I also get the warning in the 'regular' Safari, but it works fine. I guess they wan't to make clear they don't support browsers that they don't test themselves, but I agree that could be done more subtle, maybe by just adding that to the system requirements somewhere and pointing people to that when they complain. Or did you really get a lot of complaints about certain browsers not working correctly with the ASL web interface?

Hi Breun,

Like with my iphone it does not have flash so naturally the memory chart does not work, everything else does.

I think an option to suppress the alert, or at least in the case of iphone remove it as its just annoying as I can't run another browser.

It should be detected in the browser as I find most pages open up in full web mode not mobile if the site is using up to date pages as it knows its an iphone not a typical mobile device using wap.

ANyway since we have these planned feature changes it should go on

Hi Mike,

I know this is in progress, but can you add Fedora 13 support onto the list please?

I think it would be good to with asl, try to work with rawhide as well, as then you don't end up with a current OS released and not able to support it.

Particularly more towards the release date of rawhide to the next release.

The repo for Fedora 14 is already in place so no harm trying to build what builds.