Re: FAILED_LOGIN _ATTEMPTS issue

On czw, 2008-12-11 at 09:04 -0800, Jared Still wrote:
>
> On Thu, Dec 11, 2008 at 5:55 AM, Remigiusz Sokolowski
> <remigiusz.sokolowski_at_nordea.com> wrote:
> hi,
>
> I wonder how do You deal with FAILED_LOGIN _ATTEMPTS issue in
> a day to
> day practice.
> This part of profile is thought of as a countermeasure against
> "brute
> force" attacks on password, however dark side of it is a
> blocking an
> account.
>
> You can use a profile to limit the number of attempts that may be
> made against a single account.
>
> http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_6010.htm#i2065930
>
> The failed_login_attempts parameter can be used to lock the account
> after N consecutive failed login attempts.
>
> The password_lock_time parameter can be used to lock the account
> for N days after the failed login attempts threshold is reached, where
> N
> can be a fraction of a day.
>
> eg. a value of 0.0104 would lock the account for approximately 15
> minutes.

certainly - but it means locking of an account anyway (even though for a short time).
>
>
> The "ideal" solution to this issue would be to allow a client
> identified
> by IP to connect with for example only its own account or few
> chosen
> accounts.
> Any thoughts?
>
> If the connections are made through an application server, using
> tcp.validnode_checking
> to specify which clients may connect may be feasible.

Those are direct connections to a database - that is a problem
>
> If there's a large number of clients that connect directly to the
> database, this
> would probably be rather unwieldy.

I think if the connection manager is able filter traffic based on IP, it could do that based on a schema to which one wants to connect.

Possible solution to my problem could be another db instance with accounts, which would connect to a production database by db links (without possibility to create new ones or to modify) and all connections beside those from this intermediate instance cut off according to IP.
But I dream about something lighter (without db link costs)
>
> There's probably other options available if you check into the
> Advanced
> Security Option. Personally, I have no experience with that.

And is this possible to allow connection only to one/few schemas with that option? I know only about secure connections based on TCPS and certificates, but this do not disable requests to "illegal" schemas.

Best regards
Remigiusz

-- 
----------------------------------------------------------------------
Remigiusz Sokolowski <remigiusz.sokolowski_at_nordea.com>
pos  : DBA at DUSB
addr : Nordea Bank Polska SA, Luzycka 6A Street, 81-537 Gdynia, Poland
phone: +48 58 667 17 43


-----------------------------------------------------------------------------------------
Nordea Bank Polska S.A. z siedziba w Gdyni, ul. Kielecka 2, 81-303 Gdynia
wpisana do Rejestru Przedsiebiorców Krajowego Rejestru Sadowego pod numerem: 0000021828,
dla której dokumentacje przechowuje Sad Rejonowy Gdansk – Pólnoc w Gdansku,
VIII Wydzial Gospodarczy Krajowego Rejestru Sadowego,
o kapitale zakladowym i wplaconym w wysokosci: 227.593.500,00 zlotych,
NIP: 586-000-78-20, REGON: 190024711
-----------------------------------------------------------------------------------------
--
http://www.freelists.org/webpage/oracle-l