Curiefense protects your platform against a variety of attacks and threats, including SQL and command injection, cross site scripting (XSS), account takeovers (ATOs), application-layer DDoS, remote file inclusion (RFI), API abuse, and more.
Curiefense inspects every request and analyzes it according to predefined sets of profiles, rules, signatures and patterns. Some of this data is preloaded, some is customized by the user, some is received from external threat feeds, and some is automatically generated and adapted as the threat environment evolves.
Curiefense processes each request according to its policies, and pushes all events (hits) into a PostgreSQL database (in raw log form) and a Prometheus database (as metrics).These metrics and events are continuously analyzed to reshape your security posture as new attacks and hostile sources are detected.
Curiefense integrates with your system as an Envoy Filter. You can use it anywhere you have Envoy running, whether as an ingress gateway, a sidecar or reverse proxy, a load balancer, or other situations. Curiefense attaches directly to Envoy and can start protecting your platform immediately.
Curiefense provides multiple security technologies encapsulated into a single platform, protecting against a wide range of threats. It includes features that many web security solutions do not: content filtering, advanced session protection, JSON payload inspection, human detection and biometric behavioral analysis, and more.
It moves your security from outside your infrastructure to inside, eliminating latency from external routing and processing.
It runs within your perimeter, with no need to compromise your privacy by sharing your data with a third party.
As a cloud native product, Curiefense integrates well with your existing DevOps, cloud infrastructure, and security operations by providing a simple yet comprehensive API along with its UI management console.
Curiefense is managed by REST API, UI console, or both. It lets you choose where to save your data, whether on a local machine or a remote secured server.
Curiefense uses Git as its storage engine for configurations. It contains a set of JSON files which store all rules, policies, signatures, and other details.
Every change made through our API or UI triggers a git commit. This provides a full history of changes, and the ability to roll back/forward, forking, tagging, and deploying different versions of the configuration as you wish.
Because Curiefense uses branches and tags, you can maintain multiple platforms from a single management console (e.g. production, devops, qa, etc,) while controlling how platforms are associated with different configurations.
Whenever Curiefense's configuration is modified, the change is pushed out to one or more cloud storage locations. Each Curiefense instance then pulls its configuration from its designated storage URL and self-updates.
Curiefense uses 3 databases to store data:
-- PostgreSQL
-- Prometheus
-- Redis
PostgreSQL is used to save HTTP requests along with their headers, bodies, session attributes, stats, profiling, and tags.
Prometheus stores dozens of metrics that cover security operations, attacks and blocks, and many other aspects of your traffic.
Redis is used to maintain session controllers and rate-limiting enforcement across distributed clusters.
Curiefense comes with pre-configured containers that spawn all these databases, so they are ready to be used immediately. Or you can replace them with your own, by modifying a single entry in a yaml file.
In addition to the above, Curiefense stores system data (control plane) and configuration files for its various services. These are generated and stored in their containers.
Lastly, cloud storage (e.g. AWS S3 bucket, Google Cloud Storage, Azure Blob Storage) is used to synchronize configuration settings across instances.
Reblaze, along with a number of security enthusiasts and cloud native leaders.
A growing number of companies, including eBay and Cisco.
Curiefense is available as a fully operational system that is:
-- free
-- open source
-- and extensible.
Currently, Curiefense is extending Envoy using its built in Lua binding capabilities. A more extensive roadmap will be published soon.
Curiefense consists of eleven services. (Several can be considered optional, since they're replaceable by existing services already running in your system.) Here's the list:
The main service is curieproxy, which is Envoy built with our additional filters and bootstrap configuration. This is accompanied by a service named curiesync, which keeps the proxy's configuration up to date.
curielogger receives access logs from curieproxy, pushes them to logdb (PostgreSQL) as detailed raw logs, and pushes dozens of composed metrics to prometheus. Access to log data is done via the API provided by curielogserver, which is a REST API interface for everything log related, from access log views to analysis and recommendations.
To synchronize session policies and rules (such as rate limiting) across the entire cluster, redis is deployed as well.
Configuration management is managed by the confserver, a REST API that also acts as the backend for the uiserver.
For convenience, we also deploy grafana for dashboarding and echo for testing.
Logdb, redis, prometheus and grafana are all optional, since you can configure the system to use other services in their place.
https://app.swaggerhub.com/apis/curiefense/curiefense-configuration_api_server_v_1_0/1.0
The Product Manual is available at https://docs.curiefense.io.
The Compose way:
git clone https://github.com/curiefense/curiefense.git
cd curiefense/deploy/compose/
docker-compose up
The Helm way:
helm install curiefense
For detailed installation instructions, see the Product Manual linked to above.
Curiefense's WAF includes both positive and negative security mechanisms.
Curiefense uses a negative security model to block requests which match one or more threat signatures (or some other characteristic defined as undesirable). This is an efficient way to eliminate large amounts of hostile traffic with low overhead.
Positive security mechanisms allow you to further define the characteristics of desirable traffic, and exclude requests which do not match. For example, you can define the maximum number of request headers, cookies and arguments (query string or POST's body), as well as their max length. You can also attach a PCRE Regex to any header, cookie or argument to regulate which characters must, may, or may not appear in them.
WAF policies are combined into sets known as WAF Profiles. Each WAF Profile can be attached to any number of URL Maps.
Curiefense's ACL (Access Control List) is an easy-to-use mechanism that controls whether a certain request or session is allowed, denied (i.e., blocked), or challenged.
Curiefense ACL has 2 operating modes:
While in active mode, action is taken and security policies are enforced. Report mode instructs Curiefense to allow all requests and not enforce security policies; instead, when a request is received that violates a policy, the ACL will only flag the request. This latter mode is useful for debugging, testing, and initial fine tuning to mitigate false positives.
Security policies are defined based on tags:
-- Some tags are assigned to each request automatically (e.g., its ASN and geolocation).
-- Some are assigned according to threat feeds. For example, you can assign a tag of "blacklist" if a request's IP address is currently on the Spamhaus DROP list.
-- Some are assigned according to definitions that you create. For example, you can tag requests from in-house IPs as "internal".
Requests are processed according to their tags. Curiefense ACL provides the following operations:
When a request is processed, each of its tags is processed until a defined action for that tag is found. Then that action is executed.
The earlier the operation in the list, the higher it is in the hierarchy. For instance, suppose you want to allow traffic exclusively from the United States. However, you want to deny traffic from a VPN even if the IP is allocated in the US. You would set:
URLMaps are the mechanism by which you map security policies such as ACL, WAF, and Rate Limiting to services based on the Host header (i.e. FQDN) and paths. Matches are based on Regex.
Curiefense is very flexible, and can be as granular as you wish. Security policies can be assigned to any scope within your platform, from globally down to individual URLs.
Curiefense is an open source project backed by Reblaze. As such, ongoing maintenance is a combined effort of the user community and Reblaze's teams.
Curiefense allows every user to add their own unique signatures. If you create a feed that might be useful to the community, please consider contributing it using our project on github (github.com/curiefense).
Rate Limiting is a powerful mechanism for detecting and blocking attacks which rely on a larger-than-normal number of requests being sent to the target. Common examples include brute-force credential stuffing, payment card validation, and inventory denial.
Curiefense's rate limiting goes beyond simple bi-dimensional counters. Rules can be set to match unique instances of headers, arguments, cookies and other attributes (e.g., geolocation, AS numbers), whether alone or combined.
Curiefense uses an intuitive tag-based system to evaluate incoming requests:
1. Tags are attached to requests and sessions during their initial processing.
2. Then the tags are evaluated (and if appropriate, actions are taken) during later processing mechanisms, including rate limiting, ACL, and metrics.
Session profiling is the first step of this process. Admins can define tags according to a wide variety of criteria:
-- Inherent characteristics (e.g., IP address, CIDR, ASN)
-- Content (e.g., matching headers, cookies, arguments or URLs)
-- External data sources (e.g., blocklists and whitelists)
-- Internal data sources and lists
There is no option for user and or API authentication since Curiefense is designed to run internally, in an environment you are already securing (e.g. behind identity-aware infrastructure).
Curiefense can protect as many endpoints that you need It is "plugged" into Envoy as an HTTP filter, and therefore, supports all services your Envoy Proxy is serving.
You will need to set up Envoy to Proxy your API traffic as step one. That means routing traffic to upstreams as desired and all.
You can use the very same Envoy as a matter of fact. there is no need for additional Envoy whatsoever.
No.
You can...
