And by “heartbreak” I, of course, “being unable to talk to your server.”
The best advice I can give is, make sure you have easy access to the server console, whether by walking downstairs, across the building, or via some sort of networked console device. If you don’t have this, you don’t need my advice, because you’re an iptables veteran.
If you’re *not* a veteran, then learn from me. Or don’t, I care not.
Lots, and I mean *lots* of iptables “how tos” dive into the commands, and a large quantity start with something like this:
Which is all well and good. Unless you’re typing the commands by hand into an SSH session. What happens then, you ask? Well, I’ll tell you.
As soon as you even think about lightly caressing the enter key after typing in “iptables -P INPUT DROP”, the game is over.
You see, in iptables land, that means “LALALALALA NOT LISTENING LALALALA.” And there’s no “let me enter a bunch of commands, then implement them” feature. Oh no, everything takes affect at *lightning* speed.
So, use a console. Or at least have access. Or put all your commands into a script, which will keep running while your SSH access is axed, then you can log back in.
What’s that? You’ve already *done* that, and don’t have console access? Well, best email support at your hosting provider.
What? You have your own servers in a data center far far away? That’s silly then. Hope your emergency callout rate isn’t too high, or that it’s in business hours wherever they are.
Well, there’s *one* thing that would save you. Just *one*, and it’s unlikely it’ll help *you*, Mr. (or Ms.) interwebs. If you have some sort of remote power management, or *any* way to power off your server *without* the normal shutdown scripts running, you’re ok.
See, iptables doesn’t save it’s rules after every change. Only when you ask it to, or on shutdown via most distribution’s init scripts (or whatever they use). So if you can hard power cycle it, you’ll be ok, since the changes will get “undone.”
Hopefully you’ve found this article before, rather than after.