SRX http test cookie

Does SRX 3600 has capability of testing HTTP cookie for botnet attacks ?
FireBallITAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

dpk_walCommented:
AFAIK SRX supports SYN cookie and there is no inbuilt HTTP cookie protection:
http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/denial-of-service-network-syn-cookie-protection-understanding.html

HTTP cookie can be inspected using custom IPS/application signatures while the data is being sent form server to client at the network level.

Thank you.
0
btanExec ConsultantCommented:
Indeed SRX series can do the DoS/DDoS and SYN cookie checks - do see the table stated on the capabilities as a whole http://www.juniper.net/us/en/local/pdf/datasheets/1000267-en.pdf
Specific to HTTP cookie inspection, I will say it is more of enforcement of HTTP inspection as a whole. Like this to enforce a HTTP policy to setup and put into active state.
4.Next step is to configure the IDP policy in the edit mode. Run the below commands to setup the IDP policy in configuration edit mode.

[edit] >set security idp idp-policy HTTP-INSPECTION rulebase-ips rule 1 match attacks predefined-attack-groups "HTTP"        
      (policy name: HTTP-INSPECTION, inspecting all HTTP signatures for any SRC and any DST)
[edit]>set security idp idp-policy HTTP-INSPECTION rulebase-ips rule 1 then action recommended              
      (This command defines the action as recommended for any attack detected)
[edit]>set security idp idp-policy HTTP-INSPECTION rulebase-ips rule 1 then notification        
      (This command defines notification to be sent out in case an attack is detected)

5.Now the newly defined IDP policy needs to be setup as the active IDP policy.  Run the following command:

[edit]>set security idp active-policy HTTP-INSPECTION
http://kb.juniper.net/InfoCenter/index?page=content&id=KB15806

Detection for bot is likely to hit the signature and blacklist for the SRX's IDP control as well as other virus scanning in this UTM/IDS gateway. We should also look into the SSL inspection which SRX can support as well, otherwise it is blinded for all SSL traffic
Combined with the Application Identification feature, the SSL Inspection feature enables SRX-series devices to inspect HTTP traffic that is encrypted in SSL on any TCP/UDP port. By default, SSL inspection is disabled and can be enabled by using the configuration CLI.
but note that it can be performance crunching on the box if all security services are enabled so do test it out first https://kb.juniper.net/InfoCenter/index?page=content&id=KB24803
0
FireBallITAuthor Commented:
Actually we want to block get attacks
%99 of the get attacks is not accepting cookies / does not go to second page and wait for a while
we should not put an rate for frequency because most of the atackers has too much bots so a request does not come for second time before a real visitors second request
0
KuppingerCole Reviews AlgoSec in Executive Report

Leading analyst firm, KuppingerCole reviews AlgoSec's Security Policy Management Solution, and the security challenges faced by companies today in their Executive View report.

btanExec ConsultantCommented:
if they hit the signature as malicious payload in the request/post for http policy, it will be dropped. But of course if you need to there is even custom IDP signature you can craft to enforce it. See this example to even block URLs having  a GET for *.exe in path and sends a RST back to the client. http://rtoodtoo.net/how-to-write-srx-idp-custom-attacksignature/
Will be best to engage Juniper support for consultancy for blocking such cases effectively as I do agree also rate limiting is not solving the issue if clearing it is deem malicious or suspicious..Ideally a CAPTCHA is at the web resource to deter at web app/resource as well, but that is also not a long term soln but a deterrence to attacker traffic such as bot..
0
FireBallITAuthor Commented:
yes it is a good explanation i know it but it does not work real time . There is no effectively impact on attack with this way.

User can add an same signature rule on their server easily.
We need an automated detection system.  or a way to block botnet get  / head   / post attacks
0
btanExec ConsultantCommented:
No really good means if we stick with SRX. It is still and just a UTM/IPS, not a true Web Appl Firewall (WAF) like F5 ASM, Citrix Netscalar or mod_security equivalent that really go deep into inspecting HTTP header. The deep inspection and being appl aware esp in web of this blocking can be checking for the cookies and referrer etc to trigger the block before reaching backend. Otherwise, it is reactive based on known attack signature or custom signature per se.

So far SRX knowledgebase did not show any hint that it can drill to such depth - of course I may be wrong. Below are the IDP Application-Level fields and supported level of depth ... for custom approach.
http://www.juniper.net/documentation/en_US/junos12.1/topics/concept/idp-custom-attack-object-understanding.html
http://www.juniper.net/documentation/en_US/junos12.1/topics/concept/idp-application-level-ddos-protection-overview.html

WAF can handle slow attacks (Slowloris, RUDY) which is what you need, besides the mentioned on premises provider, they can have VM and be hosted via AWS. But rather than the hassle, another option (though may be costly) you can explore subscribing to services such incapsula, cloudflare or akamai which have WAF capability too. The layering of defense helps alot even before it hit backend. It gives more assurance esp to critical online services.
Web Application Protection solution relies on a unique client classification engine that analyzes and classifies all incoming site traffic. This anti-DDoS solution is specifically designed to transparently identify malicious bot traffic—stopping all HTTP floods and other Application Layer (OSI Layer 7) DDoS attacks.
https://www.incapsula.com/ddos/ddos-attacks/botnet-ddos.html
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
FireBallITAuthor Commented:
thanks for the point of waf
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.