Not too helpful, but the Windows event viewer (Application log) will show
when a connection as SYS is being made and from which workstation.
--
Terry Dykstra
Canadian Forest Oil Ltd.
"DA Morgan" <damorgan_at_x.washington.edu> wrote in message
news:1099151037.145035_at_yasure...
> Pete Finnigan wrote:
>
> > Hi Daniel,
> >
> > I can think of one way, which is not particularly practical. You could
> > sniff the network traffic to the server and extract the SQL, DDL and
> > connections to and from it. To do so you would need to sit directly in
> > front of the server hosting the database. You would need to extract the
> > time, user and the SQL from the packets and ideally store them in
> > another database for querying. You could use a packet sniffer or
> > possibly SQL*Net trace on the server.
> >
> > Don't forget about SQL*net logs and the listener log to get connections.
> >
> > There are commercial products available that already do this. I don't
> > know the licence costs of them. There is Chakra from OR Solutions,
> > Guardium SQL Guard from Guardium, Entregra for Oracle from Lumigent,
> > Zeus Extensible Traffic Manager from Zeus technology and also Integrigy
> > and Application security Inc are both about to release IDS / firewall
> > type products which slightly less fill the bill. There are links to all
> > of these on my tools page in the commercial section - see
> > http://www.petefinnigan.com/tools.htm
> >
> > A possible other way would be to poll the SGA and extract the SQL, but
> > this method could "lose" SQL if you do not poll fast enough and also
> > would hurt the database. It is possible to do the same by reading the
> > SGA directly with C programs. Writing a program to just extract SQL
> > would not be that difficult. There are commercial tuning products that
> > do this (access the SGA directly) but whether you can stream the SQL out
> > of them or not, i am not sure. There are some papers on direct SGA
> > access on my site at http://www.petefinnigan.com/other.htm - I also
> > talked about the same in my Oracle security web log recently -
> > see http://www.petefinnigan.com/weblog/entries/index.htm
> >
> > hope this helps a bit,
> >
> > kind regards
> >
> > Pete
>
> Thanks. Given the age of the O/S and the database I doubt I'll find any
> OTC programs but I'll look.
>
> I am currently pursuing a strategy that looks at v_$sqlarea. It may not
> catch everything ... but much like a nuclear deterent strategy ... it is
> scary enough to deter anyone from trying to do something as they would
> never know whether they would be caught. Then output results to a table
> and use some form of obfuscation to make it impossible to know which
> rows in the table to delete if one wished to cover one's tracks.
> --
> Daniel A. Morgan
> University of Washington
> damorgan_at_x.washington.edu
> (replace 'x' with 'u' to respond)
Received on Mon Nov 01 2004 - 09:53:20 CST
