Awesome, thank you. Because I'm that kind of person I'll probably bodge one up on the pcb plotter today, with some available pads for adding resistors later.

The most obvious route for disaster is a compromised cellphone charger, at least for my usage patterns. Since it'd take me about ten minutes to make a pez-candy-sized PCB with USB-micro-M and USB-micro-F connectors with only the power lines connected between them, I'm wondering if an android phone will charge when it's getting power, regardless of whether the USB is connected, or it won't charge until it's had a USB chat. I recall older devices being able to charge at lower-power (150mA?) but having to negotiate for 500mA. I'm perfectly happy to settle for 150mA for right now, until I can program a little AVR to fake the negotiation process and make me an air-gap charger. I don't have a usb traffic sniffer at work, and am about to lose my pcb fabrication equipment for a couple of weeks, so if I could find out today if it's worth making the pcb I'd do it this afternoon. Anyone know?

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.

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.

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.