Re: Trap SQL statements in network traffic instead of database

From: Tim Gorman <>
Date: Fri, 11 Aug 2017 15:38:21 -0600
Message-ID: <>


There is a company named Teleran <> 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.



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.

Received on Fri Aug 11 2017 - 23:38:21 CEST

Original text of this message