# Chat Completions Source: https://docs.onefirewall.com/ai-gateway/api-reference/chat-completions POST /api/v1/chat/completions OpenAI-compatible chat completions endpoint with integrated security, PII masking, and web search. The Chat Completions API allows you to interact with various AI models through a secure gateway. It supports streaming, secret detection, and PII masking. # Available Models Source: https://docs.onefirewall.com/ai-gateway/api-reference/models A list of supported AI models available through the gateway. The Secure AI Gateway provides a unified interface to multiple AI models. Specify the model with the `model` parameter in your API requests. | Model ID | Provider | Description | | :---------------------------- | :-------------- | :------------------------------------------------ | | `openai/gpt-4o-mini` | OpenAI | Fast and cost-effective for simple tasks | | `openai/gpt-4o` | OpenAI | Most capable OpenAI model | | `openai/gpt-5.2` | OpenAI | The best model for coding and agentic tasks | | `google/gemini-2.5-flash` | Google | Fastest and most cost-efficient multimodal model | | `google/gemini-2.5-pro` | Google | Most capable Google model with advanced reasoning | | `xai/grok-4-1-fast-reasoning` | xAI / Reasoning | Fast reasoning and problem solving | | `deepseek/deepseek-reasoner` | DeepSeek | Advanced reasoning model | | `deepseek/deepseek-chat` | DeepSeek | Fast and efficient chat model (V3) | | `openai/o1` | OpenAI | Advanced reasoning and problem-solving | | `minimax/MiniMax-M2.1` | MiniMax | Reasoning model with tool support | ## Model Selection To use a specific model, pass its ID in the request body: ```json theme={null} { "model": "deepseek/deepseek-reasoner", "messages": [...] } ``` ## Capabilities Mapping | Feature | Support | | :-------------------- | :---------------------------------------------------------------------------------------- | | Text Generation | All models | | Visual Input (Vision) | `openai/gpt-4o`, `openai/gpt-5.2`, `google/gemini-2.5-pro`, `xai/grok-4-1-fast-reasoning` | | Web Search | All models (via Gateway tool) | | Streaming | All models | *** ## API Endpoints (OpenAI Compatible) The gateway follows the OpenAI API structure, so standard clients can fetch available models dynamically. ### `GET /api/v1/models` Retrieves the list of currently supported models in the standard OpenAI response format. **Example Request:** ```bash theme={null} curl http://localhost:3000/api/v1/models \ -H "Authorization: Bearer YOUR_API_KEY_HERE" ``` ### `GET /api/v1/models/[model]` Retrieves information about a specific model. Model IDs with slashes (e.g. `openai/gpt-4o`) are fully supported. **Example Request:** ```bash theme={null} curl http://localhost:3000/api/v1/models/openai/gpt-4o \ -H "Authorization: Bearer YOUR_API_KEY_HERE" ``` # Security Features Source: https://docs.onefirewall.com/ai-gateway/api-reference/security-features How the Secure AI Gateway protects your data. The Secure AI Gateway sits between your users and the AI providers and applies the following checks to every request and response. ## Secret Detection The gateway scans outgoing messages for credentials. If a secret is detected, the request is blocked before it reaches the AI provider. Detected secrets include: * API keys (OpenAI, AWS, GitHub, etc.) * Private keys (RSA, SSH, etc.) * Database connection strings * Bearer tokens ## PII Detection & Masking Personal Identifiable Information (PII) is detected automatically. Behavior is controlled by the `pii` parameter: * `disabled`: no scanning. For internal testing. * `obfuscate`: redacts sensitive data (e.g., `[REDACTED_EMAIL]`) and lets the conversation continue. * `block`: rejects the request if sensitive data is found. Supported PII types: * Email addresses * Phone numbers * Credit card numbers * IP addresses * Social Security Numbers (SSN) ## AI Firewall Rules The gateway enforces organizational policies through firewall rules. Rules can: * Prevent the model from discussing certain topics. * Enforce specific personas or safety guidelines. * Restrict usage based on time or volume. ## Audit Logs Every API request is logged. Log entries include: * User ID / API key ID * Model used * Timestamp * Security check result (e.g., "Blocked by Secret Detection") # API Usage Guide Source: https://docs.onefirewall.com/ai-gateway/introduction Complete guide to using the Secure AI Gateway API. ## Quick Start ### 1. Get Your API Key 1. Go to the **Profile** page in the app. 2. Click **Create API Key**. 3. Give it a name (e.g., "Automation Script"). 4. Copy the key immediately. It is not shown again. ### 2. Make Your First Request The endpoint is OpenAI-compatible, meaning you can use standard LLM libraries or simple `curl` commands. ```bash theme={null} curl https://onefirewall.ai/api/v1/chat/completions \ -H "Authorization: Bearer YOUR_API_KEY_HERE" \ -H "Content-Type: application/json" \ -d '{ "model": "openai/gpt-4o", "messages": [ {"role": "user", "content": "What is the capital of France?"} ] }' ``` ## API Reference ### Endpoint: `POST /api/v1/chat/completions` | Parameter | Type | Default | Description | | :------------ | :------ | :---------------- | :------------------------------------------------------------------------- | | `model` | string | **REQ** | Identifier (e.g., `openai/gpt-4o`, `grok/grok-beta`) | | `messages` | array | **REQ** | Chat history (OpenAI format) | | `system` | string | *Default Persona* | Custom system prompt. If provided, it overrides all default behavior. | | `stream` | boolean | `false` | Enable/disable real-time streaming. | | `web_search` | boolean | `true`\* | Enables tools. Defaults to `true` unless a custom `system` prompt is used. | | `pii` | string | `disabled` | Security mode: `disabled`, `obfuscate`, or `block`. | | `temperature` | number | `0.7` | Controls randomness (0.0 to 2.0). | *** ## Python Examples ### Standard (Non-Streaming) ```python theme={null} import requests API_KEY = "your_key_here" URL = "https://onefirewall.ai/api/v1/chat/completions" headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } data = { "model": "openai/gpt-4o", "web_search": True, "pii": "obfuscate", "messages": [ {"role": "user", "content": "Who won the Super Bowl recently?"} ] } response = requests.post(URL, headers=headers, json=data) print(response.json()["choices"][0]["message"]["content"]) ``` ### Streaming Use `stream: true` to receive tokens as they're generated, useful for CLI or UI applications. ```python theme={null} import requests import sys API_KEY = "your_key_here" URL = "https://onefirewall.ai/api/v1/chat/completions" data = { "model": "openai/gpt-4o", "stream": True, "messages": [{"role": "user", "content": "Write a long essay on AI ethics"}] } # Request with stream=True headers = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"} response = requests.post(URL, headers=headers, json=data, stream=True) # Flush output to console in real-time sys.stdout.reconfigure(encoding='utf-8') for chunk in response.iter_content(chunk_size=None): if chunk: print(chunk.decode('utf-8'), end="", flush=True) ``` *** ## JavaScript / Node.js Example ```javascript theme={null} const API_KEY = "sk-YOUR-KEY-HERE"; const URL = "https://onefirewall.ai/api/v1/chat/completions"; const response = await fetch(URL, { method: "POST", headers: { "Authorization": `Bearer ${API_KEY}`, "Content-Type": "application/json" }, body: JSON.stringify({ model: "openai/gpt-4o", messages: [ { role: "user", content: "Hello!" } ] }) }); const data = await response.json(); console.log(data.choices[0].message.content); ``` *** ## Tips 1. **HTTPS only**: all examples use `https://onefirewall.ai`; there is no unencrypted endpoint. 2. **`pii` level**: `disabled` for development (default), `obfuscate` for production, `block` where sensitive data must never reach the model. 3. **Model selection**: use the same model IDs available in the chat UI. 4. **Custom prompts**: a `system` prompt you provide replaces the default persona entirely — it is not merged with it. 5. **API independence**: the API does not read team UI settings; behavior is controlled entirely by request parameters. ## Managing API Keys * View keys: **Profile** page. * Delete a key: click the trash icon next to it in the key list. * Usage: request count and last-used date are shown per key in the same list. # Authorization Source: https://docs.onefirewall.com/api-reference/authorization Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. To use these APIs, you need authorized access to the OneFirewall platform. If you don't have an account, create one and log in at the [OneFirewall Alliance Platform](https://app.onefirewall.com). ### Generate an API Token Once you have access, go to the profile page and generate an API JWT token. Store it securely — you'll need it for every request to the APIs described in this documentation. Every request must include your token in the `Authorization` header. The example below targets `/api/v1/version`, an endpoint that doesn't actually require authorization. ##### HTTP Request ```http theme={null} GET /api/v1/version HTTP/1.1 Host: app.onefirewall.com Authorization: Bearer PLACE_YOUR_OWN_TOKEN_HERE ``` ##### Python Request ```python simple-http-request.py theme={null} import requests url = "https://app.onefirewall.com/api/v1/version" payload={} headers = { 'Authorization': 'Bearer PLACE_YOUR_OWN_TOKEN_HERE' } response = requests.request("GET", url, headers=headers, data=payload) print(response.text) ``` ### Organization Selection For certain APIs, especially those related to scanning and resource management, you must specify the organization context. You can do this in two ways: * Header: `X-Org-Id` set to your organization's ID. * Query parameter: `org_id=YOUR_ORG_ID` appended to the URL. If neither is provided, the API falls back to your default organization, or returns an error if no context can be determined. ##### Example with Org ID Header ```http theme={null} POST /api/v1/scan/example.com HTTP/1.1 Host: app.onefirewall.com Authorization: Bearer YOUR_TOKEN X-Org-Id: 69084dbb6b1a388fbd6c757d ``` # Domains by Score Source: https://docs.onefirewall.com/api-reference/endpoint/domain-feeds/domains-by-score get /domains/score/{min_score} Retrieve a list of malicious domains Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Domains by TS Source: https://docs.onefirewall.com/api-reference/endpoint/domain-feeds/domains-by-ts get /domains Retrieve the latest malicious domains recorded Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Overwrite Decision Source: https://docs.onefirewall.com/api-reference/endpoint/domain-feeds/overwrite-decision put /domains/{domain_name} This API is used to change / overwrite the decision based on score, in other words setting manually a IoC in whitelist or blacklist. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Report Domain Source: https://docs.onefirewall.com/api-reference/endpoint/domain-feeds/report-domain post /domains Enable users to report domains suspected of serving malware, viruses, or trojans. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Scan Domain Source: https://docs.onefirewall.com/api-reference/endpoint/domain-feeds/scan-domain get /domains/{domain_name} Retrieve metadata for over a million known malicious domains. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # CTI Source: https://docs.onefirewall.com/api-reference/endpoint/intel/get-intel get /intel/{ipv4} Cyber Threat Intelligence for a given IPv4, contains information about the IP, Crime Score, Reports, Members, MITRE, Agents, etc.. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # STIX2.0 Source: https://docs.onefirewall.com/api-reference/endpoint/iocs/stix20 get /stix2/{stix2id} STIX2 (Structured Threat Information eXpression version 2) is a standardized language for representing cyber threat intelligence (CTI) that enables the sharing of threat intelligence across organizations and security tools. It is important to Threat Intel because it allows security professionals to more easily and effectively analyze and respond to cyber threats, improving their overall threat intelligence capabilities. At OneFirewall, our mission is to deliver a trustworthy and effective cybersecurity platform that safeguards against cyber attacks. To accomplish this goal, we leverage STIX2 structured information to proactively identify and block malicious actors. We also empower our users with access to this critical threat intelligence data, enabling them to enhance their own cybersecurity defenses. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Latest IPv4 Source: https://docs.onefirewall.com/api-reference/endpoint/ipv4-feeds/latest-ipv4 get /ips You can call the API `/api/v1/ips` in order to receive an array of the latest IPv4 feeds collected at the OneFirewall Data lake. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Live IPv4 Source: https://docs.onefirewall.com/api-reference/endpoint/ipv4-feeds/live-ipv4 get /ipv4/{min_score} This API is similar with the `IP addresses [FLAT]` however have some advantages and disadvantages in respect: ##### Advantages 1. Real time calculation of the OneFirewall Crime Score 2. Equipped with the new (v3.2) Scoring algorithm 3. Can be integrated into directly Fortigate, Checkpoint, etc.. ##### Disadvantages 1. Use pagination (therefore you have to call multiple times the IP if the list is bigger than 10000) 2. Is relatively 6x slower than `IP addresses [FLAT]` Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # One IPv4 Source: https://docs.onefirewall.com/api-reference/endpoint/ipv4-feeds/one-ipv4 get /ips/{ipv4} You can call the API `/api/v1/ips/` in order to receive information for the IPv4 feeds in request if is presented at the OneFirewall Data lake. This API is useful when you want to verify if OneFirewall have an information for the actor in request. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Pre-compiled IPv4 Source: https://docs.onefirewall.com/api-reference/endpoint/ipv4-feeds/pre-compiled-ipv4 get /flat/{min_score} If you need a simple list (example CSV) to retrieve all the IPv4 feeds based on their score, you can use the below API Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Report IPv4 Source: https://docs.onefirewall.com/api-reference/endpoint/ipv4-feeds/report-ipv4 post /ips Post information about threat intelligence in relation to a IPv4 Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Files Source: https://docs.onefirewall.com/api-reference/endpoint/security-binary-feeds/files get /files/{digest} Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Files by Score Source: https://docs.onefirewall.com/api-reference/endpoint/security-binary-feeds/files-by-score get /files/score/{min_score} Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Files by TS Source: https://docs.onefirewall.com/api-reference/endpoint/security-binary-feeds/files-by-ts get /files Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Overwrite Decision Source: https://docs.onefirewall.com/api-reference/endpoint/security-binary-feeds/overwrite-decision put /files/{digest} Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Report Digest Source: https://docs.onefirewall.com/api-reference/endpoint/security-binary-feeds/report-digest post /files Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # File types Source: https://docs.onefirewall.com/api-reference/endpoint/tools/file-types get /file_types OneFirewall revertive each file flagged as malware and associates it with a specific file type (when possible), or more precisely, a MIME type. Currently, OneFirewall only accepts file types from a predetermined list provided by this API. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Health Check Source: https://docs.onefirewall.com/api-reference/endpoint/tools/health-check get /version The \`/version\` API endpoint is primarily used to verify the operational status of the API service. When accessed, it responds with basic information indicating the current version of the API, along with a confirmation that the service is active and available. This endpoint typically does not require authentication and serves as a straightforward health check to ensure that the API is up and running correctly. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # IP Metadata Source: https://docs.onefirewall.com/api-reference/endpoint/tools/ip-metadata get /info/{ipv4} You can call the API `/api/v1/info/` in order to receive GeoIP information for the IPv4. This API is useful when you want to verify public data in regards to the GeoIP of any IPv4 Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # List of CDNs Source: https://docs.onefirewall.com/api-reference/endpoint/tools/list-of-cdns get /info/cdn/list To retrieve a list of well-known Content Delivery Network (CDN) providers along with their respective edge IP addresses, you can utilize the `/api/v1/info/cdn/list` endpoint. The data provided by this API is generally static, yet the R&D team at OneFirewall periodically updates it. It’s worth noting that CDN providers frequently acquire new IP addresses, making it impossible to guarantee that the following list is exhaustive at any given moment. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Reverse Domain Source: https://docs.onefirewall.com/api-reference/endpoint/tools/reverse-domain get /info/domain/{domain_name} You can call the API `/api/v1/info/domain/` in order to receive an array IPs resolved for the Domain name. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Overwrite Decision Source: https://docs.onefirewall.com/api-reference/endpoint/url-feeds/overwrite-decision put /urls/{url} This API is used to change / overwrite the decision based on score, in other words setting manually a IoC in whitelist or blacklist. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Report URL Source: https://docs.onefirewall.com/api-reference/endpoint/url-feeds/report-url post /urls Enable users to report url suspected of serving malware, viruses, or trojans. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Scan URL Source: https://docs.onefirewall.com/api-reference/endpoint/url-feeds/scan-url get /urls/{url} Retrieve metadata for over a million known malicious feeds. Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # URLs by Score Source: https://docs.onefirewall.com/api-reference/endpoint/url-feeds/urls-by-score get /urls/score/{min_score} Retrieve a list of malicious urls Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # URLs by TS Source: https://docs.onefirewall.com/api-reference/endpoint/url-feeds/urls-by-ts get /urls Retrieve the latest malicious url recorded Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Create WCF Agent Source: https://docs.onefirewall.com/api-reference/endpoint/wcf-agent/create post /agents Creates a new WCF Agent with specified configuration for threat detection and IP blocking across multiple security platforms Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Delete an Agent Source: https://docs.onefirewall.com/api-reference/endpoint/wcf-agent/delete-one delete /feedback Delete Agent from the DB (this does not make the agent to stop working, you must disable the running before deleting) Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Get WCF Installation Source: https://docs.onefirewall.com/api-reference/endpoint/wcf-agent/get-all get /feedback The end point is used to retreive a list of WCF Agent installed, along with configuration presented and how each WCF Agent is performing Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Handle WCF Configuration Source: https://docs.onefirewall.com/api-reference/endpoint/wcf-agent/update post /feedback/config End-point to submit changes to the WCF Agent, the configuration set it here, will be saved into the DB and will be retreived from the WCF Installed agent, next time is synced Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. # Introduction Source: https://docs.onefirewall.com/api-reference/introduction Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. This site documents the OneFirewall API: endpoints, parameters, responses, and authentication, with examples and code snippets for each. We're always looking for feedback. Contact us at `support[at]onefirewall.com` with any suggestions. #### High Level Design #### APIs # OpenAPI 3.0 Source: https://docs.onefirewall.com/api-reference/openapi Updated API documentation with live interaction is now available in the product dashboard under **API Docs**. The openapi documentation was generated thanks to [apigit](.apigit.com) ```json openapi.json theme={null} { "openapi": "3.0.2", "info": { "title": "OneFirewall Alliance - OpenAPI 3.0", "description": "The API documentation site serves as a comprehensive resource for developers looking to utilize the OneFirewall Platform's application programming interface (API). It offers in-depth information on API endpoints, parameters, responses, and authentication processes. Additionally, it features practical examples and code snippets to assist developers in integrating the API into their own applications. The website is crafted to be user-friendly, intuitive, and easily navigable, enabling developers to swiftly locate the necessary information to begin working with the API.", "termsOfService": "https://onefirewall.com/privacy-policy.html", "contact": { "email": "support@onefirewall.com", "url": "https://onefirewall.com", "name": "Engineering Division" }, "license": { "name": "", "url": "" }, "version": "V4" }, "externalDocs": { "description": "http://docs.onefirewall.com", "url": "http://app.onefirewall.com" }, "servers": [ { "url": "https://app.onefirewall.com/api/v1", "description": "OneFirewall Server", "variables": {} } ], "tags": [ { "name": "IPv4 Feeds", "description": "", "externalDocs": { "description": "", "url": "" } }, { "name": "IoCs", "description": "", "externalDocs": { "description": "", "url": "" } }, { "name": "Tools", "description": "", "externalDocs": { "description": "", "url": "" } }, { "name": "URL Feeds", "description": "", "externalDocs": { "description": "", "url": "" } }, { "name": "Domain Feeds", "description": "", "externalDocs": { "description": "", "url": "" } }, { "name": "Security Binary Feeds", "description": "", "externalDocs": { "description": "", "url": "" } }, { "name": "Secure VPN", "description": "Secure VPN by OneFirewall", "externalDocs": { "description": "", "url": "" } } ], "paths": { "/stix2/{stix2id}": { "get": { "summary": "STIX2.0", "description": "STIX2 (Structured Threat Information eXpression version 2) is a standardized language for representing cyber threat intelligence (CTI) that enables the sharing of threat intelligence across organizations and security tools. It is important to Threat Intel because it allows security professionals to more easily and effectively analyze and respond to cyber threats, improving their overall threat intelligence capabilities.\nAt OneFirewall, our mission is to deliver a trustworthy and effective cybersecurity platform that safeguards against cyber attacks. To accomplish this goal, we leverage STIX2 structured information to proactively identify and block malicious actors. We also empower our users with access to this critical threat intelligence data, enabling them to enhance their own cybersecurity defenses.", "operationId": "stix2", "tags": [ "IoCs" ], "parameters": [], "responses": { "200": { "description": "The response body contains an array of STIX2 objects, for simplicy we not going to explain in details the content format, however we are using Standard STIX2 bundles, and more information can be found here: STIX™ Version 2.0", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": "string" } } } } } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "stix2id", "description": "Threat Actor ID (IPv4, URL, Domain, File), at the moment we only provide information based on IPv4", "schema": { "type": "string" }, "required": true } ] }, "/version": { "get": { "summary": "Health Check", "description": "The \\`/version\\` API endpoint is primarily used to verify the operational status of the API service. When accessed, it responds with basic information indicating the current version of the API, along with a confirmation that the service is active and available. This endpoint typically does not require authentication and serves as a straightforward health check to ensure that the API is up and running correctly.", "tags": [ "Tools" ], "parameters": [], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "version": "2024-03-14", "is_master": "true", "application": "OneFirewall WCF Server (V4)", "ofa_instance": "CLOUD", "hostname": "onefirewall-server-74f84cb45c-5zgs2", "m": 0, "e": "" } } } } } } }, "operationId": "version" } }, "/file_types": { "get": { "summary": "File types", "description": "OneFirewall revertive each file flagged as malware and associates it with a specific file type (when possible), or more precisely, a MIME type. Currently, OneFirewall only accepts file types from a predetermined list provided by this API.", "operationId": "file_types", "tags": [ "Tools" ], "parameters": [], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": [ { "name": "application/x-krita", "description": "KRA is the file format for Krita, a raster graphics editor. It is a ZIP archive containing a number of files, including the image data, the layer structure, and the document settings.

It is similar in function to PSD files for photoshop.

A .krz file is a compressed version of a .kra file and only missing the mergedimage.png contained within it to save storage. The lack of this file can affect interchange with other applications such as Scribus.", "types": [ ".kra", ".krz" ], "alternatives": [], "furtherReading": [ { "title": "Krita File Format", "url": "https://docs.krita.org/en/general_concepts/file_formats/file_kra.html" } ] } ] } } } } } }, "security": [ { "Authorization": [] } ] } }, "/files/{digest}": { "get": { "summary": "Files", "description": "", "operationId": "Search by Digest", "tags": [ "Security Binary Feeds" ], "parameters": [ { "in": "query", "name": "deep_scan", "description": "YES or NO (Defualt). A Deep Scan is perfromed accross 4 million IoCs if the Digest is not presented into the main OneFirewall Data Lake", "schema": { "type": "string", "default": "NO", "enum": [ "YES", "NO" ] } } ], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "md5": "947F536E12836C13CFC73638B796471D", "sha1": "F478B6E4653C4620AF43841CC1F0227BC79F3ADB", "sha256": "1AE54CBDE48D74B3312771FCDB51E672CD0D60F737FA5FE09F9C83597B8A3B5F", "score": 96, "ts": 1693519331, "file_bytes": null, "total_reports": 47, "total_members": 1, "file_type": "application/x-executable", "file_name": "947f536e12836c13cfc73638b796471d", "tags": [ "n/a", "elf", "Gafgyt" ], "elk_ts": "2023-08-31T22:02:11.000Z", "elk_entry_ts": "2023-08-30T00:03:23.000Z", "entry_ts": 1693353803 } } } } } } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "digest", "description": "Digest value in any format from MD5,SHA1,SHA256", "schema": { "type": "string" }, "required": true } ], "put": { "summary": "Overwrite Decision", "description": "", "operationId": "Overwrite Decision", "tags": [ "Security Binary Feeds" ], "parameters": [], "requestBody": { "content": { "application/json": { "schema": { "type": "object", "properties": { "decision": { "type": "string", "description": "0 for whitelist, 1 for blacklist, -1 (default) for based on score (not overwrite)" } }, "required": [ "decision" ] } } } }, "responses": { "200": { "description": "The request was received and processed successfully, no body content", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] } }, "/files/score/{min_score}": { "get": { "summary": "Files by Score", "description": "", "operationId": "Retrieve a list of malicious files by digest type", "tags": [ "Security Binary Feeds" ], "parameters": [ { "in": "query", "name": "format", "description": "CSV=the output is CSV, LIST=the output is a list of digest separated by ‘,’", "schema": { "type": "string", "default": "CSV", "enum": [ "CSV", "LIST" ] } }, { "in": "query", "name": "page", "description": "A cursor that indicates the next page ID to access the next batch of data", "schema": { "type": "string" } }, { "in": "query", "name": "digest", "description": "SHA256,SHA1 or MD5 (String)\t", "schema": { "type": "string", "enum": [ "SHA256", "SHA1", "MD5" ] }, "required": true } ], "responses": { "200": { "description": "If the response header contains a variable with name next_page, use the value with the new request on the API in order to retreive the next batch of data for the same Score. If the header is not presented, means there no more data to return.\n\n", "headers": {}, "content": { "text/html": { "schema": { "type": "string" }, "examples": { "example1": { "value": "E285554419641DFF5D76400773422172E364B53AE22C412D92EAA98A28CAE5F0\nA73E7A36715AD8A067EDD3B455ADA4AE88D5F973FB627F996FF6FD0BEC820B6E\n..." } } } } }, "400": { "content": {}, "headers": {}, "description": "The request was malformed (body contains further explanations)" }, "402": { "description": "Not enough OneFirewall Coins to perform the request", "content": {}, "headers": {} }, "403": { "description": "The request not authorized (body contains further explanations)", "content": {}, "headers": {} }, "404": { "description": "The requested digest was not found", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "min_score", "description": "Minimum WCF Crime Score Feeds", "schema": { "type": "number", "exclusiveMinimum": true, "exclusiveMaximum": true, "minimum": 1, "maximum": 1000 }, "required": true } ] }, "/files": { "get": { "summary": "Files by TS", "description": "", "operationId": "Retrieve the latest malicious files recorded", "tags": [ "Security Binary Feeds" ], "parameters": [ { "in": "query", "name": "ts", "description": "Latest updates starting from this timestamp", "schema": { "type": "number" }, "required": true }, { "in": "query", "name": "page_size", "description": "Maximum size to return", "schema": { "type": "number", "default": 101, "exclusiveMinimum": true, "minimum": 100, "exclusiveMaximum": true, "maximum": 2000 }, "required": false }, { "in": "query", "name": "min_score", "description": "Filter based on minimum score", "schema": { "type": "number", "exclusiveMinimum": true, "minimum": 0, "exclusiveMaximum": true, "maximum": 1000, "default": 1 } }, { "in": "query", "name": "file_type", "description": "Filter based on file type", "schema": { "type": "string" } }, { "in": "query", "name": "file_name", "description": "Filter based on file name", "schema": { "type": "string" } }, { "in": "query", "name": "tags\t", "description": "Array of strings separated by ‘,’ to return documents that contain at least one of the tags provided (default none)", "schema": { "type": "array", "items": { "type": "string" }, "minItems": 0, "maxItems": 100, "uniqueItems": true } } ], "responses": { "200": { "description": "The request was received and processed successfully", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "header": { "type": "Malware", "version": 4, "ts": 1693519200, "next_ts": 1693519490, "page_size": 100, "user": { "guid": "OFA-GUID-YORP-4193-FDFM", "name": "NAME", "surname": "Surname", "username": "name.surname@domain.com", "role": 0, "unsuccessful_login": 0, "member_of": { "gid": "OFA-GID-dsfgdsfgfdj", "name": "Org1", "trust": 0.85, "delay": "0", "credit_tokens": 2000000000, "debit_tokens": 1888915 } } }, "body": [ { "md5": "B3A5311FB0E11953EBD765D4231776EE", "sha1": "EE727E0FFE780EC24609B9FCCA8512ADE671E2D5", "sha256": "15678297D3D6DA1D77C9B5C7B479F5C3C922D739C42CA00641F3D3587A829970", "score": 96, "ts": 1693519331, "file_bytes": null, "total_reports": 47, "total_members": 1, "file_type": "application/x-executable", "file_name": "b3a5311fb0e11953ebd765d4231776ee", "tags": [ "n/a", "elf" ], "elk_ts": "2023-08-31T22:02:11.000Z", "elk_entry_ts": "2023-08-30T00:03:23.000Z", "entry_ts": 1693353803 }, { "md5": "947F536E12836C13CFC73638B796471D", "sha1": "F478B6E4653C4620AF43841CC1F0227BC79F3ADB", "sha256": "1AE54CBDE48D74B3312771FCDB51E672CD0D60F737FA5FE09F9C83597B8A3B5F", "score": 96, "ts": 1693519331, "file_bytes": null, "total_reports": 47, "total_members": 1, "file_type": "application/x-executable", "file_name": "947f536e12836c13cfc73638b796471d", "tags": [ "n/a", "elf", "Gafgyt" ], "elk_ts": "2023-08-31T22:02:11.000Z", "elk_entry_ts": "2023-08-30T00:03:23.000Z", "entry_ts": 1693353803 }, { "md5": "9D6980C593C635DE0E0A37224272924D", "sha1": "2EEA6F42D295AC7CEEB7FF079B99ADBB698C321F", "sha256": "DE895366E2FB48A164C45082928A4AF3D08969A5218F8B9581455635F7922876", "score": 96, "ts": 1693519331, "file_bytes": null, "total_reports": 47, "total_members": 1, "file_type": "application/x-executable", "file_name": "9d6980c593c635de0e0a37224272924d", "tags": [ "n/a", "elf" ], "elk_ts": "2023-08-31T22:02:11.000Z", "elk_entry_ts": "2023-08-30T00:03:23.000Z", "entry_ts": 1693353803 } ] } } } } } } }, "security": [ { "Authorization": [] } ] }, "post": { "summary": "Report Digest", "description": "", "operationId": "Report files suspected of containing a type of malware", "tags": [ "Security Binary Feeds" ], "parameters": [], "requestBody": { "content": { "application/json": { "schema": { "type": "object", "properties": { "confidence": { "type": "number", "description": "Confidence from 0.0 to 1.0", "default": 1 }, "tags": { "type": "array", "items": { "type": "string" } }, "file_bytes": { "type": "string" }, "file_type": { "type": "string" }, "file_name": { "type": "string" }, "md5": { "type": "string" }, "sha1": { "type": "string" }, "sha256": { "type": "string" } }, "required": [ "confidence", "file_type" ] } } } }, "responses": { "200": { "description": "The request was received and processed successfully, no body content\n", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] }, "parameters": [] }, "/flat/{min_score}": { "get": { "summary": "Pre-compiled IPv4", "description": "If you need a simple list (example CSV) to retrieve all the IPv4 feeds based on their score, you can use the below API", "operationId": "Pre-compiled CSV of IPv4 based on Min Score", "tags": [ "IPv4 Feeds" ], "parameters": [ { "in": "query", "name": "list", "description": "NO=the output is CSV, YES=the output is a list of IPs separated by ‘,’", "schema": { "type": "string", "enum": [ "YES", "NO" ], "default": "NO" } } ], "responses": { "200": { "description": "In case of an 200 response the body will be presented as the below examples:\n\n", "headers": {}, "content": { "text/html": { "schema": { "type": "string" }, "examples": { "example1": { "value": "IPv4,LiveScore,Members,Reports,LastUpdate,AS,ASN,CDN,Reverse,IS_CDN\nX.Y.Z.W,216,3,21,2023-04-29T04:43:54.000Z,,,,,<'Well-known CDN' in case of Valid CDN>\nX.Y.Z.W,211,3,45,2023-04-28T09:21:50.000Z,,,,,<'Well-known CDN' in case of Valid CDN>\nX.Y.Z.W,217,3,32,2023-04-29T05:54:04.000Z,,,,,<'Well-known CDN' in case of Valid CDN>\nX.Y.Z.W,204,3,53,2023-04-29T04:58:13.000Z,,,,,<'Well-known CDN' in case of Valid CDN>\n....." } } } } } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "min_score", "description": "", "schema": { "type": "number", "exclusiveMinimum": true, "minimum": 1, "exclusiveMaximum": true, "maximum": 1000 }, "required": true } ] }, "/ipv4/{min_score}": { "get": { "summary": "Live IPv4", "description": "This API is similar with the `IP addresses [FLAT]` however have some advantages and disadvantages in respect:\n\n##### Advantages\n\n1. Real time calculation of the OneFirewall Crime Score\n2. Equipped with the new (v3.2) Scoring algorithm\n3. Can be integrated into directly Fortigate, Checkpoint, etc..\n\n##### Disadvantages\n\n1. Use pagination (therefore you have to call multiple times the IP if the list is bigger than 10000)\n2. Is relatively 6x slower than `IP addresses [FLAT]`", "operationId": "", "tags": [ "IPv4 Feeds" ], "parameters": [ { "in": "query", "name": "format", "description": "CSV=the output is CSV, LIST=the output is a list of IPs separated by ‘,’", "schema": { "type": "string", "enum": [ "CSV", "LIST" ] } }, { "in": "query", "name": "agid", "description": "Agent ID", "schema": { "type": "string" } }, { "in": "query", "name": "plugin", "description": "Plugin Name", "schema": { "type": "string" } }, { "in": "query", "name": "page", "description": "A cursor that indicates the next page ID to access the next batch of data", "schema": { "type": "string" } } ], "responses": { "200": { "description": "If the response header contains a variable with name next_page, use the value with the new request on the API in order to retreive the next batch of data for the same Score. If the header is not presented, means there no more data to return.\n\n", "headers": {}, "content": { "text/html": { "schema": { "type": "string" }, "examples": { "example1": { "value": "X.Y.Z.W\nX.Y.Z.W\nX.Y.Z.W\nX.Y.Z.W\n....." } } } } } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "min_score", "description": "Minimum WCF Crime Score Feeds", "schema": { "type": "number", "exclusiveMinimum": true, "minimum": 0, "exclusiveMaximum": true, "maximum": 1001 }, "required": true } ] }, "/info/{ipv4}": { "get": { "summary": "IP Metadata", "description": "You can call the API `/api/v1/info/` in order to receive GeoIP information for the IPv4. This API is useful when you want to verify public data in regards to the GeoIP of any IPv4", "operationId": "IP Metadata", "tags": [ "Tools" ], "parameters": [], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "status": "success", "continent": "North America", "continentCode": "NA", "country": "United States", "countryCode": "US", "region": "VA", "regionName": "Virginia", "city": "Ashburn", "district": "", "zip": "20149", "lat": 39.03, "lon": -77.5, "timezone": "America/New_York", "offset": -14400, "currency": "USD", "isp": "Google LLC", "org": "Google Public DNS", "as": "AS15169 Google LLC", "asname": "GOOGLE", "reverse": "dns.google", "mobile": false, "proxy": false, "hosting": true, "query": "8.8.8.8" } } } } } } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "ipv4", "description": "Single IPv4", "schema": { "type": "string" }, "required": true } ] }, "/info/domain/{domain_name}": { "get": { "summary": "Reverse Domain", "description": "You can call the API `/api/v1/info/domain/` in order to receive an array IPs resolved for the Domain name.", "operationId": "Reverse Domain", "tags": [ "Tools" ], "parameters": [], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": [ "172.67.129.97", "104.21.2.162" ] } } } } } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "domain_name", "description": "Any valid Domain name", "schema": { "type": "string" }, "required": true } ] }, "/info/cdn/list": { "get": { "summary": "List of CDNs", "description": "To retrieve a list of well-known Content Delivery Network (CDN) providers along with their respective edge IP addresses, you can utilize the `/api/v1/info/cdn/list` endpoint. The data provided by this API is generally static, yet the R&D team at OneFirewall periodically updates it. It’s worth noting that CDN providers frequently acquire new IP addresses, making it impossible to guarantee that the following list is exhaustive at any given moment.", "operationId": "List of CDNs", "tags": [ "Tools" ], "parameters": [], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": "[\n {\n \"name\": \"\",\n \"addresses\": [\n \"\",\n \"\"\n \n ]\n },\n \n]" } } } } } }, "security": [ { "Authorization": [] } ] } }, "/ips": { "get": { "summary": "Latest IPv4", "description": "You can call the API `/api/v1/ips` in order to receive an array of the latest IPv4 feeds collected at the OneFirewall Data lake.", "operationId": "Latest IPv4", "tags": [ "IPv4 Feeds" ], "parameters": [ { "in": "query", "name": "page_size", "description": "The maximum size of the array to retrieve", "schema": { "type": "number", "exclusiveMinimum": true, "minimum": 0, "exclusiveMaximum": true, "maximum": 1001, "default": 50 }, "required": false }, { "in": "query", "name": "ts", "description": "Timestamp from when to retreive data", "schema": { "type": "integer", "exclusiveMinimum": true, "minimum": -1 }, "required": false }, { "in": "query", "name": "full", "description": "full=yes provide more information", "schema": { "type": "string", "enum": [ "yes", "no" ], "default": "no" } } ], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "header": { "type": "IPv4", "version": 2, "ts": "1684014988", "page_size": 1, "delay": 0, "eval": "return (scoreTimeZero) / (1 + Math.exp( (3/(scoreTimeZero)) * ((current_time/3600) - (2.5 * scoreTimeZero))))", "exec_python": "score = (scoreTimeZero) / (1 + numpy.exp( (3/(scoreTimeZero)) * ((current_time/3600) - (2.5 * scoreTimeZero))))", "user": { "guid": "OFA-GUID-XXXX-XXXX-XXXX", "name": "Your name", "surname": "Your surname", "username": "Your email", "role": 0, "unsuccessful_login": 0, "member_of": { "gid": "OFA-GID-XXXXXXX", "name": "Organisation name", "trust": 0.9, "delay": "0" } } }, "body": [ { "gid": "OFA-RULE-GID-XXXXXX", "ip": "XXX.YYY.ZZZ.WWW", "ts": 1684015144, "entry_ts": 1683928684, "is_network": false, "ip_info": { "as_domain": "cloudflare.com", "as_name": "Cloudflare, Inc.", "asn": "AS13335", "continent": "NA", "continent_name": "North America", "country": "US", "country_name": "United States" }, "score": 34, "info": { "members": 1, "events": 1, "sources": [ "sshlog" ], "stix_bundles": [], "attack_infos": [], "notes": [ "May 12 23:47:55 OFA-SRV2 sshd[12317]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=XXX.YYY.ZZZ.WWW user=root" ] }, "elk_ts": "2023-05-13T21:59:04.000Z", "elk_entry_ts": "2023-05-12T21:58:04.000Z", "delay": 0, "dec": 8.3e-7 } ] } } } } } } }, "security": [ { "Authorization": [] } ] }, "post": { "summary": "Report IPv4", "description": "Post information about threat intelligence in relation to a IPv4", "operationId": "Report IPv4", "tags": [ "IPv4 Feeds" ], "parameters": [], "requestBody": { "content": { "application/json": { "schema": { "type": "object", "properties": { "ip": { "type": "string", "description": "An IPv4 format for single IP or Network" }, "confidence": { "type": "number", "description": "A confidence value 0.0 to 1.0. A percentace of confidence on the the actor being malicious" }, "notes": { "type": "string", "description": "Notes associated to the actor " }, "decision": { "type": "number", "default": -1, "exclusiveMinimum": true, "minimum": -2, "exclusiveMaximum": true, "maximum": 2, "description": "-1==no decision (default), 0==whitelist, 1==Block" }, "ttl": { "type": "number", "description": "Until when the decision is valid (Timestamp in the future)" }, "source": { "type": "string", "description": "The source from where the actor was identified" } }, "required": [ "ip", "confidence", "source" ] } } } }, "responses": { "200": { "description": "", "content": {}, "headers": {} }, "201": { "description": "", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] } }, "/ips/{ipv4}": { "get": { "summary": "One IPv4", "description": "You can call the API `/api/v1/ips/` in order to receive information for the IPv4 feeds in request if is presented at the OneFirewall Data lake. This API is useful when you want to verify if OneFirewall have an information for the actor in request.", "operationId": "One IPv4", "tags": [ "IPv4 Feeds" ], "parameters": [], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "header": { "type": "IPv4", "version": 2, "ts": "1684014988", "page_size": 1, "delay": 0, "eval": "return (scoreTimeZero) / (1 + Math.exp( (3/(scoreTimeZero)) * ((current_time/3600) - (2.5 * scoreTimeZero))))", "exec_python": "score = (scoreTimeZero) / (1 + numpy.exp( (3/(scoreTimeZero)) * ((current_time/3600) - (2.5 * scoreTimeZero))))", "user": { "guid": "OFA-GUID-XXXX-XXXX-XXXX", "name": "Your name", "surname": "Your surname", "username": "Your email", "role": 0, "unsuccessful_login": 0, "member_of": { "gid": "OFA-GID-XXXXXXX", "name": "Organisation name", "trust": 0.9, "delay": "0" } } }, "body": [ { "gid": "OFA-RULE-GID-XXXXXX", "ip": "XXX.YYY.ZZZ.WWW", "ts": 1684015144, "entry_ts": 1683928684, "is_network": false, "ip_info": { "as_domain": "cloudflare.com", "as_name": "Cloudflare, Inc.", "asn": "AS13335", "continent": "NA", "continent_name": "North America", "country": "US", "country_name": "United States" }, "score": 34, "info": { "members": 1, "events": 1, "sources": [ "sshlog" ], "stix_bundles": [], "attack_infos": [], "notes": [ "May 12 23:47:55 OFA-SRV2 sshd[12317]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=XXX.YYY.ZZZ.WWW user=root" ] }, "elk_ts": "2023-05-13T21:59:04.000Z", "elk_entry_ts": "2023-05-12T21:58:04.000Z", "delay": 0, "dec": 8.3e-7 } ] } } } } } } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "ipv4", "description": "A single IPv4", "schema": { "type": "string" }, "required": true } ] }, "/domains/{domain_name}": { "get": { "summary": "Scan Domain", "description": "Retrieve metadata for over a million known malicious domains.", "operationId": "Scan Domain", "tags": [ "Domain Feeds" ], "parameters": [], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "domain": "ukfoyr.com", "score": 88, "ts": 1693526732, "total_reports": 1, "total_members": 1, "tags": [ "CTA", "OneFirewall" ], "elk_ts": "2023-09-01T00:05:32.000Z", "elk_entry_ts": "2023-09-01T00:05:32.000Z", "entry_ts": 1693526732 } } } } } } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "domain_name", "description": "Domain name you wishing to gain information (must be valid format)", "schema": { "type": "string" }, "required": true } ], "put": { "summary": "Overwrite Decision", "description": "This API is used to change / overwrite the decision based on score, in other words setting manually a IoC in whitelist or blacklist.", "operationId": "Domain", "tags": [ "Domain Feeds" ], "parameters": [], "requestBody": { "content": { "application/json": { "schema": { "type": "object", "properties": { "decision": { "type": "integer", "description": "0 for whitelist, 1 for blacklist, -1 (default) for based on score (not overwrite)", "exclusiveMinimum": true, "minimum": -2, "exclusiveMaximum": true, "maximum": 2, "default": -1 } }, "required": [ "decision" ] } } } }, "responses": { "200": { "description": "", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] } }, "/domains/score/{min_score}": { "get": { "summary": "Domains by Score", "description": "Retrieve a list of malicious domains", "operationId": "Domains by Score", "tags": [ "Domain Feeds" ], "parameters": [ { "in": "query", "name": "format", "description": "CSV=the output is CSV, LIST=the output is a list of digest separated by ‘,’", "schema": { "type": "string", "default": "CSV", "enum": [ "CSV", "LIST" ] } }, { "in": "query", "name": "page", "description": "A cursor that indicates the next page ID to access the next batch of data", "schema": { "type": "string" } }, { "in": "query", "name": "protocol", "description": "SHA256,SHA1 or MD5 (String)\t", "schema": { "type": "string", "enum": [ "HTTP", "HTTPS" ] }, "required": true } ], "responses": { "200": { "description": "If the response header contains a variable with name next_page, use the value with the new request on the API in order to retreive the next batch of data for the same Score. If the header is not presented, means there no more data to return.\n\n\n", "headers": {}, "content": { "text/html": { "schema": { "type": "string" }, "examples": { "example1": { "value": "domain1.xyz\ndomain2.xyz\n..." } } } } }, "400": { "content": {}, "headers": {}, "description": "The request was malformed (body contains further explanations)" }, "402": { "description": "Not enough OneFirewall Coins to perform the request", "content": {}, "headers": {} }, "403": { "description": "The request not authorized (body contains further explanations)", "content": {}, "headers": {} }, "404": { "description": "The requested digest was not found", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "min_score", "description": "Minimum WCF Crime Score Feeds", "schema": { "type": "number", "exclusiveMinimum": true, "exclusiveMaximum": true, "minimum": 1, "maximum": 1000 }, "required": true } ] }, "/domains": { "get": { "summary": "Domains by TS", "description": "Retrieve the latest malicious domains recorded", "operationId": "Domains by TS", "tags": [ "Domain Feeds" ], "parameters": [ { "in": "query", "name": "ts", "description": "Latest updates starting from this timestamp", "schema": { "type": "number" }, "required": true }, { "in": "query", "name": "page_size", "description": "Maximum size to return", "schema": { "type": "number", "default": 101, "exclusiveMinimum": true, "minimum": 100, "exclusiveMaximum": true, "maximum": 2000 }, "required": false } ], "responses": { "200": { "description": "The request was received and processed successfully", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "header": { "type": "Domain", "version": 4, "ts": 1693519200, "next_ts": 1693526758, "page_size": 100, "user": { "guid": "OFA-GUID-DSDG-FDFG-XJDO", "name": "Name", "surname": "Surname", "username": "name.surname@domain.com", "role": 0, "unsuccessful_login": 0, "member_of": { "gid": "OFA-GID-sdgdfgdfd", "name": "Org1", "trust": 0.85, "delay": "0", "credit_tokens": 2000000000, "debit_tokens": 1888975 } } }, "body": [ { "domain": "ukfoyr.com", "score": 88, "ts": 1693526732, "total_reports": 1, "total_members": 1, "tags": [ "CTA", "OneFirewall" ], "elk_ts": "2023-09-01T00:05:32.000Z", "elk_entry_ts": "2023-09-01T00:05:32.000Z", "entry_ts": 1693526732 }, { "domain": "vewuio.com", "score": 88, "ts": 1693526732, "total_reports": 1, "total_members": 1, "tags": [ "CTA", "OneFirewall" ], "elk_ts": "2023-09-01T00:05:32.000Z", "elk_entry_ts": "2023-09-01T00:05:32.000Z", "entry_ts": 1693526732 } ] } } } } } } }, "security": [ { "Authorization": [] } ] }, "post": { "summary": "Report Domain", "description": "Enable users to report domains suspected of serving malware, viruses, or trojans.", "operationId": "Report Domain", "tags": [ "Domain Feeds" ], "parameters": [], "requestBody": { "content": { "application/json": { "schema": { "type": "object", "properties": { "confidence": { "type": "number", "description": "Confidence level on the malicious capabilities of the domain", "default": 1 }, "tags": { "type": "array", "items": { "type": "string" }, "uniqueItems": true, "minItems": 1, "maxItems": 10 }, "domain": { "type": "string", "description": "Domain name" } }, "required": [ "confidence", "file_type", "domain" ] } } } }, "responses": { "200": { "description": "The request was received and processed successfully, no body content\n", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] }, "parameters": [] }, "/urls/{url}": { "get": { "summary": "Scan URL", "description": "Retrieve metadata for over a million known malicious feeds.", "operationId": "Scan URL", "tags": [ "URL Feeds" ], "parameters": [], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "url": "http://www.almaservice.it", "score": 54, "ts": 1695896501, "total_reports": 1, "total_members": 1, "tags": [ "MARAVENTO", "OneFirewall" ], "elk_ts": "2023-09-28T10:21:41.000Z", "elk_entry_ts": "2023-09-28T10:21:41.000Z", "entry_ts": 1695896501 } } } } } } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "url", "description": "URL you wishing to gain information (must be valid format and URL Encoded)", "schema": { "type": "string" }, "required": true } ], "put": { "summary": "Overwrite Decision", "description": "This API is used to change / overwrite the decision based on score, in other words setting manually a IoC in whitelist or blacklist.", "operationId": "Overwrite Decision URL", "tags": [ "URL Feeds" ], "parameters": [], "requestBody": { "content": { "application/json": { "schema": { "type": "object", "properties": { "decision": { "type": "integer", "description": "0 for whitelist, 1 for blacklist, -1 (default) for based on score (not overwrite)", "exclusiveMinimum": true, "minimum": -2, "exclusiveMaximum": true, "maximum": 2, "default": -1 } }, "required": [ "decision" ] } } } }, "responses": { "200": { "description": "", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] } }, "/urls/score/{min_score}": { "get": { "summary": "URLs by Score", "description": "Retrieve a list of malicious urls", "operationId": "URLs by Score", "tags": [ "URL Feeds" ], "parameters": [ { "in": "query", "name": "format", "description": "CSV=the output is CSV, LIST=the output is a list of digest separated by ‘,’", "schema": { "type": "string", "default": "CSV", "enum": [ "CSV", "LIST" ] } }, { "in": "query", "name": "page", "description": "A cursor that indicates the next page ID to access the next batch of data", "schema": { "type": "string" } } ], "responses": { "200": { "description": "If the response header contains a variable with name next_page, use the value with the new request on the API in order to retreive the next batch of data for the same Score. If the header is not presented, means there no more data to return.\n\n\n", "headers": {}, "content": { "text/html": { "schema": { "type": "string" }, "examples": { "example1": { "value": "URL1\nURL2\n..." } } } } }, "400": { "content": {}, "headers": {}, "description": "The request was malformed (body contains further explanations)" }, "402": { "description": "Not enough OneFirewall Coins to perform the request", "content": {}, "headers": {} }, "403": { "description": "The request not authorized (body contains further explanations)", "content": {}, "headers": {} }, "404": { "description": "The requested digest was not found", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] }, "parameters": [ { "in": "path", "name": "min_score", "description": "Minimum WCF Crime Score Feeds", "schema": { "type": "number", "exclusiveMinimum": true, "exclusiveMaximum": true, "minimum": 1, "maximum": 1000 }, "required": true } ] }, "/urls": { "get": { "summary": "URLs by TS", "description": "Retrieve the latest malicious url recorded", "operationId": "URLs by TS", "tags": [ "URL Feeds" ], "parameters": [ { "in": "query", "name": "ts", "description": "Latest updates starting from this timestamp", "schema": { "type": "number" }, "required": true }, { "in": "query", "name": "page_size", "description": "Maximum size to return", "schema": { "type": "number", "default": 101, "exclusiveMinimum": true, "minimum": 100, "exclusiveMaximum": true, "maximum": 2000 }, "required": false } ], "responses": { "200": { "description": "The request was received and processed successfully", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "header": { "type": "URL", "version": 4, "ts": 1693519200, "next_ts": 1695919395, "page_size": 100, "user": { "guid": "OFA-GUID-3256-FDGS-OODP", "name": "Name", "surname": "Surname", "username": "name.surname@domain.com", "role": 0, "unsuccessful_login": 0, "member_of": { "gid": "OFA-GID-jkbjhvhjg", "name": "Org1", "trust": 0.85, "delay": "0", "credit_tokens": 2000000000, "debit_tokens": 1888963 } } }, "body": [ { "url": "http://www.almaservice.it", "score": 54, "ts": 1695896501, "total_reports": 1, "total_members": 1, "tags": [ "MARAVENTO", "OneFirewall" ], "elk_ts": "2023-09-28T10:21:41.000Z", "elk_entry_ts": "2023-09-28T10:21:41.000Z", "entry_ts": 1695896501 }, { "url": "http://www.gothamserver.net", "score": 54, "ts": 1695898867, "total_reports": 1, "total_members": 1, "tags": [ "MARAVENTO", "OneFirewall" ], "elk_ts": "2023-09-28T11:01:07.000Z", "elk_entry_ts": "2023-09-28T11:01:07.000Z", "entry_ts": 1695898867 } ] } } } } } } }, "security": [ { "Authorization": [] } ] }, "post": { "summary": "Report URL", "description": "Enable users to report url suspected of serving malware, viruses, or trojans.", "operationId": "Report URL", "tags": [ "URL Feeds" ], "parameters": [], "requestBody": { "content": { "application/json": { "schema": { "type": "object", "properties": { "confidence": { "type": "number", "description": "Confidence from 0.0 to 1.0", "default": 1 }, "tags": { "type": "array", "items": { "type": "string" }, "uniqueItems": true, "minItems": 1, "maxItems": 10 }, "url": { "type": "string", "description": "Confidence level on the malicious capabilities of the url" } }, "required": [ "confidence", "file_type", "url" ] } } } }, "responses": { "200": { "description": "The request was received and processed successfully, no body content\n", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ] }, "parameters": [] }, "/vpn/{vid}": { "get": { "description": "Get Information and Installation instruction of a given VPN License ID", "operationId": "Get VPN ID", "tags": [ "Secure VPN" ], "parameters": [], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": { "vid": "OFA-VID-LIC-XXXXXX", "account_name": "Test", "notes": "", "ts": 1720917876, "user": { "guid": "OFA-GUID-2091-4193-9813", "name": "Name", "surname": "Surname", "username": "name.surname@onefirewall.com", "role": 0, "unsuccessful_login": 0, "member_of": { "gid": "OFA-GID-XXXXXXX", "name": "OneFirewall Alliance LTD", "trust": 0.85, "delay": "0", "credit_tokens": 20003000, "debit_tokens": 2597036, "is_public": 0 } }, "mgid": "OFA-GID-XXXXXXXXX", "exist": true } } } } } } }, "security": [ { "Authorization": [] } ], "summary": "Get VPN ID" }, "delete": { "description": "Deactivate a given VPN License ID", "operationId": "Delete VPN ID", "tags": [ "Secure VPN" ], "parameters": [], "responses": { "200": { "description": "", "content": {}, "headers": {} } }, "security": [ { "Authorization": [] } ], "summary": "Delete VPN ID" }, "parameters": [ { "in": "path", "name": "vid", "description": "VPN ID (Starts with OFA-VID-LIC prefix)", "schema": { "type": "string" }, "required": true } ] }, "/vpn": { "get": { "summary": "Get all", "description": "Use this method to get an array of active VPN for your organization", "operationId": "Get all Active VPN for your Organization", "tags": [ "Secure VPN" ], "parameters": [], "security": [ { "Authorization": [] } ], "responses": { "200": { "description": "", "headers": {}, "content": { "application/json": { "schema": { "type": "string" }, "examples": { "example1": { "value": [ { "vid": "OFA-VID-LIC-XXXX", "account_name": "Test", "notes": "", "ts": 1720950949, "user": { "guid": "OFA-GUID-2091-4193-9813", "name": "Name", "surname": "Surname", "username": "name.surname@onefirewall.com", "role": 0, "unsuccessful_login": 0, "member_of": { "gid": "OFA-GID-XXXXXX", "name": "OneFirewall Alliance LTD", "trust": 0.85, "delay": "0", "credit_tokens": 20003000, "debit_tokens": 2597241, "is_public": 0 } }, "mgid": "OFA-GID-XXXXX", "exist": true }, { "vid": "OFA-VID-LIC-XXXXX", "account_name": "ds", "notes": "", "ts": 1720954197, "user": { "guid": "OFA-GUID-2091-4193-9813", "name": "Name", "surname": "Surname", "username": "name.surname@onefirewall.com", "role": 0, "unsuccessful_login": 0, "member_of": { "gid": "OFA-GID-XXXXX", "name": "OneFirewall Alliance LTD", "trust": 0.85, "delay": "0", "credit_tokens": 20003000, "debit_tokens": 2597277, "is_public": 0 } }, "mgid": "OFA-GID-XXXXX", "exist": true } ] } } } } } } }, "post": { "summary": "Create", "description": "Create a new VPN License", "operationId": "Create a new VPN License for your Organization", "tags": [ "Secure VPN" ], "parameters": [], "requestBody": { "content": { "application/json": { "schema": { "type": "object", "properties": { "account_name": { "type": "string", "description": "Account name (mandatory)" }, "notes": { "type": "string", "description": "Addition notes" } }, "required": [ "account_name" ] } } } }, "security": [ { "Authorization": [] } ], "responses": { "200": { "description": "", "content": {}, "headers": {} } } } } }, "components": { "schemas": {}, "securitySchemes": { "Authorization": { "type": "apiKey", "in": "header", "description": "Authorization Token", "name": "Authorization" } }, "headers": {}, "responses": {} }, "security": [] } ``` # Authorization Source: https://docs.onefirewall.com/closedvpn/authorization How to obtain a Personal Access Token and authenticate your requests. ClosedVPN authenticates API requests with a **Personal Access Token (PAT)** sent in the `Authorization` header. This page covers how to get your first token, how to use it, and how to manage its lifecycle. ## Getting your first token Creating a token requires an authenticated session, so the very first token comes from signing in. There are two routes. 1. Sign in at [closedvpn.io](https://closedvpn.io) using the magic link sent to your email address. 2. Open the **Profile** page. 3. Choose **Create token**, give it a name, and optionally set an expiry. 4. Copy the token immediately — it is shown only once. The magic link flow is the only way to authenticate without an existing token. **1. Request a link.** This endpoint needs no credential. If the address has no account, one is created. ```bash theme={null} curl -X POST https://closedvpn.io/auth/send-magic-link \ -H "Content-Type: application/json" \ -d '{"email": "john@example.com"}' ``` **2. Follow the link.** The email contains a URL carrying a `token` query parameter, valid for 24 hours and usable once. Visiting it exchanges the token for a session cookie. ```bash theme={null} curl -c cookies.txt \ "https://closedvpn.io/auth/verify-magic-link?token=THE_TOKEN_FROM_THE_EMAIL" ``` **3. Create a PAT** using that session. ```bash theme={null} curl -b cookies.txt -X POST https://closedvpn.io/auth/generate-pat \ -H "Content-Type: application/json" \ -d '{"tokenName": "CI Pipeline", "expiryDays": 90}' ``` ```json theme={null} { "message": "PAT generated", "pat": "a3f5b8c1d2e4f607", "note": "Save this PAT securely; it won't be shown again!" } ``` The value in the `pat` field is the only time the plaintext token is available. It is stored as a bcrypt hash, so it cannot be recovered. If it is lost, revoke it and create a new one. ## Using your token Send the token as a Bearer credential on every request. ```bash theme={null} curl https://closedvpn.io/auth/get-orgs \ -H "Authorization: Bearer YOUR_PAT_HERE" ``` The first time a magic link is verified, a default organization named **My Org** is created with you as its owner, and the first available VPN is assigned to it. So a new account can call organization endpoints immediately. ## Organization context Endpoints that act on a single organization either take an explicit `org_id`, or fall back to your **selected organization**. ```bash theme={null} curl -X POST https://closedvpn.io/auth/select-org \ -H "Authorization: Bearer YOUR_PAT_HERE" \ -H "Content-Type: application/json" \ -d '{"orgId": "60c72b2f5f1b2c001c8e4b1a"}' ``` `GET /auth/vpn-exit-nodes` requires a selection and returns `400` without one. `GET /auth/threat-prevention-stats` accepts an optional `org_id` and falls back to the selection. ## Roles Each member of an organization is either an **owner** or a **member**. Owner-only operations are: updating and deleting the organization, adding members, changing roles, and removing members. Attempting one as a member returns `403`. Two guards apply to owners: you cannot change your own role, and the last remaining owner can neither leave nor delete their only organization. ## Managing tokens [`GET /auth/get-pats`](/closedvpn/endpoint/personal-access-tokens/get-pats) returns your active tokens. Only the bcrypt hash of each is returned, never the plaintext. Tokens whose expiry has passed are deactivated as a side effect of this call and excluded from the result. [`POST /auth/delete-pat`](/closedvpn/endpoint/personal-access-tokens/delete-pat) deactivates a token. Pass the **hash** returned by `GET /auth/get-pats` in the `token` field, not the plaintext value. Pass `expiryDays` when creating a token to set a lifetime. Omit it for a token that never expires. An expired token returns `403`. `POST /auth/logout` clears the browser session cookie only. It does not revoke Personal Access Tokens and has no effect on API clients. Use `/auth/delete-pat` to revoke a token. ## Authentication errors | Status | Meaning | | :----- | :------------------------------------------------------------- | | `401` | No credential was supplied. | | `403` | The token is invalid, expired, or has been deactivated. | | `403` | The token is valid, but you lack permission for this resource. | A `403` where you expect success usually means the token is fine but your role is insufficient, or you are not an active member of the target organization. # Creating a VPN Certificate Source: https://docs.onefirewall.com/closedvpn/create-vpn-cert Issue and download an OpenVPN client profile for a member. Each member of an organization gets one OpenVPN client profile. A single endpoint both issues and returns it: ``` GET /auth/download-certificate?org_id= ``` The first call generates the certificate on the VPN host and consumes one licence. Every later call returns the same certificate and consumes nothing, so the endpoint is safe to call repeatedly. ## Prerequisites Before a certificate can be issued: * You are an **active member** of the organization. * A VPN configuration is **assigned** to that organization. * That VPN's `commands` map defines a **`create_cert`** entry. * The organization has at least one **free licence** (`used_licenses` \< `total_licenses`). ## Step 1 — Find your organization ```bash theme={null} curl https://closedvpn.io/auth/get-orgs \ -H "Authorization: Bearer YOUR_PAT_HERE" ``` Take the `_id` of the organization you want. The response also carries `used_licenses` and `total_licenses`, so you can confirm capacity before issuing, and `vpn_name` tells you which VPN is assigned. ```json theme={null} { "orgs": [ { "_id": "60c72b2f5f1b2c001c8e4b1a", "name": "My Org", "vpn_id": "60c72b2f5f1b2c001c8e4b2a", "vpn_name": "Frankfurt Node", "used_licenses": 3, "total_licenses": 10 } ] } ``` ## Step 2 — Download the profile ```bash theme={null} curl -OJ "https://closedvpn.io/auth/download-certificate?org_id=60c72b2f5f1b2c001c8e4b1a" \ -H "Authorization: Bearer YOUR_PAT_HERE" ``` The response is served as `application/x-openvpn-profile` with a `Content-Disposition` header naming the file, for example `ClosedVPN-My Org.ovpn`. The `-OJ` flags above tell curl to honour that name. ## The response format The body is **not** a bare `.ovpn` file. The first line is a `# closedvpn-json` comment carrying the organization's exit nodes, followed by a blank line and then the OpenVPN profile. ``` # closedvpn-json {"vpnExitNodes":[{"id":"60c72b2f5f1b2c001c8e4b2a","name":"Frankfurt Node","location":"Frankfurt, Germany","coordinates":[50.1109,8.6821]}]} client dev tun proto udp remote vpn-fra.closedvpn.io 1194 ... ``` OpenVPN ignores `#` comment lines, so the file works as-is with most clients. If your tooling parses the profile strictly, strip the first two lines: ```bash theme={null} tail -n +3 "ClosedVPN-My Org.ovpn" > profile.ovpn ``` Or read the exit-node metadata out of it: ```bash theme={null} head -1 "ClosedVPN-My Org.ovpn" | sed 's/^# closedvpn-json //' | jq . ``` ## Licences A licence is consumed only when a **new** certificate is generated. `used_licenses` increments at that point. Re-downloading an existing certificate does not consume another. Licences are never released. `used_licenses` only ever increases — removing a member or having them leave does not free their licence — so an organization that cycles through members will need `total_licenses` raised. Once all licences are used, further members receive `403`. The message differs by role: owners are told to acquire more licences, members are told to contact their owner. ## Troubleshooting The `org_id` query parameter is missing. No VPN configuration is attached to the organization. Assign one, or create the organization with a `vpnId` — list the available VPNs with `GET /auth/vpns`. The assigned VPN configuration has no `create_cert` entry in its `commands` map. An administrator must add it before certificates can be issued. Occurrences of `CLIENT_NAME` in the command are substituted at run time. All licences are in use. `used_licenses` is never decremented — removing a member or having them leave does not release their licence — so the only remedy is to increase `total_licenses`. You are not an active member of the organization named by `org_id`. The `org_id` does not match any organization. Check the value against `GET /auth/get-orgs`. The same status is returned as `User not found` in the rare case where your own user record no longer exists. The organization references a VPN configuration that no longer exists. An administrator must assign a valid VPN — list them with `GET /auth/vpns`. The platform reached the VPN host but the `create_cert` command failed. The `details` field carries the host's error output. The `create_cert` command ran without error but produced no output. The command itself is likely misconfigured on the VPN host. ## Checking the connection Once connected, confirm the tunnel and read traffic counters with [`GET /auth/vpn-user-stats`](/closedvpn/endpoint/statistics/vpn-user-stats). ```bash theme={null} curl "https://closedvpn.io/auth/vpn-user-stats?org_id=60c72b2f5f1b2c001c8e4b1a" \ -H "Authorization: Bearer YOUR_PAT_HERE" ``` When you are not connected, or the VPN host cannot be reached, the response is `{"connected": false}` with no other fields. Check `connected` before reading the rest. # Activity Logs Source: https://docs.onefirewall.com/closedvpn/endpoint/activity-logs/activity-logs GET /auth/activity-logs Returns the last 50 activity logs for the authenticated user across all their organizations, personalized with "You" for the caller's actions. # Logout Source: https://docs.onefirewall.com/closedvpn/endpoint/authentication/logout POST /auth/logout Clears the browser session cookie. This endpoint has no effect for API clients authenticating with a Personal Access Token, and it does not revoke tokens. Use `/auth/delete-pat` to revoke a PAT. # Send Magic Link Source: https://docs.onefirewall.com/closedvpn/endpoint/authentication/send-magic-link POST /auth/send-magic-link Generates and emails a one-time magic link to initiate authentication. This endpoint does not require authentication as it starts the login process. # Validate Token Source: https://docs.onefirewall.com/closedvpn/endpoint/authentication/validate-token GET /auth/validate-token Validates the provided PAT and returns user information if valid, including the selected organization if set. # Verify Magic Link Source: https://docs.onefirewall.com/closedvpn/endpoint/authentication/verify-magic-link GET /auth/verify-magic-link Validates the magic link token from the email. Upon success, sets an authentication cookie and returns user info, allowing PAT generation via `/auth/generate-pat`. This endpoint does not require PAT authentication; it uses the token query parameter for verification. # Download Certificate Source: https://docs.onefirewall.com/closedvpn/endpoint/certificates/download-certificate GET /auth/download-certificate Returns the caller's OpenVPN client profile for an organization, issuing one on first use. If the caller already holds a certificate it is returned as-is and no licence is consumed, so this endpoint is safe to call repeatedly. Otherwise the platform runs the VPN configuration's `create_cert` command over SSH, stores the result and increments `used_licenses`. Issuing a new certificate requires a VPN assigned to the organization, a `create_cert` entry in that VPN's `commands` map, and at least one free licence. **JavaScript only** — the auto-generated sample calls `res.json()`, which throws a `SyntaxError` because this endpoint returns an OpenVPN profile (`application/x-openvpn-profile`), not JSON. Use `res.text()` instead, as shown below. The cURL, Python, PHP, Go, Java and Ruby samples handle this correctly. ```js theme={null} fetch('https://closedvpn.io/auth/download-certificate?org_id=YOUR_ORG_ID', { headers: { Authorization: 'Bearer YOUR_PAT' } }) .then(res => res.text()) .then(profile => console.log(profile)) .catch(err => console.error(err)); ``` For a complete walkthrough — including how to strip the leading `# closedvpn-json` metadata line and save the profile as a `.ovpn` file — see [Creating a VPN Certificate](/closedvpn/create-vpn-cert). # Add Member Source: https://docs.onefirewall.com/closedvpn/endpoint/members/add-user POST /auth/add-user Adds a user to an organization with a specified role and activates membership immediately. Only owners can add users. # Leave Organization Source: https://docs.onefirewall.com/closedvpn/endpoint/members/leave-org POST /auth/leave-org Allows a user to leave an organization. Cannot leave if the user is the last owner. # Remove Member Source: https://docs.onefirewall.com/closedvpn/endpoint/members/remove-user POST /auth/remove-user Removes a user from an organization. Only owners can remove users, and they cannot remove themselves or the last owner. # Update Member Role Source: https://docs.onefirewall.com/closedvpn/endpoint/members/update-user-role POST /auth/update-user-role Updates the role of a user in an organization. Only owners can update roles, and users cannot update their own role. # Count Notifications Source: https://docs.onefirewall.com/closedvpn/endpoint/notifications/count-notifications GET /auth/count-notifications Returns the number of unread notifications for the authenticated user. # List Notifications Source: https://docs.onefirewall.com/closedvpn/endpoint/notifications/get-notifications GET /auth/get-notifications Retrieves the list of unread notifications for the authenticated user, sorted by timestamp descending. # Mark All Notifications Read Source: https://docs.onefirewall.com/closedvpn/endpoint/notifications/mark-all-notifications-read POST /auth/mark-all-notifications-read Marks all unread notifications as read for the authenticated user. # Mark Notification Read Source: https://docs.onefirewall.com/closedvpn/endpoint/notifications/mark-notification-read POST /auth/mark-notification-read Marks a specific notification as read for the authenticated user. # Create Organization Source: https://docs.onefirewall.com/closedvpn/endpoint/organizations/create-org POST /auth/create-org Creates a new organization for the authenticated user, setting them as the owner and assigning the given VPN configuration to it. # Delete Organization Source: https://docs.onefirewall.com/closedvpn/endpoint/organizations/delete-org POST /auth/delete-org Marks an organization as inactive. Only owners can delete, and users must have at least one active organization remaining. # Get Organization Source: https://docs.onefirewall.com/closedvpn/endpoint/organizations/get-org GET /auth/get-org/{org_id} Retrieves details of a specific organization by ID if the user is a member. # List Organizations Source: https://docs.onefirewall.com/closedvpn/endpoint/organizations/get-orgs GET /auth/get-orgs Retrieves the list of active organizations the authenticated user is part of. # Select Organization Source: https://docs.onefirewall.com/closedvpn/endpoint/organizations/select-org POST /auth/select-org Selects an organization for the user to work with, updating their selectedOrg field. # Update Organization Source: https://docs.onefirewall.com/closedvpn/endpoint/organizations/update-org POST /auth/update-org Updates the details of an existing organization. Only owners can update the organization. # Revoke PAT Source: https://docs.onefirewall.com/closedvpn/endpoint/personal-access-tokens/delete-pat POST /auth/delete-pat Marks a PAT as inactive using its hashed token value (as returned from `/auth/get-pats`). # Generate PAT Source: https://docs.onefirewall.com/closedvpn/endpoint/personal-access-tokens/generate-pat POST /auth/generate-pat Creates a PAT for the authenticated user, returning the raw token only once. The client must store it securely. # List PATs Source: https://docs.onefirewall.com/closedvpn/endpoint/personal-access-tokens/get-pats GET /auth/get-pats Returns a list of active PATs for the authenticated user, automatically deactivating expired ones. # Update Profile Source: https://docs.onefirewall.com/closedvpn/endpoint/profile/update-profile PUT /auth/settings-profile Updates the user's profile and syncs the new display name across every organization they belong to. The display name is composed from `givenName` and `surname`; there is no `name` field in the request. Omitted optional fields are reset to their empty value rather than left unchanged, so send the complete profile on every call. # Threat Prevention Stats Source: https://docs.onefirewall.com/closedvpn/endpoint/statistics/threat-prevention-stats GET /auth/threat-prevention-stats Returns threat prevention dashboard data including total connections, threats blocked, risk score, latest events, and geographic breakdown. Uses the selected organization or org_id query parameter. # VPN Traffic Report Source: https://docs.onefirewall.com/closedvpn/endpoint/statistics/vpn-report-stats GET /auth/vpn-report-stats Returns detailed VPN traffic statistics including daily download/upload data, online user count and per-user usage breakdown for all the user's organizations. # VPN User Stats Source: https://docs.onefirewall.com/closedvpn/endpoint/statistics/vpn-user-stats GET /auth/vpn-user-stats Returns real-time VPN connection statistics for the authenticated user in a specific organization, including connection status, IP addresses and traffic data. # Create VPN Configuration Source: https://docs.onefirewall.com/closedvpn/endpoint/vpn-configurations/create-vpn-config POST /auth/create-vpn-config Creates a new VPN server configuration. Generates an SSH key pair automatically. Requires the user to have at least one existing configuration access. # Delete VPN Configuration Source: https://docs.onefirewall.com/closedvpn/endpoint/vpn-configurations/delete-vpn-config DELETE /auth/delete-vpn-config/{id} Marks a VPN configuration as inactive (soft delete). # Execute VPN Command Source: https://docs.onefirewall.com/closedvpn/endpoint/vpn-configurations/execute-vpn-command POST /auth/execute-vpn-command/{id} Executes a named command (defined in the VPN configuration) on the remote VPN server via SSH. # Get VPN Configuration Source: https://docs.onefirewall.com/closedvpn/endpoint/vpn-configurations/get-vpn-config GET /auth/vpn-config/{id} Returns details of a specific active VPN configuration by ID. # List VPN Configurations Source: https://docs.onefirewall.com/closedvpn/endpoint/vpn-configurations/list-vpn-configs GET /auth/vpn-configs Returns a list of active VPN configurations the authenticated user has access to. # Update VPN Configuration Source: https://docs.onefirewall.com/closedvpn/endpoint/vpn-configurations/update-vpn-config PUT /auth/update-vpn-config/{id} Updates the name and/or config of an existing active VPN configuration. Supplying `config` replaces the entire document, so send the complete object including `access`, `commands` and `private`. # List All VPNs Source: https://docs.onefirewall.com/closedvpn/endpoint/vpn-exit-nodes/list-vpns GET /auth/vpns Returns a simplified list of all active VPN configurations (ID and name only). # List Exit Nodes Source: https://docs.onefirewall.com/closedvpn/endpoint/vpn-exit-nodes/vpn-exit-nodes GET /auth/vpn-exit-nodes Returns a list of VPN exit nodes assigned to the user's currently selected organization. # Introduction Source: https://docs.onefirewall.com/closedvpn/introduction Manage organizations, members, VPN configurations and certificates over HTTP. **ClosedVPN** is a secure, enterprise-grade VPN built by [OneFirewall](https://onefirewall.com) for hybrid and remote teams. It combines fast private access with AI-powered threat prevention across Windows, macOS, iOS and Android. The ClosedVPN API gives you full programmatic control — provision VPN certificates, manage organizations and members, monitor live connection stats, and automate access workflows from your own scripts, CI pipelines or integrations. ## Base URL All endpoints are served from a single host and prefixed with `/auth`. ``` https://closedvpn.io ``` ## Authentication Every endpoint except `/auth/send-magic-link`, `/auth/verify-magic-link` and `/auth/logout` requires a **Personal Access Token (PAT)** in the `Authorization` header. ``` Authorization: Bearer YOUR_PAT_HERE ``` You can create a token from the **Profile** page in the [ClosedVPN web application](https://closedvpn.io), or programmatically with [`POST /auth/generate-pat`](/closedvpn/endpoint/personal-access-tokens/generate-pat). The plaintext token is returned **once** and stored only as a bcrypt hash — it cannot be recovered later. Save the token the moment you create it. If you lose it, revoke it and issue a new one — there is no way to read it back. For the full sign-in flow, token lifecycle and role-based access rules, see the [Authorization](/closedvpn/authorization) guide. ## Your first request Confirm your token works by validating it. This returns the authenticated user and their currently selected organization. ```bash theme={null} curl https://closedvpn.io/auth/validate-token \ -H "Authorization: Bearer YOUR_PAT_HERE" ``` ```json theme={null} { "success": true, "user": { "userId": "60c72b2f5f1b2c001c8e4b1b", "name": "John Doe", "email": "john@example.com", "avatar": "JD", "selectedOrg": "60c72b2f5f1b2c001c8e4b1a" } } ``` ## Organization context Most resources belong to an organization. Endpoints that operate on one either take an explicit `org_id` query parameter, or fall back to the caller's **selected organization**. Retrieve your organizations with [`GET /auth/get-orgs`](/closedvpn/endpoint/organizations/get-orgs), then set the active one with [`POST /auth/select-org`](/closedvpn/endpoint/organizations/select-org). Endpoints like `GET /auth/vpn-exit-nodes` and `GET /auth/threat-prevention-stats` depend on that selection. ## Conventions Every timestamp is a Unix epoch value in **milliseconds**, returned as a number rather than an ISO-8601 string. For example `1735689600000`. Resource identifiers are MongoDB ObjectIds, returned as 24-character hexadecimal strings such as `60c72b2f5f1b2c001c8e4b1a`. Errors return a JSON body with a `message` field describing the failure. A request with **no** credential returns `401`. A credential that is present but invalid, expired or inactive returns `403`. ## Endpoints Magic link sign-in, session validation and sign-out. Create, list and revoke the tokens used for API access. Create, update, select and delete organizations. Add members, change roles and remove access. Issue and download OpenVPN client profiles. Manage VPN servers and run their predefined commands. List the exit nodes available to your organization. Connection status, traffic reporting and threat prevention. Read in-app notifications and mark them as read. Retrieve recent activity for your account. The VPN capability previously delivered through the OneFirewall Application at `https://app.onefirewall.com/api/v1/vpn` now runs on ClosedVPN and is served from `https://closedvpn.io`. The legacy OneFirewall VPN endpoints are deprecated and are replaced by the operations documented in this tab. # Threat Intelligence Sources Source: https://docs.onefirewall.com/essentials/ThreatIntelligence How OneFirewall evaluates, scores, and maintains the threat intelligence sources feeding its blocklists. ## Source evaluation New sources are evaluated on: * **Credibility** of the maintaining organization or individual. * **Update frequency** — checked via documentation, GitHub commit logs, or direct monitoring. Sources marked "active" with stale updates are flagged for review. * **Data type** — IPs, domains, URLs, or file hashes. Sources are cross-referenced against the existing database to avoid redundancy, and against other trusted feeds to validate consistency: higher overlap with trusted feeds increases confidence in a new source. ## Confidence scores Confidence scores range from 0.1 to 0.9. Most newly added sources start around 0.2 until their track record justifies a higher score; scores are recalibrated against existing data as needed. ## Thresholds Each source has a per-update threshold set slightly above its typical upload volume. For example, a source that consistently reports around 800 entries gets a threshold of 1000. When a source exceeds its threshold, the newest entries are retained and older ones are dropped, so updates reflect the latest data. ## Recent changes About 40 sources were added. Database growth by risk category: | Risk level | Growth | | ---------- | ------ | | Low | +17% | | Medium | +61% | | High | +46% | | Critical | +168% | One notable addition, **Anti Attacks**, has contributed over 1.5 million unique IPs since being added. Existing sources were also reviewed: confidence values were raised for sources with validated consistency, thresholds were applied across all sources, and some previously dormant sources were reactivated after confirming compatibility with current parsing logic. ## Format support Parsing logic was added for: * **Compressed feeds** — `.zip` and `.gz` archives are unpacked and processed automatically. * **Domain feeds** — a dedicated parser extracts and validates domain-based blocklists, cross-referenced with IP feeds to identify overlaps. * **File/hash feeds** — a parser handles malicious file hashes (SHA256, MD5) and filenames from `.json` and `.txt` sources, cross-referenced with IP and domain feeds. These additions extend coverage beyond IPv4 to domains and file-based indicators. # Benchmark Source: https://docs.onefirewall.com/essentials/benchmark OneFirewall is a real-time threat intelligence layer that sits in front of your existing firewall — Palo Alto, Check Point, Juniper, or others — and pushes live, crowd-sourced attack data into its enforcement engine. This page compares threat intelligence capabilities across these vendors and what layering OneFirewall on top adds. *** ## The fundamental difference Firewall vendors build their own enforcement engines, and their threat intelligence is limited to what their own customer telemetry and research labs observe. OneFirewall works differently: it draws on collective intelligence from 210+ global security centres, validates it in real time, and pushes it to your existing infrastructure. | | OneFirewall | Palo Alto Networks | Check Point | Juniper Networks | | --------------------------- | -------------------------------------- | --------------------------------- | --------------------------------- | -------------------------------------- | | **Primary function** | Dedicated threat intelligence platform | Firewall + bundled TI | Firewall + bundled TI | Firewall + bundled TI | | **TI product** | World Crime Feeds (WCF) | WildFire / AutoFocus | ThreatCloud AI | SecIntel / ATP Cloud | | **Intelligence model** | Crowd-sourced Alliance (210+ members) | Vendor telemetry (85K+ customers) | Vendor telemetry (150K+ networks) | Vendor telemetry (Juniper Threat Labs) | | **CTA membership** | Full member | Full member | Full member | Not a member | | **Works with any firewall** | Yes, vendor-agnostic | No, Palo Alto only | No, Check Point only | No, Juniper only | | **Deployment model** | On-prem, cloud, hybrid | Cloud (SaaS) | Cloud (SaaS) | Cloud (SaaS) | *** ## Benchmark metrics ### Intelligence sourcing and coverage | Metric | OneFirewall | Palo Alto | Check Point | Juniper | | ----------------------------- | -------------------------------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------- | | **Intelligence sources** | 210+ Alliance members + CTA + government agencies + security vendors | WildFire subscriber network + Unit 42 research | 150K connected networks + CP Research + external feeds | Juniper Threat Labs + ATP Cloud + third-party feeds | | **IoC types covered** | IPs, domains, URLs, file hashes | Files, IPs, URLs, DNS | IPs, domains, URLs, files | IPs, domains, C\&C, GeoIP | | **STIX 2.1 native** | Yes | Partial | Partial | No | | **MITRE ATT\&CK mapping** | Per-indicator | Via Cortex XSOAR | Via ThreatCloud Graph | Limited | | **Crime score / risk rating** | 0–1000 granular score | Binary (malicious/benign) | Confidence levels | Binary (block/allow) | ### Enforcement speed | Metric | OneFirewall | Palo Alto | Check Point | Juniper | | --------------------------- | ----------------------------------------------------------------------------- | --------------------------------------- | --------------------------------- | -------------------------------------- | | **Time to block (new IoC)** | Under 30 seconds from first report across the Alliance | Minutes (WildFire cloud analysis cycle) | Near real-time (ThreatCloud push) | Near real-time (SecIntel feed refresh) | | **Feed refresh interval** | Continuous (5-minute EDL cycles for Check Point; real-time for the WCF Agent) | Periodic (WildFire signature updates) | Continuous (ThreatCloud push) | Periodic (ATP Cloud sync) | | **Automated enforcement** | Yes, no analyst required | Yes, within ecosystem | Yes, within ecosystem | Yes, within ecosystem | ### Integration | Capability | OneFirewall | Palo Alto | Check Point | Juniper | | ------------------------------- | ------------------------- | ----------------------- | ------------------------- | --------------------- | | **Check Point integration** | Native (SmartConsole EDL) | No | Built-in | No | | **Palo Alto integration** | Native (EDL / MineMeld) | Built-in | No | No | | **Fortinet integration** | Native (WCF Agent) | No | No | No | | **Juniper integration** | Native (custom feed) | No | No | Built-in | | **AWS WAF** | Yes | No | No | No | | **GCP Cloud Armor** | Yes | No | No | No | | **Cisco / Sophos / Forcepoint** | Yes | No | No | No | | **API access** | RESTful + STIX 2.1 | AutoFocus API | ThreatCloud API | ATP Cloud API | | **Total supported platforms** | 16+ | 1 (Palo Alto ecosystem) | 1 (Check Point ecosystem) | 1 (Juniper ecosystem) | *** ## What each vendor provides ### Palo Alto Networks (WildFire + AutoFocus) WildFire analyzes files in a cloud sandbox and pushes signatures to Palo Alto firewalls. AutoFocus provides a searchable repository of threat indicators drawn from WildFire telemetry and Unit 42 research. The intelligence is locked to the Palo Alto ecosystem: it cannot enrich a non-Palo Alto firewall. ### Check Point (ThreatCloud AI) ThreatCloud AI aggregates telemetry from 150,000+ connected networks and uses over 50 AI-powered engines to process indicators, with a strength in graph-based analysis of relationships between domains, IPs, and URLs. Like WildFire, this intelligence only feeds Check Point products. ### Juniper Networks (SecIntel) SecIntel delivers curated feeds from Juniper Threat Labs and ATP Cloud to SRX firewalls and MX routers, covering C\&C, GeoIP, attacker IPs, and infected-host indicators. It extends enforcement to routing infrastructure but is limited to Juniper hardware, and Juniper is not a CTA member. ### OneFirewall (World Crime Feeds) OneFirewall connects 210+ global security centres into one network. When a member detects an attack, the indicator is validated, scored with a Crime Score (0–1000), mapped to MITRE ATT\&CK, and pushed to every connected firewall in under 30 seconds, regardless of vendor. *** ## Running OneFirewall alongside a firewall vendor OneFirewall runs on top of an existing firewall rather than replacing it. | Scenario | Firewall alone | Firewall + OneFirewall | | --------------------------------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------- | | New ransomware staging IP detected in Brazil | Blocked only if your vendor's research lab has seen it | Blocked within 30 seconds across all Alliance members | | Zero-day C\&C domain registered 2 hours ago | Depends on vendor's feed update cycle | Collective detection triggers an immediate block | | Multi-vendor environment (e.g. Palo Alto perimeter + Fortinet branch) | Each vendor operates in its own intelligence silo | A single intelligence feed enriches both | | Compliance audit (NIS2, DORA, ISO 27001) | Vendor-specific logs | Unified enforcement log with timestamp, source, Crime Score, and confidence | *** ## Deployment ``` ┌─────────────────────────────────────────────────┐ │ OneFirewall Alliance │ │ 210+ Global Security Centres │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Member A │ │ Member B │ │ Member C │ ... │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────────────────────────────────┐ │ │ │ World Crime Feeds (WCF) Engine │ │ │ │ Validation · Crime Score · ATT&CK │ │ │ └──────────────┬───────────────────────┘ │ └──────────────────┼──────────────────────────────┘ │ ┌──────────┼──────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Palo Alto │ │Check Point│ │ Fortinet │ ... + 13 more │ NGFW │ │ Quantum │ │FortiGate │ └──────────┘ └──────────┘ └──────────┘ Your existing infrastructure stays in place ``` *** ## FAQ ### We already have Palo Alto WildFire — why add OneFirewall? WildFire analyzes files within the Palo Alto ecosystem. OneFirewall adds crowd-sourced IP/domain/URL intelligence from 210+ organizations outside the Palo Alto customer base, validated in real time and pushed directly to your firewall. ### Doesn't Check Point ThreatCloud already aggregate external feeds? ThreatCloud aggregates feeds from Check Point Research and selected external sources. OneFirewall's intelligence comes from live, reciprocal sharing between 210+ security centres across industries and geographies, with each member both contributing and consuming. ### Is this a rip-and-replace? No. OneFirewall sits on top of your existing firewall. The WCF Agent integrates with your current infrastructure — no hardware changes, no policy migration. ### What about data sovereignty? OneFirewall shares only anonymized threat indicators. Logs, user data, and internal traffic stay on-premises. *** Ready to test OneFirewall on your existing infrastructure? [Start a Proof of Value](/contact). # Configurations Source: https://docs.onefirewall.com/essentials/configurations The OneFirewall platform has two configurable components. Both are configured through an editable JSON block in the web console. # Organization Level Admins can go to the Organizations section, where all registered organizations are listed. Clicking Edit on an organization opens a configuration panel with settings such as allowed token usage and trust level. The Configuration Settings section within this panel is an editable JSON block. #### Example ```JSON theme={null} { "live": { "index_name": "poc_traffic", "score_name": "score", "elastic_url": "default", "action_name": "action", "date_time_name": "@timestamp", "allow_value": [ "Allow", "pass" ], "deny_value": [ "Deny", "decline" ], "low_score": [ 1, 60 ], "medium_score": [ 60, 120 ], "high_score": [ 120, 150 ], "critical_score": [ 150, 1000 ], "device_name": [ "firewall" ], "direction_name": [ "direction" ], "service_name": [ "service" ] }, "reserved_ips": [ "1.1.1.1", "62.49.0.0/16", "125.209.84.250", "1.4.6.7", "6.7.8.9" ], "blocking_roule": { "score": 20, "tags": [ "tor_exit_nodeXXX" ] } } ``` ### Explanation of the keys | Key | Description | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | live | Settings for how the `LIVE` page parses data for the final report | | live.index\_name | The ELK index where the data is saved. Default `poc_traffic` | | live.score\_name | The field name for the OFA Crime Score. Default `score` | | live.elastic\_url | The ElasticSearch URL, if not the default. Default `default` | | live.action\_name | The field name for Allow/Deny traffic status. Default `action` | | live.date\_time\_name | The field name for the timestamp. Default `@timestamp` | | live.allow\_value | Array of strings marking traffic as accepted/allowed by the customer's firewall. Default `["Allow"]` | | live.deny\_value | Array of strings marking traffic as blocked by the customer's firewall. Default `["Deny"]` | | live.low\_score | Two-element array with the min/max value for `LOW` score. Default `[1, 60]` | | live.medium\_score | Two-element array with the min/max value for `MEDIUM` score. Default `[60, 120]` | | live.high\_score | Two-element array with the min/max value for `HIGH` score. Default `[120, 150]` | | live.critical\_score | Two-element array with the min/max value for `CRITICAL` score. Default `[150, 1000]` | | live.device\_name | Array of strings representing the Device field in the parsed data. Default `["firewall"]` | | live.direction\_name | Array of strings representing the Direction field in the parsed data. Default `["direction"]` | | live.service\_name | Array of strings representing the Service field in the parsed data. Default `["service"]` | | reserved\_ips | IPs (CIDR format) used by the organization that are excluded from being reported as malicious. Functions as a whitelist scoped to the organization. See [Release notes](/releases/2025-05-22#2-custom-reserved-ips) | | blocking\_roule | Additional blocking rules based on tags and score. See [Release notes](/releases/2025-05-22#4-tag-based-prevention-rules) | | blocking\_roule.score | Minimum score for blocking. Combined with tags using `AND` | | blocking\_roule.tags | Tags (matched with `OR`) the IP must have before blocking; combined with `blocking_roule.score` using `AND` | # WCF Agent Level Each installed WCF Agent has configurable settings that are centrally managed by the server. To view or modify them, go to the Agent Status section and click Edit on the listed agent to open its JSON configuration panel. #### Example ```JSON theme={null} { "gaid": "OFA-AGENT-ID-D6NmSW62hUZW", "score_threshold": 150, "version": "v4.60.4", "proxy": "CLOUD", "sync_time": 1, "maximum_rules": 99999998, "ids": { "iptables": { "active": false }, "ebtables": { "active": false }, "pflist": { "active": false }, "modsec": { "active": false, "modsec_logs": "/var/log/apache2/modsec_audit.log" }, "cloudflare": { "active": false, "cloudflare_x_auth_email": "", "cloudflare_x_auth_key": "" }, "luna": { "active": false, "json": [] }, "sshlog": { "active": false, "ssh_log_location": "/var/log/auth.log" } }, "ips": { "httpd": { "active": true, "command": "cp blacklist_onefirewall.txt httpd/blacklist.txt" }, "iptables": { "active": true, "acl": "/opt/onefirewall/acl/ipset.txt", "reload_command": "sudo ipset flush blacklist && sudo ipset restore < /opt/onefirewall/acl/ipset.txt " }, "checkpoint": { "active": false, "username": "admin", "password": "", "address": "https://10.47.2.48", "group": "OneFirewall_IPS", "policy": "standard", "domain": "Test_domain_Server", "gateways": "Test_gw" }, "checkpoint_securexl": { "active": false, "connections": "ofa@192.168.1.40", "password": "************", "command": "bash artifacts/checkpoint/install-securexl.sh", "vsids": "1,2" }, "fortigate": { "active": false, "connections": "ofa@192.168.1.40", "password": "************", "command": "bash artifacts/fortigate/install-fortigate-url-feed.sh", "feeds": "/api/v1/feeds", "updates": "5" }, "csp": { "active": false, "connections": "ofa@192.168.1.40", "password": "************", "command": "bash artifacts/csp.sh", "feeds": "onefirewall.txt", "updates": "5" }, "ebtables": { "active": false }, "pflist": { "active": false, "ofa_ips_txt": "/opt/apps/onefirewall-cloud-client/ofa-ips.txt", "pflist_reload_command": "sudo pfctl -f /etc/pf.conf;" }, "modsec": { "active": false, "ruleset": "/usr/share/modsecurity-crs/rules/onefirewall_rules.conf", "modsec_reload_command": "sudo apachectl -k graceful;" }, "cloudflare": { "active": false, "cloudflare_x_auth_email": "", "cloudflare_x_auth_key": "" }, "cisco": { "active": false, "cisco_host": "", "cisco_user": "", "cisco_password": "" }, "haproxy": { "active": false, "haproxy_logs": "/opt/onefirewall/acl/haproxy.txt", "haproxy_reload_command": "sudo service haproxy reload" }, "csv": { "active": false, "csv_logs": "/opt/onefirewall/feeds.csv", "csv_reload_command": "wc /opt/onefirewall/feeds.csv" }, "aws": { "active": false, "accessKeyId": "", "secretAccessKey": "", "region": "" }, "sophos": { "active": false, "user": "", "password": "", "address": "", "command": "bash artifacts/sophos/update_blacklist_sophos.sh" }, "trellix": { "active": false, "username": "", "password": "", "api": "", "fileslist_file": "", "broker_ca_bundle": "", "cert_file": "", "private_key": "" }, "infoblox": { "active": false, "username": "", "password": "", "api": "", "group": "", "policy": "", "action": "", "view": "", "domains_file": "", "domains_file_whitelist": "", "api_whitelist_url": "" }, "forcepoint": { "active": false, "username": "", "password": "", "api": "", "group": "", "policy": "", "action": "", "parent": null, "urls_file": "" } }, "running": "yes" } ``` ### Explanation of the keys | Key | Description | | ---------------- | --------------------------------------------------------------------------------------- | | gaid | Unique agent ID, generated during Agent install | | score\_threshold | Minimum score for the Agent to instruct the IPS/firewall to block traffic | | version | Installed Agent version, used for troubleshooting | | sync\_time | How often the Agent must communicate with the server to be considered alive, in minutes | | maximum\_rules | Maximum rules to block, for firewalls that can't handle more than X rules | | running | Whether the Agent is active. Values `yes` or `no`. Default `yes` | | ids | Intrusion Detection systems the Agent reads data from | | ids.active | Whether the specific IDS integration is in use | | ids.\[\*] | Integration-specific settings; see the Install Agent page for details | | ips | Intrusion Prevention systems (firewalls) the Agent injects/blocks traffic on | | ips.active | Whether the specific IPS integration is in use | | ips.\[\*] | Integration-specific settings; see the Install Agent page for details | # Alliance Contribution Source: https://docs.onefirewall.com/essentials/contribution Contributions are anonymized, weighted, and combined into a shared intelligence pool that strengthens proactive threat prevention **OneFirewall Alliance** extracts IoC (Indicator of Compromise) data from alliance members, anonymizes and weights it, and aggregates it into a shared object used by all members for prevention. OneFirewall rewards alliance members who contribute new IoCs (IPv4, domains, files, URLs) or confirm that existing IoCs are malicious. OneFirewall also gathers data from security partners, open-source repositories, and internal security teams. The breakdown: *** ## Threat Intel Source Contribution | Source | Contribution | Notes | | -------------------------- | ------------ | --------------------------------------------------------------------- | | Security Partners | ∼27% | Security Partners specialized in cyber-attack hunting | | Alliance Members | ∼43% | Customers of OneFirewall contributing to the Threat Intel data lake | | Open-Source Data | ∼21% | Crafted and collected by the Security Engineering team of OneFirewall | | Internal Security Research | ∼6% | OneFirewall’s research team, monitoring and reporting | | Machine Learning | ∼0.1% | Pattern extraction for forecasting threat actors | | OneFirewall Honey-net | ∼2% | Honeypot network collecting attack threat intel | *** ## Member Participation An alliance member of OneFirewall can choose between two modes: * **Consumer-only**\ Regardless of on-prem or cloud installation, the member only consumes (reads) the latest threat intelligence. * **Consumer-and-contributor**\ The member can also report threat intelligence information back to the alliance, enhancing other members’ awareness of the latest threats. *** ## Contributor A **Contributor** is a member that reports IoCs — IPv4 addresses, domains, URLs, or file digests — back to the OneFirewall SaaS service, based on the organization's internal intelligence from events flagged as malicious through automated or manual processes. *** ## Outbound Data Sharing In Contributor mode, members send data back to the OneFirewall SaaS Cloud service. Contributing members share at least the following information (in JSON format): * **Actor**: IPv4, URL, FileDigest, or domain name * **Timestamp**: Date and time of the report * **Confidence**: A numeric value (0.0 to 1.0) representing confidence in the actor’s maliciousness * **Source (Optional)**: Appliance/Process used (e.g., `manual`, `Appliance-X`) * **Event ID (Optional)**: Internal unique event ID * **STIX (Optional)**: STIX v2.0 format bundle of the cyber attack * **tags (Optional)**: Tags separated by "," example `report-00000` In addition, contributors must authenticate against OneFirewall SaaS, which identifies the Member Organization (via random ID). This ID is used for subsequent calculations to either add a new feed or update an existing feed with enhanced confidence. The information is submitted via the **OneFirewall public HTTPS/API endpoint**, which updates the **Cyber Crime Score** based on combined intelligence from other sources. ## Example of Data ```json theme={null} [ { "ip": "8.8.8.8", "timestamp": 1759158848, "confidence": 0.5, "tags": "report_00000" } ] ``` ### Current Data Collection Plugins 1. Manual replication of submitted events (UI on-prem instance) 2. SIEM connector with ELK (Logstash config, case by case) 3. Apache and NGINX ModSecurity 4. SSH Logs > Being a contributing member implies OneFirewall can acknowledge the customer as an active contributor. No other information is shared or disclosed without explicit reference to this status. *** ## FAQs **Q: How is this information stored in the OneFirewall Data Lake?**\ A: The JSON information is stored with a randomly generated ID linked to the member, used only to generate anonymous data for updating the Cyber Crime Score. **Q: Do other OneFirewall members have access to what I submitted?**\ A: No. Other members only see the updated Crime Score. **Q: If I share information, can I later delete it?**\ A: Yes. At any point, a member can permanently delete (hard delete) their contributions. **Q: Is the handling of this information GDPR compliant?**\ A: Yes. The shared information contains no PII. **Q: Can I stop or pause my contributions?**\ A: Yes. Data collection/sharing is managed entirely on-premises, so you can pause or stop anytime. **Q: Can I choose which cyber events to contribute?**\ A: Currently, event-level selection is not supported, but a custom pattern can be applied upon request. **Q: How often is information contributed to the community?**\ A: Every 60 seconds (configurable). *** # OneFirewall Crime Score Source: https://docs.onefirewall.com/essentials/crime-score # OneFirewall Crime Score (OFA Score) The **OneFirewall Crime Score (OFA Score)** is a quantitative risk metric assigned to an asset (IPv4 address, domain, URL, or file hash) based on intelligence collected and validated within the OneFirewall Alliance ecosystem. The score ranges from **0 to 1000**, representing the probabilistic confidence and severity that an asset is malicious or has been involved in cybercriminal activity. Higher values indicate higher risk and stronger correlation with confirmed malicious behavior. *** ## Score Semantics **Score = 0**\ The asset has never been observed, submitted, or correlated within the OneFirewall Threat Intelligence ecosystem. **Score = 1**\ The asset has been observed at least once in relation to suspicious or malicious activity. **Score > 1**\ Represents progressive risk elevation derived from multi-factor correlation, validation, and scoring algorithms. *** ## Scoring Model – Contributing Factors The Crime Score is computed by a correlation engine that weighs multiple intelligence dimensions, factoring in submission timing and source trust. ### 1. Alliance Member Frequency Number of independent Alliance Members reporting the same asset in malicious contexts. Higher independent confirmations increase score non-linearly. *** ### 2. Source Trust Weight Each Alliance Member is assigned a dynamic **trust score** based on: * Historical submission accuracy * False positive rate * Validation consistency * Participation longevity * Correlation agreement with other members Submissions from higher-trust members carry greater influence in score computation. *** ### 3. Confidence Metadata Submissions may include a **confidence level** indicating the reporting entity’s internal validation depth. Examples: * Observed exploitation attempt * Confirmed compromise * Sinkhole validation * Sandbox execution * Heuristic suspicion Confidence metadata directly affects score weighting. *** ### 4. Temporal Oscillation (Time Decay Model) The Crime Score incorporates a time-based decay function. If no new malicious activity is observed, the score gradually decreases according to a proprietary decay algorithm designed to model: * Infrastructure churn * Botnet IP reassignment * Compromised host remediation * Natural IPv4 reallocation Currently, **only IPv4 indicators** are subject to time-based decay. Domains, URLs, and file hashes are not automatically decayed due to persistence characteristics. *** ### 5. Structured CTI Enrichment (STIX 2.x) If a submission includes structured CTI (e.g., STIX 2 objects), additional contextual enrichment increases scoring precision: * Associated threat actor * Malware family * Campaign reference * MITRE ATT\&CK mapping * Kill chain phase * Infrastructure pivot correlation Structured CTI improves confidence granularity and cross-asset correlation. *** ### 6. Cross-Member Temporal Correlation If multiple independent Alliance Members report the same asset within correlated time windows, the score increases significantly due to: * Distributed attack validation * Campaign propagation detection * Multi-tenant exposure confirmation This mechanism reduces false positives and strengthens consensus-based elevation. *** ## Dynamic Score Behavior The Crime Score is dynamic. It may: * **Increase** with new validated submissions * **Increase** through correlation enrichment * **Decrease** via negative submissions (false-positive correction) * **Decrease** through time-based decay (IPv4 only) This ensures the score reflects current threat posture rather than historical bias. *** ## Operational Usage – Enforcement Thresholds Using the Crime Score for automated perimeter enforcement requires selecting a blocking threshold aligned with organizational risk tolerance. OneFirewall does not enforce a fixed threshold, but operational guidance based on Alliance usage patterns is as follows. ### Recommended Calibration Process 1. Start enforcement at **Score ≥ 400** 2. Reduce threshold by **50 points per week** 3. During each phase, review: * Inbound blocked traffic * Outbound blocked traffic * False positives * Business impact 4. Continue reduction until operational equilibrium is reached. *** ## Alliance-Validated Enforcement Baseline Across the majority of Alliance Members, a threshold of: > **Score ≥ 190** has demonstrated an effective balance between prevention efficiency and low false-positive impact. This value is derived from empirical operational validation across multi-sector deployments. *** ## Practical Use Instead of manually evaluating raw IoCs, security controls can: * Consume numeric risk thresholds * Automate firewall and IPS decisions * Apply dynamic blocking policies * Adjust risk appetite programmatically # Elasticsearch settings for PoV Source: https://docs.onefirewall.com/essentials/elasticindex ## Elasticsearch index configuration To set up the PoV elasticsearch index, apply an Index Lifecycle Management (ILM) policy with rollover and automated deletion. This gives several benefits: 1. Automatic data growth management * With rollover (max\_age: 1d or max\_size: 50gb), you don’t need to manually monitor index size or age. * As soon as an index reaches the threshold, Elasticsearch creates a new one (poc\_traffic-000002, etc.) and automatically updates the alias poc\_traffic. 2. Better query and update performance * Oversized indices slow down searches and updates. * By splitting them regularly, shards remain smaller, keeping queries, aggregations, and writes efficient. 3. Automatic cleanup of old data * The delete phase (min\_age: 34d) removes indices older than 34 days. * No need for external jobs (cron, scripts) to enforce data retention → lower risk of wasting disk space. 4. Resource usage optimization * number\_of\_shards: 1 and number\_of\_replicas: 0 reduce overhead when high availability is not required. * index.translog.flush\_threshold\_size: 512mb and refresh\_interval: 30s optimize ingestion performance compared to immediate search. * Prevents the cluster from being overloaded with either too many small shards or oversized ones. 5. Easier management with index templates * With an index template (poc\_traffic\_template), each new rollover index automatically inherits the same settings. * No need to reapply configurations like refresh\_interval or max\_result\_window manually. 6. Elasticity and scalability * Ideal for time-series data (like logs or traffic data) that continuously grows. * The combination of alias + rollover + ILM is the recommended Elastic pattern for scalable data management. ```bash theme={null} curl -XPUT "http://localhost:9200/_ilm/policy/poc_traffic_policy" -H "kbn-xsrf: reporting" -H "Content-Type: application/json" -d' { "policy": { "phases": { "hot": { "actions": { "rollover": { "max_age": "1d", "max_size": "50gb" } } }, "delete": { "min_age": "34d", "actions": { "delete": {} } } } } }' ``` ```bash theme={null} curl -XPUT "http://localhost:9200/poc_traffic-000001" -H "kbn-xsrf: reporting" -H "Content-Type: application/json" -d' { "aliases": { "poc_traffic": { "is_write_index": true } }, "settings": { "number_of_shards": 1, "number_of_replicas": 0, "refresh_interval": "30s", "index.lifecycle.name": "poc_traffic_policy", "index.lifecycle.rollover_alias": "poc_traffic", "index.translog.flush_threshold_size": "512mb", "max_result_window": 100000 } }' ``` ```bash theme={null} curl -XPUT "http://localhost:9200/_index_template/poc_traffic_template" -H "kbn-xsrf: reporting" -H "Content-Type: application/json" -d' { "index_patterns": ["poc_traffic-*"], "template": { "settings": { "number_of_shards": 1, "number_of_replicas": 0, "refresh_interval": "30s", "index.lifecycle.name": "poc_traffic_policy", "index.lifecycle.rollover_alias": "poc_traffic", "index.translog.flush_threshold_size": "512mb", "max_result_window": 100000 } }, "priority": 500 }' ``` # Integrations Source: https://docs.onefirewall.com/essentials/integrations # OneFirewall Integrations OneFirewall integrates with firewall and Intrusion Prevention System (IPS) solutions to block malicious traffic in real time. ## Supported Firewall and IPS Solutions The OneFirewall World Crime Feeds (WCF) Agent integrates with the following firewall and IPS solutions: * **Checkpoint and Checkpoint SecureXL** * **Fortigate (Fortinet)** * **CISCO IOS** * **GCP CloudArmor** * **Windows Defender** * **Cloudflare** * **PFsense OS** * **AWS CloudFront** * **Apache ModSecurity** * **Sophos** * **SonicWall** * **Forcepoint** * **Palo Alto** * **Q Radar (IBM)** * **ElasticSearch** * **HAProxy** * **AWS WAF** * **Trelix** * **InfoBlox** ## Key Benefits of Integration * **Real-time enforcement**: Integrated firewalls and IPS block identified threats automatically. * **Centralized management**: Security policies and incident response are managed from one place. * **Device-based pricing**: Pricing is based on the number of network devices, not traffic volume. # Threat Intelligence Source: https://docs.onefirewall.com/essentials/intelligence # OneFirewall Intelligence [Visit the OneFirewall Intelligence Page](https://onefirewall.com/intelligence.html) OneFirewall provides threat intelligence feeds built from data shared across the OneFirewall Alliance. ## Threat Intelligence Feeds OneFirewall provides several Indicator of Attack (IoA) feeds: * **IPv4**: Malicious IP addresses identified through suspicious traffic patterns, known malware sources, and blacklists. * **Files**: File hash analysis (MD5, SHA1, SHA-256) to detect malicious files. * **URLs**: Web addresses flagged for malicious activity using reputation scores and behavioral patterns. * **Domains**: Fully qualified domain names (FQDNs) identified as malicious through pattern analysis, historical data, and reputation scoring. ## Threat Intelligence Sources The OneFirewall World Crime Feeds (WCF) Platform aggregates threat intelligence from multiple sources: * **Cyber Threat Alliance**: Cybersecurity organizations sharing threat intelligence. * **OneEye Forecast**: OneFirewall's private honeynet, providing insights into emerging threats. * **Additional Sources**: Contributions from over 135 entities, including Checkpoint, Fortigate, AlienVault, Juniper Networks, SonicWall, and more. ### Source Breakdown OneFirewall's DataLake draws from over **135 unique sources**: 1. **Cyber Threat Alliance** (30+ member organizations) – 1 source 2. **DeceptionGrid** (OneFirewall’s Honeynet) – 1 source 3. **AI/ML-Based Inspection** (OneFirewall’s proprietary models) – 1 source 4. **OneFirewall Security Operations Center (SOC)** – 1 source 5. **Publicly Available Threat Feeds** – 49 sources 6. **Private Intelligence from Security Partners** – 7 sources 7. **Extended Alliance Members** (Active contributing customers) – 75 sources > **Note:** The number and distribution of feeds may vary over time based on real-time activity and partner contributions. ## Data Quality As a member of the Cyber Threat Alliance, OneFirewall validates submitted data and has access to threat intelligence shared by all CTA members. ## Impact of the OneFirewall Alliance Platform The OneFirewall Alliance Platform (WCF) shares threat intelligence in real time, pooling data from multiple sources. This enables: * Faster responses to attacks. * Broader perspectives on emerging threats. * Reduced security costs. # Logs and Network Events Source: https://docs.onefirewall.com/essentials/logs-events/logs-events ## Overview **OneFirewall Server WCF (World Crime Feeds)** is the core server component that can be installed **on-premises** or in the **cloud**, depending on your deployment setup. It is responsible for collecting and processing security logs from firewalls, intrusion prevention systems (IPS), and other network or security devices in your environment. *** ## Syslog Listener on UDP Port 514 The OneFirewall service includes a **Syslog listener** running on **UDP port 514**, which is the standard port for receiving syslog traffic. This listener can accept log messages from multiple sources and automatically parse them to extract relevant security information, such as: * Source and destination IPs * Timestamps * Severity levels * Event types or signatures *** ## Sending Logs to OneFirewall Depending on your existing infrastructure, there are several ways to forward logs to the OneFirewall Syslog listener. ### **ELK / OpenSearch** To forward logs using **Filebeat** or **Logstash**, edit the configuration file and include a Syslog output section: ```yaml theme={null} output.syslog: host: ["udp://:514"] protocol: udp facility: local0 ``` Then restart the service to apply changes: ```bash theme={null} sudo systemctl restart filebeat ``` or ```bash theme={null} sudo systemctl restart logstash ``` *** ### **IBM QRadar** 1. Go to **Admin → Data Sources → Log Sources**. 2. Add a new **Syslog** destination. 3. Set the **Destination IP** to your OneFirewall server. 4. Select **UDP** as the protocol and set **Port 514**. 5. Save and deploy the configuration. *** ### **Splunk** In Splunk, you can configure Syslog forwarding either via a **forwarder** or directly on the main server. #### Example configuration ``` [udp://514] connection_host = ip sourcetype = syslog ``` Ensure that your firewall allows **outbound UDP 514** traffic to the OneFirewall server. Restart the Splunk service after applying changes: ```bash theme={null} sudo systemctl restart splunk ``` *** ### **pfSense / OPNsense** 1. Navigate to **Status → System Logs → Settings → Remote Logging Options**. 2. Enable **Send log messages to remote syslog server**. 3. Enter the **OneFirewall Server IP** and set **Port** to `514`. 4. Select the log categories you want to forward (e.g., Firewall, DHCP, System). 5. Save the settings. *** ## API Log Ingestion (Cloud Environments) For **cloud-based deployments**, OneFirewall Server exposes an **HTTP API endpoint** that allows log ingestion via HTTPS. This method is typically used when UDP traffic is restricted or when integrating with cloud-native logging tools such as: * **AWS CloudWatch Logs** * **Azure Monitor** * **Google Cloud Logging** The API accepts structured JSON log payloads and supports authentication using API tokens. *** ## Verifying Log Connectivity You can verify if logs are successfully reaching the OneFirewall server using standard Linux tools. ### **Using `tcpdump`** ```bash theme={null} sudo tcpdump -i any port 514 -n ``` ### **Using `logger` (for testing)** ```bash theme={null} logger -n -P 514 -d "Test log message from client" ``` If configured correctly, the message will appear in the OneFirewall server logs. # S3 Log Processing Architecture Source: https://docs.onefirewall.com/essentials/logs-events/s3-log-processing Authentication methods and ingestion patterns for processing Amazon S3 logs ## Overview This document outlines the architectural patterns and security requirements for ingesting and processing log files stored in Amazon S3 via the **onefirewall** Virtual Machine. *** ## Prerequisites & Core Requirements Avoid static long-term credentials (IAM Access Keys) wherever possible in favor of short-lived tokens. Restrict permissions strictly to `s3:GetObject` and `s3:ListBucket` on the designated log prefixes. ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3LogReadAccess", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::your-log-bucket-name", "arn:aws:s3:::your-log-bucket-name/*" ] } ] } ``` *** ## Authentication Patterns The authentication model depends on whether the **onefirewall** VM is hosted natively inside AWS or in an external environment. ### IAM Instance Profiles If the VM is running inside AWS as an EC2 instance, **do not** use access keys. Attach an **IAM Role** directly to the VM instance profile. * **Mechanism:** AWS Instance Metadata Service (IMDSv2) automatically issues short-lived security credentials. * **Rotation:** Managed automatically by AWS without application downtime. * **Code Integration:** AWS SDKs pick up the role credentials transparently. ```bash theme={null} # Test access directly from the VM using the instance role aws s3 ls s3://your-log-bucket-name/ ``` ### 1. IAM Roles Anywhere (Recommended) Establishes trust between external servers and AWS IAM using PKI and X.509 digital certificates. * **Pros:** Issues short-lived credentials without storing AWS static keys on the VM. * **Requires:** An existing internal Certificate Authority (CA) or AWS Private CA. ### 2. Static IAM Access Keys (Fallback) If IAM Roles Anywhere cannot be implemented, use dedicated IAM User keys with strict guardrails: Static keys must never be hardcoded in application source code. Store them in secure secret stores like HashiCorp Vault or environment variables. * Mandate key rotation **every 90 days**. * Enforce IP-based explicit deny conditions in the IAM Policy. *** ## Ingestion Models **scheduled polling** based on latency requirements. ### 1. AWS OFA Log Adapter Scanning the bucket continuously to new incoming log files and processing with AWS OFA Log Adapter ```mermaid theme={null} graph LR A[S3 Log Creation] -->|s3:GetObject| B(AWS OFA Log Adapter) B -->|ofa traffic_api| C[OneFirewall Alliance OnPrem/Whitelabel] ``` # OneFirewall Coins Source: https://docs.onefirewall.com/essentials/ofa-coins ## TL;DR OFA Coins are the credit system for API access within the OneFirewall Alliance. Members need a sufficient Coin balance to make requests against OneFirewall's APIs. ## Overview Coins are acquired by purchasing them from OneFirewall or by earning them through participation in the OneFirewall Alliance community. Each user has a Coin balance tied to their member account. Each API service has a fixed Coin cost. The system checks the user's Coin balance before processing a request. If the balance covers the request cost, the system deducts the corresponding amount of Coins. If a user attempts to make a request but does not have enough Coins to cover the cost, the request is denied until they acquire more Coins. Members can monitor their Coin balance and transaction history in the web console, under the user profile page. Coin acquisition, pricing, and management details may change based on OneFirewall Alliance policy updates. ## OFA Coins Acquisition Coin allocation is determined by the license tier acquired by the user. Coins are provided upon acquiring a license and can be used to access the API Services. For Coin allocation details by license tier, contact the OneFirewall support team at [support@onefirewall.com](mailto:support@onefirewall.com). ## API Services and Costs Coin cost per API service varies based on data complexity and processing requirements. | API Service | OFA Coins Required | | --------------------------------------- | ------------------ | | IPv4 Feeds (FLAT) | 200 | | IPv4 Feeds (FLAT REAL TIME) | 45 | | IPv4 Feeds (REST) - single IP | 1 | | IPv4 Feeds (REST) - single IP by search | 2 | | IPv4 Feeds (REST) - Multiple IP | 12 | | STIX2 | 20 | | Malicious Files | 8 | | Malicious Files (Deep Scan) | 120 | | Domains | 32 | | Domains (Deep Scan) | 120 | ## Check the cost of each API call Each API response includes a header, `X-OFA-COST`, containing the number of Coins debited for that request. # OFA-DNS Servers Source: https://docs.onefirewall.com/essentials/ofa-dns Step-by-step guide to change DNS settings on the most common OS and Italian ISP routers. This guide explains how to change OneFirewall Alliance DNS settings on the most common **OS Windows, Linux, MAC iOS** and routers provided by **Fastweb**, **Vodafone**, **TIM**, and **WindTre**.\ Menu labels may vary slightly depending on your router model, but the workflow is similar across devices. **If your router cannot handle two or more DNS servers, please use only one OFA-DNS server and the Alternative as in the 3th DNS Server section** ## OFA DNS Servers | Provider | Primary DNS | Secondary DNS | | -------- | ----------- | ------------- | | OFA-DNS | `ofa-dns1` | `ofa-dns2` | Please contact [support@onefirewall.com](mailto:support@onefirewall.com) for get configuration values and to enable your ISP Provider ## 3th DNS Server to add at the configuration You can choose the one provided from you ISP Provider or one of the following existing DNS Providers | Provider | Primary DNS | Secondary DNS | | ---------- | ---------------- | ----------------- | | Google | `8.8.8.8` | `8.8.4.4` | | Cloudflare | `1.1.1.1` | `1.0.0.1` | | OpenDNS | `208.67.222.222` | `208.67.220.220` | | Quad9 | `9.9.9.9` | `149.112.112.112` | *** ## Windows (10 / 11) ### Using Settings 1. Open **Settings**. 2. Go to **Network & Internet**. 3. Select Wi-Fi or Ethernet. 4. Find **DNS server assignment** and click **Edit**. 5. Choose **Manual** and enable **IPv4**. 6. Enter your DNS servers. 7. Save. ### Using Control Panel 1. Open Control Panel. 2. Network and Sharing Center → Change adapter settings. 3. Right‑click interface → Properties. 4. Select **Internet Protocol Version 4 (TCP/IPv4)** → Properties. 5. Choose **Use the following DNS server addresses**. 6. Enter DNS values. 7. OK. ## Linux (Ubuntu / Debian / Fedora / etc.) ### Method 1 — NetworkManager (GUI) ### Steps 1. Open **System Settings** (or **System Preferences** on older versions). 2. Select **Network**. 3. Choose your active connection: * Wi-Fi * Ethernet 4. Click **Details…** (or **Advanced…**). 5. Open the **DNS** tab. 6. Click the **+** button and add your DNS servers. 7. Example: ``` ofa-dns1, ofa-dns2, 8.8.8.8 ``` ### Method 2 — Netplan (Ubuntu Server) Edit the file: ```bash theme={null} sudo nano /etc/netplan/*.yaml ``` Add: ```yaml theme={null} nameservers: addresses: [ofa-dns1, ofa-dns2, 8.8.8.8] ``` Apply: ```bash theme={null} sudo netplan apply ``` ### Method 3 — resolv.conf (manual) ```bash theme={null} sudo nano /etc/resolv.conf ``` Add: ```bash theme={null} nameserver ofa-dns1 nameserver ofa-dns2 nameserver 8.8.8.8 ``` ## macOS (Tahoe / Ventura / Monterey / Big Sur) ### Steps 1. Open **System Settings** (or **System Preferences** on older versions). 2. Select **Network**. 3. Choose your active connection: * Wi-Fi * Ethernet 4. Click **Details…** (or **Advanced…**). 5. Open the **DNS** tab. 6. Click the **+** button and add your DNS servers. 7. Example: ``` ofa-dns1 ofa-dns2 8.8.8.8 ``` *** ## Fastweb Routers :::warning Some Fastweb routers **do not allow DNS changes** on the WAN connection.\ If the DNS section is missing, configure DNS directly on your device or use your own router in cascade. ::: ### Steps 1. Open your browser and navigate to: * `http://192.168.1.254` * `http://192.168.1.1` 2. Log in using the credentials on the router label. 3. Go to **Advanced Settings → Internet → DNS**. 4. Disable **Automatic DNS**. 5. Enter your preferred DNS servers. ``` ofa-dns1 ofa-dns2 8.8.8.8 ``` 6. Save and restart the router. *** ## Vodafone Routers (Vodafone Station / Power Station) :::warning Many Vodafone Station models **lock DNS settings** on the primary connection.\ If DNS options do not appear, use device-level DNS or a third-party router. ::: ### Steps 1. Access the router via: * `http://192.168.1.1` * `http://vodafone.station` 2. Log in with the password printed on the router. 3. Navigate to **Settings → Internet → Advanced Settings → DNS**. 4. Disable **Automatic DNS**. 5. Add your custom DNS servers. ``` ofa-dns1 ofa-dns2 8.8.8.8 ``` 6. Save and reboot. *** ## TIM Routers (Smart Modem, TIM HUB, TIM HUB+) Most TIM routers allow DNS modification without restrictions. ### Steps 1. Go to: `http://192.168.1.1` 2. Log in using the admin password from the router label. 3. Open **Advanced → WAN / Internet Settings → DNS**. 4. Turn off **Automatic DNS**. 5. Input the DNS servers you prefer. ``` ofa-dns1 ofa-dns2 8.8.8.8 ``` 6. Save and restart the router. *** ## WindTre Routers (Home\&Life, Zyxel, D-Link) WindTre routers generally allow DNS configuration. ### Steps 1. Open your browser and go to `http://192.168.1.1`. 2. Log in using the credentials printed on the device. 3. Navigate to **Advanced Settings → Internet → IPv4 → DNS**. 4. Disable **Automatic DNS Assignment**. 5. Enter custom DNS values. ``` ofa-dns1 ofa-dns2 8.8.8.8 ``` 6. Save and run a reboot. *** ## Need a model-specific guide? Please contact [support@onefirewall.com](mailto:support@onefirewall.com) with the router specific version, and we support you through the configuration # OneFirewall Mobile Source: https://docs.onefirewall.com/essentials/ofa-mobile OFA Mobile extends corporate firewall protection to iOS and Android devices. It runs as an agent on the device, using a local VPN to monitor and control network traffic and block connections to untrusted networks. ## Key features * Local VPN inspects outbound connections and blocks untrusted networks at the device level. * Uses the OneFirewall Threat Intelligence Datalake, so blocking reflects current threat data. * Blocks connections to known-malicious IPv4 addresses, domains, and URLs, covering phishing, malware downloads, and data exfiltration attempts. * No rooting or jailbreaking required. * Supports current iOS and Android releases. ## Deployment models * **Cloud WCF Server** — managed through [app.onefirewall.com](https://app.onefirewall.com/), with onboarding and updates handled by OneFirewall. * **On-premises WCF Server** — run it yourself, or have the OneFirewall Platform team maintain it. ## MDM integration OFA Mobile deploys through your existing Mobile Device Management system and connects to your on-premises network, so enrollment and policy management stay in your normal MDM workflow. ## Pricing Pay-as-you-use — you pay for what you use. *** To get started, contact OneFirewall for a Proof of Value. More detail on the [OFA Mobile page](https://onefirewall.com/ofa-mobile.html). # ONE-F3D-Agent Installation Source: https://docs.onefirewall.com/essentials/one-f3d-agent How to install and run the World Crime Feed-Defend-Detect (F3D) Agent - by OneFirewall (one-f3d-agent) The **World Crime Feed-Defend-Detect Agent** integrates with the OneFirewall Platform to: * Ingest security events from SIEMs (via syslog) * Serve threat feeds to firewalls (FortiGate, pfSense, etc.) * Serve threat feed indicators for IPv4, domains, URLs, and file hashes as flat text file lists. * Automate blocking of malicious activity This guide shows you how to deploy the ONE-F3D-Agent on your own infrastructure. *** ## 1. Prerequisites ### 1.1 Virtual Machine Specifications * **RAM:** 8 GB (minimum 4 GB) * **vCPU:** 4 cores (minimum 2 cores) * **Disk:** 50 GB (minimum 20 GB) ### 1.2 Network Requirements | Direction | Protocol / Port | Purpose | | --------- | --------------------- | ------------------------------------------- | | Inbound | UDP 514 | Receive syslog events from your SIEM | | Inbound | TCP 443 (HTTPS) | Serve threat feeds to firewalls | | Inbound | TCP 8080 (HTTP) | Serve threat feeds to firewalls without SSL | | Outbound | TCP 443 → OneFirewall | Sync config & retrieve instructions | | Outbound | TCP 443 → Firewalls | Push automated-blocking commands (optional) | *** ## 2. Install Docker & Docker Compose ```bash theme={null} # On Debian/Ubuntu sudo apt update sudo apt install -y docker.io sudo systemctl enable --now docker # Install Docker Compose sudo curl -L "https://github.com/docker/compose/releases/download/$(curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r '.tag_name')/docker-compose-$(uname -s)-$(uname -m)" \ -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose ``` ## 3. Prepare Your Deployment Directory ```bash theme={null} mkdir -p ~/one-f3d-agent cd ~/one-f3d-agent ``` 1. Download the docker-compose.yml file for the ONE-F3D-Agent from [https://app.onefirewall.com/install-agent.html](https://app.onefirewall.com/install-agent.html), or from your on-premises installation (e.g., https\://LOCAL\_IP/install-agent.html). 2. The docker-compose.yml file includes environment variables required for the ONE-F3D-Agent to interact with its components. Make sure the FIREWALL\_PARSER variable (e.g., FIREWALL\_PARSER: "fortigate\_parser") matches the firewall log type sent by your SIEM. 3. Save the docker-compose.yml file to the \~/one-f3d-agent directory. ## 4. Example docker-compose.yml ```yaml theme={null} version: "3.9" services: nginx: image: nginx restart: always volumes: - ./onefirewall/db/local:/usr/share/nginx/html/api environment: NGINX_PORT: 80 ports: - 8080:80 command: | bash -c ' cat < /etc/nginx/conf.d/nginx-test.conf server { listen 80; listen [::]:80 ; server_name ofa-local.onefirewall.com; location / { root /usr/share/nginx/html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } } EOF nginx -g "daemon off;"' onefirewall-wcf-agent: image: registry.onefirewall.com/wcf-agent:v4 restart: always ports: - 8085:8080 ....... wcf-agent-feeds: image: registry.onefirewall.com/onefirewall-wcf-agent-feeds:v1 restart: always ....... onefirewall-fluentbit-adapter: image: registry.onefirewall.com/onefirewall-fluentbit-adapter:v2 environment: OFA_API_URL: "https://app.onefirewall.com" OFA_LAST_EVENTS: 2000000 FIREWALL_PARSER: "fortigate_parser" LOG_LEVEL: "info" ....... ``` Contact OneFirewall support team with access to download ONE-F3D-Agent required binary images ## 4.1 Example docker-compose.yml with SSL enabled Prepare your tls certs or use your own SSL certificate Example with Self-Signed Cert Go to the one-f3d-agent folder (i.e. \~/one-f3d-agent) ```bash theme={null} mkdir -p nginx/certs openssl genrsa -out nginx/certs/ofa.key 2048 openssl req -new -key nginx/certs/ofa.key -out nginx/certs/ofa.csr -subj "/CN=local-onefirewall.com" openssl x509 -req -days 3650 -in nginx/certs/ofa.csr -signkey nginx/certs/ofa.key -out nginx/certs/ofa.crt ``` edit the nginx service in docker-compose.yml as in the follow: ```yaml theme={null} version: "3.9" services: nginx: image: nginx restart: always volumes: - ./nginx/certs:/opt/ssl - ./onefirewall/db/local:/usr/share/nginx/html/api environment: NGINX_PORT: 80 ports: - 8080:80 - 8443:443 command: | bash -c ' cat < /etc/nginx/conf.d/nginx-test.conf server { listen 443 ssl; listen [::]:443 ssl; server_name ofa-local.onefirewall.com; ssl_certificate /opt/ssl/ofa.crt; ssl_certificate_key /opt/ssl/ofa.key; location / { root /usr/share/nginx/html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } ``` the existing services should not be edited, keep them as they are configured. ## 5. Launch the Agent ```bash theme={null} docker compose up -d docker-compose logs -f onefirewall-wcf-agent docker-compose logs -f wcf-agent-feeds docker-compose logs -f onefirewall-fluentbit-adapter docker-compose logs -f nginx ``` 1. `docker compose up -d` runs containers in the background. 2. `docker compose logs -f` streams the agent’s output for troubleshooting. ## 6. Verify Operation 1. Visit `https://app.onefirewall.com/agent-status.html` to see the Agent is working and blocking malicious connections 2. Visit `https://app.onefirewall.com/live.html` to see the traffic captured in real time ## Appendix - enable only fluentbit adapter for log collector This section covers running a reduced ONE-F3D-Agent as a logs-only service using Docker Compose, to capture and manage logs from your applications. If you are encountering issues with log parsing, check if catchall\_parser is enabled. This parser routes all logs to a single handler, which may hinder the capture of specific log formats. Make sure to specify a suitable FIREWALL\_PARSER that matches the format of the logs you are attempting to collect, in the following list: ``` FIREWALL_PARSER: "sonicwall_parser" FIREWALL_PARSER: "fortigate_parser" FIREWALL_PARSER: "sophos_parser" FIREWALL_PARSER: "paloalto_parser" FIREWALL_PARSER: "paloalto_csv_parser" FIREWALL_PARSER: "pfsense_parser" FIREWALL_PARSER: "pfsense_RFC5424_parser" FIREWALL_PARSER: "opnsense_parser" FIREWALL_PARSER: "nftables_parser" FIREWALL_PARSER: "checkpoint_flat_parser" FIREWALL_PARSER: "haproxy_security_parser" ``` Alternatively, you can create a custom regex to parse your device logs. Extract fluent-bit.yml from the container, then update the existing regex or add a new one. You can do this by editing the file and uncommenting the volume mount section to use your own configuration. ``` services: onefirewall-fluentbit-adapter: image: registry.onefirewall.com/onefirewall-fluentbit-adapter:v2 environment: FIREWALL_PARSER: "catchall_parser" LOG_LEVEL: "info" # debug, info, warn, error ENABLE_STDOUT: "*_ofa_logs" DEBUG_LUA: "false" FLUSH_INTERVAL_SECONDS: "5" # 5 seconds OFA_EVENTS_FLUSH_INTERVAL: "5" OFA_POLL_INTERVAL_HOURS: "1" OFA_JWT_TOKEN: "TOKEN_OFA" OFA_API_URL: "https://app.onefirewall.com or http[s]://localhost:PORT" OFA_MIN_SCORE_TO_LOG: "2" OFA_LAST_EVENTS: "2000000" OFA_MEMBER_ID: "OFA-GID-" OFA_API_URL_CLOUD: "" # <= empty, only for IPS OFA_JWT_TOKEN_CLOUD: "" # <= empty, only for IPS OFA_AGENT: "haproxy_waf" OFA_AGENT_LID: "report_xxxxx" OFA_AGENT_TAGS: "report_xxxxx" OFA_CONTRIBUTE: "0" OFA_IPS_FLUSH_INTERVAL: "300" # 5 minutes OFA_IPS_LIMIT: "1000" OFA_IPS_WORDS: "deny, timeout, ofa_warning" # lowercase, comma-separated values OFA_IPS_PORTS: "22, 23, 25, 443" SEND_TRAFFIC: "yes" ENABLE_ELASTIC_OUTPUT: "*_ofa_logs_OFF" ELASTIC_IP: "192.168.2.100" ELASTIC_PORT: "39220" ELASTIC_INDEX: "poc_traffic" ports: - "514:514/udp" # volumes: # - ./fluent-bit/fluent-bit.yml:/config/fluent-bit.yml ``` # OneFirewall System Events Source: https://docs.onefirewall.com/essentials/onefirewall-events OneFirewall emits operational and security events using the **CEF (Common Event Format)** standard, consumed by external monitoring systems, SIEMs, and log collectors. All events are forwarded over **syslog (UDP)** and follow a consistent, structured format. *** ## 1. Log Structure Overview Each log entry consists of **two main parts**: 1. **CEF Header** – fixed, pipe-delimited metadata used for classification 2. **CEF Extension** – space-separated key=value pairs with event details *** ## 2. CEF Header Format ``` CEF:||||||| ``` ### Header Fields | Field | Description | Example | | ---------------- | --------------------------- | ------------------------- | | `Version` | CEF version | `0` | | `Vendor` | Event vendor | `OneFirewall` | | `Product` | Application / service | `OFA-SRV` | | `Device Version` | Build or release identifier | `'2025-12-18'` | | `Signature` | Event type identifier | `APP_STATUS`, `NET_EVENT` | | `Name` | Event category | `Application` | | `Severity` | Numeric severity (0–10) | `3` | *** ## 3. CEF Extension Format The extension contains **space-separated key=value pairs**. ### Common Extension Fields | Field | Description | | ---------- | -------------------------------- | | `rt` | Event timestamp (UTC, ISO-8601) | | `level` | Log level (`INFO`, `WARN`, etc.) | | `hostname` | Host producing the event | | `clientip` | Client IP address | | `user` | User responsible for the action | | `member` | Tenant / organization | | `msg` | Human-readable message | Additional fields may be included depending on the event type (e.g. `IPv4`, `decision`, `ofa_score`). *** ## 4. Event Types & Examples ### 4.1 Application Lifecycle (`APP_STATUS`) Emitted when the application starts or changes operational state. ``` CEF:0|OneFirewall|OFA-SRV|'2025-10-12'|APP_STATUS|Application|3| rt=2025-10-12T01:21:56.184Z level=INFO hostname=192.168.0.2 clientip=NA user=NA member=NA msg='APP STARTED' ``` *** ### 4.2 Agent Management (`NEW_AGENT`, `AGENT_DELETED`) Tracks creation and deletion of agents. **New agent created** ``` CEF:0|OneFirewall|OFA-SRV|'2025-12-18'|NEW_AGENT|Application|3| rt=2025-10-12T00:22:37.234Z level=INFO hostname=192.168.0.2 user=user@example.com member='OneFirewall Alliance LTD' msg='New agent created' ``` **Agent deleted** ``` CEF:0|OneFirewall|OFA-SRV|'2025-12-18'|AGENT_DELETED|Application|3| rt=2025-10-12T00:31:32.529Z level=INFO hostname=192.168.0.2 user=user@example.com member='OneFirewall Alliance LTD' msg='Agent with OFA_dgH3Ti3z deleted' ``` *** ### 4.3 IPv4 List Generation (`IPV4_LIST`) Generated when IPv4 reputation lists are produced for enforcement or integrations. ``` CEF:0|OneFirewall|OFA-SRV|'2025-12-18'|IPV4_LIST|Application|3| rt=2025-10-12T00:33:43.999Z level=INFO hostname=192.168.0.2 user=user@example.com member='OneFirewall Alliance LTD' msg='IPv4 list generated for score=150, agid=OFA_cBzsXacP and plugin=fortinet' tot_size=22874 ``` *** ### 4.4 Feedback Updates (`FEEDBACK_UPDATED`) Indicates updates to feedback, scoring, or intelligence linked to an agent. ``` CEF:0|OneFirewall|OFA-SRV|'2025-12-18'|FEEDBACK_UPDATED|Application|3| rt=2025-10-12T00:48:13.075Z level=INFO hostname=192.168.0.2 user=user@example.com member='OneFirewall Alliance LTD' msg='Feedback updated for agid=OFA_cBzsXacP' ``` *** ### 4.5 Network Events (`NET_EVENT`) Represents observed or processed network traffic, optionally enriched with OneFirewall intelligence. **network event** ``` CEF:0|OneFirewall|OFA-SRV|'2026-01-12'|NET_EVENT|Application|3|rt=2026-01-14T00:56:06.280Z level=INFO hostname=mac clientip=undefined user=dev.team2@onefirewall.com member='OneFirewall Alliance LTD' msg='firewall=fortinet action=Allow service=serv1 src_ip=103.40.61.98 dst_ip=10.1.1.19 port=443 ofa_action=allow ofa_risk=low ofa_score=527 ofa_ip=103.40.61.98 ofa_members=25 ofa_first_seen=2025-10-06T14:21:06.000Z ofa_last_seen=2026-01-14T00:18:42.000Z ofa_reports=2725 ofa_geo_asn=AS133700 ofa_geo_domain= ofa_geo_country=India ofa_sources=cloud-provider-it,financial-service-it,honeynet-activity-gb,automotive-nl,security-provider-us,Transportation-it,threat-intel-de,tech-hub-it,cyber-threat-alliance-us,software-house-gb,security-provider-es ofa_intel=ddos-source,ssh-brute-force-i ofa_mitre=T1046,T1595,T1566,T1110' ``` #### 4.5.1 How Reads A network event corresponds to a single network flow captured and analyzed by OneFirewall and is structured into three main sections. ##### CEF Header As outlined above ##### CEF Extension As outlined above ##### CEF Extension Message The CEF extension includes a msg variable containing space-separated key=value data, as shown in the table below. | Field | Type | Description | | ----------------- | ---------- | -------------------------------------------------------------------------------------------- | | `firewall` | `string` | Firewall name or unique identifier | | `action` | `string` | Action taken by the firewall (e.g. `allow`, `block`) | | `service` | `string` | Service or application name | | `src_ip` | `ip` | Source IP address | | `dst_ip` | `ip` | Destination IP address | | `port` | `integer` | Destination port number | | `ofa_action` | `string` | Action determined by OneFirewall (`allow` or `block`) | | `ofa_risk` | `string` | Risk level assigned by OneFirewall (e.g. `LOW`, `MEDIUM`, `HIGH`) | | `ofa_score` | `integer` | OneFirewall threat/crime score | | `ofa_ip` | `ip` | IP address associated with the score (source or destination, depending on traffic direction) | | `ofa_members` | `integer` | Number of members who reported the threat actor | | `ofa_first_seen` | `datetime` | First time the IP or actor was observed | | `ofa_last_seen` | `datetime` | Most recent event recorded | | `ofa_reports` | `integer` | Total number of reports for the threat actor | | `ofa_geo_asn` | `string` | Autonomous System Number (ASN) | | `ofa_geo_domain` | `string` | Domain associated with the IP address | | `ofa_geo_country` | `string` | Country of origin | | `ofa_sources` | `string` | Comma-separated list of sources reporting the threat actor | | `ofa_intel` | `string` | Comma-separated list of intelligence tags or indicators | | `ofa_mitre` | `string` | Comma-separated list of MITRE ATT\&CK technique IDs | > When OneFirewall has no available information, all ofa\_ fields will be empty. *** ### 4.6 Policy & Decision Changes (`PUT_DECISION`) Logs policy or enforcement decisions applied to IP addresses. ``` CEF:0|OneFirewall|OFA-SRV|'2025-12-18'|PUT_DECISION|Application|3| rt=2025-10-12T01:16:57.741Z level=INFO hostname=192.168.0.2 user=user@example.com member='OneFirewall Alliance LTD' decision=BLOCK IPv4=1.0.138.92 ``` *** ## 5. SIEM compatibility Logs follow CEF 0, so they ingest directly into Splunk, Elastic, Microsoft Sentinel, and other syslog-compatible collectors. # Proof of Value Source: https://docs.onefirewall.com/essentials/pov # Proof of Value (PoV) of OneFirewall Solution ## Introduction OneFirewall is a threat intelligence sharing platform. It matches network traffic against a threat intelligence database and reports actionable insights on detected threats. ## Objective The Proof of Value (PoV) demonstrates OneFirewall's ability to identify and mitigate cyber threats in an on-premises or private cloud environment. A VM running the OneFirewall platform is installed, and edge traffic logs are analyzed to detect malicious activity. ## Scope 1. **Installation and Setup**: * Deploy a Virtual Machine with OneFirewall in the on-premises environment. * Ensure compatibility with the existing private cloud infrastructure. 2. **Traffic Logging**: * Enable logging of edge traffic to the OneFirewall VM. * Configure the system to capture and forward relevant network traffic for analysis. 3. **Threat Analysis**: * OneFirewall continuously matches incoming traffic against the threat intelligence database. * Provide real-time insights and alerts on detected malicious actors attempting to penetrate the network perimeter. ## Process ### 1. Preparation * Prepare a **Linux-based virtual machine** (Ubuntu, Debian, Red Hat, or equivalent) with **Docker** and **Docker Compose** installed. * Ensure the selected on-premises environment or private cloud instance meets all **network and permission requirements** needed for deployment. * Provide the required **access credentials** (i.e. VPN, VM credentials with sudoers rights) to the OneFirewall team, who will handle the setup and configuration. ### 2. Installation * OneFirewall staff deploy and configure the **OneFirewall OnPrem Solution**, a containerized ecosystem orchestrated via Docker Compose, under a PoV License. * Verify network connectivity so the solution can access and process traffic logs. * Run final installation and connectivity checks to confirm the solution is operational. ### 3. Configuration * Enable logging of all edge traffic to the OneFirewall VM. * Set up the permissions and integrations needed for traffic analysis. ### 4. Monitoring and Analysis * OneFirewall monitors network traffic in real time. * Traffic is matched against the threat intelligence database to identify and classify potential threats. * Reports and alerts are generated from the analysis. ### 5. Evaluation * Assess the volume and nature of detected threats. * Evaluate the responsiveness and accuracy of OneFirewall in identifying and mitigating potential cyber threats. * Gather feedback from network security personnel on the platform's usability and effectiveness. ## Deliverables * **Installation Report**: Setup process and initial configuration of the OneFirewall VM. * **Traffic Analysis Report**: Detected threats, including types of attacks, sources, and frequency. * **Evaluation Report**: OneFirewall's performance during the PoV, including key findings and areas for improvement. ## VM Requirement | Component | Basic | Recommended | | :-------- | :-------- | :---------- | | CPU/vCPU | 8 | 16 | | RAM | 32GB | 48GB | | Disk | 750GB SSD | 1TB SSD | ## Network connectivity | Direction | Service | Reason | | --------- | ------- | ---------------------------------------------------------------------------------------------- | | Inbound | 514/UDP | Syslog traffic | | Inbound | 443/TCP | UI and API Platform Access | | Inbound | 22/TCP | SSH Console access for installation | | Outbound | 443/TCP | Access Cloud Feeds at [https://app.onefirewall.com/api/v1](https://app.onefirewall.com/api/v1) | # Sizing Requirements (GCP) Source: https://docs.onefirewall.com/essentials/sizing-requirements-gcp Sizing Requirements of the OneFirewall Alliance solution ## 1. Introduction Sizing requirements for the OneFirewall Alliance solution, based on Service Level Agreement (SLA) and log throughput: | OFA Type | Size | SLA | Capability | License | | :-------------------------- | :----------------------------------------------------------------------------------------- | :--------------------------- | :-------------------------------------------------------------------------------- | :-------------------- | | **P-Micro (Collaudo/Test)** | 8 vCPU / 24–32 GB RAM / 300 GB SSD | 99% (No High Availability) | 1 Tenant, no backup, 100–300 log/s, Non-scalable | Trial License | | **P-0** | 8 vCPU / 32 GB RAM / 30GB node + 1000 GB SSD (persistent volume/standard-rwo) | 99.9% (No High Availability) | 1 Tenant, up to 10 users per tenant, daily backup, 100–300 log/s, Non-scalable | Single Tenant License | | **P-1** | 3× 8 vCPU / 3× 32 GB RAM / 30GB node + 3× 1000 GB SSD (persistent volume/standard-rwo) | 99.999% (High Availability) | 2–6 Tenants, up to 15 users per tenant, daily backup, 300–700 log/s, Non-scalable | Single Tenant License | | **P-2** | 3–5× 8 vCPU / 3–5× 32 GB RAM / 30GB node + 3× 1000 GB SSD (persistent volume/standard-rwo) | 99.9999% (High Availability) | 7+ Tenants, up to 30 users per tenant, daily backup, 700–1600 log/s, Scalable | While Label License | The following sections detail each installation type, with a sizing example and indicative infrastructure costs on GCP. *** ## 2. P-Micro **P-Micro** targets a testing environment: a single-VM installation of OneFirewall. ### Requirements and Costs | Requirements | Description | Monthly Cost (USD) | | :-------------------- | :----------------------------------------------- | :------------------- | | 1 VM (Compute Engine) | `n2-standard-8` (Spot Instance) | 39.40 | | 1 SSD (gp3) | 500 GB (persistent volume/standard-rwo) | 98.60 | | Cloud NAT | Internet update, app.onefirewall.com, gitlab.com | 41.50 (100 GB/month) | | Snapshot | N/A | 0 | | **Total** | | **179.50 USD/month** | For **Compute Engine (CE)** or **Google Kubernetes Engine (GKE)**, the system or Kubernetes user must be able to independently configure the environment (`sudoers` privileges or unrestricted RBAC management). *** ## 3. P-0 (ProdSmall) ### Requirements and Costs | Requirements | Description | Monthly Cost (USD) | | :------------------------- | :-------------------------------------------------------- | :------------------- | | 1 VM (Compute Engine) | `n2-standard-8` (Committed Use Discount) | 148.04 | | 1 SSD (gp3) | 30GB node + 1000 GB (persistent volume/standard-rwo) | 197.20 | | Cloud NAT | Internet update, app.onefirewall.com, gitlab.com | 41.50 (100 GB/month) | | External Load Balancer 443 | e.g. `onefirewall.example.it` (or ingress GKE equivalent) | Variable | | Snapshot | 1 per day | — | | **Total** | | **376.74 USD/month** | Compute Engine or GKE users must have privileges to configure the environment (`sudoers` or unrestricted RBAC), and IAM rules for ingress and external load balancer 443. *** ## 4. P-1 (ProdMedium) ### Requirements and Costs | Requirements | Description | Monthly Cost (USD) | | :--------------------------------------------------------------- | :-------------------------------------------------------- | :-------------------- | | 3 VM (Compute Engine) — one per AZ (or GKE Multi-Node, Multi-AZ) | `n2-standard-8` (Committed Use Discount) | 73 (GKE) + 444.12 | | 3 SSD (gp3) | 30GB node + 1000 GB each (persistent volume/standard-rwo) | 591.60 | | Cloud NAT | Internet update, app.onefirewall.com, gitlab.com | 41.50 (100 GB/month) | | External Load Balancer 443 | e.g. `onefirewall.example.it` (or ingress GKE equivalent) | Variable | | Snapshot | 1 per day | — | | **Total** | | **1108.72 USD/month** | Users must be able to configure the environment independently (`sudoers` or unrestricted RBAC), and manage IAM rules for ingress and external load balancer 443. *** ## 5. P-2 (ProdEnterprise) ### Requirements and Costs | Requirements | Description | Monthly Cost (USD) | | :----------------------------------------------------------------- | :-------------------------------------------------------- | :-------------------- | | 3–5 VM (Compute Engine) — one per AZ (or GKE Multi-Node, Multi-AZ) | `n2-standard-8` (Committed Use Discount) | 73 (GKE) + 740.20 | | 3 SSD (gp3) | 30GB node + 1000 GB each (persistent volume/standard-rwo) | 986.00 | | Cloud NAT | Internet update, app.onefirewall.com, gitlab.com | 41.50 (100 GB/month) | | External Load Balancer 443 | e.g. `onefirewall.example.it` (or ingress GKE equivalent) | Variable | | Snapshot | 1 per day | — | | **Total (up to)** | | **1840.70 USD/month** | For Compute Engine or GKE, users must have `sudoers` or unrestricted RBAC access, and appropriate IAM rules for ingress and external Load Balancer 443. # Virtual Private Server Source: https://docs.onefirewall.com/essentials/vps Technical Implementation # pfSense OpenVPN Client setup To configure OpenVPN, you need to: * Get the file openvpn-clientX.vpn (request it from [support@onefirewall.com](mailto:support@onefirewall.com)). * Open openvpn-clientX.ovpn in a text editor. * Go to the pfSense Webconfigurator at System / Certificate / Authorities, and add a new authority CA as in figure 1.1 by importing it from the OpenVPN client. * Get the CA certificate from `openvpn-clientX.ovpn` by copying all text between `` and ``, excluding the tags themselves. Install the client's certificate and private key to connect to the OpenVPN server. Get the certificate and private key values from the **openvpn-clientX** file, and import the certificate under System / Certificate / Certificates as YourOrgOpenVPN, following the steps in the figures above. Go to VPN / OpenVPN / Client, configure it as shown above using the TLS cert from openvpn-clientX.ovpn, and save the configuration. In Status / OpenVPN, confirm the client VPN is active: # PFBlockerNG - OneFirewall Blacklist setup To set up pfBlockerNG, configure the IPv4 blacklist as shown below. # Setup System Logs (syslogs) - Settings To set up system log mirroring, follow the configuration in Status / System Logs / Settings, shown in figure 3.1: # WCF Installation Source: https://docs.onefirewall.com/essentials/wcf-installation How to install and run World Crime Feeds (WCF) by OneFirewall The **WCF Agent** integrates with the OneFirewall Platform to: * Ingest security events from SIEMs (via syslog) * Serve threat feeds to firewalls (FortiGate, pfSense, etc.) * Automate blocking of malicious activity This guide shows you how to deploy the WCF Agent on your own infrastructure. *** ## 1. Prerequisites ### 1.1 Virtual Machine Specifications * **RAM:** 8 GB (minimum 4 GB) * **vCPU:** 4 cores (minimum 2 cores) * **Disk:** 50 GB (minimum 20 GB) ### 1.2 Network Requirements | Direction | Protocol / Port | Purpose | | --------- | --------------------- | ------------------------------------------- | | Inbound | UDP 514 | Receive syslog events from your SIEM | | Inbound | TCP 443 (HTTPS) | Serve threat feeds to firewalls | | Inbound | TCP 8085 (HTTP) | Serve threat feeds to firewalls | | Outbound | TCP 443 → OneFirewall | Sync config & retrieve instructions | | Outbound | TCP 443 → Firewalls | Push automated-blocking commands (optional) | *** ## 2. Install Docker & Docker Compose ```bash theme={null} # On Debian/Ubuntu sudo apt update sudo apt install -y docker.io sudo systemctl enable --now docker # Install Docker Compose sudo curl -L "https://github.com/docker/compose/releases/download/$(curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r '.tag_name')/docker-compose-$(uname -s)-$(uname -m)" \ -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose ``` ## 3. Prepare Your Deployment Directory ``` mkdir -p ~/wcf-agent cd ~/wcf-agent ``` 1. Download the WCF Agent Docker image into this folder. 2. Obtain your config.json from OneFirewall's Install Agent page. 3. Place config.json in \~/wcf-agent/onefirewall/config. ## 4. Create docker-compose.yml ```yaml theme={null} version: '3' services: onefirewall-wcf-agent: image: registry.onefirewall.com/wcf-agent:v4 restart: always ports: - 8085:8080 volumes: - "/tmp/log/:/var/log/:ro" - "./onefirewall/config:/opt/onefirewall/WCF-Agent-latest/config/:rw" - "./onefirewall/db:/opt/onefirewall/WCF-Agent-latest/db/:rw" command: > bash -x init.sh ``` Contact OneFirewall support team with access to download WCF Agent binary image ## 5. Launch the Agent ``` docker compose up -d docker-compose logs -f onefirewall-wcf-agent ``` 1. `docker compose up -d` runs containers in the background. 2. `docker compose logs -f` streams the agent’s output for troubleshooting. ## 6. Verify Operation 1. Visit `https://app.onefirewall.com/agent-status.html` to see the Agent is working and blocking malicious connections 2. Visit `https://app.onefirewall.com/live.html` to see the traffic captured in real time # OneFirewall Documentation Source: https://docs.onefirewall.com/introduction Welcome to the documentation portal of OneFirewall Alliance Hero Light This API documentation is generated with apigit v1. ## Setting up This documentation covers the OneFirewall APIs, their functionality, and the system's overall architecture, for developers integrating with the OneFirewall platform. OneFirewall (OFA) Coins are a form of currency used within the OneFirewall Alliance PoV measures the efficacy of OneFirewall in identifying and mitigating cyber attacks ## Read More # Get Scan Policy Source: https://docs.onefirewall.com/offensive-security/configuration/get-policy get /api/v1/user/scan-policy Retrieves the custom scan policy for the user. # Update Scan Policy Source: https://docs.onefirewall.com/offensive-security/configuration/update-policy post /api/v1/user/scan-policy Creates or updates the user's custom scan policy. # Introduction to Vulnix0 Source: https://docs.onefirewall.com/offensive-security/introduction An overview of the Vulnix0 platform and how to get started with the API. ## What is Vulnix0? Vulnix0 is an offensive security platform built by OneFirewall Alliance, with AquilaX Security as technology partner. It combines several security functions into one system, so organizations can discover, validate, and remediate vulnerabilities before attackers exploit them. The platform covers: * Attack Surface Management (ASM): discovers and maps external-facing digital assets to eliminate blind spots. * Automated Penetration Testing: simulates real-world adversary tactics against your defenses. * Dynamic Application Security Testing (DAST): analyzes live web applications for runtime vulnerabilities. * Threat Intelligence Validation: correlates global threat data with your environment to identify real risks. * Data Leakage Detection: monitors the open and dark web for exposed credentials and sensitive information. ## Generating an API Key To interact with the Vulnix0 API, you must first generate an API key from your user settings. This key authenticates your requests and should be kept confidential. 1. Log in to your Vulnix0 dashboard at [vulnix0.com](https://vulnix0.com). 2. Click your profile name in the top-right corner and select Settings. 3. On the settings page, scroll down to the API Keys section. 4. Click Generate New API Key. Generate API Key Use this key to authenticate your requests by including it in the `api-key` header. ### Organization Context When using the offensive security APIs (like initiating a scan), you may need to provide your Organization ID so results are attributed correctly. You can provide it in one of two ways: * Header: `X-Org-Id: YOUR_ORG_ID` * Query parameter: `?org_id=YOUR_ORG_ID` If you don't provide one, the system uses your default organization. # Delete Scan Source: https://docs.onefirewall.com/offensive-security/scan-management/delete-scan delete /api/v1/scans/{reqid} Deletes a scan record and its associated data by request ID. # Initiate Scan Source: https://docs.onefirewall.com/offensive-security/scan-management/initiate-scan post /api/v1/scan/{target} Starts a new vulnerability scan for a given target. The target is specified as the final part of the URL path. # List User Scans Source: https://docs.onefirewall.com/offensive-security/scan-management/list-scans get /api/v1/scans Retrieves a list of all scans initiated by the authenticated user. # Get Scan Details Source: https://docs.onefirewall.com/offensive-security/scan-management/scan-details get /api/v1/scans/{reqid} Retrieves full results and status of a specific scan by its request ID. # Health Check Source: https://docs.onefirewall.com/offensive-security/utilities/health get /api/v1/health Verifies the API is running and responding. # Operational Playbook & Incident Management Source: https://docs.onefirewall.com/operation-playbook Guidelines, emergency procedures, and interaction methods between the ClientX IT team and OneFirewall Alliance support centers. **Document Status:** Operational\ **Last Updated:** July 2026\ **Provider:** OneFirewall Alliance\ **Client:** ClientX *** ## 1. Document Objective This Operational Playbook defines the guidelines, emergency procedures, and interaction methods between the **ClientX IT team** and the **OneFirewall Alliance support centers**. The application in use is critical for business continuity and security. This document is designed to: * Give clear, immediate instructions to mitigate or resolve blocking service disruptions or anomalies. * Define escalation paths and dedicated contact channels based on the severity of the event. * Give the ClientX team the autonomy to execute structured workarounds (emergency bypassing) while waiting for specialized intervention from OneFirewall Alliance. > Keep this document up to date and accessible to all technical personnel authorized to manage the infrastructure. *** ## 2. Support Channels and Contacts (24/7) The OneFirewall Alliance support service is active **24 hours a day, 7 days a week** to ensure business continuity and infrastructure security for ClientX. ### Emergency Support (Service Block / Critical Incidents) *To be used exclusively in case of total service disruption, application offline, or blocking anomalies (High/Critical Severity).* **+44 (0) 20 3807 8020** * `support@onefirewall.com` * `solution-architects@onefirewall.com` **Mandatory Email Subject Line:** `[EMERGENZA] [ClientX] Brief Description of the Problem` ### Standard Support and Requests (Non-Blocking) *To be used for configurations, minor anomalies, questions about platform usage, or profile modifications.* * **Support Email:** `support@onefirewall.com` * **Response Time:** Within 24 hours * **Email Subject Line:** `[ClientX] Brief Description of the Problem or specific request` *** ## 3. Incident Severity Matrix To optimize intervention times, reports must be classified according to the following criteria: | Level | Impact | Description | Channel to Use | | :---------------- | :---------- | :----------------------------------------------------------------------------------------------------------- | :---------------------- | | **P1 - Critical** | **Total** | The ClientX application is isolated/offline; the OneFirewall agent is massively blocking legitimate traffic. | Phone + Emergency Email | | **P2 - High** | **Partial** | Malfunction of a single Agent feature or significant traffic slowdowns. | Emergency Email | | **P3 - Medium** | **Minimal** | GUI anomalies on the dashboard, reporting requests, or configuration changes. | Standard Email | *** ## 4. Operational Procedure in Case of Disruption (Emergency Workaround) In the event of a critical disruption (e.g., isolation of instances or application traffic block caused by a potential massive false positive), the ClientX IT team is authorized to follow this bypassing and quick recovery procedure. **ATTENTION:** Completing these steps temporarily disables OneFirewall protection. Execute these actions **only** in coordination with OneFirewall support or in the event of absolute application unavailability. ### Step 1: Cleaning Address Groups on Google Cloud Platform (GCP) *To immediately restore traffic flow at the network level and eliminate centralized IP blocks:* 1. Log in to the **ClientX GCP Console** using administrative credentials. 2. Navigate to: `VPC Network` -> `Firewall Policies` (or `Network Security` depending on the configuration). 3. Locate the Address Groups synchronized by OneFirewall Alliance (e.g., `ofa-blocked-ips-group`). 4. Proceed to clear (empty) the IPs contained within the group, or temporarily remove the Address Group association from active firewall rules. ### Step 2: Disabling the OneFirewall Agent *To prevent local machines from continuing to process rules or blocking traffic at the host level:* 1. Log in to the **OneFirewall Alliance Dashboard** on ClientX premises (`https://IP_HOST`) 2. Navigate to `Admin` -> `Agents`: * Disable the Agents related to **Cloud Armor** for the affected GCP project. 3. Navigate to `Intelligence (IoC)` -> `IPv4`: * If a specific IP is involved, under the IPv4 section, add the IP/IPs whose service accessibility is limited to the **whitelist**. ### Step 3: Notification to OneFirewall Alliance Immediately after executing steps 1 and 2, contact the 24/7 support via the emergency phone number to open the incident. This allows OneFirewall technicians to analyze logs, identify the root cause, and proceed with a secure restoration. # NetFlow Security Source: https://docs.onefirewall.com/products/NetFlow-Security-Report Guide to integrate and utilize OneFirewall's NetFlow Security Analysis API **NetFlow Security Analysis** is a sub-product of **OneFirewall Alliance** that provides **real-time network metadata analysis**. It gives visibility into **allowed** and **blocked** traffic at your organization's perimeter, helping identify malicious activity that bypassed traditional security controls. > OneFirewall cross-references this traffic against threat intelligence from its Cybersecurity Alliance to flag **previously allowed traffic** that has since been identified as **malicious**. *** ## Getting Started ### 1. Account and Licensing * An active **OneFirewall account** (on-prem or cloud). * A **valid license** for NetFlow Security Analysis. * **Permissions** to access API functionality. If you don't have access, contact **OneFirewall Support**. ### 2. Generate Your API Token Navigate to your **profile settings** on the OneFirewall platform and generate an **API token** to authorize your requests. *** ## Sending Network Metadata To send traffic data for analysis, use the following API endpoint: ### POST Request ``` import requests import json url = "https://app.onefirewall.com/api/v1/poc_traffic/direct" payload = json.dumps({ "firewall": "fortinet", "direction": "inbound", "dst_ip": "192.168.0.1", "service": "org1", "src_port": 3435, "dst_port": 443, "src_ip": "94.22.73.32", "action": "Allow" }) headers = { 'Authorization': '', 'Content-Type': 'application/json' } response = requests.request("POST", url, headers=headers, data=payload) print(response.text) ``` * firewall: Name of your firewall or IPS * direction: `inbound` or `outbound` * src\_ip / dst\_ip: Source and destination IPv4 addresses * src\_port / dst\_port: Source and destination port numbers * service: Human-readable name of the service * action: `Allow` or `Deny` #### Response Codes * 200 OK – Request accepted * 201 Created – Resource created and queued for analysis * 4xx – Error in request (e.g., malformed payload or invalid token) #### Rate Limiting You can send multiple requests, but be aware of the following limits: * 150 requests per 10 seconds * Requests beyond this rate will be throttled or rejected ### View Live Reports After sending the traffic metadata, you can monitor results live: 1. Go to [https://app.onefirewall.com](https://app.onefirewall.com) 2. Navigate to the Live section 3. View real-time analysis and threat assessments ### What NetFlow Security Analysis Provides * Detects malicious activity that slipped past traditional security layers * Gives visibility into blocked and allowed traffic across your perimeter * Uses threat intelligence from the Cybersecurity Alliance * Supports zero-trust strategies with traffic-level data # R&D Projects Source: https://docs.onefirewall.com/products/RnD Research and Development projects within OneFirewall # Encrypted communication (SOCS) ### Signal Open Source (Server, Mobile) - Java/Kotlin. Docker compose, Unix VMs Secure, private communication within an organization, built on the Signal open-source framework, with support for custom encryption algorithms for in-house or bespoke cryptography over the public internet. Uses Knox for hardware encryption. Deployed to two customers for stress testing on physical servers with eight dedicated VMs under VMware, isolated from each other, with secure public-facing access for mobile and desktop clients. Achieved 100% encrypted transmission over the public internet for voice, file sharing, and text. # Scalable Threat Distribution ### NodeJS, Python, Microservices, plugins for current SIEM and firewall devices in the market Threat-sharing across a global network of firewalls and SIEM solutions under an open alliance model, not tied to a single vendor, so private and public organizations can exchange real-time intelligence on malicious actors. Aggregates over 50 million threat intelligence data points from more than 500 sources, feeding real-time updates. Malicious connections are blocked within 30 seconds, in some cases within 5 seconds. Currently maintains 59 active sources, processing over 1 billion data points per month. # Cybersecurity Trust algorithm ### Python, NodeJS and Frontend (Browser version) A cybercrime scoring system that analyzes attack signals, identifies the originating device or appliance, and traces the source actor from the data feed. The score is a single numerical value representing trust and confidence in the actor identification, without exposing identifying details. The trust score comes from a matrix of factors rather than simple logic: source credibility, supporting data, timing of the report, corroboration from other alliance members, and the reliability of each data point. It can be assigned to any internet asset — IPv4, domain, URL, or file. # Closed VPN ### OpenVPN, Kotlin (Android), Swift (iOS) and multiplatform desktop application An open-source project based on the OpenVPN protocol, letting organizations establish secure communication channels over public internet infrastructure between customers, employees, and central data centers. CloseVPN integrates third-party cyberattack intelligence feeds and protects users on any device, inside or outside the organization. It provides internet connectivity through a dedicated VPN server hardened against malicious attacks, and blocks access to sites identified as phishing threats. # Secure DNS with realtime feeds ### Bind9, python, bash, and linux VM, AWS Built on the open-source BIND9 project for fast DNS query resolution, designed to detect and mitigate phishing campaigns by identifying malicious domains. Deployed across two data centers, in London and Frankfurt, operational for two years. Has prevented access and mitigated attacks from approximately 40,000 unique threat actors. # Mobile Protection (OFA Mobile) ### Android (Kotlin), Swift (iOS), local VPN - tunneling Blocks malicious connections within a mobile application using device-level routing, without requiring jailbreaking or rooting. Uses a predefined list of malicious actors. Deployed with two customers. Achieves prevention within 40 seconds — for example, if an attacker targets Organization X, the solution can block that attacker's inbound and outbound communications on an employee's mobile device at Organization Y within 40 seconds. # OneFirewall DeceptionGrid Source: https://docs.onefirewall.com/products/deceptiongrid # OneFirewall DeceptionGrid ## Overview DeceptionGrid is OneFirewall's honeynet platform: a distributed network of honeypots deployed across multiple geolocations to attract, monitor, and study real-world cyber adversaries. It converts attacker activity into threat intelligence. Each node simulates a digital environment using a set of decoy services. By observing how threat actors interact with these services, OneFirewall extracts telemetry, attack patterns, and behavioral indicators that feed its Threat Intelligence Data Lake, giving early visibility into emerging threats and attacker tactics, techniques, and procedures (TTPs). *** ## Services Deployed per Honeypot Node Each node simulates services across the following categories: ### Network & Remote Access * SSH (Port 22) – credential brute-force and key abuse * Telnet (Port 23) – legacy devices and insecure admin access * RDP (Port 3389) – Windows remote desktop environment * OpenVPN/IPsec (Port 1194/500) – corporate VPN gateway emulation ### Web & API Services * HTTP/HTTPS (Port 80/443) – fake websites, admin panels, and CMS * RESTful APIs (custom ports) – mimicking microservices or internal APIs * WebSocket endpoints – real-time protocol interaction analysis ### IoT & OT Protocols * Modbus (Port 502) – industrial control simulation * MQTT (Port 1883) – IoT message broker * UPnP/SSDP – smart home broadcast traffic * BACnet (Port 47808) – building automation system protocol * Zigbee (simulated stack) – wireless sensor activity ### File & Data Access * FTP/SFTP (Port 21/22) – insecure file transfer protocols * SMB/CIFS (Port 445) – Windows file sharing with weak credentials * NFS (Port 2049) – Unix/Linux network file system * ElasticSearch (Port 9200) – open data analytics nodes ### Databases * MySQL (Port 3306) * PostgreSQL (Port 5432) * MongoDB (Port 27017) * Redis (Port 6379) * Cassandra (Port 9042) These are configured with known vulnerabilities or weak configurations. ### DevOps & Cloud Services * Docker Daemon API (Port 2375) – exposed container runtime * Kubernetes API/Kubelet (Port 10250) – open clusters * Jenkins (Port 8080) – continuous integration tool interface * GitLab CI (Port 8929) – self-hosted pipelines ### Email & Messaging * SMTP (Port 25) * IMAP (Port 143) / POP3 (Port 110) – enterprise mailboxes ### Authentication & Directory Services * LDAP/LDAPS (Port 389/636) – enterprise directory services * Kerberos (Port 88) – Windows domain controller simulation * OAuth/OpenID Connect endpoints – federated auth flows ### VoIP & Legacy Communication * SIP (Port 5060) – VoIP endpoint attracting toll fraud attempts * XMPP/IRC – chat/C2 environments ### Application & Custom Decoys * Vulnerable web apps – DVWA, Juice Shop, fake ERP/CRM systems * Fake admin portals – SCADA dashboards, CMS panels * Geo-localized interfaces – banking portals or ISP panels specific to the node's region *** ## Deployment Architecture Each node is: * Isolated and sandboxed for controlled observation * Geographically distributed for visibility across regions * Tuned for low-interaction or high-interaction deception, depending on the node's risk tolerance and role * Instrumented for full telemetry, including session recording, packet capture, and real-time alerting *** ## How It Works 1. **Lure & Engage**: nodes respond to global scans and targeted probing with realistic service banners and behaviors. 2. **Record & Analyze**: all activity is logged, enriched, and correlated in real time. 3. **Extract Intelligence**: attacker behavior is converted into IOCs, TTPs, and threat actor fingerprints. 4. **Feed Defense**: threat data flows into OneFirewall's threat intelligence sharing platform. *** For integration or research partnerships, contact the OneFirewall team. # Federated XDR Source: https://docs.onefirewall.com/products/federated-xdr # Federated XDR ## Overview OneFirewall Alliance is a federated Global XDR platform. Member organizations securely share real-time threat signals through an alliance model, building a threat intelligence ecosystem that spans multiple networks, clouds, and geographies, rather than operating within a single enterprise or data center. ## Key Components ### World Crime Feeds Agent Listener A modular agent that integrates with security telemetry sources, including: * Intrusion detection systems (IDS) such as **Snort** * SIEM platforms such as **ELK Security**, **QRadar**, and **Splunk** * Raw system events, audit logs, endpoint telemetry, and cloud logs Feeds are aggregated, normalized, and enriched using threat intelligence from alliance members. ### Global Threat Intelligence Engine * Curated and enriched using machine learning and human analysis * Sources signals from enterprise environments, public data sources, and proprietary honeypots * Identifies new attack vectors, zero-days, and active campaigns early ### Instruction Layer – Distributed IPS Control Once threats are detected, OneFirewall can instruct defense mechanisms through integrations with: * Firewalls: Checkpoint, Fortinet, Cisco * Endpoint and network security: Trellix, Sophos, SonicWall * Cloud providers: AWS Shield, Google Chronicle SOC * Application security: Cloudflare, web layers, proxies * Routers, email gateways, and more *** ## Comparison with Traditional XDR | Capability | Traditional XDR | OneFirewall Global XDR | | ----------------------- | -------------------------------- | --------------------------------------- | | Scope | Limited to a single organization | Federated across trusted orgs | | Threat Sharing | None or reactive sharing | Real-time alliance-wide sharing | | Detection Model | Post-factum, often local context | Proactive, context-aware | | Integration Breadth | Vendor-specific or limited stack | Multi-vendor, plug-in agnostic | | Threat Response | Delayed, localized playbooks | Global instructions, instant | | Resilience to Zero-Days | Limited without global view | Early detection from collective insight | | Ecosystem | Vendor siloed | Open, trusted alliance | *** ## How It Works ### Proactive Defense Members receive threat data shared by other alliance members before a specific threat targets their organization, rather than relying solely on signature updates. ### Federated Intelligence Threats discovered in one environment inform defenses across all others, reducing mean time to detect (MTTD) and mean time to respond (MTTR). ### Plug-in Ecosystem Integrations support deployment across legacy systems, modern cloud platforms, and hybrid environments. ### Privacy-Preserving Design Information sharing uses metadata exchange, anonymization, and zero-trust principles, within GDPR, HIPAA, and similar compliance boundaries. *** ## Use Cases * Pre-emptively block IPs or domains reported as malicious by other alliance members * Respond to ransomware campaigns observed in other alliance nodes before local infection * Integrate with SIEM/SOAR pipelines to enrich investigations with global context * Orchestrate firewall and endpoint reconfigurations across hybrid environments *** # Compatible Security Products by Category The tables below list SIEM, WAF, EDR, XDR, firewall, and IPS products that are natively compatible with, or have existing integrations with, the OneFirewall Global XDR platform. *** ## SIEM (Security Information and Event Management) | Vendor | Product Name | | ---------- | ------------------------------- | | Splunk | Splunk Enterprise Security (ES) | | IBM | QRadar SIEM | | Elastic | Elastic Security (ELK Stack) | | Sumo Logic | Cloud SIEM | | Microsoft | Microsoft Sentinel | | Exabeam | Exabeam Fusion SIEM | | LogRhythm | LogRhythm SIEM | | Fortinet | FortiSIEM | | Rapid7 | InsightIDR | | Trellix | Trellix Helix | | Graylog | Graylog Security | | Devo | Devo SIEM Platform | | ArcSight | ArcSight ESM | | Securonix | Securonix Next-Gen SIEM | | RSA | NetWitness Platform | *** ## WAF (Web Application Firewall) | Vendor | Product Name | | ---------- | -------------------------------- | | Cloudflare | Cloudflare WAF | | AWS | AWS WAF | | Azure | Azure WAF | | Imperva | Imperva Cloud WAF / SecureSphere | | Akamai | Kona Site Defender | | F5 | BIG-IP Advanced WAF | | Barracuda | Barracuda WAF | | Citrix | Citrix Web App Firewall | | Fortinet | FortiWeb | | Radware | AppWall | | Sophos | Sophos Web Appliance | | Fastly | Fastly Next-Gen WAF | | StackPath | StackPath WAF | *** ## EDR (Endpoint Detection and Response) | Vendor | Product Name | | ----------- | ----------------------------- | | CrowdStrike | Falcon EDR | | SentinelOne | Singularity EDR | | Microsoft | Defender for Endpoint | | Trellix | Endpoint Security | | Palo Alto | Cortex XDR (EDR capabilities) | | Bitdefender | GravityZone EDR | | Sophos | Intercept X | | Trend Micro | Apex One EDR | | ESET | ESET Inspect | | Cisco | Secure Endpoint | | Kaspersky | Kaspersky EDR | | VMware | Carbon Black Cloud | | Cybereason | Cybereason EDR | *** ## XDR (Extended Detection and Response) | Vendor | Product Name | | ----------- | ------------------------------------- | | Palo Alto | Cortex XDR | | CrowdStrike | Falcon XDR | | SentinelOne | Singularity XDR | | Microsoft | Defender XDR (Microsoft 365 Defender) | | Trellix | Trellix XDR Platform | | Trend Micro | Vision One (XDR) | | Sophos | Sophos XDR | | Cisco | Cisco XDR | | Bitdefender | GravityZone XDR | | Fortinet | FortiXDR | | Elastic | Elastic Security XDR | | Rapid7 | InsightXDR | | Cynet | Cynet 360 AutoXDR | *** ## Firewalls | Vendor | Product Name | | ----------- | -------------------------------------- | | Palo Alto | Next-Gen Firewall (NGFW) | | Fortinet | FortiGate | | Cisco | Firepower / ASA | | Check Point | Quantum Security Gateway | | Sophos | Sophos Firewall | | SonicWall | SonicWall NGFW | | Juniper | SRX Series | | WatchGuard | Firebox | | Barracuda | CloudGen Firewall | | Huawei | USG Series | | Hillstone | StoneOS Firewall | | Forcepoint | NGFW | | Untangle | NG Firewall | | Ubiquiti | UniFi Security Gateway / Dream Machine | | Netgate | pfSense | *** ## IPS (Intrusion Prevention Systems) | Vendor | Product Name | | ------------- | ------------------------- | | Cisco | Firepower IPS | | Snort (Cisco) | Snort (open source) | | Suricata | Suricata (open source) | | Palo Alto | Threat Prevention | | Fortinet | FortiIPS | | Trend Micro | TippingPoint IPS | | IBM | X-Force IPS | | Trellix | Network Security Platform | | Check Point | IPS Software Blade | | Juniper | IDP Series | | Hillstone | Network-Based IPS | | NSFOCUS | NSFOCUS NIPS | *** ## Integration Compatibility OneFirewall supports ingestion of telemetry, threat intelligence enrichment, and coordinated response actions across the products listed above, through the plugin ecosystem and the World Crime Feeds Agent Listener. For systems not yet integrated, OneFirewall's team can develop dedicated connectors or adapt existing APIs for compatibility. # ClosedVPN Source: https://docs.onefirewall.com/products/secure-vpn ## Secure VPN by OneFirewall ### Overview Secure VPN by OneFirewall provides endpoint-level security for phones, desktops, and servers. It uses OneFirewall's threat intelligence feed to detect and block malicious connections at the device level. ### Key Features * **Cross-platform**: available for phones, desktops, and servers. * **Threat intelligence integration**: connections are checked against OneFirewall's threat intelligence in real time. * **Encrypted tunnel**: traffic is encrypted from the device to the VPN endpoint. * **Simple deployment**: install and configure without additional infrastructure. ### Download Download the VPN client binary from the OneFirewall app. Binaries are built for the latest CPU architectures on Windows and macOS. If a specific architecture is needed, use the download link in the format `[name]_[intel|arm].[dmg|exe]`. ### API Documentation # Web Attack Filter Source: https://docs.onefirewall.com/products/waf # Web Application Firewall ## Overview **OneFirewall-WAF** (Web Attack Filter) is a Web Application Firewall built by **OneFirewall Alliance LTD**. It protects web applications by combining real-time threat intelligence with rule-based filtering. *** ## Core Capabilities ### Real-Time Threat Prevention Uses OneFirewall's threat intelligence to block malicious actors before they can exploit your application. ### Multi-Layer Protection Protects your app at multiple levels: * TCP/IP DDoS mitigation * Rule engine built on ModSecurity * Rate limiting per URI * Custom signature injection ### Deployment Options * **Managed by OneFirewall** (hosted on OneFirewall's cloud) * **Self-managed by customer** (on-premises or private cloud) ### Dashboard Real-time dashboard for threat insights, traffic patterns, and rule analytics, with unlimited user access. *** ## Core Features | Feature | Description | | ----------------------- | -------------------------------------------------------------------------- | | **DDoS Protection** | Blocks volumetric and protocol-layer attacks using CDN-backed strategies | | **Custom Rulesets** | Public and proprietary ModSecurity rule sets tailored for your application | | **Threat Intelligence** | Real-time feed with updated indicators of compromise | | **Rate Limiting** | Fine-grained control to limit abusive traffic on specific endpoints | *** ## Deployment Models ### 1. Managed by OneFirewall * Installed and operated in OneFirewall's cloud * 24/7 monitoring, updates, and operational responsibility ### 2. Self-Managed by Customer * Installed and configured by OneFirewall engineers * Customer retains control of day-to-day operations *** ## What's Included * 1.5h expert training session * Monthly service reviews * Feature request program (case-by-case evaluation) * Real-time analytics dashboard *** ## SLA Highlights (Managed Deployment) | SLA Metric | Commitment | | -------------------------------- | ------------------------------------- | | **Service Functionality Uptime** | 99.99% over any 3-month period | | **Platform Availability** | 99.999% online presence over 3 months | *** # v2025-01-10 - Usage Metrics Source: https://docs.onefirewall.com/releases/2025-01-10 WCF Agent configuration management, an active/inactive toggle, and real-time usage reporting. ## Active Toggle Enable or disable the WCF Agent for a specific instance directly through the Web Interface or via the API. ## Config.json Management WCF Agent configurations can now be viewed, updated, and deleted server-side through a JSON editor in the Agent Status Console, including sync time, score thresholds, and rule sets. Changes apply automatically during the agent's next execution cycle. The agent-side `config.json` file now retains only essential data — configuration details related to how the WCF Agent interacts with firewalls, IDS, or IPS in the perimeter have been removed. Sensitive information, such as passwords and cryptographic keys, is no longer stored in the local file system. These secrets are now encrypted and accessible only during the WCF Agent's runtime. ## Real-Time Usage Report A monitoring dashboard provides real-time insight into platform usage, including API access tracking and system activity. It includes a threshold alert system that notifies you if a WCF Agent fails to communicate with the server, plus visibility into data injection and contribution metrics for both on-premises and SaaS instances. # v2025-05-22 - Query Speed Source: https://docs.onefirewall.com/releases/2025-05-22 Query engine performance, custom reserved IP ranges, shared submission tags, and tag-based prevention rules. ## Query Speed The query engine has been overhauled to serve real-time data in 0.32s on average, down from 12s. No UI or workflow changes are required; this also reduces load on local OneFirewall instances. ## Custom Reserved IPs Define your own list of reserved IPs or networks (CIDR format) at the organization level. Any IP you add is automatically rejected during submissions, in addition to global reserved-IP rules (e.g. private ranges). To configure: go to **Organizations**, click **Edit** on the target organization (Admin only), and update the `reserved_ips` array in the JSON configuration. ## Shared Tags Across the Alliance Attach optional tags when submitting IPs, files, domains, or URLs, and share them with the OneFirewall community — for example AlienVault threat lists, Cyber Threat Alliance feeds, or Tor exit-node indicators. Tagged submissions contribute to and draw from curated community tag data. ## Tag-Based Prevention Rules The Live Score API (used by the WCF Agent) now supports prevention based on score and specific tags — for example, block any IP above a score threshold and matching a tag such as `malware` or `botnet`. To configure: go to **Organizations**, set the score threshold and/or desired tags, and save to activate. # v2025-06-21 - Tags Source: https://docs.onefirewall.com/releases/2025-06-21 Changed IP lookup behavior, a score calculation fix, and negative score weighting for submissions. ## Updates * Searching for an IP address not present in the Threat Intelligence Data Lake no longer creates a new entry. The search still returns a score of 0, but no entry is created. ## Bug Fixes * Fixed an issue with score calculation for manual submissions. ## New Features * You can now assign a negative score weight to a submission, acting as a statement of "Secure" relative to the rest of the alliance data. This lets you explicitly communicate that an IP is not malicious. # v2025-07-19 - Hardening Source: https://docs.onefirewall.com/releases/2025-07-19 Authentication rate limiting and account lockout, trusted-device sessions, and internalized queue processing. ## Updates * Login now enforces rate limiting and account lockout to mitigate brute-force attacks. ## New Features * A "Trust This Device" option is now available during login. When selected, your session persists beyond the standard 2-hour timeout. ## Infrastructure * Removed the standalone Queue Consumer and Queue Management services. Task queuing and processing is now handled internally by the application. # v2025-09-14 - Defence Center Source: https://docs.onefirewall.com/releases/2025-09-14 A new dashboard shows per-agent blacklist size, scores, and blocked-event trends over time. ## Agent Monitoring Page A new page in the platform shows how each deployed agent is performing at detecting and blocking malicious actors in real time. ## Features * **Agent overview charts**: polar area chart comparing blacklist size across agents; bar chart of per-agent scores, color-coded by data freshness (updated in the last 24h vs. stale). * **Blocked rules time-series**: blocked events aggregated into 10-minute buckets, with zoom to drill into short windows or view long-term trends. Empty periods render as 0-count buckets rather than gaps. * **Tooltips**: hovering over a data point shows IP, score, number of events, members affected, and blacklist size. ## Backend improvements * MongoDB and Elasticsearch queries scoped to relevant time ranges (e.g., last 24h) for faster page loads. * Pre-bucketing and debouncing added to time-series rendering to prevent browser slowdowns on large datasets. * Query logic unified across MongoDB and Elasticsearch. # v2025-09-23 - Search Page Source: https://docs.onefirewall.com/releases/2025-09-23 Search any IPv4 address for threat intelligence data, activity history, and MITRE ATT&CK-mapped events. ## IPv4 Threat Intelligence Search Search any IPv4 address to retrieve threat intelligence data associated with it. ### Summary view * **Risk level** with Crime Score visualization. * **IP details**: ASN, domain, reverse DNS, country of origin. * **Timeline**: first seen date, latest attack timestamp, time span of malicious activity. * **Community intelligence**: number of reports and distinct contributing organizations. * **Historical crime level graph**: malicious activity trends over time. ### Activity feed Each entry includes: * Human-readable description of the activity (e.g., brute-force attempts, malware distribution, reconnaissance). * Mapped MITRE ATT\&CK techniques. * Honeypot engagement logs from OneFirewall DeceptionGrid. * External references (e.g., Blocklist.de reports). ### Notes * Explanations shown when a classification is unavailable (confidential, obfuscated, or withheld). * Reported activity represents a subset of broader cybercrime attempts identified by the Alliance community. # v2025-10-24 - WCF Install Source: https://docs.onefirewall.com/releases/2025-10-24 The WCF Agent installation page now includes plugin selection for supported firewall vendors. ## WCF Agent Installation The installation page for the WCF Agent now includes plugin selection. Choose from a list of supported plugins — including Fortinet, Check Point, and Sophos — and enable them directly during installation. # v2026-01-16 - 2FA Source: https://docs.onefirewall.com/releases/2026-01-16 Enable two-factor authentication for cloud, on-prem, and personal accounts, with automatic OTP lockout after repeated failed attempts. ## Two-Factor Authentication OneFirewall supports two-factor authentication (2FA) across cloud, on-premises, and hybrid deployments, and for personal user accounts. 2FA requires a second verification factor in addition to the password. ## Service Accounts and OTP Service accounts, used for automation, integrations, and non-interactive access, authenticate without an OTP challenge. This keeps API integrations and CI/CD pipelines from being disrupted by 2FA. Scope service accounts tightly and protect them with strong credentials and network controls. ## OTP Lockout Policy After 10 consecutive unsuccessful OTP attempts, the account is automatically locked. While locked, login is denied even with correct credentials. An administrator must manually reset the OTP status via the OneFirewall portal to restore access. ## Recommendation Enable 2FA on personal accounts, particularly for administrators and users with access to logs, rules, policy configuration, or API/integration permissions. # v2026-02-18 - CTI API Source: https://docs.onefirewall.com/releases/2026-02-18 Retrieve consolidated IPv4 threat intelligence — score, geolocation, MITRE ATT&CK, and STIX data — through a single API endpoint. # CTI API: IPv4 Intelligence Endpoint ## `GET /api/v1/intel/` Returns consolidated threat intelligence for a single IPv4 address — crime score and score history, geolocation and ASN ownership, reporting sectors and countries, MITRE ATT\&CK technique mappings, and STIX 2.1 observables — in one response. Use it to determine whether an IP is malicious and why, without querying multiple feeds separately, and to feed dashboards, SIEM enrichment, or automated response workflows. This endpoint is additive: existing IPv4 feed, geolocation, and scoring APIs are unchanged. ### Response Structure The API returns a JSON object with the following fields: | Field | Type | Description | | -------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------- | | `type` | `string` | Input type: `"ip"`, `"domain"`, `"url"`, or `"sha"`. Returns `undefined` on request mismatch. | | `request` | `string` | Original IPv4 input provided by the user. | | `timestamp` | `number` | Unix timestamp when the data was generated. | | `timestamp_readable` | `string` | Human-readable ISO 8601 timestamp (e.g., `"2026-02-16T00:32:00Z"`). | | `request_id` | `string` | Unique identifier for this request. | | `body` | `object` | JSON object mirroring data from IPv4 Feeds, including core threat indicators. | | `ip_info` | `object` | Geolocation (country, city, lat/lon) and ASN details (owner, network range). | | `history` | `array` | Array of historical Crime Score entries, each with timestamp and score value. | | `sectors` | `array` | Sectors and industries (e.g., `"finance"`, `"healthcare"`) reporting the IPv4 as malicious. | | `countries` | `array` | ISO country codes where OneFirewall Alliance members reported attacks originating from this IPv4. | | `reports` | `array` | Reasons for reports (e.g., `"phishing"`, `"DDoS"`, `"malware C2"`). | | `members` | `array` | Subset of OneFirewall Alliance members who publicly reported this IPv4 (anonymized non-public members excluded). | | `mitre_id` | `array` | MITRE ATT\&CK external IDs associated with observed tactics (e.g., `"T1071.001"`). | | `stix` | `array` | STIX 2.0/2.1 observables and indicators linked to this IPv4 (includes IDs, patterns, created\_by\_ref). | | `intel` | `array` | MITRE ATT\&CK intelligence objects cross-referenced with `mitre_id` (tactics, techniques, descriptions). | | `agents` | `array` | All agents belonging to reporting alliance members (includes agent ID, version, last\_seen). | ### Sample Response ```json theme={null} { "type": "ip", "request": "101.36.***.***", "timestamp": 1771461453, "timestamp_readable": "2026-02-16T00:37:33.702Z", "request_id": "kaRQEhJOiusY", "body": { "gid": "OFA-RULE-GID-0Rd9qGMjk0lxrwjR", "ip": "101.36.***.***", "ts": 1771461076, "blocked_by": [], "unblocked_by": [], "start": 1696884978, "end": 1696884978, "entry_ts": 1729044462, "is_network": false, "score": 581, "ttl_by": [], "info": { "members": 26, "events": 61, "sources": [ "router", ], "stix_bundles": [], "attack_infos": [], "notes": [ "luna3", ] }, "reports": 2735, "elk_ts": "2026-02-16T00:31:16.000Z", "elk_entry_ts": "2024-10-16T02:07:42.000Z", "delay": 0, "dec": 8.3e-7 }, "ip_info": { "as_domain": "ucloud.cn", "as_name": "UCLOUD INFORMATION TECHNOLOGY (HK) LIMITED", "asn": "AS135377", "continent": "Asia", "continent_code": "AS", "country": "Japan", "country_code": "JP" }, "history": [ { "ip": "101.36.***.***", "members": 19, "events": 24, "elk_ts": "2025-11-22T00:17:15.000Z", "ts": 1763770635, "elk_entry_ts": "2024-10-16T02:07:42.000Z", "current_ts": "2025-11-22T00:25:18.000Z", "score": 415 }, { "ip": "101.36.***.***", "members": 19, "events": 24, "elk_ts": "2025-11-22T07:22:41.000Z", "ts": 1763796161, "elk_entry_ts": "2024-10-16T02:07:42.000Z", "current_ts": "2025-11-22T08:10:00.000Z", "score": 412 } ], "sectors": [ "Cloud Provider IT", "Threat Intel DE", "Honeynet GB", "Automotive NL", "Cyber Threat Alliance USA", "Security Provider US", "Transportation IT", "Financial Service IT", "Software House GB", "Tech Hub IT" ], "countries": [ "IT", "DE", "GB", "NL", "US" ], "reports": [ "Service Brute Force", "indicator--9db300d4", "DDOS Source attempts", "Brute Force", "Brute Force: Password Guessing", "Remote Services: SSH", "Valid Accounts", "101.36.***.***", "Scanning for Vulnerable Software", "indicator--77a74faa", "indicator--69420ee6", "reconnaissance", "initial-access", "credential-access", "defense-evasion", "persistence", "privilege-escalation", "discovery" ], "members": [ "Blocklist.de - fail2ban Reporting Service", "OneFirewall DeceptionGrid", "Huijbregts ict & cybersafety", "Cyber Threat Alliance", "AquilaX Security", "TEC4I FVG: Human Technology Hub" ], "mitre_ids": [ "T1046", "T1595", "T1595.002", "T1110", "T1566", "T1078" ], "stix": [ { "id": "indicator--1a7c8688-5c0f-491e-948f-bc48ab20e509", "type": "indicator", "spec_version": "2.1", "pattern": "[ipv4-addr:value = '101.36.***.***']", "pattern_type": "stix", "created": "2025-12-18T23:00:00.000Z", "modified": "2025-12-18T23:00:00.000Z", "valid_from": "2025-12-18T23:00:00.000Z", "kill_chain_phases": [ { "kill_chain_name": "mitre-attack", "phase_name": "command-and-control" } ], "indicator_types": [ "malicious-activity" ], "confidence": 70, "object_marking_refs": [ "marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da" ], "created_by_ref": "identity--7b501448-4025-4783-bbf8-950e05e5c376", "x_cta_received": "2025-12-19T16:10:19.000Z", "x_cta_submission_id": "e0863061-b29f-40e7-b38a-3ff5e8b7f4e0", "x_cta_submitted_by": "identity--7b501448-4025-4783-bbf8-950e05e5c376", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "72a6ccef68cfdf1dce69277e1b91246891d2d6fb95e46974e009717f2308422f", "x_cta_hash_context": "1213f2e1fd7d6df4547021b17c3bec91245f2b7050f0faae391c2e1bc249c62a" }, { "id": "indicator--b86dbe41-4934-43ae-a830-f98d6ff8bd00", "type": "indicator", "spec_version": "2.1", "pattern": "[ipv4-addr:value = '101.36.***.***']", "pattern_type": "stix", "modified": "2025-12-20T10:21:54.808Z", "created": "2025-12-20T10:21:43.860Z", "kill_chain_phases": [ { "kill_chain_name": "mitre-attack", "phase_name": "command-and-control" } ], "indicator_types": [ "malicious-activity" ], "confidence": 90, "object_marking_refs": [ "marking-definition--f88d31f6-486f-44da-b317-01333bde0b82" ], "created_by_ref": "identity--7b501448-4025-4783-bbf8-950e05e5c376", "x_cta_received": "2025-12-21T14:52:08.000Z", "x_cta_submission_id": "475ef319-33bf-436d-9420-e86533ea6199", "x_cta_submitted_by": "identity--7b501448-4025-4783-bbf8-950e05e5c376", "valid_from": "2025-12-20T10:21:43.860Z", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "72a6ccef68cfdf1dce69277e1b91246891d2d6fb95e46974e009717f2308422f", "x_cta_hash_context": "2a2372f0a95fea8ad250879a5fdc62a0cb388e35af7c0614c9183569fd789270" }, { "name": "Scanning for Vulnerable Software", "labels": [ "malicious-activity" ], "pattern": "[ipv4-addr:value = '101.36.***.***']", "created_by_ref": "identity--4d755f87-141e-4b71-9a1e-8e1ec9bba882", "kill_chain_phases": [ { "kill_chain_name": "lockheed-martin-cyber-kill-chain", "phase_name": "exploitation" } ], "type": "indicator", "id": "indicator--31f339e6-5506-488b-a0f1-f0b9a537f98f", "created": "2025-12-23T08:12:11.416Z", "modified": "2025-12-23T08:12:11.416Z", "valid_from": "2025-12-23T08:12:11.416Z", "x_cta_received": "2025-12-23T08:12:12.000Z", "x_cta_submission_id": "42f13bf6-9c80-4aee-ae2f-ce16c4d0d6a0", "x_cta_submitted_by": "identity--4d755f87-141e-4b71-9a1e-8e1ec9bba882", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "9a9f2614b58ee6bcff385f25ef400c0fa3a0e4445a1a9d0353a7a601f90c7355", "x_cta_hash_context": "9a9f2614b58ee6bcff385f25ef400c0fa3a0e4445a1a9d0353a7a601f90c7355" }, { "type": "indicator", "id": "indicator--cef9bd32-6eed-4eb9-a4b1-a6f9377f985c", "created_by_ref": "identity--269557e7-b2ac-42e5-8059-6e2f66bfe29d", "created": "2025-11-30T18:01:20.650Z", "modified": "2025-11-30T18:01:20.650Z", "pattern": "[ipv4-addr:value = '101.36.***.***']", "valid_from": "2025-11-30T18:01:20.650Z", "kill_chain_phases": [ { "kill_chain_name": "lockheed-martin-cyber-kill-chain", "phase_name": "reconnaissance" } ], "labels": [ "anomalous-activity" ], "x_cta_received": "2025-11-30T18:01:24.000Z", "x_cta_submission_id": "dc6f772a-f406-4869-bdb3-c6abd2ea1292", "x_cta_submitted_by": "identity--269557e7-b2ac-42e5-8059-6e2f66bfe29d", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "3f55e1b7e5d0f654c661901fdc19e776e2659ebdaae121b0a914050605e96c08", "x_cta_hash_context": "3f55e1b7e5d0f654c661901fdc19e776e2659ebdaae121b0a914050605e96c08" }, { "type": "indicator", "id": "indicator--27d6880c-b1b4-49d1-af58-5458a53e4f72", "created_by_ref": "identity--269557e7-b2ac-42e5-8059-6e2f66bfe29d", "created": "2025-11-29T23:01:34.242Z", "modified": "2025-11-29T23:01:34.242Z", "pattern": "[ipv4-addr:value = '101.36.***.***']", "valid_from": "2025-11-29T23:01:34.242Z", "kill_chain_phases": [ { "kill_chain_name": "lockheed-martin-cyber-kill-chain", "phase_name": "reconnaissance" } ], "labels": [ "anomalous-activity" ], "x_cta_received": "2025-11-29T23:01:38.000Z", "x_cta_submission_id": "484cc6b0-f829-40b0-a888-6fa6b28db9c1", "x_cta_submitted_by": "identity--269557e7-b2ac-42e5-8059-6e2f66bfe29d", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "3f55e1b7e5d0f654c661901fdc19e776e2659ebdaae121b0a914050605e96c08", "x_cta_hash_context": "3f55e1b7e5d0f654c661901fdc19e776e2659ebdaae121b0a914050605e96c08" }, { "id": "indicator--77a74faa-827f-4dbe-8992-7ea47646d7b5", "spec_version": "2.1", "name": "indicator--77a74faa", "created_by_ref": "identity--d881d918-e772-4246-931d-23a0f1b739bb", "type": "indicator", "pattern_type": "stix", "created": "2025-11-15T07:40:22.000Z", "modified": "2025-12-01T06:20:05.000Z", "indicator_types": [ "malicious-activity" ], "pattern": "[ipv4-addr:value = '101.36.***.***']", "valid_from": "2025-12-01T06:20:05.000Z", "kill_chain_phases": [ { "kill_chain_name": "mitre-attack", "phase_name": "reconnaissance" } ], "x_cta_received": "2025-12-01T11:43:14.000Z", "x_cta_submission_id": "50c41256-c3aa-4797-9d32-50441d95897b", "x_cta_submitted_by": "identity--d881d918-e772-4246-931d-23a0f1b739bb", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "c5ccbe410803ed8e967234ca07a121c73d331cd496ec656fc3ffba2e7ae52d28", "x_cta_hash_context": "c5ccbe410803ed8e967234ca07a121c73d331cd496ec656fc3ffba2e7ae52d28" }, { "type": "indicator", "id": "indicator--84dde0ca-63da-4d3c-8028-750040943631", "created_by_ref": "identity--269557e7-b2ac-42e5-8059-6e2f66bfe29d", "created": "2025-12-14T23:01:19.789Z", "modified": "2025-12-14T23:01:19.789Z", "pattern": "[ipv4-addr:value = '101.36.***.***']", "valid_from": "2025-12-14T23:01:19.789Z", "kill_chain_phases": [ { "kill_chain_name": "lockheed-martin-cyber-kill-chain", "phase_name": "reconnaissance" } ], "labels": [ "anomalous-activity" ], "x_cta_received": "2025-12-14T23:01:22.000Z", "x_cta_submission_id": "671f7f44-c4ea-4169-a145-1f90558fdace", "x_cta_submitted_by": "identity--269557e7-b2ac-42e5-8059-6e2f66bfe29d", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "3f55e1b7e5d0f654c661901fdc19e776e2659ebdaae121b0a914050605e96c08", "x_cta_hash_context": "3f55e1b7e5d0f654c661901fdc19e776e2659ebdaae121b0a914050605e96c08" }, { "id": "indicator--ac335e09-eaed-41ed-bab3-9b83984012d4", "type": "indicator", "spec_version": "2.1", "pattern": "[ipv4-addr:value = '101.36.***.***']", "pattern_type": "stix", "created": "2025-12-12T23:00:00.000Z", "modified": "2025-12-12T23:00:00.000Z", "valid_from": "2025-12-12T23:00:00.000Z", "kill_chain_phases": [ { "kill_chain_name": "mitre-attack", "phase_name": "command-and-control" } ], "indicator_types": [ "malicious-activity" ], "confidence": 70, "object_marking_refs": [ "marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da" ], "created_by_ref": "identity--7b501448-4025-4783-bbf8-950e05e5c376", "x_cta_received": "2025-12-13T16:42:18.000Z", "x_cta_submission_id": "a08c0945-9f14-4e17-96a4-b531d5c73eae", "x_cta_submitted_by": "identity--7b501448-4025-4783-bbf8-950e05e5c376", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "72a6ccef68cfdf1dce69277e1b91246891d2d6fb95e46974e009717f2308422f", "x_cta_hash_context": "1213f2e1fd7d6df4547021b17c3bec91245f2b7050f0faae391c2e1bc249c62a" }, { "id": "indicator--c67f6839-ec10-4594-af41-39c1d06cef05", "type": "indicator", "spec_version": "2.1", "pattern": "[ipv4-addr:value = '101.36.***.***']", "pattern_type": "stix", "modified": "2025-12-12T18:54:35.584Z", "created": "2025-12-12T18:54:18.519Z", "kill_chain_phases": [ { "kill_chain_name": "mitre-attack", "phase_name": "command-and-control" } ], "indicator_types": [ "malicious-activity" ], "confidence": 90, "object_marking_refs": [ "marking-definition--f88d31f6-486f-44da-b317-01333bde0b82" ], "created_by_ref": "identity--7b501448-4025-4783-bbf8-950e05e5c376", "x_cta_received": "2025-12-13T16:50:32.000Z", "x_cta_submission_id": "84fa9794-20d9-44ee-a20e-70a548e9c542", "x_cta_submitted_by": "identity--7b501448-4025-4783-bbf8-950e05e5c376", "valid_from": "2025-12-12T18:54:18.519Z", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "72a6ccef68cfdf1dce69277e1b91246891d2d6fb95e46974e009717f2308422f", "x_cta_hash_context": "2a2372f0a95fea8ad250879a5fdc62a0cb388e35af7c0614c9183569fd789270" }, { "type": "indicator", "id": "indicator--148586ef-a02f-4f3f-b639-b907884db7ef", "created_by_ref": "identity--269557e7-b2ac-42e5-8059-6e2f66bfe29d", "created": "2025-12-16T13:01:22.120Z", "modified": "2025-12-16T13:01:22.120Z", "pattern": "[ipv4-addr:value = '101.36.***.***']", "valid_from": "2025-12-16T13:01:22.120Z", "kill_chain_phases": [ { "kill_chain_name": "lockheed-martin-cyber-kill-chain", "phase_name": "reconnaissance" } ], "labels": [ "anomalous-activity" ], "x_cta_received": "2025-12-16T13:01:25.000Z", "x_cta_submission_id": "3e86d95e-8ec0-4e3e-abff-36bfc3070597", "x_cta_submitted_by": "identity--269557e7-b2ac-42e5-8059-6e2f66bfe29d", "x_cta_patn_obs_exprs": [ { "observation_expression": "[ipv4-addr:value='101.36.***.***']", "comparison_expressions": [ { "path": "ipv4-addr:value", "op": "=", "value": "101.36.***.***" } ], "observation_expression_hash": "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" } ], "x_cta_hash_pattern_obs_exprs": [ "b52b88e6353b21d0f6950b2fec3543be714d257af38635a86249ee0762a42ce7" ], "x_cta_hash_pattern": "e1d4a16b8df1e24c3f6a1474c3d8cd2496f1de8e0e4e637c5365b7e8b41d382e", "x_cta_hash_identity": "3f55e1b7e5d0f654c661901fdc19e776e2659ebdaae121b0a914050605e96c08", "x_cta_hash_context": "3f55e1b7e5d0f654c661901fdc19e776e2659ebdaae121b0a914050605e96c08" } ], "intel": [ { "type": "course-of-action", "name": "Brute Force Mitigation", "description": "Set account lockout policies after a certain number of failed login attempts to prevent passwords from being guessed. \nToo strict a policy can create a denial of service condition and render environments un-usable, with all accounts being locked-out permanently. Use multifactor authentication. Follow best practices for mitigating access to [Valid Accounts](https://attack.mitre.org/techniques/T1078)\n\nRefer to NIST guidelines when creating passwords.(Citation: NIST 800-63-3)\n\nWhere possible, also enable multi factor authentication on external facing services.", "phases": [], "external_id": "T1110" }, { "type": "course-of-action", "name": "Network Service Scanning Mitigation", "description": "Use network intrusion detection/prevention systems to detect and prevent remote service scans. Ensure that unnecessary ports and services are closed and proper network segmentation is followed to protect critical servers and devices.\n\nIdentify unnecessary system utilities or potentially malicious software that may be used to acquire information about services running on remote systems, and audit and/or block them by using whitelisting (Citation: Beechey 2010) tools, like AppLocker, (Citation: Windows Commands JPCERT) (Citation: NSA MS AppLocker) or Software Restriction Policies (Citation: Corio 2008) where appropriate. (Citation: TechNet Applocker vs SRP)", "phases": [], "external_id": "T1046" }, { "type": "course-of-action", "name": "Valid Accounts Mitigation", "description": "Take measures to detect or prevent techniques such as [OS Credential Dumping](https://attack.mitre.org/techniques/T1003) or installation of keyloggers to acquire credentials through [Input Capture](https://attack.mitre.org/techniques/T1056). Limit credential overlap across systems to prevent access if account credentials are obtained. Ensure that local administrator accounts have complex, unique passwords across all systems on the network. Do not put user or admin domain accounts in the local administrator groups across systems unless they are tightly controlled and use of accounts is segmented, as this is often equivalent to having a local administrator account with the same password on all systems. \n\nFollow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers. (Citation: Microsoft Securing Privileged Access) \n\nAudit domain and local accounts as well as their permission levels routinely to look for situations that could allow an adversary to gain wide access by obtaining credentials of a privileged account. (Citation: TechNet Credential Theft) (Citation: TechNet Least Privilege) These audits should also include if default accounts have been enabled, or if new local accounts are created that have not be authorized. \n\nApplications and appliances that utilize default username and password should be changed immediately after the installation, and before deployment to a production environment. (Citation: US-CERT Alert TA13-175A Risks of Default Passwords on the Internet) When possible, applications that use SSH keys should be updated periodically and properly secured. ", "phases": [], "external_id": "T1078" }, { "type": "attack-pattern", "name": "Vulnerability Scanning", "description": "Adversaries may scan victims for vulnerabilities that can be used during targeting. Vulnerability scans typically check if the configuration of a target host/application (ex: software and version) potentially aligns with the target of a specific exploit the adversary may seek to use.\n\nThese scans may also include more broad attempts to [Gather Victim Host Information](https://attack.mitre.org/techniques/T1592) that can be used to identify more commonly known, exploitable vulnerabilities. Vulnerability scans typically harvest running software and version numbers via server banners, listening ports, or other network artifacts.(Citation: OWASP Vuln Scanning) Information from these scans may reveal opportunities for other forms of reconnaissance (ex: [Search Open Websites/Domains](https://attack.mitre.org/techniques/T1593) or [Search Open Technical Databases](https://attack.mitre.org/techniques/T1596)), establishing operational resources (ex: [Develop Capabilities](https://attack.mitre.org/techniques/T1587) or [Obtain Capabilities](https://attack.mitre.org/techniques/T1588)), and/or initial access (ex: [Exploit Public-Facing Application](https://attack.mitre.org/techniques/T1190)).", "phases": [ "reconnaissance" ], "external_id": "T1595.002" }, { "type": "attack-pattern", "name": "Active Scanning", "description": "Adversaries may execute active reconnaissance scans to gather information that can be used during targeting. Active scans are those where the adversary probes victim infrastructure via network traffic, as opposed to other forms of reconnaissance that do not involve direct interaction.\n\nAdversaries may perform different forms of active scanning depending on what information they seek to gather. These scans can also be performed in various ways, including using native features of network protocols such as ICMP.(Citation: Botnet Scan)(Citation: OWASP Fingerprinting) Information from these scans may reveal opportunities for other forms of reconnaissance (ex: [Search Open Websites/Domains](https://attack.mitre.org/techniques/T1593) or [Search Open Technical Databases](https://attack.mitre.org/techniques/T1596)), establishing operational resources (ex: [Develop Capabilities](https://attack.mitre.org/techniques/T1587) or [Obtain Capabilities](https://attack.mitre.org/techniques/T1588)), and/or initial access (ex: [External Remote Services](https://attack.mitre.org/techniques/T1133) or [Exploit Public-Facing Application](https://attack.mitre.org/techniques/T1190)).", "phases": [ "reconnaissance" ], "external_id": "T1595" }, { "type": "attack-pattern", "name": "Phishing", "description": "Adversaries may send phishing messages to gain access to victim systems. All forms of phishing are electronically delivered social engineering. Phishing can be targeted, known as spearphishing. In spearphishing, a specific individual, company, or industry will be targeted by the adversary. More generally, adversaries can conduct non-targeted phishing, such as in mass malware spam campaigns.\n\nAdversaries may send victims emails containing malicious attachments or links, typically to execute malicious code on victim systems. Phishing may also be conducted via third-party services, like social media platforms. Phishing may also involve social engineering techniques, such as posing as a trusted source, as well as evasive techniques such as removing or manipulating emails or metadata/headers from compromised accounts being abused to send messages (e.g., [Email Hiding Rules](https://attack.mitre.org/techniques/T1564/008)).(Citation: Microsoft OAuth Spam 2022)(Citation: Palo Alto Unit 42 VBA Infostealer 2014) Another way to accomplish this is by [Email Spoofing](https://attack.mitre.org/techniques/T1672)(Citation: Proofpoint-spoof) the identity of the sender, which can be used to fool both the human recipient as well as automated security tools,(Citation: cyberproof-double-bounce) or by including the intended target as a party to an existing email thread that includes malicious files or links (i.e., \"thread hijacking\").(Citation: phishing-krebs)\n\nVictims may also receive phishing messages that instruct them to call a phone number where they are directed to visit a malicious URL, download malware,(Citation: sygnia Luna Month)(Citation: CISA Remote Monitoring and Management Software) or install adversary-accessible remote management tools onto their computer (i.e., [User Execution](https://attack.mitre.org/techniques/T1204)).(Citation: Unit42 Luna Moth)", "phases": [ "initial-access" ], "external_id": "T1566" }, { "type": "attack-pattern", "name": "Brute Force", "description": "Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained.(Citation: TrendMicro Pawn Storm Dec 2020) Without knowledge of the password for an account or set of accounts, an adversary may systematically guess the password using a repetitive or iterative mechanism.(Citation: Dragos Crashoverride 2018) Brute forcing passwords can take place via interaction with a service that will check the validity of those credentials or offline against previously acquired credential data, such as password hashes.\n\nBrute forcing credentials may take place at various points during a breach. For example, adversaries may attempt to brute force access to [Valid Accounts](https://attack.mitre.org/techniques/T1078) within a victim environment leveraging knowledge gathered from other post-compromise behaviors such as [OS Credential Dumping](https://attack.mitre.org/techniques/T1003), [Account Discovery](https://attack.mitre.org/techniques/T1087), or [Password Policy Discovery](https://attack.mitre.org/techniques/T1201). Adversaries may also combine brute forcing activity with behaviors such as [External Remote Services](https://attack.mitre.org/techniques/T1133) as part of Initial Access. \n\nIf an adversary guesses the correct password but fails to login to a compromised account due to location-based conditional access policies, they may change their infrastructure until they match the victim’s location and therefore bypass those policies.(Citation: ReliaQuest Health Care Social Engineering Campaign 2024)", "phases": [ "credential-access" ], "external_id": "T1110" }, { "type": "attack-pattern", "name": "Valid Accounts", "description": "Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Compromised credentials may be used to bypass access controls placed on various resources on systems within the network and may even be used for persistent access to remote systems and externally available services, such as VPNs, Outlook Web Access, network devices, and remote desktop.(Citation: volexity_0day_sophos_FW) Compromised credentials may also grant an adversary increased privilege to specific systems or access to restricted areas of the network. Adversaries may choose not to use malware or tools in conjunction with the legitimate access those credentials provide to make it harder to detect their presence.\n\nIn some cases, adversaries may abuse inactive accounts: for example, those belonging to individuals who are no longer part of an organization. Using these accounts may allow the adversary to evade detection, as the original account user will not be present to identify any anomalous activity taking place on their account.(Citation: CISA MFA PrintNightmare)\n\nThe overlap of permissions for local, domain, and cloud accounts across a network of systems is of concern because the adversary may be able to pivot across accounts and systems to reach a high level of access (i.e., domain or enterprise administrator) to bypass access controls set within the enterprise.(Citation: TechNet Credential Theft)", "phases": [ "defense-evasion", "persistence", "privilege-escalation", "initial-access" ], "external_id": "T1078" }, { "type": "attack-pattern", "name": "Network Service Discovery", "description": "Adversaries may attempt to get a listing of services running on remote hosts and local network infrastructure devices, including those that may be vulnerable to remote software exploitation. Common methods to acquire this information include port, vulnerability, and/or wordlist scans using tools that are brought onto a system.(Citation: CISA AR21-126A FIVEHANDS May 2021) \n\nWithin cloud environments, adversaries may attempt to discover services running on other cloud hosts. Additionally, if the cloud environment is connected to a on-premises environment, adversaries may be able to identify services running on non-cloud systems as well.\n\nWithin macOS environments, adversaries may use the native Bonjour application to discover services running on other macOS hosts within a network. The Bonjour mDNSResponder daemon automatically registers and advertises a host’s registered services on the network. For example, adversaries can use a mDNS query (such as dns-sd -B _ssh._tcp .) to find other systems broadcasting the ssh service.(Citation: apple doco bonjour description)(Citation: macOS APT Activity Bradley)", "phases": [ "discovery" ], "external_id": "T1046" } ], "agents": [ { "_id": "", "agid": "OFA-AGENT-ID-********", "plugin": "CloudArmor", "active": true, "hostname": "n/a", "blacklist": [ ], "blacklist_size": 10082, "ts": 1771460426, "mgid": "OFA-GID-******", "score_threshold": "190", "code": 0, "version": 10, "config": { "gaid": "OFA-AGENT-ID-*******", "score_threshold": 150, "start_from": 0, "version": "v4.60.4", "proxy": "CLOUD", "installation_name": "gcp", "sync_time": 200, "maximum_rules": 99999998, "running": "yes" } } ] } ``` # v2026-05-18 - Scheduled Tasks Source: https://docs.onefirewall.com/releases/2026-05-18 Schedule recurring API queries against OneFirewall threat intelligence, evaluate conditions on the results, and deliver alerts via in-app notification or email. # Tasks ## Overview Tasks is an automation engine that schedules periodic queries against OneFirewall's threat intelligence APIs, evaluates conditions on the responses, and delivers notifications through in-app or email channels. Tasks replace external cron scripts or third-party alerting integrations for common OneFirewall workflows. Configuration happens through a 6-step wizard in the portal. *** ## What Tasks Do A Task is a scheduled unit of work with three parts: 1. **One or more API queries** — the Task calls internal OneFirewall API endpoints on a schedule. 2. **Conditions** — the Task evaluates the API response against user-defined rules (e.g. `score > 500`). Notification is only sent when conditions pass. Conditions can be omitted to notify on every run. 3. **Notification delivery** — the Task sends a message to the in-app notification bell, to email, or both. *** ## Task Types | Type | Behaviour | | --------------- | -------------------------------------------------------------------------------------------------- | | `api_condition` | Calls one or more APIs, checks conditions, sends a templated notification when conditions are met. | | `api_fetch` | Calls an API and sends the raw or templated response as a notification unconditionally. | | `hello_world` | Sends a static message (useful for testing notification delivery). | *** ## Guided Wizard Creating a task uses a **6-step wizard**: ### Step 1 — Task Name Give the task a short descriptive name (e.g. `Alert on High-Risk IP`). ### Step 2 — API Calls Add one or more OneFirewall API endpoints to query. A searchable preset picker covers common endpoints: * IP / Domain / URL / File Hash intelligence * Files, Domains, URLs, IPs above a score threshold * Defence rules, overview statistics, and more Each API call has a **Test** button that fires the request live and shows the JSON response inline — useful for discovering which field names to use in conditions and templates. Multiple API calls are executed in sequence. Responses are merged into a single template data object for use in Step 3. **Timestamp tokens** in API paths are automatically resolved at execution time: | Token | Resolves to | | ------------- | ------------------------------------ | | `__now__` | Current Unix timestamp (ms) | | `__24h_ago__` | Unix timestamp 24 hours earlier (ms) | This allows recurring tasks to always query a rolling time window without manual updates. ### Step 3 — Conditions & Template **Conditions** define when a notification is sent. Each condition targets a field from an API response and evaluates it against a value. | Operator | Description | | ---------- | -------------------------------- | | `>` | Greater than | | `<` | Less than | | `>=` | Greater than or equal | | `<=` | Less than or equal | | `==` | Exact string match | | `!=` | Not equal | | `contains` | Case-insensitive substring match | Multiple conditions are combined with **AND** (all must pass) or **OR** (any must pass) logic, selectable per task. When a task has multiple API calls, each condition can target a specific call's response using `api_index`. **Notification Template** defines the message content using `{{fieldName}}` placeholders: ``` Alert: {{score}} score detected for {{ip}} — reported by {{members}} members ``` For the second API call onwards, use prefixed references: ``` Top actor: {{api2_1_actor}} with score {{api2_1_score}} in {{api2_1_country}} ``` Array responses are automatically flattened up to 10 items with numbered prefixes (`api2_1_*`, `api2_2_*`, …), making it straightforward to reference ranked list data in templates. **HTML templates** are supported — if the template begins with `` or ` **Timestamp note for Live Traffic:** `/malicious/top` and `/malicious/detailed` accept optional `from_ts` and `to_ts` query parameters in **Unix seconds**. When omitted, both default to the last hour automatically, which is the right behaviour for a recurring task — every run always reflects the most recent hour. ### Building the Weekly Report Task Follow the wizard with these settings: **Step 1 — Name** ``` Weekly Security Digest ``` **Step 2 — API Calls** Add three calls in sequence: | Call | Path | | ---- | -------------------------------------- | | 1 | `/api/v1/graphs/overview` | | 2 | `/api/v1/defense` | | 3 | `/api/v1/graphs/traffic/malicious/top` | Use the **Test** button on each to verify the live JSON response and confirm field names before proceeding. **Step 3 — Conditions & Template** Leave conditions **empty** — the task will notify on every scheduled run regardless of values. Paste an HTML template in the Notification Template field. Because the template starts with ``, the Task Runner automatically treats it as HTML: the email receives the full rendered document, and the in-app notification receives the stripped plain-text version. Example template: ```html theme={null}

Weekly Security Digest

OneFirewall — automated report
Threat Intelligence Database
{{graph1.value}}
Live IPv4 Rules
{{graph2.value}}
File Signatures
{{graph3.value}}
Domains
{{graph4.value}}
URLs
Defence Center — Last 24 Hours
{{api2.attacks}}
Blocked Attacks
{{api2.actors}}
Unique Threat Actors
Top Malicious Actors — Last Hour of Live Traffic
{{api3_1_actor}}  ·  Score {{api3_1_live_score}}  ·  {{api3_1_ip_info_country}}
{{api3_2_actor}}  ·  Score {{api3_2_live_score}}  ·  {{api3_2_ip_info_country}}
{{api3_3_actor}}  ·  Score {{api3_3_live_score}}  ·  {{api3_3_ip_info_country}}
{{api3_4_actor}}  ·  Score {{api3_4_live_score}}  ·  {{api3_4_ip_info_country}}
{{api3_5_actor}}  ·  Score {{api3_5_live_score}}  ·  {{api3_5_ip_info_country}}
Generated automatically by OneFirewall Tasks
``` **Template field reference:** | Placeholder | Source | Field | | ---------------------------- | -------------------------------- | ---------------------------------- | | `{{graph1.value}}` | API 1 (`/graphs/overview`) | Total Live IPv4 rule count | | `{{graph2.value}}` | API 1 | Total File Signature count | | `{{graph3.value}}` | API 1 | Total Domain count | | `{{graph4.value}}` | API 1 | Total URL count | | `{{api2.attacks}}` | API 2 (`/defense`) | Blocked attack events (last 24h) | | `{{api2.actors}}` | API 2 | Unique threat actor IPs (last 24h) | | `{{api3_1_actor}}` | API 3 (`/malicious/top`), item 1 | Top threat actor IP | | `{{api3_1_live_score}}` | API 3, item 1 | OFA threat score | | `{{api3_1_ip_info_country}}` | API 3, item 1 | Geolocation country | | `{{api3_2_actor}}` … | API 3, item 2–5 | Second through fifth actors | The array-flattening logic in the Task Runner automatically expands the `malicious/top` response array into `api3_1_*`, `api3_2_*`, … prefixed keys — up to 10 items — so no custom scripting is needed. **Step 4 — Notification Channel** Select **Email + App Notification**. For an organisation-wide report, add the team's shared security mailbox under **Additional Recipients**. **Step 5 — Schedule** Select **Recurring → Weekly → Monday → 09:00** (or whichever day and time fits your team's review cadence). **Step 6 — Review & Activate** Confirm all three API calls, the HTML template, and the weekly schedule, then click **Activate Task**. *** ### Extending the Report To add more data to the same report, add additional API calls in Step 2 and reference them in the template using `{{api4_…}}`, `{{api5_…}}`, etc. Common additions: | Call | Path | Adds to report | | ---- | ------------------------------------------- | ---------------------------------------------------------------------------------- | | 4th | `/api/v1/graphs/traffic/malicious/detailed` | Traffic risk category breakdown (low/medium/high/critical counts) | | 4th | `/api/v1/feeds/500/5/10` | Current intelligence feed (IPs with score ≥ 500, seen by ≥ 5 members, ≥ 10 events) | | 4th | `/api/v1/domains/score/500` | Domains above a threat score threshold | | 4th | `/api/v1/files/score/500` | Malicious file hashes above threshold | ### Sending to Multiple Teams Create one task per audience and adjust the **Additional Recipients** list in Step 4: * `SOC Weekly Digest` → SOC team mailing list * `Executive Weekly Summary` → same API calls, simplified template without raw IPs * `CISO Board Report` → monthly schedule, higher-level stats only Each task is independent and can have its own schedule, template, and recipient list. *** ## Summary * **Scheduled API queries** against any OneFirewall endpoint — run now, one-time, hourly, or on a daily/weekly/monthly recurring schedule. * **Condition engine** with 7 operators, AND/OR logic, and multi-API-call support. * **Mustache-style templates** with automatic array flattening and full HTML email support. * **Three notification channels**: in-app bell, email, or both — with configurable additional recipients. * **Live API test** in the wizard so you can inspect the JSON response before setting up conditions. * **Task log** with paginated history and inline HTML message preview. * **Distributed, crash-safe execution** with atomic locking and stale-task recovery. * **Deep-link URL support** for pre-populating the wizard from other pages in the portal. # v2026-06-22 - MCP Server Source: https://docs.onefirewall.com/releases/2026-06-22 Connect AI agents directly to OneFirewall threat intelligence and firewall automation via the Model Context Protocol The **OneFirewall MCP Server** exposes OneFirewall's threat intelligence platform to AI agents — Claude, GPT-4, Copilot, and any MCP-compatible client — as callable tools. Agents can investigate IPs, pull live threat feeds, report malicious actors, and query firewall agent status without leaving the conversation. *** ## What is MCP? The [Model Context Protocol](https://modelcontextprotocol.io) (MCP) is an open standard that lets AI models call external tools over a secure, structured interface. Instead of copy-pasting IPs into a dashboard, an AI agent can call `get_ip_intel("1.2.3.4")` and receive structured threat intelligence directly in its context. *** ## Connect Your AI Tool The OneFirewall MCP server is hosted and managed — no self-hosting required. Your JWT token is available from the [OneFirewall dashboard](https://app.onefirewall.com). Paste it into the configuration for your AI client below. Edit `claude_desktop_config.json`: **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json`\ **Windows:** `%APPDATA%\Claude\claude_desktop_config.json` ```json theme={null} { "mcpServers": { "onefirewall": { "command": "npx", "args": [ "-y", "mcp-remote", "https://mcp.onefirewall.com/mcp", "--header", "Authorization: Bearer YOUR_JWT_TOKEN" ] } } } ``` Restart Claude Desktop. The OneFirewall tools appear in the tools panel (hammer icon). Open **Cursor Settings → MCP** and add a new server, or edit `.cursor/mcp.json` in your project: ```json theme={null} { "mcpServers": { "onefirewall": { "command": "npx", "args": [ "-y", "mcp-remote", "https://mcp.onefirewall.com/mcp", "--header", "Authorization: Bearer YOUR_JWT_TOKEN" ] } } } ``` The tools become available in Cursor's Agent mode automatically. Edit `~/.codeium/windsurf/mcp_config.json`: ```json theme={null} { "mcpServers": { "onefirewall": { "command": "npx", "args": [ "-y", "mcp-remote", "https://mcp.onefirewall.com/mcp", "--header", "Authorization: Bearer YOUR_JWT_TOKEN" ] } } } ``` Reload Windsurf. Tools are available in Cascade (Agent mode). Add to your VS Code `settings.json`: ```json theme={null} { "mcp": { "servers": { "onefirewall": { "type": "http", "url": "https://mcp.onefirewall.com/mcp", "headers": { "Authorization": "Bearer YOUR_JWT_TOKEN" } } } } } ``` Enable **GitHub Copilot Agent mode** and the OneFirewall tools will be listed under available MCP servers. Run once to register the server globally: ```bash theme={null} claude mcp add --transport http onefirewall https://mcp.onefirewall.com/mcp \ --header "Authorization: Bearer YOUR_JWT_TOKEN" ``` The tools are then available in every Claude Code session without further configuration. Add to `~/.config/opencode/config.json`: ```json theme={null} { "mcp": { "onefirewall": { "type": "remote", "url": "https://mcp.onefirewall.com/mcp", "headers": { "Authorization": "Bearer YOUR_JWT_TOKEN" } } } } ``` The OneFirewall tools will be available automatically in your next OpenCode session. *** ## Available Tools Full CTI profile for an IPv4 — crime score, MITRE ATT\&CK mappings, STIX2 bundles, member reports, and attack observations. Paginated real-time feed of all malicious IPs above a configurable crime score threshold. Ready for firewall/IPS ingestion. Submit threat intelligence on a malicious IP to the OneFirewall Alliance, contributing to the collective crime score. Status, configuration, active blocklist, and last sync time for all WCF firewall agents in your organisation. *** ## Tool Reference ### `get_ip_intel` Retrieve the complete intelligence profile for an IPv4 address. | Parameter | Type | Required | Description | | --------- | ------ | -------- | -------------------------------------------------------- | | `ipv4` | string | Yes | The IPv4 address to investigate (e.g. `"185.220.101.5"`) | **Example prompt:** > *"What does OneFirewall know about 185.220.101.5?"* **Returns:** crime score, MITRE ATT\&CK techniques, STIX2 bundles, number of Alliance members who reported it, agent observations, geolocation, ASN, and historical notes. *** ### `get_live_ipv4_feeds` Pull a real-time blocklist of malicious IPs above a minimum crime score. | Parameter | Type | Required | Default | Description | | ------------ | ------- | -------- | ------- | -------------------------------------------------- | | `min_score` | integer | Yes | — | Minimum WCF crime score (1–1000) | | `format` | string | No | `CSV` | `CSV` or `LIST` (comma-separated) | | `show_score` | string | No | — | `"yes"` to include score alongside each IP | | `page` | string | No | — | Pagination cursor from `next_page` response header | | `agid` | string | No | — | Scope feed to a specific WCF Agent ID | | `plugin` | string | No | — | Filter by IPS/plugin name | **Example prompt:** > *"Give me all IPs with a crime score above 200 in CSV format."* Responses are paginated. If the `next_page` header is present in the API response, pass that value as the `page` parameter to retrieve the next batch. *** ### `report_ip` Report an IP address as malicious to the OneFirewall Alliance. | Parameter | Type | Required | Default | Description | | ------------ | ------- | -------- | ------- | -------------------------------------------------------- | | `ip` | string | Yes | — | IPv4 address or CIDR network | | `confidence` | float | Yes | — | Confidence level: `0.0` (uncertain) → `1.0` (certain) | | `source` | string | Yes | — | Where the threat was observed (e.g. `"sshlog"`, `"ids"`) | | `notes` | string | No | — | Free-text description of the observed behaviour | | `decision` | integer | No | `-1` | `-1` = score-based, `0` = whitelist, `1` = blacklist | | `ttl` | integer | No | — | Unix timestamp after which the decision override expires | **Example prompt:** > *"Report 10.0.0.1 as malicious — I observed repeated SSH brute-force attempts, confidence 0.95, source 'sshlog'."* *** ### `get_agent_status` Retrieve the status of WCF firewall agents registered in your organisation. | Parameter | Type | Required | Description | | --------- | ------ | -------- | ---------------------------------------------------------------- | | `agid` | string | No | Agent ID to filter to a single agent. Omit to return all agents. | **Example prompt:** > *"Show me the status of all my firewall agents."* **Returns:** per-agent configuration (score threshold, sync interval, max rules), last sync timestamp, active blocklist, plugin name, and error codes. # v2026-08-02 - TAXII 2.1 Server Source: https://docs.onefirewall.com/releases/2026-08-02 OneFirewall threat intelligence is available through a TAXII 2.1 server, supporting both pulling and pushing STIX indicators. OneFirewall exposes its threat intelligence through a **TAXII 2.1 server**, alongside the existing REST API and STIX 2.0 lookup endpoint. Any TAXII 2.1-compatible client — MISP, OpenCTI, Anomali, or a custom ingestion pipeline — can discover, pull, and (new) **push** OneFirewall indicators using the standard TAXII discovery/collections model, instead of a custom integration against the REST feeds. *** TAXII 2.1 logo ## Pull: Discover and Sync Indicators * **Discovery** — `GET /taxii2/` returns the server title, description, and the available API Root. * **API Root** — `GET /taxii2/onefirewall/` exposes server-wide information and the supported TAXII version. * **Collections** — `GET /taxii2/onefirewall/collections/` lists three collections, each a live, consensus-scored view over OneFirewall's shared threat data: * `ip-indicators` — malicious IPv4 addresses * `domain-indicators` — malicious domains * `url-indicators` — malicious URLs * **Objects** — `GET .../collections/{collection-id}/objects/` returns STIX 2.1 Indicator objects, with standard `added_after`, `limit`, and `next` pagination for efficient incremental sync. * **Manifest** — `GET .../collections/{collection-id}/manifest/` returns lightweight `id`/`date_added`/`version` metadata without full object content, for clients that want to check what's changed before fetching. * **Single object lookup** — `GET .../collections/{collection-id}/objects/{object-id}/` fetches one indicator by its STIX id. Each Indicator is generated live from OneFirewall's own consensus scoring — IPv4 scores reflect real-time decay by age, exactly as they do in the REST feeds. Every indicator's STIX id is deterministic (derived from the indicator value itself), so repeated syncs are stable and safe to de-duplicate against. ## New: Push Indicators via TAXII Collections are now **writable**. `POST .../collections/{collection-id}/objects/` accepts a standard TAXII envelope of up to 50 STIX 2.1 Indicator objects per call and submits them through the same validation and scoring pipeline as the REST API — so a TAXII push behaves identically to a normal OneFirewall submission, just over the standard TAXII wire format. The server responds with a TAXII Status resource reporting per-object success or failure, so a client submitting a mixed batch can see exactly which indicators were accepted: ```json theme={null} { "id": "status--d5af6a72-9103-45df-88e3-53dd0b94b8e4", "status": "complete", "total_count": 2, "success_count": 1, "failure_count": 1, "successes": [{ "id": "indicator--f4ca1ddb-965a-54ff-85d9-a94da8e306fb" }], "failures": [{ "id": "indicator--bad", "message": "IP format is not valid" }] } ``` A TAXII submission always contributes to the shared consensus score — it never forces an explicit block/allow decision on your own firewall, and never auto-forwards to the OneFirewall Alliance network. Those remain deliberate, explicit actions via the REST API. ## Authentication & Access The TAXII server uses the same credentials as the rest of the OneFirewall API — no separate signup or key required: ```http theme={null} GET /taxii2/onefirewall/collections/ HTTP/1.1 Host: app.onefirewall.com Authorization: Bearer YOUR_TOKEN_HERE Accept: application/taxii+json;version=2.1 ``` * **Bearer JWT** (or HTTP Basic, for service accounts) — identical to REST API auth. * Requires your organization's plan to include **Threat Intel** access, same as the existing STIX lookup endpoint. * Reading objects/manifests is metered against your normal OneFirewall token balance; discovery and the collection listing are free. ## Summary * **Two-way interoperability** — pull the shared feed and push findings back into it through any TAXII 2.1-native platform, without building a custom REST integration. * **Standard pagination and filtering** — `added_after`/`next` behave the same as in other TAXII feeds. * **Shared authentication** — the same organization, token, and access scope work across the REST API, the STIX lookup endpoint, and TAXII. # v2026-08-18 - Live Traffic Source: https://docs.onefirewall.com/releases/2026-08-18 The Live Traffic dashboard gains attacker lead-time analysis, a threat origin map, drill-down IP intel, and batch ingestion Updates to the **Live Traffic dashboard**: attacker lead-time analysis, a threat origin map, per-IP drill-down, raw data access, and batch event ingestion. *** ## Attacker Lead Time by Severity A new heatmap cross-tabs every top attacker by severity against how long OneFirewall already knew about that IP before it reached you — from under an hour to over a year. * The **Top Attacks** table gains a **Known By OFA** column, showing how much lead time your Alliance membership gave you on each attacker (or `—` for an IP with no prior OneFirewall record). * This lets you see at a glance whether the attackers doing the most damage are ones the shared intel already flagged well in advance, or genuinely new actors. ## Threat Origin World Map The dashboard now includes a world map plotting where live attack traffic is originating from, alongside the lead-time heatmap and the existing device breakdown chart — all three now share one row (30% / 40% / 30%). ## IP Intel Drill-Down Clicking an IP anywhere in the Live Traffic tables now opens a **Threat Actor** modal with: * Full crime-score history chart for that IP * A connections table scoped to your organization — click any row to highlight the matching point on the score chart above * A link through to the IP's full intel profile ## Raw Data Debug View A new **Raw Data** button opens the latest 10 unfiltered documents for your organization straight from the index — no field remapping or aggregation — so you can sanity-check what's actually being ingested when a chart looks wrong. Backed by a new `GET /api/v1/graphs/traffic/raw` endpoint. ## Data Health: Unrecognized Actions Traffic where the `action` field doesn't match any of your configured allow/deny values was previously excluded from both counters silently. The dashboard's data health panel now surfaces these as an **"Unrecognized action value(s)"** warning, listing the offending values, so misconfigured action mappings are visible instead of quietly under-counted. ## Batch Traffic Ingestion `POST` to the live traffic endpoint now accepts either a single JSON document (unchanged) or an **array of documents**. Arrays are queued in-memory and drained one at a time by a FIFO worker, so bursts of events are processed in submission order without blocking the response — the endpoint replies immediately with `{"message": "queued", "queued": N}`. Auto-reported denied traffic can now also carry caller-supplied **tags**, merged with a fixed `live_traffic` tag on the resulting intel record. ## Crime Score Capping Crime scores are now consistently capped at **1000** everywhere they're calculated or displayed — IPv4 lookups, live traffic scoring, and the domain/files/index/IPv6 tables — fixing a few places where a very fresh, high-confidence score could render above the intended maximum. ## Also in this release * Dashboard risk badges, stat tiles, and severity table colors updated for better readability against the Defense Center attack chart. * The generated PDF report's attack summary now includes the same world map / device breakdown shown on the dashboard. # Automated Deployment Source: https://docs.onefirewall.com/releases/Automated-Deployment OneFirewall: Cloud-Native Solution with Automated Deployment via GitLab and Canary Strategy ## 1. Introduction OneFirewall is a cloud-native security platform designed to protect modern distributed environments. Built with a modular, scalable architecture, it integrates seamlessly with containerized infrastructures like Kubernetes. It supports frequent and reliable updates through a fully automated CI/CD pipeline using GitLab. ## 2. Cloud Native by Design Key architectural features: * **Containerization**: All components are Docker containers. * **Orchestration**: Designed for Kubernetes/OpenShift environments. * **Auto-Scaling**: Dynamic scaling based on load or cluster policies. * **Resilience**: Stateless, fault-tolerant microservices. * **Observability**: Integrated with tools like BetterStack and Elastic for metrics, logging, and tracing. These features ensure fast adoption, simplified management, and agile updates in distributed environments. ## 3. Git Strategy: Optimized GitFlow for Continuous Delivery OneFirewall uses a simplified GitFlow model adapted for Continuous Delivery: * `main`: Stable production branch; every commit triggers automatic deployment. * `develop`: Integration branch for E2E testing. * `feature/*`: For developing new features. * `hotfix/*`: For urgent production bug fixes. * `release/*`: For testing and validating candidate releases. Merges into `main` trigger CI pipelines with automated testing, security checks, and approval policies. ## 4. CI/CD and Automated Deployment via GitLab Runner The CI/CD system is built on GitLab using secure, dedicated runners. **Deployment Workflow:** 1. Push to `main` triggers the pipeline. 2. Runner validates the commit. 3. Docker containers are built, tested, and pushed to the registry. 4. Automated deployment via Helm (for Kubernetes) or Docker Compose. 5. Canary strategy ensures safe, progressive rollout. ## 5. Canary Deployment: Safe and Controlled Rolling Updates To reduce deployment risk, a canary strategy is used: * **Step 1**: Deploy to 5–10% of pods/instances. * **Step 2**: Monitor metrics, errors, and performance. * **Step 3**: Continue rollout if metrics are within thresholds. * **Step 4**: Auto-rollback on critical failures. **Benefits:** * Zero downtime * High reliability * Fast regression detection ## 6. Solution Benefits * **Rapid Time-to-Market**: Production releases in hours. * **Security**: Isolated, secure runners protect deploy secrets. * **Reliability**: Automated testing minimizes regression risk. * **Customization**: Supports multi-tenant deployments with client-specific configurations. ## 7. Conclusion OneFirewall is a modern security platform built for dynamic, distributed environments. With a strong DevOps foundation, optimized Git strategy, and safe canary deployments, it enables frequent, secure updates without service interruption—maintaining high standards of quality and security across all clients. # Enterprise-Grade Reliability Source: https://docs.onefirewall.com/releases/Enterprise-GradeReliability High availability (HA) OneFirewall Infra OneFirewall (WCF Server) is primarily composed of a set of software components that seamlessly intercommunicate to deliver a full suite of functionalities. Traditionally, these components are embedded within a single server and orchestrated using Docker Compose, including a local database. While this setup ensures a **99.99% SLI**, making it suitable for most use cases, certain critical infrastructure demands even higher reliability, reaching **four to six nines (99.9999% to 99.999999%)**. To meet these stringent requirements, we propose the implementation of the following **enhanced underlying infrastructure**. ## Requirements | **Component** | **Specification** | Notes | | ------------- | ----------------- | :-------------- | | **VMs** | 3 | k8s master/node | | **RAM** | 32 GB | for each VM | | **vCPU** | 24 | for each VM | | GPU | N/A | for each VM | | SSD | 1TB | for each VM | | NSF | 3TB | Shared | ## Connectivity | **Service** | **Specification** | Notes | | ------------ | ----------------- | :------------------------------------- | | **ALB** | against the 3 VMs | If possible, otherwise DNS round robin | | **VM** | 443 Inbound | For Web and API Access | | **VM** & NFS | Same subnet | for K8s connections | | VM | 22 Inbound | For management console | | VM | 443 Outbound | Via Proxy for updates on new feeds | ## ArchitectureEnterprise-GradeReliability # High Level Design Source: https://docs.onefirewall.com/releases/HighLevelDesign A High-Level Design (HLD) architecture of a OneFirewall (White-label) # **Introduction** OneFirewall WCF Platform brings together threat intelligence from multiple sources (Alliance), including government agencies, security vendors, and other organizations, and provides a centralized repository for this information # **OneFirewall System Components** All services are managed using a containerized solution and deployed on a Kubernetes cluster. The cluster can be a service-managed solution from a cloud provider or an on-premises installation using open-source solutions based on Rancher. * **onefirewall-server:** * The core server that exposes the APIs of OneFirewall. * Manages the UI functionalities of OneFirewall. * Implements authentication using a database-based mechanism. * Integrates authentication with OIDC providers: Google, GitHub, and Atlassian. * Stores threat intelligence data in time series format within an Elasticsearch cluster. * **onefirewall-elasticsearch:** * Manages threat intelligence data as time series. * Supports data storage on persistent block storage or NAS servers. * **onefirewall-db:** * Manages application data and configurations. * Handles Identity and Access Management (IAM) for platform users. * **onefirewall-rabbitmq:** * Acts as a message queue for data ingestion. * Manages synchronization of threat intelligence data with the OneFirewall cloud platform. * **onefirewall-queue-consumer:** * A server responsible for dequeuing messages from onefirewall-rabbitmq. * Interacts with the ingestion APIs in onefirewall-server via onefirewall-proxy. * **onefirewall-proxy:** * The API gateway for OneFirewall. * **onefirewall-wcf-agent:** * Implements integrations with various existing router/firewall solutions. * Supports both open-source and commercial firewall solutions. * **onefirewall-log-analyzer:** * Handles integration with various SIEM solutions. * Manages ingestion and processing of log data. * **onefirewall-cloud-sync:** * Synchronizes threat intelligence data. * Sends data packets to the message queue (onefirewall-rabbitmq). # Sizing Requirements (AWS) Source: https://docs.onefirewall.com/releases/SizingRequirements OneFirewall Solution Install ## | OFA Type | Size | SLA | Capability | License | | --------------------------- | ------------------------------------- | -------- | ------------------------------------------------------------- | --------------------- | | **P-Micro** (Collaudo/Test) | 8vCPU, 24/32GB RAM, 300GB SSD | 99% | No-High Availability | Trial License | | | | | 1 Tenant, no backup, 100-300 log/s | | | **P-0** | 8vCPU, 32GB RAM, 1000GB SSD | 99.9% | No-High Availability | Single Tenant License | | | | | 1 Tenant, up to 10 users, daily backup, 100-300 log/s | | | **P-1** | 3x 8vCPU, 3x 32GB RAM, 3x 10TB SSD | 99.999% | High Availability | Multi Tenant License | | | | | 2-6 Tenants, up to 15 users each, daily backup, 300-700 log/s | | | **P-2** | 3-5x 8vCPU, 3-5x 32GB RAM, 3x 1TB SSD | 99.9999% | High Availability | Multi Tenant License | | | | | 7+ Tenants, up to 30 users each, daily backup, 700-1600 log/s | | *** ## P-Micro **Purpose:** Testing infrastructure enabling the installation of the OneFirewall solution on a single VM. **Requirements and Costs:** | Resource | Cost (USD) | | ------------------------------------------------ | ---------------- | | 1 VM (EC2) or EKS single Node m6i.2xlarge (SPOT) | \$190/m | | 1 SSD (gp3) 300GB | \$34/m | | Cloud NAT internet update (100GB/month) | \$41/m | | Snapshot | N/A | | **Total Annual Cost** | **\$3.202/year** | *** ## P-0 (a.k.a. ProdSmall) **Purpose:** Small production deployments. **Requirements and Costs:** | Resource | Cost (USD) | | ---------------------------------------------- | ---------------- | | 1 VM (EC2) per AZ or EKS Multi Node (multi AZ) | \$148/m | | 1 SSD gp3 1000GB | \$145/m | | Cloud NAT internet update (100GB/month) | \$41/m | | External LoadBalancer 443 | variable | | Snapshot (1 per day) | - | | **Total Annual Cost** | **\$4.404**/year | *** ## P-1 (a.k.a. ProdMedium) **Purpose:** Medium-scale production deployments. **Requirements and Costs:** | Resource | Cost (USD) | | ---------------------------------------------- | ----------------- | | 3 VM (EC2) per AZ or EKS Multi Node (multi AZ) | \$445/m | | 3 SSD gp3 1000GB | \$437/m | | Cloud NAT internet update (100GB/month) | \$41/m | | External LoadBalancer 443 | variable | | Snapshot (1 per day) | - | | **Total Annual Cost** | **\$11.461**/year | *** ## P-2 (a.k.a. ProdEnterprise) **Purpose:** Enterprise-scale production deployments. **Requirements and Costs:** | Resource | Cost (USD) | | ------------------------------------------------ | -------------------- | | 3-5 VM (EC2) per AZ or EKS Multi Node (multi AZ) | \$741/m | | 3 SSD gp3 1000GB | \$437/m | | Cloud NAT internet update (100GB/month) | \$41/m | | External LoadBalancer 443 | variable | | Snapshot (1 per day) | - | | **Total Annual Cost** | **\$15.021.36**/year | The costs are estimated based on AWS pricing and may vary slightly if using other cloud providers. Additionally, these estimates do not include any potential discounts or savings. # 22,043 Events, One Day Source: https://docs.onefirewall.com/study-cases/22043-events-one-day A full 24-hour analysis window, from total parsed events down to unique threat actors, in a single narrative summary This is the summary view for the analysis window 2026-08-15 23:59:09 to 2026-08-16 23:59:09: **22,043** total parsed events, down 20% against the prior window, broken down into every category covered elsewhere in this report. *** ## The full chain in one place Of 22,043 total events, **4,477 (20.31%)** were blocked by Demo Org's own firewall and **1,511 (6.85%)** more were blocked through the checkpoint-ip integration. **16,055 (72.83%)** were permitted. Of that permitted traffic, **1,939 (8.80%)** was flagged and intercepted as malicious after the fact. Across the entire window, **1,723** unique threat actors were identified. ## Why 1,723 doesn't equal the sum of the other actor counts The severity table elsewhere in this report lists unique IP counts per band that don't add up to 1,723 when summed directly, because a single actor can generate events across more than one severity band or appear in both the blocked and permitted branches during the same window. 1,723 is the deduplicated total across the entire dataset, not a sum of the per-band figures. ## What a -20% change means here The prior-period comparison is carried at the top level of this summary, not buried in a footnote. A 20% drop in total parsed events changes the denominator every other percentage in this report is measured against, which is why it's surfaced before any of the breakdown figures. *** Proof of Value engagements produce this exact daily summary against a client's own edge traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # 526 Critical, Denied Source: https://docs.onefirewall.com/study-cases/526-critical-denied Breaking the traffic a firewall already blocked down by severity, to see what share of it was high-confidence to begin with This is the denied side of Demo Org's traffic, re-scored by severity: **526** Critical events and **257** High events, sitting alongside smaller Medium and Low segments, all inside traffic the firewall had already blocked before OneFirewall was introduced. *** ## Scoring what's already blocked, not just what got through Most of the gap-analysis material in this report focuses on permitted traffic that slipped past enforcement. This chart looks the other direction: of everything Demo Org's firewall already denied, how much of it corresponds to sources OneFirewall independently scores as Critical or High. A firewall's own deny log doesn't carry that distinction internally — a block is a block, regardless of whether the source has a Crime Score of 190 or 950. Re-scoring the denied traffic recovers that detail. ## Why this number is reassuring rather than alarming Unlike the permitted-and-malicious figures elsewhere in this report, 526 and 257 aren't a gap — they're confirmation. This is traffic the existing rule set was already right to block, now with a severity figure attached to it. Like the small "contributed value" slice in the enforcement-split chart, it confirms that a meaningful share of current blocking activity lines up with high-confidence scoring, rather than blind or overly broad rules. *** Proof of Value engagements re-score a client's own denied traffic in the same way. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # 670 Events, 549 Actors Source: https://docs.onefirewall.com/study-cases/670-events-549-actors Two figures that turn a severity breakdown into a specific, bounded response task Combining High and Critical severity from the same analysis window gives **670** events, 3.04% of permitted traffic, averaging 27.9 per hour, up **30%** against the prior comparison period. Behind those events sit **549** unique threat actors — distinct source IPs. *** ## Why these two numbers are grouped together 670 is an event count; 549 is a source count. Read together, they say something an event count alone doesn't: the high-severity traffic in this window isn't dominated by a small number of actors making repeated attempts, it's spread across a comparably large set of distinct sources — roughly 1.2 events per actor. That ratio matters for response planning, since it rules out the possibility of resolving most of the exposure by addressing one or two persistent IPs. ## The 30% is a change indicator, not a static count This figure is measured against the prior period, not presented as an absolute. An increase of this size in high-severity permitted traffic is the kind of shift a continuously running analysis surfaces immediately, rather than something that would only become visible on the next scheduled reporting cycle. ## What "permitted, then intercepted" means Both figures describe traffic the client's firewall already allowed through. OneFirewall's detection layer classified and intercepted it after the fact, which is why these numbers exist as a distinct category rather than being folded into the firewall's own blocked-traffic count. *** Proof of Value engagements surface this same event-to-actor ratio against a client's own high-severity traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Allowed vs Blocked Source: https://docs.onefirewall.com/study-cases/allowed-vs-blocked The first split in a Proof of Value analysis: how much traffic the client's own firewall let through versus stopped Of all traffic observed in this analysis window, the client's firewall allowed **16,055** events through and blocked **4,477**. This is the enforcement outcome on its own, before any OneFirewall scoring is applied. *** ## What this split does and doesn't say A ratio of roughly 78% allowed to 22% blocked describes how permissive the existing rule set is, not how accurate it is. A firewall can block a large share of traffic and still let scored, corroborated threats through, because static rules and geo/rate-based filters aren't built to evaluate an indicator's Crime Score. They enforce whatever was configured into them at some earlier point, independent of what the Alliance currently knows about a given source. ## Why this is the starting number Every other breakdown in this analysis (clean versus malicious, severity bands, unique threat actors) is a further cut of the **16,055** allowed events. This chart is the denominator everything else is measured against, and it's built entirely from traffic the client already logs, without any change to the existing firewall configuration. *** Proof of Value engagements produce this same split against a client's own edge traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Where Attacks Land Source: https://docs.onefirewall.com/study-cases/attack-origin-vs-enforcement Correlating the geography of attack origins against the specific enforcement points absorbing the traffic The map on the left shows attack volume by country of origin for the analysis window: **154** from the US, **28** from China, **16** from Brazil, with smaller counts distributed across dozens of other countries. The bar chart on the right shows blocked volume by the specific device that enforced it. *** ## Origin distribution A long tail of single- and double-digit counts spread across nearly every region, alongside concentration in a small number of countries, is consistent with botnet and residential proxy infrastructure rather than a small number of dedicated attackers operating from fixed locations. Proxy chains route through whatever IP space is available at the time, which is why origin alone is an unreliable basis for blocking: filtering by country either misses distributed traffic or over-blocks legitimate users routed through the same regions. Blocking by validated indicator addresses the behavior independent of routing. ## Enforcement points The bar chart names four separate devices: two Checkpoint deployments and two Fortigate deployments, each enforcing independently. Checkpoint-3472409 and Fortigate-infra1 each blocked roughly **3,400–3,600** events; Checkpoint-198365 close behind; Fortigate-infra2, covering a smaller segment of the environment, closer to **1,750**. All four are enforcing against the same underlying Crime Score feed. ## Mixed-vendor enforcement Environments running more than one firewall vendor typically maintain separate blocklists and separate update cycles per platform, which creates a gap between what one device knows and what another enforces. In this data, both vendors applied the same intelligence at the same time, so an indicator confirmed at one edge does not need to be independently rediscovered at another. *** Proof of Value engagements run this correlation across a client's existing mix of enforcement points. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Attack Origins Mapped Source: https://docs.onefirewall.com/study-cases/attack-origins-mapped Attack volume by country of origin for a single analysis window, plotted geographically Each number on this map is attack volume attributed to a country of origin for the same analysis window covered elsewhere in this report. The United States shows the highest count at **224**, followed by China at **93**, with dozens of other countries contributing counts in the single or low double digits — including clusters across South America, Southeast Asia, and Western Europe. *** ## A long tail is the expected shape A small number of countries carrying most of the volume, alongside a wide scatter of low counts everywhere else, is the typical signature of botnet and proxy infrastructure rather than a handful of attackers operating from fixed locations. Compromised hosts and proxy exit nodes exist wherever infrastructure happens to be available, which is why origin country is a weak basis for blocking on its own. Geo-blocking a high-count country stops a fraction of the volume, does nothing about the long tail, and risks blocking legitimate traffic routed through the same regions. ## What the map is useful for Origin data isn't the blocking mechanism here — the Crime Score is. What this map does provide is context: it shows where enforcement decisions driven by Crime Score are concentrated geographically, which is useful for understanding exposure by region even though the underlying decision to block is made per indicator, not per country. *** Proof of Value engagements map attack origins against a client's own traffic in the same way. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Clean vs Malicious Source: https://docs.onefirewall.com/study-cases/clean-vs-malicious Of the traffic a firewall already allowed through, how much OneFirewall's intelligence identifies as malicious Of the **16,055** events the client's firewall allowed through, OneFirewall's scoring identifies **14,116** as clean and **1,939** as malicious. *** ## Scoring after the fact, not instead of This isn't a re-evaluation of a blocking decision. It's a second, independent classification applied to traffic that already passed. The firewall made an allow/deny call based on its own rules; OneFirewall separately matches the same traffic against the Alliance's threat intelligence and Crime Score data. The two systems can disagree, and this chart is where that disagreement becomes visible: **1,939** events, roughly 12% of everything permitted, carried an indicator the existing rule set had no way to recognize. ## Where this number goes next **1,939** isn't a flat category. It's the starting point for the severity breakdown that follows: Low, Medium, High, and Critical. That breakdown is what turns "this was malicious" into a prioritized list of what to act on first. *** Proof of Value engagements run this same clean-versus-malicious split against a client's own permitted traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # One IP, a Dozen Industries Source: https://docs.onefirewall.com/study-cases/cross-sector-correlation A single malicious IP correlated across automotive, logistics, finance, and cloud infrastructure members spread over five countries At the center of this graph is one IP address, 31.77.227.120. Every line connects to an Alliance member that reported traffic from that address, independently and without coordination between members. *** ## Distribution across sectors The labeled nodes span an automotive company in the Netherlands, a logistics provider in the UK, a cybersecurity firm in the UK, a threat intel provider in Germany, a financial services firm in Italy, a cloud provider in Italy, a security partner in Rome, a GenAI security vendor in Serbia, a software house in the UK, and a set of anonymized members labeled M-1 through M-8. There is no shared vertical or supply-chain relationship among these organizations. The single connecting factor is that the same address was observed hitting all of them. ## Anonymized nodes Not every member's identity is exposed on a graph like this. The M-1 through M-8 nodes contribute their observation without an identifying label. The correlation weight is based on the observation being independently verifiable, not on the reporting member being named. ## Correlation across independent members This is the practical form of the Alliance Member Frequency factor in the Crime Score model. The financial services firm in Italy had no visibility into the automotive company in the Netherlands being hit by the same IP days earlier. Evaluated individually, each of these sightings resembles routine background scanning. Correlated, they describe a single actor working through unrelated targets across five countries. That pattern is only visible once the observations are pooled. *** Proof of Value engagements check whether a client's own traffic already correlates with sightings like these. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # What Gets Through Source: https://docs.onefirewall.com/study-cases/firewall-gap-analysis A gap analysis showing the traffic an existing firewall denies versus what quietly passes through it This chart comes from a Proof of Value run against an organization's edge, referred to here as Demo Org. The outer ring is a split between traffic the organization's own firewall passed (green) and traffic it denied (red). The inner ring breaks the denied traffic down by severity. *** ## Denied traffic is not automatically the right traffic Demo Org's existing rule set (geo-blocks, rate limits, static lists) was already stopping a measurable volume of traffic before OneFirewall was introduced. "Denied" and "denied because it was dangerous" are separate claims, however. The inner ring color-codes the denied segment by severity, and the callout marked **Affected Traffic**, pointing at **491** and **256** events, marks the boundary between what the existing rules caught and what fell just outside that boundary. ## Where the discrepancy originates A gap analysis compares total volume blocked against volume that should have been blocked based on current scoring. A rule set built on static entries doesn't have visibility into an indicator that nineteen independent Alliance members scored Critical an hour earlier. It only enforces what was configured into it at some earlier point. The affected traffic segment in this chart represents that lag: scored, corroborated activity the existing perimeter had no mechanism to recognize at enforcement time. ## Baseline before change This chart is typically the first output in an engagement because it establishes a baseline using traffic the organization already logs, without requiring a change to existing firewall configuration. It quantifies what current rules catch and what they don't, using the same data source the organization already has. *** Proof of Value engagements produce this same breakdown against a client's own firewall logs. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # HAProxy with Fluent Bit Source: https://docs.onefirewall.com/study-cases/fluentbit Integrating HAProxy Logs with OneFirewall Using Fluent Bit This guide shows you how to capture logs from an HAProxy Docker container, extract relevant fields, and forward them to OneFirewall's traffic validation API using Fluent Bit and Lua scripting. ## Overview * HAProxy logs are sent directly to Fluent Bit over UDP (syslog) * Fluent Bit extracts fields (like source IP and HTTP status) * Lua script transforms log into a JSON payload * Fluent Bit posts the data to OneFirewall's API *** ## 1. Folder Structure ``` project-root/ ├── docker-compose.yml ├── fluent-bit/ │ ├── fluent-bit.conf │ ├── parsers.conf │ └── send_to_onefirewall.lua ├── haproxy/ │ └── haproxy.cfg ``` *** ## 2. HAProxy Configuration ### `haproxy.cfg` ```cfg theme={null} global log fluent-bit:5140 local0 daemon defaults log global mode http option httplog timeout connect 5s timeout client 30s timeout server 30s ``` This configuration sends logs over UDP to Fluent Bit, which must be running in the same Docker network. *** ## 3. Fluent Bit Parser ### `parsers.conf` ```ini theme={null} [PARSER] Name haproxy_raw Format regex Regex ^<\d+>\w+\s+\d+\s+\d+:\d+:\d+\s+haproxy\[\d+\]: (?\d+\.\d+\.\d+\.\d+):\d+ \[[^\]]+\] \S+ \S+ \d+/\d+/\d+/\d+/\d+ (?\d{3}) ``` *** ## 4. Lua Script for Transformation ### `send_to_onefirewall.lua` ```lua theme={null} function escape(s) s = string.gsub(s, '\\', '\\\\') s = string.gsub(s, '"', '\\"') return s end function cb_send(tag, ts, record) local src_ip = tostring(record["src_ip"]) local action = tostring(record["action"]) if not string.match(src_ip, "^%d+%.%d+%.%d+%.%d+$") then return -1 end local json = string.format( '{"src_ip":"%s","dst_ip":"192.168.0.1","src_port":3435,"dst_port":443,"service":"myservice","firewall":"haproxy","action":"%s","direction":"inbound"}', escape(src_ip), escape(action) ) return 1, ts, { body = json, headers = {} } end ``` *** ## 5. Fluent Bit Configuration ### `fluent-bit.conf` ```ini theme={null} [SERVICE] Flush 1 Log_Level info Parsers_File /fluent-bit/etc/parsers.conf [INPUT] Name syslog Mode udp Listen 0.0.0.0 Port 5140 Parser haproxy_raw Tag haproxy.syslog [FILTER] Name lua Match haproxy.* script /fluent-bit/etc/send_to_onefirewall.lua call cb_send [OUTPUT] Name http Match haproxy.* Host app.onefirewall.com Port 443 URI /api/v1/poc_traffic/direct Format msgpack tls On tls.verify On Header Authorization Bearer YOUR_TOKEN_HERE Header Content-Type application/json Body_Key body Headers_Key headers Compress off [OUTPUT] Name stdout Match * Format json_lines ``` *** ## 6. Docker Compose Example ```yaml theme={null} version: '3.8' services: haproxy: image: haproxy:lts-alpine3.21 container_name: haproxy ports: - "443:443" depends_on: - fluent-bit command: > sh -c "haproxy -f /usr/local/etc/haproxy/haproxy.cfg" volumes: - ./haproxy/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg fluent-bit: image: fluent/fluent-bit:2.1 container_name: fluent-bit ports: - "5140:5140/udp" volumes: - ./fluent-bit:/fluent-bit/etc ``` > Ensure both containers are on the same network (Docker Compose does this by default). *** ## 7. OneFirewall Traffic Validation When Fluent Bit sends structured traffic data to OneFirewall: * OneFirewall **validates `src_ip` and `dst_ip` fields** * Invalid or private IPs are rejected with: ```json theme={null} { "message": "Not valid SRC or DST IP" } ``` * Ensure you're using valid **public IPv4 addresses** for testing. *** ## Result With this setup in place, HAProxy logs flow to Fluent Bit over UDP, get parsed and transformed into JSON by the Lua script, and are posted directly to OneFirewall's traffic validation API. *** ## Notes * Replace `YOUR_TOKEN_HERE` with your actual OneFirewall token * Consider adding retry/failure handling or S3 backup for production * Ensure `dst_ip` is not a private/local IP unless OneFirewall allows it *** ## Need Help? Reach out to [OneFirewall Support](https://app.onefirewall.com) if you need help debugging HTTP integration or validating traffic. # Mapping the Alliance Source: https://docs.onefirewall.com/study-cases/global-intelligence-network What a live map of OneFirewall Alliance members reveals about the value of shared threat intelligence Each dot on this map is a OneFirewall Alliance member or contributing source, sized by activity and colored by role. Each green line is a correlation: the same actor observed against two or more members within a time window close enough to indicate common origin rather than coincidence. *** ## Why correlation is the relevant unit, not the dot A single organization only observes the traffic that reaches its own edge. If an IP scans a SaaS platform in Frankfurt on Monday and hits a logistics company in São Paulo on Wednesday, neither organization has enough information on its own to know it's the same source. Each event is logged and closed independently. Cross-member correlation changes what's visible. When two members log traffic from the same address within a correlated window, OneFirewall links the two observations and adjusts the confidence assigned to that indicator. This is the **Cross-Member Temporal Correlation** factor in the Crime Score model: it's a direct input into how a score is calculated, not a separate visualization layered on top. ## Reading the density The concentration of dots over North America, Western Europe, and parts of Asia reflects where the Alliance currently has the most members and sensors reporting, not where all attack traffic originates. Coverage is a function of participation. A sparse region on the map is a gap in the dataset, not a low-risk area. Additional members reporting from that region shorten the interval between an indicator being observed and being enforced elsewhere. ## Operational effect For a single firewall relying only on its own logs, an indicator has to be observed locally before it can be acted on. With cross-member correlation, the same indicator can already carry a Crime Score derived from sightings at other members before it reaches a given perimeter. *** Proof of Value engagements run this same correlation against a client's own edge traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # HAProxy MITRE ATT&CK Source: https://docs.onefirewall.com/study-cases/haproxy-fluentbit-mitre-pattern-detection Forward HAProxy traffic logs to OneFirewall through Fluent Bit for MITRE ATT&CK pattern detection and IPS reporting This guide explains how to configure HAProxy and the OneFirewall Fluent Bit adapter to collect HTTP traffic logs, forward them to OneFirewall, and enable pattern detection aligned with MITRE ATT\&CK techniques. ## Overview The integration uses HAProxy as the ingress point and Fluent Bit as the log collection and forwarding layer. * HAProxy emits structured access logs with the `HAPROXY_LOG` prefix. * Fluent Bit receives HAProxy syslog events over UDP. * The OneFirewall Fluent Bit adapter parses the records using `catchall_parser`. * OneFirewall analyzes the traffic for malicious behavior and pattern detection mapped to MITRE ATT\&CK. * Optional IPS reporting can send suspicious IP intelligence back to the OneFirewall cloud. ## 1. HAProxy Logging Configuration Update the `global` section of your `haproxy.cfg` to send logs both to stdout and to the Fluent Bit adapter over UDP. ```cfg theme={null} global log stdout format raw local0 log 172.17.0.1:31514 local0 ``` The UDP destination must match the host and port exposed by the Fluent Bit adapter. In the Docker Compose example below, Fluent Bit listens on `172.17.0.1:31514` and forwards UDP traffic to container port `514`. ## 2. HAProxy Frontend Configuration In the HAProxy frontend, capture the relevant request headers and define a log format that the OneFirewall Fluent Bit adapter can parse. ```cfg theme={null} frontend balancer bind :80 bind *:443 ssl crt /certs/ingress-ofa.pem timeout http-keep-alive 10s capture request header x-forwarded-for len 200 capture request header Host len 64 capture request header Cf-Pseudo-IPv4 len 64 http-request deny if { hdr_ip(X-Forwarded-For) -f /ofa/ofa.csv } http-request set-var(txn.xff) req.hdr_ip(X-Forwarded-For,1) acl xff_private var(txn.xff) -m ip 192.168.0.0/16 10.0.0.0/8 172.16.0.0/12 127.0.0.0/8 http-request set-log-level silent if xff_private || !{ var(txn.xff) -m found } log-format "HAPROXY_LOG %[var(txn.xff)] %ci %cp %fp %H \"%r\" %ST" ``` The last two directives are required for OneFirewall pattern detection: * `http-request set-var(txn.xff) hdr(X-Forwarded-For)` stores the original client IP from the `X-Forwarded-For` header. * `log-format "HAPROXY_LOG ..."` emits a predictable log structure containing the original IP, connection metadata, HTTP protocol, raw request, and status code. The resulting log fields are: | Field | Description | | ----------------- | ----------------------------------------- | | `HAPROXY_LOG` | Static prefix used by the parser | | `%[var(txn.xff)]` | Original client IP from `X-Forwarded-For` | | `%ci` | HAProxy client IP | | `%cp` | Client source port | | `%fp` | Frontend destination port | | `%H` | HTTP protocol version | | `%r` | Full HTTP request line | | `%ST` | HTTP response status code | ## 3. OneFirewall Fluent Bit Adapter Add the OneFirewall Fluent Bit adapter to your Docker Compose stack. ```yaml theme={null} onefirewall-fluentbit-adapter: image: registry.onefirewall.com/onefirewall-fluentbit-adapter:v2 environment: FIREWALL_PARSER: "catchall_parser" LOG_LEVEL: "info" # debug, info, warn, error ENABLE_STDOUT: "*_ofa_logs" DEBUG_LUA: "false" FLUSH_INTERVAL_SECONDS: "5" # 5 seconds OFA_EVENTS_FLUSH_INTERVAL: "5" OFA_POLL_INTERVAL_HOURS: "1" OFA_JWT_TOKEN: "TOKEN_OFA" OFA_API_URL: "https://app.onefirewall.com or http[s]://localhost:PORT" OFA_MIN_SCORE_TO_LOG: "2" OFA_LAST_EVENTS: "2000000" OFA_MEMBER_ID: "OFA-GID-" OFA_API_URL_CLOUD: "https://app.onefirewall.com" OFA_JWT_TOKEN_CLOUD: "OFA_TOKEN_FOR_IPS_REPORT" OFA_AGENT: "haproxy_waf" OFA_AGENT_TAGS: "report_xxxxx" OFA_CONTRIBUTE: "0" OFA_IPS_FLUSH_INTERVAL: "300" # 5 minutes OFA_IPS_LIMIT: "1000" OFA_IPS_WORDS: "ofa_warning" # lowercase, comma-separated values OFA_IPS_PORTS: "443" SEND_TRAFFIC: "yes" ENABLE_ELASTIC_OUTPUT: "*_ofa_logs_OFF" ELASTIC_IP: "192.168.2.100" ELASTIC_PORT: "39220" ELASTIC_INDEX: "poc_traffic" ports: - "172.17.0.1:31514:514/udp" ``` For `OFA_API_URL`, provide only the protocol, host, and optional port, for example `https://app.onefirewall.com` or `http://localhost:8080`. Do not include the API path; the adapter resolves the required endpoint automatically. ## 4. Environment Variables | Variable | Purpose | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | `FIREWALL_PARSER` | Selects the parser used by the adapter. Use `catchall_parser` for this HAProxy log format. | | `OFA_JWT_TOKEN` | Token used to authenticate with the target OneFirewall API. | | `OFA_API_URL` | OneFirewall API base URL cloud or local installation for clients. Use only protocol, host, and optional port. | | `OFA_MIN_SCORE_TO_LOG` | Minimum score required before events are logged by the adapter. | | `OFA_MEMBER_ID` | OneFirewall member identifier, used when sending data directly to Elasticsearch. | | `OFA_API_URL_CLOUD` | OneFirewall cloud URL used for IPS partner reporting, or local client installation if partner contribute or not to the OneFirewall Alliance | | `OFA_JWT_TOKEN_CLOUD` | Token used for IPS report submission to the OneFirewall cloud. | | `OFA_AGENT` | Agent type reported to OneFirewall. For HAProxy WAF deployments, use `haproxy_waf`. | | `OFA_AGENT_TAGS` | Tags associated with the generated reports. | | `OFA_CONTRIBUTE` | Enables or disables contribution mode. Use `0` to disable contribution. | | `OFA_IPS_FLUSH_INTERVAL` | Interval, in seconds, used to flush IPS reports. | | `OFA_IPS_LIMIT` | Maximum number of IPS items sent per flush. | | `OFA_IPS_WORDS` | Keywords used to select IPS events. Values must be lowercase and comma-separated. | | `OFA_IPS_PORTS` | Ports associated with IPS reporting. | | `SEND_TRAFFIC` | Enables traffic forwarding to OneFirewall when set to `yes`. | | `ENABLE_ELASTIC_OUTPUT` | Enables or disables Elasticsearch output routing. | | `ELASTIC_IP`, `ELASTIC_PORT`, `ELASTIC_INDEX` | Elasticsearch destination settings when direct Elasticsearch output is enabled. | ## 5. MITRE ATT\&CK Pattern Detection Flow With this configuration, HAProxy provides enough context for OneFirewall to analyze web traffic and detect suspicious patterns. ```mermaid theme={null} flowchart LR Client[Client / Attacker] --> HAProxy[HAProxy Ingress] HAProxy -->|UDP syslog: HAPROXY_LOG| FluentBit[OneFirewall Fluent Bit Adapter] FluentBit -->|Parsed traffic events| OFA[OneFirewall] OFA --> Detection[MITRE ATT&CK Pattern Detection] Detection --> Reports[Events, IPS Reports, Optional Elasticsearch] ``` The `HAPROXY_LOG` records allow OneFirewall to evaluate request behavior such as suspicious paths, attack tooling, anomalous source IPs, abusive request patterns, and other indicators associated with MITRE ATT\&CK techniques. ## 6. Validation Checklist After deploying the configuration, verify the following: * HAProxy starts successfully with the updated `global` and `frontend` configuration. * UDP port `31514` is bound on `172.17.0.1` by the Fluent Bit adapter. * HAProxy logs contain the `HAPROXY_LOG` prefix. * The Fluent Bit adapter logs show parsed records matching `*_ofa_logs`. * OneFirewall receives traffic events from the `haproxy_waf` agent. * IPS reporting is enabled only when `OFA_API_URL_CLOUD` and `OFA_JWT_TOKEN_CLOUD` are configured with valid cloud credentials. ## Result Once enabled, HAProxy keeps serving traffic while emitting structured logs OneFirewall can act on. The Fluent Bit adapter forwards those events for MITRE ATT\&CK pattern detection, with optional IPS reporting and Elasticsearch output depending on which environment variables are set. # How Old Are Your Threats Source: https://docs.onefirewall.com/study-cases/how-old-are-your-threats Cross-tabulating High and Critical events by how long the underlying indicator has been known, alongside where the traffic originated and which device stopped it The table on the left sorts every High and Critical event by the age of the indicator behind it — how long ago that source was first observed, not how long ago the event itself happened. *** ## Reading the age buckets The counts run from **less than 1 hour** old up to **more than 1 year** old: 1 High / 1 Critical in the newest bucket, climbing to **93 High / 118 Critical** in the 1–7 day range, tapering through the older buckets down to **45 High / 102 Critical** for indicators first seen over a year ago. Two things stand out. First, the 1–7 day bucket carries the highest volume in both columns: most of the current High and Critical activity comes from sources that are recent, not long-tenured signatures on a static list. Second, the over-a-year bucket is not small. 102 Critical events are tied to sources with a track record stretching back more than twelve months, meaning the score never fully decayed because the source kept generating validated activity recently enough to stay elevated. ## Why age matters alongside severity A Critical score by itself says how confident the system is that a source is malicious right now. Age adds a second axis: whether that's a source that just appeared, or one that's been through the decay model repeatedly and kept re-triggering it. A 1–7 day Critical indicator and a >1 year Critical indicator carry the same enforcement weight, but they describe different attacker behavior: one is a fresh campaign, the other a persistent source that has never gone fully quiet. ## The origin map and device breakdown alongside it The map in the middle and the bar chart on the right cover the same ground as the origin and enforcement-point breakdowns elsewhere in this report — geographic concentration, with the US region carrying the highest count at 266, and blocked volume split across the same four devices (Checkpoint-3472409, Checkpoint-198365, Fortigate-infra1, Fortigate-infra2). They're included here as the surrounding context for the age data, not a separate finding. *** Proof of Value engagements produce this same age-versus-severity breakdown against a client's own traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Malicious, Ranked Source: https://docs.onefirewall.com/study-cases/malicious-ranked Breaking the permitted-and-malicious traffic total down into severity bands so it can be triaged, not just counted The **1,939** permitted events flagged as malicious split into four severity bands: **Low 731**, **Medium 538**, **High 245**, **Critical 425**. *** ## A single number hides the decision "1,939 malicious events got through" is a headline. It isn't a task list. Treating all 1,939 the same way means either over-reacting to low-risk noise or under-reacting to the 425 events that carry the highest confidence of active compromise attempts. The severity band is derived from the Crime Score assigned to the source, so this breakdown reflects the same scoring logic used everywhere else in the platform, not a separate categorization built for this chart alone. ## What separates the bands in practice Low and Medium severity traffic is typically worth logging and reviewing on a normal cadence: reconnaissance-adjacent activity from sources with a thinner track record. High and Critical, together **670** events here, represent sources with enough independent corroboration and score to warrant a blocking decision without waiting for further evidence. *** Proof of Value engagements produce this same severity breakdown against a client's own malicious traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # 35.000 attacks daily Source: https://docs.onefirewall.com/study-cases/member-x How OneFirewall blocked 35,000 daily attacks against a B2B SaaS platform running across Azure, DigitalOcean, and GCP A OneFirewall member (referred to here as Member X) runs a B2B SaaS platform serving clients globally, hosted across three cloud providers: Azure, DigitalOcean, and GCP, with two instances in Europe and one in the US. *** ## Background As Member X's business grew, so did its exposure to attacks. 22% of incoming traffic was performing unauthorized operations, and an average of 35,000 attacks per day targeted web services and management consoles. The existing security setup had clear gaps: Cloudflare's free plan handled CDN without advanced security features, management consoles were reachable directly without a VPN, and there was no capability to detect advanced threats. Member X needed a fix within 24 hours, without reworking its technology stack. ## What happened OneFirewall started by analyzing the attack traffic: high-frequency automated bot traffic, brute-force attempts against SSH, and application-layer attacks on web services. Threat sources were scored using OneFirewall's Crime Score metric, and any source scoring above 120 was prioritized for blocking. Within 24 hours, OneFirewall deployed ACLs to block IPs scoring above 120, whitelisted remote access to approved IP ranges, adjusted traffic routing and CDN configuration to reduce the attack surface, and hardened web ingress points using the gathered threat intelligence. ## Result All traffic from IPs with a Crime Score above 120 was blocked, eliminating the 35,000 daily unauthorized requests. Latency dropped 28%, since malicious traffic was filtered at the edge before reaching the application. SSH brute-force attempts and the identified web application attacks were both stopped automatically, without manual intervention. Member X's own traffic also fed back into the network: the integration added over 12,000 new threat feed entries per day, including 0.49% of threats not previously detected by other Alliance members. # Across the Kill Chain Source: https://docs.onefirewall.com/study-cases/mitre-kill-chain-visibility A single actor's activity mapped across ten of the fourteen MITRE ATT&CK tactics, from first scan to lateral movement This view organizes a single actor's activity into MITRE ATT\&CK categories rather than a single alert. The activity spans a large portion of the framework. *** ## Category breakdown **Report** covers the raw detections that opened the case: a port scan, a hit against the Emerging Threats "known compromised or hostile host" list, and Resource Development, MITRE's term for infrastructure setup preceding the main activity. **Brute Force** groups four related detections: brute force on the SSH service, service brute force generally, and password guessing as its own attack pattern. **Service** lists the ET COMPROMISED hits again, tied specifically to SSH as the targeted remote service. **Tactic** summarizes the case: ten distinct MITRE ATT\&CK tactics, Reconnaissance, Resource Development, Initial Access, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Command and Control, and Impact. ## Scope of the activity MITRE ATT\&CK defines fourteen tactics spanning an intrusion from initial reconnaissance to impact on the target. An actor touching ten of them against a single organization indicates a sustained campaign that progressed past an initial SSH brute-force attempt rather than a single scan that happened to be logged. The "ET COMPROMISED" tag originates from the Emerging Threats open ruleset, independent of OneFirewall's own scoring. The host was already flagged by a separate detection engine before this correlation was built. ## Effect on response Treating each of these detections as a separate SSH alert results in addressing symptoms individually. Viewing them as one actor's progression through Credential Access into Lateral Movement and Command and Control changes the response to address the intrusion as a whole, rather than the login attempts that happened to trip a threshold first. *** Proof of Value engagements map incidents like this one across the full kill chain rather than as isolated alerts. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Indicator to Action Source: https://docs.onefirewall.com/study-cases/mitre-mitigation-mapping How a single flagged campaign gets traced across countries, corroborated by independent sources, and mapped to concrete MITRE ATT&CK mitigations This is one attack campaign shown from two angles. On the left, the countries it reached: Italy, Germany, Spain, the UK, the US, Serbia, France, and the Netherlands. On the right, the classification of the activity as MITRE ATT\&CK attack patterns and courses of action rather than a single severity label. *** ## Source diversity The sources that flagged this activity include Olidata, an Italian MSP partner; Blocklist.de's fail2ban reporting service; Suricata-based network detection; DeceptionGrid, a honeypot network with no legitimate traffic to hide behind; and AquilaX, an AI-driven software security source, among others. These are distinct source types (public blocklists, commercial partners, honeypots, AI-assisted detection) with no operational relationship to one another. Independent agreement across source types is a factor in the trust weighting applied when a Crime Score is calculated. ## Classification, not just a score The right panel classifies the campaign into MITRE ATT\&CK attack patterns (password guessing is shown as one example) paired with courses of action that map to specific configuration changes: account lockout policies against brute forcing, port closure and network segmentation against service scanning, file and process permission hardening against service-stop attempts, and credential-handling controls against valid-account abuse. ## Score versus technique A Crime Score indicates confidence that an asset is malicious. MITRE ATT\&CK mapping indicates which technique is in use, and therefore which control addresses it. Blocking the IP addresses this instance. Applying the mapped course of action addresses the technique, which remains relevant the next time a different IP uses the same approach. *** Proof of Value engagements map campaigns like this one against a client's own logs. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # One IP, 16,199 Reports Source: https://docs.onefirewall.com/study-cases/one-ip-16199-reports A full score card for a single indicator: zero local events, a year of activity, and inconsistent enforcement across an agent fleet This is a single IPv4 address, assigned to ASN AS4837 (China Unicom) and originating from China: a **Crime Score of 432**, flagged **Critical**, backed by **16,199 reports** from **28 Alliance members** contributing **76 unique IoC points**, first seen **over a year ago**, and last active **27 minutes** before this lookup. *** ## Zero local events, still Critical The "Reported Events" panel on this card shows zero — this organization has never logged traffic from this address itself. The Critical classification comes entirely from the other 27 members who have. That's the practical effect of cross-member correlation: an indicator can arrive at a perimeter pre-scored as dangerous, before it ever shows up in that organization's own logs. ## Protection isn't uniform across the fleet Ten enforcement agents are tracked against this indicator. Five show as Protected — a mix of Checkpoint deployments and a Fortinet device. Five show as Exposed, including a perimeter firewall in one data center. Same organization, same threat data, same score — but the block isn't applied everywhere yet. That gap is exactly what a policy sync across the fleet is meant to close. ## A year of activity, no decay The historical chart behind this score covers 103 snapshots over roughly a year, trending upward rather than flattening out. Crime Scores decay when an indicator goes quiet; this one hasn't, because it keeps generating fresh reports — the most recent one 27 minutes before this lookup. A year-old indicator that's still active scores differently than one that spiked once and disappeared. *** Proof of Value engagements surface indicators like this one already present in a client's own traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # One IP, 19 Members, 7 Countries Source: https://docs.onefirewall.com/study-cases/one-ip-19-members What a single correlation graph looks like when independent Alliance members across seven countries flag the same indicator This is one IPv4 address, shown at the center of its own correlation graph: **19 independent Alliance members** reported it, spanning **7 countries** — Netherlands, Spain, Germany, USA, UK, Ukraine, and Italy — plus **12 additional members** shown only as anonymized private nodes (M-1 through M-12). *** ## Same indicator, independent sightings Every line on this graph is a separate organization that logged traffic from this address on its own edge, with no visibility into who else was seeing the same thing. None of these 19 members coordinated with each other before the correlation happened — OneFirewall links the sightings after the fact, based on the shared indicator and a correlated time window. That's what turns 19 isolated log entries into one graph. ## Anonymized members still contribute Twelve of the nineteen nodes carry no country flag or organization name — just a private label (M-1 through M-12). Contributing an observation to the Alliance doesn't require disclosing who you are. A member can report an indicator, have it factored into the Crime Score, and stay off any public-facing map. This matters for organizations that don't want their own exposure visible to competitors or to the attacker. ## The same address, unrelated sectors The public nodes on this graph aren't clustered in one industry. The tags attached to them include a GenAI platform, an automotive company, a logistics provider, a software house, a financial services firm, a cloud provider, and a honeynet — alongside dedicated threat intel and CTI organizations. A single sector's isolated monitoring would have caught one hit each. Correlating across all of them is what surfaces the same address as a repeat offender rather than seven unrelated one-off events. *** Proof of Value engagements run this same cross-member correlation against a client's own edge traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Passed vs Denied Source: https://docs.onefirewall.com/study-cases/passed-vs-denied The same enforcement split as a radial chart, with severity broken out inside both the passed and denied branches This radial chart lays out the same two branches covered elsewhere in this report — traffic passed by Demo Org and traffic denied by Demo Org — but keeps the severity bands visible inside both, rather than only inside the passed branch. *** ## Two branches, same severity scale The outer green band on the right is traffic passed by Demo Org's firewall. The segmented band on the left is traffic denied by Demo Org, broken into the same Low, Medium, High, and Critical bands used throughout this analysis, with **425** Critical and **245** High events called out specifically. Both branches are scored using the same Crime Score thresholds, which is what makes it possible to compare severity across an enforcement boundary instead of only within one side of it. ## The thin green segment A narrow green slice sits at the boundary between the two branches — a small amount of already-denied traffic that OneFirewall's scoring also assessed as clean. It's a minor share of the total, and it functions as a cross-check on the existing rule set rather than a finding that needs action: traffic the firewall blocked and OneFirewall independently agrees was not malicious. ## Why the same data appears twice in this report This chart and the enforcement-split donut cover the same underlying numbers from different angles. The donut answers "how much was passed versus denied." This one answers "how severe was the traffic on each side of that decision," which is the detail a flat pass/deny ratio doesn't carry on its own. *** Proof of Value engagements produce this same breakdown against a client's own firewall decisions. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # 24 Hours of Proof Source: https://docs.onefirewall.com/study-cases/proof-of-value-24-hours A 24-hour analysis window from a OneFirewall Proof of Value engagement, broken down metric by metric This is a single 24-hour window from a Proof of Value engagement, covering 2026-08-13 12:47:14 to 2026-08-14 12:47:14. No production traffic was altered and no firewall rules were changed; edge logs already being generated were mirrored and analyzed for the duration of the window. *** ## Event breakdown **11,979** events were parsed. **2,275 (18.99%)** were already blocked by the client's own firewall, and **974 (8.13%)** more were blocked by an existing checkpoint-ip integration. The remaining **8,730 (72.88%)** were permitted. Of that permitted traffic, **1,062 (12.16%)** was flagged as malicious, from **1,000 distinct sources**, a near one-to-one ratio between flagged events and unique attackers, consistent with broad opportunistic scanning rather than a single persistent actor. Of the flagged events, **303** were Critical (immediate action), **142** High (blocking recommended), and **617** Medium or Low (routed for review). ## Trend indicator The dashboard also shows a **-20%** change on total parsed events versus the prior comparison window. A drop of that size can reflect a legitimate change in traffic patterns, or an attacker shifting to a different vector after being blocked elsewhere. A continuous monitoring window surfaces that kind of shift; a report generated on a monthly cycle would not. ## What the window represents This output corresponds to the standard Proof of Value process: a VM deployed against real edge traffic, logging continuously, matched against the Alliance's threat intelligence, producing a volume breakdown, a split between traffic already blocked and traffic that wasn't, and a severity-ranked list of what remains. *** Proof of Value engagements produce this same report against a client's own traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # One IP, 13,287 Reports Source: https://docs.onefirewall.com/study-cases/reading-a-crime-score Breaking down a single indicator of compromise and what four months of accumulated intelligence look like in practice This is a single IPv4 address, looked up on demand: a **Crime Score of 546**, flagged **Critical**, backed by **13,287 reports** from **19 members**, contributing **35 CTI points**, first observed **four months prior**, and last active **26 minutes** before this lookup. *** ## Score composition A Crime Score is a weighted correlation across independent Alliance members, each carrying a trust weight based on historical accuracy and false-positive rate, combined with confidence metadata describing how the activity was validated. An observed exploitation attempt is weighted differently from a heuristic suspicion. Nineteen members independently reporting the same address over four months is what places the score in the Critical range rather than a single flagged event. ## Persistence versus decay IPv4 Crime Scores decay over time when no new activity is observed, accounting for infrastructure churn, botnet reassignment, and host remediation. This address has not decayed: it registered a new attack 26 minutes before the lookup, on top of four months of continuous activity. The combination of a long track record and current activity distinguishes an indicator warranting active blocking from one that was flagged once and has since gone quiet. ## Hosting provider is not a scoring input The ASN attached to this indicator belongs to Alibaba's US technology arm. Cloud infrastructure from major providers is regularly abused, and provenance alone is a weak signal since legitimate traffic originates from the same ASNs. The three feeds marked "Protected" in this panel (two Checkpoint deployments and one Fortinet deployment, with six more not shown) already have this indicator enforced. Policy was applied automatically based on the score, not a manual review of the ASN. *** Proof of Value engagements surface indicators like this one already present in a client's own traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # 561 Attacks, 30 Minutes Source: https://docs.onefirewall.com/study-cases/real-time-attack-visibility Reading the metrics behind a 30-minute attack window from a live threat intelligence feed This panel covers a single 30-minute window. In that window, OneFirewall logged **561 attacks**, with the highest-scoring source an IP out of Hong Kong routed through LARUS Limited's AS, carrying a Crime Score of **522**. *** ## Source composition Two of the reporting sources listed are public fail2ban aggregators: Blocklist.net.ua and Blocklist.de. These services report IPs currently attempting SSH and login brute-forcing against a broad, independently monitored host pool. That's the input class threat intelligence in this system is built from: observed, repeated hostile behavior reported by third parties, correlated alongside Alliance member submissions. ## Volume and update frequency The panel reports **47,797 new IPs first seen**, up **19%** over the comparison period, and **454,298 submissions**, up **304%**. A spike of that size typically indicates either infrastructure cycling through fresh IP ranges or a scanning campaign sweeping in a large batch of previously unflagged hosts. A blocklist updated once a day would lag behind a change of this magnitude before it could be pulled and applied. The submission rate reflects how quickly new indicators become available for enforcement. ## Sources and infrastructure Top reporting countries for this window were the Netherlands, the US, Romania, and Singapore, with **UNMANAGED LTD (AS47890)** identified as the top offending ASN. The bar chart shows how much of this traffic was matched and blocked across the enforcement types already in place: Checkpoint and Fortinet feeds, with the same intelligence enforced consistently across both. *** Proof of Value engagements analyze a client's own edge traffic against this feed. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Severity at a Glance Source: https://docs.onefirewall.com/study-cases/severity-at-a-glance The full severity table behind the summary charts, with score ranges, event share, and unique IP counts for each band This table is the source data behind the severity donuts elsewhere in the same analysis: four bands, each defined by a Crime Score range, with event counts, share of total traffic, share of permitted traffic, and unique IP counts. *** ## Reading the columns **Low** (score 1–60) accounts for 731 events, 3.32% of total traffic, 4.55% of permitted traffic, and 729 unique IPs. **Medium** (60–120) accounts for 538 events, 2.44% total, 3.35% permitted, 445 unique IPs. **High** (120–175) accounts for 245 events, 1.11% total, 1.53% permitted, 204 unique IPs. **Critical** (175–1000) accounts for 425 events, 1.93% total, 2.65% permitted, 345 unique IPs. ## Why unique IPs matter alongside event counts Low severity has the highest event count but also the highest ratio of unique IPs to events — 729 IPs behind 731 events, close to one-to-one, consistent with broad, low-intensity scanning from many distinct sources. Critical severity shows more repetition per source (345 IPs behind 425 events), which is more consistent with a smaller set of actors making repeated attempts. The same event count can describe very different attacker behavior depending on how concentrated it is. ## Score ranges tie back to the same model These bands use the same 0–1000 Crime Score scale applied everywhere else in the platform. The thresholds separating Low from Medium from High from Critical aren't specific to this report — they're the same scoring boundaries used for enforcement decisions elsewhere in the deployment. *** Proof of Value engagements generate this table against a client's own traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Signal From Noise Source: https://docs.onefirewall.com/study-cases/severity-based-triage How severity-based triage turns a flood of flagged traffic into a short, prioritized list of what to act on first The events in this chart were already permitted by the client's own firewall, then flagged retroactively by OneFirewall's intelligence layer. The dashboard classifies how severe that permitted-but-malicious traffic was. *** ## Severity bands Permitted-but-malicious traffic splits into four bands: **Low** (score 1–60, 327 events), **Medium** (60–120, 290 events), **High** (120–175, 142 events), and **Critical** (175–1000, 303 events). Each band tracks unique IPs as well as event counts. 303 critical events from 265 distinct sources is a different scenario than 303 events from a small number of IPs repeatedly hitting the same endpoint. ## Delta over baseline The panel on the right combines High and Critical: **445 events, 3.71% of permitted traffic**, flagged with a **+30% change** against the prior baseline, from **401 unique threat actors**. The alert is a delta, not a static count. A 30% increase in high-severity permitted traffic indicates a change in exposure that a snapshot report would not capture on its own. ## Resulting priority order The four donuts below break the totals down further: of the traffic evaluated, **8,730** events were allowed and **2,275** were blocked by the client's own firewall; of what was allowed, **7,668** were clean and **1,062** were malicious; and across the full blocking picture, the client's firewall accounted for 2,275, OneFirewall's checkpoint-ip enforcement accounted for another **974**, and **303** critical-severity events remained unblocked at the time of this snapshot. *** Proof of Value engagements produce this severity-ranked breakdown against a client's own traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # From IP to STIX2 Source: https://docs.onefirewall.com/study-cases/stix2-threat-graph How a single indicator becomes a machine-readable STIX2 graph that other security tools can consume automatically This graph is a STIX2 bundle generated from a single flagged IP: six objects, four relationships, structured for automated consumption rather than manual reading. *** ## Graph structure A OneFirewall Threat Report object sits at the top as the container. It points to an Indicator, the malicious IP, which "indicates" three Attack Pattern objects: Network Service Discovery, Vulnerability Scanning, and Active Scanning. A Course of Action object, Network Service Scanning Mitigation, connects to one of those patterns through a "mitigates" relationship. Four typed relationships, using standard STIX2 vocabulary: indicates, mitigates. ## Purpose of the format STIX2 (Structured Threat Information Expression) is a standard specifically so threat intelligence doesn't remain a paragraph in a written report. A SOAR platform, TIP, or SIEM correlation engine can ingest this bundle directly, without an analyst transcribing "this IP is doing recon" into a separate schema. The relationship types carry meaning a flat IOC list doesn't: this indicator specifically indicates reconnaissance-stage activity, and a defined mitigation is already attached to it. ## Kill-chain stage Network Service Discovery, Vulnerability Scanning, and Active Scanning are early kill-chain activity: mapping exposed services before deciding how to proceed. Structuring intelligence at this stage means downstream automation can act on the reconnaissance itself, rather than waiting for a later, more damaging stage to trigger a response. *** Proof of Value engagements generate structured intelligence of this kind from a client's own indicators. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # The Blocking Gap Source: https://docs.onefirewall.com/study-cases/the-blocking-gap Comparing what the client's firewall already blocks against what OneFirewall's scoring says still needs to be blocked Three numbers, three different sources of enforcement: **4,477** events blocked by the client's own firewall, **1,511** blocked through OneFirewall's checkpoint-ip integration, and **425** critical-severity events that neither system had stopped yet at the time of this snapshot. *** ## Three enforcement states, not two Most gap analyses stop at "blocked versus not blocked." This one separates blocking into what the existing rule set already handles, what an integrated OneFirewall enforcement point additionally catches, and what remains — the traffic that's scored, corroborated, and still getting through both. That last group, **425** events, is exactly the Critical band from the severity breakdown: the highest-confidence malicious traffic in the dataset, still unaddressed. ## Why the 425 is the actionable figure The first two numbers describe enforcement already in place. The 425 describes the delta — the specific set of events where applying the same Crime Score threshold already used elsewhere in the deployment would close the gap. It's a small fraction of total traffic, which is the point: this isn't a case for replacing the firewall, it's a specific, bounded list of what the current setup doesn't yet cover. *** Proof of Value engagements identify this same gap against a client's own enforcement stack. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Events to Actors Source: https://docs.onefirewall.com/study-cases/traffic-flow-to-threat-actors A full traffic flow breakdown showing how parsed events split by enforcement decision, then converge by severity into unique threat actor counts This flow diagram traces the same event set through two independent classifications: what the client's own firewall did with the traffic, and what severity OneFirewall assigned to it. The two classifications don't collapse into each other: traffic gets a severity score regardless of whether it was already blocked. *** ## The first split: enforcement decision Of total parsed events, **72.9%** were passed by Demo Org's firewall and **27.1%** were blocked. This is the enforcement outcome on its own, before severity is factored in. ## Severity within each branch Both branches are then broken down by the same four severity bands, independent of the enforcement action already taken. Within the passed branch: **64.0%** of total events were Clean Traffic, with **4.0%** Low, **2.2%** Medium, **0.9%** High, and **1.5%** Critical severity slipping through despite being permitted. Within the blocked branch: **11.4%** Low, **6.8%** Medium, **3.1%** High, and **5.5%** Critical. Most of what Demo Org's firewall blocked was, independently, also scored as malicious by OneFirewall. A small slice, **0.3%**, is labeled Denied (Contributed Value): traffic the firewall blocked that OneFirewall's scoring assessed as clean, cross-validating that portion of the existing rule set rather than flagging it as a gap. ## Convergence into actor counts On the right, the four severity bands from both branches converge into unique threat actor totals, deduplicated across whatever enforcement decision already applied to their traffic: **513 Low Actors**, **283 Medium Actors**, **120 High Actors**, and **196 Critical Actors**. This is a count of distinct sources at each severity level, not event volume. A single actor can appear in both the passed and blocked branches across different events and still counts once here. *** Proof of Value engagements produce this same flow breakdown against a client's own traffic. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Watching a Score Climb Source: https://docs.onefirewall.com/study-cases/watching-a-score-climb One IP's Crime Score over time, laid against the actual connections it made to a customer's infrastructure during that period The top chart is the Crime Score history of a single IP over five days, climbing from roughly **175** to a plateau near **320**. The dashed vertical lines mark each date that IP exchanged traffic with Demo Org. The table below lists those connections individually. *** ## The score didn't stop the traffic The score rises in two phases: a steady climb through day 13 and 14, a plateau, then a sharper rise around day 15 into day 16 where it settles near its ceiling. What the dashed lines show is that this IP kept connecting to Demo Org's infrastructure throughout that entire period, including after the score had already reached Critical territory. A rising score describes accumulating evidence against a source. It doesn't, on its own, stop a firewall rule that was never configured to check it. ## What the connections actually were The table lists five sessions from the hours before this snapshot: an inbound HTTPS connection through Checkpoint-3472409, an inbound RDP attempt through the same device, an inbound SSH connection, an outbound RDP session through Fortigate-infra1, and an inbound SSH connection through Checkpoint-198365. Every row carries the same OFA Intel tags — **critical** and **block** — regardless of outcome. Of the five, four were **Allowed** and one, the RDP attempt, was **Deny**ed. ## Why RDP and SSH specifically Both protocols are remote management access, not general application traffic. It's the kind of service a Critical-scored source targets when the goal is direct control over a host rather than data collection. Four allowed sessions across HTTPS, RDP, and SSH, from a source already carrying a plateaued Critical score, is the flow-level version of what the aggregate charts elsewhere in this report describe in percentages: scored, corroborated activity that reached the destination anyway. *** Proof of Value engagements surface this same connection-level detail for indicators already active against a client's own infrastructure. [Start a Proof of Value](https://onefirewall.com/proof-of-value). # Cloudflare Outage Source: https://docs.onefirewall.com/updates/cloudflare # Service Impact Notification: Cloudflare Outage and OneFirewall Services This is an update on the service impact caused by today's outage at Cloudflare, Inc. OneFirewall's platform uses Cloudflare as a CDN and edge-delivery layer for several public-facing components, and this outage temporarily affected some services. *** ## Background of the Outage On Tuesday, 18 November 2025, Cloudflare experienced a global service incident that disrupted access to several major platforms, including ChatGPT, X (formerly Twitter), Spotify, and Canva. Cloudflare reported that its network, which supports an estimated \~20% of the web, encountered an internal service degradation triggered by a very large configuration file or an unexpected traffic spike affecting its traffic processing pipeline. Cloudflare stated there is no evidence of malicious activity, and the root cause is still under review. *** ## Impact on OneFirewall Services Core Threat Intelligence Services remained fully operational throughout the incident. Because our public UI and API rely on Cloudflare's CDN, customers experienced limited access during the outage. * Outage timeframe: approximately 6 hours from 7am UTC. * During this window, customers were unable to receive new IoC feeds via the public API/UI. * Once Cloudflare resolved the issue, all services auto-restored without any manual action required. ### Service Impact Summary | Service Area | Status | | -------------------------- | ------------------ | | Online Documentation | Impacted | | IoC Collection (ingestion) | Partially impacted | | IoC Distribution (feeds) | Partially impacted | | On-Premises Instances | **Not impacted** | | Run-Time Protection | **Not impacted** | *** ## What This Means for You * No action needed. Your on-prem or hosted environments require no changes or manual intervention. * No data loss. All IoCs generated during the outage were queued and delivered once connectivity returned. * No security degradation. Real-time protection and backend threat-intelligence engines ran continuously. *** ## Mitigation Steps by OneFirewall To reduce reliance on a single CDN provider, OneFirewall is rolling out a multi-CDN architecture: * Traffic will be balanced between Cloudflare and Fastly. * Rollout will happen progressively over the coming weeks. This reduces the likelihood that a single provider outage affects service availability. *** ## FAQ **Do I need to do anything on my on-premises instance?** No. All systems have already returned to normal without intervention. **Was any data, IoC, or feed information lost?** No. All feeds generated during the outage were held in queue and delivered automatically once services recovered. **Did this outage impact my security coverage?** No. Run-time protection and threat-intelligence pipelines operated normally throughout. **Will this be prevented in the future?** The multi-CDN rollout described above reduces the chance of a repeat. *** If you have any questions, contact your account manager or email [support@onefirewall.com](mailto:support@onefirewall.com). The OneFirewall Team OneFirewall Alliance Ltd. # Check Point Integration Guide Source: https://docs.onefirewall.com/wcf-agents/checkpoint-feeds ## Overview This guide explains how to integrate **OneFirewall Alliance (OFA) Threat Feeds** with **Check Point Security Gateways** using **Indicators** and **External Dynamic Lists (EDLs)**. Supported categories: * Malicious IPs * Malicious Domains * Malicious URLs * Malicious File Hashes (MD5, SHA1, SHA256) ## Compatibility OneFirewall threat feeds are compatible with Check Point gateways that support **SecureXL** and **EDL-based Indicators**. | Version | SecureXL Support | Notes | | --------------- | ---------------- | ---------------------------------------------------------------- | | R75 and earlier | Not supported | SecureXL was unavailable or unstable in these versions. | | R76 – R77.30 | Basic support | Early SecureXL features available, limited performance. | | R80.10 – R80.30 | Full support | Stable with CLI tools and acceleration. | | R80.40+ | Enhanced | Hardware acceleration improvements and better template handling. | | R81 – R81.20 | Recommended | Most robust version with multithreaded SecureXL. | | R82+ | Ongoing | Continued optimization expected. | ## Prerequisites * A valid **OneFirewall Alliance** account. * Check Point Gateway running **R80.10 or later** (R81+ recommended). * Ability to define **Indicators** in SmartConsole. * Internet access from the gateway to reach OneFirewall's feed URLs. * HTTPS inspection must allow outbound connections to threat feed URLs (if required by policy). ## Step 1: Generate API Token 1. Log into your **OneFirewall Alliance** dashboard. 2. Go to the **API Access** section. 3. Click **Generate JWT Token**. 4. Save the token securely — this will be used to authenticate feed requests. ## Step 2: Configure Indicators in SmartConsole ### A. Create an External Dynamic List (EDL) 1. In **SmartConsole**, navigate to: `Security Policies` → `Threat Prevention` → `Indicators` → `External Feeds` 2. Click **New > Indicator Feed**. 3. Choose the type (IP, Domain, URL, File Hash). 4. Fill in the fields: * **Name**: `OFA - [Type] Feed` (e.g., `OFA - IP Feed`) * **Feed URL**: URL provided by OneFirewall * **Authentication**: * Select `Custom Headers` * Add Header: * `Authorization` → `` * (`N.B.` if the Header is not working, you can also pass the OFA JWT token through `Basic Auth`. Fill `username` with the OFA JWT token, and keep `password` empty or with a whitespace.) * **Refresh Interval**: e.g., `5 minutes` (as preferred) * Enable `SSL Verification` if supported and required 5. Click **OK** to save. ### B. Create a Rule Using the Indicator Feed 1. Go to **Security Policies**. 2. Add a new rule (Access or Threat Prevention, depending on traffic type). 3. In the **Source** or **Destination**, choose the relevant Indicator Feed object. 4. Define the desired action (Drop, Reject, Prevent, etc.). 5. Install policy. ## Feed Types and URL Format Each OFA feed corresponds to a specific type of threat indicator: | Feed Type | URL Example | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | IP Addresses | `https://api.onefirewall.com/api/v1/ipv4/{OFA_SCORE}?agid=OFA-AGENT-ID-{RANDOM_ALFA_NUMERIC}&plugin=checkpoint-ip` | | Domains | `https://api.onefirewall.com/api/v1/domains/score/{OFA_SCORE}?agid=OFA-AGENT-ID-{RANDOM_ALFA_NUMERIC}&plugin=checkpoint-domain` | | URLs | `https://api.onefirewall.com/api/v1/urls/score/{OFA_SCORE}?agid=OFA-AGENT-ID-{RANDOM_ALFA_NUMERIC}&plugin=checkpoint-url` | | File Hashes | `https://api.onefirewall.com/api/v1/files/score/{OFA_SCORE}?digest=MD5&agid=OFA-AGENT-ID-{RANDOM_ALFA_NUMERIC}&plugin=checkpoint-hash-md5` | | File Hashes | `https://api.onefirewall.com/api/v1/files/score/{OFA_SCORE}?digest=SHA1&agid=OFA-AGENT-ID-{RANDOM_ALFA_NUMERIC}&plugin=checkpoint-hash-sha1` | | File Hashes | `https://api.onefirewall.com/api/v1/files/score/{OFA_SCORE}?digest=SHA256&agid=OFA-AGENT-ID-{RANDOM_ALFA_NUMERIC}&plugin=checkpoint-hash-sha256` | Replace these with the actual URLs provided in your OFA dashboard. Authentication via bearer token is required. `OFA_SCORE` is the score suggested by OneFirewall guidance, and `RANDOM_ALFA_NUMERIC` is a random alphanumeric value, e.g. `827c65d86a44`. ## Notes * OneFirewall uses **JWT-based Bearer Authentication**. * Ensure your Check Point version supports **custom HTTP headers** in EDLs. * Feeds are **auto-refreshable** and optimized for Check Point integration. * All feed types can be used **simultaneously** in different rules or combined policies. # Cloud Armor Enterprise Source: https://docs.onefirewall.com/wcf-agents/cloud-armor How to configure a centralized IP deny list using Address Groups in Cloud Armor Enterprise with Terraform. ## Overview Use **Address Groups** in Google Cloud Armor Enterprise to manage a centralized IP deny list, reusable across multiple security policies. This guide covers integrating the OneFirewall WCF Agent with Cloud Armor Enterprise Address Groups for automated dynamic updates to the deny list. ## Prerequisites Address Groups with `purpose = CLOUD_ARMOR` require the project to be enrolled in **Cloud Armor Enterprise**. Without it, you cannot create or modify address groups. If you downgrade, all security policies referencing address groups will be frozen (read-only). The GCP project must be enrolled in the Enterprise tier. On downgrade, security policies referencing address groups become read-only until those rules are removed. The `google_network_security_address_group` resource requires the **`google-beta`** provider. Make sure it is configured in your Terraform setup. ### Required IAM Permissions for the Service Account The service account used by Terraform must have the following roles: | Role | Description | | ------------------------------ | ------------------------------------------------------ | | `roles/compute.securityAdmin` | Create and manage Cloud Armor security policies | | `roles/compute.networkAdmin` | Create and manage address groups | | `roles/iam.serviceAccountUser` | Required if the SA needs to impersonate other accounts | For production environments, prefer creating a **custom role** with only the necessary permissions, rather than assigning broad roles like `roles/editor`. ### Address Group Limits & Quota The **capacity** of an address group **cannot be changed after creation**. Plan your value carefully before deploying. | `purpose` configuration | Maximum capacity | | ------------------------- | ------------------------------------------------------ | | `CLOUD_ARMOR` only | Up to **10,000+** IPs (requestable via quota increase) | | `DEFAULT` + `CLOUD_ARMOR` | Maximum **1,000** IPs | To increase quota limits, the service account needs the `serviceusage.quotas.update` permission, included in the `Owner`, `Editor`, and `Quota Administrator` roles. Requests can be submitted from the GCP Console under **IAM & Admin → Quotas**. ## Step 1: Configure the `google-beta` Provider ```hcl terraform.tf theme={null} terraform { required_providers { google-beta = { source = "hashicorp/google-beta" version = ">= 5.0" } } } provider "google-beta" { project = var.project_id region = "global" } ``` ## Step 2: Create the Address Group ```hcl address_group.tf theme={null} resource "google_network_security_address_group" "denylist" { provider = google-beta name = "denylist-addresses" parent = "projects/${var.project_id}" location = "global" type = "IPV4" # "IPV4" or "IPV6" capacity = 10000 # Cannot be changed after creation purpose = ["CLOUD_ARMOR"] items = [ "1.2.3.4/32", "5.6.7.8/32", "10.0.0.0/8", ] description = "Centrally managed IP deny list for Cloud Armor" } ``` The `items` field can also be managed externally via `gcloud` or the API, without re-running Terraform every time you add or remove an IP. ## Step 3: Create the Security Policy with the Deny Rule ```hcl security_policy.tf theme={null} resource "google_compute_security_policy" "main" { provider = google-beta name = "main-security-policy" # Rule 1: block IPs in the address group rule { action = "deny(403)" priority = 1000 description = "Block IPs listed in the deny list address group" match { expr { # use origin.user_ip instead of origin.ip if CDN mask expression = "evaluateAddressGroup('${google_network_security_address_group.denylist.id}', origin.ip)" } } } # Default rule: allow everything else rule { action = "allow" priority = 2147483647 description = "Default allow rule" match { versioned_expr = "SRC_IPS_V1" config { src_ip_ranges = ["*"] } } } } ``` ## Step 4: Attach the Policy to a Backend Service ```hcl backend.tf theme={null} resource "google_compute_backend_service" "app" { name = "my-backend-service" security_policy = google_compute_security_policy.main.id load_balancing_scheme = "EXTERNAL_MANAGED" protocol = "HTTP" # ... other backend parameters } ``` ## Step 5: Update the Deny List Without Terraform To add or remove IPs dynamically, without going through Terraform, use `gcloud`: ```bash theme={null} # Add IPs to the address group gcloud network-security address-groups add-items denylist-addresses \ --location global \ --items "9.9.9.9/32,8.8.8.8/32" # Remove IPs from the address group gcloud network-security address-groups remove-items denylist-addresses \ --location global \ --items "9.9.9.9/32" # Inspect the current state gcloud network-security address-groups describe denylist-addresses \ --location global ``` ## Step 6: Reuse the Address Group Across Multiple Security Policies The same address group can be referenced by multiple security policies simultaneously: ```hcl multi_policy.tf theme={null} # Reference the same address group in different policies resource "google_compute_security_policy" "api" { name = "api-security-policy" rule { action = "deny(403)" priority = 1000 match { expr { # use origin.user_ip instead of origin.ip if CDN mask expression = "evaluateAddressGroup('${google_network_security_address_group.denylist.id}', origin.ip)" } } } # ... } ``` ## Step 7: Handle a CDN with Masked IP (X-Forwarded-For) ```hcl multi_policy.tf theme={null} resource "google_compute_security_policy" "main" { provider = google-beta name = "main-security-policy" advanced_options_config { user_ip_request_headers = ["X-Forwarded-For"] # or: ["True-Client-IP"] # or both with priority order: ["True-Client-IP", "X-Forwarded-For"] } rule { action = "deny(403)" priority = 1000 match { expr { # use origin.user_ip instead origin.ip expression = "evaluateAddressGroup('${google_network_security_address_group.denylist.id}', origin.user_ip)" } } } # ... } ``` ## Notes | Aspect | Value | | ------------------------------------- | --------------------------------------- | | Required tier | **Cloud Armor Enterprise** | | Terraform resource | `google_network_security_address_group` | | Terraform provider | `google-beta` | | Required `purpose` field | `CLOUD_ARMOR` | | Max capacity (CLOUD\_ARMOR only) | 10,000+ (with quota increase) | | Max capacity (CLOUD\_ARMOR + DEFAULT) | 1,000 | | Capacity editable after creation | No | | Minimum SA roles | `securityAdmin` + `networkAdmin` | | Update IPs without Terraform | Yes, via `gcloud` or API | # Sensor Configuration Source: https://docs.onefirewall.com/wcf-agents/config-sensor How to configure your WCF Agent (Sensor) ## Overview The WCF Sensor Configuration is a pre-defined JSON file that determines how your installed setup instructs your firewall, router, or IPS device to behave. OneFirewall supports two setup types: * **API-Based** * **Agent-Based** ## API-Based Setup The simplest installation method. Covers systems such as Fortigate, Checkpoint, pfSense, and others. Select your device from the menu and enable it. The system guides you through the remaining steps during installation. ## Agent-Based Setup Applies to systems such as Checkpoint SecureXL, Sophos, Trellix, and others. To connect these with OneFirewall for real-time protection, install the **WCF Agent** — the bridge between your device and the OneFirewall platform. When you select a device that requires an agent, the system generates a pre-compiled JSON configuration. Review and edit this JSON before completing the integration with your device. ### Step 1: Activation 1. Log in to your OneFirewall Server instance, open the main menu on the right, and click **Install Agent**. 2. Select the device you want to activate. 3. Define the following parameters: * **IoC Type** — Choose between *IP*, *URL*, *Domain*, or *File*. * **Cyber Crime Threshold** — Set the sensitivity level at which the device starts blocking threats. * **Sync Interval** — Define how often the agent updates its IoC data. If the selected device requires an Agent-Based setup, you are presented with the following form: ### Step 2: Download Configuration 1. Prepare a virtual machine with Docker and Docker Compose installed. 2. Download the `docker-compose.yml` file from the previous step and place it on the new machine. This file contains the parameters (including your certificate) the agent needs to connect securely to your OneFirewall Server. 3. Start the agent: ```bash theme={null} docker-compose up -d ``` ### Step 3: Setup Access 1. Navigate to the **Agent Status** page from the menu to see the list of installed agents. 2. Click **View & Edit** on the newly installed agent to open its JSON configuration form. 3. Scroll to the `ips` section of the JSON and set your own parameters. See the examples below. ## Notes Below are JSON configuration examples for each supported device. ### Sophos ```json theme={null} "ips": { "sophos": { "active": true, "user": "", "password": "", "address": "", "command": "bash artifacts/sophos/update_blacklist_sophos.sh" } } ``` ### Checkpoint SecureXL ```json theme={null} "ips": { "checkpoint_securexl": { "active": true, "connections": "@", "password": "", "command": "bash artifacts/checkpoint/install-securexl.sh", "vsids": "" }, } ``` # ForcePoint NGFW Integration Source: https://docs.onefirewall.com/wcf-agents/forcepoint-ngfw ## Overview Integrate OneFirewall Alliance (OFA) threat feeds with ForcePoint NGFW using Security Management Center (SMC) and External Dynamic Feeds. This enables real-time policy enforcement based on live threat data for: * Malicious IPs * Malicious URLs ## Compatibility Compatible with ForcePoint NGFW Software 7.0, 6.11, 6.10, 6.9, 6.8, 6.7, 6.5, managed through Security Management Center (SMC). ## Prerequisites * A valid OneFirewall Alliance account. * ForcePoint running 6.5 or later (7.0 recommended). * Console access. * Internet access from the gateway to OneFirewall's feed URLs. * HTTPS inspection must allow outbound connections to threat feed URLs, if required by policy. ## Step 1: Generate API Token 1. Log into your OneFirewall Alliance dashboard. 2. Go to the **API Access** section. 3. Click **Generate JWT Token**. 4. Save the token securely — it authenticates feed requests. ## Step 2: Configure IP Address List and URL List ### Configure the external feeds #### Install Docker and Docker Compose ```bash theme={null} # On Debian/Ubuntu sudo apt update sudo apt install -y docker.io sudo systemctl enable --now docker # Install Docker Compose sudo curl -L "https://github.com/docker/compose/releases/download/$(curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r '.tag_name')/docker-compose-$(uname -s)-$(uname -m)" \ -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose ``` #### Prepare your deployment directory ``` mkdir -p ~/wcf-agent-forcepoint cd ~/wcf-agent-forcepoint ``` 1. Download the WCF Agent Docker image into this folder. 2. Obtain your config.json from OneFirewall's Install Agent page. 3. Place config.json in \~/wcf-agent/onefirewall/config. #### Create docker-compose.yml ```yaml theme={null} version: '3' services: onefirewall-wcf-agent-forcepoint-ngfw: image: registry.onefirewall.com/onefirewall-wcf-agent-forcepoint:v4 restart: always environment: - IS_TEST=False volumes: - ./storage/logs:/var/tmp/ - ./storage/data:/opt/onefirewall/data/ - ./onefirewall/config:/opt/onefirewall/config/:ro ``` Contact the OneFirewall support team for access to download the WCF Agent binary image. #### Launch the agent ``` docker compose up -d docker-compose logs -f onefirewall-wcf-agent-forcepoint-ngfw ``` ## Notes * OneFirewall uses JWT-based Bearer Authentication. * Feeds refresh automatically and are optimized for ForcePoint NGFW SMC 7.0 integration. * All feed types can be used simultaneously, in different rules or combined policies. # ForcePoint Web Security Source: https://docs.onefirewall.com/wcf-agents/forcepoint-websec ## Overview Integrate OneFirewall Alliance (OFA) threat feeds with ForcePoint Web Security / URL Filtering. This enables real-time policy enforcement based on live threat data for: * Malicious IPs * Malicious URLs ## Compatibility Compatible with ForcePoint Web Security / URL Filtering version 8.5.x. ## Prerequisites * A valid OneFirewall Alliance account. * ForcePoint running 8.5.x. * Console access. * Internet access from the gateway to OneFirewall's feed URLs. * HTTPS inspection must allow outbound connections to threat feed URLs, if required by policy. ## Step 1: Generate API Token 1. Log into your OneFirewall Alliance dashboard. 2. Go to the **API Access** section. 3. Click **Generate JWT Token**. 4. Save the token securely — it authenticates feed requests. ## Step 2: Configure IP Address List and URL List ### Configure the external feeds #### Install Docker and Docker Compose ```bash theme={null} # On Debian/Ubuntu sudo apt update sudo apt install -y docker.io sudo systemctl enable --now docker # Install Docker Compose sudo curl -L "https://github.com/docker/compose/releases/download/$(curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r '.tag_name')/docker-compose-$(uname -s)-$(uname -m)" \ -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose ``` #### Prepare your deployment directory ``` mkdir -p ~/wcf-agent-forcepoint cd ~/wcf-agent-forcepoint ``` 1. Download the WCF Agent Docker image into this folder. 2. Obtain your config.json from OneFirewall's Install Agent page. 3. Place config.json in \~/wcf-agent/onefirewall/config. #### Create docker-compose.yml ```yaml theme={null} version: '3' services: onefirewall-wcf-agent-forcepoint-websec: image: registry.onefirewall.com/onefirewall-wcf-agent-urls:v4 restart: always environment: - IS_TEST=False volumes: - ./storage/logs:/var/tmp/ - ./storage/data:/opt/onefirewall/data/ - ./onefirewall/config:/opt/onefirewall/config/:ro ``` Contact the OneFirewall support team for access to download the WCF Agent binary image. #### Launch the agent ``` docker compose up -d docker-compose logs -f onefirewall-wcf-agent-forcepoint-websec ``` ## Notes * OneFirewall uses JWT-based Bearer Authentication. * Feeds refresh automatically and are optimized for ForcePoint Web Security / URL Filtering integration. * All feed types can be used simultaneously, in different rules or combined policies. # FortiCloud WCF Integration Source: https://docs.onefirewall.com/wcf-agents/forticloud Step-by-step guide to set up the FortiCloud Web Content Filtering integration with OneFirewall. ## Overview This guide sets up the FortiCloud Web Content Filtering (WCF) integration with OneFirewall. ## Prerequisites Install the following on the machine where the agent will run: * [Docker](https://docs.docker.com/get-docker/) * [Docker Compose](https://docs.docker.com/compose/install/) Need help installing Docker and Docker Compose? Follow the [WCF Installation Guide](https://docs.onefirewall.com/essentials/wcf-installation) for a step-by-step walkthrough. ## Step 1: Open the WCF Installation Page Navigate to the WCF installation page in the OneFirewall portal (refer to your on-premises installation if applicable): [https://app.onefirewall.com/install-wcf.html](https://app.onefirewall.com/install-wcf.html) ## Step 2: Select FortiCloud On the integration page, select **FortiCloud** from the list of available connectors. FortiCloud selection screen ## Step 3: Configure the Integration Fill in the required fields: | Field | Description | | --------------- | ------------------------------------------------------------------- | | **Device Name** | A unique name to identify this device within OneFirewall | | **Type** | Select **IPv4** | | **Score** | Set the threat score threshold to use for filtering | | **Update Time** | How often the agent fetches updated data (e.g. every **5 minutes**) | Setting the update time to **5 minutes** is recommended for near-real-time threat intelligence updates. ## Step 4: Activate FortiCloud Once all fields are filled in, click **Activate FORTICLOUD**. OneFirewall generates a ready-to-use `docker-compose.yml` file with the required environment variables pre-populated for your account. ## Step 5: Deploy with Docker Compose ### The generated `docker-compose.yml` ```yaml docker-compose.yml theme={null} services: fortiappsec-updater: image: registry.onefirewall.com/onefirewall-wcf-agent-fortiappsec:v1 platform: linux/amd64 container_name: fortiappsec-updater environment: - FORTINET_API_KEY=${FORTINET_API_KEY} - EP_ID=${EP_ID} - OFA_API_URL=${OFA_API_URL} - OFA_JWT_TOKEN=${OFA_JWT_TOKEN} - OFA_SCORE=${OFA_SCORE} - AGID=${AGID} - KEEP_DAYS=${KEEP_DAYS:-30} - SCRIPT_DIR=/app/backups - DEMO_MODE=${DEMO_MODE:-false} - IP_LIMIT=${IP_LIMIT:-9999} volumes: - ./backup:/app/backups restart: "always" ``` The environment variables (e.g. `OFA_JWT_TOKEN`, `AGID`) are automatically filled in by OneFirewall after you click **Activate FORTICLOUD**. `FORTINET_API_KEY` and `EP_ID` are the API key and application ID from your FortiAppSec application, configured from your organization values. ### Start the agent Save the generated `docker-compose.yml` to a directory on your machine, then run: ```bash theme={null} docker-compose up -d ``` The agent starts in the background and begins syncing threat intelligence data with your FortiGate device at the configured update interval. ## Verify the Agent Is Running Check that the container started correctly: ```bash theme={null} docker ps ``` You should see `fortiappsec-updater` listed with a status of `Up`. To view live logs: ```bash theme={null} docker logs -f fortiappsec-updater ``` ## Troubleshooting Check the logs with `docker logs fortiappsec-updater`. A missing or invalid environment variable is the most common cause — make sure you copied the exact `docker-compose.yml` generated after activation. Make sure Docker is authenticated with the OneFirewall registry. Contact support if you receive a `403 Forbidden` or `unauthorized` error when pulling the image. Verify the container is running and check that the `OFA_JWT_TOKEN` is still valid. Tokens may expire — re-activating the integration on the portal will issue a new token. # FortiGate Integration Guide Source: https://docs.onefirewall.com/wcf-agents/fortigate ## Overview This guide describes how to integrate **OneFirewall Alliance (OFA) Threat Feeds** into a **FortiGate Security Fabric** using External Dynamic Lists (EDLs). The integration enables automatic enforcement of security rules based on live threat intelligence from OneFirewall, covering both **inbound** and **outbound** traffic. ## Prerequisites | Feature | Minimum FortiOS Version | | ------------------------------------- | ----------------------- | | External Connectors (Threat Feeds) | **6.0+** | | Support for Custom HTTP Headers | **6.2.3+** | | Feed Auto-Refresh & Policy Binding | **6.4+** | | Full GUI Integration & Advanced Logic | **7.0+** | * Custom Bearer token authentication used by OneFirewall's API requires **FortiOS 6.2.3 or higher**. * Devices running FortiOS prior to 6.2.3 can only ingest unauthenticated feeds, which is incompatible with OneFirewall's authenticated feed. * FortiOS 6.4 or 7.x is recommended: secure external connectors with headers, feed auto-refreshing, integration with inbound/outbound policies, and GUI-based management and logging. ## Step 1: Generate API Token 1. Log into your OneFirewall Alliance profile. 2. Navigate to the **API Access** section. 3. Generate a **JWT token**. 4. Save this token securely — it will be used for authenticating feed requests. ## Step 2: Configure FortiGate External Connector 1. Access your FortiGate device. 2. Go to `Security Fabric` > `External Connectors`. 3. Click **Create New** > Select **IP Address Threat Feed**. 4. Configure the feed. 5. Set update interval as needed (e.g., every 15 minutes). 6. Save the connector. ## Step 3: Create Security Policies Apply the OFA threat intelligence through security policies. This example maps the **any** keyword to specific network interfaces: # OneDevice Parallel Source: https://docs.onefirewall.com/wcf-agents/onedevice-parallel ## Overview OneDevice Parallel is a OneFirewall appliance that runs alongside your existing firewall — pfSense, FortiGate, Check Point, Sophos, or others. It analyzes logs from that firewall and updates security rules in real time. ## Use Cases For organizations that already have a firewall in place but aren't fully using its capabilities. OneDevice adds the monitoring and rule automation needed to operationalize that firewall's protection. ## Compatibility **OneDevice** is a compact physical appliance provided by OneFirewall Alliance Ltd. (or its alliance partners), installed directly within the customer's network. ### Hardware Specifications | Component | Specification | | ----------------------------- | ------------------------------------- | | **Operating System** | Debian | | **CPU** | 4 cores (optionally 8) | | **RAM** | 8 GB (optional 12 or 16 GB) | | **Storage** | 128 GB SSD (or higher) | | **Network Interfaces (NICs)** | 1 (standard configuration includes 4) | | **Wi-Fi** | Not included by default | | **Power Supply** | 12V | ### Software Each OneDevice ships pre-installed with the OneFirewall application, maintained by OneFirewall Alliance. ## Notes * Network operation: once powered on and connected, the device listens on UDP 514 (receives syslog metadata from your existing firewall) and HTTPS 443 (hosts the rule engine that feeds updated rules to your existing firewall). * Cloud connectivity: the device maintains a continuous connection to the OneFirewall Control Framework (WCF), the console used to monitor performance, push updates, and manage device operations. # OneDevice Series Source: https://docs.onefirewall.com/wcf-agents/onedevice-series ## Overview OneDevice In-Series is a OneFirewall product line for small businesses that lack existing security protection. Installed directly into your network, it functions as a dynamic firewall, monitoring, preventing, and blocking cyberattacks in real time. Each unit ships as a plug-and-play device. ## Use Cases For small and medium enterprises (SMEs) that lack an existing firewall solution for inbound and/or outbound network connections. ## Compatibility **OneDevice** is a compact physical appliance provided by OneFirewall Alliance Ltd. (or its alliance partners), installed directly within the customer's network. ### Hardware Specifications | Component | Specification | | ----------------------------- | ------------------------------------- | | **Operating System** | Debian | | **CPU** | 4 cores (optionally 8) | | **RAM** | 8 GB (optional 12 or 16 GB) | | **Storage** | 128 GB SSD (or higher) | | **Network Interfaces (NICs)** | 3 (standard configuration includes 4) | | **Wi-Fi** | Not included by default | | **Power Supply** | 12V | ### Software Each OneDevice ships pre-installed with the OneFirewall application, maintained by OneFirewall Alliance. ## Step 1: Connect the Device 1. Connect your existing internet cable to **NIC-W** (the WAN port previously used for internet access). 2. Use **NIC-L** to access the internet through the device. Behind the scenes, the device performs: * Network bridging * Traffic monitoring * Threat detection and prevention **NIC-C** maintains a secure connection to the OneFirewall Server (Console/WCF), used for centralized monitoring, management, and performance oversight of your OneDevice. ## Notes * Can be installed either before or after your current router. Contact the support team to discuss alternatives for your topology. # Palo Alto (EDL) Integration Guide Source: https://docs.onefirewall.com/wcf-agents/paloalto How to consume a OneFirewall IP feed using External Dynamic Lists (EDL) on Palo Alto Networks firewalls. ## Overview This guide explains how to ingest OneFirewall Alliance IP feeds into a Palo Alto firewall using External Dynamic Lists (EDL), using a proxy method to support Bearer Token authentication. ## Prerequisites Use **PAN-OS 10.0+**, which supports HTTPS-based EDLs and certificate profiles. Palo Alto EDLs do not support Bearer Tokens or custom headers. This guide uses a direct URL with query parameters to fetch the feed. ## Step 1: Generate API Token 1. Log into your OneFirewall Alliance profile. 2. Navigate to the **API Access** section. 3. Generate a **JWT token**. 4. Save this token securely — it will be used for authenticating feed requests. ## Step 2: Create the External Dynamic List (EDL) 1. In the Palo Alto Web UI, go to **Objects → External Dynamic Lists**. 2. Click **Add**. 3. Fill in the fields: * **Name**: `onefirewall_ipv4_feed` * **Type**: `IP List` * **Source**: If Client Authentication is available, use basic auth in that section and set the source to: ```vim theme={null} https://app.onefirewall.com/api/v1/ipv4/200?agid=827c65d86a44&plugin=paloalto" or https://YOUR_ON_PREM_INSTALLATION/api/v1/ipv4/200?agid=827c65d86a44&plugin=paloalto" ``` Use the credentials as shown in the figure. If Client Authentication is not available, pass credentials directly in the URL: ```vim theme={null} https://FIRST_63_CHAR_OF_TOKEN:LAST_PART_OF_TOKEN@app.onefirewall.com(or your local on prem installation)/api/v1/ipv4/200?agid=827c65d86a44&plugin=paloalto" i.e. https://eyJh********************************.***********************Z3:VpZC************************************************************.*******************************************@app.onefirewall.com/api/v1/ipv4/200?agid=827c65d86a44&plugin=paloalto ``` * **Recurring**: Every 15 minutes (or as needed) * **Certificate Profile**: *(optional, only needed for HTTPS with custom certs)* 4. Click **OK** and then **Commit** your changes. If using HTTPS, ensure the server's certificate is valid or import the root CA into the firewall's trusted store. See the [Official Palo Alto EDL Configuration Guide](https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-admin/policy/use-an-external-dynamic-list-in-policy/configure-the-firewall-to-access-an-external-dynamic-list) for further details. ## Step 3: Apply the EDL in a Security Policy 1. Go to **Policies → Security**. 2. Create a new rule or edit an existing one: * **Source / Destination Zone**: According to your environment * **Destination Address**: Add an address object referencing the EDL (`onefirewall_ipv4_feed`) * **Action**: `Deny` or `Drop` 3. Name and place the rule in the correct policy order. 4. **Commit** the configuration. ## Step 4: Verify EDL Status Verify whether the EDL was successfully downloaded using the CLI: ```bash theme={null} request system external-list show type ip name onefirewall_ipv4_feed ``` # pfSense Integration Guide Source: https://docs.onefirewall.com/wcf-agents/pfsense ## Overview This guide explains how to integrate **OneFirewall Alliance (OFA) Threat Feeds** with **pfSense** using **pfBlockerNG** and **External Dynamic Feeds**. ## Prerequisites * pfSense 2.7.0 or later. ## Step 1: Generate API Token 1. Log into your **OneFirewall Alliance** dashboard. 2. Go to the **API Access** section. 3. Click **Generate JWT Token**. 4. Save the token securely — this will be used to authenticate feed requests. ## Step 2: Generate the Agent Configuration Go to the OneFirewall Alliance Dashboard -> Install Agent, activate pfSense license, and save the configuration setup provided. ## Step 3: Configure IP Address List and URL List From pfSense Dashboard, go to System -> Package Manager and install pfBlockerNG if not already installed. ### Configure pfBlockerNG Go to Firewall -> pfBlockerNG and configure the package. Follow all "Next" steps until the "Finish" section. ### Configure the OneFirewall Threat Feeds Go to Firewall -> pfBlockerNG -> IP section, and apply the following steps: Go to Firewall -> pfBlockerNG -> IP -> IPv4 section, and apply the following steps: The OFA\_API\_WITH\_TOKEN is the configuration URL provided by the OneFirewall Install Agent section. ## Notes * OneFirewall uses **JWT-based Bearer Authentication**. * Feeds are **auto-refreshable** and optimized for pfSense integration. # Checkpoint Secure XL Source: https://docs.onefirewall.com/wcf-agents/secure-xl ## Overview Check Point SecureXL accelerates traffic processing on Check Point Security Gateways by offloading packet processing to dedicated network processors and hardware. OneFirewall's WCF Agent works with SecureXL to push and continuously update large rule sets — thousands to millions of rules — without degrading gateway performance. ## Compatibility SecureXL support depends on the Gaia OS and Security Gateway version: | Check Point Version | SecureXL Support | Notes | | ------------------- | ---------------- | ----------------------------------------------------------------------- | | R75 and earlier | Not supported | SecureXL was not available or incomplete in these versions. | | R76 – R77.30 | Basic support | Early implementations; some features (e.g., template caching) limited. | | R80.10 – R80.30 | Full support | Stable SecureXL support with CLI tools and acceleration improvements. | | R80.40+ | Enhanced | Improved hardware acceleration, template handling, and flow management. | | R81 – R81.20 | Recommended | Includes Dynamic Dispatcher and multithreaded SecureXL. | | R82+ | Ongoing | Continued support and optimization for SecureXL features. | ## How SecureXL Works Components: * **SecureXL Acceleration**: bypasses the slower packet-inspection path when possible. * **SecureXL Devices**: NICs and Network Processing Units (NPUs) that accelerate traffic. * **Templates**: created per connection type; matching connections are processed faster. * **Flows**: handle ongoing connections so packets in an established session are processed efficiently. Packet flow: 1. The first packet of a new connection undergoes full inspection (security policy checks, DPI). 2. Once the packet is allowed, SecureXL creates a template containing source, destination, protocol, and other connection data. 3. Subsequent packets matching the template use the fast path and bypass full inspection. 4. SecureXL maintains state for established connections and routes their packets directly. 5. Supported connections and packet types are offloaded to SecureXL hardware, reducing CPU load. ## Integration with the WCF Agent The WCF Agent includes a sub-module for SecureXL that pushes and updates security rules on the gateway without significant delay, using Check Point's standard command-line interface. No changes to Check Point scripts are required. The implementation used depends on the client configuration (blades, no blades, or performance constraints): or ## Monitoring and Configuration * **Monitoring**: `fwaccel stat` shows SecureXL status and performance. * **Configuration**: SecureXL settings can be adjusted from the Check Point CLI to enable or disable specific acceleration features. ## Notes * SecureXL combined with the WCF Agent supports real-time rule updates without impacting throughput or latency. * Scales to large, dynamic rule sets by combining SecureXL acceleration with the WCF Agent's update mechanism. # Sophos Integration Guide Source: https://docs.onefirewall.com/wcf-agents/sophos ## Overview This guide describes how to integrate **OneFirewall Alliance (OFA) Threat Feeds** into **Sophos Firewall** using External Dynamic Lists (EDLs). The integration enables automatic enforcement of security rules based on live threat intelligence from OneFirewall, covering both **inbound** and **outbound** traffic. ## Prerequisites * Sophos Firewall **20.0+**. * A VM with the latest Ubuntu LTS, Docker, and Docker Compose, to host the WCF Agent. ## Step 1: Generate the Agent Configuration 1. Log into your OneFirewall Alliance profile. 2. Navigate to the **Install Agent** section. 3. Select **Sophos** from the dropdown menu and fill in the Sophos API information (URL, user, password). Start with a tolerant score threshold (e.g. 200) — this can be changed later from the agent-status page at runtime. 4. Save the generated `config.json` securely — it will be used to authenticate feed requests. ## Step 2: Install the WCF Agent 1. Contact [support@onefirewall.com](mailto:support@onefirewall.com) for the installation file (this step will be integrated into the portal in a future release). 2. Create a `wcf-agent` folder in a filesystem path of your choice. 3. Unpack the installation file and follow the instructions in the `README` file. Place the downloaded `config.json` in the `onefirewall/config` folder. ## Step 3: Create Security Policies The Sophos API is the address URL of the Sophos Firewall Dashboard, e.g. `192.168.1.1:443`. The agent creates blacklists — external dynamic lists containing the IP threats from OneFirewall — named as shown in the screenshots below. Once started, configure Inbound/Outbound firewall **rules and criteria** on the Sophos firewall as shown: # Web App (HTTP) Feeds Source: https://docs.onefirewall.com/wcf-agents/webapp-feeds How to notify OneFirewall if your web app is under attack ## Overview Many internet-facing web applications aren’t protected by a Web Application Firewall (WAF) or an IDS that inspects web payloads, so web attacks can go unnoticed. Configure your web application to feed Indicators of Compromise (IoCs) to OneFirewall automatically whenever malicious activity is detected, without deploying a separate security appliance. * OneFirewall aggregates IoCs from all your apps in one place for investigation. * No additional WAF/IDS product to deploy or manage. * Automated feeds speed up blocking and threat hunting. ## How It Works 1. Your web app (or its runtime/logging layer) detects suspicious activity or extracts IoCs from logs. 2. The app sends those IoCs (IP addresses, URLs, user-agents, file hashes, etc.) to OneFirewall via a secure API. 3. OneFirewall ingests the IoCs, enriches and correlates them, and applies blocking or alerting rules across your environment. ## Prerequisites * An active OneFirewall account. If you don’t have one, contact [support@onefirewall.com](mailto:support@onefirewall.com). * An API token, generated from your OneFirewall account. ## Step 1: Create an Account 1. Go to [https://app.onefirewall.com](https://app.onefirewall.com) and create an account. 2. Generate an **API Token** and store it securely (e.g., in a password manager or secrets vault). ## Step 2: Set Environment Variables Create or update your .env file (or environment variables for your app): ``` ONEFIREWALL_END_POINT="https://app.onefirewall.com/api/v2/ips" ONEFIREWALL_API_KEY="" ONEFIREWALL_BULK=100 ONEFIREWALL_TAG="report-XXXXXXXX" ``` Contact the OneFirewall team to define the `report-XXXXXXXX` tag value. These settings control how your application submits unauthorized access attempts and anomalies to OneFirewall. ## Step 3: Create Middleware Implement middleware that intercepts all incoming requests and records any response that does **not** return a `200 OK` status. Status codes to capture: * `401 Unauthorized` * `403 Forbidden` * `404 Not Found` * Other unexpected error codes This ensures anomalous or suspicious activity is consistently detected and logged. ## Step 4: Submit Feeds to OneFirewall 1. Each time an anomaly is detected, add the event to your local feed queue. 2. Once the number of queued events reaches the value defined in `ONEFIREWALL_BULK`, send the batch to **OneFirewall** using the API. This batching approach reduces API overhead and keeps IoC reporting timely. ## Code Examples Reference implementations for capturing anomalies and submitting them to OneFirewall. ### NodeJS with Express module ```js theme={null} const express = require("express"); const axios = require("axios"); const app = express(); app.set("trust proxy", true); const ONEFIREWALL_END_POINT = process.env.ONEFIREWALL_END_POINT || "https://app.onefirewall.com/api/v2/ips"; const ONEFIREWALL_API_KEY = process.env.ONEFIREWALL_API_KEY || ""; const ONEFIREWALL_BULK = parseInt(process.env.ONEFIREWALL_BULK || "100", 10); const ONEFIREWALL_TAG = process.env.ONEFIREWALL_TAG || "report-example" let feedQueue = []; function getClientIp(req) { if (req && req.ip) { // req.ip can be in format "::ffff:198.51.100.23" — normalize IPv4-mapped IPv6 const ip = req.ip.replace(/^::ffff:/, ""); if (ip && ip !== "::1") return ip; } const headers = req.headers || {}; // x-forwarded-for: comma separated list, client ip is first if (headers["x-forwarded-for"]) { const list = headers["x-forwarded-for"].split(",").map(s => s.trim()); if (list.length > 0 && list[0]) return list[0].replace(/^::ffff:/, ""); } // Cloudflare if (headers["cf-connecting-ip"]) { return headers["cf-connecting-ip"].replace(/^::ffff:/, ""); } // Akamai / others if (headers["true-client-ip"]) { return headers["true-client-ip"].replace(/^::ffff:/, ""); } // x-real-ip if (headers["x-real-ip"]) { return headers["x-real-ip"].replace(/^::ffff:/, ""); } // Forwarded: for= if (headers["forwarded"]) { // Example: Forwarded: for=198.51.100.1;proto=https;by=203.0.113.43 const m = headers["forwarded"].match(/for=([^;,\s]+)/i); if (m && m[1]) return m[1].replace(/^"|"$/g, "").replace(/^::ffff:/, ""); } // Last resort: req.connection remote address (older Node) const conn = req.connection || req.socket || {}; if (conn.remoteAddress) { return conn.remoteAddress.replace(/^::ffff:/, ""); } return "unknown"; } // Middleware to capture anomalies app.use((req, res, next) => { const originalSend = res.send; res.send = function (body) { const statusCode = res.statusCode; if ([401, 403, 404].includes(statusCode)) { const clientIp = getClientIp(req); const anomaly = { source: req.hostname || req.get("host") || "unknown", ip: clientIp, confidence: 0.2, notes: req.originalUrl, tags: ONEFIREWALL_TAG }; feedQueue.push(anomaly); console.log("Captured anomaly:", anomaly); if (feedQueue.length >= ONEFIREWALL_BULK) { submitToOneFirewall(); } } // call original send return originalSend.apply(this, arguments); }; next(); }); // Function to send anomalies to OneFirewall let submitting = false; // prevent concurrent submissions async function submitToOneFirewall() { if (submitting) return; // avoid concurrent submissions if (feedQueue.length === 0) return; submitting = true; // Copy payload so queue is not mutated mid-flight const payload = [...feedQueue]; try { const response = await axios.post(ONEFIREWALL_END_POINT, payload, { headers: { "Content-Type": "application/json", Authorization: `Bearer ${ONEFIREWALL_API_KEY}` }, timeout: 10_000 }); console.log( `Submitted ${payload.length} anomalies to OneFirewall: ${response.status}` ); // clear only the successfully submitted items // (if new items were appended while submitting, preserve them) feedQueue = feedQueue.slice(payload.length); } catch (error) { console.error("Error submitting to OneFirewall:", error.message); // keep feedQueue intact for retry } finally { submitting = false; } } ``` ### GoLang with Fiber module ```go theme={null} // main.go package main import ( "bytes" "encoding/json" "log" "net" "net/http" "os" "regexp" "strconv" "strings" "sync" "time" "github.com/gofiber/fiber/v2" ) type Anomaly struct { Source string `json:"source"` IP string `json:"ip"` Confidence float64 `json:"confidence"` Notes string `json:"notes"` Tags string `json:"tags"` } // --- Config (env) --- var ( oneFirewallEndpoint = getenv("ONEFIREWALL_END_POINT", "https://app.onefirewall.com/api/v2/ips") oneFirewallAPIKey = getenv("ONEFIREWALL_API_KEY", "") oneFirewallBulk = mustAtoi(getenv("ONEFIREWALL_BULK", "100")) oneFirewallTag = getenv("ONEFIREWALL_TAG", "report-example") httpTimeout = time.Second * 10 ) // --- Queue & Submission State --- var ( queueMu sync.Mutex feedQueue []Anomaly submitMu sync.Mutex submitting bool ) // Helper: get env with default func getenv(k, def string) string { if v := os.Getenv(k); v != "" { return v } return def } func mustAtoi(s string) int { n, err := strconv.Atoi(s) if err != nil { return 100 } return n } // --- Client IP extraction (WAF/CDN aware) --- var ( forwardedForRe = regexp.MustCompile(`(?i)for=([^;,\s]+)`) ) // Normalize IPv4-mapped IPv6 like "::ffff:198.51.100.23" func normalizeIP(ip string) string { ip = strings.Trim(ip, `"`) ip = strings.TrimSpace(ip) ip = strings.TrimPrefix(ip, "::ffff:") // If it's an IP:port, strip port host, _, err := net.SplitHostPort(ip) if err == nil && host != "" { return host } return ip } func getClientIP(c *fiber.Ctx) string { // 1) Prefer headers set by known proxies/CDNs if v := c.Get("X-Forwarded-For"); v != "" { parts := strings.Split(v, ",") if len(parts) > 0 { return normalizeIP(strings.TrimSpace(parts[0])) } } if v := c.Get("CF-Connecting-IP"); v != "" { return normalizeIP(v) } if v := c.Get("True-Client-IP"); v != "" { return normalizeIP(v) } if v := c.Get("X-Real-IP"); v != "" { return normalizeIP(v) } if v := c.Get("Forwarded"); v != "" { if m := forwardedForRe.FindStringSubmatch(v); len(m) == 2 { return normalizeIP(m[1]) } } // 2) Fiber’s derived IP (may use proxy headers depending on deployment) if ip := c.IP(); ip != "" && ip != "::1" { return normalizeIP(ip) } // 3) Remote address fallback if ra := c.Context().RemoteAddr().String(); ra != "" { return normalizeIP(ra) } return "unknown" } // --- Submit to OneFirewall --- func submitToOneFirewall() { // prevent concurrent submissions submitMu.Lock() if submitting { submitMu.Unlock() return } submitting = true submitMu.Unlock() // snapshot queue queueMu.Lock() if len(feedQueue) == 0 { queueMu.Unlock() submitMu.Lock() submitting = false submitMu.Unlock() return } payload := make([]Anomaly, len(feedQueue)) copy(payload, feedQueue) queueMu.Unlock() // marshal outside lock body, err := json.Marshal(payload) if err != nil { log.Printf("marshal error: %v", err) submitMu.Lock() submitting = false submitMu.Unlock() return } req, err := http.NewRequest(http.MethodPost, oneFirewallEndpoint, bytes.NewReader(body)) if err != nil { log.Printf("request build error: %v", err) submitMu.Lock() submitting = false submitMu.Unlock() return } req.Header.Set("Content-Type", "application/json") req.Header.Set("Authorization", "Bearer "+oneFirewallAPIKey) client := &http.Client{Timeout: httpTimeout} resp, err := client.Do(req) if err != nil { log.Printf("submit error: %v", err) submitMu.Lock() submitting = false submitMu.Unlock() return } defer resp.Body.Close() if resp.StatusCode >= 200 && resp.StatusCode < 300 { // success -> drop only the submitted items queueMu.Lock() if len(feedQueue) >= len(payload) { feedQueue = feedQueue[len(payload):] } else { // shouldn't happen, but be safe feedQueue = nil } queueMu.Unlock() log.Printf("Submitted %d anomalies to OneFirewall: %s", len(payload), resp.Status) } else { log.Printf("submit failed: %s (queue retained)", resp.Status) } submitMu.Lock() submitting = false submitMu.Unlock() } func main() { app := fiber.New(fiber.Config{ // Optionally set a proxy header Fiber should trust (if you fully trust your proxy layer) // ProxyHeader: fiber.HeaderXForwardedFor, // EnableTrustedProxyCheck: true, // TrustedProxies: []string{"YOUR.WAF.CIDR/24"}, }) // Middleware: run AFTER handlers to inspect final status app.Use(func(c *fiber.Ctx) error { err := c.Next() status := c.Response().StatusCode() if status == 0 { status = http.StatusOK } if status == http.StatusUnauthorized || status == http.StatusForbidden || status == http.StatusNotFound { clientIP := getClientIP(c) host := c.Hostname() if host == "" { host = c.Get("Host") if host == "" { host = "unknown" } } anomaly := Anomaly{ Source: host, IP: clientIP, Confidence: 0.2, Notes: c.OriginalURL(), Tags: oneFirewallTag, } // enqueue safely queueMu.Lock() feedQueue = append(feedQueue, anomaly) queueLen := len(feedQueue) queueMu.Unlock() log.Printf("Captured anomaly: %+v (queue=%d)", anomaly, queueLen) // flush if bulk reached if queueLen >= oneFirewallBulk { go submitToOneFirewall() } } return err }) // --- Example routes --- app.Get("/", func(c *fiber.Ctx) error { return c.SendString("Hello, Fiber!") }) app.Get("/secret", func(c *fiber.Ctx) error { return c.SendStatus(http.StatusForbidden) // 403 }) app.Get("/missing", func(c *fiber.Ctx) error { return c.SendStatus(http.StatusNotFound) // 404 }) // Optional: periodic flush so you don't wait for bulk threshold flushSec := mustAtoi(getenv("ONEFIREWALL_FLUSH_SEC", "60")) if flushSec > 0 { ticker := time.NewTicker(time.Duration(flushSec) * time.Second) go func() { for range ticker.C { queueMu.Lock() hasItems := len(feedQueue) > 0 queueMu.Unlock() if hasItems { submitToOneFirewall() } } }() } port := getenv("PORT", "3000") log.Printf("App running on :%s", port) if err := app.Listen(":" + port); err != nil { log.Fatal(err) } } ``` ### Python3 with FastAPI ```python theme={null} # main.py import asyncio import json import os import re import socket from typing import List, Dict, Any import httpx from fastapi import FastAPI, Request, Response from starlette.middleware.base import BaseHTTPMiddleware from starlette.responses import PlainTextResponse # --- Config (env) --- ONEFIREWALL_END_POINT = os.getenv("ONEFIREWALL_END_POINT", "https://app.onefirewall.com/api/v2/ips") ONEFIREWALL_API_KEY = os.getenv("ONEFIREWALL_API_KEY", "") ONEFIREWALL_BULK = int(os.getenv("ONEFIREWALL_BULK", "100")) ONEFIREWALL_TAG = os.getenv("ONEFIREWALL_TAG", "report-example") ONEFIREWALL_FLUSH_SEC = int(os.getenv("ONEFIREWALL_FLUSH_SEC", "60")) # optional periodic flush HTTP_TIMEOUT = 10.0 # --- In-memory queue & locks --- feed_queue: List[Dict[str, Any]] = [] queue_lock = asyncio.Lock() submitting_lock = asyncio.Lock() forwarded_re = re.compile(r'for=([^;,\s]+)', re.IGNORECASE) def _normalize_ip(value: str) -> str: """Normalize IPv4-mapped IPv6 and strip port if present.""" v = value.strip().strip('"') if v.startswith("::ffff:"): v = v[len("::ffff:") :] # strip port if present try: host, _port = v.rsplit(":", 1) # if host still contains colon, it was IPv6 w/o port socket.inet_aton(host) # will raise if not IPv4 return host except Exception: return v def get_client_ip(req: Request) -> str: """ Extract real client IP behind WAF/CDN by checking (in order): X-Forwarded-For, CF-Connecting-IP, True-Client-IP, X-Real-IP, Forwarded, then client.host """ headers = req.headers xff = headers.get("x-forwarded-for") if xff: # client IP is first in the comma-separated list first = xff.split(",")[0].strip() if first: return _normalize_ip(first) cf = headers.get("cf-connecting-ip") if cf: return _normalize_ip(cf) tci = headers.get("true-client-ip") if tci: return _normalize_ip(tci) xri = headers.get("x-real-ip") if xri: return _normalize_ip(xri) fwd = headers.get("forwarded") if fwd: m = forwarded_re.search(fwd) if m: return _normalize_ip(m.group(1)) # fallback to client address from transport client_host = req.client.host if req.client else "unknown" if client_host and client_host != "::1": return _normalize_ip(client_host) return "unknown" async def submit_to_onefirewall(): """Post a copy of the queue to OneFirewall. Clear only on success.""" # avoid concurrent submissions if submitting_lock.locked(): return async with submitting_lock: # snapshot queue async with queue_lock: if not feed_queue: return payload = list(feed_queue) try: async with httpx.AsyncClient(timeout=HTTP_TIMEOUT) as client: resp = await client.post( ONEFIREWALL_END_POINT, content=json.dumps(payload), headers={ "Content-Type": "application/json", "Authorization": f"Bearer {ONEFIREWALL_API_KEY}", }, ) if 200 <= resp.status_code < 300: # success: trim only the submitted items async with queue_lock: # if new items arrived during submission, preserve them del feed_queue[: len(payload)] print(f"Submitted {len(payload)} anomalies to OneFirewall: {resp.status_code}") else: print(f"Submit failed: {resp.status_code} (queue retained)") except Exception as e: print(f"Error submitting to OneFirewall: {e} (queue retained)") class AnomalyCaptureMiddleware(BaseHTTPMiddleware): """ Middleware runs AFTER the request is processed (call_next), inspects the final status code, and enqueues anomalies for 401/403/404. """ async def dispatch(self, request: Request, call_next): response: Response try: response = await call_next(request) except Exception: # if your handler raises and you turn it into a 500 elsewhere, # we don't enqueue here (only 401/403/404 as requested) return PlainTextResponse("Internal Server Error", status_code=500) status = response.status_code or 200 if status in (401, 403, 404): client_ip = get_client_ip(request) host = request.headers.get("host") or request.url.hostname or "unknown" anomaly = { "source": host, "ip": client_ip, "confidence": 0.2, "notes": str(request.url.path), "tags": ONEFIREWALL_TAG, } async with queue_lock: feed_queue.append(anomaly) qlen = len(feed_queue) print(f"Captured anomaly: {anomaly} (queue={qlen})") if qlen >= ONEFIREWALL_BULK: # fire and forget asyncio.create_task(submit_to_onefirewall()) return response app = FastAPI() app.add_middleware(AnomalyCaptureMiddleware) # --- Example routes --- @app.get("/") async def root(): return {"message": "Hello, FastAPI!"} @app.get("/secret") async def secret(): return Response(status_code=403) # Forbidden @app.get("/missing") async def missing(): return Response(status_code=404) # Not Found # Optional: periodic flush so you don't wait for bulk threshold @app.on_event("startup") async def startup_event(): if ONEFIREWALL_FLUSH_SEC <= 0: return async def periodic_flush(): while True: await asyncio.sleep(ONEFIREWALL_FLUSH_SEC) async with queue_lock: has_items = len(feed_queue) > 0 if has_items: await submit_to_onefirewall() asyncio.create_task(periodic_flush()) # Run with: uvicorn main:app --host 0.0.0.0 --port 3000 ```