Sadly that's not going to happen until people put more priority on other people than they do on invisible lines that old dead people drew that really have no purpose other than making us hate each other.
Really, that's all they need to do to secure funding. "We have reliable intelligence saying that somewhere, some how, space terrorists will act terroristly."
People don't understand how important GPS is these days. Loran has been more or less shuttered, so there's no real backup. The part that really scares me is that oil rigs are held stationary by massive rotors. Those rotors are controlled by GPS. If they lose signal, imagine every oil rig on earth suddenly snapping off the top of the oil pipelines that are below them. Imagine hundreds of deepwater horizon style events across the entire world.
I'm not a fan of that thinking. A military space race will essentially lead to a new cold war. The last one wasn't very fun. Scientific progress doesn't get the praise it deserves when half the world thinks it will lead to their imminent destruction. Hell, Sputnik had kids hiding under school desks when they should have been celebrating a landmark for our species.
No, a firewall is an application, a process that brokers all incoming and outgoing communications and maintains a state table of those inbound and outbound connections. The key there is that it maintains a state table. TCPd is a shim process that acts between inetd and the actual application. It is not a firewall. It doesn't drop packets. It doesn't maintain a state table, so it can't, for instance, handle reflexive policies or tell whether or not a dialog has been established. It does handle access control for applications based on IP. However, there's a difference between a firewall saying "you aren't on my allowed hosts list, DROP" and inetd saying "packets accepted, looks like you want to launch application X, tcpd, is that cool? No? ok, sorry, not allowed. SIGTERM." In the end you get similar results, but they're significantly different processes.
This is why I strongly disagree with the idea that firewalls are always needed. They're just another tool, and there are other tools that do similar things.
That I will certainly give you:) And we do have some workarounds - namely using hosts.allow and hosts.deny. It still functions essentially the same as a firewall, but it doesn't require the additional process that interferes with their software.
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.
Given the vendor supports infrastructure for several national governments, I don't think they're likely to change very quickly. I actually just checked the vendor's website - as of release 20, they now support SElinux in permissive mode. Still not supported on enforcing mode.
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.
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.
After 4 weeks of oracle training, the advice from the oracle trainer was that oracle simply doesn't play well with firewalls. I'm not a DBA (thankfully), but that's from their actual instruction.
Slashdot Mirror
Sadly that's not going to happen until people put more priority on other people than they do on invisible lines that old dead people drew that really have no purpose other than making us hate each other.
Really, that's all they need to do to secure funding. "We have reliable intelligence saying that somewhere, some how, space terrorists will act terroristly."
What about my welcome?
People don't understand how important GPS is these days. Loran has been more or less shuttered, so there's no real backup. The part that really scares me is that oil rigs are held stationary by massive rotors. Those rotors are controlled by GPS. If they lose signal, imagine every oil rig on earth suddenly snapping off the top of the oil pipelines that are below them. Imagine hundreds of deepwater horizon style events across the entire world.
I'm not a fan of that thinking. A military space race will essentially lead to a new cold war. The last one wasn't very fun. Scientific progress doesn't get the praise it deserves when half the world thinks it will lead to their imminent destruction. Hell, Sputnik had kids hiding under school desks when they should have been celebrating a landmark for our species.
I always wondered about this. How do they define outer space? Above N miles? Outside of the Earth's gravitational pull?
Wave motion gun, obviously.
This is why I strongly disagree with the idea that firewalls are always needed. They're just another tool, and there are other tools that do similar things.
That I will certainly give you :) And we do have some workarounds - namely using hosts.allow and hosts.deny. It still functions essentially the same as a firewall, but it doesn't require the additional process that interferes with their software.
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.
Given the vendor supports infrastructure for several national governments, I don't think they're likely to change very quickly. I actually just checked the vendor's website - as of release 20, they now support SElinux in permissive mode. Still not supported on enforcing mode.
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.
After 4 weeks of oracle training, the advice from the oracle trainer was that oracle simply doesn't play well with firewalls. I'm not a DBA (thankfully), but that's from their actual instruction.