Re: IPAddressDeny/IPAddressAllow is too limited ot be useful

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

Am 27.12.18 um 12:38 schrieb Lennart Poettering:
> On So, 23.12.18 02:17, Reindl Harald (h.reindl@xxxxxxxxxxxxx) wrote:
> 
>> http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html
>>
>> "All traffic from and to this address will be prohibited for processes
>> of the service" is nice in theory but let's say we have a internal
>> webserver which needs to make curl calls to the internet
>>
>> IPAddressDeny=any
>> IPAddressAllow=localhost
>> IPAddressAllow=10.0.0.0/8
>> IPAddressAllow=192.168.0.0/16
>> IPAddressAllow=172.16.0.0/12
>>
>> can not be used
>>
>> IPAddressDenyIn=any
>> IPAddressAllowIn=localhost
>> IPAddressAllowIn=10.0.0.0/8
>> IPAddressAllowIn=192.168.0.0/16
>> IPAddressAllowIn=172.16.0.0/12
>>
>> would be broadly useable
> 
> I presume by this you mean you want to filter TCP-SYN differently from
> other TCP packets? i.e. that incoming connection setup requests shall
> be differently handled than packets in an already established
> connection?

yes

> There certainly is use in a concept like that, but I think this should
> be handled differently in the context of a local firewall like we
> implement: instead of filtering packets we should filter on the API
> level, i.e. in bind(), connect() and accept(). And the kernel now has
> BPF hooks into these system calls, so it's just a matter of
> implementing support for this in systemd (see discussion at the end of
> #7626).

sounds good

> I think packet filtering is great, but if possible only for
> context-less decisions. As soon as context matters (which the question
> of "is this an incoming or outgoing connection?" is after all) I think
> it's better to filter in code hooks, i.e. no attempt to reconstruct
> context at a stage where most context is already removed. Or in other
> words: connection tracking is messy, and we should avoid it if we have
> other ways to support the same usecases.

agreed

what i would have liked to use that feauture for is besides smb.service
where it works our admin-panel which shuld only be rechable over LAN/VPN
but sadly it needs to do dns, epp, whois and so needs to talk to the
outside world
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel