什么是共享或允许与公司无关的互联网用户访问 trac 和 svn 的最佳实践？
它应该位于 DMZ 上吗？它应该位于内部且具有某种形式的 SSH 连接吗？或者使用 https？
如果您要这样做，并且对安全性有疑虑，那么最佳实践列表应该是什么，假设 WAN 上有基本的防火墙，服务器是否应该像边界区域一样在网络上独立存在（远离内部用户，双重防火墙）。
提前致谢。
答案1
假设你确实偏执（又称过度杀伤场景）：
- 在防火墙子网中放置一个反向代理 [例如使用 apache2]，使其只能通过 https 访问，仅供需要访问它的外部用户的选定 IP 地址访问 [这可以保护您免受对 apache / svn / trac 中可能存在的漏洞的盲目攻击]。仅将对有效 URL [例如 /svn 和 /trac] 的请求转发到位于单独子网中的实际服务器。确保此代理只能在端口 80/tcp 上访问您的实际服务器。仅此而已。
- 将您的实际 svn / trac 服务器放在单独的子网中，并控制访问：允许来自公司内部和代理的传入 http 连接。禁止传出连接。
如果限制对 #1 的访问以明确列出 IP 范围不是一个选项 - 请考虑某种形式的看门人 - 再次 - 避免盲目攻击。
在代理级别 - 考虑使用：
答案2
取决于你的预算。
尝试在前面设置防火墙，仅允许 https 访问，并在 apache 端使用双向 ssl。
答案3
如果我这样做，我会将 trac 放在公司主防火墙之外的盒子上，但在其上设置防火墙规则以阻止除 ssh（对我而言）和 http（对其他所有人而言）之外的任何访问。
另一个选择可能是问自己：我们到底应该托管这个吗？在 sourceforge 或 savannah.{non}gnu.org 或 github 上哪个更好？
答案4
仅具有 https 访问的标准服务器是相当安全的解决方案，具有有限数量的开放端口等。
偏执的配置可能是 VPN（例如开放VPN) 供公司外部用户访问。Trac 和 svn 只能从您的私有网络和 VPN 访问。用户对 VPN 的访问将由您颁发的证书保护。当然，其他任何服务器和内部网络都无法从 VPN 访问。
当然，只有当公司外部人员数量相当稳定且规模不大时，此解决方案才可行。如果这些用户和特定人员的数量发生变化，那么具有 https 访问和良好设置防火墙的第一个解决方案肯定是唯一的解决方案（并且被许多人和公司使用）。