2

In the Securing Debian Howto I read (about iptables):

The tools can easily be misused, causing enormous amounts of grief by completely crippling network access to a system. It is not terribly uncommon for a remote system administrator to accidentally lock himself out of a system hundreds or thousands of miles away. One can even manage to lock himself out of a computer who's keyboard is under his fingers.

I'm wondering... how?

  • Not possible; iptables has nothing to do with the console keyboard. – psusi Dec 31 '14 at 16:27
  • Maybe it is an ethernet keyboard ;) – goldilocks Dec 31 '14 at 16:28
  • @psusi indeed I'm a bit astonished about that sentence. Still, the source is influential. – Giacomo Tesio Dec 31 '14 at 16:44
  • 2
    I can think of one thing: it's possible to have your local X server listening on TCP instead of Unix sockets, and your clients connect like that. An iptables -I INPUT -j DROP would break your X session very badly, but switching to text mode should still work. This is also a weird config, so it doesn't strike me as an answer to the question. – derobert Dec 31 '14 at 16:46
4

Under the following conditions you could lock yourself out at the keyboard.

If you block all outbound network traffic with IPTABLES. AND If you use some sort of network authentication like LDAP or NIS for user logins. As a result the system can not access the external service so you won't be able to login with those user ID's. AND you have no other local user accounts with passwords AND You've disabled direct root login from the console.

You are still not completely locked out because you could reboot the system into Single user mode and fix your mistake.

1

in simplest form, if login and authentication is dependant on network connectivity while console login is disabled (that can be done too, for physical security purposes).

0

While securing a computer it is possible to lock oneself out so that the only recovery is to reboot into console mode. In some cases you will need a bootable CD. In the worst case with a locked down BIOS, you may not be able to easily do that either.

Getting locked out of root from all consoles is trivial and takes two steps in either order:

  • Remove or lock the root password (a recommended configuration).
  • Edit /etc/sudoers to an invalid configuration.

I always keep one or more root consoles open when making changes, and test with new connections before closing them.

Remote access is easier to break, and merely requires preventing access over protocols which permit logins. (Shorewall has/had an "absent minded admin" option to help prevent this.) Again, it helps to keep an active root console open while making changes. Tools with a test mode help as well, as you should regain access when the test times out and the configuration reverts.

If your password protocols work over the network (NIS, LDAP, etc), you can lock out all access by blocking their protocol(s) with iptables. If you have a cache working, you may not notice this immediately. Carefully test that the services are still working before logging out of your root console. Having a local account and/or password can help prevent this.

Password lockout policies can also cause problems. I have heard one developer describe how he locked himself out while implementing a password policy. His first policy was 1 failure and a 24 hour lockout. He was able to have someone else who was logged in to re-enable his account.

0

It sounds like I'm the only person whos done this before...

If you have a system and the only means of accessing it is via SSH you can easily mess your ruleset up and block SSH access into the box, effectively locking your self out of the computer.

For example:

# Because it's secure
iptables -P INPUT DROP 
iptables -P OUTPUT DROP
# Because you want to create a new ruleset and you've been up for 25 hours and aren't thinking straight
iptables -F

That'll drop all traffic in and out then flush the currently loaded rules, including the rules allowing SSH traffic into and out of the box. Boom! You're locked out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.