BITS & BOLTS
Insecure RPCs can leave you wide open. Take steps to protect your network.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Remote Procedure Calls (RPCs) are at the heart of client/server computing, from Windows to *nix, allowing networked devices to seamlessly call services and components from one another. They're also the source of numerous vulnerabilities and exploits.
RPC is ubiquitous, and that's the dilemma: You can't simply turn it off. That said, you're not without security options. RPC isn't inherently insecure: Developers can write secure code using RPC, and there are alternatives. You can defend your networks against known RPC exploits.
Since almost every system runs RPC services, it's an obvious target.
RPC reduces the complexity of network programming by handling communication over UDP. The programmer writes client/server code with identical parameters and leaves the networking to the protocol, allowing the protocol to span multiple OSes and networks.
Most RPC vulnerabilities are simply the result of sloppy coding. Poor error-checking leaves an app open to buffer-overflow exploits.
The consequences are familiar. In 2003, flaws in the RPC interface with DCOM opened Windows 2000/XP/2003 to buffer-overflow exploits and re-sulted in the LoveSan and Blaster worms.
Linux had a similar vulnerability in its rpc.statd and glibc libraries, which led to the Ramen worm in 2000 and the Lion and Adore worms in 2001.
Fight back with layered security against known vulnerabilities and exploits, and/or implement alternatives to simple RPC.
For the Defense
Faulty code isn't likely to go away. Given this fact of life, rigorously apply these defensive strategies:
Patch, patch, patch. Exploits continue to be created, and unpatched systems are the easiest to compromise.
Deploy application firewalls. Traditional layer 3 and 4 firewalls are ineffective against RPC exploits because RPCs don't use a specific port. They use a port mapper--usually running on port 135 on Windows and port 111 on Unix--to tell the client program which port RPC is running. Blocking ports 135 and 111 would deny all RPC traffic, while blocking all UDP traffic would disable DNS. Firewalls that filter layer 7 traffic can detect application-based attacks, such as RPC exploits.
Detect and prevent. Blocking suspicious traffic at the firewall isn't always possible. Craft custom IDS signatures that can trap these anomalous packets; the trick is to analyze them and look for their uniqueness. Be precise with the syntax so legitimate traffic doesn't trigger a false alarm.
Your signatures need to be updated in a timely manner. You may have used an application for months or years without incident, but new vulnerabilities come to light all the time.
If Internet-facing apps are your company's lifeblood, invest in services to bulletproof your code.
Alternatives to RPC are complex and require significant investment of time and resources:
RPC over HTTPS forces authentication and "hides" RPC within a tunneling mechanism.
Object Request Broker (ORB) is middleware that manages communication and data exchange be-tween distributed objects from different vendors. It's more secure than RPC because object communication details are hidden.
Message-Oriented Middleware (MOM) is a client/server infrastructure that allows applications to be distributed across heterogeneous platforms. It simplifies development by insulating the application developer from the details of the various OS and network interfaces. Application programming interfaces that extend across diverse platforms and networks are typically provided by the MOM.