Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

On Centos 6.4, I want to block all incoming ports except 22, 80 and 443. 80 (external) should be redirected 8080 (internal). 443 (external) should be redirected to 8181 (internal). I used the following commands:

service iptables stop
iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8181
service iptables save
service iptables restart

However, I can still access ports 8080 and 8181. Is there a way to block ports 8080 and 8181 externally and still have open internally for redirection from 80 and 443?

share|improve this question
I posted a solution below. I do not have a virtual machine to test with at the moment, so here are some tips: you may need to change your 80 and 443 rules to 8080 and 8181 depending when iptables performs its checks. Also be aware that there are two mistakes above: tco should be tcp and -AINPUT should be -A INPUT. – gparent Jun 4 '13 at 19:57

3 Answers 3

up vote 5 down vote accepted

There's nothing in your rules dropping any packets. You can accomplish this by setting the default policy of your INPUT chain to DROP. By default it is ACCEPT:

iptables -P INPUT DROP

As you do this, you may begin to notice that your outgoing connections do not work anymore.

You can add rules at the top of your INPUT chain to ACCEPT already established traffic back in.

Do so using the following:

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

The RELATED part lets other related traffic through (for instance, ICMP packets sent as a result of something happening in an ESTABLISHED connection)

share|improve this answer
Thanks. When I used the DROP option, although iptables wasn't running, I suddenly lost ssh access. I have seen some interesting suggestions here though:…. Nevertheless, I'll see if I can get your solution working without losing access as it seems cleaner. However it would be nice to see it in its full context. – Steve Taylor Jun 5 '13 at 6:44
thanks for the answer. This solved my problem too. – sandun dhammika Jun 5 '13 at 7:08
Now that I look at it, this does actually answer the original question, although it has now sadly raised another. Here's a bit of light reading:… – Steve Taylor Jun 5 '13 at 13:53
What other issue did it raise? – gparent Jun 5 '13 at 14:22

I would better create a new chain and then add my rules into this chain. You can do that by: First DROP incoming/forwarding/outgoing traffic

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Then create a chain with judgment ACCEPT and add rules inside:

iptables -N myrules # Create a new chain
iptables -A myrules -m state --state ESTABLISHED,RELATED
iptables -A myrules -j LOG --log-prefix="Myrules: " # Just a log prefix
iptables -A myrules -j ACCEPT # Packets matching this rule will be ACCEPTed
iptables -A INPUT -i eth0 -p tcp --dport 22 -j myrules

Then, add the redirect rules:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8181
share|improve this answer
Then what? You're not even jumping to the chain. – Steve Taylor Jun 5 '13 at 12:57

Do you have multiple NICs on the server or not? You can lock it down that way. You can also easily lock it down by source IPs so you can only allow "INPUT" rules to those ports from specific IPs and only all "FORWARD" or "PREROUTING" rules from others.

share|improve this answer
This does not answer the question unless my reading comprehension is off. – gparent Jun 4 '13 at 19:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.