左右互博：站在攻擊者的角度來做防護

作者：PgHook 2015-03-24 11:38:09

安全應用安全

在做這幾次防護的過程中，我一直在思考。我如果是攻擊者，我會怎么來攻擊?我會怎么去做?

0×01、前言

習慣性的講點廢話，筆者是一名菜鳥安全工程師。有幸參與過兩次安全方面的比賽，有些個人的體會，所以就有了這篇文章了。(自知技術還很菜，望各位大牛不喜勿噴，也歡迎對這方面感興趣的同學來和我一起交流探討。)

‍‍‍‍0×02、攻擊者會怎么做?‍‍‍‍

在做這幾次防護的過程中，我一直在思考。我如果是攻擊者，我會怎么來攻擊?我會怎么去做?

A、第一步，針對目標做信息收集(擴大目標)

子域信息、Whois信息、Ip信息、端口信息、公司人員的信息、公司郵箱信息等等,一切與目標相關的信息。

B、針對拿到的信息，進行漏洞掃描及挖掘

針對子域，我們可以去嘗試獲取其ip，及對其域名進行漏洞掃描。

針對whois信息，我們可以去嘗試，獲取其注冊郵箱，進一步進行社工拿到密碼進行域名劫持。

針對ip信息，我們可以去獲取ip對應的端口及服務，對相應的服務進行漏洞掃描及挖掘。(對于踢場子的來說，直接進行ddos，直接讓你玩不下去。)

針對公司人員信息及公司郵箱信息，可以進行社工弱口令之類。看能否拿到某位員工的公司郵箱，通過敏感信息進一步深入。(如果碰到某位關鍵人物)

看我寫起來貌似很簡單似的，但實際上確是一個苦逼而漫長的過程。

除了攻擊者的技術水平、人的毅力及對事物的專注程度外，還與運氣有點關系。(看你碰到的是sb管理還是nb管理)

做為防護者，這個時候你該怎么做了??對方已經出招，得接住呀!不然這個看場子的任務就將失敗了。

0×03、我是這樣來做防護的

A、Find and fix(這個其實是很關鍵的)

從字面上理解就是”發現并修復“，簡單的來說就是通過一些手段，去發現系統中的安全問題，然后解決問題。(醫生的最高境界不是去治療疾病，而是在疾病沒有來，就拔除了，根源在代碼)

帶領團隊成員對站點進行安全測試，發現安全問題，盡量減少外部安全隱患。(這里只能說是減少隱患，一個人的力量是有限的，一個團隊的力量也是有限的，并且側重點都不一樣。)

上面也說了，只能是減少安全隱患，當漏了安全問題的時候，該怎么辦了??這就有了下面的了。

B、Defend and Defer

從字面上來說是“捍衛和推遲”(這是谷歌翻譯的啊!和我沒關系)，這里的防護難道僅僅是弄一些安全設備(防火墻、入侵檢測系統、web應用防火墻)么???當然這些也是不可少的，但不是全部。合理的事物，放在合理的位置，才能產生好的效果。

縱深防護

這里主要涉及到，防火墻的HA，入侵檢測系統、白名單的使用，CDN及云防護。

流量從外面到里面需要經過如下幾層：

第一層必須經過CDN云防護的過濾及隱藏真實ip;‍‍

‍‍第二層必須經過防火墻白名單過濾，只允許cdn過來的流量;‍‍

‍‍第三層必須經過IDS或者IPS的過濾或者記錄風險行為。

也就是說就算我服務器存在一些安全風險，如果你沒能繞過這重重過濾也是沒用的。

MASTER防火墻

BACKUP防火墻

這里防火墻的HA,主要是為了防止單點故障或者說是流量攻擊時而設。關于這個防火墻的HA，這里有文章介紹：

http://drops.wooyun.org/%E8%BF%90%E7%BB%B4%E5%AE%89%E5%85%A8/4010

難道安全防護做到這里就完成了?如果有人繞過了你的種種過濾(或者說你的某一層過濾失效了)，你還能高枕無憂么?不能想當然，你做不到，并不代表別人也做不到。一切皆有可能，做好最壞的打算。

當黑客繞過了重重過濾后，對服務器進行攻擊的時候，你是否能在第一時間發現?

當黑客找到服務器漏洞，繞過了各種防護，拿到了shell，你是否能在第一時間了解到，并能分析出漏洞所在地?

這個時候就有了第四層的監控(應該算是比較失敗的)，基于主機的ids(可以理解成一個文件監控系統，自然也可以成為一個日志分析系統)，從理論上講，我們可以使用這個東西，對網站目錄進行監控及日志文件進行監控。一但網站文件發生變化，就立刻報警。但通過實戰，通過經驗告訴我，不要理想化，任何東西，都不可能橫空出世，都是有他的機制的。

這里第四層，使用的是ossec這個軟件，它對文件的監控，上面也說了比較失敗的。比較失敗的原因是，之前只是知道怎么去使用它，并不明白它是采用的什么機制，導致差點出大大問題。

第五層，做最壞的打算，當攻擊者上傳拿到shell后，繞過了前面三層的防護，而在第四層失效的情況下，攻擊者不就可以在你的網絡里面漫游了么?這種情況是不能容忍的，這個時候第五層防護就出現了。用專業詞匯來說叫“風險控制”，風險控制的目的是，減少風險事件發生時造成的損失。打好各個補丁(防止提權)，降低服務運行權限，取消上傳目錄的執行權限。就算攻擊者通過某0day拿到服務器的shell，他也不能干啥，因為權限很低嘛!

你現在能拿到子域信息、Whois信息、公司人員的信息、公司郵箱信息。對于公司人員的信息、公司郵箱信息這里暫時不考慮，這個只能通過提高員工的安全意識來進行。這里還存在子域信息，和whois信息。關于這個域名信息上面B主要就是針對這個的，這里就不提了。

往往被大家忽略的是whois信息，通過whois信息我們可以看到有可能看到注冊者的郵箱(這里是可以隱藏的)就可以對郵箱(一般是個人郵箱，才好弄)進行社工(現在滿大街的庫)，如果僥幸能拿下，就happy了。還能看到域名使用的ns服務器，即而得知使用的那家的cdn，如果說在注冊域名的地方不行，那就去cdn唄，效果差不多。

Cdn就一定靠得住么?就算它靠的住，難保他自己會不存在問題。一不小心，發現了一個隱患，只能說是個可能性吧!你想想如果，cdn上面的郵箱和密碼被泄漏出去了，別人給你改改，你的站點就死活打不開了，前面的一切就白費了。

看到沒，qq郵箱，是不是可以對這個郵箱進行社工啊?手氣好說不定就搞定了這個密碼。

這個是咱們的，已經改了個昵稱了，默認是顯示郵箱的。

C、Secure at the Source

個人理解這句話的意思應該是“源代碼里面的安全”，這個就要從代碼的書寫者身上去找答案了。也就是上面所提高到高明的醫生，不會讓疾病產生，在源頭就給干掉了。很多大公司都有他們的一套“安全開發流程”，應該就是在這個層面的。

在這里做好了，可以減少很多問題，及bug，但往往得不到很好的解決。從代碼的的書寫者，角度來說，肯定是怎么方便怎么來。壓根不會去考慮安全問題，或許也不了解。再者，書寫者的水平也參差不齊，就造就了不安全的代碼。#p#

0×04、遲早都是要還的

曾經的不諳世事，曾經的無知無畏。現在終于要還了，以前經常去挖掘別人系統的漏洞，沒日沒夜的去掃別人的系統。甚至弄掛別人的服務器，都沒想過有一天，我也會被晾在外面，被人虐。

由于業務需要的原因，某重要子域需要關閉CDN上的云防護。即第一層的防護，這其實是很危險的，但業務的需要也是沒辦法的，首先要保障的是可用，如果都不可用了，還談什么安全了?第二層防護其實就是為了，最大限度的隱藏真實ip，防止ddos攻擊。云防護已經沒了，那么第三層就顯的尤為重要了。這里就主要介紹下，在這個第三層發現的一些攻擊行為吧!這里主要介紹下，幾個典型的案例。

案例一：某攻擊者使用sqlmap對站點進行注入攻擊