Blog

  • Hardening a fresh VPS: the first fifteen minutes

    A freshly provisioned VPS gets scanned within minutes of receiving an IP address. Most of what matters can be done before you install anything else at all.

    Keys, then no passwords

    Create a non-root user, copy your key across, and confirm the key works in a second terminal before you disable password authentication. Locking yourself out of a fresh box is an avoidable rite of passage.

    adduser deploy
    usermod -aG sudo deploy
    rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy
    # verify in a SECOND terminal, then:
    sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
    systemctl restart ssh

    Default deny

    Set the firewall to deny inbound by default and open only what you actually serve. Re-read the rule list a week later. The ports you opened just to test something are still open, and one of them is a database.

    Unattended upgrades

    Automatic security updates are the highest-value fifteen seconds you will spend on a new server. The failure mode people fear, an update breaking production, is far rarer than the one they ignore: a six-month-old unpatched CVE in a public-facing service.

    Backups before you need them

    A backup on the same disk is not a backup. It protects you from a bad deploy, not from a dead server. Get a copy off the machine, then restore it once to prove it works.

  • Reading nmap output properly

    An open port and a working service are not the same claim, and nmap is considerably more careful about that difference than most people reading its output.

    State is not capability

    A state of open means a SYN-ACK came back. That is all it means. It does not tell you the service is healthy, that it will accept your protocol, or that the banner is truthful. filtered is the genuinely interesting result: something dropped the probe silently, which tells you about the network path rather than the host.

    Version detection is a guess with a confidence score

    The service and version columns come from matching response fingerprints against a signature database. A reverse proxy, a load balancer, or a deliberately edited banner will all produce confident-looking output that is wrong. Treat the version column as a hypothesis to confirm, never as a fact to act on.

    $ nmap -sV --reason -oA scan 10.20.0.15
    
    PORT   STATE SERVICE VERSION      REASON
    22/tcp open  ssh     OpenSSH 8.9  syn-ack ttl 63
    80/tcp open  http    nginx 1.18   syn-ack ttl 63

    The --reason flag is the habit worth forming. It shows you why nmap made each call, which is exactly the information you need when a result later turns out to be wrong. And -oA costs nothing now while saving you from re-running a scan you have already done.

    Timing changes results

    Aggressive timing templates drop packets on congested links, and dropped probes get reported as filtered. If a result surprises you, re-run it slower before you build a theory on top of it.

  • Building a home lab you are not afraid to break

    A lab you are afraid to break is not a lab. The whole point is that you can leave a box in a ruined state at 2am and roll it back before breakfast. That single property, cheap rollback, matters far more than the hardware you run it on.

    Segment first, install second

    The most common mistake is building the lab flat and bridging it straight onto the home network. Put the lab behind its own firewall interface with no route back to your personal devices. If a target box ends up fully compromised during an exercise, the blast radius should stop at the VLAN boundary.

    # three VLANs is enough to start
    # 10  - management  (hypervisor, firewall admin)
    # 20  - targets     (deliberately vulnerable VMs, no egress)
    # 30  - attacker    (your working VM)

    Give the target VLAN no outbound internet at all. It removes an entire class of accidents, and it forces you to stage tooling deliberately rather than pulling it off the internet mid-exercise.

    Snapshot discipline

    Snapshot every target VM in its clean state before the first packet. Name it something you will still understand later. The temptation is to keep working on a box you have already modified, but findings from a dirty machine are not reproducible, and non-reproducible findings are just anecdotes.

    Write it down as you go

    Keep a terminal log and a scratch file open from the start. Reconstructing what you did three hours ago from shell history is miserable, and the details you lose are exactly the ones that made the difference.