Allow internal ips block external ips

Jz87 · 07-19-2010, 03:55 PM

Im running Centos 5.4 with a sftp server, and I´d like to allow all 172.16.0.x ip and 192.168.0.x ip and block everything else.

Does someone have a good way to do this with IPTables or any other opensource FW?

Thanks !

anomie · 07-19-2010, 03:58 PM

The networks you mentioned are RFC1918 private IP space. They are not routable across the 'net. In order for inbound traffic to reach you, some externally-facing device must be providing NAT/PAT.

So, don't provide NAT/PAT, and keep your border devices and hosts secure.

If you have more questions, please describe your network more thoroughly.

Jz87 · 07-19-2010, 04:03 PM

thanks for quick reply.
Exaclly, it´s a lab enviorment and I just wan´t to block everything else except those internal IPs.

Jz87 · 07-19-2010, 04:04 PM

And forgot to mension we do use NAT

anomie · 07-19-2010, 04:08 PM

You can open it up to your internal subnets, but remember that in doing so you'll also be allowing the internal IP for your NAT device (for the sake of argument, let's call it 192.168.0.1). You might consider allowing stateful traffic, but dropping inbound requests from 192.168.0.1.

Jz87 · 07-19-2010, 04:20 PM

that sounds like a good idea, how would you do that in a good way ?

anomie · 07-19-2010, 04:31 PM

Ideally, you have packet filtering at the switch level to handle this. (Or somewhere between you and the NAT device.)

Alternatively, your NAT device does the packet filtering.

Or, you have host-level firewalls in place for all your private network workstations. (That may get unwieldy.)

win32sux · 07-19-2010, 05:14 PM

Quote:

Originally Posted by Jz87

Im running Centos 5.4 with a sftp server, and I´d like to allow all 172.16.0.x ip and 192.168.0.x ip and block everything else.

Does someone have a good way to do this with IPTables or any other opensource FW?

That could be done like (example):

Code:

iptables -P INPUT DROP
iptables -A INPUT -m state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p TCP --dport 22 -s 172.16.0.0/24 -m state NEW -j ACCEPT
iptables -A INPUT -p TCP --dport 22 -s 192.168.0.0/24 -m state NEW -j ACCEPT

Change the destination port number to whichever you've got your daemon listening on. Also, keep in mind that if someone cracks a host on your LAN (and obtains root privileges) they can spoof any IP.

Quote:

Originally Posted by anomie

You can open it up to your internal subnets, but remember that in doing so you'll also be allowing the internal IP for your NAT device (for the sake of argument, let's call it 192.168.0.1). You might consider allowing stateful traffic, but dropping inbound requests from 192.168.0.1.

Could you elaborate as to the reason you'd be blocking the router's IP? Just curious.

anomie · 07-19-2010, 05:43 PM

I was envisioning something similar to:

Code:

            ----------
           ( internet )
            ----------
                |
                |
            ------------
           | NAT device |
            ------------
                |
                |
             ----------
            | bridged  |
            | firewall |
             ----------
                |
                |
            ------------
           | switch for |
           | internal   |
           | hosts      |
            ------------
                |
             ........

The NAT device should never be making unsolicited connections attempts to any of the internal hosts. (All inbound traffic should be part of a stateful session.)

win32sux · 07-19-2010, 06:24 PM

Quote:

Originally Posted by anomie

The NAT device should never be making unsolicited connections attempts to any of the internal hosts.

I agree. And in your diagram, this sort of thing can be effectively enforced, given the bridged firewall you placed there. If you remove the bridged firewall, however, things get a bit difficult, as a bad guy which manages to own the router will be able to use any IP or MAC he/she wishes. This may or may not be a concern in this case, but it's something I think the OP should keep in mind.

anomie · 07-19-2010, 09:42 PM

TBH, I'm probably over-complicating things for the purposes of this thread. A NAT + firewall host is "good enough" for many situations.