Using IPTables to block all connections but still be able to backup vServer

Question

my vServer / webserver (OS: Debian squeeze) got hacked and compromised. Therefore, I want to use rules in IPTable to block all input and output connections except ssh. Afterwards I want to back up at least some databases and files, which should be saved. I found some tutorials and scripts describing the workflow, but I still have questions:

1.) Sine I have no physical access to the server, I'm quite careful to use this, because I don't want to lock out myself. When I use the following script with "iptables-restore < /etc/myscript", I should be still able to connect with SSH from my local machine, right? If not, is it correct that a restart of the machine should reactivate the old standard rules?

2.) I'm a little confused by rules defining sport & dport (source & destination port). As written in the script, would it be possible from a third webserver to connect to the compromised machine? Because I want to back up the files to another vServer and could obviously not transfer the files via HTTP.

3.) Probably the most stupid question, but I still want to ask: Processing the commands of the script line by line, there would be a complete blocking of all connections after the second part - the rule to allow ssh connections is defined in the third part. Since I'm connected via SSH, shouldn't my connection be disrupted after using the rules (and before accepting ssh)?

# flushing old rules
IPTABLES -F
IPTABLES -X 
IPTABLES -t nat -F
IPTABLES -t nat -X

# creating general policy
IPTABLES -P INPUT DROP
IPTABLES -P OUTPUT DROP
IPTABLES -P FORWARD DROP

# allowing SSH
IPTABLES -A OUTPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED  -j ACCEPT
IPTABLES -A INPUT -p tcp --sport 22 -j ACCEPT

Answer 1

I should be still able to connect with SSH from my local machine, right?

No. The relevant rules are:

IPTABLES -A OUTPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED  -j ACCEPT
IPTABLES -A INPUT -p tcp --sport 22 -j ACCEPT

You'll probably want to convert the command name to lower case but the rules themselves need more work. First off, you probably don't want to restrict the first ACCEPT to destination port 22. The ESTABLISH,RELATED rule is probably better to leave wide open that way you're giving the greenlight to any traffic you've already let through, which is what most people want to have happen. Essentially this rule says "If it's related to an open connection (including connections the local machine opens) let it through." No need to get more specific than that since we're DROP'ing everything but SSH and if we start a connection from this machine we probably want it to go through.

The second rule needs to use --dport and not --sport since we're trying to matching ssh connections coming from somewhere else and INTO our server (hence why you put it on the INPUT chain).

As written in the script, would it be possible from a third webserver to connect to the compromised machine?

If you make the corrections above, the files can be transferred either by initiating the connection on the compromised server or having the third web server connect over SSH (which is what you would have greenlit).

Since I'm connected via SSH, shouldn't my connection be disrupted after using the rules (and before accepting ssh)?

As long as you leave the RELATED,ESTABLISHED wide open then you should be alright, since the ssh session is already related to an established connection. But yes if you modify the firewall in a way that isn't compatible with a current connection, that connection will drop.