← Back to home

Download PII Guard Server

Headless background service for Linux hosts. Install on a server that can reach your databases — every scan, credential and result remains securely on that machine.

v0.1.0 · checksums published below · auto-update ships with v0.2.

Server-based deployment (Linux)

Headless background service with a browser management UI on port 3200. Install it once on a Linux host that can reach your databases — every scan, credential and result stays on that machine.

Debian / Ubuntu / Mint (x86_64)
8.1 MB
Download

Installs the `pii-guard` systemd service bound to 127.0.0.1:3200. Auto-generates a secrets key on fresh installs.

sha256: 8cf2fdaaeee19ff3
RHEL / Fedora / Rocky / Alma (x86_64)
10.3 MB
Download

Install with `sudo dnf install ./pii-guard-server-0.1.0-1.x86_64.rpm`.

sha256: 62cb8582240b17b4
  1. 1Install the package
    # Debian / Ubuntu / Mint
    sudo dpkg -i pii-guard-server_0.1.0_amd64.deb
    
    # RHEL / Fedora / Rocky / Alma / Amazon Linux 2023
    sudo dnf install ./pii-guard-server-0.1.0-1.x86_64.rpm

    The postinstall script creates the pii-guard system user, provisions /etc/pii-guard/ and /var/lib/pii-guard/, generates a random PII_GUARD_SECRETS_KEY when the env file is empty, enables the pii-guard.service unit, and stages the browser UI to /usr/share/pii-guard/web (served by the service itself — no separate web server needed). On an existing secrets.db it refuses to mint a new key and prints a warning instead. Binaries are linked against glibc 2.34, so they run on Amazon Linux 2023, RHEL/Rocky/Alma 9+, Ubuntu 22.04+ and Debian 12+.

  2. 2Start the service and confirm it is listening
    sudo systemctl enable --now pii-guard
    sudo systemctl status pii-guard --no-pager
    curl -fsS http://127.0.0.1:3200/health   # -> {"status":"healthy",...}

    Default bind is 127.0.0.1:3200. The service writes only to /var/lib/pii-guard and /var/log/pii-guard; the systemd unit blocks home-directory access, kernel/cgroup mutation, privilege escalation and capabilities.

  3. 3Capture the API token

    On first boot the server prints a one-time API token to journald. You paste this on the Server access required screen the first time you open the browser UI.

    sudo journalctl -u pii-guard --no-pager | grep "API token"

    Prefer to set the token explicitly? Uncomment PII_GUARD_API_TOKEN in /etc/pii-guard/pii-guard.env and restart the service. Protected APIs require the x-pii-guard-token header (or the session cookie set after the token unlock).

  4. 4Expose it over a reverse proxy — and pick HTTP or HTTPS

    Read this or login will fail. The browser session cookie is flagged Secure, so browsers only send it back over HTTPS. Serve the UI over plain HTTP and the cookie is dropped — every request 401s, sign-in/register fail and the machine fingerprint shows “Unable to read machine ID”. Choose one of the two options below.

    Keep the service bound to 127.0.0.1:3200 and put nginx in front. A ready example installs at /usr/share/doc/pii-guard/nginx-pii-guard.conf.

    Option A — HTTPS (recommended for anything network-reachable)

    Leave PII_GUARD_COOKIE_SECURE at its default (true) and terminate TLS in nginx. With a domain, use certbot --nginx. With only a bare IP (e.g. a fresh EC2 box), generate a self-signed cert that carries the IP — the browser warns once, which is expected:

    # self-signed cert for a bare IP (no domain)
    sudo openssl req -x509 -nodes -newkey ec \
      -pkeyopt ec_paramgen_curve:prime256v1 -days 825 \
      -keyout /etc/pki/tls/private/pii-guard-selfsigned.key \
      -out    /etc/pki/tls/certs/pii-guard-selfsigned.crt \
      -subj "/CN=<PUBLIC_IP>/O=PII Guard" \
      -addext "subjectAltName=IP:<PUBLIC_IP>"
    
    # nginx: :80 -> 301 https, :443 ssl proxies to 127.0.0.1:3200
    # (see the bundled nginx-pii-guard.conf — keep HSTS off while self-signed)
    sudo nginx -t && sudo systemctl reload nginx

    Then open inbound TCP 443 in the host firewall and your cloud security group (AWS SG, GCP firewall…). TLS on the box is unreachable until the port is allowed at the network edge.

    Option B — plain HTTP (internal / trusted network only)

    If the host is reachable only from a locked-down VPC/VPN, you can skip TLS by disabling the Secure flag. The token then travels in cleartext, so restrict the security group to trusted IPs.

    # /etc/pii-guard/pii-guard.env
    PII_GUARD_COOKIE_SECURE=false
    
    sudo systemctl restart pii-guard
    # nginx serves the UI on :80 -> proxy_pass http://127.0.0.1:3200; (no redirect)
  5. 5Open the management UI and activate

    Browse to the host — https://your-host (Option A) or http://your-host (Option B). On the Server access required screen, paste the API token from step 3 to unlock the session, then Sign in or Register with your Netrik account (or Paste key for an offline licence). The machine fingerprint resolves and your licence binds to this server. All scans now execute on the Linux host using the databases, mounted paths and credentials available there.

    The same UI is also reachable from Netrik Desktop via Connect to a remote server using the host URL and the API token.

Login returns 401 / “Unable to read machine ID”

Almost always the Secure-cookie-over-HTTP problem from step 4: the UI is being served over plain HTTP, so the browser drops the session cookie and every /api/v1/invoke/* call — including sign-in, register and the machine fingerprint — returns 401. Fix it by either fronting the service with HTTPS (Option A) or setting PII_GUARD_COOKIE_SECURE=false (Option B), then restarting the service. Confirm the cookie round-trip from the host:

TOKEN=$(sudo journalctl -u pii-guard --no-pager | grep -oE 'API token[^:]*: [^ ]+' | tail -1 | awk '{print $NF}')
curl -fsS -X POST http://127.0.0.1:3200/api/v1/invoke/get_machine_id_cmd \
  -H "x-pii-guard-token: $TOKEN" -H 'Content-Type: application/json' -d '{}'
# -> {"success":true,"data":"<32-hex machine id>"}

A 200 here means the server is healthy and the issue is purely the browser cookie / TLS layer. Note: signing in still routes through the local server, which talks to netriksolutions.com on your behalf — that is by design, not a misconfiguration.

“This site can’t be reached” after enabling TLS? If you previously served over HTTP, the browser caches the permanent (301) redirect to HTTPS. Test in a fresh incognito window, or tick Disable cache in DevTools → Network and reload, or clear cached files for the host.

Verifying your download

Every release directory ships SHA256SUMS.txt. Confirm the file you downloaded matches before installing:

# Verify server package checksum
shasum -a 256 pii-guard-server_*.deb
shasum -a 256 pii-guard-server-*.rpm
# Compare against SHA256SUMS.txt in the release directory

Deployment & Licensing Notes

  • Security Group: Ensure port 443 is open in your cloud security groups to allow network access to the management UI.
  • Licensing: Sign in with the email you used at netriksolutions.com/register to bind a trial license. The activation gate binds your license key to the current machine.