SecureLunaSecureLuna

How SecureLuna Works

Effective date: 2026-09-29

Transparency is part of the product. This page explains exactly how SecureLuna connects to your servers, what data it reads, what it stores, and the things it will never do.

1. Connection Model

You choose one of two ways for each server.

Agent (recommended) — nothing is handed to SecureLuna.

  1. You register a server by name and run the one-line install command we show you. The installer prints everything it will install before doing it.
  2. It installs one check script (/opt/secureluna-agent/sl-agent), one token file readable only by root, and two timers: the daily check and a resource sample every 10 minutes.
  3. The command list is fixed inside the script (sl-agent show prints it). The agent is send-only: SecureLuna never sends it commands to run, and there is no background process.
  4. Results are sent over HTTPS (outbound 443 only), so servers behind a firewall or on a private network work too.
  5. Updates are applied right before the daily check, and only when the new version carries a valid SecureLuna signature. The signing key is not stored on SecureLuna's servers, so a compromise of our servers cannot push code to yours. Set SL_AUTO_UPDATE=0 to turn this off.

SSH — no install on your server.

  1. You register a server you operate (host, SSH user, port).
  2. SecureLuna generates an SSH key pair on our side (or you register a password). You receive the public key.
  3. You install the public key on your server (typically appending to ~/.ssh/authorized_keys).
  4. Each scheduled run, SecureLuna connects via SSH and runs read-only commands defined by the rule library.

Either way, output is evaluated per rule (met / not met / not checked) and stored in our database.

2. What We Read

SecureLuna reads only the configuration and state needed to evaluate a checklist item. Examples:

  • Sudoers file content (cat /etc/sudoers, cat /etc/sudoers.d/*).
  • Password policy (cat /etc/login.defs).
  • SSH server configuration (cat /etc/ssh/sshd_config).
  • Firewall settings (iptables -L, ufw status, etc.).
  • Audit / logging configuration (cat /etc/audit/auditd.conf).
  • System metrics for sparklines (CPU/RAM/disk/network usage — sampled briefly) and basic server info (OS, kernel, CPU count, memory, disk, internal IP).

3. What We Will Never Do

  • We never modify your system (no chmod, no file edits, no package installs).
  • We never access systems you have not explicitly registered with us.
  • We never execute exploit code, payloads, or tools intended to bypass security controls.
  • We never download files from your server to ours (only the small text output of read commands).
  • We never store your data outside our infrastructure unless you explicitly enable the Backup add-on (which writes to a cloud storage provider you connect).

4. Credential Storage

  • SSH private keys, passwords and agent tokens are encrypted at rest using AES-256-GCM with a random IV per value.
  • The encryption key lives in the server's environment configuration, separate from the database — a database dump alone cannot be decrypted.
  • Decryption happens only at connection time, in memory, in the worker process.
  • Agent tokens are looked up by their SHA-256 hash; each token works for one server only and can be reissued at any time.

5. Asset Load

SecureLuna is designed to put minimal load on your server. Concurrency, jitter, and short timeouts ensure that scheduled runs do not impact production workloads. Metrics are brief (sub-second) snapshots. The agent is not a daemon: it runs from a timer, at low CPU and I/O priority, and exits when done.

6. Permission Model (within SecureLuna)

  • Each customer is a tenant. Data is partitioned by tenant.
  • Users in a tenant share access to that tenant's assets.
  • Asset delegation lets you grant a specific external user access to a single asset with one of three permission levels: VIEW (read-only), SCAN (read + run checks), MANAGE (read + run + edit settings).
  • Asset deletion and re-delegation are restricted to the owner tenant.
  • SecureLuna operations team has super-admin access for support purposes; all such access is logged in the audit trail.

7. Revoking Access

Agent: run sudo sl-agent uninstall — it removes the timers, token, stored samples and script. You can also reissue the token in the dashboard, which stops the installed agent from reporting immediately.

SSH: remove our public key from ~/.ssh/authorized_keys. We will detect the connection failure on the next scheduled run and mark the asset as "connection failed" in your dashboard.

8. Reporting a Security Concern

If you discover a vulnerability in SecureLuna or have a security concern, please email wndudgns2001@gmail.com. We will acknowledge within 48 hours.

한국어 요약

  • 서버마다 두 방식 중 고릅니다. 에이전트(권장): 명령 한 줄로 설치하고, 서버가 매일 결과를 보내기만 합니다(보내기 전용 — SecureLuna 는 명령을 내려보내지 않음). SSH: 발급한 공개키를 서버에 등록하면 매일 SSH 로 접속해 읽기 전용 명령만 실행합니다.
  • 에이전트가 설치하는 것은 점검 스크립트 1개, root 전용 토큰 파일 1개, 타이머 2개(매일 점검 · 10분마다 리소스 기록)뿐입니다. 상주 프로세스가 없고, 명령 목록은 파일 안에 고정돼 있습니다(sl-agent show).
  • 에이전트 업데이트는 SecureLuna 서명이 확인된 버전만 매일 점검 직전에 적용합니다. 서명 키는 SecureLuna 서버에도 두지 않습니다. SL_AUTO_UPDATE=0 으로 끌 수 있습니다.
  • 읽는 정보: sudoers·패스워드정책·SSH 설정·방화벽·감사 설정·시스템 메트릭·서버 정보. 산업 표준 체크리스트 항목 평가에 필요한 것만.
  • 고객 시스템을 변경하지 않으며, 등록하지 않은 시스템에는 접근하지 않습니다. 익스플로잇·페이로드 실행 없음.
  • SSH 개인키·비밀번호·에이전트 토큰은 AES-256-GCM 으로 암호화 저장합니다. 암호화 키는 DB 와 분리된 서버 환경 설정에 있고, 워커 프로세스에서 메모리상으로만 복호화합니다.
  • 회수: 에이전트는 sudo sl-agent uninstall, SSH 는 authorized_keys 에서 SecureLuna 공개키 삭제로 즉시 차단됩니다.
  • 모든 운영팀(슈퍼관리자) 행위는 감사 로그에 기록됩니다.