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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












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









share|improve this question























  • 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















up vote
0
down vote

favorite












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









share|improve this question























  • 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













up vote
0
down vote

favorite









up vote
0
down vote

favorite











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









share|improve this 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






debian iptables






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 6 at 12:01









Jeff Schaller

37.9k1053123




37.9k1053123










asked Jan 19 '15 at 19:43









Tobias B.

31




31











  • 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

















  • 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
















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





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











1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted











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.






share|improve this answer






















  • 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








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f179932%2fusing-iptables-to-block-all-connections-but-still-be-able-to-backup-vserver%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote



accepted











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.






share|improve this answer






















  • 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














up vote
0
down vote



accepted











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.






share|improve this answer






















  • 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












up vote
0
down vote



accepted







up vote
0
down vote



accepted







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 6 at 12:01









Jeff Schaller

37.9k1053123




37.9k1053123










answered Jan 19 '15 at 19:52









Bratchley

11.8k74388




11.8k74388











  • 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
















  • 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















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




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




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

















draft saved

draft discarded
















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f179932%2fusing-iptables-to-block-all-connections-but-still-be-able-to-backup-vserver%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?