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:
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).
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.
# 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
iptables -A INPUT -s YOUR.IP.ADDRESS.HERE -j ACCEPT
# Drop all other traffic
iptables -A INPUT -j DROP
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
iptables -A OUTPUT -d YOUR.IP.ADDRESS.HERE -j ACCEPT
# Drop all other unpermitted outbound traffic.
iptables -A OUTPUT -j DROP
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.