Those are my IPTABLES rules:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p udp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

iptables -A OUTPUT  -j REJECT
iptables -A INPUT -j REJECT
iptables -A FORWARD -j REJECT

Im using a remote ssh conetion to set them up, but after i set:

iptables -A OUTPUT  -j REJECT

My connection get lost. I have read all the documentation for Iptables and i can figure out anything, the global Rejects for INPUT work well because i can access to the web page but i get a timeout for ssh. Any idea?



The ports used on a TCP flow aren't symmetric: while the server (daemon) end listens on port 22, the client end will use a random high numbered (1024+) port. If you do your filtering on destination port, then these will be blocked. You'll want something like 'iptables -A OUTPUT -m state --state ESTABLISHED,RELATED' before the reject line to make replies to external requests work.

  • ESTABLISHED lets the connection bypass the rest of the rules once you accept the initial package. This makes use of the stateful nature of the firewall. RELATED, allows related connections like FTP DATA connections to be created without specific rules for them. There are helper modules that handle identifying these. – BillThor Jan 16 '11 at 7:15
  • Thanks for your answer, i didn't know that TCP connections are asymmetric, im developer but im new to networking, i will have to study more about this. reading Tanenbaum's Computer Networks from page 1 – Serge Jan 17 '11 at 3:52
  • I will get ride of the output restrictive rule because my original intention was to prevent the leak of information in the case the server gets infected with malicious code, but it makes no sense to restrict all the outgoing except one port since that port can be used to send information. – Serge Jan 17 '11 at 4:04

I think your overly restrictive output rules are causing the problem - your ssh connections get in but they can't go back out. The return connection does not go to port 22 on your client machine, it goes to a high numbered port.

For troubleshooting, disable your output rules entirely and see what that does. Typically with firewalls you worry more about connections coming in than going out.

So, try iptables -A OUTPUT -j ACCEPT as yout only output rule and see what happens.

  • "Typically with firewalls you worry more about connections coming in than going out." Exactly, it makes no sense to have restrictive output and an open port because it can be used for many proposes. Thanks – Serge Jan 17 '11 at 3:55

The line

iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

should read

iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

since the packet comes from port 22 on your server, and goes to a random ephemeral port on the client's machine, as Phil has already pointed out. You might want to consider adding -m state --state ESTABLISHED if you're feeling extra paranoid.

  • Thanks for your answer, i will keep it on mind but i will get ride of the output restriction, thinking about it it makes no sense since it is for a webserver and malicious code can use the port to pass information out. – Serge Jan 17 '11 at 3:55

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.