Re: [systemd-devel] Adding "After=network-online.target" via drop-in
On Sun, Feb 19, 2017 at 6:56 PM, Andrei Borzenkov wrote: > 19.02.2017 15:34, Mantas Mikulėnas пишет: > > On Sat, Feb 18, 2017 at 10:32 PM, Ian Pilcher > 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, ) = 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 /32 via `.) 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding "After=network-online.target" via drop-in
19.02.2017 15:34, Mantas Mikulėnas пишет: > On Sat, Feb 18, 2017 at 10:32 PM, Ian Pilcher 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)? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding "After=network-online.target" via drop-in
No, that's not how I tested it. On Sun, Feb 19, 2017 at 2:42 PM, Reindl Harald wrote: > > i guess you tested that from the local host itself and not from the > outside because this is *not* true > > on the local machine things are different like reject a specific port for > the "lo" interface but "telnet lan-address port" is also refused -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding "After=network-online.target" via drop-in
On 02/19/2017 06:34 AM, Mantas Mikulėnas wrote: 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). That's a great point. In my case the internal address is non-routable, so listening on only that address does add at least some level of difficulty for a hypothetical attacker. Always good to remember this counter-intuitive (IMO) behavior. -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding "After=network-online.target" via drop-in
On Sat, Feb 18, 2017 at 10:32 PM, Ian Pilcher 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). -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding "After=network-online.target" via drop-in
Am 19.02.2017 um 13:34 schrieb Mantas Mikulėnas: On Sat, Feb 18, 2017 at 10:32 PM, Ian Pilcher mailto:arequip...@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) i guess you tested that from the local host itself and not from the outside because this is *not* true on the local machine things are different like reject a specific port for the "lo" interface but "telnet lan-address port" is also refused ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?
On Mon, Feb 06, 2017 at 09:56:30PM +0100, Lennart Poettering wrote: > On Sat, 21.01.17 21:20, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > On Fri, Jan 20, 2017 at 02:51:00PM +, Patrick Schleizer wrote: > > > I've learned about the kernel parameter and symlink ways to disable > > > predictable network interface names. > > > > What would be the "symlink way"? > > Linking the relevant .link file to /dev/null in /etc. What if there is no .link file and the Interfaces just come up as enp8s0 and wlp2s0 > However, if you pick your own names outside of the kernel's > namespaces, then all is good, and that's actually what we > recommend. (Though I'd do it by dropping in some .link files with the > right [Match] sections to make this happen, not bother with udev > rules, but either works) [2/5147]mh@swivel:~ $ cat /etc/systemd/network/lanc0.link [Match] MACAddress=f0:de:f1:b0:03:20 [Link] Name=lanc0 [3/5148]mh@swivel:~ $ ip --oneline link show | grep f0:de:f1:b0:03:20 2: enp0s25: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000\link/ether f0:de:f1:b0:03:20 brd ff:ff:ff:ff:ff:ff [4/5149]mh@swivel:~ $ My ethernet is still enp0s25, what am I doing wrong? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
