RPC

Implementaciones más comunes de los RPC

Las implementaciones de RPC más populares son:

Sun - RPC (ONC-RPC: Open Network Computing-RPC): RPC muy extendido en entornos Unix, infraestructura sobre la que se ejecuta NFS (servicio de sistema de ficheros en red), NIS (servicio de directorio)

DCE/RPC (Distributed Computing Environmen RPC): RPC definido por la Open Software Foundation

Java-RMI: invocacion de métodos remotos en Java CORBA (Common Object Requesting Broker Architecture): soporta la invocación de métodos remotos bajo un paradigma orientado a objetos en diversos lenguajes SOAP (Simple Object Access Protocol): protocolo RPC basado en el intercambio de datos (parámetros + resultados) en formato XML

Como se asegura las transmisiones basadas en RPC

En un ambiente de computación distribuida la posibilidad de fallo aumenta, considerando que tanto los sistemas local y remoto como la red de datos son potenciales fuentes de fallas. La implementación debe proveer mecanismos para manejar tales situaciones.

Cuando se realiza una llamada a un procedimiento local, uno no se pregunta cuantas veces el procedimiento se ejecutó. Si un procedimiento retorna entonces se ejecutó exactamente una vez. Sin embargo, si se considera un procedimiento remoto del cual no se ha obtenido respuesta después de un intervalo de tiempo, no se puede tener certeza si se ha ejecutado. Si el servidor experimenta un error de ejecución, por ejemplo, antes de que el “stub” del lado del servidor se realice la llamada, entonces ésta no se habrá ejecutado. Si el servidor experimenta un error de ejecución después de haber devuelto su resultado al “stub”, se habrá ejecutado una vez. Si el cliente retransmite una solicitud por no haber recibido una respuesta del servidor, se confunden aún más las cosas. Es posible que la primera solicitud haya sufrido un retraso en algún lugar de la red y finalmente, haya sido ejecutada al igual que la solicitud retransmitida.

Existe tres tipos de semánticas de RPC: exactamente una vez, cuando mucho una vez, y al menos una vez.

Que cuestiones afectan la comunicación por medio de rpc

Errores de Comunicación.

·         No se puede localizar al servidor

·         Pérdida de mensajes de petición

·         Pérdida de mensajes de respuesta.

Fallo en el Servidor

·         Error por parámetros incorrectos, operación no permitida, etc.

Caída del Servidor

Fallo en el Cliente.

Caída del cliente.

 No se puede localizar al servidor.

Cuando se le solicita al binder la dirección del servidor apropiado, puede ocurrir que el servidor esté caído y no se haya registrado, por lo que no está disponible.

Pérdida de mensajes de petición.

Para tratar la posible pérdida de las peticiones, la solución más fácil es que el módulo de comunicaciones ponga una temporización cuando envía el mensaje de petición.

Pérdida de mensajes de respuesta.

La solución obvia a este problema podría estar en apoyarse otra vez en las temporizaciones, de tal forma que si no se recibe la respuesta en un tiempo finito, simplemente se vuelve a enviar la petición.

En una base de datos para que se implementan los rpc

XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP como protocolo de transmisión de mensajes.

Es un protocolo muy simple ya que solo define unos cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión.

Que vulnerabilidades presenta el uso de los rpc

Lo que debería saber sobre la vulnerabilidad RPC/DCOM

Microsoft publicó en julio, un boletín de seguridad sobre una vulnerabilidad provocada por el desbordamiento de búfer en el protocolo RPC (boletín MS03-026). Sin embargo, parecen existir no una, sino dos fallas.

La primera, es la que Microsoft describía en el mencionado boletín como capaz de permitir a un atacante remoto la ejecución de código, lo que en las últimas horas ha sido ampliamente demostrado con la aparición del Lovsan.A, que aunque no se trata del primero que se aprovecha del agujero, está claro que ha sido el más notorio.

La nueva falla en cambio, sería capaz de permitir un ataque de denegación de servicio, y poco se sabe de ella, salvo un misterioso boletín de seguridad MS03-032 que solo ha sido publicado por Microsoft España, sin enlaces a ningún parche (existe otro sobre tres fallas del Internet Explorer, en las mismas condiciones).