<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 19, 2017 at 6:56 PM, Andrei Borzenkov <span dir="ltr"><<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">19.02.2017 15:34, Mantas Mikulėnas пишет:<br>
<span class="">> On Sat, Feb 18, 2017 at 10:32 PM, Ian Pilcher <<a href="mailto:arequipeno@gmail.com">arequipeno@gmail.com</a>> wrote:<br>
><br>
>> I have configured sshd on my firewall to listen only on its internal<br>
>> IP address.  This is causing it to fail when it first starts, since the<br>
>> IP address is not actually configured yet.<br>
>><br>
>> I have confirmed that adding network-online.target to the After=... line<br>
>> in sshd.service file works, but I know that using a drop-in is the<br>
>> preferred way of doing this.<br>
>><br>
>> I haven't been able to find clear documentation of whether files in the<br>
>> drop-in directory are "incremental" or not.<br>
>><br>
><br>
> All multi-valued parameters are incremental.<br>
><br>
> Alternatively, you could use sshd.socket (socket-activation) with<br>
> FreeBind=yes -- that way Linux would allow the socket to be bound even if<br>
> the address isn't configured yet.<br>
><br>
> That said... listening only on internal addresses doesn't mean the<br>
> connections will be accepted only from internal interfaces -- at least for<br>
> IPv4, Linux considers the addresses as belonging to the whole host, and<br>
> will still accept connections from any interface. (I tested this just a<br>
> while ago.) So changing the listen-addr is not a good security measure, you<br>
> *still* need the corresponding firewall rules (filtering by source IP).<br>
><br>
<br>
</span>What is the value of rp_filter sysctl on your interfaces<br>
(/proc/sys/net/ipv4/conf/*/rp_<wbr>filter)?<br>
</blockquote></div><br>.all.rp_filter = 2 (loose filter), so max(all, <interface>) = 2 as well.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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>`.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>></div></div>
</div></div>