Defending Layer 7: A look inside Web Application …15 years in TI, 6 years in Information Security Experience with ISO 27001, HIPAA and PCI Compliance, Audit, Risk management. Expert

DefendingLayer7:AlookinsideWebApplicationFirewalls

OWASPAguascalientes- ChapterMeetingSeptember – September1st2016

{AlejandroJalomo,MSc,CISSP,CRISC,CISA,ISO27001LA}§ 15yearsinTI,6yearsinInformationSecurity§ ExperiencewithISO27001,HIPAAandPCICompliance,Audit,

Riskmanagement.§ Expertindataprotectionsolutions§ Drummer,black&graytattoos,concerts

{DavidGarcia}§ Morethan8yearsinInformationSecurity§ ExperiencewithApplicationSecurity,VulnerabilityManagement,ThirdParty

Compliance.§ ExpertinPentesting§ Rubik’scubes,soccer,Necaxa

About us

We arenot insocialnetworks,we just talk byphone

Agenda

§ What is aWebApplication Firewall(WAF)?§ When touseaWAF?§ WAFArchitecture§ KeyMarket Players§ TopTenOpenSource WAFs§ Typical WAFArchitecture§ Difference between IPSandWAF§ What is ModSecurity?§ What ModSecurity cando?§ Deployment Options§ Main Areas ofFunctionality§ What RulesLookLike§ Transaction Lifecycle§ UsefulRules§ Transaction Example§ Otherprojects§ WhatisWebKnight?§ Questions§ Demos

What is aWebApplication Firewall(WAF)?

§ A web application firewall (WAF) is an appliance, serverplugin, or filter that applies a set of rules to an HTTPconversation.

§ Generally, these rules cover common attacks such as cross-sitescripting (XSS) and SQL injection.

§ By customizing the rules to your application, manyattacks can be identified and blocked. The effort toperform this customization can be significant andneeds to be maintained as the application ismodified.

What is aWebApplication Firewall(WAF)?

§ Software or appliances used to filter unwanted TCP port80/443 traffic from connecting to a web server

§ Web Application Firewalls:• Examine within the data payload, beyond simply the

IP or TCP headers• Perform "Deep packet inspection"• Detect and respond to signatures for known

application vulnerabilities• Do not require modifications to existing application

code

When touseaWAF?

Gartner 2016 Magic Quadrant for Web Application Firewalls

Magic Quadrant for WebApplication Firewalls,Published:19July 2016

KeyMarket Players

Top10Ope

nSource

WAF

s

1. ModSecurity (Trustwave SpiderLabs)2. AQTRONIXWebKnight3. ESAPIWAF4. WebCastellum5. Binarysec6. [email protected]. OpenWAF8. Ironbee9. Profense10.Smoothwall

Typical WAFArchitecture

Difference between IPSandWAF

AnIPSgenerallysitsin-lineandwatchesnetworktrafficasthepacketsflowthroughit.Itactsbytryingtomatchdatainthepacketsagainstasignaturedatabaseordetectanomaliesagainstwhatispre-definedas"normal"traffic.

IPSsdonothavetheabilitytounderstandwebapplicationprotocollogic.Hence,IPSscannotfullydistinguishifarequestisnormalormalformedattheapplicationlayer(OSILayer7).

WAFs are designed to protect web applications/servers fromweb-based attacks that IPSs cannot prevent. In the sameregards as an IPS, WAFs can be network or host based. They sitin-line and monitor traffic to and from webapplications/servers. Basically, the difference is in the level ofability to analyze the Layer 7 web application logic.

By watching for unusual or unexpected patterns in the trafficthey can alert and/or defend against unknown attacks. Forexample- if a WAF detects that the application is returningmuch more data than it is expected to, the WAF can block itand alert someone.

Difference between IPS and WAF

WhatisModSecurity?

• An HTTP intrusion detection tool• Lets you see your web traffic• Once you are able to see HTTP traffic, you are able to analyze it in real time,record it as necessary, and react to the events

• Without actually touching web applications• The concept can be applied to any application—even if you can’t access thesource code.

ModSecurity is a toolkit for real-timeweb application monitoring, logging,and access control.

• Real-timeapplicationsecuritymonitoringandaccesscontrolAt its core, ModSecurity gives you access to the HTTP traffic stream, in real-time, along with theability to inspect it.

WhatModSecurity cando?

• VirtualpatchingVirtual patching is a concept of vulnerability mitigation in a separate layer, where you get to fixproblems in applications without having to touch the applications themselves.

ModSecurity excels at virtual patching because of its reliable blocking capabilities and theflexible rule language that can be adapted to any need.

• FullHTTPtraffic loggingModSecurity gives you that ability to log anything you need, including raw transaction data,which is essential for forensics.

• Webapplication hardeningModSecurity is attack surface reduction, in which you selectively narrow down the HTTPfeatures you are willing to accept (e.g., request methods, request headers, content types, etc.).

DeploymentOptions

• EmbeddedBecause ModSecurity is an Apache module, you can add it to any compatible version of Apache.

The embedded option is a great choice for those who already have their architecture laid outand don’t want to change it.

• ReverseproxyReverse proxies are effectively HTTP routers, designed to stand between web servers and theirclients.

You can use it to protect any number of web servers on the same network.

Main Areas ofFunctionality

• ParsingThe supported data formats are backed by security-conscious parsers that extract bits of dataand store them for use in the rules.

• BufferingBoth request and response bodies will be buffered. This means that ModSecurity usually seescomplete requests before they are passed to the application for processing, and completeresponses before they are sent to clients.

Main Areas ofFunctionality

• LoggingThis feature allows you to record complete HTTP traffic. Request headers, request body,response header, response body will be available

• RuleengineThe rule engine builds on the work performed by all other components. By the time the ruleengine starts operating, the various bits and pieces of data it requires will all be prepared andready for inspection.

Atthatpoint,theruleswilltakeovertoassessthetransactionandtakeactionsasnecessary.

What RulesLookLike

SecRule ARGS"<script>"log,deny,status:404

SecRule VARIABLESOPERATORACTIONS

configurationtellsModSecurity howtoprocessthedataitsees;therulesdecidewhattodowiththeprocesseddata.

Thethreepartshavethefollowingmeanings:

1.TheVARIABLESparttellsModSecurity wheretolook.TheARGSvariable,usedintheexample,meansallrequestparameters.

2.TheOPERATORparttellsModSecurity howtolook.Intheexample,wehavearegularexpressionpattern,whichwillbematchedagainstARGS.

3.TheACTIONSparttellsModSecurity whattodoonamatch.Theruleintheexamplegivesthreeinstructions:logproblem,denytransactionandusethestatus404forthedenial(status:404).

Transaction Lifecycle

RequestHeaders(1)

allowrulewriterstoassessarequestbeforethecostlyrequestbodyprocessingisundertaken

Forexample,ModSecurity willnotparseanXMLrequestbodybydefault,butyoucaninstructitdosobyplacingtheappropriaterulesintophase1.

Transaction Lifecycle

RequestBody(2)

isthemainrequestanalysisphaseandtakesplaceimmediatelyafteracompleterequestbodyhasbeenreceivedandprocessed.

Transaction Lifecycle

ResponseHeaders(3)

takesplaceafterresponseheadersbecomeavailable,butbeforearesponsebodyisread.

Therulesthatneedtodecidewhethertoinspectaresponsebodyshouldruninthisphase.

Transaction Lifecycle

ResponseBody(4)

isthemainresponseanalysisphase.Theresponsebodywillhavebeenread,withallitsdataavailablefortherulestomaketheirdecisions.

Transaction Lifecycle

Logging(5)

It’stheonlyphasefromwhichyoucannotblock.

Bythetimethisphaseruns,thetransactionwillhavefinished,sothere’slittleyoucandobutrecordthefactthatithappened.

UsefulRules

AVIntegration

Drop for Brute ForceSecAction phase:1,initcol:ip=%{REMOTE_ADDR},nologSecRule ARGS:login "!^$"\

nolog,phase:1,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt=20/120SecRule IP:AUTH_ATTEMPT"@gt 25"\

"log,drop,phase:1,msg:'PossibleBrute Force Attack'"

SecRule FILES_TMPNAMES"@inspectFile /opt/modsecurity/bin/file-inspect.pl“\phase:2,t:none,log,block

Transaction Example

POST/?a=testHTTP/1.0Content-Type:application/x-www-form-urlencodedContent-Length:6b=test

parameterainthequerystringandparameterbintherequestbody

request

Transaction Example

HTTP/1.1200OKDate:Sun,17Jan201000:13:44GMTServer:ApacheContent-Length:12Connection:closeContent-Type:text/html

HelloWorld!

ModSecurity is first invoked by Apache afterrequest headers become available, but before arequest body (if any) is read.

First comes the initialization message, whichcontains the unique transaction ID generated bymod_unique_id.

Using this information, you should be able topair the information in the debug log with theinformation in your access and audit logs.

At this point, ModSecurity will parse theinformation on the request line and in therequest headers

response

Transaction Example

Inthisexample,thequerystringpartcontainsasingleparameter(a),soyouwillseeamessagedocumentingitsdiscovery.ModSecurity willthencreateatransactioncontextandinvoketheREQUEST_HEADERSphase:

[4] Initialising transaction (txid SopXW38EAAE9YbLQ).[5] Adding request argument (QUERY_STRING): name "a", value "test"[4] Transaction context created (dcfg 8121800).[4] Starting phase REQUEST_HEADERS.

Assuming that a rule didn’t block the transaction, ModSecuritywill now return control to Apache, allowing other modules toprocess the request before control is given back to it.

Transaction Example

In the second phase, ModSecurity will first read and process the requestbody, if it is present.

In the following example, you can see three messages from the input filter,which tell you what was read.

The fourth message tells you that one parameter was extracted from therequest body. The content type used in this request (application/x-www-form-urlencoded) is one of the types ModSecurity recognizes and parsesautomatically. Once the request body is processed, the REQUEST_BODY rulesare processed.

[4] Second phase starting (dcfg 8121800).[4] Input filter: Reading request body.[9] Input filter: Bucket type HEAP contains 6 bytes.[9] Input filter: Bucket type EOS contains 0 bytes.[5] Adding request argument (BODY): name "b", value "test"[4] Input filter: Completed receiving request body (length 6).[4] Starting phase REQUEST_BODY.

Transaction Example

Shortly thereafter, the output filter will start receiving data, at which pointthe RESPONSE_HEADERS rules will be invoked:

[9] Output filter: Receiving output (f 81d2258, r 81d0588).[4] Starting phase RESPONSE_HEADERS.

Transaction Example

Once all the rules have run, ModSecurity will continue to store the responsebody in its buffers, after which it will run the RESPONSE_BODY rules:

[9] Output filter: Bucket type MMAP contains 12 bytes.[9] Output filter: Bucket type EOS contains 0 bytes.[4] Output filter: Completed receiving response body (buffered full - 12bytes).[4] Starting phase RESPONSE_BODY.

Transaction Example

Finally, the logging phase will commence. The LOGGING rules will be run firstto allow them to influence logging, after which the audit logging subsystemwill be invoked to log the transaction if necessary. A message from the auditlogging subsystem will be the last transaction message in the logs. In thisexample, ModSecurity tells us that it didn’t find anything of interest in thetransaction and that it sees no reason to log it:

[4] Initialising logging.[4] Starting phase LOGGING.[4] Audit log: Ignoring a non-relevant request.

Transaction Example

Again, assuming that none of the rules blocked, the accumulated responsebody will be forwarded to the client:

[4] Output filter: Output forwarding complete.

1. http://waf-fle.org/2. https://splunkbase.splunk.com/app/880/3. https://www.owasp.org/index.php/Category:OWASP_WeBekci_Project4. http://www.root25.com/2013/02/mod-security-log-auditor-application-in-PHP-free-analyse-

draw-chart-from-modsecurity-log.html5. https://www.netsparker.com/blog/docs-and-faqs/generate-modsecurity-web-application-

firewall-rules/

Otherprojects

AQTRONIXWebKnight isanapplicationfirewallforIISandotherwebserversandisreleasedundertheGNUGeneralPublicLicense.

MoreparticularlyitisanISAPIfilterthatsecuresyourwebserverbyblockingcertainrequests.

IfanalertistriggeredWebKnight willtakeoverandprotectthewebserver.

Itdoesthisbyscanningallrequestsandprocessingthembasedonfilterrules,setbytheadministrator.

Theserulesarenotbasedonadatabaseofattacksignaturesthatrequireregularupdates.InsteadWebKnightusessecurityfiltersasbufferoverflow,SQLinjection,directorytraversal,characterencodingandotherattacks.

ThiswayWebKnight canprotectyourserveragainstallknownandunknownattacks.

BecauseWebKnight isanISAPIfilterithastheadvantageofworkingcloselywiththewebserver,thiswayitcandomorethanotherfirewallsandintrusiondetectionsystems,likescanningencryptedtraffic.

Questions?DEMOS