I agree with faris. I want automatic rules updates, but not automatic asl updates. The description of the AUTOMATIC_UPDATES setting says it controls the rules updates. Is there a way to update the rules but not update asl?

I believe I'm experiencing an explanation failure here

I want my cake and I want to eat it.

I want to update rules regularly/automatically but I don't want to update the components at the same time.

I do not mind if I end up running unsupported components for a few days in the meantime.

BUT would I be right in thinking that in some situations the updated rules might require updated components otherwise they won't work/very bad things might happen?

If so, and assuming that I'm not the only one not wanting my components to be updated at the same time as the rules, please could you consider changing the way things work slightly? Here's my suggestion. Obviously I don't know how difficult it might be to implement in real life.


1) Add a --rulesonly option to asl -u which only updates the rules, and make that an option or even the default option for the auto-update cron job.

[ 1a) Potentially add a weekly cron job that updates components, timed to happen when ASL support is officially open (i.e. not a weekend) ]

2) 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.

[ 2a) Continue to support the older version of ASL in a limited way - i.e. rules only - for 7 to 14 days ]

3) 7 to 14 days later, start to release rules that require the new version.

[ 3a) Discontinue support for previous version of ASL ]

In this way you be able to have a 7 to 14 day window after the release of a new version of ASL to allow sysadmins to plan when to update asl.

OK, so this is really kind of complicated isn't it? Oh heck, maybe we should just stick to the way it gets done now. "If it aint broke...." and all that. ASL version upgrade issues are really quite rare at the end of the day, aren't they?

Faris.

Yup, have these loaded, but due to tls encryption, some packets get occasionally dropped, tried various TLSRequired settings (ctrl | data | auth | auth+data), but no joy. Not ideal, but if you have any other suggestions I'd be happy to try them...

I edited my earlier post and it seems to have been lost (hosting upgrade?), anyway... I fixed the problem:

As of ProFTPD 1.3.3rc1, mod_tls only accepts SSL/TLS data connections that reuse the SSL session of the control connection, as a security measure. To relax the requirement that the SSL session from the control connection be reused for data connections, use the following in /etc/proftp-tls.conf:

I'll take encrypted FTP un/pw over whatever security measure that would otherwise offer.

On detection of "old/incompatible" asl version<->rules why not send e-mail notification to admin informing them of the update instead of running it?
Never realised asl -u (could) also update the core asl, odd that asl-web (and gradm?) did not get updated at same time?

Anyway, I'd rather not have spent half the day trying to figure out what was happening + finding a solution + dealing with customer queries (wish I could "cut down my support overhead" ). ASL rocks, but with an increasing user-base, bet this will bork more systems as is...

I see Scotts point and agree. Once a final version is out (2.2.6) it's already been in testing maybe for a month and it's hammered out.

Else as he said he still has people running old 1.9 versions.

Anyway as he said it's simple once a new version is final the old is not supported.

Take system updates, it's exactly the same. The moment you file a bug your told to update to the current package.

Updates are pushed for a reason, both for support and the actual package.

Agree, but there must be a better way to get the unaware to upgrade or be made aware? The pre-existing system obviously wasn't working, but if the solution is a forced update, it should be made clearer. A simple posting on this forum or to user list would have been sufficient.

Personally, I don't like any package updates to run un-attended in the middle of the night. Specifically, with ASL 2.2.6 several new settings for this update were not added to /etc/asl/config (asl -s -f not run or maybe it was?), asl-web/gradm wasn't updated (I asked why, no response yet), permissions on clam were changed (significantly) and an optional kernel update/dazuko dependencies + configuration settings were also rolled into the release (but can be run separately). Support for Plesk 9.5 is mentioned, but does that mean 9.5 is required or that any version up to 9.5 is OK. Is there a list of the Feature Request #'s we can review? etc. etc.


And that's why FTP/TLS stopped working on our server... and we run stock RHEL/Plesk boxes + ASL, using not-out-of-the-ordinary FTP/TLS. We were able to sort out the problem, but prefer to choose when to undertake updates/patches/fixes to ensure we assign time/staff to cover.

The ASL update notification was posted by Scott on May 10 at 6:41 pm (UK time) and the server updated at 4AM on May 11, that's a small window.

We all see a lot of support questions in these forums and as a community we help as best we can, but often I'm hard pushed to point users in the direction of relevant documentation. I'm really happy with ASL and the quality of product, but improved documentation with clear indication of modus operandi (and changes) is needed.

As ASL subscriptions increase, so to does the responsibility to offer support/guides/documentation for beginner > advanced (please, don't post link to the WIKI, or if you do, re-organise and update it first).

All of which makes any "support overhead" reduction counter-intuitive.

Just my 0.0133918p (based on today's exchange rate)

Hi Breun,

Yes I totally agree with your point.

Already I have so many little 'fixes' and I also like to keep some standard packages, so my asl repo files have a lot of excludes. I also sometimes have to rebuild some packages just to keep a high enough version number (denyhosts for example).

Often I find somethings been changed and I have to work around it as I find 9 times put of 10 it won't change back.

I also have 'custom' servers, meaning I have to set custom not webserver. I have asked and asked to have this preserved in the asl config, as it kills off cups on our internal network server! It's also the gateway for the LAN / WAN.

So I just had to implement fixes.

I think when features change it should go to a poll, and any config option for example custom be maintained.

The rkhunter allow rootlogins forced no - I don't see the logic. If you and I allow rootlogins (which we do obviously), why a daily more or less spam from rkhunter?

Anyway I do know where your coming from, trust me, but your at stage 2 frustration, I am at stage 5, gone through depression, dispair and moved into just bloody patch around it.

Unfortunately I can see your going to have to like me run cron jobs, or simply disable all updating and do it manually and then patch

I tend to agree with the "no automatic yum" crowd. I'm still dealing with 2.2.6 fallout (the new OSSEC isn't playing nice with another process on my machine and I have a cron job killing it every hour or so). My other machine is doing fine now but that was only after manually running asl -s- f and restarting OSSEC. This is causing no end of grief and support has been slow I guess due to all the other problems (close to 24 hours and no email response). I rarely move to new versions the day after release for this reason. If the server starts acting up my boss gets anxious (and we're in peak retail season). Add in that there's a rumor going around that Google indexes slower sites less frequently (thank Matt Cutts) and you have a recipe for max hassle.

As my wife likes to say, not cool.

Well this is all good input, and a great place to really make your voice heard is during the beta period. So please (please, please, please) participate in the -testing channel if you can.

Fair point. We were running testing channel on one server up till Feb this year; experienced very few issues as it happens. Sadly, we do not have a box "living on the edge" and therefore suitable for this purpose at the moment.

Yeah, the problem with the testing channel is that it isn't really something we can use on production servers, and without testing it on production servers we don't necessarily know what problems we'll face. Egg. Turtle*.

As such, we assume to a certain extent that there might well be problems with the upgrade and so it is necessary to do so at a time and date that works for us so that humans can be available to monitor logs and services for problems and if necessary rectify any issues or to contact support if we are unable to fix or figure out what's gone wrong.

(* For those who don't know, turtles lay eggs just like chickens)

I think the previous comment from faris pretty much sums it up AND included a turtle reference to boot

Sorry to play the devil but if you all had participated it would not change the rkhunter allow rootlogin no issue, I found this a month ago and was told it's a depreciated option.

But I then patched around it.

I have never had testing repo bring down a server. I run ASL in testing any my OS testing repos and I like to be ontop of things.

If your running a later OS that support yum downgrade it's so easy. I even backported the later yum to a clients F7 server.

Suggestion - Scott why not a forum just for testing and issues. It should have a FAQ section or a sticky for workarounds - AKA rkhunter for example.

I still do not understand why not add a extra option in asl config to allow root logins and shut up rkhunter, else remove it completely out of the asl config it does nothing right now.

I hope we then don't see an update that simply ends up killing off root logins off the server completely.

Also I thought there was supposed to be some audit security tool to allow you to tweak alerts coming mentioned ages ago has it just disappeared into the ether? I already tweak the reports in cron removing such warnings as running php in non safe mode - I use php-5.3 and there is no such option, that is now is truly 'depreciated'

Sorry if I sound peeved, but it seems things change and no one is really listening or suggesting workarounds, that is just how it is now.

We definitely listen, please tell me whats not being listened to so we can respond.

OK, to capture all this feedback as features, heres what I have so far:

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) 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 #4 below)

4) 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).

5) 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)

6) 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: See #5, I think I know whats being asked for, basically an ignore button... )

7) 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)

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)

Anything else?