-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFE] Enable tcp_wrapper support in Flatcar, especially with sshd but possibly other daemons as well. #1183
Comments
I can also recommend to look into bpf programs if you want to filter a systemd unit: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#BPFProgram=type:program-path |
eBPF sounds like a good alternative but: node-1 /etc/systemd/system/sshd.service.d # netstat -anp |grep ssh node-1 /etc/systemd/system/sshd.service.d # systemctl show sshd |grep IPAddress Maybe I'm doing something wrong, but it does not seem to work. |
I guess you also have to set it for |
I have masked sshd.socket and according to the documentation of systemd you should be able to set it on any unit. |
Looks like you need to create a global deny and then a specific allow. |
So if this is doable with systemd service configuration - i dont think we want to pull in another way of achieving the same result. Would you agree? |
I would agree. I think we can close this again. |
Current situation
Setting up a high secure environment it is good practice to always deploy dual layered security. With respect to sshd, where you need to have the daemon running to be able to do some maintenance, you want both a firewall to prevent access of unwanted connections, but if the firewall fails on you for whatever reason, you want a second layer of defense, and tcp_wrappers is in general a good second layer to allow only connections from specific host names.
Implementing hosts.allow files in a Flatcar linux install resulted in no added security and checking with ldd we find that indeed tcp_wrapper support is not enabled.
node-1 ~ # ldd /usr/sbin/sshd
linux-vdso.so.1 (0x00007ffccdfde000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f23652c0000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007f23652ae000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f2365259000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f236517f000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f2364d43000)
libz.so.1 => /lib64/libz.so.1 (0x00007f2364d29000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2364b46000)
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f2364b18000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f2364ae9000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f2364ae2000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f2364ad3000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f2364ac1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2365432000)
libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007f2364ab7000)
On a normal linux install I would expect something like:
ldd /usr/sbin/sshd |grep libwrap
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f69bbf9f000)
Impact
There is no viable option to create dual layered security on a Flatcar host which results in having to deploy other second layers which are in general more cumbersome to implement, or don't give the added benefit tcp_wrappers gives you.
Ideal future situation
sshd is compiled with tcp_wrapper support and the needed libraries are installed as well.
Implementation options
compile sshd with tcp_wrapper support.
Additional information
Adding this into Flatcar should have minimal impact because there are no hosts.allow or hosts.deny files in /etc at the moment, which results in no rules being in place. When we enable this feature in sshd we can tell everyone that this feature can then be used by just adding the correct files in /etc.
The text was updated successfully, but these errors were encountered: