This discussion is archived
10 Replies Latest reply: Dec 10, 2012 12:45 PM by Osama_Mustafa RSS

security via IP address ... or suggestions?

85592 Newbie
Currently Being Moderated
We have a third party package built on top of Oracle (with forms, etc via application server).

On some occasions, particularly during application upgrades, the scripts delivered
to us have "default" oracle user passwords for the schemas involved with this
3rd-party package. So the regular course of events is to set all accounts
to the default passwords before the upgrade scripts run.

That makes life easy for the upgrade but causes a big security hole, as you might imagine.

We were thinking of limiting access via IP address for the databases in this
condition.

Is that a viable option?
Any other ideas?
  • 1. Re: security via IP address ... or suggestions?
    sb92075 Guru
    Currently Being Moderated
    es3960 wrote:
    We have a third party package built on top of Oracle (with forms, etc via application server).

    On some occasions, particularly during application upgrades, the scripts delivered
    to us have "default" oracle user passwords for the schemas involved with this
    3rd-party package. So the regular course of events is to set all accounts
    to the default passwords before the upgrade scripts run.

    That makes life easy for the upgrade but causes a big security hole, as you might imagine.

    We were thinking of limiting access via IP address for the databases in this
    condition.

    Is that a viable option?
    Any other ideas?
    use OS Authentication & no passwords are then required
  • 2. Re: security via IP address ... or suggestions?
    85592 Newbie
    Currently Being Moderated
    I'm not sure OS authentication will work,
    but it definitely is an angle I had not thought of.
  • 3. Re: security via IP address ... or suggestions?
    EdStevens Guru
    Currently Being Moderated
    es3960 wrote:
    We have a third party package built on top of Oracle (with forms, etc via application server).

    On some occasions, particularly during application upgrades, the scripts delivered
    to us have "default" oracle user passwords for the schemas involved with this
    3rd-party package. So the regular course of events is to set all accounts
    to the default passwords before the upgrade scripts run.

    That makes life easy for the upgrade but causes a big security hole, as you might imagine.

    We were thinking of limiting access via IP address for the databases in this
    condition.

    Is that a viable option?
    Any other ideas?
    SQLNET provides a very crude and ham-fisted method for filtering on IP address, but that is really not the place to do ip filtering. That really should be done at the firewall/router. Not only is that the proper place to do it, the configuration capable there is much more flexible.
  • 4. Re: security via IP address ... or suggestions?
    85592 Newbie
    Currently Being Moderated
    A complication to firewall filtering is that I have some databases on this system which
    are secure using the normal login/password security

    and others which are undergoing upgrade and have the bogus passwords in place.

    So a direct machine-to-machine firewall filter wouldn't work unless I were to use multiple
    listeners (?) Right now I use a single listener to service all of these databases.

    (but your focus on firewall/router as the proper place for IP filtering I accept
    and agree)
  • 5. Re: security via IP address ... or suggestions?
    EdStevens Guru
    Currently Being Moderated
    es3960 wrote:
    A complication to firewall filtering is that I have some databases on this system which
    are secure using the normal login/password security

    and others which are undergoing upgrade and have the bogus passwords in place.

    So a direct machine-to-machine firewall filter wouldn't work unless I were to use multiple
    listeners (?) Right now I use a single listener to service all of these databases.

    (but your focus on firewall/router as the proper place for IP filtering I accept
    and agree)
    Offhand I don't see a way to achieve this. Setting up two listeners won't help, because the tns configuration I referred to is set in sqlnet.ora, which would be read by both listeners.
  • 6. Re: security via IP address ... or suggestions?
    jgarry Guru
    Currently Being Moderated
    How big is the set of clients that will be accessing? I haven't thought it all the way through, but my first thought is to change to a different service name on the server, and temporarily reconfigure those clients. Security by obscurity, with all that implies, which may be enough. Does the app server set the login? You may want to control it there.
  • 7. Re: security via IP address ... or suggestions?
    Justin Cave Oracle ACE
    Currently Being Moderated
    Taking a step back, do you really need security? Or is auditing sufficient?

    If the vulnerability exists only during an upgrade, it would seem reasonable to assume that an external attacker is very unlikely to penetrate your network just at the moment that you're in the middle of an upgrade and use the default password to access your database. Presumably, the vulnerability is limited to internal attackers. If you simply audit connections and/or queries against sensitive tables and alert the internal users that you'll be reviewing the logs after the upgrade is complete, that should drastically reduce the probability that some internal user is going to mount an attack when they know the upgrade is underway. If they know that you'll be able to identify that someone logged in as them to their machine logged in to the database with the default password when the system was being upgraded and they've been warned that doing so can result in termination, they're going to be very, very unlikely to exploit the loophole.

    Now, obviously, the type of organization and the type of data you're protecting will determine whether this is sufficient. I'm guessing, though, that a third-party system whose upgrades depend on a hard-coded password is probably not protecting top secret information for the CIA.

    Justin
  • 8. Re: security via IP address ... or suggestions?
    jgarry Guru
    Currently Being Moderated
    My experience has been you just want to stop the regular users who are chomping at the bit to get their work done (or didn't get the memo they're not supposed to).
  • 9. Re: security via IP address ... or suggestions?
    85592 Newbie
    Currently Being Moderated
    Thanks to all for the input.

    Our upgrade can take 24-48 hours to complete.

    The data involved includes stuff that we must protect by
    corporate policy and various government regulations.

    Your comments have solidified my thinking that I will need to edit
    the upgrade scripts to use predetermined but non-default passwords.
    I have the scripts and this is something I can accomplish.

    The window of time is too big and the data is too important.
  • 10. Re: security via IP address ... or suggestions?
    Osama_Mustafa Oracle ACE
    Currently Being Moderated
    You have several Ways to do that , Guys mention here

    1-OS authentications
    2-Sqlnet.ora using
    tcp.validnode_checking = Yes
    tcp.invited_nodes = (IP, IP)
    Or
    tcp.excluded_nodes = (IP, IP)
    3-oracle connection manager
    4-If you are using Linux you can limit access by using ipfilter.
    5-You can test this by putting confuigure firewall to excluded some IP's

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points