使用 Orbit Viewer THOR 建置亮度溫度分佈圖

Orbit Viewer THOR 是一套由 NASA 所提供專門來解析 TRMM 衛星資料的軟體，詳細的軟體介紹就不在這邊做介紹，畢竟只要會用就好了，是吧！由於這篇主要是針對亮度溫度分佈圖，所以其他的部份就不會多做說明。

一開始如果不知道想畫的颱風圖是存在哪筆衛星資料時，這時請將颱風資料庫和搜尋 TRMM/TMI 資料兩種資訊做個整合交叉查詢已得到確切的衛星資料編號。

知道了衛星資料編號後，就可以到 TRMM Data Access 去下載相對應的資料，在這邊要注意的地方是，含有亮度溫度資訊的衛星資料，其開頭代碼為 1B11: Microwave Brightness Temperature (TMI)，下載錯的話可是沒法顯示出正確的資訊。

啟動 Orbit Viewer，接著點選 File 開啟欲繪亮度溫度的衛星檔案，在這邊將以 1B11.080912.61677.6.HDF 為例，軟體啟動後如下圖：

接著點選 highResCh ，如下圖所示，在 channel 的部份則不需要去動它。

接著於下方的 Global: 1B11.080912.61677.6.HDF 的部份，使用滑鼠左鍵點選所要觀看的區域，其亮度溫度分佈圖就會顯示於主畫面上。

軟體預設是以點的方式來顯示亮度溫度分佈圖，如果想以平滑的方式展現，就點選 Option -> Interpolate Data ，圖就會變成這樣。

在決定欲輸出的圖之後，點選 File -> Save Image 便可以將圖另存成檔案，其支援的格式可以參考下圖所示。

基本上亮度溫度分佈圖，這樣就完成，此教學說明是使用 1.3.5 版，但 Orbit Viewer THOR 已經出到 2.0 ，其介面有點差異，有興趣的話可以自行去學習。

淺談 WEB 應用安全的防治挑戰

　　隨著科技不斷演進，使得WEB面臨著許多前所未知的風險。首先，於系統層面存在版本較舊的HTTP 軟體，未定時更新的作業系統等問題；其次，在應用層面有SQL Injection、XSS(Cross Site Scripting)、表單漏洞、上傳漏洞、網站掛馬等漏洞需加防範；最後在網路層面上則有ARP欺騙攻擊等，只要管理員稍不留心，便會使主機和使用者身陷於危險之境。

　　至於是哪些危險呢？必須瞭解怪客(Cracker)產業鏈。怪客主要是使用這些漏洞來進行一些「商業」行為，以網站掛馬為例，怪客大多是鎖定政府網站或企業網站為目標，利用應用層面安全漏洞，如SQL Injection等，來進行控制和入侵WEB伺服器，篡改網頁且植入惡意程式碼以啟動網站掛馬，接著掛馬便執行病毒，該使用者在不知情的狀況下，其電腦已成了殭屍網路(BotNet)的一員。在控制使用者的電腦之後，怪客通過竊取手段偷取使用者帳號、銀行帳號、密碼等，以竊取其私有財產。怪客至今的攻擊手段，除了掛馬之外，SQL Injection、XSS、Client Side、Database 等也為其攻擊目標。

　　在WEB應用安全主動防禦中，首先遇到的便是WEB應用安全弱點掃瞄的挑戰，在掃瞄的過程中需克服後門檢測、WEB 2.0、和HTTPS與驗證碼等問題。基礎掃瞄器的架構，主要分為爬行檢測和檢測功能。在爬行檢測中，細分為JavaScript檢測、繞道驗證碼、Google Hack和資料夾掃瞄等動作。於檢測功能中，則分為SQL Injection、XSS、針對WEB伺服器常見漏洞和知名WEB公開漏洞的檢測等。

　　於繞道驗證碼這個主題中，則需從設計的源由開始講起。驗證碼誕生的目的，主要是避免單一用戶瘋狂註冊帳號、防止大量垃圾訊息等。然而WEB掃描器運作方式類似網路爬蟲，依賴於請求的頁面數量和內容，某些WEB須在已登入的環境下，才能得到更多的WEB資訊。現今驗證碼各有其特點，實際的繞過驗證碼的方式可能不盡相同，而掃瞄器本質是希望繞過驗證碼的防護，且擁有合法使用者身份，以取得更多WEB頁面得到更多資訊。

　　應用層安全的檢測，主要分為黑盒和白盒解決方案。使用黑盒測試的優點在於能快速迅捷的部署、設計通用性高的程式、7x24小時隨時可用且可模擬真實外部攻擊風險狀況；然而不知道內部架構、過於僵化的測試程式、誤報和漏報的矛盾，皆為其缺點。白盒測試的優點則為：已知主要架構、系統參數檢測較精準；而黑盒檢測的優點，基本上就是白盒的缺點、7x24小時的監控仍是個問題及協力廠商所提供的元件，都是管理員需關注的部分。

　　綜觀以上，資訊安全防護除了需靠管理員的細心處理，在進行應用層安全檢測時，最好能共用黑盒與白盒的方式進行，以互補缺陷降低的損失。

雨量前置處理程式更新20090306

主要是修正 雨量前置處理程式 (1/2) 與 雨量前置處理程式 (2/2) 這兩篇中所提的程式。

修正的列表如下：

• 自動判斷年份的讀取機制(ADD)
• 時區轉換判斷系統(FIX)
• Windows Server 的相容性(ADD)

在做修正的時候，意外發現站台編號 94061 實際的資料，其實是對應 94062 的資訊，這點以後可能得多注意些。

下載 TRMM/TMI 資料

這邊是去 TRMM Data Access 做下載資料的動作，其主要是依據 搜尋 TRMM/TMI 資料 所提供的編號列表來做選擇式的下載。

Step 1.
進入至 TRMM Data Access 網站後，點擊 Data Products 。

Step 2.
這一頁中，點選 Orbital 以進入下一個流程。



Step 3.
於這個頁面中，我們則需要點選 1B11: Microwave Brightness Temperature (TMI) 這個連結。

Step 4.
從這開始，便要開始依據 搜尋 TRMM/TMI 資料 這篇所紀錄的資訊，來進行年、月、日的查詢資料。

Step 5.
這邊是月的部份。

Step 6.
這邊是日的部份。

Step 7.
按照 搜尋 TRMM/TMI 資料 的範例，我們將查找 2008-12-01 編號 62964 的資料。

Step 8.
可以見到第三行為我們要找的編號 62964 衛星資料，接著只需要將該 HDF 下載便完成此項動作。

搜尋 TRMM/TMI 資料

這邊的工作，主要是藉由 TRMM Overflight Finder 來限定搜尋範圍且得到相關的衛星資料編號。以下為詳盡的工作流程：

Step 1.
除了經緯度和搜尋範圍為固定的數值(25、130、600)之外，起始日期可以依照需求去做微調，待一切設定完成之後，便可點擊 Search for Oribt(s)以取得資料。

Step 2.
於本頁一開始的 Based on Selections 便是上一頁的設定參數，而下面的表格則為結果的輸出。但我們需要的部份只有 Orbit (編號) ，以圖例來說 62964 就是我們所需要的數字。

點擊連結時，我們則可以得到該編號所呈現的帶狀衛星資料圖，如下所示。

Step 3.
將這些編號逐一記錄起來，此動作就算圓滿達成任務。

清除 Thumbs.db

如果是用 *nix 的主機上傳時，往往是沒有這個問題的。但在使用 Windows 主機做上傳時往往會順手把 Thumbs.db 這個 Windows 用的預覽檔傳上去。 

雖然對主要的系統沒有什麼影響，但我就是覺得看起來很不舒服阿！也因為不完全都是我在上傳，所以這部份屬於無法控制的範圍，在這邊計劃使用被動的處理方式來解決這個問題。

在不影響系統做統計的狀況下，希望能在被紀錄前先把 Thumbs.db 先刪除，在 Shell Script 完成後，應該會加入 daily 的排程去處理。

FTP 分區異動

前陣子調到了 400G 和約 100G 的空間，趁著寫計畫書的空檔，我想還是將一些分區做一些整併和異動。

目前主要是把原先的電影和動漫做個整併，統整起來約 250G 的空間將全換成電影，剩下動漫則都歸類到 400G 的空間那邊去。

剩下的細節等過幾天再補上最新的配置圖。

[雨量] 實驗編號 1

這次實驗以 clusting 為主要的實驗方法，主要使用到的演算法有 SOM、Clusting、Fuzzy C-Means 這三種，分群的數量則為 4、5、10 總共三組做為比對。

全部數據出來後，再由 GA 去跑出最佳解的 BC 順序，但可能需要再修改 GA 的程式以達到需求。

此外有幾個需要考量的地方，像是選擇 BC 的 Threshold 該設定回多少，最低限度的資料數量又該是多少？

預定下星期三前把這些做完。

FTP 資料庫的 Table 設計

由於受限於 proftpd 的一些先天上的問題，所以在設計上比較不能照正統的方式去處理相關的 Tables。

雖然在資料庫裡前前後後有 26 個 Tables，但大都是用 View 去實現的，所以在先這邊列出實體上的四個 Tables。

FTP_User

CREATE TABLE `FTP_User` (
 `Id` int(10) unsigned NOT NULL AUTO_INCREMENT,
 `Name` varchar(12) NOT NULL,
 `Passwd` varchar(20) NOT NULL,
 `Uid` smallint(5) unsigned NOT NULL DEFAULT '5001',
 `Gid` smallint(5) unsigned NOT NULL DEFAULT '5000',
 `Home` varchar(16) NOT NULL DEFAULT '/home/NDU_FTP',
 `Shell` varchar(16) NOT NULL DEFAULT '/sbin/nologin',
 `Count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '登入次數',
 `Address` varchar(16) NOT NULL COMMENT 'IP位置',
 `Comment` varchar(16) NOT NULL,
 `Mail` varchar(45) NOT NULL COMMENT 'E-Mail',
 `Subscription` tinyint(1) NOT NULL DEFAULT '0' COMMENT '訂閱',
 `Accessed` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
 `Modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
 `Deleted` tinyint(1) NOT NULL DEFAULT '0' COMMENT '刪除',
 PRIMARY KEY (`Id`),
 UNIQUE KEY `Name` (`Name`)
) ENGINE=MyISAM AUTO_INCREMENT=41 DEFAULT CHARSET=utf8 \
COMMENT='ProFTP Users Table'

FTP_Group

CREATE TABLE `FTP_Group` (
 `Id` int(11) NOT NULL,
 `Name` varchar(16) NOT NULL DEFAULT 'NDU_FTP',
 `Gid` smallint(6) NOT NULL DEFAULT '5000',
 `Members` varchar(100) NOT NULL,
 PRIMARY KEY (`Id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 \
COMMENT='ProFTP Group Table'

FTP_FileHistory_U

CREATE TABLE `FTP_FileHistory_U` (
 `Id` int(11) unsigned NOT NULL AUTO_INCREMENT,
 `UName` varchar(12) NOT NULL,
 `FName` varchar(100) NOT NULL,
 `FSize` bigint(20) NOT NULL,
 `Address` varchar(16) NOT NULL,
 `UTime` datetime NOT NULL,
 PRIMARY KEY (`Id`)
) ENGINE=MyISAM AUTO_INCREMENT=26343 DEFAULT CHARSET=utf8 \
COMMENT='上傳檔案紀錄'

FTP_FileHistory_D

CREATE TABLE `FTP_FileHistory_D` (
 `Id` int(11) unsigned NOT NULL AUTO_INCREMENT,
 `UName` varchar(12) NOT NULL,
 `FName` varchar(100) NOT NULL,
 `FSize` bigint(20) NOT NULL,
 `Address` varchar(16) NOT NULL,
 `DTime` datetime NOT NULL,
 PRIMARY KEY (`Id`)
) ENGINE=MyISAM AUTO_INCREMENT=141273 DEFAULT CHARSET=utf8 \
COMMENT='下載檔案資料'

當然這些 Tables 還得配合 Proftpd 的設定檔才能 work，至於更細節的部份，等下次再補上。畢竟這套東西，畢業後我應該也會帶走，屆時再來寫個更完整的文件，現在就當作是草案記錄吧！

WordPress Template 修改目標

目前先排除掉 WordPress 升級的問題，只優先考量 Template 修改的問題，目前有幾個點是需要自己去改進的。

1. 字型放大
   
2. Recent Post 的 offset
   
3. Latest Post 的篇數
4. Home 的版型微調

除了 1 是 CSS 的問題之外，其他都要動到 PHP。原來想做點比較結構化的東西，但為了效率就先求有再求精吧！一切的一切都是希望螺絲起子能夠夠好阿。