Re: Trap SQL statements in network traffic instead of database

  • From: Tim Gorman <tim.evdbt@xxxxxxxxx>
  • To: sbecker6925@xxxxxxxxx, oracle-l <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 11 Aug 2017 15:38:21 -0600

Sandra,

There is a company named Teleran <http://www.teleran.com/> which does exactly what you're discussing. Gathering Oracle and other database traffic from the network (product called "iSight"), storing it in a database for analysis/reporting (product called "iSight Analytics"), and then also trapping and blocking/altering database traffic for security (product called "iGuard").

The idea is to have a centralized Teleran server residing in your data center, with Teleran agents on each database server tapping into the network stream, sending captured SQL (and optional return data) to a centralized Teleran analytics server.

Full disclosure: I have never worked for Teleran and have no financial ties or investments, but I have configured their products for mutual customers and I have contracted for them. I also consider them friends.

Thanks!

-Tim


On 8/11/17 14:43, Sandra Becker wrote:

We need to produce a "log" of sql statements--along with the user, IP (or host) they are coming from, and the sql statement--for another team to analyze. My manager does not want to user auditing because of the uncertainty of the load on this critical database. He suggested doing a SPAM port capture. I opened a ticket with our SAs and they wanted to know what ports. I gave them the listener ports. The SA ran a tcpdump (said it was verbose), but it didn't give any information on users, app servers, or sql statements. I really don't know what I'm doing here, just passing information between my manager and SAs. So, questions:

1. Will tcpdump give me what my manager is asking for? If yes, what are the options the SA should use?0
2. Is there a better way to retrieve this information without using database auditing?

Any assistance you can provide will be greatly appreciated.

--
Sandy B.


Other related posts: