Lock yourself out on purpose and recover out of band

applied · 45 min · Objective 3.5

Task

Cut your own remote access to a router with a firewall rule, then recover it through the hypervisor console — the lab equivalent of out-of-band management. The lesson is not the recovery; it is understanding exactly which class of mistake in-band management cannot survive.

Steps

  1. From Host A, confirm SSH to the router works. Leave that session open; you will watch it die.
  2. In that session, apply a rule that drops everything inbound: sudo iptables -P INPUT DROP. The session freezes immediately — you have cut the branch you were sitting on.
  3. Try to reconnect from Host A. It fails. Note what the failure looks like: a connection timeout rather than a refusal, because the packets are dropped silently rather than rejected.
  4. Recover through the hypervisor console window. Log in locally and restore the policy: sudo iptables -P INPUT ACCEPT. Confirm SSH works again.
  5. Now do it the way that would have been safe. Apply the same restrictive policy but add the permit rule first: sudo iptables -A INPUT -s 192.168.10.10 -p tcp --dport 22 -j ACCEPT, then set the policy to DROP. Confirm you are still connected.

Verify

sudo iptables -L INPUT -n -v --line-numbers
ssh -o ConnectTimeout=5 -o BatchMode=yes user@192.168.10.1 hostname; echo "ssh exit $?"
sudo iptables -L INPUT -n | head -3

After step 5 the INPUT chain must show the accept rule above a DROP policy, and the SSH command must still succeed with exit 0. After step 2 it must fail with a timeout. Both results are the lab: the same intended end state, reached in two orders, with opposite outcomes.

Notes

Rule order is the mechanism, and it is the same first-match-wins behaviour the ACL troubleshooting in domain 5 examines. The policy applies to anything no rule matched, so a permit rule placed after the fact is a permit rule that never runs.

The operational habit that prevents this without a console: apply risky changes with a timed revert. Schedule the rollback first — echo "iptables -P INPUT ACCEPT" | at now + 5 minutes — then make the change. If it works, cancel the revert; if it locks you out, it undoes itself while you go and make coffee.

This is also the clearest possible argument for out-of-band management. The recovery path must not depend on the thing being changed. A console server, an IP KVM, or a cellular-connected management port are all answers to the same question, and the hypervisor console you just used is the lab's version of one.