Thats an interesting idea, maybe a way to save the "policy" for the rules and make it possible to load others (move them, etc.)?

This should not be a candidate to vote on, but just implemented. I recently opened 2 posts about this, because upgrading ASL (and not sending a mail that it got upgraded, which imho should be done as well) is one thing, but ASL should not ever touch the php.ini or http.conf and related files without permission. Web(hosting) environments rely on these files (especially php.ini), and when you change (disable) something, then some application may not work properly anymore. And the administrator may not find out about this for days until someone points him/her to it, and then he may not even know that ASL got upgraded and then spends hours looking for the cause of the problem. Which is what happened to me with this last upgrade to version 3.

Totally agree, the recent changes to PHP caused problems with several websites which relied upon curl_exec to handle credit card authorisation.

I'm adding in a new one/old one based an incident a customer just caused for themselves. (Wish I could do a really big frown, I feel so bad for them)

Candidate # 30: Light weight apache proxy with modsecurity to sit in front of nginx, litespeed, etc.

This customer unfortunately installed nginx in front of apache, and proxied almost all their sites to apache - except one, which nginx served up for them like the excellent web server that it is. And of course,because there is no modsecurity (or any WAF) for nginx, that site got totally owned using a really simple set of web attacks.

BTW, there is an effort underway to port to ngix, which brings me to candidate #31:

Candidate # 31: modsecurity port for nginx

This doesnt help litespeed though, which has a closed implementation of some of the features in modsecurity, but not the whole rule language unfortunately.

For any litespeed customers, we've been providing litespeed with free ASL licenses so they can work on making their modsecurity implementation complete. I was emailing them about it today, so its possible they may support the full rule language in the immediate future, they do not currently though so its not complete, and if you use it you will be vulnerable to attacks that apache users are not. So do encourage them to support the entire language, we would love to be able to check that off as a fully supported web server!

selinux

Can you elaborate some more? The ASL kernel supports the weaker selinux system now, the stronger RBAC system is enabled by default.

Here are my votes:

Near future:
Atomicorp Candidate #4: Redirect blocked users. (I don't understand the difference between this and #5)
Candidate # 31: modsecurity port for nginx

Down the road:
Atomicorp Candidate #1: ASL RBL
*NEW*: Configure service monitoring from asl gui (possibly replacing psmon with monit). I've been using monit for a little while now and I think I've finally got it configured so that it can bring apache back up even with a "subsys locked" error.

Great feedback so far everyone. It looks like the redirect pages are in the lead right for one of the big features, so we're going to start working on them shortly. This doesnt mean the voting has ended, we just want everyone to know what we will be working on in the mean time.

AC #4 - with support to upload custom html with tags for where the explanation messaging (generated by ASL) would go. Multi-lingual support also would be good here.
and
Candidate #21

And my own...

Improve the license manager interface so I can see which servers are using ASL and how many licenses I have purchased, expiration dates etc. Could be cleaner and nicer design for this.

I agree with that

For me those would be great:
Atomicorp Candidate #4

Atomicorp Candidate #21
rergarding #21:
might it be useful to write a wrapper that DNS lookups for the characteristic googlebots?
something that has the logic in it to verify real bots by the user-agent and only whitelist it if it matches.
http://www.google.com/support/webmasters/bin/answer.py?answer=80553
http://www.google.com/support/webmasters/bin/answer.py?answer=1061943

Maybe those links are useful somehow (could not attach them another way without getting shunned):
perishablepress.com/press/2010/07/14/blackhole-bad-bots/
sebastians-pamphlets.com/smart-robots-txt
projecthoneypot.org
botsvsbrowsers.com
Just an idea.

Thanks for the feedback we really appreciate it!



You are limited to four URLs in a post to the forums. Any more than that and you will get shunned.

Yeah, I'm still trying to figure out a way to do this that doesnt kill the users experience with the server. DNS lookups on source IPs *before* serving up content will make the server appear to be really slow to the user (the server isnt actually slow, its just waiting for the lookup to complete).

So we dont want that, any thoughts on how you would like to see candidate #21 work? Heres my current working idea:

1) If the UA claims its googlebot then, dont serve up content until we finish the steps below:
2) lookup the IP, if it says its google, then do a reverse and make sure the FQDN matches the IP as well.
If it really is a google boot:
auto-whitelist the IP (dont shun it)

If it is NOT really a google bot:
block and shun the host

Optional: If it is a search engine, dont block anything it does either (let google/bing/etc. do whatever it wants to the system)

That may work and if you slow down google, thats probably not so bad and we could cache the IP for a period of time and only look it back up on an interval so this doesnt happen every time the IP connections. I dont think the option step (and dont block it either) should be the default, not shunning a search engine is a good idea, not blocking it may not be a good idea.

Let me explain, and please lend me your thoughts:

We have rules that try to trick search engines when they are being used to do bad things. For example , that is if a bad guy is carrying out a "google hack" to try and find vulnerable applications we return a 404 for those searches, so the bad guy doesnt think you are vulnerable (and moves on) - and by badguy that might be a fully automated worm so you definitely want them to get a 404 and leave.

If you have shunning setup, ASL will also shun the search engine. So, maybe we make that class of rules by default to not-shun, but still "block". The same is true for DLP rules, we dont want google caching sensitive data from your server, but we dont want to shun it either.

Are there any rules you think a search engine should never be blocked on? (not shunned, we can handle that differently) My gut says no to the security rules, although maybe to the spam rules.

Thoughts appreciated.

This is kind of like graylisting, but for web access, isn't it?

Unfortunately Google now insists everybody serves pages asap and is actively recording page serve times. If they don't do it already, they will start making speed of page serving part of the ranking algorithm before too long. So any slowdown, at all, will cause problems.

If Google allowed any sort of human contact you could get in touch and discuss this with them, suggesting they specifically exclude the first X accesses or Xth percentile or something. But oh no. No such thing as human contact with Google.

You may note I'm a bit bitter --well I am. But that's for another post in another secion.

thanks for the feedback.

@faris: I feel your pain. It's love&hate thing regarding Google for me. Some things Google does very well, others they take advantage of their monopoly and that is scary and makes me upset.

@Mike: havent thought about the delay you and faris mentioned, but I think a delay is not good. I totally agree that the "bad code" should be left out. Unfortunately my knowledge on rules level is not good enough to comment on that one.
But "Google hacks" and "Spam Stuff" should be kicked somehow. If we shunn than for Google it looks like being "blocked" or not? Even if not they give you a bad rate due to speed which would upset the customers.
Due to lack of knowledge regarding the rules I'm not very helpful I think Sorry. But I do my best.

What about this idea:
Maybe it's a good point to mix with #1 and thinking about an ASL-collaborative-collection of search-engine-whitelist & blacklist. It might be longterm think. For example if we start with a learn mode and all ASL people that want to can collect data and we share them automatically. in a few months we might have a good list of IP's to start AWL with! Make a ipwhois check to get subnets out of it and than use the AWL. I can't believe that Google ever gets rid of his subnets they already have.

btw. why can't we get a list from iana? I have always asked that myself.
Maybe getting in touch with Ben Laurie at Google (benl&google.com) might be an idea?!
He's listed as contact at iana for Google Inc. and a founding director of The Apache Software Foundation and a core team member of OpenSSL. He wont give us the IPsfor sure but he might come up with something useful.
He, as an IT guy, might/should be interested in security.
Like always, just and idea. Might be silly but just brainstorming doesnt hurt.