RPM

De primeras podemos descartar los ficheros de configuración, ya que lo más normal es que su contenido cambie, aunque todavía podríamos revisar su configuración de permisos, propietario, etc.

Si queremos hacer una revisión de todos los ficheros del sistema, algo que lógicamente puede tardar bastante tiempo, utilizaremos el siguiente comando. Hay que tener en cuenta que en caso de no haber salida todo es correcto:

# rpm -Va

Si queremos hacer la revisión de un único paquete lo indicamos y quitamos el parámetro “a”:

# rpm -V telnet

Y si quisiéramos revisar un único fichero:

# rpm --verify --file /usr/bin/chcon

¿Y qué sucede si se detecta algún problema? Vamos a verlo. Voy a hacer un backup del binario /usr/sbin/apachectl y a reescribirlo:

# mv /usr/sbin/apachectl /usr/sbin/apachectl.BAK
# touch /usr/sbin/apachectl
# rpm -V --file /usr/sbin/apachectl
S.5....T.  c /etc/httpd/conf/httpd.conf
S.5....T.    /etc/rc.d/init.d/httpd
S.5....T.  c /etc/sysconfig/httpd
SM5....T.    /usr/sbin/apachectl

Como véis ahora sí que hay salida. Tenemos 8 puntos que se pueden convertir en otros caracteres cuando hay algo que no cuadra:

• 5: fallo en el checksum MD5
• S: discrepancia en el tamaño del fichero
• T: fecha de modificación distinta al original
• L: enlace simbólico
• D: dispositivo
• U: usuario
• G: grupo
• M: permisos

Así pues, en el ejemplo anterior vemos como el binario apachectl tiene un checksum MD5 distinto, distinto tamaño, fecha de modificación y de permisos. La “c” es de fichero de configuración.

Si queremos comprobar de una tacada la integridad de todos los binarios de /usr/sbin, es tan sencillo como:

# rpm -Va | grep "/usr/sbin"
S.5....T.    /usr/sbin/apachectl

Podemos añadir un mayor nivel de debug con el parámetro “v”, “vv” más debug aún:

# rpm -Vv --file /usr/sbin/apachectl
# rpm -Vvv --file /usr/sbin/apachectl

Como veis, esta es una buena y sencilla forma de asegurarnos que los binarios del sistema no han sido alterados y también de tener un control del estado de los ficheros de configuración, etc.

También te puede interesar:

• 6 trucos útiles del gestor de paquetes yum
• ¿Qué es mejor, compilar o usar yum/apt?
• Bug en RRDtool 1.2.28 , texto en gráficos y leyenda
• rhn_register y yum a través de un proxy

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

También te puede interesar:

• Reinstalar CentOS de forma remota vía VNC (sin acceso físico al servidor)
• Instalar y configurar vnc-server en CentOS/RHEL/Fedora
• ssh, authorized_keys y umask
• Usar autenticación LDAP (OpenLDAP) con OpenSSHD (sshd)

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:

• Gestión de LVM en Linux (Logical Volume Manager)
• Crear y eliminar particiones con fdisk en Linux

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: *************

También te puede interesar:

• Encriptación y desencriptación con GnuPG
• Encriptar mensajes de Gmail con FireGPG
• Gestión de particiones con parted en Linux
• Montar un filesystem por UUID o label

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

También te puede interesar:

• Ocultar la versión de PHP
• Encriptar un filesystem con LUKS y cryptsetup
• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Configurar PHP + FastCGI en Oracle iPlanet Web Server

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

También te puede interesar:

• Encriptar un filesystem con LUKS y cryptsetup
• 10 trucos para securizar PHP
• Comando chage: tiempo de vida de claves y usuarios en GNU/Linux
• Permisos especiales (setuid, setgid, sticky bit)

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

También te puede interesar:

• Cómo crear un repositorio local de yum
• Cómo instalar RRDtool en CentOS 5
• Bonding/Teaming/Trunking en RHEL y CentOS
• SELinux ‘semanage: command not found’

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.

También te puede interesar:

• Introducción a iptables
• FreeBSD: comando PS no muestra todas las columnas
• APF: Unable to load iptables module (ip_tables), aborting
• Bloquear direcciones IP en Windows 2003 Server

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.

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.

También te puede interesar:

• Como instalar y configurar el firewall APF
• APF: Unable to load iptables module (ip_tables), aborting
• Ejemplos de reglas para IPtables
• Bloquear con IPTABLES el tráfico desde/hacia una dirección IP

• 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?

También te puede interesar:

• Exim: establecer filtros anti-spam para entrada y salida de correo
• Estadísticas de correo, spam y virus con Mailgraph
• Consulta la reputación de una IP en cientos de listas anti-spam
• SpamAssassin: Crear regla que examine las cabeceras en busca de una cadena

Voy a recopilar una serie de entradas que tenía publicadas en otro blog. En esta primera voy a tratar un tema delicado, las operaciones bancarias a través de Internet.

Dejando a un lado el phising (que abarcaría otro artículo completo), muy a menudo escuchamos, ya sea a través de conocidos o por los medios, que suceden graves delitos relacionados con robos de tarjetas y demás información sensible a través de Internet.

Hoy en día gran parte de los internautas realizan compras online, y podríamos asegurar que un porcentaje realmente elevado no toma ninguna medida de seguridad a la hora de hacerlo. Independientemente de la seguridad que nos pueda ofrecer la tienda online, banco o sitio web contra el que realizamos la operación, no servirán de nada sino hacemos lo mismo en nuestro ordenador.

Mis consejos para realizar operaciones bancarias por Internet de forma segura son los siguientes:

Evitar el pago con tarjeta de crédito, utilizar métodos alternativos.

Cuando hablo de métodos alternativos, no solamente me refiero a pagar por transferencia bancaria u otro medio de pago tradicional. El pago por PayPal está muy extendido por las tiendas online (permite la transferencia de dinero entre usuarios que tengan correo electrónico, sin facilitar ningún dato de tus tarjetas de crédito).

Los keylogger son tu mayor enemigo.

Un Keylogger es un tipo de software que se encarga de registrar las pulsaciones que se realizan en el teclado, para memorizarlas en un fichero y/o enviarlas a través de internet. Se propagan como un virus y están muy extendidos en sistemas con Microsoft Windows. Si tu ordenador está infectado con uno, al teclear tu tarjeta de crédito o cualquier otro dato sensible puedes estar enviandolo por Internet a los delincuentes (quienes almacenan miles de datos bancarios para su utilización de forma ilegal).

La principal solución para combatir un Keylogger es la utilización de un buen antivirus, antispyware y demás herramientas, además de mantener actualizado el sistema siempre con los últimos parches de seguridad.

Uso de un Live-CD.

Soy de la opinión de que el punto número 2 no te dará el 100% de garantías de estar limpio de este tipo de malware, así que os recomiendo utilizar un Live-CD cuando vayáis a efectuar compras online, operaciones bancarias, etc.

Definición de Live-CD (Wikipedia):

Es un sistema operativo (normalmente acompañado de un conjunto de aplicaciones) almacenado en un medio extraíble, tradicionalmente un CD o un DVD (de ahí sus nombres), que puede ejecutarse desde éste sin necesidad de instalarlo en el disco duro de una computadora, para lo cual usa la memoria RAM como disco duro virtual y el propio medio como sistema de archivos.

Esta medida nos garantiza que el sistema está limpio de virus y software malicioso siempre que lo utilicemos. Existen gran variedades de Live-CD GNU/Linux que podemos utilizar para esta tarea, muchos de los cuales únicamente arrancan un navegador (Firefox):

• Ubuntu Live CD
• Knopixx
• Webconverger (Sólo contiene firefox).

Hay centenares de LiveCD, GoblinX, Frenzy, Mutagenix, Anonym.OS, CDlinux… tenéis una lista completa aquí.

Despídete de Windows

La última regla y también la más radical. Personalmente os recomiendo el uso de un Live-CD o directamente no utilizar Windows a la hora de realizar operaciones bancarias, manejar y guardar información sensible en el PC, etc.

Los virus en GNU/Linux, BSD o Mac OS X están mucho menos difundidos y tus posibilidades de sufrir este problema serán mínimas o nulas. Sé que esto último es muy complicado, pero por lo menos espero que hagáis caso de alguna de las recomendaciones expuestas en este artículo para evitar males mayores.

También te puede interesar:

• Generador de passwords aleatorios
• Navegar por Internet de forma segura con KioskCD