Blocking outgoing connects with iptables

Question

I have a (non production) machine where external supporters have shell-access (non-root). I want to prevent them from going further on into our network from that machine using iptables.

The "normal" firewall-gui only blocks incoming traffic. How can I set up rules like "accept all incoming traffic (plus response), but allow only new outgoing traffic for specific targets (like snmp-traps to the monitoring server)"?

OS is CentOS 5

Solution 1

There are two ways to drop all outgoing traffic except what you explicitly define as ACCEPT. The first is to set the default policy for the OUTPUT chain to drop.

iptables -P OUTPUT DROP

The downside to this method is that when the chain is flushed (all rules removed), all outbound traffic will be dropped. The other way is to put a "blanket" DROP rule at the end of the chain.

iptables -A OUTPUT -j DROP

Without knowing exactly what you need, I can not offer advice on what to accept. I personally use the method of putting a default DROP rule at the end of the chain. You may need to investigate how your GUI is setting rules, otherwise it may conflict with traditional CLI ways of restoring rules on boot (such as /etc/sysconfig/iptables).

Solution 2

Presuming you only want to accept incoming TCP traffic, you can use these rules to restrict outgoing traffic to established TCP connections (which would have to have been initiated from the outside) and IP addresses outside your LAN:

iptables -A INPUT -p tcp -i lo -j ACCEPT
iptables -A INPUT -p tcp -p 22 -j ACCEPT   # repeat for other ports you want to allow
iptables -P INPUT -j DENY
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -p tcp \! -d 10.0.0.0/8 -j ACCEPT  # replace by your LAN's network(s)
iptables -A OUTPUT -p tcp \! --syn -j ACCEPT
iptables -P OUTPUT -j DENY

Given your requirements, you may prefer to apply some rules specifically to processes executed by the supporters. Supposing they are in the supporters group, the following rules will deny supporters (and only supporters) all connections (incoming or outgoing) inside your LAN:

iptables -I INPUT \! -i lo -s 10.0.0.0/8 -m owner --gid-owner supporters -j DENY
iptables -I OUTPUT \! -o lo -d 10.0.0.0/8 -m owner --gid-owner supporters -j DENY

Note that gid-owner tests the process's fsgid, which is almost always the effective GID. Unless a process is run setgid or switches its effective GID to a supplementary group, the user's primary group (recorded in the user database, e.g. /etc/passwd) applies.

Solution 3

Consider installing Shorewall as your firewall builder. Use the single interface example as a starting point and doesn't provide any unnecessary outgoing access rules. Required ICMP types are allowed.

You will likely want to provide at least outgoing DNS (name lookup) and NTP (time synchronization) access rules.

Comments

[Nils]

DNS - propably not. That server has everything he needs "on board". NTP - sure. The SNMP-Traps were just an example. Shorewall looks interesting. I will try it. Is it comparable to Bastille (Debian version)?

[Nils]

The gid-owner looks interesting. Do I have to define INPUT rules at all? All listening services (basically SSH and HTTP) are already well secured by their own means. I don`t care about ICMP in ths setup. Do I have to put up "INPUT" rules at all in this case?

[Nils]

Can you please explain the sense of OUTPUT -p tcp \! -d 10/8 -j ACCEPT? This will accept all outgoing tcp traffic that is not going to the LAN?

[Gilles 'SO- stop being evil']

@Nils You don't strictly need the INPUT rules, but I find it cleaner to block both directions (and they may catch stray UDP packets). Yes, -p tcp \! -d 10/8 -j ACCEPT accepts outgoing TCP traffic going outside the LAN; include it or not depending on what policy you want to implement.

[BillThor]

It has been a long time since I ran Bastille, and it covers different things than Shorewall. Shorewall is strictly about building firewalls. It has several configuration files with clear functions. Many are optional if you need the features. The available documentation makes it easy to get things right and understand what you have done.

[Nils]

From what I`ve seen on the Shorewall page it is more like SuSEFirewall - where you define a config-file which will build some rules based on that config.

[BillThor]

With Shorewall there are several files. Once you have defined your interfaces and policies most of the changes should be to the rules file. There are several optional configuration files for traffic shaping, specialized routing, and other features you likely don't need.

[Nils]

Shorewall is a very good tool, but it has shown to be oversized for this purpose.

[Nils]

CentOS uses the FORWARD-chain to allow outgoing traffic for incoming established connections.

[Nils]

I used the -A OUTPUT -j DROP as the last OUTPUT-rule. The first accepts traffic for lo (as outlined by gilles), then I allow a couple of services I need to contact (e.g. to poll via http from the patchserver).

[Gilles 'SO- stop being evil']

@soubunmei Processes can only choose between the set of groups they were granted initially (unless they're running as root). Unless some process deliberately chooses differently, the user's primary group applies.

[把友情留在无盐]

still it is more common to grant access to groups , instead of deny access to groups . whitelist is easier to implement than blacklist .