2 |
Oracle Security / Oracle Auditing / Auditing/Reporting DBA Actions |
Nov 28th, 2014, 3:53pm |
Started by Pete Finnigan | Last post by Pete Finnigan |
Hi, I wonder if anyone can give me some advice here. Apologies as this is quite long. This is on Windows platform 2008 R2 64 bit and 10g/11g databases running Enterprise Edition 64bit I have set up auditing on one of our databases as per compliance requirement. I am auditing sys operations which are written to the Event Log on the Windows server. I have a filter log set up filtering on Event ID 34 in Windows Unfortunately there appears to be a lot of messages regarding backups. I'm trying to create a process so that it would be easy to spot sysdba logins and actions. Loads of messages about internal commands relating to what Datapump is doing does not seem helpful to me. I just ran an rman crosscheck, report obsolete, delete obsolete and a few other clean up commands. This has caused around 100 records to be written to the event log. I have set up a test database to audit out to XML to see if this is any better. Trying to filter out results, everything done by SYSDBA comes in with an ACTION of 0 (UNKNOWN) Why is this? Code:Alter database backup controlfile to trace as normal user is recorded as Action 35 (ALTER DATABASE) |
| Code:Alter database backup controlfile to trace as SYSDBA is recorded as Action 0 (UNKNOWN) |
| I presume something like Audit Vault would give some nice clear reports about what is going on but there is no appetite to spend any more money on tools at the moment. Does anyone know how to make auditing SYSDBA events manageable? Thanks Phil |
Reply | Quote | Notify of replies
|
3 |
Oracle Security / Oracle Auditing / Re: Query Rewrite not working with FGA |
Jul 23rd, 2014, 9:51am |
Started by Pete Finnigan | Last post by Pete Finnigan |
Thanks for your posts Phil, I was not aware of this bug. I have used FGA with a number of clients on some very big systems and also a small system but not on a data warehouse. The problem with standard audit and sql capture is that its not row level but at the statement level. Also the performance impact is bigger when SQL is captured and also its global for all audit and cannot be targetted onto just the statements that you need. Did you test whether you could create a view over the access and then add FGA to the view not the base table? There is a risk that direct access to the base table would bypass the audit but you could create RBAC to prevent this access. Its not ideal but combined with standard audit on the base table perhaps without SQL capture which would then have less performance impact. A more convoluted approach; maybe you could convert the table to make the important data an object and then the type body could write the audit for you; in this way you can achieve FGA without FGA. cheers Pete |
Reply | Quote | Notify of replies
|
4 |
Security In General / Security / Re: Searching for hash method used |
Jul 2nd, 2014, 10:55am |
Started by Pete Finnigan | Last post by Pete Finnigan |
Hi Ivan, Sorry for the late reply; things are very busy for me and I was just told by someone some unanswered posts are on my forum. There is little to go on except that it could be base64 but it decodes to binary. I would look at things like length to see if its a standard length for a known algorithm, or change your password 4 or 5 times and compare the hashes but change your password by one character if you can, so set it to "a" and then "b" or if length is enforced then "passworda" "passwordb"... and see if there is a noticable change in the hash or its completely random. If you can see a pattern its almost certainly not a hash and almost certainly no salt. If its random then it could very well be a hash but if its a salted hash then you would not have the salt (maybe its your username!). If so try an online hash site for common algorithms and try hashing your password to see if you can generate the same value. hth Pete |
Reply | Quote | Notify of replies
|
5 |
Oracle Security / Oracle Security tools / Re: McAfee products |
Jul 2nd, 2014, 10:49am |
Started by Pete Finnigan | Last post by Pete Finnigan |
Hi, Its a late response, sorry. VP should only be considered really as a stop gap not a permanent solution to not patching. The problem with VP is that the products tend to block remote attacks only and not local attacks and the actual VP technology does not solve other database security issues such as weak passwords, bad privilege design on data etc. A VP product is fine as a belt and braces and I am sure all tghe vendors would agree with me. You cannot replace patching for a long period with these products hth Pete |
Reply | Quote | Notify of replies
|
6 |
Oracle Security / Oracle Security / Re: How about a Hack Attack platform? |
Nov 11th, 2013, 1:08pm |
Started by Pete Finnigan | Last post by Pete Finnigan |
Hi Marcel-Jan, Its a good idea but would need to be done right. The best approach would be to build a virtual box vm with perhaps XE on it and use that as the "host" to the study. I would be happy to host it here on my site as a free download and also partner in terms of structuring whats in it, lessons, tools, how to secure etc / creating it. It could be simply a curriculum I guess with detailed installation instructions on build, setup, exploits etc. let me know your thoughts Cheers Pete |
Reply | Quote | Notify of replies
|
8 |
Oracle Security / Oracle Security / Re: Default passwords |
Apr 30th, 2013, 10:47am |
Started by Pete Finnigan | Last post by Pete Finnigan |
Before discussing about active / inactive user accounts there is a "Enforcing Password Complexity Verification" rule that defines criterias a password have to fulfill at the time is set. This is not only internally DBA but you will see it everywhere, in OS or other databases. Before discussing about account status the password is breaking the rules. If there is some way attackers can get use of such account (i.e. because locking mechanisms not consistently checked internally but only at logon-time or because bugs/ or way to overpass protections) the accounts will be exposed just because someone ignored this minimal rule at the time of setting that account (password). This is covered by the old NIST CVE-2007-6260 and the advice was to change the default passwords not matter the context or when are set; even the accounts are locked, expired at the end of instance creation; DBCA was changed a bit in 10g but as mentioned in http://www.securityfocus.com/archive/1/483652 there is a timeframe the instance is vulnerable (could be enough for a trojan like attack) and the same, there is possible that accidentally unlocking to expose on issues. On the other hand, attacks which only require a existing valid account, not matter if active or not (in DoS) could experiment such accounts too. Please note that there is no warning back to DBA about the complexity of the password when a DBA is unlocking user accounts and theoretically there are no clues about the fact that for i.e. user apps_002 is having password identical with user name (because of privacy) so a DBA is simple unlocking the user not being aware about the fact it is opening the DB for intruders. Regards, Paul B. |
Reply | Quote | Notify of replies
|
9 |
Security In General / Security / Re: Introduction into Cryptography course |
Nov 10th, 2012, 10:43pm |
Started by Pete Finnigan | Last post by Pete Finnigan |
Forgot to tell: I did it. I managed to score 70% percent of the problem sets (average) and the exam of Cryptography I and got a statement of accomplishment. It was a time intensive course, but it already is paying off. In insight that is. When I have to configure certificates for a site, I actually know what's under the cover. I'm going to do Cryptography II as well (in january). It will cover certificates more thoroughly, amongst others. Oh by the way, you can do Cryptography I every couple of months. A new course started november 5th. |
Reply | Quote | Notify of replies
|
Return to the board index.
|