seguridad i - linux

Seguridad I

Ver. 1.0.0

Digital Thinking © 2004 - 2005

Capitulo 1: Introducción 1

Introducción Todos los días, en todo el mundo, las redes de ordenadores y hosts son violados. El nivel de sofisticación de estos ataques varia ampliamente; mientras hay una creencia generalizada que la mayoría de estas intrusiones tienen éxito debido a la debilidad de los passwords, hay todavía un gran numero de intrusiones que hacen uso de técnicas más avanzadas para entrar. Poco es sabido acerca de este ultimo tipo de intrusiones, debido principalmente a su naturaleza y a su dificultad de ser detectadas. ERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley.Purdue. Sun. Cualquier sistema en Internet (y muchos que no lo están) son susceptibles de ser violados fácilmente. Son estos objetivos inusuales? Que ocurrió? Joven, con pelo rubio y grasiento, sentado en una habitación oscura. La habitación esta iluminada solamente por la luz de la pantalla de 40 caracteres de un C64. Tomando otra larga calada de su Benson & Hedges, su cansado sistema cracker “Telnetea” a otro site “.mil” anónimo de su lista de víctimas. No importa. Tiene toda la noche….lo tacha de su lista, y cansinamente teclea la siguiente víctima potencial…. Esta parece ser la imagen habitual de un cracker de sistemas. Joven, sin experiencia, y con un montón de tiempo que perder, tan solo para entrar en otro sistema. Sin embargo, hay un tipo de cracker mucho mas peligroso rondando por ahí. Uno que sabe todo lo ultimo acerca de seguridad de sistemas y herramientas cracking, que puede modificarlas para llevar a cabo ataques específicos, y que puede curarse sus propios programas. Uno que no solo se dedica a leer sobre los últimos agujeros de seguridad, sino que también descubre bugs y puntos débiles. Una “criatura mortal” que puede tanto golpear “envenenadamente” , como ocultar su rastro sin un solo susurro o pista. El cybercracker esta aquí.. Las victimas no son arbitrariamente escogidas – hay un propósito, tanto como si es por conseguir fines monetarios, un ataque “golpea y corre” para robar información, o un desafió para golpear un prestigioso-gran site o red personalmente. Un cybercracker es difícil de detectar, mas aun de parar, y aun mas si cabe de mantenerlo alejado de tu site por tu bien.

Overview En este texto vamos a realizar un acercamiento inusual a los sistemas de seguridad. En vez de decir meramente que algo es un problema, vamos a mirar a traves de los ojos de un intruso, y ver por que lo es. Vamos a ilustrar que incluso los aparentemente inocuos servicios de red pueden convertirse en herramientas muy valiosas a la hora de buscar puntos débiles en un sistema, incluso cuando estos servicios operan del modo esperado. En un esfuerzo por verter algo de luz sobre como ocurren estas intrusiones cada vez mas avanzadas, este texto reseña varios mecanismos usados actualmente por los crackers para obtener acceso a los sistemas y, adicionalmente, algunas técnicas que sospechamos están usando, o hemos usado nosotros mismos en tests o ambientes autorizados / amigables. Nuestra motivación a la hora de escribir este texto ha sido el hecho de que los administradores de sistemas no son muy a menudo conscientes del peligro existente por cualquier cosa mas allá de los ataques más triviales. Mientras por todos es sabido que el nivel de protección apropiado depende de que es lo que debe ser protegido, muchos sites parecen estar faltos de los recursos para valorar que nivel de protección es adecuada. Dando a conocer lo que los intrusos pueden hacer para ganar acceso a un sistema remoto, intentamos ayudar a los administradores de sistemas a tomar decisiones sobre como proteger su site – o como no hacerlo. Limitaremos la discusión a técnicas que pueden posibilitar el acceso a intrusos a shells en un host corriendo UNIX. Una vez hecho esto, los detalles acerca de como conseguir privilegios root están mas allá del ámbito de este texto, consideramos que son o dependen del site y, en muchos casos, muy triviales para merecer discutirse. El propósito de este texto es el de tratar de que el alumno vea su sistema de una forma nueva / diferente – una forma que posiblemente le permita tener la oportunidad de entender como su propio sistema puede estar comprometido, y como. También queremos reiterar que el propósito de este texto es el de enseñar al lector como testear la seguridad de su propio site, y no como irrumpir en sistemas ajenos. Las técnicas de intrusión ilustradas aquí dejaran muy a menudo huellas en los logs de tu sistema – seria constructivo examinarlos después de intentar alguno de estos ataques, para ver como seria un ataque verdadero. Ciertamente otros sites y administradores de sistemas tomaran una visión fugaz de tus actividades si es que decides usar sus hosts para hacer tests de seguridad sin autorización avanzada; de hecho, es posible que se tomen medidas legales contra tu persona si lo perciben como un ataque.


Capitulo 2: Conceptos de Seguridad 2

2 Conceptos de Seguridad

2.1 Seguridad de Contraseñas

En todo sistema operativo tipo UNIX se dan varias constantes, y una de ellas es el fichero /etc/passwd y la forma en que funciona.

Para que la autentificación de usuario funcione correctamente se necesitan (como mínimo) algún tipo de fichero(s) con UID a mapas de nombres de usuarios, GID a mapas de nombres de grupos, contraseñas para todos los usuarios y demás información variada.

El problema es que todo el mundo necesita acceso al fichero de contraseñas, cada vez que se hace un ls, se verifica el fichero de contraseñas, de modo que ¿cómo se consigue almacenar todas las contraseñas con seguridad y a la vez mantenerlas legibles por el mundo? Durante muchos años, la solución ha sido bastante simple y efectiva, simplemente, haz un hash de las contraseñas y guarda el hash, cuando un usuario necesite autentificar, toma la contraseña que introduce, pásala por el hash y si coincide, evidentemente se trataba de la misma contraseña.

El problema que tiene esto es que la potencia computacional ha crecido enormemente, y ahora se puede coger una copia del fichero de contraseñas e intentar abrirlo mediante fuerza bruta en una cantidad de tiempo razonable. Para resolver esto hay varias soluciones:

• Utiliza un algoritmo de hashing "mejor", como MD5. Problema: se pueden romper muchas cosas si están esperando algo más.

• Almacena las contraseñas en alguna otra parte. Problema: el sistema/usuarios siguen necesitando tener acceso a ellas, y podría hacer que fallasen algunos programas si no están configurados de esta forma.

Varios sistemas operativos han escogido la primera opción, Linux ha implementado la segunda desde hace tiempo, se llama contraseñas con shadow.

En el fichero de contraseñas, se reemplaza la contraseña por una ‘x’, lo cual le indica al sistema que verifique tu contraseña contra el fichero shadow (se hace lo mismo con el fichero de grupos y sus contraseñas).

Parece lo suficientemente simple, pero hasta hace bien poco, implementar el shadow era una ardua tarea. Había que recompilar todos los programas que verificasen la contraseña (login, ftpd, etc, etc) y esto, por supuesto, implica una considerable cantidad de esfuerzo. Es aquí donde brilla Red Hat, con su confianza en PAM.

NOTA:

Los distintos unix trabajan con distintos ficheros, donde la forma de encriptación en cada uno de ellos, por supuesto es distinta.

AIX:

/etc/passwd

/etc/security/passwd

Solaris

/etc/passwd

/etc/shadow

Irix(Cuidado con las cuentas por default!)

/etc/passwd

/etc/shadow

FreeBsd, OpenBsd



/etc/passwd

/etc/master.passwd

Para implementar contraseñas con shadow hay que realizar dos cosas. La primera es relativamente simple, cambiar el fichero de contraseñas, pero la segunda puede ser un calvario. Hay que asegurarse que todos tus programas tienen soporte para contraseñas con shadow, lo cual puede ser bastante penoso en algunos casos (esta es una más que importante razón por la cual un mayor número de distribuciones deberían venir con PAM).

Debido a la confianza de Red Hat en PAM para la autentificación, para implementar un esquema nuevo de autentificación todo lo que se necesita es añadir un módulo PAM que lo entienda y editar el fichero de configuración para cualquier programa (digamos el login) permitiéndole que use ese módulo para hacer la autentificación. No hace falta recompilar, y hay poco tejemaneje, ¿a que sí?.

En Red Hat 6.0, durante la instalación se te da la opción de elegir contraseñas con shadow, o puedes implementarlas más tarde vía las utilidades pwconv y grpconv que vienen con el paquete de utilidades shadow.

La mayoría del resto de distribuciones también tienen soporte para contraseñas con shadow, y la dificultad de implementación varía de un modo u otro. Ahora, para que un atacante mire las contraseñas con hash, tiene que esforzarse un poco más que simplemente copiar el fichero /etc/passwd. También asegúrate de ejecutar cada cierto tiempo pwconv, para tener la certeza de que todas las contraseñas efectivamente tienen shadow. Hay veces que las contraseñas se quedan en /etc/passwd en lugar de enviarse a /etc/shadow como deberían, lo cual hacen algunas utilidades que editan el fichero de contraseñas.

2.2 Rompiendo contraseñas(Cuando necesitamos recuperar contraseñas)

En Linux las contraseñas se guardan en formato hash, sin embargo ello no las hace irrecuperables, no es posible hacer ingeniería inversa de la contraseña a partir del hash resultante, sin embargo sí que puedes hacer un hash de un lista de palabras y compararlas. Si el resultado coincide, entonces has encontrado la contraseña, es por esto que es crítica la elección de buenas contraseñas, y las palabras sacadas de un diccionario son una idea horrible. Incluso con un fichero de contraseñas con shadow, el root puede acceder a las contraseñas, y si se han escrito scripts o programas que se ejecuten como root (pongamos un script CGI para www) los atacantes pueden recuperar el fichero de contraseñas. La mayoría del software para romper contraseñas también te permite la ejecución en múltiples hosts en paralelo para acelerar las cosas.

John the ripper ("Juan el destripador")

Un eficiente rompedor de contraseñas se encuentra disponible en: http://www.false.com/security/john/

Crack

El rompedor de contraseñas original y ampliamente extendido (según me consta), se encuentra disponible en: http://www.users.dircon.uk/~crypto/

Saltine cracker

Otro rompedor de contraseñas con capacidades de red, se puede descargar de: http://www.thegrid.net/gravitino/products.html

Velocity Cracking Utilities

Velocity Cracking Utilities (VCU en adelante), es un programa basado en windows para ayudar a romper contraseñas "VCU intenta facilitar la tarea de romper contraseñas a usuarios de computadoras de cualquier nivel". Este programa se puede descargar de: http://wilter.com/wf/vcu/

Espero que esto sea suficiente motivo para utilizar contraseñas con shadow y un hash más robusto como el MD5 (el cual soporta Red Hat 6.0, en adelante).


http://www.false.com/security/john/

http://www.users.dircon.uk/%7Ecrypto/

http://www.thegrid.net/gravitino/products.html

http://wilter.com/wf/vcu/


Aquí dejamos una comparativa de estos crackeadores, en la misma máquina y con los mismos ficheros de passwords y de palabras. Algunos de ellos tardaban demasiado, y aborté el proceso de petar passwords. En estos casos, calculé el tiempo estimado que tardarían en acabar en función del tiempo que llevaban (1 hora) y las palabras que habían provado hasta el momento. Estos son los resultados, ordenados por velocidad:

Cracker Tiempo Comparaciones

por Segundo Observaciones

John the ripper 1.4 6'15'' 26667c/s . John the ripper 1.31 6'30'' 25641c/s . John the ripper 1.0 8'05'' 20619c/s . Star Crack 0.64ß 9'15'' 18018c/s . Star Crack 0.51ß 11'25'' 14599c/s . Cracker Jack 1.4 13'33'' 12300c/s . Cracker Jack 1.3 386 14'55'' 11173c/s . Cracker Jack 1.3 8086 22'22'' 7452c/s . Hades 1.00a 47'05'' 3540c/s . Brute 2.00 (est)59'54'' 2782c/s .

PCUPC 2.01 (est)135'37'' 1229c/sSólo soporta ficheros de

passwords de menos de 500 linias.

Guess 2.1 (est)141'58'' 1174c/sSólo soporta ficheros de


Killer Cracker 9.5 (est)151'12'' 1105c/sSólo soporta ficheros de


Xit 2.0 (est)195'37'' 852c/s . Hellfire Cracker 1.3 infinito 0c/s Se colgó y no pudo ser provado.

Este test fue realizado en un Pentium 133, con 16 Mb de RAM, con los datos en el disco duro, con una cache de lectura de 2 Mb y sin hacer ningún preprocesado en el fichero de passwords ni en el de palabras. El fichero de palabras contenia 10000 palabras y el de passwords 1000 passwords. Tenian que encontrar 554 passwords. Algunos de ellos no los dejé acabar ya que tardaban demasiado y estimé el tiempo en función de lo que habían crackeado hasta el momento de pararlos, por lo tanto no sé si hubieran encontrado todos los passwords. Sólo los he incluido en la comparativa por si alguno de vosotros los usa, para que vea que hay cosas mejores.

Como se puede ver, el John the ripper encripta casi el doble de passwords por segundo que el Cracker Jack. He de reconocer que el fichero con el que hize la prueba parece ser especialmente adecuado para el John the ripper, ya que 20000c/s no se consiguen habitualmente. De todas formas, la comparativa es significativa de la velocidad a la que se petan passwords con cada uno de los programas.


Capitulo 2: Ataques 8

3 Ataques

3.1 Que es el Spoofing?

El spoof tradicional es cuando los 'atacantes' falsean el origen de los paquetes haciendo que la victima piense que estos son de un host de confianza o autorizado para saltar un firewall o que la victimas no nos detecten.

3.2 TCP y IP spoofing

Centrémonos en Nuestro Server (linux/unix/Bsb) que protege varios servicios al mismo tiempo a través de los ya conocidos Tcp Wrappers y con herramientas tipo Firewalls que protegen toda una RED. La mayoría de estas herramientas protege, comparando Host y IP y utilizándolos para identificarlos por ejemplo los archivos /etc/host.allow y /etc/host.deny.

/etc/host.allow supongamos que es una red local y yo 192.168.0.1 soy el Server y nada mas quiero que ellos usen mis servicios AllowHosts caos.qqmelo.com.ar,192.168.0.2 kuazar.qqmelo.com.ar,192.168.0.3 bach.qqmelo.com.ar,192.168.0.4 giba.qqmelo.com.ar,192.168.0.5 hellraiser.qqmelo.com.ar,192.168.0.6 /etc/host.deny estos son los que no quiero que usen mis servicios DenyHosts gerente.qqmelo.com.ar, 192.168.0.7 cinic.qqmelo.com.ar, 192.168.0.8 sperman.qqmelo.com.ar, 192.168.0.9 pero también se pueden poner rangos de ip tipo 200.0.212.* o 200.*.*.*

3.3 Caso de spoof básico

Supongamos bach.qqmelo.com.ar esta corriendo un NT Server con wingate y cinic.qqmelo.com.ar que quiere entrar a mi server, pero no tiene acceso a mi server, entonces cinic hace: $telnet 192.168.0.4 23 wingate>192.168.0.1 21...conected 200 Qqmelo Server (wu-ftp 6.9) on host powertech.qqmelo.com.ar Bienvenido Qqmelo Server ftp>user ftp 331 Anonymous access allowed, send identity (e-mail name) as password pass [email protected] 230 Anonymous user logged in. 0-----0

3.4 Ataque Spoof de números secuenciales

Tenemos un Webserver y tenemos al CLASICO atacante, vamos a dar el servicio rhosts que es un buen ejemplo porque rhosts hace una conexión de confianza entre dos maquinas porque tiene 'autentificación remota 'rlogin,rsh,rcp y rcmp porque los usuarios que tienen acceso a estos servicios son confiados y están autorizados a entrar a: sistema local sin passwd un ejemplo del archivo.rhosts



node1.qqmelo.com.ar caos node2.qqmelo.com.ar kuazar node3.qqmelo.com.ar giba node4.qqmelo.com.ar bach node5.qqmelo.com.ar qrmelo Cuando el circuito virtual esta establecido, los dos hosts tienen que tener iguales maneras de verificación que los datos sean transferidos limpiamente. Por esto TCP usa en (ingles) sequence numbers. TCP le asigna a cada paquete un numero como index identificatorio. Los dos hosts usan este numero para chequear errores y reportarlos. Es mas, este proceso de pasar los números secuenciales cuando el circuito ya esta establecido. La secuencia es usada para aceptar los datos que llegan. Al principio de la conexión, el cliente que manda los paquetes TCP con un numero en secuencia inicial, pero no certificada (no puede haber una ahora). Si la aplicación del Server esta corriendo del otro lado de la conexión, el Server manda de vuelta el paquete con su propia inicial de numero secuencial desde el paquete del cliente más uno. Cuando el sistema cliente recibe este paquete, lo debe mandar de vuelta con su propia confirmación: el numero inicial del Server mas uno. El atacante tiene dos problemas el primero es cambiar la dirección y la otra es mantenerla secuencia en el dialogo con la maquina victima, el segundo es él mas complica el ataque ya que él número secuencial ya que el cambio del mismo no es arbitrario. Si el atacante adivina correctamente él numero, este puede sincronizarse con la victima e iniciar una sesión. Desde ahora la maquina del atacante queda vinculada a la maquina victima como un host de confianza, y puede iniciar conexiones tipo rhosts así pude logearse.

3.5 Un caso de ataque secuencial

Aplicación: mendax para linux lenuage:c http://esperosun.chungnam.ac.kr/-jmkim/hacking/1997/11/mendax_linux.tgz Para usarlo tenemos que hacer:

gunzip mendax_linux.tgz tar -xvf mandax_linux.tar make ./mendax estas son las opciones -p Port -s Port -l Username -r Username -c command -w Port -d -t -L TERM -S PORT

ahora mi objetivo es ejecutar el comando rsh desde 192.168.0.8 a 192.168.0.1 spoofeando me por 192.168.0.2 ,el comando que quiero ejecutar es:

mv .rhosts .r; echo + + > .rhosts para spoofearme [root@gerente]# mendax -p 514 192.168.0.2 192.168.0.1 -l caos -r caos Flooding sourse con TCP SYN packets from 192.168.0.8

samplin secuense numbers seq number: 816640001, ack number: 64001 difference:64000 seq number: 816640001, ack number: 128001 difference:64000 seq number: 816640001, ack number: 192001 difference:64000 using 64000 as prediction difference (3 hits)

spoofing rshd



reseting TCP target connection: reseting source: .............. [root@gerente]# para ver si funciono ls -l .r* -rw-r--r-- 1 caos user fecha .rhosts el archivo rhosts tiene que tener en el ++ y después en el log aparece fecha gnss rshd: [email protected]

3.6 ARP Spoofing

ARP Spoofing es la variación de IP Spoofing porque explota una debilidad del protocolo TCP/IP. ARP "autentificación" es también basado en la "Source Adress" dirección de donde provienen los paquetes, lo que lo diferencia a ARP es que se fija en una dirección en el Hardware. Para verla, se hace lo siguiente:

[toor@powertech toor]# ifconfig eth0 ne2k-pci.c: PCI NE2000 clone 'Winbond 89C940' at I/O 0x6400, IRQ 9. eth0: Winbond 89C940 found at 0x6400, IRQ 9, 00:00:E8:57:82:6B.<-\ eth0 Link encap:Ethernet HWaddr 00:00:E8:57:82:6B <--------|Hwaddr BROADCAST MULTICAST MTU:1500 Metric:1 Interrupt:9 Base address:0x6400

El Guardes: son valores únicos, que están "quemados" en tu tarjeta de red por el fabricante, que identifica tu dirección física. Estas consisten en 48-bits (12 caracteres). Un ejemplo de una dirección de hardware es esta:

HWaddr 00:00:E8:57:82:6B

ARP significa en ingles "Address Resolution Protocol". ARP resuelve la IP a una dirección física. Cuando un host quiere una sesión, manda para afuera un ARP broadcast llevando la IP de su objetivo deseado. Sin embargo, por conveniencia, nuestro sistema crea lo que se podría llamar "ARP cache" así la maquinas se pueden conectar a Host conocidos mas rápidamente sin hacer un broadcast. Es con este cache que los atacantes pueden utilizarlo para spooferase ya que lo que guarda es la hardware address. En el ARP spoofing, el atacante mantiene su HWaddress pero asume el IP de un trusted Host, para hacerlo el atacante manda "la información de mapeo" al objetivo y al cache. Desde ese punto, los paquetes provenientes del objetivo son ruteadas hasta la HDaddress del atacante. Desde ahora el objetivo piensa que el atacante es un trusted host.

3.7 DNS spoofing

DNS spoofing es cuando el atacante compromete al Domanin Name Server (DNS) y altera la tabla con los Hostnames y IP. Estos cambios son escritos adentro de la base de datos de traduccion del DNS Server. Cuando el cliente hace un nslookup a un host el DNS le da la IP y también el revez, esta dirección queda en la manos del atacante.

Normalmente ejemplo: [toor@powertech toor]# nslookup www.qqmelo.com.ar Server: relay3.impsat1.com <|____Nuestro DNS Address: 200.31.1.8 <------| Non-authoritative answer: Name: www.qqmelo.com.ar Address: 63.65.251.8 [toor@powertech toor]# nslookup www.yahoo.com.ar Server: relay3.impsat1.com <|____Nuestro DNS Address: 200.31.1.8 <------| Non-authoritative answer:


mailto:[email protected]


Name: ar.yahoo.com Addresses: 200.49.66.82, 200.49.66.83 Aliases: www.yahoo.com.ar, ar.rc.yahoo.com

Pero supongamos que el atacante ingresa al DNS de impsat y con un programa que automatice la tarea de cambiar. Si alguien busca www.yahoo.com el DNS le pone el IP de qqmelo.com.ar, redirecionandolo. Un ejemplo de estos tipo de programas es el paquete de ADM se llama ADMidpkd.tar.gz. Con este programa, también si estas en LAN podes poner en función el snifer sin ingresar al DNS ya que trabaja igual que un snifer normal pone la tarjeta de red en modo promiscuo e intercepta el paquete del Query y lo cambia haciendo lo que comente antes.

"hackeado" ejemplo: [toor@powertech toor]# nslookup www.yahoo.com.ar Server: relay3.impsat1.com Address: 200.31.1.8 Non-authoritative answer: Name: ar.yahoo.com Addresses: 63.65.251.8 <-------IP de qqmelo Aliases: www.yahoo.com.ar, ar.rc.yahoo.com

Y entonces todos aquellos que usen el DNS de impsat y quiera ir a yahoo verán la pagina de qqmelo. En el paquete de programas que le comente de ADM hay un sniffer que ante CUALQUIER request o query, o como lo llamen lo mandara a qqmelo, o a la dirección que elijamos. También hay varios programas mas:

-=Jizz=- author: unknown OS: *NIX ,MS-DOS -=ERECT=- author: Johan y Dioxide OS:*NIX -=Snoof=- author:DOC_Chaos [RoC] OS:*NIX Los pueden bajar en: http://www.anticode.com

3.8 Previniendo IP Spoofing

La mejor manera de prevenir estos ataques son:

• Restringir direcciones locales que vengan de la afuera de nuestra RED. • Intentar no tener Trusted Host. • Utilizar SYN Loggers así se podrá detectar si alguien intenta Hacerle un DoS a tu

maquina, se preguntaran y porque un SYN logger, bueno porque este ataque es él más efectivo contra sistemas *NIX, y así pueden tomar su "identidad".

• Utilizar Firewall que trabajen con los módulos del kernel y no un soft que escucha puertos, firewalls recomendados:

IPchains IPfwadm IP filter

• Activar él modulo del kernel rp_filter, en muchas distros lo activan por default por

ejemplo Debian, lo que tienen que hacer es poner en /etc/rc.d/rc.local la siguiente línea:

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

Esto tiene que utilizarse con IPchains.


http://www.yahoo.com/


• Filtrar servicios que son vulnerables a este ataque por ejemplo:

X Windows Servicios R, (rlogin, rsh. rexec) Servicios RCP TCP Wrappers

Cualquier servicio que use IP para autentificar • Utilizar servicios con encriptación integrada ejemplos:

OpenSSH OpenSSL SSH SSH2 FtpSSL

Ya que con conectarse a un puerto y al recibir un par de paquetes se puede calcular secuencia TCP y se puede Spoofear el Servicio. Además las conexiones no podrán ser "Snifeadas" esto significa que no podrán capturar los paquetes, que pueden llevar los datos del login.

3.9 Previniendo ARP Spoof

Ya les explique como es esta ataque acá vemos como protegernos del mismo. Hay muchas maneras de defenderse de esto, la mejor manera es grabar nuestra HWaddr en piedra, pero seria algo incomodo. Los ataques de ARP spoofing son muy limitados en muchas maneras. Una de la maneras es que las nuevas tarjetas de red le hacen un update al cache mas o menos cada 5 minutos haciendo que el ataque no sea de gran riesgo a una red. "ARP": Una Herramienta para manipular tablas de ruteo. ARP, te permite interactuar y manipular el cache de arp, acá voy a explicar como usar esta herramienta:

Opción Función

-a [hostname] Especifica un host en particular al que le queres hacer el query.

-b [hostname] Borra una entrada a un Host particular.

-f [archivo de conf.] Archivo de configuración.

-a [hostname] [address_type]

Especifica la HWaddr al Host seleccionado.

-t [type] Para las distintas tipo de entrada por Ej.: ether, ax25, arcnet, and pronet (token ring)

-v Para activar el modo Verbose.

Si igual quieren estar seguros que no les hagan este ataque instalen en su sistema "ARPwatch" que observa los cambios de IP/Ethernet, se detectan cambios o nuevas direcciones este programa le envía un mail al root.

3.10 Previniendo DNS Spoofing

DNS spoofing en muy fácil detectar. Si sospechas de tu DNS, hace nslookup desde varias maquinas de tu red fijarse en los procesos , en la tabla cron para ver si están corriendo un programa "desconocido" o si lo inicia y fijarse si su tarjeta de red esta en modo promiscuo, Salvo si tu DNS haya sido comprometido por algún tiempo va a ser rápidamente descubierta ya que si esto es hecho en un ISP los usuario se quejaran. Pero revisando las maquinas capas no puede ser suficiente, por eso recomiendo que utilicen este fabuloso programa, este se llama DOC (Domain Obsenity Control) que viene con mucha documentación. DOC es un programa que diagnostica tu DNS mandando distintos Querys y después analiza el contenido de lo obtenido, DOC lo pueden bajar de: http://coast.cs.purdue.edu/pub/tools/unix/doc.2.0.tar.gz

3.11 Buffer Overflows y otros ataques


http://coast.cs.purdue.edu/pub/tools/unix/doc.2.0.tar.gz


El método más común para conseguir derechos de ‘root’ en un sistema es el de provocar ”buffer overruns”. El funcionamiento de estos ”Exploits” se basa en sobreescribir campos estáticos de la pila de usuario (ingl. User stack) de un determinado programa en ejecución. De esta forma se sobreescriben otras variables en la pila de usuario para ejecutar así el código deseado (ej. una shell). Programas vulnerables a este tipo de ataque son aquellos que tienen un tamaño de campo (array) estático para la entrada de valores y que no tienen control de desbordamiento de búfer. Los únicos programas atractivos para estos ataques son los que tienen el ”suid-Bit” o el ”sgid-Bit” activado, por lo que se ejecutan con los derechos del propietario del programa y no con los del usuario que ejecuta el programa. Normalmente estos programas necesitan el modo ”suid root”, ya que ejecutan programas de los que root es propietario (ej. passwd). Otro tipo de ataque a programas privilegiados son los llamados ”link attacks”. Por el trabajo inseguro que estos programas realizan en directorios públicos, sería posible pasar datos a ficheros muy distintos de lo pensado, consiguiendo con ello información restringida sobre el sistema. Para reducir la cantidad de ficheros tipo suid y sgid, Linux ofrece a través de la posibilidad de asignar los permisos sobre los ficheros, de tal modo que el acceso a ellos sea seguro. Se puede comprobar los ficheros /etc/permissions.secure y /etc/permissions.paranoid para ver los permisos modificados. Antes de llegar al nivel de seguridad paranoica, es conveniente comprobar que la funcionalidad del propio sistema no esté demasiado restringida. Por su complejidad y la cantidad de código existente, el sistema X Window (XFree86) ha presentado con cierta frecuencia huecos de seguridad que actualmente no representan tanto problema ya que en Linux los servidores y librerías ya no son ”suid-root”. Sin embargo, pueden existir algunos defectos en la comunicación cliente-servidor, por lo cual, también existe la posibilidad de interceptar las entradas por teclado o de leer el contenido de una ventana. Si se tiene en cuenta el consejo, usando ”Xauthority” mediante el comando xauth y renunciando al comando xhost +, se consigue un nivel alto de seguridad. Para iniciar programas del sistema X Window de forma remota, se usa el paquete ssh de la serie n (network). ssh existe para casi todas las plataformas. No obstante este tipo de ”X11-Forwarding” involucra otro tipo de peligros, por lo que puede ser mejor prescindir completamente de ello. Los Buffer overflows representan, directamente por detrás del ”sniffing” (la lectura pasiva de datos para espiar ej. contraseñas), la manera más frecuente de poner en peligro la seguridad del sistema. En realidad cualquier servicio que sea accesible desde afuera, representa un problema potencial de seguridad ( ej. Mail, Webserver, POP3, etc.) Todos los servicios imprescindibles solo deberían ser accesibles a través de una configuración de Firewall del kernel de Linux (mediante ipchain) y solo se debería brindar servicios a determinados solicitantes. Si esto no fuera posible, lo mejor es realizar el servicio en cuestión con una versión especialmente segura ( ej. paquete postfix en lugar de paquete sendmail). Además los expertos tienen la posibilidad de ejecutar cada servicio en su propio entorno chroot. Denial of Service Para ataques del tipo ”Denial-of-Service”, el agresor bloquea un determinado servicio de red por sobrecarga. Según las circunstancias, esto no solo afecta a un servicio de red en concreto sino que bloquea todos los accesos a la computadora. Este tipo de ataque se realiza especialmente para dejar fuera de servicio a un servidor de nombres con el propósito de acoger su función y de este modo poder desviar los paquetes de red a otro lugar. Para ocultar el origen del ataque, normalmente el ”Denial of Service” se usa en combinación con ”IP Spoofing”. Por lo general, un par de horas después de la publicación de un ataque tipo ”Denial of Service”, el cual realmente llega a paralizar una computadora, aparece un parche para protegerse de él. el administrador del sistema debería estar siempre al tanto de las últimas novedades. Un ”Denial-of-Service”, de moda fue el WinNuke, donde los "piratas" desconectaban de Internet a sus victimas.

3.12 Ping of death

El viejo "ping de la muerte", asolo varios servidores. Fue el típico ataque por inundación, y lo que hacia mandaba "pines" sobredimensionados, donde la victima quedaba Knockout.

3.13 Internet worm

Internet worm, o i worm, son los famosos virus o gusanos, que se dispersan via email "melissa o i love you".


Capitulo 4: Scanners 14

4 Scanners

4.1 Introducción Scanners

Como sabemos todos, tenemos los denominados puertos en los sistemas Linux, y estos brindan servicios. Hemos vistos como proteger estos, pero también, tenemos que saber ( "o auditar", los servicios que estamos corriendo. Para ello lo que haríamos es crear un sistema, un soft, que tenga la capacidad de conectarse a un determinado puerto. El sistema operativo Linux, posee las capacidades de los Sockets Bsd, e incluye las librerías necesarias para crear un scanner. Sobre scanners, tenemos en la red varios, siendo uno de los mejores el nmap, que lo podemos descargar gratuitamente www.insecure.org/nmap. Este personalmente, considero que es uno de los mejores scanners. Daremos brevemente una reseña de su uso:

#nmap 127.0.0.1 como supondrán, escanea a mi propia maquina #nmap -sS 127.0.0.1, es el llamado "kiddie scan" en tono burlesco, por los script

kiddies, o los chicos del script, que lo que hacen es crear un script y se mandan a crackear sistemas operativos.

#nmap -p 21 127.0.0.1 Lo que hace es scanear un puerto, en este caso el puerto 21, o sea el ftp.

#nmap -o scan.log 127.0.0.1 Lo que haría en este caso, es escanear puertos y guardar el informe en el archivo scan.log

4.2 Técnicas de Finger Printing

Nmap, queso y posiblemente otros programitas que podemos descargar de la red, tienen la habilidad de detectar remotamente el sistema operativo, leyendo del stack de TCP. Según la ley, el scaneo de puertos esta permitido, y un scaneo de puertos, nos mostrara información muy importante. Pero, que pasaría si nosotros tenemos una red grande, y no exclusivamente de Linux, si no compartiendo NT's y otros unixes. Simple, nmap tiene una gran característica muy interesante, que me deja barrer toda una red, por ejemplo, si nuestra red es la 192.168.0.xxx, lo que haríamos es lo siguiente:

#nmap 192.168.0.1-255 y aquí barrimos toda la red, pero esto, no nos serviría de mucho, puesto que lo interesante seria tener un reporte, o sea que lo redireccionamos

#nmap 192.168.0.1-255 -o mired.log MMMM, muy interesante, esto nos puede

mostrar que nuestra red es totalmente un desastre... en este punto, llegamos a la conclusión que necesitamos un buen firewall.

4.3 BSD sockets

Para aquellos que quieran personalizar sus scanners, y posteriormente utilizarlo como "herramienta de auditoria", acá veremos muy básicamente como programar un scan en c. Lo primero que debemos ver, es que todo se guarda en una estructura, la cual se llama sockaddr_in, una vez echo esto, debemos crear una instancia de esta, que lo haremos con un puntero. Anteriormente, necesitamos incluir varias librerías las cuales son:

#include <netdb.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> main() { int port=80; int sock;

struct sockaddr_in cucu; cucu.sin_family = AF_INET; cucu.sin_addr.s_addr = inet_addr("127.0.0.1"); cucu.sin_port = htons(port);

sock=socket(AF_INET,SOCK_STREAM,0); if (connect(sock, (struct sockaddr *)&cucu, sizeof(cucu)) < 0) { printf("el puerto esta cerrado \n");



close(sock); exit(0); } printf("Puerto abierto \n"); close(sock); }

Mas allá de esto, sabemos que con solo el nmap, podemos descubrir muchas cosas. Con la practica, veremos que lo que nos convendría, quizás es realizar un scaneo del tipo

nmap -O -sS -P0 www.target.com -o salida.log

donde con esto, vemos que lo que estamos haciendo es q a la salida, la vamos a llamar salida.log, y con ello, tendremos un scan

4.4 Ejemplo de nmap

Primero, tan solo haremos un scan hacia nosotros mismos, donde veremos que tipo de información podemos recolectar de allí.

# nmap 127.0.0.1 Starting nmap V. 2.53 by [email protected] ( www.insecure.org/nmap/ ) Interesting ports on localhost (127.0.0.1): (The 1506 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 37/tcp open time 79/tcp open finger 110/tcp open pop-3 111/tcp open sunrpc 113/tcp open auth 139/tcp open netbios-ssn 513/tcp open login 514/tcp open shell 515/tcp open printer 814/tcp open unknown 901/tcp open samba-swat 904/tcp open unknown 909/tcp open unknown 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds Detengámonos un poco acá. Esto nos muestra algunos puertos abiertos, y por ejemplo, nos muestra que podemos tener puertos abiertos innecesariamente, como puede ser el puerto de ftp si este no le damos utilización, ya que esto podría quedar expuesto a un stack buffer overflow. Otro puerto que es innecesario que quede abierto es el 79, o puerto de finger, ya que puede revelar información importante a los atacantes, y puede llegar a peligrar nuestro sistema si esto pasa. Es la vieja técnica, donde lo que es mas común que se haga un finger [email protected] donde queda la información del archivo /etc/passwd “al aire libre”. Otro puerto que buscaran los piratas para tratar de ingresar a nuestro sistema, es el 25,cuando el viejo sendmail soporta verificación (vrfy) y expansión de usuarios (expn). Lo que pueden hacer, es tratar de conectarse a ese puerto y realizar un ataque” por diccionario”, o sea aplicar esto para sacar usuarios del sistema. Los hackers con la practica saben como explotar estos servicios, y existen sitios como pàcketstorm.securify.com, donde normalmente hablan de estos servicios, sus fallas y sus soluciones. Ahora, lo que realizaremos con nmap es detectar el sistema operativo, para ello haremos lo siguiente:

#nmap -O 127.0.0.1



Starting nmap V. 2.53 by [email protected] ( www.insecure.org/nmap/ ) Interesting ports on localhost (127.0.0.1): (The 1506 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 37/tcp open time 79/tcp open finger 110/tcp open pop-3 111/tcp open sunrpc 113/tcp open auth 139/tcp open netbios-ssn 513/tcp open login 514/tcp open shell 515/tcp open printer 814/tcp open unknown 901/tcp open samba-swat 904/tcp open unknown 909/tcp open unknown 6000/tcp open X11 TCP Sequence Prediction: Class=random positive increments Difficulty=3731298 (Good luck!) Remote operating system guess: Linux 2.1.122 - 2.2.14

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

4.5 Mas allá del nmap

Hemos visto lo que nmap puede realizar, nos puede traer un dolor de cabezas, pero en buena medida sirve para darnos una ayuda, para saber que servicios estamos dejando abiertos. Si prestamos atención al archivo /etc/services, nos daremos cuenta que existe un servicio llamado sun-rpc, el cual permite la instalación y uso de los comandos “r”, de berkeley, los que han caído en desuso. Pero hay que tener cuidado con este servicio, ya que se detecto una vulnerabilidad en el servicio rpc.statd, con lo cual los piratas podían llegar a tener nivel de r00t, en los sistemas que el quisiera atacar ( mas información statdx.c, en www.packetstorm.securify.com).

4.6 Otros tipos de scanners

Este es un scaner de puerto, pero existen scaners mas completos, donde se pueden sacar varios tipos de vulnerabilidades del cgi-bin. Muchos de ellos, como el cgi-scan, que fue el primitivo, y desde allí, hasta hoy se registraron 317 fallos del cgi-bin.

4.7 NT también existe

Para NT, también existen scanners, y quizás mejores, por el hecho de que NT es una plataforma mas pobre, en el sentido de que es mas fácil “hackearlo”. Una de las grandes fallas de las que se aprovechan los scanners de NT, es la llamada “sesión nula”, por la cual es posible obtener usuarios. Como es posible? Si, como se ha leído este gran error, nos deja leer los usuarios del sistema. Programas que se aprovechan de este gran error son entre otros, ntis, cis, y retina.

• Ntis: este pequeño programa tiene una desventaja, que corre sobre dos, y encima, pidiendo winnt. No presenta interfaz grafica, solo puede ser útil en un script. • Retina: “El Sr. scanner de NT”, nos posibilita entre otras cosas listar los usuarios, mientras que a la vez intenta un mini brute force attack. Tiene una gran base de datos e errores reportados, y es mas nos indica como repararlos. Podemos descargar una versión evaluación de este producto de la siguiente pagina. http://www.eeye.com • Cis: este es un pequeño programa, muy útil, pero que no tiene tantas funcionalidades como el retina. Lo podemos descargar de http://www.astake.com .



4.8 Sniffers, la amenaza interna

En esta parte hablaremos de unos programas que sirven para "pinchar" la red, en estos momentos que se escuchan tantas noticias, de que el correo ha sido pinchado, y todas esas cosas.

4.8.1 Pensemos este escenario

Un cybercafe, donde la mayoría de la gente, chatea, navega, y escribe algún que otro mail. Para colmo, en ese cybercafe, tenemos un administrador medio despistado, que usa como servidor de Internet, un Microsoft Proxy Server. Al ver que este mismo cibercafe, no tiene una red switcheada, sino que toda la difusión la hace un hub, vemos que las posibilidades de sniffear son bastante elevadas.

4.8.2 Pero, vayamos por pasos, y veamos algo de teoría

Un sniffer es un programa, que se aprovecha de la mala implementación de los paquetes tcp, y como estos no viajan encriptados, al capturarlos, se revela toda la información que viaja en ellos, como pueden ser passwords, u otra información importante. Existen varios tipos de sniffers, y para distintas plataformas, pero veamos un par de ellos. Comenzaremos nombrando uno de ellos, para Windows, como puede ser el distinto, donde nos proponen bajarnos una versión gratuita a modo de prueba, y como no, que la bajaremos. Una vez allí, veremos que tenemos para seleccionar un adaptador, que en este caso es nuestra plaqueta de red, y que vemos un embudito, para poder filtrar los paquetes. Una vez que hacemos esto, vemos los paquetes viajando, y a la vez, vemos que esta la codificación en hexadecimal, y la correspondiente traducción a su lado.

4.8.3 Ejemplo practico

Nuestro amigo, el de la maquina de al lado, resulta que esta chateando, en un chat XXX, es posible que le capturemos varias secciones de su chat. Este programa tiene como pro lo fácil de configurar y/o usar, y como dificultad, que la información contiene demasiada "basura". Ahora bien, estamos a la espera de que el administrador se conecte, y que largue la pass de dominio, se conecta, y nada! Muy bien, lo que sucede es que para poder capturar esa contraseña, no necesitamos un sniffer cualquiera, si no, sniffers especiales, a los que haremos mención ahora.

4.8.4 Lophtcrack

Este tan conocido y usado, lopthcrack, en su versión 2.5 y posteriores, incluye un sniffer, llamado smb capture, que captura las contraseñas, y luego el mismo la puede crackear. Fácil de usar, indudablemente lophtcrack es uno de los mejores programas vistos de seguridad en nt, junto con Retina, sin lugar a dudas. Para descargar este programita, nos dirigimos a la página de lopht. http://www.lopht.com

4.8.5 Smbsniff En la misma pagina de l0pht, existe este programa, realizado en plataformas Linux, y dedicado a capturar contraseñas de NT, o passwords "hasheados".

4.8.6 Winsniff

Realmente este programa no lo probamos mucho, pero nos gusto, por que puede funcionar en conjunto con el unicode. Se puede dejar corriendo en background. y pueden redirigirse todos los paquetes capturados hacia un archivo de passwords, en el cual estarán alojados estos. Para descargar este programa, actualmente lo encontré en la página

http://www.350cc.com



Estos son los sniffers, que hemos visto por aquí, es una presentación rápida, luego los veremos en mayor profundidad.

4.9 Linux también existe

En Linux también tenemos sniffers, como pueden ser

TCPDUMP SNIFFIT LIN-SNIFF Y OTROS.

Por comodidad, vamos a describir el sniffit, dando sus características, su potencialidad, y su posible uso. Tan solo descargar el sniffit, que lo podemos bajar de ..... y lo instalamos, ya tenemos la potencialidad de un sniffer muy poderoso. Por ejemplo, muestra de su poder es que puede capturar secciones en forma grafica, que limpia la escoria de "tcp", y que soporta filtrado por ip, y aun mas, por puertos!!!!!!!!!. Si somos fiacas, y queremos mas, lo que tenemos a mano, es el sniffit en forma interactiva, tan solo poniendo el sniffit -i, lanzamos a correr nuestro sniffer en una simpática pantallita azul. aquí, con las teclas F1 a F4 podremos seleccionar los ip de destino, de origen y los puertos de ellos. Pero, si nosotros quisiéramos que capture los passwords,. y dejarlo corriendo en segundo plano, no nos serviría de mucho. Para esto sniffit, posee unas grandes opciones para la línea de comando, y lo que haremos es lo siguiente. sniffit -p <n puerto> y esto logra sniffear tanto las conexiones de entrada como las de salida de ese puerto, aunque lo mejor seria enganchar a un "target" fijo.

4.9.1 Vamos a citar un ejemplo de la vida real.

Un jefe quería saber que actividad tenia el informix, y quería saber quien realizaba un cambio de permisos o un GRANT. Los pasos que se siguió para resolver esto, fue:

a) Primero se sniffio todas las conexiones de una lan hacia el puerto del informix, que es el 1525, y esto , lo se direccionaba hacia un archivo ascii llamado "save".

b) el archivo "save", seria procesado por un programita en c, cuya función era detectar la cadena GRANT, y mandar un mail avisando al administrador del sistema.

Como vemos, un sniffer puede sernos de gran ayuda, para quien lo administre con buenos fines. Otro "sniffer" o analizador de red, es el monitor de red, que trae windows nt. Con este se captura todo el trafico de la red, inclusive contraseñas POP.

4.9.2 Detectando un sniffer

Lo que básicamente realiza un sniffer es poner la placa de red en modo promiscuo, o sea decir que todas las comunicaciones en la red, pasan por esta interface. Podremos ver esto si realizamos un: ifconfig, y el resultado nos demuestra un promisc, significa que ese equipo ha estado snifeando! Pero, esto no es muy practico, considerando que un sniffer hay que detectarlo en forma remota, ya que no podemos ir por todas las maquinas viendo esto, para eso, hay un proggie llamado "Antisniff" de los laboratorios l0pht.


Capitulo 5: Firewall Iptables 6

5 Firewall de TCP / IP

5.1 Introducción

La seguridad resulta cada vez más importante tanto para las compañías como para los individuos. Internet les ha proporcionado una poderosa herramienta para distribuir información entre ellos y para obtener información de otros, pero también les ha expuesto a peligros de los que habían estado exentos hasta entonces. La criminalidad informática, el robo de información y el daño malintencionado constituyen peligros potenciales.

Una persona no autorizada y sin escrúpulos que consiga el acceso al sistema de una computadora puede que averigüe contraseñas del sistema o que se aproveche de los errores y del comportamiento particular de ciertos programas para obtener una cuenta funcional en dicha máquina. Una vez que sea capaz de entrar en la máquina, puede que tenga acceso a información que podría resultar dañina, información tan sensible comercialmente como los planes de negocio, detalles de nuevos proyectos o las bases de datos con información de los clientes. Un daño a este tipo de datos o su modificación puede causar severos retrasos a la compañía.

La forma más segura de evitar daños de tanto alcance consiste en impedir que las personas no autorizadas puedan obtener el acceso a la máquina. Aquí es donde intervienen los firewall.

Este capítulo se centrará en aspectos técnicos específicos de Linux. Más adelante se presentará un ejemplo de configuración del firewall que debería servir como punto de partida para su propia configuración, pero, como con todos los asuntos relacionados con la seguridad, no confíe en nadie. Vuelva a comprobar otra vez el diseño, asegúrese de que lo entiende y entonces modifíquelo para ajustarlo a sus requerimientos. Para estar a salvo, esté seguro.



5.2. Métodos de ataque

Como administrador de una red, es importante que usted entienda la naturaleza de los posibles ataques a la seguridad informática. Se describirán brevemente los tipos de ataques más importantes para que usted pueda comprender mejor y de forma más precisa de qué le protegerá un firewall sobre Linux. Debería realizar alguna lectura adicional para asegurarse de que está capacitado para proteger su red de otros tipos de ataques. Aquí están algunos de los más importantes métodos de ataque y las maneras de protegerse contra ellos:

Acceso no autorizado

Esto simplemente quiere decir que personas que no deberían utilizar los servicios de su computadora son capaces de conectarse y utilizarlos. Por ejemplo, personas de fuera de su compañía podrían intentar conectarse a la máquina con las cuentas de su compañía o a su servidor de NFS.

Existen varias formas de evitar este ataque especificando con cuidado quién puede tener acceso a estos servicios. Usted puede evitar el acceso a la red a todo el mundo excepto a los usuarios deseados.

Aprovechamiento de las debilidades conocidas de un programa

Algunos programas y servicios de red no fueron diseñados originalmente teniendo en cuenta una elevada seguridad y son inherentemente vulnerables a los ataques. Los servicios remotos del tipo BSD (rlogin, rexec, etc.) constituyen un ejemplo.

La mejor manera de protegerse contra este tipo de ataque consiste en deshabilitar los servicios vulnerables o en encontrar alternativas. Con 'software' de código abierto resulta muchas veces posible reparar sus debilidades.

Denegación de servicio

Los ataques de denegación de servicio causan que el servicio o programa deje de funcionar o impide que otros hagan uso de ese servicio o programa. Estos ataques pueden ser realizados al nivel de red enviando datagramas cuidadosamente preparados y malintencionados de tal forma que puedan causar que las conexiones de red fallen. También pueden realizarse a nivel de aplicación, donde órdenes cuidadosamente construidas se envían contra un programa para tratar que se vuelva muy ocupado o que pare su funcionamiento.

Impedir que el tráfico de red sospechoso alcance sus máquinas y que lleguen órdenes y peticiones de programa sospechosos son las mejores formas de minimizar el riesgo de un ataque de denegación de servicio. Resulta muy útil conocer los detalles del método de ataque, por lo que debería aprender usted mismo todo lo posible de cada tipo nuevo de ataque que se haga público.

Suplantación de identidad

Este tipo de ataque causa que un 'host' o aplicación simule las acciones de otro. Típicamente, el atacante se hace pasar por un 'host' inocente siguiendo el rastro de las direcciones IP contenidas en los paquetes de red. Por ejemplo, un 'exploit' bien documentado del servicio de tipo BSD rlogin puede utilizar esta técnica para simular una conexión de TCP desde otro 'host' prediciendo los números de secuencia de TCP.

Para protegerse contra este tipo de ataque, verifique la autenticidad de los datagramas y órdenes. Evite el encaminamiento de datagramas con direcciones de origen no válidas. Introduzca impredicibilidad en los mecanismos de control de la conexión, como los números de secuencia de TCP y la asignación dinámica de puertos.

'Eavesdropping'

Éste es el método de ataque más simple. Un 'host' se configura para escuchar" y capturar los datos no destinados a él. Programas de fisgoneo cuidadosamente escritos pueden obtener los nombres de usuario y sus contraseñas a partir de las conexiones de red con ingresos de usuarios en el sistema. Redes de difusión como las de tipo Ethernet son especialmente vulnerables a este tipo de ataques.

Para protegerse contra este tipo de amenazas, evite el uso de tecnologías de red con difusiones e imponga el uso de encriptación de los datos.

Los firewalls de IP resultan muy útiles para evitar o reducir los accesos no autorizados, los ataques de denegación de servicio a nivel de red, y los ataques de suplantación de identidad. No resultan muy útiles para evitar el aprovechamiento de las debilidades de los servicios de red o programas ni el ['eavesdropping'].



5.3 ¿Qué es un firewall?

Un firewall es una máquina segura y confiable que se asienta entre una red privada y una red pública. La máquina firewall se configura con un conjunto de reglas que determinan a qué tráfico de red se le permitirá pasar y cuál será bloqueado o rechazado. En algunas organizaciones grandes, puede que encuentre un firewall localizado dentro de la red corporativa para separar áreas sensibles de la organización de otros empleados. Algunos casos de criminalidad informática acontecen dentro de la misma organización, no sólo provienen de fuera.

Se pueden construir firewall en una variedad de maneras. La configuración más sofisticada involucra un número de máquinas separadas y se conoce como red del perímetro. Dos máquinas, denominadas estranguladoras actúan como "filtros" para permitir pasar sólo ciertos tipos de tráfico de red, y entre estos estranguladores residen servidores de red como una pasarela de correo o un servidor intermediario de 'World Wide Web'. Esta configuración puede resultar muy segura y permite de forma fácil un amplio rango de control sobre quién puede conectarse tanto desde dentro hacia fuera cómo desde fuera hacia dentro. Este tipo de configuración debería ser el utilizado por las grandes organizaciones.

Sin embargo, típicamente los firewall son máquinas únicas que sirven todas estas funciones. Esto es algo menos seguro, porque si hay alguna debilidad en la propia máquina del firewall que le permita a alguien conseguir el acceso al mismo firewall, la seguridad de toda la red habrá sido comprometida. Sin embargo, estos tipos de firewall son más baratos y fáciles de mantener que la configuración más sofisticada descrita arriba. La Figura 5-1 ilustra los dos tipos más comunes de configuración de firewall.

Figura 5-1. Las dos clases más importantes de diseño de firewall

El núcleo de Linux proporciona un rango de características internas que le permiten funcionar bastante bien como un firewall de IP. La implementación de red incluye código para realizar filtros a nivel de IP en numerosas formas, y proporciona un mecanismo para configurar con precisión qué tipos de reglas le gustaría imponer. El firewall en Linux es suficientemente flexible como para convertirle un algo muy útil en cualquiera de las configuraciones ilustradas en la Figura 5-1. El 'software' de firewall de Linux proporciona otras dos características muy útiles que se discutirán mas adelante.



5.4 ¿Qué es el filtrado de IP?

El filtrado de IP es simplemente un mecanismo que decide qué tipos de datagramas de IP serán procesados normalmente y cuáles serán descartados. Por descartados se entiende que el datagrama se elimina y se ignora completamente, como si nunca se hubiera recibido. Usted puede aplicar muchos criterios, y en diferentes ordenamientos, para determinar qué datagramas desea filtrar; algunos ejemplos de esto son:

• Tipo de protocolo: TCP, UDP, ICMP, etc.

• Número de conector (para TCP/UDP)

• Tipo de datagrama: SYN/ACK, datos, petición de eco de ICMP, etc.

• Dirección de origen del datagrama: de donde proviene

• Dirección de destino del datagrama: adonde se dirige

Llegado este punto, resulta muy importante comprender que el filtrado de IP es una utilidad en la capa de red. Esto significa que este mecanismo no entiende nada acerca de la aplicación que utiliza las conexiones de red, sólo sabe acerca de las conexiones mismas. Por ejemplo, usted puede denegar el acceso a usuarios a su red interna por el puerto de defecto de telnet, pero si se apoya únicamente en el filtrado de IP, no podrá evitar que se utilice el programa de telnet en un puerto por el que usted permite el paso a través de su firewall. Puede evitar este tipo de problemas haciendo uso de servidores intermediarios para cada servicio que permita que cruce su firewall. Los servidores intermediarios comprenden la aplicación para la que fueron diseñados y por tanto evitan los abusos, tales como utilizar el programa de telnet para pasar a través de un firewall utilizando el puerto de 'World Wide Web'. Si su firewall soporta un servidor intermediario de 'World Wide Web', aquella conexión de telnet será siempre respondida por el servidor intermediario que sólo permitirá que pasen peticiones HTTP. Existe un gran número de programas servidores intermediarios. Algunos son 'software' libre y muchos otros son productos comerciales. El documento 'Firewall-HOWTO' expone un subconjunto popular de aquellos, pero esto queda fuera del alcance de este libro.

El conjunto de reglas de filtrado de IP se construye a partir de muchas combinaciones de los criterios enumerados previamente. Por ejemplo, imagínese que usted quiere que los usuarios del 'World Wide Web' dentro de la red de Virtual Brewery no tengan acceso a ningún servicio de Internet excepto a los servidores Web. Entonces configuraría su firewall permitiendo el reenvío de:

• datagramas con una dirección de origen dentro de la red de Virtual Brewery, una dirección de destino cualquiera y con un puerto de destino igual a 80 (el de WWW)

• datagramas con dirección de destino dentro de la red de Virtual Brewery y un puerto de origen igual a 80 (WWW) siendo cualquiera la dirección de origen

Nótese que se han utilizado dos reglas aquí. Se tiene que permitir que nuestros datos salgan fuera, pero también que la correspondiente respuesta vuelva. En la práctica, como se verá en breve, Linux simplifica esto y nos permite especificar lo mismo en una sola orden.



5.5 Configuración de Linux como firewall

Para poder construir un firewall IP con Linux, es necesario disponer de un núcleo compilado con soporte de firewall de IP y de la utilidad de configuración adecuada. En todos los núcleos anteriores a la serie 2.2 se usaba la utilidad ipfwadm. Los núcleos 2.2.x supusieron el lanzamiento de la tercera generación de firewall de IP para Linux que se denominó 'IP Chains'. 'IP chains' utiliza un programa similar a ipfwadm que se llama ipchains. Los núcleos de Linux 2.3.15 y siguientes soportan la cuarta generación de firewall de IP de Linux que se denomina netfilter. El código de netfilter es el resultado de un gran rediseño del flujo en el manejo de paquetes en Linux. Netfilter es una criatura con múltiples facetas, pues proporciona un soporte compatible hacia atrás tanto con ipfwadm como con ipchains además de una nueva orden alternativa que se llama iptables. En este manual nos abocaremos a iptables.

5.5.1. Núcleo configurado con firewall de IP

El núcleo de Linux debe configurarse para que dé soporte a las funciones de firewall de IP. Sólo hay que seleccionar las opciones adecuadas cuando se realiza un make menuconfig del núcleo. En los núcleos 2.4.0 y posteriores se deberían seleccionar estas opciones:

Networking options ---> [*] Network packet filtering (replaces ipchains) IP: Netfilter Configuration ---> . <M> Userspace queueing via NETLINK (EXPERIMENTAL) <M> IP tables support (required for filtering/masq/NAT) <M> limit match support <M> MAC address match support <M> netfilter MARK match support <M> Multiple port match support <M> TOS match support <M> Connection state match support <M> Unclean match support (EXPERIMENTAL) <M> Owner match support (EXPERIMENTAL) <M> Packet filtering <M> REJECT target support <M> MIRROR target support (EXPERIMENTAL) . <M> Packet mangling <M> TOS target support <M> MARK target support <M> LOG target support <M> ipchains (2.2-style) support <M> ipfwadm (2.0-style) support

5.5.2 La utilidad iptables

La sintaxis de la utilidad iptables es bastante similar a la de ipchains. Los cambios consisten en mejoras y en el resultado del rediseño de la herramienta para que sea extensible a través de librerías dinámicas.

La utilidad iptables se incluye en el paquete de código fuente de netfilter que está disponible en http://www.samba.org/netfilter/. También estará incluido en cualquier distribución basada en la serie de núcleos 2.4.

Se hablará un poco del importante paso hacia delante que netfilter representa en una sección dedicada más adelante en este capítulo.



5.6 Las formas posibles de filtrado

Considérese cómo una máquina Unix, o de hecho cualquier máquina capaz de realizar encaminamiento de IP, procesa los datagramas de IP. Los pasos básicos, mostrados en la Figura 5-2 son:

Figura 5-2. Las etapas del procesamiento de un datagrama de IP

• Se recibe el datagrama de IP. (1)

• Se examina el datagrama de IP entrante para determinar si está destinado a un proceso de esta máquina.

• Si el datagrama es para esta máquina, se procesa localmente.(2)

• Si no está destinado a esta máquina, se realiza una búsqueda en la tabla de encaminamiento de una ruta adecuada y el datagragama se reenvía por la interfaz adecuada o se elimina si no se puede encontrar una ruta. (3)

• Los datagramas procedentes de procesos locales se envían hacia el 'software' de encaminamiento para ser reenviados hacia la interfaz apropiada. (4)

• Se examina el datagrama de IP saliente para determinar si existe una ruta válida que escoger, si no es así, se elimina.

• Se transmite el datagrama de IP. (5)

En nuestro diagrama, el flujo 1→3→5 representa nuestra máquina encaminando datos entre un 'host' sobre nuestra red Ethernet y un 'host' alcanzable vía nuestro enlace de PPP. Los flujos 1→2 y 4→5 representan los flujos de entrada y de salida de datos de un programa de red ejecutándose en nuestro 'host' local. El flujo 4→3→2 representaría un flujo de datos vía una conexión 'loopback'. Naturalmente, los datos fluyen tanto hacia dentro como hacia fuera de los dispositivos de red. Los símbolos de interrogación del diagrama representan los puntos dónde la capa de IP realiza las decisiones de encaminamiento.

El firewall de IP del núcleo de Linux es capaz de aplicar filtrados en varias etapas de este proceso. Es decir, se pueden filtrar los datagramas de IP que entren en su máquina, aquellos que estén siendo reenviados a través de su máquina y aquellos que estén preparados para ser transmitidos.

En iptables, una regla de tipo 'Input' se aplica al flujo 2 del diagrama, una regla de tipo 'Forwarding' al flujo 3 y una regla de tipo 'Output' al flujo 4. Esto tiene implicaciones importantes sobre cómo se deben estructurar los conjuntos de reglas, pero los principios generales permanecen válidos para todos los tipos de firewall de Linux.

Todo esto puede parecer complicado de forma innecesaria en un primer momento, pero proporciona una flexibilidad que permite construir configuraciones muy sofisticadas y poderosas.



5.7 Netfilter e 'IP Tables' (Núcleos 2.4)

Mientras desarrollaba el firewall 'IP Chains', Paul Russell decidió que realizar funciones de firewall de IP debería ser algo menos difícil; pronto asumió como tarea simplificar los aspectos de procesamiento de datagramas en el código de firewall del núcleo y produjo un esquema de filtrado que era mucho más claro y mucho más flexible. Denominó este nuevo esquema netfilter.

Pero, ¿qué era lo que no estaba bien con las cadenas de IP de ipchains? Habían aumentado de forma importante la eficiencia y la gestión de las reglas del firewall. Pero la forma que tenían de procesar los datagramas eran todavía complejas, en especial en conjunción con características relacionadas con las funciones de firewall como el enmascaramiento de IP y con otras formas de traducciones de direcciones. Parte de esta complejidad era debida a que el enmascaramiento de IP y la traducción de direcciones de red fueron funciones desarrolladas independientemente del código de firewall e integradas más tarde, en vez de haber sido diseñadas como partes mismas del código del firewall desde el principio. Si un desarrollador deseara añadir todavía más características a la secuencia de procesamiento de datagramas, entonces se encontraría con dificultades para encontrar el lugar donde insertar el código y se habría visto obligado a realizar cambios en el núcleo.

Además, había otros problemas. En concreto, la cadena “input” describía la entrada a la capa de red de IP tomada en conjunto. La cadena input afectaba tanto a los datagramas que estaban destinados a este 'host' así como los datagramas que iban a ser encaminados. Esto resulta contrario a la intuición porque se confundía la función de la cadena 'input' con la de la cadena 'forward', que se aplicaba sólo a los datagramas que iban a ser reenviados, pero que siempre seguía a la cadena 'input'. Se quería tratar de forma diferente los datagramas para el propio 'host' de los que iban a ser reenviados, era necesario construir reglas complejas que excluían a unos o a otros. El mismo problema aparecía con la cadena “output” de salida.

Esta complejidad influía de forma inevitable en el trabajo del administrador de sistemas porque se veía reflejada en la forma en que se debían diseñar los conjuntos de reglas. Además, cualquier extensión al proceso de filtrado exigía la modificación directa del núcleo, porque todas las políticas de filtrados estaban implementadas allí y no había forma de proporcionar una interfaz transparente. netfilter aborda tanto la complejidad como la rigidez de las soluciones antiguas implementando un esquema genérico en el núcleo que simplifica la forma en que se procesan los datagramas y proporciona la posibilidad de extender las políticas de filtrado sin tener que modificar el núcleo.

Veamos dos de los cambios claves realizados. La Figura 5-3 ilustra cómo se procesan los datagramas en la implementación de 'IP Chains', mientras que Figura 5-4 ilustra cómo se procesan en la implementación de netfilter. Las diferencias claves consisten en la eliminación de la función de enmascaramiento del código central y de un cambio en la localización de las cadenas de entrada y de salida. En acompañamiento a estos cambios, se creó una herramienta de configuración nueva y extensible que se denominó iptables.

En 'IP Chains' la cadena de entrada se aplica a todos los datagramas recibidos por el 'host', independientemente de si están destinados al 'host' local o de si serán encaminados a otro 'host'. En netfilter, la cadena 'input' de entrada se aplica solamente a los datagramas destinados al 'host' local, y la cadena 'forward' de reenvío se aplica sólo a los datagramas destinados a otro 'host'. De forma similar, en 'IP chains', la cadena 'output' de salida se aplica a todos los datagramas que abandonen el 'host' local, independientemente de si el datagrama se genera en el 'host' local o ha sido encaminado desde otro 'host'. En netfilter, la cadena 'output' de salida se aplica solamente a los datagramas generados en este 'host' y no se aplica a los datagramas que están siendo encaminados provenientes de otro 'host'. Este cambio por sí solo ofrece una enorme simplificación de muchas configuraciones de firewall.

Figura 5-3. Procesamiento de datagramas en 'IP Chains'



En la Figura 5-3, los componentes etiquetados como “demasq” y “masq” son componentes separados de núcleo que son responsables del procesamiento de los datagramas enmascarados entrantes y salientes. Estos componentes han sido reimplementados como módulos de netfilter.

Considérese el caso de una configuración para la que la política por defecto para cada una de las cadenas 'input', 'forward' y 'output' es deny. En 'IP Chains', se necesitarían seis reglas para permitir cualquier sesión a través del 'host' firewall; dos para cada una de las cadenas 'input, 'forward' y 'output' (una cubriría el camino en un sentido y la otra en el sentido contrario). Puede imaginarse cómo esto puede llegar a resultar extremadamente complejo y difícil de gestionar cuando se mezclan sesiones que pueden ser encaminadas y sesiones que podrían conectarse al 'host' local sin que deban ser encaminadas. 'IP chains' le permite crear cadenas que le simplificarían esta tarea un poco, pero su diseño no resulta evidente y requiere de un cierto nivel de experiencia.

En la implementación de netfilter con iptables, esta complejidad desaparece completamente. Para que se pueda encaminar por un 'host' firewall un servicio que se desea prohibir que termine en el propio 'host', sólo se necesitan dos reglas: una para un sentido y otra para el contrario ambas en la cadena 'forward'. Esto es la forma obvia de diseñar reglas de firewall, y servirá para simplificar enormemente el diseño de las configuraciones del firewall.

Figura5-4. Cadena de procesamientos de datagramas en 'netfilter'

El documento PACKET-FILTERING-HOWTO ofrece una lista detallada de los cambios que se han realizado, por lo que aquí nos vamos a centrar en los aspectos más prácticos.

5.7.1 Compatibilidad hacia atrás con ipfwadm e ipchains

La flexibilidad notoria de netfilter en Linux queda ilustrada por su habilidad para emular las interfaces ipfwadm e ipchains. La emulación hace un poco más sencilla la transición a la nueva generación del 'software' de firewall.

Los dos módulos de netfilter del núcleo denominados ipfwadm.o e ipchains.o proporcionan la compatibilidad hacia atrás para ipfwadm e ipchains. Sólo puede cargarse uno de estos módulos a la vez, y utilizarlo sólo si el módulo ip_tables.o no está cargado. Cuando se ha cargado el módulo apropiado, entonces netfilter funciona exactamente de la misma forma que la anterior implementación del firewall.

netfilter imita la interfaz de ipchains con las siguientes órdenes:

rmmod ip_tables modprobe ipchains ipchains ...

5.7.2 Uso de iptables

La utilidad iptables se utiliza para configurar las reglas de filtrado de netfilter. Su sintaxis se apoya fuertemente en la de la orden ipchains, pero difiere en un aspecto muy importante: es extensible. Esto quiere decir que su funcionalidad puede extenderse sin tener que recompilar. Consigue este truco utilizando bibliotecas compartidas. Hay extensiones estándares de las que se explorarán algunas dentro de un momento.

Antes de que se pueda utilizar la orden iptables, se debe cargar el módulo del núcleo de netfilter que proporciona el soporte para ello. La forma más fácil de hacerlo es con la orden modprobe:

modprobe ip_tables



La orden iptables se utiliza para configurar tanto el filtrado de IP como la traducción de direcciones de red. Para facilitar esto, existen dos tablas de reglas denominadas filter y nat. Por defecto, se asume la tabla 'filter' salvo que se especifique la opción -t. También se proporciona cinco cadenas predefinidas. Las cadenas INPUT y FORWARD están disponibles para la tabla filter, las cadenas PREROUTING y POSTROUTING están disponibles para la tabla nat, y la cadena OUTPUT está disponible para ambas tablas. En este capítulo se discutirá solamente la tabla filter.

La sintaxis general de la mayoría de las órdenes de iptables es:

iptables orden especificación_de_regla extensiones

Veamos alguna de las opciones con detalle, y después se revisarán algunos ejemplos.

5.7.2.1. Órdenes

Existen varias formas de manipular las reglas y los conjuntos de reglas con la orden iptables. Las relevantes para la función de firewall de IP son:

-A cadena

Añade una o más reglas al final de la cadena especificada. Si se proporciona un nombre de 'host' tanto como origen como destino y se resuelve a más de una dirección IP, se añadirá una regla por cada una de esas direcciones.

-I cadena número_de_regla

Inserta una o más reglas al comienzo de la cadena especificada. De nuevo, si se proporciona un nombre de 'host' en la especificación de la regla, se añadirá una regla por cada una de las direcciones que se resuelvan.

-D cadena

Borra de la cadena especificada una o más reglas que concuerden con la especificación de regla de la cadena especificada.

-D cadena número_de_regla

Borra la regla que ocupa la posición número_de_regla en la cadena especificada. Las posiciones de reglas comienzan en el 1 para la primera regla de la cadena.

-R cadena número_de_regla

Reemplaza la regla que ocupa la posición número_de_regla en la cadena especificada por la regla proporcionada en la especificación.

-C cadena

Comprueba el datagrama descrito por la especificación de la regla contra la cadena especificada. Esta orden devolverá un mensaje que describe cómo el datagrama procesa la cadena. Resulta de la mayor utilidad para las pruebas de la configuración del firewall por lo que se contemplará con más detalle más adelante.

-L [cadena]

Muestra las reglas de la cadena especificada, o de todas las cadenas si no se especifica ninguna.

-F [cadena]

Borra todas las reglas de la cadena especificada, o de todas las cadenas si no se especifica ninguna.

-Z [cadena]

Pone a cero los contadores de datagramas y bytes en todas las reglas de la cadena especificada, o de todas las cadenas si no se especifica ninguna.

-N cadena

Crea una nueva cadena con el nombre especificado. No puede existir antes una cadena del mismo nombre. Así es cómo se crean las cadenas de usuario.

-X [cadena]

Borra la cadena de usuario especificada, o todas las cadenas de usuario si no se especifica ninguna. Para que este comando tenga éxito. no deben existir referencias a la cadena especificada desde cualquier otra cadena de reglas.

-P cadena política

Establece la política por defecto de la cadena especificada a la política especificada. Las políticas válidas de firewall son ACCEPT, DROP, QUEUE, y RETURN. ACCEPT permite pasar a los datagramas. DROP causa que el datagrama sea descartado. QUEUE causa que el datagrama sea pasado al espacio de usuario para posterior procesamiento. La política RETURN causa que el código del firewall de IP vuelva a la cadena que llamó a la que contenía esta regla, y que continúe con la regla situada tras la regla desde la que se hizo la llamada.



5.7.2.2 Parámetros de especificación de reglas

Existe una serie de parámetros de iptables que constituyen la especificación de una regla. Donde se requiera la especificación de una regla, se debe proporcionar algunos de esos parámetros o se asumirá sus valores por defecto.

-p [!]protocolo

Especifica el protocolo del datagrama que concordará con esta regla. Los nombres válidos de protocolos son tcp, udp, icmp, o un número, si se conoce el número del protocolo de IP. Por ejemplo, podría utilizarse un 4 para concordar con el protocolo de encapsulamiento ip. Si se proporciona el signo!, entonces se niega la regla y el datagrama concordará con cualquier protocolo diferente del especificado. Si no se proporciona este parámetro, se asume por defecto la concordancia con todos los protocolos.

-s [!]dirección[/máscara]

Especifica la dirección de origen del datagrama que concordará con esta regla. Se puede proporcionar la dirección como un nombre de 'host', como un nombre de red o como una dirección de IP. El parámetro opcional máscara es la máscara de red que se utilizará y puede proporcionarse tanto en la forma tradicional (e.g., /255.255.255.0) como en la forma moderna (e.g., /24).

-d [!]dirección[/máscara]

Especifica la dirección de destino del datagrama que concordará con esta regla. La codificación de este parámetro es la misma que la del parámetro -s.

-j blanco

Especifica qué acción se tomará cuando se concuerde con esta regla. Puede pensarse en este parámetro como con el significado de “salta a”. Los blancos válidos son ACCEPT, DROP, QUEUE, y RETURN. Se describieron sus significados más arriba. Sin embargo, también puede proporcionarse el nombre de una cadena de usuario, que sería por donde el proceso continuaría. También puede proporcionarse el nombre de un blanco complementado con el de una extensión. Se hablará acerca de las extensiones en breve. Si se omite este parámetro, no se realizará ninguna acción sobre los datagramas concordantes, excepto la actualización de los contadores de datagramas y bytes de esta regla.

-i [!]nombre_de_interfaz

Especifica la interfaz por la que se recibió el datagrama. De nuevo, el signo “! invierte el resultado de la concordancia. Si el nombre de la interfaz acaba con un signo “+”entonces cualquier interfaz que comience con la cadena proporcionada concordará. Por ejemplo, -i ppp+ concordará con cualquier dispositivo de red de PPP y -i ! eth+ con todas las interfaces excepto las correspondientes a dispositivos de Ethernet.

-o [!]nombre_de_interfaz

Especifica la interfaz por la que se enviará el datagrama. Este argumento tiene la misma codificación que el argumento -i.

[!] -f

Especifica que esta regla se aplica al segundo y restantes fragmentos de un datagrama fragmentado, y no al primer fragmento.

5.7.2.3. Opciones

Las siguientes opciones de iptables son más generales por naturaleza propia. Algunas de ellas controlan características bastante esotéricas del 'software' de netfilter.

-v

Hace que iptables sea más explícito en su salida. Proporcionará más información.

-n

Hace que iptables muestre las direcciones de IP y los números de puertos en forma de números sin intentar resolverlos contra sus correspondientes nombres.

-x

Fuerza que los números de salida de iptables parezcan con sus valores exactos sin ninguna aproximación.

- -line-number

Causa que se muestren los números de línea en los listados de los conjuntos de reglas. El número de línea corresponderá con la posición de la regla dentro de la cadena.

5.7.2.4 Extensiones

Se dijo antes que la utilidad iptables es extensible a través de módulos de bibliotecas compartidas. Existen alguna extensiones estándares que proporciona algunas de las



características que ipchains proporcionaba. Para utilizar una extensión, se debe especificar su nombre con el argumento -m nombre de iptables. La lista siguiente muestra las opciones -m y -p que establecen el contexto de la extensión, y las opciones proporcionadas por esa extensión.

5.7.2.4.1 Extensiones de TCP: utilizadas con -m tcp -p tcp

- -sport [!] [puerto[:puerto]]

Especifica el puerto que debe utilizar el origen del datagrama para concordar con esta regla. Se pueden especificar los puertos en la forma de un rango, especificando los límites inferior y superior con un signo : como delimitador. Por ejemplo, 20:25 describe todos los puertos que van desde el 20 hasta el 25 incluyendo ambos. De nuevo, el signo ! puede utilizarse para negar los valores.

- -dport [!] [puerto[:puerto]]

Especifica el puerto que el datagrama de destino utilizará para concordar con esta regla. Este argumento se codifica de forma idéntica a la opción - -sport.

- -tcp-flags [!] máscara comp

Especifica que esta regla debe concordar cuando los indicadores de TCP del datagrama concuerden con los especificados por máscara y comp. máscara es una lista separada por comas de los indicadores que deben examinarse en la comprobación. comp es una lista separada por comas de indicadores cuyo valores han de ser todos 1 para que la regla concuerde. Los indicadores válidos son: SYN, ACK, FIN, RST, URG, PSH, ALL o NONE. Esto constituye una opción avanzada: consúltese una buena descripción del protocolo de TCP, como el documento RFC-793, para la explicación del significado y la implicación de cada uno de estos indicadores. El signo ! niega la regla.

[!] - -syn

Especifica que la regla concordará sólo con los datagramas cuyo bit SYN valga 1 y cuyos bits ACK y FIN valgan ambos 0. Los datagramas con estos valores de los indicadores se utilizan para abrir las conexiones de TCP, por tanto esta opción puede ser utilizada para gestionar las solicitudes de conexión. Esta opción es una abreviatura de:

- -tcp-flags SYN,RST,ACK SYN

Cuando se utilice el operador de negación, la regla concordará con todos los datagramas cuyos bits SYN y ACK no valgan 1 simultáneamente.

5.7.2.4.2 Extensions de UDP: utilizadas con -m udp -p udp

- -sport [!] [port[:port]]

Especifica el puerto que debe utilizar el origen del datagrama para concordar con esta regla. Se pueden especificar los puertos en la forma de un rango, especificando los límites inferior y superior con un signo : como delimitador. Por ejemplo, 20:25 describe todos los puertos que van desde el 20 hasta el 25 incluyendo ambos. De nuevo, el signo ! puede utilizarse para negar los valores.

- -dport [!] [port[:port]]

Especifica el puerto que el datagrama de destino utilizará para concordar con esta regla. Este argumento se codifica de forma idéntica a la opción - -sport.

5.7.2.4.3 Extensiones de ICMP: utilizadas con -m icmp -p icmp

- -icmp-type [!] nombre_de_tipo

Especifica el tipo de mensaje de ICMP que concordará con esta regla. Puede especificarse el tipo tanto por su númeero como por su nombre. Algunos nombres válidos son: echo-request, echo-reply, source-quench, time-exceeded, destination-unreachable, network-unreachable, host-unreachable, protocol-unreachable, y port-unreachable.

5.7.2.4.4 Extensiones de MAC: utilizadas con -m mac

- -mac-source [!] address

Especifica la dirección Ethernet del 'host' transmisor que concuerda con esta regla. Esto sólo tiene sentido en una regla de la cadena de entrada 'input' o de reenvío 'forward' porque se trasmitirá cualquier datagrama que pase la cadena de salida 'output'.



5.7.3 Nuestro ejemplo simple revisado otra vez

Para implementar nuestro ejemplo simple con netfilter, simplemente se podría cargar el módulo ipchains.o para que se comporte como la versión ipchains. En cambio, se volverá a realizar una implementación con iptables para ilustrar lo similar que es.

De nuevo, supóngase que se dispone en nuestra organización de una red y que se está utilizando una máquina firewall basada en Linux para permitir a nuestros usuarios que sean capaces de acceder a servidores WWW de Internet, y para impedir el paso de cualquier otro tipo de tráfico.

Si nuestra red tiene una máscara de red de 24 bits (clase C) y tiene como dirección 172.16.1.0, entonces se podría utilizar las siguientes reglas de iptables:

# modprobe ip_tables # iptables -F FORWARD # iptables -P FORWARD DROP # iptables -A FORWARD -m tcp -p tcp -s 0/0 --sport 80 -d 172.16.1.0/24 / --syn -j DROP # iptables -A FORWARD -m tcp -p tcp -s 172.16.1.0/24 --sport / 80 -d 0/0 -j ACCEPT T

# iptables -A FORWARD -m tcp -p tcp -d 172.16.1.0/24 --dport 80 -s 0/0 -j ACCEPT

En este ejemplo, las órdenes de iptables se interpretan exactamente como sus equivalentes de ipchains. La diferencia más importante es que debe cargarse el módulo ip_tables.o. Nótese que iptables no soporta la opción -b, por lo que debe proporcionarse una regla para cada sentido.



5.8 Manipulación de los bits de TOS

Los bits del campo de tipo de servicio (TOS) son un conjunto de cuatro indicadores de un bit de la cabecera de IP. Si uno de estos indicadores de bit vale 1, un encaminador puede manipular el datagrama de forma diferente del caso en el que ningún indicador valiera 1. Cada uno de los cuatro bits tiene un propósito diferente y sólo uno de los bits de TOS puede valer 1 al mismo tiempo, es decir, las combinaciones no están permitidas. Estos indicadores de bit se denominan de "tipo de servicio" porque permiten que la aplicación que transmite los datos informe a la red del tipo de servicio de red que requiere.

Las clases de servicios de red disponibles son:

Demora mínima

Se utiliza cuando se le da la máxima importancia al tiempo de viaje de un datagrama del 'host' de origen al 'host' de destino (demora). Por ejemplo, un suministrador de red podría estar utilizando tanto conexiones de red de fibra como por satélite. Los datos transportados por las conexiones por satélite tienen que viajar más lejos y su demora entre los mismos extremos será por lo general mayor que la de las conexiones de red terrestres. Un suministrador de red podría elegir asegurarse que los datagramas con este tipo de servicio no se transporten por satélite.

Rendimiento máximo

Se utiliza cuando el volumen de datos transmitidos en cualquier período de tiempo es importante. Existen numerosos tipos de aplicaciones de red para las que el tiempo de demora no es muy importante pero el rendimiento sí que lo es; por ejemplo, las transferencias de ficheros en bloque. Un suministrador de red podría elegir encaminar los datagramas con este tipo de servicio vía rutas de demora alta, pero de gran ancho de banda, como las conexiones por satélite.

Fiabilidad máxima

Se utiliza cuando es importante tener alguna certeza de que los datos llegarán al destino sin necesidad de una retransmisión. El protocolo IP puede transportarse sobre un número variado de medios de transmisión de bajo nivel. Mientras que SLIP y PPP son adecuados para protocolos de enlace de datos, no son tan fiables para transportar IP como otras redes, como las redes X.25. Un suministrador de red podría tener disponible una red alternativa, que ofreciera alta fiabilidad para transportar IP y que se utilizaría cuando se eligiera este tipo de servicio.

Coste mínimo

Se utiliza cuando resulta importante minimizar el coste de los datos transmitidos. El alquiler de ancho de banda de un satélite para una transmisión transoceánica cuesta generalmente menos que el alquiler de espacio de un cable de fibra óptica sobre la misma distancia, por lo que los suministradores de red pueden elegir proporcionar ambos y cobrar de forma diferente según sea el que se utilice. En este escenario, el bit de tipo de servicio de “coste mínimo” puede ocasionar que los datagramas sean encaminados vía la ruta de menor coste por satélite.

5.8.1 Establecimiento de los bits de TOS con iptables

La herramienta iptables permite especificar reglas que capturen sólo los datagramas con los bits de TOS concordantes con los valores predeterminados por la opción -m tos, y que establezcan los bits de TOS de los datagramas de IP que concuerden con una regla con el blanco -j TOS. Pueden establecerse los bits de TOS solamente en las cadenas FORWARD y OUTPUT. La concordancia y el establecimiento ocurren de forma independiente. Se puede configurar todo tipo de reglas interesante. Por ejemplo, puede configurarse una regla que descarte todos los datagramas con una cierta combinación de bits de TOS, o una regla que establezca los bits de TOS solamente de los datagramas que provengan de unos ciertos 'hosts'. La mayoría de las veces, se utilizarán reglas que contengan tanto la concordancia como el establecimiento para así realizar traducciones de bits de TOS, como ya se podía hacer con ipfwadm o ipchains.

En lugar de la configuración complicada de dos máscaras de ipfwadm e ipchains, iptables utiliza la estrategia más simple de especificar de forma plana los bits de TOS que deben concordar, o los bits de TOS que deben establecerse. Además, en lugar de tener que recordar y utilizar el valor hexadecimal, puede especificarse los bits de TOS utilizando los nombres mnemotécnicos mostrados en la tabla siguiente.

La sintaxis general utilizada para concordar los bits de TOS se parece a:

-m tos --tos nombre_mnemotécnico [otros_args] -j target

La sintaxis general utilizada para establecer los bits de TOS se parece a:

[otros_args] -j TOS --set nombre_mnemotécnico



Recuérdese que las dos posibilidades generalmente se utilizarán juntas, pero que también pueden ser utilizadas de forma independiente si se quiere una configuración que así lo requiera.

Mnemónico Hexadecimal

Normal-Service 0x00

Minimize-Cost 0x02

Maximize-Reliability 0x04

Maximize-Throughput 0x08

Minimize-Delay 0x10



5.9 Comprobación de una configuración del firewall

Después de haber diseñado una configuración de firewall adecuada, es importante comprobar que efectivamente se obtiene lo que se deseaba. Una forma de hacerlo consiste en utilizar un 'host' de prueba fuera de nuestra red para que intente atravesar su firewall: esto puede llegar a resultar farragoso y lento, y se estaría limitado a la comprobación únicamente de aquellas direcciones que realmente puedan usarse.

Un método más rápido y sencillo está disponible con la implementación del firewall de Linux. Permite generar pruebas y ejecutarlas contra el firewall como si se estuviera haciendo la prueba con datagramas reales. Todas las variedades de 'software' del firewall del núcleo de Linux, ipfwadm, ipchains, e iptables, dan soporte a este tipo de comprobaciones. La implementación involucra el uso de la orden de comprobación relevante.

El procedimiento general de comprobación es como sigue:

1. Diseñe y configure su firewall utilizando iptables.

2. Diseñe una serie de comprobaciones que determinen si su firewall está realmente funcionando como deseaba. Puede utilizar cualquier dirección de origen o destino para realizar estas comprobaciones, por lo que escoja algunas combinaciones de direcciones que deberían ser aceptadas y otras que deberían ser rechazadas. Si se va a permitir o prohibir a un cierto rango de direcciones, es una buena idea comprobar las direcciones situadas justo en los límites del rango—una dirección justo dentro del rango y otra justo fuera del rango. Esto le ayudará a asegurarse de que configuró correctamente los rangos, pues a veces resulta muy fácil especificar de forma incorrecta las máscaras de su configuración. Si se filtra por número de protocolo y puerto, sus comprobaciones también deberían comprobar todas las combinaciones importantes de estos parámetros. Por ejemplo, si se desea aceptar TCP sólo en ciertas circunstancias, compruebe que se rechazan los datagramas de tipo de UDP.

3. Desarrolle reglas de iptables para implementar cada comprobación. Probablemente merezca la pena escribir todas estas reglas en un guión de tal forma que pueda hacer y rehacer la comprobación fácilmente a la vez que va corrigiendo los errores o cambiando el diseño. Las comprobaciones utilizan casi la misma sintaxis que las especificaciones de reglas, pero los argumentos tiene significados ligeramente diferentes. Por ejemplo, el argumento de dirección de origen de una especificación de una regla especifica la dirección de origen que deberían tener los datagramas concordantes con esta regla. En cambio, el argumento de dirección de origen en la sintaxis de comprobación especifica la dirección de origen del datagrama de prueba que se generará. En el caso de iptables, se debe utilizar la opción –C. En todos los casos siempre se deben especificar la dirección de origen, la dirección de destino, el protocolo y la interfaz que se utilizará como prueba. El resto de argumentos, como los números de puertos y los valores de los bits de TOS, son opcionales.

4. Ejecute cada orden de comprobación y anote el resultado. El resultado de cata comprobación consistirá en una única palabra que indicará el blanco final del datagrama después de haber cruzado la configuración del firewall; es decir, dónde terminará el proceso. Para el caso de iptables, pueden comprobarse las cadenas de usuario además de las predefinidas.

5. Compare la salida de cada comprobación contra el resultado deseado. Si encuentra alguna discrepancia, necesitará analizar su conjunto de reglas para determinar dónde cometió el error. Si escribió sus órdenes de pruebas en un fichero de guión, entonces podrá reejecutar la comprobación de forma fácil después de haber corregido cualquier error de la configuración del firewall. Se considera buena práctica borrar por completo sus conjuntos de reglas y reconstruirlas desde cero, en vez de estar realizando cambios dinámicamente. Esto le ayudará a asegurarse de que la configuración activa que está comprobando refleja el conjunto de órdenes de su guión de configuración.

Veamos lo que podría ser la trascripción de una comprobación manual de nuestro ejemplo simple con iptables. Recuerde que la red local del ejemplo era 172.16.1.0 con una máscara de red de 255.255.255.0, y que se permitían las conexiones de TCP hacia servidores Web de fuera de la red. La cadena de reenvío 'forward' no permitía pasar nada más. Empiece con una transmisión que sabemos debería funcionar, una conexión desde el 'host' local a un servidor Web de fuera:

# iptables -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 accepted

Fíjese en los argumentos que se han proporcionado y en la forma en que se utilizan para describir el datagrama. La salida de la orden indica que se aceptó el datagrama para su reenvío, que es lo que se esperaba.



Ahora hagamos otra prueba, esta vez con una dirección de origen que no pertenece a nuestra red, y, que por tanto, debería ser rechazada.

# iptables -C forward -p tcp -s 172.16.2.0 1025 -d 44.136.8.2 80 -i eth0 denied

Realice algunas comprobaciones más, con el mismo nivel de detalle que la primera comprobación pero con diferentes protocolos. También deberían ser rechazados:

# iptables -C forward -p udp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied # iptables -C forward -p icmp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied

Pruebe con otro puerto de destino, de nuevo esperando que sea rechazado:

# iptables -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 23 -i eth0 denied

Tendrá que recorrer un largo camino para estar tranquilo pues tendrá que diseñar una serie de comprobaciones muy exhaustiva. Aunque a veces esto resulta tan complicado como el diseño de la propia configuración del firewall, también es la mejor forma de saber si su diseño proporciona la seguridad que esperaba.



5.10 Un ejemplo de configuración del firewall

Se han discutido los fundamentos de la configuración del firewall. Veamos ahora qué aspecto tendría una configuración real del firewall.

Se ha diseñado la configuración de este ejemplo con vistas a que sea fácilmente extensible y personalizable. Se proporcionan una versión de iptables.

En el ejemplo con iptables, se ha pasado a utilizar el conjunto de reglas FORWARD por la diferencia de significado del conjunto de reglas INPUT en la implementación de netfilter. Esto tiene implicaciones; significa que ninguna de las reglas protege el 'host' mismo del firewall.

#!/bin/bash ####################################################### # VERSIÓN PARA IPTABLES # Este configuración está pensada como ejemplo de configuración de # un firewall sobre un 'host' único que no hospede él mismo ningún # servicio ####################################################### # SECCIÓN CONFIGURABLE POR EL USUARIO # El nombre y la localización de la utilidad iptables. IPTABLES=iptables # Ruta del ejecutable de iptables. PATH="/sbin" # El espacio de direcciones de nuestra red interna y el dispositivo # de red que la soporta. OURNET="172.29.16.0/24" OURBCAST="172.29.16.255" OURDEV="eth0" # Las direcciones de fuera y el dispositivo de red que la soporta. ANYADDR="0/0" ANYDEV="eth1" # Los servicios de TCP que deseamos permitir que pasen - un "" vacío # significa todos los puertos # nota: separados por espacios TCPIN="smtp,www" TCPOUT="smtp,www,ftp,ftp-data,irc" # Los servicios de UDP que deseamos permitir que pasen - un "" vacío # significa todos los puertos # nota: separados por espacios UDPIN="domain" UDPOUT="domain" # Los servicios de ICMP que deseamos permitir que pasen - un "" vacío # significa todos los tipos # referencia para los números de los tipos: /usr/include/netinet/ip_icmp.h # nota: separados por espacios ICMPIN="0,3,11" ICMPOUT="8,3,11" # Registro; descomente la siguiente línea para habilitar el registro # de los datagramas rechazados por el firewall # LOGGING=1 # FIN DE LA SECCIÓN CONFIGURABLE POR EL USUARIO ####################################################### # Borra las reglas de la cadena de entrada $IPTABLES -F FORWARD # # Por defecto, queremos denegar el acceso a los intentos de entrada $IPTABLES -P FORWARD deny # Rechaza todos los datagramas destinados a este hosts y recibidos # desde fuera. $IPTABLES -A INPUT -i $ANYDEV -j DROP



# SUPLANTACIÓN DE IDENTIDAD # No se debería aceptar ningún datagama proveniente de fuera con una # direccción de origen coincidente con una de las nuestras, por # eso las rechazamos. $IPTABLES -A FORWARD -s $OURNET -i $ANYDEV -j DROP # 'SMURF' # No se permiten difusiones dirigidas de ICMP a nuestra red para evitar # los ataques del estilo denominado 'Smurf'. $IPTABLES -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET -j DENY # Deberíamos aceptar fragmentos, esto se debe explicitar en iptables. $IPTABLES -A FORWARD -f -j ACCEPT # TCP # Aceptaremos todos los datagramas de TCP que pertenezcan a una # conexión ya existente (i.e. cuyo bit de ACK valga 1) # en el caso de los puertos de TCP que estamos permitiendo. # Esto debería capturar más del 95% de todos los paquetes válidos de TCP. $IPTABLES -A FORWARD -m multiport -p tcp -d $OURNET --dports $TCPIN / ! --tcp-flags SYN,ACK ACK -j ACCEPT $IPTABLES -A FORWARD -m multiport -p tcp -s $OURNET --sports $TCPIN / ! --tcp-flags SYN,ACK ACK -j ACCEPT # TCP - CONEXIONES ENTRANTES # Aceptaremos únicamente las solicitudes de conexión desde # fuera en los puertos de TCP permitidos. $IPTABLES -A FORWARD -m multiport -p tcp -i $ANYDEV -d $OURNET $TCPIN / --syn -j ACCEPT ## TCP - CONEXIONES SALIENTES # Aceptaremos todas las conexiones salientes de TCP hacia los puertos # de TCP permitidos $IPTABLES -A FORWARD -m multiport -p tcp -i $OURDEV -d $ANYADDR / --dports $TCPOUT --syn -j ACCEPT # UDP - ENTRADA ## Aceptaremos la entrada y vuelta de los datagramas de UDP por puertos #permitidos. $IPTABLES -A FORWARD -m multiport -p udp -i $ANYDEV -d $OURNET / --dports $UDPIN -j ACCEPT $IPTABLES -A FORWARD -m multiport -p udp -i $ANYDEV -s $OURNET / --sports $UDPIN -j ACCEPT # UDP - SALIDA # Se aceptarán la salida de los datagramas de UDP hacia los puertos permitidos y su vuelta. $IPTABLES -A FORWARD -m multiport -p udp -i $OURDEV -d $ANYADDR / --dports $UDPOUT -j ACCEPT $IPTABLES -A FORWARD -m multiport -p udp -i $OURDEV -s $ANYADDR / --sports $UDPOUT -j ACCEPT # ICMP - ENTRADA # Aceptaremos la entrada de los datagramas de ICMP de los tipos permitidos $IPTABLES -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET / --dports $ICMPIN -j ACCEPT # ICMP - SALIDA # Aceptaremos la salida de los datagramas de ICMP de los tipos permitidos. $IPTABLES -A FORWARD -m multiport -p icmp -i $OURDEV -d $ANYADDR / --dports $ICMPOUT -j ACCEPT # CASO POR DEFECTO y REGISTRO # Todos los restantes datagramas caen dentro de la regla por defecto # y son eliminados. Serán registrados si más arrriba se ha configurado # la variable LOGGING. # if [ "$LOGGING" ] then # Registra los paquetes de TCP descartados $IPTABLES -A FORWARD -m tcp -p tcp -j LOG # Registra los paquetes de UDP descartados $IPTABLES -A FORWARD -m udp -p udp -j LOG # Registra los paquetes de ICMP descartados $IPTABLES -A FORWARD -m udp -p icmp -j LOG fi # # fin.



En muchas situaciones simples, para utilizar el ejemplo todo lo que necesitará será editar la sección superior del fichero denominado “SECCIÓN CONFIGURABLE POR EL USUARIO” para especificar qué protocolos y tipos de datagramas desea que se les permita su entrada y su salida. Para el caso de configuraciones más complejas, se necesitará también editar la sección inferior. Recuerde que el ejemplo es simple, por tanto examínelo cuidadosamente para asegurarse de que hace lo que usted desea cuando lo implemente.


Capitulo 4: Enmascaramiento IP 25

4 Enmascaramiento IP y Traducción de Direcciones de Red

4.1 Introducción

No hace falta tener una memoria excelente para recordar los días en los que sólo las grandes compañías se podían permitir disponer de un cierto número de máquinas conectadas por una red local. Frente a aquello, hoy los precios de la tecnología de red han bajado y bajado hasta producir dos consecuencias: La primera, que las redes locales sean algo común, presentes incluso en entornos domésticos. Es seguro que muchos de los lectores, usuarios de Linux, tendrán en su casa dos o más computadoras conectadas por algún tipo de ethernet. La segunda, que los recursos de red, y de forma especial las direcciones IP, hayan llegado a ser algo escaso y, aunque no están lejanos los tiempos en que eran gratuitos, sean ahora objeto de compraventa.

La mayor parte de la gente que disponga de una LAN deseará también disfrutar de una conexión a Internet que todas las máquinas de su red puedan utilizar al mismo tiempo. Las reglas del encaminamiento IP son muy estrictas respecto a la forma de manejar esta situación. Las soluciones tradicionales a este problema hubieran pasado por solicitar un conjunto de direcciones IP, probablemente un rango de clase C, dar a cada máquina de la LAN una dirección del rango asignado, y utilizar un router para conectar la LAN a la Internet.

En el actual escenario de una Internet mercantilizada, esa solución saldría bastante cara. En primer lugar habría que pagar por el rango de direcciones asignado, en segundo lugar habría que pagar con toda probabilidad al Proveedor de Servicios de Internet (ISP) por el privilegio de disponer de una ruta hacia la red local en sus máquinas, de tal forma que el resto de la Internet supiera como llegar a ellas. Esto puede sonar posible para algunas empresas, pero en una instalación doméstica los costes no estarían justificados.

Afortunadamente Linux proporciona una solución al problema, solución que utiliza un componente de un grupo de funcionalidades avanzadas de red llamadas en conjunto Traducción de Direcciones de Red (NAT). NAT es un conjunto de procedimientos para modificar las direcciones IP contenidas en las cabeceras de los datagramas IP mientras éstos viajan (al vuelo). Puede sonar extraño, pero mostraremos que se trata de la solución ideal al problema —real para muchos— que acabamos de plantear. IP masquerade es el nombre que recibe un tipo de traducción de direcciones de red que permite que todas las máquinas de una red privada utilicen la internet contando con una única conexión (y una única dirección IP).

El enmascaramiento IP (en inglés «IP masquerading») permite utilizar un rango de direcciones privadas (reservadas) en la red local y que el router Linux se encargue de hacer al vuelo ciertas traducciones astutas de direcciones IP y puertos. Cuando le llega un datagrama IP de alguna máquina de la red local, se fija en el protocolo de nivel superior encapsulado en el mismo («UDP», «TCP», «ICMP», etc...) y modifica el datagrama para que parezca que fue generado por el propio router (y recuerda que ha sido modificado). A continuación saca el datagrama a Internet donde aparece generado por la única dirección IP pública del router. Cuando la máquina destino recibe el datagrama cree que se ha originado en la máquina Linux, y responde a su dirección de Internet. Cuando el router Linux recibe un datagrama en su interfaz de red conectada a Internet, busca en su tabla de conexiones enmascaradas en curso para ver si el datagrama pertenece a alguna máquina de la LAN y, si es así, deshace la traducción que hizo en el primer datagrama y reenvía este datagrama de respuesta a la máquina local.

En Figura 4-1 aparece un ejemplo sencillo.

Figura 11-1. Un escenario de enmascaramiento IP típico

Tenemos una pequeña red ethernet en la que utilizamos uno de los rangos de direcciones reservadas. La red dispone de un router con enmascaramiento, una máquina Linux, por



supuesto, que proporciona acceso a la Internet. Una de las máquinas de la red (192.148.1.3) deseo establecer una conexión con el host remoto 209.1.104.178 en el puerto 8888. El equipo encamina su datagrama por el router con enmascaramiento, que identifica la petición de conexión como requeriente de los servicios de enmascaramiento. El router entonces acepta el datagrama y reserva un número de puerto (1035) para este menester, sustituye la dirección IP y número de puerto de la máquina origen del datagrama por los suyos propios, y transmite el datagrama al host destino. El host destino cree que ha recibido una petición de conexión de la máquina Linux enmascaradora, y genera un datagrama de respuesta. La máquina enmascaradora, al recibir ese datagrama, halla la asociación en su tabla de masquerading y deshace la sustitución que llevó a cabo en el primer datagrama. Entonces transmite el datagrama de respuesta a la máquina origen.

La máquina local cree que se está comunicando directamente con el host remoto. El host remoto no sabe nada de la existencia de la máquina local y cree que ha establecido una conexión con la máquina Linux enmascaradora. La máquina Linux enmascaradora sabe que las otras dos máquinas están hablando entre sí y en qué puertos, y realiza las traducciones de direcciones y puertos necesarias para que la comunicación tenga lugar.

Todo lo anterior puede parecer un poco confuso, y puede que lo sea, pero funciona y es verdaderamente simple de poner a punto. Así que no se preocupe si aún no comprende todos los detalles.

4.1 Efectos colaterales

La funcionalidad de enmascaramiento IP viene acompañada de su propio conjunto de efectos laterales, algunos son útiles y algunos pueden acabar siendo un problema.

Ninguna de las máquinas en la red detrás del router enmascarador son jamás vistas directamente desde la Internet. Consecuentemente, solamente se necesita una dirección IP válida y rutable para permitir que todas las máquinas establezcan conexiones hacia la internet. Esto tiene un lado no tan bueno: ninguna de esas máquinas es visible desde la Internet, y por lo tanto no se puede conectar directamente a ellas desde la Internet. La única máquina visible en una red enmascarada es el propio router enmascarador. Se trata de algo importante cuando se piensa en servicios como el correo o el FTP. Resulta de utilidad decidir qué servicios deberían ser provistos por la máquina enmascaradora y para cuáles debería actuar como proxy o tratar de algún otro modo especial.

Segundo, dado que ninguna de las máquinas enmascaradas son visibles, se encuentran relativamente protegidas de ataques del exterior. Eso puede simplificar (o eliminar) la necesidad de puesta a punto de funcionalidades de firewall en la máquina enmascaradora. No se debe confiar demasiado en esto, puesto que la red local estará únicamente tan segura como lo esté la máquina enmascaradora. Así, si la seguridad es un punto importante, se debería utilizar un firewall para protegerla.

Tercero, el enmascaramiento IP tendrá cierto impacto negativo en el rendimiento de su red. En un escenario típico ese impacto negativo será probablemente insignificante. Si se tiene un gran número de sesiones enmascaradas activas puede ocurrir que se perciba cierta sobrecarga en la máquina enmascaradora que afecte negativamente al rendimiento de la red. El enmascaramiento IP implica un incremente considerable en el proceso que requiere cada datagrama comparado con el normalmente exigiría. Si piensa utilizar un 384SX14 como router enmascarador para una conexión telefónica a la Internet puede resultar, pero no espere demasiado si quiere usarlo como router en su red corporativa a velocidades Ethernet.

Por último, ciertos servicios de red simplemente no funcionarán a través de enmascaramiento, o, al menos, no sin un poco de ayuda. Típicamente se trata de servicios que dependen de conexiones entrantes para funcionar, como ciertos tipos de Canales de Comunicación Directa (DCC), ciertas funciones del IRC, o algunos tipos de servicios de audio y vídeo multicast. Algunos de esos servicios disponen de módulos del kernel especialmente desarrollados para proporcionar una solución, y de ellos hablaremos dentro de un momento. Para otros es posible que no se encuentre soporte, así que se debe tener en cuenta que el enmascaramiento no es la solución adecuada en todas las situaciones.



4.2 Configuración del Núcleo para enmascaramiento IP

Para usar la función del enmascaramiento IP el núcleo debe ser compilado precisamente con soporte de enmascarmiento. Los núcleos de la serie 2.4 no presentan el soporte de enmascaramiento Ip como una opción de la compilación. En su lugar, se debe seleccionar la opción del filtrado de paquetes de red:

Networking options ---> [M] Network packet filtering (replaces ipchains)

En los núcleos de la serie 2.2 cierto número de módulos de asistencia para ciertos protocolos se crean durante la compilación del núcleo. Algunos protocolos comienzan estableciendo una conexión hacia fuera y entonces reciben una conexión desde fuera en otro puerto. Normalmente eso no podría ser enmascarado, puesto que no hay forma para la máquina Linux de asociar la segunda conexión con la primera sin meterse dentro del propio protocolo. Los módulos asistentes hacen justamente eso: examinan los datagramas y permiten que el enmascaramiento funcione para los protocolos que soportan. Protocolos que de otra forma serían imposibles de enmascarar. Los protocolos soportados son:

Module Protocol

ip_masq_ftp FTP

ip_masq_irc IRC

ip_masq_raudio RealAudio

ip_masq_cuseeme CU-See-Me

ip_masq_vdolive Para VDO Live

ip_masq_quake Quake, de IdSoftware

Esos módulos deben ser cargados manualmente mediante la orden insmod. Nótese que no pueden ser cargados por el demonio kerneld. Cada uno de esos módulos acepta como argumento el puerto en el que debe escuchar. Para el módulo RealAudio™ se podría poner:

# insmod ip_masq_raudio.o ports=7070,7071,7072

Los puertos especificados dependen del protocolo. El mini-HOWTO del enmascaramiento IP (IP masquerade mini-HOWTO), escrito por Ambrose Au, trata con más detalle los módulos asistentes y cómo configurarlos.

El paquete netfilter contiene módulos que realizan funciones similares. Por ejemplo, para que se hagan cargo del seguimiento de las sesiones FTP, se deben cargar los módulos ip_conntrack_�ftp y ip_nat_�ftp.o.



4.3. Configuración del enmascaramiento IP

Las reglas de enmascaramiento son una clase especial de reglas de filtrado. Solamente se puede enmascarar datagramas que se reciban por una interfaz y que vayan a ser rutados por otra. Una regla de enmascaramiento se construye de forma parecida a una regla de encaminamiento de firewall, pero incluyendo unas opciones especiales que le dicen al núcleo que debe enmascarar el datagrama IP. El programa iptables utiliza la opción -j MASQUERADE para indicar que los datagramas que cumplan las condiciones especificadas por la regla deben ser enmascarados.

Veamos un ejemplo. Una estudiante de informática de la Universidad tiene unas cuantas máquinas en casa interconectadas en una pequeña red local ethernet. Ha decidido utilizar uno de los rangos privados de direcciones IP para su red. Comparte el lugar con otras estudiantes, todas las cuales tienen interés en usar la Internet. Dado que las residentes no gozan de una economía especialmente boyante, no se plantean costearse una conexión permanente a Internet. En su lugar utilizan una conexión PPP telefónica. A todas ellas las gustaría poder compartir la conexión para chatear en el IRC, navegar por el Web, y bajarse ficheros por FTP directamente a cada una de sus computadoras. El enmascaramiento IP es la respuesta.

Nuestra estudiante primeramente configura una máquina Linux para que se encargue del enlace telefónico y para que actúe como router de la red local. La dirección IP que la asignan cuando se conecta telefónicamente no es importante. Configura el router Linux para que haga enmascaramiento IP y usa uno de los rangos privados de direcciones IP para la red local: 192.148.1.0. Se asegura de que todas las computadoras de la red tienen como ruta por defecto una que apunte al router Linux.

Todo lo que se necesita para que el enmascaramiento funcione en ese escenario son las siguientes invocaciones del programa con iptables:

# iptables -t nat -P POSTROUTING DROP # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Ahora siempre que alguna de las máquinas de la red local traten de acceder a un servicio en una máquina remota, sus datagramas serán automáticamente enmascarados por el router enmascarador Linux. La primera regla en cada uno de los ejemplos impide que la máquina Linux rute cualquier otro datagrama y proporciona cierta seguridad.

Para listar las reglas de enmascaramiento que se hayan creado, se utiliza la opción -l para el programa ipfwadm, exactamente como se dijo ya al referirnos a los firewall.

Para listar la regla que creamos previamente se utiliza:

# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy DROP) target prot opt source destination MASQUERADE all -- anywhere anywhere MASQUERADE Chain OUTPUT (policy ACCEPT) target prot opt source destination

Las reglas de enmascaramiento aparecen aquí también con MASQUERADE como target.



4.4 Más sobre la traducción de direcciones de red

El software netfilter es capaz de realizar muchos tipos de traducción de direcciones de red. El enmascaramiento IP es un ejemplo simple de ello.

Es posible, por ejemplo, configurar reglas NAT que traduzcan sólo ciertas direcciones o rangos de direcciones y dejen las demás intactas, o que traduzcan rangos de direcciones en rangos en vez de en direcciones individuales (que es lo que hace el enmascaramiento). Se puede de hecho utilizar el programa iptables para crear reglas NAT que conviertan casi cualquier cosa, con combinaciones de condiciones que utilicen atributos estándares tales como dirección origen o destino, tipo de protocolo, puerto, etc.

La traducción de la dirección origen de un datagrama es conocida como «Source NAT» o SNAT, en la documentación de netfilter. La traducción de la dirección destino de un datagrama es conocida como «Destination NAT» o DNAT. La traducción del puerto TCP o UDP es conocida como REDIRECCION. SNAT, DNAT, y REDIRECT son targets que se pueden usar con iptables para construir reglas más complejas y sofisticadas.

El tema del NAT y su utilización necesitaría al menos un capítulo completo. ... ¡y es problable que incluso un libro! Lamentablemente no dispongo de espacio en este libro para tratarlo en mayor profundidad. Si se desea más información sobre los posibles usos del NAT, es conveniente leer el IPTABLES-HOWTO (o su versión en castellano: IPTABLES-COMO).


Capitulo 7: El día después 43

7 El Día Después

7.1 El Día Después

Todo parece muy normal. Llegamos a nuestra oficina, nos ponemos en el servidor, y de repente, al acceder a nuestra pagina, vemos, que esta no esta, si no que existe una mera burla de alguien que quizá, amparado en la oscuridad de la noche, ha atacado nuestros servidores. Luego, una vez que la bronca que nos causa todo se ha ido y de preguntarnos: ¿Por que lo han echo?, ¿Si en nuestro servidor no tenemos información Vital?, comienza un fino trabajo de reconstrucción de los hechos. Lo primero que debemos ver y analizar, si podemos, siempre que el atacante no haya sido maligno, es ver por que servicio se nos han filtrado a nuestros servidores. En este caso, la evaluación consta de varios items: 1) Evaluación del sistema operativo que estamos corriendo nosotros en este momento

Sun Solaris Windows NT/2000 Linux BSD SCO, AIX, IRIX, otros

2) Evaluación de que servicios están corriendo en nuestros servidores, como ser

POP3 IMAP FTP HTTP (Muy especialmente si estamos corriendo IIS) DNS (Muy especialmente si estamos corriendo alguna version de Bind) SMTP (sendmail o Exchange) RPC

---- Finger (!), Telnet(!), SSh, rlogin (!!) una vez que hayamos detectado esto, lo mejor seria ir a alguna pagina de seguridad informática, y ver que falla presentan estos servicios. Por ejemplo: Si estamos corriendo NT, con IIS 4 , o win2k con IIS5, es muy probable que el atacante haya ingresado las primeras veces por aquí, pero el problema es que entonces, el atacante gano privilegios, o que el sistema estaba mal seteado, ya que para abusar de este fallo, el atacante cuenta con privilegios de Cuenta invitada de Internet. Un grave error, que he visto en varias ocasiones, es que los administradores cambian de ubicación el default site, y crean los directorios en otro lugar. Windows NT, por defecto, a estos directorios, le da control total a everyone!!!, si! a todos, y lo mas triste es que no han deshabilitado el default website, que es la puerta de entrada de cualquier atacante. Por suerte, el directorio donde se guardan los logs, esta protegido, y solo tienen acceso los usuarios administradores y System, una cuenta interna de Windows NT. Los Logs del IIS, nos pueden ser de vital importancia a la hora de recopilar información sobre un ataque, estos por defecto se ubican en:

c:\winnt\system32\Logfiles Pero, como sabemos, esta ruta puede estar cambiada.... Alli, veremos quien ingreso, donde y que hizo.... El tema, es que si esto ha pasado, lo que nos queda es tomar medidas para contrarrestar la situación. Lo mejor en estos casos, es estar constantemente actualizados con los Services Pack, en este caso el Service Pack 6, y el Service Pack 6.a nos solucionan este tipo de problemas.

Ahora, veamos otro caso, que puede ser mucho mas peligroso. Es sabido que el NT, tiene la llamada null session, que entre otras cosas, permite una enumeración remota de usuarios, lo que compromete gravemente al sistema operativo. Imaginémonos que un intruso ha dado, por adivinación o fuerza bruta con la password de administrador, acá el peligro es múltiple, por que no solo compromete a la maquina que el ha atacado, si no que compromete también a todas las maquinas que se encuentren en la



misma subred, ya que como sabemos, existen programas para poner en modo promiscuo una interfaz Ethernet. El tema, es que no es tan sencillo lograr esto en NT, pero con astucia, los intrusos se las ingenian para lograrlo, sencillamente poniendo un programa de dos, y volcándolo en algún directorio que pueda ser ejecutable por un navegador, vemos de nuevo que nos encontramos en problemas.... A esta altura, lo mejor seria plantearse seriamente de aislar el equipo y analizar paso a paso lo que ha ocurrido, antes de ponerlo nuevamente en producción.

7.2 Que pasa en un sistema Unix

El intruso ha encontrado una vulnerabilidad en el rpc de Unix, y con esto, en unos minutos, ha conseguido el status de root. sin pensarlo demasiado, se asegura su estancia, y pone una backdoor, y varios troyanos. La cosa se va complicando.

7.3 Backdoors en Sistemas Unix

Colocar una backdoor en un sistema Unix, es muy simple. Necesitamos solo tener el status de root, y ya estamos, solo necesitamos agregar una linea en el /etc/services, que nos permita, que la conectarnos a cierto puerto de cierta IP, nos de una shell interactiva que nos de el status de root. Nuestro Problema seria ahora como localizar esta backdoor?. Bueno, no es tan difícil, es obvio que tenemos un puerto nuevo a la escucha, entonces, lo que haríamos seria lanzar un scaneo hacia nosotros mismos, para esto utilizaremos el famoso nmap.

#nmap localhost y si vemos un puerto extraño, lo que haremos es telnetear hacia ese puerto.... si vemos que tenemos una "bind shell" o shell escucha, lo que tenemos que hacer es dirigirnos al archivo /etc/services y borrar la entrada correspondiente a la bind shell.

7.4 Detectando troyanos

Realizando una review, de lo que hemos aprendido sobre sistemas operativos Unix, recordemos que existen los archivos suid.... Estos se caracterizan por tener un +s como bit de tipo, o en forma octal, tener un 4. Estos archivos pueden ser potencialmente una amenaza a nuestros servidores, siempre y cuando algún intruso halla hecho una copia de algún programa maligno, o haya copiado el interprete de comandos (bash, sh, tsh, ksh, el que sea) a otro archivo, y a este le haya dado permisos suid... veamos.... el intruso como root ejecuta lo siguiente....

#cp /bin/bash /tmp/.config #chmod 4777 /tmp/.config

y allli tenemos una shell suid para que cuando el individuo, se loguee como usuario adquiera el status de root. Nada mas sencillo que esto

$user:/tmp/.config para convertirse en root. Para detectar esto, lo piola seria como usuario del sistema, realizar una búsqueda de estos archivos peligrosos.

find / -perm -4000 > suid y si vemos alguno sospechoso, ejecutarlo.... si al ejecutarlo vemos que hemos alcanzado el status de root, estamos nuevamente en problemas, pero lo que debemos hacer, es solamente borrar estos archivos peligrosos.

7.5 Casos Prácticos



Varias veces, he visto varios firewalls muy bien configurados, muy acertadas las cadenas de filtrado, y un desastre la seguridad tras de esta...

Caso numero 1:

He visto casos donde se cuida mucho la seguridad, (?), y es sorprendente, como se cree que se esta seguro... Administradores que cuidan de no tener el telnet abierto, pero dejan ssh, y con contraseñas muy fáciles de crackear... Es increíble, las contraseñas del tipo juan:juan... es de recordar, que si les dejamos a los usuarios que asignen sus contraseñas, corremos el riesgo, que estos por comodidad asignen contraseñas muy obvias. Es Muy grande el riesgo que se corre, si estos usuarios ponen contraseñas iguales a sus nombres de usuario, y dejan todo el sistema expuesto a stack buffer overflows. Por eso, a veces, con solo tener un cliente ssh, nuestra seguridad puede estar expuesta... Recordemos esto.... Nunca está demás crackear nuestras propias contraseñas, y advertirle a los usuarios que estas deberían ser cambiadas, como parte de nuestra política de seguridad. Por que aunque cerremos telnet, una contraseña fácil, nos deja expuesto todo nuestro sistema.

Caso numero 2:

Administrador un poco vago, no tiene muchas ganas de trabajar. Entonces, como viene, deja el servidor, ni bien esta instalado.... En la primera oportunidad, el Instala un Windows NT Server, y como tenia que brindar paginas asp, Instala el IIS 4.0, y todas esas cosas... Todo estaba corriendo en perfecta condiciones, pero un buen día revisando el servidor... , se encuentra con un nc, puesto en C:\InetPub\scripts..... El mismo administrador piensa ¿Que es esto, si yo no uso estas cosas?, pero en ese momento, recuerda que le habían comentado una pagina de seguridad informática y no duda tan solo un momento en ir a verla. La pagina es www.packetstorm.securify.com, y el mismo va hasta esta... y encuentra el nc.exe... Uh... se encuentra que por alli le están ejecutando comandos... solo que no tienen los suficientes permisos, como el user IUSR_nombremaquina se conectan... algo tan viejo como hacer un ../../../.. Este bug, se conoce como el unicode, y es conocido, afecta al IIS4 y A IIS5, ni bien este ha sido instalado. Sería recomendable instalar el Service Pack 6.

Caso numero 3:

Muy bien protegido el servidor. Tiene reglas de filtrado. Muy protegido. Pero tiene el FTP anónimo... No dura mucho hasta, que un exploit, Rompe con la seguridad de este. Este servicio no es otro que el wu-ftp.2.6.0(1) que por defecto viene con el sistema operativo Red Hat Linux 6.2. Es increíble, la cantidad de servidores que están expuestos a este ataque. Lo mejor sería denegar el ftp anónimo en el archivo /etc/ftpusers Lo haríamos de la siguiente manera:

#echo “ftp” /etc/ftpusers; killall –HUP inetd NOTA: Puede variar la ubicación de los archivos si son diferentes distribuciones. Como hemos visto, se aplica, la vieja leyenda de la frazada corta, no solo es necesario cubrirnos, si no estar al tanto de las novedades, y de los stack buffer overflows.

7.6 Medidas Mínimas de Seguridad

Analizar fehacientemente que servicios brindaremos, y si estos son seguros, o sea,

ver su historial de seguridad.



Mantener actualizadas nuestras versiones de demonios y/o servicios, e intentar

“hackear” nuestras redes, utilizando diversos tipos de scanners: nmap, nessus, retina, etc.

Intentar correr los Stack Buffer Overflows, Bad format string, y DoS en nuestros sistemas. NOTA: Los dos primeros (Stack Buffer Overflows permiten lograr la escalada de privilegios en el sistema, mientras que el DOS, o Denial of Service, lo que hace, es dar de baja un servicio, o lograr la paralización del sistema operativo).

Consultar Los Advisories y boletines de seguridad.


Capitulo 8: Logs del Sistema 47

8 Log del Sistema

8.1 Los Logs y su importancia

La mayoría de los logs, que se refieren a los eventos, y a los servicios, de Linux, se encuentran alojados en /var/log. Quizás, para los que vengan de NT, este directorio les brindaría la misma información que les puede brindar el Event Viewer. Tenemos los logs de servicio y los logs referenciado a la seguridad del sistema. Veremos ahora esto último. lastlog lista los usuarios del /etc/passwd, y se fija si alguna vez se han logueado en el sistema.

8.2 wtmp

Este guarda las ultimas entradas de los usuarios. Es invocado por el comando last, y nos puede advertir si un intruso ha ingresado a nuestro sistema.

root tty3 Wed May 23 16:23 still logged in root tty2 Wed May 23 16:11 still logged in root tty1 Wed May 23 16:10 still logged in reboot system boot 2.2.18 Wed May 23 16:09 (00:19) root ftpd1021 maq5.aptd.com.ar Wed May 23 14:20 - 14:20 (00:00) root tty4 Wed May 23 13:24 – down (01:52) root tty3 Wed May 23 13:19 – down (01:57) root tty2 Wed May 23 13:07 – down (02:09) root tty1 Wed May 23 12:46 – down (02:31) nacho tty5 Wed May 23 12:25 – down (02:51) reboot system boot 2.2.18 Wed May 23 12:19 (02:57) root tty2 Wed May 23 12:12 – down (00:06)

Esta lista es mucho mas larga, pero por cuestiones de espacio solo imprime esta parte. extraigamos la primera línea, y vamos a analizarla de a poco.

root tty3 Wed May 23 16:23 still logged in

Nos damos cuenta aquí, que el primer campo que vemos es el usuario que se conecto, o sea root. El segundo campo, es la terminal que uso, en este caso veremos que uso la terminal tty3, o sea que se conecto localmente. El tercer campo esta vacio en este caso, por que fue un acceso local. El cuarto campo indica fecha y hora de ingreso. El quinto campo indica el tiempo de permanencia de ese usuario, en este caso esta logueado aun. Analizaremos la quinta linea ahora:

root ftpd1021 maq5.aptd.com.ar Wed May 23 14:20 - 14:20 (00:00)

El primer campo, es el usuario root. El segundo, nos dice que se conectaron por ftp. El tercero, desde donde se conectaron. El cuarto y quinto campo, es el tiempo que estuvieron. Pero imaginémonos que tenemos un archivo de logs gigantescos, y nosotros queremos ver los últimos logs. Mostraremos como hacemos para ver los ingresos al sistema.

last -10 viene a nuestra ayuda.

Todo muy lindo, pero imaginémonos que algún intruso entra a nuestro sistema y logra el status de root, entonces, lo primero que va a tratar de hacer es borrar todas las huellas que el dejo... Existen 2 formas de borrar estas huellas... La mas grosera, y obvia, es hacer un rm -fr /var/log, así borra sus huellas el atacante, y otra es utilizar algún programa "zappers", para editar estos archivos a mano. Con conocimientos de programación en C, podríamos llegar a escribir alguno de estos programas.


Capitulo 8: Logs del Sistema 48

8.3 Detectando los logs alterados

Nuestro atacante, deberá ser lo suficientemente inteligente como para evitar dejar "huellas" sobre sus "andanzas". Alguna vez, he leído acerca del "crimen perfecto", sobre borrar los logs, directamente en rm -fr /var/log. Así no lo encontraríamos mas a nuestro atacante, pero nos daríamos fácilmente cuenta, ya que no encontraremos nada en nuestros logs. Otra cosa, que suelen hacer los intrusos, es vaciar el contenido del /var/log/wtmp. Si al llegar una mañana nos encontramos con lo siguiente

wtmp begins Fri May 25 12:11:47 2001 y casualmente, es 25 de Mayo, Ahhh, alguien nos hizo una visita nada amigable. Lo que hacen "nuestros visitantes", es utilizar algún tipo de programa para tratar de disfrazar sus entradas. Con algún editor de wtmp, con simples líneas de programación en C, podrán saltearse nuestras auditorias. Lo mejor en estos casos, es adquirir algún producto comercial de auditorias o probar, con alguno de los tantos gratuitos, que descargaremos en www.freshmeat.net.


Capitulo 5: DMZ 30

5 DMZ

5.1 Creando Zonas Desmilitarizadas

Mucha gente, piensa que crear DMZ en Linux aun no es posible. Quizá, por que solo han oído hablar de IPCHAINS... y piensan, que únicamente el forwardeo es de "adentro hacia afuera". Explicaremos sencillamente como aplicar el "Reverse Masqueranding", y como se pueden crear brevemente, zonas desmilitarizadas en Linux.

Puesta en escena:

Ahora, supongamos que somos una empresa que brinda servicio de Correo Electrónico. Sencillamente, podríamos imaginarnos, que cada servicio se ejecuta, en una maquina distinta. Es mas, imaginémonos que hasta corren en sistemas operativos diferentes....

Web Server (Internet

Information Server)

DNS Server (Bind)

Mail Server (Sendmail)

Router

INTERNET

Por una disposición de la empresa de debemos instalar Microsoft Windows NT, con la consecuencia a nivel seguridad que ello trae aparejado... Ahora veamos como esta estructurado todo esto, a nivel IP router IP 200.200.200.32 Mail IP 200.200.200.33 DNS IP 200.200.200.34 www IP 200.200.200.35 o sea, que vemos que tenemos 4 IPs ocupados....

Planteo del Problema

Una mañana, recibimos la directiva de proteger TODAS LAS MAQUINAS... entonces necesitamos poner firewalls.

Nosotros sabemos que los Linux están bien protegidos, casi no están expuestos. Pero la empresa quiere implementar un firewall centralizado.

OK!, no hay problemas...

Nueva disposición

Router

Mail Server (Sendmail)

DNS Server (Bind)

Firewall

INTERNET

Web Server (Internet

Information Server)

Este es el esquema que deberíamos lograr. Las opciones eran pocas...

Un firewall comercial por software, son muy costosos y algunos poco efectivos. Un firewall por hardware, está fuera de nuestro presupuesto.

Entonces, vamos a implementa un Linux forwardeando puertos....


Capitulo 5: DMZ 31

Instalación del sistema operativo.... Instalamos el sistema operativo, ponemos a correr el firewall, y aparecen las primeras sorpresas. Deberíamos decirle al fw que nos proteja toda la red interna, y que los servidores, ahora se hallan en nuestra LAN. Para hacer esto: "TODO lo que nos llega al puerto 80, redirigirlo hacia el puerto 80 de nuestra LAN" Pero vemos que tendríamos que cambiar todo el modelo anterior....

Explicando los cambios

Anteriormente, teníamos lo siguiente. router IP 200.200.200.32 Mail IP 200.200.200.33 DNS IP 200.200.200.34 www IP 200.200.200.35 ahora, tendremos lo siguiente. router IP 200.200.200.32 Firewall IP 200.200.200.33 y los servicios, en IPs privadas. Mail 192.168.1.100 DNS 192.168.1.101 www 192.168.1.102 Así, estamos ahorrando IPs publicas, protegiendo nuestros servers, y balanceando las cargas. Pero, como hacemos esto?.... Tendríamos que decir que todo lo que llegue a la IP del fw por el puerto 80, se reenvíe hacia el puerto 80 de la maquina con IP 192.168.1.102, que es la que verdaderamente publica en el 80. ipmasqadm portfw -a -P tcp -L 200.200.200.33 80 -R 192.168.1.102 80 Muy sencillo... Pero cuidado... falta algo mas!!!.... Es obvio que al hacer esto, estamos cambiando las direcciones IP... Todos los servicios, DNS, MAIL, WWW tendrían que apuntar ahora hacia el 200.200.200.33 entonces, en el dns server, tendríamos que tener las siguientes entradas. MAIL, DNS, Y WWW APUNTANDO HACIA 200.200.200.33 ya que con lo que resolverá hacia que dirección IP interna se dirige para resolver la petición, es el puerto con el que viene la petición. por ejemplo, si quisiera hacer un telnet a telnet misitio.com 25 este query lo resuelve la dirección IP interna 192.168.1.100. Así, podremos tener nuestros servidores protegidos, y hasta tener distintas "Tecnologías de sistemas operativos, corriendo sobre una misma IP".


Capitulo 10: Buffer Over Flows 2

10 Buffer Over Flows

10.1 Creando Buffer Over Flows

Este documento nació tras el fruto de la investigación, y parte de mi curiosidad. Recuerdo aquel día, allá por el año 1999, cuando le pregunté a alguien que supuestamente era un "Guru" de GNU/LINUX, si había forma de conseguir como usuario, leer el archivo /etc/shadow... No era tan común por esos tiempos ya encontrarse con el bug del phf, y menos aun, encontrarse con sistemas que no tuvieran el archivo /etc/shadow... ya que la diversión era encontrar sistemas con el archivo /etc/passwd, y las contraseñas sin sombrear. Revisando por allí, alguien me dijo, que había una forma de escalar privilegios "explotando" los archivos con permisos suid. Una demostración, valió mas que mil palabras, pero ahora, me interesa saber como se hacen estos programitas...

Introducción

1 - Comprendiendo los archivos suid: En algunas ocasiones, necesitaremos ejecutar como usuarios programas que son propios de root... Por ejemplo: /usr/bin/passwd Veamos una cosita, que los archivos que tienen el flag suid, llevan una s, vamos a hacerle un ls -l a /usr/bin/passwd. ls –l /usr/bin/passwd -r-s--x--x 1 root root 11440 Dec 9 1999 /usr/bin/passwd* vemos que este archivo tiene una s, esto significa que cuando lo ejecutemos seriamos root, pero cuando termina ese archivo, solo volvemos a ser usuarios... Para finalizar con esta introducción a flag suid, diré como otorgarles el flag suid a estos archivos... Para cederles el flag suid, hacemos de la siguiente manera. #chmod +s archivo Para quitarles el flag suid, hacemos de la siguiente manera. #chmod -s archivo y Listo!...

Cadenas desbordadas en C

Como sabemos, cuando programamos en C, y definimos variables, tenemos que definir el tipo y el tamaño de la variable... Por ejemplo, si queremos definir una variable, hola, podríamos hacer lo siguiente... char hola[10]; Ahora, que pasaría si a hola le quiero copiar una cadena de mas de 10 caracteres?... la respuesta es sencilla... se desborda!!... Veamos un programa sencillo para ilustrar esto, luego lo iremos complicando...

#include <stdio.h> #include <string.h> int main(void) {

char crash[10]; char boing[]="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; strcpy(crash,boing);

}



Vemos aquí que cuando corro este programa, se produce un core dump, o sea que se vuelca todo el contenido de la memoria a disco... Trataremos de debuggear ese core...

gdb -c core /pavadas/kk Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `./kk'. Program terminated with signal 11, Violación de segmento. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x41414141 in ?? () < *** Muchas A!.... (gdb) me dice que 0x4141 (el código en hexa de la A, me provoco ese core!). Ahora, pensemos que pasaría si tenemos un comando y le pasamos una cadena gigante como argumento... o mejor, pensémoslo de esta manera, arreglaremos nuestro programita para que reciba argumentos...

#include <stdio.h> #include <string.h> int main(int argc, char *argv[]) { if (argc < 2) { printf("Por favor, especifique un argumento \n"); exit(0); } char demo[10]; strcpy(demo,argv[1]);

} Al ejecutar esto, pasaría lo siguiente...

#./demo AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA otro core mas!!...

Yendo aun mas lejos:

Imaginémonos que ahora le pasamos parámetros a un comando del sistema. hagamos la prueba con gzip....

gzip 'perl -e `printf "A"'x90` y vemos la siguiente salida... que nos dice que no existe el fichero o directorio... Pero, como somos muy inquietos, seguimos metiendo pua... ahora, lo que hacemos es: gzip 'perl -e `printf "A"'x255` y lo que nos dice aquí es que no existe fichero o directorio, pero lo que verdaderamente nos ocupa, es lo siguiente...

gzip 'perl -e `printf "A"'x256` Nos dice nombre de archivo demasiado largo...

gzip 'perl -e `printf "A"'x1025` Violación de segmento (core dump)... uy! y esto?... justo a los 1024?, por que será...



Todo tiene explicación... allá vamos...

Desbordando a la Pila

El tema, es que cuando por algún buffer overflow, se produce una sobre escritura de la dirección de retorno, se pueden lograr inyectar códigos arbitrarios. Si el programa que "desbordamos" estaba corriendo como root, no quieran pensar lo nefasto que quedara nuestro sistema.

Buscando estos problemas

Lo que nos traerá estos problemas, de posibles buffer overflows, son los archivos que tienen suid. Recuerden hacer:

find / -perm -4000..... Y fíjense que estos archivos, no sean explotables...


Capitulo 11: Servidor de SSH 32

11 Servidor de SSH (Secure Shell)

11.1 Introducción

Hoy, mucha gente tiene múltiples cuentas de correo. Un usuario habitual puede tener una cuenta personal de algún proveedor de Internet , un cuenta laboral en la red local de su empleador, y una o varias PCs en su casa. También puede tener permiso para utilizar otras cuentas pertenecientes a familiares o amigos. Si tiene múltiples cuentas, es natural querer hacer conexiones entre ellas. Por ejemplo, se puede querer copiar archivos entre computadoras en una red, ingresar a una cuenta remotamente desde otra, o transmitir comandos para ejecutar en una computadora remota. Existen varios programas para estos propósitos, como el ftp o el rcp para transferencia de archivos, telnet y rlogin para ingreso remoto, y rsh para la ejecución remota de comandos. Desafortunadamente, muchos de esos programas relacionados con las redes tienen un problema fundamental: la falta de seguridad. Si se transmite un archivo (sensible) por Internet, potencialmente, un intruso puede interceptarlo y leer los datos. O peor, si se ingresa en una computadora remota utilizando un programa como telnet, el nombre de usuario y clave pueden ser interceptados mientras viajan por la red. ¿Cómo prevenir estos serios problemas? Se puede utilizar un (programa de encriptamiento) para encerrar los datos en un código secreto que nadie más podrá leer. Se puede instalar un firewall, que actuará como escudo para proteger de los intrusos diversas porciones de una red de computadoras. O se puede utilizar un amplio rango de soluciones, solas o combinadas, de variado costo y complejidad.

11.1.1 ¿Qué es SSH?

Secure Shell (SSH), es un método popular y poderoso, basado en software, para la seguridad de redes. Cada vez que se envían datos desde una computadora a una red, SSH automáticamente lo encripta. Cuando los datos llegan al destinatario, SSH automáticamente lo desencripta. El resultado es un encriptamiento transparente: los usuarios pueden trabajar normalmente, sin pensar que sus comunicaciones están seguramente encriptadas en la red. Además, SSH utiliza algoritmos modernos y seguros y es lo suficientemente efectivo para ser utilizado dentro de aplicaciones críticas en las grandes corporaciones. SSH posee una arquitectura cliente/servidor, como se muestra en la Figura 1-1. Un programa de servidor de SSH, típicamente instalado y corrido por un administrador de sistemas, acepta o rechaza las conexiones entrantes a su computadora. Los usuarios entonces corren sus programas cliente SSH, típicamente en otras computadoras, para hacer requerimientos del servidor SSH, tales como “Por favor ingréseme”, o “ Por favor ejecute este comando”. Todas las comunicaciones entre clientes y servidores están seguramente encriptadas y protegidas contra cualquier modificación. Nuestra descripción está simplificada, pero debería dar una idea general de qué hace SSH. Profundizaremos más tarde. Por ahora, sólo basta recordar que los clientes SSH se comunican con servidores SSH con conexiones de red encriptadas. Un producto basado en SSH podría incluir clientes, servidores, o ambos. Los productos Unix generalmente contienen a ambos; otras plataformas son usualmente sólo clientes, aunque están comenzando a aparecer servidores basados en Windows. Un usuario de Unix encontraría que SSH es una forma segura de los comandos r: rsh (remote shell), rlogin (remote login), y rcp (remote copy). De hecho, el SSH original para Unix incluye los comandos de nombre similar ssh, scp, y slogin como reemplazos fáciles y seguros para los comandos r. La curva de aprendizaje es pequeña, y la seguridad es muy superior.

11.2 Cómo correrlo. Un ejemplo

Supongamos que un usuario está fuera de su ciudad en un viaje de negocios y desee leer su correo electrónico, que se encuentra en una máquina Unix que pertenece al proveedor de internet, shell.isp.com. Un amigo de una universidad cercana le permite ingresar a su cuenta Unix en la máquina local.university.edu, y luego ingresar remotamente en la suya. Para el ingreso remoto se pueden utilizar los programas telnet o rlogin, pero como hemos visto, esta conexión entre máquinas es insegura. (Sin duda algún estudiante subversivo tomaría la clave y la utilizaría para convertirla en un servidor renegado para software pirata y MP3 de artistas innombrables) Afortunadamente, tanto la máquina Unix del amigo como la propia tienen instalado un producto SSH.



En el ejemplo que expondremos en todo este capítulo, representamos el (shell prompt) de la máquina local, local.university.edu, como un signo pesos ($) y el (prompt) en shell.isp.com como shell.isp.com>.

11.2.1 Sesiones en una Terminal Remota con SSH

Para conectarse con la cuenta remota shell.isp.com desde la cuenta en local.university.edu, suponiendo que el nombre de usuario en shell.isp.com sea “pat”, se tipea: $ ssh –l pat shell.isp.com clave de pat: ******** Último ingreso: Lun 24 Mar 19:52:33 2002 desde quondam.nefertiti.org Usted tiene correo nuevo. shell.isp.com> Esto lleva a la situación que se muestra en la Figura 2-1. El comando ssh corre un cliente que se contacta con el servidor SSH en shell.isp.com por Internet, pidiendo ser ingresado en la cuenta remota con el nombre de usuario pat*. También se puede proveer la sintaxis user@host en lugar de la opción –l para lograr lo mismo: $ ssh [email protected] En un primer contacto, SSH establece un canal seguro entre el cliente y el servidor de manera que todas las transmisiones entre ellos estén encriptadas. El cliente entonces se alista para la clave, que provee al servidor desde el canal seguro. El servidor autentica al usuario comprobando que la clave es correcta y permite el ingreso. Todos los intercambios subsecuentes entre cliente y servidor están protegidos por ese canal seguro, incluyendo los contenidos del correo electrónico que el usuario procederá a leer utilizando un programa de correo en shell.isp.com. Es importante recordar que el canal seguro existe sólo entre las máquinas cliente y servidor SSH. Luego de ingresar a shell.isp.com a través de ssh, si luego se utilizan telnet o ftp hacia una tercera máquina, insegura.isp.com, la conexión entre shell.isp.com e insegura.isp.com no es segura. Sin embargo, se puede correr otro cliente ssh desde shell.isp.com hasta insegura.isp.com, creando así otro canal seguro, que mantiene la cadena de conexiones protegida. Hemos cubierto sólo el uso más simple de ssh. El Capítulo X profundiza mucho más sobre sus muchas características y opciones. *Si los nombres usuario local y remoto son idénticos se puede omitir la opción –l (-pat) y sólo tipear ssh shell.isp.com.

11.2.2 Transferencia de Archivos con scp

Continuando con la historia, supongamos que mientras el usuario lee su correo electrónico se encuentra con un mensaje que contiene un adjunto que le gustaría imprimir. Para enviar el archivo a la impresora local de la universidad, primero se debe transferir el archivo a local.university.edu. Una vez más, el usuario rechaza los métodos tradicionales de transferencia de archivos, como ftp y rcp, por inseguros. En cambio, utiliza otro programa cliente SSH, scp, para copiar el archivo a través de la red por un canal seguro. Primero, el usuario debe escribir el adjunto a un archivo en el directorio de shell.isp.com utilizando el cliente de correo electrónico, nombrando el archivo print-me. Cuando el usuario finaliza la lectura de sus mensajes, sale de shell.isp.com, finalizando la sesión y regresando al (shell prompt) en local.university.edu. Ahora está listo para copiar el archivo con seguridad. El programa scp posee una sintaxis muy similar a la del tradicional programa cp de Unix, y casi idéntica a la del inseguro programa rcp. Es, a grandes rasgos: scp nombre-de-fuente nombre-de-destino En este ejemplo, scp copia el archivo print-me en shell.isp.com a través de la red a un archivo local en la cuenta de su amigo en local.university.edu, también llamado print-me: $ scp [email protected]:print-me print-me El archivo es transferido a través de una conexión asegurada por SSH. Los archivos de fuente y destino pueden ser especificados no sólo por el nombre de archivo, sino también por nombre de usuario (pat en nuestro ejemplo) y nombre de host (shell.isp.com),



indicando la ubicación del archivo en la red. De acuerdo a las necesidades del usuario, varias partes de la fuente y del destinatario pueden omitirse, y utilizar valores por defecto. Por ejemplo, omitir el nombre de usuario y el signo de arroba (pat@) hace que scp asuma que el nombre de usuario remoto es el mismo que el local. Como ssh, scp se alista para la clave remota y la pasa al servidor SSH para verificación. Si la operación es exitosa, scp ingresa a la cuenta pat en shell.isp.com, copia el archivo remoto print-me al archivo local print-me, y sale de shell.isp.com. El archivo local print-me puede ser enviado ahora a una impresora. No es necesario que el nombre de archivo del destino sea el mismo que el del remoto. Por ejemplo, si se está sintiendo francés, podría llamar al archivo imprime-moi: $ scp [email protected]:print-me imprime-moi La sintaxis completa de scp puede representar archivos locales y remotos de manera óptima, y el programa tiene también numerosas opciones de línea de comandos. (x.5)

11.3 Agregando Complejidad al Ejemplo

El sesión de ejemplo anterior brindó una introducción rápida a los programas cliente más ampliamente utilizados – ssh y scp – en un formato a seguir mientras se está sentado frente a la computadora. Ahora que se tienen las bases, continuaremos con el ejemplo pero incluiremos situaciones y complicaciones comentadas por primera vez. Éstos incluyen la característica de seguridad de los “hosts conocidos” y el caracter de escape de SSH.

11.3.1. Hosts Conocidos

La primera vez que un cliente SSH se encuentra con una máquina remota, hace algo de trabajo extra e imprime un mensaje como el siguiente: $ ssh –l pat shell.isp.co No se encuentra la clave del host en la lista de hosts conocidos. ¿Está seguro de que desea continuar con la conexión (si/no)? Asumiendo que la respuesta sea sí (la más común), el cliente continúa: El host “shell.isp.com” fue agregado a la lista de hosts conocidos. Este mensaje aparece sólo la primera vez que se realiza una conexión con un host remoto particular. El mensaje es una característica de seguridad relacionada con el concepto de hosts conocidos de SSH. Supongamos que un adversario desea obtener la clave del usuario. Él sabe que el usuario utiliza SSH, así que no puede monitorear su conexión fisgoneando en la red. En cambio, él subvierte el servicio de nombres que utiliza el host local de manera que el nombre del host remoto deseado, shell.isp.com, se traduce en falso a la dirección de IP de una computadora corrida por él. Entonces instala un servidor SSH alterado en el host remoto falso y espera. Cuando el usuario ingresa a través del cliente SSH confiable, el servidor alterado SSH graba la clave para su uso posterior. El servidor falso se puede desconectar con un mensaje de error pre-planeado, como “ sistema en mantenimiento – por favor intente nuevamente luego de las 16:00 hs. “. O peor, puede engañar al usuario por completo utilizando su clave para ingresar al verdadero shell.isp.com y pasar información transparentemente entre el usuario y el servidor, monitoreando así la sesión completa. Esta estrategia hostil se llama ataque del hombre del medio. A menos que el usuario piense en comprobar la dirección de IP originante de la sesión en el servidor, él nunca se dará cuenta del engaño. El mecanismo de host conocido de SSH previene esos ataques. Cuando un cliente y servidor SSH hacen una conexión, cada uno comprueba la identidad del otro. Sí, no sólo el servidor autentica al cliente, como vimos antes cuando el servidor comprobaba la clave de pat, sino que el cliente también autentica al servidor mediante una criptografía (public-key). En resumen, cada servidor SSH tiene una identificación única, secreta, llamada (host key), para identificarse ante sus clientes. La primera vez que un usuario se conecta con un host remoto, una contraparte pública de la (host key) se copia y guarda en su cuenta local (asumiendo que el usuario haya respondido “sí” al mensaje del cliente acerca de las (host keys) antes), Cada vez que el usuario se reconecte con el host remoto, el cliente SSH comprueba la identidad del host remoto utilizando esta ( public key). Por supuesto, es mejor guardar la (public host key) del servidor antes de conectarse por primera vez, porque si no el usuario está técnicamente expuesto a un ataque esa primera vez. Los administradores pueden mantener listas de hosts conocidos en todo un sistema para un conjunto dado de hosts, pero esto no es de mucha utilidad para conectarse a



hosts aleatorios alrededor del mundo. Hasta que exista un método seguro, confiable y ampliamente desplegado de recuperar tales (keys) (como un DNS seguro, o una infraestructura de (public key) basada en X.509) , este mecanismo de grabar al primer uso es un compromiso aceptable. Si falla la autenticación de servidor, pueden ocurrir varias cosas dependiendo de la razón de la falla y la configuración del SSH. Típicamente aparece un mensaje de alarma en la pantalla, que va desde una repetición del mensaje de los hosts conocidos: No se encuentra la clave del host en la lista de hosts conocidos. ¿Está seguro de que desea continuar con la conexión (si/no)? a palabras más arriesgadas: Cuidado:¡La identificación del host ha cambiado! ¡Es posible que alguien esté haciendo algo malo! ¡Alguien podría estar espiándote ahora (man-in-the-middle attack)! También es posible que la (host key) haya sido cambiada. Por favor contáctese con su administrador de sistemas. Agregue la (host key) correcta en <path>/known_hosts para deshacerse de este mensaje. El agente que esté enviando está inhabilitado para prevenir ataques de servidores corruptos. X11 enviando está inhabilitado para prevenir ataques de servidores corruptos. ¿Está seguro de que desea continuar con la conexión (si/no)? Si la respuesta es sí, ssh permite la conexión, pero inhabilita varias características como una precaución de seguridad y no actualiza la base de hosts conocidos personales con la nueva (key); el usuario debe hacerlo él mismo para que el mensaje desaparezca. Como dice el texto del mensaje, si el usuario ve esta alarma, no está necesariamente siendo hackeado: por ejemplo, el host remoto puede haber cambiado legítimamente su (host key ) por alguna razón. En algunos casos, incluso luego de haber leído este manual, el usuario no conocerá la causa de estos mensajes. La recomendación es contactar al administrador del sistema si se necesita ayuda, antes de tomar un riesgo y comprometer la clave.

11.4. Copia Segura con scp

El programa de copia segura, scp, obedece a claves en el archivo de configuración de cliente de la misma manera en que lo hace ssh. Además, scp provee otras características y opciones que cubriremos en esta sección.

11.4.1.- Sintaxis Completa

Hasta el momento, hemos descripto la sintaxis de scp sólo en general en 2.2.1: scp name-of-source name-of-destination Cada uno de estos nombres, o especificaciones de ruta, en la línea de comandos representa archivos o directorios de la siguiente manera (es bastante consistente con el comportamiento de cp o rcp de Unix) :

• Si name-of-source es un archivo, name-of-destination puede ser un archivo (existente o no) o un directorio (que debe existir). En otras palabras, un archivo único puede ser copiado en otro archivo o en un directorio.

• Si name-of-source es dos o más archivos, uno o más directorios, o una

combinación, name-of-destination debe ser un directorio existente dentro del que tome lugar la copia*. En otras palabras, los archivos y directorios múltiples pueden ser copiados sólo dentro de un directorio.

* Decimos “debe”, pero técnicamente se puede especificar un archivo como destino en algunos casos. Sin embargo, este comportamiento probablemente no es el esperado. Cuando los archivos múltiples se copian en sólo un archivo de destino, cada uno se sobreescribe en el próximo. Tanto name-of-source como name-of-destination pueden tomar la siguiente forma de izquierda a derecha:

1. El nombre de usuario de la cuenta que contiene el archivo o directorio, seguido por @. Esta parte es opcional y si se omite, el valor es el nombre de usuario del usuario que invoca scp.



2. El hostname del host que contiene el archivo o directorio, seguido por dos puntos. Esta parte es opcional si la ruta está presente y falta el nombre de usuario. Si se omite, el valor es localhost. SSH2 permite un número de puerto TCP opcional para la conexión SSH que se inserta entre el hostname y los dos puntos, precedido por un signo de discusión.

3. La ruta del directorio al archivo o directorio. (Opcional si el hostname está

presente.) Los nombres de ruta relativos se asumen como relativos al directorio por defecto, que es el directorio actual ( para rutas locales) o el directorio home del usuario ( para rutas remotas). Si se omite por completo, se asume que la ruta es el directorio por defecto.

Aunque cada campo es opcional, no se pueden omitir todos al mismo tiempo, dejando la cadena vacía. El hostname (2) o la ruta de directorio (3) deben estar presentes. Algunos ejemplos:

MyFile El archivo ./MyFile en localhost

MyDirectory

El directorio ./ MyDirectory en localhost El directorio actual en localhost server.example.com: El directorio – usermane en server.example.com server.example.com

Un archivo local llamado “server.example.com” (¿faltan los dos puntos al final? es un error común)

server.example.com: MyFile El archivo MyFile en el directorio home del usuario remoto en

server.example.com bob@ server.example.com: El directorio –bob en server.example.com bob@ server.example.com

Un archivo local llamado “bob@ server.example.com” (faltan los dos puntos otra vez) bob@ server.example.com:MyFile El archivo –bob/MyFile en server.example.com

server.example.com:dir/MyFile El archivo dir/MyFile en el directorio home del usuario remoto en

server.example.com

server.example.com:/dir/MyFile El archivo /dir/MyFile en server.example.com (nótese la ruta absoluta)

[email protected]:dir/MyFile El archivo –bob/dir/MyFile en server.example.com [email protected]:/dir/MyFile El archivo /dir/MyFile en server.example.com (aunque se autentica como bob, la ruta es absoluta) server.example.com#2000:

El directorio home del usuario remoto en server.example.com, a través de el puerto TCP 2000 (sólo SSH2) Aquí hay algunos ejemplos completos:

• scp myfile myfile2 Una copia como cp

• scp myfile bob@host1: Copia ./myfile a –bob en el host1

• scp bob@host1:myfile Copia –bob/myfile en el host1 a ./myfile

• scp host1:file1 host2:file2 Copia file1 de host1 a file2 en host2

• scp bob@host1:file1 jen@host2:file2 Lo mismo que arriba, pero copiando

desde la cuenta de bob a la de jen.



Tabla 11-1. Especificaciones de Ruta

Campo Otra Sintaxis Opcional Estandar para

Host Local Host Remoto

Nombre de usuario

Seguido por @ Si Invocar el nombre del Usuario

Invocar el nombre del Usuario

Nombre del host

Seguido por : Solo si se omite el nombre de usuario y la ruta esta presente

Ninguno, el archivo se accede localmente

N/D

Numero de puerto

Precedido por #

Si 22 22

Ruta de Directorio

N/D Solo si el nombre del host está presente

Directorio actual (invocante?

Directorio home remoto del nombre de usuario

11.4.2.- Manejo de ()Wildcards()

scp para SSH1 y OpenSSH no posee soporte especial para () wildcards() en los nombres de archivo. Simplemente, permite que la shell las expanda:

$scp *.txt server.example.com: Es necesario estar atento a las () wildcards () en las especificaciones, según están evaluados en la máquina local, no en la remota. Por ejemplo, este intento está destinado a fallar:

$scp1 server.example.com:*.txt La shell Unix intenta expandir la ()wildcard() antes de que se invoque scp1, pero el directorio actual no contiene ningún nombre de archivo que coincida con “server.example.com:*.txt” . C shell y sus derivados informarán que no hay coincidencia y no ejecutarán scp1. Shells estilo Bourne, notando que no hay coincidencia en el directorio actual, pasarán la () wildcard() sin expandir a scp1, y la copia puede ser exitosa como fue planeado, pero no se debe confiar en este comportamiento aleatorio. Lo más recomendable es evitar siempre las () wildcards() de manera que sean explícitamente ignoradas por la shell y pasadas a scp1:

$scp1 server.example.com:\*.txt . scp2 hace su propia expresión regular combinando luego de que la expansión shell- () wildcard() está completa. La manpage sshregex para SSH2 describe a los operadores soportados. Aun así, escápele a los caracteres () wildcard () si desea que la shell local no se entrometa.

11.4.3.- Copia Recursiva de Directorios

A veces, es necesario copiar no sólo un archivo sino ()una jerarquía de () directorio. En este caso se utiliza la opción -r, que significa recursiva. Si se esá familiarizado con rcp, su opción –r tiene el mismo efecto. Por ejemplo, para copiar el directorio /usr/local/bin y todos sus archivos y subdirectorios con seguridad a otra máquina:

#SSH1, SSH2, OpenSSH $ scp –r /usr/local/bin server.example.com:

Si se omite la opción –r en la copia de directorios, scp lo hará notar:

$ scp /usr/local/bin server.example.com: /usr/local/bin: not a regular file

Aunque scp puede copiar directorios, éste no es necesariamente el mejor método. Si un directorio contiene links () hard o soft (), no serán duplicados. Los links se copian como simples archivos (los objetivos de los links), o peor, los links circulares causan que scp () se repita () indefinidamente. En cambio, scp2 detecta los links simbólicos y copia sus objetivos. Otros tipos de archivos especiales, como los llamados pipes, tampoco se copian correctamente*. Una mejor solución es utilizar tar, que maneja los archivos especiales correctamente, y enviarlo a la máquina remota para deshacerlo a través de SSH:

$ tar cf - /usr/local/bin | server.example.com tar xf -



*Estas limitaciones también ocurren cuando se copian archivos simples, pero por lo menos el resultado erróneo salta a la vista rápidamente. En el caso de los directorios, se puede copiar una () jerarquía () incorrectamente sin notarlo.

11.4.4 Conservación de Permisos

Cuando scp copia archivos, los archivos de destino son creados con ciertos atributos. Por defecto, los permisos adhieren a un umask en el host de destino, y la hora de modificación y último acceso será la hora de la copia. Alternativamente, se le puede decir a scp que duplique los permisos y las horas de los archivos originales. La opción –p es la que realiza este trabajo:

#SSH1, SSH2, OpenSSH $ scp –p myfile server.example.com:

Por ejemplo, para transferir un directorio home completo a una máquina remota, lo más probable es que se desee mantener los atributos de archivo iguales a los originales:

$ scp –rp $HOME server.example.com:myhome/

11.4.5.- Remoción Automática de Archivo Original

Luego de copiar un archivo, scp2 ofrece la opción de borrar el original. La opción de línea de comandos –u especifica esto*:

# SSH2 only $ scp2 myfile server.example.com: $ ls myfile myfile $ scp2 –u myfile.server.com: $ ls myfile myfile: No such file or directory

Para agregar un comando de “transporte seguro”, además de una copia segura, se puede definir uno en términos de scp2 –u :

$ alias smv=’scp2 –u’

11.4.6.- Características de Seguridad

scp posee dos características para proteger al programador de correr comandos peligrosos. Suponiendo que se desee copiar un archivo local myfile a un directorio remoto. Si se tipea: # SSH1, SSH2, OpenSSH $ scp2 myfile server.example.com:mydir $ rm myfile y se conecta con server.example.com, se encontrará con que mydir no es un directorio, sino un archivo, ¡y está sobreescrito! La opción –d previene esta tragedia. Si el destino no es un directorio, scp envía una queja y se retira sin copiar el archivo. # SSH1, SSH2, OpenSSH $ scp2 –d myfile server.example.com:mydir warning: Destination file is not a directory warning: Exiting. Esta opción es necesaria sólo cuando se está copiando un archivo simple. Si se copian archivos múltiples o un directorio, todas las implementaciones scp confirman por defecto que el destino remoto sea un directorio.* Otra característica de seguridad de scp2 es la opción –n, que instruye al programa a describir sus acciones pero no realiza ninguna copia. Esto es útil para verificar el comportamiento de scp2 antes de ejecutar un comando potencialmente riesgoso. # SSH2 only $ scp2 –n myfile server.example.com: Not transferring myfile -> server.example.com:. myfile (1k)

11.5 Reenvío de Puertos



SSH utiliza TCP/IP como su mecanismo de transporte, usualmente TCP puerto 22 en la máquina servidor, mientras encripta y desencripta el tránsito que pasa a través de la conexión. Existe una característica llamada reenvío de puertos (port forwarding), que encripta y desencripta el tránsito TCP/IP que pertenece a otras aplicaciones, en otros puertos TCP, utilizando SSH. Este proceso es bastante transparente y poderoso. Telnet, SMTP, NNTP, IMAP y otros protocolos inseguros que corren sobre TCP se pueden hacer seguros reenviando las conexiones a través de SSH. Al reenvío de puertos también se lo llama tunneling porque la conexión SSH provee de un “túnel” seguro a través del cual puede pasar otra conexión TCP/IP. Supongamos que se tiene una máquina H que corre un lector de correo electrónico capaz de IMAP y se la desea conectar a un servidor en la máquina S para leer y enviar correo electrónico. Normalmente, esta conexión será insegura, con la clave de acceso de la cuenta de correo transmitida como texto simple entre el programa de correo y el servidor. Con el reenvío de puertos de SSH, se puede re-rutear la conexión IMAP de manera transparente (como se encuentra en el puerto TCP 143 del servidor S) para que pase a través de SSH, encriptando con seguridad los datos de la conexión*. Para brindar una protección real, la máquina servidor IMAP debe estar corriendo un servidor SSH para reenvío de puertos. En resumen, con unos mínimos cambios de configuración de los programas, el reenvío de puertos de SSH protege las conexiones TCP/IP arbitrarias redirigiéndolas a través de una sesión SSH. El reenvío de puertos puede incluso pasar una conexión segura a través de una firewall si se configura apropiadamente. Una vez que se comienza a asegurar las comunicaciones con el reenvío de puertos, se nota que es imprescindible. Aquí hay ejemplos de lo que se puede hacer:

• Acceder a varias clases de servidores TCP (por ej.: SMTP, IMAP, POP, LDAP, etc.)

a través de una firewall que impide el acceso directo. • Proveer protección para las sesiones con estos mismos servidores TCP,

impidiendo la revelación o alteración de claves u otro contenido que de otra manera debería ser enviado sin proteger como parte de la sesión.

• Encauzar (tunnel) la conexión control de una sesión FTP, para encriptar el nombre de usuario, la clave y los comandos. (Sin embargo, usualmente no es posible proteger los canales de datos que transportan los contenidos de archivos.)

• Utilizar los servidores SMTP de ISP para enviar correo electrónico, aunque se esté conectado fuera de la red de ISP y el ISP prohíba el relevo de correo electrónico desde la ubicación actual.

Nota: El reenvío de puertos no funciona con protocolos que no estén construídos en TCP, como los basados en UDP (DNS, DHCP, NFS y NetBIOS**) o con protocolos que no estén basados en IP, como AppleTalk o SPX/IPX de Novell.

* Este ejemplo de reenvío de puertos protege la conexión IMAP pero no protege realmente a los mensajes de correo electrónico. Antes de alcanzar al servidor IMAP, los mensajes pasan a través de otros servidores de correo y pueden ser interceptados durante el tránsito. Para que la seguridad sea completa, tanto el transmisor como el receptor deben utilizar herramientas como PGP o S/MIME para firmar y/o encriptar los mensajes. ** Esto es un tanto impreciso. DHCP está basado íntegramente en UDP, de manera que el reenvío de puertos de SSH no puede hacer nada con él. Los otros, sin embargo, utilizan TCP y UDP para diferentes propósitos o pueden ser configurados, a veces, para correr sobre TCP, aunque generalmente utilizan UDP. De todas maneras, en las situaciones más comunes, SSH no puede reenviarlos.

11.5.1 Reenvío local

En el ejemplo anterior, había un servidor IMAP corriendo en la máquina S, y un lector de correo electrónico en la máquina home H. El objetivo era asegurar la conexión IMAP utilizando SSH. Aquí profundizaremos con más detalle: IMAP utiliza el puerto TCP 143, esto significa que un servidor IMAP estará “escuchando” a la espera de conexiones en el puerto 143 de la máquina servidor. Para encauzar (tunnel) la conexión IMAP a través de SSH, se necesita elegir un puerto local en alguna máquina H (entre 1024 y 65535) y reenviarlo al receptáculo (socket) remoto (S,143). Suponiendo que se elige al azar el puerto 2001, el siguiente comando crea entonces el túnel:



$ ssh –L2001:localhost:143 S

11.5.2 Conexiones TCP

Para comprender el reenvío de puertos, es importante conocer algunos detalles sobre TCP, el Protocolo de Control de Transmisión (Transmission Control Protocol). TCP es un ladrillo fundamental de Internet. Construído encima de IP, es el mecanismo de transporte para muchos protocolos de Internet del nivel de aplicación como FTP, Telnet, HTTP, SMTP, POP, IMAP, y el mismo SSH. TCP viene con fuertes garantías. Una conexión TCP es un circuito virtual, () full-duplex() entre dos partes que se comunican, actuando como un puente de dos vías. Cualquiera de las partes puede escribir en el puente cualquier número de bytes en cualquier momento, y los bytes llegarán al otro lado con la garantía de que permanecerán inalterados y ordenados. Los mecanismos que implementan estas garantías, sin embargo, están diseñados para contrarrestar los problemas de transmisión en la red, como el ruteo (routing) alrededor de links fallidos, o la retransmisión de datos corrompidos por ruidos o perdidos debido a la congestión temporaria de la red. Éstos no son efectivos contra intentos deliberados de robar una conexión o alterar datos en tránsito. SSH provee esta protección que TCP por sí mismo no puede brindar. Si una aplicación no necesita estas garantías acerca de la integridad y el orden de los datos, o no desea el costo asociado con ellas, entonces otro protocolo llamado UDP, Protocolo de Datagrama de Usuario (User Datagram Protocol) suele ser suficiente. Está orientado a los paquetes, y no tiene garantías de entrega o de ordenamiento de paquetes. Algunos protocolos que corren sobre UDP son NFS, DNS, DHCP, NetBIOS, TFTP, Kerberos, SYSLOG, y NTP. Cuando un programa establece una conexión TCP a un servicio, necesita dos piezas de información: la dirección IP de la máquina destino y una manera de identificar el servicio deseado. TCP (y UDP) utilizan un entero (integer) positivo, llamado número de puerto, para identificar un servicio. Por ejemplo, SSH utiliza el puerto 22, telnet el 23, e IMAP el 143. Los números de puerto permiten servicios múltiples en la misma dirección IP. La combinación de una dirección IP y un número de puerto se llama receptáculo (socket). Por ejemplo, si se corre telnet para conectarse al puerto 23 en la máquina en la dirección IP 128.220.91.4, el receptáculo es denotado “(128.220.91.4,23)”. Simplemente, cuando se hace una conexión TCP, su destino es un receptáculo. La fuente (el programa cliente) también tiene un receptáculo de su lado de la conexión, y la conexión como un todo es definida íntegramente por el par de receptáculos de fuente y destino. Para que un intento de conexión a un receptáculo sea exitoso, algo debe estar “escuchando” en ese receptáculo. Esto es, un programa que corre en la máquina destino debe pedirle a TCP que acepte los pedidos de conexión en ese puerto y que pase las conexiones al programa. Cuando al intentar una conexión TCP se recibe la respuesta “conexión denegada”, significa que la máquina remota está funcionando, pero nada está “escuchando” en el receptáculo objetivo. ¿Cómo sabe el programa cliente el número de puerto objetivo de un servidor que está escuchando? Los números de puerto de muchos protocolos están estandarizados, asignados por la IANA, Autoridad de Números Asignados de Internet (Internet Assigned Numbers Authority). (La lista completa de números de puerto de la IANA se encuentra en http://www.isi.edu/in-notes/iana/assignments/port-numbers.) Por ejemplo, el número de puerto TCP asignado al protocolo NNTP (Usenet news), es el 119. Por lo tanto, los servidores de noticias escuchan en el puerto 119, y los lectores de noticias (clientes) se conectan a ellos por medio del puerto número 119. Más específicamente, si un lector de noticias es configurado para hablar con un servidor de noticias en la dirección IP 10.1.2.3, requiere una conexión TCP al receptáculo (10.1.2.3,119). Los números de puerto no están siempre () hardcoded() dentro de los programas. Muchos sistemas operativos permiten que las aplicaciones se refieran a los protocolos por nombre, en lugar de número, definiendo una tabla de nombres y números de puertos TCP. Los programas pueden entonces buscar los números de puerto por el nombre del protocolo. Bajo Unix, la tabla está a menudo contenida en el archivo /etc/services o el mapa de servicios NIS, y las preguntas (queries) se realizan utilizando las rutinas de biblioteca getservbyname () , getservbyport (), y procedimientos relacionados. Otros ambientes permiten que los servidores registren sus puertos de escucha de manera dinámica a través de un servicio de nombres, como el AppleTalk Name Binding Protocol o los records WKS y SRV de DNS. Hasta ahora, la discusión estuvo basada en el número de puerto utilizado por un servidor TCP cuando un programa cliente TCP desea conectarse. Llamamos a esto número de puerto objetivo. El cliente también utiliza un número de puerto, llamado número de puerto fuente, de manera que el servidor pueda transmitir al cliente. Si se combinan la dirección de IP del cliente con su número de puerto fuente, se consigue el receptáculo (socket) del cliente.



Al contrario de los números de puerto objetivo, los números de puerto fuente no son estándar. En la mayor parte de los casos, ni al cliente ni al servidor le interesa qué número de puerto fuente utiliza el cliente. A menudo un cliente permitirá que TCP seleccione un número de puerto sin usar por fuente. (Sin embargo, los comandos –r de Berkeley se interesan por los puertos fuente.) Si se examinan las conexiones TCP existentes en una máquina con un comando tal como netstat –a o lsof-i tcp, se verán conexiones a los números de puertos conocidos para los servicios comunes (por ej.: 23 para Telnet, 22 para SSH), junto con números de puerto fuente largos, aparentemente al azar en el otro extremo. Esos puertos fuente fueron elegidos del rango de puertos no asignados por TCP en las máquinas que iniciaron esas conexiones. Una vez establecida, una conexión TCP es determinada completamente por la combinación de sus receptáculos fuente y objetivo. Por lo tanto, múltiples clientes TCP pueden conectarse al mismo receptáculo objetivo. Si las conexiones se originan en diferentes hosts, las porciones de dirección IP de los receptáculos fuente diferirán, distinguiendo las conexiones. Si vienen de dos programas diferentes corriendo en el mismo host, TCP asegura en ese host que tengan diferentes números de puerto fuente. La opción –L especifica el reenvío local, en el cual el TCP cliente está en la máquina local con el cliente SSH. A la opción la siguen tres valores separados por dos puntos: un puerto local en el que escuchar (2001), el nombre de la máquina remota o la dirección IP (S), y el número de puerto objetivo remoto (143). El comando anterior ingresa a S, así como si se tipeara ssh S. Sin embargo, esta sesión SSH ha reenviado el puerto TCP 2001 en H al puerto 143 en S; el reenvío sigue en efecto hasta que el programador se retire de la sesión. Para hacer uso del túnel, el paso final es decirle al lector de correo electrónico que utilice el puerto reenviado. Normalmente el programa de correo electrónico se conecta al puerto 143 en la máquina servidor, eso es, al receptáculo (S,143). En cambio, está configurado para conectarse al puerto 2001 en la máquina home H (localhost,2001). De manera que el camino de la conexión es ahora como sigue:

1. El lector de correo electrónico en la máquina home H envía datos al puerto local

2001. 2. El cliente local SSH en H lee el puerto 2001, encripta los datos, y los envía a

través de la conexión SSH al servidor SSH en S. 3. El servidor SSH en S desencripta los datos y los envía al servidor IMAP que está

escuchando en el puerto 143 en S. 4. Los datos son enviados de vuelta desde el servidor IMAP a la máquina home H

por el mismo proceso en reversa.

El reenvío de puertos puede ser especificado sólo cuando se crea una conexión SSH. No se puede agregar un reenvío a una conexión existente con ninguna implementación SSH de la que tengamos conocimiento, aunque no hay nada intrínseco al protocolo SSH que lo evite, y sería, a veces, una característica útil. En lugar de utilizar la opción –L para establecer un reenvío local se puede usar la palabra clave LocalForward en el archivo de configuración del cliente:

# SSH1, OpneSSH LocalForward 2001 localhost:143 # SSH2 solamente LocalForward “2001:localhost:143”

Nótense las pequeñas diferencias en sintaxis. En SSH1 y OpenSSH, hay dos argumentos: el número de puerto local, y el receptáculo remoto expresado como host:port. En SSH2, la expresión es igual que en la línea de comando, excepto que debe ser encerrada entre comillas. Si se omiten las comillas, ssh2 no se queja, pero tampoco reenvía el puerto. Nuestro ejemplo con la máquina home H y el servidor IMAP S se puede mostrar así:

# SSH1, OpenSSH Host local-forwarding-example Hostname S LocalForward 2001 localhost:143 # Corrido en la máquina home H $ ssh local-forwarding-example

11.5.2.1 Forwardeo local y GatewayPorts

En SSH1 y OpenSSH, por defecto, sólo el host que corre el cliente SSH puede conectarse a puertos reenviados localmente. Esto es porque ssh sólo escucha en el interfaz () loopback() en busca de conexiones al puerto reenviado; une el receptáculo (localhost,2001), también conocido como (127.0.0.1,2001), y no (H,2001). De manera que, en el ejemplo anterior, sólo la máquina H puede utilizar el reenvío; los intentos de



otras máquinas de conectarse a (H,2001) obtienen el mensaje “conexión denegada”. Sin embargo, ssh para SSH1 y OpenSSH tiene una opción de línea de comando, -g, que deshabilita esta restricción, permitiendo que cualquier host se conecte a puertos localmente reenviados:

# SSH1, OpenSSH $ ssh1 –g –L<localport>:<remotehost>:<remoteport> hostname

La configuración cliente de palabra clave GatewayPorts también controla esta característica; el valor por defecto es no, y dar GatewayPorts=yes hace lo mismo que –g:

# SSH1, OpenSSH GatewayPorts yes

Hay una razón por la que GatewayPorts y –g están deshabilitados por defecto: representan un riesgo para la seguridad.

11.5.2.2 Reenvío remoto

Un puerto reenviado remotamente es igual a uno local, pero las direcciones están invertidas. Esta vez el cliente TCP es remoto, su servidor es local, y se inicia una conexión reenviada desde la máquina remota. Continuando con nuestro ejemplo, si se está en la máquina S, donde está corriendo el servidor IMAP, se puede crear un túnel seguro para que los clientes remotos alcancen al servidor IMAP en el puerto 143. Una vez más, se selecciona un número de puerto para reenviar (digamos, 2001 nuevamente) y se crea el túnel:

$ ssh –R2001:localhost:143 H

La opción –R especifica el reenvío remoto. La siguen tres valores, separados por dos puntos como antes, pero interpretados con una ligera diferencia. El puerto remoto para ser reenviado (2001) va ahora primero, seguido por el nombre de la máquina o la dirección IP (localhost) y el número de puerto (143). SSH puede ahora reenviar conexiones desde (localhost,143) a (H,2001). Una vez corrido este comando, se ha construído un túnel seguro desde el puerto 2001 en la máquina remota H, al puerto 143 en la máquina servidor S. Ahora cualquier programa en H puede utilizar el túnel seguro conectándose a (localhost,2001). Como antes, el comando también corre una sesión terminal SSH en la máquina remota H, al igual que ssh H. Como en el reenvío local, se puede establecer un reenvío remoto utilizando una palabra clave en el archivo de configuración del cliente. La palabra clave RemoteForward es análoga a LocalForward, con la misma diferencia sintáctica entre SSH1 y SSH2:

# SSH1, OpenSSH RemoteForward 2001 S:143 # SSH2 solamente RemoteForward “2001:S:143” Por ejemplo, aquí está el reenvío precedente definido en un archivo de configuración formato SSH2: # SSH2 solamente remote-forwarding-example: Host H RemoteForward “2001:S:143” $ ssh2 remote-forwarding-example

Nota: Se podría pensar que la característica GatewayPorts discutida más arriba se aplica igualmente bien al reenvío de puertos remoto. Esto debería tener sentido como una característica, pero no ocurre. Debería haber una manera para que el cliente comunique este parámetro al servidor para un reenvío dado, y esa característica no ha sido incluída en el protocolo SSH. En SSH1 y SSH2, los puertos reenviados remotamente siempre escuchan en todas las interfaces de red y aceptan conexiones desde cualquier parte. El servidor OpenSSH acepta la opción de configuración GatewayPorts, y se aplica globalmente a todos los reenvíos remotos establecidos por ese servidor.


Disclaimer 65

Disclaimer

Todo el contenido y materiales (tanto impresos como software) son para un fin educativo.

Digital Thinking Group ni ninguno de sus Instructores se responsabilizan por el mal uso

que puedan darle a estos.


Temario

1. Introducción 1

1.1 Overview 1

2 Conceptos de Seguridad 2

2.1 Seguridad de Contraseñas 2

2.2 Rompiendo contraseñas (Cuando necesitamos recuperar contraseñas) 3

2.3 Recuperación de contraseñas en Microsoft Windows NT 5

2.3.2 Crackeando los passwords en Windows NT 5

2.3.2.1 Introducción 5

2.3.2.2 Crackeando los passwords en Windows NT 5

2.3.2.3 Obteniendo el archivo SAM 6

2.3.2.4 Volcando los passwords desde el registro 6

2.4 Usando un sniffer 7

2.4.1 Donde conseguir los programas que necesitamos? 7

3 Ataques 8

3.1 Que es el Spoofing? 8

3.2 TCP y IP spoofing 8

3.3 Caso de spoof básico 8

3.4 Ataque Spoof de números secuenciales 8

3.5 Un caso de ataque secuencial 9

3.6 ARP Spoofing 10

3.7 DNS spoofing 10

3.8 Previniendo IP Spoofing 11

3.9 Previniendo ARP Spoof 12

3.10 Previniendo DNS Spoofing 12

3.11 Buffer Overflows y otros ataques 12

3.12 Ping of death 13

3.13 Internet worm 13

4 Scanners 14

4.1 Introducción Scanners 14

4.2 Técnicas de Finger Printing 14

4.3 BSD sockets 14

4.4 Ejemplo de nmap 15

4.5 Mas allá del nmap 16

4.6 Otros tipos de scanners 16

4.7 NT también existe 16

4.8 Sniffers, la amenaza interna 17

4.8.1 Pensemos este escenario 17

4.8.2 Pero, vayamos por pasos, y veamos algo de teoría 17

4.8.3 Ejemplo practico 17

4.8.4 Lophtcrack 17

4.8.5 Smbsniff 17

4.8.6 Winsniff 17

4.9 Linux también existe 18

4.9.1 Vamos a citar un ejemplo de la vida real. 18

4.9.2 Detectando un sniffer 18

5 Firewall de TCP / IP 19

5.1 Introducción 19

5.2. Métodos de ataque 20

5.3 ¿Qué es un firewall? 21

5.4 ¿Qué es el filtrado de IP? 22

5.5 Configuración de Linux como firewall 23

5.5.1. Núcleo configurado con firewall de IP 23

5.5.2 La utilidad iptables 23

5.6 Las formas posibles de filtrado 24


Temario

5.7 Netfilter e 'IP Tables' (Núcleos 2.4) 25

5.7.1 Compatibilidad hacia atrás con ipfwadm e ipchains 26

5.7.2 Uso de iptables 26

5.7.2.1. Órdenes 27

5.7.2.2 Parámetros de especificación de reglas 28

5.7.2.3. Opciones 28

5.7.2.4 Extensiones 28

5.7.2.4.1 Extensiones de TCP: utilizadas con -m tcp -p tcp 29

5.7.2.4.2 Extensions de UDP: utilizadas con -m udp -p udp 29

5.7.2.4.3 Extensiones de ICMP: utilizadas con -m icmp -p icmp 29

5.7.2.4.4 Extensiones de MAC: utilizadas con -m mac 29

5.7.3 Nuestro ejemplo simple revisado otra vez 29

5.8 Manipulación de los bits de TOS 30

5.8.1 Establecimiento de los bits de TOS con iptables 31

5.9 Comprobación de una configuración del firewall 31

5.10 Un ejemplo de configuración del firewall 35

6 Enmascaramiento IP y Traducción de Direcciones de Red 38


6.1 Efectos colaterales 39

6.2 Configuración del Núcleo para enmascaramiento IP 40

6.3. Configuración del enmascaramiento IP 41

6.4 Más sobre la traducción de direcciones de red 42

7 El Día Después 43

7.1 El Día Después 43

7.2 Que pasa en un sistema Unix 44

7.3 Backdoors en Sistemas Unix 44

7.4 Detectando troyanos 44

7.5 Casos Prácticos 44

7.6 Medidas Mínimas de Seguridad 45

8 Log del Sistema 47

8.1 Los Logs y su importancia 47

8.2 wtmp 47

8.3 Detectando los logs alterados 48

9 DMZ 49

9.1 Creando Zonas Desmilitarizadas 49

10 Buffer Over Flows 51

10.1 Creando Buffer Over Flows 51

11 Servidor de SSH (Secure Shell) 54


11.1.1 ¿Qué es SSH? 54

11.2 Cómo correrlo. Un ejemplo 54

11.2.1 Sesiones en una Terminal Remota con SSH 55

11.2.2 Transferencia de Archivos con scp 55

11.3 Agregando Complejidad al Ejemplo 56

11.3.1. Hosts Conocidos 56

11.4. Copia Segura con scp 57

11.4.1.- Sintaxis Completa 57

11.4.2.- Manejo de ()Wildcards() 59

11.4.3.- Copia Recursiva de Directorios 59

11.4.4 Conservación de Permisos 60

11.4.5.- Remoción Automática de Archivo Original 60

11.4.6.- Características de Seguridad 60


Temario

11.5 Reenvío de Puertos 60

11.5.1 Reenvío local 61

11.5.2 Conexiones TCP 62

11.5.2.1 Forwardeo local y GatewayPorts 63

11.5.2.2 Reenvío remoto 64

Disclaimer 65


seguridad i - linux

Documents