# rm-rf.es | Administración de sistemas

Bitácora personal de un SysAdmin Gnu/Linux, Windows, BSD...

Instalar y configurar TigerVNC server y utilizarlo con un túnel SSH

Instalar y configurar el servidor VNC TigerVNC es realmente sencillo. Lo que muchas veces no nos paramos a pensar es que el protocolo en sí no es seguro por lo que el tráfico no está cifrado al conectar al escritorio remoto. Vamos a ver como solucionarlo.

Lo primero es instalar TigerVNC con yum (RHEL, CentOS, Scifi linux, etc). En este caso instalo también el cliente para hacer las pruebas en local:

# yum install tigervnc-server tigervnc

Una vez instalado debemos saber que la configuración se realiza en el fichero /etc/sysconfig/vncservers. Los comentarios del fichero nos indican claramente como configurarlo, también hice un artículo hace un tiempo, echadle un vistazo: Instalar y configurar vnc-server en CentOS/RHEL/Fedora

He creado un usuario “alex” al que únicamente se le permite el acceso local por seguridad:

# The VNCSERVERS variable is a list of display:user pairs.
#
# Uncomment the lines below to start a VNC server on display :2
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see this URL:
# http://kbase.redhat.com/faq/docs/DOC-7028

# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.

# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.

# VNCSERVERS="2:myusername"
# VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"
VNCSERVERS="2:ale
VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"

Creamos el password VNC para el usuario del siguiente modo:

# su alex -c "vncpasswd"
Password: XXXX
Verify: XXXX

Arrancamos el servidor VNC para el usuario alex:

[alex@localhost /]$ vncserver
xauth:  creating new authority file /home/alex/.Xauthority

New 'rhcsa:1 (alex)' desktop is rhcsa:1

Starting applications specified in /home/alex/.vnc/xstartup
Log file is /home/alex/.vnc/rhcsa:1.log

Llegados a este punto podemos acceder sin problemas en local al escritorio remoto con el comando vncviewer:

$ vncviewer localhost:1

Desde fuera no, por motivos de seguridad. Para ello vamos a crear un tunel SSH de modo que las conexiones VNC con el exterior sí que estén cifradas. Vamos a usar por ejemplo el puerto 6922 para el tunel. El servidor VNC se encuentra en la IP 10.0.0.100, desde el equipo remoto con el que queremos conectar al servidor creamos el tunel:

$ ssh alex@10.0.0.100 -L 6922:10.0.0.100:5901 -N

Y ya está, podemos acceder remotamente al servidor VNC de forma segura con el nuevo puerto:

$ vncviewer localhost:6922

Si queréis usar el estandar podéis mantener los puertos de VNC:

$ ssh alex@10.0.0.100 -L 5901:10.0.0.100:5901 -N
$ vncviewer localhost:1

Encriptar un filesystem con LUKS y cryptsetup

luksLUKS (Linux Unified Key Setup) es un cifrado que trabaja a nivel de bloque de fichero sobre la partición o volumen lógico y que permite encriptar sistemas de ficheros, para los cuales es necesaria una passphrase o keyfile para su desencriptado. Encriptar un sistema de ficheros es especialmente útil cuando trabajamos con información sensible en dispositivos físicos portatiles, como por ejemplo pendrives, ordenadores portátiles, etc.

Vamos a encriptar un sistema de ficheros de un disco secundario sobre un sistema RHEL 6 (CentOS). Para encriptar particiones de sistema (filesystem / o /home por ejemplo) es preferible hacerlo en el momento de la instalación, ya que resulta más sencillo y evitamos la pérdida de datos posterior.

Preparación del sistema

Para la encriptación con LUKS necesitamos tener cargado el módulo de kernel dm_crypt así como el paquete cryptsetup-luks:

# lsmod | grep dm_cry
dm_crypt               10848  0
dm_mod                 63859  5 dm_crypt,dm_mirror,dm_log

Si no está cargado en vuestro sistema hacedlo con modprobe:

# modprobe dm_crypt

Acordaos de configurarlo (por defecto es probable que con modprobe sea suficiente) para que sea persistente a reinicios.

Instalamos cryptsetup-luks en caso de que no esté instalado:

# yum install cryptsetup-luks
# rpm -qa | grep cryptse
cryptsetup-luks-libs-1.1.2-2.el6.i686
cryptsetup-luks-1.1.2-2.el6.i686

Preparación del sistema de ficheros/partición

Vamos a asumir que tenemos ya el sistema de ficheros creado. Podéis revisar los siguientes artículos si tenéis dudas, tanto de crear una partición estándar como un LVM:

Algo recomendable pero que suele llevar bastante tiempo es, lo primero de todo, llenar de datos aleatorios la partición a encriptar. Repito que puede llevar bastante tiempo dependiendo del tamaño de la partición. Si sólo estáis haciendo pruebas no es necesario que lo hagáis (sustituid /dev/volgroup1/logvol1 por vuestra partición o volumen):

# dd if=/dev/urandom of=/dev/volgroup1/logvol1

Encriptación del filesystem

Llegados a este punto ya tenemos el sistema de ficheros preparado para su encriptación. Haremos uso del comando cryptsetup. Lo primero que haremos es asignar la passphrase. Cuanto más compleja sea mejor, igual que cualquier password:

Nota: se eliminará cualquier dato del filesystem

# cryptsetup luksFormat /dev/volgroup1/logvol1

WARNING!
========
This will overwrite data on /dev/volgroup1/logvol1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: *********
Verify passphrase: *********

Al tratarse de un filesystem encriptado debemos mapearlo ya que no se puede leer directamente. Esa unidad mapeada será la que montaremos y utilicemos como un filesystem estándar. Vamos a sacar el UUID del sistema de ficheros encriptado para utilizarlo si queremos en lugar de la etiqueta (LABEL):

# cryptsetup luksUUID /dev/volgroup1/logvol1
79da86ea-70f2-4a80-82cb-6c614a885a37

Mapeamos el sistema de ficheros contra encrypted-fs:

# cryptsetup luksOpen /dev/volgroup1/logvol1 encrypted-fs
Enter passphrase for /dev/volgroup1/logvol1:

Y ya tenemos el volumen listo para particionar en /dev/mapper/encrypted-fs. Le damos formato y lo montamos:

# mkfs.ext4 /dev/mapper/encrypted-fs

Finalmente, lo añadimos a fstab para el arranque al inicio del sistema. Podemos hacerlo con el UUID o con la etiqueta (LABEL) del fs:

# tune2fs -l /dev/mapper/encrypted-fs | grep UUID
Filesystem UUID:          9578a03e-949b-4fe8-a16c-57024b01fe89

Lo añadimos a /etc/fstab:

UUID=9578a03e-949b-4fe8-a16c-57024b01fe89 /encrypted-fs ext4    defaults 0 0

Y añadimos también la siguiente entrada a /etc/crypttab para que solicite la passphrase en el arranque del sistema:

encrypted-fs /dev/volgroup1/logvol1 none

Si reiniciáis, durante el arranque se os solicitará la passphrase del volumen:

logvol1 is password protected: *************

10 trucos para securizar PHP

php 5.3.6

En esta entrada vamos a ver unos cuantos puntos que nos servirán para securizar PHP en nuestro servidor web. Nos centramos en la configuración propia de PHP, hay que tener en cuenta que la securización de la capa aplicación es tanto o más importante que la de la configuración del servidor. Hay que tener siempre actualizados a la última versión estable y con los parches de seguridad correctamente aplicados cualquier cms o script de terceros tipo WordPress, Joomla, Oscommerce, etc.

Ocultar la versión de PHP

En su día hice un artículo completo sobre esto, podéis verlo aquí (ocultar la versión de PHP). Básicamente evitamos que con un simple telnet puedan averiguar la versión de PHP que hay corriendo en el servidor:

# telnet servidor 80

Connected to xxx.com (xx.xx.xx.xx).
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 13 Aug 2010 14:18:09 GMT
Server: Apache/1.3.26 (Unix) mod_gzip/1.3.26.1a PHP/5.3.3
Last-Modified: Fri, 12 Feb 2010 12:22:56 GMT
ETag: "44967c-6f-53ca4800"
Accept-Ranges: bytes
Content-Length: 111
Connection: close
Content-Type: text/html

Connection closed by foreign host.

Para evitar esto cambiamos a off la siguiente variable en el fichero de configuración general php.ini:

expose_php Off

Deshabilitar funciones peligrosas

También hice un artículo hace un tiempo: PHP: Deshabilitar funciones peligrosas. Existen funciones que en servidores con aplicaciones estándar rara vez se usan, pero que por contra pueden generar graves problemas de seguridad si el atacante consigue utilizarlas. Es preferible desactivar el mayor número posible y en caso de que una de ellas sea necesario valorar su activación o proponer alternativas.

Las funciones a deshabilitar se añaden en la directiva “disable_functions” en el fichero php.ini. Aquí tenéis un ejemplo con funciones peligrosas que conviene desactivar:

disable_functions = “apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode”

O un ejemplo más conservador:

disable_functions ="system,passthru,escapeshellarg,escapeshellcmd,proc_close,proc_open,ini_alter,popen,show_source,pcntl_exec"

deshabilitar session ID en URL

Si queremos que las URL’s de nuestros sitios PHP no muestren los ID de sesiones:

http://ejemplo.com/?PHPSESSID=4kgj577sgabvnmhjgkdiuy1956if6ska

Modificamos la directiva siguiente en el fichero php.ini:

session.use_trans_sid = off

Deshabilitar register_globals

Pese a ser una directiva antigua y que se encuentra en periodo de extinción todavía quedan desarrolladores/programadores que la utilizan. Esta función permite al atacante manipular cualquier variable global definida en la programación. Por defecto está deshabilitada en las versiones actuales de PHP, pero conviene revisarlo por si en algún momento se ha activado:

register_globals = Off

Desactivar acceso a URL remotas en funciones de manejo de ficheros

Funciones como include, fopen o file_get_contents permiten, además de hacer llamadas a ficheros locales, llamar a ficheros vía URL, esto puede provocar graves errores de seguridad invocando a scripts maliciosos que se encuentran fuera de nuestro servidor y su ejecución remota.

Para deshabilitarlo modificamos la directiva allow_url_fopen a Off en el php.ini:

allow_url_fopen = Off

Evitar el acceso a la información de PHP

Como ya sabéis con un simple script como el siguiente podemos ver vía URL toda la información de PHP, su compilación, sus módulos activados, versión, directivas de configuración, etc.

<? phpinfo() ?>

Si queremos desactivarlo, únicamente hay que modificar a Off la siguiente directiva en el fichero php.ini:

expose_php = Off

Si en algún momento necesitáis conocer alguna información, siempre podéis averiguarla desde línea de comandos: información sobre PHP desde línea de comandos

Safe Mode

safe_mode = On

Si bien por defecto safe_mode On puede significar una restricción demasiado fuerte en determinados entornos, puede ayudar mucho a incrementar la seguridad de nuestro servidor. Activar safe_mode implica que los scripts PHP únicamente pueden acceder a los ficheros que tienen como propietario el mismo que ellos. De este modo evitamos por ejemplo que tengan acceso de lectura a ficheros de sistema como /etc/passwd entre otros.

Efectivamente, esto puede ser un problema en el momento que necesitamos acceder a información generada por otros usuarios en el sistema (ficheros de otras aplicaciones. La solución es la siguiente:

safe_mode = Off
safe_mode_gid = On

Activamos safe_mode_gid en lugar de safe_mode, de modo que en lugar de revisar el usuario se revisa el grupo. Independientemente del UID del fichero, necesitaremos que estar dentro del grupo para poder acceder al ficheros. El grupo del script PHP deberá ser el mismo que el del fichero a acceder.

Otro punto a tener en cuenta con safe_mode es que no podremos ejecutar binarios. Únicamente aquellos que ubiquemos en el directorio especificado en la configuración:

safe_mode_exec_dir = /directorio

Esto se solaparía con las funciones deshabilitadas anteriormente, como por ejemplo system() o exec().

open_basedir

open_basedir = /directorio

La directiva open_basedir permite configurar que PHP pueda acceder únicamente a los ficheros de un único directorio (y sus subdirectorios). Es una buena forma de enjaular PHP si realmente sólo necesitamos que acceda a un determinado directorio.

Visualización y registro de errores

display_errors = Off
log_errors = On
error_log = /ruta/fichero/log

Con estas tres directivas, evitamos que cualquier error o warning se muestre por pantalla y hacemos que se registren directamente en un log especificado. De este modo podemos evitar que se muestre información sensible por pantalla. También podéis hacer uso de la directiva error_reporting si queréis mostrar por pantalla los errores. Con ella podéis especificar que se muestren únicamente los warning, los notice o lo que queráis.

SQL Injection

En su día se utilizaba magic_quotes para limpiar los datos de entrada de un script PHP, pero es una directiva obsoleta a partir de PHP 5.3 así que no merece la pena hablar de ella. En su defecto, si usáis servidor web Apache, os recomiendo encarecidamente configurar mod_security y habilitar sus reglas que permiten detectar y parar una gran cantidad de ataques de este tipo, y sino, puedes crear tus propias reglas.

Como último apunte, conviene siempre si es posible mantener una versión estable de PHP, libre de bugs y fallos de seguridad. Seguro además que una vez aplicados estos trucos os toca lidiar con los programadores. Se quejarán de algo seguro ;)

Seguridad Unix con TCP Wrappers

Seguridad Unix TCP WrappersEl otro día hablábamos sobre securizar un sistema Linux con iptables y en otro artículo encontrábamos un firewall basado en FreeBSD llamado pfSense. Hoy vamos a ver cómo securizar un sistema Unix (Linux, BSD…) a través de TCP Wrappers,  un buen complemento de iptables. La wikipedia lo define como:

TCP Wrapper (“Envoltorio de TCP”) es un sistema de red ACL que trabaja en terminales y que se usa para filtrar el acceso de red a servicios de protocolos de Internet que corren en sistemas operativos (tipo UNIX), como Linux o BSD. Permite que las direcciones IP, los nombres de terminales y/o respuestas de consultas ident de las terminales o subredes sean usadas como tokens sobre los cuales filtrar para propósitos de control de acceso.

Bien, partimos de la base de que tenemos dos ficheros configurables, /etc/hosts.deny y /etc/hosts.allow. En ellos podemos especificar que IPs, hostnames o redes pueden acceder a determinados servicios del sistema. TCP Wrappers suele venir instalado por defecto en la mayoría de sistemas operativos Unix.

La sintaxis básica de estos ficheros es la siguiente:

daemon : dirección : acción
ó
daemon : dirección

Daemon es el demonio/servicio a filtrar, dirección es la dirección, host o subred y acción si denegamos o aceptamos el acceso. Para saber si un servicio puede ser configurado para filtrado vía TCP Wrappers hay que saber si su binario está enlazado con la biblioteca libwrap.a. Para ello:

# ldd /usr/sbin/sshd | grep libwrap.so
	libwrap.so.0 => /lib/libwrap.so.0 (0x001ce000)

Si la salida es NULL el demonio no está compilado con TCP Wrappers y no funcionará. Si devuelve algo como lo anterior sí que lo está. Vamos a ver entonces unos cuantos ejemplos:

Permitir acceso ssh únicamente a unas IPs

/etc/hosts.allow Permitimos acceso a las IPs 192.168.0.111, 192.168.0.112, 192.168.0.113.

sshd: 192.168.0.111 192.168.0.112 192.168.0.113

/etc/hosts.deny Denegamos al resto.

sshd: ALL

Bloquear todo excepto lo declarado en /etc/hosts.allow

/etc/hosts.allow

sshd: 192.168.0.111 192.168.0.112 192.168.0.113

/etc/hosts.deny Denegamos acceso al resto de servicios excepto SSH a las Ips indicadas. La máquina quedará blindada excepto el acceso SSH a las Ips permitidas:

ALL: ALL

Permitir también el uso de sendmail a una subred y unos hosts concretos

/etc/hosts.allow Permitimos acceso a las IPs 192.168.0.111, 192.168.0.112, 192.168.0.113.

sshd: 192.168.0.111 192.168.0.112 192.168.0.113
sendmail: 10.0.0.0/24 test.com prueba.com

/etc/hosts.deny

ALL: ALL

Permitir todo y bloquear el acceso total a una única IP

/etc/hosts.allow

ALL: ALL

/etc/hosts.deny

ALL: 192.168.0.115

Filtrar y ejecutar un comando tras un intento de acceso

/etc/hosts.allow

ALL: ALL

/etc/hosts.deny

ALL: 192,168.0.115 \
   : spawn (/bin/echo %a desde %h intento acceder a %d >> \
    /var/log/connections.log) \
   : deny

Aquí ya depende todo si queremos aplicar una política restrictiva desde el principio, bloquear todo y a partir de ahí comenzar a abrir servicios a determinadas Ips, rangos o hosts o si por el contrario queremos dejar todo abierto y cerrar servicios a determinadas Ips,etc.

Si os resulta interesante, disponéis de más información en el handbook de freebsd o en Linux about.com. Esta ha sido una mera introducción a TCP Wrappers

Repositorio CentOS-5.6 Continuous Release ( CR ) disponible

CentOSCentOS ha publicado un nuevo repositorio a través de mirror.centos.org. CentOS-5.6 Continuous Release ( CR ) contiene rpms que serán incluidas en la próxima versión de la rama 5.X de CentOS, pero que debido a que son actualizaciones de seguridad y soluciones a bugs conocidos es recomendable instalarlas sin tener que esperar a que salgan a la luz con la nueva versión 5.7, que saldrá aproximadamente en una semana.

Se recomienda encarecidamente activar estos repositorios y actualizar el sistema. Únicamente hay que instalar los siguientes repos y actualizar el sistema. Como ya sabéis se añadirá el nuevo repositorio CentOS-CR.repo en la ruta /etc/yum.repos.d/. Podéis descargar los rpm a continuación:

i386:

http://mirror.centos.org/centos/5.6/cr/i386/RPMS/centos-release-cr-5-6.el5.centos.1.i386.rpm

md5: 67bbeb40cb77a91379847074667d2956
sha256: 50cd9f3d35b391a9009a9caae80182dcfccfa5abaf4ff4ef5f4d880bcf26b04c

x86_64:

http://mirror.centos.org/centos/5.6/cr/x86_64/RPMS/centos-release-cr-5-6.el5.centos.1.x86_64.rpm

md5: c447f54818a657a9dfd7fdd28a28cfcc
sha256: dab390a0fca17612e438b215fc90448ebcef982e96e25cbea8426f00edc8b7a5

pfSense: Firewall Open Source basado en FreeBSD

Estos días hemos estado probando a nivel local la distribución pfSense, firewall Open Source basado en FreeBSD y que en su día comenzó siendo un fork del proyecto m0n0wall.

La principal función de pfSense es la de ser usado a modo de firewall o router, pero si vamos más allá descubrimos que cumple a la perfección con otras funciones como la de conectividad VPN (IPsec, OpenVPN, PPTP), balanceo de carga, NAT, tabla de estado, posible configuración de failover entre dos nodos físicos pfSense, Dynamic DNS, informacíon vía RRD a tiempo real con gráficas, servidor DHCP y Relay, etc.

Si no disponéis del presupuesto necesario para la adquisición de un buen firewall comercial, dadle una oportunidad a esta distribución. Los requerimientos mínimos son 128 MB de RAM y una de 100 MHz Pentium.

Toda la información sobre pfSense en el sitio web oficial.

pfSense Firewall

Introducción a iptables

firewallMuchos sysadmins estamos acostumbrados a utilizar Frontends del firewall iptables para facilitarnos el trabajo, como por ejemplo APF Firewall. Yo soy uno de ellos. Independientemente de esto, conviene saber como funciona iptables de forma interna para evitar la dependencia de este tipo de aplicaciones de terceros para configurar de forma correcta el firewall del kernel Linux. Vamos a ver algunos puntos que nos ayudarán a comprender su funcionamiento.

Listar reglas, Chain y políticas de Iptables

Con estos comandos podemos ver de un vistazo la configuración establecida en el firewall.

Ver el listado de reglas activas en el firewall:

# iptables -L

Borrar todas las reglas establecidas en el firewall:

# iptables -F

Pone a 0 los contadores de bytes y paquetes:

# iptables -Z

Iptables tiene 3 Chain (cadenas) sobre las cuales construir las reglas, establecer políticas comunes, etc: INPUT, FORWARD y OUTPUT. La política por defecto para ellas es de aceptar todo:

# iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

También podemos listar únicamente las reglas y política de una Chain concreta:

# iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Si no fuera suficiente estas tres Chain podemos crear nuevas o eliminar podemos hacerlo, así como renombrar las ya existentes:

Crear una nueva Chain llamada TEST:

# iptables -N TEST

Eliminarla:

# iptables -X TEST

Renombrarla a TEST2:

# iptables -E TEST TEST2

Establecer políticas por defecto

Para poder empezar a configurar Iptables debemos partir de una base, una política por defecto que aceptará o denegará el tráfico para cada una de las Chain vistas anteriormente (INPUT OUTPUT o FORWARD). Si quisierais blindar el sistema podríais partir de una base ‘paranoica‘ denegando todo:

# iptables -P INPUT DENY
# iptables -P OUTPUT DENY
# iptables -P FORWARD DENY

En el momento que lo hicierais perderíais toda conectividad en la máquina, así que nosotros vamos a comenzar aceptando todo y aplicando pequeñas restricciones en nuestra máquina, una vez configurado todo es cuando podríamos aplicar la configuración restrictiva de arriba:

# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -P FORWARD ACCEPT

Veréis que estamos añadiendo las reglas directamente desde la línea de comandos, lo óptimo es añadirlas dentro de un script para así ejecutarlo todo de forma automática cuando arrancamos el equipo, lo veremos después.

Filtrado de puertos, IPs, rangos…

Una vez establecida la política por defecto, podemos comenzar a definir nuestras reglas específicas para cada cadena (Chain). La estructura del comando usado para filtrado de puertos, ips, etc es la siguiente:

Filtrado/apertura de un puerto/rango de puertos

# iptables -A <INPUT|OUTPUT|FORWARDING> -p <tcp|udp> --dport <PUERTO_DESTINO> -j <ACCEPT|DROP>

Así por ejemplo si quisieramos cerrar el puerto de entrada tcp 21 (FTP) para toda la máquina:

# iptables -A INPUT -p tcp --dport 21 -j DROP

Permitir el tráfico de entrada por el puerto 80, necesario por ejemplo si el equipo es un servidor web:

# iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Para bloquear un rango de puertos, simplemente especificamos el primer y último puerto del rango, en este ejemplo bloqueamos la salida tcp de los puertos 2000 al 3000:

# iptables -A OUTPUT -p tcp --dport 2000:3000 -j DROP

Permitir/denegar puertos a determinadas IPs, interfaces de red o CIDR

# iptables -A <INPUT|OUTPUT|FORWARDING> -s <IP|RANGO> -p <tcp|udp> --dport <PUERTO_DESTINO> -j <ACCEPT|DROP>

Es probable que necesitemos configurar políticas de aceptación o denegación de puertos a determinadas IPs, o incluso el acceso/denegación total a las mismas. La IP la especificaremos con el parámetro -s. Vamos a ver unos ejemplos:

Aceptar todo el tráfico de entrada de una IP:

# iptables -A INPUT -s 192.168.1.128 -j ACCEPT

Denegar todo el tráfico de entrada a una IP:

# iptables -A INPUT -s 192.168.1.128 -j DROP

Aceptar a una IP el acceso a un determinado puerto:

# iptables -A INPUT -s 192.168.1.128  -p tcp --dport 25 -j ACCEPT

Para el tema de rangos, podemos usar la notación CIDR. Vamos a aceptar todo el tráfico en la red local:

# iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT

También podemos especificar reglas restringiendo según interfaces de red en lugar de IPs o rangos. Esto lo hacemos mediante el parámetro -i:

# iptables -A INPUT -i eth0 -j ACCEPT

Nuestro primer script de Iptables

Antes de hacer el script conviene saber qué puertos tenemos abiertos en la máquina para configurarlos previamente y evitar problemas. Podemos usar nmap o netstat para averiguarlo. Un ejemplo de un típico servidor con servicios web, MySQL, correo, etc podría ser el siguiente:

# nmap -sTU localhost

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2011-08-27 21:14 CEST
Interesting ports on localhost (127.0.0.1):
Not shown: 3152 closed ports
PORT     STATE         SERVICE
1/tcp    open          tcpmux
21/tcp   open          ftp
25/tcp   open          smtp
80/tcp   open          http
110/tcp  open          pop3
143/tcp  open          imap
443/tcp  open          https
465/tcp  open          smtps
783/tcp  open          spamassassin
993/tcp  open          imaps
995/tcp  open          pop3s
3306/tcp open          mysql
161/udp  open|filtered snmp

La salida de nmap nos ofrece una guía clara sobre los puertos a abrir. A partir de aquí es cuestión de construir nuestro script con las reglas correspondientes, estableciendo primero las políticas generales y luego definiendo el filtrado/apertura concreta de puertos, si queremos restringir puertos a determinadas IPs, bloquear el acceso a rangos CIDR, etc.

#!/bin/sh
# Primero limpiamos cualquier regla haciendo un flush
# tambien reseteamos contadores (-Z) y las Chain personalizadas
# que se hayan creado (-X)
iptables -F
iptables -X
iptables -Z

# Politicas por defecto (ACEPTAR TODO)
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

# Cerramos ssh excepto para nuestra red privada
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

# Tenemos un servidor MySQL pero únicamente para servir en local
iptables -A INPUT -p tcp --dport 3306 -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP

# Aceptamos todas las conexiones FTP, HTTP y HTTPS
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Servicios de correo
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 143 -j ACCEPT
iptables -A INPUT -p tcp --dport 110 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 465 -j ACCEPT
iptables -A INPUT -p tcp --dport 993 -j ACCEPT
iptables -A INPUT -p tcp --dport 995 -j ACCEPT

# SNMP lo vamos a permitir para nuestra red local
iptables -A INPUT -p udp --dport 161 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 161 -j DROP

# Una vez que hayamos abierto todo lo necesario, podemos cerrar
# el resto o un rango especifico de puertos conocidos...
iptables -A INPUT -p tcp --dport 1:1024 -j DROP
iptables -A INPUT -p udp --dport 1:1024 -j DROP

Este es un ejemplo sencillo (¡ojo, no verificado!) que muestra las posibilidades más básicas de iptables, hay que tener en cuenta que no hemos tratado más que TCP y UDP sobre rasgos generales, no tratamos ICMP ni configuraciones detalladas. Para ello, os emplazo y recomiendo la guía que encontraréis el TLDP (The Linux Documentation Project) o a futuros artículos que complemetarán a este y enlazaré conforme vayamos avanzando.

Consejos para reducir el SPAM en tu correo

SPAMEl Spam es uno de los mayores quebraderos de cabeza tanto para los administradores de sistemas como para el usuario final de Internet, y parece q lo seguira siendo durante un tiempo… Centrándonos en el usuario final, gracias a unos simples consejos podemos reducir el correo basura en nuestras cuentas de correo en un porcentaje muy alto.

  • Registros en sitios web: La mayor parte de los internautas se registran continuamente en foros, blogs, tiendas y todo tipo de webs online, el resultado suele ser que nuestra dirección de correo electrónico queda almacenada en decenas de bases de datos, para posteriormente (en gran parte de los casos) ser usadas para envío de boletines y/o publicidad.Es recomendable en estos casos tener una dirección de correo electrónico alternativa, y usarla para todos estos registros, de este modo nuestro e-mail habitual quedará libre de este tipo de correos.
  • Buzones globales: Este tipo de buzones, también conocido como cuentas atrapalo todo o catch all son uno de los mayores focos de spam. Básicamente, estas cuentas recogen los correos de todas aquellas cuentas de nuestro dominio que reciben emails y no existen.Solución: No utilizar nunca configuraciones de buzón global en nuestras cuentas de correo.
  • Filtros en clientes de correo: La mayor parte de clientes de correo (Outlook, Thunderbird…) cuentan con filtros internos para detectar correos basura. Conviene activarlos
  • Sentido común: Consejo que se suele presuponer y es desgraciadamente poco habitual. Controla a quién das tu dirección e-mail, evita publicarla en foros, sitios web, mantén limpio de virus, troyanos, spyware y demás tu ordenador…

Como podéis observar, son consejos muy básicos, pero eficaces. ¿Algún consejo para añadir?