为什么tcp-wrappers被Redhat Centos Fedora废弃？
<h2>1 简述</h2><p> <strong>TCP wrappers is a simple tool to block incoming connection on application level.</strong> This was very useful 20 years ago, when there were <strong>no firewalls in Linux</strong>. This is not the case for today and <strong>connection filtering should be done in network level or completely in application scope if it makes sense</strong>. 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.</p>
<h2>2 详细描述</h2>
<p style="box-sizing: inherit; margin: 0 0 1rem; color: rgba(55, 58, 60, 1); font-family: "Open Sans"">The last version of <code style="box-sizing: inherit; font-family: Hack, monospace; color: rgba(189, 65, 71, 1); background-color: rgba(247, 247, 249, 1); border: 1px solid rgba(234, 236, 240, 1); border-radius: 0.25rem; padding: 0.2rem 0.4rem; font-size: 12.6px">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 <strong>using firewalls/iptables/nftables for all traffic on network level or use similar filtering at the application level.</strong></p>
<p style="box-sizing: inherit; margin: 0 0 1rem; color: rgba(55, 58, 60, 1); font-family: "Open Sans"">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 . Another thread was started during 2017 which is trying to explain the reasons why we should do that with other constructive ideas.</p>
<p style="box-sizing: inherit; margin: 0 0 1rem; color: rgba(55, 58, 60, 1); font-family: "Open Sans"">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.</p>
<h2 style="box-sizing: inherit; margin: 0 0 1rem; color: rgba(55, 58, 60, 1); font-family: "Open Sans"">3 升级影响<span id="Upgrade.2Fcompatibility_impact" class="mw-headline"><br></span></h2>
<p>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.</p>
<p style="box-sizing: inherit; margin: 0 0 1rem; color: rgba(55, 58, 60, 1); font-family: "Open Sans""> </p>
<h2 style="box-sizing: inherit; margin: 0 0 1rem; color: rgba(55, 58, 60, 1); font-family: "Open Sans""><span id="Migration_to_tcpd" class="mw-headline">4 替代方案</span></h2>
<p>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:</p>
<ul>
<li>Disable <code>sshd.service</code></li>
</ul>
<pre>systemctl disable sshd
</pre>
<ul>
<li>Copy the shipped <code>sshd@.service</code> to <code>/etc</code>:</li>
</ul>
<pre>cp {/usr/lib,/etc}/systemd/system/sshd@.service
</pre>
<ul>
<li>Modify the <code>ExecStart</code> line in the above file under <code>/etc/</code> from</li>
</ul>
<pre>ExecStart=-/usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY
</pre>
<p>to</p>
<pre>ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY
</pre>
<ul>
<li>Reload <code>systemctl</code></li>
</ul>
<pre>systemctl daemon-reload
</pre>
<ul>
<li>Enable and start <code>sshd.socket</code></li>
</ul>
<pre>systemctl enable sshd.socket
systemctl start sshd.socket
</pre>
<ul>
<li>Verify that you can connect to new service (not working now, because it is blocked by SELinux). Blocked by the bug #1482554 .</li>
</ul>
<p>A similar approach can be used for other services to drop the <code>tcp_wrappers</code> dependency.</p>
<p> </p>
<p>参考链接：</p>
<p>https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers</p>
<p>https://serverfault.com/questions/869431/openssh-removed-support-for-tcp-wrappers-now-what-no-hosts-allow-for-ssh-acce</p>
<p>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UOAUI4TC6PQVHRJ2ONQ2N3IKHR4577VH/ 废弃后如何实现原有功能</p>
</div>
<div id="MySignature" role="contentinfo">
勤苦修行得自在，道力有边边亦无边！<br><br>
来源：https://www.cnblogs.com/noxy/p/12008118.html 顶一个！好详细的分析，说的很有道理。
确实，TCP Wrappers当年确实是个神器，记得刚学Linux那会儿，几乎每个服务都要配置hosts.allow和hosts.deny。但时代不同了，现在谁还用这个啊。
说几个观点：
1. 20年的老古董，早就该进历史博物馆了。现在有firewalld、iptables、nftables这些更专业的防火墙工具，功能强大不说，性能也更好。
2. 维护确实是个大问题。没什么人维护了，安全漏洞谁来修？总不能一直裸奔吧。
3. systemd和SSH都移除了支持，说明大势已去。Redhat系跟进废弃也很正常。
不过说实话，有些老系统上可能还在用。如果真的需要迁移，帖子里的那个systemd+tcpd的方案挺巧妙的，算是给老用户一个过渡期吧。
个人建议：新项目就直接用防火墙+应用层配置吧，别再纠结TCP Wrappers了。技术债早点还清比较好。
参考链接 收藏了，感谢分享！
頁:
[1]