安全加固總論

1、漏洞掃描的種類及其修復方法

在系統上線的過程當中，通常要通過三重檢查：主機基線掃描、主機端口掃描、web掃描。相應的漏洞咱們劃歸爲：主機基線配置漏洞、主機端口漏洞、web應用漏洞。

 

1.1主機基線掃描

1.1.1 主機基線掃描的必要性

雖然基線配置存在於主機內部不能爲攻擊者直接利用，從定義上不宜稱之爲「漏洞」；可是若是使用telnet確實存在用戶名密碼明文傳輸問題，若是沒有超時自動退出登陸窗口確實有可能被攻擊者利用，因此從影響上稱之爲「漏洞」也不能說名存實亡。因此基線掃描存在的不是有沒有必要的問題，而只該是尺度的問題。好比多久超時退出，密碼有效期多長，密碼長度和複雜度該怎樣等等。

 

1.1.2 主機基線配置漏洞的修復方法

主機基線配置漏洞，總的而言就是修改主機配置文件。通常的掃描器給出的html掃描報告都會給出漏洞修復要修改的文件和修改的內容（這也是更推薦修復人員直接看html報告的緣由），按給的建議進行操做通常就能夠修復相應的漏洞。固然有時掃描器兼顧不到全部操做系統或者沒有兼顧到最新版本的操做系統，因此有些時候會有些出入但整體而言問題不大。修復中最大的問題，一是部分漏洞修復修改的文件有重複，若是逐個漏洞按修復建議進行修復，那會有重複工做；二是單個的漏洞修復方法沒有考慮全局，若是嚴格逐個執行漏洞的修復操做可能會有問題，好比要求root不能遠程登陸主機又要求普通用戶不能su到root，若是就這麼操做，那麼遠程就無法使用root了。鑑於這兩點，推薦的作法是逐個漏洞寫成腳本，而後合併重複項考慮執行後對系統使用的影響進行增減，最後執行腳本便可。

 

1.2 主機端口掃描

1.2.1 主機端口掃描的必要性

端口是主機的門戶，全部的網絡攻擊都要經過端口進行。若是主機不開聽任何端口那就能夠認爲這是一臺絕對安全的主機。但一臺服務器不可避免要開放端口，否則其自己應沒有什麼意義。而當服務器一旦開啓端口，就必要保證端口的安全性，由於若是端口存在漏洞攻擊者就可能經過端口攻擊乃至進入、控制系統。端口掃描和端口漏洞修復是保證端口安全性的兩大保障。

 

1.2.2 主機端口漏洞的修復方法

主機端口漏洞，「修復」方法通常有四種：一是打補丁或升級軟件，從軟件代碼層面完全修復漏洞；二是使用白名單，包括防火牆白名單、主機/etc/hosts.deny等文件的白名單及軟件自身的白名單三種形式；三是修改和隱藏軟件版本號。前邊在「修復」這個詞上加上了雙引號，由於前面三種方法中，只有第一種打補丁/升級方式是真正修復了漏洞。第二種白名單提高的安全性與白名單的數量負相關。在下文中咱們會對第三種修改和隱藏版本號這一方式進行討論，說明其爲何不失爲一種修復方式。

 

1.3 web應用掃描

1.3.1 web應用掃描的必要性

web應用掃描並非對web服務的端口再次進行掃描，也不是對web服務的端口進行更深刻的掃描；主機端口掃描和web應用掃描，沒有包含關係也沒有重合關係。主機端口掃描只是對web所使用的中間件進行了掃描但沒有對web中間件之上的web應用進行掃描，web應用掃描是正是對中間件之上的web應用進行掃描。web應用服務是服務器向服戶提供服務的主要表現形式，其餘的安全其宗旨都靠攏於保障web應用服務的安全，web應用自身的安全性更應進行保障。

 

1.3.2 web應用漏洞的修復方法

web應用漏洞，能夠大略分爲兩種，一種是sql注入、xss和csrf等技術方面的漏洞，另外一種是驗證碼可反覆使用等業務交互邏輯方面的漏洞。但無論是哪一類，修復方法都是讓程序員修改代碼升級應用。一是web應用漏洞通常不歸維護人員處理，二是各web漏洞的修復方法隨具體存在漏洞的代碼的不一樣而變化沒有統一固定的形式，因此這裏很少敘述。

 

1.4 軟件包版本掃描

1.4.1 軟件包版本掃描的非必要性

在最爲嚴格的狀況下，還有針對系統軟件包的檢查，凡有更新的軟件包必須更新到最新版本，否則斷定爲有漏洞。穩定是服務器操做系統的第一要素，但凡適合做爲服務器的操做系統，通常而言都不會採用最新的軟件版本。強制全部軟件包更新到最新版本換取有限的安全性提高的要求，對服務器穩定性作出了挑戰，在整體上有可能會給系統帶來更大的安全隱患。反過來，對於修復漏洞而言，大多數軟件包並不監聽端口（好比curl）或者並無監聽端口（好比未啓動的httpd）若是攻擊者能利用這些軟件包的漏洞那麼須要攻擊者已經具備了主機的權限，既然已經具備了主機權限攻擊者又何須反過來去利用這些漏洞呢。或許也存在多是攻擊者可利用這些漏洞進行權限提高--這裏有疑問由於權限提高的前提通常是有一個高權限用戶運行了有漏洞的程序而後攻擊者經過緩衝區溢出以該用戶身份執行命令--這裏權當存在這種可能，這帶來的利弊策略制定者要進行考量。通常而言不推薦實施這種要求。

 

1.4.2 軟件包版本漏洞的修復方法

對於執行者而言只能執行上層的決定，若是軟件包版本不是最新這個問題指明必需要處理那也只好處理。從原理上這類掃描就是經過「rpm -qa|grep 包名」而後將包名上的版本號與其最新的版本號相比較看是否一致來判斷的。一種辦法是，若是該軟件包不是必須的可直接用」rpm -e 包名」或「yum erase 包名」將軟件包卸載（必定要注意若是上面兩個命令執行後提示軟件受保護卸載錯誤那麼不要強制卸載，否則系統可能不少命令都執行不了）。第二種方法是將軟件更新到最新版本版本，不過要注意iso文件製做的本地yum源是不行的須要到軟件源的updates目錄下載那纔是操做系統官方發佈的最新的軟件包。

但還有一個問題就是觀察發現掃描器並是以軟件官方發而的軟件爲準而不是以操做系統官方updates目錄爲準。軟件官方和操做系統官方常常是有區別的，好比Linux內核的官方是linus團隊，他們只發布源代碼至於怎麼編譯、是否與Linux版本徹底兼容、打包成rpm或deb或其餘格式這些事他們無論；CentOS官方是Redhat，其編譯適配CentOS後在updates中發佈rpm更新包。問題就在於若是掃描器以軟件官方發佈的版本爲準，而操做系統官方尚未推出該版本的rpm更新包（這種現像十分常見），又非要更新那隻能本身手動編譯。但原來的編譯參數是什麼不知道，編譯出來的是否與操做系統相兼容更很差說--連操做系統官方都還沒有驗證好。說軟件包版本掃描對服務器穩定性作出了挑戰，最主要的也正在於此。

 

2、漏洞修復FAQ

 

2.1 修改和隱藏版本號是否可以提高安全性？

從直觀感覺上來講是這樣的場景：我手上有exp，你只管修改和隱藏版本號，我怎樣均可以攻擊你。但這個場景其實有一個很大的問題：你怎麼知道這臺機器是有這個漏洞能夠用這個exp？或者從正向提問：如今你是一名滲透測試人員，你如何肯定一臺機器是否有漏洞、有什麼漏洞？滲透測試簡而言之就是兩種方法：第一種是掃描器，第二種是手工測試。

凡掃描器者其要義就是「匹配特徵碼」，匹配上了就是有漏洞，沒匹配上就是沒漏洞。版本號就是掃描器最常使用的特徵碼，版本匹配上就是有漏洞，版本沒匹配上就是沒漏洞。若是你用掃描器掃描，我把版本號改了掃描器告訴你沒有漏洞，那我是否是騙過你了呢，那我是否是騙過了其餘用掃描器的攻擊者了呢，那我是否是提升了安全性了呢？

或者你是一名高手，不用掃描器，用手工測試的方式。根據PTES標準，滲透測試可劃分爲前期交互、信息收集、威脅建模、漏洞分析、滲透攻擊、後滲透攻擊、報告生成等七個階段。信息收集根據不一樣環境可收集的信息不少，但具體到一臺要攻擊的主機而言，最重要的信息就是開放了哪些端口，是什麼服務，服務是什麼版本？仍是要扯到版本上來，由於漏洞是和版本相關，知道了什麼版本你才知道要去檢測什麼漏洞。若是我隱藏了版本那麼你全部漏洞都要測，若是我告訴你一個錯誤的版本你可能就去測那些不存在的漏洞。並且漏洞的表現常常和主機相關聯，常常表現出「異常」，攻擊者沒看到版本或者版本不對，看到這些異常也可能會判斷主機不存在漏洞。

總而言之，修改和隱藏版本號能夠欺騙以版本爲「特徵碼」的掃描器，能夠增長人工滲透的成本，因此是能夠提升系統的安全性。「增長成本」這道理和家裏上鎖有類似，能夠這樣講家裏的鎖對於真要進你家的開鎖高手而言就是形同虛設，但你並不會就不上鎖也不會否定上鎖提升了安全性。

 

2.2 爲何須要使用修改和隱藏版本號的方式？

不管怎麼說，修改和隱藏版本號漏洞總仍是在那裏的，老是讓人不放心，爲何必定要用修改版本號的方式而不是直接修改漏洞。其實防火牆的修復方式也沒真正修復漏洞，因此使用修改和隱藏版本號的緣由與使用白名單的緣由都同樣：方便。若是「方便」兩個字不能讓人以爲值得過犧牲的安全性。那咱們來看看若是不用白名單，不用修改和隱藏版本號，而是去升級怎麼個「複雜」。

對於開源免費的產品好比tomcat，通常沒有單獨的補丁修復漏洞就是要下載官方提供的最新版本。從時間縱向而言，tomcat平均每個月一版，要真正修復漏洞那就是每月要從新部署一次，整個企業有多少個tomcat呢；從產品橫向而言，經常使用的就有tomcat、apache等十數種產品，每次推出新版本就升級那是一個旁大的工做量，並且還沒考慮升級可能帶來的配置變更，以及以前的部署人員的特殊配置帶來的種種問題。

對於商業收費的產品好比weblogic，會有單獨的補丁包。不須要從新安裝軟件和部署應用，可是協商啓停這一較小的工做，在數量放大下也是一個不小的工做量。

 

2.3 怎麼評價白名單修復方式？

相比打補丁升級白名單方式更加方便，相比修改和隱藏版本號方式雖然也沒有修復漏洞但沒在白名單的ip就不能鏈接也就沒法利用漏洞，因此不失爲一種修復方式。

因爲白名單提高的安全性與白名單數量負相關，因此從技術角度上講，白名單應當聽從「最小化」原則，白名單數量應儘量地少。但從運行平穩角度上講，白名單應當聽從「最大化」原則，不能肯定要不要加入白名單地都須要加入白名單。矛盾的焦點在於難於肯定「是否是要加入白名單」，這種沒法肯定是很常見的，好比一臺數據庫是我只能說我是在用，但我無法肯定你有沒有在用他有沒有在用，尤爲是在老的系統或者通過屢次交接的系統。若是白名單隻列我給的，致使別的系統出了問題這當如何處理。這是白名單方式存在的一個最大問題。

 

2.4 白名單方式中iptables和/etc/hosts.allow等文件這兩種方式有什麼區別？

更準確的說法是防火牆和/etc/hosts.allow等文件這兩種方式有什麼區別，這是咱們暫且將防火牆和iptables視爲同義。

iptables對什麼端口都能限制，而/etc/hosts.allow和/etc/hosts.deny只對使用了libwrap庫的服務生效（好比ssh、telnet），對沒使用libwrap庫的服務不生效（好比httpd）。因此能用iptables就用iptables這樣統一一些方便管理。

可是linux纔有防火牆，aix和sunos沒有防火牆（更準確地說是比較複雜），因此aix和sunos只能用/etc/hosts.allow和/etc/hosts.deny。但這就有一個問題，就是那些在aix或sunos上但又沒有使用libwrap庫的程序的漏洞就無法經過白名單進行處理了。