0

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
  • BTW, it's probably better if you don't post about how you think your question is "stupid" or whatever. It doesn't really do much for most people besides making it feel awkward. Also it typically feels like you're being just a little too self-critical. – Bratchley Jan 19 '15 at 19:54
0

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.

  • Hi Bratchley, thanks for the quick response. I do understand your points and changed the script like you suggested. Regarding the first rule, I wanted to restrict the ACCESS to port 22, because I guess that there are still unwanted scripts on the compromised machine, which could attack foreign servers. When those scripts start to establish connections directly after I start the machine and before I could add those rules to the IPTables, I worry about the consequences. I hope by restricting connections to port 22, to prevent any outgoing connections except my backup connection. BR – Tobias B. Jan 19 '15 at 20:15
  • Alright, makes sense to me, just wanted to make sure you were fully aware of what each command did. In that case though, you probably want to change it to --sport since outbound traffic will be coming FROM sshd and not the other way around. – Bratchley Jan 20 '15 at 14:14

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.