Seguridad I

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).

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:
Comparaciones
Cracker Tiempo Observaciones
por Segundo
John the ripper 1.4 6'15'' 26667c/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 .
Sólo soporta ficheros de
PCUPC 2.01 (est)135'37'' 1229c/s passwords
de menos de 500 linias.
Guess 2.1 (est)141'58'' 1174c/s passwords de menos
de 1000 linias.
Killer Cracker 9.5 (est)151'12'' 1105c/s passwords
de menos de 1000 linias.
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@email.com
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

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: caos@192.168.0.2
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 <------|

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
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.

• 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
Especifica un host en particular al que le queres hacer el

-a [hostname]
query.
-b [hostname] Borra una entrada a un Host particular.
-f [archivo de conf.] Archivo de configuración.
-a [hostname]
Especifica la HWaddr al Host seleccionado.
[address_type]
Para las distintas tipo de entrada por Ej.:
-t [type]
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

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 fyodor@insecure.org ( 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
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 user@victima.com
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 fyodor@insecure.org ( 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
901/tcp open samba-swat
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.

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:

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
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
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)

MASQUERADE all -- anywhere anywhere MASQUERADE
Chain OUTPUT (policy ACCEPT)

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

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)
nacho tty5 Wed May 23 12:25 – down (02:51)
reboot system boot 2.2.18 Wed May 23 12:19 (02:57)
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.
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....
Mail Server
(Sendmail)
Router DNS Server

(Bind)
INTERNET Web Server
(Internet
Information
Server)
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
Mail Server
(Sendmail)
Router Firewall
DNS Server
INTERNET (Bind)
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:
y lo que nos dice aquí es que no existe fichero o directorio, pero lo que verdaderamente
nos ocupa, es lo siguiente...
Nos dice nombre de archivo demasiado largo...
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 pat@shell.isp.com
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 pat@shell.isp.com: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 pat@shell.isp.com: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.

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.
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)
bob@server.example.com:dir/MyFile
El archivo –bob/dir/MyFile en server.example.com
bob@server.example.com:/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 Remoto

Host Local
Nombre de Seguido por @ Si Invocar el Invocar el
usuario nombre del nombre del
Usuario Usuario
Nombre del Seguido por : Solo si se omite el Ninguno, el N/D
host nombre de archivo se
usuario y la ruta accede
esta presente localmente
Numero de Precedido por Si 22 22
puerto #
Ruta de N/D Solo si el nombre Directorio actual Directorio
Directorio del host está (invocante? home remoto
presente 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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Seguridad I - Linux

Uploaded by

Copyright:

Available Formats

Digital Thinking © 2004 - 2005

En este texto vamos a realizar un acercamiento inusual a los sistemas de seguridad.

Digital Thinking © 2004 - 2005

2.1 Seguridad de Contraseñas

Para que la autentificación de usuario funcione correctamente se necesitan (como mínimo)

El problema que tiene esto es que la potencia computacional ha crecido enormemente, y

• Utiliza un algoritmo de hashing "mejor", como MD5. Problema: se pueden romper

• Almacena las contraseñas en alguna otra parte. Problema: el sistema/usuarios

Varios sistemas operativos han escogido la primera opción, Linux ha implementado la

En el fichero de contraseñas, se reemplaza la contraseña por una ‘x’, lo cual le indica al

Irix(Cuidado con las cuentas por default!)

Digital Thinking © 2004 - 2005

Debido a la confianza de Red Hat en PAM para la autentificación, para implementar un

En Red Hat 6.0, durante la instalación se te da la opción de elegir contraseñas con

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

John the ripper ("Juan el destripador")

Un eficiente rompedor de contraseñas se encuentra disponible en:

El rompedor de contraseñas original y ampliamente extendido (según me consta), se

Otro rompedor de contraseñas con capacidades de red, se puede descargar de:

Velocity Cracking Utilities

Velocity Cracking Utilities (VCU en adelante), es un programa basado en windows para

Digital Thinking © 2004 - 2005

Digital Thinking © 2004 - 2005

3.1 Que es el Spoofing?

3.2 TCP y IP spoofing

Centrémonos en Nuestro Server (linux/unix/Bsb) que protege varios servicios al mismo

La mayoría de estas herramientas protege, comparando Host y IP y utilizándolos para

estos son los que no quiero que usen mis servicios

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

Bienvenido Qqmelo Server

3.4 Ataque Spoof de números secuenciales

un ejemplo del archivo.rhosts

Digital Thinking © 2004 - 2005

El atacante tiene dos problemas el primero es cambiar la dirección y la otra es mantenerla

Si el atacante adivina correctamente él numero, este puede sincronizarse con la victima e

3.5 Un caso de ataque secuencial

Aplicación: mendax para linux lenuage:c

Para usarlo tenemos que hacer:

ahora mi objetivo es ejecutar el comando rsh desde 192.168.0.8 a 192.168.0.1

mv .rhosts .r; echo + + > .rhosts

Flooding sourse con TCP SYN packets from 192.168.0.8

samplin secuense numbers

seq number: 816640001, ack number: 64001 difference:64000

using 64000 as prediction difference (3 hits)

Digital Thinking © 2004 - 2005

reseting TCP target connection:

3.6 ARP Spoofing

Para verla, se hace lo siguiente:

[toor@powertech toor]# ifconfig eth0

Un ejemplo de una dirección de hardware es esta:

En el ARP spoofing, el atacante mantiene su HWaddress pero asume el IP de un trusted

3.7 DNS spoofing

[toor@powertech toor]# nslookup www.qqmelo.com.ar

[toor@powertech toor]# nslookup www.yahoo.com.ar

Digital Thinking © 2004 - 2005

Un ejemplo de estos tipo de programas es el paquete de ADM se llama ADMidpkd.tar.gz.

[toor@powertech toor]# nslookup www.yahoo.com.ar

También hay varios programas mas:

author: Johan y Dioxide

Los pueden bajar en:

3.8 Previniendo IP Spoofing

pero también se pueden poner rangos de ip tipo 200.0.212.* o 200...*