This Bash-based security baseline check and auto-hardening script for Kylin systems turns scattered security review items into an executable, remediable, and auditable workflow. Its core value lies in reducing the time spent on manual baseline reviews, preventing configuration drift, and making remediation easier to track. Keywords: Kylin Linux, security baseline, automated hardening.
The script provides a deployment-ready technical specification snapshot
| Parameter | Description |
|---|---|
| Target system | Kylin / Kylin Server OS |
| Implementation language | Bash |
| Checks and configuration items | 67 |
| Required privileges | root |
| Output path | /root/result/results_show |
| Backup strategy | Append .kybak to modified files |
| Typical protocols | SSH, NTP, SNMP, Syslog |
| Core dependencies | systemctl, pam, sysctl, rsyslog, auditd |
| GitHub stars | Not provided in the original source |
The script’s core value is that it upgrades checking into checking plus remediation
The script described in the original source does more than run baseline scans. It directly remediates noncompliant settings, including permission tightening, service enablement or disablement, PAM policy updates, and kernel parameter enforcement. This design works especially well for bulk remediation in regulated domestic IT environments and aligns more closely with the practical needs of compliance assessments and internal audits.
Compared with manually reviewing configuration files one by one, this script-driven approach offers three clear benefits: consistent standards, repeatable execution, and traceable results. All results are appended to /root/result/results_show, and every modified file gets a .kybak backup, which reduces rollback cost if a change causes issues.
#!/bin/bash
RESULT_FILE="/root/result/results_show"
TARGET_CONF="/etc/ssh/sshd_config"
cp "$TARGET_CONF" "${TARGET_CONF}.kybak" # Back up the configuration first for easier rollback
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' "$TARGET_CONF" # Disable remote root login
systemctl restart sshd # Restart the service to apply the change
echo "SSH baseline remediated" >> "$RESULT_FILE" # Record the execution resultThis example captures the script’s typical execution pattern: back up, remediate, apply, and record.
The script breaks security controls into seven auditable modules
The account and authentication module closes high-risk identity entry points
The script checks whether sudo is installed, identifies non-root accounts with UID 0, detects accounts with empty passwords, and restricts su access to root for users outside the wheel group. The goal here is not just to find issues, but to block lateral privilege escalation and weak identity controls.
The file and directory permissions module reduces the local privilege escalation surface
It removes world-writable directories and files from PATH, corrects permissions for critical files such as /etc/passwd, /etc/group, and /etc/shadow, and checks for unreasonable suid/sgid bits under /usr/bin. These controls are essential for preventing local privilege escalation, command hijacking, and sensitive data exposure.
find /usr/bin -perm /6000 -type f > /tmp/suid_sgid_list.txt # Enumerate suid/sgid files
chmod 000 /etc/shadow # Tighten shadow permissions to prevent password hash exposure
chmod 644 /etc/passwd /etc/group # Correct standard account file permissionsThis logic shows the script’s dual focus on high-risk permission bits and critical account files.
The service and process management module directly constrains the exposed attack surface
The script enables required services such as rsyslog, sshd, auditd, and ntpd, while disabling telnet, sendmail, talk, ntalk, nfs, and a set of legacy high-risk services. For SSH, it further restricts protocol versions, failed authentication attempts, the login banner, and the root login policy.
The network and kernel security module reduces default host exposure
The script disables ip_forward, turns off source routing, ICMP redirects, and broadcast responses, and checks ASLR and relative PATH issues. At a system level, this reduces exploitable default behavior and helps prevent a host from being used as a forwarding node or an easy reconnaissance target.
sysctl -w net.ipv4.ip_forward=0 # Disable IP forwarding
sysctl -w net.ipv4.conf.all.accept_redirects=0 # Do not accept ICMP redirects
sysctl -w net.ipv4.conf.all.send_redirects=0 # Do not send redirects
sysctl -w kernel.randomize_va_space=2 # Enable ASLR address randomizationKernel parameter tuning is one of the most stable and highest-return categories in host baseline hardening.
The script brings log auditing and password policy into a unified remediation loop
The logging and auditing module ensures changes and events remain traceable
The script enables rsyslog, records su activity to /var/log/secure, writes cron activity to /var/log/cron, and sets audit log retention to 365 days. In many compliance scenarios, logs are not secondary artifacts. They are evidence that security controls are functioning as intended.
The password policy and account lockout module establishes a unified password standard
It sets minimum password length, complexity, expiration, minimum change interval, password history retention, and failed login lockout policy, while also enforcing TMOUT=480 and limiting shell history length. In other words, the script does not just enforce password strength. It also limits long-lived exposed sessions.
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 minlen=8 minclass=3 dcredit=-1 ucredit=-1 lcredit=-1
password required pam_pwhistory.so remember=5 enforce_for_root # Prevent historical password reuse
account required pam_faillock.so preauth silent deny=6 unlock_time=1800 # Lock the account after consecutive failuresThese PAM settings are central to password governance, but you should validate compatibility in a test environment before rollout.
The script still requires layered validation in production
The original source explicitly notes that the script was tested on Kylin-Server-V10-SP3, and item 66, chattr +i, has been commented out to avoid disrupting follow-up operations and maintenance. This shows the author already recognizes the tradeoff between security hardening and operational manageability.
In addition, some configuration changes do not take effect globally right away. PAM rules often require a new login session, sysctl settings may require reload, and service configuration changes require process restarts. A safer rollout pattern is to execute in three stages: test, canary, and full deployment.
Production environments should use a minimum-risk execution workflow
bash kylin_baseline.sh > /tmp/kylin_fix.log 2>&1 # Run the script first and capture detailed logs
grep -E "FAILED|WARN|ERROR" /tmp/kylin_fix.log # Filter failures and risk indicators
ls /etc/*.kybak /etc/ssh/*.kybak 2>/dev/null # Verify that backup files were createdThe goal at this stage is not to change everything immediately. It is to confirm that remediation actions, error output, and rollback artifacts are all complete and usable.
The script fits domestic server security compliance and large-scale baseline governance
If your goal is to standardize security remediation across Kylin hosts, this type of script is highly efficient. It is especially suitable for initial baseline convergence, pre-assessment checks before compliance reviews, consistency governance across large server fleets, and operational scenarios where teams want to turn experience into executable rules.
That said, you should also recognize its limits. The script comes from an article description, the download source is a cloud drive link, and the original source does not provide a versioned repository, release history, or automated test information. In enterprise use, you should perform a code audit first, split rules by version, and convert high-risk changes into switchable policies.
FAQ
1. Is this script suitable for direct one-click execution in production?
No. You should first validate it on a Kylin test machine running the same version, with special attention to whether PAM, SSH, sysctl, and service disablement affect live workloads. Then roll it out in controlled batches.
2. What is the most valuable capability of this script?
Its value is not just in finding issues, but in automatically remediating them with traceability. It combines checking, configuration changes, result logging, and backup-based rollback, making it clearly more useful than a read-only baseline scanner.
3. What should you verify before using this script?
First, confirm root access and the exact OS version. Next, verify service dependencies and business-critical ports. Finally, review the downloaded script itself to ensure that no unvalidated commands are introduced directly into production.
AI Readability Summary: This article reconstructs and analyzes a Bash-based security baseline check and auto-hardening script for Kylin Linux. It covers 67 configuration items across accounts, permissions, services, networking, auditing, and password policy. The script supports automated remediation, persistent result logging, and configuration backup, making it well suited for domestic server security compliance and day-to-day baseline governance.