[systemd-devel] IPAddressDeny/IPAddressAllow is too limited ot be useful

[Lennart Poettering]

On So, 23.12.18 02:17, Reindl Harald (h.reindl at thelounge.net) 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?

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).

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.

Lennart

--
Lennart Poettering, Red Hat