Category Archives: Ciberseguridad

Protección antivirus en Alfresco ECM (primera parte)

Alfresco ECM no viene con antivirus de serie, al igual que otras aplicaciones y programas como puede ser OpenOffice.org, etc. dejando esta tarea al sistema operativo y las soluciones antivirus elegidas.
La solución de usar un antivirus directamente sobre Alfresco plantea varias soluciones cada una con sus pros y sus contras así como el impacto en el sistema que puede ser mayor o menor.
.
Se pueden plantear por tanto varias soluciones de escaneo con los documentos subidos a Alfresco, que pueden ser:
1. Escaneo del repositorio localizando el fichero infectado directamente y dejando a posteriori la localización del NodeRef.
2. Escaneo bajo demanda al subir un documento, haciendo para ello que Alfresco ECM redirija el contenido hacia un antivirus que permita la lectura de un stream de datos.
Ambas soluciones son viables en Alfresco aunque su función es distinta, en la primera se escanea todo el repositorio, dejándose generalmente para tareas nocturnas o de fin de semana y aseguran tener un repositorio saneado con el tiempo. Esto causa impacto en los discos que cada cierto tiempo tienen que realizar la tarea de principio a fin y que puede ser muy larga dependiendo del tamaño del repositorio.
La segunda solución es limpia y permite que cualquier documento subido a Alfresco ECM haya sido previamente escaneado, bloqueando si es necesaria, su subida si se detecta un código maligno. Esta solución impacta directamente a la hora de la subida del documento pero nos asegura que los archivos subidos estén limpios sin tener que ser examinados posteriormente.
Una solución muy completa es la de unir ambas soluciones de forma que siempre sean escaneados los documentos al ser subidos y creados en Alfresco ECM y a su vez, que cada cierto tiempo se compruebe la “salud” de los documentos pasando un escaneo completo ya que además se escanearán con la última actualización del antivirus lo que puede detectar documentos con virus que inicialmente no fueron detectados.
— Una primera solución —
Para la primera solución, a su vez, se puede abordar desde distintas perspectivas, bien desde un plano más externo a Alfresco ECM y otro directamente desarrollando parte de la solución como una extensión de este.
En cualquier caso hay que elegir una solución antivirus que pueda servirnos para estos propósitos. En mi caso he elegido la solución ClamAV ya que permite muchas formas de interactuar, es OpenSource y podemos usarlo en varias plataformas (Linux, BSD, AIS, Solaris, etc.)
Para instalar ClamAV solo hay que instalarlo vía apt-get/aptitude, yum, etc. o bien bajando el fichero directamente y compilándolo, generalmente con la secuencia:
./configure
make
make install
Una vez instalado (en el servidor, se entiende) podemos hacer uso del comando “clamscan” para escanear el repositorio. (NOTA: No es objetivo de este post la configuración de clamav, freshclam, etc.)
El uso de clamscan es muy sencillo, básicamente hay que poner las opciones necesarias y el directorio/fichero a escanear. Aquí vamos a usar las opciones de visualizar solo los ficheros infectados y que además sea de forma recursiva.
Un ejemplo:
clamscan -i -r /alfresco/alf_data/
Bien, hasta aquí correcto, nos listará los virus encontrados, pero ahora necesitamos saber a qué documento de alfresco corresponde en su entorno. Como sabemos, en Alfresco, ni siquiera el nombre del documento es correcto para poder localizarlo, en todo caso podría ser si conocemos la ruta completa, aunque no sería lo mejor; pero si podemos usar el UUID o también llamado nodeRef.
Aquí podemos usar también varias formas, bien haciendo llamadas RESTful/SOAP a WebServices o WebScripts de Alfresco ECM en el que hay que extenderlo para poder realizar las llamadas necesarias y que este nos devuelva los valores o bien realizar las acciones que necesitamos; o usar directamente consultas SQL a la base de datos utilizada. En este primer caso vamos a usar una consulta SQL hacia nuestra instalación en MySQL.
La consulta podría ser algo asi:

SELECT alf_node.uuid 
    FROM alf_node_properties
        INNER JOIN alf_node
            ON alf_node.id = alf_node_properties.node_id
        INNER JOIN alf_qname
            ON alf_qname.id = alf_node_properties.qname_id
WHERE alf_node_properties.node_id =
(SELECT alf_node_properties.node_id 
    FROM alf_content_url
                INNER JOIN alf_content_data
                        ON alf_content_url.id = alf_content_data.content_url_id
        INNER JOIN alf_node_properties
            ON alf_content_data.id = alf_node_properties.long_value
        INNER JOIN alf_qname
            ON alf_qname.id = alf_node_properties.qname_id
    WHERE alf_content_url.content_url = ‘${FUID}’
    AND alf_qname.local_name = ‘content’)
AND alf_qname.local_name = ‘name’;
 

Donde ${FUID} es la localización física del fichero en el contentstore o File Unique IDentifier, lo que Alfresco ECM llama normalmente contentUrl.
Bien, entonces, ¿Cómo podríamos hacer para que si un fichero es localizado con un virus, nuestro sistema Linux realice una llamada a Alfresco para que, por ejemplo lo renombre, ponga un aviso en el título, envíe correos electrónicos, etc.?
Para esto vamos a usar además un comando más, el comando wget (o curl si se prefiere) que puede realizar peticiones GET a un servidor para poder llamar a Alfresco ECM via RESTful y realizar una llamada al WebScript necesario.
Lo primero es el script que usaremos dentro del cron del sistema operativo (en este caso realizado para Linux CentOS con bash):
——————– alfviral.sh
#!/bin/bash

# Variables de configuración
#

ALFUSER=admin
ALFPASSWD=admin
ALFRESCO_URL=http://localhost:8080/alfresco
DIR_ROOT=/home/alfresco/alfresco-enterprise-3.3.4/alf_data
USERNAME=alfresco
PASSWD=alfresco
DATABASE=alfresco_enterprise_334
HOST=localhost
PORT=3306

PROG=$0
PROGDIR=`dirname “$PROG”`

SCANRES_FILE=scanres.txt
NODEREFS_FILE=noderefs.txt
DOCNAMES_FILE=docnames.txt

# Crea lista de ficheros infectados
#
echo “Creando lista de ficheros infectados…”
rm -f ${PROGDIR}/${SCANRES_FILE} 2>/dev/null
CONTENTSTORE=${DIR_ROOT}/contentstore
clamscan -i -r ${CONTENTSTORE} | awk -F: ‘$1~/.bin/{print “store:/”$1}’ | sed s:${CONTENTSTORE}::g >${PROGDIR}/${SCANRES_FILE}

if [ ! -s ${PROGDIR}/${SCANRES_FILE} ]
then
    echo “No hay ficheros infectados.”
    exit 0
fi

# Crea lista de NodeRefs de los ficheros
#
echo “Creando referencias NodeRefs de los FUID…”
rm -f ${PROGDIR}/${NODEREFS_FILE} 2>/dev/null
for FUID in $(cat ${PROGDIR}/${SCANRES_FILE})
do
    mysql -u${USERNAME} -p${PASSWD} -D${DATABASE} -h${HOST} -P${PORT} –skip-column-names –raw –silent >>${PROGDIR}/${NODEREFS_FILE} <
SELECT alf_node.uuid 
    FROM alf_node_properties
        INNER JOIN alf_node
            ON alf_node.id = alf_node_properties.node_id
        INNER JOIN alf_qname
            ON alf_qname.id = alf_node_properties.qname_id
WHERE alf_node_properties.node_id =
(SELECT alf_node_properties.node_id 
    FROM alf_content_url
                INNER JOIN alf_content_data
                        ON alf_content_url.id = alf_content_data.content_url_id
        INNER JOIN alf_node_properties
            ON alf_content_data.id = alf_node_properties.long_value
        INNER JOIN alf_qname
            ON alf_qname.id = alf_node_properties.qname_id
    WHERE alf_content_url.content_url = ‘${FUID}’
    AND alf_qname.local_name = ‘content’)
AND alf_qname.local_name = ‘name’;
q
STOP
done

if [ ! -s ${PROGDIR}/${NODEREFS_FILE} ]
then
    echo “¡No se han encontrado referencias a los ficheros!”
    exit 1
fi

# Lanza las llamadas a Alfresco hacia el webscript
#
echo “Llamando a Alfresco…”
rm -f ${PROGDIR}/${DOCNAMES_FILE} 2>/dev/null
ALF_TICKET=`curl “http://localhost:8080/alfresco/service/api/login?u=${ALFUSER}&pw=${ALFPASSWD}” | grep TICKET_ | sed ‘s:::g’ | sed ‘s:::g’`
for NODEREF in $(cat ${PROGDIR}/${NODEREFS_FILE})
do
    curl “${ALFRESCO_URL}/service/protect/alfviral?nref=${NODEREF}&alf_ticket=${ALF_TICKET}” >>${PROGDIR}/${DOCNAMES_FILE}
    echo “” >>${PROGDIR}/${DOCNAMES_FILE}
done——————– alfviral.sh

Y en segundo lugar crear un WebScript que realice las tareas necesarias:
——————– alfviral.get.desc.xml
<webscript>  <shortname>Alfresco Virus Alertshortname>
  <description>Alfresco Virus Alertdescription>
   <url>/protect/alfviral?nref={nref}url>
   <format default=”text”>extension</format>
   <authentication>user</authentication>
   <transaction>required</transaction>
webscript>
——————– alfviral.get.desc.xml

——————– alfviral.get.js
// chequeo de parámetros
if (args.nref == undefined || args.nref.length == 0)
{
    status.code = 400;
    status.message = “Es necesario indicar el nref.”;
    status.redirect = true;
}
else
{
    // buscar el documento por su nodeRef
    var nodes = search.luceneSearch(“ID:”workspace://SpacesStore/” + args.nref + “””);

    // renombrar el documento
    var name_infected = “”;
    name_infected = nodes[0].name;
    if (name_infected.indexOf(“_INFECTADO”) == -1)
    {
        nodes[0].name = name_infected + “_INFECTADO”;
        nodes[0].save();
        if (logger.isLoggingEnabled())
            logger.log(“El documento: ” + nodes[0].name + ” ha sido renombrado por estar infectado.”);
    }
    
    model.name_infected = nodes[0].name;
}

——————– alfviral.get.js

——————– alfviral.get.text.ftl
${name_infected}
——————– alfviral.get.text.ftl

——————– alfviral.get.html.400.ftl

${status.message}
body>
html>

——————– alfviral.get.html.400.ftl
Poniendo la llamada en nuestra crontab podemos escanear periódicamente nuestro repositorio y actuar en consecuecia.
En este caso, simplemente se han renombrado los documentos infectados, como puede verse en la imagen:

Para la segunda entrega seguiremos abordando nuevas posibilidades para mantener “sano” nuestro repositorio.

¡Ah!, y FELIZ NAVIDAD A TODOS

Autenticación NTLM (SSO) en share de Alfresco 3.1

Para la autenticación por NTLM de la nueva interface “share” de Alfresco hay que seguir los siguientes pasos:

A) Modificar webapps/share/WEB-INF/web.xml para activar las líneas y filtros referentes a la autenticación NTLM (de igual forma que en mi post anterior Autenticación NTLM en Alfresco)

B) Copiar webapps/share/WEB-INF/classes/alfresco/webscript-framework-config.xml como shared/classes/alfresco/web-extension/webscript-framework-config-custom.xml

C) Añadir lo siguiente (desde el hasta ):



[…]

alfresco
Alfresco – user access
Access to Alfresco Repository WebScripts that require user authentication
alfresco
http://localhost:8080/alfresco/wcs
user
true

[…]

Reiniciar el servidor y listo. Hay que tener en cuenta siempre las recomendaciones y configuraciones de los posts anteriores en cuanto a navegadores y sistemas.

Para más información se puede ir a la wiki de Alfresco.

Single Sign On (SSO) en Alfresco con NTLM (Windows)

En el artículo anterior se vió la forma de configurar la autenticación NTLM (Autenticación NTLM en Alfresco) tanto vía WebClient (web) como vía CIFS (unidades compartidas de Windows). De hecho se ha visto una configuración denominada “passthru” en la que los usuarios se buscan directamente en la SAM de Windows, ya sea 2000/2003/… Server, o el mismo Windows XP que también contiene la suya.

Bien, pero, si el cliente es desde windows y nos hemos identificado con un usuario que ya existe en Alfresco, lo ideal es que no vuelva a preguntar por esa autenticación y envíe los datos de usuario/password (o cadena MD4) de nuevo, si no que el mismo Internet Explorer los envíe de forma automática y por tanto se esté autenticado. Esto es lo que se conoce como Single Sign On (SSO).

Alfresco permite este sistema de autenticación “automatizada” o de “autentícate una vez solamente” en determinadas configuraciones. Una de ellas es a través de NTLM siempre que el sistema utilice NTLMv1. En el caso que nos ocupa, con una instalación de Alfresco Enterprise 3.1 SP1 en una máquina Linux Ubuntu 9.10 y una base de usuarios en Windows XP, accediendo desde el propio Windows XP autenticados previamente con una cuenta que existe en Alfresco.

Los ficheros a configurar son los mismos que anteriormente, o sea, web.xml y ntlm-authentication-context.xml

Muy bien, ya están configurados, pero entonces, ¿por qué se me solicita siempre usuario y contraseña desde Internet Explorer si estoy autenticado con un usuario y contraseña que ya están en Alfresco)

La respuesta está en base a dos configuraciones que hay que revisar:

1. Uso de NTLMv1 desde Windows. Para ello hay que realizar los siguientes pasos en Windows:

a) Ir a “Panel de control->Herramientas administrativas->Política de seguridad local”
b) Seleccionar la carpeta “Políticas locales”
c) Ir a “Opciones de seguridad”
d) Seleccionar “Network Security : nivel de autenticación del controlador LAN”
e) Comprobar (o en su caso establecerla) que está en la opción de “Enviar LM & NTLM – usar seguridad de sesión NTLMv2 si se negocia”

2. Acceso desde Internet Explorer. El navegador seguirá visualizando la ventana de autenticación porque, evidentemente, no se fía de realizar un acceso de forma automática sin el consentimiento del usuario. Para ello en Internet Explorer hay que seguir los siguientes pasos:

a) Ir a “Herramientas->Opciones de Internet…->Seguridad”
b) Seleccionar “Sitios de confianza”
c) Pulsar en el botón “Sitios..”
d) Introducir (Agregar) la URL del sitio al que se accede (del servidor donde está Alfresco), p.e. http://172.26.0.6:8080/alfresco (desactivar “Requerir comprobación del servidor (https)…” si no es una URL segura)

Con esto ya obtenemos SSO desde Windows con Internet Explorer desde la versión 6.

Para comprobar que funciona solo hay que activar en log4j.xml la depuración de NTLM:

log4j.logger.org.alfresco.web.app.servlet.NTLMAuthenticationFilter=debug
log4j.logger.org.alfresco.repo.webdav.auth.NTLMAuthenticationFilter=debug

Cuando autentique correctamente dará un resultado como el que sigue:

11:50:37,178 DEBUG [app.servlet.NTLMAuthenticationFilter] New NTLM auth request from 172.26.0.13 (172.26.0.13:3072) SID:A28CADB932CA4EFB87283284B9C29990
11:50:37,238 DEBUG [app.servlet.NTLMAuthenticationFilter] Received type1 [Type1:0xa208b207,Domain:WRKGRP,Wks:XPPRO]
11:50:37,239 DEBUG [app.servlet.NTLMAuthenticationFilter] Client domain WRKGRP
11:50:37,429 DEBUG [app.servlet.NTLMAuthenticationFilter] Sending NTLM type2 to client – [Type2:0x80000203,Target:PT043A,Ch:6ce8db32e9dccc27]
11:50:37,459 DEBUG [app.servlet.NTLMAuthenticationFilter] Received type3 [Type3:,LM:947bde8ff03d7b972817a6dc0232eddeba5c294ad9a337a2,NTLM:4a532d7bbd01f1ef2300a8fc91b54fbcad5e11db6a94f284,Dom:XPPRO,User:fegor,Wks:XPPRO]
11:50:37,555 User:fegor DEBUG [app.servlet.NTLMAuthenticationFilter] Updated cached NTLM details
11:50:37,556 User:fegor DEBUG [app.servlet.NTLMAuthenticationFilter] User logged on via NTLM, [fegor,Wks:XPPRO,Dom:XPPRO,AuthSrv:PT043A,Fri Dec 18 11:50:37 GMT+01:00 2009]

“Rizando el rizo”…

Bueno, pero , ¿que pasa con Fire Fox?, este navegador por defecto no es capaz de autenticar vía NTLM…

Por defecto no, pero podemos “forzarlo”, ¿como?, solo hay que seguir los siguientes pasos:

a) Poner en la URL de Fire Fox “about:config” y aceptar la entrada.
b) Buscar la cadena “network.automatic-ntlm-auth.trusted-uris” e introducir como valor la URL de Alfresco. P.e. http://172.26.0.6:8080/alfresco

Con esta configuración podremos tener acceso SSO en Fire Fox 3 desde un cliente Windows.

Esta configuración (al igual que la del artículo anterior) han sido probadas tanto en la versión 2.1 (SP7) como en la 3.1 (SP1) de Alfresco Enterprise.

Autenticación NTLM en Alfresco con Active Directory

En muchas ocasiones, aunque el servidor de autenticación sea un Windows 2000 Server, Windows 2003 Server o posterior y sus usuarios estén en el Active Directory no es necesario tener que configurar Alfresco para que autentique como tal vía LDAP/Active Directory.

Windows 2000 y superiores utilizan la autenticación mixta vía LDAP (Active Directory) y TLM v2 y por tanto podemos configurar Alfresco tocando solamente 3 ficheros, que serán:

web.xml
ntlm-authentication-context.xml
file-servers-custom.xml

En Alfresco, este tipo de autenticación donde no solo se usa el protocolo “desafío/respuesta” NTLM sino que además se usa contra una base de datos de usuarios de Windows, para la identificación de cada persona, se le denomina “NTLM passthru”.

Se usa ${tomcat} como identificador del punto de comienzo del servidor de aplicaciones que en este caso es Apache-Tomcat.

Primero hay que activar los filtros necesarios para la autenticación vía web en ${tomcat}/webapps/alfresco/WEB-INF/web.xmldescomentando las líneas siguientes:

org.alfresco.web.app.servlet.NTLMAuthenticationFilter

org.alfresco.repo.webdav.auth.NTLMAuthenticationFilter


Authentication
Filter
/navigate/*


Authentication
Filter
/command/*


Authentication
Filter
/download/*


Authentication
Filter
/template/*


Authentication
Filter
/n/*


Authentication
Filter
/c/*


Authentication
Filter
/t/*


Authentication
Filter
/d/*


Authentication
Filter
/ajax/*


Authentication
Filter
/wcs/*


Authentication
Filter
/wcservice/*

Lo mejor es buscar la cadena “NTLM” y a partir de ahí descomentar estas líneas.

El siguiente fichero a configurar es ${tomcat}/share/classes/alfresco/extension/ntlm-authentication-context.xml donde solo hay que establecer el servidor o servidores Windows que contienen el Active Directory.

En este caso, por ejemplo:


MIDOMINIOserv001, serv001


Y por último el fichero ${tomcat}/share/classes/alfresco/extension/file-servers-custom.xml que es el que nos permitirá acceder a los recursos CIFS (SMB) desde Windows o desde Linux. Aquí se configura para usar “passthru” así como los servidores necesarios.

Por ejemplo:



MIDOMINIOserv001, serv001



Con esto ya estaría configurado nuestro sistema para autenticación NTLM y acceso a los recursos vía CIFS/SMB. Bastará con poner en la dirección del navegador de ficheros la dirección del host o servidor Alfresco:

En Windows como \serv001

En Linux, generalmente como smb://srv001

Observaciones: Hay que tener en cuenta que si es un entorno Linux los puertos usados
para los recursos CIFS/SMB (puertos 137, 138, 139 y 445) solo pueden abrirse por el usuario root y no por un usuario sin privilegios de administración. En este último caso habría que utilizar puertos por encima del 1024 reasignándose dentro de la configuración (en el
propio fichero file-servers-custom.xml) y utilizando un sistema de “forwading” o “NAT” con un router.

Firewall en Linux (Ipfwadm, Ipchains… Iptables)

En muchas distribuciones (p.e. en Ubuntu) no vienen ningún firewall configurado y activado por defecto si no lo establecemos expresamente. Hasta Windows XP ya traía uno y aconsultaba al usuario y aconsejaba activarlo…

En linux tenémos un firewall (cortafuegos) que es una verdadera maravilla, podemos hacer de todo hoy día y no tiene nada que envidiar al más robusto sistema de protección y bloqueo de tráfico que haya en el mercado. Pero empecemos por el principio…

En un primer inicio, bajo el kernel 2.0 se utilizó un sistema rudimentario pero muy potente que era Ipfwadm. Este tenía 3 directivas básicas (INPUT, OUTPUT y FORWARD) para controlar el tráfico de entrada, salida y el “reenvío”. Potente, sencillo aunque con una sintáxis algo complicada para realiar tareas más avanzadas.

La segunda generación la tenemos en el núcleo 2.2 con Ipchains. Este trae un nuevo concepto, el de las “cadenas de reglas”, o lo que es igual, permite las pilas de reglas creadas por el usuario, o sea, podemos hacer una “cadena” de reglas que se llame WEB y que controle todo el tráfico que sea de este tipo.

Además de esto trajo consigo la numeración de reglas por lo que era posible insertar nuevas reglas a las ya existentes, no solo añadirlas.

Junto con la capacidad de filtrar cualquier protocolo (no solo TCP, UDP e ICMP) y la capacidad de usar la “negación” en las reglas le aventajaba en mucho a su antecesor.

Pero vino por fín con la versión 2.4 del kernel de linux (comenzó en realidad en la rama 2.3) Iptables. Una nueva implementación para dotar a los sistemas con kernel linux de un verdadero y potente sistema de firewall con posibilidad de bloquear y denegar tráfico, devolver tráfico de una conexión existente, realizar traslaciones de direcciones, enrutar, y dos aspectos muy importantes, implementar un sistema SPI o Stateful Packet Inspection (Inspección de Paquetes de Estado) y de QoS (Quality of Service) o Calidad del Servicio.

En el caso del SPI ahora es posible asociar el tráfico devuelto generado a partir de una regla input anterior, en Ipchains hacían falta 6 reglas para enrutar entre dos interfaces.

Además al llevar una “inteligencia” en la gestión de los paquetes mediante este SPI tiene una ventaja adicional, es que mantiene el control de sesiones de tráfico, de forma que aunque un atacante pueda fabricar paquetes que simulen paquetes de un protocolo determinado como devueltos, (Ipchains podía permitir dicho tráfico) como no existe una sesión para dichos paquetes se rechazarán.

Como únicamente la cadena FORWARD controla cualquier paquete para ser reenviado, INPUT y OUTPUT solo se aplican para entrar o salir del host, se reduce mucho el número de reglas a incluir en nuestro sistema.

La instalación de Iptables requiere la compilación del kernel si no están configuradas, pero hoy día están dentro de todos los kernels por defecto de las distribuciones así que no hay que preocuparse. Además cada distribución realiza una gestión de las reglas a su manera, pe. es de considerar la de CentOS (evidentemente también Fedora y RedHat) que se implementan de forma sencilla pero efectiva.

Como Ubuntu no trae esta bonita configuración (la de CentOS) hay que ponerse manos a la obra, lo mejor es ponerla en el rc.local si no somos muy paranóicos o crearnos un sistema de arranque/parado dentro de /etc/init.d dentro de los niveles de arranque que necesitemos y (si no usamos referencias a hosts sino solo a IPs) hacer que arranque antes de que lo hagan las interfaces de red. El primer sistema está bien para portátiles y ordenadores de escritorio pero para servidores es más que recomendable la segunda opción.

Se pueden realizar multitud de configuraciones y espero ir poniendo aquí algunas complejas que controlen no solo tráfico o enrutamiento, sino también “Throughput”, “Reliability”, etc. dentro de un sistema basado en QoS.

Por lo pronto yo uso dos en mi portátil, una para utilizarla como sistema básico de cortafuegos, hay que tener en cuenta que uso dos interfaces (bueno tres como veréis más abajo) que son la ethernet cableada y la wifi. Como soy quisquilloso con eso, activo una u otra y dejo pasar tráfico a mi sistema de una u otro como yo quiera. Además de esto utilizo los flags largos y no los cortos porque así (consejo de un amigo) se aprende uno mejor la sintáxis de los comandos. Este es por tanto mi fichero firewall_on.sh

#!/bin/sh
#
# Firewall sencillo
# fegor
#
# eth0 -> Ethernet cableada
# eth1 -> Ethernet inalámbrica
#
# Evitar ecos de ICMP, ataques SYN floods y otras medidas
# de protección
#
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
#
# Limpieza
#
iptables –delete-chain
iptables –flush
iptables –table nat –flush
#
# Permitir tráfico loopback
#
iptables –append INPUT –in-interface lo –jump ACCEPT
iptables –append OUTPUT –out-interface lo –jump ACCEPT
#
# Políticas por defecto
#
iptables –policy INPUT DROP
iptables –policy OUTPUT DROP
iptables –policy FORWARD DROP
#
# Permitir tráfico establecido de entrada e
# ilimitado de salida
#
iptables –append INPUT –match state –state ESTABLISHED,RELATED –jump ACCEPT
iptables –append OUTPUT –match state –state NEW,ESTABLISHED,RELATED –jump ACCEPT
#
# Permitir entradas selectivas (ssh, http, etc.)
#
iptables –append INPUT –in-interface eth0 –protocol tcp –syn –match state –state NEW –source 0/0 –destination 0/0 –destination-port 22 –jump ACCEPT
iptables –append INPUT –in-interface eth1 –protocol tcp –syn –match state –state NEW –source 0/0 –destination 0/0 –destination-port 22 –jump ACCEPT
# Permitir entradas EMule/AMule
iptables –append INPUT –in-interface eth0 –protocol tcp –syn –match state –state NEW –source 0/0 –destination 0/0 –destination-port 4662 –jump ACCEPT
iptables –append INPUT –in-interface eth0 –protocol udp –source 0/0 –destination 0/0 –destination-port 4672 –jump ACCEPT
#
# Rechazar finalmente el tráfico restante
#
iptables –append INPUT –jump DROP

Otro script qu utilizo es para enrutar mi USB Modem 3G y hacer que cualquier otro ordenador salga a través de mi portátil. Para ello hay que activar el enrutamiento y hacer el FORWARD pertinente. Este es mi router_on.sh

#!/bin/sh
#
# Enrutar tráfico de los demás a internet
# fegor
#
# eth0 -> Ethernet cableada
# eth1 -> Ethernet inalámbrica
# ppp0 -> Modem USB 3G
#
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables –flush
iptables –table nat –flush
iptables –table nat –append POSTROUTING –out-interface ppp0 -j MASQUERADE
iptables –append FORWARD –in-interface eth0 -j ACCEPT
iptables –append FORWARD –in-interface eth1 -j ACCEPT

Y eso es todo, no pretende ser un manual de Iptables, ni guia, ni tutorial, ni nada más que lo que habéis leído. Para saber más:

Enlaces:

http://www.netfilter.org/
http://es.wikipedia.org/wiki/Iptables
http://www.linuca.org/body.phtml?nIdNoticia=99
http://www.bulma.net/body.phtml?nIdNoticia=1522

Bibliografía:

Firewalls (Manual de referencia)
Keith E. Strasberg, Richard J. Gondek y Gary Rollie
Edit. Mc Graw Hill

Información dentro de la propia distribución linux que tengáis:

man iptables
iptables –help