New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Komari Probe Intranet Deployment Guide
Komari Probe Intranet Deployment Guide
This document is based on a WireGuard intranet environment. All communications are restricted to the intranet, with no public ports exposed.
Operations are idempotent and can be executed repeatedly.
Network Architecture
| Node | WireGuard IP | Role |
|---|---|---|
| task | 10.10.0.1 | Komari Master + WG Main Node |
| cf | 10.10.0.x | Agent + XRay Proxy |
| cf2 | 10.10.0.4 | Agent + XRay Proxy |
| bwg | 10.10.0.x | Agent |
Access Path: Local Browser → v2rayN(XHTTP) → CF CDN → cf/cf2 XRay → WG Intranet → task:8008
I. Master Installation (task server)
1.1 Install Docker (Skip if already installed)
curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable docker && sudo systemctl start docker
1.2 Deploy Komari Container
# Idempotent: Clean up old containers first
docker stop komari 2>/dev/null; docker rm komari 2>/dev/null
mkdir -p /opt/komari/data
docker run -d \
-p 127.0.0.1:25774:25774 \
-v /opt/komari/data:/app/data \
--name komari \
--restart unless-stopped \
ghcr.io/komari-monitor/komari:latest
1.3 View Initial Password (Generated only during initial DB creation)
docker logs komari 2>&1 | grep "Password"
⚠️ The password is only displayed during the first startup. To reset, delete
/opt/komari/data/komari.dband recreate the container.
1.4 Reset Password (If forgotten)
docker stop komari && docker rm komari
rm -f /opt/komari/data/komari.db
docker run -d \
-p 127.0.0.1:25774:25774 \
-v /opt/komari/data:/app/data \
--name komari \
--restart unless-stopped \
ghcr.io/komari-monitor/komari:latest
# View new password
docker logs komari 2>&1 | grep "Password"
II. Nginx HTTPS Reverse Proxy (task server)
2.1 Install Nginx
sudo apt update && sudo apt install -y nginx
2.2 Apply for Let's Encrypt Wildcard Certificate (DNS Verification)
# Install acme.sh (Idempotent)
curl https://get.acme.sh | sh -s [email protected]
source ~/.bashrc
# CF API Token
export CF_Token="YOUR_CF_API_TOKEN"
# Apply for certificate
~/.acme.sh/acme.sh --issue --dns dns_cf \
-d "*.xxxx.xxx" \
-d "xxxx.xxx" \
--keylength 2048
# Install certificate
~/.acme.sh/acme.sh --install-cert -d "*.xxxx.xxx" \
--key-file /etc/nginx/komari.key \
--fullchain-file /etc/nginx/komari.crt \
--reloadcmd "systemctl reload nginx"
2.3 Configure Nginx
cat << 'EOF' | sudo tee /etc/nginx/sites-available/komari
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
proxy_cache_path /tmp/komari_cache levels=1:2 keys_zone=komari:10m max_size=100m inactive=60m;
# HTTPS - For browser access (Port 8008)
server {
listen 10.10.0.1:8008 ssl;
server_name jk.xxxx.xxx;
ssl_certificate /etc/nginx/komari.crt;
ssl_certificate_key /etc/nginx/komari.key;
# Static asset caching (Solves chunked transfer truncation issues under CF CDN)
location /assets/ {
proxy_pass http://127.0.0.1:25774;
proxy_cache komari;
proxy_cache_valid 200 1d;
proxy_cache_use_stale error timeout;
proxy_buffering on;
proxy_buffer_size 128k;
proxy_buffers 8 256k;
}
location / {
proxy_pass http://127.0.0.1:25774;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 86400s;
}
}
# HTTP - For Agent intranet communication (Port 25774)
# Agents connect via WG intranet; no TLS needed to avoid cert validation issues
server {
listen 10.10.0.1:25774;
location / {
proxy_pass http://127.0.0.1:25774;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 86400s;
}
}
EOF
# Enable site and remove default
sudo ln -sf /etc/nginx/sites-available/komari /etc/nginx/sites-enabled/komari
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx
III. DNS and Routing Configuration
3.1 Cloudflare DNS
Add A record: jk.xxxx.xxx → 10.10.0.1, Proxy status: Off (Grey cloud/DNS Only).
3.2 XRay Server Routing Rules (cf / cf2)
Add the following at the very beginning of the routing.rules array:
{
"type": "field",
"domain": ["domain:jk.xxxx.xxx"],
"outboundTag": "direct-out"
}
⚠️ This must precede the
geoip:privateblock rule; otherwise, intranet IPs will be blackholed.
Restart XRay:
sudo systemctl restart xray
3.3 v2rayN Client Routing
Ensure the routing rules in v2rayN route .xxxx.xxx or jk.xxxx.xxx through the proxy instead of a direct connection.
IV. Agent Installation (Monitored Nodes)
4.1 Panel Settings
Log in to [https://jk.xxxx.xxx:8008](https://jk.xxxx.xxx:8008), go to Settings, and set the Dashboard Address to:
http://10.10.0.1:25774
Note: Agents communicate via HTTP port 25774 to avoid certificate issues. Browser access remains via
[https://jk.xxxx.xxx:8008](https://jk.xxxx.xxx:8008).
4.2 Add Nodes
- Go to Servers → Add Node, add cf / cf2 / task / bwg.
- Click the Download Icon next to the node to get the one-click installation command.
- Recommended: Check Disable Remote Control (for security) and Ignore Unsafe Certificates (if using self-signed certs).
4.3 Execute Installation Command on Each Node
# Verify intranet connectivity first
curl http://10.10.0.1:25774
# Execute the installation command generated by the panel (URL should be http://10.10.0.1:25774)
# Example (Copy the actual command from your panel):
# wget -qO- https://raw.githubusercontent.com/komari-monitor/komari-agent/refs/heads/main/install.sh \
# | sudo bash -s -- -e http://10.10.0.1:25774 -t <TOKEN> --month-rotate 1
4.4 Uninstall Agent
sudo systemctl stop komari-agent
sudo systemctl disable komari-agent
sudo rm -f /etc/systemd/system/komari-agent.service
sudo systemctl daemon-reload
sudo rm -rf /opt/komari/agent /var/log/komari
V. Security Hardening
5.1 Port Exposure Check
# Confirm public IP cannot access these ports
curl -I http://PUBLIC_IP:8008 # Should return Connection Refused
curl -I http://PUBLIC_IP:25774 # Should return Connection Refused
5.2 Architectural Security Points
- Docker binds only to
127.0.0.1:25774, not exposed to the public. - Nginx HTTPS listens on
10.10.0.1:8008(for browser access). - Nginx HTTP listens on
10.10.0.1:25774(for agent communication). - Both ports are bound to the WG intranet interface; unreachable from the public internet.
- Agents communicate via WG intranet
[http://10.10.0.1:25774](http://10.10.0.1:25774)(no certificate required). - Users access via XRay proxy chain to HTTPS:8008; no direct external path.
- XRay routing still blocks
geoip:privateexcept for the explicitly allowed10.10.0.0/24.
VI. Common Operations
# View Master status
docker ps | grep komari
docker logs komari --tail 20
# Restart Master
docker restart komari
# Update Master
docker pull ghcr.io/komari-monitor/komari:latest
docker stop komari && docker rm komari
docker run -d \
-p 127.0.0.1:25774:25774 \
-v /opt/komari/data:/app/data \
--name komari \
--restart unless-stopped \
ghcr.io/komari-monitor/komari:latest
# Backup Data
cp -r /opt/komari/data /opt/komari/data.bak.$(date +%Y%m%d)
# View Nginx status
sudo systemctl status nginx
sudo tail -20 /var/log/nginx/error.log
# Certificate Renewal (acme.sh renews automatically; manual trigger below)
~/.acme.sh/acme.sh --renew -d "*.xxxx.xxx" --force
VII. Troubleshooting
| Symptom | Action |
|---|---|
| Browser cannot access | Check if v2rayN global proxy is on or hosts are configured. |
| No request logs in XRay | Request intercepted by v2rayN; check client routing rules. |
| XRay shows request but connection fails | Check if the outbound used is direct-out or warp-out. |
| JS assets fail to load | CF CDN chunked truncation; refresh or check Nginx cache config. |
| Agent Offline | Verify WG tunnel: ping 10.10.0.1. Ensure Agent service is running. |
| Agent reports 400 Bad Request | HTTP request sent to HTTPS port; ensure Agent uses [http://10.10.0.1:25774](http://10.10.0.1:25774). |
| Agent reports Cert Error | Use HTTP port 25774 or check "Ignore Unsafe Certs" during install. |
| Certificate untrusted | Use a real Let's Encrypt certificate with a valid domain. |
| Agent process remains after uninstall | Find PID with ps aux | grep komari-agent and sudo kill -9 <PID>. |
Thanked by 1JasonM
Comments
https://www.huntress.com/blog/komari-c2-agent-abuse
Seems like exactly the type of application users that need a step by step howto should install on their boxes.
@totally_not_banned correct, you should disable almost feature on agent if u only use it as telemetry/status.
You can run it inside rootless container as well with some caps or mount
I am running the Komari server in a Docker environment, but I noticed that I can access a terminal via the control panel. It actually allows me to execute commands directly on my monitored server, just like SSH. Is there a way to disable this?
Well, the article says that
--disable-web-sshwill disable at least the command execution but i'm not really familiar with the application beyond that, sorry.if you'd like to host a self-deployed monitoring app, this one: ltstats , it has no web/* ssh feature.
I found that someone also use it in LET, such as @oloke and @Neoon
Sounds insecure as fuck, why does your monitoring panele, need full root access?
LTstats has It has been working well for me for almost a year. I heard there is a new release planned with more features (but definitely not web SSH). It's also pretty easy to theme and customize.
@lukast__ also runs an instance of course.
happy to hear ltstats has news features planned.
New Features when?
There's quite a lot planned (being able to ping IPs will definitely come, and it's planned to also support (but I cannot yet say with certainty that all will get implemented) monitoring multiple disks independently and to make it very easy to add custom data); however, this requires quite significant changes, and because I want to make sure that it's as bug-free as possible (generally and especially security-wise), and as I didn't have much time for it lately, I can't really say how long it will take, probably a few months.
(Suggestions are always welcome.)
And thanks for the mention @igctt and for the small review @oloke
(And sorry as this is not really related to the initial topic of this thread.)
if possible, would you like to add an 'alias metric' feature? that's in bare metal server(in home), cpu_steal is not necessary, and system temperature is more attractive to me, I'd like to tailor the agent a bit to report cpu temperature in the cpu_steal field, then no more fields needed and in the web panel, an alias setting 'cpu_steal -> temperature' let it can be notify when high temp is reached.
another one, some servers have expire date, may it notify when expire date is in one week or two days? the notify frequency that is one time a day is enough.
thank you for your great project. it's pretty good now. that's my two cents idea.
I am running komari monitor using docker compose and all the agents are behind tailscale. Though the webUI is exposed by nginx (for logging and reverse proxy) and cloudflare tunnels on a obscure subdomain. Though it's nice that you can have it set to private
No matter how you run it, you should always disable web ssh in agents. Even before the bug, i had disable it, its just common sense, no agent should have that power. Also run them from user, not root. Just download agent and server standalone files and run them from user.