不只是資安

[工具介紹] 利用 collectd + InfluxDB + Grafana 監測系統效能

2016-09-08T17:36:00.000+08:00

傳統上用來監測網路流量、系統效能數據的常用工具多以 RRD 為基本的技術，這類工具包含 MRTG 與 Cacti。RRD 有幾個明顯的缺點，其中一個就是資料的解析度會隨著時間的過去而降低。

例如在 Cacti 中，過去 24 小時的流量圖表是長這樣:

但是一周前的 24 小時的流量圖表就變成這般可怕的模樣:

當你不幸地需要歷史數據資料時，別說要如何進行分析了，光拿出這種圖表就需要莫大的勇氣。

在講究高清不失真的這個年代，以 RRD 為基礎的工具已經漸漸不符合我們所需。

目前比較常見用來記錄時間數據的工具，應以 ELK stack 為首。ELK stack 以 Elasticsearch 為核心，可用來分析各式各樣的資料。這個特性是它的強項，不過在某些時候卻也變成它的弱點 (過於複雜)。而我今天要介紹的 collectd + InfluxDB + Grafana，正是以處理時間數據為主，所以在製作與時間數據相關的圖表時會更為簡化。
Grafana 本身類似 ELK 的 Kibana，主要作為圖表呈現的部分。而資料來源的部分，除了 InfluxDB 之外，像是 Graphite、OpenTSDB、甚至是 Elasticsearch 也都可以支援。在此架構中，collectd 會負責收集作業系統的效能數據，並將之”餵進” InfluxDB，最後再透過 Grafana 的圖表予以呈現。

在今天的範例中，我將示範如何在 CentOS 7 中利用 collectd + InfluxDB + Grafana 建置一個呈現系統效能數據的儀表板。需特別注意的是，為了簡化範例的說明，所有的套件皆安裝在同一個系統 (IP 位址為 192.168.111.241) 下。而在實務上，這三個套件通常應分散在不同的系統上。

安裝 InfluxDB

透過官方 RPM Repo 安裝 InfluxDB 套件

cat<<EOF>/etc/yum.repos.d/influxdb.repo
[influxdb]
name = InfluxDB Repository - RHEL $releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF
yum install influxdb -y
systemctl enable influxdb.service
systemctl start influxdb.service

配置防火牆

cat<<EOF>/etc/firewalld/services/influxdb.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>InfluxDB</short>
  <description>InfluxDB is an open source time series database with no external dependencies. It's useful for recording metrics, events, and performing analytics.</description>
  <port protocol="tcp" port="8083"/>
  <port protocol="tcp" port="8086"/>
</service>
EOF
chmod 600 /etc/firewalld/services/influxdb.xml
firewall-cmd --add-service=influxdb --permanent
firewall-cmd --reload

透過指令 influx 進入 influxdb 命令列模式，並輸入下列命令創建管理者帳密

create user admin with password 'password' with all privileges;  
exit

利用瀏覽器連結 influxdb 管理介面，網址是 http://192.168.111.241:8083，應可看到類似下列畫面

安裝 Grafana

透過官方 RPM Repo 安裝 Grafana 套件

cat<<EOF>/etc/yum.repos.d/grafana.repo
[grafana]
name=grafana
baseurl=https://packagecloud.io/grafana/stable/el/6/\$basearch
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packagecloud.io/gpg.key https://grafanarel.s3.amazonaws.com/RPM-GPG-KEY-grafana
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
EOF
yum install grafana –y
systemctl enable grafana-server.service
systemctl start grafana-server.service

配置防火牆

cat<<EOF>/etc/firewalld/services/grafana.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Grafana</short>
  <description>Grafana provides a powerful and elegant way to create, explore, and share dashboards and data with your team and the world.</description>
  <port protocol="tcp" port="3000"/>
</service>
EOF
chmod 600 /etc/firewalld/services/grafana.xml
firewall-cmd --add-service=grafana --permanent
firewall-cmd --reload

設定 influxdb collectd plugin

安裝 collectd 套件

yum install collectd -y

修改檔案 /etc/influxdb/influxdb.conf，將 [[collectd]] 區塊的

enabled = false

改為

enabled = true
bind-address = ":25826" # the bind address
database = "collections" # Name of the database that will be written to
retention-policy = ""
batch-size = 5000 # will flush if this many points get buffered
batch-pending = 10 # number of batches that may be pending in memory
batch-timeout = "10s"
read-buffer = 0 # UDP read buffer size, 0 means to use OS default
typesdb = "/usr/share/collectd/types.db"
#enabled = false

重新啟動服務

systemctl restart influxdb.service

配置防火牆

cat<<EOF>/etc/firewalld/services/collectd.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>collectd</short>
  <description>collectd daemon for InfluxDB</description>
  <port protocol="udp" port="25826"/>
</service>
EOF
firewall-cmd --add-service=collectd --permanent
firewall-cmd --reload

透過指令 influx 進入 influxdb 命令列模式，並輸入下列命令創建資料庫與存取帳密

CREATE DATABASE collections
CREATE USER collectdrw WITH PASSWORD 'readwrite'
GRANT ALL ON collections to collectdrw
CREATE USER collectdread WITH PASSWORD 'readonly'
GRANT READ ON collections TO collectdread
exit

設定 collectd for influxdb

這個動作需在需收集效能數據的各主機上分別執行。

設定 collectd 服務所需的外掛。在此範例中我們沒有另外新增數據收集的外掛，僅增加了將資料送往 InfluxDB 的外掛。

cat<<EOF>/etc/collectd.d/network.conf
Hostname    "grafana"
FQDNLookup  false
LoadPlugin  network
LoadPlugin  uptime
<Plugin network>
  Server "192.168.111.241" "25826"
</Plugin>
EOF
systemctl enable collectd.service
systemctl start collectd.service

回到 influxdb 的管理介面，重整後在 Database 下拉式選單中應可看到多了一個名為 collections 的資料庫。
選取 collections 後，在 Query Templates 中選取 Show Measurements。
按下 Enter 後，應可看到類似下面的結果，表示 collections 中已有 cpu_value 等數據。
接著，我們輸入 SHOW TAG KEYS FROM "cpu_value" 並按下 Enter，應可看到類似下列畫面。結果顯示 cpu_value 包含四個 key，分別為 host、instance、type 以及 type_instance。
接著，我們輸入 SHOW TAG VALUES FROM "cpu_value" WITH KEY = "host" 並按下 Enter，應可看到類似下列畫面。結果顯示 host 這個 key 的內容僅包含 grafana，也就是我們目前唯一已經設定過的 collectd 服務主機名稱。
接著，我們輸入 SHOW TAG VALUES FROM "cpu_value" WITH KEY = "host" 並按下 Enter，應可看到類似下列畫面。結果顯示 InfluxDB 已確實收到來自於 collectd 服務的效能數據。

設定 Grafana Dashboard

利用瀏覽器連結 Grafana 管理介面，網址是 http://192.168.111.241:3000，應可看到類似下列畫面
使用預設帳密 admin / admin 登入系統。
點選左上角的圖示後會出現主要選單，點選 admin 後可以修改基本資訊與密碼。
同樣利用主選單的 Data Sources 選項，進入後按下右上角的 "+Add data source" 按鈕。
分別填入下列資訊，其中 Url 欄位因為我們選取 direct 的存取方式，所以不能使用預設的 http://localhost:8086，而必須指定為 http://192.168.111.241:8086。

Name: Collectd
Default: 選取與否皆可
Type: InfluxDB
Url: http://192.168.111.241:8086
Access:direct
Http Auth: 兩個選項皆不用選取
Database: collections
User: collectdread
Password: readonly
Default group by time: 保留空白

填寫完畢後按下 "Add" 按鈕。如果 Data Source 可以正常連結的話會出現類似下列的成功畫面，否則會出現錯誤訊息。
利用主選單的 Dashboards > + New 開始新增儀表板。
利用 Manage dashboard 的 Settings 功能可修改儀表板的相關設定。
在此範例中我們僅設定名稱即可，將之設定為 System Information，設定完畢後按下右上方的 X 即可回到 Dashboard 的畫面。
點選左上方的綠色區塊後會出現 ROW 功能選單，選取 Add Panel > Graph。
Graph 有多個頁籤設定，其中 Metrics 可用來配置資料相關設定。首先，我們須將 Panel data source 改為 Collectd。
此時我們會發現 Metrics A 內容有所改變，點選後出現圖形化編輯選項。
Grafana 的圖形化編輯功能相當方便，不過為了方便說明，所以我們透過 Toggle Edit Mode 進入直接編輯模式。

輸入下列內容

SELECT last("value") FROM "load_shortterm" WHERE "host" = 'grafana' AND $timeFilter GROUP BY time($interval) fill(null)

透過 "+ Add query" 按鈕另外新增兩個 Metrics，內容分別為

SELECT last("value") FROM "load_midterm" WHERE "host" = 'grafana' AND $timeFilter GROUP BY time($interval) fill(null)
SELECT last("value") FROM "load_longterm" WHERE "host" = 'grafana' AND $timeFilter GROUP BY time($interval) fill(null)

切換至 General 頁籤，將 Panel 的標題修改為 Load。
切換到 Legend 頁籤，勾選 Min、Max、Avg 以及 Current。
設定完畢後按下右方的 X 即可回到 Dashboard 畫面，然後按下 CTRL+S 將 Dashboard 予以儲存。
之後就可以透過 Dashboard 下拉式選單快速連結至我們剛剛新增的 System Information Dashboard 了。

透過幾個簡單的設定，我們就建立了一個系統負載的數據圖表。

下一步

Grafana 除了圖形類 (Graph) 的報表之外，另有提供表格式 (Table) 、單一數值 (Singlestat) 與其他種類的報表。
此外，我們的範例是針對特定的單一主機來進行配置。但是我們通常不會只有管理一台主機，此時就可以透過 Dashboard 的 Templating 機制設定一個變數用來代表主機名稱，然後將 Metrics 的條件指定為此一變數，而非原先固定的主機名稱。如此一來，Dashboard 就會提供一個所有主機名稱的下拉式選單，方便我們觀看個別主機的相關數據。

盡管如此，我們會發現自己要從無到有刻出一個合用且美觀的報表其實也不是那麼簡單的事情。幸好 Grafana 有提供儀表板匯出/匯入的功能，而且有善心人士已經將一些常見的效能數據儀表板匯出並提供下載 (清單在此)。不過在選用這些儀表板時，需特別注意的是它使用的資料來源是哪一種 (InfluxDB、Graphtie 或是其他的資料來源)，以免發生牛頭不對馬嘴的狀況。

[工具介紹] 以 Apache myfixip 模組支援 Proxy Protocol

2016-09-04T22:43:00.001+08:00

我在前一篇文章中提到，HAProxy 推出 Proxy Protocol 用以解決在代理伺服器架構下無法取得用戶端 IP 位址的困境。在這篇文章中，我將以 HAProxy 搭配 Apache + myfixip 模組，實際展示如何透過 Proxy Protocol 解決用戶端 IP 位址的問題。
本次展示的架構如下 :

其中代理伺服器使用 CentOS 7 的 HAProxy 1.5.14 套件，而 Web 服務器使用 CentOS 7 的 Apache 套件。
我們先在 Web 服務器放置內容如下的 PHP 腳本，而在 PHP 中，$_SERVER["HTTP_X_FROWARDED_FOR"] 這個變數就代表 HTTP 檔頭 X-Forwarded-For。

<?php
echo nl2br("X-Forwarded-For: " . $_SERVER["HTTP_X_FORWARDED_FOR"] . PHP_EOL);
echo nl2br("Remote Address: " . $_SERVER["REMOTE_ADDR"] . PHP_EOL);

用戶端直接連結 Web 服務器

當用戶端直接連往 Web 服務器 (192.168.10.12) 上的 PHP 腳本後，可以看到如下的輸出：

HTTP-X-Forwarded-For:
Remote Address: 192.168.10.10

在這種單純的情況下，直接使用 REMOTE_ADDR 變數即可取得用戶端的 IP 位址。

用戶端透過 HAProxy 的 HTTP 模式連往 Web 服務器

我們在 HAProxy 使用下列設定：

listen http-proxy
bind 0.0.0.0:80
mode http
option httpchk
option forwardfor
balance source
server web-1 192.168.10.12:80 weight 1 check

當用戶端透過代理伺服器 (192.168.10.11) 連往 Web 服務器 (192.168.10.12) 上的 PHP 腳本後，可以看到如下的輸出：

X-Forwarded-For: 192.168.10.10
Remote Address: 192.168.10.11

在這種情況下，儘管 REMOTE_ADDR 變數顯示為代理伺服器的 IP 位址，但是使用 HTTP_X_FROWARDED_FOR 變數依舊可取得用戶端的 IP 位址。

用戶端透過 HAProxy 的 HTTP 模式連往 Web 服務器

我們將 HAProxy 的設定修改成如下：

listen http-proxy
bind 0.0.0.0:80
mode tcp
balance source
server web-1 192.168.10.12:80 weight 1 check

當用戶端透過代理伺服器 (192.168.10.11) 連往 Web 服務器 (192.168.10.12) 上的 PHP 腳本後，可以看到如下的輸出：

X-Forwarded-For:
Remote Address: 192.168.10.11

在這種情況下，不存在 HTTP_X_FROWARDED_FOR 變數，而 REMOTE_ADDR 顯示的也是代理伺服器 IP 位址。也就是程式無法正確獲得用戶端 IP 位址。

用戶端透過支援 Proxy Protocol 的設定連往 Web 服務器

因為 HAProxy 本身就內建支援 Proxy Protocol，所以不需安裝額外的套件，只要把設定修改成如下即可：

listen http-proxy
bind 0.0.0.0:80
mode tcp
balance source
server web-1 192.168.10.12:80 weight 1 check send-proxy

至於 Apache 的部分，因為 Apache 目前尚未內建 Proxy Protocol 的支援，所以我們需要安裝另外的模組。在此，我以 myfixip 模組為例，相關步驟如下:

yum install git gcc httpd-devel
cd /tmp
git clone https://github.com/ggrandes/apache24-modules.git
cd apache24-modules
apxs –i –c mod_myfixip.c

新增檔案 /etc/httpd/conf.modules.d/00-myfixip.conf，內容如下

LoadModule myfixip_module modules/mod_myfixip.so
<IfModule mod_myfixip.c>
   RewriteIPResetHeader off
   RewriteIPAllow 192.168.10.0/24 127.0.0.1
</IfModule>
systemctl restart httpd

需特別注意的是因為 Proxy Protocol 會改變代理伺服器與 Web 服務器之間的溝通方式，所以需要兩邊同時啟用，否則將無法正常運作，甚至可能導致無法存取服務。
當用戶端再次透過代理伺服器 (192.168.10.11) 連往 Web 服務器 (192.168.10.12) 上的 PHP 腳本後，可以看到如下的輸出：

X-Forwarded-For:
Remote Address: 192.168.10.10

在這種情況下，即使經過代理伺服器的作用，但是 REMOTE_ADDR 變數依舊可以正確地顯示出用戶端的 IP 位址。

透過 myfixip 模組，可以讓 Apache 支援 Proxy Protocol，有效地取得用戶端 IP 位址。
除了 HAProxy 之外，如果你使用了 AWS ELB 的 TCP 或 SSL 模式，透過 myfixip 擴充 Apache 使其支援 Proxy Protocol 也同樣會有很大的助益。比較麻煩的是，目前 AWS 的管理介面並不支援 Proxy Protocol 的設定，而必須使用命令列模式控制 Proxy Protocol 的開啟或關閉。有需要的讀者可參考官方文件。

[教戰手則] 狡詐的用戶端真實 IP 位址

2016-09-04T11:53:00.000+08:00

在 TCP/IP 網路的世界裡，盡管 IP 位址本身有很多的問題，但是用戶端的 IP 位址對許多安全機制來說依舊是一個很基本且重要的資訊。舉例來說，利用用戶端的 IP 位址當做存取控制的依據，就是常見的第一道安全門檻。除此之外，各式各樣的系統日誌，也幾乎都包含用戶端的 IP 位址來當作用戶端的身分紀錄。尤其對像是 HTTP 這類網路服務而言，用戶端的 IP 位址往往更是最主要的身分代表。
誠如 DEVCORE 在 “如何正確的取得使用者 IP?” 這篇文章中所提到，因為所有用戶端的資訊都是不可靠的，再加上眾多代理伺服器從中攪局，所以如何”正確的”取得用戶端 IP 位址這個看似再簡單不過的問題卻變得相當複雜，甚至無法在所有的情況下都能順利完成目的。
我在此先直接引用自該文章的結論
”那我們該怎麼處理呢？我的建議是記錄所有相關的 header 欄位存入資料庫，包含「REMOTE_ADDR」「X-Forwarded-For」等等，真正有犯罪事件發生時，就可以調出所有完整的 IP 資訊進行人工判斷，找出真正的 IP。當然從 header 存入的數值也可能會遭到攻擊者竄改插入特殊字元嘗試 SQL Injection，因此存入值必須先經過過濾，或者使用 Prepared Statement 進行存放。
可以參考的 HTTP Header（依照可能存放真實 IP 的順序）

HTTP_CLIENT_IP
HTTP_X_FORWARDED_FOR
HTTP_X_FORWARDED
HTTP_X_CLUSTER_CLIENT_IP
HTTP_FORWARDED_FOR
HTTP_FORWARDED
REMOTE_ADDR (真實 IP 或是 Proxy IP)
HTTP_VIA (參考經過的 Proxy)”

而今天我要分享的是另一種情境，那就是當你的代理伺服器因為太有個性，除了 REMOTE_ADDR 之外其他檔頭 (Header) 都不願意送出呢 (嚴格來說，REMOTE_ADDR 其實根本也不是 HTTP 檔頭) ?在實務上，當你使用 HAProxy 的 TCP Mode 時，它就是這麼有個性。
基本上，HAProxy 有兩種運作模式，一種稱之為 HTTP 模式。在 HTTP 模式下，可以對用戶端送來的檔頭做判斷與處理，當然也包含檔頭的新增與內容修改。而在 TCP 模式下，這些功能都無法獲得。或許有讀者會質疑運作在 TCP 模式下的 HAProxy 是否還算是一個代理伺服器?這種定義的問題，我並不想在此討論，而就實務的情況來看，這種情況就是真實存在的。
既然 TCP 模式比之 HTTP 模式就像被閹割般的無能，那為什麼我們還會需要使用 TCP 模式呢?常見的情況有二，一個是因為 SSL/TLS 加密的因素。如果你的網站支援 SSL/TLS 加密，那麼使用 HAProxy 後你有兩種選擇，一種是把 SSL/TLS 加解密交給 HAProxy，這種情況又稱之為 SSL Termination (請參考下圖)。SSL Termination 常用於 SSL 加速，另外也可能是為了 IDS/IDP/DLP 這類需要分析封包內容的安全機制而必須先將 SSL/TLS 連線予以解密。

但是因為 HAProxy 本身也是軟體形式，所以對於 SSL 加速沒有甚麼幫助，甚至有可能反而造成效能的瓶頸，所以第二種選擇就是把 SSL/TLS 加解密維持在原有的地方，例如 Web Server 本身。在這種情境下，因為所有經過 HAProxy 的封包內容都已經經過加密，所以 HAProxy 僅能透過 TCP 模式與後端 Web Server 溝通，而無法使用 HTTP 模式。
另外一個因素則是如果你需要代理的服務不是 HTTP，而是其他的網路服務 (像是 MySQL)，當然就不能使用 HTTP 模式，而必需使用 TCP 模式。
而不幸的是，不管是在 HTTP 模式或 TCP 模式之下，都是由代理伺服器代替用戶端傳送封包，所以 REMOTE_ADDR 皆會顯示為代理伺服器的 IP 位址。還好在 HTTP 模式下，HAProxy 會加上 X-Forwarded-For 這個檔頭，所以我們還是有機會取得用戶端的真實 IP 位址。但是在 TCP 模式下，HARroxy 無法新增任何檔頭，也讓我們失去獲得用戶端真實 IP 位址的機會。
那麼我不用 HAProxy 不就沒事了?當然不是。即使是其他的 HTTP 代理伺服器，只要考慮到 SSL/TLS 加解密，就都有類似的問題。舉例來說，現在很熱門的 AWS ELB 在某些模式時也會有跟 HAProxy TCP 模式一樣的情形。
有鑑於此，HAProxy 特別訂出了所謂的 Proxy Protocol。只要是支援 Proxy Protocol 的代理伺服器與網路服務相互搭配，透過適當的設定就可以取得用戶端的 IP 位址。當然，這個用戶端 IP 位址，不一定是真實的用戶端 IP 位址，不過通常至少是連往代理伺服器的 IP 位址，而不是全部變成代理伺服器的 IP 位址。除了 HAProxy 本身的支援外，許多代理服務器或服務也都內建或透過外接模組的方式，提供此一功能的支援。詳細清單可參考這裡。
在下一篇文章中，我將使用 HAProxy + Apache 的 myfixip 模組當作範例，實際展示 Proxy Protocol 的運作。
相關連結:

[資安觀念] 有備就無患？

2015-04-22T16:04:00.002+08:00

在筆者接手過的系統中，備份機制是一個常見但是卻也常常做的不足的事情。在討論何謂足夠的備份機制之前，我們先來看看一個更基本的問題，那就是備份對現代化資訊系統的必要性。
隨著 IT/IS 技術的不斷進步，高可用性 (HA) 的系統已經是基本的配置。除此之外，災難復原 (DR) 更是考慮到了實體的安全，當主要系統的所在地無法正常運作時，可以在最短的時間內於第二個地點恢復服務。甚至，有了號稱可以提供 100% uptime 的雲端系統，備份豈不多餘？
答案絕對是否定的。正所謂天有不測風雲，設計再精良的系統，都無法保證絕對不會受到損害，而備份就是資訊可用性的最後一道重要防線：

相較於 HA / DR 的技術，備份技術擁有選擇性多、成熟度高、費用便宜等好處。其中選擇性多可以避免發生被單一廠商吃死的狀況。
即使是號稱 100% uptime 的雲端系統，也無法確保真的不會出問題。雲端系統的架構可能比(大部分的)私有架構更為成熟，但是絕對不會一躍變成神一般的等級。
有些問題非 HA / DR 技術可解決，其中之一正是豬一般的隊友。如果你曾經看過 delete from members (SQL command) 或 rm -rf / (SHELL command) 的 Live Show，你就絕不會懷疑備份的重要性。此時，備份 (加上 transaction log) 就可以避免你直接升天。
備份除了可以保全資料，在不得已 (沒預算) 的情況下還可以用來解決需要長期保留資料的問題 (如日誌)。儘管如此，如果在預算許可的情況下，後者還是應該選擇專門用於封存 (Archiving) 的技術。

既然備份依舊是 IT/IS 不可避免的項目，那麼回到一開始的話題，何謂不足的備份機制？常見的情況包含：

備份的目標不完整。舉例來說，公司有三台資料庫主機，卻只有備份到其中兩台。或是明明主機內有五個資料庫，卻只備份到其中三個。這個問題發生的原因通常是沒有落實相關作業的 SOP 或變更管理。
備份的項目不完整。跟前述有點類似，但是主要是指有些該備份的東西卻完全沒有備份。舉例來說，像是使用者上傳的檔案、系統的設定檔等，可能都忘了加入備份機制。這類問題發生的原因通常在於沒有做好系統分析或數位資產分類。
備份沒有進行相關的檢查工作。舉例來說，確認壓縮檔可以正常解壓，又或者資料庫的備份檔可以確實地予以還原。這部份可以透過自動化的程序簡化檢查工作。
備份資料防護不足。既然備份的資料多為公司重要的數位資產，那麼做好保護以避免不相關人士的存取 (甚至竄改) 就顯得相當重要。簡單來說，備份資料的安全防護至少應等同於線上資料的安全防護，甚至是擁有更高等級的防護機制。
備份資料的存放點不足。我看過最誇張的例子就是將僅有的備份放在同一台主機的同一個分割區內。備份就是為了避免當突發狀況發生時遭受資料遺失的風險，把備份資料放在同一個分割區不就宣告只要硬碟一壞就整個 GG 了嗎？
硬碟會不會壞？你買硬碟時廠商都清清楚楚地標示了保固期跟 MTBF，所以硬碟壞掉根本就是可預期會發生的災難。你會說我用 RAID 啊，一顆硬碟壞掉沒問題的啦，那 RAID 卡就不會故障並把資料搞亂嗎？相信我，我還真遇過。

針對上述第五點，比較嚴謹的作法可參考所謂的 3-2-1 備份法則 (3-2-1 backup rule)：

每一筆資料至少擁有三個分身 (Have at least three copies of your data)
至少使用兩種以上的儲存媒介 (Store the copies on two different media)
保留其中一個分身於異地 (Keep one backup copy offsite)

把僅有的備份資料放在同一個分割區，明顯違反了 3-2-1 備份法則的所有規則。據此，我們可以考慮將主要的備份資料放在同一個機房內的網路硬碟，而次要的備份資料則放在異地。如果主要資料的所在地為辦公室，可以考慮利用雲端硬碟儲存次要的備份資料。但是如果主要的備份資料所在地為 IDC，那麼辦公室或雲端硬碟就可以擇一以用來存放次要的備份資料。透過幾個簡單的規則，下次就算發生機房失火這種極度恐怖的災難，你也可以全身而退了。

[從電影看資安] 凡瀏覽過必留下痕跡 - 超急情聖

2014-02-14T12:08:00.000+08:00

在電影超急情聖 (Don Jon) 中，男主角 Joseph Gordon-Levitt 飾演的唐冏平日沒啥興趣，就是跟三兩好友到夜店對女生品頭論足，並各自帶著”戰利品”回去享用一番。雖然看似令許多男生羨慕不已，不過唐冏這位老兄更大的興趣竟然是上色情網站享受 DIY 的快感。
就在一次夜店行動中，唐冏遇到了由 Scarlett Johansson 所飾演芭芭拉。唐冏視芭芭拉為天菜，當然不可能放過。雖然兩人交談甚歡，但是仍舊功虧一簣，逼的唐冏只好利用人肉搜索的方式找到芭芭拉的 Facebook 帳號。
兩人交往後，唐冏不改上色情網站的嗜好，甚至當場被芭芭拉抓包。為了手上的這隻鳥，唐冏只好宣示從此放棄網路上的這片大好森林。只不過江山易改，本性難移。雖然唐冏與芭芭拉進展順利，但是唐冏卻依舊偷偷持續上色情網站滿足生理所需，直到有一天…

DIY 帶給唐冏天堂般的樂趣

到夜店對女生品頭論足也是一定要的啦

慘了，遇到"舊情人"
甩了舊情人，馬上就發現天菜

被天菜打槍，只好退而求其次

得不到的最令人懷念

人肉搜索

可以一起看電影

可以在電影院熱吻

但是就是不能上床

就算上床也只能用"正常的姿勢"

只好看 A 片解解悶，沒想到卻被當場抓包

唐冏扯謊後兩人感情進展神速

46個？

唐冏該不會真不知道有瀏覽記錄這種東西吧？

年輕真好？

這下真的冏了
不過就是看 A 片嘛

心情鬱悶到只能上色情網站尋求慰藉芭芭拉因為瀏覽器的瀏覽記錄而發現唐冏一直欺騙她，不但持續上色情網站，甚至可說是不眠不休，因此憤而離開唐冏。
利用瀏覽器上網，對使用電腦的人來說，可是說是再自然不過的事。而瀏覽器為了提供使用者更方便的使用經驗，也加入了許多聰明的機制。像是瀏覽記錄、網頁快取、Cookie、輸入欄位 (包含密碼) 等各式記錄，都可以大幅提昇使用經驗。不過這些資料，卻也可能包含了個人的私密資料 (如上色情網站的記錄)。這些資料一旦被揭露後，輕則尷尬收場，嚴重時身分被盜用也是有可能的。如果使用的是自己的私人電腦，對此倒也不用太過緊張。不過如果使用的是其他人的電腦、甚至是公共電腦，這可就是個大問題了。
對此，各個瀏覽器都有提供所謂的清除記錄功能，可以將上述資料分別加以清除。不過在使用時因為要手動執行，所以並不是很方便。比較方便的作法，可以使用如 Chrome 瀏覽器的”無痕式視窗”。透過無痕式視窗，我們就可以放心的使用其他人的電腦或公共電腦，而不用擔心留下任何記錄。不過儘管如此，還是應該避免在這些電腦使用很重要的網路服務 (如網路銀行)。因為無痕式視窗雖然可以避免留下記錄，但是卻無法避免後門程式竊取你所輸入的資料，所以還是有可能會有帳號被盜的可能性，可是千萬輕忽不得。

[從電影看資安] 小小的 USB 隨身碟，大大的資安問題 - 決勝機密

2014-02-11T04:37:00.000+08:00

在電影決勝機密 (Paranoia) 中，男主角亞當卡西迪 (由 Liam Hemsworth 飾演) 任職於兩大電信公司之一的懷特電信。亞當出身藍領家庭，為了過更好的生活在公司中力求表現。雖然帶領的團隊有不錯的產品，但是在一次的簡報會議中得罪了大老闆，只好整組人打包~~到夜店尋歡~~回家吃自己。不過夜店尋歡就算了，亞當竟然還把帳算到前公司的頭上。大老闆尼可拉斯懷特對此相當不爽，威脅他必須到敵對公司艾康電信去當商業間諜，竊取最新產品的資訊。亞當被逼的別無選擇，只能默然接受。面試過程相當順利，還遇到了在夜店發生一夜情的女主角艾瑪詹寧斯 (由 Amber Heard 飾演)，原來她正是艾康電信的大將啊。
為了順利取得機密，亞當不但要拍新老闆賈克高達的馬屁，還得繼續陪女主角上床。就在一次翻雲覆雨後，亞當趁艾瑪洗澡時，順利從艾瑪的電腦中找到新產品的資料，並複製到 USB 隨身碟當中。亞當交差後，尼可拉斯懷特認為取得的資料還不夠，亞當只好規劃再一次的動作 - 侵入艾康研發中心竊取新產品的原型機。亞當成功利用竊取到的女主角指紋進入研發中心的管制區域，不過卻發現原來整件事是新老闆賈克高達的詭計，為的就是引誘尼可拉斯懷特犯罪，以便惡意收購懷特電信。深受無妄之災的亞當，利用原本被打槍的技術，順利取得對話記錄並指引 FBI 前往三人秘密會談的地點，讓兩個老闆一起到牢裡圍爐吃鱉。

男主角亞當是一個手機應用高手

健保好，沒有健保只好哭到飽

要升級就看這一次了

直接被大老闆打槍，冏

為什麼老外離職都只要一個紙箱就可以清完家當？

自動定位美女模式

不是應該聊聊昨晚的表現嗎？

表現可想而知

上個夜店竟然要 16000 美金！

當老闆就是懂得把握機會

快把這個笨小子推出去

面試裝上身

世界真是小小小

還好我已經先在夜店打好關係了

這種話還需要用問句嗎？

…

我絕不是在偷看女主角洗澡

目錄已經被鎖定

不怕，因為…

密碼就藏在包包裡！

WiFi 密碼也都幫你傳便便

既然有 USB 隨身碟，連 WiFi 是連心酸的嗎？

為什麼我老是找不到重要的檔案在哪裡？

雖然有些事情慢點好，但是不包含 USB 隨身碟的速度

還好動作夠快，順利取得資料

USB 隨身碟是一個偉大的發明，帶給我們方便的生活。不過 USB 隨身碟帶來的資安風險，卻也是讓人頭痛不已。USB 隨身碟的問題有兩個面向，一個是往內，另外一個則是往外的。所謂的往內，就是一些惡意的後門程式透過 USB 隨身碟進入電腦，甚至因而擴散到其他的電腦設備。而往外則是不應該外流的資料透過 USB 隨身碟洩漏出去。兩者相較，前者算是比較單純的問題，而後者則複雜許多。原因在於外流的資料包含兩種情況，一種是無意的，另外一種則是有心。一旦這兩種情況混在一起，就會產生方便性與安全性考量的衝突。電影中，男主角利用 USB 隨身碟帶走了女主角電腦中的機密資料就屬於有心的資料外流意外。雖然女主角有針對目錄進行鎖定，但是把密碼跟電腦一起放在包包裡，就跟把 ATM 提款機密碼寫在提款卡上面的行為一樣智障。

針對 USB 隨身碟的資安問題，一般常見的簡單手法包含限制 USB 使用、限制可連線的 USB 設備等。不過這些手法通常只有開跟關的選擇，應用上的限制較多，比較完整的方案則屬於資料外洩防護 (DLP) 與加密 (DRM) 兩種類型。簡單來說，DLP 著重在資料流出前的保護，而 DRM 則在流出後的保護。流出後的保護？沒錯，因為前面說到資料的流出可能是無心的 (例如 USB 隨身碟遺失)，甚至是必要的 (如透過 USB 隨身碟把檔案交給第三方)，而 DRM 可以確保這類狀況不會危害到資料的安全。在技術上，DLP 與 DRM 並不是二選一的問題。不過在實務應用與經濟考量上，DLP 與 DRM 通常不會一起導入，甚至一同運作時會互相影響。至於要選哪個，就看企業自己的評估與考量了。

[從電影看資安] 權限管理做的好，核彈乖乖不亂跑 - 白宮末日

2014-02-04T20:03:00.000+08:00

去年美國白宮可說是流年不利，一連被炸毀了兩次，一次是在電影「全面攻佔：倒數計時」中，另外一次則是在今天我要跟各位分享的這部電影 - 「白宮末日」中。

講到美國政府，恐怖份子的目標總是不離核彈，而這兩部片也都無法免俗。在全面攻佔這部片中，三個美國最有權力的政治人物必須同時提供自己的密碼才能夠啟動核彈。雖然細節上有所不同，不過概念上與我之前的文章「缺一不可 – Two-Man Control」一樣，只是角色從兩個人變成了三個人。

至於在白宮末日中，核彈的啟動則同時需要美國總統的血型 (？)/心跳與密碼，在資安上屬於多重因素驗證 (Multi-factor Authentication) 機制。以發射核彈這樣高度敏感的作業而言，採用 Two-Man Control 會比多重因素驗證來的保險許多，原因在於可以避免因為美國總統個人的失心瘋而造成世界毀滅。不過這次分享內容的重點不在此，我們從權限的管理(回收)來看這個事件：

男主角從 G.I. Joe 逃脫後變成了議長的隨扈

有夠無聊的工作

還是當總統的隨扈比較屌，趕緊找關係

即使出賣身體也不在乎

人帥真好！

既然都出賣身體了，多要幾張白宮通行證也只是剛好

當然沒時間去看女兒的才藝表演，因為去~~陪吃飯~~保護議長了

拯救世界的英雄一開始一定是個糟老爸

這是美國總統隨扈的指揮官，兒子戰死在國外的一次行動中

男主角的女兒是個政治迷，連 PEOC 這麼專業的名詞都知道

解說員當然要臭屁一下，據說連核彈都炸不穿是吧？

轟!

白宮”又”被炸了

恐怖份子

比恐怖份子還恐怖的內奸，PEOC 再猛也沒用

男主角”不小心”就救了美國總統

破解核彈發射密碼只要30分鐘！

副總統搭著空軍一號到天上避難去了

不錯，還記得要更換核彈發射密碼

一行人對於如何處理美國總統失聯一事爭論不已

好機會

副總統在空軍一號上宣示成為總統

熱騰騰的核彈發射密碼

是有沒有這麼倒楣？

這下真的升天了

冏～史上最短命的美國總統

老三也會出頭天，議長成為新的總統

核彈發射器

真是先進的技術，血型也可以拿來當做身分辨識 (？)

原本的美國總統終於露面啦，不過他已經被取代兩次，密碼沒用也是必然

大叔可是很堅持的

這到底是偵測血型還是掌紋啊？不過多了好幾根手指頭，是外星人的掌紋吧

這樣也行！

沒想到大叔連核彈發射密碼都有

有需要這麼驚訝嗎？

想也知道就是你這個老三搞的鬼啊

Money Talks

終究還是邪不勝正啊

在電影中，原本的美國總統在被取代後，雖然重新設定過核彈發射密碼，但是卻沒有把開啟核彈發射器的血型跟心跳資訊一併予以更新。幸好原本的美國總統是屬於正義的那一方，如果是敵人，可就真的 GG 了。

雖然一般公司不會擁有核彈，但是卻有各式各樣的資訊系統。在這些系統中，總存在著許多的權限，其中尤以特權最為重要，擁有特權可以做出一般權限無法完成的事情。舉例來說，系統的管理者帳號就是一種特權，可以做的事…幾乎是所有事情了吧！所以很多公司的老闆平時對系統管理者可說是又愛又恨。只不過兩者之間通常相安無事，直到系統管理者離職的前一刻…如果又是非自願離職，老闆可能得提心吊膽好一陣子了。

如何落實權限的發放與回收，尤其是針對所謂的特權帳號，對老闆們而言可說是一項重要的安全考量。常見的資安措施如限制共享帳號、最小權限原則、定期更換密碼、多重因素驗證、稽核與完善的作業流程，都可以協助權限管理的進行。只不過權限管理沒有萬靈丹，所以必須多方加以考量，以免像電影情節般地百密一疏，功虧一簣了。

[工具介紹] Apache 模組 mod_security - 以阻擋造訪路徑攻擊為例

2014-01-10T14:01:00.000+08:00

在前一篇文章中，我提到網站應用程式的安全問題，光靠定期更新並不能有效加以解決。透過 Secure SDLC 與 Secure Coding 的施作，才能有效提昇系統的整體安全性。而在前兩篇文章中，我提到了這幾天遠通電信網站被發現的一個安全漏洞 - 造訪路徑攻擊，也提到了一些防護手法。
但是回到現實面，我們知道很多時候該做的事情就是沒辦法進行，所以文章中提到的防護手法不一定能夠順利實施。原因有很多，不過歸到底通常都出在人身上。正所謂樹多有枯枝，人多有白痴。那怕只是一個程式設計師的一時鬼遮眼，都有可能讓系統產生莫大的安全漏洞。針對這種狀況，通常建議的作法就是採用 Virtual Patching，白話一點來說就是導入 WAF (Web Application Firewall)。不過再次回到現實面的現實面，導入 WAF 的金錢成本相當高，通常沒有準備七位數是沒有廠商會理你的。
好消息是沒錢也有沒錢的作法，其中 Apache 的 mod_security 模組正是一個免費的好用工具。在這次的文章中，我將示範如何利用 mod_security 來阻擋造訪路徑攻擊，環境為 CentOS 6。在進行前必須提醒讀者，因為示範過程將會改變網站的存取行為，因此請不要直接在正式的環境模擬。
為了完成這次的範例，我先在網站上放置了一個 PHP 程式 – get_file_content.php，其內容為

<?php
  $content = file_get_contents($_GET['path']);
  echo nl2br($content);
?>

這個程式的功能很簡單，就是讓使用者透過 path 變數指定某個檔案名稱，然後程式就會將檔案內容完整顯示出來。所以當我們呼叫 get_file_content.php?path=../../../../../../etc/passwd 時，應該會看到這個熟悉的畫面

接下來，就讓我們一步步完成今天的範例吧。

安裝 EPEL Repository
EPEL 提供了 mod_security 的 RPM 套件，可以大幅簡化安裝與日後更新的動作，所以我選擇透過 EPEL 來安裝 mod_security。請先在 https://fedoraproject.org/wiki/EPEL 下載並安裝適合的版本。
安裝 mod_security
指令是
```
yum -y install mod_security
```
新增造訪路徑攻擊字串的規則
mod_security 的規則設定檔放在目錄 /etc/httpd/modsecurity.d/activated_rules 內，檔案名稱必須以 .conf 結尾。請在這個目錄產生一個稱為 testing.conf 的檔案，並在檔案內加入下列內容
```
SecRule REQUEST_URI "../" "phase:1,t:urlDecode,log,deny,status:503,id:1000"
```
重新讀取 apache 設定檔
指令是
```
service httpd reload
```
重新載入網址
此時畫面應該會出現錯誤訊息 (Code=503)

查看阻擋記錄
我們可以在日誌檔 /var/log/httpd/modsec_audit.log 看到類似下列的訊息

--48927b7c-A--
[10/Jan/2014:01:24:19 +0800] Us7bQ8CoAHcAAEwAH-AAAAAB 192.168.10.11 51517 192.168.10.10 80
--48927b7c-B--
GET /get_file_content.php?path=../../../../../../etc/passwd HTTP/1.1
Host: 192.168.10.10
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 OPR/18.0.1284.68
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4

--48927b7c-F--
HTTP/1.1 503 Service Temporarily Unavailable
Content-Length: 402
Connection: close
Content-Type: text/html; charset=iso-8859-1

--48927b7c-E--

--48927b7c-H--
Message: Access denied with code 503 (phase 1). Pattern match "../" at REQUEST_URI. [file "/etc/httpd/modsecurity.d/activated_rules/testing.conf"] [line "1"] [id "1000"]
Action: Intercepted (phase 1)
Stopwatch: 1389288259978368 472 (- - -)
Stopwatch2: 1389288259978368 472; combined=48, p1=43, p2=0, p3=0, p4=0, p5=5, sr=0, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/).
Server: Apache/2.2.15 (CentOS)
Engine-Mode: "ENABLED"

--48927b7c-Z--

下載 OWASP 規則
透過一個簡單的規則，我們就可以避免造訪路徑攻擊。儘管如此，這個規則其實功能有限，因為它只檢查了 Request 字串，萬一是透過 POST (也就是 Content Body) 傳遞攻擊字串，那可就一點也派不上用場了。
撰寫規則這種事，最好還是讓給專業的來。目前 mod_security 提供兩組規則，其中一組要錢，另外一組由 OWASP 所維護的規則則免費使用。在此我們選用 OWASP 的免費規則，指令如下
```
cd /etc/httpd/modsecurity.d
rm –f activated_rules/testing.conf
wget https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master -O owasp-modsecurity-crs.master.tgz
tar xvfz owasp-modsecurity-crs.master.tgz
```

安裝所需規則
我們下載的檔案內包含許多規則，一般而言，我們不會啟用全部的規則。在此範例中，我們僅會啟用示範所需的規則。指令如下

cd activated_rules/
cp ../SpiderLabs-owasp-modsecurity-crs-f4d33c4/modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf
ln –s ../SpiderLabs-owasp-modsecurity-crs-f4d33c4/base_rules/modsecurity_crs_42_tight_security.conf modsecurity_crs_42_tight_security.conf

重新讀取 apache 設定檔
指令是
```
service httpd reload
```
重新載入網址
此時畫面應該會出現錯誤訊息 (Code=403)

雖然錯誤訊息有所不同，但是一樣達到阻擋造訪路徑攻擊的目的。
新增其他規則
等等，萬一駭客輸入的攻擊字串不包含 ../，而是直接輸入 /etc/passwd 呢？令人驚訝的是，呼叫 get_file_content.php?path=/etc/passwd 依舊會直接顯示出檔案內容。因為 /etc/passwd 實在太過重要，所以 OWASP 提供了其他的規則以避免這類攻擊字串，指令如下
```
ln –s ../SpiderLabs-owasp-modsecurity-crs-f4d33c4/base_rules/modsecurity_40_generic_attacks.data modsecurity_40_generic_attacks.data
ln –s ../SpiderLabs-owasp-modsecurity-crs-f4d33c4/base_rules/modsecurity_crs_40_generic_attacks.conf modsecurity_crs_40_generic_attacks.conf
```
再次重新讀取 apache 設定檔
指令是
```
service httpd reload
```
再次測試
此時呼叫 get_file_content.php?path=/etc/passwd 應該也會看到錯誤訊息了

透過 mod_security 與 OWASP 提供的規則，我們就可以輕鬆避免遭受造訪路徑的攻擊。好啦，輕鬆兩字是騙人的，儘管 mod_security 解決了金錢成本的問題，但是導入 WAF 時所可能遭遇的其他問題，還是需要好好處理才能真正發揮 mod_security 的效用。

[資安觀念] 您補對了嗎？

2014-01-09T21:28:00.000+08:00

這幾天 eTag 的新聞依舊不斷，今天看到一篇來自於自由時報的新聞報導 - 國道計程變國際笑話／遠通資安凸槌政府罰不到，報導最後提到
“根據資深網管人員康康表示，駭客可能在遠傳網址後面加上特殊字元，剛好可以進入敏感目錄，不能顯示後端資料庫資料是否外洩。但這顯示管理人員太不小心了，因為只要有定期更新修補程式，就可以避免這個問題。”
姑且不論這位康康到底是何方神聖，但是看到結論是只要定期更新修改程式就可以避免這個問題，就知道這位康康果然很資深，講的大概是10年前的觀念。
駭客的攻擊手法千百種，不過大致的趨勢是從早期的攻擊網路、攻擊作業系統、到後來針對應用程式的弱點下手。而應用程式包含所謂的套裝程式 (如 PDF Reader) 以及自行開發的程式，都是可能受到攻擊的目標。而公開的網站應用程式，更是熱門的目標。在這些應用程式之中，自行開發的網站應用程式，自是熱門中的熱門。原因無他，一是這類網站通常含有大量的有價資訊，另外一方面則是這類網站的安全防護能力通常也較差，往往用自動化工具就可以找到不少可憐的羔羊。再加上公開的特性，對駭客來說就像男人看到穿著清涼又身材曼妙的美女在沙灘上走來走去一般令人無法抗拒。
很可惜的是，對自行開發的網站應用程式而言，很多安全問題並不是靠更新系統就可以解決的。必須要從應用程式面下手，認真做好各項的防護工作後才能有效提昇安全性。更好的作法，當然就是導入類似 Secure SDLC 的制度。道理很簡單，因為一開始駭客就不是利用作業系統的漏洞取得這些機密資訊，而是利用了程式沒有做好限制的邏輯缺陷。我相信大家都知道窗戶破了就該把窗戶補好，而不是把原本的圍牆升級為高壓電網。就像我常說的，頭痛醫頭不算什麼，頭痛醫腳才是真庸醫。
所以，儘管定期更新真的很重要，但是再也別把它當成萬靈丹或唯一該做的事情了。

[交戰守則] 避免造訪路徑攻擊 (Path Traversal Attack)，免得成為下一個遠通電收

2014-01-07T22:15:00.001+08:00

這幾天對開車族而言，一個很重要的新聞就是國道全面採用計程收費。而說到計程收費，就不得不提到 eTag 這個東西。一直以來，eTag 就充滿了各式各樣的爭議，不過爭議再多，終究還是一個既定的政策。只是開車族可能發現，eTag 本來提供了查詢的功能，但是從去年底全面上線以來，卻一直處於無法查詢的狀態。至於原因？從一開始說的系統轉移，到後來包含頻寬不足、受到駭客攻擊等說法，讓人摸不清真相。如果是一般的企業，敢承認自己被駭客攻擊，大概民眾都不太會去懷疑，畢竟這對公司的信譽可是會產生很嚴重的負面影響。但是對遠通電收這樣一家公司而言，反而有不少人懷疑這只是他們的推托之詞。

事情的真相，大概只有三個人知道。不過就在昨天，有人在 pastebin.com 貼了一個分享，網址是 http://www.fetc.net.tw/portal/front/staticPage?articleId=402880fd1eafaeee011eafefd1d60005&path=../../../../../../../../../../../../../../etc/passwd，內容是”疑似”遠通電收網站主機的 passwd 檔！雖然這個檔案實際上不包含密碼，但是這個安全漏洞的影響可大可小。如果稍有不慎 (其實已經很不慎了)，別說是主機的密碼，就連資料庫的密碼也是整串帶走。在針對網站的攻擊手法中，這類攻擊稱之為造訪路徑攻擊，英文是 path traversal attack。又因為攻擊字串中往往帶有 ../ 字串，所以又稱為 dot-dot-slash attack。

嚴格來說，這並不是一種很新的攻擊手法，甚至已經可以算得上是老掉牙的東西。而要避免這種攻擊手法也不是很困難，在 OWASP 的網站上，針對造訪路徑攻擊有提到下列幾種防護手法：

Prefer working without user input when using file system calls
不要把使用者的輸入帶入有關 file system 的函式呼叫參數中。

Use indexes rather than actual portions of file names when templating or using language files
使用代號來表示檔案，而不要使用實際的檔案名稱/路徑。

Ensure the user cannot supply all parts of the path – surround it with your path code
避免使用者可以輸入完整的檔案名稱與路徑。實務上，此點要做的好其實並不容易，務必要搭配下一個建議手法。

Validate the user’s input by only accepting known good – do not sanitize the data
驗證使用者的輸入。不要使用清除非法字元的方式，而是只接受合法的輸入。

Use chrooted jails and code access policies to restrict where the files can be obtained or saved to
使用 chroot 的機制以避免網站程式讀取到系統的其他檔案。除此之外，如果網站框架允許設定程式的權限，也可以用來避免此一問題。

以造訪路徑攻擊而言，其實也可用源碼檢測工具加以偵測，效果通常不錯。而黑箱工具，往往也可以達到一定的成效。可想而知，遠通電收應該是連這類工具都沒用就大膽上線。遠通電收不是第一個出包的網站，我相信也不會是最後一個。重點是，這種事情千萬不要發生在你跟我的身上。

[迷你好兔] 利用 CMAN+Pacemaker 建立不中斷的網路

2014-01-07T20:30:00.000+08:00

閘道器是一種很常見的網路裝置，包含路由器與代理伺服器都可算是閘道器的一種。以下圖而言，標示為 Gateway 的設備提供了包含內部 IP 上網用 NAT 機制 (SNAT)、HTTP Reverse Proxy 與 Virtual Server (DNAT) 等功能，可說是一台多功能的閘道器。這些功能對於一個網管人員來說，並不是什麼新奇的概念與技術。但是這個架構有一個致命的缺點，那就是閘道器 Gateway 掌管了所有資料的交換，所以一旦 Gateway 出了問題，那可就真是一場大災難了。而這正是所謂的單點失效 (Single Point of Failure, 簡稱SPF) 問題。

為了解決這個問題，許多中高階的網路設備都提供了高可用性的備援機制 (High Availablity, 簡稱 HA)，其中比較簡單的一種架構稱之為 Active/Passive 模式。在此模式中，至少會佈署兩台提供相同功能的設備，其中一台為主 (Active)，另外一台為輔 (Passive)。當主要的設備失效時，輔助的設備會自動接手繼續提供服務，以確保服務不會因為設備失效而中斷。而當主要的設備恢復運作後，可以選擇繼續由輔助的設備提供服務，或是自動切換回主要的設備。可惜的是，這樣的功能通常只見於中高階的設備，而這些設備本來就所費不貲，所以採用此架構往往不但成本相對高昂，而且平常備用的設備並沒有提供服務，再再降低了設備的使用效率。
在今天在範例中，我將利用 CentOS 6 內建的 CMAN+Pacemaker 建立一個高可用性的閘道器，用低廉的成本解決單點失效的網路問題。與原本的架構相較，需要增加為兩台主機以提供 Active/Passive 模式，而且每個主機僅需配置一個內部用的 IP 位址。本範例假設兩台主機原本就已經分別設定好 Routing/DNAT/SNAT/Reverse Proxy 等網路功能，以下就讓我們一步步完成今天的範例吧。

設定主機的網路 (Gateway01 與 Gateway02)
兩台主機的 IP 位址分別為 192.168.10.21 (Gateway01) 與 192.168.10.22 (Gateway02)。此兩台主機各配置兩張網卡，在範例中內部網路皆連結至網路介面 eth1。在此架構中，我們不需要設定外部網卡 (也就是 eth0) 的 IP 位址，所以請設定成手動指定但不輸入 IP 位址等資訊。
設定 /etc/hosts 檔 (Gateway01 與 Gateway02)
在兩台主機的 /etc/hosts 分別加上下列兩行設定
```
192.168.10.21 gateway01
192.168.10.22 gateway02
```
安裝所需套件 (Gateway01 與 Gateway02)
在兩台主機分別安裝所需套件，指令為
```
yum install ccs cman pacemaker pcs resource-agents
```
設定 CMAN 參數 (Gateway01 與 Gateway02)
分別在兩台主機執行下列指令
```
echo "CMAN_QUORUM_TIMEOUT=0" >> /etc/sysconfig/cman
```
設定防火牆 iptables (Gateway01 與 Gateway02)
我們需要用到 UDP Port 5404, 5405 與 TCP Port 11111，請在兩台主機分別進行設定，以便兩台主機能夠順利進行溝通。
設定預設路由 (Gateway01 與 Gateway02)
因為在此架構中，備援主機本身不具備對外的 IP 位址，因此與其他內部設備一樣必須透過配置於主要主機的 IP 位址 192.168.0.254 進行網際網路的連結。為了避免當備援主機身分轉換成為主要主機後兩個路由產生衝突，所以我們降低此路由的優先順序，使其轉換成主要主機後，可以順利使用對外 IP 位址作為預設路由。我們在兩台主機分別執行下列指令
```
route add default gw 192.168.0.254 metric 99
```
設定開機自動新增預設路由 (Gateway01 與 Gateway02)
分別在兩台主機的 /etc/rc.local 加上下列設定
```
route add default gw 192.168.0.254 metric 99
```

設定 Cluster (Gateway01)
在 gateway01 執行下列指令

ccs -f /etc/cluster/cluster.conf --createcluster pacemaker1
ccs -f /etc/cluster/cluster.conf --addnode gateway01
ccs -f /etc/cluster/cluster.conf --addnode gateway02
ccs -f /etc/cluster/cluster.conf --addfencedev pcmk agent=fence_pcmk
ccs -f /etc/cluster/cluster.conf --addmethod pcmk-redirect gateway01
ccs -f /etc/cluster/cluster.conf --addmethod pcmk-redirect gateway02
ccs -f /etc/cluster/cluster.conf --addfenceinst pcmk gateway01 pcmk-redirect port=gateway01
ccs -f /etc/cluster/cluster.conf --addfenceinst pcmk gateway02 pcmk-redirect port=gateway02

同步 Cluster 設定 (Gateway01)
將 gateway01 下的 /etc/cluster/cluster.conf 同步至 gateway02，指令為
```
rsync /etc/cluster/cluster.conf gateway02:/etc/cluster/
```
啟動 cman 服務 (Gateway01 與 Gateway02)
在兩台主機分別執行下列指令
```
service cman start
```
啟動 pacemaker 服務 (Gateway01 與 Gateway02)
在兩台主機分別執行下列指令
```
service pacemaker start
```
設定 cman 與 pacemaker 開機自動執行 (Gateway01 與 Gateway02)
在兩台主機分別執行下列指令
```
chkconfig cman on
chkconfig pacemaker on
```

關閉 fencing 與 STONITH (Gateway01)
執行下列指令

pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore

確認 Cluster 狀態 (Gateway01)
執行指令

pcs status

應可以看到類似下列資訊

Cluster name: pacemaker1
Last updated: Tue Jan  7 17:27:30 2014
Last change: Tue Jan  7 12:55:21 2014 via crm_attribute on gateway01
Stack: cman
Current DC: gateway01 - partition with quorum
Version: 1.1.10-14.el6_5.1-368c726
2 Nodes configured
0 Resources configured


Online: [ gateway01 gateway02 ]

設定網路資源 (Gateway01)
執行下列指令

pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.0.254 cidr_netmask=24 nic=eth1 op monitor interval=3s
pcs resource create ClusterPublicIP ocf:heartbeat:IPaddr2 ip=168.95.10.10 cidr_netmask=28 nic=eth0 op monitor interval=3s
pcs resource create ExternalDefaultRoute ocf:heartbeat:Route destination="0.0.0.0/0" gateway="168.95.10.1"

其中網路相關參數 (192.168.0.254/24, 168.95.10.10/28 與 168.95.0.1) 請依據實際的環境加以調整。

設定 Email 通知 (Gateway01)
如果我們希望知道何時發生資源轉移 (如從 gateway01 轉移到 gateway02)，可以執行下列指令
```
pcs resource create EmailNotification ocf:heartbeat:MailTo email=cyril.hcwang@gmail.com op monitor timeout=10 interval=3s
```
設定資源群組 (Gateway01)
利用資源群組的設定，我們可以確保所有的資源同時進行轉移，而不會出現內部 IP 位址 192.168.0.254 配置於 Gateway01 但外部 IP 168.95.10.10 位址卻配置於 Gateway02 的錯誤狀況。指令如下
```
pcs resource group add Gateway ClusterIP CusterPublicIP ExternalDefaultRoute EmailNotification
```

設定資源啟用順序 (Gateway01)
指令如下

pcs constraint order ClusterIP then ClusterPublicIP
pcs constraint order ClusterPublicIP then ExternalDefaultRoute
pcs constraint order ExternalDefaultRoute then EmailNotification

設定完畢後我們可以透過下列指令確認啟用順序

pcs constraint order show --full

設定主要設備 (Gateway01)
在此範例中，我希望主要由 Gateway01 提供服務，因此需設定其擁有較高的優先權。指令如下
```
pcs constraint location Gateway prefers gateway01=10
pcs constraint location Gateway prefers gateway02=5
```
設定完畢後我們可以透過指令
```
pcs constraint location show --full
```
確認是否有其他的優先權設定會影響到此一判斷，並在必要時透過指令
```
pcs constraint location Gateway remove [resource-id]
```
加以移除。

確認設定
除了透過上述指令進行單一項目的顯示與確認，我們還可以透過指令

pcs config

顯示全部的設定，執行後應可以看到類似下列訊息

Cluster Name: pacemaker1
Corosync Nodes:

Pacemaker Nodes:
 gateway01 gateway02

Resources:
 Group: Gateway
  Resource: ClusterIP (class=ocf provider=heartbeat type=IPaddr2)
   Attributes: ip=192.168.0.254 cidr_netmask=24 nic=eth1
   Operations: monitor interval=3s (ClusterIP-monitor-interval-3s)
  Resource: ClusterPublicIP (class=ocf provider=heartbeat type=IPaddr2)
   Attributes: ip=168.95.10.10 cidr_netmask=28 nic=eth0
   Operations: monitor interval=3s (ClusterPublicIP-monitor-interval-3s)
  Resource: ExternalDefaultRoute (class=ocf provider=heartbeat type=Route)
   Attributes: destination=0.0.0.0/0 gateway=168.95.10.1
   Operations: monitor interval=60s (ExternalDefaultRoute-monitor-interval-60s)
  Resource: EmailNotification (class=ocf provider=heartbeat type=MailTo)
   Attributes: email=cyril.hcwang@gmail.com
   Operations: monitor interval=3s timeout=10 (EmailNotification-monitor-interval-3s)

Stonith Devices:
Fencing Levels:

Location Constraints:
  Resource: Gateway
    Enabled on: gateway01 (score:10) (id:location-Gateway-gateway01-10)
    Enabled on: gateway02 (score:5) (id:location-Gateway-gateway02-5)
Ordering Constraints:
  start ClusterIP then start ClusterPublicIP (Mandatory) (id:order-ClusterIP-ClusterPublicIP-mandatory)
  start ClusterPublicIP then start ExternalDefaultRoute (Mandatory) (id:order-ClusterPublicIP-ExternalDefaultRoute-mandatory)
  start ExternalDefaultRoute then start EmailNotification (Mandatory) (id:order-ExternalDefaultRoute-EmailNotification-mandatory)
Colocation Constraints:

Cluster Properties:
 cluster-infrastructure: cman
 dc-version: 1.1.10-14.el6_5.1-368c726
 no-quorum-policy: ignore
 stonith-enabled: false

確認 Cluster 執行狀態
再次執行指令

pcs status

應可看到類似下列資訊

Cluster name: pacemaker1
Last updated: Tue Jan  7 17:52:42 2014
Last change: Tue Jan  7 12:55:21 2014 via crm_attribute on gateway01
Stack: cman
Current DC: gateway01 - partition with quorum
Version: 1.1.10-14.el6_5.1-368c726
2 Nodes configured
4 Resources configured


Online: [ gateway01 gateway02 ]
Full list of resources:
 Resource Group: Gateway
     ClusterIP  (ocf::heartbeat:IPaddr2):       Started gateway01
     ClusterPublicIP    (ocf::heartbeat:IPaddr2):       Started gateway01
     ExternalDefaultRoute       (ocf::heartbeat:Route): Started gateway01
     EmailNotification  (ocf::heartbeat:MailTo):        Started gateway01

測試資源的轉移 (Gateway01)
因為目前資源配置於 Gateway01，因此測試時我們需要將資源轉移至 Gateway02。方法有二，一個是直接將 Gateway01 進行關機的動作，另外一個更為方便的方式則是將 Gateway01 設為備用，指令如下

pcs cluster standby gateway01

我們再次執行指令

pcs status

可以看到類似下列資訊

Cluster name: pacemaker1
Last updated: Tue Jan  7 18:10:31 2014
Last change: Tue Jan  7 18:10:22 2014 via crm_attribute on gateway01
Stack: cman
Current DC: gateway01 - partition with quorum
Version: 1.1.10-14.el6_5.1-368c726
2 Nodes configured
4 Resources configured

Node gateway01: standby
Online: [ gateway02 ]
Full list of resources:
 Resource Group: Gateway
     ClusterIP  (ocf::heartbeat:IPaddr2):       Started gateway02
     ClusterPublicIP    (ocf::heartbeat:IPaddr2):       Started gateway02
     ExternalDefaultRoute       (ocf::heartbeat:Route): Started gateway02
     EmailNotification  (ocf::heartbeat:MailTo):        Started gateway02

測試 Gateway01 重新上線 (Gateway01)
透過指令
```
pcs cluster unstandby gateway01
```
可以重新讓 Gateway01 上線，因為我們已經設定 Gateway01 擁有較高的優先權，所以再次執行指令
```
pcs status
```
應可以看到類似步驟 21 的訊息，表示資源配置再次回到 Gateway01。
確認通知信
因為我們剛剛做了兩次資源轉移的動作，所以你應該會收到相關的通知信。

透過 CMAN+Pacemaker，我們就可以輕鬆建立一個不中斷的網路連線服務。其實 CMAN+Pacemaker 所支援的服務不僅於此，有興趣的人可以透過指令
pcs resource list
列出所有支援的項目，進一步找出適合你的支援項目。

[迷你好兔] 利用 SSH Tunnel 保護你的 MySQL 連線 (三)

2013-12-28T20:59:00.000+08:00

在前面兩篇文章裡，我提到如何利用 SSH Tunnel 的技術來保護遠端的 MySQL 連線。在第二種作法中，使用者利用自己的電腦達成 SSH Tunnel 的功能。因為大多數的使用者為 Windows 環境，所以在這篇文章中，我將示範如何在 Windows 的環境下設置 SSH Tunnel 以提供遠端 MySQL 連線。範例中使用的工具為 Putty，其他類似的 SSH Client 工具多也提供同樣的功能。

開啟 Putty
新增 Putty 設定
完成設定
按下按鈕「Save」即可完成設定。
對 SSH 主機進行連結並登入系統
進入設定畫面
在連線視窗按下右鍵，並選取 Change Settings…
開啟 Tunnel 選項畫面
位置是 Connection –> SSH –>Tunnels。
輸入 Tunnel 設定
Source Port 與 Destination 分別輸入 3307 與 192.168.0.20:3306。同樣的，我們選用 3307 當做 SSH Tunnel 的連結埠，以與 MySQL 預設埠號 3306 做一區別。
按下按鈕「Add」完成新增動作
應可看到下列畫面
完成設定
按下按鈕「Apply」即可完成設定。

進行至此，我們就可以利用 MySQL Client 端工具來進行遠端的 MySQL 連線了。後面的例子我將以 MySQL Query Browser 為例。

開啟 MySQL Query Browser
設定 MySQL 連線資訊
Server Host 與 Port 分別填入 127.0.0.1 與 3307。此外，請填入 MySQL 的帳號/密碼。
進行連線
按下按鈕「OK」就可以連線到遠端的 MySQL 資料庫。雖然畫面上顯示是本機的 IP (127.0.0.1)，但是實際上卻是連到遠端站台的資料庫主機，也就是 192.168.0.20。
確認 MySQL 的權限
因為 MySQL 的權限會根據帳號以及登入 IP 的不同而改變，所以需要特別注意原本的權限設定。以上述的例子而言，登入的 IP 會是 192.168.0.10，也就是 SSH 主機的內部網段 IP。如果有所不確定，可透過 MySQL 指令 show full processlist 來確認連結的帳號與 IP。也就是說，在這個作法下內部網路的資料傳輸是沒有經過加密的。

利用 Putty 的 SSH Tunnel 功能，我們就可以在 Windows 下利用各式各樣的管理工具來操作 MySQL 資料庫，而且不用再擔心資料外洩的問題。

[迷你好兔] 利用 SSH Tunnel 保護你的 MySQL 連線 (二)

2013-12-27T20:13:00.000+08:00

在前一篇的文章中，我分享了如何利用 SSH Tunnel 連結遠端的 MySQL 服務。作法雖然可行，但是有一些小問題。首先就是你必須擁有遠端 SSH Tunnel 主機的管理權限，以便取消防火牆的限制。如果 SSH Tunnel 主機之前還有其他的防火牆或安全設備加以保護，同樣也必須予以開放。此外，這樣的作法會導致遠端站台多開啟一個原本不必要的網路服務埠號。即使透過類似敲門機制加以保護，終究還是增加了一定程度的風險。
對此，我們可以稍微調整原本的作法，改由使用者的電腦執行 SSH Tunnel 的工作。SSH Client 工具通常就具備建立 SSH Tunnel 的能力，因此不管使用者使用的是 Windows 或 Linux 環境，都可以運用此一作法。

在這次的範例中，我們假設使用者的電腦是 Linux 環境，所需步驟如下：

在使用者的電腦開啟 SSH Tunnel 服務
指令如下
```
ssh -N -L 3307:192.168.0.20:3306 root@210.59.0.10
```

連結 SSH Tunnel
在使用者的電腦利用 MySQL Client 工具連結 TCP Port 3307。如果是 MySQL CLI 工具，指令為
```
mysql –p –h 127.0.0.1 –P 3307
```
輸入密碼後我們就可以進入 MySQL。因為指令 mysql 預設為透過 socket 連結資料庫，所以必須加上 –h 127.0.0.1 這組參數。
確認 MySQL 權限
因為 MySQL 的權限會根據帳號以及登入 IP 的不同而改變，所以需要特別注意原本的權限設定。以上述的例子而言，登入的 IP 會是 192.168.0.10，也就是 SSH 主機的內部網段 IP。如果有所不確定，可透過 MySQL 指令 show full processlist 來確認連結的帳號與 IP。也就是說，在這個作法下內部網路的資料傳輸是沒有經過加密的。

此一作法不似前一個作法，對原本站台不需做任何設定的調整，所以適用範圍更廣。儘管有資料在內部網路為明文傳輸的缺點，但是通常原本的架構在內部網路即為明文傳輸，所以實際上也算不上是缺點了。

[迷你好兔] 利用 SSH Tunnel 保護你的 MySQL 連線 (一)

2013-12-26T22:02:00.000+08:00

在網路的世界裡，Tunnel (通道) 是一個很有用卻也同時很可怕的技術。透過 Tunnel 的技術，內部員工可以任意連上公司所禁止連結的 IP 或服務。如果再加上加密的技術，公司幾乎可說是很難有所作用。Tunnel 技術不只可能遭受內部員工的濫用，更往往是駭客喜愛的手法。今天我們利用 Tunnel 來做一件比較正面的事情，那就是用 SSH Tunnel 來連結/管理遠端的 MySQL 服務。
在常見的網站架構中，我們會把網路分成多個網段 (可能是實體區域網路或虛擬區域網路)。對於一些重要且不需直接提供對外服務的主機，我們會選擇佈署在內部的隔離網段，以限制其他網段 (包含網際網路) 的設備直接加以存取。而這類需要保護的主機中，資料庫主機算是最常見的一種。透過這樣的架構，我們可以直接從網路架構上限制同一個內部隔離網段內的設備才能連結至資料庫的服務，以確保資料庫主機與服務的安全性。
這樣的架構雖然相對安全，但是卻衍生一個問題，那就是如果我們需要從外部管理資料庫服務，似乎就變得有點棘手。針對這個問題，我們可以透過目的地 NAT 的技術來達到從網際網路直接連結資料庫服務的目的，只是這個解法有一個很嚴重的安全問題：那就是一般的資料庫連線都是未加密。一方面是因為考慮到效能，另一方面則是因為內部資料傳輸也相對較為安全，所以通常不需要使用加密的傳輸方式。所以如果直接透過目的地 NAT 的技術來連結資料庫，不但資料可能全被看光，帳號密碼往往也同樣不保。而利用 SSH Tunnel 的方式，不但可以解決連結內部資料庫主機的問題，也可以確保在網際網路上傳輸帳號密碼等資訊時是經過加密的。
在下圖的例子裡，我們透過一台 CentOS 6 當做 SSH Tunnel 主機，以提供管理者透過網際網路連結內部 MySQL 服務。
步驟如下：

開啟 SSH Tunnel 選項
要利用 SSH 服務當做 Tunnel，首先必須在 SSH Tunnel 主機的設定檔 (CentOS 6 為 /etc/ssh/sshd_config) 設定 AllowTcpForwarding 為 yes。因為 CentOS 6 的預設值即為 yes，所以除非之前曾經修改過此一設定，否則不需要進行此動作。
開啟防火牆的埠號
MySQL 服務使用 TCP 3306，為了區分方便，我們選定 TCP 3307 當做 SSH Tunnel 的連結埠。所以我們必須在 SSH Tunnel 主機的防火牆 (iptables) 開放 TCP 3307。
執行 SSH Tunnel
在 SSH Tunnel 主機開啟 Tunnel 服務，指令是
```
ssh -N -L 210.59.0.10:3307:192.168.0.20:3306 root@192.168.0.20
```
如果我們已經設定好 ssh 的金鑰登入，此時就不需要輸入密碼。否則，就會出現輸入密碼的提示。如果需要輸入密碼，請輸入資料庫主機 (也就是 192.168.0.20) 內帳號 root 的密碼。
連結 SSH Tunnel
在使用者的電腦利用 MySQL Client 工具連結 SSH Tunnel 主機的外部 IP 與 TCP Port 3307。如果是 MySQL CLI 工具，指令為
```
mysql –p –h 210.59.0.10 –P 3307
```
輸入密碼後我們就可以進入 MySQL。
確認 MySQL 權限
因為 MySQL 的權限會根據帳號以及登入 IP 的不同而改變，所以需要特別注意原本的權限設定。以上述的例子而言，登入的 IP 會因為指令最後面的 root@192.168.0.20 而成為 192.168.0.20。如果有所不確定，可透過 MySQL 指令 show full processlist 來確認連結的帳號與 IP。也因為這樣的關係，所以不只資料在網際網路傳輸時是經過 SSH Tunnel 的加密保護，連 SSH Tunnel 主機與資料庫主機之間的資料傳遞也是經過加密保護。

利用一個簡單的 ssh 指令，我們就可以透過網際網路安全地連結至遠端的 MySQL 服務。不過也因為過於方便，最好不要讓這個 SSH Tunnel 一直運行著，等到有需要再執行會是比較安全的作法。如果搭配像是 iptables 的敲門機制，那也是不錯的選擇。
其實透過 SSH Tunnel 的技術，不只可以用來保護遠端的 MySQL 連線，其他像是 ftp 或是 pop3 等服務，也常見被包裝在 SSH Tunnel 之中。透過 SSH Tunnel 的包裝，可以讓這些原本使用明文傳輸的協定達到加密的效果，以避免資料在傳輸過程中遭到窺視，大大提昇了傳輸時的安全性。

[工具介紹] Apache 模組 mod_log_forensic

2013-12-25T19:20:00.000+08:00

雖然這幾年 GA (Google Analytics) 等網站流量分析機制逐漸取代了傳統上利用網站日誌來分析網站流量的作法，但是分析網站日誌依舊是系統/網站管理員不可忽視的一個重要工作。以一般的網站服務器而言，主要會提供兩種日誌，一種是存取日誌 (Access Log)，另外一種是錯誤日誌 (Error Log)。除了分析網站流量，系統/網站管理員還可以透過分析網站日誌來了解是否發生過攻擊網站的行為 (像是SQL 注入攻擊) 。儘管這些日誌有很大的用處，但是因為這些日誌一直以來都是網站流量分析工具所依賴的資料來源，所以其能儲存的格式與資料也就不太容易改變，也就是說不能應付其他較為特殊的應用。
Apache HTTP 服務器除了上述兩種日誌，另外還提供了一種稱之為 Forensic 的日誌，只是在預設的情況下這個功能是被關閉的。跟原本的日誌相比， Forensic 日誌有下列特點：

每一個請求 (Request) 會有兩筆記錄，一筆是在開始處理請求前，另外一筆則是請求處理結束後。此一特點可以用來分析是否有不正常中斷的請求，這類不正常的請求可能是因為程式或設定的錯誤，也有可能是因為遭受到有心份子的攻擊。如果沒有開啟 Forensic 日誌，這類行為往往僅會在錯誤日誌留下類似 Segement Fault 的訊息，對於釐清問題並沒有太大的幫助。
Forensic 日誌的格式是固定的，不像存取日誌或錯誤日記可以自定需要記錄的格式與欄位。
Forensic 記錄的內容比原本的存取日誌還要詳細，包含標頭的內容也會一併予以記錄，其中甚至包含 Cookie 等可能包含機密資料的標頭。因此對於 Forensic 日誌檔必須予以嚴加保護，以避免有心份子取得不適當的資料。

接下來，我們先看一下在 CentOS 6 的環境下，如何開啟 Forensic 日誌的功能：

修改 Apache 設定檔，預設為 /etc/httpd/conf/httpd.conf
載入 mod_log_forensic 模組，也就是將
```
#LoadModule log_forensic_module modules/mod_log_forensic.so
```
這行改成
```
LoadModule log_forensic_module modules/mod_log_forensic.so      
```
並設定 Forensic 日誌檔所在位置
加上下列設定
```
ForensicLog logs/forensic_log
```
其中 logs/forensic_log 表示儲存的檔案路徑。
重新載入 Apache 的設定
指令是
```
service httpd reload
```

設定完成後，我們可以試著讀取網站上的網頁，如果一切正確的話應該可以在 logs/forensic_log 這個檔案內看到類似下列的資訊：

+24178:52ba84d3:0|GET /wordpress/ HTTP/1.1|Host:192.168.0.119|Connection:keep-alive|Cache-Control:max-age=0|Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8|User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36|Accept-Encoding:gzip,deflate,sdch|Accept-Language:zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4|Cookie:wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_fc7f48cee0e7fa37753a2c3c863a3dce=superhero%257C1388125383%257Cdfb3d0e44bc16b8e120138195b9aa229; wp-settings-time-1=1387952591
+24179:52ba84d3:0|GET /wordpress/wp-includes/css/admin-bar.min.css?ver=3.7.1 HTTP/1.1|Host:192.168.0.119|Connection:keep-alive|Cache-Control:max-age=0|Accept:text/css,*/*;q=0.1|If-None-Match:"30e3-3220-4e95d2605fe80"|If-Modified-Since:Tue, 22 Oct 2013 23%3a56%3a26 GMT|User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36|Referer:http%3a//192.168.0.119/wordpress/|Accept-Encoding:gzip,deflate,sdch|Accept-Language:zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4|Cookie:wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_fc7f48cee0e7fa37753a2c3c863a3dce=superhero%257C1388125383%257Cdfb3d0e44bc16b8e120138195b9aa229; wp-settings-time-1=1387952591
-24179:52ba84d3:0
-24178:52ba84d3:0

我們可以發現每一行記錄的開頭都是一串數字，這是用來識別每一個請求的代號。而每一個代號應該會有兩筆記錄，前面分別加上符號 + 或 –。+ 號表示請求開始處理前的紀錄，而 - 號表示請求處理結束後的紀錄。如果我們發現特定的請求代號只有 + 號的紀錄，而沒有 - 號的記錄，表示此一請求為不正常的中斷。此時，我們就可以透過日誌內的完整資訊來分析此一請求的各項資訊。
雖然找出不正常中斷請求的原理很簡單，但是如果要靠人工來找出 Forensic 日誌檔中有問題的紀錄，實在是一個不可能的任務。好在 Apache HTTP 服務器提供了一個簡單的腳本 check_forensic，可以用來幫助我們找出 Forensic 日誌檔中有問題的紀錄。不過在 CentOS 6 Apache HTTP 服務器的 RPM 安裝檔當中，並沒有包含此一腳本，所以我們需要自行下載 tarball 並取得當中的腳本 check_forensic 腳本。如果 Forensic 日誌檔沒有任何錯誤，執行腳本 check_forensic 並不會顯現任何資訊。反之，如果有任何不正常中斷的請求，check_forensic 將會列出有問題的紀錄，類似下列結果：

[root@web httpd]# ./check_forensic forensic_log
+24177:52ba84d3:0|GET /wordpress/wp-content/themes/twentythirteen/fonts/genericons.css?ver=2.09 HTTP/1.1|Host:192.168.0.119|Connection:keep-alive|Cache-Control:max-age=0|Accept:text/css,*/*;q=0.1|If-None-Match:"3087-57d7-4e001b3bdeb80"|If-Modified-Since:Tue, 25 Jun 2013 22%3a03%3a42 GMT|User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36|Referer:http%3a//192.168.0.119/wordpress/|Accept-Encoding:gzip,deflate,sdch|Accept-Language:zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4|Cookie:wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_fc7f48cee0e7fa37753a2c3c863a3dce=superhero%257C1388125383%257Cdfb3d0e44bc16b8e120138195b9aa229; wp-settings-time-1=1387952591
[root@web httpd]#

Apache 的 Forensic 日誌檔提供系統/網站管理員有別於標準存取與錯誤日誌的資訊，不管在面對有心或是無意的異常存取行為，都是一項有力的工具。

[工具介紹] 利用 knockd 實現複雜的敲門機制

2013-09-23T13:00:00.000+08:00

去年我介紹過如何利用 iptables 的 recent 模組來保護如 ssh 之類的網路服務。今天我要介紹的這個服務 – knockd，也可以達成類似的目的。不過不同於 iptables 的作法，knockd 可以輕鬆支援用多個網路埠的組合當做敲門的鑰匙，而且這些網路埠並不會對敲門動作的封包有所回應，可以達到更高的隱密性。此外，如果要保護的服務一多，將保護機制獨立在 iptables 的規則設定之外，也可以簡化 iptables 的複雜度，以避免設定錯誤的情況發生。
在今天的範例中，我們需要兩台 Linux 主機，其中一台當做利用 knockd 機制保護 ssh 服務的主機 (名稱為 knockd.cyril.idv，IP 位址為 192.168.199.103)，另外一台用戶端電腦則是用來測試是否可以正常連上受保護的 ssh 服務 (名稱為 client.cyril.idv，IP位址為 192.168.199.102)。採用的 Linux 版本為 32 位元的 CentOS 6.4。為了測試方便，我們在兩台電腦的 /etc/hosts 各加上下列設定：

192.168.199.102 client.cyril.idv client
192.168.199.103 knockd.cyril.idv knockd

接下來，我們就一步步完成今天的範例。

第一階段安裝與設定 knockd 服務
此階段的操作皆在 ssh 服務主機 (knockd.cyril.idv) 上進行。

加入對應的 repo
新增檔案 /etc/yum.repos.d/nux-misc.repo 並加入下列內容

[nux-misc]
name=Nux Misc
baseurl=http://li.nux.ro/download/nux/misc/el6/i386/
enabled=0
gpgcheck=1
gpgkey=http://li.nux.ro/download/nux/RPM-GPG-KEY-nux.ro

安裝 knock 服務
指令是

[root@knockd ~]# yum --enablerepo=nux-misc install knock-server –y

將目前執行中的防火牆規則導入至檔案
指令是
```
[root@knockd ~]# iptables-save > /tmp/iptables.sav
```

修改防火牆規則檔案
直接修改上述檔案，將內容改為

# Generated by iptables-save v1.4.7 on Mon Aug 17 21:32:51 2012
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [149:22436]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Mon Dec 17 21:32:51 2012

除了將 INPUT 的預設動作由 ACCEPT 改為 DROP 之外，也移除掉原本 ssh 服務 (TCP Port 22) 的開放規則。

匯入新的防火牆規則
指令是

[root@knockd ~]# iptables-restore < /tmp/iptables.sav

移除防火牆規則檔案
指令是

[root@knockd ~]# rm –f /tmp/iptables.sav

確認目前的防火牆規則
指令是

[root@knockd ~]# iptables-save

應可以看到類似下列的訊息：

# Generated by iptables-save v1.4.7 on Mon Aug 17 21:42:57 2012
*filter
:INPUT DROP [17:1672]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [149:22436]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Mon Dec 17 21:42:57 2012

將目前的防火牆規則寫入系統設定
指令是
```
[root@knockd ~]# service iptables save
```

設定 knockd
knock 服務預設的設定檔是 /etc/knockd.conf，修改成如下：

[options]
        UseSyslog

[opencloseSSH]
        sequence      = 4567:tcp,5678:tcp,6789:tcp
        seq_timeout   = 15
        tcpflags      = syn
        start_command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport ssh -j ACCEPT      
        cmd_timeout   = 10
        stop_command  = /sbin/iptables -D INPUT -s %IP% -p tcp --dport ssh -j ACCEPT

設定 knock 服務自動啟動
指令是
```
[root@knockd ~]# chkconfig knockd on
```
啟動 knock 服務
指令是
```
[root@knockd ~]# service knockd start
```

第二階段安裝 knock 用戶端程式
雖然 knock 使用的敲門技術可以透過許多工具來產生所需的敲門封包，但是使用 knock 內建的工具可以簡化指令的操作。不過如果要進行比較複雜的敲門動作 (也就是送出比較複雜的封包)，那就還是必須借助更複雜的封包產生工具了。
此階段的操作皆在 ssh 用戶端電腦 (client.cyril.idv) 上進行。

加入對應的 repo
新增檔案 /etc/yum.repos.d/nux-misc.repo 並加入下列內容

[nux-misc]
name=Nux Misc
baseurl=http://li.nux.ro/download/nux/misc/el6/i386/
enabled=0
gpgcheck=1
gpgkey=http://li.nux.ro/download/nux/RPM-GPG-KEY-nux.ro

安裝 knock 用戶端工具
指令是

[root@client ~]# yum install --enablerepo=nux-misc knock –y

第三階段測試 knock 機制

直接嘗試連結 ssh 服務
指令是
```
[root@client ~]# ssh knockd
```
我們發現指令一直沒有回應，必須透過 Ctrl-C 才能跳脫。
使用敲門機制
指令是
```
[root@client ~]# knock knockd 4567:tcp 5678:tcp 6789:tcp && ssh knockd
```
此時我們應該可以透過 ssh 服務正常連結至主機 knockd (192.168.199.103)，並看到類似下列訊息：
Last login: Mon Aug 17 21:40:42 2012 from client.cyril.idv
[root@knockd ~]#

檢查 knock 服務的日誌
knock 服務預設會將日誌寫入 /var/log/secure 這個檔案中，在 ssh 服務主機 (192.168.199.103) 我們可以看到類似下列的訊息

Aug 17 21:45:31 knockd knockd: waiting for child processes...
Aug 17 21:45:31 knockd knockd: shutting down
Aug 17 21:45:31 knockd knockd: starting up, listening on eth0
Aug 17 21:45:42 knockd knockd: 192.168.199.102: opencloseSSH: Stage 1
Aug 17 21:45:42 knockd knockd: 192.168.199.102: opencloseSSH: Stage 2
Aug 17 21:45:42 knockd knockd: 192.168.199.102: opencloseSSH: Stage 3
Aug 17 21:45:42 knockd knockd: 192.168.199.102: opencloseSSH: OPEN SESAME
Aug 17 21:45:42 knockd knockd: opencloseSSH: running command: /sbin/iptables -A INPUT -s 192.168.199.102 -p tcp --dport ssh -j ACCEPT
Aug 17 21:45:42 knockd sshd[2472]: Accepted publickey for root from 192.168.199.102 port 52920 ssh2
Aug 17 21:45:42 knockd sshd[2472]: pam_unix(sshd:session): session opened for user root by (uid=0)
Aug 17 21:45:52 knockd knockd: 192.168.199.102: opencloseSSH: command timeout
Aug 17 21:45:52 knockd knockd: opencloseSSH: running command: /sbin/iptables -D INPUT -s 192.168.199.102 -p tcp --dport ssh -j ACCEPT

透過 knock 所提供的敲門機制，我們可以建立起複雜的敲門機制。以上述的例子而言，我們必須依序連接 3 個 TCP 埠，才能順利連結 ssh 服務。除了 TCP 埠，我們也可以選擇 UDP 埠。而因為對 knock 機制而言，其實只是在接受到敲門訊息後呼叫特定的指令，所以除了 iptables 的指令外，也可以用來呼叫其他指令，以達成不同的管理目的。

[工具介紹] 利用 glusterfs 達成目錄即時自動同步與高可用性

2013-09-17T00:55:00.001+08:00

去年我介紹過利用 lsyncd 這個套件來達成目錄的同步備援，今天則要利用 glusterfs 來達成類似的效果。雖說類似，但是 lsyncd 與 glusterfs 相比有下列差別：

lsyncd 監測目錄的變動，並定期 (或達到一定的異動次數) 將異動同步到另外一個目錄。因為 lsyncd 採用 inotify 監測技術，所以如果目錄內的檔案或子目錄一多，就可能會產生無法監測的問題。
lsyncd 本身並沒有支援高可用性，必須利用其它機制 (如 heartbeat) 來達成高可用性。
被同步的目錄通常僅能當做備援，無法作為負載平衡之用。不但在資源使用上較為浪費，擴充性也比較差。

嚴格來說，拿 lsyncd 與 glusterfs 相比並不是一件公平且合理的事情，因為 glusterfs 本身是一個完整的分散式檔案系統，所以在功能上本就遠比 lsyncd 這類工具來的強大許多。用最簡單的說法，glusterfs 可以將許多不同的儲存空間整合在一起，變成一個分散式的虛擬儲存空間。glusterfs 所管理的虛擬儲存空間除了可以具備分散的特性 (distributed, 也就是將不同的檔案存放在不同的儲存空間) 之外，glusterfs 還提供了複製 (replicated, 也就是同一個檔案存放在兩個以上的儲存空間) 以及分條 (stripped, 也就是將一個檔案打散在多個不同的儲存空間) 的選項。這些選項可以單獨使用，也可以一起套用。今天我要跟大家分享的就是透過複製特性來達成目錄的自動同步與高可用性。
範例需要三台 Linux 系統，其中兩台作為 glusterfs 的服務端，另外一台則作為 glusterfs 的用戶端，所使用的環境皆為 CentOS 6.4。相關架構如下：

為了方便起見，我們讓這三台 Linux 之間可以透過主機名稱進行連結，所以我們在 /etc/hosts 設定如下：

192.168.199.100 server1.cyril.idv server1
192.168.199.101 server2.cyril.idv server2
192.168.199.102 client.cyril.idv client

接下來就讓我們一起一步步完成今天的範例吧。

第一階段：glusterfs 服務端的基本安裝
此階段的步驟必須在 server1 與 server2 上皆予以執行。

安裝 glusterfs 的 repo
指令為
```
wget http://download.gluster.org/pub/gluster/glusterfs/3.3/LATEST/EPEL.repo/glusterfs-epel.repo -O /etc/yum.repos.d/glusterfs-epel.repo
```
註1：雖然目前 glusterfs 的最新版本為 3.4，但是 GA 版本仍為 3.3，所以在這個範例中我選擇使用 3.3 的 repo。
如果系統已經安裝 EPEL 的 repo，裡面就包含了 glusterfs 3.2 的相關 RPM 套件。但仍建議停用 EPEL 內的 glusterfs 套件，而改採用上述的套件。
安裝 glusterfs 的服務器套件
指令為
```
yum install glusterfs-server -y
```
設定 glusterfs 服務開機後自動啟動
指令為
```
chkconfig glusterd on
```
啟動 glusterfs 服務
指令為
```
service glusterd start
```

修改防火牆設定
在 glusterfs 官方文件中提到應該開啟 TCP 111, 24007, 24008, 24009 以及之後的數個埠號，至於要開到幾個埠號，則跟 brick 數量有關。以這個例子而言，應該開啟 TCP 111, 24007, 24008, 24009, 24010, 24011 等埠號。
修改完後記得確認防火牆規則是否已經生效。指令為

iptables –L -n

執行後應可以看到類似下列資訊

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0      
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:111
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:24007
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:24008
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:24009
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:24010
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:24011
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target     prot opt ource               destination
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)     
target     prot opt source               destination

第二階段：glusterfs 服務端的服務設定
此階段的指令僅需在 server1 予以執行即可。

將 server2 加入可信任的儲存池 (Trusted Stroage Pool)
指令為
```
[root@server1 ~]gluster peer probe server2.cyril.idv
```
執行後應可看到下列訊息
```
Probe successful
```

確認信任關係
指令為

[root@server1 ~]gluster peer status

執行後應可看到類似下面的訊息

Number of Peers: 1

Hostname: server2.cyril.idv
Uuid: f44e01c6-e889-432a-8056-cf7174421324
State: Peer in Cluster (Connected)

建立 Volume
在 glusterfs 的架構中，每一個 volume 就代表了單獨的虛擬檔案系統。建立 volume 的指令為
```
[root@server1 ~]gluster volume create datavol replica 2 transport tcp server1.cyril.idv:/data server2.cyril.idv:/data
```
執行後應可看到下列訊息
```
Creation of volume datavol has been successful. Please start the volume to access data.
```
註2：glusterfs 會自動建立不存在的 /data 目錄。此外，在建立 volume 時，我們不需要特別指定虛擬檔案系統的屬性 (像是分散與否)，glusterfs 會自動根據相關參數 (如 brick 數) 決定此一虛擬檔案系統的屬性。

啟動 Volume
指令為

[root@server1 ~]gluster volume start datavol

執行後應可看到下列訊息

Starting volume datavol has been successful

確認服務之間的連線已經正常連結
指令為

[root@server1 ~]netstat –tap | grep glusterfsd

執行後應可看到類似下列的訊息

tcp        0      0 *:24009                     *:*                         LISTEN      2343/glusterfsd
tcp        0      0 server1.cyril.idv:24009     server2.cyril.idv:exp2      ESTABLISHED 2343/glusterfsd
tcp        0      0 server1.cyril.idv:24009     server1.cyril.idv:1020      ESTABLISHED 2343/glusterfsd
tcp        0      0 server1.cyril.idv:24009     server2.cyril.idv:1020      ESTABLISHED 2343/glusterfsd
tcp        0      0 server1.cyril.idv:24009     server1.cyril.idv:1023      ESTABLISHED 2343/glusterfsd
tcp        0      0 localhost:1020              localhost:24007             ESTABLISHED 2343/glusterfsd

查詢 volume 的狀態
指令為

[root@server1 ~]gluster volume info datavol

執行後應可看到類似下列訊息


Volume Name: datavol
Type: Replicate
Volume ID: 185ef7c6-7c7f-461d-8690-eec24a1a4c38
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: server1.cyril.idv:/data
Brick2: server2.cyril.idv:/data

其中 Type 資訊表示這是一個複製的 (Replicate) 虛擬檔案系統。

為了增加安全性，我們可以限制只有 client 電腦的 IP 才能連上此一虛擬檔案系統
指令為
```
[root@server1 ~]gluster volume set datavol auth.allow 192.168.199.102
```
執行後應可看到下列訊息
```
Set volume successful
```

再次確認 volume 的狀態
指令同樣為

[root@server1 ~]gluster volume info datavol

執行後應可看到類似下列訊息


Volume Name: datavol
Type: Replicate
Volume ID: 185ef7c6-7c7f-461d-8690-eec24a1a4c38
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: server1.cyril.idv:/data
Brick2: server2.cyril.idv:/data
Options Reconfigured:
auth.allow: 192.168.199.102

第三階段：glusterfs 用戶端的安裝

安裝 glusterfs 的 repo
指令為

[root@client ~]wget http://download.gluster.org/pub/gluster/glusterfs/3.3/LATEST/EPEL.repo/glusterfs-epel.repo -O /etc/yum.repos.d/glusterfs-epel.repo

安裝 glusterfs 用戶端的套件
指令為

[root@client ~]yum install glusterfs-client -y

建立掛載點
指令為

[root@client ~]mkdir /mnt/glusterfs/data –p

掛載虛擬檔案系統
指令為

[root@client ~]mount.glusterfs server1.cyril.idv:/datavol /mnt/glusterfs/data

確認掛載的結果
指令為

[root@client ~]mount –t fuse.glusterfs

執行後應可看到類似下列訊息

server1.cyril.idv:/datavol on /mnt/glusterfs/data type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)

設定開機自動掛載
修改 /etc/fstab，加上下列設定

server1.cyril.idv:/datavol /mnt/glusterfs/data glusterfs defaults 0 0

重新開機
指令為
```
[root@client ~]sync; shutdown –r now
```

確認開機自動掛載是否成功
指令同樣為

[root@client ~]mount –t fuse.gluserfs

執行後應可看到類似下列訊息

server1.cyril.idv:/datavol on /mnt/glusterfs/data type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)

測試檔案的操作
指令為

[root@client ~]echo "Hello GlusterFS" >> /mnt/glusterfs/data/test0

確認檔案的同步複製
我們可以同時在 server1 與 server2 的 /data 下看到 test0 這個檔案，而且內容皆為 "Hello GlusterFS"。

至此，我們已經完成利用 glusterfs 建立目錄即時同步的架構。接下來我們將透過更多的例子，看看此一架構可以提供何種程度的高可用性。
註3：如果我們直接在 server1 或 server2 上針對檔案系統 (也就是 /data) 進行異動的操作 (如新增檔案)，將無法對達到同步的效果，甚至連用戶端也無法接受到這些異動。

第四階段：高可用性測試

關閉 server1
指令為
```
[root@server1 ~]sync;shutdown –h now
```
修改檔案內容
指令為
```
[root@client ~]echo "Hello GlusterFS Replication" >> /mnt/glusterfs/data/test0
```
雖然 server1 已經關機，但是我們依舊可以對原本掛載的目錄進行讀寫，其讀寫的目的地會自動變成 server2。
確認 server2 上檔案 test0 的內容
指令為
```
[root@server2 ~]# cat /data/test0
```
執行後應可看到下列訊息
```
Hello GlusterFS
Hello GlusterFS Replication
```
開啟 server1
確認 server1 上檔案 test0 的內容
指令為
```
[root@server1 ~]# cat /data/test0
```
執行後應可看到下列訊息
```
Hello GlusterFS
Hello GlusterFS Replication
```
註4：glusterfs 具備自動修復 (heal) 的功能，如果目錄下的資料較多，自動修復所需的時間也會跟著增長。在自動修復期間雖然服務端的檔案可能會有不一致的現象發生，但是 glusterfs 會確保用戶端只會看到最新的檔案。
再次關閉 server1
指令同樣為
```
[root@server1 ~]sync;shutdown –h now
```
卸載用戶端上的目錄掛載
指令為
```
[root@client ~]umount /mnt/glusterfs/data
```
再次掛載目錄
指令為
```
[root@client ~]mount -a
```
執行後應可看到下列訊息
```
Mount failed. Please check the log file for more details.      
```
註5：掛載失敗的原因在於 server1 已經關機，所以用戶端自然無法進行連結。雖然 glusterfs 在掛載後的讀寫具備自動切換的能力，但是掛載時的動作卻無法自動切換。

修改掛載的參數，使其支援備用掛載主機
修改 /etc/fstab，將原本

server1.cyril.idv:/datavol /mnt/glusterfs/data glusterfs defaults 0 0

修改為

server1.cyril.idv:/datavol /mnt/glusterfs/data glusterfs defaults,backupvolfile-server=server2.cyril.idv 0 0

再次掛載目錄
指令為
```
[root@client ~]mount –a
```
確認掛載結果
指令為
```
[root@client ~]mount –t fuse.glusterfs      
```
執行後應可看到下列訊息
```
server2.cyril.idv:/datavol on /mnt/glusterfs/data type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)
```
註6：在此我們可以看到掛載主機已經從 server1 改為 server2了。透過此一參數，可以避免 glusterfs 在掛載目錄時因為單一主機失效而掛載失敗。

透過 glusterfs，我們可以輕鬆建立一個可自動同步且具備高可用性的目錄。更棒的是，如果未來我們發現這個目錄有空間不足或效能低落的情況發生，只要加上更多的 brick，就可以直接在線上進行擴充的工作，不用再擔心因為資料轉移所造成的過多時間花費與停機時間了。

[個人意見] ALE 了沒 - The Ugly Truth about ALE

2013-04-26T14:52:00.000+08:00

對資安從業人員來說，一個揮之不去的困擾就是如何評估一個計畫或產品的必要性。必要性除了從功能面著手，更重要的是財務面的考量。把錢花在刀口上是所有員工的責任，更何況當我們要向 CEO 爭取支持時，如果提不出相關的證明，就算 CEO 可以接受"威脅"形式的溝通，到 CFO 那關也往往只能等著被打槍。所以諸如 ROI (Return on Investment)、TCO (Total Cost of Ownership) 等指標，就變成我們用來將相關需求與財務做整合的可用工具。
除了 ROI 與 TCO，還有一種更常見的評量工具，我們稱之為 Annualized Loss Expectancy，簡稱 ALE。ALE 不但在實務上很常見，更是許多資安認證的必考題。首先，我們來看 ALE 的計算公式：
ALE = SLE * ARO
Annualized Loss Expectancy = Signle Loss Expectancy * Annualized Rate of Occurrence
每年損失的期望值 = 單一事件損失期望值 * 每年發生的機率
舉例來說，假設我們公司平均每五年發生一次中毒事件，每次造成的損失 (人力成本、業務損失) 為 100000 元，那麼病毒這個威脅來源的 ALE 就是
100000 元 * 1/5 = 20000 元
ALE 的觀念與計算都相當簡單。此外，通常安全計畫或產品的導入並不會增加受益，所以 ROI 不容易套用。而 TCO 則因為沒有辦法與"成效"做關連，所以說服力也往往不足。這些因素的加總，使得 ALE 很受到資安從業人士的歡迎。但是當我們認真思考後，就會發現 ALE 的計算往往只是落入無意義的數字遊戲，對事情的判斷並沒有任何幫助。
ALE 本身就是一種根據統計而來的計算。面對統計數據，我們必須先釐清的是何謂有效的數據來源？不管是 SLE 或 ARO，是要參考全世界的企業？還是國內的企業？是要參考所有產業的企業？還是只要參考與企業本身相同產業的企業？甚至只要考慮自己企業本身的歷史數據？
當我們選定一個數據來源時，就會發現下一個問題，那就是樣本數不夠多，甚至是無法取得任何實際的樣本數據。通常特定種類資安事件的發生次數都不會很頻繁，一個企業可能一年發生個一兩次就很可怕了。高於此發生頻率的問題，我相信不需要採用 ALE 的方式，光用威脅就可以讓 CEO/CFO 屈服了。樣本不夠多，統計數據的參考價值就很低，這就是統計的天性。就算我們拿全世界企業的數據來參考，就真的拿的到真實的數據嗎？有多少企業願意誠實公布這樣的數據？又有多少企業能夠在資安事件發生時都確實掌握了？ARO 如此、SLE 更是如此。別忘了 SLE 可是損失的期望值，必須知道損失的機率分布才能算的出。好吧，就算我們把 SLE 簡化成損失的平均值，問題也沒有變得比較好回答。
所以，SLE 與 ARO 變成了自由心證的數字。而不幸的是，因為 ALE 的計算就是這麼簡單，只要把 SLE 乘上 ARO 就成了。所以一旦"不小心"將 SLE 高估了兩倍，ALE 也就變成兩倍，對於財務可行性的判斷結果可能也因此有了翻盤的影響。
當然，我們也別看輕 ALE。畢竟 ALE 除了在某些場合確實能夠幫助我們分析財務面的可行性，甚至在更多時機能夠成為我們用來說服 CEO/CFO 的溝通工具。只是，在這些數字背後所代表的意義，其實只是我們內心主觀的偏見。而這，正是 ALE 的 Ugly Truth。

相關連結：

Security and Business: Financial Basics

[從電影看資安] 確實做好 NAC，電腦亂插免驚係 - 空降危機

2013-04-23T21:07:00.000+08:00

作為 007 電影系列的第 23 部作品，空降危機中充滿了各種"老"的感覺。007 老了，MI6 也老了。不過老歸老，不放棄的精神卻是未曾減少。M 夫人為了 MI6 的未來，勇敢面對政客的質疑。而 007 也為了維持國家安全，必須面對自己因為受傷與年紀漸長所帶來的技巧生疏。除了無形的老，連片中的道具與武器，也都極力配合著"老"這個觀念。古董車、老式無線電發射器、獵槍、取代被炸毀的 MI6 總部的地下碉堡、007 的老家、甚至是史上年紀最大的 007 女郎，都充滿了濃濃的復古意味。當然，薑是老的辣，007 就利用這群老東西，成功的剷除了他的前輩，也就是曾經最受 M 夫人所器重的前情報員-西法。

電影一開始，007 在進行一項任務時發現一個受傷的情報員。
更糟的是，內含情報員名單的硬碟被搶了。

M 夫人指示 007 以追回硬碟為優先任務，情報員就放給他死。不管在哪個產業，人人都是可以被犧牲的棋子。

尚未從超級老爸破壞中復原的伊斯坦堡，這次 007 只是小意思來點摩托車特技。

市區還是留給超級老爸來破壞，007 負責破壞火車。

火車即將進入隧道，再抓不到壞人就等著名單外洩了，但是偽 007 女郎顯然對自己的槍法不是很有信心。
有1就有2，連無名小卒都可以放棄了，007 算什麼？(呃，好像說反了)
果然打中 007 了！James Bond, KIA!

M 夫人真是衰到家，不但名單外洩，連總部也在自己眼前被炸了。

007 不虧是 007，大難不死後第一件事就是幹他最拿手的事。

出門在外的好夥伴-CNN 頻道。

007 回到 MI6，工作人員帶他到"新"的 MI6 總部。

新總部是一個外表低調到不行的古老碉堡。

你不需要說抱歉，只要…你知道的。
空降危機中少數真正"新"的東西之一-軍需官 Q。

007 憑著有限的線索來到了一個賭場，沒想到後續"線索"得來全不費工夫。
既然是線索，當然要好好"探索"一番。

007 就是這麼真男人，即使知道是陷阱也要上。

原來是老前輩啊，對他來說，007 只代表一個字-菜。

只是老前輩做夢也想不到，菜鳥就靠著一個超復古的無線電發射器，引來了一堆救兵。

英國的直升機就這麼忽然出現在不知名的小島上。
M 夫人終於知道自己的老巢是被誰炸掉了。

原來正是她自己的兒子。
除了逮人，當然也順道接受了壞蛋的電腦設備。
嗯，連記憶體內的資料都不爽給你看。
Q 表示，我有離線恐懼症。

Q 確實是電腦高手。
Q 表示，我真的好想破解密碼喔。
007表示，我才是主角，猜密碼這種功勞還是交給我。

雖然 007 猜對了密碼，但是沒多久 MI6 的系統就發出警告。
Q 還在一頭霧水中。

Q:…
就算是天才，也一樣會成為資安防護中的那顆老鼠屎。

不是他駭入你們，是你放他進來的，傻B。
經過一連串的追蹤後，007 選擇回到老家 (空降莊園?) 當做最後決戰的地點。

小鬼當家老灰啊版。

密密麻麻的壞蛋，但是他們不知道要分散跟尋找掩護嗎？

一陣熱情如火的纏綿。
愛你愛到殺死你。

再冷酷的人，臨死前也難免會感傷。

果然 M 夫人才是 007 最愛的 007 女郎。(無誤)

第24、25部 007 作品已經在籌劃中囉，你演不演？

007表示，有錢賺當然演啊。哈利波特系列已經結束了，你也一起來這邊賺吧。

在電影中，聰明如軍需官Q也犯下了一個不可原諒的大錯，那就是隨意將壞人的電腦接上內部網路。我們都知道，路邊撿來的隨身碟不可亂插，路邊撿來的電腦 (如果你撿得到的話) 當然也不可以隨意接上內部網路，更何況還是壞人的電腦。除了路邊撿來的電腦，員工、協力廠商、訪客的智慧型手機、平板電腦、筆電，都可能因為防護力不足而成為內部資安威脅的來源。更遑論還有所謂的商業間諜，隨時對藏於企業內部網路當中的珍貴資訊虎視眈眈。
因應這些行動裝置所帶來的方便性與危險性，每個企業都應該訂定完善的 BYOD 政策，以有效管理因這些裝置所帶來的風險。但是政策再好，如果只限於管理上的政策 (如規定不能隨意將個人手機接入公司的網路)，終究只能防君子 (而且還是腦袋清楚的君子)，而無法防堵小人。所以搭配必要的技術性政策，如導入NAC，將可以大幅提高管理性政策的有效性，達到更即時且全面的效果。正所謂樹多有枯枝，人多有白痴，光依靠管理性政策來保護內部網路的安全，只要一個白痴就可以讓企業產生莫大的資安威脅。如果 MI6 有確實導入 NAC 機制，那麼壞人的電腦根本就無法對 MI6 內部網路進行任何的存取動作，更別說要入侵 MI6 的重要伺服器了。如此一來，後續故事應該會有完全不同的發展，或許 M 先生也只能先回去繼續當他的佛地魔了。

[從電影看資安] 資安也要背後靈，跟前顧後保安寧 - 12生肖

2013-04-22T22:14:00.000+08:00

12生肖 (CZ12) 是由華人電影圈中極富盛名的犯錯動作男星-成龍-所自導自演的一部冒險電影，也號稱是他最後一部動作片。姑且先不論"最後"兩字的可信度是不是比"天下的男人都會犯同樣的錯"來得高，成龍在這部片中賣力依舊，讓人不得不佩服。
12生肖故事內容講述英法聯軍在與清朝政府的戰爭期間，搶奪了許多中國的寶物，其中原本放置於圓明園的12獸首，日後身價水漲船高，在拍賣市場中屢創價格的新高。也因為利益驅使，所以俠盜 (?) 集團首腦 JC (成龍飾演) 受到好友的委託，希望能夠代為尋找其他尚未被發現的獸首。而在這些失落的獸首中，象徵中國人的龍首，更是寶物中的寶物。有了目標，當然必須先收集足夠的情資，因此 JC 假冒成國家地理頻道的攝影師，前往拜訪專門研究12獸首的關教授，並趁機取得部分獸首的完整資訊。除了取得獸首的資訊，JC 更經由關教授的介紹，認識了女主角 Coco - 一個致力於促進各國國寶"回家"的小女生。就在一連串的~~胡鬧劇情~~陰錯陽差後，JC 一行人順利用假的雞首"換"到一個真品，但是 Coco 的弟弟也在過程中遭受奸商，也是 JC 的委託人所綁架。在面對利益與人命的衝突時，JC 想當然爾一定是選擇正妹人命優先。最後，JC 不但順利救出 Coco 的弟弟，還"順便"搶回了原本就一直在委託人手上的龍首，為亞洲飛鷹 JC 的冒險故事，畫下一個完美的句點 (還是逗點?)。

這個馬首的價格是6千9百萬美元，富豪的錢果然都不是錢。

到別人家搶東西就算了，還拍照留戀咧。

這個偷偷摸摸的人就是俠盜 (?) JC。

JC 這次玩的是極限滑輪 (Extreme Rollerblading)。

隨便說說自己是國家地理頻道的攝影師也騙得了人。

教授也懂得拍馬屁。

關教授，算你還有點警覺。

雖然 JC 的手勢跟關教授的表情充滿無限的想像空間，但是別想歪了，JC 想要摸摸獸首。

反正都是假貨，隨便你摸吧！

關教授還以為 JC 是怕弄髒獸首才戴上手套，真是一個傻B老實人。

這可是高科技的3D立體顯影手套，西德最新產品，11萬美金一副。

數據馬上就送到後端的仿冒工廠。

再加上 3D 列印！？

馬上就變一個鼠首給你。

陰錯陽差間認識了一個古堡的女繼承人。

古堡女主人邀一行人前往參觀。

竟然把國寶雞首隨便擺放，果然太容易得來的東西都不會受到重視。

JC 當然不想放過眼前的肥羊，沒想到連正氣凜然的 Coco 都支持。

這次連手套都不用戴了，Coco 自願當內奸。

三兩下雞首就被掉包了，家裡太大果然不是一件好事，這麼多人瞎搞也沒被發現。

這個雞頭裡面藏的可是國寶雞首啊，但是鑄銅為什麼可以飄在空中？

在電影12生肖中，關教授因為對 JC 所冒充的攝影師掉以輕心，所以導致 JC 可以輕鬆取得獸首的資訊，並進而做出山寨版的獸首。在組織日常的運作中，也常常會面臨到招待外來訪客的情況。外來訪客不一定真是所謂的客人，也可能是協力廠商的維護人員。身為 IT/IS 人員，如果沒有確實遵守必要的作業規範 (如限制可攜帶的物品)，並在需要時陪同在側，那就可能產生很嚴重的資安問題。舉例來說，協力廠商可能因為作業需要，所以必須使用系統管理者的權限，或是對重要的網路設備或伺服器進行操作。如果沒有 IT/IS 人員在一旁確認其所進行的動作，那麼機密資料不小心被訪客看到、甚至洩漏出去，也不會是什麼值得大驚小怪的事情。

不可否認，除非訪客是迷死人不償命的帥哥或美女，否則陪同作業不但很無聊，而且還可能嚴重影響原本的工作時間安排。對此，我只能說這就是 IT/IS 人員無法逃避的責任。陪同作業不是陪對方聊天，而是隨時隨地確認對方是否進行了非經許可的動作，並在發生前 (時) 予以阻止。再加上對方來訪本就有原本的任務，因此往往也沒辦法一直閒聊。所以進行陪同作業時更像是把自己當做訪客的背後靈，不能干擾他進行作業的同時，也不能讓對方對組織的資訊安全產生危害。倒是對於 IT/IS 的主管們來說，當部屬告訴你他今天跟了協力廠商支援人員一整天時，可千萬別以為他是偷懶只顧聊天。當然，我相信 IT/IS 的主管，也早就把當訪客背後靈這件乏味但又重要的工作內容，列在 IT/IS 的工作規範當中了。

[迷你好兔] 如何利用 Nagios/Icinga 來監測 CentOS 下的 Adaptec Raid 控制卡

2013-04-12T22:12:00.000+08:00

Raid 控制卡對伺服器來說，可說是很常見也很重要的一個元件。雖然主機本身通常都會有燈號可以顯示硬碟的狀態，甚至在硬碟出問題時發出警示聲響，但是這種方式對於遠端管理來說沒有多大的幫助，更何況並不是所有機器都有專業保母 24 小時隨時看著呢。至於 Raid 控制卡的狀態，光從主機外觀可就是更加不容易掌握了。
在這次的分享中，我將示範如何利用 Nagios 來監測安裝於 CentOS 下的 Adaptec Raid 控制卡，其型號為 6405/5405。

下載 Adaptec 命令列工具 (Command Line Utility)
以 6405 為例，可以從產品頁面下的 Storage Manager Downloads 連結，找到最新版本的命令列工具。
目前提供的最新版本是 Adaptec ARCCONF Command Line Utility v1.1.20324。雖然這個版本是從 6405 的頁面中下載，但是一樣支援 5405 這個型號。
選擇合適的執行檔
解開下載的壓縮檔後可以看到11個目錄，各自代表不同系統的執行檔。以 64 位元的 CentOS 為例，所需的執行檔就是 linux_x64/arcconf。我們將這個檔案放置於系統內的 /opt/Adaptec 目錄下，並加上執行權限。

測試 Command Line Tool
輸入指令

/opt/Adaptec/arcconf GETCONFIG 1 AL

如果看到下列資訊表示指令運作正常

Controllers found: 1
----------------------------------------------------------------------
Controller information
----------------------------------------------------------------------
   Controller Status                        : Optimal
   Channel description                      : SAS/SATA
   Controller Model                         : Adaptec 6405
…

下載 Nagios/Icinga 監測所需腳本
可以從這裡下載所需腳本 check-aacraid.py
https://www.ip6.li/cms/tiki-download_file.php?fileId=46
下載完後請將檔案放置於 nagios plugins 的目錄，並加上執行權限。以 64 位元的 CentOS 為例，此一目錄為 /usr/lib64/nagios/plugins/。
如果監測的 Raid 控制卡是 6405，必須修改 check-aacraid.py，將
```
if bstatus.group(1) == "Not Installed":
```
改為
```
if bstatus.group(1) == "ZMM not installed":
```

測試監測腳本 check-aacraid.py
執行

/usr/lib64/nagios/plugins/check-aacraid.py

如果出現下列資訊表示腳本執行成功

Logical Device 0 Optimal,Controller Optimal

在安裝 ZMM 的情況下，顯示資訊則為

Logical Device 0 Optimal,Controller Optimal,Battery Status ZMM Optimal

設定 nagios 帳號權限
因為 arcconf 需要 root 權限才能正常執行，所以我們需要加上 sudo 的設定。新增 sudo 設定檔 /etc/sudoers.d/nagios，並輸入下列內容
```
nagios ALL=(root) NOPASSWD: /opt/Adaptec/arcconf GETCONFIG 1 *
Defaults:nagios !requiretty
```
測試 nagios 權限
切換為帳號 nagios 後，再次執行步驟 5，應該不用輸入 root 密碼就可以得到相同的結果。
設定 nrpe
修改 nrpe 設定檔 /etc/nagios/nrpe.cfg，加上下列設定
```
command[check_aacraid]=/usr/lib64/nagios/plugins/check-aacraid.py
```
重新啟動 nrpe
指令
```
service nrpe restart
```

設定 Ngaios/Icinga
之前所有動作皆在安裝 Adaptec 控制卡的主機上進行，後面幾個動作則在 Nagios/Icinga 監測主機上進行。以 Icinga 為例，所需修改之設定檔為 /etc/icinga/objects/localhost.cfg，加上下列設定

define service{      
       use                              local-service      
       host_name                        hostname      
       service_description              AACRaid [Adaptec] Status      
       check_command                    nrpe!check_aacraid      
}

其中 hostname 是安裝 Adaptec Raid 控制卡的主機名稱。

重新讀取設定檔
以 Icinga 為例，指令是
```
service icinga reload
```

透過幾個簡單的步驟，我們就可以利用 Naigos/Icinga 隨時監控 Adaptec Raid 控制卡與硬碟的狀態，晚上睡覺也可以睡得更安穩囉。

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

2012-11-07T22:56:00.000+08:00

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

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

修改 ssh 服務所使用的埠號
ssh 服務的設定檔為 /etc/ssh/sshd_config，將
```
#Port 22
```
改為
```
Port 2222
```
其中 2222 表示我們想要 sshd 服務所使用的埠號。
重新啟動 ssh 服務
指令為
```
service sshd restart
```
匯出 iptables 所使用的設定
指令為
```
iptables-save > /tmp/iptables
```
如果你使用其他工具 (如webmin) 來設定 iptables，那麼就不需要進行 iptables 規則的匯入與匯出，可以直接加入所需規則。
修改 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
匯入 iptables 的規則
指令是
```
iptables-restore < /tmp/iptables
```
測試新的規則
從另外一台主機執行下列指令
```
telnet ip_address 54321; ssh ip_address –p 2222
```
其中 ip_address 請換成前一台主機的 IP 位址。順利的話，應該可以看到 ssh 的登入提示符號。如果我們在 telnet 與 ssh 兩個指令之間停頓超過 5 秒，將無法連結至 ssh 服務，也就是說每次敲門後的開放只保留 5 秒，5 秒過後又自動加以關閉。如以一來，即使利用埠號掃描攻擊也很難發現 ssh 服務真正使用的埠號。
刪除規則暫存檔
指令是
```
rm –f /tmp/iptables
```
將規則寫入 iptables 的啟動設定
如果測試無誤，我們就可以把規則寫入 iptables 的啟動設定，以確保每次啟動 iptables 時都能套用此一設定。指令是
```
service iptables save
```

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

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

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

2012-11-06T21:29:00.000+08:00

數位資料對一個企業的重要性，我想已經不用我在此多加贅述。而這些數位化的資料，除了存在於資料庫當中，其實還有不少是以檔案形式存在著。對於資料庫，通常我們除了定期備份之外，還會考慮到備援的機制 (如常見的主從式架構)，以確保資料庫的高可用性。但是對於檔案呢？往往可能就沒有那麼受到重視了。備份或許有之，但是是否有也良好的備援機制呢？檔案的備援有多種可能性，從分散式儲存機制 (如 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 時，有下列幾點事情需要注意：

因為新版的 rsync 已經預設使用 ssh 當做傳輸的方式，所以可以直接設定使用 rsync 即可。如果 rsync 版本過舊，可以將 sync 方式由 rsync 改為 rsyncssh。也就是說，我們必須確保主目錄的主機可以直接透過 ssh 登入備援主機，而不需要輸入密碼。除了利用 rsync + ssh 的方式，也可以透過 rsync 的 target，如此一來就不需要 ssh 了。
lsyncd 預設不會同步檔案的所有權與權限，因此我們透過 rsyncOps 這個參數來改變 lsyncd 呼叫 rsync 的行為。
透過 delay = 10 這個設定，我們要求 lsyncd 將同步間隔時間由預設的 20 秒改為 10 秒。
我們必須確保所有的寫入動作發生於主目錄的主機上，而在一般的情況下，這應該是不成問題的。但是如果我們~~自找麻煩地~~在主目錄掛載了其他主機的目錄，那麼這些掛載而來目錄的寫入動作，將無法被 lsyncd 監測到，所以也就無法同步。
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
```
CentOS 所安裝的 lsyncd 並沒有提供啟動腳本，因此請在 /etc/rc.local 加上設定
```
/usr/bin/lsyncd /etc/lsyncd.conf
```
如此一來，開機時 lsyncd 才會自動執行。

雖然 lsyncd 無法真正達成目錄的"即時"同步，但是在可接受的誤差範圍內，lsyncd 有著安裝簡單與適用範圍廣泛的優點，對於檔案備援來說絕對是一個令人心動的選擇。

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

2012-10-14T14:59:00.000+08:00

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

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

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

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

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

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

2012-09-18T07:22:00.001+08:00

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

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

男主角趙懷安，跟後面要講的劇情無關，純粹是看在李連杰的面子上才放這張照片。
臨時出現的亡命二人組，書生樣的「風裡刀」外貌神似督主。

西廠的官兵一看，嚇到不知所措。

亡命之徒果然見過世面，馬上就發現西廠官兵的異常反應。

「風裡刀」最厲害的就是那張嘴，所以馬上前往官兵的房間套話。

雙方僵持不下。

西廠也不是那麼笨 (至少目前還不笨)，早偷偷派了人回去確認是不是真貨。

嘍囉不忘多拍幾下督主的馬屁。

督主就是督主，馬上想到一個~~餿主意~~妙計，那就是他要冒充「風裡刀」混進去搞破壞。

嘍囉想到一個辨別真假督主的方式，那就是用密語。

密語是「龍門飛甲」。

對「便知真假」。

嘍囉回到龍門客棧，先用密語確認督主的身分。

果然是假冒的，但是真督主有令不可打草驚蛇。

這是督主假扮的「風裡刀」，果然很像 (~~根本就是同一個人演的~~)。

督主又出現了，這次是真是假？

對方搶先一步說出密語的前半部。

搶答失敗。

只好硬著頭皮講出另一半的密語。

被擺道了。

剛剛是假的督主。

這次換督主的手下大將來認證說密語。

實在被騙太多次了，已經惱羞成怒。

不管三七二十一，放就對啦。

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

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

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

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