這兩天遇到一個資訊安全的典型攻擊案例就是密碼攻擊。就在前天晚上接近11點的時候Slack一直持續發Alert說有人在進行同一帳號大量的密碼連續猜測攻擊,當時Developer也進去看SSO系統log確實也看到同一帳號持續的failed login,因為帳號密碼錯誤,所以可以確定這是典型的密碼猜測攻擊事件。

  當下大家並沒有太多多餘的執行動作,比較多所著墨的是在於如何解決當下密碼被攻擊的事件。

  事情的詳細狀況是:我們預計要做一分鐘連try 20次密碼失敗WAF便自動block IP的機制好死不死是下週才要上線,加上我們的Account沒有任何鎖定機制,當下我們對此密碼攻擊可以說是無能為力的。

  唯一可以做的就是先手動把攻擊者IP加入ACL黑名單Block他。但有人則concern即使把IP封住別人也是會換一個IP跳板再繼續打,所以是否有其他方式可行?

  於是RD提出可以試著Disable Account!但是Disable Account之後該Account就不能再被使用,而且也可能影響使用者的License使用權益,因為使用者可能得靠account才能存取已有LicenseService,所以Disable Account這條路也不可行。

  之後另一位RD提出可行的類Account Lock方式,雖然我們的Account管理功能並沒有把Account Lock這件事做在上面,但卻可以透過直接在DBAccount類別改成M,即被MergeAccount,則該account形同失效,不能再登入機器,之後只要再把類別改回Y,即有效的Account,便可再次正常使用該Account,此法獲得其他人的支持。

  但我想了想也上網找了找,我覺得其實還是應該先手動Block IP,雖然有可能攻擊者可能會再換一個IP再來攻擊,但至少此舉可以增加攻擊複雜度,無論如何攻擊者都變得必須為IP被鎖住這件事花些心力去處理,而趁這空檔,我們便可把握機會,先聯絡上User告知其Account正被密碼攻擊,因此我們需要做些處置讓該Account無法登入以保護您的資料安全,之後User若同意再做Account type to M for failed account login 的動作,這才是正確的流程。

  因為我們沒有Account LockUnlock 自動機制,所以如果我們動使用者資料之前,當然得先讓User知道才對,不然不就等於是私自竄改User Data了!這當然不行。所以我認為真要走到改Account type這一步,一定要先讓使用者知道我們打算做這件事。

  而也很慶幸地JM完全同意我的想法,雖然沒公開說就這麼做,但是也是先指示block IP,之後再Email給客戶,這等於是肯定我的作法,令人感到開心。

  而在私下我也跟RD說看來遇到密碼狂try的情形光鎖IP一定不夠,因為hacker 可以變換IP繼續攻擊,因此我們應該需要再做一個真正的Lock Account機制,以期達成當使用者不斷被try 密碼時,帳戶會被鎖住,且要一段時間才能恢復。

  這些RD也在開會時講出來了,所以我想這一次的經驗很重要,因為難得我的想法都有被聽進去,特別在此分享紀錄一下,當成是一次很寶貴的資安Event處理事件與經驗。

201816日星期六3:09 AM

arrow
arrow

    jackterrylau 發表在 痞客邦 留言(0) 人氣()