No edit summary |
|||
(20 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
= Deprecate TCP wrappers = | |||
= Deprecate TCP wrappers | |||
== Summary == | == Summary == | ||
TCP wrappers is a simple tool to block incoming connection on application level. This was very useful 20 years ago, when there were no firewalls in Linux. This is not the case for today and connection filtering should be done in network level or completely in application scope if it makes sense. After recent discussions I believe it is time to go for this package, if not completely, than at least as a dependency of modern daemons in system by default. | TCP wrappers is a simple tool to block incoming connection on application level. This was very useful 20 years ago, when there were no firewalls in Linux. This is not the case for today and connection filtering should be done in network level or completely in application scope if it makes sense. After recent discussions I believe it is time to go for this package, if not completely, than at least as a dependency of modern daemons in system by default. | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | ||
Line 34: | Line 14: | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: jjelen@redhat.com | * Email: jjelen@redhat.com | ||
* Release notes | * Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/85 #85] | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/28 | Fedora 28 ]] | * Targeted release: [[Releases/28 | Fedora 28 ]] | ||
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | * Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | ||
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1495181 #1495181] | |||
* Tracker bug: | |||
== Detailed Description == | == Detailed Description == | ||
The last version of <code>tcp_wrappers</code> was released 20 years ago (although IPv6 support was added later). At that time it was very powerful tool to "block all traffic", but these days we can do the same thing using firewalls/iptables/nftables for all traffic on network level or use similar filtering at the application level. | |||
One of the motivating factors for this change was removal of TCP wrappers support from systemd and | One of the motivating factors for this change was the removal of TCP wrappers support from systemd and OpenSSH in 2014, based on the thread on fedora devel list [https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.html]. Another thread was started during 2017 [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2IBVP66BM6HUZVRTFIVURNZUR2XSUMOD/] which is trying to explain the reasons why we should do that with other constructive ideas. | ||
Another factor which has driven the deprecation of this package is the lack of any upstream community around it. Although the threats on networking communications increase, the threat coverage of this package has remained the same the last two decades, | Another factor which has driven the deprecation of this package is the lack of any upstream community around it. Although the threats on networking communications continually increase, the threat coverage of this package has remained the same over the last two decades, leading one to draw the inference that new threats are now being handled by different components. | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
Line 70: | Line 35: | ||
Removing the dependency from all packages and retiring the package in single release will minimize users confusion and avoids opening sensitive services after the update. | Removing the dependency from all packages and retiring the package in single release will minimize users confusion and avoids opening sensitive services after the update. | ||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | ||
== Scope == | == Scope == | ||
* Proposal owners: Deprecate tcp_wrappers in Fedora | * Proposal owners: | ||
** Deprecate <code>tcp_wrappers</code> in Fedora: | |||
*** Remove dependency on other packages maintained and notify other maintainers to follow the same procedure. | |||
*** Remove <code>tcp_wrappers-devel</code> subpackage to avoid new packages building against it before Mass Rebuild (31st January 2018). | |||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Other developers: Remove dependency of your software on tcp_wrappers <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: Remove dependency of your software on <code>tcp_wrappers</code>. See Dependencies section for more information. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Release engineering: [https://pagure.io/releng/ | * Release engineering: [https://pagure.io/releng/issue/7029 #7029] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
Line 87: | Line 54: | ||
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --> | <!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --> | ||
* Policies and guidelines: | * Policies and guidelines: Update packaging guidelines to NOT RECOMMEND building against <code>tcp_wrappers</code> after the removal. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | <!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | ||
Line 94: | Line 61: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
Updating from older versions might expose existing services "protected" by tcp_wrappers before (sshd). The removal needs to be explicitly mentioned in the migration guide/release notes so the users are able to configure different layer of security ( | Updating from older versions might expose existing services "protected" by <code>tcp_wrappers</code> before (<code>sshd</code>). The removal needs to be explicitly mentioned in the migration guide/release notes so the users are able to configure different layer of security (<code>firewalld</code>, application configuration) if this was the only one they used. | ||
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | ||
Line 100: | Line 67: | ||
== How To Test == | == How To Test == | ||
You should be able to run system (for example with OpenSSH) without tcp_wrappers package. | You should be able to run system (for example with OpenSSH) without tcp_wrappers package. | ||
For example, OpenSSH nor OpenLDAP daemons should not be linked with libwrap. The following command should not return anything: | |||
ldd /usr/sbin/sshd | grep libwrap | |||
ldd /usr/sbin/slapd | grep libwrap | |||
There should be no tcp_wrappers-devel package in the system: | |||
rpm -q tcp_wrappers-devel | |||
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | <!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | ||
Line 116: | Line 92: | ||
== User Experience == | == User Experience == | ||
Users should not notice any difference. System administrators | Users should not notice any difference. System administrators should configure different layer of security, if <code>tcp_wrapper</code> was the only one they relied on. | ||
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | <!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | ||
== Dependencies == | == Dependencies == | ||
Other packages should be rebuilt without support for tcp_wrappers (if possible). That should be at most tens lines of code change, configure option (if upstream still supports it) or dropping downstream patch. | Other packages should be rebuilt without support for <code>tcp_wrappers</code> (if possible). That should be at most tens lines of code change, configure option (if upstream still supports it) or dropping downstream patch. | ||
The list of packaged still using <code>tcp_wrappers</code>, based on the <code>dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64</code> and manual removal of duplicates and packages building against <code>net-snmp</code> (therefore indirectly depending on <code>libwrap</code>): | |||
* 389-ds-base | |||
* aeskulap | |||
* apcupsd | |||
* apt-cacher-ng | |||
* audit | |||
* bacula | |||
* bacula2 | |||
* conserver | |||
* ctk | |||
* cyrus-imapd | |||
* dcmtk | |||
* dovecot | |||
* exim | |||
* flow-tools | |||
* gsi-openssh | |||
* net-snmp | |||
* nfs-utils | |||
* ngircd | |||
* nrpe | |||
* openldap | |||
* openssh | |||
* pptpd | |||
* prelude-manager | |||
* proftpd | |||
* pulseaudio | |||
* quota | |||
* redir | |||
* rpcbind | |||
* rwhoisd | |||
* sendmail | |||
* slapi-nis | |||
* socat | |||
* sslh | |||
* stunnel | |||
* syslog-ng | |||
* tftp | |||
* up-imapproxy | |||
* uwsgi | |||
* vsftpd | |||
* xinetd | |||
* yaz | |||
If you wish to maintain compatibility with old releases/you can adjust spec file in the similar way how [https://src.fedoraproject.org/rpms/ocserv/blob/master/f/ocserv.spec#_14 ocserv] does it: | |||
%if 0%{?fedora} >= 28 || 0%{?rhel} > 7 | |||
%define use_libwrap 0 | |||
%else | |||
%define use_libwrap 1 | |||
%endif | |||
... | |||
%if %{use_libwrap} | |||
--with-libwrap | |||
%else | |||
--without-libwrap | |||
%endif | |||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | ||
Line 128: | Line 162: | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: tcp_wrappers package will not be retired, offending packages will still carry this dependency, but guidelines should be updated to not recommend building against this package <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency mechanism: <code>tcp_wrappers</code> package will not be retired, offending packages will still carry this dependency, but guidelines should be updated to not recommend building against this package <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: Beta freeze | * Contingency deadline: Beta freeze (2018-03-06) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Line 136: | Line 170: | ||
== Documentation == | == Documentation == | ||
After removing the libwrap dependency from | === Migration to tcpd === | ||
After removing the <code>libwrap</code> dependency from <code>openssh</code>, it will stop using rules defines in <code>/etc/hosts.deny</code>. The functionality can be "added back" if needed to any socket-activated service. For example SSHD: | |||
* Disable <code>sshd.service</code> | * Disable default SSHD service <code>sshd.service</code> - will be started afterwards by <code>sshd.socket</code> | ||
systemctl disable sshd | systemctl disable sshd | ||
* | * Create directory for override config <code>/etc/systemd/system/sshd@.service.d/</code> | ||
mkdir -p /etc/systemd/system/sshd@.service.d/ | |||
* | * Create override config file for SSH service <code>/etc/systemd/system/sshd@.service.d/override.conf</code> | ||
cat <<'END' >/etc/systemd/system/sshd@.service.d/override.conf | |||
[Unit] | |||
ConditionFileIsExecutable=/usr/sbin/tcpd | |||
[Service] | |||
ExecStart= | |||
END | |||
* Append related part from default file (content varies over distributions) by prepending <code>@-/usr/sbin/tcpd</code> | |||
grep '^ExecStart=' /usr/lib/systemd/system/sshd@.service | sed 's#[^\/]*\(.*\)#ExecStart=@-/usr/sbin/tcpd \1#' >>/etc/systemd/system/sshd@.service.d/override.conf | |||
Resulting in (example from EL8): | |||
[Unit] | |||
ConditionFileIsExecutable=/usr/sbin/tcpd | |||
[Service] | |||
ExecStart= | |||
ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY | ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY | ||
* Permanently enable related required SELinux boolean | |||
setsebool -P ssh_use_tcpd=1 | |||
* Reload <code>systemctl</code> | * Reload <code>systemctl</code> | ||
Line 160: | Line 215: | ||
* Enable and start <code>sshd.socket</code> | * Enable and start <code>sshd.socket</code> | ||
systemctl enable sshd.socket | systemctl enable --now sshd.socket | ||
* Verify that you can connect to new service | |||
ssh localhost | |||
Should still result in successful connect (depending on existing content of <code>/etc/hosts.allow</code> and <code>/etc/hosts.deny</code> | |||
* Check whether it's honoring <code>/etc/hosts.deny</code> | |||
cat <<END >>/etc/hosts.deny | |||
sshd: 127.0.0.1 [::1] | |||
END | |||
* Verify that content in <code>/etc/hosts.deny</code> is honored and connection is blocked | |||
ssh localhost | |||
kex_exchange_identification: read: Connection reset by peer | |||
Blocked connection should appear in log | |||
journalctl -t sshd | grep refused | |||
May 14 08:29:11 *** sshd[1698]: refused connect from ::1 (::1) | |||
A similar approach can be used for other services with dropped <code>tcp_wrappers</code> dependency. | |||
See also https://bugzilla.redhat.com/show_bug.cgi?id=1904301 | |||
=== Migration to systemd eBPF-based filter === | |||
SystemD 235 implemented [https://github.com/systemd/systemd/pull/6764 eBPF-based filter for services]. This provides a new options <code>IPAddressAllow</code> and <code>IPAddressDeny</code> for units. It is not restricted to socket-activated services, but because it is enforced on the kernel level, it can seamlessly work with standard services. | |||
One can simply allow access to <code>sshd</code> service only from IP address 192.168.0.42 by creating a drop-in unit file in | |||
IPAddressAllow=192.168.0.42 | |||
To implement similar effects as <code>tcp_wrappers</code> do for multiple services, you can apply these rules for whole system in <code>system.slice</code>. | |||
=== Migrate to application-specific filters === | |||
Most of the tools currently support its own way of filtering traffic. For example, OpenSSH <code>Match</code> blocks can be used to disable authentication from specific IP addresses or hostnames (with <code>UseDNS yes</code>) or <code>mod_wrap2</code> for ProFTPD, which allows even more flexibility. | |||
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | <!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | ||
== Release Notes == | == Release Notes == | ||
Fedora 28 removes support for tcp_wrappers (aka <code>/etc/hosts.deny</code> access files). The preferred replacement is software firewalld/nftables rules or software specific access rules for more complex filtering. If your system security depends on tcp_wrappers rules, convert them to firewall, or set up <code>tcpd</code> to do the same job for you. | Fedora 28 removes support for tcp_wrappers (aka <code>/etc/hosts.deny</code> access files) by default. The preferred replacement is software firewalld/nftables rules or software specific access rules for more complex filtering. If your system security depends on tcp_wrappers rules, convert them to firewall, or set up <code>tcpd</code> to do the same job for you. | ||
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --> | <!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --> | ||
Line 178: | Line 267: | ||
--> | --> | ||
[[Category: | [[Category:ChangeAcceptedF28]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> |
Latest revision as of 08:43, 14 May 2022
Deprecate TCP wrappers
Summary
TCP wrappers is a simple tool to block incoming connection on application level. This was very useful 20 years ago, when there were no firewalls in Linux. This is not the case for today and connection filtering should be done in network level or completely in application scope if it makes sense. After recent discussions I believe it is time to go for this package, if not completely, than at least as a dependency of modern daemons in system by default.
Owner
- Name: Jakub Jelen
- Email: jjelen@redhat.com
- Release notes ticket: #85
Current status
Detailed Description
The last version of tcp_wrappers
was released 20 years ago (although IPv6 support was added later). At that time it was very powerful tool to "block all traffic", but these days we can do the same thing using firewalls/iptables/nftables for all traffic on network level or use similar filtering at the application level.
One of the motivating factors for this change was the removal of TCP wrappers support from systemd and OpenSSH in 2014, based on the thread on fedora devel list [1]. Another thread was started during 2017 [2] which is trying to explain the reasons why we should do that with other constructive ideas.
Another factor which has driven the deprecation of this package is the lack of any upstream community around it. Although the threats on networking communications continually increase, the threat coverage of this package has remained the same over the last two decades, leading one to draw the inference that new threats are now being handled by different components.
Benefit to Fedora
Removing this package from Fedora will remove a package from default and minimal installations (removing dependency of daemons such as SSHD). It also makes the configuration straight-forward for new users (no shared files defining access rules, poorly reporting any errors to users.
Removing the dependency from all packages and retiring the package in single release will minimize users confusion and avoids opening sensitive services after the update.
Scope
- Proposal owners:
- Deprecate
tcp_wrappers
in Fedora:- Remove dependency on other packages maintained and notify other maintainers to follow the same procedure.
- Remove
tcp_wrappers-devel
subpackage to avoid new packages building against it before Mass Rebuild (31st January 2018).
- Deprecate
- Other developers: Remove dependency of your software on
tcp_wrappers
. See Dependencies section for more information.
- Release engineering: #7029 (a check of an impact with Release Engineering is needed)
- List of deliverables: Not affected
- Policies and guidelines: Update packaging guidelines to NOT RECOMMEND building against
tcp_wrappers
after the removal.
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
Updating from older versions might expose existing services "protected" by tcp_wrappers
before (sshd
). The removal needs to be explicitly mentioned in the migration guide/release notes so the users are able to configure different layer of security (firewalld
, application configuration) if this was the only one they used.
How To Test
You should be able to run system (for example with OpenSSH) without tcp_wrappers package.
For example, OpenSSH nor OpenLDAP daemons should not be linked with libwrap. The following command should not return anything:
ldd /usr/sbin/sshd | grep libwrap ldd /usr/sbin/slapd | grep libwrap
There should be no tcp_wrappers-devel package in the system:
rpm -q tcp_wrappers-devel
User Experience
Users should not notice any difference. System administrators should configure different layer of security, if tcp_wrapper
was the only one they relied on.
Dependencies
Other packages should be rebuilt without support for tcp_wrappers
(if possible). That should be at most tens lines of code change, configure option (if upstream still supports it) or dropping downstream patch.
The list of packaged still using tcp_wrappers
, based on the dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64
and manual removal of duplicates and packages building against net-snmp
(therefore indirectly depending on libwrap
):
- 389-ds-base
- aeskulap
- apcupsd
- apt-cacher-ng
- audit
- bacula
- bacula2
- conserver
- ctk
- cyrus-imapd
- dcmtk
- dovecot
- exim
- flow-tools
- gsi-openssh
- net-snmp
- nfs-utils
- ngircd
- nrpe
- openldap
- openssh
- pptpd
- prelude-manager
- proftpd
- pulseaudio
- quota
- redir
- rpcbind
- rwhoisd
- sendmail
- slapi-nis
- socat
- sslh
- stunnel
- syslog-ng
- tftp
- up-imapproxy
- uwsgi
- vsftpd
- xinetd
- yaz
If you wish to maintain compatibility with old releases/you can adjust spec file in the similar way how ocserv does it:
%if 0%{?fedora} >= 28 || 0%{?rhel} > 7 %define use_libwrap 0 %else %define use_libwrap 1 %endif ... %if %{use_libwrap} --with-libwrap %else --without-libwrap %endif
Contingency Plan
- Contingency mechanism:
tcp_wrappers
package will not be retired, offending packages will still carry this dependency, but guidelines should be updated to not recommend building against this package - Contingency deadline: Beta freeze (2018-03-06)
- Blocks release? No
Documentation
Migration to tcpd
After removing the libwrap
dependency from openssh
, it will stop using rules defines in /etc/hosts.deny
. The functionality can be "added back" if needed to any socket-activated service. For example SSHD:
- Disable default SSHD service
sshd.service
- will be started afterwards bysshd.socket
systemctl disable sshd
- Create directory for override config
/etc/systemd/system/sshd@.service.d/
mkdir -p /etc/systemd/system/sshd@.service.d/
- Create override config file for SSH service
/etc/systemd/system/sshd@.service.d/override.conf
cat <<'END' >/etc/systemd/system/sshd@.service.d/override.conf [Unit] ConditionFileIsExecutable=/usr/sbin/tcpd [Service] ExecStart= END
- Append related part from default file (content varies over distributions) by prepending
@-/usr/sbin/tcpd
grep '^ExecStart=' /usr/lib/systemd/system/sshd@.service | sed 's#[^\/]*\(.*\)#ExecStart=@-/usr/sbin/tcpd \1#' >>/etc/systemd/system/sshd@.service.d/override.conf
Resulting in (example from EL8):
[Unit] ConditionFileIsExecutable=/usr/sbin/tcpd [Service] ExecStart= ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY
- Permanently enable related required SELinux boolean
setsebool -P ssh_use_tcpd=1
- Reload
systemctl
systemctl daemon-reload
- Enable and start
sshd.socket
systemctl enable --now sshd.socket
- Verify that you can connect to new service
ssh localhost
Should still result in successful connect (depending on existing content of /etc/hosts.allow
and /etc/hosts.deny
- Check whether it's honoring
/etc/hosts.deny
cat <<END >>/etc/hosts.deny sshd: 127.0.0.1 [::1] END
- Verify that content in
/etc/hosts.deny
is honored and connection is blocked
ssh localhost kex_exchange_identification: read: Connection reset by peer
Blocked connection should appear in log
journalctl -t sshd | grep refused May 14 08:29:11 *** sshd[1698]: refused connect from ::1 (::1)
A similar approach can be used for other services with dropped tcp_wrappers
dependency.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1904301
Migration to systemd eBPF-based filter
SystemD 235 implemented eBPF-based filter for services. This provides a new options IPAddressAllow
and IPAddressDeny
for units. It is not restricted to socket-activated services, but because it is enforced on the kernel level, it can seamlessly work with standard services.
One can simply allow access to sshd
service only from IP address 192.168.0.42 by creating a drop-in unit file in
IPAddressAllow=192.168.0.42
To implement similar effects as tcp_wrappers
do for multiple services, you can apply these rules for whole system in system.slice
.
Migrate to application-specific filters
Most of the tools currently support its own way of filtering traffic. For example, OpenSSH Match
blocks can be used to disable authentication from specific IP addresses or hostnames (with UseDNS yes
) or mod_wrap2
for ProFTPD, which allows even more flexibility.
Release Notes
Fedora 28 removes support for tcp_wrappers (aka /etc/hosts.deny
access files) by default. The preferred replacement is software firewalld/nftables rules or software specific access rules for more complex filtering. If your system security depends on tcp_wrappers rules, convert them to firewall, or set up tcpd
to do the same job for you.