当ORACLE 11G 遇到 JUNIPER 防火墙

TOP 如下

 

故障现象 172.16.100.70可以使用PL/SQL登陆ORACLE 但是执行查询操作就无响应。使用SQL*PLUS可以查询。

 

撤掉防火墙改为直连，WINDOWS的IP改为 172.16.110.70/24 没有任何问题。故判断是防火墙的问题。

 

防火墙策略全开 允许UNTRUNT 到TRUNT  ANY   结果还是不行。

 

 

开始百度

 

第一个说法：需要更改windows的注册表

 

\\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEDIR （HOMEDIR是你机器上安装的oracle数据库的instance名称）中添加一个字符串键值，名称为USE_SHARED_SOCKET，值为TRUE（注意大小写），然后重启oracle instance或直接重启windows就OK了。

 

照做 不行

原文地址 http://blog.csdn.net/bisal/article/details/36424093

 

第二个说法

 

需要在监听文件后面加参数

原文地址

http://wenku.baidu.com/link?url=8-X35W7SjEuz-L7Q_Hv3E965SwEt4BbvryWiY-jE9BYeukFG5rvhWuoUtsag-Z5sgPyOPVnMIOwKb3tFzqq_IGmpnrwZYeL9rqSr8LDVRva

 

这个是描述ORALCE 11G以前的版本。我通过在ORALCE 主机上事实监控端口发现全部都是从1521端口出去，并且结合网上的一些帖子。判断在ORACLE 11G在linux上是不存在端口随机的问题。

 

第三个说法，PL/SQL 客户端的安装方式比较特殊需要特殊的步骤原文地址如下

http://www.cnblogs.com/gulvzhe/archive/2012/08/27/2658657.html

还是不行。

 

网上搜索到类似的问题

 

http://www.itpub.net/forum.php?mod=viewthread&tid=1757430&extra=&highlight=&page=1类似的问题但是没有给出解决办法。

 

http://zhidao.baidu.com/link?url=bklnlNgKPzMAx5-4C0je8Tz8nWIqiNbJNl0gUvQDC6qKUCO4VPIlXj7faNaour9OeCsYAt4osHPsMHweSatQmq 这个问题一模一样但是还是没有解决办法。

 

 

自能自行研究。

 

Windows 服务器启用双网卡，去掉防火墙。一张网卡172.16.100.70/24  另一张网卡172.16.110.70/24 直连ORALCE 数据库。

 

然后使用端口映射软件 把172.16.100.70 的1521映射到172.16.110.102的1521端口

 

配置

Tnsnames.ora 文件

 

 

使用PL/SQL 连接本机的IP地址 登陆查询一切正常。

 

由此判断 问题不是出在跨网段等问题，当使用端口映射的时候，本机就相当于一台防火墙了。 自此认为问题还是处在防火墙上。

 

打开防火墙的各个选项。

 

首先关闭防火墙的各个安全扫描

 

全部去掉，还是不行。

 

 

仔细查看系统定义的关于数据库的服务

 

 把系统自带的超时选项改为永不超时。继续测试。貌似使用SQL*PLUS 查询的速度变快了，但是PL/SQL依然查询不了。

 

随着一个个的选项点卡，ALG 安全应用网关引起了注意，网上查询关于ALG的说明，说是可以自动匹配相应的协议，比如ORLAC 默认开放1521端口，当开启ALG服务的时候，防火墙会自动识别

除1521以外的端口。理论来说更容易ORACLE 数据通过。 先不管直接取消。

 

 

结果是PL/SQL 可以正常登陆和查询数据了。

 

 

 

原因分析，当启用SQL的时候，SSG防火墙会深入检测数据包！结果连接的地址是172.16.110.102 返回的包有可能是172.16.110.101 或者172.16.110.111 两个地址。

防火墙会认为这个地址在伪造IP包 并进行攻击下面是复制的一个LOG。

2014-11-04 18:01:39   system  alert  00008  IP spoofing! From 172.16.110.70 to 172.16.110.102, proto 1 (zone Untrust, int redundant1.10). Occurred 1 times.

 

这是我认为的一个原因 关于ALG的详细解释

 

 

从官方的说明书上查找

 

通常情况下，网络转发设备 ( 如路由器或交换机) 并不重组其所收到的封包碎片。

通常，目标主机会在所有封包碎片到达后对它们进行重新构建。转发设备的主要功

能是有效地传递信息流。如果转发设备也需要将所有数据包排队、重组和重新分

段，则其效率将会受到不利影响。但是，将封包碎片传递通过防火墙是不安全的。

攻击者可以故意打碎封包，以隐藏防火墙将有可能检测到和封锁的信息流串。

ScreenOS 允许按照区段启用碎片重组。这样一来，安全设备便可扩大其检测和封

锁恶意 URL 串的功能。仅当设备被配置为 NAT 时，碎片重组才会发生在启用了应

用程序层网关 (ALG) 的信息流中。

 

 

ScreenOS 为很多协议提供了应用程序层网关 (ALG)，如 DNS、FTP、H.323 和

HTTP 协议。在这些协议中，碎片重组可以是实施包括 FTP 和 HTTP 服务的策略中

的重要部分。Juniper Networks 防火墙为 FTP-Get 和 FTP-Put 等协议筛选封包的能

力，要求其不仅检查封包包头，而且检查负载中的数据。

 

 

大概意思了解了 在NAT 模式下 数据包在防火墙层面重组成完整的数据，并由防火墙检测数据的安全性，如果不安全则丢弃，安全就转发完整的数据。

 

而我的防火墙是工作在ROUTER模式下。

 

 

为了验证一下 我把防火墙切换到NAT模式并且打开SQL。

结果依旧是可以登陆不能查询数据。

 

 

 

从以上得出的结论是，不管工作在那个模式下，一旦开启SQL 的ALG检测。 防火墙都会对数据包进行了重组或者修改。而PL/SQL对数据包要求可能比较严谨。导致PL/SQL 获得不了自己需要的数据而陷入

停止响应。而SQL*PLUS 对数据包要求的不那么严谨。防火墙转发过来的数据照单全收。   这也是为什么通过防火墙之后感觉SQL*PLUS 查表的时候感觉速度比较慢的原因。

 

为了再次验证，我开启ALG应用网关的SQL选项 我换用另外一个简单的ORACLE 客户端 SQL HANDLER   进行登陆查询。OK 一切木有问题。而使用PL/SQL查询就没有响应。

 

 

结论

是防火墙重组了数据包而PL/SQL 不认重组的数据包。