搜尋此網誌

2012年11月7日 星期三

[工具介紹] 利用 iptables 的敲門機制保護 ssh 服務

DoorKnock之前我介紹過利用 fail2ban 來封鎖嘗試使用暴力破解登入 ssh 的有心份子,但是如果你有嚴重的潔癖,看到滿滿的登入錯誤訊息就渾身不舒服想要更進一步降低此一風險,還有一些措施可以施作,其中最常見的建議就是不要使用預設的埠號 (TCP:22)。改用其他埠號雖然看似很有效,但是一旦遇到埠號掃描的攻擊行為並被有心份子知道實際使用的埠號,其實就跟使用預設埠號沒啥兩樣。如果我們可以隱藏實際使用的埠號,並於特殊情況下才予以現形,那就不用擔心埠號掃描的攻擊方式了。

我們可以利用 iptables 內建的 recent module 來達成此一目標,想要連結 ssh 服務的一方必須先對某個特定的埠號進行"敲門"動作,iptables 才會對此 IP 位址開放 ssh 服務所使用的埠號。以下我們就透過實際的例子來加以說明,實作的環境是 CentOS 6:

  1. 修改 ssh  服務所使用的埠號
    ssh 服務的設定檔為 /etc/ssh/sshd_config,將
    #Port 22
    改為
    Port 2222
    其中 2222 表示我們想要 sshd 服務所使用的埠號。
  2. 重新啟動 ssh 服務
    指令為
    service sshd restart
  3. 匯出 iptables 所使用的設定
    指令為
    iptables-save > /tmp/iptables
    如果你使用其他工具 (如webmin) 來設定 iptables,那麼就不需要進行 iptables 規則的匯入與匯出,可以直接加入所需規則。
  4. 修改 iptables 的規則
    在 /tmp/iptables 適當的位置加入用紅色標示的兩行規則 (請務必加在 default policy 之前):
    -A INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT      
    -A INPUT -p tcp --dport 54321 -m recent --set --name SSH-PHASE1
    -A INPUT -p tcp --dport 2222 -m recent --rcheck --seconds 5 --name SSH-PHASE1 -j ACCEPT

    -A INPUT -j REJECT --reject-with icmp-host-prohibited
    其中 54321 是我們用來敲門的埠號,而 2222 則是 ssh 服務實際上所使用的埠號。同時記得刪除 ssh 服務的預設規則
    -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
  5. 匯入 iptables 的規則
    指令是
    iptables-restore < /tmp/iptables
  6. 測試新的規則
    從另外一台主機執行下列指令
    telnet ip_address 54321; ssh ip_address –p 2222
    其中 ip_address 請換成前一台主機的 IP 位址。順利的話,應該可以看到 ssh 的登入提示符號。如果我們在 telnet 與 ssh 兩個指令之間停頓超過 5 秒,將無法連結至 ssh 服務,也就是說每次敲門後的開放只保留 5 秒,5 秒過後又自動加以關閉。如以一來,即使利用埠號掃描攻擊也很難發現 ssh 服務真正使用的埠號。
  7. 刪除規則暫存檔
    指令是
    rm –f /tmp/iptables
  8. 將規則寫入 iptables 的啟動設定
    如果測試無誤,我們就可以把規則寫入 iptables 的啟動設定,以確保每次啟動 iptables 時都能套用此一設定。指令是
    service iptables save

透過兩行簡單的iptables 規則設定,我們大幅減少 ssh 服務埠號被偵測出的可能性,對 ssh 服務的保護將更加完善。最後,即使使用了 iptables 的敲門機制來保護 ssh 的服務埠, fail2ban 依舊有其必要性,理由如下:

  • fail2ban 不只可用來保護 ssh 服務,還可以用來保護包含 ftp 與 pop3 在內的各項網路服務。
  • 通常 iptables 規則中總會有些例外 IP 位址可以對系統暢行無阻,雖說這些 IP 位址多為內部使用,但是別忘了內部使用的 IP 位址並不等於絕對安全。
  • 避免日後有人不小心移除了相關設定。相信我,這種糗事發生的機會比你想像中還來的高出許多。
  • 一旦知道這個"敲門"用的埠號後,此一機制同樣可能遭受暴力攻擊。什麼人會知道這個敲門埠號?你猜對了,正是離職員工!

2012年11月6日 星期二

[工具介紹] 利用 lsyncd 達成 Linux 下的目錄"即時"同步

windows-8-transfer7數位資料對一個企業的重要性,我想已經不用我在此多加贅述。而這些數位化的資料,除了存在於資料庫當中,其實還有不少是以檔案形式存在著。對於資料庫,通常我們除了定期備份之外,還會考慮到備援的機制 (如常見的主從式架構),以確保資料庫的高可用性。但是對於檔案呢?往往可能就沒有那麼受到重視了。備份或許有之,但是是否有也良好的備援機制呢?檔案的備援有多種可能性,從分散式儲存機制 (如 DRBD),到分散式檔案系統 (如 GFS2, Hadoop Distributed File System),選擇性可說是五花八門。儘管選擇相當多,但是這些機制通常都必須在建立系統前就一併加以規劃,而且受到支援平台的限制。有些機制甚至在使用上也與傳統的檔案系統不盡相同,再再提高了管理人員與系統開發人員的進入門檻。對於大部分的系統而言,可能原先已經存在許多檔案並存放在"一般"的檔案系統 (如 ext3) 之內,有什麼好的方法可以讓這些系統無痛地達成備援的機制?
對 Linux 系統而言,基本上我們只要達成目錄的同步再加上如 heartbeat 的監測機制,就可以達到檔案的備援機制。而要達到目錄的同步,最簡單也是最常見的一種方式就是透過排程定期呼叫 rsync 將主目錄內的檔案同步至備援主機的目錄。這方法雖然很簡單,也確實可行,但是他有一個主要的問題,那就是當目錄結構一大,比對與同步的時間將會拖的很長。如此一來,表示排程間隔的時間不能太短,也就是兩個目錄所出現的時間差距也會隨之增加。而今天我要介紹的這個工具 – lsyncd,雖然也是透過 rsync 進行同步,但是 lsyncd 透過監測目錄的寫入動作,僅針對變動的部份進行同步,可以大幅提高同步的效率。而 lsyncd 的同步觸發條件預設為間隔 20 秒或累積 1000 次的寫入事件,而且這兩個參數還可以依據實際的狀況加以調整。不可否認,lsyncd + rsync 很難達成真正的即時同步,但是對於大部分的狀況,數秒的差距應該是可以被接受的。而因為 lsyncd 只需安裝在主目錄的系統上,所以對於備援主機的限制較少,甚至是不同的檔案系統都沒關係
在 Linux 下面,通常可以找到 lsyncd 的套件直接加以安裝,只是版本上可能會有所不同。以 CentOS 為例,可以在 EPEL 這個 repository 中找到 lsyncd 的套件,版本為 2.0.4。前面提到,只有主目錄的主機需要安裝 lsyncd,而用來當做備援的主機是不需要安裝的。安裝後,必須自行建立一個設定檔,檔案路徑雖然沒有什麼限制,但是我的建議是使用 /etc/lsyncd.conf 以便管理。在 /etc/lsyncd.conf 檔內輸入下列內容:
settings = {   
   logfile = "/var/log/lsyncd.log",    
   statusFile = "/var/run/lsyncd.status",    
   nodaemon = false,    
   log = all    
}

sync {   
   default.rsync,    
   source = "/data",    
   target = "192.168.1.2:/data",    
   rsyncOps = {"-avz", "--delete"},    
   delay = 10    
}

其中 source 與 target 請分別改成你想要同步的主目錄及備援主機的目錄。設定完畢之後,透過指令lsyncd /etc/lsyncd.conf
就可以啟動 lsyncd 的同步功能了。在使用 lsyncd 時,有下列幾點事情需要注意:
  1. 因為新版的 rsync 已經預設使用 ssh 當做傳輸的方式,所以可以直接設定使用 rsync 即可。如果 rsync 版本過舊,可以將 sync 方式由 rsync 改為 rsyncssh。也就是說,我們必須確保主目錄的主機可以直接透過 ssh 登入備援主機,而不需要輸入密碼。除了利用 rsync + ssh 的方式,也可以透過 rsync 的 target,如此一來就不需要 ssh 了。
  2. lsyncd 預設不會同步檔案的所有權與權限,因此我們透過 rsyncOps 這個參數來改變 lsyncd 呼叫 rsync 的行為。
  3. 透過 delay = 10 這個設定,我們要求 lsyncd 將同步間隔時間由預設的 20 秒改為 10 秒。
  4. 我們必須確保所有的寫入動作發生於主目錄的主機上,而在一般的情況下,這應該是不成問題的。但是如果我們自找麻煩地在主目錄掛載了其他主機的目錄,那麼這些掛載而來目錄的寫入動作,將無法被 lsyncd 監測到,所以也就無法同步
  5. lsyncd 透過 inotify 作為監測目錄寫入的機制,而 inotify 可監測的數量則受到 fs.inotify.max_user_watches 這個參數的限制。如果 lsyncd 欲監測的目錄數量超過系統的上限,並不會出現錯誤訊息,而是多餘的目錄直接被忽略。為了避免此一現象的發生,我們在啟動 lsyncd 後可以先透過指令
    sysctl fs.inotify.max_user_watches
    確認系統的設定值。之後在 /var/run/lsyncd.status 中找到類似下列的訊息
    Inotify watching 34567 directories
    其中 34567 表示 lsyncd 供監測了 34567 個目錄。如果兩個數字很接近,請增加系統所允許的上限值以便讓 lsyncd 完整監測並同步所有的目錄。
    透過下列指令我們可以將 inotify 可監測的數量上限變更為 40000
    echo 40000 > /proc/sys/fs/inotify/max_user_watches
    如果我們希望每次開機後此一設定值都自動變更為 40000,請修改 /etc/sysctl.conf,加上下列設定
    fs.inotify.max_user_watches = 40000
  6. CentOS 所安裝的 lsyncd 並沒有提供啟動腳本,因此請在 /etc/rc.local 加上設定
    /usr/bin/lsyncd /etc/lsyncd.conf
    如此一來,開機時 lsyncd 才會自動執行。
雖然 lsyncd 無法真正達成目錄的"即時"同步,但是在可接受的誤差範圍內,lsyncd 有著安裝簡單與適用範圍廣泛的優點,對於檔案備援來說絕對是一個令人心動的選擇。

2012年10月14日 星期日

[資安觀念] 意外"總是"會發生

a.aaa-Eppic-crash前幾天跟一位多年不見的朋友見面,在談話中他提到了他在年初所遇到的一件慘事,那就是他們線上服務的網路儲存設備的 (Linux-based) 系統整個毀損,甚至造成了部分重要檔案的損失。早在10多年前 .COM 熱潮來襲的時候,那時候因為伺服器等級的硬體設備價格高昂,再加上日誌型的檔案系統還不普遍,所以系統損毀時有所聞。但是以目前硬體設備的價格,硬體式的 RAID 控制卡已經是伺服器的基本配備。在 RAID 的架構下,一般至少會採用可以容忍一顆以上硬碟損毀的設定。再加上目前普遍採用的日誌型檔案系統,要造成系統的損毀,可說是意外中的意外了。只是不管再多的解釋,事情的發生卻是不可爭辯的事實。在面對這類問題時,除了自我解嘲為運氣不好外,是否還能採用其他更積極的作為?

答案當然是有的,而且還是早就已經存在許久的作法。首先,當然就是老生常談的備份。除了定期的備份,針對重要資料甚至可以採用即時備援的架構,以避免備份時間點與意外發生時間點差異所造成的資料損失。備份與備援可以減少原始資料損失時所造成的影響,算是比較被動的作法。比較積極的作法,可以考慮將系統與資料分別存放在不同的檔案系統、不同的硬碟、甚至是不同的 RAID 陣列。事實上,在早期的 Linux 建構建議中,將系統與資料放在不同的檔案系統,一直是一個不可輕忽的作法。但是後來 Linux 的安裝過程過於自動化,連檔案系統的劃分也不需要管理者人工設定,所以這個建議事項越來越難被落實,甚至也很少聽到有人再提起。

無獨有偶的,前一陣子另外一位朋友公司的 ERP 系統,也因為停電而造成資料庫的損毀。資料庫損毀?是的,而且他們用的可是資料庫市場的領導品牌。更何況這可不是意外的停電,而是大樓事先公告的維護性停電。大樓公告被無視化、停電時剛好在進行當日資料庫的備份作業、斷電後重新供電不穩定、前一天資料庫備份無法使用...一連串的巧合,讓他們損失了不少的資料。又是運氣不好?是的,連我一個第三者都覺得運氣真的是太差了吧。

這個事件同樣也只能怪罪於運氣不好嗎?當然不是!大樓管理單位對於停電這麼重要的事情竟然只貼了公告,而沒有主動通知,肯定有所失職。但是大樓管理單位通常不是我們能夠控制的變數,所以我們更應該著力於我們可以控制的事項上。首先,是 UPS 系統的使用。UPAS 可不光是買了接上就行,包含電力不足時的自動關閉也是同樣重要的。此外,針對伺服器在停電後重新恢復供電的行為,是否該設定為自動啟動?還是應該設定為手動啟動?這也是一個值得仔細推敲的問題。最後,備份資料的確認,同樣是容易被許多系統管理者所忽視的重點工作事項。不管是透過雜湊值 (如 MD5) 來確保檔案的完整性,或者是透過匯入的動作來確保資料庫備份資料的正確性,都可以避免日後從口中發出 WTF 的憾事。

這兩個看似完全不相關的事件,同樣都因為新技術的導入,而忽略了原本系統就存在的風險。RAID 讓我們可以避免硬碟損毀所造成的意外,但是它卻無法避免其他意外的發生 (甚至 RAID 本身也可能出錯)。資料庫領導品牌強調他們的資料庫有多種機制可以確保資料不會損毀,但是依舊無法提供 100% 的保證。所以我們在面對這些技術時,千萬別因為這些新奇的保證而忘了其他存在的風險。採用多種保護措施,本來就是管理者用來應付風險的主要策略,千萬不要認為這是資源的重複投資與浪費而縮手。尤其在面對重要資料的保護時,小心、謹慎永遠是不嫌多的,將來有一天你會感謝自己曾經注意到這些"小細節"。

2012年9月18日 星期二

[從電影看資安] 站住、口令、誰 - 龍門飛甲

相信當過兵的朋友們都還記得,部隊中晚上是禁止隨意走動的。但是話說人有三急,有時候晚上起來上個廁所,也是膀胱無力人之常情。在正常的情況下,只要一離開寢室,就會有人 (這個人叫安全士官) 大聲問道:「站住、口令、誰。」唯有正確答出當天的通關密語 (口令),才有可能全身而退,不然被當做匪諜一槍擊斃也只能自認倒楣了。軍隊透過這樣的安全機制來避免有心份子混入部隊當中,只是這樣的安全機制夠安全嗎?在由李連杰所主演電影「龍門飛甲」中,有一段類似的情節,我們先來看看。

話說由李連杰所演出的趙懷安,因為常與政府做對所以受到西廠的追捕。在一次的誤會當中,西廠官兵前往龍門客棧準備捕捉趙懷安。但是西廠所追捕的趙懷安,原來只是一個愛慕他的女生所假冒。而龍門客棧這個地方,也因為傳說埋藏了稀世珍寶,所以除了官兵之外,還有不少亡命之徒投宿在此。而這些亡命之徒當中,有一個人竟然長得跟西廠的頭目 (督主) 相當神似,故事也就因此有了變化...

男主角趙懷安,跟後面要講的劇情無關,純粹是看在李連杰的面子上才放這張照片。
vlcsnap-2012-09-18-05h04m49s176臨時出現的亡命二人組,書生樣的「風裡刀」外貌神似督主。
vlcsnap-2012-09-18-02h59m25s133
西廠的官兵一看,嚇到不知所措。
vlcsnap-2012-09-18-02h58m37s174
亡命之徒果然見過世面,馬上就發現西廠官兵的異常反應。
vlcsnap-2012-09-18-02h50m54s138
「風裡刀」最厲害的就是那張嘴,所以馬上前往官兵的房間套話。
vlcsnap-2012-09-18-02h51m40s59
雙方僵持不下。
vlcsnap-2012-09-18-02h52m12s171
西廠也不是那麼笨 (至少目前還不笨),早偷偷派了人回去確認是不是真貨。
vlcsnap-2012-09-18-03h00m14s113
嘍囉不忘多拍幾下督主的馬屁。
vlcsnap-2012-09-18-03h00m31s44
督主就是督主,馬上想到一個餿主意妙計,那就是他要冒充「風裡刀」混進去搞破壞。
vlcsnap-2012-09-18-03h00m56s38
嘍囉想到一個辨別真假督主的方式,那就是用密語。
vlcsnap-2012-09-18-03h01m08s162
密語是「龍門飛甲」。
vlcsnap-2012-09-18-03h01m35s177
對「便知真假」。
vlcsnap-2012-09-18-03h01m47s30
嘍囉回到龍門客棧,先用密語確認督主的身分。
vlcsnap-2012-09-18-03h02m22s124
果然是假冒的,但是真督主有令不可打草驚蛇。
vlcsnap-2012-09-18-03h03m08s72
這是督主假扮的「風裡刀」,果然很像 (根本就是同一個人演的)。
vlcsnap-2012-09-18-02h55m32s124
督主又出現了,這次是真是假?
vlcsnap-2012-09-18-03h04m16s217
對方搶先一步說出密語的前半部。
vlcsnap-2012-09-18-03h04m35s172 
搶答失敗。
vlcsnap-2012-09-18-06h08m02s129
只好硬著頭皮講出另一半的密語。
vlcsnap-2012-09-18-06h12m06s15
被擺道了。
vlcsnap-2012-09-18-03h07m19s24
剛剛是假的督主。
vlcsnap-2012-09-18-03h07m28s100
這次換督主的手下大將來認證說密語。
vlcsnap-2012-09-18-03h08m30s217
實在被騙太多次了,已經惱羞成怒。
vlcsnap-2012-09-18-03h08m53s189 
不管三七二十一,放就對啦。
vlcsnap-2012-09-18-03h08m59s10

囉嘍在督主提出喬裝臥底的計策時,很聰明的想到了利用密語來辨識真假督主。不過百密終有一疏,他們忘了約定誰要講上半部,誰又要講下半部。所以聰明的「風裡刀」在猜測到「龍門飛甲」可能是密語之後採用先聲奪人的策略,不待西廠官兵開口就搶先說出「龍門飛甲」,迫使西廠官兵只能說出密語的下半部。

回到部隊的例子,又有什麼樣問題呢?當安全士官大聲問道:「站住、口令、誰。」時,任何知道口令的人,都可以假冒成其他人。原因很簡單,因為整個部隊都是使用同一個口令,因此就失去了可稽核性 (Accoutability)。除了可以利用其他人的身分上廁所,這種機制還有一個問題,那就是如何確認安全士官真的是安全士官?因為「站住、口令、誰。」是一個固定的詢問方式,所以知道這句話並不能確保安全士官的身分,這樣情況我們稱之為單向的身分驗證。相對於單向的身分驗證,當然還有所謂的雙向驗證。

以我們經常使用的電子商務網站來看,通常使用各式各樣的網站憑證來做為 SSL 加密之用,這就是一種單向身分驗證的應用 (註一)。網站憑證可以確保 (至少在理論上是如此) 使用者連結的網站是他所預期的,而不是連到一個假冒的釣魚網站。對於一般的電子商務網站,單向驗證或許已經足夠,但是對其他更重要的服務而言,雙向驗證就是不可或缺的了。這些服務包含網路銀行、政府機關各項服務 (如報稅) 等。雙向驗證除了網站憑證之外,使用者也必須擁有個人的憑證 (如自然人憑證、工商憑證等) 才可以進行訊息的溝通。透過雙向驗證,不但使用者可以確認網站的真實性,網站也可以確認使用者的身分。在保護資料安全性的同時,也提供了高度可靠的可稽核性與不可否認性。

註一:一般的電子商務網路會透過帳號/密碼進行使用者的身分驗證,也可以算是一種雙向驗證。然而這是兩種機制的混合使用,與我後面提到使用憑證做到雙向驗證是不一樣的作法,在安全強度上也有所不同。

2012年9月11日 星期二

[工具介紹] 利用 ossec + ossim 管理端點的安全

之前我介紹過 Splunk ,用來作為日誌集中管理與分析的工具相當好用 (除了免費版本有討厭的 500MB 限制)。但是 Splunk 是一個一般型的分析工具,如果我們只想處理有關資安相關的資訊,不但需要自己設定各項所需的資料來源,更必須自己利用查詢指令找出感興趣的資訊,甚至轉換成所需的報表。事實上,市面上針對資安相關資訊的彙整與處理已經有一類專門的產品,統稱為 SIEM。今天我要跟各位分享兩個工具的整合利用,其中的 ossim,正是 opensource 形式的 SIEM。
在我使用 ossim 之前,原本只是使用 ossec 來做為主機 (端點) 的 IDS 機制 (HIDS)。ossec 同樣是 opensource 形式的軟體,支援多種作業系統,主要提供主機的完整性檢查、日誌檔監測與惡意程式 (Rootkit) 掃描的功能。如果發現有疑似攻擊的行為發生,ossec 還可以做出回應,例如封鎖攻擊來源的 IP 位址。ossec 採用主從式 (Client-Server) 的架構,主要透過命令列方式加以設定。而事件的判斷結果統一集中在 ossec 伺服器 (Server) 上,同樣必須透過指令的方式加以查看。
作為一個專業的管理人員,當然不能接受這麼不方便的事情。好險,有 ossim 的存在。嚴格來說,  ossim 並不是單是  ossec 的圖型化操作介面,更不是日誌管理系統。ossim 整合了許多 opensource 的資安/管理工具,並以 ISO 檔 (或專屬設備) 的形式發佈,讓管理者可以很快建立起一個完整的 SIEM 系統。ossim 整合的工具包含了
  • 流量管理: ntop, netflow
  • 入侵偵測: snort, ossec
  • 弱點掃描: openvas, nessus
  • 可用性: nagios3
  • 變更管理: arpwatch, P0f, Pads
  • 無線網路管理: kismet
除了工具的整合,  ossim 還可以透過 syslog 的機制,分析來自其他設備或軟體的資訊。而付費版本的 ossim,更提供了日誌加密封存的功能,可作為日後訴訟用的佐證。
今天,我要跟各位分享如何利用 ossec + ossim 做出一個完整的主機入侵偵測系統 (HIDS)。前面提到 ossec 採用主從式的架構,所以 ossim 就是 ossec 的伺服器 (Server),而其他我們想要管理的主機就是 ossec 的客戶端 (Client)。我以 CentOS 作為客戶端的範例,至於其他作業系統的客戶端,設定的過程也沒有太大的差異。
  1. 下載 ISO 檔
    下載網址是 http://communities.alienvault.com/community/#downloads 。目前的版本是 4.0,僅提供 64 位元的版本。
  2. 安裝 OSSIM
    OSSIM 以 Debian 為基礎,提供完整的圖型化安裝介面,在此就不一一截圖了。
  3. 連結 OSSIM 的網頁
    連結網址是 https://ossim.ip/ossim ,其中 ossim.ip 請替換成安裝 OSSIM 時所指定的 IP 位址。
  4. 新增管理的網路區段
    點選 "Assets" –> "Assets" –> "Networks" –> "New"。 
    0002
  5. 輸入管理網路區段的資訊
    有兩個主要欄位需要填寫,分別是 Name 與 CIDRs,填寫完畢後按下 "Update" 即完成新增的動作。如果你有多個管理的網路區段,請記得重複此一新增動作。
    請注意到畫面上有一個 "Asset value" 的選項,在 ossim 中,每一個資產 (Asset) 都有其價值,這個價值是用於事件風險的計算公式之中。
    0003-2
  6. 掃描主機
    雖然我們也可以用手動的方式將主機資訊一一加入,但是第一次設定時我還是建議用掃描的方式新增主機,以簡化輸入的過程。
    點選 "Assets" –> "Assets Discovery"。利用右邊的樹狀圖選取想要掃描的網路區段,如有需要可同時選取多個網路區段。
    0003
  7. 開始掃描
    選取完畢並設定好相關參數後,按下 "Start Scan" 開始進行掃描。
    0004
  8. 等待掃描結果
    掃描完畢後, ossim 會列出所有搜尋到的主機及其相關資訊。在想要新增的主機後進行勾選的動作,勾選完畢後按下 "Update database values"。
    0005
  9. 儲存掃描結果
    儲存前可以指定是否要為這些主機建立一個新的群組,或者也可以指定主機的價值 (Asset value)。設定完畢後按下 "Update" 即完成新增的動作。
    0006
  10. 登入 ossim 的系統主控端,進行 ossec 客戶端的管理
    其實管理客戶端的動作大多也可以在 ossim 的管理介面上完成,但是為了展現我們打指令的功力,還是介紹原本 ossec 所使用的方式。
    啟動用戶端管理程式,指令是
    /var/ossec/bin/manage_agents      
    使用選項 A 來新增主機。0007
  11. 輸入客戶端電腦的名稱 (Name) 與 IP 位址 (IP Address)
    名稱主要作為識別之用,並不會影響新增的結果。而 IP 位址必須填入伺服器所 "看到" 的客戶端 IP 位址。除非客戶端會透過轉址 (NAT) 來對伺服器進行連結,否則一般直接填上客戶端的 IP 位址即可。
    設定完畢後進行確認 (y) 即完成新增的動作。 0008
  12. 取得客戶端的 "鑰匙"
    ossec 作為一個安全軟體,當然不可能隨意接收其他電腦傳送過來的訊息。所以每個想要傳送訊息的客戶端,都必須擁有一個獨一無二的鑰匙。在前一個動作完成時,ossec 就幫我們建立好該客戶端的鑰匙了。我們可以透過指令 E 取得客戶端的鑰匙,而客戶代號 009 則為前一個動作進行時系統所自動產生的。第三個紅色框框內的文字就是這個客戶端的鑰匙,請完整複製下來並備用。
    0009
  13. 安裝 ossec (客戶端)
    CentOS 可以從 AtomiCorp 的 repository 中取得 ossec 套件。指令是
    wget -q -O - https://www.atomicorp.com/installers/atomic |sh
    yum install ossec-hids-client ossec-hids
    chkconfig ossec-hids on
  14. 修改設定檔,指定伺服器的 IP 位址 (客戶端)
    指令是
    vi /var/ossec/etc/ossec.conf
    修改檔案開頭的 <server-ip> 參數。
  15. 匯入鑰匙 (客戶端)
    輸入指令
    /var/ossec/bin/maange_client
    使用選項 I 匯入鑰匙,並將剛剛複製的鑰匙文字完整貼上。 確認資料無誤後,輸入 y 完成匯入鑰匙的動作。
    0010
  16. 關閉匯入工具 (客戶端)
    使用選項 Q 。
    0011
  17. 啟動服務 (客戶端)
    指令是
    service ossec-hids start
  18. 確認客戶端已經正常連結
    我們回到 ossim 的管理介面,點選 "Analysis" –> "Detection" –> "HIDS"。如果客戶端狀態出現 "Active",表示客戶端已經正常連結至 ossec 的伺服器。如果無法正常連結,可以檢查 ossec 的紀錄檔,位置是 /var/ossec/logs/ossec.log。
    0012
  19. 其他操作
    一開始我提到原本 ossec 僅提供指令的方式來管理客戶端,而 ossim 則將此功能整合至管理介面當中。例如點選畫面右上方的 "Agents" 連結,就可以看到目前所有的客戶端列表,而且還可以對其進行操作 (如執行完整性檢查) 或是查看之前所產生的相關訊息。透過 ossim ,不但可以簡化 ossec 的管理作業,所有 ossec 所產生的訊息也將被 ossim 統一處理,更加提供我們對於資訊安全的防護能力。
    0013
透過幾個簡單的動作,我們就建立起一個可運作的 HIDS 機制。但是不管採用 opensource 還是付費的軟體,這些動作都只是第一步而已。真正的挑戰在於如何調整出一個濃纖合度的設定,在減少假警報 (False positive) 的同時,也不會漏失真正需要注意的資安事件 (False negative)。如此一來,才能真正發揮 SIEM 的功效,而不是成了一個中看不中用的花瓶。

2012年8月31日 星期五

[工具介紹] 利用 OpenNMS 監測 IP/MAC/Switch Port 使用情形

身為一個專業的系統管理人員,使用各式各樣的監測機制是絕對少不了的。監測可以分為兩大類,第一類是監測"應該存在"的項目,例如監測某台主機上的 Web 服務是否正常運作、或是某台主機的 CPU 使用量是否合理。這類監測項目通常與可用性 (Availability) 有關,而可用性是許多資訊系統存在的最重要目的,因此管理者往往會竭盡心力做好這類的監測。相對應於這類項目,還有另外一類的監測項目是屬於"不應該存在"的項目,像是某台主機不應該提供 MSSQL 的服務。這類監測項目因為通常與可用性無關,所以容易受到管理者的忽視。儘管如此,這類事件對資訊環境的安全性卻有著無比重要的地位。
以管理主機群來說,一個很重要的監測項目就是我們必須確保沒有多餘的服務在有意或無意下被開啟了,也必須確保沒有不必要的設備被接上了主機群所在的網路。後者對於一個實體管理嚴格的機房來說,或許是很難發生的狀況。但是以現今虛擬化的資訊環境來看,接上一台不被允許的"設備",卻再也不需要"出現在現場"才有可能達成了。今天要跟各位分享的這個工具 – OpenNMS,支援 SNMP 協定,可以用來抓取各項重要的資訊 (如網路介面流量數據) 並繪製為圖表。除了這個功能外,更重要的是 OpenNMS 可以定期掃描網路上 IP 的使用狀況,以及這些設備上所開啟的 (網路) 服務。一旦發現 IP 位址或 (網路) 服務情況有所變動,就可以透過各式各樣的通知機制通知管理者,以做出必要的因應之策。
OpenNMS 的監測機制,除了透過主動掃描以發現任何異動外,還支援 L2/L3 對應的能力。我們都知道,在常見的網路中,每個網路介面都具備兩種位址,一種是所謂的 MAC 位址,另外一種則是 IP 位址。MAC 與 IP 的對應關係,通常記錄於設備 (主機、交換器等) 的 ARP 快取表當中。而對於交換器而言,通常還會另外維護一份稱之為 CAM 表的資料。在 CAM 表當中,記載了 MAC 位址與交換器埠的對應關係,以達到封包交換的目的。CAM 表的存在,讓交換器不需要像集線器般使用廣播方式來傳送封包。OpenNMS 可以透過 SNMP 協定查詢網路設備的 ARP 快取表與 CAM 表,並記錄之間的關係,也就是說我們可以利用 OpenNMS 了解某個交換器上的某個埠接了哪些設備及其使用的 IP 位址。這些資料不只對於管理主機群時很重要,對於管理用戶端來說更是重要。因為用戶端通常處於開放且動態的實體環境,再加上用戶端系統的安全管理通常不如主機群般嚴謹,所以監控用戶端的網路連結情形絕對馬虎不得。事實上,這類資料就是屬於新版個資法中定義的軌跡資料,對於日後舉證需求將有莫大的助益
不過可惜的是,OpenNMS 預設並沒有開啟 L2/L3 對應的功能,所以我們需要修改設定檔才能獲得這樣的資訊。這個設定檔的位置是
$OPENNMS_HOME$/etc/service-configuration.xml
對以 rpm 方式安裝的 OpenNMS 而言,這個檔案的實際位置是
/opt/opennms/etc/service-configuration.xml

將下列這段文字取消註解即可:
<service>
  <name>OpenNMS:Name=Linkd</name>
  <class-name>org.opennms.netmgt.linkd.jmx.Linkd</class-name>
  <invoke at="start" pass="0" method="init"/>
  <invoke at="start" pass="1" method="start"/>
  <invoke at="status" pass="0" method="status"/>
  <invoke at="stop" pass="0" method="stop"/>
</service>
記得要重新啟動 opennms 服務才會使修改後的設定生效。服務重新啟動後,我們可以透過指令
service opennms –v status
來查看服務的執行狀態。如果看到下列訊息,表示 L2/L3 對應的功能已經正常啟動了。
...
OpenNMS.Statsd         : running
OpenNMS.Provisiond     : running
OpenNMS.Reportd        : running
OpenNMS.Alarmd         : running
OpenNMS.AsteriskGateway: running
OpenNMS.Ackd           : running
OpenNMS.JettyServer    : running
OpenNMS.Linkd          : running
opennms is running
一旦啟動 L2/L3 對應功能後,我們就可以在交換器節點 (Node) 的畫面看到如下的連結 (註一):
0001

點下連結 View Node Link Detailed Info 就可以看到詳細的交換器埠使用狀況:
0002

除了用表列的呈現方式,OpenNMS 也提供網路拓撲圖的呈現方式。透過網路拓撲圖,我們不但可以看到設備的連結關係,更可以即時看到各連結關係的狀態,方便管理者隨時掌握網路的狀態。OpenNMS 讓管理者可以確實掌握網路環境中 IP/MAC/Switch Port 的使用狀況,不管是任何未經授權的使用或變更,都將無所遁形。

註一:重新啟動服務後,需要很長的一段時間才會看到相關的資訊。我一直到隔天才看到資訊出現。

2012年8月29日 星期三

[教戰守則] 談 VMware 虛擬交換器之 Promiscuous Mode

Podtech_VMware_Disaster_Recovery_Datac在早期使用集線器當做網路的連結設備時,因為集線器的特性是使用廣播方式傳遞封包,所以網路上的任何一台電腦只要"有心"就可以看到不屬於它的封包。不過網路介面 (網路卡) 通常為了效能的考量,並不會處理所有傳送過來的封包,而會先檢查這些封包是否確實是它應該加以處理的,唯有它應該處理的封包才會進入系統並處理之。而 Promiscuos Mode,屬於網路介面的一種運作模式,在這種模式運作下的網路介面,會忽略檢查的動作並把網路上傳送過來的所有封包都交給系統處理。也就是說,在集線器的環境下,只要電腦的網路介面進入 Promiscuous Mode 就可以把網路上的封包看透透,其中肯定包含了不少重要的資料 (如密碼)。

好在現在使用的網路設備多屬於較為聰明的交換器,交換器在正常的運作情況下不使用廣播方式傳遞封包,所以即使我們將電腦的網路介面設定為 Promiscuous Mode 也無法窺得別台電腦的封包。不過有時候,我們 (網路管理員) 確實需要窺得其他電腦的封包,其中最常見的一種狀況就是佈署 IDS/IDP 時。此時,我們可以透過交換器的 Port Mirror 功能,讓交換器把其他電腦的封包複製一份至 IDS/IDP 所連結的交換器埠,好讓 IDS/IDP 看到這些封包。這是實體交換器的特性,那麼對於虛擬環境下使用的虛擬交換器呢?

在 VMware vSphere 5 ESXi 下,虛擬機預設只能看到遞送給它的封包。對於需要看到其他電腦封包的需求,虛擬交換器並沒有 Port Mirror 的功能,不過倒是有支援 Promiscuous Mode 的功能。Promiscuous Mode 的功能設定可以指定在整個虛擬交換器上,也可以指定在特定的 Port Group 上。對於虛擬交換器而言,Promiscuous Mode 的設定預設是關閉的。而 Port Group 預設則是沒有任何設定,因此會直接繼承虛擬交換器的設定,也就是同樣是關閉的。如果我們想要虛擬機具備看到其他電腦封包的能力,我們就必須讓這台虛擬機所在的 Port Group 擁有 Promiscuous Mode 的功能。根據前面所提,這個功能可以從虛擬交換器或 Port Group 的層級加以開放。從安全的角度來看,建議的作法是將這台虛擬機放入一個專屬的 Port Group,並 (只) 針對這個 Port Group 開放 Promiscuous Mode 的功能。如此一來,這台虛擬機就可以看到這個虛擬交換器內所有收送的封包了 (包含其他 Port Group,但不包含 Management Traffic)。以此看之,Port Group 是用來方便管理的單位,而不是為了模擬不同的實體網路。如果我們想要單一虛擬機僅能看到虛擬交換器上部分的封包 (而非全部封包),必須搭配 VLAN 的設計方式,而不是光透過 Port Group 就可以達成。

網路封包窺視是一個很嚴重的問題,其可怕之處不只在於可以窺得很多重要的資料,更令管理者感到困擾的是封包窺視通常是一種很隱密的被動攻擊行為。不管是在實體或虛擬環境下,如果佈署上不一小心,就可能變成全都露而不自知了。因此對網路管理者而言,了解虛擬交換器的運作方式就成了虛擬化過程中一個必須認真對待的課題了。

2012年8月28日 星期二

[迷你好兔] 利用 Host Profile 確保 VMware vSphere 5 ESXi 主機的設定狀態

Podtech_VMware_Disaster_Recovery_Datac
在上一篇的文章中,我分享了如何修改 ESXi 主機上的 syslog 設定。由於 syslog 設定是存在於各 ESXi 主機上,所以如何有效地設定所有 ESXi 主機並確認無所錯誤,就成了一件很重要的事情。在這一篇文章中,我將利用 Host Profile 的功能,幫助我們確保所有的 ESXi 主機都有相同的 syslog 設定。

不囉嗦,馬上就開始進行:
  1. 因為 Host Profile 屬於 VMware vCenter Server 的功能,所以我們需要使用 VMware Client 連結 VMware vCenter Server。直接連結 ESXi 主機無法使用 Host Profile 的功能。
  2. 選取 "Inventory" –> "Hosts and Clusters"。
  3. 選取一個已經修改好 syslog 設定的 ESXi 主機,並在右鍵選單中選取 "Host Profile" –> "Create Profile from Host…"。0001
  4. 輸入 Host Profile 的 Name (名稱) 與 Description (描述),輸入完畢後按下 "Next >"。
    0002
  5. 確認輸入無誤後,按下 "Finish"。
    0003
  6. 選取另外一台尚未修改 syslog 設定的 ESXi 主機,並在右鍵選單中選取 "Host Profile" –> "Manage Host Profile…"。
    0004
  7. 選取我們剛剛新增的 Host Profile,選取完畢後按下 "OK"。Host Profile 必須附加 (Attach) 於 ESXi 主機才有作用,而且一台 ESXi 主機僅能附加一個 Host Profile。
    0005
  8. 在右鍵選單中選取 "Host Profile" –> "Check Compliance" 以開始檢查作業。
    0006
  9. 檢查完畢後我們可以在 Summary 這個頁籤看到此主機的設定並不符合規範 (Host is not in compliance with the attached profile)。
    0007
  10. 在 Summary 這個頁籤的下方可以找到相關資訊。
    0009
  11. 點選連結後可以看到詳細資訊,顯示 Syslog.global.logHost 這個設定值不符合規範 (Option Syslog.global.logHost doesn’t match the specified criteria)。
    0008
  12. 我們可以透過右鍵選單中的 "Host Profile" –> "Apply Profile…",將相關設定自動套用到選取的 ESXi 主機。
    0010
  13. 不過在使用 Host Profile 自動套用的功能時,ESXi 主機必須先進入維護模式 (Maintenance mode) 方可進行。對於不適合進入 Maintenance mode 的 ESXi 主機,可以使用手動的方式進行設定。
    0011
Host Profile 除了可以幫助我們簡化設定的作業,更重要的是 Host Profile 可以幫助我們確保設定的正確性。Host Profile 可有效地避免因為人為疏失或其他因素所造成的設定值不正確,進而危害到整個虛擬作業的有效性或/與安全性。

About