Sorry for that. We're not native speakers. The thing is that "n-jinks" is how Russian NGINX team pronounce it. X is pronounced as iks, not ex, in Russian.
2/10 troll, try harder.
Watching our PM get to their name in a story and pause for a few seconds and just say "that word" instead should give you some idea of how counter-intuitive it is.
You don't have to work hard to parse good branding.
As I like to say, "Give someone a ghoti, he can speak English for a day, tell them how to ghoti, and they can speak English for a lifetime".
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.
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.
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
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.
Showcasing something that started being exploited more than a decade back and has pretty well known defenses doesn't inspire much confidence.
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.
Is that because of the licensing terms of a certain underlying component that you use which forces you to share it?
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.
And it is already one of the approaches Wallarm uses to detect malicious requests.
Some feedback (edited to add stuff twice):
- The pricing is confusing. The front page shows me how to install it and run but then another page mentions a free trial? Is that's what I'm doing when I install via apt-get or run via docker?
- What's Wallarm Cloud? It appears to me Wallarm is an nginx module that "protects" stuff, somehow, and for some (maybe all) things it sends them to the Wallarm cloud for analysis. What is the Wallarm Cloud and how does that protect all of my data that it's receiving? What if it's receiving HIPPA data? Is it stored / cached and if so for how long?
- When attempting to register I think it's best to provide a verify option for the password.
- When attempting to register I keep getting errors stating my password is too simple. Even after 50 characters. I assume this is doing a check for symbols or something but allowing any character and then me putting in 50 characters I think it's safe to say it's no longer "too simple"
- You're using CORS but it's a subdomain; you don't need to do anything with CORS at all unless you really want to (but who wants to preflight every single request if you don't have to?). Just set the document.domain to the same domain and you're done.
- I think you can make your registration services flow a little better. Since it makes a request to get a token from the backend and it provides nothing with the request (minus the session id cookie) then that means you're managing session state on the backend so why are you also managing state on the front end? I get the idea behind the token but you have a token and a session id and you're using token more like a session id as it doesn't appear to change when I make calls to it.
- Why do I have a "permissions":["admin"] in my profile? :)
- Clicking on "Profile" takes me to a profile page, it downloads all of the resources and makes REST calls, and then it redirects back to active. Why not do this server-side so it's immediate and less bandwidth intensive? Alternatively if I haven't activated and I entered the wrong email address or other information now I can't update it at all. I have to create a new account. I'd suggest letting profile information be updated.
- Seems too black-box-y to me. I'd like to see something more to the point. Then again I'm an engineer but typically for products like this I've found you need at least some engineer buy-in to sell it to a company.
if (c.get().length < 8) C.isValid = !1, c.hasErrors = !0, c.errors = [{
message: "Password too short"
}];
else if (c.get().length > 256) C.isValid = !1, c.hasErrors = !0, c.errors = [{
message: "Password too long"
}];
else if (/^[a-zA-Z0-9`~!@#\$%^&*()_=+\[\]{};:'",.<>\/? -]*$/.test(c.get())) {
var e = 0;
/[a-z]/.test(c.get()) && (e += 1), /[A-Z]/.test(c.get()) && (e += 1), /[0-9]/.test(c.get()) && (e += 1), /[`~!@#\$%^&*()_=+\[\]{};:'",.<>\/? -]/.test(c.get()) && (e += 2), 3 > e ? (C.isValid = !1, c.hasErrors = !0, c.errors = [{
message: "Password too simple"
}]) : (c.hasErrors = !1, c.errors.length = 0)
} else C.isValid = !1, c.hasErrors = !0, c.errors = [{
message: "Invalid symbols in password"
}]
# What's Wallarm Cloud?
A very good question! We can't run machine-learning stuff on the Nodes as it is performance consuming thing. But we can get all the metrics from all the node (some of our customers have 300+ of them) and craft blocking rules in our cloud. We don't get data; we analyze only statistics. So, we don't have sensitive data. Also, it's possible to deploy a standalone version of Wallarm Cloud.
Here's how it works: 1. All web traffic is proxied through Wallarm Nodes which instantly block any malicious/abnormal request preventing it reaching the application. 2. To get rid of false positives and for better protection, Wallarm Nodes like New Relic agents share application metrics in exchange for an updated blocking ruleset. Wallarm Cloud crafts application profile, its structure, normal user behaviour—and updates corresponding blocking rules every 15 minutes using machine learning. Updated blocking rules are distributed among all the Wallarm Nodes. 3. A built-in vulnerability scanner discovers security flaws in an application and checks the actual severity of each payload detected in attacks (is it targeting existing vulnerability?) allowing to prioritize company defensive efforts.
The only case when we're receiving the data from the request when we detect a malicious request. We need this request to show analytics in the user interface and get a payload to check if it's targeting vulnerability. To avoid situations when we get sensitive data with attacks details, it's possible to configure Wallarm Node to cut all the data from sensitive fields (cookies, password, SSNs, etc.). We have companies with HIPAA certificates.
Almost the whole team is almost paranoid about the passwords. But I totally agree that requirement for the password are not clear now. Will make it work smoother.
Could you elaborate on this. What details do we need to add the website to make it less blackboxy? BTW, did you have a look at docs.wallarm.com?
Congratulations! :) You're admin of your company. You can add another admin who can deploy nodes or can add analyst guys who can only view data on attacks and vulnerabilities you have.
Does it seem weird that you have Admin status?
"Detect anomalies and block attacks with no latency" seems hard to believe - minimal latency, maybe, but none?
On the other hand, good luck to Wallarm - there need to be better WAFs out there.
But mod_security provide a very basic approach based on signatures (regular expressions) which: - very hard to maintain and tune, especially if you have applications with a lot of updates (if you don't tune you'll get false-positives); - they don't cover all the attacks; - it not that fast because you need to match each request to the signature database (it's possible to make fast though as CloudFlare did with LuaJIT and OpenResty).
There are no learning capabilities in mod_security, so you need to dedicate engineers time to tune it. There is a lack of analytics. It will detect thousands and millions of malicious request but never says which of them are targeting real vulnerabilities in your apps.
Anyway, mod_security is just another product. It's plain WAF, with a great community and good CRS (signature ruleset).
If you need more than four nodes, the price is more than flexible. Also, we always try to understand better customer infrastructure and, case by case, give node free of charge at all—to cover all the customer's network perimeter. Don't want them to sacrifice part of the infrastructure because of stupid license/price limitations.
In fact, Wallarm Node is much less black-box than most of the commercial security products (with their own operation system you don't have access to, updates no one knows what inside is, etc.). It is predictable in configuration (just new directives in nginx.conf). Scripts, which come with the Wallarm Node, are free to review. In-memory storage (used for fast local analytics) is accessible. You can watch what the data is exchanged between Wallarm Nodes and Wallarm Cloud. And you use operation system you know.
With our customers, it's OK for us to share source codes.
But naxsi and wallarm are too different products; they still have something in common though (using of nginx e.g.)
But I agree they could be executed better, as right now they look low-rent more so than artistic.
Which is an all in one very powerful solution... With near wire speed transfer.
I don't know why I should get that?
I am pretty sure that it's a kind of good option for some enterprises. But most of our customer has high volume applications deployed in several datacenters, with CI/CD and DevOps approaches used. For them, hardware security boxes are almost impossible to use. What they are looking for is DevOps friendly tools that scale and orchestrated well with their application. That is why we're partners with NGINX to provide all the flexibility of our filter nodes.
Moreover, IBM thing will not help you to figure out security flaws in your apps and network perimeter. It will not provide you with details which of millions of malicious request you really need to care about as they are targeting existing security flaws.
I would like to get your feedback about this IBM product. Do you use for some time? It's not that popular among security community (at least, that part we usually talk with). If you give you access to test it, we'll show you some bypasses — unfortunately, there are dozens of them for almost all old-fashioned security solutions like this.
About your points:
Devops is possible. You got like three interfaces you could utilize. Json, soap and something called afp, if you count shh, that's also possible to automate with. You can load balance it, fail over, active, active, passive active, self load balance etc. There is also a Citrix, vmware and docker version. You can load balance incoming and outgoing traffic. I don't know what else you want?
You get near wire speed format, signing, authing etc stuff on the datapower. You can also add a hardware cryptography card for even more speed.
Datapower won't protect you from passwords like admin, admin. This needs and should be done on application level. But if you feel frisky you can implement a rule check on your own. In JavaScript if you like.
Where datapower shines is with three a and validation with a check against known attack vectors.
Let's say you want to prevent overloading your api with nonsense. Including none valid string formats ie they shouldn't be longer than 69 signs. And the while json request shouldn't be bigger than 2kb. You can do side calling. Ie checking external databases for validity. Throttle and or stop requests.
The datapower is extreme powerful. In terms of flexibility, speed and security.
There is a reason why one of our customers has 60 of them.
Granted this came off a little spammy, in my opinion, because it was submitted and then no founders or employees showed up until a couple of hours later which makes it okay to me but if they wouldn't have shown up I don't think it would be appropriate.
hkr_mag or others, what differentiates Wallarm?
There is still lack of technical details on Signal Sciences website. And no public demo. Hey, guys, give us a try :)
- Integration is amazingly easy if you use nginx... basically an apt-get.
- Unlike most security packages that just block certain ports or apply predefined rules, Wallarm feels like I have a dev-ops team looking at traffic patterns 24/7. They're always learning and they identify when things seem irregular.
This is definitely the next level of network security
> Integration is amazingly easy if you use nginx... basically an apt-get.
What about the Wallarm Cloud?
> Unlike most security packages that just block certain ports or apply predefined rules, Wallarm feels like I have a dev-ops team looking at traffic patterns 24/7. They're always learning and they identify when things seem irregular.
What exactly does this mean? Are you implying that Wallarm uses machine learning and what criteria / data would it use in such a case? Alternatively is this referencing the Wallarm Cloud?
Typically infrastructure pieces are very, very well defined in what they do as they're critical (if it's too slow or not working correctly then you're business goes too slow or stops). If you have specifics of any of your claims it would be great to read.
We started as a team of white hat hackers. Ivan (CEO) is a respected researcher known for his articles and talks at international security conferences (BlackHat, Hack In the Box, etc) on web application security.
Everything started with boutique security consulting company founded by Ivan in 2009 which with time became a synonym for the "best security audits for web applications". After each security audit had carried out we got a simple question "Good job, guys, but what's next now? We've fixed all the vulnerabilities you found. The only problem that we deploy code five times a week — and each (!) update might have new security flaws. We could be hacked again anytime!"
So "What's next?" We didn't know and were looking for the answer evaluating different products pretending to secure modern web — with orchestration by DevOps teams, continuous integration (CI) with frequent code updates right on production systems, complex Single-Page Applications and REST APIs, etc. And we failed. Every solution was broken for the same reasons.
1. They are not ready for continuous integration. Frequent code updates results in false positives when legitimate users got banned. The only way to avoid this is manual/semi-manual reconfiguration after each code release.
2. They don't scale well and are not ready for orchestration by popular DevOps tools (making themselves enemies for DevOps teams).
3. They overwhelm users with senseless notifications about thousands of attacks (that obviously has every website!) — without saying which of them are in fact dangerous and targeting security flaws of protected application.
4. Finally, none of them help to find vulnerabilities which are the real reason of data breaches.
So we ran different experiments by ourselves and step by step came to the idea of the product that we wanted to see on the market and recommend to our customers. We started working on it, released first MVP and instantly got positive feedback from all those security teams.
Same features but open source [0]
[0] https://github.com/alexazhou/VeryNginx
Demo dashboard: http://alexazhou.xyz/vn/index.html#
User: verynginx
Password: verynginx
But hey, I guess that solves all the complaints about secret black boxes.