I am using Ubuntu Server (Amazon EC2) and connected with ssh using putty I was setting up iptables to block all incoming and outgoing connection except my ip address, I tried these commands from putty:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

Now, am unable to connect from anywhere. Please help me how to get back my connection.

  • 2
    From putty? Do you mean that you connected to an Ubuntu machine from Windows using ssh and then, once connected to the Linux box, you ran the commands that disable all connections? If so, you need to edit your question and explain that. We can't guess. Also tell us if you have physical access to the machine or if someone else can run a command there for you. – terdon Apr 28 '17 at 17:23
  • Yes, and I'm using amazon EC2 – Suraj Bharti Apr 28 '17 at 18:10
  • Well, then please edit your question and add all this information as requested. – terdon Apr 28 '17 at 18:13
  • Oh hey, someone locked themselves out on EC2. I've done that before, it's not easy to fix when you've done the lockout via iptables lol. My answer below might help a little. – Thomas Ward Apr 28 '17 at 19:19
  • If I destroy the instance, how would I get data back? – Suraj Bharti Apr 29 '17 at 5:31

From comments, we've established this is on an Amazon AWS EC2 instance, and that you've locked yourself out from SSH access remotely. By using Amazon EC2, you're going to have a bit of a headache here. There's no real serial/console mode for access, nor anyone who can just 'fix' it, and by disabling all connections as you did, you've locked yourself out completely.

You don't really have much of a solution here but to destroy the EC2 instance and start over.

And once you start over, you have two choices for how to firewall your system:

  1. Use the EC2 security group firewall instead. This is a little easier to configure, and it's already there without any additional configuration - it's part of the EC2 infrastructure where you have to permit ports to actually get to the EC2 instance. You also aren't going to lock yourself out as easily (though you can get locked out, it's trivial to fix it then because you just allow port 22 again in the rule set from the Amazon EC2 settings panel, provided you don't mess with iptables as well).

  2. Use a decent iptables ruleset and don't log out from PuTTY on your EC2 until you are absolutely sure the rules you've put in place don't completely torpedo your access to the system.

Now, I mention in #2 a "decent ruleset". Below here is my guide to EC2 iptables, provided that you actually read the comments before you execute commands (for example, don't mess with OUTPUT or FORWARD unless you really need to).

A Working Rule Set for iptables per your requirements:

You don't need to type lines that have a # at the beginning, those're just my comments explaining what each command does. Also, replace YOUR.IP.ADDRESS.HERE with your actual IP address, where it shows up below.

Inbound filtering:

# Permit localhost to communicate with itself.
iptables -A INPUT -i lo -j ACCEPT
# Permit already established connection traffic and related traffic
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Permit new SSH connections into the system from trusted IP address
iptables -A INPUT -p tcp --dport 22 -s YOUR.IP.ADDRESS.HERE -m conntrack --ctstate NEW -j ACCEPT
# Permit all other traffic from trusted IP Address
# Drop all other traffic
iptables -A INPUT -j DROP

Outbound filtering:

Warning: This will block access to the update servers, time sync servers, etc. so ONLY filter on Outbound if you absolutely need to, otherwise don't do this section at all

# Allow Localhost to itself
iptables -A OUTPUT -i lo -j ACCEPT
# Allow RELATED,ESTABLISHED state traffic (related to Inbound for example)
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Allow all other traffic to trusted IP address
# Drop all other unpermitted outbound traffic.
iptables -A OUTPUT -j DROP

Forward filtering:

NOTE: Unless you really need to restrict things like forwarding traffic to the Internet via a tunnel or VPN to your server as a 'proxy' to the 'net, you really don't need to mess with the FORWARD rulesets, so I would suggest not doing this because nothing else is really going to use this function or ever land in this rule set table

# Drop FORWARD target traffic, we don't need it
iptables -A FORWARD -j DROP

Note that I am a firm believer in not messing with the default policies on a server, because it has some... evils... if not done correctly, and I usually only filter ingress traffic and FORWARD traffic, and permit Outgoing traffic because of time sync servers, Ubuntu update servers not always having a set number of IPs, other related processes I need (SSH in/out for instance as part of 'related' traffic), etc.

I'm also a firm believer in using REJECT instead of DROP, but that's only to make it easier to know that your server is up and refusing connections. To that end, I would be replacing the -j DROP with -j REJECT --reject-with icmp-host-unreachable or similar.

Note that if you have your system IPv6 enabled, this needs to be done for IPv6 as well, but with ip6tables, and replacing ICMP related message indicators with ICMP6 equivalents.

| improve this answer | |
  • Is there any way to at least have backup all data. Data is very important for me. – Suraj Bharti Apr 29 '17 at 8:50
  • That's an Amazon Support question (and if you are on the free tier you don't really get much support). I don't know the data structure at EC2. But since you can't get into your EC2 to recover data, and you don't have any type of serial or console access, I don't think you will easily (if at all) be able to get data off the non-accessible system. – Thomas Ward Apr 29 '17 at 8:52

Wait - you do not have to Destroy your EC2 -- solution is mentioned in AWS cloud docs :

Troubleshoot / fix inaccessible EC2/cloud instances:

Basically the funda here is - using the managmentconsole/cloud interface, ( you've messed up the iptabes/ssh-keys etc. so bad that you just can't login to it).

  • detach the / ( bootable) volume from the bad( inaccessible) EC2
  • create a new EC2 (dont change defaults here) , attach the / volume of the older ( inaccessible) EC2 on this machine
  • mount it in the new machine - edit/fix the changes
  • detach from the new instance, re-attach to older EC2 ( which we shut down to fix the / volume)
  • restart the older EC2 machine/vm.

See the full details on AMAZON CLOUD DOCS AT https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html -scroll down to reach the part starting with "to verify the permissions on your instance"

| improve this answer | |

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.