1. 项目概述为什么你的Linux服务总在“裸奔”最近在帮几个朋友排查服务器问题发现一个挺普遍的现象很多开发者尤其是刚接触运维的朋友把服务部署到Linux服务器上后就默认它“安全”了。装个Nginx、配个MySQL、跑个Java应用端口一开域名一绑就觉得万事大吉。结果呢没过多久服务器就成了肉鸡要么被挖矿要么被挂马要么数据被拖库。每次去“救火”看到的配置都让我倒吸一口凉气——服务几乎都在以最高权限、最宽松的配置在“裸奔”。这让我意识到“部署”和“安全部署”完全是两码事。Linux系统本身确实比某些闭源系统在安全透明性上有优势但这绝不意味着默认配置就是安全的。每一个对外提供服务的进程都是一个潜在的攻击面。从SSH登录到Web服务从数据库到缓存如果不对其进行细致的安全加固就相当于把自家大门的钥匙放在了门垫下面。所以我想结合自己这些年踩过的坑、交过的“学费”整理一份面向服务的、可实操的Linux安全配置指南。这不是一份面面俱到的系统安全手册那太庞大了而是聚焦在“服务”这个核心维度上。我们会从最常暴露的几个服务入手拆解每一步加固操作的原理和目的让你不仅知道怎么配更明白为什么要这么配。目标很简单让你的服务不再是攻击者眼中“最软的那个柿子”。2. 安全基石最小权限与服务隔离思想在动手配置任何一个具体服务之前我们必须先统一思想。Linux安全乃至整个信息安全领域有一个颠扑不破的黄金法则最小权限原则Principle of Least Privilege, PoLP。这个原则说起来简单——只授予执行任务所必需的最小权限——但做起来处处是细节。2.1 理解“权限”的多个维度当我们为一个服务配置权限时不能只盯着Linux文件系统的rwx读、写、执行。那只是冰山一角。一个进程在系统中的“权力”至少包括四个层面文件系统权限这是最基础的即对特定文件和目录的访问能力。进程权限Capabilities传统上一个进程要么是普通用户要么是拥有全部特权的root。这太粗糙了。Linux Capabilities机制将root特权细分成几十个独立的单元如CAP_NET_BIND_SERVICE允许绑定1024以下端口CAP_SYS_ADMIN近似root。我们的目标是为服务进程赋予它刚好够用的Capabilities而不是整个root。网络访问权限服务能监听哪些端口能发起向哪些地址的连接这需要通过防火墙如iptables/nftables和服务的绑定配置来控制。系统资源权限服务能占用多少CPU、内存、打开多少文件描述符这可以通过cgroups、ulimit来限制防止一个服务被攻破后拖垮整个系统。注意很多Docker用户会以为容器本身就是完美的隔离。实际上默认的Docker容器进程虽然以非root用户运行但依然拥有大量的Linux Capabilities。使用--cap-dropALL --cap-addNET_BIND_SERVICE这样的参数来精细化控制才是遵循最小权限原则的做法。2.2 为每个服务创建专属系统用户这是实现隔离的第一步也是被忽略最多的一步。绝对不要用root或者通用的nobody用户来运行你的业务服务。为什么假设你的Nginx和MySQL都跑在nobody下。一旦Nginx因为一个漏洞比如解析漏洞被攻破攻击者获取的nobody进程权限就能直接访问或篡改MySQL通过nobody用户拥有的所有数据文件。隔离形同虚设。正确做法为每一个需要长期运行的服务创建一个专属的、无登录权限的系统用户和用户组。# 以创建nginx用户为例 sudo groupadd --system nginx sudo useradd --system --no-create-home --shell /bin/false -g nginx nginx--system创建系统用户/组UID/GID通常小于1000。--no-create-home不创建家目录。--shell /bin/false禁止该用户登录系统即使有人拿到了密码也无法通过shell连接。-g nginx指定主组。这样Nginx进程将以nginx:nginx的身份运行它的权限被严格限制在了我们赋予这个用户的文件访问范围内。MySQL、Redis等服务同理务必使用不同的专属用户。2.3 利用文件系统权限构建围栏创建好用户接下来就要用文件权限给这个用户“画个圈”。服务程序与配置文件通常服务二进制文件如/usr/sbin/nginx需要root用户启动因为要绑定80端口但启动后可以通过配置user nginx;指令降权运行。配置文件如/etc/nginx/nginx.conf应该设置为root用户只读防止被服务进程意外或恶意修改。sudo chown root:root /etc/nginx/nginx.conf sudo chmod 644 /etc/nginx/nginx.conf # root可读写其他用户只读数据与日志目录这是最容易出问题的地方。网站代码、上传文件、数据库数据文件、日志文件都必须严格控制。网站根目录假设是/var/www/myapp。应该由部署代码的CI/CD系统用户如deployer拥有写权限而运行服务的nginx用户只需要读和执行权限。sudo chown -R deployer:deployer /var/www/myapp sudo chmod -R 750 /var/www/myapp # 拥有者可读写执行同组用户可读执行其他用户无权限 # 如果目录下有需要nginx写入的目录如缓存再单独设置 sudo chown -R nginx:nginx /var/www/myapp/cache日志目录Nginx需要写入日志。将日志目录的所有权给nginx用户。sudo chown -R nginx:nginx /var/log/nginx sudo chmod -R 755 /var/log/nginx # 确保nginx用户有写权限其他用户通常只需读权限用于日志分析实操心得我习惯在项目初期就用一个脚本固化这些权限设置并纳入版本控制。每次部署后自动执行避免因为手动操作遗漏导致权限混乱。记住权限配置应该是声明式的、可重复的而不是每次靠记忆。3. 网络服务安全加固实战服务暴露在网络中是攻击最直接的入口。这一部分我们以最常见的Web服务Nginx和数据库服务MySQL为例进行深度加固。3.1 Web服务以Nginx为例纵深防御Nginx不仅是Web服务器更是流量的入口和第一道防线。3.1.1 隐藏版本信息与错误详情默认情况下Nginx会在HTTP响应头中返回Server: nginx/1.18.0这样的信息在错误页面也会显示详细的版本和配置路径。这是在给攻击者提供“地图”。加固方法在nginx.conf的http块中修改http { server_tokens off; # 关闭响应头中的Nginx版本号 ... }对于错误页使用自定义页面或者在server块中重定向server { error_page 404 /404.html; error_page 500 502 503 504 /50x.html; # 或者彻底隐藏错误详情只返回状态码 location /50x.html { internal; # 此页面只允许内部重定向访问 root /usr/share/nginx/html; } }3.1.2 限制请求方法与大小只允许必要的HTTP方法可以有效阻止很多恶意扫描和攻击尝试如PUT、DELETE方法可能用于上传Webshell。location / { limit_except GET POST HEAD { deny all; } client_max_body_size 10m; # 限制客户端请求体大小防CC攻击和大文件上传攻击 client_body_buffer_size 128k; client_header_buffer_size 4k; }3.1.3 配置安全的SSL/TLS如果你的服务使用HTTPS必须使用SSL/TLS配置至关重要。禁用老旧协议和不安全套件SSLv2、SSLv3、TLS 1.0、TLS 1.1都已不安全必须禁用。优先使用TLS 1.2和1.3。使用强加密套件禁用RC4、DES、3DES等弱加密算法。启用HSTS强制浏览器使用HTTPS连接防止SSL剥离攻击。server { listen 443 ssl http2; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; # HSTS (63072000 seconds 2 years) add_header Strict-Transport-Security max-age63072000; includeSubDomains; preload always; }提示可以使用在线工具如 SSL Labs Server Test 来检测你的SSL配置安全性拿到A评级才算合格。3.1.4 利用Nginx作为简易WAFNginx可以通过map指令和limit_req模块实现基础的Web应用防火墙功能。防扫描器/爬虫屏蔽带有常见扫描工具特征User-Agent的请求。map $http_user_agent $bad_bot { default 0; ~*(nmap|sqlmap|nikto|dirbuster|wget|curl|python|java) 1; ~*(bot|crawl|spider) 1; } server { if ($bad_bot) { return 403; } }注意此方法可能误伤需要根据自己业务调整。更推荐使用专业的WAF如ModSecurity。防暴力破解对登录接口进行速率限制。limit_req_zone $binary_remote_addr zonelogin:10m rate5r/m; location /api/login { limit_req zonelogin burst10 nodelay; proxy_pass http://backend_app; }这段配置将对/api/login的访问限制为每分钟5个请求并允许10个突发请求。3.2 数据库服务以MySQL/MariaDB为例加固数据库是数据的核心一旦失守损失惨重。默认安装的MySQL存在大量不安全配置。3.2.1 运行权限与文件安全绝对不要以root身份运行mysqld进程应该像我们之前说的创建一个专属用户比如mysql。sudo chown -R mysql:mysql /var/lib/mysql /var/log/mysql /run/mysqld确保数据目录(/var/lib/mysql)的权限为750只有mysql用户和同组用户可读。3.2.2 配置文件安全 (my.cnf)在[mysqld]节下进行关键安全配置[mysqld] # 1. 禁止加载本地文件 local-infile 0 # 2. 禁止符号链接防止通过软链接攻击其他文件 symbolic-links 0 # 3. 禁用DNS反向解析提升连接速度并避免DNS欺骗风险 skip-name-resolve # 4. 确保MySQL只监听本地或内网IP如果应用与数据库同机就只监听127.0.0.1 bind-address 127.0.0.1 # 如果需要远程连接通常不推荐请绑定到具体的内网IP并务必结合防火墙规则。 # 5. 设置默认存储引擎为InnoDB避免使用不安全的MyISAM default-storage-engine InnoDB # 6. 启用查询日志审计用生产环境慎用可能影响性能 # general_log 1 # general_log_file /var/log/mysql/query.log3.2.3 账户与权限管理这是数据库安全的重中之重。遵循“最小权限”原则为每个应用创建独立账户。删除匿名账户和测试数据库安装后第一件事。DROP USER localhost; DROP USER %; DROP DATABASE test;为每个应用创建专属用户用户由“用户名”和“主机名”共同定义。app_user192.168.1.%和app_user%是两个完全不同的用户。CREATE USER myapp192.168.1.100 IDENTIFIED BY StrongPassword123!; -- 或者如果应用与数据库同机限制为localhost最安全 CREATE USER myapplocalhost IDENTIFIED BY StrongPassword123!;授予最小必要权限只给这个用户访问特定数据库的特定权限。GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO myapp192.168.1.100; -- 绝对不要轻易授予 ALL PRIVILEGES 或 GRANT OPTION 权限。 FLUSH PRIVILEGES;定期审计用户权限SELECT user, host, authentication_string FROM mysql.user; SHOW GRANTS FOR myapp192.168.1.100;3.2.4 连接加密与SSL如果数据库需要被远程访问再次强调尽量通过内网或跳板机必须强制使用SSL连接。在MySQL服务器端配置SSL证书。创建要求SSL的用户。CREATE USER remote_admin% IDENTIFIED BY Password456! REQUIRE SSL; GRANT ALL PRIVILEGES ON *.* TO remote_admin% WITH GRANT OPTION; FLUSH PRIVILEGES;客户端连接时指定SSL选项。实操心得数据库的密码复杂度策略经常被忽视。我建议在my.cnf中配置validate_password插件强制要求密码长度、数字、大小写字母和特殊字符。对于生产环境所有数据库的访问都应该通过中间件或连接池进行并在网络层通过防火墙严格限制源IP做到“应用可访问人不可直连”。4. 系统级防护与入侵检测服务配置得再好也需依托于一个坚固的操作系统。系统层面的防护是最后一道也是最基本的防线。4.1 防火墙定义安全的边界iptables功能强大但复杂ufwUncomplicated Firewall是更友好的前端工具。对于新系统我推荐直接使用nftables它是iptables的继任者语法更清晰。一个基础的nftables策略示例保存为/etc/nftables.conf#!/usr/sbin/nft -f flush ruleset table inet filter { chain input { type filter hook input priority 0; policy drop; # 默认拒绝所有入站 # 允许已建立和相关连接 ct state established,related accept # 允许环回接口 iif lo accept # 允许ICMP (ping) ip protocol icmp accept # 开放SSH端口强烈建议改为非22端口 tcp dport 2222 accept # 开放HTTP/HTTPS端口如果你的服务器是Web服务器 tcp dport {80, 443} accept # 记录并拒绝其他所有入站流量 log prefix Dropped inbound: flags all counter drop } chain forward { type filter hook forward priority 0; policy drop; # 默认拒绝转发 } chain output { type filter hook output priority 0; policy accept; # 默认允许所有出站 } }启用并设置开机自启sudo nft -f /etc/nftables.conf sudo systemctl enable nftables sudo systemctl start nftables这个策略实现了“白名单”机制只明确放行必要的端口SSH、Web其他所有入站连接一律拒绝。务必根据你的服务情况修改端口列表。4.2 SSH服务守住最重要的入口SSH是管理员进入服务器的通道也是攻击者最常暴力破解的目标。禁用root登录永远不要允许root直接登录。# /etc/ssh/sshd_config PermitRootLogin no使用密钥认证禁用密码密码极易被暴力破解。使用Ed25519或RSA密钥对。PasswordAuthentication no PubkeyAuthentication yes修改默认端口将端口从22改为一个高位端口如2222能减少99%的自动化扫描和爆破尝试。Port 2222修改后记得防火墙也要同步开放新端口。使用Fail2ban这是一个自动封禁暴力破解IP的神器。它会监控日志如/var/log/auth.log当一个IP在短时间内多次认证失败就自动调用防火墙规则将其封禁一段时间。sudo apt install fail2ban # Debian/Ubuntu sudo systemctl enable --now fail2ban默认配置通常就够了你也可以在/etc/fail2ban/jail.local里自定义封禁时间和阈值。4.3 定期更新与漏洞扫描“勤打补丁”是成本最低的安全措施。建立自动安全更新机制。# Debian/Ubuntu sudo apt update sudo apt upgrade -y # 配置无人值守更新 sudo apt install unattended-upgrades sudo dpkg-reconfigure --prioritylow unattended-upgrades # CentOS/RHEL sudo yum update -y # 或使用 dnf sudo dnf update -y # 可以配置 yum-cron 实现自动更新除了系统包你的应用依赖如Python的pip包、Node.js的npm包、Docker镜像也必须定期更新它们往往是更大的漏洞来源。可以使用lynis这样的开源安全审计工具进行定期扫描它能给出非常详细的安全加固建议。sudo lynis audit system4.4 文件完整性监控与日志审计攻击者入侵后往往会篡改系统文件或留下后门。文件完整性监控FIM可以帮助你发现这些异常变化。AIDE (Advanced Intrusion Detection Environment)一个经典的主机级入侵检测系统。它首先为关键文件如/bin/sbin/etc/usr建立一个“数据库”记录文件的哈希值、权限等之后定期扫描并与数据库对比报告任何变更。sudo apt install aide sudo aideinit sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db # 定期运行检查 sudo aide --check集中化日志将服务器上的所有重要日志/var/log/auth.log/var/log/nginx/access.log 应用日志等实时收集到一个独立的、安全的日志服务器如ELK Stack或Graylog。这样即使服务器被攻破攻击者也无法抹除他们的行为记录为事后溯源提供依据。实操心得安全是一个持续的过程不是一劳永逸的设置。我习惯在每台服务器初始化后运行一遍加固脚本Ansible/Puppet并设置每周一次的安全扫描和日志审计任务。最重要的是保持“敬畏之心”默认一切外部输入都是恶意的内部网络也不是完全可信的。每一次服务的变更都要同步考虑其安全配置的更新。
