Skip to main content

Feed | Moskic

Feed | Moskic
Project, notes, links, and thoughts from my corner of the internet

  2. If you are looking to run a Tailscale service in your FNOS NAS, here is a docker-compose file might help you:

    services:
    tailscale:
    # Official Tailscale Docker image.
    image: tailscale/tailscale:latest

    # Docker container name. This is only used by Docker.
    container_name: tailscale

    # Hostname inside the container.
    # This may be used as a reference name, but TS_HOSTNAME below is more explicit for Tailscale.
    hostname: tailscale-docker

    # Use the host network stack.
    # This is recommended when using Tailscale as an exit node or when you want the host itself
    # to be reachable through Tailscale.
    network_mode: host

    # Required network capabilities for kernel-mode Tailscale networking.
    # NET_ADMIN allows Tailscale to configure routes, interfaces, and firewall rules.
    # NET_RAW allows low-level network packet handling.
    cap_add:
    - NET_ADMIN
    - NET_RAW

    environment:
    # Tailscale auth key.
    # Replace this with your own key.
    # Do NOT share your real auth key publicly.
    - TS_AUTHKEY=YOUR_TAILSCALE_AUTH_KEY_HERE

    # Directory where Tailscale stores its state.
    # This keeps the node identity persistent across container restarts.
    - TS_STATE_DIR=/var/lib/tailscale

    # Disable userspace networking and use kernel networking instead.
    # This requires /dev/net/tun and the network capabilities above.
    # Recommended for exit node usage.
    - TS_USERSPACE=false

    # Authenticate only once when the state directory already contains valid Tailscale state.
    # This prevents the container from re-authenticating on every restart.
    - TS_AUTH_ONCE=true

    # Advertise this NAS/server as a Tailscale exit node.
    # --netfilter-mode=on allows Tailscale to manage firewall/NAT rules automatically.
    # This is important for routing client internet traffic through this machine.
    - TS_EXTRA_ARGS=--advertise-exit-node --netfilter-mode=on

    # Display name shown in the Tailscale admin console and clients.
    # Change this to a name that helps you identify the device.
    - TS_HOSTNAME=my-nas-exit-node

    # Let Tailscale automatically select the correct Linux firewall backend.
    # Useful on systems using nftables instead of legacy iptables.
    - TS_DEBUG_FIREWALL_MODE=auto

    volumes:
    # Persist Tailscale state on the host.
    # Replace the left side with your own host directory.
    # Example: /vol1/1000/docker/tailscale:/var/lib/tailscale
    - /path/to/tailscale/state:/var/lib/tailscale

    devices:
    # Expose the host TUN device to the container.
    # Required for kernel-mode VPN networking.
    - /dev/net/tun:/dev/net/tun

    # Restart the container automatically unless it was manually stopped.
    # This makes Tailscale start again after NAS/server reboot.
    restart: unless-stopped

  3. In the civilian sector, AI’s siphoning effect has not only kicked Moore’s Law clear beyond the Three Realms, but has also created the myth of desktop PCs retaining over 100% of their value. Truly terrifying😂

  4. Because of the continuous background noise of Cardputer ADV, I really don't know what caused these problems. I have done a series of extreme modifications to my firmware and done the following four tests:

    1. I pushed the high-pass filter all the way up to 1000 Hz, but the noise was still there. This suggests it was not low-frequency rumble or DC offset.

    2. I disabled the app-level recording gain and soft compression by switching to Raw Capture. The noise was still there, so it was not caused by my own 2x PCM gain amplifying the noise.

    3. I lowered M5Unified's mic magnification from the default 16 down to 1. The recording became much quieter overall, so the setting was definitely taking effect, but the noise was still audible. That means the issue was not simply excessive mic software gain.

    4. I copied the recorded WAV files to a computer and played them there. The noise was still present, so it was not coming from the Cardputer's speaker or playback chain.


    Taken together, these tests basically rule out the high-pass filter settings, app-level gain, playback chain, and simple mic magnification as the main cause.

    In other words, this looks more like a hardware/input-chain noise issue than something caused by the recorder's software processing.

  5. Recently I’ve been learning ESP32 development and made a voice recorder firmware that runs on the Cardputer ADV. Maybe it’s the most powerful recorder firmware for the Cardputer ADV?

    https://github.com/Moskic/cardputer-adv-recorder
    GitHub
    GitHub - Moskic/cardputer-adv-recorder: A voice recorder and WAV player firmware for the M5Stack Cardputer ADV
    GitHub - Moskic/cardputer-adv-recorder: A voice recorder and WAV player firmware for the M5Stack Cardputer ADV
    A voice recorder and WAV player firmware for the M5Stack Cardputer ADV - Moskic/cardputer-adv-recorder

  7. I recently handled a security incident involving an old Nezha Dashboard instance.

    The root cause was a critical Nezha vulnerability: GHSA-5c25-7vpj-9mqh. My dashboard was running v2.0.7, which was affected.

    Attack flow:
    1. Attacker accessed:
    /dashboard../data/config.yaml

    2. Dashboard config was exposed

    3. JWT / agent secrets were leaked

    4. Attacker forged admin access

    5. Malicious cron jobs were created through Nezha

    6. All connected agents started scanning servers for secrets

    7. Results were sent to external webhook endpoints

    Suspicious commands looked like:

    grep -rn 'AKIA|sk-ant|sk-proj|AIzaSy|github_pat_' /root /home /opt /etc /app /var /data /tmp

    curl http://169.254.169.254/...


    Impact:
    • Nezha JWT and agent secrets should be considered leaked
    • All connected nodes should be treated as exposed
    • Any API keys, cloud credentials, SSH keys, TLS keys, or tokens on those servers should be rotated


    Recommendations:
    • Upgrade Nezha immediately, at least to v2.0.13+
    • Stop all old agents
    • Re-register every node with new secrets
    • Do not reuse old config.yaml, SQLite DB, agent secret, or UUIDs
    • Do not expose the dashboard directly to the public Internet
    • Rotate passwords, SSH keys, API tokens, and TLS certificates


    Lesson learned:

    A monitoring dashboard with remote command execution is not “just a dashboard”. Treat it like critical infrastructure.
    GitHub
    Pre-auth path traversal via /dashboard.. prefix confusion leaks jwt_secret_key
    Pre-auth path traversal via /dashboard.. prefix confusion leaks jwt_secret_key
    ### Summary
    `fallbackToFrontend` in the dashboard's `NoRoute` handler treats any URL whose **raw string** starts with `/dashboard` as an admin-frontend asset request. The check uses `strings.H...