[systemd-devel] Adding "After=network-online.target" via drop-in

[Mantas Mikulėnas]

On Sun, Feb 19, 2017 at 6:56 PM, Andrei Borzenkov <arvidjaar at gmail.com>
wrote:

> 19.02.2017 15:34, Mantas Mikulėnas пишет:
> > On Sat, Feb 18, 2017 at 10:32 PM, Ian Pilcher <arequipeno at gmail.com>
> wrote:
> >
> >> I have configured sshd on my firewall to listen only on its internal
> >> IP address.  This is causing it to fail when it first starts, since the
> >> IP address is not actually configured yet.
> >>
> >> I have confirmed that adding network-online.target to the After=... line
> >> in sshd.service file works, but I know that using a drop-in is the
> >> preferred way of doing this.
> >>
> >> I haven't been able to find clear documentation of whether files in the
> >> drop-in directory are "incremental" or not.
> >>
> >
> > All multi-valued parameters are incremental.
> >
> > Alternatively, you could use sshd.socket (socket-activation) with
> > FreeBind=yes -- that way Linux would allow the socket to be bound even if
> > the address isn't configured yet.
> >
> > That said... listening only on internal addresses doesn't mean the
> > connections will be accepted only from internal interfaces -- at least
> for
> > IPv4, Linux considers the addresses as belonging to the whole host, and
> > will still accept connections from any interface. (I tested this just a
> > while ago.) So changing the listen-addr is not a good security measure,
> you
> > *still* need the corresponding firewall rules (filtering by source IP).
> >
>
> What is the value of rp_filter sysctl on your interfaces
> (/proc/sys/net/ipv4/conf/*/rp_filter)?
>

.all.rp_filter = 2 (loose filter), so max(all, <interface>) = 2 as well.

But rp_filter only verifies the source address, which is going to be
perfectly fine (it has to be, otherwise you wouldn't get the SYN/ACK back).
It's the *destination* address that would be for the "wrong" interface, so
you might be thinking of .arp_filter or .arp_ignore instead. (Though those
wouldn't help any, since the user can just do `ip route add
<router-mgmt-ip>/32 via <router-user-facing-ip>`.)

It's really nothing new, and yes, this only works if the client is
*already* in one of the device's subnets... but imagine an edge
router/firewall with user VLAN and mgmt VLAN and it's not that unlikely
anymore.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170219/aa17da6d/attachment-0001.html>