Comandos Unix y Linux
Comandos Unix y Linux
y Linux
Pello Xabier Altadill Izura
[Link]
1. INTRODUCCIÓN
2. REFERENCIA DE COMANDOS UNIX-LINUX
3. COMBINACIONES ÚTILES
4. DIAGNOSTICO DE SISTEMA
5. RESOLUCION DE PROBLEMAS
6. NOTAS, ACTUALIZACIONES
INTRODUCCIÓN
Nota: Este guía no es para leer de forma seguida, este guía pretende ser una referencia de comandos Unix/Linux que se
pueda consultar en cualquier momento. No pretende ser una guía exhaustiva, sino una referencia que sirva como
recordatorio de los comandos más utilizados.
El shell:
Existen distintos interpretes de comandos en el mundo Unix: csh, bash, tsh, ksh,.. pero salvo pequeñas diferencias todos
son parecidos. En este documento partimos sobretodo de bash, ya que esta muy extendido a través de Linux.
Asi como windows lo vemos como un entorno con ventanas, programas, etc,.. unix lo debemos ver como lo siguiente:
Unix esta formado por procesos y ficheros.
Y no hay nada más. Los dispositivos como el disco, el cdrom, la pantalla, esta representado como un fichero en el sistema
linux, dentro de /dev. Los sockets de comunicación son ficheros. Los directorios son ficheros. Los ficheros son ficheros.
-Redirección de entrada/salida
> : con este símbolo podemos redirigir la salida estandar de un comando a un fichero. Téngase en cuenta una cosa. Si
decimos fichero siempre lo vamos a decir de manera genérica, puede ser un fichero de texto o la pantalla de terminal, ahí
cabe TODO.
>> : con esto redirigimos el resultado a un fichero, pero sin sobrescribirlo, lo que hacemos es escribir al final de este
(append en ingles).
< : con esto redirigimos el contenido del fichero a un programa. Se usa para utilizar el contenido del fichero como input de
un comando.
<< END : este redirección se utiliza para iniciar el paso de parámetros a un programa, y se termina cuando escribimos
"END" o cualquier otra palabra que hayamos especificado al inicio del comando.
DIAGNÓSTICO DE SISTEMA
Otro programa muy util para el diagnostico del sistema y las conexiones de red sería IPTRAF
que se ejecuta como iptraf o /usr/bin/iptraf.
ESTADO DE DISCO: lo normal es que de un dia para otro no aumente ni en un punto porcentual,
a no ser que tenga algun servicio concreto de estadisticas o BBDD. Si llega al 90% hay que empezar
a barrer el sistema de ficheros, localizar ficheros grandes, etc.
ESTADO DE PROCESOS: normalmente veremos una serie de procesos que van desde el ID 1 al 600-700,
muchos de los cuales comienzan por "[k". Todos ellos son los iniciados al arrancar del sistema. El resto
son servidores iniciados posteriormente. El estado de los procesos en marcha suele mostrar siempre el mismo
aspecto, aunque cada servidor tendra uno distinto. Conviene conocerlo. En cuanto a la ocupacion de la CPU
ningun servicio suele ocupar mas de un 10% suele tener esos picos). Todo lo que tenga valores como
40% o mas se consideran niveles anormales; puede tratarse de generadores de [Link] programa
UTIL para ver los porcentajes es top.
ESTADO DE MEMORIA: mientras quede RAM libre no hay problema. Un servidor Linux incluso puede
aguantar usando SWAP.
RESOLUCION DE PROBLEMAS
1.- Conectividad
Hay que asegurarse de que hay conectividad. Para ello seguimos los siguientes pasos:
- Un ping continuo a la máquina.
- Intentar acceder a alguno de los servicios del equipo (23, 22). Algunos máquinas pueden tener
cerrado el ping o los ICMP en general.
Si no hay conectividad, entonces es un problemas que deben solventar los responsables de las
conexiones, y determinar si es responsabilidad nuestra
2.- Servidores
Existen varios modos de verificar que los servicios estan en marcha,
y los más practicos son los siguientes:
-Comprobar que el proceso esta en marcha (ps -axf | grep nombre_proceso)
-Comprobar que el puerto que utiliza esta abierto (netstat -ln | grep puerto)
-Comprobar que el puerto responde correctamente (telnet localhost 25 por ejemplo)
-Comprobar que esta generando logs (en /var/log)
-Comprobarlo con el script de inicio (/etc/rc.d/init.d/servicio status)
A veces puede ocurrir que el proceso del servicio se pare nada mas iniciarse,
por eso conviene comprobar DOS veces que el proceso esta en marcha.
Notas: debe tenerse en cuenta que los servicios dependen a veces de otros servicios
externos o internos, cosa que a veces puede provocar malentendidos.
Comando
ls
Descripción: =list. listar contenido de directorios.
Ejemplos: ls, ls -l, ls -fl, ls --color
cp
Descripción: =copy. copiar ficheros/directorios.
Ejemplos:cp -rfp directorio /tmp, cp archivo archivo_nuevo
rm
Descripción: =remove. borrar ficheros/directorios.
Ejemplos: rm -f fichero, rm -rf directorio, rm -i fichero
mkdir
Descripción: =make dir. crear directorios.
Ejemplos: mkdir directorio
rmdir
Descripción: =remove dir. borrar directorios, deben estar vacios.
Ejemplos: rmdir directorio
mv
Descripción: =move. renombrar o mover ficheros/directorios.
Ejemplos: mv directorio directorio, mv fichero nuevo_nombre, mv fichero a_directorio
date
Descripción: gestion de fecha de sistema, se puede ver y establecer.
Ejemplos: date, date 10091923
history
Descripción: muestra el historial de comandos introducidos por el usuario.
Ejemplos: history | more
more
Descripción: muestra el contenido de un fichero con pausas cada 25 lineas.
Ejemplos: more fichero
grep
Descripción: filtra los contenidos de un fichero.
Ejemplos:cat fichero | grep cadena
cat
Descripción: muestra todo el contenido de un fichero sin pausa alguna.
Ejemplos: cat fichero
chmod
Descripción: cambia los permisos de lectura/escritura/ejecucion de ficheros/directorios.
Ejemplos: chmod +r fichero, chmod +w directorio, chmod +rw directorio -R, chmod -r fichero
chown
Descripción: =change owner. cambia los permisos de usuario:grupo de ficheros/directorios.
Ejemplos: chown root:root fichero, chown pello:usuarios directorio -R
tar
Descripción: =Tape ARchiver. archivador de ficheros.
Ejemplos: tar cvf [Link] directorio , tar xvf [Link], tar zcvf [Link] directorio, tar zxvf [Link]
gunzip
Descripción: descompresor compatible con ZIP.
Ejemplos: gunzip fichero
rpm
Descripción: gestor de paquetes de redhat. Para instalar o actualizar software de sistema.
Ejemplos: rpm -i [Link], rpm -qa programa, rpm --force [Link], rpm -q --info programa
mount
Descripción: montar unidades de disco duro, diskette, cdrom.
Ejemplos: mount /dev/hda2 /mnt/lnx, mount /dev/hdb1 /mnt -t vfat
umount
Descripción: desmontar unidades.
Ejemplos: umount /dev/hda2, umount /mnt/lnx
wget
Descripción: programa para descargar ficheros por http o ftp.
Ejemplos: wget [Link]
lynx
Descripción: navegador web con opciones de ftp, https.
Ejemplos: lynx [Link], lynx --source [Link] | sh
ftp
Descripción: cliente FTP.
Ejemplos: ftp [Link]
whois
Descripción: whois de dominios.
Ejemplos: whois [Link]
who
Descripción: muestra los usuarios de sistema que han iniciado una sesion.
Ejemplos: who, w, who am i
mail
Descripción: envio y lectura de correo electronico.
Ejemplos: mail pepe@[Link] < fichero, mail -v pepe@[Link] < fichero
sort
Descripción: ordena el contenido de un fichero.
Ejemplos: cat /etc/numeros | sort, ls | sort
ln
Descripción: =link. para crear enlaces, accesos directos.
Ejemplos: ln -s /directorio enlace
tail
Descripción: muestra el final (10 lineas) de un fichero.
Ejemplos:tail -f /var/log/maillog, tail -100 /var/log/maillog | more
head
Descripción: muestra la cabecera (10 lineas) de un fichero.
Ejemplos: head fichero, head -100 /var/log/maillog | more
file
Descripción: nos dice de que tipo es un fichero.
Ejemplos: file fichero, file *
Comandos de administracion
sysctl
Descripción: Configurar los paràmetros del kernel en tiempo de ejuecución.
Ejemplos: sysctl -a
ulimit
Descripción: muestra los limites del sistema (maximo de ficheros abiertos, etc..)
Ejemplos: ulimit
adduser
Descripción: añadir usuario de sistema.
Ejemplos: adduser pepe, adduser -s /bin/false pepe
userdel
Descripción: = eliminar usuario de sistema
Ejemplos: userdel pepe
usermod
Descripción: = modificar usuario de sistema
Ejemplos: usermod -s /bin/bash pepe
df
Descripción: = disk free. espacio en disco disponible. Muy util.
Ejemplos: df, df -h
uname
Descripción: =unix name. Informacion sobre el tipo de unix en el que estamos, kernel, etc.
Ejemplos: uname, uname -a
netstat
Descripción: la informacion sobre las conexiones de red activas.
Ejemplos: netstat, netstat -ln, netstat -l, netstat -a
ps
Descripción: =proccess toda la informacion sobre procesos en ejecucion.
Ejemplos: ps, ps -axf, ps -A, ps -auxf
free
Descripción: muestra el estado de la memoria RAM y el SWAP.
Ejemplos: free
ping
Descripción: heramienta de red para comprobar entre otras cosas si llegamos a un host remoto.
Ejemplos: ping [Link]
traceroute
Descripción: herramienta de red que nos muestra el camino que se necesita para llegar a otra maquina.
Ejemplos: traceroute [Link]
du
Descripción: =disk use. uso de disco. Muestra el espacio que esta ocupado en disco.
Ejemplos: du *, du -sH /*, du -sH /etc
ifconfig
Descripción: =interface config. configuracion de interfaces de red, modems, etc.
Ejemplos: ifconfig, ifconfig eth0 ip netmask [Link]
route
Descripción: gestiona las rutas a otras redes.
Ejemplos: route, route -n
iptraf
Descripción: muestra en una aplicacion de consola TODO el trafico de red IP, UDP, ICMP.
Permite utilizar filtros, y es SUMAMENTE UTIL para diagnostico y depuracion de firewalls
Ejemplos: iptraf
tcpdump
Descripción: vuelca el contenido del trafico de red.
Ejemplos: tcpdump, tcpdump -u
lsof
Descripción: muestra los ficheros(librerias, conexiones) que utiliza cada proceso
Ejemplos: lsof, lsof -i, lsof | grep fichero
lsmod
Descripción: Muestra los modulos de kernel que estan cargados.
Ejemplos: lsmod
modprobe
Descripción: Trata de instalar un modulo, si lo encuentra lo instala pero de forma temporal.
Ejemplos: modprobe ip_tables, modprobe eepro100
rmmod
Descripción: Elimina modulos del kernel que estan cargados
Ejemplos: rmmod <nombre de modulo>
sniffit
Descripción: Sniffer o husmeador de todo el trafico de red. No suele venir instalado por defecto.
Ejemplos: sniffit -i
COMBINACIONES UTILES
Los comandos son muy útiles, pero con el conocimiento básico del shell y sus comandos tenemos armas muy poderosas
que muestran todo el potencial del interprete de comandos Unix. A continuación se muestran algunos ejemplos avanzados
de comandos que se usan con cierta frecuencia.
comando | grep filtro
A la salida de cualquier comando le podemos aplicar grep para que solo nos muestre
la informacion que nos interesa.
mail -v testing@[Link]
Con el parametro -v, al terminar de escribir (. enter), veremos la traza del correo hasta el servidor,
si es aceptado o no.
Al hacer more:
/cadena : podemos hacer busqueda de cadena
f : adelante
b: volver arriba
v: iniciar vi en la linea que estamos
IPTABLES
Manual práctico (1.2)
En este manual se muestran las habituales arquitecturas de redes con firewall y la forma de montar iptables para cada caso, con distintas opciones
para cada ejemplo.
1.2 Revision: añadidos los mismos casos pero con DROP por defecto.
1. Qué es un firewall
2. Qué es iptables
3. Al grano: creando un firewall con iptables
3.1 Proteger la propia máquina
3.2 Firewall de una LAN con salida a internet
3.3 Firewall de una LAN con salida a internet con DMZ
3.4 Firewall de una LAN con salida a internet y VPNS
3.5 Firewall puro y duro entre redes
3.6 Firewall con política por defecto DROP
4. Cómo depurar el funcionamiento del firewall
Enlaces, notas, autor
1. Qué es un firewall
Un firewall es un dispositivo que filtra el tráfico entre redes, como mínimo dos. El firewall puede ser un dispositivo físico o un software sobre un
sistema operativo. En general debemos verlo como una caja con DOS o mas interfaces de red en la que se establecen una reglas de filtrado con las
que se decide si una conexión determinada puede establecerse o no. Incluso puede ir más allá y realizar modificaciones sobre las comunicaciones,
como el NAT.
Esa sería la definición genérica, hoy en dia un firewall es un hardware especifico con un sistema operativo o una IOS que filtra el tráfico
TCP/UDP/ICMP/../IP y decide si un paquete pasa, se modifica, se convierte o se descarta. Para que un firewall entre redes funcione como tal debe
tener al menos dos tarjetas de red. Esta sería la tipología clásica de un firewall:
Esquema típico de firewall para proteger una red local conectada a internet a través de un router. El firewall debe colocarse entre el router (con un
único cable) y la red local (conectado al switch o al hub de la LAN)
Dependiendo de las necesidades de cada red, puede ponerse uno o más firewalls para establecer distintos perímetros de seguridad en torno a un
sistema. Es frecuente también que se necesite exponer algún servidor a internet (como es el caso de un servidor web, un servidor de correo, etc..), y
en esos casos obviamente en principio se debe aceptar cualquier conexión a ellos. Lo que se recomienda en esa situación es situar ese servidor en
lugar aparte de la red, el que denominamos DMZ o zona desmilitarizada. El firewall tiene entonces tres entradas:
Figura 2: esquema de firewall entre red local e internet con zona DMZ para servidores expuestos
En la zona desmilitarizada se pueden poner tantos servidores como se necesiten. Con esta arquitectura, permitimos que el servidor sea accesible
desde internet de tal forma que si es atacado y se gana acceso a él, la red local sigue protegida por el firewall. Esta estructura de DMZ puede hacerse
también con un doble firewall (aunque como se ve se puede usar un único dispositivo con al menos tres interfaces de red). Sería un esquema como
este:
Figura 3: esquema de firewall entre red local e internet con zona DMZ para servidores expuestos creado con doble firewall(perímetro)
Los firewalls se pueden usar en cualquier red. Es habitual tenerlos como protección de internet en las empresas, aunque ahí también suelen tener una
doble función: controlar los accesos externos hacia dentro y también los internos hacia el exterior; esto último se hace con el firewall o frecuentemente
con un proxy (que también utilizan reglas, aunque de más alto nivel).
También, en empresas de hosting con muchos servidores alojados lo normal es encontrarnos uno o más firewalls ya sea filtrando toda la instalación o
parte de ella:
Figura 4: esquema de firewall entre redes, en la que solo se filtra y no se hace NAT
Sea el tipo de firewall que sea, generalmente no tendrá mas que un conjunto de reglas en las que se examina el origen y destino de los paquetes del
protocolo tcp/ip. En cuanto a protocolos es probable que sean capaces de filtrar muchos tipos de ellos, no solo los tcp, también los udp, los icmp, los
gre y otros protocolos vinculados a vpns. Este podría ser (en pseudo-lenguaje) un el conjunto de reglas de un firewall del primer gráfico:
Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya que simplemente nos tenemos que preocupar de proteger aquellos
puertos o direcciones que sabemos que nos interesa; el resto no importa tanto y se deja pasar. Por ejemplo, si queremos proteger una máquina linux,
podemos hacer un netstat -ln (o netstat -an, o netstat -puta | grep LISTEN), saber que puertos están abiertos, poner reglas para proteger esos puertos
y ya está. ¿Para qué vamos a proteger un puerto que realmente nunca se va a abrir?
El único problema que podemos tener es que no controlemos que es lo que esta abierto, o que en un momento dado se instale un software nuevo que
abra un puerto determinado, o que no sepamos que determinados paquetes ICMP son peligrosos. Si la política por defecto es ACEPTAR y no se
protege explícitamente, nos la estamos jugando un poco.
En cambio, si la política por defecto es DENEGAR, a no ser que lo permitamos explícitamente, el firewall se convierte en un auténtico MURO
infranqueable. El problema es que es mucho más difícil preparar un firewall así, y hay que tener muy claro como funciona el sistema (sea iptables o el
que sea) y que es lo que se tiene que abrir sin caer en la tentación de empezar a meter reglas super-permisivas.
Esta configuración de firewall es la recomendada, aunque no es aconsejable usarla si no se domina mínimamente el sistema. Uno de los objetos
principales de este documento es mostrar la forma de crear este tipo de firewalls.
IMPORTANTE
El orden en el que se ponen las reglas de firewall es determinante. Normalmente cuando hay que decidir que se hace con un paquete se va
comparando con cada regla del firewall hasta que se encuentra una que le afecta (match), y se hace lo que dicte esta regla (aceptar o denegar);
después de eso NO SE MIRARÁN MÁS REGLAS para ese paquete. ¿Cuál es el peligro? Si ponemos reglas muy permisivas entre las primeras del
firewall, puede que las siguientes no se apliquen y no sirvan de nada.
2. Qué es iptables
IPtables es un sistema de firewall vinculado al kernel de linux que se ha extendido enormemente a partir del kernel 2.4 de este sistema operativo. Al
igual que el anterior sistema ipchains, un firewall de iptables no es como un servidor que lo iniciamos o detenemos o que se pueda caer por un error
de programación(esto es una pequeña mentira, ha tenido alguna vulnerabilidad que permite DoS, pero nunca tendrá tanto peligro como las
aplicaciones que escuchan en determinado puerto TCP): iptables esta integrado con el kernel, es parte del sistema operativo. ¿Cómo se pone en
marcha? Realmente lo que se hace es aplicar reglas. Para ellos se ejecuta el comando iptables, con el que añadimos, borramos, o creamos reglas.
Por ello un firewall de iptables no es sino un simple script de shell en el que se van ejecutando las reglas de firewall.
Notas: bueno, para los más geeks y tocapelotas. Vale, se puede implementar un script de inicio en /etc/rc.d/INIT.d (o /etc/INIT.d ) con el que hagamos
que iptables se "inicie o pare" como un servidor más. Lo podemos hacer nosotros o es probable que venga en la distribución (como en redhat por
ejemplo). También se pueden salvar las reglas aplicadas con el comando iptables-save en un fichero y gestionar ese fichero con una aplicación o
front-end desde la X o desde webmin.
Vale, tenemos una máquina linux con soporte para iptables, tiene reglas aplicadas y empiezan a llegar/salir/pasar paquetes. No nos liemos: olvidemos
cuantas tarjetas de red hay, que direcciones ip tiene la máquina y olvidemos si el paquete entra o sale. Las reglas de firewall están a nivel de kernel, y
al kernel lo que le llega es un paquete (digamos, un marrón ;) ) y tiene que decidir que hacer con él. El kernel lo que hace es, dependiendo si el
paquete es para la propia maquina o para otra maquina, consultar las reglas de firewall y decidir que hacer con el paquete según mande el firewall.
Este es el camino que seguiría un paquete en el kernel:
Figura 5: cuando un paquete u otra comunicación llega al kernel con iptables se sigue este camino
Como se ve en el gráfico, básicamente se mira si el paquete esta destinado a la propia maquina o si va a otra. Para los paquetes (o datagramas,
según el protocolo) que van a la propia maquina se aplican las reglas INPUT y OUTPUT, y para filtrar paquetes que van a otras redes o maquinas se
aplican simplemente reglas FORWARD.
INPUT,OUTPUT y FORWARD son los tres tipos de reglas de filtrado. Pero antes de aplicar esas reglas es posible aplicar reglas de NAT: estas se
usan para hacer redirecciones de puertos o cambios en las IPs de origen y destino. Veremos ejemplos.
E incluso antes de las reglas de NAT se pueden meter reglas de tipo MANGLE, destinadas a modificar los paquetes; son reglas poco conocidas y es
probable que no las usen.
Por tanto tenemos tres tipos de reglas en iptables:
- MANGLE
- NAT: reglas PREROUTING, POSTROUTING
- FILTER: reglas INPUT, OUTPUT, FORWARD.
Nota: se recomienda encarecidamente ir practicando estas reglas en alguna maquina linux disponible, y especialmente hacer uso de la herramienta
iptraf para depurar y comprobar el funcionamiento de iptables. Con iptraf podemos comprobar si las conexiones TCP/IP se llegan a establecer o no.
Una conexión tcp/ip empieza con el three-way-handshake:
- La maquina que desea conectarse a otra envia un paquete con flan SYN
- Si la otra maquina acepta, envia un SYN/ACK
- Entonces la máquina establece la conexión.
Si el firewall esta denegando la conexión, con iptraf veremos que la maquina origen solo manda paquetes con el flan S (de SYN), y que del otro lado
no sale nada. Saber usar iptraf nos ayudará mucho.
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para proteger la propia máquina
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
# Y el resto, lo cerramos
iptables -A INPUT -p tcp --dport 20:21 -j DROP
iptables -A INPUT -p tcp --dport 3306 -j DROP
iptables -A INPUT -p tcp --dport 22 -j DROP
iptables -A INPUT -p tcp --dport 10000 -j DROP
Nota para freaks y geeks: siiii, que ya lo se, se puede mejorar este script usando variables, se puede poner el comando con el path completo, pero
limítense a hacer copy-paste. Para el resto de mortales, no olvidarse de ponerle flags de ejecución: chmod +x [Link] o chmod 750 [Link]
En fin, ya se ve, un script de los más simple, con unas pocas reglas con las que cerramos puertos al público a los que no tienen porque tener acceso,
salvo el 80. Pero cualquiera con algo de ojo se habrá dado cuenta de que ni se filtra el UDP ni el ICMP. Apostaría cualquier cosa a que el sistema
tiene algún puerto udp abierto, y además peligroso como el SNMP. Como he dicho anteriormente, en este tipo de firewall es recordable hacer un
netstat para ver que puertos están en estado de escucha (abiertos), y salve que un rootkit nos haya modificado los binarios, netstat nos dará la
información precisa que necesitamos. Hay gente que se decanta por hacerse un nmap así mismos. Cuidado: dependiendo de cómo lo ejecutemos
quizá no nos muestre todos los puertos, ya que suele mirar los bien conocidos.
Imaginemos que hemos dado un repaso a nuestro sistema, y ahora si que tenemos mejor identificados los puertos tcp y udp abiertos. Pero por si
acaso nos curamos en salud y al final del script cerraremos el rango de puertos del 1 al 1024, los reservados tanto para tcp como udp.
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para proteger la propia máquina
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Establecemos politica por defecto
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
## Empezamos a filtrar
¿Sencillo, no? Ahora basta con hacer copy-paste de estas reglas y aplicarlas y ajustarlas en su sistema (quizás uses PostgreSQL). Si tiene miedo de
perder el control de una máquina remota, pruebe el script en una máquina local y asegúrese de que aplica lo que usted quiere. Funcionar va a
funcionar seguro.
Vale, queremos que nuestra maquina sea inexcrutable y que solo tenga abierto un puerto imprescindible para dar determinado servicio. Con DROP
por defecto se protege la maquina perfectamente, aunque hay que añadir algunas reglas para que la propia máquina sea capaz de salir a internet.
¿ Para qué? hombre, porque la maquina necesita actualizaciones, consultar DNS por udp, sacar correo etc.
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para proteger la propia máquina con DROP por defecto
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar? no! empezamos a abrir! porque ahora esta TODO denegado.
## Debemos decir de manera explicita qué es lo que queremos abrir
# Este es el servicio que DA la maquina a internet, por tanto todo paquete entrante se acepta para
# ese puerto y los salientes vinculados se aceptan.
/sbin/iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -m tcp --sport 80 -m state --state RELATED,ESTABLISHED -j ACCEPT
# Reglas necesarias para FTP pasivo y activo. Se permiten conexiones entrantes YA establecidas
/sbin/iptables -A INPUT -p tcp -m tcp --sport 20:21 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -m tcp --dport 20:21 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state
ESTABLISHED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -m tcp --dport 1024:65535 -m state --state NEW,RELATED,ESTABLISHED -j
ACCEPT
¿Qué es lo que hace falta? Obviamente, una regla que haga NAT hacia fuera (enmascaramiento en iptables), con lo que se haría dos veces NAT en
el firewall y en el router. Entre el router y el firewall lo normal es que haya una red privada ([Link] y [Link] por ejemplo), aunque
dependiendo de las necesidades puede que los dos tengan IP pública. El router se supone que hace un NAT completo hacia dentro (quizá salvo
puerto 23), o sea que desde el exterior no se llega al router si no que de forma transparente se "choca" contra el firewall. Lo normal en este tipo de
firewalls es poner la política por defecto de FORWARD en denegar (DROP), pero eso lo vemos más adelante.
Veamos como sería este firewall-gateway:
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para firewall entre red-local e internet
##
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN
# El localhost se deja (por ejemplo conexiones locales a mysql)
/sbin/iptables -A INPUT -i lo -j ACCEPT
Pero como somos muy malvados queremos que los empleados solamente puedan navegar por internet, denegando el acceso a Kazaa o edonkey.
Esta sería una configuración simple pero efectiva.
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para firewall entre red-local e internet
## con filtro para que solo se pueda navegar.
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN
# El localhost se deja (por ejemplo conexiones locales a mysql)
/sbin/iptables -A INPUT -i lo -j ACCEPT
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para firewall entre red-local e internet
## con servicios abiertos de puerto 25, 110, y 1723
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN
# El localhost se deja (por ejemplo conexiones locales a mysql)
iptables -A INPUT -i lo -j ACCEPT
# Abrimos el puerto 25, hay que configurar bien el relay del servidor SMTP
iptables -A INPUT -s [Link]/0 -p tcp --dport 25 -j ACCEPT
# Abrimos el pop3
iptables -A INPUT -s [Link]/0 -p tcp --dport 110 -j ACCEPT
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para firewall entre red-local e internet
## con servicios abiertos de puerto 25, 110, y 1723
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
## REDIRECCIONES
# Abrimos el puerto 25, hay que configurar bien el relay del servidor SMTP
iptables -A INPUT -s [Link]/0 -p tcp --dport 25 -j ACCEPT
# Abrimos el pop3
iptables -A INPUT -s [Link]/0 -p tcp --dport 110 -j ACCEPT
Bueno ya tenemos montada la red, pero conviene insistir en que esta última configuración, con las redirecciones y los servicios de correo funcionando
en el firewall es bastante insegura. ¿Qué ocurre si hackean el servidor IIS de la red local? Pues que el firewall no sirve de gran cosa, lo poco que
podría hacer una vez se ha entrado en la red local es evitar escaneos hacia el exterior desde la máquina atacada, aunque para ello el firewall debiera
tener una buena configuración con denegación por defecto. Si necesitamos ese servidor IIS, basta con comprar una tarjeta de red por 6€ o dolares y
crear una DMZ.
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para firewall entre red-local e internet con DMZ
##
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN
# Todo lo que venga por el exterior y vaya al puerto 80 lo redirigimos
# a una maquina interna
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to [Link]:80
Vamos a ver: si las máquinas de la DMZ tienen una ip pública hay que tener muchísimo cuidado de no permitir el FORWARD por defecto. Si en la
DMZ hay ip pública NO ES NECESARIO HACER REDIRECCIONES de puerto, sino que basta con rutar los paquetes para llegar hasta la DMZ. Este
tipo de necesidades surgen cuando por ejemplo tenemos dos máquinas con servidor web (un apache y un IIS); ¿A cuál de las dos le redirigimos el
puerto 80? No hay manera de saberlo (No, con servidores virtuales tampoco, piénsalo), por eso se deben asignar IPs públicas o en su defecto usar
puertos distintos.
Por tanto hay que proteger convenientemente toda la DMZ. Tampoco haría falta enmascarar la salida hacia el exterior de la DMZ, si tiene una ip
pública ya tiene una pata puesta en internet; obviamente hay que decirle al router como llegar hasta esa ip pública. Así podría ser esta red:
Figura 8: esquema de firewall entre red local e internet con zona DMZ para servidores expuestos usando IPs públicas
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN
ATENCIÓN
Merece la pena pararse a explicar esta parte del firewall:
¿Por qué se explicita el puerto de origen/destino 1024:65535 en la primera y segunda regla? Imaginemos que un hacker logra acceso a la máquina de
la DMZ. Si no especificamos el puerto de destino en esas dos reglas, el hacker puede abrir CUALQUIER puerto de la LAN siempre que pueda
establecer como puerto origen suyo el tcp/3389, cosa fácil para un hacker que sepa algo de C o que tenga el programa pertinente a mano. De todas
formas el hacker tendría que saber que existe ese tipo de reglas, si es listo probara con puertos de gestión o con puertos netbios. El problema es que
se deja un vínculo con la LAN bien para administrarlo remotamente o para establecer relaciones de confianza y ahí es donde reside el peligro.
En las conexiones "legales" no se usa como puerto origen nada por debajo del 1024; cuando alguien se conecta a otro puerto en su extremo abre un
puerto por encima del 1024. Especificándolo en la regla de firewall protegeremos un poco mejor la LAN, aunque los puertos por encima de 1024
estarán en peligro.
Supongamos que entre los routers ya se ha establecido un tunel (con Ciscos se haria creando un interfaz Tunnel), y que si el firewall nos deja
podríamos llegar de la central a las delegaciones y viceversa usando las IPs privadas. Vaya que se puede hacer un ping desde la central a
192.168.30.x y nos responde. Para ello es imprescindible que el router de la central tenga una ruta metida para llegar a [Link]/24 y por
supuesto cada una ruta para cada delegación. Antes de meterse en el firewall hay que asegurar la visibilidad entre los routers y poder llegar a sus IPs
privadas haciendo ping.
Supongamos también que en la central esta el servidor de correo que lógicamente debe tener el puerto 25 accesible desde internet, y debe ser
accesible desde las delegaciones para puerto 25, 110 (pop3) o 143(imap). La salida a internet (web, ftp, etc..) cada uno la hace por su lado.
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para firewall entre red-local e internet con DMZ
## y delegaciones. Las delegaciones deben tener acceso al correo de la DMZ
##
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
# Para que desde la red local se salga hacia fuera hay que ENMASCARAR
# pero que pasa con las delegaciones tambien estan fuera Y NO HAY QUE
# ENMASCARAR, debemos meter una regla FORWARD explicita para que no enmascare
# porque si no una petición de la LAN a otra delegacion no se meteria
# en el tunel.
iptables -A FORWARD -s [Link]/24 -d [Link]/24 -j ACCEPT
iptables -A FORWARD -s [Link]/24 -d [Link]/24 -j ACCEPT
Se han remarcado en negrita las reglas FORWARD entre IPs privadas de delegaciones, ya que sin esas reglas y con el enmascaramiento de por
medio no se podría acceder a las delegaciones. Cabe resaltar que entre delegaciones no hay visibilidad total, solamente la central vería a todas las
demás, y las delegaciones solamente la central.
La delegaciones accederían al servidor de correo con una redirección, o sea que ellos se configurarían el servidor de correo como [Link],
mientras que desde la LAN se accedería directamente. Se puede hacer de distintas maneras.
Lo interesante sería poner ese firewall con DROP por defecto, se tratará de mostrar esa configuración al final.
En el firewall debemos indicar una serie de reglas para proteger los equipos que están al otro lado de este dispositivo, todos ellos de la red
[Link]/24
Cada uno de ellos da un servicio determinado, y puede estar gestionado desde distintas IPs, lo que significa que habrá que dar acceso a
determinados puertos de gestión (22, 3389, etc..).
Este podría ser el aspecto del script del firewall:
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para firewall entre redes.
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN
# El resto, cerrar
iptables -A FORWARD -d [Link] -j DROP
# El resto, cerrar
iptables -A FORWARD -d [Link] -j DROP
# El resto, cerrar
iptables -A FORWARD -d [Link] -j DROP
# El resto, cerrar
iptables -A FORWARD -d [Link] -j DROP
# El resto, cerrar
iptables -A FORWARD -d [Link] -j DROP
# El resto, cerrar
iptables -A FORWARD -d [Link] -j DROP
Con esta firewall y sobretodo gracias a las reglas de DROP que metemos tras especificar lo que dejamos abiertos, protegeremos de manera eficaz
todos lo puertos abiertos de las máquinas.
En el ejemplo de la DMZ ya se presentaba esta situación en las reglas forward de una a otra red. Para ilustrar el DROP por defecto, vamos a mostrar
la configuración del ejemplo anterior de firewall entre redes pero con política por defecto DROP.
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para firewall entre redes con DROP por defecto
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
## Nota: eth0 es el interfaz conectado al router y eth1 a la LAN
# El resto, cerrar
iptables -A FORWARD -d [Link] -j DROP
Ya esta, hemos levantado un verdadero muro entre internet y el conjunto de servidores que esta
Tras el firewall. No se puede ni hacer un ping a las máquinas, salvo que se haya dado acceso total a una ip. Si quisieramos dar acceso al ping,
pondríamos algo así:
Es más llevadero aplicar el DROP por defecto cuando el firewall es para la propia máquina. El primer escenario de esta manual trataba sobre este
caso, ahora lo revisamos con la política por defecto drop.
#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para proteger la propia máquina
## con política por defecto DROP
## Pello Xabier Altadill Izura
## [Link] - pello@[Link]
## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
## Empezamos a filtrar
NMAP. La herramienta para escanear puertos por excelencia, rechace imitaciones. Es una herramienta de consola rápida, efectiva y con multitud de
opciones. Podemos usarla desde máquinas ajenas a nuestra red para comprobar si realmente el firewall esta filtrando correctamente y en cierta
manera para hacernos una idea de que "visión" pueden tener los hackers de nuestro sistema.
SHELL. En el propio script del firewall podemos añadir algunas opciones para descubrir fallos de sintaxis en las reglas. Claro, imaginemos que
tenemos un firewall de 40 lineas y una de ellas falla cuando ejecutamos el script. ¿Cuál es? Es probable que el mensaje de error no aclare lo
suficiente, por eso se puede añadir algo así al final de cada regla:
...
iptables -A INPUT -s [Link] -j ACCEPT && echo " regla-21 ok"
iptables -A INPUT -s [Link] -j ACCEPT && echo " regla-22 ok"
...