Hi guys,

I was wondering if there is any way how I can use your mod_security rules for NGINX. NGINX doesn't load any apache modules, so I was wondering if you have any plans to expand and add support for other servers?

I want to give NGINX a try, but without some advanced security rules I wouldn't do that.

Anyway keep up the great work, I need to check out how far your WHM mod is now.

Best,
Oliver

They dont support mod_security, but I saw a feature request for it here: http://wiki.nginx.org/FeatureRequests

You can use nginx with our rules by putting a reverse proxy apache with mod_security in front of nginx. Thats actually very lightweight and something we will be adding post 3.0 as an option for sites running alternative web servers like nginx, etc. As Scott said, nginx does not have any WAF module or capability, so theres no way you can do anything like modsecurity inside nginx.

People have requested the nginx team add a WAF, and I know lightspeed is working on full modsec support, but so far I havent seen anything for nginx. So if you use nginx, and you want a WAF to protect it, you will need to put a WAF in front of it.

And as I said, this works great so I highly recommend you do that. We've got a bunch of customers running all sorts of non-apache webservers with apache reverse proxies and mod_security in front of them. And as I mentioned, we will be adding this into ASL post 3.0 release as an option for non-Apache web servers.

Awesome!

What's the ETA .... Any chance ASL 3 will be out before July 2011?
(Assume you meant this will be in ASL 3)

Cheers

ASL 3.0 is on schedule to be released this quarter.



No, the proxy will be a post 3.0 feature. It will not be in the ASL 3.0 release.

Check out http://code.google.com/p/naxsi/
From what I understand it doesn't use signatures at all. It uses another method which can supposedly detect new/unkown attacks.
v0.1 was only released 5 days ago so it might be a while until you can use on a production server. I'll test it on a vps though.

Thanks for the link. Looks neat, this also exists for modsecurity. We actually have both in ASL, but we realize that if you take a pure whitelisting approach (which ASL can do) the "learning phase" for a hosting system is pretty close to infinity. On a shared server, where you add new customers automatically, you have to come up with a policy in advance thats general enough to allow any random web application to just work as you add users, domains, applications, etc. and yet still stop the bad guys. If you have such a dynamic environment, then you not only to deal with more false positives (because things are changing are you dont have rules for it), but you are forced to go back into learning mode thereby leaving your system open to attack. If you environment is static, then whitelisting is feasible until you change your app (then you have to go back and relearn, take the system offline, etc.)

From a security point of view, us security guys LOVE whitelisting. Its "perfect". It can't fail (well, it can, but thats another story). In security terms it works marvellously.
From a real world point of view, its really tough to use this in any dynamic environment.

In ASL, we take a mixed approach, we have whitelisting technology in there, along with blacklisting and greylisting to provide a good balance to make the security in the system usable. The idea that the best solution is whitelisting seems a bit naive to me, so I hope they support the inverse so we can put together a practical solution people can just use right out of the box.

If naxsi can support pre-built rules, then I think its a good technology to look at it. If it can only do learned whitelisting, then I think its only going to be useful for a small number of folks or very static systems with structured changes to their applications. In short, probably not a good candidate for a shared hosting environment, but maybe a good tool for corporate customer that runs their own systems and can take the time to develop these policies for their servers (much like how our Military customers use the self learning RBAC in ASL, its stronger than selinux and they have the time and structured one-purpose systems where its feasible to do that).

Thanks again for the pointer. Also, the modsecurity project is looking to port to nginx.

I'll install it as well.

The points Mike make are valid although I think this is well suited to Nginx as in reality, it isn't, in standalone, really geared for mass hosting setups in the first place. It can of course be used in a "proxy pretty much all" mode such as in the ART Accelerator but then you might as well use ModSec for the proxied requests in that case.

Hello guys,

I'm the author of naxsi, and I'll be glad to hear some feedback from your tests !

Actually, even if the software is only in version 0.3, I've been doing a lot of tests on it, and we are currently deploying it on several production sites.
I heard some of you talking about mod_security and CRS. You might be glad to know that we are seriously considering integrating CRS level 1 support into naxsi, as the work is already half-done (as, even we work on a positive model, it can be used as well on a negative based model, just that, as a pentester, I don't believe that much in negative models for WAFs). In this way, we will be able to use naxsi + CRS on sites where a positive model approach is not adapted (sites with *very* rich user content and so on !)

Feel free to contact me, suggest things or give some feedback

Thanks for joining us, and thanks for your work on naxsi.



Do you mean level 1 core feature support? (http://sourceforge.net/apps/mediawiki/m ... e_Features), if so thats good to hear. With that said, the webpage there is a bit misleading. A port with just those features is unfortunately not going to be very useful.

I'd recommend you look at the branching logic tokens as well at a minimum, and persistent collections, which are used in all the rule sets out there. Any port that doesnt support those isn't going to be much use because none of the rulesets will work correctly without those features. I know, we run into this all the time with litespeed "port" of modsecurity. Its feature incomplete, and leaves out stuff everyone uses, so no one can correctly load any rulesets. So whats the point of a partial implementation if no one can use it?

Anyway, so my two cents if you want to be able to support importing modsec rules, definitely support more than just the level 1 subset. There really isnt any ruleset that just uses level 1.

If you want a developers license to any of our products, just shoot an email to me (mike AT atomicorp DOT com) and I'll get you setup with free licenses. We'd love to figure out a way to support nasxi (btw, we fund a lot of open source projects too), and if we nasxi can support the full range of features we use in our modsecurity rules that would be perfect.

I just posted a long thoughtful post on the announcement that openBSD has pulled Nginx into their Base as future Apache replacement with some thoughts about Naxsi and the ART angle to both but when I hit the post button, I had been logged out.

No problem I thought, it did take me awhile to complete. Let me login again and let the process go through. Surely, I thought, the post would have been temporarily saved until login is confirmed and the process will continue.
Alas! Not so. This piece of @*i#! software had simply tossed away everything I wrote.

We are not pleased!

Nginx is now supported in ASL. Please see the configuration guide here:

https://www.atomicorp.com/wiki/index.php/Nginx