linux安全风险源于配置不当、服务暴露、权限失控和版本过旧，核心需聚焦开放端口、提权路径、日志盲区三入口；用sudo ss -tulnp查监听端口及进程，sudo -l -n查提权命令，grep "failed password" /var/log/auth.log分析爆破行为，并验证补丁而非仅升级版本。
Linux系统本身没有“自带漏洞”，但配置不当、服务暴露、权限失控或软件版本过旧，会快速放大攻击面。识别风险不靠扫描工具堆砌，而要聚焦三个真实入口：开放端口、提权路径、日志盲区。
怎么看哪些端口在偷偷监听？
netstat 和 ss 都能查，但 ss 更轻量、输出更结构化，且默认包含进程名（需 root 权限）。很多人用 netstat -tuln 却漏掉 UDP 服务，或者没加 -p 导致无法定位归属进程。
- 用
sudo ss -tulnp查所有监听端口及对应 PID/程序名 - 重点关注非标准端口（如 8080、8443、2375）是否运行了 Docker API、Web 管理后台等高危服务
-
ss -tuln src :22可单独检查 SSH 是否绑定了 0.0.0.0（全网可访问），而非仅127.0.0.1 - 若看到
*:2375且无认证，Docker Remote API 已裸奔，远程执行命令只差一条 curl
为什么普通用户能执行 sudo 命令却没被发现？
sudo -l 是唯一可靠方式，但它只显示当前用户被允许执行的命令——而很多管理员误以为 “没配 NOPASSWD 就安全”，其实只要 /etc/sudoers 中存在模糊通配符（如 /usr/bin/find * 或 /bin/bash --norc --noprofile），就可能被用于提权。
- 运行
sudo -l -n 2>/dev/null（-n避免交互式密码提示）快速列出所有免密或带限制的命令 - 警惕含通配符、shell 转义、环境变量注入点的命令，例如
sudo /usr/bin/perl -e 'exec "/bin/sh"'可绕过大部分白名单限制 - 检查
/etc/sudoers.d/下的碎片化配置，它们常被遗忘，却拥有和主文件同等效力
登录失败日志为什么总对不上实际攻击行为？
默认的 /var/log/auth.log（Debian/Ubuntu）或 /var/log/secure（RHEL/CentOS）只记录 PAM 认证事件，但暴力破解常发生在 SSH 层之前（如 fail2ban 未启用、MaxAuthTries 设为 6）、或绕过 PAM（如利用 Dropbear 的 CVE-2023-48795）。
- 用
grep "Failed password" /var/log/auth.log | tail -20快速确认近期爆破频率，但注意：SSH 日志中 “invalid user” 比 “Failed password” 更危险，说明攻击者在枚举账号 - 检查
sshd_config中LogLevel是否为VERBOSE，否则不会记录具体用户名和来源 IP - 若使用 key-only 登录，
Failed password日志应几乎为零；一旦出现，大概率是有人在尝试降级到密码认证（比如修改了AuthenticationMethods）
更新内核和 OpenSSL 就万事大吉？
不是。CVE-2021-4034（PwnKit）、CVE-2023-28873（Polkit）、CVE-2023-45853（systemd-resolved）这类漏洞，修复依赖具体补丁版本，而非“大版本升级”。例如 Ubuntu 20.04 的 polkit 包即使打了安全更新，也可能因 backport 不完整仍存在绕过路径。
- 用
apt list --upgradable（Debian/Ubuntu）或dnf list updates（RHEL/CentOS）确认是否有待应用的安全更新，别只看apt update && apt upgrade是否“无包可升” - 对关键组件单独验证版本：
dpkg -l | grep polkit或rpm -q polkit，再对照发行版安全公告中的修复版本号 - 某些漏洞（如 Dirty Pipe）需重启才能生效，但
systemctl reboot不等于“已修复”——得确认uname -r输出的内核版本确实包含补丁
最常被忽略的是服务与用户的耦合关系：一个没人维护的 Jenkins 实例跑在普通用户 home 目录下，既监听公网又允许插件上传，比一个打满补丁但配置宽松的 Nginx 危险得多。风险不在版本号里，在谁启动它、对谁开放、有没有人盯日志。
