OK now that 3.0 is here, its time to tell us what you want in the next major release. As long time users know, we use a user driven release and feature cycle. Based on what we can accomplish in short blocks of development and testing, we build in the most popularly requested features for the next release.

So if you want us to add something to ASL, change something, etc - let us know!

The rules are simple:

1. The more elaborate the feature, the longer it takes, so other features will get bumped2. The sky is the limit, but take care to remember rule #1.3. Two major features per milestone period, but take care to remember rule #14. You may vote for 2 features *only* per period. You can change your vote at any time.5. Write-ins are OK, and encouraged. We will update the candidate list as they come in.

Previous candidates that are still open (if we missed something, let us know):

Candidate #15: Currently you can only enable/disable several major classes, ie spam, blacklist, etc. Please change thsi so that you can more define which types you want active. For example, if I want to disable anything that checks on the referer - I have to disable them one by one or to check the files themselves, disable the rules individually and then hope they dont change or more dont get added later on down the road. Some of these could be in mutliple classes too such as referer spam, blacklist or malware in referer, etc. Please change it so that I can turn off referrer checks altogether regardless of which parent rule set its in.Or add sub classes to each so that I can turn off certain checks against args, certain sub clases against referrers, etc.

Candidate #16: Support for mod_cband, to replace mod_bw in Plesk. With default values and the ability to set bw limits per vhost, throttling, and a sort of QoS priority but on a vhost level

Candidate #17: Expand the Atomic-Scanner package to allow you to run a system as an anti-spam/anti-malware service for downstream servers. Like Postini, or mimecast. Like Project Gamera

Candidate #20: Going a little further it would be great to setup PSA so that when a new system user is created it adds them to the RBAC for that group so that FCGI can be limited by roles for a group rather then per user. It would also be nice if you could tie this into some kind of resource management so that users in that group cant have processes that use more then X amount of resources - although Im not sure if that would be better suited for something like PAM even though the users never get a shell.

Candidate #21: A migration manager for importing / exporting ASL settings between 2 servers using an export file would be a nice feature to have as well.It could be very usefull when migrating and existing solution to a new hardware, or for quick setup of similar installations such as when you have many VPS, but probably a VPS template would do the job in this very specific case. I beleive an export settings feature would more lightweight and would offer more possibilities though.

Candidate #22: auto-resizing GUI for smaller screens.

Candidate #23: Roll back rules to older version

Candidate #24: Non interactive ASL installer

Candidate #25: asl-lite to asl upgrader

Candidate #26: Per domain "log only" mode for WAF with a timer to turn it back onto to block mode (15m, 1h, 1d, etc.)

Candidate #27: In GeoBlocking GUI, ability to click on country to see IP range that ASL uses. (you can see the ranges now in the country-map.gz file in /var/asl/data)

Candidate #28: Cancel false positive/negative button in GUI

Candidate #29: Configure ASL to use the Control Panel SSL and not the OS server one which most people that run control panels do not even realize that once a server is built and the control panel is installed and they purchase a server wide SSL for the CP that it does not cover the one that is created when a server is first built.

New Candidate #2: Add in special user defined whitelist for just RBL rules

New Candidate #3: Add in suhosin to ASL

Some internal candidates we came up with:

Atomicorp Candidate #1: ASL RBL - basically a system thats driven by our honeypots and contains all the IPs from attackers, spammers, etc. And advanced version of this would allow everyone to participate by contributing your own attack data to the system. And a really advanced version of this would allow you to create your own RBL based on your data sources.

Atomicorp Candidate #2: Malware scanning tab in ASL GUI, to allow malware scans to be scheduled and monitored (this is in addition to the real time malware features that are already in ASL)

Atomicorp Candidate #3: Add in domain delegation capabilities in ASL. For example, spam rules and redaction are delegated to the domain owner. domain owner can only see their events in the ASL GUI, and can disable rules the system owner has delegated to them (the defaults from us would be things like spam rules, XSS, redaction and the like - things that could cause the system itself to be compromised or DOSed wouldnt be delegated by default)

Atomicorp Candidate #4: Redirect blocked users to a web page that explains why they were blocked and provides options based on the policy set by the system owner (examp,e, give them a captcha and allow for spam, admin password and allow XSS rules, report as false positive, etc.) Also for cases where the system owner does not want them to disable the rule, or allow the event, give them information to reach out the system owner to resolve the issue. (the domain and/or system owner would be able to disable/enable this depending on the type of rule triggered)

Atomicorp Candidate #5: Add in classes of redirects, for example spam redirect with a capatcha or possibly a password over-ride so the user can tell the system to ignore the block and let it thru (the domain and/or system owner would be able to disable/enable this)

Atomicorp Candidate #6: Add in different kinds of active response, for example if a particular account is attempted to be logged into too many times with bad passwords, lock the account but dont shun the IP. SMTP/POP/IMAP may be good candidates to start with (this are highly application specific, the app would have to support lock outs and would have to be known to react to the specific log entry that have web application, courier for example has unique log entries that are different from dovecot, etc.)

Atomicorp Candidate #7: RBL check, a service to check if your domains and IPs show up on any RBLs.

Atomicorp Candidate #9: Upgrade, but do not enable option. For example, if ASL adds in new PHP checks, do not enable the fix automatically, just report this as a vulnerability.

Atomicorp Candidate #10: Add in "explain" window to the side of the "Event Detail" window that will include the wiki page for that event automatically when you view the event.

Atomicorp Candidate #11: "Ignore" option, this means to still action (whatever that may be) on this event ID or IP address, but dont show it in the GUI anymore. This does not lower its priority, it just hides it.

Atomicorp Candidate #12: Dont log events for this IP, but allow actions to continue. For example, a PCI-DSS scanner will expect the system to have a WAF, so you dont want to whitelist it, but you also may not care to know its scanning you. (Candidate #11 seems like a better approach for this, just ignore)

Atomicorp Candidate #13: Add details windows for False positive/negative reports - which is helpful us too, we often times ask for more information about some FNs.

Atomicorp Candidate #14: DNS URI scans on web URLs. Basically check the URL to see if its on a spam list. We already do this for internal lists, this would be adding DNS URI checks (keep in mind, this requires a fast DNS server, and will result in some slow down because of your DNS servers as modsecurity waits for a response)

Atomicorp Candidate #15: Add in an "action" column to security events, to explain if ASL blocked, did not block, etc. the event. By default most events are blocked, but with the new "log only" option for the WAF, and upcoming redirect options plus the new rule manager which allows rules to be modified as log only this seems helpful to remind an admin of what is, and is not happening with an event.

Atomicorp Candidate #16: User defined RBLs

Atomicorp Candidate #17: More granularity on the rule manager, such as being able to add arguments to ignore on the fly for WAF rules, or to change thresholds for HIDS rules (such as # of auth failures, in X seconds to trigger the rule)

Atomicorp Candidate #19: Intercept and scan file uploads thru file managers in Plesk, cpanel, etc. control panels (the real time malware kernel level protection provides a better solution, then it doesnt matter where the file gets uploaded, however VPS users who's host is not using the ASL kernel will not have this level of protection, so upload scanning is the only solution)

Atomicorp Candidate #20: Add LVE to kernel

Atomicorp Candidate #21: "Autowhitelist" search engines, still block the action but dont firewall off the search engine (keep in mind this very hard to do, google does not publish its IP ranges and useragent strings are trivial to forge, so this is not foolproof nor should it be assumed that this is a good solution for broken or malicious searches, so things should be blocked and firewalled like "google hacks" and other malicious activity using search engines).

This is great and looks even more promising as ASL evolves into the future and some of the candidates look awesome. but is it possible to add this below? i know it was discussed before with asl 2.0 and i thought it was going to be part of 3.0 but seems it did'nt make it in into 3.0.

Configure ASL to use the Plesk Control Panel SSL and not the OS server one which most people that run plesk do not even realize that once a server is built and plesk is installed and they purchase a server wide SSL for the CP that it does not cover the one that is created when a server is first built.

I'm a prime example of this issue, where i always thought that when i installed the CP wildcard ssl it covered the whole server including the initial ssl. But it was'nt til a couple days ago that i realized that when you update or install a new or renewed ssl in plesk cp it does not cover the whole server. Because now when i get to asl i get a cert expired error even thou i just installed a wildcard ssl in the cp that covers the host name of our box. That has left me now to figure out how to get the plesk cp ssl to work for the whole server which seems to be alot more complicated and out of my realm of expertise after doing some googling.

In the ASL GUI, make it so a user can be restricted to seeing only ASL events for a specific domain (might be a tall order but the ability to tie this to a Plesk or Cpanel account would be a HUGE plus).These users could then report their own false positives but they would go to the administrator for approval, who could use the existing GUI tools to file a report with ASL, whitelist, etc.(EDIT If it helps simplify, count this as a vote for AC #3)

I like AC #4 but with one small request added in: the pages have to be able to be branded to the company doing the hosting. Maybe use some kind of templating system (i.e. Smarty) to help control this.

_________________"Its not a mac. I run linux... I'm actually cool." - scott

Last edited by Highland on Mon Aug 15, 2011 8:28 am, edited 1 time in total.

I like AC #4 but with one small request added in: the pages have to be able to be branded to the company doing the hosting. Maybe use some kind of templating system (i.e. Smarty) to help control this.

Shouldnt be a problem to make them editable at the very least. For the templating system I'll add that as an enhancement in case we need to table that until later to at least get the feature out there.

In the ASL GUI, make it so a user can be restricted to seeing only ASL events for a specific domain (might be a tall order but the ability to tie this to a Plesk or Cpanel account would be a HUGE plus).These users could then report their own false positives but they would go to the administrator for approval, who could use the existing GUI tools to file a report with ASL, whitelist, etc.

Thats what I had in mind for #3, does #3 seem like a fit for this? Or were you thinking about more?

As the voting goes on, we may be merging some of the "overlapping" features into single candidates - as so far the voting is hitting on the same themes and we may be able to add in more than two candidates at this rate. For example, the whole delegating some rule functions to domain owners, letting them only see their events (and whitelist just for their domains), custom error pages (as opposed to 403s and shuns), and "timed" log only modes are really close to each other and overlap quite a bit. So it may be possible to merge all of this into one candidate feature. If there is a particular enthusiasm for doing that, please speak up.

We try to limit it to "2 votes" to keep the lists realistic, but if you find you need to weigh in on more than two please do. They may be solvable at the same time as another candidate. And if you see opportunities to "merge", let us know. You may be right that we can do it (of course, on the back end it might be more complicated than it seems too, but you won't know unless you ask!)

Configure ASL to use the Plesk Control Panel SSL and not the OS server one which most people that run plesk do not even realize that once a server is built and plesk is installed and they purchase a server wide SSL for the CP that it does not cover the one that is created when a server is first built.

I'm a prime example of this issue, where i always thought that when i installed the CP wildcard ssl it covered the whole server including the initial ssl. But it was'nt til a couple days ago that i realized that when you update or install a new or renewed ssl in plesk cp it does not cover the whole server. Because now when i get to asl i get a cert expired error even thou i just installed a wildcard ssl in the cp that covers the host name of our box. That has left me now to figure out how to get the plesk cp ssl to work for the whole server which seems to be alot more complicated and out of my realm of expertise after doing some googling.

In the ASL GUI, make it so a user can be restricted to seeing only ASL events for a specific domain (might be a tall order but the ability to tie this to a Plesk or Cpanel account would be a HUGE plus).These users could then report their own false positives but they would go to the administrator for approval, who could use the existing GUI tools to file a report with ASL, whitelist, etc.

Thats what I had in mind for #3, does #3 seem like a fit for this? Or were you thinking about more?

AC #3 does sound like it. A tie-in to Plesk accounts (or even in the Plesk admin tool like ASL used to do) would be a bonus.

_________________"Its not a mac. I run linux... I'm actually cool." - scott

I'd like to suggest an additional candidate: the ability to re-set ASL to a default install/configuration (wiping all existing customisation), useful in situations where ASL user settings may cause unexpected behaviour after updates and user simply wishes to get server running correctly.

I would prefer a "save&restore-asl-config" option ... and be able to revert/export/import etc...

Yeah, I can envisage that being useful. The Rule Management is becoming pretty complex, so being able to back-up, runs some test's and revert easily would be advantageous (and save me keeping countless notes). Additionally it would allow ASL config to be copied to another system (good when migrating/setting up new server).

Who is online

Users browsing this forum: Bing [Bot] and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum