Skip to content

Closer to your system.
Ahead of the threat.

Threat detection, DoS mitigation, scoped blocking, and local evidence. Security built around your Linux infrastructure — and the people running it.

Install BHIM KVHExplore every capability
Vibrant orange, pink, violet, and blue gradient
Protection begins
at the source.
ILLUSTRATIVE CLI SESSION

❯ bhim-protection health --strict

{"status":"healthy","database":"ok",
"reasons":[],"heartbeat":"…"}

❯ bhim-protection incidents --limit 20

# inspect local evidence, on your terms
DETECT / RESPOND / UNDERSTANDSelf-managed. Local-first.
Terminal-first workflow
Policy-limited response
Local evidence
Optional deeper visibility
See BHIM KVH in context
Cyan blue and white flowing gradient
Visibility starts at the source.
SSH activityFailure windows
HTTP trafficRate patterns
File integrityReviewed baselines
Illustrative capability view
BHIM KVH

See the signals.
Understand the context.

Read the activity your infrastructure already produces. SSH failures, HTTP request patterns, process changes, and file modifications become local, inspectable observations.

  • Journald and SSH logs with saved collection state
  • HTTP rate windows and trusted proxy parsing
  • Process, socket, and critical-file monitoring
Explore detection
Cyan blue and white flowing gradient
Visibility starts at the source.
SSH activityFailure windows
HTTP trafficRate patterns
File integrityReviewed baselines
Illustrative capability view
BHIM KVH

See the signals.
Understand the context.

Read the activity your infrastructure already produces. SSH failures, HTTP request patterns, process changes, and file modifications become local, inspectable observations.

  • Journald and SSH logs with saved collection state
  • HTTP rate windows and trusted proxy parsing
  • Process, socket, and critical-file monitoring
Explore detection
Warm orange and cream gradient
Your policy decides the action.
Management IPsAllowlisted
Response scopeSSH / HTTP
DurationYour policy
Illustrative capability view
BHIM KVH

Block the threat.
Keep a way back.

Respond explicitly to a reviewed incident, or enable automatic response after tuning your policy. Keep management addresses protected and actions scoped to the services you choose.

  • Separate SSH and HTTP port scopes
  • Management allowlists and configurable expiry
  • Peer-authenticated, policy-limited root executor
Understand scoped blocking
Bright pink and white flowing gradient
Local evidence. Useful context.
TimelineChronological
EvidenceLocal SQLite
ExportsJSONL / CSV
Illustrative capability view
BHIM KVH

Keep the story.
Follow the evidence.

Move from an alert to a timeline. Query retained observations, inspect available process relationships, and export records into the operational workflow you already use.

  • SQLite evidence and category JSONL logs
  • Incident timelines and optional process graphs
  • JSONL / CSV exports and local chain verification
Explore CLI and JSON output

Built for your
side of the terminal.

Real infrastructure. Different responsibilities. A clear way to see what matters and choose what happens next.

Explore the possibilities
Soft golden yellow and peach gradient
LINUX HOSTS
BHIM KVH

Local visibility.
Direct control.

For the server you look after.

Keep SSH activity, critical files, and local health in view without another cloud dashboard.

Bright pink and white flowing gradient
WEB INFRASTRUCTURE
BHIM KVH

Observe the pattern.
Choose the response.

For the traffic you serve.

Review HTTP patterns and combine native ingress limits with carefully scoped response.

Cyan blue and white flowing gradient
OPERATIONS & RESPONSE
BHIM KVH

Keep the evidence.
Understand the story.

For the questions after an alert.

Follow incidents, inspect retained evidence, and export the context into your own workflow.

Warm orange and cream gradient
OPTIONAL EDGE INTEGRATION
BHIM KVH

Review the plan.
Apply with intent.

For protection beyond the host.

Use a separate, reviewed AWS WAF IP-set plan when your architecture calls for edge controls.

01 / 04

A complete view.
Purposeful controls.

From the first observation to the next decision. Explore the capabilities available in BHIM KVH and configure the ones your environment needs.

SSH & HTTP detection

Observe SSH failures and suspicious success after failures. Detect HTTP rate patterns with configured windows, trusted proxy chains, and separate shared-IP thresholds.

Journald · access logs · saved collector state
Read the guide

DoS mitigation, in layers.

Combine post-request rate observations with native Nginx inline limits. Use host-level response only where the real client is a verified direct peer.

Native ingress limits · scoped host INPUT rules
Read the guide

Blocking with boundaries.

Choose SSH or HTTP ports, keep management IPs allowlisted, and set a reviewed timeout. The separate executor validates requests against protected policy.

Explicit commands · optional automatic response
Read the guide

Know when files change.

Capture trusted baselines for critical files and inspect integrity findings. Compare current state before deciding whether a change is expected.

Baselines · verification · protected-file digests
Read the guide

Keep a local record.

Retain observations in SQLite, follow incidents chronologically, and inspect category logs. A bounded durable spool supports retry when persistence is interrupted.

Incidents · timelines · JSONL / CSV export
Read the guide

Recovery is your decision.

Take explicit snapshots, inspect their manifests, and restore against a reviewed current hash. Quarantine supported non-critical files when you choose.

Snapshots · hash checks · manual quarantine
Read the guide

Look beneath the process.

Optional BCC collection adds selected exec, file, and connect observations with process identity and queryable relationships. Coverage depends on the target kernel.

Optional kernel collector · provenance graphs
Read the guide

Scan with defined limits.

Enable bounded malware scanning with pinned offline signatures. Optional vulnerability scanning uses a reviewed Trivy executable and preloaded database.

File and time budgets · pinned SHA-256 inputs
Read the guide

Connect to AWS WAF.

Use the optional adapter to review and apply a dedicated AWS WAF IP-set plan. Edge updates stay separate from the offline daemon and require explicit approval by hash.

Reviewed plans · dedicated IP sets · explicit apply
Read the guide
Warm orange and cream gradient
YOUR INFRASTRUCTURE / YOUR DECISIONSReadable signals.
Deliberate response.
Inspect before enabling automation

You’re in charge.

Review what BHIM sees, configure your thresholds, and choose the actions your environment allows. Start with observations, then introduce automation when you understand its impact.

Make the policy yours
Purple, cyan, pink, and peach gradient
FROM OBSERVATION TO UNDERSTANDINGKeep the context.
Follow the evidence.
Local records · familiar commands

Make the next step clearer.

Move from a finding to an incident timeline. Query retained observations, verify local evidence, and export JSONL or CSV into the tools you already use.

Explore the command line
SEPARATE RESPONSIBILITIES. CLEAR BOUNDARIES.

Observation stays light.
Privilege stays limited.

The split-service profile separates the monitor from the root executor. Add the optional kernel collector only when the target system and your requirements call for it.

See the full architecture

Monitorbhim-agent.service

Unprivileged collection and persistence

Respondbhim-response.service

Protected policy, peer-authenticated local socket

Observe deeperbhim-kernel.service

Optional, separately privileged BCC collector

Start with visibility.
Build confidence from there.

A deliberate path from installation to response. Review the actual behaviour on your host before putting automation in charge.

  1. 01

    Prepare your Linux host.

    Build a native binary and review systemd groups, log access, configuration, and recovery access.

  2. 02

    Install the split profile.

    Use the monitoring-first example. Keep the monitor and privileged response helper separate.

  3. 03

    Verify what you can see.

    Check health, inspect evidence, and capture a trusted integrity baseline. Investigate degraded sources.

  4. 04

    Enable the response you need.

    Add management addresses, choose service scopes, and tune thresholds against legitimate traffic.

Follow the installation guide
Small commands. Useful answers.
sudo -u bhim bhim-protection health --strict

# Inspect the latest incidents
sudo -u bhim bhim-protection incidents --limit 20

# Export retained observations as JSONL
sudo -u bhim bhim-protection export --format json --limit 100

Run routine queries as the service account in the split profile. Advanced settings live in protected TOML.

Explore the configuration reference

A few things
worth understanding.

Clear answers about deployment, protection, and the decisions that stay in your hands.

Read the documentation
Is BHIM KVH a cloud dashboard?

BHIM KVH is a self-managed security agent that runs on your Linux infrastructure. You work with it through local commands: inspect health, review incidents, follow a timeline, and export retained observations. Version 0.4.0 does not include a central cloud dashboard or a public REST API.

The core workflow keeps observations and evidence on the host. This lets you fit BHIM into an existing operational process rather than introducing another control plane. It also means you remain responsible for access permissions, storage, retention, and any copies you export to other systems.

From host activity to useful answers
  1. 01Observe

    Read configured logs and system sources.

  2. 02Retain

    Store evidence locally in SQLite and JSONL logs.

  3. 03Inspect

    Use CLI queries and JSONL / CSV exports.

What you can do from the terminal

  • Check daemon health and operational metrics.
  • List incidents and read their event timelines.
  • Export records for your own scripts and analysis tools.
  • Query process relationships when the optional kernel collector provides them.
See the command and output reference
What does DoS protection cover?

BHIM uses several distinct layers. The log observer detects request-rate patterns after the server has recorded them. Native Nginx rate limits can reject excess requests inline. Scoped host blocking can stop traffic to selected SSH or HTTP destination ports when the socket peer is the verified client. These layers complement each other, but they are configured separately.

LayerWhat it doesBoundary
HTTP observationsFind rate patterns in access logs.Detection happens after requests are logged.
Native Nginx limitsApply inline per-key limits and burst handling.Requires reviewed Nginx configuration.
Host responseBlock selected INPUT ports for a reviewed IP.Cannot enforce a forwarded client as a direct socket peer.
AWS WAF adapterUpdate a dedicated edge IP set.Separate, explicit reviewed-plan operation.

If traffic arrives through a CDN, load balancer, or shared proxy, first establish which address your logs and firewall actually see. Banning the proxy’s address can affect many legitimate users. Use explicit proxy trust settings and place enforcement at the correct ingress layer.

Configure HTTP protection
Is AWS WAF synchronisation automatic?

No. The optional AWS adapter is separate from the offline daemon. It takes a JSON plan describing a dedicated IP set and its intended addresses. Review mode validates the plan and displays a digest without making an AWS request. Applying a change requires supplying the exact digest you reviewed and having the appropriate AWS CLI credentials.

A deliberate edge-update workflow
  1. 01Prepare a plan

    Choose the dedicated IP set, scope, region, and addresses.

  2. 02Review the hash

    Inspect the proposed change; review mode makes no AWS request.

  3. 03Apply explicitly

    Submit the reviewed digest using authorised AWS credentials.

What the adapter does not do

  • It does not create AWS credentials or run inside the offline monitor.
  • It does not attach an IP set to a WebACL for you.
  • It does not automatically expire or remove addresses later.
  • It does not replace a general request-body inspection WAF.

An applied plan replaces the addresses in the dedicated set. Keep IPv4 and IPv6 plans separate, review the complete desired contents, and use a new reviewed plan when addresses must be removed. This makes the intended change explicit before it reaches the edge.

Read the WAF integration guide
Which systems can I deploy on?

The host installation targets Linux with systemd and a native binary built for the target architecture. A distribution name alone does not establish compatibility: the service account, system groups, readable logs, firewall tools, and permissions all need to match the real host.

Check these before installing

  • Operating environment: Linux, systemd, and a binary compiled for the target CPU architecture.
  • Service prerequisites: Python 3 and system user/group tools for the split installer; review adm and systemd-journal group names.
  • Observation sources: access to journald or the selected SSH files, plus compatible HTTP logs when enabled.
  • Enforcement: nftables and a traffic path where host INPUT rules can protect the intended service.
  • Optional kernel telemetry: compatible BCC dependencies, running-kernel headers, tracepoints, and suitable privileges.

Containers and node-local Helm packaging are present in the source, but they require their own deployment validation. A host firewall is not automatically an EKS forwarding policy or an ALB edge control. Actual EKS rollout, node replacement, and reboot recovery remain separate checks for the environment you intend to operate.

Check installation requirements
Can I start without automatic blocking?

Yes. Starting with observations is a useful way to understand normal activity and confirm that BHIM sees the correct sources. The installation guide includes a monitoring-first TOML example and the split-service setup, separating the unprivileged monitor from its policy-limited root executor.

  1. Prepare a monitoring profile.Use the documented example rather than assuming the checked-in source defaults disable blocking.
  2. Validate sources and evidence.Check health reasons, inspect incidents, and confirm that the observed IP addresses match your traffic path.
  3. Protect administrative access.Add real management addresses to the allowlist and verify an independent recovery route.
  4. Introduce response deliberately.Choose service scopes and expiry, test an explicit action, then enable automatic policy only when its behaviour is understood.

Automatic response is a policy choice, not a requirement for collecting evidence. You can keep it disabled while using health checks, metrics, incident timelines, exports, and integrity observations.

Follow the monitoring-first setup
What should I know about version 0.4.0?

The source identifies 0.4.0 as a development candidate. It contains implemented monitoring, local evidence, scoped response, and optional integrations, but implementation and validation are different things. Validate the actual service profile, kernel, permissions, traffic path, and recovery process on your own staging host.

Understand the operational limits

  • Collection has boundaries. Polling can miss transient activity, and optional kernel observations cover selected events rather than every system action.
  • Storage is bounded. Retention, spool capacity, and resource budgets can limit what remains available for investigation.
  • Health is a check, not a guarantee. A healthy result does not prove complete visibility or the absence of an attack.
  • Evidence is locally verifiable. The hash chain can help detect retained-data corruption, but a sufficiently privileged attacker can rewrite local records.
  • Recovery remains explicit. Snapshots, reviewed-hash restores, and supported quarantine operations require operator decisions; automatic destructive restore is unsupported.

Review degraded events and metrics alongside alerts, keep backups and independent access, and test what happens after service interruption or a host reboot. Treat BHIM as part of a layered security process alongside patching, application controls, network protection, and operational review.

Review architecture and validation boundaries

Bring protection
closer to your infrastructure.

Explore BHIM KVH on your own Linux host. Start with the guide, understand your signals, and choose your response.

Get startedView pricing