Naxsi, an open source WAF for Nginx

Naxsi, an open source WAF
for Nginx

©NBS System
Sécurité – Hébergement - Infogérance
www.nbs-system.com 1

©NBS System

A bit of background
(Seems webapp security is a good starter to talk about WAFs)

©NBS System

Overall security level of web applications evolves slowly , or at least not fast enough

• Low technical skill needed to exploit
most vulnerabilities (SQLi)

• Most actors did not reach a good
awarness level yet

(Nb of annual defaces, source: zone-h)

Because of these factors, number of attacks is dramatically growing

©NBS System

Just for May 2012 :
Govs or affiliated :
France
Bahrain
US
Thailand
Canada
Israel
… In Russia files includes you …

More than 300k accounts dumped each month

©NBS System

Web apps Classic IT

©NBS System

• Best mitigation : Patch

Not always possible :

Very complex or critical webapp
Lack of skill, knowledge lost

Your webapp security level can only be
known once you performed an (expensive ?)
security test on it.

©NBS System

• When code patching is not an option: Web Application Firewalls

Commercial WAFs :
Not very affordable for small companies
or big infrastructures
Extremely unequal quality

Open source WAFs :
Performance issues
Maybe not « corporate » enough for most
users ?
Maintenance time

©NBS System

As a pentester :
Web sites are still one of the most vulnerable
entry points on a network
And one of the most exposed as well !

As a hoster :
WebSite owners, even when web is their core
business, lack security awareness … and get
owned

As a security consultant :
CISO / Administrators are still frighten of
WHY U NO PROTECT ? WAF’s side effects
And the one using WAFs will only go for big,
expensive, corporate solutions (Hi Imperva!)

©NBS System

Enough teasing !
(and enough jokes)

©NBS System

When studying the idea of offering hardened web hosting for some of our clients,
we came accros several problems :

Commercial WAF are way too expensive for big infrastructures (especially with
a lot of small/medium clients)

Open Source WAFs (mod_security) are not fast enough (means: filtering POST
requests only if you don’t want to damage user experience)

Both kinds requires a huge investment to keep security signatures up-to-date

©NBS System

(Apr 2011) Naxsi project idea was born :

Hoster compliant WAF :
Performances / Scalability
Production grade WAF

A WAF that doesn’t require signatures / updates
Only when your site code base change

And because defense is for once funnier than attack

©NBS System

Naxsi’s design is closer to a sateless firewall than an anti-virus

Most WAFs are more web anti-viruses than firewalls
Relies on a big, heavy, frequently updated base of signatures

On the other hand, Naxsi does rely on signatures, but not in the way you might think

©NBS System

Naxsi relies on ~35 rules, targetting : SQLi, XSS, RFI/LFI, file uploads …

A rule is defined as :
A pattern (most of the time, one character, here : ‘ )
Scores (indicating the kind of threat it’s linked to, here both SQL and XSS)
Match Zones
And a unique ID

str:'" "msg:simple quote"
MainRule "str:'" "msg:simple quote"
mz:ARGS|BODY|URL|$HEADERS_VAR:Cookie"
|$HEADERS_VAR:Cookie id:1013;
"mz:ARGS|BODY|URL|$HEADERS_VAR:Cookie" "s:$SQL:4,$XSS:8" id:1013

When a request reaches a « limit » score, an action si taken upon the request :
CheckRule "$SQL >= 8" BLOCK;

Leaves a lot of room for fine-tuning

©NBS System

This naive approach has several advantages :
Fast : No massive, expensive regex set to process
Naive design : Naxsi doesn’t try to understand incoming requests. No need for
complex/costly transformation functions
Predictability : Not relying on « real » signatures makes bypass less likely to
happen
Small & Auditable code : <4K LOC

But comes with a price :
Whitelist configuration !

©NBS System

Naxsi, a tweakable WAF

©NBS System

Naxsi offers two « main » modes :
Normal mode : « Blocked » requests are redirected to a specific location
Learning mode : « To-be-blocked » requests are simply « copied » to a specific
location, and the original request is processed transparently

Redirecting requests rather than « blocking » them offers various possibilities for
blocked requests :
Return a specific error code to the user (HTTP 418: I'm a teapot)
Return a static page
Redirect user to a dynamic page (with captcha) to report false positives
Anything LUA/PHP/<language> allows you to do

Redirected requests contains both original request arguments, as well as « naxsi
signature » (in HTTP headers) :
ip=x.x.x.x&server=xx.ru&uri=/&total_processed=1&total_blocked=1&zone0=HEADER
S&id0=1308&var_name0=cookie&zone1=HEADERS&id1=1309&var_name1=cookie

©NBS System

Naxsi in test bed
« Reliability of naxsi model
versus obfuscated patterns »

©NBS System

0 div 1 union#foo*/*bar
select#foo 0 div 1 union select 1,2,current_user
1,2,current_user

mod_sec : Transformation on comments leading to a
bypass.

Naxsi : 2 SQL keywords, 4 SQL comments,
blocked early

©NBS System

hUserId=22768&From hUserId=22768&From
Date=a1%27+or&ToDa Date=a1'+or&ToDate=<
te=%3C%3Eamount+a >amount+and'')
nd%27

mod_sec : Victim of fragmentation (attack splitted
accross several parameters)

Naxsi : Evaluates the whole request, sees
multiple quotes, brackets, parenthesis

©NBS System

Naxsi in test bed
« Performances of the naxsi model »

©NBS System

Requests Per Second 6000

5000

4000
NGINX
3000 NGINX+NAXSI
APACHE
2000
APACHE+MODSEC
1000

0
100 300 500 1000 Plateform:
Concurrent connections my laptop

©NBS System

With apache-bench (1k concurrent requests, 10k total requests, long URL with
arguments) :

Nginx Nginx+Naxsi Diff (%)
Total time 1.151 s 1.271 s 9,4%
RPS 8687.21 7866.73 9,4%
TPR (mean) 0.115 0.127 9,4%
Transfert Rate 1220.48 1198.45 1,8%

©NBS System

Naxsi usage
« Hands on »

©NBS System

Learning
Daemon MySQL/Sqlite
(nx_intercept)

User(s)

Naxsi WebSite

©NBS System

Learning
Daemon
(nx_extract)

MySQL/Sqlite

BasicRule wl:1100 "mz:$BODY_VAR:redirect_to";
BasicRule wl:1005 "mz:$HEADERS_VAR:cookie" ;
BasicRule wl:1010 "mz:$HEADERS_VAR:cookie" ;

Naxsinaxsi
configuration
©NBS System

I won’t cover Ngnix setup, so let’s assume our setup is the following :
Nginx+Naxsi is used as a reverse proxy to an existing website
Naxsi setup is as :

SecRulesEnabled;
DeniedUrl "/RequestDenied"; server {
LearningMode; …
CheckRule "$SQL >= 8" BLOCK; location / {
CheckRule "$RFI >= 8" BLOCK; include "naxsi.conf";
CheckRule "$TRAVERSAL >= 5" BLOCK; proxy_pass http://x.x.x.x;
CheckRule "$UPLOAD >= 5" BLOCK; }
CheckRule "$XSS >= 10" BLOCK; location /RequestDenied {
proxy_pass http://x.x.y.z:8080;
}
…
}
Pointing to nx_intercept :
$ python nx_intercept.py -c ./naxsi-ui.conf
…

©NBS System

Naxsi’s learning daemons :
Nx_intercept : http requests interception daemon, feeds the database
Nx_extract : whitelist & statistics generation, fed from the database

[nx_extract]
username = naxsi_web
password = test
port = 8081
rules_path = /etc/nginx/core.rules

[nx_intercept]
port = 8080

[mysql]
username = naxsi
password = trivialpasswordormaybenot
hostname = 127.0.0.1
dbname = naxsi_sig

©NBS System

While the user is browsing,
exceptions are generated by
Naxsi, and HTTP requests
are forwarded to nx_intercept.

Nx_intercept extracts
signatures from forwarded
HTTP requests, and put them
into the database.

©NBS System

After browsing a bit (here two different pages), we can fire nx_extract, the whitelist
generation daemon :

©NBS System

Clicking on whitelist generation will get you there :
########### Rules Before Optimisation ##################
#1 hits on rule 1005 (mysql keyword (|)) on url / from 1 different peers
#BasicRule wl:1005 "mz:$URL:/|$HEADERS_VAR:cookie";
….
#BasicRule wl:1010 "mz:$URL:/test_securite_web|$HEADERS_VAR:cookie";
#1 hits on rule 1011 (parenthesis, probable sql/xss) on url /test_securite_web from 1
different peers
########### End Of Rules Before Optimisation ###########
# (mysql keyword (|))
BasicRule wl:1005 "mz:$HEADERS_VAR:cookie";
# open parenthesis
# close parenthesis

©NBS System

Naxsi usage
« Hands on : User forms »

©NBS System

But the real deal, with learning mode, is user forms !
Cookies, URL and so on will be detected in one browsing session, but what about
user forms ? You need to fill them, with all « authorized » characters, which can be
boring.
Thanks to Naxsi naive architecture, you can easilly fool him to reach your goal.

Let’s add a rule or two in our naxsi’s location configuration :

BasicRule id:0 "str:123FREETEXT" "s:BLOCK" "mz:ARGS|BODY|URL";
BasicRule id:42 "str:123EMAIL" "s:BLOCK" "mz:ARGS|BODY|URL";

©NBS System

This two rules will allow us, whenever we will type « 123FREETEXT » or « 123EMAIL »
within a field (GET/POST) to trigger naxsi, and output whitelist for :
Id:0 (which means *all* rules) whenever you input « 123FREETEXT »
Id:42 (which doesn’t exist) whenever you input « 123EMAIL »

The idea here is to be able to simply tell naxsi « whitelist everything » in this field, in a
convenient way.

And regarding id:42, replacing it by the Ids you want to whitelist is left as an exercice to
the audience (mainly because it’s not supported by nx_extract yet ;p)

©NBS System

Using the pattern « 123FREETEXT » in the website will thus generate a whitelist for
« all » rules, on specific element :

BasicRule wl:0 "mz:$URL:/|$ARGS_VAR:s";

©NBS System

Naxsi usage
« Hands on : User forms – another approach »

©NBS System

Naxsi is parsing both variable names and content
And most frameworks (magento, drupal etc.) provide « default » names, for several
kind of fields !

Do you see my point ? Not yet maybe …

©NBS System

In the case of magento, form fields use hardcoded name depending on type of field,
such as :
Firstname
Lastname
Email
Password
…
As a specific example, « search » field will always be passed as « q » :
BasicRule id:9002 "rx:^q$" "s:BLOCK" "mz:ARGS|BODY|URL";
And name fields are always named « firstname » in HTML forms :
BasicRule id:9003 "rx:^firstname$" "s:BLOCK" "mz:ARGS|BODY|URL";

©NBS System

Thus, browsing the website, and using the forms, even without specific patterns, will
trigger the rules, and you will see in whitelist generation :

BasicRule wl:9002 "mz:$URL:/catalogsearch/result/|$ARGS_VAR:q|NAME";

BasicRule wl:9003
"mz:$URL:/customer/account/createpost/|$BODY_VAR:firstname|NAME";

This allows you to perform « passive » learning. Let users use the website (in learning
mode), let them write your whitelist rules ;)

©NBS System

Nx_intercept can as well be fed by logfiles, nginx logfiles.
As Naxsi writes its signatures into Nginx’s error log :

ip=x.x.x.&server=xxx.ro&uri=/wp-
cron.php&total_processed=8140&total_blocked=1954&

It means two things :
You can use LearningMode, even without nx_intercept
You can get cool & nice reporting on the period you want (just inject Nginx’s log
files for this period !)

©NBS System

©NBS System

Naxsi simplicity and naive design allows you to simply write rules for whatever you
want :
Blocking robots ?
BasicRule id:X ‘str:BOT_USER_AGENT’ ‘mz:$HEADERS_VAR:user-agent’ ‘s:BLOCK’;

People looking for PhpMyAdmin ?
Basicrule id:X ‘rx:*phpmy*’ ‘mz:URL’ ‘s:BLOCK’;

As Naxsi writes signatures of attacks to Nginx’s error log, it’s fail2ban-friendly ;)
Why not let the learning mode on, and simply rely on fail2ban to push away insisting
attackers ?

©NBS System

November 2011 : « Charlie Hebdo » a french satiric newpaper, gets heavily targeted
by muslim hacktivists after an edition – representing Muhammad– was published.

Their office was burned, and …

©NBS System

Then Dos and Ddos follows …

Their actual hoster decides to shut down the website, by fear of retaliation

Migration was planned, but it became much more urgent

©NBS System

A small hardened infrastructure was setup within 8 hours :
Two RP NGINX + NAXSI (for redundancy)
A LAMP server

And here we go for first « fire experience » of naxsi !

At the time we migrated the website, we were already aware of some vulnerabilities
that were not possible to patch within such short delay, so all our hope was within
naxsi ☺

©NBS System

D+1 : Architecture is ready, dns migration ongoing
As stated earlier, we knew some vulnerabilities were present. Attackers did
know as well (as they already defaced the website twice)

D+1,5 : DNS migration is over

A small analysis of Naxsi’s logs on the first week
Over 32 000 HTTP requests blocked
Over 200 IP blacklisted

And the cool thing is that we didn’t get any false positives, and the website
remained safe.

Thanks for the bench !

©NBS System

Naxsi, an open source WAF for Nginx

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Naxsi, an open source WAF for Nginx

Similar to Naxsi, an open source WAF for Nginx (20)

More from Positive Hack Days

More from Positive Hack Days (20)

Recently uploaded

Recently uploaded (20)

Naxsi, an open source WAF for Nginx