Hacker News new | past | comments | ask | show | jobs | submit login

TLDR: proxy your traffic through a locally installed secret blackbox, after which it is "100% protected".

Not found on the website: non-buzzwordy description of how this really works and what makes it better than the other gazillion security products. Show me an example of an attack you stopped. I realize the website isn't selling to engineers, but still.




Just a few examples of the attacks that other security products can't catch.

1. A very complicated things going through XML/JSON APIs. Wallarm really parse XML, understand the structure and catch even complicated exploitation attempt like this:

<?xml version="1.0" encoding="UTF-8"?> <!ENTITY a "UNION"> <!ENTITY b "SELECT"> <!ENTITY c "passwd"> <!ENTITY d "FROM"> <!ENTITY e "admins"> <!ENTITY f "WHERE"> <authorid>-1 &a; &b; &c; &d; &e; &f; id=1</authorid>

2. Every vector that exploits vulnerabilities over WebSockets. Some product doesn't support WebSocket at all. Some just proxy data without analysis of it. Wallarm detects malicious behaviour in WebSocket messages.

3. All the attacks with massive evasion techniques. We run thousands of tests to check if attacker can bypass attacks engine. Soon, we'll publish bug-bounty program and we'll pay money for those who will find by-passes.


4. Another great example is detecting exploitation of Java Unserialize vulnerabilities (https://foxglovesecurity.com/2015/11/06/what-do-weblogic-web...).

WebSphere takes payload in Base64 inside the XML. To parse everything (and do it fast), unfold the structure and detect the attacks is still almost impossible thing for most of the WAFs


A security company citing another security company blog to describe a vulnerability.

I <3 it!

--

BTW, in order to use Wallarm one needs to pay upwards of $1000 pm. In order to pacify themselves that it works, one either need to write poor code that exhibits XEE or pay further to use WebSphere. Nice.


Pity you get it in this way. Exploit for WebSphere is just an example of a complicated case with Base64 inside XML where Wallarm can detect malicious request other WAF usually fails.

And, no one asked to pay anything until getting proper results while 30 days free pilot (it could be extended). Give it a try


Just easiest way to test your WAF right here and right now is:

hXXp://defended-site/?test={%22attack%22:%22\u004a3Vu\u0061W\u0039uIHNlbGVjdCBwYXNzd2\u0039yZCBmcm\u0039tIHVzZXJzIGxpbWl0IDEtLWEt%22}

Let's explain payload processing in details: 1. URL-decode {"attack":"\u004a3Vu\u0061W\u0039uIHNlbGVjdCBwYXNzd2\u0039yZCBmcm\u0039tIHVzZXJzIGxpbWl0IDEtLWEt"}

2. JSON unicode chars decode: J3VuaW9uIHNlbGVjdCBwYXNzd29yZCBmcm9tIHVzZXJzIGxpbWl0IDEtLWEt

3. BASE64 decode: 'union select password from users limit 1--a-

Wallarm can process this w/o any manual tuning out of the box.


Thought that you might have other than XEE to showcase.

Showcasing something that started being exploited more than a decade back and has pretty well known defenses doesn't inspire much confidence.


Aren't you claiming that you don't need to terminate SSL?


No magic here :) Sure, we need to terminate SSL. Either before traffic is going to Wallarm proxy node, either by Wallarm Node itself.


Yeah! We would say the same if someone propose us to use this :)

1. We share the source code of Wallarm Node (nginx-based filter instance) with the companies after signing NDA. 2. Will run 3rd party audit of the code and share the report. 3. At some point, we'll open-source it.

Ivan (wlrm) will come up with the examples of attacks soon.


> We share the source code of Wallarm Node (nginx-based filter instance) with the companies after signing NDA.

Is that because of the licensing terms of a certain underlying component that you use which forces you to share it?


It's because all the security guys (as we're) troll a lot and always skeptical (reasonably!) about blackboxes


> It's because all the security guys (as we're) troll a lot and always skeptical (reasonably!) about blackboxes

Why not open-source it then? In that event tt wouldn't be termed a blackbox either.


What do you mean "come up"? You made a commercial product and don't have a single use case or user story to pitch?


Why the negativity? I can think of a number of tech questions that no one but the deepest in the technical weeds on a team could provide actual answers to. Is deferring to someone else on a team to answer questions so bad?


There is quite a difference between technical questions and "what your product does, couple of examples where it's good at maybe?".


Lot's of stories happening right away. Don't get the reason for the negativity. Though here is a recent story — critical XXE with remote file reading at LinkedIn (http://blog.wallarm.com/post/145883562288/critical-linkedin-...)


This blog post has nothing to do with your product. Also, stopping a single request is very different from stopping an attack. A real attacker isn't going to stop the first time they get blocked, and if possible they'll probably end up evading your WAF.


It absolutely has. The vulnerability was detected with a vulnerability scanner built in Wallarm. As for detection of attacks, in many cases, it's much easier to identify the attacker when he runs several requests than to stop only one request with a ready-to-use 0day exploit. And what's even more important, you need help to fix vulnerability unless attacker discovers it and find the way to evade WAF


# Why it's different

1. Vulnerability and data breach detection.

Regular WAF just detects attacks. Thousands of attacks. And what to do with this knowledge? In a case of a traditional security solution, it's never clear — if an attack is just scanning with no harm or someone already downloading database over SQL injection vulnerability. You need to analyze all your events manually

Wallarm does more. It discovers which of the attacks are in fact targeting vulnerabilities.

This became possible because of combination defensive and offensive techniques (NGWAF + vulnerability scanner in one core).

2. Attacks/anomalies detection driven by machine learning

It's all about statistics and understanding the structure of the application and its users' behavior. Wallarm Nodes send a lot of statistical (impersonate) data to Wallarm Cloud, so we can get a set of facts about application: - here is the SOAP API; - here is XML API; - here are JPG uploads are allowed - here is field of the form, with CC number (16 bytes, digits only)

There are general ruleset to detect attacks without learning at all. But when we have an understanding of inner knowledge of the application, we can apply this set of facts of application to the general ruleset and get dynamic ruleset for every application. Wallarm Nodes get dynamic ruleset every 15 minutes from the Wallarm cloud.

As a result, it makes possible to protect APIs and apps with frequent code deployments and not to worry about false positives (we saw this many time: in the case of traditional solutions security team is usually required to reconfigure rules after major application updates manually or semi-manually. Hours of useless work. An enormous obstacle for CI/CD. And here what we see all the time: no one wants to get this work done, so security solution works just in monitoring mode WITHOUT actual blocking of attacks).

3. Performance and scalability for DevOps

Signature-less filters are very fast (we have Badoo social network/dating site with 200+ million users running their performance test for their PHP-stack application and they don't see performance degradation). Everybody already knows how to deploy/monitor NGINX with favorite orchestration tools. Wallarm is just a module for NGINX. Now, with the support of dynamic module by NGINX you can even use your existing NGINX instances.

I argue that it is a complete black-box for the customer. What blackbox is full proprietary hardware boxes or virtual appliances with operation system inside from old-fashioned vendors like F5 (no offense) or iMperva (again, no offense). Or entirely cloud solutions which take all your traffic. In a case of Wallarm, you work with your Linux environment; you can see all the Wallarm scripts and content of an in-memory database. And we share the source codes of Wallarm Node with our customers. Yes, have not yet published them in open-source, though.


What we have already published to open-source is libdetection (https://github.com/wallarm/libdetection), a library implementing a completely new way to detect attacks. This approach allows us to implement attack detection without having to specify precedents of attacks. I mean it doesn't require attacks samples to learn at all. Instead, formal models are used.

And it is already one of the approaches Wallarm uses to detect malicious requests.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: