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.

This is an independent study companion for CompTIA Network+ and is not produced by or endorsed by CompTIA.