10 Replies Latest reply: Dec 10, 2012 2:45 PM by Osama_Mustafa RSS

    security via IP address ... or suggestions?

    handlehandle
      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
          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?
            handlehandle
            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
              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?
                handlehandle
                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
                  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
                    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?
                      JustinCave
                      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
                        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?
                          handlehandle
                          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
                            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