Link to home
Start Free TrialLog in
Avatar of sunhux
sunhux

asked on

Tools / ways to test a WAF

I need tools / ways to test our new WAF (to be set up in UAT VLAN) for
a) Brute Force : what's the commands/syntax if I use Jack the Ripper or any other suggested tool?
b) DDoS volumetric & application
c) OWASP top 10 (eg: XSS, SQL injection, CSRF, Cross-Frame-Site-Forgery/Clickjacking, insecure file upload)
d) Rate-Limiting : can I use the command line browser  'wget' to load a page many times to simulate?
e) any other aspects to test?
f) virtual patching (eg: if a patch is not applied & the WAF has a rule/signature for Wordpress/PHP)

I don't have access to Kale Linux (but possibly an RHEL VM in UAT) to run Metasploit: hopefully there's
a Metasploit for RHEL (but do suggest how to use it to test)
ASKER CERTIFIED SOLUTION
Avatar of David Favor
David Favor
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux
sunhux

ASKER

If WAF is behind loadbalancers, should we test failovers of both WAF & LB to verify sessions persistence (ie sessions doesn't get disconnected) ?  Is this a valid test?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux

ASKER

>  to also identify the source and block it or sinkhole it or have a tarpit to slow down the attack.
Yes, I indicated this as one of the requirement (source IP of DOS in the WAF logs/dashboard)
 for the test;  does most WAF offer this sinkhole/tarpit feature?  Thought it will be just a policy
 or rule in the WAF to block the DOS/DDOS.

Thanks for pointing out WAF has to be in front of LB
Avatar of sunhux

ASKER

Should we conduct one round of tests with the WAF policies/rules in Detect mode
& then one round in Block mode (to see the differences in logging??) or just do all
the tests for Block mode?
Avatar of sunhux

ASKER

There has been cases of service disruption after migrating web apps behind the WAF, so
I thought we ought to test out the 'Detect' mode in the event 'Block' causes disruption :
at least we can see the source IP of the attacker & block at firewall
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux

ASKER

to test the Waf's  bad reputation IP, is there a tool that simulate the test IP is coming from one of bad reputation?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux

ASKER

Thanks, think  nmap has a  "-s" option to make the source IP in the packets that it send
Source IP spoofing can be tested but just that if done in public network there may be possibility that it get blocked, the other round is going through proxy and have the source as X-Forwarded-For. Supposedly the WAF would be able to check too.
Avatar of sunhux

ASKER

Lastly to test XSS & CSRF (Cross-Site Forgery), is a web server running behind the WAF sufficient
or need to build an actual application server.  I can only readily build an IIS but if an app server
is needed for this test, what will be the easiest app server to build?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux

ASKER

Colleague maintained that an IIS server suffice to test the WAF for XSS, CSRF :
 WAF needs just a basic IIS to “sense” that the backend server is alive before it can proxy traffic to it.
Else WAF will simply serve the maintenance page and declare service not available.

Is the above statement correct?
It is possible if you do simple reflective XSS no need any stored XSS as I shared in earlier post. You are just testing the WAF to inspect the http header against any signature on XSS strings.

For CSRF, it is also possible but I am doubtful if you do a simple login no need any session tracking. Suppose, for simplicity's sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If victim has already authenticated himself, submitting another request causes the login to replayed the session Id or cookie. If that is doable with only the so call backend server with no web app then ask them to setup and try.

I would see a session cookie to be automatically sent with it.  For example, if the user clicks on the link, since it was already authenticated by the web application on site, the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application and probably not what the user expects to happen.