You are SSH'd into a remote Linux server that has no console access, and you are about to run `iptables -P INPUT DROP`. What is the risk, and how do you make that change without locking yourself out?

## Why the policy is the dangerous knob Every built-in chain has a default policy, set with `-P` and visible in the header line of an `iptables -L -v` listing, for example `Chain INPUT (policy DROP 12 packets, 900 bytes)`. The policy is not a rule; it is the verdict applied to a packet that has traversed the entire chain without matching any terminating rule. That makes `-P INPUT DROP` categorically different from adding a rule. A rule affects the traffic it matches. A policy affects *everything you have not thought about* — including, on a chain that does not yet accept SSH, the packets of the session you are typing into. There is no confirmation, no grace period, and the change is effective for the very next packet. If the box has no serial console, no cloud console and no out-of-band management, you have just made it unreachable and someone has to file a ticket with a data centre. ## The two rules that must exist first Before the policy, the chain needs to accept the traffic you depend on: 1. **Traffic belonging to connections that are already up.** Without it, even a correctly placed SSH accept rule can leave existing sessions hanging, and every other outbound-initiated exchange the host relies on breaks at the same time. The conventional form is `-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT`. 2. **New SSH connections**, so you can get back in: `-p tcp --dport 22 -j ACCEPT`, adjusted if `sshd` listens elsewhere. Both go at the *top* of the chain — insert with `-I`, not `-A` — because a rule below an existing catch-all never runs. And restrict the SSH accept by source address only when you are certain of the path you arrive by; a source restriction written from memory, against a NAT or VPN egress address that has since changed, is itself a common way to lock yourself out. ## Flush is not a rollback The single most common self-inflicted lockout is not `-P` at all — it is `iptables -F` on a host whose policy is already DROP. `-F` removes rules. It does **not** reset chain policies. So the command people reach for to "clear the firewall and start again" strips away every accept rule and leaves the DROP policy standing, which is a maximally closed firewall applied instantly. If you ever need to open a host up from the command line, set the policies first and flush second: ```bash iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -F ``` ## The dead-man switch The technique that makes remote firewall work genuinely safe is an unattended rollback armed before the change and cancelled after it. Dump the known-good state, schedule a restore a few minutes out, make the change, verify, then cancel the rollback: ```bash iptables-save > /root/fw-good.v4 echo 'iptables-restore < /root/fw-good.v4' | at now + 5 minutes # note the job id # ... make the change, then verify from a second session ... atrm <jobid> # cancel once satisfied ``` This works precisely because `iptables-save` records chain policies as `:INPUT ACCEPT [0:0]` lines alongside the rules. Restoring the dump therefore restores the pre-change policy as well as the pre-change rules — it is a complete rollback, not a partial one. (`at` requires `atd` to be running; a detached `sleep` followed by the same restore does the same job where it is not.) ## Apply the whole ruleset at once A sequence of individual `iptables` commands passes through every intermediate state, and one of those intermediate states may be closed. Building the intended ruleset as a file and applying it with `iptables-restore` avoids that: the table is committed atomically, so there is no window where the policy has changed but the accept rules have not. ## Verify with a second session, not with optimism Your current SSH session is the worst possible test, because it is already established and may keep working under rules that block every new connection. The only meaningful check is opening a *new* connection from a second terminal while the first stays open as your lifeline. Watch the counters on the SSH accept rule with `iptables -L INPUT -n -v --line-numbers` and confirm they increment when that second session connects. ## Two smaller details worth knowing `iptables -w` makes the command wait for the xtables lock rather than failing with "Another app is currently holding the xtables lock" — worth having in any script that might race with other firewall writers, because a half-applied ruleset caused by a failed command is exactly the state you are trying to avoid. And if the host has a serial or cloud provider console, confirm it works *before* you need it. A console you have never logged into is not a safety net; it is an assumption.