2023金融行業(yè)信息安全技術(shù)實(shí)踐

金融行業(yè)信息安全技術(shù)實(shí)踐目錄TOC\o"1-2"\h\u6061第1章互聯(lián)網(wǎng)應(yīng)用安全 46927端口管控 57818Web應(yīng)用安全 814758系統(tǒng)安全 1019547網(wǎng)絡(luò)安全 1210772數(shù)據(jù)安全 1218830業(yè)務(wù)安全 134768互聯(lián)網(wǎng)DMZ區(qū)安全管控標(biāo)準(zhǔn) 133228小結(jié) 1731746第2章移動應(yīng)用安全 17161181.1概述 1718141.2APP開發(fā)安全 18282721.3APP業(yè)務(wù)安全 28248701.4小結(jié) 365862第3章企業(yè)內(nèi)網(wǎng)安全 36295501.1安全域 36118261.2終端安全 38286101.3網(wǎng)絡(luò)安全 41278201.4服務(wù)器安全 48111471.5重點(diǎn)應(yīng)用安全 5278821.6漏洞戰(zhàn)爭 568751.7蜜罐體系建設(shè) 66288251.8小結(jié) 765454第4章 數(shù)據(jù)安全 76271731.1數(shù)據(jù)安全治理 77193761.2終端數(shù)據(jù)安全 77194711.3網(wǎng)絡(luò)數(shù)據(jù)安全 91195481.4存儲數(shù)據(jù)安全 97137941.5應(yīng)用數(shù)據(jù)安全 98117721.6其他話題 10030361.7小結(jié) 10613090第5章業(yè)務(wù)安全 107781.1賬號安全 107324461.2爬蟲與反爬蟲 11612221.3API網(wǎng)關(guān)防護(hù) 12453991.4釣魚與反制 125188351.5大數(shù)據(jù)風(fēng)控 131219581.6小結(jié) 13726215第6章 郵件安全 138159371.1背景 139238521.2入站安全防護(hù) 1414981.3出站安全防護(hù) 172287321.4整體安全防護(hù)體系 176112591.5小結(jié) 17820380第7章 活動目錄安全 178245871.1背景 179319921.2常見攻擊方式 179150931.3維持權(quán)限的各種方式 19511201.4安全解決方案 211637817.5 小結(jié) 22222558第8章安全熱點(diǎn)解決方案 222303321.1DDoS攻擊與對策 222205141.2勒索軟件應(yīng)對 22827831.3補(bǔ)丁管理 22945581.4堡壘機(jī)管理 231279001.5加密機(jī)管理 23428631.6情報(bào)利用 238251711.7CTF 239176311.8小結(jié) 24311715第9章 安全檢測 244102831.1安全檢測方法 24596431.2檢測工具 2468151.3安全檢測思路和流程 247215111.4安全檢測案例 24989641.5紅藍(lán)對抗 276144481.6小結(jié) 27823607第10章 安全運(yùn)營 278171951.1安全運(yùn)營概述 279235881.2架構(gòu) 27965731.3工具 283127711.4所需資源 285307821.5安全運(yùn)營的思考 287132911.6小結(jié) 29024985第11章 安全運(yùn)營中心 291203841.1安全運(yùn)營中心概述 29153171.2ArcSight簡介 291313241.3SOC實(shí)施規(guī)劃和架構(gòu)設(shè)計(jì) 296170141.4ArcSight安裝配置 305306461.5小結(jié) 3081722第12章 安全資產(chǎn)管理和矩陣式監(jiān)控 30842811.1安全資產(chǎn)管理 308232561.2矩陣式監(jiān)控 317291401.3小結(jié) 3223462第13章 應(yīng)急響應(yīng) 32257391.1概述 323117691.2事件分類 324158811.3事件分級 3253481.4PDCERF模型 325137751.5其他話題 326210901.6小結(jié) 32728498第14章安全趨勢和安全從業(yè)者的未來 32779951.1職業(yè)規(guī)劃方法論 32780051.2安全環(huán)境趨勢和安全從業(yè)趨勢 332174101.3安全從業(yè)指南 333109261.4安全從業(yè)注意事項(xiàng) 338280851.5小結(jié) 339第1章互聯(lián)網(wǎng)應(yīng)用安全Web2.0時代，企業(yè)會將越來越多的應(yīng)用暴露在互聯(lián)網(wǎng)上，帶來的風(fēng)險(xiǎn)不容忽視。傳統(tǒng)企業(yè)會用防火墻進(jìn)行隔離，將應(yīng)用部署在隔離區(qū)（Demilitarizedzone，DMZ），圖11-1是一個簡單的示意圖。圖11-1 傳統(tǒng)企業(yè)互聯(lián)網(wǎng)應(yīng)用示意圖防火墻在這里的作用有兩點(diǎn)：一是將內(nèi)網(wǎng)、DMZ區(qū)、互聯(lián)網(wǎng)進(jìn)行隔離，二是將DMZ的私網(wǎng)地址映射到互聯(lián)網(wǎng)上供外部訪問。當(dāng)然，實(shí)際企業(yè)可能做映射的不一定是防火墻，也有可能是負(fù)載均衡設(shè)備。當(dāng)一個應(yīng)用需要對互聯(lián)網(wǎng)訪問時，需要注意哪些事項(xiàng)，本章將從外到里逐一闡述。端口管控首先要做的就是端口管控，即在防火墻上嚴(yán)格限制對外開放的端口。原則上DMZ服務(wù)器只允許對外開放80、443端口，而且DMZ服務(wù)器不允許主動訪問外部，訪問外部的業(yè)務(wù)需要一對一開通訪問。常見的端口管控誤區(qū)如下：有些企業(yè)管理員為了方便維護(hù)，在防火墻上直接對外開放Telnet、SSH、RDP的端口，這是非常不明智的，只要知道密碼，黑客就可以通過這些端口獲得交換機(jī)/服務(wù)器的權(quán)限，將SSH對外開放，系統(tǒng)日志就會出現(xiàn)大量的登錄失敗日志。還有一些FTP、MSSQL、MySQL、Redis、Rynsc、memcached、Elasticsearch、Mongodb搜索“FTP本地提權(quán)”“Redis未授權(quán)訪問”“MongoDB勒索”“Elasticsearch勒索”等等。一般大型企業(yè)的互聯(lián)網(wǎng)出口或者業(yè)務(wù)系統(tǒng)會比較多，在日常防火墻維護(hù)過程中，難免會出現(xiàn)遺漏，所以需要有相應(yīng)的機(jī)制來保障高危端口不對外開放，開放了要及時發(fā)現(xiàn)，這就需要端口掃描。說到端口掃描工具，必談Nmap，此外還有Zmap、Masscan也很受歡迎，下面簡單介紹Nmap和Masscan。Nmap功能非常強(qiáng)大，仔細(xì)看其幫助即可體會，如圖11-2所示。Nmap支持列表改入、各種主機(jī)發(fā)現(xiàn)、端口掃描技術(shù)、操作系統(tǒng)探測、掃描時間控制、各種格式輸出等，甚至還支持外部腳本針對性的檢測漏洞。端口掃描技術(shù)常用的有：半開放掃描（TCPSYN）、全連接掃描（TCPConnect）、ACK掃描、FIN掃描等。另外，Nmap掃描輸出的xml格式結(jié)果文件，用腳本解析起來很方便，和其他系統(tǒng)對接非常輕松。圖11-2 Namp的使用Nmap功能雖然強(qiáng)大，但在大網(wǎng)段全端口掃描時會非常慢，這時候就需要Masscan了。Masscan號稱是“最快的互聯(lián)網(wǎng)端口掃描器”，最快可以在6分鐘內(nèi)掃遍互聯(lián)網(wǎng)，每秒可以發(fā)送一百萬個數(shù)據(jù)包，適合于對大量地址進(jìn)行快速掃描。Masscan提供較為豐富的選項(xiàng)。例如，用戶可以指定掃描的端口、路由器地址、發(fā)包速率和最大速率等。同時，它還支持多種文件格式用于保存掃描結(jié)果。對于大型企業(yè)，建議采用聯(lián)合方式，例如先用Masscan快速掃描一遍，然后再針對性地用Nmap掃描，以獲取更多信息，包括操作系統(tǒng)版本、端口對應(yīng)的Banner信息等。當(dāng)掃描程序發(fā)現(xiàn)高危端口后，可以實(shí)時輸出日志給SOC，以便一線人員實(shí)時跟進(jìn)處理。在實(shí)際工作中，掃描還需要注意避開業(yè)務(wù)高峰、調(diào)整發(fā)包速率參數(shù)等，以免引起不必要的麻煩。Web應(yīng)用安全端口管控工作是基礎(chǔ)，做好端口管控工作后，需要將重點(diǎn)放在Web安全上。OWASP組織（OpenWebApplicationSecurityProject，開放式Web應(yīng)用程序安全項(xiàng)目）每年都會有個Top10的風(fēng)險(xiǎn)列表，包括各種注入（SQL、NoSQL、OS、LDAP等注入）、XSS攻擊、CSRF，等等。在Web安全領(lǐng)域，吳翰清的《白帽子講Web安全》值得推薦，客戶端腳本安全、服務(wù)端應(yīng)用安全都包括在內(nèi)。作為企業(yè)安全從業(yè)人員，除了要知道黑客怎么攻擊外，還需要關(guān)注我們怎么防守，在哪些維度上進(jìn)行防守。Web應(yīng)用防火墻針對常規(guī)的Web掃描行為，Web應(yīng)用防火墻（WebApplicationFirewall，WAF）基本上可以直接攔截或阻斷。Web應(yīng)用防火墻是通過執(zhí)行一系列針對HTTP/HTTPS的安全策略來專門為Web應(yīng)用提供保護(hù)的一款產(chǎn)品。與傳統(tǒng)防火墻不同，WAF工作在應(yīng)用層，因此對Web應(yīng)用防護(hù)具有先天的技術(shù)優(yōu)勢?；趯eb應(yīng)用業(yè)務(wù)和邏輯的深刻理解，WAF對來自Web應(yīng)用程序客戶端的各類請求進(jìn)行內(nèi)容檢測和驗(yàn)證，確保其安全性與合法性，對非法的請求予以實(shí)時阻斷，從而對各類網(wǎng)站站點(diǎn)進(jìn)行有效防護(hù)。WAF產(chǎn)品有基于硬件的，也有基于軟件的，還有基于云的：硬件WAF支持ByPass等，所以是我們的首選。當(dāng)然，有些防火墻的IPS模塊也具備一定的WAF功能，例如CheckPoint；有些負(fù)載均衡設(shè)備本身也支持SSL卸載和應(yīng)用防護(hù)，例如F5。在實(shí)際的部署過程中，需要考慮在哪一層部署，或者結(jié)合各產(chǎn)品自身特性綜合性地部署。在一些不重要的區(qū)域或者基于成本考慮，也可以使用軟件WAF，比較著名的有ModSecurity。ModSecurity的規(guī)則包括基礎(chǔ)規(guī)則集、SLR規(guī)則集、可選規(guī)則集、實(shí)驗(yàn)性規(guī)則集?；A(chǔ)規(guī)則集主要包括與HTTP協(xié)議規(guī)范相關(guān)的一些規(guī)則，一些SQL注入、XSS、目錄遍歷、Webshell等；SLR規(guī)則集則是針對特定應(yīng)用（例如Joomla、PHPBB、WordPress等）的漏洞利用規(guī)則?？紤]到ModSecurity性能有所不足，還可以使用基于nginx的方案，GitHub上的FreeWAF。客觀來講，使用開源WAF對安全人員要求較高，也更靈活。有些企業(yè)考慮將業(yè)務(wù)上云，于是出現(xiàn)了基于云的WAF，其本質(zhì)上也是軟件WAF一些日志分析、機(jī)器學(xué)習(xí)的技術(shù)。整體來講，可以考慮在前端有硬件WAF的情況下，在服務(wù)器上啟用軟件WAF，結(jié)合業(yè)務(wù)場景對特定請求進(jìn)行重點(diǎn)防護(hù)，以做補(bǔ)充。入侵檢測/防御系統(tǒng)雖然市面上某些WAF有利用機(jī)器學(xué)習(xí)的功能，可以對各種請求的參數(shù)進(jìn)行學(xué)習(xí)并判定是否合法，但WAF更多是基于規(guī)則的，有規(guī)則就會有繞過的可能。針對這些可能繞過WAF的請求，我們還需要借助入侵檢測系統(tǒng)/入侵防御系統(tǒng)（IntrusionDetectionSystem/IntrusionPreventionSystem，IDS/IPS）類產(chǎn)品對WAF后端的流量進(jìn)行分析，發(fā)現(xiàn)惡意行為。IDS開源的有Snort，網(wǎng)上有較多的資料，不再贅述。商業(yè)的IDS產(chǎn)品相對來講供進(jìn)一步分析。漏洞掃描和滲透測試掃描工具常見的有AWS、IBMAppscan、HPWebInspect、Nikto等商業(yè)或開源掃描器，針對一些漏洞邏輯可能還會使用BurpSuite、Fiddler等工具進(jìn)行輔助。筆者建議有條件的企制自己的掃描器，這樣的好處是便于內(nèi)部IPS和WAF識別或加白處理。滲透測試往往包含內(nèi)部測試和外部測試，內(nèi)部安全人員對業(yè)務(wù)理解更深，更容易發(fā)現(xiàn)問全面地覆蓋。關(guān)于漏洞掃描和滲透測試的內(nèi)容，在第19章中有更詳細(xì)的描述。系統(tǒng)安全未攔截的請求到了DMZ服務(wù)器，對應(yīng)用或者系統(tǒng)有什么樣的影響，我們放到這一節(jié)來探討。常規(guī)的系統(tǒng)加固、WebServer加固、目錄權(quán)限設(shè)置等就不說了，惡意請求的目的可能是：想利用上傳功能直接上傳一個WebShell，利用文件包含功能直接引用一個遠(yuǎn)程的WebShell，利用文件解析漏洞上傳惡意圖片或視頻，觸發(fā)特定漏洞執(zhí)行命令，或者是已經(jīng)拿到WebShell直接請求執(zhí)行命令。如何有效發(fā)現(xiàn)WebShell，是一個很大的話題，這里不詳細(xì)展開。一般來講，有以下幾個思路：對網(wǎng)絡(luò)上的各種樣本進(jìn)行收集提取。結(jié)合文件變化及屬性來判斷。結(jié)合網(wǎng)絡(luò)流量特征來判斷。結(jié)合腳本底層執(zhí)行動作來判斷。在系統(tǒng)上，有沒有較好的方式發(fā)現(xiàn)異常呢？打個比方，有些黑客喜歡拿到WebShell后上來就執(zhí)行whoami之類的指令，我們是否可以利用基于主機(jī)型入侵檢測系統(tǒng)（Host-basedIntrusionDetectionSystem，HIDS）中的檢測模型發(fā)現(xiàn)其中的異常呢？操作系統(tǒng)本身就有一些審計(jì)日志功能，針對一些特定的攻防場景，需要針對性的研究，定制規(guī)則以發(fā)現(xiàn)異常。OSSEC開源的HIDS產(chǎn)品中，OSSEC比較出名。OSSEC是一款開源的基于主機(jī)的入侵檢測系統(tǒng)，包括日志分析、文件/注冊表完整性檢測、安全策略監(jiān)控、Rootkit檢測、實(shí)時報(bào)警、動態(tài)響應(yīng)等功能。它的最大優(yōu)勢在于支持很多操作系統(tǒng)，包括Linux、MacOS、Solaris、HP-UX、AIX和Windows。OSSEC默認(rèn)帶有一些規(guī)則，包括SSH破解、Windows登錄失敗、賬號添加修改等，安裝上簡單測試就可以看到效果，但要實(shí)際投產(chǎn)使用，還需要針對性地寫一些插件規(guī)則以滿足特定場景下的攻防策略需求。另外，OSSEC有些功能的實(shí)現(xiàn)方式不是非常完美，例如，Rookit檢測中的代碼居然是直接利用netstat命令的結(jié)果進(jìn)行對比，如圖11-3所示。圖11-3 檢測中的代碼直接利用netstat命令的結(jié)果進(jìn)行對比在負(fù)載高的機(jī)器上，netstat的執(zhí)行會非常慢，還會因?yàn)闀r間原因產(chǎn)生誤報(bào)。Sysmon對于Windows系統(tǒng)，建議使用Sysmon。Sysmon是由WindowsSysinternals出品的Sysinternals系列中的工具，它以系統(tǒng)服務(wù)和設(shè)備驅(qū)動程序的方式安裝在系統(tǒng)上，并保持常駐性。Sysmon用來監(jiān)視和記錄系統(tǒng)活動，并記錄到Windows事件日志，可以提供有關(guān)進(jìn)程創(chuàng)建、網(wǎng)絡(luò)連接和文件創(chuàng)建時間更改的詳細(xì)信息。Sysmon由微軟出品，兼容性有保障，功能強(qiáng)大，對Windows審計(jì)日志是一個非常棒的補(bǔ)充。在大量機(jī)器部署的情況下，結(jié)合Sysmon+Evtsys收集日志匯總到SOC，定制CASE，也是一個不錯的方案。網(wǎng)絡(luò)安全假設(shè)某臺服務(wù)器因?yàn)橛新┒匆呀?jīng)被攻陷，黑客一般會在機(jī)器上進(jìn)行各種翻找，甚至進(jìn)一步探測其他網(wǎng)絡(luò)。WebShell通常為了方便都提供反彈shell的功能，即主動外連到特定端口，如果前面我們的動出站的連接進(jìn)行記錄，與學(xué)習(xí)到的基線或者自行維護(hù)的黑白名單進(jìn)行對比，以發(fā)現(xiàn)問題，我們把它稱之為“異常流量檢測系統(tǒng)”，在DMZ環(huán)境下只需關(guān)注主動外連的情況，相對簡單。在DMZ內(nèi)網(wǎng)活動的時候，流量不一定會被鏡像到，這時候我們需要借助蜜罐來發(fā)現(xiàn)異常。在每個DMZ提到蜜罐，大家都熟知honeyd，是一個非常優(yōu)秀的開源蜜罐框架，支持模擬多個IP主機(jī)和任意的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，還支持服務(wù)模擬腳本來模擬后端應(yīng)用，如IIS、Telnet、POP3等。在實(shí)際環(huán)境中需要關(guān)注其可能帶來的運(yùn)行風(fēng)險(xiǎn)，例如，其arpd的組件使用類似ARP欺騙的方式牽引流量到密灌，在錯誤的運(yùn)行方式下，如果同一網(wǎng)段任意存活主機(jī)在某時刻短暫掉線后，可能會被蜜罐程序的ARP包刷新網(wǎng)關(guān)上的MAC地址表，導(dǎo)致原IP無法正常訪問。其實(shí)，蜜罐不一定要非常專業(yè)，在一些特定區(qū)域比如DMZ一些簡單的基于端口訪問的初級蜜罐也能發(fā)揮很大作用。數(shù)據(jù)安全一個合法的Web請求最后可能會涉及后端各種業(yè)務(wù)邏輯，跟數(shù)據(jù)庫打交道，在頁面上展示相關(guān)內(nèi)容等。這里需要關(guān)注兩個問題，一是到數(shù)據(jù)庫的請求是否真的合法；二是頁面上返回的輸出是否包含敏感信息，我們都放在這一節(jié)來講。一個SQL注入語法可能經(jīng)過各種變形，加之利用服務(wù)端和WAF特性進(jìn)行了繞過，但到了數(shù)據(jù)庫這里，一切都是非常清晰的，數(shù)據(jù)庫審計(jì)類產(chǎn)品可以輕松發(fā)現(xiàn)一些注入行為。數(shù)據(jù)庫審計(jì)類產(chǎn)品有兩類，一種是基于proxy或插件模式的；一種是基于網(wǎng)絡(luò)流量的?；趐roxy好理解，應(yīng)用先連接proxy，再由proxy連接后端真實(shí)數(shù)據(jù)庫，這樣所有的SQL請求都會被proxy記錄下來；而有些數(shù)據(jù)庫有一些審計(jì)插件，例如Mcafee開源的MySQL_Audit插件，只需將對應(yīng)的so文件復(fù)制到plugin_dir目錄然后在配置文件里啟用即可。但這兩個方案都對應(yīng)用有一定的侵入性，穩(wěn)妥起見，建議使用基于網(wǎng)絡(luò)流量的數(shù)據(jù)庫審計(jì)類產(chǎn)品，即將應(yīng)用到DB的流量鏡像給設(shè)備，由設(shè)備再還原出SQL語句。商業(yè)的數(shù)據(jù)庫審計(jì)產(chǎn)品有imperva、安恒等。一個正常的頁面輸出，也可能會涉及銀行卡號、身份證、手機(jī)號等客戶資料信息，一般應(yīng)用需要做一些脫敏處理。在一些特殊情況下可能處理得不夠好，這時候就需要有一定的監(jiān)測機(jī)制才能發(fā)現(xiàn)這種問題。常規(guī)的DLP方案在這里需要經(jīng)過一定的調(diào)整，重點(diǎn)不再是分析HTTP的Request，而是分析服務(wù)器的Response信息。在Response信息里不僅能發(fā)現(xiàn)一些客戶資料信息，還能發(fā)現(xiàn)一些異常的東西，諸如目錄遍歷、特定WebShell等的問題。當(dāng)然有些功能也可以在WAF里實(shí)現(xiàn)，WAF也有針對Response的一些檢測規(guī)則。業(yè)務(wù)安全還有一個場景需要提到，就是互聯(lián)網(wǎng)應(yīng)用中與業(yè)務(wù)邏輯相關(guān)的安全問題，統(tǒng)稱“業(yè)務(wù)安全”擊者可能會利用暴力破解、撞庫等方式進(jìn)行嘗試請求；再例如，一個簡單的查看個人信息頁面，涉及Session或Cookie驗(yàn)證，而攻擊者可能會通過修改URL中的ID或者修改本地Cookie來看其他人的信息。還有一些是關(guān)于接口的安全問題，例如，某分類信息網(wǎng)站的簡歷泄露事件，就是攻擊者組合了3個不同的接口獲取相應(yīng)信息。這里的對抗方法，更多從風(fēng)控角度出發(fā)，收集access日志、業(yè)務(wù)日志進(jìn)行分析，再結(jié)合外部情報(bào)（黑白名單庫）、機(jī)器學(xué)習(xí)等，是一個非常細(xì)分的領(lǐng)域，我們將在第15章中詳細(xì)介紹?；ヂ?lián)網(wǎng)DMZ區(qū)安全管控標(biāo)準(zhǔn)針對DMZ區(qū)的互聯(lián)網(wǎng)應(yīng)用安全防護(hù)體系，我們將上面提到的各種管控技術(shù)方案進(jìn)行抽象，并考慮實(shí)際落地運(yùn)營情況，形成一個互聯(lián)網(wǎng)DMZ表11-1。表11-1 互聯(lián)網(wǎng)DMZ區(qū)安全管控標(biāo)準(zhǔn)當(dāng)然，除了表11-1所提到的技術(shù)點(diǎn)之外，還涉及上線流程管控、防分布式拒絕服務(wù)攻擊（DDoS）等。常規(guī)的上線流程管控包括主機(jī)上線前掃描、應(yīng)用上線前掃描、日志采集、安全防護(hù)軟件部署、堡壘機(jī)納管等各個環(huán)節(jié)，建議與ITIL流程結(jié)合在一起。而DDoS對抗也是一個很專業(yè)的細(xì)分領(lǐng)域，我們后面會在18.1節(jié)中介紹。最后，在互聯(lián)網(wǎng)DMZ區(qū)可能還會部署類似VPN、郵件等系統(tǒng)，考慮到這些更多的是為企業(yè)內(nèi)部員工使用，所以我們將在第13章中進(jìn)行闡述。小結(jié)本章從外向內(nèi)對互聯(lián)網(wǎng)應(yīng)用安全防護(hù)做了一個基本的闡述，包括端口、Web應(yīng)用、系統(tǒng)、網(wǎng)絡(luò)、業(yè)務(wù)、數(shù)據(jù)等，有些內(nèi)容會在后面的章節(jié)中更為詳細(xì)地闡述。需要特別說明的是，金融行業(yè)作為一個強(qiáng)監(jiān)管行業(yè)，在做安全工作的時候更多是考慮效果（合規(guī)、風(fēng)險(xiǎn)控制與轉(zhuǎn)移、管理與運(yùn)營落地等），所以在安全解決方案的選擇上更偏重成熟穩(wěn)定的商業(yè)產(chǎn)品，再結(jié)合企業(yè)實(shí)際需求使用開源方案做適當(dāng)?shù)难a(bǔ)充和輔助，這一點(diǎn)和互聯(lián)網(wǎng)公司因成本、規(guī)模等原因而更多選擇開源或自研是有較大差別的。第2章移動應(yīng)用安全隨著智能手機(jī)以及4G網(wǎng)絡(luò)的普及和金融科技的深入發(fā)展，人們的生活已經(jīng)被逐步改變，使用手機(jī)支付、辦公、購物、娛樂等成為主流方式。根據(jù)中國互聯(lián)網(wǎng)絡(luò)信息中心發(fā)布的第41次《中國互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計(jì)報(bào)告》截至2017年12月，我國手機(jī)網(wǎng)民規(guī)模達(dá)7.53億，網(wǎng)民中使用手機(jī)上網(wǎng)人群的占比由2016年的95.1%提升至97.5%。隨著移動終端在日常生活中承擔(dān)的數(shù)字金融業(yè)務(wù)越來越多，其安全性越來越受到重視。概述早在2012年，央行就發(fā)布了金融行業(yè)移動支付標(biāo)準(zhǔn)，涵蓋了應(yīng)用基礎(chǔ)、安全保障、設(shè)備、支付應(yīng)用、聯(lián)網(wǎng)通用5大類35項(xiàng)標(biāo)準(zhǔn)，并從產(chǎn)品形態(tài)、業(yè)務(wù)模式、聯(lián)網(wǎng)通用、安全保障等方面明確了系統(tǒng)化的技術(shù)要求，覆蓋中國金融移動支付各個環(huán)節(jié)的基礎(chǔ)要素、安全要求和實(shí)現(xiàn)方案，確立了以“聯(lián)網(wǎng)通用、安全可信”為目標(biāo)的技術(shù)體系架構(gòu)。2017年，泰爾終端實(shí)驗(yàn)室依據(jù)相關(guān)標(biāo)準(zhǔn)對多款基于Android操作系統(tǒng)的手機(jī)銀行APP進(jìn)行了安全測評，其測評內(nèi)容包括通信安全性、鍵盤輸入安全性、客戶端運(yùn)行時安全性、客戶端安全防護(hù)、代碼安全性和客戶端業(yè)務(wù)邏輯安全性等6個方面的39項(xiàng)內(nèi)容，分析評測結(jié)果不容樂觀，如圖12-1所示。圖12-1 泰爾終端實(shí)驗(yàn)室2017年對幾大金融APP測試在報(bào)告的最后，該實(shí)驗(yàn)室建議相關(guān)銀行采取更加安全的APP加固解決方案，同時增加應(yīng)用分發(fā)渠道監(jiān)控，第一時間監(jiān)測盜版、篡改應(yīng)用發(fā)布上線；增加應(yīng)用自身完整性校驗(yàn)功能，檢測到應(yīng)用被篡改后，及時提醒用戶卸載非法應(yīng)用或者自動進(jìn)行更新修復(fù)。我們把移動安全問題分兩個話題來闡述：APP開發(fā)安全，APP業(yè)務(wù)安全。APP開發(fā)安全APP應(yīng)用安全，除了我們所熟知的APP加殼外，還有一些是應(yīng)用程序本身的安全問題，例如組件安全、端口安全、數(shù)據(jù)安全等，甚至還有一些跟業(yè)務(wù)場景相關(guān)的。這里我們說一下APP開發(fā)中經(jīng)常遇到的問題與相應(yīng)對策。AndroidManifest配置安全每個Android應(yīng)用的根目錄中都必須包含一個AndroidManifest.xml文件。Manifest文件為Android系統(tǒng)提供有關(guān)應(yīng)用的基本信息，系統(tǒng)必須獲得這些信息才能運(yùn)行任意應(yīng)用代碼。此外，Manifest文件還可執(zhí)行以下操作：為應(yīng)用的Java軟件包命名。軟件包名稱充當(dāng)應(yīng)用的唯一標(biāo)識符。描述應(yīng)用的各個組件，包括構(gòu)成應(yīng)用的Activity實(shí)現(xiàn)每個組件的類命名并發(fā)布其功能。根據(jù)這些聲明，Android系統(tǒng)可以了解這組件具體是什么，以及在什么條件下可以啟動它們。確定將托管應(yīng)用組件的進(jìn)程。聲明應(yīng)用必須具備哪些權(quán)限才能訪問API中受保護(hù)的部分并與其他應(yīng)用交互。聲明其他應(yīng)用與該應(yīng)用組件交互所需具備的權(quán)限。類，這些類可在應(yīng)用運(yùn)行期間提供分析和其他信息。這些聲明只會在應(yīng)用處在開發(fā)和測試階段時出現(xiàn)在清單文件中，在應(yīng)用發(fā)布之前會被刪除。聲明應(yīng)用所需的最低AndroidAPI級別。列出應(yīng)用必須鏈接的庫。我們所熟知的導(dǎo)出組件，是Android上最常見也是門檻最低的攻擊入口，如Manifest中組件設(shè)置不當(dāng)?shù)脑?，就存在被任意調(diào)用的可能。此外，在Manifest配置文件中，還有一些可被調(diào)試的程序、可被導(dǎo)出的應(yīng)用數(shù)據(jù)以及與Scheme相關(guān)的配置開關(guān)，一旦開啟就會存在一些風(fēng)險(xiǎn)，筆者將常見的風(fēng)險(xiǎn)與對策整理成表格供讀者參考，如表12-1所示。表12-1 Manifest配置不當(dāng)類風(fēng)險(xiǎn)與對策Activity組件安全Activity組件是Android四大組件中用戶唯一能夠看見的組件，作為軟件所有功能的顯示及與用戶交互的載體，其安全性不言而喻。除了前面說的組件導(dǎo)出暴露問題外，主要是訪問權(quán)限控制和被劫持問題。當(dāng)Activity組件需要被外部特定程序調(diào)用時，建議使用android:permission屬性來指定一個權(quán)限字符串。在啟動Activity時，加入標(biāo)志位FLAG_ACTIVITY_NEW_TASK，就能使該Activity置于棧Activity，偵測到目標(biāo)Activity啟動后，立即彈出一個與該應(yīng)用界面相同的Activity，實(shí)現(xiàn)偽裝目標(biāo)Activity，也就是我們所說的“被劫持”問題。針對Activity劫持目前沒有特別好的辦法徹底解決，一個思路是在APP一些關(guān)鍵界面（比如登錄界面）被覆蓋時彈出一些提示信息，進(jìn)入后臺的時候判斷是不是用戶自己觸發(fā)，如果不是也彈出提示信息。Service組件安全Service組件是Android系統(tǒng)中的后臺進(jìn)程，主要的功能是在后臺進(jìn)行一些耗時的操作。建議私有Service不定義intent-filter并且設(shè)置exported為false，需要被同公司不同APP訪問時，可以將protectionLevel設(shè)置為signature；如果是合作伙伴APP訪問，需要對其APP簽名做校驗(yàn)。若存在Service返回?cái)?shù)據(jù)的情況，則需要關(guān)注敏感信息泄露風(fēng)險(xiǎn)。Provider組件安全ContentProvider組件是Android應(yīng)用的重要組件之一，管理對數(shù)據(jù)的訪問，主要用于不同的應(yīng)用程序之間實(shí)現(xiàn)數(shù)據(jù)共享。ContentProvider的數(shù)據(jù)源不止包括SQLite數(shù)據(jù)庫，還可以是文件數(shù)據(jù)。通過將數(shù)據(jù)儲存層和應(yīng)用層分離，ContentProvider為各種數(shù)據(jù)源提供了一個通用的接口。參見表12-2，如果在AndroidManifest文件中將某個ContentProvider的exported屬性設(shè)置為true，就會產(chǎn)生一些越權(quán)訪問數(shù)據(jù)的風(fēng)險(xiǎn)。訪問對象的不同結(jié)合App實(shí)現(xiàn)不當(dāng)，可能會產(chǎn)生數(shù)據(jù)任意訪問、SQL注入、目錄遍歷等風(fēng)險(xiǎn)。私有權(quán)限定義錯誤導(dǎo)致數(shù)據(jù)被任意訪問私有權(quán)限定義經(jīng)常發(fā)生的風(fēng)險(xiǎn)是：定義了私有權(quán)限，但是根本沒有定義私有權(quán)限的級別，或者定義的權(quán)限級別不夠，導(dǎo)致惡意應(yīng)用只要聲明這個權(quán)限就能夠訪問相應(yīng)的ContentProvider提供的數(shù)據(jù)，造成數(shù)據(jù)泄露。本地SQL注入漏洞當(dāng)ContentProvider的數(shù)據(jù)源是SQLite數(shù)據(jù)庫時，如果實(shí)現(xiàn)不當(dāng)，而Provider又是暴露的，則可能會引發(fā)本地SQL注入漏洞。具體來說，ContentProvider的query()如果使用拼接字符串組成的SQL語句去查詢底層的SQLite數(shù)據(jù)庫時，容易發(fā)生SQL注入。目錄遍歷漏洞對外暴露的ContentProvider實(shí)現(xiàn)了OpenFile()接口，因此其他有相應(yīng)調(diào)用該ContentProvider權(quán)限的應(yīng)用即可調(diào)用ContentProvider的OpenFile()接口進(jìn)行文件數(shù)據(jù)訪問。但是如果沒有進(jìn)行ContentProvider訪問權(quán)限控制和對訪問的目標(biāo)文件的URI進(jìn)行有效判斷，攻擊者利用“../”實(shí)現(xiàn)目錄遍歷便可訪問任意可讀文件。更有甚者，在Openfile()接口的實(shí)現(xiàn)中，如果要訪問的文件不存在，就會創(chuàng)建此文件，也就是說還有可能往手機(jī)設(shè)備可寫目錄中寫入任意數(shù)據(jù)。針對以上問題，最重要的是要在APP設(shè)計(jì)開發(fā)之前，就要清楚哪些Provider的數(shù)據(jù)是用戶隱私數(shù)據(jù)或者其他重要數(shù)據(jù)，考慮是否要提供給外部應(yīng)用使用，如果不需要提供，則應(yīng)直接在Manifest文件中設(shè)置為不導(dǎo)出。注意：由于APIlevel在17以下的所有應(yīng)用的“android:exported”屬性默認(rèn)值都為true，因此如果應(yīng)用的ContentProvider不必導(dǎo)出，建議顯式設(shè)置注冊的ContentProvider組件的“android:exported”屬性為false。如果必須要有數(shù)據(jù)提供給外部應(yīng)用，則需要做好權(quán)限控制，明確什么樣的外部應(yīng)用可以使用，盡量不要提供用戶隱私敏感信息。一般來講，大部分開放的Provider，都是提供給本公司其他應(yīng)用使用，一般打包簽名APP的簽名證書是一致的，這樣便可以將Provider的ProtectionLevel設(shè)置為signature。如果是合作方的APP來訪問，可以將合作方APP的簽名哈希值預(yù)埋在提供Provider的APP中，提供Provider的APP要檢查請求訪問此Provider的APP的簽名，匹配通過了才能訪問。為了避免SQL語句，不要使用拼接字符串的形式，可以使用SQLiteDatabase類中的參數(shù)化查詢query()方法。為了防止目錄遍歷，建議去除ContentProvider中的OpenFile()接口，過濾限制跨域訪問，對訪問的目標(biāo)文件路徑進(jìn)行有效判斷，過濾“../”等字符串。BroadcastReceiver組件安全BroadcastReceiver中文被譯為廣播接收者，用于處理接收到的廣播，廣播接收者的安全分為接收安全與發(fā)送安全兩個方面。接收安全動態(tài)注冊廣播如果僅為應(yīng)用內(nèi)部使用，應(yīng)當(dāng)將exported設(shè)置為false，這樣外部應(yīng)用不能隨便發(fā)送廣播到自身程序中。如果需要接收外部應(yīng)用，則需要配置權(quán)限，和前面Provider的一樣，如果是本公司其他APP，將ProtectionLevel設(shè)置為signature；如果是其他合作伙伴的APP，則除了設(shè)置ProtectionLevel外還建議避免敏感信息的傳遞。發(fā)送安全Android系統(tǒng)提供了兩種廣播發(fā)送方法，即sendOrderedBroadcast和sendBroadcast。有序廣播通過Context.sendOrderedBroadcast()來發(fā)送，所有的廣播接收器優(yōu)先級依次執(zhí)行，廣播接收器的優(yōu)先級通過receiver的intent-filter中的android:priority屬性來設(shè)置，數(shù)值越大優(yōu)先級越高。當(dāng)廣播接收器接收到廣播后，可以使用setResult()函數(shù)來將結(jié)果傳給下一個廣播接收器接收，然后通過getResult()函數(shù)取得上個廣播接收器接收返回的結(jié)果。當(dāng)廣播接收器接收到廣播后，也可以用abortBroadcast()函數(shù)讓系統(tǒng)攔截下該廣播，并將該廣播丟棄，使該廣播不再傳送到別的廣播接收器接收。普通廣播是完全異步的，通過Context的sendBroadcast()方法來發(fā)送，消息傳遞效率比較高，但所有receivers（接收器）的執(zhí)行順序不確定。接收器不能將處理結(jié)果傳遞給下一個接收器，并且無法終止廣播Intent的傳播，直到?jīng)]有與之匹配的廣播接收器為止。Android官方在SDK文檔中說明了一些不安全的API，包括：sendStickyBroadcast、sendStickyOrderedBroadcast、sendStickyOrderedBroadcastAsUser、sendStickyBroadcastAsUser，建議不要在APP使用。WebView組件安全WebView是一個基于Webkit引擎、展現(xiàn)Web頁面的組件，APP通過調(diào)用該組件就可以訪問網(wǎng)頁內(nèi)容，所以有非常多的移動應(yīng)用都內(nèi)嵌了WebView組件。而在通付盾發(fā)布的《2017年度移動應(yīng)用安全態(tài)勢報(bào)告》中，與WebView組件相關(guān)的漏洞是排名前三的，分別是：未移除有風(fēng)險(xiǎn)的WebView系統(tǒng)隱藏接口，WebView遠(yuǎn)程代碼執(zhí)行安全，WebView組件忽略SSL證書驗(yàn)證錯誤漏洞，如圖12-2所示。圖12-2 Android移動應(yīng)用高危漏洞類型分布WebView在Android應(yīng)用開發(fā)中廣泛使用，除了具有一般View的屬性和設(shè)置外，還可對URL請求、頁面加載、渲染、頁面交互進(jìn)行處理，可謂功能強(qiáng)大。對黑客而言，它是一個非常理想的攻擊面，點(diǎn)開一個鏈接或者掃描一個二維碼就會執(zhí)行惡意代碼。在使用WebView組件過程中，除了一些系統(tǒng)隱藏接口，還會有一些與本地交互、保存密碼、HTTPS通信認(rèn)證相關(guān)的風(fēng)險(xiǎn)需要關(guān)注，為了節(jié)省篇幅，筆者整理了一個WebView組件常見風(fēng)險(xiǎn)與對策表格，見表12-2。表12-2 WebView組件相關(guān)風(fēng)險(xiǎn)與對策值得注意的是，AndroidN中增加了一個開發(fā)者選項(xiàng)，就是在所有的應(yīng)用中將Web-View的渲染進(jìn)程運(yùn)行在獨(dú)立的沙箱中。即使惡意網(wǎng)頁通過漏洞在渲染進(jìn)程中執(zhí)行了代碼，還需要更多的漏洞繞過沙箱的限制。這一特性將在AndroidO中默認(rèn)啟用。但在這一緩解措施正式部署到大部分設(shè)備之前，通過攻擊WebView獲得遠(yuǎn)程代碼執(zhí)行進(jìn)而直接攻擊應(yīng)用仍然是可行的。APP業(yè)務(wù)安全釣魚APP等各種問題，這里涉及一些混淆、加殼、簽名驗(yàn)證、運(yùn)行時環(huán)境檢測等技術(shù)方鍵盤等。代碼安全系統(tǒng)的封閉及嚴(yán)格的APP審核及簽名控制，Android系統(tǒng)的開源以及基于Java的特性，導(dǎo)致APP在Android上更容易被反編譯。目前常用的一些反編譯工具（比如APKTool、dex2jar等）能夠毫不費(fèi)勁地還原Java里的明文信息，Native里的庫信息也可以通過objdump或IDA獲取。而心懷不軌的人可能會通過反編譯后加入惡意的代碼邏輯，重新打包一個APK文件去發(fā)布安裝，也就是我們常說的“二次打包”問題。針對這些問題，常見的解決方案是代碼混淆、加殼、反調(diào)試、簽名驗(yàn)證等。代碼混淆APP的代碼混淆包括Java代碼的混淆以及一些資源文件的混淆。Java語言編寫的代碼本身就容易被反編譯，Google很早就意識到這一點(diǎn)，在Android2.3的SDK中正式加入了ProGuard代碼混淆工具，開發(fā)人員可以使用它對自己的代碼進(jìn)行保護(hù)。ProGuard提供了壓縮、混淆、優(yōu)化代碼以及反混淆棧跟蹤的功能，網(wǎng)上資料較多，不再贅述。資源文件的混淆，一些互聯(lián)網(wǎng)公司也提供了一些方法供參考，比如微信提供的AndResGuard（\h/shwenzhang/AndResGuard）等。加殼加殼分為dex加殼和對native編譯（即so文件加殼），主流的加殼技術(shù)基本可以分為四代：加殼。對classes.dex文件進(jìn)行整體加殼加密，存放在APK的資源中，運(yùn)行時將加密后的classes.dex文件在內(nèi)存中解密，并讓Dalvik虛擬機(jī)動態(tài)加載執(zhí)行。防調(diào)試防Dump。整體dex在內(nèi)存中解密，黑客通過內(nèi)存Dump出現(xiàn)了防調(diào)試、防內(nèi)存Dump的技術(shù)。classes.dex文件中的方法、函數(shù)進(jìn)行抽取加密，在Java虛擬機(jī)執(zhí)行具體某個方法時才將其動態(tài)解密，并以不連續(xù)的方式存放到內(nèi)存中。后面慢慢發(fā)展成將Java代碼內(nèi)關(guān)鍵算法、業(yè)務(wù)邏輯等函數(shù)自動轉(zhuǎn)化成C++代碼進(jìn)行防護(hù)。VMP加殼/so加殼。我們知道程序的執(zhí)行，是依靠CPU對于符合規(guī)范的指令集的解析處理。如果將原指令集通過自定義規(guī)范進(jìn)行變形處理，生成新的指令集（稱之為虛擬指令集），CPU將無法識別虛擬指令。此時若配合能夠解析虛擬指令集的解釋器（機(jī)），就可以達(dá)到不直接通過CPUVMP保護(hù)方案的基本原理。對于使用AndroidNDK編寫的Native代碼，逆向它原本就有一定的困難，如果再添加外殼保護(hù)（比如UPX）則更加困難了。不同的加殼方案有著不同的效果，表12-3是某廠商網(wǎng)站上的風(fēng)險(xiǎn)描述表。表12-3 某官網(wǎng)提供的APP加固風(fēng)險(xiǎn)表目前市面上有很多APP加固平臺，像360、百度、騰訊、網(wǎng)易盾、阿里聚安全等為免費(fèi)的，像愛加密、梆梆、幾維、頂象科技等為收費(fèi)的。從事安全的讀者肯定會關(guān)注網(wǎng)上各類破解文章，比如圖12-3這個針對360加固的秒脫。圖12-3 加固后的對抗其實(shí)筆者想說的是，APP加固的目的是提升對手的攻擊成本，如果通過加固能讓相當(dāng)一部分人知難而退，就達(dá)到APP加固本身的效果了。在實(shí)際工作中，考慮到APP內(nèi)部復(fù)雜的業(yè)務(wù)場景和升級機(jī)制，有一些加固方案可能會存在一定的兼容性問題，用戶體驗(yàn)要求高的場景可能還會追求運(yùn)行速度，因此需要慎重權(quán)衡。一般的思路是在APP上進(jìn)行各種埋點(diǎn)，結(jié)合后端大數(shù)據(jù)風(fēng)控來降低安全風(fēng)險(xiǎn)。反調(diào)試調(diào)試器檢測，一般是利用android.os.Debug.isDebuggerConnected()這個API來判斷，還有一些其他的思路，比如調(diào)用Android中flag屬性ApplicationInfo.FLAG_DEBUGGABLE判斷是否屬于debug模式，循環(huán)檢查android_server調(diào)試端口和進(jìn)程信息，循環(huán)檢查自身status中的TracePid字段值等。此外，還有檢測模擬器，檢測設(shè)備是否已經(jīng)ROOT。模擬器檢測技術(shù)，一般是取一些模擬器特征，例如通過電話管理器攻取設(shè)備IMEI、IMSI，判斷設(shè)備配置信息與Android模擬器設(shè)備配置默認(rèn)值是否相同，檢測設(shè)備是否有安裝藍(lán)牙設(shè)備硬件，判斷當(dāng)前設(shè)備WIFIMAC地址，檢測是否具有QEMU虛擬機(jī)通道文件等。ROOT檢測一般的思路是，看ROOT后的手機(jī)會有哪些特征，比如，檢測su文件是否存在及可以執(zhí)行，檢測是否安裝Superuser.apk等。但實(shí)際情況是，Android碎片化非常嚴(yán)重，國產(chǎn)手機(jī)廠商特別喜歡修改原生ROM，這會導(dǎo)致一些檢測方法失效，需要關(guān)注。簽名驗(yàn)證簽名驗(yàn)證主要是為了防止二次打包，Android簽名驗(yàn)證一般有三種方法：Java層驗(yàn)證，即在Java側(cè)。但是Java代碼容易被反編譯，這個校驗(yàn)邏輯可能被篡改。NDK層驗(yàn)證，即在Native代碼實(shí)現(xiàn)公鑰信息的比對，比對的樣本進(jìn)行加密存儲。我們知通過反匯編生成的ARM代碼，相對smali被篡改的難度更大，再結(jié)合so文件加固，可以進(jìn)一步增強(qiáng)反編譯難度。服務(wù)端驗(yàn)證，即程序通過特定方法檢測獲取自身代碼校驗(yàn)值，上送云端服務(wù)器進(jìn)行比較，從而驗(yàn)證合法性。這樣針對那些非法或偽造、篡改過的客戶端，服務(wù)端可以直接拒絕服務(wù)，進(jìn)一步保障安全。數(shù)據(jù)安全針對APP，我們通常說的敏感信息包含兩方面：一是用戶敏感信息，比如用戶名、密碼、手機(jī)號、郵箱、身份證、銀行卡、住址等；二是APP本身的一些敏感信息，包括產(chǎn)品核心算法、核心業(yè)務(wù)邏輯、私鑰、本地存儲的證書、加密算法等。這些敏感信息都需要在設(shè)計(jì)APP時考慮嚴(yán)格保護(hù)，在存儲、使用、傳輸過程中也要考慮保護(hù)方法。數(shù)據(jù)存儲安全Android有外部存儲和內(nèi)部存儲之分，外部存儲安全隱患比較大，任何軟件只需要在AndroidManifest.xml中聲明如下一行權(quán)限就可以在外部存儲設(shè)備上讀寫。<uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>筆者建議涉及用戶隱私哪怕是已經(jīng)加密過的也不要保存到外部存儲設(shè)備上，還有一些APP會動態(tài)加載一些外部資源，這些外部資源可能保存在外部存儲上，建議在加載時驗(yàn)證文件完整性。在做代碼審計(jì)的時候，關(guān)注getExternalStorageState、getExternal-StorageDirectory等關(guān)鍵函數(shù)就能定位到APP使用外部存儲的代碼邏輯。內(nèi)部存儲是所有軟件存放私有數(shù)據(jù)的地方，AndroidSDK中提供了openFileInput()與openFileOutput()方法來讀寫程序的私有數(shù)據(jù)目錄。openFileOutput()方法的第二個參數(shù)指定了文件創(chuàng)建模式，如果使用了MODE_WORLD_READABLE或MODE_WORLD_WRITEABLE，就可能導(dǎo)致敏感信息泄露。除了File方式外，Android還提供了SharedPreference、SQLite、ContentProvider方式進(jìn)行數(shù)據(jù)存儲。與openFileOutput()方法一樣，SharedPreference的getSharedPreferences方法打開文件時第二個參數(shù)如果設(shè)置為MODE_WORLD_READABLE或MODE_WORLD_WRITEABLE都存在一樣的問題。相應(yīng)的對策就是在使用openFileOutput()和getSharedPreferences()打開文件時，將第二個參數(shù)設(shè)置為MODE_PRIVATE，這樣就可以利用Linux的文件權(quán)限機(jī)制來確保數(shù)據(jù)不被其他進(jìn)程訪問。注意：單單依靠MODE_PRIVATE模式是不夠的，因?yàn)榭赡芪覀兊腁PP運(yùn)行在一個已經(jīng)被Root的加密措施。敏感數(shù)據(jù)需要保護(hù)，基本上都是加密處理，當(dāng)然有一些場合如日志打印包括logcat不允許出現(xiàn)敏感信息，這是常識，無需多言。AndroidSDK提供了一些API供加密使用，這些API和JAVA提供的基本相似，由JavaCryptographyArchitecture（JCA，Java加密體系結(jié)構(gòu)）、JavaCryptographyExtension（JCE，Java加密擴(kuò)展包）、JavaSecureSocketsExtension（JSSE，Java安全套接字?jǐn)U展包）、JavaAuthenticationandAuthenticationService（JAAS，Java鑒別與安全服務(wù)）組成。JCA提供基本的加密框架，如證書、數(shù)字簽名、消息摘要和密鑰對產(chǎn)生器等；JCE擴(kuò)展了JCA，提供了各種加密算法、摘要算法、密鑰管理等功能；JSSE提供了基于SSL（安全套接層）的加密功能，供HTTPS加密傳輸使用；JAAS提供了在Java平臺上進(jìn)行用戶身份鑒別的功能，除此外，Android還提供了android.security和android.security.keystore來管理keychain和keystore。如果使用SQLite數(shù)據(jù)庫的時候需要加密，可以使用SQLCipher方案。SQLCipher是個獨(dú)立的SQLite數(shù)據(jù)庫實(shí)現(xiàn)，但它并沒有自己實(shí)現(xiàn)一套加密算法，而是使用了OpenSSL的libcrypto庫，兼容性更好。關(guān)于加密算法的選擇和使用，業(yè)界有如下安全建議：base64只是一種編碼方式，并不是加密算法。Random類，使用SecureRandom類的時候，不要調(diào)用setSeed方法，即不要設(shè)置種子。MD2、MD4、MD5、SHA-1、RIPEMD算法來加密用戶密碼等敏感信息，因?yàn)榫W(wǎng)上有大量的庫可以用來破解，建議使用SHA-256、SHA-3算法。使用消息認(rèn)證算法時，建議使用HMAC-SHA256算法，避免使用CBC-MAC。使用對稱加密算法時，不建議使用DES，建議使用AES顯式指定為CBC或CFB模式，不要使用默認(rèn)的ECB模式。非對稱算法使用RSA時，建議密鑰長度不低于512，同時注意重放攻擊。使用基于口令的加密算法PBE時，生成密鑰時要加鹽，鹽的取值最好來自SecureRandom，并指定迭代次數(shù)。關(guān)于密鑰保護(hù)，直接明文寫在配置里肯定是不行的；硬編碼在Java代碼中通過dex也容易逆向；將密鑰放在so文件里也還是面臨IDA破解。為了保護(hù)密鑰，各種千奇百怪的方法都有了，比如將一部分寫到文件中，一部分寫在Java代碼或C層代碼，這只是在一定程度上增加了逆向難度而已。有的利用so將密鑰再進(jìn)行二次加密保護(hù)，那這一層的密鑰保護(hù)又是一個問題。針對這些問題，不得不提一下白盒加密技術(shù)。白盒加密屬于對稱加密，通過將算法和密鑰緊密捆綁在一起，由算法和密鑰生成一個加密表和一個解密表，然后可以獨(dú)立用查找加密表來加密，用解密表來解密，不再依賴于原來的加解密算法和密鑰。正是由于算法和密鑰的合并，所有可以有效隱藏密鑰，與此同時也混淆了加密邏輯。數(shù)據(jù)傳輸安全一般客戶端使用HTTPS與服務(wù)端進(jìn)行通信，網(wǎng)站啟用SSLsitewide（useHTTPSonly）或HSTS(HTTPStrictTransportSecurity)，否則存在SSLStrip（HTTPS降級為HTTP）攻擊風(fēng)險(xiǎn)。由于前面在12.2.6節(jié)中講過相關(guān)的問題及對策，這里就不再過多重復(fù)。對于敏感信息，建議除了HTTPS傳輸加密外，還需要在應(yīng)用中進(jìn)行加密保護(hù)，多一層保障。其他話題安全輸入鍵盤智能手機(jī)輸入需要依靠虛擬鍵盤，而虛擬鍵盤則由具體使用的輸入法控制。金融行業(yè)APP，密碼往往涉及金錢，為了確保輸入安全，一些企業(yè)會自行開發(fā)安全輸入鍵盤，圖12-4為某行APP的安全鍵盤效果圖。這樣當(dāng)用戶輸入密碼的時候，處于自行開發(fā)的密碼鍵盤保護(hù)之下，確保用戶密碼安全。當(dāng)然除了密碼，還有其他的輸入數(shù)據(jù)也需要保護(hù)，圖12-5是某行APP的安全鍵盤在輸入身份證時的效果圖。注意這上面的鍵盤數(shù)字布局，是隨機(jī)的，每次都會變化。什么時候隨機(jī)，什么時候不隨機(jī)，需要在用戶體驗(yàn)和安全之間進(jìn)行權(quán)衡。防截屏為了防止惡意軟件通過秘密截屏的方式得到一些APP上顯示的信息，就需要對截屏進(jìn)行處理。Android系統(tǒng)沒有提供對截屏事件監(jiān)聽的接口，也沒有提供對應(yīng)的廣播，現(xiàn)在主流的思路是，基于截屏中所做的動作針對性地進(jìn)行檢測，比如，利用FileObserver監(jiān)聽某目錄資源變化，利用ContentObserver監(jiān)聽全部資源變化，利用Activity.onPause()機(jī)制等。當(dāng)發(fā)現(xiàn)有截屏?xí)r做一些處理，比如用純黑色圖片對象進(jìn)行覆蓋處理。圖12-4 安全輸入鍵盤例1圖12-5 安全輸入鍵盤例2除此之外，Android提供了一個對應(yīng)的API，直接禁用截屏功能，只需要獲取到相應(yīng)的Window對象，給其添加一個FLAG_SECURE的flag即可。注意這個FLAG_SECURE是應(yīng)用在Window對象上的，如果Activity有一些彈窗或突出的UI元素可能不受它保護(hù)，需要再單獨(dú)設(shè)置。釣魚APP釣魚APP問題在早些年比較多，隨著惡意APP越來越多，為規(guī)范并促進(jìn)AndroidAPP安全加固領(lǐng)域的健康發(fā)展，CNCERT牽頭制定了通信行業(yè)標(biāo)準(zhǔn)2015-0217T-YD《移動互聯(lián)網(wǎng)應(yīng)用程序安全加固能力評估要求與測試方法》，這個標(biāo)準(zhǔn)對提供AndroidAPP加固服務(wù)的系統(tǒng)提出了以下要求：禁止對惡意APP進(jìn)行加固。要求對APP加固提交者進(jìn)行身份驗(yàn)證。要求具備對加固前APP進(jìn)行追查的能力。通過對加固服務(wù)提供商進(jìn)行規(guī)范來防止釣魚APP，是一個不錯的思路。小結(jié)本章針對移動應(yīng)用安全問題從開發(fā)安全、業(yè)務(wù)安全的視角進(jìn)行了討論，希望讀者閱讀完能對移動應(yīng)用安全有一個基本的認(rèn)識，對技術(shù)細(xì)節(jié)感興趣的讀者可能還需要進(jìn)一步閱讀更專業(yè)的書籍進(jìn)行提升。第3章企業(yè)內(nèi)網(wǎng)安全企業(yè)出于不同安全防護(hù)等級的考慮，一般都會將內(nèi)網(wǎng)劃會為辦公網(wǎng)、生產(chǎn)網(wǎng)、測試網(wǎng)、互聯(lián)網(wǎng)、外聯(lián)網(wǎng)等不同的區(qū)域，之間通過防火墻進(jìn)行隔離。本章會先從基礎(chǔ)的安全域開始討論，然后對終端、網(wǎng)絡(luò)、服務(wù)器和重點(diǎn)應(yīng)用進(jìn)行闡述，最后會針對漏洞、蜜罐這兩個話題單獨(dú)展開。安全域網(wǎng)絡(luò)安全域是指同一系統(tǒng)內(nèi)有相同的安全保護(hù)需求，相互信任，并具有相同的安全訪問控制和邊界控制策略的子網(wǎng)或網(wǎng)絡(luò)，相同的網(wǎng)絡(luò)安全域共享一樣的安全策略。廣義的安全域是指具有相同業(yè)務(wù)要求和安全要求的IT系統(tǒng)要素的集合。IT系統(tǒng)要素包括網(wǎng)絡(luò)區(qū)域、主機(jī)和系統(tǒng)、物理環(huán)境、人和組織、策略和流程，因此不能將安全域僅僅理解為網(wǎng)絡(luò)安全域。安全域的劃分使整體網(wǎng)絡(luò)有了清楚的規(guī)劃，具有以下實(shí)際的目標(biāo)：使整體網(wǎng)絡(luò)結(jié)構(gòu)清晰。使具有相同安全防護(hù)要求的網(wǎng)絡(luò)和系統(tǒng)處于同一安全子域中。不同安全子域內(nèi)可方便地部署不同等級的安全防護(hù)策略。同一安全域內(nèi)可方便地部署相同等級的安全防護(hù)策略。各區(qū)域防護(hù)重點(diǎn)明確，將有效的安全資源投入到最需要保護(hù)的資產(chǎn)上。入，有利于網(wǎng)絡(luò)的有序擴(kuò)展。使數(shù)據(jù)流簡潔規(guī)范，有利于區(qū)分不同種類數(shù)據(jù)流，便于實(shí)施安全訪問控制和QoS安全域的理論和方法所遵循的根本原則如下：全的同時，還要保障業(yè)務(wù)的正常運(yùn)行和運(yùn)行效率。結(jié)構(gòu)簡化原則。安全域方法的直接目的和效果是要將整個網(wǎng)絡(luò)變得更加簡單，簡單的網(wǎng)絡(luò)結(jié)構(gòu)便于設(shè)計(jì)防護(hù)體系。的安全等級、安全環(huán)境、安全策略等。立體協(xié)防原則。安全域的主要對象是網(wǎng)絡(luò)，但是圍繞安全域的防護(hù)需要考慮在各個層次法實(shí)現(xiàn)協(xié)防。化；另外，在安全域的建設(shè)和調(diào)整過程中要考慮工程化管理。資源整合原則。在保障安全的前提下安全域的劃分要有利于實(shí)現(xiàn)IT現(xiàn)IT資源的共享和復(fù)用。安全域的劃分是一個既非?；A(chǔ)又非常重要的工作，企業(yè)按自己的實(shí)際情況劃分不同的安全域，同時還需要制定各安全域的安全策略并加以實(shí)現(xiàn)。表13-1將辦公網(wǎng)和業(yè)務(wù)網(wǎng)進(jìn)行了梳理，其他安全域也可以參照并建立類似的安全策略表。表13-1 辦公網(wǎng)和業(yè)務(wù)網(wǎng)的安全策略表對不同安全域間的訪問，通過部署各類安全解決方案，實(shí)現(xiàn)阻斷、檢測和過濾等功能，為上層安全防護(hù)功能的實(shí)現(xiàn)提供保障。終端安全內(nèi)網(wǎng)終端是我們?nèi)粘９ぷ鹘佑|最多的設(shè)備，也是企業(yè)內(nèi)網(wǎng)安全防護(hù)需要重點(diǎn)關(guān)注的戰(zhàn)場之一。終端用什么樣的操作系統(tǒng)，允許安裝什么樣的軟件，系統(tǒng)和軟件補(bǔ)丁怎么打，用戶的權(quán)限是管理員還是普通用戶，必須滿足什么條件才允許接入內(nèi)網(wǎng)，滿足什么條件才允許訪問互聯(lián)網(wǎng)，惡意軟件查殺，各種外設(shè)管控等等，都是終端安全領(lǐng)域不可回避的話題，也有很多基礎(chǔ)的工作要做。有些企業(yè)采用各種封堵的技術(shù)方案來控制，比如，終端電腦不允許上外網(wǎng)、不允許使用U盤、外發(fā)郵件需要審批等；還有的企業(yè)考慮到人力成本，往往將一些基礎(chǔ)工作外包出去，普通用戶沒有管理員權(quán)限，需要安裝軟件時會有專門的人提供支持。我們不去評判其好壞優(yōu)劣，畢竟鞋子合不合腳只有自己才知道。終端安全涉及資產(chǎn)管理、補(bǔ)丁管理、終端準(zhǔn)入、防病毒、外設(shè)管控、上網(wǎng)行為管理等諸多內(nèi)容，每一個話題又是一個細(xì)分的領(lǐng)域。對企業(yè)敏感數(shù)據(jù)保護(hù)有要求的企業(yè)，往往在終端上還會部署一些文檔加密、DLP類的程序。終端標(biāo)準(zhǔn)化做得不好的企業(yè)，可能終端上的環(huán)境非常復(fù)雜，尤其是安全軟件相互“打架”產(chǎn)生的兼容性問題。為了不陷入其中，我們以攻擊者的視角，來看終端安全需要關(guān)注的技術(shù)點(diǎn)。注意這里有一個假設(shè)的前提：終端資產(chǎn)的重要性（包括擁有的數(shù)據(jù)價值）遠(yuǎn)不如后臺服務(wù)器，所以攻擊者往往都會以終端為跳板進(jìn)行深入。我們以圖13-1所示的終端安全為例進(jìn)行分析。圖13-1 終端安全威脅終端在辦公網(wǎng)前臺區(qū)域，存在的風(fēng)險(xiǎn)主要包括以下幾個場景：場景一 終端用戶私接U盤，U盤所帶的木馬病毒在辦公網(wǎng)中傳播，進(jìn)一步感染辦公網(wǎng)臺重要服務(wù)器。場景二 終端用戶通過3G上網(wǎng)卡或隨身WiFi設(shè)備私接互聯(lián)網(wǎng)，無意感染病毒被黑客遠(yuǎn)控制，黑客以此為跳板進(jìn)一步侵入企業(yè)內(nèi)部。場景三 終端用戶通過上網(wǎng)防火墻訪問互聯(lián)網(wǎng)，無意感染病毒被黑客遠(yuǎn)程控制，黑客以為跳板進(jìn)一步侵入企業(yè)內(nèi)部。針對場景一，我們的對策是：操作系統(tǒng)基線配置，不允許應(yīng)用程序直接從U盤、光盤自動啟動，結(jié)合防病毒軟件進(jìn)行查殺。針對場景二，我們的對策是：結(jié)合終端外設(shè)管理封禁無線、藍(lán)牙等功能，防止非法外連，同時在終端上部署外連探測程序，檢測網(wǎng)絡(luò)連通性以發(fā)現(xiàn)非法外連的可疑行為。針對場景三，我們的對策略是：上網(wǎng)通過沙盒虛擬桌面上網(wǎng)，結(jié)合上網(wǎng)行為、下一代防火墻對惡意域名、地址及惡意文件進(jìn)行攔截。當(dāng)然，用戶訪問的惡意URL可能來自于郵件系統(tǒng)，可以在郵件系統(tǒng)中提前干預(yù)，不讓這類URL來到終端。如果那個假設(shè)前提不成立，即終端上有比較重要的數(shù)據(jù)，除了上面提到的對策使之進(jìn)不14章進(jìn)行闡述。在企業(yè)中，有一些特殊終端電腦需要關(guān)注，往往其使用者身份較高，安全執(zhí)行不到位或者執(zhí)行困難的企業(yè)，往往對這類人采取比較寬松的管理方案，比如可以直接上網(wǎng)，不受限制等。而恰恰是這類終端電腦，其上面的資料可能比普通員工的重要很多，所以需要重點(diǎn)關(guān)注。為其設(shè)置特殊的網(wǎng)段使之與其他終端隔離，在該網(wǎng)段部署蜜罐，對進(jìn)出該網(wǎng)段的流量進(jìn)行重點(diǎn)監(jiān)控，對此類人員的入站郵件內(nèi)容進(jìn)行更多層的分析，同時在SOC里將此類資產(chǎn)重點(diǎn)標(biāo)記，機(jī)器上所產(chǎn)生的安全事件風(fēng)險(xiǎn)等級提升一個級別，這些都是應(yīng)對之策?，F(xiàn)在，針對終端安全有些廠商整合了各種功能，信譽(yù)庫、云查殺、情報(bào)、EDR需要結(jié)合自己的實(shí)際情況考慮。網(wǎng)絡(luò)安全網(wǎng)絡(luò)安全涉及面非常廣，有一些基礎(chǔ)的安全加固配置，比如交換機(jī)上啟用port-security、BPDU-Guard等防護(hù)機(jī)制，對未使用的接口默認(rèn)全shutdown，使用AAA認(rèn)證技術(shù)，防火墻上開啟默認(rèn)anyanydrop策略等；也有一些專門的技術(shù)或解決方案，如NGFW、NIDS等。企業(yè)在劃分了安全域后，不同域之間需要通過VLAN、ACL、防火墻等技術(shù)進(jìn)行隔離。而安全域控制僅能依照安全策略進(jìn)行部署實(shí)施，但是即使符合安全策略的網(wǎng)絡(luò)訪問，仍可能存在惡意的網(wǎng)絡(luò)訪問行為。同時，安全策略在不斷運(yùn)營調(diào)整過程中，也可能存在失效的情況，如何及時發(fā)現(xiàn)這種隔離失效也是一個問題。因此，針對上面這兩種情況，我們應(yīng)能具備一定的檢測甚至阻斷的能力。常規(guī)思路是在實(shí)施網(wǎng)絡(luò)隔離（VLAN、NACL、防火墻等）外，還需要對其進(jìn)行流量分析（基于特征的NIDS、基于黑白名單及模型的異常訪問檢測系統(tǒng)等），以便發(fā)現(xiàn)異常。除了被動檢測外，還可以主動掃描，以發(fā)現(xiàn)ACL失效的情的惡意行為。蜜罐可部署在終端上，也可以部署在后臺服務(wù)器上，用來發(fā)現(xiàn)網(wǎng)絡(luò)上的掃描、探測等行為，我們將在13.7節(jié)中闡述。網(wǎng)絡(luò)入侵檢測系統(tǒng)網(wǎng)絡(luò)入侵檢測系統(tǒng)，無論開源還是商業(yè)都有不錯的選擇。Snort是一個具有代表性的開源NIDS，網(wǎng)上也有較多的中文資料和配套的輔助工具，如SnortSnarf、ACID等。開源IDS除Snort外，還有Bro可選，Bro事件生成引擎中實(shí)現(xiàn)的應(yīng)用層協(xié)議功能比Snort多，并且提供用于對事件做深入分析的策略腳本。開源的缺點(diǎn)是相對麻煩，先要對其有深入的理解，然后再學(xué)習(xí)其語法定制相應(yīng)的規(guī)則，對安全人員的要求較高。在安全人員能力和數(shù)量有限的企業(yè)里，還是建議使用商業(yè)產(chǎn)品，性能是個很大的優(yōu)勢，商業(yè)產(chǎn)品的支持會比使用開源方案更有保障；如果需要滿足特定場景而定制規(guī)則，商業(yè)產(chǎn)品也可以進(jìn)行定制；產(chǎn)生安全事件后，商業(yè)產(chǎn)品還會保留對應(yīng)的數(shù)據(jù)包以供進(jìn)一步分析。例如，內(nèi)網(wǎng)滲透常用的PsExec工具，首先防病毒一般不會查殺，因?yàn)樗荢ysinternals系列的一個工具，但如果我們需要發(fā)現(xiàn)這種行為，可以在終端上檢測PsExec進(jìn)程的運(yùn)行（進(jìn)程可以改名，MD5也會隨著版本不同而不同），也可以在目標(biāo)機(jī)器上檢測PSEXESVC服務(wù)的創(chuàng)建（服務(wù)名在高版本的PsExec里可以用戶指定），還可以在網(wǎng)絡(luò)上使用特征進(jìn)行匹配。當(dāng)然，具體到這一個特征，很容易規(guī)避，甚至新版PsExec直接提供了-r參數(shù)讓用戶自定如流量中返回的一些版權(quán)或說明（如ExecuteProcessesremotely），或者直接在SMB協(xié)議中看是否返回一些shell提示符等，具體就不再展開講了。在實(shí)際的運(yùn)營過程中，需要關(guān)注流量鏡像是否有效，流量是否缺失，自動化的驗(yàn)證事件是否正常觸發(fā)等。異常訪問檢測系統(tǒng)有些請求不會匹配IDS策略，比如從分支機(jī)構(gòu)遠(yuǎn)程桌面訪問總部的一臺機(jī)器，看似一個正常的登錄操作，但可能違反了企業(yè)內(nèi)部安全策略，這時候可以借助異常訪問檢測系統(tǒng)進(jìn)行檢測?；诤诎酌麊尾呗约澳Ｐ偷漠惓ＴL問檢測系統(tǒng)就是一個例子?；诤诎酌麊尾呗院美斫?，比如不允許辦公前臺網(wǎng)段直接遠(yuǎn)程桌面或SSH登錄到辦公后臺服務(wù)器網(wǎng)段，除了應(yīng)急需要保留幾個固定的IP之外，需要設(shè)置一個白名單和黑名單。除了傳統(tǒng)的黑白名單策略外，分析網(wǎng)絡(luò)訪問上的異常還有兩個切入點(diǎn)：基于訪問路徑的異常。比如，歷史上A和B經(jīng)常訪問C的1433端口，突然有一天D問C的1433端口，這在歷史記錄中是從來沒有的，因此就算一個訪問路徑上的異常。基于訪問頻率的異常。比如加入域的辦公電腦每天訪問域進(jìn)行認(rèn)證的次數(shù)為個位數(shù)，突然某天一個IP個訪問頻率的異常。拿到網(wǎng)絡(luò)流量后，我們按時間、源IP、源端口、目標(biāo)IP、目標(biāo)端口、應(yīng)用協(xié)議這六個元素來標(biāo)識訪問關(guān)系及統(tǒng)計(jì)訪問頻率，通過自學(xué)習(xí)模式生成白名單和profile規(guī)則，按照我們的管控規(guī)則自定義黑名單，對后續(xù)流量按照白名單、黑名單、profile規(guī)則的順序進(jìn)行匹配，對高風(fēng)險(xiǎn)事件進(jìn)行實(shí)時告警。系統(tǒng)的處理邏輯如圖13-2所示。圖13-2 異常訪問檢測架構(gòu)頻度分析在黑白名單策略匹配之前進(jìn)行，頻度是針對所有的事件進(jìn)行分析，先通過設(shè)置閾值來定義頻度，當(dāng)超過閾值時會產(chǎn)生相應(yīng)的頻度異常告警事件；同時事件會繼續(xù)經(jīng)過白名單、黑名單、profile的處理引擎，命中白名單的忽略，命中黑名單的產(chǎn)生異常流量告警事件，命中profile的忽略，未命中profile的則會產(chǎn)生未知流量預(yù)警事件。在實(shí)際的黑白名單策略設(shè)置過程中，主要考慮以下三類情況：跨區(qū)域的訪問，比如，辦公網(wǎng)和業(yè)務(wù)網(wǎng)之間的訪問，總部與分行之間的訪問，無線網(wǎng)段與辦公網(wǎng)段之間的訪問，內(nèi)網(wǎng)與外聯(lián)單位之間的訪問，DMZ區(qū)域主動外連訪問等。大數(shù)據(jù)平臺、征信系統(tǒng)等針對性的策略。特殊協(xié)議監(jiān)控，比如，遠(yuǎn)程桌面運(yùn)行在非3389端口，SSH協(xié)議運(yùn)行在非22PPTP、L2TP、VNC、PCAnywhere等協(xié)議運(yùn)行在網(wǎng)絡(luò)上等。隱蔽信道檢測系統(tǒng)業(yè)在防火墻上對Ping、DNS都是不做限制的，甚至個人PC及后臺服務(wù)器均能Ping通互聯(lián)網(wǎng)，如圖13-3中路徑①所示。圖13-3 DNSTunnel與PingTunnel圖13-3中，路徑①存在一定的風(fēng)險(xiǎn)，黑客能通過ICMP協(xié)議的缺陷，將需要竊取的數(shù)據(jù)分片封裝到ICMP協(xié)議的Payload中，通過不斷地發(fā)送Ping包，竊取信息。同樣原理，圖13-3中的路徑②，黑客也可能利用DNS協(xié)議的缺陷，將需要竊取的數(shù)據(jù)分片封裝到DNS協(xié)議的Payload中，通過不斷地發(fā)送DNS請求，竊取信息。ICMP協(xié)議格式如下：DNS協(xié)議格式如下：針對此類問題，建議的解決方案如下：IPS上檢測異常的ICMP、DNS協(xié)議包。此種方式的有效性依賴于特征庫。針對黑客常用的工具進(jìn)行研究分析，定制出特征庫是一個方法，比如PTunnel代碼里就有個magic，如圖13-4所示。圖13-4 PTunnelMagicCode如果命中0xD5200880這個特征的ICMP包，肯定有問題。當(dāng)然，如果黑客修改這個magic值再編譯就不行了，還得繼續(xù)找其他的特征。監(jiān)控?cái)?shù)據(jù)包的發(fā)送頻率。對于ICMP協(xié)議，正常業(yè)務(wù)場景下不會持續(xù)不斷地發(fā)送Ping數(shù)據(jù)包，如果發(fā)現(xiàn)有短時間內(nèi)不斷發(fā)送Ping終端上DNS請求數(shù)據(jù)包較多，而且每個用戶的使用習(xí)慣不同，此方法不適用于DNSTunnel的檢測。異常包大小檢測。對于ICMP協(xié)議，在Windows操作系統(tǒng)中默認(rèn)包大小為32字節(jié)，SUSELinux操作系統(tǒng)中默認(rèn)包大小為56字節(jié)。其最大數(shù)據(jù)包大小遵循IP協(xié)議規(guī)定，為65500字節(jié)。可以在防火墻上設(shè)置一個ICMP數(shù)據(jù)包大小的閥值，超過的ICMP包直接丟棄并報(bào)警。在RFC1035中，對于DNS的UDP數(shù)據(jù)包原始大小做了限制，但可通過DNS的擴(kuò)展名機(jī)制（EDNS0），允許DNS請求者公布其UDP數(shù)據(jù)包的大小，并且傳輸大于512字節(jié)的數(shù)據(jù)包。黑客也常利用此方式，將需要竊取的數(shù)據(jù)封裝到DNS在防火墻上針對DNS的UDP長度大于512或TCP包長度大于1024的約定進(jìn)行丟棄并報(bào)警。防火墻上只允許DNS請求到外網(wǎng)指定的DNS服務(wù)器，比如省localDNS或者14；有條件的企業(yè)還可以針對DNS協(xié)議中的TXT和NULL類型的記錄進(jìn)行阻斷。注意有些場景也需要使用TXT記錄，比如郵件方面會用到SPF等，有些廠商查詢情報(bào)也用此方法。以上各種手段有一定的效果，但無法完全阻攔有耐心的黑客。一些企業(yè)開始將目光放到大數(shù)據(jù)、機(jī)器學(xué)習(xí)方面，通過對DNS、ICMP請求使用各種模型進(jìn)行分析，以期發(fā)現(xiàn)異常。機(jī)器學(xué)習(xí)需要大量的日志樣本，目前此類方案在企業(yè)實(shí)際環(huán)境中的效果有待觀察。服務(wù)器安全服務(wù)器與終端環(huán)境有個明顯的不同—問，但人在上面的操作卻非常少。基礎(chǔ)安全配置首先要做的就是一些基礎(chǔ)的安全配置工作，相信每個企業(yè)都會有Windows服務(wù)器配置和管理規(guī)范、Linux服務(wù)器配置和管理規(guī)范之類的文檔，網(wǎng)上也有很多資料可供參考。Windows服務(wù)器的安全加固一般有以下幾個要點(diǎn)：安裝時磁盤分區(qū)選用NTFS，各種文件權(quán)限控制需要依靠它。協(xié)議“屬性”中，配置“禁用TCP/IP上的NetBIOS”，少量特殊應(yīng)用可能需要。服務(wù)器加入域，便于域統(tǒng)一管理安全策略。安全策略需要包括賬戶策略（密碼策略、賬戶鎖定策略、Kerberos策略）、本地策略（核策略、用戶權(quán)限分配、安全選項(xiàng)）等內(nèi)容。事件日志，需要調(diào)整最大日志文件大小。系統(tǒng)服務(wù)配置，禁用不必要的服務(wù)，比如Alerter、Browser、Messenger、Shell-HWDetection、AudioSrv、WinHttpAutoProxySvc、PimIndexMaintenanceSvc、、MapsBroker、Ifsvc、wlidsvc、NgcSvc、NgcCtnrSvc、RmSvc、SensorDataService、SensrSvc、SensorService、SSDPSRV、WiaRpc等。開啟高級審核策略，對賬戶登錄、賬戶管理、登錄/進(jìn)行配置。防病毒及所需要的安全軟件。Linux服務(wù)器的安全加固一般有以下幾個要點(diǎn)：USB存儲設(shè)備，添加GRUB密碼，禁止Ctrl+Alt+Del直接重啟服務(wù)器。/tmp和/var分區(qū)增加nodev和nosuid選項(xiàng)，對/home分區(qū)增加nosuid選項(xiàng)。對一些系統(tǒng)文件設(shè)置權(quán)限，包括/etc/crontab、/etc/securetty、/boot/grub/grub.conf、/etc/inittab、/etc/login.defs等。cups、postfix、pcscd、smartd、alsasound、iscsitarget、smb、acpid等。開啟命令記錄時間截，并將一些與命令記錄相關(guān)的參數(shù)設(shè)置為readonly。開啟日志及audit審計(jì)功能，配置監(jiān)控規(guī)則，同時設(shè)置syslog轉(zhuǎn)發(fā)將日志送到SOC。鎖定。進(jìn)行安全配置（最大重試次、禁用Rhosts認(rèn)證、指定密碼類型、指定MAC算法），同時刪除RHOST相關(guān)的各種文件。調(diào)整一些內(nèi)核參數(shù)，禁用LKM，限制/dev/mem，開啟ALSR，禁用NAT功能。很多企業(yè)開始大量使用虛擬機(jī)技術(shù)，于是很多安全加固配置可以直接做到模板里，這樣新生成的虛擬機(jī)就自動具有這些安全配置，再輔助一些運(yùn)維自動化工具對安全基線配置進(jìn)行檢查，對發(fā)現(xiàn)的問題安排跟進(jìn)處理。入侵防護(hù)檢測安全基線配置是一個基礎(chǔ)，但企業(yè)內(nèi)網(wǎng)服務(wù)器畢竟對外提供各種服務(wù)，這些應(yīng)用本身的安全性也會影響服務(wù)器本身的安全。從WebServer到開發(fā)框架，再到后端數(shù)據(jù)庫，都可能會被攻擊者搞定；另外，服務(wù)器上可能除了Root之外還會給開發(fā)人員或者應(yīng)用建有相應(yīng)的賬號，這些賬號的密碼如果泄露也會影響服務(wù)器的安全。弱口令不僅是123456之類的，有些企業(yè)的口令會有一些規(guī)律，比如Baidu@201X這樣的，可能一定程度上匹配了系統(tǒng)密碼復(fù)雜度，但別有用心的人可能很容易就將密碼拿到手了。所以，還需要在安全基線配置外，有一定的入侵防護(hù)檢測手段。一種思路是在服務(wù)器上安裝類似HIDS的產(chǎn)品，開源的有OSSEC，商業(yè)的也有不少產(chǎn)品。前面我們說過OSSEC有瑕疵，但這個產(chǎn)品的框架和思路確實(shí)值得學(xué)習(xí)，rules目錄下有大量的xml規(guī)則，在理解其規(guī)則寫法后，安全人員很輕松就能編寫自己的規(guī)則對特定的場景進(jìn)行檢測。如圖13-5所示的規(guī)則。圖13-5 OSSECRule編號31315的規(guī)則是發(fā)現(xiàn)有匹配密碼出錯的字樣，而31316規(guī)則是在31315規(guī)則命中的基礎(chǔ)上增加了頻度，代表發(fā)現(xiàn)了短時間內(nèi)多次驗(yàn)證失敗的事件。同樣，Windows下的Sysmon也是基于規(guī)則進(jìn)行匹配和過濾，其能記錄的事件類型如圖13-6所示。Sysmon的規(guī)則相對簡單，每個ID對應(yīng)一類事件，可以exclude排除也可以include包含組合運(yùn)用，內(nèi)置條件也比較豐富，如圖13-7所示。圖13-6 SysmonEventID圖13-7 SysmonRule依靠此類程序，我們在機(jī)器上收集了各種各樣的事件，接下來需要統(tǒng)一送往SOC平臺，在上面定制相應(yīng)的CASE并產(chǎn)生告警。另外，針對應(yīng)用日志（比如IIS日志），甚至應(yīng)用程序本身的日志，也可以通過類似Flume類程序采集到大數(shù)據(jù)平臺，便于進(jìn)一步分析。重點(diǎn)應(yīng)用安全在企業(yè)內(nèi)網(wǎng)中，有一些重點(diǎn)應(yīng)用的安全需要特別關(guān)注，例如，活動目錄、郵件系統(tǒng)、VPN、堡壘機(jī)等。活動目錄安全和郵件安全，我們將在第17章和第16章中進(jìn)行詳細(xì)闡述。活動目錄活動目錄服務(wù)器是辦公網(wǎng)中最重要的服務(wù)器之一，網(wǎng)上各種有關(guān)內(nèi)網(wǎng)滲透的技術(shù)文章都會涉及，所以需要重點(diǎn)關(guān)注，尤其是域管理員賬號的管理。域管理員賬號如果在其他機(jī)器上登錄過（比如管理員給普通用戶安裝軟件），一旦這臺機(jī)器被控制，通過執(zhí)行特定程序讀取內(nèi)存即可獲取域管理員的賬號和密碼。域管理員賬號密碼一旦被拿下，意味著整個內(nèi)網(wǎng)幾乎全部淪陷。關(guān)于活動目錄安全涉及比較多的內(nèi)容，我們將在第17章進(jìn)行闡述。郵件系統(tǒng)郵件系統(tǒng)一般部署在互聯(lián)網(wǎng)DMZ區(qū)，它需要接收外來的郵件，同時將郵件發(fā)送到外網(wǎng)的郵箱，但對企業(yè)員工來講，郵件系統(tǒng)可能更類似于一個OA系統(tǒng)的內(nèi)部平臺。郵件系統(tǒng)主要兩類安全問題：一類是入站郵件中的惡意URL或附件；一類是出站郵件中可能包含敏感數(shù)據(jù)，例如客戶資料。關(guān)于郵件安全和數(shù)據(jù)安全的話題，我們將在第16章進(jìn)行闡述。VPN有些企業(yè)為了方便員工遠(yuǎn)程辦公，采用了VPN方案。VPN的英文全稱是“VirtualPrivateNetwork”，即“虛擬專用網(wǎng)絡(luò)”。顧名思義，虛擬專用網(wǎng)絡(luò)可以理解為虛擬出來的企業(yè)內(nèi)部專線。虛擬專用網(wǎng)被定義為通過一個公用網(wǎng)絡(luò)（通常是因特網(wǎng)）建立一個臨時的、安全的連接，是一條穿過混亂的公用網(wǎng)絡(luò)的安全、穩(wěn)定的隧道。虛擬專用網(wǎng)是對企業(yè)內(nèi)部網(wǎng)的擴(kuò)展。虛擬專用網(wǎng)可以幫助遠(yuǎn)程用戶、公司分支機(jī)構(gòu)、商業(yè)伙伴及供應(yīng)商公司的內(nèi)部網(wǎng)建立可信的安全連接，并保證數(shù)據(jù)的安全傳輸。虛擬專用網(wǎng)可用于不斷增長的移動用戶的全球因特網(wǎng)接入，以實(shí)現(xiàn)安全連接；可用于實(shí)現(xiàn)企業(yè)網(wǎng)站之間安全通信的虛擬專用線路，用于經(jīng)濟(jì)有效地連接到商業(yè)伙伴和用戶的安全外聯(lián)網(wǎng)虛擬專用網(wǎng)。目前VPN主要采用四項(xiàng)技術(shù)來保證安全，這四項(xiàng)技術(shù)分別是隧道技術(shù)（Tunneling）、加解密技術(shù)（Encryption&Decryption）、密鑰管理技術(shù)（KeyManagement）、使用者與設(shè)備身份認(rèn)證技術(shù)（Authentication）。隧道技術(shù)是VPN的基本技術(shù)，類似于點(diǎn)對點(diǎn)連接技術(shù)，它在公用網(wǎng)建立一條數(shù)據(jù)通道（隧道），讓數(shù)據(jù)包通過這條隧道傳輸。隧道是由隧道協(xié)議形成的，分為第二、三層隧道協(xié)議。第二層隧道協(xié)議是先把各種網(wǎng)絡(luò)協(xié)議封裝到PPP中，再把整個數(shù)據(jù)包裝入隧道協(xié)議中。這種雙層封裝方法形成的數(shù)據(jù)包靠第二層協(xié)議進(jìn)行傳輸。第二層隧道協(xié)議有L2F、PPTP、L2TP等。L2TP協(xié)議是目前IETF的標(biāo)準(zhǔn)，由IETF融合PPTP與L2F而形成。第三層隧道協(xié)議是把各種網(wǎng)絡(luò)協(xié)議直接裝入隧道協(xié)議中，形成的數(shù)據(jù)包依靠第三層協(xié)議進(jìn)行傳輸。第三層隧道協(xié)議有VTP、IPSec等。IPSec（IPSecurity）是由一組RFC文檔組成，定義了一個系統(tǒng)來