{"id":68,"date":"2009-05-19T06:58:31","date_gmt":"2009-05-19T13:58:31","guid":{"rendered":"http:\/\/blog.espol.edu.ec\/fsanchez\/?p=68"},"modified":"2009-05-19T07:03:52","modified_gmt":"2009-05-19T14:03:52","slug":"configuracion-segura-de-iptables","status":"publish","type":"post","link":"https:\/\/blog.espol.edu.ec\/fsanchez\/2009\/05\/19\/configuracion-segura-de-iptables\/","title":{"rendered":"Configuraci\u00f3n Segura de IPTABLES"},"content":{"rendered":"

Tomado de: http:\/\/www.hacktimes.com\/?q=node\/49<\/a><\/span><\/p>\n

Enviado por suzdal el Dom, 04\/11\/2007 - 20:02 <\/span><\/p>\n

\n

El siguiente art\u00edculo se va a centrar en c\u00f3mo configurar un firewall iptables de forma segura y en c\u00f3mo evitar que, ante un escaneo de puertos, se obtenga informaci\u00f3n diversa acerca del Sistema Operativo instalado en el servidor escaneado que pueda ayudar a descubrir vulnerabilidades. No todos los firewalls lo consiguen ya que cada uno act\u00faa con un comportamiento distinto y, aunque ofrecen protecci\u00f3n cerrando los puertos, no siempre se filtran de la forma m\u00e1s correcta.<\/p>\n

UN POCO DE HISTORIA...<\/strong><\/p>\n

Actualmente, existen multitud de firewalls por software, algunos dedicados que proporcionan una estabilidad m\u00e1s que aceptable y que est\u00e1n integrados en el propio Sistema Operativo siendo distribuciones propias y otros que, por ejemplo, son simplemente interfaces gr\u00e1ficas que facilitan la tarea para la mayor\u00eda de usuarios y que proporcionan una seguridad por defecto para un uso m\u00e1s dom\u00e9stico. \u00c9stos \u00faltimos, en entornos m\u00e1s exigentes no proporcionan una respuesta pro-activa ante un escaneo y\/o posterior ataque. En ambos casos, muchos de estos firewalls utilizan como n\u00facleo central iptables.<\/p>\n

Iptables, c\u00f3mo se le conoce com\u00fanmente, en realidad proviene del proyecto Netfilter\/Iptables (a\u00f1o 1998 sobre n\u00facleos Linux 2.4 y superior). Dicho proyecto es la evoluci\u00f3n del ipchains del n\u00facleo Linux 2.2 que a su vez proven\u00eda del ipfwadm de BSD. La diferencia radica en que no exist\u00eda un framework general que permitiese el manejo de paquetes, siendo antiguamente alteraciones directas del c\u00f3digo de red para manipular los paquetes.<\/p>\n

Actualmente, netfilter permite no s\u00f3lo filtrar paquetes y hacer NAT (que es lo que hac\u00edan ipchains e ipfwadm) sino que separa las operaciones sobre los paquetes en filtrado, NAT y seguimiento de conexiones, siendo cada una por su parte capaz de conectarse a las herramientas de netfilter para acceder a los paquetes.<\/p>\n

Esta divisi\u00f3n que proporciona netfilter le aporta la capacidad de monitorizar el estado de una conexi\u00f3n y redirigir, modificar o incluso detener los paquetes de datos basados en el estado de la conexi\u00f3n y no s\u00f3lo por la direcci\u00f3n de origen, de destino sino incluso por el contenido del paquete.<\/p>\n

Iptables por su parte, proporciona una herramienta mediante scripts para definir reglas que indican qu\u00e9 hacer con un determinado paquete. Las reglas se agrupan en cadenas de modo que se organizan para definir un comportamiento concreto ante un paquete IP determinado.<\/p>\n

Con Iptables, es preciso controlar de forma m\u00e1s detallada qu\u00e9 reglas configurar y definir paso a paso que se va a permitir y que no, dejando a la habilidad del administrador la posibilidad de que sea m\u00e1s seguro y la certeza de no haber dejado alg\u00fan agujero o alguna regla que no sea todo lo expl\u00edcita que debiera posibilitando que se pueda falsear el estado del protocolo e incluso, penetrar en el sistema. Es aqu\u00ed donde radica la importancia de securizar no s\u00f3lo el iptables sino tambi\u00e9n de configurar reglas preventivas para conseguir hacer invisible el equipo desde Internet y asegurarse de no exponer nada que pueda suponer una brecha de seguridad en el sistema.<\/p>\n

El modo es simple y complejo a la vez, consiste en hacer que ante una petici\u00f3n de protocolo a la direcci\u00f3n IP del sistema, el firewall no responda con un \u201cport closed\u201d (cerrado) sino con un \u201cstealth\u201d (invisible\/filtrado) dificultando as\u00ed una posible detecci\u00f3n de un agujero y\/o debilidad en el sistema con la posibilidad de una penetraci\u00f3n de un hacker en la red.<\/p>\n

Si bien la parte del proyecto referente al iptables proporciona herramientas y scripts, no hay que confundirlas con el propio programa iptables. El software (por norma general) se localiza en \/usr\/sbin y el script de arranque en \/etc\/init.d.<\/p>\n

Antes de continuar con iptables y su configuraci\u00f3n es importante remarcar qu\u00e9 se entiende por \u201cescaneo\u201d o \u201cscan\u201d y de qu\u00e9 forma se suele comportar un firewall. El termino \u201cscan\u201d o \u201cescaneo de puertos\u201d se emplea para designar una acci\u00f3n que por medio de uno o varios programas analiza una direcci\u00f3n IP (asociada a un ordenador o maquina conectada en una red, sea una LAN, WAN o INTERNET), en busca de puertos (o canales de comunicaci\u00f3n) y de servicios publicados.<\/p>\n

En un escaneo de puertos, se detecta si existen canales abiertos, cerrados o invisibles\/filtrados. Inicialmente, se podr\u00eda decir que el estado ideal de un puerto puede ser cerrado, pero \u00e9ste estado ofrece informaci\u00f3n al atacante acerca de que existe una m\u00e1quina conectada tras esa direcci\u00f3n IP y que si se profundiza con ataques de protocolo inv\u00e1lidos, heur\u00edsticos y escaneos silenciosos puede darse el caso de traspasar el firewall e infiltrarse en el sistema. Por este motivo, cada vez se emplea m\u00e1s tiempo y recursos en mejorar la seguridad y filtrar y denegar todo lo que no se desea.<\/p>\n

C\u00d3MO FUNCIONA UNA CONEXI\u00d3N TCP<\/strong><\/p>\n

Para entender mejor c\u00f3mo funciona un escaneo es necesario conocer de qu\u00e9 forma funciona el establecimiento de una conexi\u00f3n:<\/p>\n

Cuando un host A quiere establecer una conexi\u00f3n con otro host B, se produce una conversaci\u00f3n como la siguiente:<\/p>\n

1. (A) --> [SYN] --> (B)<\/code>
\nUn paquete SYN es un env\u00edo o una petici\u00f3n TCP de conexi\u00f3n y s\u00f3lo tiene establecida el FLAG (del ingles bandera) SYN. Si se descartaran todas las peticiones SYN, no se podr\u00eda establecer ninguna conexi\u00f3n (\u00e9ste env\u00edo s\u00f3lo tiene establecidos el FLAG SYN y NINGUNO M\u00c1S).<\/p>\n

2. (A) <--[SYN \/ ACK]<--(B)<\/code><\/p>\n

Es en este paso donde el host B, si est\u00e1 escuchando comunicaciones en el mismo puerto o canal por el cual transmite el host A, \u00e9ste en responde a su petici\u00f3n o \u201csaludo\u201d, se contestar\u00e1 con un SYN\/ACK, dando a entender que acepta su petici\u00f3n, (\u00e9ste env\u00edo s\u00f3lo tiene establecidos los FLAGS SYN y ACK y NING\u00daN OTRO). Si por el contrario, el HOST B, no atiende a conexiones entrantes, responde con un paquete RST se entiende que el puerto est\u00e1 cerrado. Por \u00faltimo, si el host A no recibe ninguna respuesta o recibe un paquete ICMP Port Unreachable (puerto no disponible), el host A interpreta que est\u00e1 filtrado.<\/p>\n

3. (A) -- > [ACK] -- > (B)<\/code>
\nCuando se recibe la confirmaci\u00f3n, el primer HOST responde con un ACK y la conexi\u00f3n se da por establecida y es desde entonces que cualquier otro env\u00edo TCP que pertenezca a esa conexi\u00f3n tendr\u00e1 establecida ese FLAG.<\/p>\n

Para este tipo de conversaci\u00f3n, el escaneo m\u00e1s \u00fatil es el \u201cFull Scan\u201d que consta de un an\u00e1lisis puerto a puerto enviando una petici\u00f3n de conexi\u00f3n tal y como se comentaba anteriormente, pero es costosa en tiempo y no demasiado eficiente. El escaneo m\u00e1s r\u00e1pido es el \u201cHalf Open\u201d que imita al anterior, con la diferencia de que en cuanto se recibe la confirmaci\u00f3n de disponibilidad (paso 2), se entiende que el puerto est\u00e1 abierto y no pierde m\u00e1s tiempo enviando la respuesta ACK del paso 3. As\u00ed pues, \u00e9ste \u00faltimo es uno de los mecanismos b\u00e1sicos para conocer los puertos de un host y es en \u00e9l en el que se ha de centrar un administrador de sistemas y prevenir sus efectos.<\/p>\n

Tal y como se comentaba anteriormente, el netfilter\/iptables proporciona numerosas t\u00e9cnicas utilizando scripts y programas, y es con ellos donde el administrador o encargado del firewall se convierte en un programador para construir paso a paso un firewall robusto y seguro.<\/p>\n

DEFINICI\u00d3N DE REGLAS<\/strong><\/p>\n

Iptables permite al administrador definir reglas acerca de qu\u00e9 hacer con los paquetes. Las reglas se agrupan en cadenas: cada cadena es una lista ordenada de reglas. A su vez, las cadenas se agrupan en tablas y cada tabla est\u00e1 asociada con un tipo diferente de procesamiento de paquetes.<\/p>\n

Iptables proporciona por defecto tres cadenas b\u00e1sicas (INPUT, OUTPUT y FORWARD: ENTRADA, SALIDA y REENV\u00cdO) y el administrador puede crear tantas como desee. A su vez, tambi\u00e9n proporciona tres tablas con ciertas cadenas predefinidas las cuales en orden de relevancia y prioridad son:<\/p>\n

- Mangle: altera paquetes especiales.
\n- Nat: iptables act\u00faa como router.
\n- Filter: iptables act\u00faa como cortafuegos.<\/p>\n

La tabla mangle, es la responsable de ajustar las opciones de los paquetes, como por ejemplo, la calidad de servicio (QoS\/TOS). Todos los paquetes pasan por esta tabla debido a que est\u00e1 dise\u00f1ada para efectos avanzados.<\/p>\n

La tabla nat table, es la responsable de configurar las reglas de reescritura de direcciones o de puertos de los paquetes. El primer paquete en cualquier conexi\u00f3n pasa a trav\u00e9s de esta tabla; los veredictos determinan c\u00f3mo van a reescribirse todos los paquetes de esa conexi\u00f3n.<\/p>\n

La tabla filter, es la responsable del filtrado (es decir, de rechazar, bloquear o permitir que un paquete contin\u00fae su camino). Todos los paquetes pasan a trav\u00e9s de la tabla de filtros.<\/p>\n

Una vez que el administrador entiende la estructura del iptables, ya puede empezar a dise\u00f1ar la su estructura.<\/p>\n

C\u00f3mo todo script, en linux, se ha de empezar definiendo la cabecera y las posibles variables que se vayan a utilizar:<\/p>\n


\n#!\/bin\/sh # indica el shell de ejecuci\u00f3n.
\nIPTABLES=\/usr\/sbin\/iptables # especifica la ruta del iptables (el programa).
\nEXTIF=eth0 # indica el interfaz de entrada al firewall.
\nINTIF=eth1 # indica el interfaz de salida del firewall.
\n<\/code><\/p>\n

\u00c9stas no son todas las variables que se pueden utilizar, pero si son las b\u00e1sicas, m\u00e1s adelante y conforme sean necesarias, se pueden ir definiendo m\u00e1s.<\/p>\n

POL\u00cdTICAS POR DEFECTO<\/strong><\/p>\n

Antes de empezar a definir las reglas, cadenas y tablas, se ha de especificar una pol\u00edtica por defecto que establecer\u00e1 el principio de actuaci\u00f3n ante el tr\u00e1fico de la red. Dicha pol\u00edtica puede ser permisiva (ACCEPT) dejando pasar todo el tr\u00e1fico siempre y cuando no se indique lo contrario, o cerrado (DROP), el cual por defecto descartar\u00e1 todo el trafico.<\/p>\n

En modo por defecto que se utilizar\u00e1 en esta explicaci\u00f3n, es DROP, ya que asegura que todo el tr\u00e1fico que no se permita expl\u00edcitamente en las reglas y cadenas ser\u00e1 descartado.<\/p>\n


\n###### Pol\u00edtica por defecto DROP
\n$IPTABLES -P INPUT DROP
\n$IPTABLES -P OUTPUT DROP
\n$IPTABLES -P FORWARD DROP
\n<\/code><\/p>\n

REGISTRO EN LOGS DEL TR\u00c1FICO RECHAZADO<\/strong><\/p>\n

El siguiente paso, es definir las variables para los logs de todo el tr\u00e1fico que se descartar\u00e1, ya que esto, permite su an\u00e1lisis en tiempo real.<\/p>\n


\n###### Variable para Log de los REJECT
\n$IPTABLES -N DROP_IN_LOG # se crea una nueva cadena (a no ser que ya exista) de nombre DROP_IN_LOG
\n$IPTABLES -F DROP_IN_LOG # se borra el contenido de la cadena por si ya exist\u00eda.
\n$IPTABLES -A DROP_IN_LOG -j DROP # se a\u00f1ade una regla que indica a la variable creada que \u00fanicamente registre los DROPs
\n<\/code><\/p>\n


\n$IPTABLES -N DROP_FWRD_LOG
\n$IPTABLES -F DROP_FWRD_LOG
\n$IPTABLES -A DROP_FWRD_LOG -j DROP
\n<\/code><\/p>\n


\n$IPTABLES -N DROP_OUT_LOG
\n$IPTABLES -F DROP_OUT_LOG
\n$IPTABLES -A DROP_OUT_LOG -j DROP
\n<\/code><\/p>\n

REGISTRO EN LOGS DEL TR\u00c1FICO DESCARTADO<\/strong><\/p>\n

Adicionalmente, se pueden a\u00f1adir reglas para que en el log del sistema se pueda ver el tr\u00e1fico descartado:<\/p>\n


\n$IPTABLES -A DROP_IN_LOG -p ICMP -m limit --limit 10\/minute -j LOG --log-prefix \"FIREWALL_INPUT_ICMP_DROP \"
\n$IPTABLES -A DROP_IN_LOG -p TCP -m limit --limit 10\/minute -j LOG --log-prefix \"FIREWALL_INPUT_TCP_DROP \"
\n$IPTABLES -A DROP_IN_LOG -p UDP -m limit --limit 10\/minute -j LOG --log-prefix \"FIREWALL_INPUT_UDP_DROP \"
\n<\/code><\/p>\n

con el par\u00e1metro \u201c-p\u201d se indica que el protocolo sobre el cual va dirigida la regla, puede ser TCP, UDP o ICMP.<\/p>\n

Se puede mejorar para el tr\u00e1fico entrante a\u00f1adiendo las siguientes reglas:<\/p>\n


\n$IPTABLES -A DROP_IN_LOG -p tcp -i eth0 -j REJECT --reject-with tcp-reset
\n$IPTABLES -A DROP_IN_LOG -p udp -i eth0 -j REJECT --reject-with icmp-host-unreachable
\n$IPTABLES -A DROP_IN_LOG -p icmp -i eth0 -j REJECT --reject-with icmp-host-unreachable
\n<\/code><\/p>\n

Con estas reglas, lo que se consigue es que ante una petici\u00f3n entrante para una conexi\u00f3n no definida:<\/p>\n

a) El paquete TCP se rechace con otro paquete TCP pero con un FLAG RST, evitando que se responda con un SYN\/ACK que de cara al scan significar\u00eda que hay un sistema detr\u00e1s respondiendo a la petici\u00f3n.
\nb) El paquete UDP\/ICMP se rechace con una respuesta de DESTINO NO ALCANZABLE.<\/p>\n

Tambi\u00e9n en respuesta a la petici\u00f3n de conexi\u00f3n, sobre el protocolo TCP, se podr\u00eda substituir reject-with tcp-reset por reject-with icmp-host-unreachable.<\/p>\n

NOTA:<\/strong> tener en cuenta, que el bloqueo total de los ICMP puede afectar al QoS de la l\u00ednea.<\/p>\n

MODULOS DE KERNEL<\/strong><\/p>\n

El siguiente paso es cargar m\u00f3dulos del kernel que ayudar\u00e1n y facilitar\u00e1n en gran medida la protecci\u00f3n general del sistema:<\/p>\n

1.<\/strong> Para poder hacer forwards de los paquetes entre la red externa (WAN-internet) del firewall y la LAN interna. Sin este m\u00f3dulo, no se podr\u00edan utilizar reglas FORWARD ya que cada interfaz ser\u00eda independiente y la LAN estar\u00eda aislada al no disponer de salida al exterior.<\/p>\n


\necho 1 > \/proc\/sys\/net\/ipv4\/ip_forward
\n<\/code><\/p>\n

2.<\/strong> \u00c9ste m\u00f3dulo ofrece una protecci\u00f3n frente el Spoofing basada en enmascarar o suplantar la identidad. IP spoofing, consiste en que un atacante gana acceso no autorizado a un equipo o a una red haciendo parecer que un mensaje malicioso viene de una m\u00e1quina confiable haciendo \"spoofing\" de la direcci\u00f3n IP de esa m\u00e1quina<\/p>\n


\necho 1 > \/proc\/sys\/net\/ipv4\/conf\/ * \/rp_filter
\n<\/code><\/p>\n

3.<\/strong> El m\u00f3dulo Explicit Congestion Notification (ECN) proporciona un control de congesti\u00f3n en la red que hace que los paquetes se enruten hacia redes menos congestionadas de tr\u00e1fico y con un mayor ancho de banda en vez de enrutar hacia el camino m\u00e1s corto. En teor\u00eda, es recomendable tenerlo activado pero presenta algunos inconvenientes ya que existen todav\u00eda dispositivos antiguos tales como routers, firewalls, etc. que tratan los paquetes ECN como si fueran malformados y los descartan, haciendo que la comunicaci\u00f3n se rompa y el usuario no sepa por donde falla. Es por eso que se recomienda deshabilitar el m\u00f3dulo si se detectan interrupciones del tr\u00e1fico.
\n
\necho 0 > \/proc\/sys\/net\/ipv4\/tcp_ecn
\n<\/code><\/p>\n

4.<\/strong> El m\u00f3dulo sync cookies proporciona un control sobre los paquetes SYN, ofreciendo protecci\u00f3n ante ciertos ataques DoS de bomba SYNC. Sync packet flooding es una ataque de denegaci\u00f3n de servicio. En el caso de que un host atacante empezase a mandar de forma masiva paquetes SYNC con la cabecera falseada con una IP de origen falsa el host atacado mandar\u00e1 sus ACK o bien a ning\u00fan host o a un host que no es el que est\u00e1 intentando establecer la comunicaci\u00f3n. Dependiendo del tama\u00f1o de la pila TCP de ese host tratar\u00e1 el paquete ACK de una forma u otra consumiendo el ancho banda disponible hasta llegar a un momento en el que no puedan atender m\u00e1s conexiones, colaps\u00e1ndose y bloqueando las comunicaciones, produci\u00e9ndose una denegaci\u00f3n de servicio.<\/p>\n

Una buena ayuda en la prevenci\u00f3n de este tipo de ataques, es ampliar el tama\u00f1o de las colas en las que se almacena la informaci\u00f3n referente a las peticiones de conexi\u00f3n: net.ipv4.tcp_max_syn_backlog.
\n
\necho 1 > \/proc\/sys\/net\/ipv4\/tcp_syncookies
\n<\/code><\/p>\n

5.<\/strong> Con el m\u00f3dulo icmp_ignore_bogus_error_responses se establece una protecci\u00f3n similar a la anterior, pero con paquetes ICMP para evitar ataques del tipo DoS de bomba ICMP.
\n
\necho 1 > \/proc\/sys\/net\/ipv4\/icmp_ignore_bogus_error_responses
\n<\/code><\/p>\n

6.<\/strong> Activando el modulo ip_dynaddr se consigue que en las conexiones SLIP, PPP, o DHCP con o sin marcaci\u00f3n bajo demanda, el primer paquete no sea rechazado por no tener conexi\u00f3n o l\u00ednea establecida y resuelva tambi\u00e9n dns. En caso contrario, en determinadas circunstancias, la primera conexi\u00f3n es rechazada por no haber un enlace establecido porque es esta primera conexi\u00f3n o intento de conexi\u00f3n, la que activa el marcado o el enlace.<\/p>\n

La activaci\u00f3n de este m\u00f3dulo no es necesaria si se dispone de ip fija o los interfaces no son SLIP, PPP o DHCP.
\n
\necho 1 > \/proc\/sys\/net\/ipv4\/ip_dynaddr
\n<\/code><\/p>\n

7.<\/strong> Con el m\u00f3dulo accept_source_route, se decide si se aceptan paquetes cuyas ruta haya sido prefijada en el origen (source routed packets) o no. \u00c9ste m\u00f3dulo proporciona una seguridad ante escaneos y\/o ataques con rutas pre-establecidas.<\/p>\n

Es importante remarcar, que en redes multil\u00ednea donde la entrada de datos y de salida son diferentes, o con rutas prefijadas en proxies, balanceos de carga o routers, la deshabilitaci\u00f3n de \u00e9ste m\u00f3dulo, conlleva un corte en la transmisi\u00f3n, ya que se descartar\u00e1n dichos paquetes con una ruta ya establecida.
\n
\necho 0 > \/proc\/sys\/net\/ipv4\/conf\/ * \/accept_source_route
\n<\/code><\/p>\n

8.<\/strong> Deshabilitando la aceptaci\u00f3n de paquetes ICMP del tipo Redirect Acceptance con el m\u00f3dulo accept_redirects, se consigue evitar que el enrutado de paquetes cambie del prefijado, ya que en una conexi\u00f3n normal, los paquetes se env\u00edan a un gateway prefijado y consecuentemente a un router, sin embargo, si se recoge un paquete ICMP informando que el enrutado se hace desde otra ip, puede ser se\u00f1al de un ataque Man in the middle.<\/p>\n

No obstante, en redes multiruta la desactivaci\u00f3n de este m\u00f3dulo puede conllevar problemas. Jam\u00e1s deber\u00e1 estar habilitado en un router bien configurado.
\n
\necho 0 > \/proc\/sys\/net\/ipv4\/conf\/ * \/accept_redirects
\n<\/code><\/p>\n

9.<\/strong> En una red, cuando se env\u00edan paquetes ICMP del tipo Redirect Acceptance, significa que existen varios routers y por tanto se ha de notificar. No obstante, si el equipo que env\u00eda ese paquete no es un router, significa que hay una intromisi\u00f3n en la red y que se est\u00e1n enrutando las conexiones por donde no deber\u00edan.<\/p>\n

Nunca es necesario para m\u00e1quinas que no est\u00e1n destinadas a realizar tareas de enrutamiento.
\n
\necho 0 > \/proc\/sys\/net\/ipv4\/conf\/ * \/send_redirects
\n<\/code><\/p>\n

10.<\/strong> La habilitaci\u00f3n de \u00e9ste m\u00f3dulo, conlleva la aceptaci\u00f3n de las redirecciones ICMP que vengan de un router fijo. S\u00f3lo deber\u00e1 ser habilitado en caso de redes con m\u00faltiples routers. Si la red es razonablemente estable y est\u00e1tica, es preferible deshabilitarlo.
\n
\necho 0 > \/proc\/sys\/net\/ipv4\/conf\/ * \/secure_redirects
\n<\/code><\/p>\n

11.<\/strong> Con \u00e9ste m\u00f3dulo, se consigue ignorar los broadcasts, cosa que proporcionar\u00e1 una protecci\u00f3n adicional ante ataques ARP y ARP SPOOFING, en todo caso, la direcci\u00f3n mac que se obtendr\u00eda ser\u00eda la del ROUTER en caso de un ataque desde el exterior. En caso de que el equipo se encargue de enrutar, hay que tener en cuenta otros tipos de protecci\u00f3n adicional.
\n
\necho 1 > \/proc\/sys\/net\/ipv4\/icmp_echo_ignore_broadcasts
\n<\/code><\/p>\n

Con todos estos m\u00f3dulos, se ha incrementado el nivel de seguridad del sistema, a\u00f1adiendo protecci\u00f3n ante SPOOFING, algunos tipos de DOS, paquetes con la ruta modificada y peticiones de rutas (MAN IN THE MIDDLE) y broadcasts.<\/p>\n

Una vez configurado todo lo anterior y con una pol\u00edtica por defecto y sus reglas se tiende a pensar que ya se est\u00e9 suficientemente protegido. Como existen diferentes tipos de scaneos de puertos y aunque el m\u00e1s normal sea el de PING o el SYN Connect, hay scaneos con paquetes falsos o mal formados que se env\u00edan con la esperanza de evitar las reglas y que muchas veces se responden dando al atacante un S\u00cd a su paquete mal-formado.<\/p>\n

Una vez cargados los m\u00f3dulos en el n\u00facleo del sistema, corresponde al siguiente paso el proceso de filtrar expl\u00edcitamente todo lo que no se desea. N\u00f3tese que algunas reglas pueden ser o parecer recurrentes, pero no est\u00e1 dem\u00e1s tener presente dichas reglas y su contenido.<\/p>\n

FILTRADO ICMP<\/strong><\/p>\n

El primer paso es bloquear el primer y m\u00e1s viejo sistema de averiguar si hay o no hay algo o alguien en una IP, es por eso que se bloquear\u00e1n los pings (tr\u00e1fico ICMP) del interfaz de entrada y consecuentemente las respuestas.<\/p>\n


\niptables -A INPUT -i $EXTIF -p icmp --icmp-type echo-reply -j REJECT --reject-with icmp-host-unreachable
\niptables -A OUTPUT -o $EXTIF -p icmp --icmp-type echo-request -j REJECT --reject-with icmp-host-unreachable
\n<\/code><\/p>\n

Estas reglas junto con los m\u00f3dulos previamente cargados, evitar\u00e1n mensajes ICMP no deseados y que en ocasiones pueden llegar a ser perjudiciales para el QoS de la red.<\/p>\n


\n$IPTABLES -N ICMP_NON
\n$IPTABLES -F ICMP_NON
\n$IPTABLES -A ICMP_NON -p icmp --icmp-type redirect -j DROP
\n$IPTABLES -A ICMP_NON -p icmp --icmp-type router-advertisement -j DROP
\n$IPTABLES -A ICMP_NON -p icmp --icmp-type router-solicitation -j DROP
\n$IPTABLES -A ICMP_NON -p icmp --icmp-type address-mask-request -j DROP
\n$IPTABLES -A ICMP_NON -p icmp --icmp-type address-mask-reply -j DROP
\n<\/code><\/p>\n

PROTECCI\u00d3N CONTRA FLOOD<\/strong><\/p>\n

El segundo tipo de escaneo que se va a proceder a bloquear, aunque es un m\u00e9todo ya desfasado, todav\u00eda se utiliza, sobre todo en ataques DoS. Se trata del flood y antes de aplicar las reglas se ha de tener presente el l\u00edmite que se va a imponer, en este caso 30 conexiones por segundo y con un m\u00e1ximo de 60 simult\u00e1neas. Nota a tener en cuenta, es necesario consultar con el administrador de red y sistemas para establecer un l\u00edmite de conexiones suficientemente bajo para evitar el flood, pero suficientemente alto para prestar servicio a las conexiones entrantes.<\/p>\n


\n$IPTABLES -N flood
\n$IPTABLES -F flood
\n$IPTABLES -A flood -m limit --limit 30\/second --limit-burst 60 -j RETURN
\n$IPTABLES -A flood -m limit --limit 30\/second --limit-burst 60 -j LOG --log-prefix \"flood: \"
\n$IPTABLES -A flood -j DROP
\n<\/code><\/p>\n

FILTRADO DE PAQUETES MANIPULADOS<\/strong><\/p>\n

Tal y c\u00f3mo se comentaba anteriormente, en ciertos tipos de escaneos, se pueden falsear los flags tcp y as\u00ed traspasar el firewall, pero tambi\u00e9n se puede falsear el estado, para evitar eso se descartaran todos los paquetes que tengan estados inv\u00e1lidos.<\/p>\n


\n### se descartan paquetes mal formados e inv\u00e1lidos
\n$IPTABLES -N PKT_FAKE
\n$IPTABLES -F PKT_FAKE
\n$IPTABLES -A PKT_FAKE -m state --state INVALID -j DROP
\n$IPTABLES -A PKT_FAKE -p tcp ! --syn -m state --state NEW -j DROP
\n$IPTABLES -A PKT_FAKE -f -j DROP
\n<\/code><\/p>\n

Con este descarte, se consigue descartar todos los paquetes que sean inv\u00e1lidos (-m state --state INVALID), todas las conexiones nuevas que no sean SYN (-p tcp ! --syn -m state --state NEW)* y los paquetes fragmentados (-f).<\/p>\n

*Esta es una caracter\u00edstica que no est\u00e1 demasiado documentada en iptables y que tiene que ver con paquetes que est\u00e1n marcados como nuevas conexiones pero que no tienen establecido el flag SYN, esto se debe a que en determinadas ocasiones se necesita considerar que un paquete puede ser parte de una conexi\u00f3n ya establecida (ESTABLISHED) en, por ejemplo, otro firewall. Es por eso que en una red con dos o m\u00e1s firewalls, puede darse la posibilidad de cuelgue o ca\u00edda de uno de ellos, entonces el segundo acoger\u00eda y absorber\u00eda todo el trafico, sin embargo, este hecho permitir\u00eda que casi cualquier conexi\u00f3n TCP con el estado NEW atravesase el firewall.<\/p>\n

Recordando c\u00f3mo se establec\u00eda una conexi\u00f3n, el siguiente paso en la construcci\u00f3n del firewall es el bloqueo de paquetes inv\u00e1lidos, as\u00ed pues se procede a descartar los paquetes tcp con FLAGS no permitidos y para entender un poco m\u00e1s el tema en cuesti\u00f3n, es necesario entender el paso contrario y que pasa cuando se quiere finalizar una conexi\u00f3n:<\/p>\n

1. (A) --> ACK\/FIN --> (B)
\nEl primer host dice que quiere FINalizar la conexi\u00f3n. Es necesario recordar que hasta que no se acabe, todos los paquetes tcp lleva levantados el FLAG ACK.<\/p>\n

2. (A) <-- ACK <-- (B)
\nSe le responde con un ACK dando a entender que le ha llegado su petici\u00f3n de finalizar.<\/p>\n

3. (A) <-- ACK\/FIN <-- (B)
\nY se le env\u00eda un FINalizar.<\/p>\n

4. (A) --> ACK --> (B)<\/p>\n

Y consecuentemente, \u00e9ste le env\u00eda su ACK y se da por finalizada la conexi\u00f3n.<\/p>\n

\u00c9sta no es la \u00fanica forma para finalizar una conexi\u00f3n, en ciertas ocasiones (timeout, port or host unreachable, etc.), es necesario terminar de forma r\u00e1pida, es por eso que se env\u00eda un paquete RST (reset). No obstante, t\u00e9ngase en cuenta que un RST no siempre o no necesariamente, forma parte de una conexi\u00f3n TCP establecida. Generalmente, suele ir acompa\u00f1ado de un ACK.<\/p>\n

As\u00ed pues, toca a\u00f1adir reglas que descartan esos paquetes TCP que no son correctos.<\/p>\n


\n$IPTABLES -N FLAG_SCAN
\n$IPTABLES -F FLAG_SCAN
\n<\/code><\/p>\n


\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
\n<\/code><\/p>\n

por extensi\u00f3n, sucede lo mismo con los paquetes RST.
\n
\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
\n<\/code><\/p>\n

no obstante, tampoco es una combinaci\u00f3n legal el enviar un paquete TCP solamente con el flag FIN.<\/p>\n


\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags ALL FIN -j DROP
\n<\/code><\/p>\n

por extensi\u00f3n estas otras combinaciones, tambi\u00e9n son ilegales, ya que FIN\/RST y SYN son incompatibles y menos cuando van acompa\u00f1adas de URGente y PSH de datos.<\/p>\n


\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags SYN,FIN,PSH SYN,FIN,PSH -j DROP
\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags SYN,FIN,RST SYN,FIN,RST -j DROP
\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags SYN,FIN,RST,PSH SYN,FIN,RST,PSH -j DROP
\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
\n<\/code><\/p>\n

esta \u00faltima tambi\u00e9n se podr\u00eda interpretar como que esta marcada para hacer un reset (RST), pero a diferencia de FINalizar, a los reset no se les devuelven un ACK. De todas maneras, es incompatible un FLAG RST con un FIN y en ning\u00fan caso con un SYN.<\/p>\n

Otro tipo de escaneo es el conocido por NULL SCAN o NULL Flag, Se basa en enviar paquetes TCP sin ning\u00fan FLAG, esta t\u00e9cnica establece que el equipo remoto ha de responder con un paquete RST, ACK si el puerto esta cerrado y nada si esta abierto.<\/p>\n


\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags ALL NONE -j DROP
\n<\/code><\/p>\n

En contraposici\u00f3n, el escaneo mediante la activaci\u00f3n de todos los FLAGS se le conoce como XMAS. Los ataques con esta t\u00e9cnica en equipos Windows nunca han respondido, si bien antiguamente era bastante eficaz con pilas TCP\/IP del primitivo BSD, es decir, Linux, Solaris y las distribuciones basadas en BSD. No obstante en la actualidad ya no responden a estos abusos del protocolo, salvo equipos antiguos.<\/p>\n


\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags ALL ALL -j DROP
\n<\/code>
\nVariante NMAP-XMAS
\n
\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
\n<\/code>
\nVariante XMAS-PSH.
\n
\n$IPTABLES -A FLAG_SCAN -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
\n<\/code><\/p>\n

En todos estos casos, se puede sustituir el destino DROP por el REJECT --reject-with icmp-host-unreachable, falseando una respuesta.<\/p>\n

Una vez implementadas estas reglas, s\u00f3lo queda aplicarlas al firewall y se obtendr\u00e1 una protecci\u00f3n a\u00fan mayor y bastante m\u00e1s efectiva ante los escanos de puertos.<\/p>\n

CONCLUSIONES<\/strong><\/p>\n

Como conclusi\u00f3n al leer este art\u00edculo, se podr\u00eda decir que la construcci\u00f3n restrictiva mediante DROP, la carga de m\u00f3dulos en el kernel y el bloqueo de paquetes TCP, es bastante segura y activa, pudiendo controlar los paquetes de entrada y la respuesta.<\/p>\n

No obstante, siempre cabe la posibilidad de errores humanos o una incorrecta implementaci\u00f3n en el sistema o terceros errores que pueden dar pie a un fallo de seguridad. Por todo ello, nunca se ha de establecer un s\u00f3lo punto de control y barrera, sino que es recomendable disponer de varios firewalls en paralelo (tolerancia a fallos y redundancia) y en serie en cada red o subred. Tambi\u00e9n es recomendable disponer un sistema de IDS o NIDS para aumentar el control y vigilancia de la red.<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"

Tomado de: http:\/\/www.hacktimes.com\/?q=node\/49 Enviado por suzdal el Dom, 04\/11\/2007 - 20:02 El siguiente art\u00edculo se va a centrar en c\u00f3mo configurar un firewall iptables de forma segura y en c\u00f3mo evitar que, ante un escaneo de puertos, se obtenga informaci\u00f3n diversa acerca del Sistema Operativo instalado en el servidor escaneado que pueda ayudar a descubrir […]<\/p>\n","protected":false},"author":401,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[866],"tags":[],"class_list":["post-68","post","type-post","status-publish","format-standard","hentry","category-linux"],"_links":{"self":[{"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/posts\/68","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/users\/401"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/comments?post=68"}],"version-history":[{"count":3,"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/posts\/68\/revisions"}],"predecessor-version":[{"id":70,"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/posts\/68\/revisions\/70"}],"wp:attachment":[{"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/media?parent=68"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/categories?post=68"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.espol.edu.ec\/fsanchez\/wp-json\/wp\/v2\/tags?post=68"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}