Is allowing unauthenticated RPC calls okay for servers behind a corporate firewall?

Question

Our distributes application uses Microsoft RPC for interprocess communications. Starting with Windows XP SP2 and Windows 2003 SP1 Microsoft tightened the bolts so now the programs on two different computers can't communicate that easily.

Either they both must be running under suitable user accounts so that uathentication succeeds or the RPC server must "open the hole" by calling RpcServerRegisterIf2() with RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag to allow unathenticated calls as prior to the "tightening" change.

How safe is the second option? Will it really compromise the computer which is behind a corporate firewall?

Asking this here because it's a program design problem, not setup problem.

Answer 1

Not safe at all. Yes, it will really compromise the computer.

People who assume that attacks or malicious behaviour can only come from outside "the corporate firewall" will eventually be very disappointed :-)

I would never delegate the responsibility for securing my systems or applications to a party outside of my control. That's just asking for trouble.

I see this in the same area as people asking why they need constraints in their databases if their applications will always follow the rules, not realising that all it takes is some rogue with a JDBC driver and JRE, or even a buggy release of your application, to bring down the whole house of cards.

I would have thought that, in a corporate environment, all users would be centrally maintained anyway (e.g., AD) so that the issue with authentication would be minimal.