1
Oracle® Exadata Storage Server X5-2 Extreme Flash Installation Guide.pdf
100墨值下载
10/17/2018 文档 2186415.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=12pxkde3ey_72&id=2186415.1 1/5
版权所有 (c) 2018，Oracle。保留所有权利。Oracle 机密。
What To Check When The Audit Vault And Database Firewall Does Not Capture Traffic (文档 ID
2186415.1)
In this Document
Goal
Solution
References
APPLIES TO:
Oracle Audit Vault and Database Firewall - Version 12.2.0.2 and later
Information in this document applies to any platform.
GOAL
This note is meant to provide a step by step guide to identify possible causes when the sql traffic generated by a
monitored secured target is not being logged by the Database Firewall.
SOLUTION
1) Check that the service_name and the port from Secured Target Addresses list are correctly reflecting the
database service_name and the listener port:
Furthermore check that the PROTECTED_ADDRESSES parameter in appliance.conf file of that Enforcement Point
includes all the details of the secured target correctly. The appliance.conf file is located on the Database Firewall at
/var/dbfw/va/<EP#>/etc, where <EP #> is the number of the Enforcement Point.
2) Check that the enforcement point is up and running
10/17/2018 文档 2186415.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=12pxkde3ey_72&id=2186415.1 2/5
3) Confirm that the traffic generated on the secured target is gets to the Database Firewall. For that we must peek
at the network interface that is being used by the enforcement point with one of the following methods:
a) Using tcpdump:
#tcpdump -i <eth0>|grep <ip_of_the_database> | grep <ip_of_the_client_connecting_to_the_database>
[root@dbfw0039f6904728 ~]# tcpdump -i eth0|grep "10.171.32.120"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:10:27.316730 IP 10.171.32.120.32723 >
management_interface.oracle_database_firewall_internal.livelan: Flags [P.], seq
4271588316:4271588614, ack 3152656695, win 405, length 298
09:10:27.316780 IP management_interface.oracle_database_firewall_internal.livelan >
10.171.32.120.32723: Flags [.], ack 298, win 141, length 0
09:10:27.318423 IP management_interface.oracle_database_firewall_internal.33204 >
10.171.32.120.cichild-lm: Flags [P.], seq 507493789:507494087, ack 4174470361, win 165, length 298
09:10:27.531230 IP 10.171.32.120.cichild-lm >
management_interface.oracle_database_firewall_internal.33204: Flags [P.], seq 1:458, ack 298, win
282, length 457
09:10:27.531293 IP management_interface.oracle_database_firewall_internal.33204 >
10.171.32.120.cichild-lm: Flags [.], ack 458, win 164, length 0
09:10:27.531427 IP management_interface.oracle_database_firewall_internal.livelan >
10.171.32.120.32723: Flags [P.], seq 1:458, ack 298, win 141, length 457
09:10:27.719307 IP 10.171.32.120.32723 >
management_interface.oracle_database_firewall_internal.livelan: Flags [.], ack 458, win 428, length
0
09:10:27.719882 IP 10.171.32.120.32723 >
management_interface.oracle_database_firewall_internal.livelan: Flags [P.], seq 298:319, ack 458,
win 428, length 21
09:10:27.719922 IP management_interface.oracle_database_firewall_internal.livelan >
10.171.32.120.32723: Flags [.], ack 319, win 141, length 0
If the Database Firewall is configured in-line one has to check that bridge interface is up and running:
#ifconfig
#brctl show br<n>
If the Database Firewall is configured in DAM mode one has to run the tcpdump against the Database Firewall
network interface where the cable from the spanning port (mirror port) is plugged:
of 5
100墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论