How to use Defneo, module by module

Defneo is installed on-premise, on a server you control (physical, virtual or VPS). Every component runs as a Docker container, started with Docker Compose.

• Operating system: Linux x86_64 (for example Ubuntu 22.04/24.04 or Debian 12), with root access.
• Docker: Docker Engine 24 or newer with the Compose v2 plugin. The installer can install it for you.
• Ports: 80 and 443 free on the server — Defneo becomes the reverse proxy that receives web traffic.
• Community Edition: runs fewer services than the commercial edition, so it needs fewer resources; before installing, the automatic check verifies Docker and Compose, free disk space and ports 80/443.
• Commercial edition: the default limits are calibrated for an 8 GB RAM machine; installation sizes memory to the hardware and stops if the stack does not fit. Disk use grows with the traffic history you keep and with the optional analytics engine.

When installing the commercial edition, Defneo measures the available memory and sizes every service's limits automatically. If the stack cannot fit your hardware, the installer stops with a clear report instead of starting an unstable install.

Defneo Community gives you a reverse proxy with automatic TLS, backend management, web analytics, CrowdSec detection and the shared attacker feed. The condition of the free edition: your installation shares the attackers it bans on its own and receives the common list.

1. Open the Community page and enter your company email address (Gmail, Yahoo, Outlook and disposable addresses are not accepted).
2. Confirm your registration from the link in the email within 48 hours.
3. Copy the install command shown and run it as root on the server. Add --install-docker if Docker is not installed yet.
4. Wait for the installer to finish: it checks requirements, starts the services and prints the panel address.
5. Open the panel in your browser and create the administrator account.

The commercial edition adds server and workstation agents, CTEM, the security scanner, OSINT, multi-framework compliance (NIS2, DORA, GDPR, ISO 27001), AI governance and training. You can evaluate it for 30 days on your own server.

1. Install Defneo Community if you have not already.
2. In the panel, open System → Edition and press Start the 30-day trial (administrators only).
3. Run the upgrade command shown on the page on the server.
4. The upgrade downloads the verified commercial edition, copies your data and settings, starts the new stack and checks its health.
5. If the health check fails, the installation automatically rolls back to Community, untouched.

Organizations that prefer a direct commercial install (without Community first) can book a demo and receive installation instructions.

The first time you open the panel, the initial setup wizard creates the administrator account. Until an administrator exists, the panel accepts no other logins.

1. Open the panel address printed at the end of installation and create the administrator account with a strong password.
2. Log in and open your account security settings.
3. Enable two-step verification (TOTP): scan the QR code with an authenticator app and confirm with a code.
4. Optionally add a passkey (WebAuthn/FIDO2) — a hardware key or your device's biometric login.
5. Create separate accounts for colleagues under System → Users, with the right role.

Defneo sits in front of your applications as a reverse proxy. Every published site or application is a backend: a domain, one or more destination servers, and the protection layers applied to it.

1. Point the domain's DNS record (A/AAAA) to the public address of the Defneo server.
2. In the panel, open Traffic → Backends and press Add backend.
3. Fill in the service name, the domain and the address of the application server (or servers).
4. Keep the default layers ticked: security headers, CrowdSec and request rate limiting.
5. Save. The configuration applies immediately and the Let's Encrypt certificate is issued on the first HTTPS request.
6. Open the domain in your browser and check in Analytics that the first requests appear.

Defneo Community is free under the AGPL-3.0 licence, with no artificial limits in the code. The commercial edition runs the same core and adds the modules for endpoints, exposure, compliance and governance.

Defneo uses Traefik as its reverse proxy. Each backend combines a routing rule (domain and, optionally, a path), the destination servers and a chain of middlewares — the layers every request passes through before reaching the application.

• Security headers — HSTS, X-Frame-Options, X-Content-Type-Options and more, applied uniformly.
• CrowdSec — blocks IPs with an active ban decision.
• Rate limiting — three profiles (default, strict, per site); the default values are adjusted from Settings.
• Compression — gzip for text responses.

1. Open Traffic → Backends and choose the backend.
2. Edit servers, middlewares, priority or health check and save — the change applies without restarting the site.
3. To take a site out of the proxy temporarily, use the Disable toggle; its configuration is kept.
4. For domain or path redirects (for example old domain → new domain), use Traffic → Redirects.

CrowdSec is Defneo's detection engine. It analyses every request logged by the proxy and compares it with scenarios — attack patterns such as scanning for sensitive paths, login brute force, exploitation of known CVEs or L7 floods. When a scenario triggers, the IP receives a ban decision, enforced immediately by every backend with the CrowdSec layer.

• Scenarios from the CrowdSec hub, plus Defneo scenarios for real-world cases: distributed scans across a subnet, crawlers pretending to be Googlebot, hostile slow connections.
• Legitimate search-engine crawlers are verified and kept out of bans.
• Every scenario is mapped to the matching MITRE ATT&CK techniques.
• Responses produced by the blocking layer itself are not counted as a new attack — a false positive does not become permanent.

1. Open Threats → CrowdSec for active decisions, recent alerts and per-scenario metrics.
2. Click an IP to see why it was banned (see The IP page).
3. Adjust scanner ban duration in Settings if you want longer bans for repeated probing.

Besides behaviour analysis (CrowdSec scenarios), Defneo can inspect the content of each request with the AppSec component. Virtual-patching rules block attempts to exploit known CVEs even if the application behind has not been updated yet.

1. Check under Threats → CrowdSec that AppSec rules are active.
2. Follow requests refused by AppSec in the alert list; each entry shows the rule that fired.
3. Sources that repeatedly try exploits are also banned at IP level, with the duration configured for scanners.

Geoblocking refuses requests from the selected countries, based on IP geolocation. It helps when your services target only certain markets and you see persistent attacks from other regions.

1. Open Threats → Blocklist and the geoblocking section.
2. Choose the countries to block.
3. Add to the exception list the IPs that must get through anyway (partners, external monitoring, your team's VPN).
4. Save and check in Analytics that traffic from the blocked countries drops.

The scraping-defence module looks for automated harvesting patterns: many distinct pages at machine pace, IP rotation within the same subnet or autonomous system (AS), crawlers claiming to be search engines.

• The User-Agent proves nothing. A crawler counts as legitimate only if it comes from the operator's published ranges or passes forward-confirmed reverse DNS (FCrDNS).
• Proof of a human matters. An IP with a history of human browsing in the last week is not banned, even if it looks aggressive in a short window.
• Gradual escalation: IP → subnet → autonomous system, only on detection history and with no evidence of human traffic from that AS.

1. Open Exposure → Scraping defence and leave it in monitor mode for a few days.
2. Review the detections: who, which pages, what evidence.
3. Switch to block when you are happy with what would have been banned.

Every backend has an AI crawlers field with three options. Blocking happens in the proxy itself with a 403, without loading your application and without feeding attack detection.

1. Open Traffic → Backends and edit the site.
2. Choose the option in the AI crawlers field and save.
3. Check in Analytics, bot filter, category “AI crawlers”.

Automated scanners look for files that should not be public: .env, .git, database backups, configuration files. Defneo uses this in two ways.

• The anti-leak layer intercepts requests for known sensitive paths at the edge and answers with a 404 identical to a normal one — even if the application behind exposed the file by mistake.
• Traps are decoy paths: any IP that hits them is banned automatically, because no real visitor ever goes there.

Files modern applications need (for example /.well-known/ for certificates and domain verification) are not blocked.

The Blocklist page brings together everything blocked: CrowdSec decisions, manual bans, blocked countries and imported lists. The IOC module adds indicators of compromise (IPs, domains) from external threat-intelligence feeds.

1. Open Threats → Blocklist to see and filter blocked IPs, with the reason and expiry of each.
2. In Threats → IOC add indicators manually or subscribe to external feeds; imports run periodically.
3. Defneo compares new traffic with active indicators and automatically bans matching sources.

Any IP from lists, Analytics or alerts opens in a detail page. It answers the question “why was it banned and should it stay banned?”.

• Active decision — type, duration, creation and expiry time.
• CrowdSec alerts — the scenarios that fired, with the events behind them.
• Risk assessment — a score by request category (PHP probing, admin scans, code-execution attempts and so on).
• Activity — response codes, User-Agents, paths accessed, timeline.
• Recommendation — if the score is low, the page suggests unbanning as a possible false positive.

1. To unban, press Unban; the decision is removed from every backend immediately.
2. For a manual ban, pick a duration (for example 4h, 30m, 1d) and a reason.

The analyzer periodically looks for IPs with unusual request volume and the paths they hit. The summary sent to the AI model is pseudonymised (IPs become labels), and the model proposes blocking rules.

1. Open Threats → Traffic spikes and choose a spike.
2. Read the proposal and the validator's verdict: what is applicable, what is refused and why.
3. Apply only what makes sense. Applying requires the administrator role and a re-validation at apply time.

• Overview — the home page: backends, service health, agents, and relevant alerts gathered from every module into one feed.
• Briefing — the daily digest: blocked IPs, new CVEs on your software, agents that did not report, expiring deadlines, plus security news. With an AI model configured, the briefing is written in natural language and can be listened to as audio.
• CTO Center — the executive picture: security posture, threats, compliance, AI governance, inventory and key indicators, exportable as a strategic PDF report.

Defneo computes analytics directly from the requests passing through the proxy. You add no script to your site and set no tracking cookies, and the data stays on your server.

• Live traffic — requests from the last few seconds, with country, path and response code.
• Dashboard — requests, unique visitors, status codes, countries, hours, operating systems, browsers, pages, traffic sources, domains.
• Pages/All — by default only real pages are counted, not static assets; you can switch to all requests.
• Bot filters — all, no bots or bots only, classified by category (search engines, AI crawlers, scanners, monitoring and more), plus excluding banned IPs.
• Drill-down — click any value (country, page, IP, source, status code) and see every aggregate narrowed to it.
• Visitor journeys — which pages each visitor viewed, in what order and where they hit errors.

Defneo collects metrics with Prometheus and shows them in Grafana. Dashboards are provisioned automatically at install and open directly from the panel, behind the panel's own login.

• Traefik (requests, latency, errors per backend), CrowdSec (decisions, scenarios), Overview, Security threats.
• Web applications, network (interface traffic, connections, packets), platform (resources per component), long-term web analytics.
• Traffic reports — correlates the routes declared in the site's sitemap with the actual 404/5xx errors, so you see broken pages.

1. Open General → Reports and pick a dashboard.
2. Adjust the time range in the dashboard corner.
3. For direct Grafana access, use the System → Grafana link.

The Infrastructure page shows every Defneo component running on the server: status (running, stopped, restarting), uptime, CPU, memory and the configured limit.

1. Open System → Infrastructure.
2. Click a component for details: image, restarts, networks, recent log.
3. The memory-budget section shows caps and reservations; the panel warns if reservations exceed available memory.
4. When you change a limit, the page tells you whether it is already live or needs the component to be recreated.

Every module can emit events: a router down, a certificate about to expire, an agent offline, a network alert. Events reach the panel inbox (the bell) and, according to your rules, external channels.

1. Open System → Settings → Notifications.
2. Add a channel: email (SMTP), webhook, Slack, Discord or Telegram, and send a test message.
3. For each event type, choose the severities that go to external channels.
4. Enable the daily ban digest if you want one notification a day instead of one per IP.

In the commercial edition, notifications also cover infrastructure alerts (over 70 Prometheus rules: system, network, CrowdSec, proxy), IOC matches, NetMon and offline agents.

A proxy router can be present in the configuration yet disabled — for example when a middleware fails to load. The domain then answers 404 although the application works. Edge Health detects exactly that.

• Every router is checked every minute, not only backends managed from the panel.
• Severity follows the consequence: a public domain down is critical, an internal router is low.
• Recovery is announced, and a router removed on purpose (a disabled backend) is not treated as a failure.
• If the proxy state cannot be read, the panel says “unknown”, not “zero routers down”.

For every backend with a public domain, the proxy automatically obtains a Let's Encrypt certificate and renews it before expiry. Defneo independently checks the certificates actually served and warns you when one approaches expiry or is invalid.

1. Check the list of served certificates and their expiry in the backends page.
2. Configure notifications for the “certificate” event type.
3. If a certificate is not issued, follow Certificate not issued.

The grade is computed every day from a few passive checks — exactly what any visitor sees: the TLS handshake, the response headers of the home page, the security.txt file and the domain's SPF and DMARC records. No guessed paths are tried.

• The score is additive and every check shows its contribution.
• An invalid certificate means an F; accepting TLS 1.0/1.1 caps the grade at C.
• A check that could not run is left out of the calculation (not penalised), and an unreachable page gets no grade, not an F.

1. Open Traffic → Security grade.
2. Click a site to see each check and how to fix it.
3. After fixing, run the assessment again.

The Defneo agent runs on each Linux server or Windows workstation you want to track. It periodically sends the panel its inventory, security posture and relevant events. Communication is signed, and the agent verifies the panel's identity on every connection.

1. In the panel, open Endpoint → Agents and press Add agent.
2. Choose the operating system. The panel generates an enrolment token and the command (Linux) or a preconfigured installer (Windows).
3. On Linux, run the command as root. On Windows, run the installer as administrator.
4. On its first report the agent appears in the list and the token can no longer be used.
5. Open the agent's page for inventory, scores and recommendations.

• System — operating system, kernel, CPU, memory, disks, uptime.
• Software — installed packages and their versions, used by CVE correlation.
• End-of-life runtimes — languages and platforms that no longer receive updates, checked against vendors' public calendars.
• Services and ports — what listens on each host and which process holds the port.
• Updates — pending system updates, including Windows Update.
• Processes — process drill-down, with binary hashes checked against public sources.

The Network & assets page brings together hosts with agents and discovered assets. The Active Directory coverage page compares domain computers with installed agents and shows which machines are not tracked yet.

Agents run configuration checks inspired by the CIS Benchmarks: SSH, password policies, unnecessary services, permissions on sensitive files, logging, firewall and more. Results feed each host's score and the compliance controls that require hardened configuration.

1. Open Compliance → CIS Benchmarks for the fleet-wide picture.
2. Filter by host or by check to find common issues.
3. Apply the proposed fix and wait for the agent's next report.

FIM watches each host's critical files and alerts you when they change. On package-based systems, verification compares files with the hashes published by the package vendor — that is how replaced system binaries are spotted.

1. Open Endpoint → FIM for the list of changes across the fleet.
2. Review each change: was it a planned update or an unexpected change?
3. Acknowledge legitimate changes so they no longer show as open.

NetMon learns each host's normal network behaviour and flags what breaks the pattern: periodic connections to the same destination (beaconing), algorithmically generated-looking domains (DGA), DNS queries carrying data, unusual volumes and never-seen destinations.

1. Open the agent page and the NetMon tab.
2. Each detection comes with context: the process that opened the connection, destination information and the baseline's age.
3. Ask for the AI interpretation to get a verdict per finding and verification commands to run on the host.
4. For known noise, create a suppression rule with a reason. Suppressed alerts stay in history.

On Windows workstations, besides the inventory agent, you can install the protection component. It reacts to events instead of scanning periodically and coexists with Microsoft Defender — it never disables or reconfigures it.

1. Open Endpoint → Endpoint protection.
2. Enable protection for the workstations you want and choose the policy.
3. Follow detections, quarantined files and blocked connections; restore a false positive from quarantine.

Parental control uses the Windows protection component for children's profiles: blocked applications, blocked sites and a usage schedule by day and hour.

1. Open Endpoint → Parental control and create a profile.
2. Link the profile to the child's Windows user.
3. Choose the blocked apps and sites and the screen-time schedule.
4. The child gets warnings before time runs out; at the end the session is locked, without losing open work.

During an incident you can act directly on the host from the panel: kill a suspicious process, isolate a host from the network or add a firewall rule. Actions are designed not to cause more harm than the problem.

1. Enable controlled response for that host (a per-host option, off by default).
2. Propose the action from the agent page.
3. A different person with the right permissions approves it; the proposal expires after 30 minutes.
4. The agent executes the action and reports the result, recorded in history.

The CVE page does not show a generic vulnerability list, but the ones affecting software installed on your hosts: Linux packages, Windows programs and libraries, the operating system's patch level and the platform's own dependencies.

• Sources: OSV for open-source ecosystems, NVD for commercial software (through a vetted mapping), MSRC for Windows patch level.
• Prioritisation: the CISA KEV catalogue (actively exploited) and the EPSS score (exploitation likelihood), alongside CVSS.
• Remediation: the minimum fixed version and a per-host remediation plan, written by the AI assistant or from templates.

1. Open Threats → CVE and sort by KEV/EPSS.
2. Click a vulnerability to see affected hosts.
3. Create the remediation task and follow it until the agent reports the fixed version.

The scanner checks your sites from an attacker's perspective. Passive mode reads only what is public (TLS, headers, DNS, HTTP methods); active mode also tries sensitive paths and content fuzzing, with explicit consent and for administrators only.

1. Open Threats → Security Scanner and enter the target (a domain you own).
2. Choose passive or active mode; for active, confirm you are entitled to scan the target.
3. Read the findings, grouped by severity and mapped to compliance controls.
4. Each finding comes with remediation steps and, optionally, a playbook for a coding assistant.
5. Schedule recurring scans and compare results over time.

An OSINT investigation gathers what is public about a target without probing it: certificates from Certificate Transparency logs, DNS records, services indexed by public engines, and content the site publishes itself (pages, scripts, sitemap).

1. Open Threats → OSINT and start an investigation on your domain.
2. Wait for it to finish — some public sources respond slowly, and the investigation runs in the background.
3. Read the report: domain tree, hosts found, exposed services, email DNS configuration.
4. Open the Remediation tab: findings are grouped by fix, each with its effect.
5. Optionally, scan all discovered hosts — sequentially, one at a time.

Attackers register domains that resemble yours (swapped letters, other extensions, added words) for phishing or fake shops. Defneo combines several discovery methods and checks each candidate's page to estimate whether it is a clone.

1. Enter your domain and start the check.
2. Review the candidates: the clone score, the factors behind it and whether the domain is actually yours (same server as the original).
3. Mark each candidate (for example legitimate or malicious); your mark sticks on later runs.
4. In the commercial edition, add important domains to the watchlist — you are notified only of new findings.
5. For a confirmed clone, use the attribution and takedown analysis: who hosts it, who registered it, and the fastest way to get it stopped.

CTEM (Continuous Threat Exposure Management) gathers findings from every module — CVE, scanner, OSINT, network scans, configuration — onto the assets they concern and turns them into a workflow: discovery, prioritisation, remediation, verification.

• Assets with criticality; changing criticality recalculates finding scores.
• Explainable risk score — factors add up exactly to the score and are shown.
• Clickable KPIs, with the exact list behind every number; a KPI that cannot be computed shows “n/a”, not 0.
• Network scans authorised per target, with exclusion lists that always win.
• Risk acceptance — administrators only, with reason, owner and expiry date.

Every integration with a third-party service (payment processor, CRM, email, cloud) is a key that, if leaked, grants access to data. The Integrations page keeps track of those keys — without storing the secrets — and computes each one's risk.

1. Open Exposure → Integrations and add your integrations (some are discovered automatically).
2. Fill in the metadata: owner, permissions, IP restrictions, last rotation date, volume of data reachable.
3. Follow the score and its factors; rotate keys that are old or too permissive.

• Email Auth — checks SPF, DKIM and DMARC on your domains and explains what is missing to prevent spoofing of your addresses.
• HIBP — checks whether the organisation's addresses appear in public data breaches, including a local database for checking passwords without sending them out.
• GitHub audit — reads the organisation audit log and flags risky actions: SSH keys added, OAuth apps authorised, repositories made public, branch protection disabled.
• Azure AD (Entra ID) audit — reads the audit and sign-in logs: role changes, application consents, risky sign-ins, MFA failures.

1. Open the page you need from the Identity or Audit menu.
2. Connect the source (domain, GitHub organisation, Azure tenant) with read permissions.
3. Investigate events by severity; results feed the compliance controls for authentication and access.

The NIS2 self-assessment shows where you stand against the risk-management measures required by the NIS2 Directive (Art. 21), transposed in Romania by Emergency Ordinance 155/2024. Each control has a practical explanation and an ISO 27001 mapping.

1. Open Compliance → NIS2 self-assessment.
2. Go through the domains and set each control's status: compliant, partial, not started or not applicable.
3. Follow the score and the gap list, ordered by importance.
4. Use the gap list as the starting point for your action plan.

The NIS2 action plan turns requirements into concrete work. The top of the page is the guided plan: what to do, in order, why it matters and how to do each step, with upcoming deadlines highlighted.

• Entity profile — sector, size, type (essential/important) and contact details, used in forms.
• Controls with live signals — some controls tick themselves from what other modules do (for example backup, MFA, training, monitoring), with the evidence source shown.
• DNSC track — the registration and reporting stages, with deadlines derived from the previous stage.
• Incident register — a significant incident starts the 24-hour, 72-hour and 30-day clocks, with forms pre-filled from the incident data.
• PDF report — every control with its status and evidence source, for an audit or inspection.

1. Complete the entity profile.
2. Follow the guided plan's steps; mark manual steps as done.
3. When an incident happens, open it in the register immediately — clocks start from detection time.
4. Export the PDF report when you need it.

The DORA module covers the requirements of Regulation (EU) 2022/2554 on digital operational resilience: the ICT risk-management framework, protection and detection, response and recovery, testing, incident management and ICT third-party risk.

1. Open Compliance → DORA.
2. Check the controls proven automatically (backup, monitoring, detection, training and more) and each one's source.
3. Complete the organisational controls and attach evidence.
4. Use the Supplier register as the starting point for the register of information.
5. Generate the narrative and the audit report.

• ROPA (Art. 30) — the record of processing activities, with each activity's gaps flagged: missing legal basis, transfer without a mechanism, pending DPIA.
• Data-subject requests (Art. 15–22) — a 30-day clock, with the extension allowed by Art. 12(3).
• Personal data breaches (Art. 33/34) — a 72-hour clock and a draft notification generated from the breach data.
• Processors (Art. 28) — processing agreements and their annual review.
• Technical and organisational measures (Art. 32) — many prove themselves from the platform's state (access control, TLS, backup, integrity, detection, agents).
• DPIA screening — the criteria that indicate an impact assessment is required.

1. Open Compliance → GDPR and fill in the record of processing.
2. Log requests and breaches as they happen; follow the clocks.
3. Export the PDF documents: ROPA, Art. 32 evidence, privacy notice skeleton.

The ISO module covers the management-system requirements (clauses 4–10) and the 93 Annex A controls of ISO/IEC 27001:2022. Technical controls receive live signals from the platform's modules, and every control comes with practical guidance.

1. Open Compliance → ISO Standards.
2. Set each control's applicability and justification.
3. Fill in status and evidence; follow the controls proven automatically.
4. Export the Statement of Applicability (SoA) as PDF.

The Compliance Center reads what the other modules do and shows the state of every enabled framework, with the list of items needing attention. A control mapped once (for example “tested backup” or “MFA for administrators”) serves every framework that requires it.

• A score per framework, with drill-down to the control and the evidence source.
• The attention list: controls that regressed, deadlines approaching, expired evidence.
• A framework whose source cannot be read shows as “unavailable”, not 0% — two different statements.

An auditor wants to know not only where you stand today but where you stood on a given date. Evidence snapshots freeze the state of controls at a point in time. Each snapshot is cryptographically linked to the previous one, and the database refuses any change or deletion.

1. Create a snapshot before an audit or at the end of each month.
2. Run Verify chain: the result tells you either that the chain is intact or the first altered entry.
3. Export the snapshot for the auditor.

NIS2 and DORA require managing the risk introduced by suppliers. The register tracks each supplier: the services they provide, the access they hold in your systems, the contract, assessments and criticality.

1. Open Compliance → Supplier register and add your suppliers.
2. Record each one's access (accounts, keys, connections) and review date.
3. When the relationship ends, revoke access — the row stays in history.
4. Export the register as the starting point for the DORA register of information.

The first step of AI governance is knowing what you use. The inventory is the module's backbone: each AI system or tool (from a customer chatbot to an internal assistant) has an owner, purpose, provider, data processed and risk tier.

1. Open Compliance → AI Governance and add your AI systems.
2. Classify each system under Regulation (EU) 2024/1689 (the AI Act).
3. For high-risk systems, complete the Art. 9–15 obligations (risk management, data, documentation, logging, transparency, human oversight, robustness).
4. Optionally, track each system's cost, benefit and implementation phase.

Besides per-system obligations, the AI Act requires organisation-level measures: staff AI literacy (Art. 4), transparency towards people interacting with an AI system (Art. 50), rules for general-purpose models and internal governance.

1. Open Compliance → AI Governance; the guided plan is at the top.
2. Follow the steps in order; urgent ones are obligations already in force and not yet met.
3. Mark a step as done only when its controls are met — the plan and the full list stay in sync.
4. Export the PDF documents for audit.

More and more automations and AI agents (your own or your partners') access your applications. The AI Policies page lets you declare them explicitly — by User-Agent and optionally by IP — to separate them from unknown traffic and follow their behaviour.

1. Open Endpoint → AI Policies and add an agent: name, type, User-Agent pattern, optional IP pattern.
2. Enable or disable the policy as needed.
3. Follow anomalies: unusual volumes, new paths, errors. An AI assistant explains the anomaly, with a template fallback.

Before an AI assistant is allowed to act, you must be able to answer at any time: which model was asked, by which module or token, about what, what it answered and which human decided. The AI journal answers exactly that.

• Recorded automatically: model calls, proposals, human decisions (apply/reject) and actions executed.
• Prompts and answers are kept only as a fingerprint (hash) and length — content is not stored.
• The journal cannot be edited or deleted; chain verification points to the first altered row, if any.
• When the action comes through an API token, the journal records the token.

1. Open Compliance → AI journal.
2. Filter by kind, actor or subject.
3. Run chain verification before an audit.

The training module turns “we train our staff” into a proven statement: who, which course, when, with what score and when it expires. The included catalogue covers the essentials (phishing, passwords and MFA, personal data, incidents, AI) plus a dedicated management course.

1. Open Compliance → User training and import learners (the same list the phishing simulations use).
2. Mark managers and roles — management has separate requirements under NIS2 and DORA.
3. Enrol learners in courses; each gets a personal link, with no panel account needed.
4. The learner goes through the modules (on a phone too, as swipeable cards) and takes the quiz.
5. Automatic reminders go to those who have not finished; follow coverage across the organisation.

Phishing simulations measure how people react to realistic deceptive messages: fake delivery notices, lock screens, collaboration invites, urgent payment requests from the “CEO”.

1. Open Identity → Phishing Sim and configure the sending server.
2. Choose the scenario and recipients.
3. Launch the campaign and follow: opens, clicks, credentials entered, reports.
4. Automatically enrol those who clicked in the matching course.

Security policies (acceptable use, passwords, remote work, use of AI) only matter if people know them. The training module publishes policies and collects attestations.

1. In Compliance → User training, open the policies section.
2. Publish the policy, with its audience and the period after which it must be re-confirmed.
3. Employees confirm it from their personal link.
4. Follow coverage per policy.

Your domain's MX record points to the Defneo server. Every message from the internet reaches the gateway first, is checked with the same rules as the Site Shield mail filter, and only then is handed to Exchange (or your Microsoft 365 tenant).

• What it checks: executable and script attachments (also inside ZIPs), HTML attachments with a password form, macro documents, known malware hashes, senders from hijacked networks (Spamhaus DROP) or abuse lists, links whose text shows another domain than the target, display names that imitate another domain, your own domain sent from outside without a signature.
• Sender reputation comes from the attackers your installation has banned and from the Defneo community feed.
• Antivirus: ClamAV-format signatures always; the full ClamAV engine optionally (it needs about 1.5 GB of memory).

Three modes: monitor (only labels the message), tag — the default — (junk gets a spam header and an Exchange transport rule moves it to the Junk folder) and reject (clear phishing and malware are refused outright). A single weak signal never moves a message; it is only recorded.

1. Together we set the accepted domains and the Exchange receive connector (or Microsoft 365 tenant) the gateway delivers to.
2. In Exchange, the internet receive connector accepts only the gateway's address — otherwise spammers bypass the MX and deliver directly.
3. A transport rule sends messages tagged by Defneo to the user's Junk folder. In Microsoft 365: an inbound connector from the gateway, with Enhanced Filtering, plus the same rule.
4. Move the MX record to the Defneo server. Start in monitor mode if you want to see the verdicts before anything is moved.

Exchange's public names (for example mail.company.com and autodiscover.company.com) go through Defneo, with an automatic certificate, like any other site. On top of that, Defneo applies rules that know Exchange:

• Exploits refused and the source banned: ProxyShell, ProxyNotShell, ProxyLogon cookies and web shells under aspnet_client.
• Only client paths reach Exchange: Outlook on the web, EWS, ActiveSync, Autodiscover, MAPI, RPC and OAB. Any other path on those names gets a 404.
• The admin centre (ECP) and remote PowerShell are refused from the internet — without a ban — and stay open to the networks you declare trusted.
• Brute force on Outlook on the web: failed logins are counted (the page Exchange sends you to after a wrong password), not logins — a whole office signing in in the morning is not mistaken for an attack.

On a hosting account without root you cannot filter mail before delivery, but the account owns its mailboxes. Site Shield reads them on every run (every 5 minutes) and moves clear junk into each mailbox's Junk folder — nothing is modified or deleted.

• Users teach it from any client (webmail, Outlook, phone): a message moved into Junk is a report — the account learns its links and files, the mailbox its sender.
• A message moved back out of Junk means "not junk": the sender becomes trusted for that mailbox and what it taught is unlearned.
• A daily e-mail lists everything that was moved, so a wrong move is easy to find.

1. Open System → Users (administrators only).
2. Add a user, choose the role and hand over the login details.
3. Ask them to enable 2FA or a passkey at first login.
4. Disable leavers' accounts immediately.

An API token lets a script or agent use the panel without borrowing a person's session. The token acts on behalf of its owner, with a role that can never exceed the owner's.

1. Open System → Settings → API access (tokens) (administrator, real session).
2. Create the token: name, maximum role, expiry (at most 90 days).
3. Copy the token — it is shown only once.
4. Use it in the Authorization: Bearer … header of API requests.
5. Revoke the token when no longer needed; its usage history is kept.

Backup packs the platform's configuration and database and sends them to a destination outside the server. Backup status is also evidence for the continuity controls of NIS2, DORA and ISO 27001.

1. Open the panel's Backups page (administrators only).
2. Configure the destination: Google Drive, an SSH server or a WebDAV server.
3. Run a test backup and check the file at the destination.
4. Let the scheduled backup run automatically and follow the last run's status.

Every Defneo release is described by a digitally signed manifest. The panel checks daily for a new version (only if you enabled checking) and shows what it contains, including whether it is a security update.

1. Open System → Updates.
2. Read the notes of the available version.
3. Press Apply and confirm by typing the version (administrators only).
4. The server re-verifies the signature, takes a backup, applies the update and checks platform health.
5. If the health check fails, the platform automatically rolls back to the previous version.

When you change a backend, a rate-limit rule or HTTPS access to the panel, Defneo first saves the current state, applies the change and checks the proxy's health. If something breaks, it rolls back automatically to the last good configuration.

1. Open Traffic → Config versions for the change history.
2. Compare two versions to see exactly what changed.
3. Restore an earlier version manually if needed.

If your organisation already has a SIEM or SOC, Defneo sends it findings and events. Every event enters a queue and is retried if the destination is unavailable; what cannot be delivered is kept for analysis.

1. Open System → SIEM Export (configuring destinations requires the administrator role).
2. Add the destination: syslog (UDP/TCP/TLS), webhook, Splunk HEC, Microsoft Sentinel or Elastic; pick the format (for example CEF or ECS).
3. Send a test event.
4. Follow the queue, successful deliveries and undelivered messages.

Every installation reports the IPs it banned on its own, with the detection scenario and time. The central feed server publishes an IP only when several independent sources confirm it, and signs the list. Installations fetch it and apply it automatically at the edge.

• Only the attacker's IP address, scenario and time are sent — never your traffic or your users' data.
• The list is digitally signed; a list with an invalid signature is refused.
• Besides the community, the feed includes maintained public blocklists.
• Each feed ban's reason shows its source, so you know where it comes from.
• In the commercial edition, the feed also delivers vulnerability prioritisation data (KEV/EPSS) for the CVE page.

The first step is to find out whether the 403 affects only some visitors or everyone.

1. Only you or one visitor: look up the IP in the panel. If it has a ban decision, the IP page shows why — see A legitimate visitor was banned.
2. Only from certain countries: check the geoblocking list and its exceptions.
3. Only for certain tools: if the backend has “AI crawlers: All”, AI assistants get a 403 on purpose.
4. For every visitor on every site: the blocking layer is fail-closed — if it cannot check decisions, it refuses everything. Check in System → Infrastructure that the CrowdSec service is running and healthy, then restart it if needed.
5. Right after a restart: wait a minute or two for the blocking layer to load its decision list.

1. Ask the visitor for their public IP address (for example from a “what is my IP” site) or find it in Analytics by time and page.
2. Open the IP page: see the decision, the scenario that triggered it and the requests made.
3. Press Unban. The decision disappears from every backend immediately.
4. If the scenario may recur (for example a partner making many legitimate automated requests), add the IP to an exception list.
5. If the scenario seems too sensitive for your site, note the case and send it to support.

1. DNS: check that the domain (and the www variant, if you use it) points to the public address of the Defneo server, not an old server.
2. Ports: ports 80 and 443 must be open from the internet to the server. If the server sits behind a router or firewall, set up port forwarding.
3. CDN or proxy in front: if the domain goes through a CDN, make sure it allows Let's Encrypt validation, or use the CDN's certificate.
4. Issuance limits: Let's Encrypt limits the number of certificates per domain per week. After many failed attempts, wait before retrying.
5. ACME email address: check that it was set during installation; it is used for Let's Encrypt notifications.

After fixing, visit the domain over HTTPS again; issuance resumes automatically.

An agent that has not reported for a while shows as offline in Endpoint → Agents and in the briefing. Check, in order:

1. The install: run the install command again and read the output to the end. A silently failed download (for example due to an untrusted certificate) can leave the agent uninstalled.
2. Connectivity: from the host, check that the panel address is reachable over HTTPS.
3. The token: enrolment tokens are single-use and expire. If the host was reinstalled or the token was already used, generate a new one.
4. System clock: reports are signed with a timestamp; a clock off by a few minutes makes reports get rejected. Enable NTP sync.
5. The service: check that the agent service is running (systemd on Linux, the scheduled task or service on Windows).
6. The panel certificate: if you changed the panel's certificate or domain, the agent may refuse the new identity; re-enrol it.

The Updates page distinguishes several outcomes, each with a different meaning:

1. Read the update log on the Updates page.
2. Check memory and disk space — a lack of resources is the most common cause.
3. Fix the cause and retry.
4. If the problem persists, send the log to support.

A dashboard that shows 0 when it could not read its data is lying: “zero vulnerabilities” sounds reassuring but may mean the source failed. That is why Defneo makes the distinction everywhere.

• 0 — the source was read and found nothing.
• Unavailable / n/a — the source could not be read or the indicator cannot be computed; the reason is shown.
• Not verified — there is no reliable way to check (for example a program with no mapping to the vulnerability database).
• Template — text that would have been AI-generated was produced from a template because no AI model is configured.

Every Defneo component — proxy, detection, databases, panel — runs on your server. There is no cloud console your data passes through.

• Analytics is computed from your own proxy's log, with no third-party scripts and no tracking cookies.
• Telemetry of third-party components that ship with it enabled (for example Grafana) is turned off.
• Update checking is optional; you can replace it with manually importing the signed manifest.
• AI features use an OpenAI-compatible endpoint you choose — including a local model. With no endpoint configured, they use templates and send nothing; where context contains IPs, they are pseudonymised before sending, and every call is recorded in the AI journal.

We take every security report about Defneo seriously — the platform, the agents, the installer or the website.

1. Send your report to security@defneo.com.
2. Include the affected version, reproduction steps and the estimated impact.
3. Do not access data that is not yours and do not degrade other people's services while testing.
4. We acknowledge receipt, keep you informed and coordinate the disclosure date with you.