API’S, SOCKET’S Y RPC´S

 

API’S

Una API o Interfaz de Programación de Aplicaciones, es un conjunto de funciones que los sistemas operativos,  ofrece a los programadores. Estas funciones del sistema pueden ser llamadas para realizar ciertas tareas de forma eficiente. Estas funciones contienen parámetros de entrada y salida y a veces valores de retorno. Las funciones de la API ya vienen compiladas en archivos separados llamados librerías. Pueden ser consideradas como una gran colección de componentes software que proveen a los lenguajes de programación  muchas utilidades, tales como interfaces gráficas del usuario (GUI).  Gracias a estas librerías o paquetes podemos escribir muchos tipos de programas distintos, como las conocidas Applets para Web,  servidores Web, Proxy, servidores de correos, servidores Irc, y prácticamente lo que podamos imaginar tanto en relación con Internet como cualquier aplicación de gestión, diseño gráfico, etc.

Un API desde el punto de vista técnico es la forma en la que se les presentan al programador las rutinas para llevar a cabo cierto trabajo. Por ejemplo, en JAVA para escribir el texto "Voy a ser un gran programador de vjuegos" utilizas la instrucción:

System.out.println("Voy a ser un gran programador de vjuegos");

 

en cambio en C utilizas la instrucción:

printf("Voy a ser un gran programador de vjuegos\n");

 

y en C++ utilizas la instrucción:

cout << "Voy a ser un gran programador de vjuegos" << endl;

 

como puedes ver JAVA, C y C++ le ofrecen al programador realizar el mismo trabajo (en este ejemplo imprimir en pantalla) escribiendo las instrucciones de diferente forma en cada uno, esto es... tienen diferente API.

 

 

 

 

 

 

 

¿Entonces qué es una librería y cómo funciona?

            Una librería es un conjunto de rutinas (una rutina es un conjunto de instrucciones), previamente construidas, que se enfocan en realizar algún trabajo en especial, para que así el programador ya no tenga que preocuparse por los detalles de cómo hacer ese trabajo, simplemente manda a llamar dentro de su propio código las instrucciones adecuadas que hay en la librería para hacer lo que él busca y ya, las instrucciones harán lo que deban hacer sin que nadie tenga que preocuparse por cómo lo hacen.

De esta forma se le facilita la vida al programador, dejando que se pueda enfocar más en lo que es su programa en sí.

Como una librería no es parte del código de tu programa, para poder utilizarla es necesario, al momento de compilar tu programa, ligarlo con la librería, es decir, hacer saber al programa que las rutinas están en alguna otra parte, y por supuesto, en que parte están.

Existen dos formas en las que el código y la librería pueden quedar ligados, en forma dinámica y en forma estática, y cada una tiene sus propias ventajas y desventajas.

Cuando ligas en forma estática lo que haces es "pegarle" a tu ejecutable las rutinas que utilizas de la librería, de modo que todo queda guardado en un mismo archivo:

de este modo cuando corres el programa se cargará en memoria al mismo tiempo que las rutinas de la librería, y siempre las tendrás a la mano no importa cuándo, cómo, dónde ni porque, el ejecutable será "autosuficiente" siempre, el problema cuando estas ligando en forma estática es que el tamaño del ejecutable puede ocupar más espacio.

 

Cuando ligas en forma dinámica lo que haces es simplemente indicarle al programa que cuando se esté ejecutando busque en algún directorio de la máquina local la librería que necesita:

de este modo el ejecutable ya no ocupará tanto espacio, y cuando necesite utilizar alguna rutina la cargará directamente de la librería que se encuentra en la máquina donde está corriendo, el problema con esto, como podrás imaginarte, es que puede o no existir dicha librería en la máquina donde está corriendo lo que, obviamente, causará que el programa pueda o no correr.

 

SOCKET’S

   Los sockets no son más que puntos o mecanismos de comunicación entre procesos que permiten que un proceso hable ( emita o reciba información ) con otro proceso incluso estando estos procesos en distintas máquinas. Esta característica de interconectividad entre máquinas hace que el concepto de socket nos sirva de gran utilidad. Esta interfaz de comunicaciones es una de las distribuciones de Berkeley al sistema UNIX, implementándose las utilidades de interconectividad de este Sistema Operativo ( rlogin, telnet, ftp, ... ) usando sockets. 

Un socket es al sistema de comunicación entre ordenadores lo que un buzón o un teléfono es al sistema de comunicación entre personas: un punto de comunicación entre dos agentes ( procesos o personas respectivamente ) por el cual se puede emitir o recibir información. La forma de referenciar un socket por los procesos implicados es mediante un descriptor del mismo tipo que el utilizado para referenciar ficheros. Debido a esta característica, se podrá realizar redirecciones de los archivos de E/S estándar (descriptores 0,1 y 2) a los sockets y así combinar entre ellos aplicaciones de la red. Todo nuevo proceso creado heredará, por tanto, los descriptores de sockets de su padre.  

La comunicación entre procesos a través de sockets se basa en la filosofía CLIENTE-SERVIDOR: un proceso en esta comunicación actuará de proceso servidor creando un socket cuyo nombre conocerá el proceso cliente, el cual podrá "hablar" con el proceso servidor a través de la conexión con dicho socket nombrado. 

El proceso crea un socket sin nombre cuyo valor de vuelta es un descriptor sobre el que se leerá o escribirá, permitiéndose una comunicación bidireccional, característica propia de los sockets y que los diferencia de los pipes, o canales de comunicación unidireccional entre procesos de una misma máquina. El mecanismo de comunicación vía sockets tiene los siguientes pasos: 

1.       El proceso servidor crea un socket con nombre y espera la conexión.  

2.       El proceso cliente crea un socket sin nombre. 

3.       El proceso cliente realiza una petición de conexión al socket  servidor. 

4.       El cliente realiza la conexión a través de su socket mientras el  proceso servidor mantiene el socket servidor original con  nombre. 

 

 Es muy común en este tipo de comunicación lanzar un proceso hijo, una vez realizada la conexión, que se ocupe del intercambio de información con el proceso cliente mientras el proceso padre servidor sigue aceptando conexiones. Para eliminar esta característica se cerrará el descriptor del socket servidor con nombre en cuanto realice una conexión con un proceso socket cliente. 

Todo socket viene definido por dos características fundamentales: 

-          El tipo del socket, que indica la naturaleza del mismo, el tipo de comunicación que puede generarse entre los sockets. 

-           El dominio del socket especifica el conjunto de sockets que pueden establecer una comunicación con el mismo. 

 

TIPOS DE SOCKETS

Define las propiedades de las comunicaciones en las que se ve envuelto un socket, esto es, el tipo de comunicación que se puede dar entre cliente y servidor. Estas pueden ser: 

-          Fiabilidad de transmisión. 

-           Mantenimiento del orden de los datos. 

-          No duplicación de los datos. 

-          El "Modo Conectado" en la comunicación. 

-          Envío de mensajes urgentes. 

 

Los tipos disponibles son los siguientes: 

§         Tipo SOCK_DGRAM: sockets para comunicaciones en modo no conectado, con envío de datagramas de tamaño limitado ( tipo telegrama ). En dominios Internet como la que nos ocupa el protocolo del nivel de transporte sobre el que se basa es el UDP. 

§         Tipo SOCK_STREAM: para comunicaciones fiables en modo conectado, de dos vías y con tamaño variable de los mensajes de datos. Por debajo, en dominios Internet, subyace el protocolo TCP. 

§          Tipo SOCK_RAW: permite el acceso a protocolos de más bajo nivel como el IP ( nivel de red ). 

§         Tipo SOCK_SEQPACKET: tiene las características del    SOCK_STREAM pero además el tamaño de los mensajes es fijo. 

 

 

 

 

 

 

 

RPC’S

 

La mayoría de los sistemas de ordenadores están conectados en red, soportando comunicación de datos entre ellos. Como resultado de esto, se han desarrollado muchas técnicas para soportar el desarrollo de aplicaciones que requieren procesos en diferentes sistemas, para comunicar y coordinar sus actividades. Una de estas técnicas son las RPC “Remote Procedure Call”, (Llamadas a Procedimientos remotos).

    El concepto de RPC es una sencilla técnica para desarrollar aplicaciones donde se requiere la comunicación entre procesadores que cooperan en un sistema distribuido. RPC es una técnica consistente, como evidencia la existencia de muchas especificaciones e implementaciones.

    Las RPC son expresadas como procedimientos ordinarios. Estas llamadas no requieren un compilador especial para el código fuente del programa. Las ventajas de esto incluyen:

§              Transferencia: La capa RPC puede ser reemplazada con llamadas a funciones directas si llegan a estar disponibles.

§              Familiaridad de la interface:  La mayoría de programadores están acostumbrados a una forma de llamadas a procedimientos. Esto permite una fácil adaptación al mecanismo RPC en sistemas ya implantados.

    La mayor ventaja de usar el mecanismo RPC es para permitir que una aplicación realice una simple llamada a función a una interface conocida. El mecanismo RPC proporciona un stub que empaqueta los argumentos en una forma sencilla, para ser transmitidos bajo una red a otro sistema, donde los argumentos son desempaquetados por otro stub en el proceso servidor  y pasados a la función actual o procedimiento que ha sido llamado. El valor de retorno del procedimiento es pasado al proceso cliente de una manera similar. Mientras todo esto ocurre, el cliente ha sido bloqueado y no se reanuda hasta que recibe el valor de retorno.

    Una implementación del modelo RPC normalmente consiste de al menos 3 elementos, un compilador de lenguaje, una librería runtime cliente y una librería runtime servidor. El compilador de lenguaje genera los stubs cliente y servidor apropiados, desde el programa escrito en un lenguaje RPC que normalmente es un lenguaje no orientado a procedimientos, que proporciona la capacidad de declarar procedimientos remotos y sus parámetros. Unidos a las aplicaciones cliente y servidor, los stubs cliente y servidor son compilados por un compilador de lenguaje, tal como C, produciendo ficheros objeto que son linkados con las librerías runtime del cliente y servidor, este proceso genera un cliente.

 

El esquema de funcionalidad para el segundo caso  se  muestra en la
figura anterior:

§           El cliente llama al Stub del Cliente,  con los parametros exactamente de la misma forma que si se tratase de un procedimiento local.

§           El Stub construye  un  paquete (esto es lo que se conoce como "marshal" de los parametros) y
hace una llamada al kernel del sistema operativo.

§           El kernel local envia el mensaje al kernel remoto.

§           El kernel remoto entrega el mensaje al Stub del Servidor.

§           El Stub del servidor desempaqueta los parametros ("unmarshal") y llama al servidor.

§           El servidor realiza el trabajo y retorna el resultado al Stub.

§           El Stub del servidor empaqueta los resultados (marshal en el servidor) y llama al kernel.

§           El kernel Remoto envia el mensaje al kernel del Cliente.

§           El kernel del Cliente le entrega el mensaje al Stub cliente que espera por el.

§           El Stub desempaqueta el resultado (unmashal en el Cliente) y lo regresa al Cliente.

 

La limitación del RPC más clara en los sistemas distribuidos es que no permite enviar una solicitud y recibir respuesta de varias fuentes a la vez, sino que la comunicación se realiza únicamente entre dos procesos.

 

 

 

 

 

 

 

APORTACIÓN

 

El Remote Procedure Call (RPC) es un protocolo utilizado por Windows para permitir que un programa que se ejecuta en una computadora pueda acceder a los servicios de otra conectada en la misma red red.

Últimamente se encontro una vulnerabilidad en Windows, la vulnerabilidad radica en el intercambio de mensajes entre procesos que se realiza sobre protocolos TCP/IP al utilizarse RPC y consiste en la ejecución arbitraria de código. Ocurren porque no se controla si el formato de los mensajes TCP/IP cumplen el estándar predefinido. Afecta la interface DCOM con RPC, que controla las solicitudes de activación de objetos de DCOM que las computadoras clientes envían al servidor.

Distributed Component Object Model (DCOM) es un protocolo que muestra un conjunto de interfaces que permiten a los clientes y servidores comunicarse entre sí. Los objetos de un cliente pueden solicitar los servicios de objetos de servidores en otras computadoras dentro de una red si están ejecutando en Windows 95, 98, NT, 2000 y XP. Usando una interface DCOM, un programa puede iniciar un Remote Procedure Call (RPC) a un objeto de otro programa especializado que proporciona el procesamiento necesario y devuelve el resultado. DCOM emplea protocolos TCP/IP y HTTP con escucha en el puerto 135 de TCP/UDP y en los puertos 139, 445 y 593 de TCP.

La vulnerabilidad puede ser explotada por un intruso para ejecutar código dañino con privilegios de zona local en el sistema afectado. Para explotar esta vulnerabilidad el atacante debería contar con los conocimientos necesarios para enviar una solicitud especialmente diseñada a uno de los puertos afectados en la computadora remota. En los entornos conectados a una Intranet, este puerto suele estar accesible, pero en las computadoras conectadas a Internet, los puertos deberían estar bloqueados por el firewall. Esto explica porqué la mayoría de las computadoras infectadas no están en un ambiente de empresa, pero el nivel de dispersión alcanzado hace pensar que también existen muchas computadoras infectadas detrás de firewalls corporativos incorrectamente configurados y en sistemas que tienen al día sus parches de seguridad.

La recomendación de Microsoft es bloquear todos los puertos TCP/IP que no se utilicen. Las computadoras que se conectan en algún momento a Internet deberían tener bloqueados los puertos 135, 139, 445, 593 o cualquier otro relacionado con el protocolo RPC. Microsoft considera que el uso de RPC sobre TCP no está pensado para ser utilizado en un entorno inseguro como Internet, donde debería utilizarse RPC sobre HTTP. La solución consiste en actualizar cuanto antes el sistema por medio de los parches disponibles en el sitio de Microsoft.