关于RHEL on AWS环境中Red Hat Insights Client加密规则修复及异常原因的咨询

Hey there, let's break down your concerns step by step—this is a common scenario, but let's dig into the details to get to the bottom of it.

First, why the remediation playbook and official guidance aren't working #

It’s frustrating when official fixes don’t land, so let’s start with some quick, actionable checks:

• Verify the current crypto policy state: Run update-crypto-policies --show to confirm which policy is active. If it’s not set to DEFAULT or FUTURE (the secure defaults), manually apply it with update-crypto-policies --set DEFAULT then restart sshd with systemctl restart sshd.
• Check for SSH config overrides: Red Hat’s crypto policies can be bypassed if you have hardcoded Ciphers or MACs lines in /etc/ssh/sshd_config. Run grep -E 'Ciphers|MACs' /etc/ssh/sshd_config—if you see these entries, either comment them out (to let the system policy take over) or replace them with secure values matching the crypto policy.
• Confirm post-fix service restart: Even if you apply the policy, sshd won’t pick up changes until you restart it. Double-check that you did this step—sometimes it’s easy to miss!

Next, the confusing modified date vs. recent alert #

The fact that the policy shows a modified date from July 24 but you only got the alert 3 days ago doesn’t automatically mean a breach—here are the most likely explanations:

• Insights scanning delay: Red Hat Insights doesn’t scan every system continuously. It’s possible the scan that detected the insecure ciphers only ran recently, even though the config change happened earlier. You can trigger an immediate scan with insights-client --checkin to verify the current state.
• System package updates: Did you run a yum update or apply any RHEL errata in the last few days? Updates to the crypto-policies or openssh-server packages could have reset or modified the policy, even if you didn’t touch it manually. Check your yum logs (/var/log/yum.log) for recent updates to these packages.
• AWS automation (unlikely, but possible): AWS won’t modify your EC2 instance’s OS configs by default, but if you’re using AWS Systems Manager Run Command, CloudFormation, or other automation tools, it’s worth checking if any recent jobs touched these instances. You can review CloudTrail logs for API actions related to your instances to rule this out.

Is this a data breach? #

Before jumping to conclusions, do some quick forensic checks to rule out unauthorized access:

• Check SSH logs in /var/log/secure for unusual login attempts, unfamiliar IPs, or failed brute-force attacks.
• Run last to see recent user logins, and check /etc/passwd//etc/shadow for any unexpected user accounts.
• Use rpm -Va crypto-policies openssh-server to verify that the package files for these components haven’t been tampered with (any output means files were modified outside of package updates).

If all these checks come up clean, it’s almost certainly not a breach—just a configuration quirk or scanning delay.

备注：内容来源于stack exchange，提问作者Huw Evans