The Database as a Networked Server - Implementing Database Security and Auditing - page 87

Traffic redirects are a big problem for firewalls. If you punch a hole in
the firewall on port 1521 and the server tries to redirect traffic, the client
will not be able to continue the communication with the server and will fail
all connection attempts. There are several ways to resolve this problem, but
first you should reevaluate whether you really need to have Oracle redirec-
tion. You probably would be better off without redirection. If you remain
with redirection and plan on using a firewall, you should choose a firewall
that supports SQL*Net/Net8/Net9 redirection—many of the large firewall
vendors do because this is a common problem. In this case the firewall will
inspect the packet payload and look for the port that the client is being told
to move to, and then will dynamically open that port for this client only.
Incidentally, if you do not have a firewall in place and are trying to protect
an Oracle environment by specifying which nodes on the network can or can-
not connect to your server, then you can use a built-in feature rather than
deploy an additional firewall. To activate this feature you can use the proto-
cols.ora file in Oracle 8i or the sqlnet.ora file in Oracle 9i and 10g. You
specify which nodes to allow or deny using the following commands:

TCP.INVITED_NODES=(<Client IP-ADDRESS 1>, <Client IP-ADDRESS 2>)
TCP.EXCLUDED_NODES=(<Client IP-ADDRESS 3>, <Client IP-ADDRESS 4>)
TCP.VALIDNODE_CHECKING=yes

3.8 Summary

In this chapter the primary focus has been on the database as a set of ser-
vices open to the network and waiting for requests that can be fulfilled. You
learned that hackers can use this fact and that attacks can be initiated
through the network by sending malformed requests to the ports on which
the server is listening. You learned that by disabling services and network
options that are not being utilized, you can limit the exposure—after all, if
you're not using these options, why leave them for the hacker? You also
learned that it is important to understand, monitor, and continuously ana-
lyze those ports, services, protocols, and options that are being used to
make sure they are not exploited through attack or misuse.
This chapter looked at the networking layer in the database. This is a
narrow viewpoint because the database is obviously far more complex than
just a listener that waits for requests, and yet even this narrow viewpoint
provides a lot of insight into protecting your database environment. In the
next chapter you will go one level deeper—into the authentication layer.
This is the layer that—once a (well-formed) connection request comes in—
decides who the request is coming from and whether it should be serviced.