干服務(wù)器運(yùn)維這行越久越明白一件事你永遠(yuǎn)不知道下一分鐘攻擊會(huì)從哪個(gè)方向來。我接手過一臺(tái)被挖礦腳本占滿CPU的Web服務(wù)器半夜替電商客戶處理過CC攻擊打到帶寬爆掉的告警也親眼見過同事因?yàn)橐粭l文件上傳漏洞整個(gè)后臺(tái)被重裝成別人的“肉雞”。服務(wù)器攻擊與防御這件事表面上是工具和規(guī)則的對(duì)抗本質(zhì)上是對(duì)攻擊者思路的還原——你只有知道對(duì)方怎么進(jìn)來的才知道該把門鎖在哪里。這篇文章不打算從教科書定義講起而是結(jié)合我自己在服務(wù)器運(yùn)維、安全加固和應(yīng)急排查中踩過的坑把最常見的攻擊手法、防御落地步驟、排查實(shí)錄和避坑清單一次說清楚。適合剛接觸服務(wù)器的新手也適合做運(yùn)維和開發(fā)的朋友對(duì)照著查漏補(bǔ)缺。1. 先從攻擊面說起一臺(tái)服務(wù)器到底哪里最容易被盯上很多人對(duì)攻擊的理解是“黑客用工具掃一下端口然后黑進(jìn)來”真實(shí)情況復(fù)雜得多。一臺(tái)服務(wù)器就像一個(gè)房子門、窗、煙囪、空調(diào)外機(jī)全是入口攻擊者只挑最容易撬的那個(gè)。所以做防御的第一步不是急著裝一堆安全軟件而是先搞清楚自己門前到底有什么“可燃物”。1.1 從一次半夜告警看攻擊入口去年底有一次凌晨三點(diǎn)監(jiān)控平臺(tái)突然報(bào)警一臺(tái)承載官網(wǎng)的ECS實(shí)例帶寬跑滿了。登錄上去一看公網(wǎng)入方向流量接近2Gbps但CPU和內(nèi)存占用都不高。第一反應(yīng)是DDoS流量攻擊可仔細(xì)看防火墻日志流量并不是單一來源而是幾十個(gè)IP輪番發(fā)起大量GET請(qǐng)求每個(gè)請(qǐng)求都帶著不同的隨機(jī)UA頭。這實(shí)際上是CC攻擊——通過大量應(yīng)用層請(qǐng)求耗盡Web服務(wù)的連接池和帶寬。為什么會(huì)有這種攻擊很多時(shí)候不是有人專門針對(duì)你而是你的服務(wù)器被掃描工具發(fā)現(xiàn)后成了批量攻擊列表里的一個(gè)節(jié)點(diǎn)。服務(wù)器上開放的端口越少、暴露的服務(wù)越少被盯上的概率就越低。所以我現(xiàn)在的項(xiàng)目中第一件事永遠(yuǎn)是資產(chǎn)清點(diǎn)這臺(tái)服務(wù)器上跑了哪些服務(wù)監(jiān)聽哪些端口哪些端口是必須對(duì)公網(wǎng)開放的哪些其實(shí)只在內(nèi)網(wǎng)用。提示你永遠(yuǎn)不知道你的服務(wù)器IP被掃描了多少次。只要公網(wǎng)可達(dá)掃描器每幾分鐘就會(huì)來一輪這是常態(tài)。1.2 端口、服務(wù)與資產(chǎn)清點(diǎn)的具體做法資產(chǎn)清點(diǎn)聽起來簡(jiǎn)單實(shí)際做起來需要耐心。我通常用下面的辦法用ss -tlnp或netstat -tlnp查看當(dāng)前監(jiān)聽的端口和對(duì)應(yīng)的進(jìn)程這一步是摸清家底。對(duì)照業(yè)務(wù)清單逐一確認(rèn)每個(gè)端口是否必須對(duì)外開放不認(rèn)識(shí)的進(jìn)程要查清來源。對(duì)公網(wǎng)開放的端口做服務(wù)版本登記比如 Nginx 1.20、OpenSSH 8.2、MySQL 5.7版本號(hào)是后續(xù)判斷漏洞影響范圍的關(guān)鍵。記錄域名、證書、CDN、回源IP之間的關(guān)系防止出現(xiàn)“CDN背后裸奔”的情況。有一次我排查一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器發(fā)現(xiàn)3306端口對(duì)公網(wǎng)開放。一問才知道是當(dāng)初為了方便本地調(diào)試直接在安全組里加了0.0.0.0/0放行規(guī)則。這種端口暴露在公網(wǎng)上等同于把金庫(kù)大門敞開著任何人都能拿工具嘗試暴力破解。1.3 攻擊面梳理的隱患盤點(diǎn)攻擊面不光是端口還包括幾個(gè)容易被忽略的點(diǎn)默認(rèn)口令和弱口令。很多人覺得“密碼長(zhǎng)一點(diǎn)就安全”但像root/123456、admin/admin這種組合在暴力破解工具字典里排在最前面。管理后臺(tái)暴露在公網(wǎng)。比如 WordPress 后臺(tái)、Tomcat Manager、phpMyAdmin任何一個(gè)都可以成為突破口。敏感信息泄露。網(wǎng)頁(yè)源碼注釋、接口報(bào)錯(cuò)信息、備份文件.bak/.sql被直接放在web目錄下等于把地圖送給了攻擊者。第三方組件版本過舊。比如某個(gè)開源CMS用了老版本已知漏洞直接可查攻擊者根本不需要多高深的技術(shù)。把這些點(diǎn)記下來之后攻擊面才算真正清楚。接下來看具體攻擊手法時(shí)就有的放矢了。2. 常見攻擊手法與底層邏輯防御的前提是理解攻擊。我挑了幾個(gè)在真實(shí)業(yè)務(wù)中高頻出現(xiàn)的類型每個(gè)都結(jié)合我處理過的案例來講盡量不說空話。2.1 流量型攻擊DDoS與CC攻擊的典型特征DDoS和CC攻擊經(jīng)常被混為一談其實(shí)觸發(fā)層級(jí)完全不同。DDoS主要打網(wǎng)絡(luò)層和傳輸層比如SYN Flood、UDP Flood目的是把帶寬和交換機(jī)處理能力耗盡讓正常用戶連不上。CC攻擊打的是應(yīng)用層模擬真實(shí)用戶請(qǐng)求不停請(qǐng)求某個(gè)動(dòng)態(tài)接口或搜索接口把CPU、數(shù)據(jù)庫(kù)連接池打滿網(wǎng)站響應(yīng)變慢甚至直接502。我在處理一次CC攻擊時(shí)發(fā)現(xiàn)攻擊方只盯著一個(gè)URL重復(fù)請(qǐng)求這個(gè)URL是會(huì)員中心的查詢接口。當(dāng)時(shí)上游WAF沒有配頻控導(dǎo)致每個(gè)請(qǐng)求都正常轉(zhuǎn)發(fā)到后端數(shù)據(jù)庫(kù)連接瞬間被打穿。后面加了針對(duì)該接口的單IP每秒請(qǐng)求數(shù)限制同時(shí)在Nginx層做了隊(duì)列深度控制情況立刻緩解。注意CC攻擊比DDoS更隱蔽因?yàn)榱髁刻卣骱驼Ｓ脩艉芟窆饪磶捒床怀鰡栴}要看每個(gè)請(qǐng)求的頻次、UA分布、來源IP聚合度。2.2 文件上傳攻擊為什么總被低估文件上傳攻擊是我在Web安全項(xiàng)目里最常遇到的漏洞之一。基本原理是借助上傳功能攻擊者上傳一個(gè)包含惡意代碼的文件比如PHP一句話木馬、JSP后門如果服務(wù)器把文件解析執(zhí)行了攻擊者就拿到了WebShell相當(dāng)于在服務(wù)器里安了一個(gè)“遠(yuǎn)程遙控器”。真實(shí)的攻擊流程通常是這樣的攻擊者找到一個(gè)上傳點(diǎn)頭像上傳、附件上傳、導(dǎo)入功能上傳一個(gè)偽裝成圖片的腳本文件訪問這個(gè)文件路徑使腳本被解析執(zhí)行然后通過WebShell執(zhí)行系統(tǒng)命令。我去幫一個(gè)客戶排查時(shí)發(fā)現(xiàn)他們的上傳目錄里躺著一個(gè)名為avatar.jpg的文件后綴是jpg但文件頭尾被拼接了PHP代碼。原因就是上傳時(shí)只校驗(yàn)了Content-Type前端可控沒有校驗(yàn)文件真實(shí)內(nèi)容而且上傳目錄還開了腳本執(zhí)行權(quán)限。防御上我目前比較認(rèn)可的組合是白名單后綴校驗(yàn)加上MIME類型校驗(yàn)、文件重命名脫離可控路徑、上傳目錄禁止執(zhí)行腳本、文件存儲(chǔ)和Web解析目錄分離。這四個(gè)動(dòng)作做完大部分文件上傳繞過手段就失效了。2.3 SSRF攻擊內(nèi)網(wǎng)跳板是怎么打出來的SSRF服務(wù)端請(qǐng)求偽造是很多應(yīng)用層漏洞里比較特殊的一個(gè)。它利用的是服務(wù)器自身發(fā)起的請(qǐng)求讓服務(wù)器去訪問攻擊者指定的內(nèi)網(wǎng)或外部地址。由于請(qǐng)求是從服務(wù)器發(fā)出的很多防火墻規(guī)則會(huì)認(rèn)為這是“可信流量”于是攻擊者就能借服務(wù)器這個(gè)“跳板”探測(cè)內(nèi)網(wǎng)。最典型的場(chǎng)景是圖片處理功能用戶提交一個(gè)URL服務(wù)器去抓取圖片。如果這個(gè)功能沒有做域名白名單和IP限制攻擊者可以傳http://127.0.0.1:3306來探測(cè)本機(jī)數(shù)據(jù)庫(kù)端口甚至傳http://10.0.0.5/來掃描內(nèi)網(wǎng)其他主機(jī)。我遇到過一臺(tái)服務(wù)器通過這種漏洞被讀取了內(nèi)網(wǎng)云元數(shù)據(jù)接口從而拿到了臨時(shí)憑證。防御的核心不是簡(jiǎn)單屏蔽localhost而要限制請(qǐng)求目標(biāo)只允許訪問特定協(xié)議不留file協(xié)議、特定端口白名單、特定域名白名單并禁止302跳轉(zhuǎn)跟隨、禁止訪問內(nèi)網(wǎng)IP段。2.4 反序列化攻擊看起來沒事的接口最危險(xiǎn)反序列化攻擊在一線業(yè)務(wù)里不算高頻但一旦發(fā)生往往就是管理員權(quán)限級(jí)別的淪陷。很多開發(fā)對(duì)“序列化”不敏感覺得就是把對(duì)象變成字符串存起來但反序列化是把字符串恢復(fù)成對(duì)象的過程如果數(shù)據(jù)源不可信攻擊者就能構(gòu)造惡意內(nèi)容在恢復(fù)過程中觸發(fā)危險(xiǎn)方法。Java、PHP、Python都有對(duì)應(yīng)的反序列化利用鏈。比如Java里常見的攻擊點(diǎn)是把序列化后的對(duì)象直接交給ObjectInputStream.readObject()處理攻擊者構(gòu)造好某個(gè)存在漏洞的類讓服務(wù)器在反序列化時(shí)執(zhí)行命令。排查這類問題時(shí)我一般會(huì)重點(diǎn)看代碼里是否對(duì)反序列化數(shù)據(jù)做了簽名校驗(yàn)以及是否引入了容易被利用的組件庫(kù)。防御上最有效的方法是不接受不可信來源的反序列化數(shù)據(jù)如果必須接受使用白名單類過濾比如ObjectInputFilter或改成JSON等安全格式傳輸。這個(gè)問題最大的難點(diǎn)在于它不是“一眼就能看出來”的漏洞代碼審查時(shí)要留意所有接收二進(jìn)制數(shù)據(jù)的入口。2.5 注入類與WebShellXSS、SQL注入的防御思路XSS和SQL注入屬于老生常談但我不打算略過因?yàn)閷?shí)際項(xiàng)目里“換了馬甲”的注入依然很多。XSS的核心是用戶輸入被當(dāng)作頁(yè)面內(nèi)容輸出導(dǎo)致腳本在他人瀏覽器里執(zhí)行。SQL注入的核心是用戶輸入被拼進(jìn)SQL語(yǔ)句導(dǎo)致數(shù)據(jù)庫(kù)被拖走或篡改。兩者的共同點(diǎn)是對(duì)輸入過于信任。前幾年我審計(jì)過一個(gè)后臺(tái)登錄后的搜索框直接把參數(shù)拼到SQL里當(dāng)時(shí)用 OR 11 --一測(cè)試就出數(shù)據(jù)。后來整改時(shí)統(tǒng)一封裝了參數(shù)化查詢開始引入ORM約束。對(duì)于XSS主要還是輸出端的編碼轉(zhuǎn)義要到位前端框架自帶的防XSS機(jī)制不要隨意關(guān)閉。3. 防御體系落地方案從基線加固到縱深防御攻擊手法學(xué)完接下來就是動(dòng)手防。防御不能靠單點(diǎn)必須一層一層疊起來這也就是常說的縱深防御。3.1 系統(tǒng)層基線加固系統(tǒng)層的基礎(chǔ)打不牢上層做再多都白搭。我建議按下面的順序逐項(xiàng)落實(shí)禁用root遠(yuǎn)程登錄改用普通用戶加sudoSSH使用密鑰認(rèn)證。定期應(yīng)用系統(tǒng)更新和安全補(bǔ)丁關(guān)鍵漏洞要優(yōu)先修復(fù)。關(guān)閉不必要的系統(tǒng)服務(wù)用firewalld或iptables只放行必要端口。設(shè)置合理的文件權(quán)限web目錄的寫入權(quán)限盡量收窄。修改默認(rèn)端口或使用Fail2ban等工具對(duì)暴力破解做自動(dòng)封禁。我實(shí)際操作中會(huì)把SSH端口改到高位并開啟密鑰登錄雖然不能徹底防住掃描但能把自動(dòng)爆破的流量擋掉一大半。改端口不是安全手段只是減小暴露面真正的防線是密鑰和訪問來源限制。# 以CentOS/RHEL系為例允許指定IP段訪問SSH端口 firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.10.0.0/16 port port2222 protocoltcp accept firewall-cmd --permanent --remove-servicessh firewall-cmd --reload3.2 網(wǎng)絡(luò)層與接入層防御網(wǎng)絡(luò)層防御重點(diǎn)在入口也就是防火墻和安全組。這里有兩個(gè)容易踩的坑第一個(gè)是安全組規(guī)則配得過于寬松比如把某個(gè)端口對(duì)所有IP開放第二個(gè)是只關(guān)注入方向忽略了出方向服務(wù)器被入侵后向外發(fā)起的攻擊流量沒人管。我在給一個(gè)項(xiàng)目做加固時(shí)直接把出方向默認(rèn)拒絕只放行必要的DNS、HTTPS和軟件源端口。這樣即使WebShell執(zhí)行成功了攻擊者想連外網(wǎng)下載工具也會(huì)因?yàn)槌龇较虮幌拗贫≥^多。接入層方面有條件就上WAF配合IP黑白名單、地區(qū)封禁、頻率限制和CC防護(hù)規(guī)則。如果預(yù)算有限先用Nginx層的限速和訪問控制頂上# 限制同一IP每分鐘請(qǐng)求數(shù)超過后返回503 limit_req_zone $binary_remote_addr zonereq_one:10m rate30r/m; server { listen 80; server_name example.com; location /api/ { limit_req zonereq_one burst20 nodelay; proxy_pass http://backend; } }3.3 應(yīng)用層控制輸入、輸出、權(quán)限三板斧到應(yīng)用層防御動(dòng)作要落到代碼和配置里主要盯三件事輸入校驗(yàn)所有外部參數(shù)做合法性校驗(yàn)包括長(zhǎng)度、類型、取值范圍。能走白名單就不要用黑名單。輸出編碼動(dòng)態(tài)內(nèi)容輸出到頁(yè)面時(shí)做好HTML實(shí)體編碼防止XSS拼接SQL時(shí)全部參數(shù)化。權(quán)限控制接口遵循最小權(quán)限同一個(gè)接口不能既是普通用戶入口又是管理員入口。文件讀寫權(quán)限也要注意。我見過有項(xiàng)目把/data/upload配成了777權(quán)限導(dǎo)致WebShell上傳后還能被修改執(zhí)行。我通常會(huì)把上傳目錄的owner固定為某個(gè)低權(quán)限用戶并禁止腳本解析。3.4 運(yùn)維層監(jiān)控、日志與備份監(jiān)控和日志是防御體系中偏“事后”的環(huán)節(jié)但很多攻擊在爆發(fā)之前都是有前兆的。我推薦的監(jiān)控指標(biāo)包括CPU和內(nèi)存使用率、帶寬出入方向、數(shù)據(jù)庫(kù)慢查詢、Web日志中4xx/5xx狀態(tài)碼占比、登錄失敗次數(shù)、關(guān)鍵文件完整性。日志采集上我習(xí)慣用“三份日志”方案操作系統(tǒng)日志、Web訪問日志、應(yīng)用日志分別落盤和集中存儲(chǔ)。Web訪問日志至少保留90天建議每日做日志切割防止單文件過大導(dǎo)致問題。備份則要保證“異地多版本”至少有一個(gè)ecph存到對(duì)象存儲(chǔ)里不能和服務(wù)器在同一臺(tái)機(jī)器上否則服務(wù)器被勒索加密時(shí)備份也會(huì)被一起加密。提示備份之前先測(cè)恢復(fù)。不要等到服務(wù)器真的掛了才發(fā)現(xiàn)備份文件是壞的這個(gè)坑我替客戶踩過一次數(shù)據(jù)恢復(fù)不了時(shí)整個(gè)人是崩潰的。4. 攻擊模擬、排查與應(yīng)急實(shí)錄紙上談兵結(jié)束這才是真正考驗(yàn)運(yùn)維能力的地方。我平時(shí)會(huì)做大量的攻擊模擬和故障演練為的是真出事時(shí)不慌。4.1 如何模擬一次DDoS/CC攻擊并驗(yàn)證防御效果不推薦在線上環(huán)境直接做破壞性測(cè)試我一般在預(yù)發(fā)布環(huán)境或單獨(dú)的測(cè)試機(jī)上進(jìn)行。先用壓測(cè)工具模擬高并發(fā)請(qǐng)求觀察Nginx配置的限速是否生效再用ab/Wrk這類的工具構(gòu)造高頻請(qǐng)求驗(yàn)證WAF的CC防護(hù)規(guī)則是否響應(yīng)。模擬時(shí)要關(guān)注三個(gè)指標(biāo)一是服務(wù)器是否還能正常響應(yīng)非被攻擊的接口二是CPU和內(nèi)存是否處于安全水位三是誤殺率也就是正常用戶請(qǐng)求有沒有被誤傷。有一次我配了過于嚴(yán)格的限速策略每IP每分鐘只許5個(gè)請(qǐng)求測(cè)試時(shí)發(fā)現(xiàn)正常用戶翻頁(yè)都會(huì)觸發(fā)503業(yè)務(wù)直接沒法用。后來把rate放寬到60r/m才找到平衡點(diǎn)。4.2 服務(wù)器被“打掛”后如何快速定位原因服務(wù)器出現(xiàn)過一次“打掛”的情況很多人的第一反應(yīng)是“是不是被DDoS了”。實(shí)際上不一定可能是代碼死循環(huán)、數(shù)據(jù)庫(kù)連接泄漏、磁盤寫滿等多種原因。我一般按下面的順序排查先用uptime和top/htop看系統(tǒng)負(fù)載如果CPU或內(nèi)存被占滿初步判斷是計(jì)算資源耗盡。用ss -antp查看連接數(shù)如果大量SYN_RECV或ESTABLISHED連接異常大概率是流量型攻擊或連接池失控。用sar或iftop看流量和帶寬結(jié)合時(shí)間點(diǎn)和Web日志里的請(qǐng)求集中度判斷是DDoS、CC還是爬蟲。最后看應(yīng)用日志如果有大量超時(shí)或異常報(bào)錯(cuò)優(yōu)先查代碼層面的瓶頸。有一次客戶報(bào)“H5頁(yè)面打不開”我查下來發(fā)現(xiàn)是磁盤被日志寫滿了df -h顯示使用率100%。這不是攻擊而是日志輪轉(zhuǎn)配置沒生效造成的“自傷”。所以排查時(shí)先別急著甩鍋給攻擊多個(gè)指標(biāo)對(duì)比著看才靠譜。4.3 疑似被入侵后的止血與溯源流程一旦確認(rèn)服務(wù)器被拿下時(shí)間就是生命。我建議按下面的流程走每一步都要留下證據(jù)立即將被感染的主機(jī)從對(duì)外服務(wù)中摘除可以停機(jī)或斷開外網(wǎng)避免攻擊者持續(xù)控制。保留現(xiàn)場(chǎng)給系統(tǒng)盤做鏡像或快照保護(hù)內(nèi)存和日志不被破壞。收集入侵線索last登錄記錄、/var/log/auth.log或 secure日志、crontab任務(wù)、啟動(dòng)項(xiàng)、異常進(jìn)程和安全工具的告警信息。查WebShell在web目錄下搜索最近修改的php/jsp/aspx文件重點(diǎn)檢查后綴偽裝、內(nèi)容中包含eval/system/base64函數(shù)調(diào)用的文件。溯源分析判斷是通過哪里進(jìn)來的弱口令漏洞供應(yīng)鏈找到根因后再做系統(tǒng)重裝或修復(fù)。查找WebShell時(shí)可以先用命令掃描定位可疑文件后再人工判斷# 搜索web目錄下最近7天內(nèi)修改過的腳本文件 find /data/www -name *.php -mtime -7 # 搜索常見的危險(xiǎn)函數(shù)調(diào)用需配合人工確認(rèn) grep -rlE eval\(|assert\(|system\(|shell_exec\(|passthru\( /data/www --include*.php注意WebShell掃描的結(jié)果只能作為線索不是命中就一定是惡意文件。部分框架源碼本身就會(huì)調(diào)用這些函數(shù)必須人工確認(rèn)。4.4 常見問題速查表我在多個(gè)項(xiàng)目里梳理過一批高頻問題整理成表格方便對(duì)照排查。問題現(xiàn)象可能原因排查方法帶寬被占滿CPU不高DDoS流量攻擊iftop看IP分布聯(lián)系機(jī)房或云廠商上高防CPU高但帶寬正常CC攻擊或Web代碼死循環(huán)看Web日志請(qǐng)求集中度配合Nginx限速數(shù)據(jù)庫(kù)連接數(shù)打滿SQL查詢未優(yōu)化或連接池泄漏show processlist分析慢SQL重啟后觀察登錄日志中有大量失敗記錄暴力破解啟用密鑰登錄配合Fail2ban自動(dòng)封禁頁(yè)面被植入非法廣告WebShell或篡改全線掃描WebShell檢查文件修改時(shí)間上傳目錄出現(xiàn)可疑腳本文件上傳漏洞立即禁用目錄腳本解析整改上傳校驗(yàn)內(nèi)網(wǎng)被外部訪問SSRF或端口暴露收嚴(yán)出網(wǎng)策略檢查應(yīng)用層URL請(qǐng)求校驗(yàn)服務(wù)器被加密文件后綴勒索病毒先隔離斷網(wǎng)從備份恢復(fù)排查感染源這張表里的每一項(xiàng)我都實(shí)際處理過對(duì)照著查能省很多時(shí)間。但真正的經(jīng)驗(yàn)不是這張表本身而是判斷問題時(shí)的思路先看整體指標(biāo)再縮小范圍最后落到具體日志和代碼。5. 幾個(gè)讓我印象深刻的踩坑經(jīng)歷說了這么多還是想分享幾個(gè)特別典型的坑。第一個(gè)是“改了安全組就萬(wàn)事大吉”的心態(tài)。有次客戶配置好安全組覺得防護(hù)到位了結(jié)果沒留意服務(wù)器本機(jī)的防火墻是關(guān)閉狀態(tài)。安全組過濾的是云平臺(tái)層面的流量但服務(wù)器本地防火墻關(guān)了等于外面的防線再?gòu)?qiáng)內(nèi)部的門沒鎖。后來我都是安全組和本機(jī)防火墻兩手抓缺少任何一個(gè)都不算數(shù)。第二個(gè)坑是“日志沒有同步出事后無(wú)從查起”。有一次某臺(tái)服務(wù)器被入侵我想看攻擊者的進(jìn)入路徑結(jié)果發(fā)現(xiàn)這臺(tái)機(jī)器根本沒開日志收集原有的auth日志因?yàn)榇疟P滿了被輪轉(zhuǎn)清掉。從那以后我接手的每臺(tái)服務(wù)器第一件事就是確認(rèn)日志有沒有集中存儲(chǔ)時(shí)間同步有沒有配好。沒有日志的服務(wù)器出了事就是“無(wú)頭懸案”。第三個(gè)坑是“只防外部不看內(nèi)部”。很多團(tuán)隊(duì)默認(rèn)內(nèi)部網(wǎng)絡(luò)是安全的導(dǎo)致數(shù)據(jù)庫(kù)、Redis、管理后臺(tái)的密碼常年不換防火墻也不設(shè)內(nèi)部隔離。結(jié)果攻擊者通過一個(gè)前臺(tái)文件上傳漏洞進(jìn)來后在內(nèi)網(wǎng)橫向移動(dòng)如入無(wú)人之境。防御一定要有縱深內(nèi)部服務(wù)和外部流量一樣要做鑒權(quán)和訪問控制。6. 最后的幾點(diǎn)個(gè)人體會(huì)做了這些年服務(wù)器攻擊與防御相關(guān)的工作我最大的體會(huì)是安全不是裝幾個(gè)軟件、開幾個(gè)服務(wù)就完事的它是一個(gè)持續(xù)的、需要融進(jìn)日常操作習(xí)慣的事情。哪怕一臺(tái)服務(wù)器只跑一個(gè)小網(wǎng)站也應(yīng)該按照“清點(diǎn)資產(chǎn)—收緊暴露面—持續(xù)監(jiān)控—及時(shí)響應(yīng)”的節(jié)奏來維護(hù)。如果你剛接手一臺(tái)服務(wù)器可以從今天就開始做三件事檢查開放端口和登錄方式、確認(rèn)日志是否集中存儲(chǔ)和輪轉(zhuǎn)、給系統(tǒng)盤和數(shù)據(jù)庫(kù)做一次可驗(yàn)證的備份。這三件事花不了幾個(gè)小時(shí)但能在很多場(chǎng)景下救命。我在實(shí)際運(yùn)維中遇到的事故多數(shù)都不是因?yàn)楣粽呒夹g(shù)多高明而是因?yàn)榛A(chǔ)工作長(zhǎng)期欠賬。把地基打好絕大多數(shù)攻擊都會(huì)在門口被擋下來。