資料庫防火牆的阻斷方式：行為阻斷或者Session阻斷

行為阻斷是資料庫防火牆的自然工作方式。當檢測到入侵行為的時候，阻斷該行為的操作。行為阻斷依據響應偏好的不同，可以工作在不同模式之下。

模式一：錯誤響應模式

阻斷操作之後，返回預先定義的錯誤資訊，使應用程式可以構造合理的錯誤響應。錯誤響應模式的好處在於可以讓應用程式檢測到入侵發生，並響應合理的錯誤形式給使用者和入侵者。壞處在於可能入侵者也可以感知到有安全業務邏輯在發生作用，特別是如果應用程式缺乏錯誤處理有可能會直接返回錯誤響應給入侵者。 

模式二：靜默響應模式

阻斷操作之後，返回正常的零響應資訊，包括0行資料，0行資料被影響或者成功操作的響應資訊。靜默響應模式的好處在於完全正常的業務邏輯響應可以使入侵者很難獲取相關資訊，壞處在於應用程式也無法感知入侵，只能依賴於安全裝置的執行。 

模式三：持續阻斷模式

當檢測到應該被阻斷的風險操作之後，該Session被定義為高度風險Session，所有後續的操作都被標記為高風險操作，無論其內容如何都會被阻斷。持續阻斷模式的好處在於增加了入侵者的嘗試成本，增加其沮喪感，壞處在於可能由於風險檢測引擎的誤判導致業務持續失敗。

Session阻斷相對於行為阻斷是一種很簡單的操作，中斷網路連線，阻止進一步的操作。Session阻斷的好處在於技術上實現非常簡單，壞處則會帶來眾多不可預知的影響。而且，其不可被用在資料庫防火牆中。  

絕大部分企業級應用建立在資料庫連線池技術之上。基本路徑是：業務應用程式發起資料庫操作請求，從資料庫連線池中獲得一個資料庫連線，應用程式在這個給定的資料庫連線執行業務操作，業務操作完成之後釋放這個資料庫連線到資料庫連線池。 

下面我們來分析Session阻斷的操作和影響。一般情況下，多數Session阻斷會採用向客戶端和服務端分別發Reset包的方式來實現阻斷，我們這裡不探究reset訊號的阻斷有效性，假設其總是可以快速阻斷。在此前提下我們從兩個方面來探討可能的影響： 

Session阻斷之後，會導致資料庫連線池的可用數量減少。特別是在多數情況下，資料庫連線池並不會檢測到Reset訊號，也就是說雖然網路連線已經被中斷，但是資料庫連線池並沒有意識到連線已經不可用，依然會把業務分配到這個已經中斷的資料庫連線之上，導致業務大規模錯誤。

簡單來看，入侵者可以透過簡單的可以被資料庫防火牆識別的無效攻擊來實現cc攻擊，導致業務系統不可用。為了避免這種情況，需要在資料庫連線池上增加特定錯誤檢測功能，當檢測到特定錯誤之後，關閉特定無效連結，並主動發起重新連線以保持業務程式執行。 

在大部分情況下，資料庫並不能很好的處理reset訊號，而需要依賴死程式檢測程式來處理。由於處理無法保證有效，也就是說在相當多的場景下可能會出現大量的僵死程式，消耗大量資料庫會話資源，甚至存在共享的資源沒有釋放，從而導致資料庫掛起。