OpenBSD Journal

OpenBSD-based web application firewall

Contributed by jolan on from the openbsd-under-the-hood dept.

Srebrenko Sehic writes:

Just wanted to let you guys know that Armorlogic is using OpenBSD as the core of it's new web application firewall product called Profense. When choosing an operating system to base Profense on, we didn't even have to think about others. OpenBSD gives us complete freedom to re-use the code as we like, unparalled stability, security, robustness, and a clean code base.

If you are interested, check out our website at www.armorlogic.com for more information about Profense. You can also download a free evaluation version.

(Comments are closed)


Comments
  1. By submicron (67.67.139.29) on

    That's great and all, another product that is based on OpenBSD. But the website is supsiciously lacking in meat. There's no real explanation of what this product does to actually protect against yet-undisclosed web application vulnerabilities, or for that matter what makes this product different from about half a dozen products on the market. I'll think its a bigger deal when there's actual content on the site.

    Comments
    1. By Anonymous Coward (82.236.141.3) on

      If I understand correctly, it basically filters HTTP requests (as a packet filter would do for... well, packets!)

      There are doing a good job to promote OpenBSD :

      "Profense is based on a stripped and hardened OpenBSD platform. OpenBSD is regarded as the most secure OS generally available. The web proxy, filtering and administration components run in a non-privileged and closed run-time environment. Technologies like ProPolice, W^X protection, non-executable stack, etc. are used to further harden the system against attacks. With Profense you get a seriously hardened and secured frontend to your web applications - without compromising functionality."

      And their system uses CARP for high availability, too :)

      Comments
      1. By Anonymous Coward (69.197.95.218) on

        Considering how little these proxies do to protect webservers, I'd much rather see people using openbsd for their webservers, and learning how to code instead of sticking some questionable openbsd-based proxy in front of their webservers. The site claims to magically secure your incorrectly written exploitable web apps without having to re-write them. This is both very unlikely, and a stupid way to solve the problem anyways.

        Comments
        1. By Anonymous Coward (68.161.196.197) on

          Putting your comment aside, their website claims to be pretty much a panacae against everything that could possible go wrong with a web application or server. The subject is right on the mark here: where is the actual information? They say that they can protect against 'zero day exploits', and give an explanation of what said exploit is, but not how they plan to secure you against the unknown. This seems more like a PHB product. Has anyone downloaded and tested this software?

          Comments
          1. By Anonymous Coward (68.161.196.197) on

            Well, forget that. Since I can't even _use_ their web application, it seems that it might be hard to get an eval copy... Or maybe their profense settings are too high? Each time I attempt to 'register', it pukes on my email and phone, saying both are 'invalid'. I guess no one should try to ring me at home, being that my phone number is 'invalid'.... [sigh]

    2. By Srebrenko Sehic (195.24.1.195) on

      Just to clarify some of the questions raised here, since some people obviously don't bother to read the information on the website.

      Profense is based on "positive security", pretty much like any well configured firewall. You start with a "deny all" and explicitly allow traffic into your network based on what you want to grant access to.

      Profense can do the same for web applications (HTTP and HTTPS based). You basically define access policy for your web application. Eg. you define which pages (URLs) are valid, if they take any parameters, which values those parameters can have, which HTTP method you can access those via (GET, POST, etc.). When a user (or a potential attacker) requests something on your website, it's checked againt the defined access policy. If the request dosen't match the ACL, it's denied and logged.

      Profense will automatically generate an ACL based on the outgoing traffic from the website it's protecting. Unless your have a bunch of fancy javascript, you'll have to do minimal manual ACL adjustments.

      Profense is not a "security gizmo". It's a positive HTTP/HTTPS filtering reverse proxy, with some extra features like caching, TCP connection offloading, compression and SSL acceleration.

      Regarding questions about "zero-day" attacks. Let's imagine a new PHPBB worm that exploits a unknown SQL injection vulrenability in some PHP script. If you played your cards right (eg. defined an ACL that only allows characters a-Z and numbers 0-9 for a vulrenable parameter), the attacks will be stopped before if even reaches your vulrenable PHPBB application. And yes, Profense will provide "sane defaults" for all your paremeters, pages, so unless you specifically shoot your self in the foot, you'll be safe.

      Or, say you have a default IIS installation and you forgot to remove the vulernable default scripts. Unless you explicitly add those to the ACL, an attacker will simply receive a "403 access forbidden" trying to request them.

      Or, if your web developers forgot to remove "debug.asp" or "index.php.bak" from the website before putting it into the production.

      I could provide a bunch of other examples, but you get the idea.

      And I agree that fixing your vulrneable web applications if the *correct* approach, but remember that poeple don't always known how, don't care, don't have the ressources or have access to the source. They are left in the blind.

      Finally, Profense will protect your custom web applications as well, so forget about your favourite IDS/IPS system. It knows nothing wheter "yourscript.php?login=admin&passwd=test' OR '1=1" is valid or not.


      Comments
      1. By m0rph (68.104.17.51) on

        what about SOAP/XML-RPC/JSON-RPC?

        Comments
        1. By Srebrenko Sehic (195.24.1.195) on

          Support for webservices is currently not implemented, but is planned for a later release.

      2. By Anonymous Coward (217.162.139.33) on

        all fine and dandy, but at the price you're offering it at, a company might just as well hire a seasoned coder to check their web app in the first place. add the cost of hardware to run it, service contracts, hw failure etc. and you have a very hefty piece of "plug&play software".

        so an easy low-cost solution it is not, but make a nice brochure and I'm sure you'll sell some ...

        good luck anyway.

        Comments
        1. By Anonymous Coward (82.236.141.3) on

          You mean, a *really* seasoned coder or some expensive 'infosec' consultant who will barely run an automated, dummy tool like Nessus and say "everything is fine" ?

          The solution they offer is a workaround. I do agree, and they do recognize this fact too. So what? Packet filters are workarounds, a non-executable stack is a workaround, ProPolice is a workaround, privilege separation is a workaround and so on.

          Unfortunately, we do not live in a world where programs are bug-free and are to be totally trusted, even when written by experts who sometimes are tired/lazy/etc. and do make errors. So we have to use workarounds to mitigate the consequences of bugs.

          Comments
          1. By Anonymous Coward (68.161.196.197) on

            I would tend to disaggree. A work around has the conotation, at least for me, of being held together by 'duct tape'. If your logic was extended out, then basically everything is a 'workaround'. Hell, passwords and ACLs are workarounds, because if we could simply trust everyone, there would be no need to implement them! In all honesty, it would be best if everyone would write secure code to the best of their ability, but this would never happen. tcpwrappers is a workaround, this at least a workable solution.

          2. By Anonymous Coward (217.162.139.33) on

            I meant what I wrote. The place to secure a web app is the design phase, not band-aid solutions when it's already implemented.

            Checking user input is not something to be done on a proxy that can get taken out of the loop when something goes wrong: "Oh, yeah btw, we unplugged the firewall 'cos there was some problem..."

            Granted, that is not always possible, but that is a project management/human resources issue, not information security.

      3. By Anonymous Coward (147.249.60.21) on


        that is the most interesting spellings of "vulnerable" that i've ever seen in one post.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]