Herramientas Basicas Seguridad

Juan Carlos Guel López [email protected]

Monitoreo del Sistema Tiger Instalación y Configuración Cops Instalación y Configuración Seguridad en Red TCP-Wrappers Instalación y Configuración Secure Shell Instalación y Configuración Cifrado de Datos PGP Instalación y Configuración

Monitoreo del Sistema

Descripción General Versiones de Tiger Cómo Funciona

Descripción General TIGER, o los scripts de 'tiger', son un conjunto de scripts en Bourne Shell, se compone de programas en C y archivos de datos que se usan para realizar una revisión de seguridad en sistemas UNIX producido por el Centro de Cómputo de la Univesidad A&M de Texas. Es una herramienta de fácil uso, que es fácil de comprender, analizar y adecuar. Actualmente soporta sistemas SunOS 4.x y SunOS 5.x y posteriores y NeXT 3.x. Otros sistemas que se incluyen en los archivos de configuración son sistemas IRIX 4.x, AIX 3.x, UNICOS 6.x, Linux 0.99.x y HP/UX. Estas configuraciones no han sido probadas completamente como en sistemas SunOS y en algunos casos no funcionan de forma adecuada.

Objetivo El objetivo primario de TIGER es reportar la manera en que 'root' pueden ser comprometido. La primera verificación que realiza es en los uid, solo ´root´ debe tener un uid igual a 0, de igual forma se verifican los “gid” del sistema.

Versiones de Tiger En este momento hay tres distribuciones de Tiger. • tiger-2.2.3p1 es la última distribución de TAMU, incluyendo los check_devs y check_rhosts. • tiger-2.2.3p1-ARSC es una contribuición por el Centro de Supercomputo de la Región Artica. • tiger-2.2.4p1 es la distribución de TAMU con algunos cambios para su uso en Linux.

Cómo Funciona

TIGER verifica los directorios pertenecientes a 'root’junto con los archivos, verifica también archivos cron, inetd, archivos con setuid encendido, PATHs, etc, para ver si estos pueden estar alterados. De igual forma, realiza un chequeo en los paths en otras cuentas para detectar alguna vulnerabilidad, pero 'root' recibe la atención especial.

Al ejecutar TIGER en una forma sencilla se realizarian los siguientes pasos:

• Se verifican los archivos de datos de usuarios del sistema. • Se verifican las entradas del cron. • Se verifican los alias del Mail. • Se verifican Sistemas de Archivos exportados por NFS. • Se verifican las entradas del inetd. • Se verifican las variables PATH. • Se verifican archivos rhosts y netrc. • Se verifican permisos en Archivo y Directorios. • Se verifica la localización de archivos inusuales en los sistemas de Archivos.

La cantidad de tiempo requerida para ejecutar TIGER varía dependiendo de el tamaño del sistema y la forma en que esté configurado TIGER. Por ejemplo, sobre una sparcStation LX con 1GB de disco, con menos de 20 usuarios, y una configuración completa DE TIGER, toma aproximadamente sobre 90 minutos. Una configuración más sencilla de TIGER puede tardar aproximadamente 25 minutos. La mayor parte del tiempo TIGER verifica los pathnames. Sobre sistemas con un número grande de usuarios, la verificación tardará mucho mayor tiempo.

¿Qué es COPS? ¿Qué verifica cops? ¿Dónde obtener cops? Instalación de cops Ejecución de cops Interpretación de resultados

¿Qué es Cops? COPS (Computer Oracle and Password System) Herramienta de seguridad desarrollado por Daniel Farmer y Eugene H. Spafford, cuyo principal objetivo es la detección de una gran variedad de problemas de seguridad particulares de Unix. Este paquete se divide en tres partes: Un conjunto de programas que intentan de forma automática detectar potenciales riesgos de seguridad. Estas pueden ser ejecutadas de manera individual o mediante un script. • Documentación, la cual detalla la ejecución, operación e interpretación de los resultados del programa. •El Script COPS de ejecución en shell y perl. Además incluye algunos documentos de varios tópicos relacionados con la seguridad en Unix. La última versión liberada de COPS es la 1.04

¿Qué Verifica Cops? • Permisos de archivos, directorios y dispositivos del sistema. • Cuentas sin password. • Contenido, formato y seguridad de los archivos de grupos y password • Los programas y archivos que corren en /etc/rc* y en la tabla de cron. • La existencia de archivos SUID propiedad de root, si estos pueden ser escritos por cualquiera o si estos son shell scripts. • Verificación CRC de binarios importantes o reporte de alteraciones en archivos del sistema. • anonymous ftp habilitado. • Verifica las fechas de varios huecos de seguridad reportados en CERT en los binarios del sistema.

¿Dónde Obtener COPS ? Existen varios lugares de donde es seguro obtener via ftp el paquete COPS: ftp://ftp.asc.unam.mx/pub/tools/cops.tar.gz ftp://ftp.cert.org/pub/tools/cops/cops.1.04.tar.gz ftp://coast.cs.purdue.edu/pub/tools/unix/cops/cops.1.04.tar.gz Es importante obtener el paquete limpio, ya que de obtenerlo de un servidor no seguro exponemos nuestro sistema innecesariamente, a un posible COPS troyano. Después de obtener el paquete es necesario desempaquetarlo, utilizando los comandos tar y gunzip.

Instalación de Cops Cops está integrado por una serie de programas especializados en la búsqueda de algún tipo de vulnerabilidad dentro del sistema. Para construir los binarios de cops se requiere realizar los siguientes pasos: a) Obtener las rutas de dependencia entre archivos, y compiladores, esto es buscar los compiladores de gcc o cc, los compiladores de la ayuda troff o nroff, etc. Esto se logra ejecutando el script reconfig. $ ./reconfig

Configuración de Cops b) Editar el shell script de cops y realizar las siguientes modificaciones según se requieran. $vi ./cops b.1) Cops requiere obtener la ruta completa donde se localizan el directorio de cops, para esto debemos modificar la directiva SECURE de cops, esta directiva se localiza cerca de la linea 93 y tiene la siguiente ruta por default. SECURE = /usr/foo/bar debe quedar: SECURE=/path/to/cops_104/

b.2) Cops tiene la opción de enviar la información obtenida por medio de un correo electrónico para controlar esto debemos utilizar la directiva SECURE_USERS, esta directiva se encuentra una línea abajo de la directiva SECURE, con la dirección electrónica por default: SECURE_USERS=“[email protected]” modificar por el correo electrónico del usuario que ejecutará cops. Ejemplo: SECURE_USERS=“[email protected]”

c) Si nuestro sistema tiene habilitado /etc/shadow, el realizar una verificación de los password puede resultar innecesaria, para deshabilitar esta opción del cops se requiere comentar el módulo ”pass.chk”, la ejecución de este modulo dentro de cops la encontraremos cerca de la línea 198. Se ve de la forma siguiente el código que se necesita comentar. if $TEST -n “$verbose” ; then $ECHO “**** pass.chk ****” >> $VERBUCKET ; fi $SECURE/pass.chk “-w ./pass.words -b -g -s -c -d -n” >> $RESULT 2>> $BIT_BUCKET

d) Regularmente cuando una máquina es atacada, es común encontrar puertas traseras esto para garantizar la entrada posterior al sistema, una puerta que puede pasar desapercibida por presentar una cuenta valida en muchos sistemas es la cuenta ftp anonymous, para verificar esta opción se debe habilitar la verificación de ftp anonymous. Cerca de la linea 192 se encuentra el código que llama a la rutina de verificación de ftp.chk, se debe habilitar una bandera para lograr que esta verifique las opciones de ftp anonymous. if $TEST -n “$verbose” ; then $ECHO “**** ftp.chk ****” >> $VERBUCKET ; fi $SECURE/ftp.chk -a >>$RESULT 2>> $BIT_BUCKET

e) Un recurso frecuente utilizado por los intrusos es modificar ciertos binarios claves del sistema, con esto garantizarse puertas de entrada o ejecutar troyanos que les garanticen su entrada posterior. Estas acciones generan rastros en el sistema los cuales pueden ser detectados por cops, para esto se debe de habilitar la ejecución del módulo crc.chk, ya que por default cops lo lleva deshabilitado. La ejecución de este módulo se encuentra cerca de la línea 218, para esto descomentamos lo siguiente: #if $TEST -n “$verbose” ; then # $ECHO “**** crc.chk ****” >> $VERBUCKET ; fi #$SECURE/crc.chk 2>> $BIT_BUCKET # crc.chk puts it´s results in a file called crc.results ... #if $TEST -s “$SECURE/crc_results” ; then # $CAT $SECURE/crc_results >> $RESULT #fi

f) Por ultimo salvar los cambios realizados en el script cops.

Compilación de los fuentes de cops. Como ya mencionamos cops está integrado por una serie de módulos programados en C, los cuales realizan la verificación fuerte del sistema estos archivos se localizan en: /path/to/cops_104/src/ Para obtener el código ejecutable se requiere solamente de ejecutar: $ make all

Ejecución de cops Después de haber compilado los fuentes de cops, solo necesitaríamos ejecutar el scripts cops el cual tiene la siguiente sintaxis: cops [-a architecture] [-b bit_bucket] [-s secure_dir] [-m user] [-f filter_file] [-dxvV]

donde: -a : Especifica el subdirectorio arquitectura que deseamos ejecutar, Al ejecutar make install se generarán los binarios adecuados. -b : Especifica el bit bucket, donde se almacenarán todos los mensajes de error.

-d : Enviará un reporte por correo electrónico si existen cambios desde la ultima vez que se ejecuto cops. -f : Especifica el archivo de filtro que cops usará para filtrar los mensajes de advertencia extraños. -m : Cops envía la salida por correo electrónico al usuario especificado. -x : Muestra la versión de cops. -vV : Activa el modo de verbose

Ejemplo: $ ./cops -v& Nota: Al terminar la ejecución de cops este generará un reporte con los resultados encontrados este resultado se encontrará sobre un directorio en la ruta que definimos dentro del script de cops el directorio tendrá el nombre de la máquina y dentro de este directorio se encontrará un archivo con la fecha de la auditoria con la característica siguiente: año_mes_dia.

Seguridad en Red

Introducción ¿Qué es TCP Wrappers? ¿Qué es un Wrapper? Historia del TCP Wrappers Esquema de trabajo Dónde obtenerlo Instalación de TCP Wrappers Lenguaje de Control de Acceso TCP Wrappers Avanzado

Introducción El gran desarrollo que han tenido las redes de computadoras han abierto a los usuarios posibilidades nunca antes imaginadas. Actualmente una persona puede tener acceso a información que está físicamente localizada del otro lado del Planeta, o comunicarse en cuestión de segundos con personas ubicadas a muchos kilómetros de distancia. Esto ha cambiado la forma como muchos de nosotros vemos y usamos a las computadoras. Sin embargo también ha abierto la posibilidad a muchos problemas. A través de los mismos servicios de red que nos permiten difundir y obtener información, en muchas ocasiones ha sido posible obtener acceso no autorizado a los sistemas, permitiéndo a los intrusos utilizar recursos a los que no deberían tener acceso, o incluso realizar actos dañinos como robar o destruir información.

Los requerimientos de la seguridad varían dependiendo de la complejidad de las tareas o actividades en las cuales se emplea el equipo de cómputo y de la plataforma de equipo que éstas involucren. Las medidas de seguridad necesarias para proteger una PC no es la misma que las medidas de seguridad necesarias para garantizar el funcionamiento continuo de una red de área local (LAN), y éstas a su vez son menores a las requeridas cuando se trata de una de red área amplia (WAN), que sería el caso de la conexión a INTERNET. TCP Wrappers permite controlar y proteger los servicios de red, limitando el acceso como sea posible, y registrado todos las conexiones para hacer el trabajo de detectar y resolver problemas de forma más fácil.

¿Qué es TCP Wrappers?

TCP Wrappers es una herramienta simple que nos sirve para monitorear y controlar el tráfico que llega por la red. Esta herramienta ha sido utilizada exitosamente en la protección de sistemas y la detección de actividades ilícitas.

Fue desarrollada por Wietze Zweitze Venema y esta basada en el concepto de Wrapper; es una herramienta de seguridad libre y muy util.

¿Qué es un Wrapper? Un Wrapper es un programa para controlar el acceso a un segundo programa. El Wrapper literalmente cubre la identidad del segundo programa, obteniendo con esto un más alto nivel de seguridad.

Los Wrappers son usados dentro de la Seguridad en Sistemas UNIX. Estos programas nacieron de la necesidad de modificar el comportamiento del sistema operativo sin tener que modificar su estructura.

Los Wrappers son ampliamente usados, y han llegado a formar parte de herramientas de seguridad por las siguientes razones: • Debido a que la seguridad lógica esta concentrada en un solo programa, los Wrappers son fáciles y simples de validar. • Debido a que el programa protegido se mantiene como una entidad separada, éste puede ser actualizado sin necesidad de cambiar el Wrapper. • Debido a que los Wrappers llaman al programa protegido mediante la llamada al sistema estándar exec(), se puede usar un solo Wrapper para controlar el acceso a diversos programas que se necesiten proteger.

Historia del TCP Wrappers La historia del TCP Wrappers se remonta a 1990, cuando una de las máquinas de la Universidad de Eindhoven en Holanda era objeto de fuertes ataques por un Hacker alemán, que seguido obtenía privilegios de root. Cuando obtenía dichos privilegios introducía el comando "rm -rf /". El comportamiento destructivo de este individuo hacía muy difícil averiguar que estaba pasando, dado que "rm -rf" remueve cualquier huella. Una noche Venema noto que el Hacker lo estaba observando a través de la red, esto lo realizaba mediante el comando “finger”, el cual proporciona información de los usuarios de manera remota. Este tipo de servicio no requiere un password, y casi nunca mantiene un registro de su uso, por lo que fue el comienzo del diseño de un sistema que pudiera detectar y registrar información de las conexiones realizadas.

Esquema de trabajo Para explicar cómo trabaja el TCP Wrappers, primero necesitamos entender cómo funcionan los servicios de red TCP/IP en sistemas UNIX. Los servicios de red se basan en el modelo Cliente Servidor. Por ejemplo, cuando alguien usa el comando "telnet" para conectarse a un servidor, el demonio del proceso "telnet" dentro del server es ejecutada actuando así como servidor, dando al usuario la capacidad para poder accesar al sistema.

Lo más común en sistemas Server es correr un "Daemon” que espera por cualquier clase de conexión a través de la red. Cuando una conexión tiene lugar, este "Daemon" (Usualmente llamado “inetd” en Unix) corre el servicio apropiado y regresa a su estado latente, en espera de otras conexiones, como se ilustra en la figura: telnet cliente

telnet cliente

ftpd telnetd . . . fingerd

login

inetd

Una vez analizado el modo en que los servicios de red son inicializados en TCP/IP, veamos como lo hace TCP Wrappers: • El truco consiste en hacer un intercambio, se mueve el programa servidor de red a otro lugar, y se instala un programa trivial en lugar del servidor original de red. Siempre que una conexión tiene lugar, este programa registra el nombre del servidor remoto y entonces corre el servicio de red correspondiente como se ilustra: telnet cliente

TCP Wrappers

Archivo de Registro

telnetd

Esencialmente TCP-Wrappers se compone de 4 programas: •tcpd. Es el demonio del TCP-Wrappers. •tcpdmatch. Predice como el tcpd manejaría una petición en específico. •tcpdchk. Verifica las reglas de control de acceso contenidas en los archivos /etc/hosts.allow y /etc/hosts.deny. •safe_finger. Versión de finger para implementar el finger reversivo.

Dónde obtenerlo

Existen muchos lugares de donde obtener esta herramienta, pero los más conocidos son los siguientes: ftp://ftp.asc.unam.mx/pub/tools/tcp-wrappers.tar.gz ftp://ftp.win.tue.nl/pub/security/tcp_wrappers_7.6.tar.gz ftp://ftp.cert.org.pub/tools/tcp_wrappers/tcp_wrappers_7.6.tar.gz ftp://coast.cs.purdue.edu/pub/tools/unix/tcp_wrappers/tcp_wrappers_7.6.tar.gz

Instalación de TCP Wrappers 1. Descompactar el archivo tcp_wrappers_7.6.tar.gz para después extraer los archivos de esta herramienta. $ gunzip tcp_wrappers_7.6.tar.gz $ tar xvf tcp_wrappers_7.6.tar 2. Revisar en el archivo “/etc/inetd.conf” la ruta del directorio donde se encuentran los demonios de los servicios de red. finger telnet

stream stream

tcp tcp

nowait nowait

nobody root

/usr/sbin/in.fingerd in.fingerd /usr/sbin/in.telnetd in.telnetd

En este caso, se encuentran los demonios en /usr/sbin.

3. En el archivo Makefile buscar la cadena “REAL_DAEMON_DIR” donde aparecerán distintas opciones de rutas de directorios, descomentar la que corresponda al directorio obtenido en el punto anterior. En este mismo archivo buscar la cadena “FACILITY=LOG_MAIL” y sustituirla por “FACILITY=LOG_LOCAL0” a fin de que los mensajes generados por el “tcpd” se registren por separado de los generados por el sendmail y para habilitar las extensiones del lenguaje y las opciones de banners buscar la cadena “STYLE” y descomentar la línea. # SysV.4 Solaris 2.x OSF AIX REAL_DAEMON_DIR=/usr/sbin # FACILITY= LOG_LOCAL0 # LOG_MAIL is what most sendmail daemons use # #Optional: Turning on language extensions STYLE = -DPROCESS_OPTIONS # Enable language extensions.

4. Ejecutar el comando “make”; aparecerán las versiones de los sistemas operativos para los cuales el “tcpd” ha sido configurado. Ejecutar nuevamente “make s.o.” , donde “s.o.” es el sistema operativo de la máquina correspondiente. $ make linux Al terminar la compilación existirán en el directorio actual los archivos ejecutables tcpd, tcpdmatch, tcpdchk, try_from y safe_finger, los cuales serán copiados al directorio donde se encuentran los demonios de los servicios de red u otro directorio (en este caso /usr/sbin). $ mv tcpd tcpdmatch tcpdchk try_from safe_finger /usr/sbin

5. Editar el archivo "/etc/inetd.conf", sustituyendo todas las referencias a las rutas de los demonios de servicios de red que utilicen el protocolo TCP/IP por la ruta donde se encuentra el tcpd. Nota: hacer una copia de este archivo antes de editarlo finger telnet

stream stream

tcp tcp

nowait nowait

nobody root

/usr/sbin/tcpd /usr/sbin/tcpd

in.fingerd in.telnetd

6. Se recomienda mantener el registro de las conexiones hechas por el tcpd en un archivo o bitácora. Se debe agregar la siguiente línea al archivo de configuración "syslog.conf". local0.info /usr/local/adm/tcpd.log

La bitácora puede crearse con el comando touch. $ touch /usr/local/adm/tcpd.log

7. Reinicializar los demonios inetd y syslogd para que lean su nueva configuración de los archivos correspondientes. $ ps aux | egrep “inetd|syslogd” $ kill -HUP A partir de este momento, el “tcpd” debe registrar todos los accesos a los servicios para los que se haya activado su ejecución. $ telnet localhost $ cat /usr/local/adm/tcpd.log Sep 28 18:42:59 chela in.telnetd[29102]: connect from 127.0.0.1

Lenguaje de Control de Acceso Patrones El lenguaje de control de acceso implementa los siguientes patrones: •Una cadena que comience con el carácter ".” •Una cadena que termine con el carácter ".” •Una expresión de la forma "n.n.n.n/m.m.m.m" es interpretada como un patrón "dir_red/mascara", es decir, la dirección de una máquina cliente coincide si dir_red es igual al AND lógico de la dirección y la mascara.

Comodines El lenguaje de control de acceso soporta los siguientes comodines: ALL. Si este comodín aparece en la lista de demonios dentro de una regla de control de acceso, entonces coincide con cualquier nombre de demonios de red del sistema. Si aparece en la lista de clientes, entonces coincide con cualquier nombre o dirección de máquinas cliente. LOCAL. Este comodín coincide con cualquier cadena que no contenga el carácter ".", su principal uso se encuentra en la lista de clientes. Operador EXCEPT. EXCEPT funciona como un operador que tiene un uso esperado de la siguiente forma: lista_1 EXCEPT lista_2; lo cual coincide todo lo que se encuentre en la lista_1 a menos de que se encuentre en la lista_2.

Expansiones %a. Estos caracteres se expanden a la dirección de la máquina cliente. %h. Estos caracteres se expanden al nombre de la máquina cliente (o la dirección si el nombre no está disponible). %d. Estos caracteres se expanden al nombre del demonio del servicio de red correspondiente a la petición. %p. Estos caracteres se expanden al identificador del proceso del demonio del servicio de red correspondiente. %c. Este carácter se expande a la información del cliente ya sea el nombre de la cuenta junto con la dirección o nombre de la máquina cliente, dependiendo de cuánta información esté disponible.

Archivos de Control de Acceso El tcpd soporta una forma sencilla para controlar los accesos a los servicios ofrecidos por nuestro sistema, los cuales pueden ser manejados ya sea por máquina, por servicio o por combinaciones de ambos. El tcpd revisa qué servicio está siendo solicitado y desde dónde con base a reglas de control de acceso que se encuentran en los siguientes archivos (normalmente ubicados bajo el direectorio /etc): •hosts.allow. Contiene las reglas que especifican las maquinas y servicios que están autorizados •hosts.deny. Contiene las reglas que especifican las maquinas y servicios que NO están autorizados

Reglas Para el Control de Acceso Cada uno de los archivos de control de acceso consiste de cero o más líneas con el siguiente formato: list-daemons : list-hosts [ : comando-shell ] donde: list-daemons es una lista de los nombres de los demonios (servicios). list-hosts es una lista de nombres, direcciones, o patrones de hosts que serán comparados con el nombre o dirección del host cliente que realiza la petición del servicio. Esta comparación se realiza de manera secuencial, línea por línea empezando por el archivo hosts.allow y terminando por el archivo hosts.deny. La búsqueda se suspende cuando una regla de control de acceso es activada. comando-shell es un comando que podemos ejecutar, normalmente se utiliza para implementar anzuelos.

Ejemplos de Archivos de Configuración Ejemplo 1 /etc/host.deny # Niega todos los servicios a todas las maquinas cliente a menos de que # estén especificadas en el archivo hosts.allow ALL:ALL

/etc/hosts.allow # En la primera regla se permite el acceso a los servicios de finger y ftp # solamente al dominio .labvis.unam.mx in.fingerd, in.ftpd:.labvis.unam.mx # En la segunda regla se permite el acceso a todos los servicios de red # solamente a máquinas que van desde la 132.248.170.8 a la 132.248.170.255 ALL:132.248.170.

Archivo tcpd.log Sep 25 20:57:04 chela in.fingerd[1698]: connect from 132.248.159.3 Sep 25 20:59:24 chela in.telnetd[1706]: refused connect from 132.248.159.3 Sep 25 21:02:38 chela in.fingerd[1721]: connect from 132.248.170.8 Sep 25 21:03:50 chela in.fingerd[1727]: refused connect from themis.derecho.unam.mx

Ejemplo 2 /etc/hosts.deny # Niega todos los servicios a todos las máquinas excepto a una en # específico: 132.248.170.8 ALL:ALL EXCEPT 132.248.170.8

Archivo tcpd.log Sep 22 13:35:44 chela in.fingerd[18227]: refused connect from 132.248.170.9 Sep 22 13:37:39 chela in.fingerd[18235]: connect from 132.248.170.8

Ejemplo 3 /etc/hosts.deny # Solamente se permite el servicio de finger para todo mundo excepto # para la máquina 132.248.170.8 ALL EXCEPT in.fingerd:ALL EXCEPT 132.248.170.8

Archivo tcpd.log Nov 22 14:08:35 chela in.fingerd[18371]: connect from 132.248.159.3 Nov 22 14:09:01 chela in.telnetd[18376]: refused connect from 132.248.159.3

Ejemplo 4 /etc/hosts.deny # No se permite el acceso a los hosts que van desde la # dirección 132.248.159.0 hasta la 132.248.159.7 ALL:132.248.159.0/255.255.255.248

Archivo tcpd.log Nov 24 16:04:33 chela in.ftpd[28591]: refused connect from 132.248.159.3 Nov 24 16:05:04 chela in.ftpd[28595]: connect from 132.248.159.21

Ejemplo 5 /etc/hosts.allow # Se permite el acceso a todo mundo menos a las m'aquinas de la red local ALL:ALL EXCEPT LOCAL

Archivo tcpd.log Aug 16 23:59:42 chela in.telnetd[13347]: refused connect from whisky

Ejemplo 6 /etc/hosts.allow # Se permite el acceso a los dominio labvis.unam.mx a todos los servicios # de red y el servicio ftp solo al dominio super.unam.mx ALL:.labvis.unam.mx in.ftpd:.super.unam.mx

Anzuelos TCP-Wrappers brinda anzuelos para la ejecución de comandos de shell cuando una regla para el control de acceso es activada.Consideremos la siguiente línea del “hosts.deny”: ALL:ALL: (/usr/sbin/safe_finger -l @%h | /bin/mail root)

En este caso se niega el acceso a todas las máquinas para todos los servicios de red en el sistema y además se implementa el finger recursivo, es decir se hace un finger a la máquina cliente y la salida es enviada por correo electrónico a un usuario determinado. Date: Wed, 26 Nov 1997 19:37:29 -0600 From: root To: [email protected] [themis.derecho.unam.mx] Login name: gacarran No Plan.

In real life: Carranza Guerrero Gabriela A.

Banners Esta opción nos permite ser mas corteses cuando negamos la petición de servicios a máquinas cliente. Habilitación de la opción de Banners. Copiar el archivo “Banners.Makefile” que viene en la distribución del TCP-Wrappers en el directorio donde residirán nuestros banners. Dentro de este directorio crear y editar los archivos correspondientes a cada servicio con su respectivo mensaje. Editar el archivo “Banners.Makefile” en donde se puede identificar fácilmente la parte correspondiente a cada servicio de red. Sustituir la palabra “prototype” por el nombre del archivo que contenga el mensaje de acuerdo al servicio de red correspondiente.

Ejecutar el comando “make” para que actúe sobre el archivo Banners.Makefile. Al finalizar el comando make, se habrán creado los archivos con el nombre de los servicios de red (in.ftpd, in.telnetd en el caso de Linux) los cuales contienen los mensajes en un formato adecuado para que sean manejados por los demonios de los servicios de red.

¿Qué es Secure Shell? ¿Dónde obtenerlo? Versiones de secure shell Instalación de secure shell Binarios básicos de Secure shell Operación de secure shell.

¿Qué es Secure Shell? Secure Shell (Ssh) es un programa que permite realizar conexiones con otras máquinas a través de alguna red, ejecutar programas en una máquina remota, y mover archivos de una máquina a otra, de forma segura. Ssh provee fuerte autenticación y comunicación segura sobre un canal inseguro. Este es un remplazo a los comandos rlogin, rsh, y rcp.

Adicionalmente, SSH provee seguridad para conexiones de servicios X Window y envio seguro de conexiones arbitrarias TCP.

Los servicios r (rlogin, rsh, rcp) son vulnerables a cierto tipo de ataques. Cualquiera que tenga acceso de root a una máquina en la red, o acceso físico a la red de cómputo, puede obtener acceso no autorizado por una gran variedad de formas, además de poder obtener información de ingresos a máquinas “escuchando” (sniffer) el trafico sobre la red, esto incluye los password ( con ssh esto no es posible).

El sistema X window tiene varias vulnerabilidades. Con ssh, se puede crear una sesión X remota segura que permanece transparente al usuario.

Ssh protege de los siguientes tipos de ataques: • IP spoofing, donde un host remoto envía paquetes a otro host aparentando ser un tercer host. • Ruteo de IP spoofing, donde un host puede pretender que un paquete de IP proviene de otro hosts valido. • DNS spoofing, cuando un ataque provoca que los registros de servidor de nombre se pierdan. • Intersección de password en claro, u otra información intercambiada entre dos hosts. • Manipulación de datos que se encuentran en intercambio entre hosts.

Protocolos de Secure Shell Características del protocolo de Autenticación: • Mecanismo de negociación y autenticación. •Soporte de múltiples mecanismos de autenticación. •Soporte de banner pre-autenticación. •Autenticación basada en llave de cliente. Características del protocolo de conexión: •Paso de variables de ambiente. •Agente de autenticación. •Control de flujo y señales.

Características del protocolo de Transporte.

•Corre sobre TCP/IP, pero puede trabajar sobre UDP. •Manejo de regeneración de llaves. •Verificación de identidad de cliente de servicio utilizando llave pública de cifrado. •Negociación a través de mecanismo de secreto compartido

¿Qué algoritmos de cifrado utiliza SSH? Ssh proporciona las siguientes opciones de cifrado: • DES • 3DES • IDEA • Blowfish • Twofish

Ssh usa los siguientes cifrados para autenticación: • RSA • DSA

¿Cómo Ssh autentifica? Ssh autentifica utilizando uno o mas de los siguientes métodos: • Llave pública (RSA o DSA). • Password. • Kerberos. • .rhosts o /etc/hosts.equiv. Cuando inicia una sesión, ssh establece comunicación con el servidor de ssh (sshd), y posteriormente intenta autentificar al usuario utilizando la siguiente secuencia.

Primero, si la máquina local del usuario se encuentra en los archivos /etc/hosts.equiv o /etc/ssh/shosts.equiv del servidor remoto, y además el login del usuario es el mismo en ambas máquinas, la entrada del usuario es permitida inmediatamente. Segunda, si en el home del usuario de la máquina remota existe alguno de los archivos .rhosts o .shosts y este archivo contiene una línea con el nombre de la máquina cliente y el login del usuario, cumpliendose estos requisitos se permite la entrada del usuario. Estos dos métodos presentan riesgos de seguridad, estos riesgos puede ser reducidos si se utiliza una combinación de estos junto con una autenticación basada en RSA. Esto significa que el usuario solo obtendrá el acceso, si la máquina

es reconocida por /etc/hosts.equiv, /etc/ssh/shosts.equiv, .rhosts, .shosts, y además puede verificar la llave del hosts cliente: ($HOME/.ssh/known_hosts o /etc/ssh/ssh_known_hosts). Ejemplo: tutor.asc.unam.mx 1024 33 498339755842586657267109283152616088353241547574402687538560178 955256983984658064352705706822150671493163137462289309920741813 015594790641160363431690762872947160309555468936674856086281614 467129286485467651617448973081072952981758412749663954979538714 82229373472020415572629866029345549440297168066150844263

Este método cierra los huecos tipo IP spoofing, DNS spoofing, Routing spoofing.

Un tercer método de autentificación se basa en Autentificación RSA. El servidor conoce la llave pública y solo el usuario conoce la llave privada. El archivo $HOME/.ssh/authorized_key contiene una lista de las llaves públicas de los hosts que son permitidos tener acceso a este servidor. Ssh implementa el protocolo automático de autenticación RSA. Cuando un usuario intenta tener acceso a esta máquina el programa ssh transmite al servidor la llave pública esperando que sea utilizada para la autentificación, el servidor verifica si la llave es permitida, y si esto es así, enviará un número generado de manera aleatoria utilizando esta llave pública, este número solo puede ser descifrado con la llave privada, si esto lo logra el hosts cliente la comunición se establece. El usuario crea un par de llaves ejecutando ssh-keygen. La manera en que se genera esto se proporcionará más adelante.

Si cualquier método de autenticación falla, ssh solicitará al usuario el password. El password es enviado al host remoto para su verificación por el canal cifrado.

Ejemplo de negociación de ssh cliente/servidor. SSH Version 1.2.27 [alpha-dec-osf4.0], protocol version 1.5. Standard version. Does not use RSAREF. ejemplo.asc.unam.mx: Reading configuration data /etc/ssh_config ejemplo.asc.unam.mx: ssh_connect: getuid 254 geteuid 0 anon 0 ejemplo.asc.unam.mx: Connecting to tutor [132.248.159.13] port 22. ejemplo.asc.unam.mx: Allocated local port 1019. ejemplo.asc.unam.mx: Connection established. ejemplo.asc.unam.mx: Remote protocol version 1.5, remote software version 1.2.27 ejemplo.asc.unam.mx: Waiting for server public key. ejemplo.asc.unam.mx: Received server public key (768 bits) and host key (1024 bits). ejemplo.asc.unam.mx: Host 'tutor' is known and matches the host key.

ejemplo.asc.unam.mx: Host 'tutor' is known and matches the host key. ejemplo.asc.unam.mx: Initializing random; seed file /usr/users/tutor/.ssh/random_seed ejemplo.asc.unam.mx: Encryption type: idea ejemplo.asc.unam.mx: Sent encrypted session key. ejemplo.asc.unam.mx: Installing crc compensation attack detector. ejemplo.asc.unam.mx: Received encrypted confirmation. ejemplo.asc.unam.mx: Trying rhosts or /etc/hosts.equiv with RSA host authentication. ejemplo.asc.unam.mx: Server refused our rhosts authentication or host key. ejemplo.asc.unam.mx: No agent. ejemplo.asc.unam.mx: Trying RSA authentication with key '[email protected]' ejemplo.asc.unam.mx: Server refused our key. ejemplo.asc.unam.mx: Doing password authentication. [email protected] password:

¿Dónde obtenerlo?

Un lugar de donde podemos obtener ssh versión 1.2.27: ftp://ftp.asc.unam.mx/pub/tools/ssh.tar.gz Nota: En cualquiera de estos caso se obtiene acceso por anonymous.

Versiones de Secure Shell Hay dos protocolos desarrollados sobre ssh estos son: SSH1: Este protocolo lo encontramos en la versión Unix es la 1.2.27 que puede ser utilizada libremente para propósitos no comerciales. SSH2: Provee licencias mas estrictas que SSH1, la versión Unix de ssh es la 2.0.13 puede ser utilizada libremente por instituciones educativas bajo una licencia expresa. Cabe destacar que los algoritmos RSA y IDEA, que son utilizados en ssh, son reclamadas como patentes en diferentes paises, incluyendo US, asi que su uso puede ser legal o no, todo dependiendo de la legislación. En algunos paises (Rusia, Iraq, y Pakistan) es ilegal el uso de cualquier algoritmo de cifrado.

Instalación de Secure Shell Después de haber obtenido el paquete de secure shell versión 1.2.27 -versión libre - procedemos a desempaquetarlo: $gunzip ssh.tar.gz $tar -xvf ssh.tar. En este punto obtendremos un directorio ./ssh-1.2.27/ sobre el punto donde desempaquetamos. A continuación se citan los pasos necesarios para obtener los binarios de ssh, compilando los fuentes: a) Configuración del entorno de compilación. A diferencia de otras herramientas ssh no requiere de editar los archivos Makefile, la configuración la realizamos a través de los parámetros que le pasemos al script configure.

Dentro del directorio ./ssh-1.2.27/ encontraremos el script configure, el cual tiene los siguientes argumentos validos: --prefix=PREFIX

Donde se instalar los binarios por default /usr/local.

--exec_prefix=PREFIX

Donde instalara los ejecutables por default el mismo que prefix.

--with-rsh=PATH

Usar especificaciones rsh cuando sea necesario

--without-idea

No incluir IDEA

--with-tis=PATH

Soporte a mecanismo de autentificación TIS authsrv.

--with-etcdir=PATH

Donde obtendra información sobre el sistema por default /etc.

--with-libwrap=[PATH]

Usa libwrap (tcp_wrappers) y identd.

--with-socks4[=PATH]

Incluye soporte para SOCKS (Cruce de firewall).

--with-socks5[=PATH]

Incluye soporte para SOCKS5.

--enable-warnigs

Habilita la bandera -Wall al compilador gcc.

Ejemplo: Si nuestra intención es lograr que tcp-wrapper lleve un control sobre los accesos realizados con ssh, se necesitará la bandera -with-libwrap, ademas se pretende realizar autenticar la maquina para ejecutar comandos rsh, se requiere entonces la bandera -with-rsh.

$./configure --wit-libwrap --wit-rsh=/path/to/rsh.

Para obtener la ruta a rsh utilizar el comando whereis. Esto genera los cambios necesarios en los archivos de código fuente para su correcta compilación.

b) Compilar los binarios de secure shell. Para esto basta con ejecutar: $make c) Obtener las llaves del host así como los archivos de configuración del sistema, para esto ejecutar: $make install Obteniendo los archivos: /etc/ssh_host_key /etc/sshd_config

d) Ya que obtuvimos los binarios del sistema procedemos a configurar el sistema para poder ejecutar el demonio del servidor de ssh y permitir accesos por el puerto por default de secure shell (port 22). d.1) Editar el archivo /etc/inetd.conf e incluir la siguiente línea: (si se tiene demonio de tcp-wrapper) ssh tcp root nowait /usr/local/sbin/tcpd /usr/local/sbin/sshd -i

(Si no se tiene habilitado tcp-wrapper) ssh tcp root nowait /usr/local/sbin/sshd /usr/local/sbin/sshd -i

d.2) Editar el archivo /etc/services y habilitar el puerto de secure shell, usando la siguiente línea: ssh

22/tcp

ssh

22/udp

e) Por ultimo Reiniciar el demonio de inetd. e.1) Obtener el proceso de inetd. $ps -fea | grep inetd e.2) Enviar señal HUP. $kill -HUP proceso En este punto el sistema debe responder las peticiones de conexión por secure shell.

Operación de Secure Shell Generando llave de autentificación El primer paso que se debe hacer es generar la llave de autenticación mediente el uso del comando ssh-keygen. Para esto se debe decidir de antemano una frase que sea facil de recordar. Ejemplo: $ssh-keygen Initializing random number generator... Generating p: .++ (distance 6) Generating q: ........++ (distance 110) Computing the keys... Testing the keys... Key generation complete.

Enter file in which to save the key ($HOME/.ssh/identity): [RETURN] Enter passphrase (empty for no passphrase): secure shell Enter same passphrase again: secure shell Your identification has been saved in /users/tutor/.ssh/identity. Your public key is: 1024 37 [lots of numbers] [email protected] Your public key has been saved in /users/tutor/.ssh/identity.pub

Modificando la frase de password. Para lograr modificar la frase debe utilizarse la opción -p de ssh-keygen.

$ssh-keygen -p Enter file in which the key is ($HOME/.ssh/identity): [RETURN] Enter old passphrase:secure shell Key has comment ’[email protected]' Enter new passphrase (empty for no passphrase): linux red hat Enter same passphrase again: linux red hat Your identification has been saved with the new passphrase.

Accesos autorizados Para permitir accesos al sistema hay que colocar la llave publica en el archivo ~/.ssh/authorized_keys. Todas las llaves listadas en este archivo tendrán acceso al sistema.

Entrada remota al sistema.

Para establecer una conexión a un sistema remoto debe utilizarse el comando ssh. Si el nombre de la cuenta es el mismo que el de la máquina local basta solamente usar como argumento el nombre del sistema remoto. $ssh tutor.remoto Enter passphrase for RSA key ’[email protected]': litt1e 1amp jumb3d Last login: Wed Oct 16 20:37:00 1996 from idefix [more output from the remote machine] Puede evitarse la frase password manteniendo la llave de autentificación en memoria. Solamente se necesita utilizar sshadd. $ssh-add

La opción -d elimina la llave de memoria. $ssh-add -d ~/.ssh/isp Para obtener una lista de todas las llaves que mantenemos en memoria usamos la opción -l. $ssh-add -l Para borrar todas las llaves que se mantienen en memoria usamos la opción -D. $ssh-add -D Copiando archivos entre máquinas. Pueden copiarse archivos entre sistemas utilizando el comando scp. Para especificar un archivo en un sistema remoto simplemente será el nombre del sistema remoto seguido de dos puntos (:)

Ejemplos: $scp tutor@maquina:/tmpu/archivo /copias/ En este caso entrará a maquina remota con la cuenta tutor en el directorio /tmpu/ y obtendrá el archivo que colocará en el directorio local /copias/.

$scp /copias/archivo tutor@maquina:~/bck/ En este caso realizará una copia desde un archivo local /copias/archivo a una maquina remota colocando el archivo en el directorio bck del home de tutor.

Sesión entre máquinas

Ssh permite mantener sesiones interactivas con una máquina remota, de la forma del comando telnet, esto podemos realizarlo de la siguiente forma: $ssh -l login maquina. La opción -l permite proporcionar el login con el que se entrará a la cuenta de la maquina remota. En caso de mantener el mismo login en ambas máquinas no se requiere este parametro -l. $ssh maquina

Cifrado de Datos

Introducción Historia Descripción General Cómo Funciona Ataques y Problemas Versiones Cuál Usar PGP 2.6.3i

Introducción Hasta tan sólo 25 años, el intercambio de mensajes cifrados era todavía un privilegio reservado a militares, diplomáticos y servicios secretos. Los modernos sistemas de llaves públicas establecieron las bases para acercar esta potente tecnología al gran público, pero fue el lanzamiento en 1991 del popular programa PGP, el que hizo por fin realidad el acceso de las masas a las ventajas del correo electrónico ultrasecreto. Los dos millones de usuarios cosechados desde entonces pueden convertirse ahora en mucho más, gracias a la facilidad de uso que aporta PGP.

Problemas con el correo •Los mensaje no puede ser entregado y acaba en el buzón del administrador del sistema de correo, que puede o no leerlo. • En otras ocasiones, alguien puede interferir el mensaje en su largo trayecto por la red. Además de leerlo, puede incluso modificarlo y reenviarlo a su destino. Las consecuencias pueden ser variadas. • También existen determinadas personas u organizaciones que pueden escanear, de forma simple y automatizada, grandes cantidades de mensajes, quizás buscando información sensible (números de tarjetas de crédito, etc.) ¡Hay demasiados "sniffers" ahí fuera!

El uso de PGP en el correo electrónico aporta significativas ventajas que no conviene pasar por desapercibido: • Evita todos los inconvenientes que hemos reseñado previamente. • Hace valer el Derecho Constitucional a la Intimidad de nuestras comunicaciones. •Contribuye a que el cifrado de los mensajes se convierta en una práctica común en Internet.

PGP garantiza el secreto de las comunicaciones electrónicas para todos los ciudadanos, y no sólo para los servicios secretos de las Grandes Potencias o los grandes delincuentes. Por ello, la legalidad de su empleo varía en los diferentes países, en función de cómo se respeten las libertades en ellos. Así, en Estados Unidos, el país de origen del creador de PGP, el uso de PGP es legal, pero se prohibe la exportación del programa a otros países, al considerar la criptografía al mismo nivel que el armamento. Es por esto que nunca debe de obtenerse PGP en ningún sitio de ese país, y tiene que utilizar la Versión Internacional que fue desarrollada precisamente para disfrutar de PGP en el resto del mundo.

En México, la Constitución reconoce el derecho al secreto en las comunicaciones privadas, y el nuevo Código Penal extiende ese derecho al correo electrónico. Por tanto, el uso de PGP es legal en México. Esta es, por cierto, la situación habitual en el mundo libre.

Historia La llegada de las computadoras comienza a complicar las cosas. Asimismo, la Segunda Guerra Mundial hace que los países en contienda se interesen en la criptografía, desarrollando máquinas de cifrado entre las que podrían destacarse las máquinas Enigma del ejército alemán. Los algoritmos empiezan a utilizar llaves aleatorias, y gracias a diversos avances en la investigación y el incremento tan rápido de las potencias de cálculo se ha llegado a algoritmos por ahora indestructibles como IDEA, diseñado en el instituto ETH de Zurich en 1990 por James L. Massey y Xuejia Lai.

Paralelamente, surge otro tipo de criptografía, la criptografía de llave pública. Su historia comienza en 1976, cuando Whitfield Diffie y Martin Hellman desarrollan el algoritmo DH. Al año siguiente, 1977, Ron Rivest, Adi Shamir y Leonard Adleman, del Massachussets Institute of Technology (MIT) diseñan un nuevo algoritmo muy potente, el RSA. Y tan potente era que la Agencia de Seguridad Nacional (NSA) del Gobierno americano les sugiere no publicarlo. Haciendo caso omiso, y sobre todo por temor a que más adelante no se les sugiriese, sino que les prohibiese, publican el algoritmo en la revista Scientific American. El algoritmo es patentado a nombre de la compañía RSA Data Security Inc., siendo válida esta patente en Estados Unidos y Canadá.

Unos años después Ron Rivest diseña un algoritmo para producir extractos cifrados de mensajes (en inglés, message digests), el MD5, siendo utilizados para comprobar que los mensajes no han sido alterados. En 1991 empieza a extenderse el rumor en Estados Unidos de que el Gobierno quiere prohibir el empleo de la criptografía en líneas de comunicación, por ello, el programador Phillip Zimmermann, combinando el mejor algoritmo existente de llave única, IDEA, con el mejor de llave pública, el RSA, y añadiendo el MD5 para las firmas digitales, crea el programa PGP y lo distribuye como freeware por decenas de BBSs.

Un tiempo más tarde surgiría el conflicto. Alguien envió en junio de 1991 a varios grupos de USENET una copia de PGP, y así empezó a distribuirse y utilizarse fuera de Estados Unidos, incumpliendo la legislación ITAR del Departamento de Estado americano sobre exportación de armas Se llegó a una solución doble. Se crearon dos versiones paralelas de PGP: las de uso exclusivo para Estados Unidos y Canadá, que emplean una biblioteca de funciones, la RSAREF, de RSA Data y que no son exportables a otros países, encargándose el MIT de la distribución gratuita del PGP; y las de uso internacional (identificadas añadiendo al número de versión una i), que emplean la biblioteca MPILIB de Zimmermann y que desde la primera versión salida de Estados Unidos han sido desarrolladas en Europa para ahorrarle más quebraderos de cabeza a Zimmermann.

Descripción General PGP (Pretty Good Privacy, “intimidad bastante buena”), de Phil's Pretty Good Software, es el programa más extendido y acreditado para el cifrado del correo electrónico. En la práctica, utilizarlo equivale a dotar al correo de valores añadidos del máximo interés: • confidencialidad • autentificación • integridad En pocas palabras: con PGP se dejan de sufrir las múltiples carencias del correo electrónico ordinario y se pasa a disfrutar de todas las ventajas del correo electrónico seguro.

PGP hace uso de los algoritmos criptográficos más potentes del momento. Aunque la criptografía es un campo extenso y complejo. PGP combina la comodidad del criptosistema de llave pública de Rivest-Shamir-Adleman (RSA) con la velocidad de la criptografía convencional, con resúmenes de mensajes para firmas digitales, con compresión de datos antes de cifrar, con un buen diseño ergonómico y con una completa gestión de llaves. Por otra parte, PGP realiza las funciones de llave pública con más rapidez que la mayoría de las demás implementaciones informáticas. PGP es criptografía de llave pública para todos.

PGP versión Internacional es un programa GRATUITO para usos no comerciales, está disponible para muchas plataformas diferentes: MS-DOS, Windows, Unix, MacOS, Atari, Amiga, OS2, etc, y la instalación de PGP en su computadora aportará nuevas funciones con las cuales nadie, absolutamente nadie, podrá leer su correo electrónico (aparte del destinatario que indique, como es lógico) e impedirá que alguien pueda suplantar su identidad en Internet, pues sus mensajes llevarán su propia y exclusiva firma digital, la cual es un bloque de caracteres que acompaña a un documento o archivo, acreditando quién es su autor ("autenticación") y que no ha existido ninguna manipulación posterior de los datos ("integridad").

Cómo Funciona

En primer lugar, algo de vocabulario básico. Supongamos que quiero enviarte un mensaje que nadie excepto tú puedas leer. Podría "cifrar" el mensaje, lo que significa revolverlo de una forma tremendamente complicada, con el fin de que resulte ilegible para cualquiera que no seas tú, el destinatario original del mensaje. Yo pongo una "llave" criptográfica para “cifrar” el mensaje y tú tienes que utilizar la misma llave para “descifrarlo”. Por lo menos así funciona en los criptosistemas convencionales de "llave única".

En criptosistemas de llave pública, todo el mundo tiene dos llaves complementarias, una revelada públicamente y otra secreta (llamada también llave privada). Cada llave abre el código que produce la otra. Saber la llave pública no sirve para deducir la llave secreta correspondiente. La llave pública puede publicarse y distribuirse ampliamente por una red de comunicaciones. Este protocolo proporciona intimidad sin necesidad de ese canal seguro que requieren los criptosistemas convencionales. Cualquiera puede utilizar la llave pública de un destinatario para cifrar un mensaje y él empleará su llave secreta correspondiente para descifrarlo. Sólo él podrá hacerlo, porque nadie más tiene acceso a esa llave secreta. Ni siquiera la persona que lo cifró podría descifrarlo.

También proporciona autenticación para mensajes. La llave secreta del remitente puede emplearse para cifrar un mensaje, "firmándolo". Se genera una firma digital, que el destinatario (o cualquier otra persona) puede comprobar al descifrarla con la llave pública del remitente. De esta forma se prueba el verdadero origen del mensaje y que no ha sido alterado por nadie, ya que sólo el remitente posee la llave secreta que ha producido esa firma. No es posible falsificar un mensaje firmado y el remitente no podrá desautorizar su firma más adelante.

Estos dos procesos pueden combinarse para obtener intimidad y autenticación al mismo tiempo si se firma primero el mensaje con la llave secreta y se cifra después el mensaje firmado con la llave pública del destinatario. El destinatario sigue estos pasos en sentido contrario al descifrar primero el mensaje con su propia llave secreta y comprobar después la firma con la llave pública del remitente. El programa lo hace automáticamente.

PGP utiliza "resúmenes de mensaje" para elaborar las firmas. Un resumen de mensaje es una función "distribución" ("hash") unidireccional de 128 bits, criptográficamente resistente, de ese mensaje. Es análogo a una "suma de verificación" o código CRC de comprobación de errores: "representa" el mensaje de forma compacta y se utiliza para detectar cambios en él. A diferencia de un CRC, sin embargo, resulta computacionalmente impracticable para un atacante idear un mensaje sustitutivo que produzca un resumen idéntico. El resumen del mensaje se cifra con la llave secreta para elaborar la firma. Los documentos se firman añadiéndoles como prefijo un certificado de firma, junto con el identificador de la llave que se utilizó para realizarla, un resumen de mensaje del documento (firmado con la llave secreta) y un sello de hora del momento de la firma. El destinatario utiliza el identificador de la llave para buscar la llave pública del remitente y comprobar la firma.

Ataques y Problemas PGP ha demostrado ampliamente su gran seguridad, y todavía ningún experto ha podido romper sus llaves. Sin embargo, por razones ajenas al programa y que caen fuera de sus posibilidades, puede no ser impenetrable en algunos casos a los ataques destinados a hacerse con nuestros datos. El principio fundamental que hay que tener en mente es si la información que se protege es más valiosa que los medios para obtenerla para aprender a defenderse de los ataques poco costosos e ignorar los caros. Algunos de los planteamientos que se van a presentar pueden parecer paranoicos, pero ser paranoico es algo recomendable en cuestiones de seguridad.

Descubrimiento de la pass-phrase (Frase secreta) Archivos no del todo borrados Virus y caballos de Troya Fallos de seguridad "físicos” Escuchas Inseguridad en equipos multiusuario Análisis del tráfico Criptoanálisis

Versiones Llegados a este punto hay que destacar el considerable desconcierto que aparece con las diferentes versiones de PGP existentes. Debido a la política existente en Estados Unidos en lo referente a exportación de material criptográfico, han ido surgiendo diferentes versiones de PGP y diferentes legislaciones para su uso.

Versiones Freeware de PGP • PGP 2.3a • PGP 2.6ui • PGP 2.62ui • MIT PGP 2.6.2 • PGP 2.6.3i • PGP 5.0i • PGP 5.5.3i • PGP 6.0.2i

Versiones comerciales de PGP (para Estados Unidos y Canadá únicamente)

• ViaCrypt PGP 2.7.1 y 4.0 Al ser comercial incluye manual, licencia de uso individual. No incluye fuentes. • PGP 4.5 y 5.0 En Junio de 1996 PGP Inc. compra ViaCrypt y comienza a desarrollar versiones comerciales de PGP para los Estados Unidos y Canadá. La versión más reciente es PGPMail 4.5.

Cuál Usar El mejor consejo que se puede dar para los que decidan usar las nuevas versiones 5.xi y asegurarse de la compatibilidad con todas las versiones, es que deberían tener dos pares de llaves, una RSA para mantener la compatibilidad, y otra DSS/DH para utilizar los nuevos avances de la criptografía y las nuevas versiones 5.xi y 6.xi al máximo, pudiendo así funcionar con dos llaves usando RSA cuando tengan que intercambiar correo cifrado con usuarios de versiones antiguas.

Los que han estado usando versiones antiguas y se cambien a la nueva pueden mantener su antigua llave RSA y generar un par nuevo DSS/DH y desde PGPKeys seleccionar una u otra por defecto para mantener la compatibilidad. Y los que empiecen desde cero tendrán que crear el parde llaves RSA con la versión 2.6.3i ya que la nueva versión 5.0i NO puede generar llaves RSA, si quiere usar PGP con usuarios de versiones anteriores, esta subsanado en la nueva versión 5.5.3i que ya puede generar llaves RSA.

PGP 2.6.3i Se trata de la versión más clásica de PGP 100% compatible con las versiones de PGP del MIT, que lleva ya algunos años en la brecha, pero sigue igual de potente, versátil y segura. No obstante, la utilidad de esta versión clásica de PGP ha quedado muy limitada ante la aparición de versiones mucho más modernas y elaboradas, y ha dejado de ser una elección adecuada para el usuario normal de PGP. PGP 2.6.3i puede leer y entender mensajes, llaves y firmas creadas con cualquier versión de PGP 2.x. Debido a que PGP 2.6.3i usa MPILIB en vez de RSAREF, todavía es capaz de entender el viejo formato de firma de llaves de las versiones PGP 2.2 y anteriores. No obstante, no puede escribir tales firmas.

PGP 2.6.3i no es un programa oficial ya que fue basado en un código fuente que una vez fue exportado ilegalmente desde los EEUU. Sin embargo, una vez que el programa ha sido exportado, cualquiera puede usarlo libremente. Phil Zimmermann, el autor original de PGP, ha emitido una declaración pública sobre PGP 2.6.i (el predecesor a PGP 2.6.3i), la cual posiblemente es lo más próximo a un apoyo que él podría efectuar sin incriminarse a sí mismo. Es perfectamente legal usar PGP 2.6.3i siempre y cuando no viva en un país donde la codificación es ilegal (tal como Francia, Rusia, Irán, Iraq o China), no se encuentre físicamente dentro de los EEUU o se asegure que no bajó una copia de PGP que se encuentre físicamente dentro de los EEUU.

Existir versiones GRATIS para MS-DOS/Windows, Mac y Unix; PGP está también disponible para otras plataformas menos habituales: • OS/2 • Amiga • Atari • VAX/VMS

PGP 2.6.3i en Unix “Introducción” Internet es una red totalmente heterogénea, en cuanto a máquinas, sistemas operativos, programas, etc., así pues PGP está disponible para las principales plataformas, UNIX, MSDOS, Windows ( 95, NT ) Macintosh etc. En esta sección trataremos sobre la instalación para sistemas UNIX que comprende diferentes versiones (en general cada fabricante de equipos ha desarrollado su propia versión de UNIX), AIX (IBM), HP-UX (Hewlett Packard), IRIX (Silicon Graphics), SunOS, SOLARIS (SUN Microsystems ), Digital Unix (DEC) etc. Junto a estos sistemas comerciales se han desarrollado versiones de Unix de libre distribución como son Linux, FreeBSD, NeTBSD, etc, muy usadas en PC's compatibles con procesadores 386,486 o Pentium.

Antes que nada es necesario compilar el programa antes de que podamos usarlo. Esto es habitual en el mundo UNIX, debido a que es un sistema que funciona en maquinas completamente diferentes con sistemas a su vez diferentes, de manera que la única forma de que un programa pueda funcionar en todas ellas sin tener que hacer una versión específica para cada una es obtener el código fuente del programa y compilarlo en tu máquina "a medida". No obstante y teniendo en cuenta la popularidad de determinados sistemas Unix (sobre todo Linux, por ser de libre distribución y funcionar en múltiples plataformas) se han elaborado "paquetes" ya compilados con el programa PGP listo para instalar, lamentablemente los paquetes suelen depender de la versión de Unix, e incluso dentro de Linux hay varios formatos.

Hay que seguir tres pasos para poder usar PGP en UNIX cómodamente:

•Conseguir el programa en código fuente •Compilarlo en nuestra máquina •Instalarlo

“Dónde conseguirlo” Bien; lo primero que necesitaremos es conseguir el programa; como es de libre distribución, lo podremos encontrar en muchos servidores de FTP anónimo. El nombre del archivo podrá ser "pgp263is.tar.gz" ó "pgp263is.tgz", donde la "s" indica que es código fuente (source) y la extensión "tgz" ó tar.gz ( son equivalentes ) indica que han sido comprimidos con el programa "gzip" y empaquetados con el programa "tar" ambos muy comunes en las máquinas UNIX. • ftp://ftp.asc.unam.mx/pub/tools/pgp.tar.gz

“Primeros pasos de la instalación” Ya que tenemos el programa, vamos a descomprimirlo y desempaquetarlo, simplemente tecleando en la línea de comandos: $ gzip -d pgp263is.tar.gz con este comando lo hemos descomprimido, ahora nos queda el nombre sin la extensión "gz" es decir pgp263is.tar, para desempaquetarlo ejecutamos el siguiente comando: $ tar xvf pgp263is.tar

Esta acción crea cinco archivos (varios "readme", una firma digital y notas de la distribución) y otro archivo empaquetado con "tar", llamado "pgp263ii.tar" que contendrá todo el código fuente del programa, la documentación necesaria y el resto de archivos. Así pues lo desempaquetamos de nuevo: $ tar xvf pgp263ii.tar En este caso nos creará muchos más archivos y tres directorios "doc", "contrib" y "src" donde estarán contenido los archivos fuentes. Nos cambiamos a este último directorio y nos prepararemos para compilar el PGP. $ cd src

“Compilar PGP” Como casi siempre en UNIX, los programas se compilan usando el programa "make". Vamos a proceder a compilar PGP, pero previamente debemos saber con exactitud qué sistema UNIX estamos usando, pues la compilación varía de un sistema a otro. Si no sabemos qué UNIX tenemos, podemos usar el siguiente comando: $ uname -a Para compilar, usaremos el comando "make" en la forma: $make <sistema_unix>, donde <sistema_unix> es uno de los que están definidos en el archivo "makefile" del PGP y que podemos ver tecleando "make" a secas.

Así pues, si nuestro sistema es por ejemplo Linux funcionando en un PC, teclearíamos: $ make linux Y comenzaría la compilación, que puede tardar unos cuantos minutos dependiendo de lo rápido que sea nuestro sistema. Al final de la compilación, si todo va bien, encontraremos un archivo llamado "pgp" y ejecutable, que será ya el programa definitivo, con lo que pasaríamos a su instalación. Podríamos probar el funcionamiento del programa simplemente tecleando "./pgp". $ ./pgp

“Completando la instalación”

Ahora realizaremos una serie de pasos para que el programa PGP quede correctamente instalado. Aquí existe una pequeña diferencia en cuanto a si estamos instalando PGP para nuesto uso particular (como usuarios normales) o para todo el sistema (como administrador, root, o super-usuario). Supondremos primero que lo instalamos por nuestra cuenta; al no poder copiar archivos en los directorios del sistema (no tenemos permisos para ello) tendremos que almacenar tanto el programa como los archivos de configuración, ayuda etc. en nuestro directorio personal.

Si somos simples usuarios 1. Copiar el programa PGP a otro directorio. Copiaríamos el programa a su localización definitiva. Es importante que este directorio tenga el "PATH" puesto, ya que si no nos obligaría a usar el programa dándole siempre el camino completo. $ cp pgp ../programas 2. Crearnos un directorio ".pgp". Necesitaremos un directorio para almacenar los archivos de llaves y alguna otra cosa más. Este directorio se debe llamar ".pgp” y lo crearemos en nuestro directorio personal. $ mkdir .pgp

3. Instalar la documentación y ayuda. En el directorio "doc" tenemos los archivos pgpdoc1.txt y pgpdoc2.txt. Debemos copiarlos al directorio ".pgp”. $ cp pgpdoc* ../.pgp En este mismo directorio esta la página man de PGP. También es útil copiarla al directorio ".pgp" y mejor ya formateada, para no tener que verla con el programa "nroff". Para ello: $ nroff -man pgp.1 > pgp.manual $ cp pgp.manual ../.pgp 4. Copiar los archivos de configuración. Copiamos los archivos "es.hlp", "language.txt" y "config.txt" en el directorio ".pgp". Estos archivos son de configuración y de ayuda. $ cp es.hlp config.txt language.txt .pgp

5. Configurar el lenguaje y el juego de caracteres a usar. Editaremos el archivo config.txt para especificar el lenguaje a usar y el juego de caracteres. Este archivo viene comentado y en él se indica dónde y cómo cambiar estos valores. # Representation of Names of Languages # Language = es # CharSet = latin1 Para tener el sumario de órdenes en español renombraremos al archivo "es.hlp" como "pgp.hlp": $ mv es.hlp pgp.hlp

Si somos administradores Si es administrador de la máquina, puede instalar el programa para todos los usuarios, aunque cada uno deberá crearse de la misma forma ya indicada antes, su directorio personal ".pgp". 1. Instalar el ejecutable "pgp" en un directorio de programas. $ cp src/pgp /usr/local/bin 2. Instalar la página man pgp.1 en su lugar correcto, para que los usuarios puedan consultar la ayuda con "man pgp". Este lugar en general es /usr/man/man1. Las páginas man suelen estar comprimidas para ahorrar espacio en disco; si este es el caso en tu sistema, primero la comprimiríamos y luego la copiaríamos: $ gzip pgp.1 $ cp pgp.1.gz /usr/man/man1

3. Colocar la documentación ("pgpdoc1.txt" y “pgpdoc2.txt") en /var/lib/pgp (podría variar con el sistema). $ mkdir /var/lib/pgp $ cp pgpdoc1.txt pgpdoc2.txt /var/lib/pgp 4. Copiar los archivos de configuración ("config.txt", "language.txt" y "es.hlp") en /usr/local/lib/pgp y editarlos para adaptar el idioma y la ayuda al español. $ mkdir /usr/local/lib/pgp $ cp config.txt language.txt es.hlp /usr/local/lib/pgp $ cd /usr/local/lib/pgp; mv es.hlp pgp.hlp 5. Crear a los usuarios (o indicarles que deben hacerlo) un directorio en su directorio personal llamado ".pgp", donde se almacenarán los archivos que contienen los anillos de llaves públicas y privadas.

“Cómo utilizar PGP” Para ver un resumen rápido de las instrucciones de PGP, escribe: $ pgp -h Generación de llaves RSA Para generar tu propio par único de llaves pública/secreta de un tamaño determinado, escribe: $ pgp -kg PGP mostrará un menú de tamaños recomendados para la llave (nivel comercial bajo, nivel comercial alto y nivel "militar") y te pedirá qué indiques qué tamaño de llave quieres, hasta 2048 bits. También se pide un identificador de usuario, esto es, tu nombre junto con tu e-mail (Rodrigo Lopez Valencia ).

PGP también pedirá una "contraseña" para proteger tu llave secreta. La contraseña puede ser una expresión o frase con varias palabras, espacios, signos de puntuación o cualquier cosa que quieras poner. No la pierdas, porque no hay forma de recuperarla. La contraseña te hará falta más adelante, cada vez que utilices tu llave secreta. El programa te pedirá que introduzcas un texto al azar para poder acumular algunos bits aleatorios para las llaves. Cuando se te pida, debes pulsar algunas teclas razonablemente al azar El par de llaves generado se colocará en tus anillos de llaves públicas y secretas. Puedes utilizar más adelante la orden "pgp kxa" para extraer (copiar) tu nueva llave pública desde el anillo correspondiente y ponerla en un archivo de llave separado, listo para distribuir entre tus amigos.

Extracción (copia) de una llave del anillo Para extraer una llave del anillo de llaves públicas o secretas: $ pgp -kx identificador llave_publica.asc [anillo] Este proceso copia (sin borrar) la llave especificada por el identificador desde el anillo al archivo indicado. Si la llave tiene alguna firma de certificación, también se copia con la llave. Si quieres que la llave extraída se represente en caracteres ASCII imprimibles, para correo electrónico, pon las opciones -kxa. Visualización del contenido del anillo Para ver el contenido del anillo de llaves públicas: $ pgp -kv[v] [identificador] [anillo] Para ver las firmas de certificación de cada llave, utiliza la opción -kvv: $ pgp -kvv [identificador] [anillo]

Adición de una llave al anillo de llaves Para añadir el contenido de un archivo de llaves públicas o secretas al anillo de llaves correspondiente: pgp -ka llave_de_otro.asc [anillo]. El nombre opcional del anillo es, por omisión, "pubring.pgp" o "secring.pgp", según se refiera a llaves públicas o secretas. Puedes indicar un nombre diferente para el archivo y también su extensión por omisión será ".pgp". Eliminación de una llave o identificador del anillo Para suprimir una llave del anillo de llaves públicas: $ pgp -kr identificador [anillo]

Cifrado de un mensaje Para cifrar un mensaje de texto normal con la llave pública del destinatario, escribe: $ pgp -e archivo.txt su_identificador Esta orden produce un texto cifrado llamado archivo.txt.pgp. Ejemplo: $ pgp -e carta.txt Alice $ pgp -e carta.txt "Alice S" Si se encuentra una llave pública que coincide, PGP la utiliza para cifrar el archivo normal "carta.txt" y produce un archivo cifrado llamado "carta.txt.pgp". PGP intenta comprimir el texto en claro antes de cifrarlo, lo que mejora considerablemente su resistencia al criptoanálisis.

Si quieres enviar el mensaje cifrado por canales de correo electrónico, conviértelo al formato ASCII imprimible "radix-64" añadiendo la opción -a. $ pgp -ea carta.txt Alice Cifrado de un mensaje para múltiples destinatarios Si quieres enviar el mismo mensaje a más de una persona, puedes hacer que se cifre para varios destinatarios. $ pgp -ea carta.txt Alice Bob Carol Así se crea un archivo cifrado llamado carta.txt.pgp que podría descifrar Alice, Bob o Carol. Puede indicarse cualquier número de destinatarios.

Firma de un mensaje Para firmar un archivo normal con tu llave secreta, escribe: $ pgp -s archivo.txt [-u tu_identificador] Esta orden produce un archivo firmado llamado archivo.txt.pgp. Un ejemplo podría ser: $ pgp -s carta.txt -u Bob Esta orden busca en el archivo de llaves secretas "secring.pgp" cualquier certificado que contenga la cadena "Bob" en el identificador de usuario. Te llamas Bob, ¿no?. La búsqueda no tiene en cuenta el tipo de letra. Si se encuentra una llave secreta que coincide, PGP la utiliza para firmar el archivo normal "carta.txt" y produce un archivo firmado "carta.txt.pgp".

Para firmar mensajes electrónicos en los que quieras dejar el resultado legible. La firma se aplica en un formato imprimible al final del texto y se desactiva la compresión. Así el texto permanece legible aunque no se compruebe la firma. Ejemplo: $ pgp -sta archivo.txt Se genera un mensaje firmado en el archivo "archivo.txt.asc", formado por el texto original, todavía legible, y una firma ASCII imprimible añadida, todo preparado para enviar por correo electrónico.

Firma y posterior cifrado Para firmar un archivo normal con tu llave secreta y después cifrarlo con la llave pública del destinatario: $ pgp -es archivo.txt su_identificador [-u tu_identificador] Este ejemplo produce un archivo cifrado anidado, archivo.txt.pgp. Si no incluyes el identificador de usuario del destinatario, te pedirá que lo introduzcas. Si no indicas tu propio identificador de usuario, se utiliza la llave más reciente del anillo de llaves secretas como elección por omisión para la firma. Si quieres enviar este mensaje cifrado por medio de canales de correo electrónico, conviértelo al formato ASCII imprimible "radix-64" añadiendo la opción -a.

Descifración y comprobación de firmas Para descifrar un archivo cifrado o para comprobar la integridad de un archivo firmado: $ pgp -d[p] arch_cifrado [-o arch_normal] Por omisión se asume que el nombre del archivo cifrado tiene una extensión ".pgp". Si se anida una firma dentro de un archivo cifrado, se descifra automáticamente y se comprueba su integridad. Se mostrará el identificador completo del firmante.

Revocación de una llave pública Supongamos que, por algún motivo, tanto tu llave secreta como tu contraseña se ven comprometidas. Tendrás que decírselo al resto del mundo para que dejen de utilizar tu llave pública. Para ello, tienes que emitir un certificado de "compromiso de llave" y revocar la llave pública. Para generar ese certificado, utiliza la orden -kd: $ pgp -kd tu_identificador Este certificado lleva tu firma, realizada con la misma llave que estás revocando. Deberías distribuirlo ampliamente cuanto antes. Las personas que lo reciban podrán añadirlo a sus anillos de llaves públicas y sus programas PGP evitarán automáticamente que vuelvan a utilizar la llave antigua por error. Puedes generar un nuevo par de llaves secreta/pública, y publicar la nueva llave pública.

Área de Seguridad en Cómputo DGSCA-UNAM Tel : (01) 5622-8169 Fax: (01) 5622-8043 http://www.asc.unam.mx ftp://ftp.asc.unam.mx E-Mail : [email protected]