行为阻断是数据库防火墙的自然工作方式。当检测到入侵行为的时候，阻断该行为的操作。行为阻断依据响应偏好的不同，可以工作在不同模式之下。

模式一：错误响应模式

阻断操作之后，返回预先定义的错误信息，使应用程序可以构造合理的错误响应。错误响应模式的好处在于可以让应用程序检测到入侵发生，并响应合理的错误形式给用户和入侵者。坏处在于可能入侵者也可以感知到有安全业务逻辑在发生作用，特别是如果应用程序缺乏错误处理有可能会直接返回错误响应给入侵者。 

模式二：静默响应模式

阻断操作之后，返回正常的零响应信息，包括0行数据，0行数据被影响或者成功操作的响应信息。静默响应模式的好处在于完全正常的业务逻辑响应可以使入侵者很难获取相关信息，坏处在于应用程序也无法感知入侵，只能依赖于安全设备的运行。 

模式三：持续阻断模式

当检测到应该被阻断的风险操作之后，该Session被定义为高度风险Session，所有后续的操作都被标记为高风险操作，无论其内容如何都会被阻断。持续阻断模式的好处在于增加了入侵者的尝试成本，增加其沮丧感，坏处在于可能由于风险检测引擎的误判导致业务持续失败。

Session阻断相对于行为阻断是一种很简单的操作，中断网络连接，阻止进一步的操作。Session阻断的好处在于技术上实现非常简单，坏处则会带来众多不可预知的影响。而且，其不可被用在数据库防火墙中。  

绝大部分企业级应用建立在数据库连接池技术之上。基本路径是：业务应用程序发起数据库操作请求，从数据库连接池中获得一个数据库连接，应用程序在这个给定的数据库连接执行业务操作，业务操作完成之后释放这个数据库连接到数据库连接池。 

下面我们来分析Session阻断的操作和影响。一般情况下，多数Session阻断会采用向客户端和服务端分别发Reset包的方式来实现阻断，我们这里不探究reset信号的阻断有效性，假设其总是可以快速阻断。在此前提下我们从两个方面来探讨可能的影响： 

Session阻断之后，会导致数据库连接池的可用数量减少。特别是在多数情况下，数据库连接池并不会检测到Reset信号，也就是说虽然网络连接已经被中断，但是数据库连接池并没有意识到连接已经不可用，依然会把业务分配到这个已经中断的数据库连接之上，导致业务大规模错误。

简单来看，入侵者可以通过简单的可以被数据库防火墙识别的无效攻击来实现cc攻击，导致业务系统不可用。为了避免这种情况，需要在数据库连接池上增加特定错误检测功能，当检测到特定错误之后，关闭特定无效链接，并主动发起重新连接以保持业务程序运行。 

在大部分情况下，数据库并不能很好的处理reset信号，而需要依赖死进程检测程序来处理。由于处理无法保证有效，也就是说在相当多的场景下可能会出现大量的僵死进程，消耗大量数据库会话资源，甚至存在共享的资源没有释放，从而导致数据库挂起。