block network access for certain users/groups

block network access for certain users/groups

[Elmar Stellnberger]

I need to block network access for certain users/groups, fully:

iptables -A mychain -m owner --gid-owner blockedusergroup -j DROP

...drops ping packages in the output chain but lets my user happily  
connect to localhost:631 or any other http address. In deed the rule above  
is therefore pretty useless.

I need to block ALL incoming and outgoing packages for a certain  
user/group.
At the moment there is only insufficient blocking for outgoing packages  
available.

What will I have to do to implement network access restrictions on a per  
user/group basis?
Logging such packages is already possible. Why is blocking them not?
Can anyone help me?

Elmar Stellnberger

block network access for certain users/groups

[Elmar Stellnberger]

I need to block network access for certain users/groups, fully:

iptables -A mychain -m owner --gid-owner blockedusergroup -j DROP

...drops ping packages in the output chain but lets my user happily  
connect to localhost:631 or any other http address. In deed the rule above  
is therefore pretty useless.

I need to block ALL incoming and outgoing packages for a certain  
user/group.
At the moment there is only insufficient blocking for outgoing packages  
available.

What will I have to do to implement network access restrictions on a per  
user/group basis?
Logging such packages is already possible. Why is blocking them not?
Can anyone help me?

Elmar Stellnberger

Re: block network access for certain users/groups

[Lars Nooden]

On 7/29/10 10:09 PM, Elmar Stellnberger wrote:
> iptables -A mychain -m owner --gid-owner blockedusergroup -j DROP

For starters, consider using the REJECT target instead of DROP if for no 
other reason than that it will make your engineering easier:

	http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

	http://www.chrisbrenton.org/2009/07/why-firewall-reject-rules-are-better-than-firewall-drop-rules/


> What will I have to do to implement network access restrictions on a per
> user/group basis?

Follow your chains in sequence and make sure that the packets going to 
or from that group have only one way to go.  If the packets are getting 
through, then there is some chain or rule allowing them through before 
the packet gets to the --gid-owner rule you have above.

/Lars

Re: block network access for certain users/groups

[Richard Horton]

On 29 July 2010 20:09, Elmar Stellnberger <estellnb@gmail.com> wrote:
>
>
> I need to block network access for certain users/groups, fully:
>
> iptables -A mychain -m owner --gid-owner blockedusergroup -j DROP
>

Err... I know this is stating the obvious but your output chain does
jump to the mychain at some point doesn't it ;)

Also some apps remember do not run with the groupid of the person who
launched the application - gid-owner matches the *effective* group id
of the process.




--
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.pbase.com/arimus - My online photogallery
http://www.richardhorton.info

Re: block network access for certain users/groups

[Jan Engelhardt]

Ref: http://marc.info/?l=netfilter&m=128043201731932&w=2

On Thursday 2010-07-29 21:33, Lars Nooden wrote:
> On 7/29/10 10:09 PM, Elmar Stellnberger wrote:
>> iptables -A mychain -m owner --gid-owner blockedusergroup -j DROP
>
> For starters, consider using the REJECT target instead of DROP if for no other
> reason than that it will make your engineering easier:
>
> 	http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

That page - especially the summary - is leaving out one essential feature
Gáspar already mentioned it in another thread; the CHAOS target from
Xtables-addons.

It is hard to press its behavior into the three rows
"application connects to non-existent service" / "naïve network scanning" /
"specialist program", but the behavior can be summed up into:

1. Connect: With an x% (tunable) chance, failure is reported promptly to the
   user/scanner. (This is to elicit point 2.)
2. Scanning many ports will be slow/expensive. (nmap)
3. Syn scans produce nonsensical results. (nmap)

> 	http://www.chrisbrenton.org/2009/07/why-firewall-reject-rules-are-better-than-firewall-drop-rules/

Re: block network access for certain users/groups

[Lars Nooden]

On 07/30/2010 12:00 PM, Jan Engelhardt wrote:
> 
> Ref: http://marc.info/?l=netfilter&m=128043201731932&w=2
> 
> On Thursday 2010-07-29 21:33, Lars Nooden wrote:
>> On 7/29/10 10:09 PM, Elmar Stellnberger wrote:
>>> iptables -A mychain -m owner --gid-owner blockedusergroup -j DROP
>>
>> For starters, consider using the REJECT target instead of DROP if for no other
>> reason than that it will make your engineering easier:
>>
>> 	http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
> 
> That page - especially the summary - is leaving out one essential feature
> Gáspar already mentioned it in another thread; the CHAOS target from
> Xtables-addons.

CHAOS and TARPIT look about the same as DROP in regards to the question
of REJECT vs DROP.  The same arguments apply about a quick response from
the filter or not.

 http://www.chrisbrenton.org/2009/07/why-firewall-reject-rules-are-better-than-firewall-drop-rules/

 http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject


/Lars

Re: block network access for certain users/groups

[Elmar Stellnberger]

Promptly stated we have the following two problems:
* The --uid-owner and --gid-owner flags may only be specified in the
output chain (as the man page says).
  However to block all network traffic for a certain user we do also
need it in the input chain.
  Curiously we can log the user who is going to receive a package but
we can not select for this.
* The --gid-owner iptables-rule is apparently ineffective for
http-access (lynx localhost:631).
   It is the first rule and would be expected to reject any package
with the specified gid.

Jan Engelhardt & Lars Nooden:
Thxs for your advice.
Using Reject would for sure be the cleaner solution as Drop only lags
for normal app. users and does not help against professional
portscans.
Nonetheless our primary goal here should be to block all network
access for a certain user and only for this user.
The idea is to run programs which do not need network access under the
specified user id (as apache runs under wwwrun).

Richard Horton:
I have connected with lynx to cups (localhost:631).
Lynx does not have the suid-group id bit set so the group should not change.

Lars Nooden & Richard Horton:

As you can see my rule is the first to execute (It is on the right
place but obviously does not work right):
>iptables -L -v
Chain OUTPUT (policy ACCEPT 1 packets, 52 bytes)
 pkts bytes target     prot opt in     out     source
destination
 8683  506K user_spec  all  --  any    any     anywhere
anywhere
    0     0 ACCEPT     all  --  any    lo      anywhere
anywhere
 8682  506K ACCEPT     all  --  any    any     anywhere
anywhere            state NEW,RELATED,ESTABLISHED
    1    52 LOG        all  --  any    any     anywhere
anywhere            limit: avg 3/min burst 5 LOG level warning
tcp-options ip-options prefix `SFW2-OUT-ERROR '

Chain reject_func (0 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 REJECT     tcp  --  any    any     anywhere
anywhere            reject-with tcp-reset
    0     0 REJECT     udp  --  any    any     anywhere
anywhere            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  any    any     anywhere
anywhere            reject-with icmp-proto-unreachable

Chain user_spec (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 DROP       all  --  any    any     anywhere
anywhere            owner GID match app
...

Nonetheless the rule is there and being executed:
> ping localhost
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
PING localhost (127.0.0.1) 56(84) bytes of data.

--- localhost ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms



2010/7/30 Lars Nooden <lars.curator@gmail.com>:
> On 07/30/2010 12:00 PM, Jan Engelhardt wrote:
>>
>> Ref: http://marc.info/?l=netfilter&m=128043201731932&w=2
>>
>> On Thursday 2010-07-29 21:33, Lars Nooden wrote:
>>> On 7/29/10 10:09 PM, Elmar Stellnberger wrote:
>>>> iptables -A mychain -m owner --gid-owner blockedusergroup -j DROP
>>>
>>> For starters, consider using the REJECT target instead of DROP if for no other
>>> reason than that it will make your engineering easier:
>>>
>>>      http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
>>
>> That page - especially the summary - is leaving out one essential feature
>> Gáspar already mentioned it in another thread; the CHAOS target from
>> Xtables-addons.
>
> CHAOS and TARPIT look about the same as DROP in regards to the question
> of REJECT vs DROP.  The same arguments apply about a quick response from
> the filter or not.
>
>  http://www.chrisbrenton.org/2009/07/why-firewall-reject-rules-are-better-than-firewall-drop-rules/
>
>  http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
>
>
> /Lars
>

Re: block network access for certain users/groups

[Richard Horton]

[snipped original]
Might be worth turn trace on :
iptables -t raw -A OUTPUT -j TRACE

See which rules the packets hit; if you want to cut down the amount of
traces just add the relevant matches - I tend to trace everything
until I know what I'm the packet(s) look like what I expect and  then
start focusing in.
-- 
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.pbase.com/arimus - My online photogallery
http://www.richardhorton.info