The internal side of my ISP router has three devices:

ISP router
Firewall router

Behind the Firewall router is a NAT network using 192.168.100.n/24

This question is regarding iptables running on the Server. I wanted to allow access to port 8080 only from the NAT clients behind the Firewall router, so I used this rule

-A Firewall-1-INPUT -s -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT

This worked, but UNEXPECTEDLY ALLOWED GLOBAL ACCESS, which resulted in our JBOSS server getting compromised. I now know that the correct rule is to use the Firewall router's address instead of the internal network, but can anyone explain why the first rule allowed global access? I would have expected it to just fail.

Full config, mostly lifted from a RedHat server:

:Firewall-1-INPUT - [0:0]
-A INPUT -j Firewall-1-INPUT
-A FORWARD -j Firewall-1-INPUT
-A Firewall-1-INPUT -i lo -j ACCEPT
-A Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A Firewall-1-INPUT -m comment --comment "allow ssh from all"
-A Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A Firewall-1-INPUT -m comment --comment "allow https from all"
-A Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A Firewall-1-INPUT -m comment --comment "allow JBOSS from Firewall"
### -A Firewall-1-INPUT -s -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT
-A Firewall-1-INPUT -s -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPt
-A Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
  • 2
    If you found the answer, don't put in you question, publish it as an answer and select it. – Cristian Ciupitu Jun 3 '14 at 0:16
  • Good point, but confusing as I neither found the answer nor put it in my question. nandroP's answer below looks quite promising. – nortally Jul 17 '14 at 22:25

can anyone explain why the first rule allowed global access?

the first rule allowed global access because you were accepting NEW conections from although the isp router does not fit in this range, it appears your default policy was ACCEPT, so effectively, you were allowing NEW connections from the entire internet.

the second rule, the server only allows NEW conns from, because of the second line, which default REJECTs implicitly

-A Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited"

which means only this one IP can establish NEW connections.

another way to do this would be to implement an explicit default DROP, instead of implicitly as part of the rule chains


the difference between DROP and REJECT is significant, as DROP will silently drop all packets, but REJECT will tell the remote user "no". this can be exploited by a clever hacker to discover your devices. DROP is better.

  • The last line of the ruleset is -A Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited so the INPUT policy doesn't matter (although "should" be DROP for sake of properness) – fukawi2 Jun 3 '14 at 7:12

I think you have been jumping to conclusions. You rule permits connections from it says. If your firewall is configured to NAT connections to the server just like connections to the rest of the Internet, your first rule wound't match connections from the LAN.

Does that mean, that you unintentionally have been allowing connections from somebody else? Probably not, but we can't say definitive no to that question either. In order for somebody to connect to your server by using the firewall rule allowing traffic from they would have to be able to send packets to your server with source IPs in that range. They would also have to receive packets that you send back to, otherwise they would be operating completely blind and need to guess a 32 bit sequence number. In your setup packets to that range of IP addresses are likely to take the default route back to your ISP.

If somebody from a different ISP would try to connect to your server using source IPs in the range, there are at least three places on the route from them to your server at which that source range was supposed to be filtered. And there wouldn't be a route back to them. With all of those obstacles, I don't believe that is what happened.

Somebody using the same ISP as you would have a better chance. If the router from the ISP consider to be directly attached to it's external interface, then any other customer on that link could have connected to your server. But that would have been an extremely targeted attack.

All things considered, I'd say there are many much more likely attack vectors than a connection being allowed in due to that rule. One of the more likely attack vectors would be that somebody opened browser with security holes in it on the server and went to a webpage, that happened to be hosting malware.

If you want to know how the compromise happened, you'd first need to provide what evidence you have about the nature of the compromise. How did you find out that it had been compromised?

  • Thanks for the detailed replay. The other attack vectors you mention are certainly worth considering, but I'm pretty sure it was the firewall. I should have mentioned that I tested this--when I said that the config allowed global access, I mean that I was able to connect from a different network outside my router that did not use or spoof the network. – nortally Jul 17 '14 at 22:29

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.