保護開源資料庫:GreenSQL可助一臂之力

　　該產品是開源產品，目的也是僅僅保護開源的資料庫系統MYSQL和PostgreSQL免遭SQL injection攻擊。系統工作在Proxy模式。可以運行於多個Linux發行套件以及FreeBSD之上。對於PostgreSQL而言GreenSQL也是僅有的保護方案。對於SQL Injection不懂的可以Google一下，現在非常流行，我們隔三差五會聽到，某某公司泄露了多少多少的客戶信息，其中就有SQL Injection的功勞。而且最近剛剛出了一個書，專門寫SQL Injection。我托同事從美國買了一本回來，啃了兩天，就這麼一個東西絮絮叨叨寫了4，500頁，真是暈菜。不過我還是佩服老美的鑽研精神，寫的很細緻。

　　GreenSQL迄今還是活躍的，最新的版本1.2是09年12月剛release的版本。看了幾個版本的release notes，feature沒有什麼變化，基本都是可用性的修改，redesign，bug fix等等。

　　下圖為網路部署圖。

　　該產品可以運行於下述模式：

　　1.Simulation Mode (database IDS)

　　是Silent模式，類似於IDS系統，僅僅對於可疑事件進行Log。

　　2.Blocking Suspicious Commands (database IPS)

　　類似於IPS系統，GreenSQL將利用其“啟髮式”引擎檢測以及阻塞非法的查詢。其阻塞的Action同IPS看起來很不同，不是中斷連接，而是僅僅返回空的結果集，這樣用戶無法察覺其存在，行為也更加graceful。

　　3.Learning mode

　　在該模式下，GreenSQL學習查詢信息，並自動加入到白名單（筆者註：這個過程應該是離線的，否則沒有意義了）。在learn了足夠多的東西后，可以將系統配置為下面的模式4.

　　4.Active protection from unknown queries (db firewall)

　　利用從模式3學到的白名單作為基礎，採用“啟髮式”（這個詞聽得我耳朵都磨出繭子了，大家都說自己的引擎是啟髮式的）引擎，進行下一步的DB IPS的工作。

　　其引擎基本實現如下：

　　1.模式匹配

　　GreenSQL uses a pattern matching engine to find commands that are considered “illegal”. In essence, this is a signature-based subsystem. For example, the following commands are considered “illegal”: database administrative commands; commands that try to change a db structure; and commands used to access system files.

　　2.根據幾個的因素，計算Risk

　　GreenSQL calculates each query’s risk. Essentially, this is an anomaly detection subsystem. After the risk is calculated, GreenSQL can block the query or just create a warning message (this depends on the application mode). There are a number of heuristics GreenSQL uses when calculating risk. For example, query risk is increased by:

　　* Access to sensitive tables (users, accounts, credit information)
* Comments inside SQL commands
* An empty password string
* An ‘or’ token inside a query
* An SQL expression that always returns true (SQL tautology)

　　In order to find anomalies, GreenSQL uses its own SQL language lexer to find SQL tokens.

　　最後看看管理Web界面，先不說功能如何，我的感受是心中充滿陽光，項目的發起人審美觀念非常好：

　　現在SQL Injection的防範已經是WAF的基本配置了，為什麼會有這個東東專門防範SQL Injection。筆者認為原因如下：（本想畫一張圖給大家看看，但是太晚了，我又是急性子，發了再睡覺）：

　　1.Web Server位於HTTP層

　　2.後面的App server位於App層

　　3.後面的DB Server位於SQL層

　　1的層次最低，2的層次最高，3的層次勉強可以說比1高一點點，比3第一點點。因此要想徹底根除SQL Injection要在3保證保證應用層程序員的code沒有問題，才能完全保證SQL Injection的消失，但這不可能。在1防範可能不很精確，在3能可以從某個程度說是一個很好的補充，當然也無法完全解決問題，畢竟還低那麼一點點。是不是有點唐僧啊。

　　總之累了該回家了，一家之言，敬請拍磚。