1. 先想清楚Linux加固到底在防什么每次有人讓我?guī)兔匆谎鄯?wù)器安全性我第一句話都不是問裝了什么東西而是反問一句你希望這臺機器被攻破之后損失上限是多少這個問題聽起來很虛但恰恰決定了加固方案的邊界。很多教程上來就讓你改SSH端口、關(guān)root登錄、裝Fail2ban照做一遍感覺挺踏實實際上只擋住了最外圍的“隨手掃描流量”真正有目標(biāo)的攻擊者連腰都沒彎。Linux系統(tǒng)安全加固本質(zhì)上是做兩件事收縮攻擊面增加攻擊成本。攻擊面指的是這臺機器對外暴露的所有入口——開放端口、運行的服務(wù)、可登錄的賬戶、可執(zhí)行的文件、可被篡改的配置。攻擊成本則是攻擊者拿到權(quán)限之后還要花多大精力才能穩(wěn)住腳跟、擴大戰(zhàn)果。我見過不少團隊把精力全花在第一件事上結(jié)果一臺機器被人種了后門因為文件權(quán)限太松散任何用戶都能往啟動目錄里丟東西加固做了等于沒做。這篇文章是系統(tǒng)安全加固系列的第一篇聚焦Linux環(huán)境。我會按我自己在生產(chǎn)環(huán)境里實際操作的順序來講先收斂賬戶和登錄入口再壓SSH風(fēng)險面然后調(diào)內(nèi)核參數(shù)和文件系統(tǒng)權(quán)限最后補上審計和監(jiān)控。每一節(jié)都會說清楚這么做的原因以及哪些環(huán)節(jié)容易踩坑。內(nèi)容偏實戰(zhàn)適合剛接手服務(wù)器運維的開發(fā)者也適合想系統(tǒng)梳理安全基線的人。我現(xiàn)在所在的團隊長期維護幾十臺Linux節(jié)點有云主機也有物理機發(fā)行版以 CentOS 和 Ubuntu 為主。下面所有配置都是這兩類系統(tǒng)上驗證過的Debian 系和 RHEL 系的主要差異我會單獨標(biāo)注其他發(fā)行版參考思路即可。2. 賬戶與登錄入口的收斂刪掉不用的門比把門鎖換得更高級更重要2.1 從賬戶清單開始我接手任何一臺機器第一件事永遠(yuǎn)是跑cat /etc/passwd和cat /etc/shadow把每一行都過一遍。這一步非?；A(chǔ)但很多人從來沒有認(rèn)真看過自己機器上到底有多少個賬戶。默認(rèn)安裝的Linux系統(tǒng)會帶出一批系統(tǒng)賬戶比如 daemon、bin、lp、mail、nobody 這些它們多數(shù)是歷史遺留沒有登錄Shell也沒有實際用途但留著它們沒有任何好處——每個賬戶都是一個潛在的身份載體。生產(chǎn)環(huán)境里更常見的問題是自己創(chuàng)建的賬戶冗余。比如項目早期測試時建的臨時賬號或者某個同事離職之后沒人清理的舊賬號甚至還有直接給應(yīng)用創(chuàng)建了超級用戶權(quán)限賬戶的情況。我的建議是每臺機器上可交互登錄的賬戶控制在個位數(shù)最好就是兩三個管理員再加一個專用的部署賬戶。其他一律刪除或者鎖定。檢查賬戶的時候重點看三列是否有可用的Shell/bin/bash、/bin/sh這類是否在 shadow 文件里有密碼哈希以及 UID 是否為 0。任何 UID 為 0 的非 root 賬戶都是極其危險的信號等于直接給了另一個超級用戶權(quán)限。我見過某臺機器上有個叫 sync 的老賬戶 UID 是 0一查是很多年以前有人圖方便直接改的這就是典型的隱藏風(fēng)險。2.2 清理和鎖定的正確姿勢清理賬戶不是直接userdel -r就完事。我的操作順序是先鎖定、再觀察、最后刪除。因為有些賬戶雖然在 passwd 里存在但可能被某個啟動腳本或者 cron 任務(wù)引用直接刪掉會導(dǎo)致服務(wù)起不來。鎖定命令有兩種passwd -l username和usermod -L username效果類似都是在 shadow 文件的密碼字段前加個感嘆號讓密碼驗證永遠(yuǎn)失敗。但注意這只禁止了密碼登錄如果賬戶配置了SSH密鑰依然可以登錄。所以更穩(wěn)妥的做法是把 Shell 也換掉usermod -s /sbin/nologin username這樣即使有人拿著這個賬戶的密鑰來登錄也會直接被拒絕分配Shell。對于已經(jīng)確定廢棄的賬戶等觀察一兩周沒有服務(wù)報錯之后再執(zhí)行userdel -r username連同家目錄一起清掉。還有一個細(xì)節(jié)容易被忽略檢查/etc/sudoers或者/etc/sudoers.d/目錄下的文件。很多時候賬戶是清理了但 sudo 授權(quán)條目還留著萬一 UID 被復(fù)用新賬戶自動繼承管理員權(quán)限。我習(xí)慣是清理賬戶的同時把對應(yīng)的 sudo 條目一并刪掉并且每年做一次授權(quán)清單復(fù)核。2.3 root 賬戶的處理思路root 該不該直接禁用這是安全加固里爭議最多的話題之一。我的觀點是root 賬戶不應(yīng)該被刪但應(yīng)該讓它無法直接被登錄所有管理操作通過 sudo 來執(zhí)行。原因是 root 一旦被設(shè)置為不可登錄攻擊者就算拿下了某個普通賬戶也還需要再攻破 sudo 的密碼驗證多了一層阻力。具體配置在后面SSH部分會詳細(xì)講這里先說明一個容易踩的坑不要隨手passwd -l root。很多教程這么教但如果你用的是某些云平臺的鏡像系統(tǒng)里根本沒有其他可用的 sudo 用戶鎖掉 root 之后你可能連機器都進不去。正確順序是先創(chuàng)建一個具備 sudo 權(quán)限的管理賬戶測試能正常登錄再處理 root 的登錄限制。3. SSH 加固攻擊者最常敲的窗口值得花一半精力去守3.1 從密鑰登錄和禁用密碼開始SSH 是幾乎所有Linux服務(wù)器最常被掃描的入口。默認(rèn)的 22 端口配合密碼認(rèn)證每天都會被互聯(lián)網(wǎng)上的掃描器嘗試成千上萬次。我見過最夸張的一臺機器/var/log/secure里一天刷了十幾萬條失敗登錄記錄全是來自各種僵尸網(wǎng)絡(luò)的 SSH 爆破。加固第一步永遠(yuǎn)是更換認(rèn)證方式禁用密碼登錄只允許密鑰認(rèn)證。這一步做完暴力破解基本就斷了路因為攻擊者沒有你的私鑰再怎么試密碼也無濟于事。操作前必須確認(rèn)所有管理員已經(jīng)生成并配置好了自己的公鑰。生成密鑰推薦用 Ed25519 算法而不是老舊的 RSAssh-keygen -t ed25519 -a 100 -C your_identifier-a 100指定 KDF 迭代次數(shù)默認(rèn)值偏小適當(dāng)調(diào)高可以延緩私鑰被暴力猜測的速度。公鑰放到服務(wù)器的~/.ssh/authorized_keys之后記得檢查文件權(quán)限chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys權(quán)限不對的話sshd 會直接忽略這個文件導(dǎo)致密鑰登錄失敗反而是個隱藏的坑。確認(rèn)所有管理員都能用密鑰登錄之后再修改 sshd_configPasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM no這里有個細(xì)節(jié)ChallengeResponseAuthentication是老的鍵盤交互式認(rèn)證開關(guān)很多時候以為關(guān)了密碼登錄但 PAM 模塊還會允許空密碼或簡單密碼尤其是 Ubuntu 上常見。我建議直接禁掉UsePAM不過要注意這個選項會影響到某些依賴 PAM 做二次認(rèn)證的場景如果機器上有特殊需求至少保持ChallengeResponseAuthentication no。改完配置后sshd -t systemctl reload sshdsshd -t是語法自檢這條命令不通過就絕對不能 reload不然你可能發(fā)現(xiàn)自己被鎖在外面。另外reload 不會斷開已建立的連接所以理論上不會把自己踢掉線但為了保險我建議測試新連接之前先開啟第二個SSH會話保持一個兜底通道。3.2 改端口到底有沒有用把 SSH 端口從 22 改成別的比如 2222、10022很多人覺得這是純粹的心理安慰。我的評價是它治標(biāo)不治本但確實是低成本降低掃描噪音的有效手段。互聯(lián)網(wǎng)上的自動掃描器主要針對默認(rèn)端口改了端口大量無差別掃描就會繞開你。但必須清醒認(rèn)識到有針對性的攻擊者可以快速掃描端口找到 SSH 服務(wù)。所以改端口只能作為輔助手段不能替代密鑰認(rèn)證和后續(xù)的訪問控制。改的方式很簡單Port 10022建議選擇一個不常見的端口范圍在 1024 到 65535 之間。改完別忘了更新防火墻放行規(guī)則否則自己先被擋在外面。另外如果機器上跑了 SELinux還需要同步調(diào)整端口標(biāo)簽semanage port -a -t ssh_port_t -p tcp 10022這個細(xì)節(jié)很容易漏掉很多 CentOS 用戶改了端口死活連不上查半天才發(fā)現(xiàn)是 SELinux 攔截。3.3 用 AllowUsers 和 MaxAuthTries 壓縮入口SSH 還有一個很重要的配置是限制允許登錄的用戶名單和認(rèn)證嘗試次數(shù)。AllowUsers的效果是白名單機制只有名單里的賬戶才能嘗試登錄名單之外的直接拒絕連密碼驗證環(huán)節(jié)都不會進入。我用一個專門的部署賬戶為例AllowUsers deploy admin1 admin2這樣配置之后即使系統(tǒng)里還有殘余的弱密碼賬戶攻擊者也沒辦法從SSH這個入口去試。MaxAuthTries控制的是每次連接允許的認(rèn)證嘗試次數(shù)默認(rèn)值是 6有點偏大。我一般壓到 3MaxAuthTries 3 LoginGraceTime 30LoginGraceTime是登錄超時時間超過30秒沒完成認(rèn)證就斷開連接。這兩個參數(shù)組合起來配合密鑰認(rèn)證基本把SSH爆破的空間壓縮到了很小。注意AllowUsers配置只能匹配用戶名或者用戶來源IP的格式。如果管理員經(jīng)常從動態(tài) IP 登錄不要在這里綁得太死否則容易把自己鎖在門外。我建議在 AllowUsers 里只控制用戶名把來源 IP 的限制交給防火墻去做。3.4 關(guān)于 sshd_config 的權(quán)限和歸屬有一件事很多人都沒注意到/etc/ssh/sshd_config這個文件本身如果權(quán)限過于寬松任何能寫入的用戶都可以給 sshd 偷偷加配置比如插一個危險的端口轉(zhuǎn)發(fā)或者放行某個惡意賬戶。所以安裝完系統(tǒng)之后我建議檢查一下ls -l /etc/ssh/sshd_config確認(rèn)歸屬是 root:root權(quán)限為 644 或更嚴(yán)格。/etc/ssh/目錄下的主機密鑰文件更敏感ssh_host_ed25519_key這種私鑰文件權(quán)限應(yīng)該是 600一旦泄露攻擊者可以用它來偽裝你的服務(wù)器發(fā)起中間人攻擊。算法層面的調(diào)整也值得做。一些老版本系統(tǒng)還允許ssh-dss和ssh-rsa簽名算法這兩種都已經(jīng)不安全了建議顯式禁用KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512 HostKeyAlgorithms sk-ssh-ed25519openssh.com,ssh-ed25519 PubkeyAcceptedAlgorithms ssh-ed25519 Ciphers chacha20-poly1305openssh.com,aes256-gcmopenssh.com,aes128-gcmopenssh.com配置完之后同樣要sshd -t檢查。這里提醒一句老版本的 OpenSSH7.0 以下可能不認(rèn)識這些新算法名升級 OpenSSH 之前不要貿(mào)然套用否則會出現(xiàn)所有客戶端都連不上的局面。4. 內(nèi)核參數(shù)與網(wǎng)絡(luò)棧讓惡意數(shù)據(jù)包連敲門的機會都少了4.1 通過 sysctl 收緊網(wǎng)絡(luò)行為Linux 內(nèi)核的網(wǎng)絡(luò)協(xié)議棧提供了很多可調(diào)參數(shù)其中一部分和系統(tǒng)安全息息相關(guān)。我平時會專門整理一批 sysctl 參數(shù)作為基線統(tǒng)一分發(fā)到所有服務(wù)器上。比較核心的有這么幾個net.ipv4.ip_forward 0 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.all.send_redirects 0 net.ipv4.conf.all.accept_source_route 0 net.ipv4.tcp_syncookies 1 net.ipv4.icmp_echo_ignore_broadcasts 1 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.all.log_martians 1逐個解釋一下。accept_redirects說的是是否接受ICMP重定向報文。重定向是路由器用來告訴主機“你走這條路更近”的機制但對于服務(wù)器來說基本用不上反而可能被攻擊者用來篡改路由表把流量引到惡意設(shè)備上。關(guān)掉沒毛病。accept_source_route是 IPv4 源路由選項攻擊者可以用它指定數(shù)據(jù)包的傳輸路徑從而繞過防火墻檢測?，F(xiàn)在的網(wǎng)絡(luò)環(huán)境里源路由幾乎沒有合法用途直接關(guān)閉。tcp_syncookies是 SYN Cookie 機制當(dāng) SYN 隊列被占滿時通過構(gòu)造特殊序列號的響應(yīng)包來驗證連接合法性這是抵御 SYN Flood 攻擊的有效武器。默認(rèn)值可能是 0務(wù)必改成 1。rp_filter是反向路徑過濾啟用后內(nèi)核會檢查數(shù)據(jù)包進來的接口是否與路由表一致不一致就丟棄。這是防 IP 地址偽造的重要手段。注意不要和net.ipv4.conf.all.rp_filter混淆all的值是邏輯或關(guān)系必須確保所有網(wǎng)卡的rp_filter都為 1。寫入配置的方式是放在/etc/sysctl.d/99-security.conf里然后執(zhí)行sysctl --system或sysctl -p生效。建議用獨立文件而不是直接改/etc/sysctl.conf后續(xù)哪個參數(shù)出了問題方便單獨排查和回滾。驗證方式sysctl net.ipv4.tcp_syncookies4.2 關(guān)鍵網(wǎng)絡(luò)層限制配合防火墻我見過一些團隊調(diào)了很多內(nèi)核參數(shù)卻忘記檢查防火墻規(guī)則結(jié)果服務(wù)器對外開放了十幾個端口攻擊面比預(yù)想的大得多。內(nèi)核參數(shù)只能加固協(xié)議棧的行為但端口是否對外可訪問是防火墻決定的事。我這里說一個“最小開放端口”的原則一臺普通的Web服務(wù)器對外只需要開放 80HTTP和 443HTTPSSSH 端口只對管理網(wǎng)段開放。其余端口一律拒絕。用 nftables 或者 iptables 實現(xiàn)。下面是 nftables 的一個最小示例nft add table inet filter nft add chain inet filter input { type filter hook input priority 0; policy drop; } nft add rule inet filter input ct state established,related accept nft add rule inet filter input iif lo accept nft add rule inet filter input tcp dport 80 accept nft add rule inet filter input tcp dport 443 accept nft add rule inet filter input tcp dport 10022 ip saddr 192.168.10.0/24 accept注意策略是默認(rèn)丟棄然后逐條放行。這個順序千萬不要寫反先放行再丟棄會導(dǎo)致規(guī)則混亂。ct state established,related accept這一條很重要它保證已經(jīng)建立的連接不會被誤傷否則你的出站響應(yīng)對應(yīng)包會被自己防火墻攔掉表現(xiàn)為“能出去不能回來”。刪除端口前先確認(rèn)服務(wù)確實沒在監(jiān)聽。判斷監(jiān)聽狀態(tài)ss -tlnp這個命令列出所有正在監(jiān)聽的TCP端口和對應(yīng)進程比老的netstat -anp更簡潔也是排查端口遺漏的首選工具。4.3 AIDE與文件完整性基線從網(wǎng)絡(luò)層轉(zhuǎn)向文件層網(wǎng)絡(luò)和登錄入口收緊了攻擊者的直接入口變少但我們還要防“已經(jīng)被突破之后”的情況。Linux 文件繁多攻擊者留下的后門往往藏在某些關(guān)鍵系統(tǒng)文件里比如把/usr/bin/systemctl替換成帶后門的版本或者往/etc/ld.so.preload里塞惡意動態(tài)庫。這類篡改用肉眼看很難發(fā)現(xiàn)必須依賴文件完整性校驗工具。AIDEAdvanced Intrusion Detection Environment是我常用的工具。它會在系統(tǒng)干凈狀態(tài)時采集文件哈希、權(quán)限、屬主、文件大小等信息生成基線數(shù)據(jù)庫。之后定期掃描對比一旦發(fā)現(xiàn)文件發(fā)生變化就告警。初始化過程aideinit默認(rèn)數(shù)據(jù)庫路徑是/var/lib/aide/aide.db.gz。生產(chǎn)環(huán)境建議把數(shù)據(jù)庫存放路徑改到獨立磁盤分區(qū)甚至遠(yuǎn)程存儲否則攻擊者同時篡改了文件又更新了數(shù)據(jù)庫校驗就形同虛設(shè)。我見過一臺機器被人改了/bin/ls順手也把 AIDE 數(shù)據(jù)庫更新了等發(fā)現(xiàn)時已經(jīng)過去了幾個月。AIDE 的配置文件中有一個重要選項是排除目錄比如/proc、/sys、/dev這些動態(tài)目錄不能納入校驗否則每次掃描都會有大量噪音。另外/var/log/和/tmp/這類內(nèi)容頻繁變化的目錄也建議排除聚焦于靜態(tài)文件更有效。校驗頻率方面我是在 cron 里配置每天凌晨執(zhí)行一次0 3 * * * /usr/bin/aide --check /var/log/aide/aide.log 21增量模式-C可以在每日全量檢查之間快速對比小范圍變化有異常就立即查。這個工具本身不防篡改但它提供的告警能力讓排查時間從幾個月縮短到幾小時。5. 文件系統(tǒng)與關(guān)鍵目錄權(quán)限松一分風(fēng)險大十分5.1 掛載參數(shù)中的安全取舍文件系統(tǒng)層面的加固容易被忽略因為平時很少有人仔細(xì)看/etc/fstab。但攻擊者一旦拿到受限權(quán)限能做的破壞很大程度上取決于文件系統(tǒng)掛載時給了多少自由度。不少發(fā)行版默認(rèn)把某些目錄掛載得過于寬松。拿 Linux 最常用的 ext4 和 XFS 來說掛載時可以指定一些安全相關(guān)的選項。比如/tmp目錄很多服務(wù)都會往這里寫臨時文件但/tmp本身不應(yīng)該是可執(zhí)行程序的存放地。攻擊者可以往/tmp丟一個 payload然后誘導(dǎo)某個高權(quán)限進程去執(zhí)行這是很經(jīng)典的提權(quán)路徑。我建議在 fstab 里這樣掛載/tmp/tmp ext4 defaults,noexec,nosuid,nodev 0 0noexec禁止執(zhí)行二進制文件nosuid禁止SUID位生效nodev禁止設(shè)備文件。這三個選項疊加起來能在很大程度上削弱臨時目錄的攻擊價值。這里有個坑有些程序的安裝包需要從/tmp跑安裝腳本掛上noexec之后會報權(quán)限錯誤。遇到這種情況要么臨時mount -o remount,exec /tmp再裝要么把安裝包換個路徑。/home或者專門的數(shù)據(jù)目錄也建議加上nodev,nosuid。這幾個選項不會影響正常讀寫只限制特殊文件類型的創(chuàng)建和訪問性價比極高。查看當(dāng)前掛載參數(shù)mount | grep /tmp如果之前沒有指定可以用mount -o remount,noexec,nosuid,nodev /tmp臨時改但要想永久生效必須改 fstab。5.2 關(guān)鍵文件與SUID的基線管理Linux 系統(tǒng)里 SUID 是個很有意思的機制。它允許普通用戶以文件屬主的身份執(zhí)行某個程序典型例子是/usr/bin/passwd。這個機制本身不是壞事但攻擊者可以用它來做文章。一個自定義的 SUID 二進制文件可以讓普通用戶直接獲得 root 的權(quán)限執(zhí)行某個操作甚至直接派生一個 root Shell。所以每隔一段時間我會掃描一遍全盤的 SUID 文件find / -perm -4000 -type f 2/dev/null正常情況下輸出的文件應(yīng)該是一個可預(yù)期的清單比如/bin/mount、/usr/bin/su、/usr/bin/passwd這些。如果清單里出現(xiàn)了奇怪的文件路徑或者新增了不明來歷的 SUID 文件就要高度警惕了。刪除 SUID 位用chmod u-s /path/to/file另一個需要關(guān)注的是關(guān)鍵文件的可寫權(quán)限。我建議檢查一下系統(tǒng)里有哪些重要目錄被賦予了other用戶的寫權(quán)限find / -xdev -type d -perm -0002 -print正常系統(tǒng)里輸出應(yīng)該很少最多是/tmp和/var/tmp這類明確需要共享寫入的目錄。如果發(fā)現(xiàn)/etc、/usr、/var下的目錄有全局寫權(quán)限那基本屬于配置事故攻擊者可以往這些目錄里植入惡意腳本靜默等待觸發(fā)。/etc/shadow的權(quán)限也值得單獨檢查正常應(yīng)該是 000 或 600。有些老系統(tǒng)為了兼容某些工具把 shadow 設(shè)成 644等于把密碼哈希撒得滿地都是。密碼哈希一旦被拿走去跑字典攻擊就是時間問題了。5.3 鎖定關(guān)鍵的“隱藏”開關(guān)最后一個容易被忽視的是cron目錄和啟動腳本。攻擊者特別喜歡把反彈 Shell 腳本掛在/etc/cron.d/或者寫入/etc/crontab因為這種方式即使系統(tǒng)重啟也能保持持久化。我建議定期檢查這幾個位置ls -la /etc/cron.d/ cat /etc/crontab同時留意/etc/systemd/system/下有沒有新增的.service文件尤其是名字故意偽裝成系統(tǒng)服務(wù)的那種。檢測方法就是不定期對比目錄內(nèi)容的快照或者用前面提到的 AIDE 對這些路徑做重點監(jiān)控。補充一個實用習(xí)慣所有新部署的服務(wù)都應(yīng)該用獨立的低權(quán)限賬戶運行不要用 root 直接跑。比如 Nginx、MySQL、Redis它們在各自的發(fā)行版包里都有對應(yīng)的專用賬戶檢查一下確認(rèn)沒有被改成 root 就行。6. 審計與監(jiān)控加固不是一錘子買賣6.1 auditd讓每個敏感操作都留下記錄安全加固做到這里攻擊面已經(jīng)被大幅收縮。但沒有任何一套配置是永久有效的攻擊者在想盡辦法繞過規(guī)則。這時候最需要的是審計能力——系統(tǒng)里有沒有發(fā)生不該發(fā)生的動作如果有能不能回溯到具體的人和命令。Linux 自帶的 auditd 是目前最可靠的內(nèi)核級審計方案。它基于內(nèi)核的審計框架能記錄文件訪問、系統(tǒng)調(diào)用、登錄事件、賬戶變更等關(guān)鍵操作。安裝和啟動非常簡單yum install audit systemctl enable auditd systemctl start auditd重點在規(guī)則配置。以監(jiān)控/etc/passwd、/etc/shadow、/etc/sshd_config這幾個核心文件為例auditctl -w /etc/passwd -p wa -k passwd_watch auditctl -w /etc/shadow -p wa -k shadow_watch auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_watch-w指定被監(jiān)控文件-p wa表示記錄寫入和修改屬性操作-k是為規(guī)則打的標(biāo)簽方便后期篩選日志。這些規(guī)則只是臨時生效要把它們持久化應(yīng)該寫進/etc/audit/rules.d/audit.rules或者使用auditctl -R導(dǎo)入。查看審計日志有三種方式ausearch按條件查詢aureport生成統(tǒng)計報告/var/log/audit/audit.log直接翻原始日志。排查時我常用ausearch -k passwd_watch -ts today這條命令列出今天所有針對 passwd 文件的寫操作包括發(fā)起進程、用戶ID、命令路徑定位問題非常高效。審計規(guī)則別上來就一把梭全監(jiān)控那是給自己制造噪音。我建議分階段先覆蓋登錄和關(guān)鍵賬戶文件跑一段時間觀察量級再逐步擴大到二進制目錄和配置目錄。6.2 登錄安全從 PAM 配置到賬戶鎖定策略PAMPluggable Authentication Modules是 Linux 系統(tǒng)認(rèn)證框架的核心幾乎所有的認(rèn)證入口——SSH、su、sudo、圖形登錄——最終都會經(jīng)過它。PAM 配置里有兩個常用的安全模塊值得加強pam_tally2和pam_faillock。它們的作用是賬戶鎖定連續(xù)多次認(rèn)證失敗后暫時鎖定賬戶防止暴力破解。Ubuntu 上我用pam_faillock比較多配置在/etc/pam.d/common-auth和/etc/pam.d/common-account里auth required pam_faillock.so preauth silent audit deny4 unlock_time900 auth required pam_faillock.so authfail audit deny4 unlock_time900 account required pam_faillock.so含義是連續(xù)失敗4次鎖定15分鐘。不建議把閾值降得太低比如 2 次否則管理員自己輸錯幾次密碼就被鎖了運維事故比安全風(fēng)險更讓人頭疼。CentOS/RHEL 上的配置路徑稍有不同用的是/etc/pam.d/password-auth和/etc/pam.d/system-auth模塊名是pam_faillock也更常見。改 PAM 配置前一定要備份原始文件并且用pam-auth-update檢查語法一致性配置錯誤可能導(dǎo)致所有人都無法登錄。還有一個秘密被很多人忽略/etc/securetty。這個文件控制 root 允許從哪些終端登錄如果里面有不該出現(xiàn)的偽終端名稱等于給 root 登錄開了小門。建議只保留基本的控制臺條目其余刪掉。6.3 日志侵入檢測的簡單套路日志排查是所有安全監(jiān)控的基礎(chǔ)。但日志文件本身也可能被篡改所以有一件事必須在加固階段就做好讓日志及時轉(zhuǎn)走。最簡單的方式是配置 rsyslog 把關(guān)鍵日志轉(zhuǎn)發(fā)到集中的日志服務(wù)器或者至少同步到獨立的存儲位置。在/etc/rsyslog.conf里加一行*.* 192.168.10.10:514讓所有日志實時外送到日志收集節(jié)點。即使攻擊者清了本機日志集中平臺上的記錄依然存在。這是事后溯源的救命稻草強烈建議在生產(chǎn)環(huán)境落地。日常巡檢我一般看這幾類日志日志路徑關(guān)注內(nèi)容/var/log/secure 或 auth.log登錄成功/失敗、sudo 使用記錄/var/log/croncron 任務(wù)執(zhí)行是否有異常新條目/var/log/messages 或 syslog網(wǎng)絡(luò)、內(nèi)核、系統(tǒng)級報錯/var/log/audit/audit.log審計事件特別是有失敗和拒絕的事件圈出重點之后我習(xí)慣用一條命令快速過濾暴力破解嘗試grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -20列出嘗試次數(shù)最多的來源IP。這個數(shù)據(jù)不僅用于應(yīng)急也用來做防火墻的黑名單配置或者買云廠商的安全組策略參考。7. 工具推薦加固之后還要能持續(xù)看見風(fēng)險配置做完了但如果只是手動檢查一遍過了兩個月又回到原樣。我習(xí)慣在每臺機器上部署一套輕量級安全監(jiān)控工具把“事后發(fā)現(xiàn)”變成“實時預(yù)警”。第一梯隊的工具是 RKHunter 和 Chkrootkit專門用來檢測rootkit和后門。RKHunter 掃描已知惡意程序的特征碼對比系統(tǒng)二進制文件的哈希值檢查網(wǎng)絡(luò)端口異常綁定。我把它配置成每天執(zhí)行一次并輸出報告rkhunter --check --sk第一次運行時會因為系統(tǒng)文件屬主權(quán)限和其他因素產(chǎn)生告警需要根據(jù)實際情況生成白名單。這一步挺重要否則每天收到一堆誤報最后連告警都不看了。第二梯隊是 Osquery。它是 Facebook 開源的系統(tǒng)插樁工具把操作系統(tǒng)抽象成一張可以 SQL 查詢的表。比如我想查所有監(jiān)聽的端口SELECT * FROM listening_ports;或者查所有 UID 為 0 的用戶SELECT * FROM users WHERE uid 0;Osquery 的價值在于可以集中管理同時它可以把采集結(jié)果發(fā)送到集中平臺做規(guī)則檢測。對有一定基礎(chǔ)設(shè)施規(guī)模、又不想上重型的商業(yè)化安全工作臺的情況這個方案是性價比很高的中間選擇。另外還有一個方向是配置基線檢查工具像 OpenSCAP、Lynis。Lynis 是傻瓜式的好東西一條命令輸出系統(tǒng)安全狀況報告lynis audit system它會檢查系統(tǒng)更新狀態(tài)、文件權(quán)限、用戶配置、網(wǎng)絡(luò)設(shè)置、軟件漏洞等數(shù)百個項目然后給出一個 hardening index 和一個建議清單。雖然沒有實現(xiàn)自動化修復(fù)但作為持續(xù)巡檢的補充維度很有用。把這些工具全部配上之后加固體系才算完整登錄入口有強認(rèn)證網(wǎng)絡(luò)層有最小開放文件系統(tǒng)有權(quán)限約束文件變化有完整性校驗操作行為有審計日志風(fēng)險狀態(tài)有定期掃描。這條鏈路閉合了才能真正降低運營一臺Linux系統(tǒng)的安全焦慮。8. 我自己踩過的三個“加固陷阱”技術(shù)清單講完了我想單獨說說實際運維里最容易翻車的三個點因為每一步我都吃過虧。第一個坑是改 SSH 配置時沒有留兜底通道。有一年我在一臺離線的物理機上調(diào)整 sshd_config把PasswordAuthentication設(shè)成 no然后執(zhí)行了 reload隨后發(fā)現(xiàn)自己當(dāng)前的連接因為配置改變被踢了密鑰認(rèn)證又因為 localhost 主機的密鑰權(quán)限問題失敗。結(jié)果是我人就在機房但機器的SSH理論上已經(jīng)把我放逐了最后只能通過帶外管理口登錄修復(fù)。現(xiàn)在我的習(xí)慣是改任何 SSH 配置之前先screen開一個會話然后在里面sudo su到另一個用戶或者干脆同時在機器上開兩個連接測試。對待改動大型服務(wù)配置永遠(yuǎn)默認(rèn)會有問題都需要先給自己留一條后路。第二個坑是防火墻規(guī)則順序?qū)懛?。?dāng)時在給一臺生產(chǎn)數(shù)據(jù)庫服務(wù)器做加固我要求默認(rèn)策略 drop但我在規(guī)則里先寫了一堆 drop最后才寫 accept 放行導(dǎo)致業(yè)務(wù)連接被自己防火墻攔截。排查了半天發(fā)現(xiàn)是對外端口沒有放行而連接本地時因為回環(huán)接口放行了所以本地測試一切正常只有外部訪問異常。這個教訓(xùn)讓我養(yǎng)成了“寫完防火墻規(guī)則第一件事用另一臺機器驗證外部訪問”的習(xí)慣。第三個坑和 AIDE 有關(guān)。我很早就部署了 AIDE但數(shù)據(jù)庫存在了本機結(jié)果在一次真實的入侵事件里攻擊者不僅偽造了幾個二進制還順手更新了 AIDE 數(shù)據(jù)庫。等我們發(fā)現(xiàn)文件不對勁時重新比對已經(jīng)無從談起。從那以后我把 AIDE 數(shù)據(jù)庫定期同步到獨立的備份存儲且每次檢查之后馬上把新基線外傳避免“既當(dāng)運動員又當(dāng)裁判”的局面。這三件事的共性其實都是同一個安全加固不是配置下發(fā)了就萬事大吉它需要持續(xù)的維護、冗余的安全通道和對策失敗時的預(yù)案。這也是我寫系統(tǒng)安全加固系列的一個初衷——不是給一份抄完就忘的配置單而是希望每個接過服務(wù)器運維的人都建立起一套自己的安全檢查節(jié)奏和危機應(yīng)對意識。這一篇是 Linux 環(huán)境的做法之后的系列里我會繼續(xù)順著應(yīng)用層、容器層和云上架構(gòu)的加固思路往下走。