I think you should read the oracle documentation I posted pointing out how oracle functions before you make assumptions about what we are doing (http://docs.oracle.com/cd/B28359_01/network.111/b28316/concepts.htm). We aren't using oracle by choice, it is bundled inside a vendor's application and configured as they need it configured. Hardware is based on their specs. Software is configured based on their specs to maintain support. We are blocking the ports at the network level using a firewall. We are also blocking the ports at a local level using hosts.allow and hosts.deny. You don't NEED to use a firewall process to block things. Tcpd reads hosts.allow/hosts.deny every time a connection comes in and determines whether or not a host is allowed, and also what services are allowed from that host.

Right, we'll tell them and get told "hey, thanks, but Deutsch telekom doesn't want to change, so we're not implementing it." We've tried. We aren't their largest customer by a longshot, and so long as they are providing critical infrastructure for several governments, they're going to move to change things at glacial speeds.

Or they are apps that have been around for 20+ years on solaris, predating stuff like SElinux. They've updated somewhat frequently, but a lot of core technology hasn't changed. Also, the move from unix to linux introduces some interesting issues that show linux's relative immaturity in comparison. For example, linux doesn't handle network multihoming very well in comparison. You can only stipulate a single default gateway normally - you have to set up a workaround by adding additional routing tables, bind each to an interface, create rule and route files, etc, which to my knowledge don't play nice with a number of linux security features. IPTables is notorious for having issues with multihomed linux servers. Point is, saying "you aren't using a firewall and that is wrong!" is a blanket statement that has many exceptions for different situations.

Correct - for all of our telephony servers KSH is set to the default (some weird carry over from the way the vendor software reconfigures linux to act more like earlier solaris did). So, whenever users log in, they're using ksh. Usually folks use their own accounts thanks to centralized auth or they get nastygrams.

FYI, I looked at the 11g docs and you are correct, the default is now to use a shared instance. We are still using dedicated instances on our end. Section 3.4 covers it here: http://docs.oracle.com/cd/B283...

FYI, it depends if you're using a shared or dedicated server process. Shared uses a single interface, dedicated creates a new instance. We use dedicated in our environment. Check section 3.4.2 per the 11g docs: http://docs.oracle.com/cd/B283...

This applies to all oracle installations, and from training, this is still the default (at least as late as 11g, I haven't tried 12 yet - again, that is per oracle training). We're running oracle grid with dataguard (4 separate 2-node clusters with failover sites) on RHEL5. It functions the exact same way. Shared socket works so long as you don't mind the bottleneck it creates. It's far easier to remove iptables from the picture, let oracle function as it is supposed to. Any sort of access control can be handled by using hosts.allow/hosts.deny and letting tcpd handle it instead of having a whole extra process in the picture.

Also, hosts.deny all:all and then adding the hosts you want to allow in hosts.allow works just as well as a firewall, without having an extra process running on your systems.

We're using Oracle Grid Infrastructure/Data guard on linux. Windows firewall doesn't apply.

Reread the other comments - if you are in a situation where you have millions of users on a vendor-supported platform, you meet whatever requirements the vendor requires to continue receiving support as stipulated in their contract. If they say no application firewalls because they interfere with their application's functionality, it's not incompetence, it's a hoop you jump through to continue receiving support under your contract. Or, you get to explain why the vendor won't take the operations guys' calls at 4am in the morning when you've got 2 million customers without service.

For us, we control everything else using both hard firewalls and ACLs. Everything in those subnets purposefully needs to be able to talk to everything else. Plus, as mentioned elsewhere, we're beholden to the vendor whose application is running on those boxes, and their config requires iptables and selinux to be disabled on individual hosts. So, we control everything with network equipment above them. I think the only thing we are using IPTABLES for is mangling dscp markings.

Yup, this is our case. There's also a common misconception that with oracle you can just open port 1521 and everything works, but per oracle, that's only part of it. SQL*NET is weird software.

The actual training did "get into" why it works that way. See the above referenced article explaining how SQL*NET works. 1521 doesn't handle the actual sql query, it forks a new oracle process for that particular request which has a new socket associated with it.

FYI, oracle requires ports from 1024-65535 to be open for any client. 1521 is only used for initial setup dialog. This also forks a new oracle process, which gets its own socket. Afterwards, as stated above, this information is sent back to the client which reconnects on the new socket. This oracle doc explains what I am talking about: https://asktom.oracle.com/pls/...

I disagree. When we have 15 million customers on a 3rd party's platform, we can't suddenly turn around to that vendor and say "yeah, no, you're using SELinux no matter what." We either build things to their spec, or we lose support. Their spec stipulates disabling SELinux and iptables, so they get disabled. Case closed. So, while I agree in principle, I have to disagree that it's always possible.