EXCLUSIVE !! Qualys new Open Source WAF Project Codename “IronBee” v0.1.0
IronBee is a new open source project to build a universal web application security sensor.
Qualys is announcing the development of IronBee, a new open source project to build a universal web application security sensor. Our desire is not only to build the code and the rules, but also to focus on building a community around the project. In fact, we believe that building the community is the most important aspect of the project and the only way to ensure that it has a long life.
IronBee has been in development for several months now. We have completed the initial design phase and the prototype implementation, and we have the development and collaboration infrastructure ready. Now that we have a meaningful starting point, we are inviting others to join us.
At this time, we are looking for early adopters and those who wish to participate in shaping the project:
- Developers to work on the IronBee core and on the security modules
- Application defenders to tell us what they need and to provide feedback on our proposed solutions (e.g., configuration language, signature language)
- Application security researchers to exchange attack information, write signatures and rules, and design new detection and protection techniques
- Web server and proxy developers to help us make IronBee work in their environments
- Distribution maintainers to package IronBee to run on their systems
- Infrastructure and cloud providers to help make IronBee effective for embedding into their infrastructures.
Features
IronBee consists of three layers:
- Platform (or framework) for application security processing and logging
- Application security-specific modules
- Rules
1. Platform
Deployment
Embedded
The IronBee engine is embedded in another process. This may be a webserver, proxy or other software which would hand off the data stream to the engine with support for:
- Observation (passive inspection and intelligence gathering)
- Buffering (both inbound and outbound) and blocking
- Embedded Engine: Apache 2.2+ reference implementation (using a connection-level filter)
- Reverse proxy: Build a default (recommended) implementation, building upon one of the available open source products
- Additional potentially supported platforms: (depends heavily on community involvement)
- Apache httpd on Windows
- Apache Traffic Server
- Microsoft IIS/ISA/Forefront TMG
- nginx
- Squid Perhaps using ICAP/eCAP as support is already there?
Passive
Passively analyze HTTP requests and responses using the following passive data acquisition methods:
- Read raw HTTP log files
- Read PCAP files
- Sniff live traffic
- Proof of concept using libnids
- Issue: Need TCP reassembly library with compatible licence
- Investigate CyaSSL for passive SSL decryption
Out-of-Process Engine:
Ship data to another process (e.g., using domain sockets) or another server (over TCP/IP) for inspection: * Apache 2.2+ reference implementation * Investigate ICAP as a proof of concept implementation
Modularity
Provide a powerful and easy-to-use API for IronBee users and developers to extend functionality via modules.
- Module collaboration framework (interfaces, hooks, callbacks, providers, etc)
- Dynamic modules in C*
- Dynamic modules in C bytecode (via LLVM)
- Dynamic modules in Lua
Configuration
The IronBee project will implement a simple configuration language that aims for the ability to have very granular control over the engine. We hope to accomplish these goals by providing the following:
- File-based configuration language with support for on-the-fly reloads and no impact on the host container
- Core Apache-like configuration language
- Programmatic (scriptable) configuration using Lua
Protocol Parsers
IronBee will parse the following protocols into individual parts and store them into variables for use in the rule language, modules, logging, etc. The protocols we will initially support are the following:
- HTTP:
- Complete active/passive HTTP parser support via LibHTP
- Support for parsing personalities (adjust parsing functionality to match backend implementations)
- Subprotocol parsers:
- Support subprotcol parsing in request/response.
- XML
- JSON
- Add support for other subprotocols such as HTML, JavaScript, etc. as needed, and as time permits.
Inspection Support
IronBee aims to provide powerful and efficient inspection functions by providing the following to users and developers:
- Matching functions:
- PCRE
- Aho-Corasick
- Investigate alternative regular expression engines (TRE, re2)
- Investigate alternative parallel matching algorithms
- Other matching functions as necessary
- Transformation functions:
- Allow users and developers to decode and normalize data as needed.
- Optimized data retrieval and transformation library that avoids duplication of effort in a rule set
- Rule qualification (run only those rules that have a potential to trigger in a transaction)
- Streaming inspection (useful in situations where extensive buffering is not desirable)
- Simple signature language for rule writers: (80% of requirements)
- Very fast Lua implementation for non-signature inspection logic : (19% or requirements)
- Implementation of C modules for non-signature inspection logic: (1% or requirements)
Logging
Ironbee will provide various logging methods and formats. Analysts will be able to configure the method(s) suitable for their environment.
- One-line summary log (e.g, to send to host container, syslog style?)
- Audit logging using an extensible log format that can log entire transactions and parts thereof
- New format using MIME (complete)
- Support ModSecurity format to aide in people migrating to our engine and still use existing management tools
- Remote logging:
- Centralization of audit logs
- Event summaries
- Syslog
Documentation
Having complete, clear and concise documentation is a top priority for this project. We plan on delivering documentation in the following ways:
- User and reference manual: Provided in various formats
- Dev guide
- Doxygen
- Example modules in C and Lua
Miscellaneous
Platform goals that do not fit into any other category are listed below:
- Integration with external access control mechanisms
- Persistent storage: Mechinism to store data outside of normal transactional and connection based scopes.
2. Application Security Modules
The goal of application security modules is to provide functionality beyond what is available in the IronBee rule language, ASM’s can be implemented in Lua or C. Below is the initial list of features we plan on supporting with this type of module:
- Session management
- Session monitoring
- Geolocation
- IP address reputation
- User agent profiling
- Network access control
- Passive vulnerability scanning
- Cookie encryption and signing
- Brute-force attack detection
- DoS and DDoS attack detection
- Application modeling (also known as learning or dynamic policy generation)
3. Rules
In the IronBee spirit of open and shared development, we will be launching a collaborative community hub to foster the sharing of intelligence and the creation of rules for IronBee.
- Establish a community hub (a framework for collaborative information sharing, rule authoring, packaging and distribution)
- Important aspects of rule development:
- Transparency: What does to rule do?
- Traceability: What attacks does a rule address?
- Documentation: Comprehensive end-user documentation
- Validation: Confidence, precision, false positive/false negative rate
- Build community-supported rules that focus on:
- Rules for known vulnerabilities
- Generic application security rules