Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The internal side of my ISP router has three devices:

ISP router 128.128.43.1
Firewall router 128.128.43.2
Server 128.128.43.3

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 192.168.100.0/24 -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:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
: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"
### THIS RESULTED IN GLOBAL ACCESS TO PORT 8080
### -A Firewall-1-INPUT -s 192.168.100.0/24 -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT
### THIS WORKED
-A Firewall-1-INPUT -s 128.128.43.2 -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPt
###
-A Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
share|improve this question
2  
If you found the answer, don't put in you question, publish it as an answer and select it. –  Cristian Ciupitu Jun 3 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 at 22:25
add comment

2 Answers 2

can anyone explain why the first rule allowed global access?

the first rule allowed global access because you were accepting NEW conections from 192.168.100.0/24. although the isp router 192.168.43.1 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 128.128.43.2/32, 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

-P INPUT DROP

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.

share|improve this answer
    
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 at 7:12
add comment

I think you have been jumping to conclusions. You rule permits connections from 192.168.100.0/24as 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 192.168.100.0/24 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 192.168.100.0/24, 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 192.168.100.0/24 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 192.168.100.0/24 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?

share|improve this answer
    
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 192.168.100.0/24 network. –  nortally Jul 17 at 22:29
add comment

Your Answer

 
discard

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.