RPC

Las implementaciones de RPC

·         La desarrollada por Sun Microsystem denominada ONC-RCP (Open Network  Computing, ONC-RCP), distribuida con casi todos los sistemas UNIX.

·         La desarrollada por Microsoft en línea con el Ambiente de Computación Distribuida  (DCE, Distributed Computing Enviroment) definido por la Fundación de Software  Abierto (OSF, Open Software Foundation). Incluida en los sistemas operativos  Windows.

Asegurar transmisiones basadas en RPC

La llamada de procedimiento remoto (RPC) segura protege los procedimientos remotos con un mecanismo de autenticación. El mecanismo de autenticación Diffie-Hellman autentica tanto el host como el usuario que realiza una solicitud para un servicio. El mecanismo de autenticación utiliza el cifrado Estándar de cifrado de datos (DES). Las aplicaciones que utilizan RPC segura incluyen NFS y los servicios de nombres, NIS y NIS+.

Diffie-Hellman

El protocolo criptográfico Diffie-Hellman,1 debido a Whitfield Diffie y Martin Hellman, (Diffie-Hellman Problem->DHP) es un protocolo de establecimiento de claves entre partes que no han tenido contacto previo, utilizando un canal inseguro, y de manera anónima (no autenticada).

Se emplea generalmente como medio para acordar claves simétricas que serán empleadas para el cifrado de una sesión (establecer clave de sesión). Siendo no autenticado, sin embargo, provee las bases para varios protocolos autenticados.

Su seguridad radica en la extrema dificultad (conjeturada, no demostrada) de calcular logaritmos discretos en un cuerpo finito.

Cuestiones que afectan la comunicación por RPC

En llamadas remotas las posibles fuentes de fallos son múltiples.

1.       Fallos en los procedimientos llamados

La ejecución del proceso llamado se detiene por errores del hardware o del sistema operativo que lo ejecuta (ej.: caída del sistema)

También por errores internos del propio procedimiento (divisiones por 0, índices de arrays fuera de rango, etc.)

2.       Fallos en la comunicación

Perdida de la conexión: la red deja de enviar paquetes (caída de la red, perdida de un enlace,...)

Corrupción del contenido de alguno de los mensajes enviados

Perdida de paquetes: algún mensaje/s no llega a su destino

Recepción fuera de orden: paquetes retrasados recibidos de forma desordenada

3.       Otros fallos: bugs en el proceso llamado, ataques, etc.

Implementación de RPC en Bases de Datos

SQL Server admite el uso de servidor a servidor RPC, que permite utilizar una conexión a un servidor para llamar a un procedimiento en un servidor secundario. En este artículo se describe un método para utilizar RPC para llamar a cualquier procedimiento almacenado extendido personalizado en un servidor secundario sin cambiar el código de la aplicación.

La llamada a un procedimiento almacenado extendido puede producirse de dos maneras diferentes:

·         Ad-hoc Transact-SQL.

·         Mediante una llamada a un "contenedor" procedimiento almacenado.

En cualquier caso, puede redirigir la llamada a un servidor remoto mediante una llamada de SQL Server RPC sin realizar ningún cambio a la aplicación cliente.

Debido a que se realiza un seguimiento de un procedimiento almacenado extendido en sysobjects como cualquier otro procedimiento almacenado de Transact-SQL, puede colocar la referencia al procedimiento almacenado existente y reemplazarlo con un contenedor que llama a la rutina remota. Si ya dispone de un contenedor de procedimiento almacenado, o bien puede actualizarla para utilizar la sintaxis RPC o puede utilizar el método que se describe en este artículo para proporcionar un nivel adicional de direccionamiento indirecto en la llamada de procedimiento almacenado extendido.

Vulnerabilidades en RPC

La vulnerabilidad podría permitir a un atacante ejecutar código arbitrario y tomar control total del sistema afectado. La configuración por defecto no permite que los usuarios sean atacados por medio de esta vulnerabilidad, aunque podría ser afectada en aplicaciones de terceros.

Vulnerabilidades XMLRPC en PHP

Otra vulnerabilidad bastante común en esta categoría incluye vulnerabilidades en el uso de XML-RPC

XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar las llamadas y HTTP como mecanismo de transporte.

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

Un común desperfecto está en los distintas implementaciones de XML-RPC en PHP pasando entradas de datos del usuario sin filtrar por la función eval() en el servidor XML-RPC. Esto permite al atacante ejecutar código, en el sistema vulnerable. Cualquier usuario con habilidad de subir XML manualmente al servidor puede insertar código PHP que puede ser ejecutado por la aplicación Web vulnerable.

Tipos de RPC y Parametros

ONC

ONC RPC, abreviación del inglés Open Network Computing Remote Procedure Call, es un protocolo de llamada a procedimiento remoto (RPC) desarrollado por el grupo ONC de Sun Microsystems como parte del proyecto de su sistema de archivos de Red NFS, algunas veces se lo denomina Sun ONC o Sun RPC. Trabaja sobre los protocolos TCPy UDP. La codificación de datos se realiza utilizando el protocolo XDR (presentación de datos).

ONC RPC está regulado por RFC 1831. Los mecanismos de autenticación usados por ONC RPC están descritos en RFC 2695, RFC 2203, y RFC 2623.

Desarrollo de aplicaciones: compiladores de protocolo

El desarrollo de aplicaciones para ONC RPC consiste en desarrollar programas cliente/servidor, donde los datos deben codificarse según el protocolo XDR.

Las aplicaciones se realizan en forma sistemática mediante compiladores de protocolo como el programa rpcgen, que fue el programa original desarrollado por Sun que generaba casi todo el código en lenguaje C necesario para crear los programas servidor y cliente. Existen compiladores de este protocolo que generan código en Java, denominados jrpcgen.

Implementaciones

Las implementaciones de ONC RPC existen para la mayoría de los sistemas como Unix (OpenVMS Alpha, OpenVMS I64,1 etc.) y Linux (en el subdirectorio sunrpc de la biblioteca Glibc).

Las tecnologías que involucran a ONC RPC (incluyendo NFS y NIS) desarrollada por Sun para su sistema operativo Solaris, en sus versiones más recientes se denominan tecnologías ONC+.2

La Free Software Foundation está desarrollando una implementación GNU de este protocolo, denominado GNU Guile-RPC,3 como parte del desarrollo del lenguaje de programación GNU Guile.

Microsoft provee una implementación para su Windows en el producto "Microsoft Windows Services for UNIX”; además, existen otras implementaciones de ONC RPC para Windows, incluyendo versiones en lenguaje C/C++, Java, y Microsoft .NET.

DCE

DCE Remote Procedure Call o bien DCE RPC es un sistema de llamada a procedimiento remoto del conjunto de software OSF DCE. DCE / RPC, la abreviatura de "Distributed Computing Environment / Remote Procedure Calls ", es el sistema de llamada a procedimiento remoto desarrollado para el entorno de la informática distribuida (DCE). Este sistema permite a los programadores escribir software distribuido como si fuera todos los que trabajan en el mismo equipo, sin tener que preocuparse por el código de red subyacente.1

DCE RPC no debe confundirse con DCE el cual es un conjunto de servicios que incluye DCE RPC, además de otras cosas como CDS y DCE DFS.

DCE RPC fue encargado por la fundación Open Software Foundation. Una de las compañías clave que contribuyeron fue Apollo.

DCOM

Distributed Component Object Model (DCOM), en español Modelo de Objetos de Componentes Distribuidos, es una tecnología propietaria de Microsoft para desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre sí. Extiende el modelo COM de Microsoft y proporciona el sustrato de comunicación entre la infraestructura del servidor de aplicaciones COM+ de Microsoft. Ha sido abandonada en favor del framework .NET.1 2

La adición de la "D" a COM fue debido al uso extensivo de DCE/RPC, o más específicamente la versión mejorada de Microsoft, conocida como MSRPC.

En términos de las extensiones que añade a COM, DCOM tenía que resolver los problemas de

·         Aplanamiento - Serializar y deserializar los argumentos y valores de retorno de las llamadas a los métodos "sobre el cable".

·         Recolección de basura distribuida, asegurándose que las referencias mantenidas por clientes de las interfaces sean liberadas cuando, por ejemplo, el proceso cliente ha caído o la conexión de red se pierde.

Uno de los factores clave para resolver estos problemas es el uso de DCE/RPC como el mecanismo RPC subyacente bajo DCOM. DCE/RPC define reglas estrictas en cuanto al aplanamiento y a quién es responsable de liberar la memoria.

DCOM fue uno de los mayores competidores de CORBA. Los defensores de ambas tecnologías sostenían que algún día serían el modelo de código y servicios sobre Internet. Sin embargo, las dificultades que suponía conseguir que estas tecnologías funcionasen a través de cortafuegos y sobre máquinas inseguras o desconocidas, significó que las peticiones HTTP normales, combinadas con los navegadores les ganasen la partida. Microsoft, en su momento intentó y fracasó anticiparse a esto añadiendo un transporte extra HTTP a DCE/RPC denominado "ncacn_http" (Connection-based, over HTTP).

Parámetro por Valor

Un parámetro por valor, como fd o nbytes, solo se copia a la pila. Para el procedimiento que recibe la llamada, un parámetro por valor es tan sólo una variable local ya iniciada. El procedimiento llamado podría modificarla, pero esto no afecta el valor de la variable original en el procedimiento que hizo la llamada.

Parámetro por Referencia

Un parámetro por referencia en C es un apuntador a una variable (es decir, la dirección de la variable), en lugar del valor de la variable. En la llamada a read, el segundo parámetro es un parámetro por referencia, puesto que en C los arreglos siempre se transfieren por referencia. Lo que se introduce en realidad a la pila es la dirección del arreglo de caracteres. Si el procedimiento llamado utiliza este parámetro para guardar algo en el arreglo de caracteres, esto sí modifica el arreglo en el procedimiento que hizo la llamada. La diferencia entre los parámetros llamados por valor o por referencia es importante para RPC, como veremos más adelante.

Clasificación de Hardware de los SOD

Clúster

• Una colección de estaciones de trabajo o PCs que están conectadas mediante alguna tecnología de red.
• Para fines de computación paralela estas PCs o estaciones de trabajo estarán conectadas mediante una red de muy alta velocidad.
• Un clúster trabaja como una colección integrada de recursos y pueden tener una imagen simple del sistema abarcando todos sus nodos.

Grid

• Un gran conjunto de Sitios que están conectadas mediante una red global de alta velocidad (10 Gb/s) que tienen una alta capacidad de procesamiento (entre 1000 a 10000 GFLOPS) y un gran capacidad de almacenamiento (entre 1000 a 10000 TB)
• Los Sitios interconectados utilizan Procesamiento Distribuido y P2P (Peer to Peer Architecture) con desarrollos de SW novedosos adicionales con interfaces estándar abiertas.
• Utiliza nuevas técnicas de Autoadministración, auto escalabilidad y auto reparación (tolerante a fallas)

MPP

• Es un gran sistema de procesamiento paralelo con una arquitectura que no comparte nada.
• Consiste en cientos de elementos de procesamiento los cuales están interconectados por un Switch o red de alta velocidad.
• Cada nodo puede tener una variedad de componentes de hardware, pero generalmente consisten de una memoria central y de uno o varios procesadores.

SMP

• Poseen desde 2 a 64 procesadores y pueden ser considerados como una arquitectura que comparte todo.
• En estos sistemas todos los procesadores comparten todos los recursos globales disponibles (bus del sistema, memoria, sistemas de I/O, etc.);
• Una copia sencilla del Sistema Operativo corre en estos sistemas.

CC-NUMA

• Es un sistema multiprocesador escalable.
• Como en SMP, cada procesador en un sistema CC-NUMA tiene una vista global de toda la memoria.
• Este tipo de sistema consigue su nombre (NUMA) a partir de los tiempos no uniformes que le toma para acceder ya sea a la parte memoria más cercana, así como a la más remota.

Sistemas Distribuidos

• Pueden ser considerados redes convencionales de computadores independientes.
• Los mismos tienen múltiples imágenes del sistema, a partir de que cada nodo tiene su propio sistema operativo, y
• Cada máquina individual en un sistema distribuido puede ser, por ejemplo, una combinación de MPPs, SMPs, Clústeres, Grids y computadoras individuales.

Diferencias entre SO Distribuido y Sistema Distribuido

La diferencia es que los SO Distribuidos contienen varios Sistemas Distribuidos para su funcionamiento, esto quiere decir que un Sistema Distribuido forma parte de los SO Distribuidos.

Diferencias entre los Sistemas Operativos de Red, Distribuidos y Multiprocesador

Dentro de los que hoy en día se considera SOD podemos encontrar tres grandes grupos, donde cada uno de ellos tiene sus características y su uso particular (con mayor o menor difusión y teniendo la posibilidad de vincular diferentes tipos.

• SO de Red
• SO Distribuido (Real)
• SO Multiprocesador

Las características generales de cada uno de ellos se puede ver en el siguiente cuadro:

Ejemplos de SO Distribuidos

Solaris

Es un sistema operativo de tipo Unix desarrollado desde 1992 inicialmente por Sun Microsystems y actualmente por Oracle Corporation como sucesor de SunOS. Es un sistema certificado oficialmente como versión de Unix. Funciona en arquitecturas SPARC y x86 para servidores y estaciones de trabajo.

Sprite

Es el nombre de un sistema operativo distribuido con un núcleo monolítico desarrollado por la University of California, Berkeley, más concretamente por el grupo de investigación de John Ousterhout.

Este sistema operativo tiene la apariencia para los programadores de un sistema único, ya que la distribución se produce dentro del propio núcleo y de este modo, Sprite nos da la impresión de estar trabajando sobre un típico sistema UNIX.

Amoeba

Amoeba es un sistema operativo distribuido de investigación, basado en una arquitectura de micronúcleo. Fue desarrollado por Andrew S. Tanenbaum y otros en la Universidad Libre de Amsterdam. El objetivo del proyecto Amoeba era construir un sistema de tiempo compartido que hiciera que una red entera de computadores pareciera a los ojos de un usuario como una máquina única.

Los servicios suministrados por el núcleo incluyen threads, segmentos de memoria, mecanismos de IPC (RPCs y mensajes) y E/S [160].

El desarrollo parece detenido, dado que la fecha de la última modificación en el código data de febrero de 2001.

Existen versiones para varias plataformas, incluyendo i386, Sun-3 y SPARC.

Clases de SO Distribuidos

Por su estructura 

• Monolítica: Es  la  estructura  utilizada en los primeros SO en la que las funciones  se implementan en el kernel.
• Por capas: Corresponde a una estructura  jerárquica que se divide en distintos niveles.
• Maquina virtual: Se trata de un tipo de sistemas  operativos que presentan una interfaz a cada proceso, mostrando una máquina que parece idéntica a la maquina  real. 

Por los modos de explotación: maneras que puede  funcionar un 

• Procesamiento por lotes: Es la agrupación por bloques  de los  trabajos  similares, existe la ausencia  de interacción entre el usuario y el proceso mientras se  ejecuta.
• Multiprogramación: El SO se encarga de distribuir  la carga  computacional entre los procesadores existentes, con el fin de  incrementar el procesamiento de la máquina.Tiempo real: Un SO  en tiempo real  es aquel en el cual los resultados  son correctos  también es correcto  en el  tiempo que se producen los resultados.
• Híbrido: Estos SO intentan ser  una mezcla    de los dos anteriores.

Por los servicios ofrecidos

• Esta clasificación se tiene en cuenta la visión  del usuario  final 

Por el número de usuario:

• Monousuario: Son aquellos que únicamente  soportan un usuario a la vez
• Multiusuario: Son capaces de dar  servicio  a  mas de un usuario a la vez

Por el número de tareas:

• Monotarea:  Son aquellas que solo permiten una tarea a la vez
• Multitarea: Es aquella que  permite al usuario  estar realizando  varios  trabajos al mismo  tiempo.

Por el número de procesadores:

• Monoproceso: Son los que  solamente permiten realizar un proceso a la vez
• Multiproceso: son aquellos  que permiten realizar varios procesos simultáneamente y son  capaces de  ejecutar varias  tareas  al mismo tiempo.

Por la forma de ofrecer los servicios.

• Sistema centralizado: Con este  tipo de modelo  los computadores  mainframe se encargaban de todo el procesamiento  y los usuarios manejaban únicamente terminales  tontas
• Sistemas de Red: Estos SO son aquellos que mantienen  a dos o mas computadoras  unidas  a través de un medio  de comunicación  con  el objetivo primordial  de poder  compartir  los diferentes recursos  y la  información  del sistema, cada computador mantienen  su propio SO
• Sistemas distribuidos: Son sistemas  cuasi-independientes  que permiten distribuir los trabajos, tareas  o procesos  entre  un conjunto  de procesadores.