Los que tenemos servidores dedicados y gestionamos varios dominios sabemos lo importante que es el tener todo optimizado y monitorizado ya que, como es lógico, los recursos son limitados. A cualquier administrador de sistemas o propietario de un blog que tuviese la suerte de que una de sus noticias llegase a la portada de menéame, por ejemplo, sabrá lo que es sufrir el envite de millones de visitas en poco tiempo y ver cómo el servidor donde está alojado, por decirlo de alguna manera, se “estresa”.

Para los que no tenemos tantos recursos como una gran empresa o para los que quieran asegurarse la estabilidad y carga de sus webs pueden tener en CloudFlare su solución. CloudFlare es un CDN, por explicarlo sencillamente, una red de servidores (como el tuyo) que alojan copias del mismo contenido para repartirse la carga de visitas y que no caiga todo el tráfico siempre en el mismo equipo.

Una ventaja enorme de CloudFlare es su facilidad de uso ya que la configuración de un balanceador de carga puede resultar tediosa si no tenemos experiencia. Con éste servicio, en 5 sencillos pasos tendremos nuestro CDN funcionando y accesible. Sólo podremos aplicarlo a servidores dedicados o a aquellos donde tengamos acceso a las DNS puesto que será lo que necesitemos ajustar.

Podemos imaginarnos entonces que si dispusiésemos de dos equipos balanceando la carga, cuando tuviésemos 1 millón de visitas, cada uno sólo tendría que cargar con la mitad (500 mil). Si esta idea genérica la extrapolamos a una red de digamos, 200 ordenadores, la carga que podrán soportar será muchísimo mayor. Además, a esto tendremos que sumar servidores geolocalizados para reducir tiempos de carga (si soy de Madrid, quiero un servidor cerquita, no en China)

CloudFlare dispone de 3 planes diferentes: Gratuito, Pro y Enterprise. Para la mayoría de usuarios sencillos, la versión 100% free le aportará todo lo que necesita y la configuración no le llevará más de 5 minutos. Para profesionales o webs con millones de visitas, las opciones Pro o Enterprise tendrán un coste de 20$ mensuales (Pro) o un plan personalizado.

Click here to view the embedded video.

Via: wwwhats new

Cloud Hosting y Cloud Computing a tu alcance

La virtualización es la introducción de una capa abstracción dispuesta en una máquina física que permite la emulación de múltiples instancias o máquinas sobre un mismo hardware, denominadas máquinas virtuales. La virtualización no es algo nuevo, es una tecnología que lleva bastante tiempo en desarrollo y en uso, si bien es cierto, que los avances en los desarrollos, la evolución del hardware y la necesidad de una rapidez en despliegue de aplicaciones junto con un abaratamiento en los costes, han potenciado mucho el uso de este tipo de tecnologías.

Esta capacidad de ejecutar varias instancias sobre un mismo hardware, permite un mayor aprovechamiento de las infraestructuras instaladas (que normalmente suelen tener un rendimiento por debajo del 50%, según estudios de diversos fabricantes), maximizando el retorno de inversión y minimizando nuevas inversiones. Un mejor aprovechamiento de los recursos y, por tanto, el decremento en inversiones en nuevas infraestructuras, permitirán un crecimiento controlado del centro de datos, con el consiguiente ahorro de espacio y un ahorro en energía (por la alimentación de la granja de servidores como por el ahorro en climatización). Desde el punto de vista de la administración de sistemas, la virtualización permite centralizar la gestión, desplegar de manera rápida aplicaciones o mejorar la continuidad del negocio, permitiendo rápidas recuperaciones ante fallos o desastres.

Los beneficios de la virtualización de los centros de datos son múltiples:

• Hoy en día, casi todas las alternativas para virtualizar servidores incluyen una gestión centralizada de la infraestructura de virtualización, normalmente con un interfaz sencillo.
• La infraestructura de virtualización permite un rápido despliegue de servidores, lo cual facilita mucho la gestión y facilita la administración y despliegue de entornos de desarrollo o de producción, sin necesidad de adquirir nuevo hardware dedicado en exclusiva e infrautilizado. El nivel de aprovechamiento de las infraestructuras aumenta exponencialmente, sacándose el máximo partido a las inversiones realizadas y minimizando nuevas inversiones, con las consiguientes ventajas derivadas (crecimiento sostenido del centro de datos, menor consumo energético, etc). Además, se minimizan las interrupciones de servicio por paradas programadas gracias a que muchos sistemas incluyen la migración en caliente de instancias que están en un mismo clúster.
• El TCO (Coste total de propiedad) del desarrollo o la implantación de cualquier nueva aplicación baja, ya que los costes asociados a la operación (administración, configuración, mantenimiento, etc) y a la infraestructura (servidores, rack, electrónica de red, etc) son compartidos con el resto de aplicaciones.

A día de hoy existen múltiples opciones para la creación y gestión de máquinas virtuales (libres, gratuitas y bajo licencia), por lo que el espectro es bastante amplio así como los servicios, ventajas e inconvenientes de cada uno de los modelos.

La virtualización ha llegado para quedarse, es una tecnología sólida y muy flexible que permite, por una pequeña inversión, un enorme ahorro de costes. En épocas de austeridad económica, maximizar el uso de las infraestructuras existentes, minimizar nuevas inversiones, recortar los gastos de operación y una apuesta por la eficiciencia energética, son factores claves para las empresas hoy en día. La virtualización de servidores es el primer paso en la consolidación de los centros de datos, es decir, la facilidad de despliegue del cloud computing proviene precisamente de la facilidad de despliegue que ofrece la virtualización.

Personalmente, es una de mis tecnologías favoritas dentro del centro de datos. El nivel de ahorro de costes que hemos conseguido es muy interesante sumado a la rapidez de respuesta ante nuevos proyectos o necesidades. Aún recuerdo la época en la que para arrancar un proyecto necesitábamos casi un mes para ponerlo en marcha, el tiempo de adquisición de un nuevo servidor, que siempre se adquirían por duplicado (uno para pre-producción y otro para producción). Ahora, salvo proyectos muy especiales, las necesidades se encuentran centradas, principalmente, en la adquisición de memoria RAM y espacio de almacenamiento.

Y es, precisamente, la necesidad de memoria RAM y el espacio de almacenamiento compartido, además de la capacidad de proceso (que hoy en día es bastante alta y que incluye soporte de virtualización), los factores claves que determinan cuánto podemos “exprimir” nuestras infraestructuras, ya que, aunque se compartan los recursos hardware, se necesita una base de partida sólida para comenzar el despliegue de instancias virtuales, por lo que la cantidad de memoria RAM disponible no puede ser baja. El almacenamiento compartido no es obligatorio, pero sí que es un elemento importante que facilita el despliegue.

La verdad, creo que tenemos virtualización para muchos años.

Fuente Bitelia

El equipo de TurnKey ha realizado un grandísimo trabajo con ésta aplicación. Con TKLBAM, como ellos mismos la llaman (y no me extraña porque hay que ver qué nombrecito le han puesto), los programadores han intentado imaginarse su sistema de copias ideal y plasmarlo en un servicio al alcance de todos.

Para llegar a materializar lo que tenían en mente han puesto las ideas sobre la mesa: Automático (Pain Free) para no tener que preocuparse de nada, fácil de migrar para evitar perder horas y horas ajustando nuestras restauraciones, integrado en el sistema y que lo reconozca para evitar restaurar archivos que ya son idénticos en ambas partes y, por supuesto, muy seguro y a prueba de manazas.

Si las ventajas anteriores os parecen pocas, podéis pegarle un vistazo a las siguientes:

• Podemos migrar configuraciones y archivos entre diferentes distribuciones, diferentes versiones de la misma distro o incluso entre 64 y 32 bits.
• Copiar y restaurar máquinas locales en otras remotas.
• Seguridad en nuestras copias. Encriptadas mediante AES e incrementales podemos siempre tener la seguridad de no perder nada.

Y mucho más, todo ésto bajo la filosofía Open Source. Un vídeo para poder abrir boca:

Información básica:

• Plataforma: Linux
• Licencia: Open Source
• Precio: Gratuito
• Enlace de descarga: TKLBAM

BIND (acrónimo de Berkeley Internet Name Domain) es una implementación del protocolo DNS y provee una implementación libre de los principales componentes del Sistema de Nombres de Dominio, los cuales incluyen:
• Un servidor de sistema de nombres de dominio (named).
• Una biblioteca resolutoria de sistema de nombres de dominio.
• Herramientas para verificar la operación adecuada del servidor DNS (bind-utils).

El Servidor DNS BIND es ampliamente utilizado en la Internet (99% de los servidores DNS) proporcionando una robusta y estable solución.

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

DNS (Domain Name System).

DNS (acrónimo de Domain Name System) es una base de datos distribuida y jerárquica que almacena la información necesaria para los nombre de dominio. Sus usos principales son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico correspondientes para cada dominio. El DNS nació de la necesidad de facilitar a los seres humanos el acceso hacia los servidores disponibles a través de Internet permitiendo hacerlo por un nombre, algo más fácil de recordar que una dirección IP.

Los Servidores DNS utilizan TCP y UDP en el puerto 53 para responder las consultas. Casi todas las consultas consisten de una sola solicitud UDP desde un Cliente DNS seguida por una sola respuesta UDP del servidor. TCP interviene cuando el tamaño de los datos de la respuesta exceden los 512 bytes, tal como ocurre con tareas como transferencia de zonas.

NIC (Network Information Center).

NIC (acrónimo de Network Information Center o Centro de Información sobre la Red) es una institución encargada de asignar los nombres de dominio en Internet, ya sean nombres de dominio genéricos o por países, permitiendo personas o empresas montar sitios de Internet mediante a través de un ISP mediante un DNS. Técnicamente existe un NIC por cada país en el mundo y cada uno de éstos es responsable por todos los dominios con la terminación correspondiente a su país. Por ejemplo: NIC México es la entidad encargada de gestionar todos los dominios con terminación .mx, la cual es la terminación correspondiente asignada a los dominios de México.

FQDN (Fully Qualified Domain Name).

FQDN (acrónimo de Fully Qualified Domain Name o Nombre de Dominio Plenamente Calificado) es un Nombre de Dominio ambiguo que especifica la posición absoluta del nodo en el árbol jerárquico del DNS. Se distingue de un nombre regular porque lleva un punto al final.

Como ejemplo: suponiendo que se tiene un dispositivo cuyo nombre de anfitrión es «maquina1» y un dominio llamado «dominio.com», el FQDN sería «maquina1.dominio.com.», así es que se define de forma única al dispositivo mientras que pudieran existir muchos anfitriones llamados «maquina1», solo puede haber uno llamado «maquina1.dominio.com.». La ausencia del punto al final definiría que se pudiera tratar tan solo de un prefijo, es decir «maquina1.dominio.com» pudiera ser un dominio de otro más largo como «maquina1.dominio.com.mx».

La longitud máxima de un FQDN es de 255 bytes, con una restricción adicional de 63 bytes para cada etiqueta dentro del nombre del dominio. Solo se permiten los caracteres A-Z de ASCII, dígitos y el carácter «-». No se distinguen mayúsculas y minúsculas.

Desde 2004, a solicitud de varios países de Europa, existe el estándar IDN (acrónimo de Internationalized Domain Name) que permite caracteres no-ASCII, codificando caracteres Unicode dentro de cadenas de bytes dentro del conjunto normal de caracteres de FQDN. Como resultado, los limites de longitud de los nombres de dominio IDN dependen directamente del contenido mismo del nombre.

Componentes de un DNS.

Los DNS operan a través de tres componentes: Clientes DNS, Servidores DNS y Zonas de Autoridad.

Clientes DNS.

Son programas que ejecuta un usuario y que generan peticiones de consulta para resolver nombres. Básicamente preguntan por la dirección IP que corresponde a un nombre determinado.

Servidores DNS.

Son servicios que contestan las consultas realizadas por los Clientes DNS. Hay dos tipos de servidores de nombres:

Un gran número de problemas de operación de servidores DNS se atribuyen a las pobres opciones de servidores secundarios para las zona de DNS. De acuerdo al RFC 2182, el DNS requiere que al menos tres servidores existan para todos los dominios delegados (o zonas).

Una de las principales razones para tener al menos tres servidores para cada zona es permitir que la información de la zona misma esté disponible siempre y forma confiable hacia los Clientes DNS a través de Internet cuando un servidor DNS de dicha zona falle, no esté disponible y/o esté inalcanzable.

Contar con múltiples servidores también facilita la propagación de la zona y mejoran la eficiencia del sistema en general al brindar opciones a los Clientes DNS si acaso encontraran dificultades para realizar una consulta en un Servidor DNS. En otras palabras: tener múltiples servidores para una zona permite contar con redundancia y respaldo del servicio.

Con múltiples servidores, por lo general uno actúa como Servidor Maestro o Primario y los demás como Servidores Esclavos o Secundarios. Correctamente configurados y una vez creados los datos para una zona, no será necesario copiarlos a cada Servidor Esclavo o Secundario, pues éste se encargará de transferir los datos de manera automática cuando sea necesario.

Los Servidores DNS responden dos tipos de consultas:

Zonas de Autoridad.

Permiten al Servidor Maestro o Primario cargar la información de una zona. Cada Zona de Autoridad abarca al menos un dominio y posiblemente sus sub-dominios, si estos últimos no son delegados a otras zonas de autoridad.

La información de cada Zona de Autoridad es almacenada de forma local en un fichero en el Servidor DNS. Este fichero puede incluir varios tipos de registros:

Las zonas que se pueden resolver son:

Zonas de Reenvío.

Devuelven direcciones IP para las búsquedas hechas para nombres FQDN (Fully Qualified Domain Name).

En el caso de dominios públicos, la responsabilidad de que exista una Zona de Autoridad para cada Zona de Reenvío corresponde a la autoridad misma del dominio, es decir, y por lo general, quien esté registrado como autoridad del dominio tras consultar una base de datos WHOIS. Quienes compran dominios a través de un NIC (por ejemplo ejemplo: www.nic.mx) son quienes se hacen cargo de las Zonas de Reenvío, ya sea a través de su propio Servidor DNS o bien a través de los Servidores DNS de su ISP.

Salvo que se trate de un dominio para uso en una red local, todo dominio debe ser primero tramitado con un NIC como requisito para tener derecho legal a utilizarlo y poder propagarlo a través de Internet.

Zonas de Resolución Inversa.

Devuelven nombres FQDN (Fully Qualified Domain Name) para las búsquedas hechas para direcciones IP.

En el caso de segmentos de red públicos, la responsabilidad de que exista de que exista una Zona de Autoridad para cada Zona de Resolución Inversa corresponde a la autoridad misma del segmento, es decir, y por lo general, quien esté registrado como autoridad del segmento tras consultar una base de datos WHOIS.

Los grandes ISP, y en algunos casos algunas empresas, son quienes se hacen cargo de las Zonas de Resolución Inversa.

Herramientas de búsqueda y consulta.

Mandato host.

El mandato host una herramienta simple para hacer búsquedas en Servidores DNS. Es utilizada para convertir nombres en direcciones IP y viceversa.

De modo predefinido realiza las búsquedas en las Servidores DNS definidos en el fichero /etc/resolv.conf, pudiendo definirse de manera opcional el Servidor DNS a consultar.

host www.alcancelibre.org

Lo anterior realiza una búsqueda en los Servidores DNS definidos en el fichero /etc/resolv.conf del sistema, devolviendo como resultado una dirección IP.

host www.alcancelibre.org 200.33.146.217

Lo anterior realiza una búsqueda en los Servidor DNS en la dirección IP 200.33.146.217, devolviendo una dirección IP como resultado.

Mandato dig.

El mandato dig (domain information groper) es una herramienta flexible para realizar consultas en Servidores DNS. Realiza búsquedas y muestra las respuestas que son regresadas por los servidores que fueron consultados. Debido a su flexibilidad y claridad en la salida es que la mayoría de los administradores utilizan dig para diagnosticar problemas de DNS.

De modo predefinido realiza las búsquedas en las Servidores DNS definidos en el fichero /etc/resolv.conf, pudiendo definirse de manera opcional el Servidor DNS a consultar. La sintaxis básica sería:

dig @servidor nombre TIPO

Donde servidor corresponde al nombre o dirección IP del Servidor DNS a consultar, nombre corresponde al nombre del registro del recurso que se está buscando y TIPO corresponde al tipo de consulta requerido (ANY, A, MX, SOA, NS, etc.)

Ejemplo:

dig @200.33.146.209 alcancelibre.org MX

Lo anterior realiza una búsqueda en el Servidor DNS en la dirección IP 200.33.146.209 para los registros MX para el dominio alcancelibre.org.

dig alcancelibre.org NS

Lo anterior realiza una búsqueda en los Servidores DNS definidos en el fichero /etc/resolv.conf del sistema para los registros NS para el dominio alcancelibre.org.

dig @200.33.146.217 alcancelibre.org NS

Lo anterior realiza una búsqueda en los Servidor DNS en la dirección IP 200.33.146.217 para los registros NS para el dominio alcancelibre.org.

Mandato jwhois (whois).

El mandato jwhois es una herramienta de consulta a través de servidores WHOIS. La sintaxis básica es:

jwhois dominio

Ejemplo:

jwhois alcancelibre.org

Loa anterior regresa la información correspondiente al dominio alcancelibre.org.

Equipamiento lógico necesario.

Instalación a través de yum.

Si se utiliza de CentOS 5, Red Hat™ Enterprise Linux 5 o White Box Enterprise Linux 5, o versiones posteriores, se puede instalar utilizando lo siguiente:

yum -y install bind bind-chroot bind-utils caching-nameserver

Instalación a través de Up2date

Si se utiliza de Red Hat™ Enterprise Linux 4, o versiones posteriores, se puede instalar utilizando lo siguiente:

up2date -i bind bind-chroot bind-utils caching-nameserver

Procedimientos.

SELinux y el servicio named.

A mediados de 2008, Common Vulnerabilities and Exposures List y US-CERT reportaron que el investigador Dan Kaminsky descubrió que varias implementaciones de DNS (BIND 8 y 9 antes de 9.5.0-P1, 9.4.2-P1, y 9.3.5-P1; Microsoft DNS en todas las versiones de Windows 2000 SP4, XP SP2 y SP3, y Server 2003 SP1 y SP2). La vulnerabilidad permite a atacantes remotos falsificar tráfico DNS a través de ciertas técnicas de envenamiento de cache contra servidores de resolución recursiva (es decir cuando se usa la opción allow-recursion abierta a todo el mundo, como ocurre en los servidores DNS públicos), y se relaciona a insuficiente aleatoriedad de las ID de transacción y puertos de origen. Es decir, vulnerabilidad de entropía de insuficiencia de zócalos (sockets) de DNS (DNS Insufficient Socket Entropy Vulnerability). En otras palabras, un atacante puede contaminar el cache de un servidor DNS y hacer que los clientes se conecten hacia direcciones falsas. Es importante aclarar que esta es realmente una vulnerabilidad del protocolo DNS.

SELinux protege casi por completo al servicio named contra la vulnerabilidad anteriormente descrita. Es por tal motivo que es importante utilizar SELinux.

A fin de que SELinux permita al servicio named trabajar con permisos de escritura para zonas maestras, es decir un esquema de servidor maestro con servidores esclavos o bien un servidor DNS dinámico, utilice el siguiente mandato:

setsebool -P named_write_master_zones 1

Para definir que se desactive la protección de SELinux para el servicio named, haciendo que todo lo anteriormente descrito en esta sección pierda sentido y el servidor sea parcialmente susceptible a la vulnerabilidad de Kaminski, utilice el siguiente mandato:

setsebool -P named_disable_trans 1

Sí realiza el procedimiento anterior, es importante configurar la función de consultas recursivas exclusivamente para redes en la que se confíe plenamente.

Sí se va a configurar un DNS dinámico, SELinux impedirá crear los ficheros *.jnl (journal, ficheros de diario) correspondientes. Las zonas de DNS dinámicas deben ser almacenadas en directorios específicos que solo contengan zonas dinámicas. Sugiero crear el directorio /var/named/chroot/var/named/dynamics para tal fin y configurar éste para qué pertenezca al usuario y grupo named, tenga permisos de lectura, escritura y ejecución para el usuario y grupo named (770) y tenga los contextos de SELinux de usuario de sistema (system_u), rol de objeto (object_r) y tipo cache del servicio named (named_cache_t) a fin de permitir escritura en este directorio.

cd /var/named/chroot/var/named/
mkdir dynamics/
chmod 770 dynamics/
chown named:named dynamics/
chcon -u system_u -r object_r -t named_cache_t dynamics/

Cualquier fichero de zona que se vaya a utilizar a través del servicio named, debe contar con los contextos de SELinux de usuario de sistema (system_u), rol de objeto (object_r) y tipo zona del servicio named (named_zone_t). En el siguiente ejemplo se utiliza el mandato chcon para cambiar los contextos del fichero mi-dominio.zone y definir los contextos de SELinux mencionados:

cd /var/named/chroot/var/named/
chcon -u system_u -r object_r -t named_zone_t mi-dominio.zone

Preparativos.

Idealmente se deben definir primero los siguiente datos:

Es importante tener bien en claro que los puntos 2, 3 y 4 involucran datos que deben existir previamente y estar plenamente resueltos por otro servidor DNS; Lo anterior quiere decir no pueden utilizar datos que sean parte o dependan del mismo dominio que se pretende resolver. De igual modo, el servidor donde se implementará el DNS deberá contar con un nombre FQDN y que esté previa y plenamente resuelto en otro DNS.

Como regla general se generará una zona de reenvío por cada dominio sobre el cual se tenga autoridad plena y absoluta y se generará una zona de resolución inversa por cada red sobre la cual se tenga plena y absoluta autoridad. Es decir, si se es propietario del dominio «cualquiercosa.com», se deberá generar el fichero de zona correspondiente a fin de resolver dicho dominio. Por cada red con direcciones IP privadas sobre la cual se tenga control y plena y absoluta autoridad, se deberá generar un fichero de zona de resolución inversa a fin de resolver inversamente las direcciones IP de dicha zona. Regularmente la resolución inversa de las direcciones IP públicas es responsabilidad de los proveedores de servicio ya que son estos quienes tienen la autoridad plena y absoluta sobre dichas direcciones IP.

Todos los ficheros de zona deben pertenecer al usuario «named» a fin de que el servicio named pueda acceder a estos o bien modificar éstos en el caso de tratarse de zonas esclavas.

Creación de los ficheros de zona.

Los siguientes corresponderían a los contenidos para los ficheros de zona requeridos para la red local y por el NIC con el que se haya registrado el dominio. Cabe señalar que en las zonas de reenvío siempre se especifica al menos un registro MX (Mail Exchanger o intercambiador de correo), para definir donde está el servidor de correo para el dominio, y que se utilizan tabuladores (tecla TAB) en lugar de espacio. Solo necesitará sustituir nombres y direcciones IP, y quizá añadir nuevos registros para complementar su red local.

Configuración mínima para /var/named/chroot/etc/named.conf.

La configuración mínima del fichero /var/named/chroot/etc/named.conf, y que permitirá utilizar el servicio para todo tipo de uso, es la siguiente:

options {
	directory "/var/named";
	dump-file "/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	allow-recursion {
		127.0.0.1;
		192.168.1.0/24;
	};
	forwarders {
		8.8.8.8;
		8.8.4.4;
	};
	forward first;
};

include "/etc/named.rfc1912.zones";
include "/etc/rndc.key";

controls {
	inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndckey"; };
};

Lo anterior define como opciones que el directorio predeterminado será /var/named (ruta relativa a /var/named/chroot), de define un fichero conde se almacena la información del caché en /var/named/data/cache_dump.db; un fichero de estadísticas en /var/named/data/named_stats.txt, un fichero de estadísticas específicas en lo concerniente al uso de la memoria en /var/named/data/named_mem_stats.txt; consultas recursivas permitidas solo a 127.0.0.1 y 192.168.1.0/24, se definen como ejemplos de servidores DNS para reenviar consultas a 200.33.146.209 y 200.33.146.217 (solo éstos utilizar desde redes de Prodigy Internet de Telmex, definir en lugar de éstos los servidores DNS del proveedor de acceso a Internet); se define que la primera opción al realizar una consulta será reenviar a los DNS que se acaban de definir; se incluyen los ficheros de configuración /etc/named.rfc1912.zones, que corresponde a las zonas del RFC 1912, y la firma digital única que se generó automáticamente tras instalar el paquete bind; Se define también que los controles se realizan solo desde 127.0.0.1 hacia 127.0.0.1 utilizando la firma digital única.

El fichero conviene asegurarse que el fichero /var/named/chroot/etc/named.conf tenga los contextos correspondientes para SELinux a fin de evitar potenciales problemas de seguridad.

chcon -u system_u -r object_r -t named_conf_t /var/named/chroot/etc/named.conf

Zona de reenvío red local /var/named/chroot/var/named/red-local.zone.

$TTL 86400
@		IN	SOA	dns.red-local.	alguien.gmail.com. (
		2009091001; número de serie
		28800 ; tiempo de refresco
		7200 ; tiempo entre reintentos de consulta
		604800 ; tiempo tras el cual expira la zona
		86400 ; tiempo total de vida
		)
@		IN	NS	dns.red-local.net.
@		IN	MX	10	mail
@		IN	TXT	"v=spf1 a mx -all"
@		IN	A	192.168.1.1
intranet	IN	A	192.168.1.1
maquina2	IN	A	192.168.1.2
maquina3	IN	A	192.168.1.3
maquina4	IN	A	192.168.1.4
www		IN	A	192.168.1.1
mail		IN	A	192.168.1.1
ftp		IN	CNAME	intranet
dns		IN	CNAME	intranet

Zona de resolución inversa red local /var/named/chroot/var/named/1.168.192.in-addr.arpa.zone

$TTL 86400
@		IN	SOA	dns.red-local.	alguien.gmail.com. (
		2009091001 ; número de serie
		28800 ; tiempo de refresco
		7200 ; tiempo entre reintentos de consulta
		604800 ; tiempo tras el cual expira la zona
		86400 ; tiempo total de vida
		)
@		IN	NS	dns.red-local.
1	IN	PTR	intranet.red-local.
2	IN	PTR	maquina2.red-local.
3	IN	PTR	maquina3.red-local.
4	IN	PTR	maquina4.red-local.

Zona de reenvío del dominio /var/named/chroot/var/named/dominio.com.zone

Suponiendo que hipotéticamente se es la autoridad para el dominio «dominio.com», se puede crear una Zona de Reenvío con un contenido similar al siguiente:

$TTL 86400
@		IN	SOA	fqdn.dominio-resuelto.	alguien.gmail.com. (
		2009091001; número de serie
		28800 ; tiempo de refresco
		7200 ; tiempo entre reintentos de consulta
		604800 ; tiempo tras el cual expira la zona
		86400 ; tiempo total de vida
		)
@		IN	NS	fqdn.dominio-resuelto.
@		IN	MX	10	mail
@		IN	TXT	"v=spf1 a mx -all"
@		IN	A	201.161.1.226
servidor	IN	A	201.161.1.226
www		IN	A	201.161.1.226
mail		IN	A	201.161.1.226
ftp		IN	CNAME	servidor
dns		IN	CNAME	servidor

Zona de resolución inversa del dominio /var/named/chroot/var/named/1.161.201.in-addr.arpa.zone

Suponiendo que hipotéticamente se es la autoridad para el segmento de red 201.161.1.0/24 (regularmente lo debe de hacer el proveedor de servicio de acceso hacia Internet), se puede crear una Zona de Resolución Inversa con un contenido similar al siguiente:

$TTL 86400
@		IN	SOA	fqdn.dominio-resuelto.	alguien.gmail.com. (
		2009091001 ; número de serie
		28800 ; tiempo de refresco
		7200 ; tiempo entre reintentos de consulta
		604800 ; tiempo tras el cual expira la zona
		86400 ; tiempo total de vida
		)
@		IN	NS	fqdn.dominio-resuelto.
1	IN	PTR	servidor.dominio.com.
2	IN	PTR	maquina2.dominio.com.
3	IN	PTR	maquina3.dominio.com.
4	IN	PTR	maquina4.dominio.com.

Cada vez que haga algún cambio en algún fichero de zona, deberá cambiar el número de serie a fin de que tomen efecto los cambios de inmediato cuando se reinicie el servicio named, ya que de otro modo tendría que reiniciar el equipo, algo poco conveniente.

Las zonas de resolución inversa que involucran direcciones IP públicas son responsabilidad de los ISP (proveedores de servicio de acceso hacia Internet). Crear una zona de resolución inversa sin ser la autoridad de dicha zona tiene efecto solo para quien use el servidor DNS recién configurado como único DNS.

Configuración de parámetros en el fichero /etc/named.conf

options {
	directory "/var/named";
	dump-file "/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	allow-recursion {
		127.0.0.1;
		192.168.1.0/24;
	};
	forwarders {
		8.8.8.8;
		8.8.4.4;
	};
	forward first;
};
include "/etc/named.rfc1912.zones";
include "/etc/rndc.key";
controls {
	inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndckey"; };
};

zone "red-local" { 
	type master; 
	file "red-local.zone";
	allow-update { none; };
};
zone "1.168.192.in-addr.arpa" { 
	type master; 
	file "1.168.192.in-addr.arpa.zone";
	allow-update { none; };
};

Seguridad adicional en DNS para uso público.

Quienes hayan utilizado en recientes fechas los servicios de DNS Report, habrán notado que el diagnóstico en línea devuelve ahora un error que, en resumen, indica que el servidor puede ser susceptible de sufrir/participar en un ataque DDoS (Distributed Denail of Service o denegación de servicio distribuido).

Un DDoS (Distributed Denial of Service) es una ampliación del ataque DoS, se efectúa con la instalación de varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos del mundo. El atacante consigue coordinar esos agentes para así, de forma masiva, amplificar el volumen del saturación de información (flood), pudiendo darse casos de un ataque de cientos o millares de computadoras dirigido a una máquina o red objetivo. Esta técnica se ha revelado como una de las más eficaces y sencillas a la hora de colapsar servidores, la tecnología distribuida ha ido haciendo más sofisticada hasta el punto de otorgar poder de causar daños serios a personas con escaso conocimiento técnico.

La falla reportada por la herramienta en línea de DNS Report, para un servidor DNS que permite consultas recursivas, indicará algo como lo siguiente:

«ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn’t happen). This can cause an excessive load on your DNS server. Alos, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Alos, the bad guys could use your DNS server as part of an attack, by forging their IP address»

Significa que el servidor DNS puede permitir a cualquiera realizar consultas recursivas. Si se trata de un DNS que se desea pueda ser consultado por cualquiera, como puede ser el caso del DNS de un ISP, esto es normal y esperado. Si se trata de un servidor que solo debe consultar la red local, o bien que se utiliza para propagar dominios alojados de manera local, si es conveniente tomar medidas al respecto.

Solución al problema es modificar el fichero named.conf, donde se añade en la sección de opciones (options) una línea que defina la red, las redes o bien los ACL (Access Control List o listas de control de acceso) que tendrán permitido realizar todo tipo de consultas.

options {
        directory "/var/named";
	dump-file "/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
        forwarders { 192.168.0.1; };
        forward first;
        allow-recursion { 127.0.0.1; 192.168.0.0/24; };
};
controls {
	inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndckey"; };
};

Lo anterior hace que solo se puedan realizar consultas recursivas en el DNS desde 192.168.0.0/24, ya sea para un nombre de dominio alojado de manera local y otros dominios resueltos en otros servidores (ejemplo: www.yahoo.com, www.google.com, www.alcancelibre.org, etc). El resto del mundo solo podrá realizar consultas sobre los dominios alojados de manera local y que estén configurado para permitirlo.

En la siguiente configuración de ejemplo, se pretende lograr lo siguiente:

De este modo se impide que haya consultas recursivas y con esto impedir la posibilidad de sufrir/participar de un ataque DDoS.

options {
        directory "/var/named";
	dump-file "/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
        forwarders { 192.168.0.1; };
        forward first;
        allow-recursion { 127.0.0.1; 192.168.0.0/24; };
};

controls {
	inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndckey"; };
};

include "/etc/named.rfc1912.zones";
include "/etc/rndc.key";

zone "miredlocal" {
        type master;
        file "miredlocal.zone";
        allow-update { none; };
        allow-query { 192.168.0.0/24; };
        allow-transfer { 192.168.0.2; };
};

zone "midominio.com" {
        type master;
        file "midominio.com.zone";
        allow-update { none; };
        allow-transfer { 200.76.185.252; 200.76.185.251; };
};

Un DDoS (Distributed Denial of Service) es una ampliación del ataque DoS, se efectúa con la instalación de varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos del mundo. El atacante consigue coordinar esos agentes para así, de forma masiva, amplificar el volumen del saturación de información (flood), pudiendo darse casos de un ataque de cientos o millares de computadoras dirigido a una máquina o red objetivo. Esta técnica se ha revelado como una de las más eficaces y sencillas a la hora de colapsar servidores, la tecnología distribuida ha ido haciendo más sofisticada hasta el punto de otorgar poder de causar daños serios a personas con escaso conocimiento técnico.

La falla reportada por la herramienta en línea de DNS Report, para un servidor DNS que permite consultas recursivas, indicará algo como lo siguiente:

«ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn’t happen). This can cause an excessive load on your DNS server. Alos, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Alos, the bad guys could use your DNS server as part of an attack, by forging their IP address»

Significa que el servidor DNS puede permitir a cualquiera realizar consultas recursivas. Si se trata de un DNS que se desea pueda ser consultado por cualquiera, como puede ser el caso del DNS de un ISP, esto es normal y esperado. Si se trata de un servidor que solo debe consultar la red local, o bien que se utiliza para propagar dominios alojados de manera local, si es conveniente tomar medidas al respecto.

Solución al problema es modificar el fichero named.conf, donde se añade en la sección de opciones (options) una línea que defina la red, las redes o bien los ACL (Access Control List o listas de control de acceso) que tendrán permitido realizar todo tipo de consultas.

options {
        directory "/var/named";
	dump-file "/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
        forwarders { 192.168.0.1; };
        forward first;
        allow-recursion { 127.0.0.1; 192.168.0.0/24; };
};
controls {
	inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndckey"; };
};
include "/etc/named.rfc1912.zones";
include "/etc/rndc.key";

Lo anterior hace que solo se puedan realizar todo

Netfilter es un conjunto de ganchos (Hooks, es decir, técnicas de programación que se emplean para crear cadenas de procedimientos como manejador) dentro del núcleo de GNU/Linux y que son utilizados para interceptar y manipular paquetes de red. El componente mejor conocido es el cortafuegos, el cual realiza procesos de filtración de paquetes. Los ganchos son también utilizados por un componente que se encarga del NAT (acrónimo de Network Address Translation o Traducción de dirección de red). Estos componentes son cargados como módulos del núcleo.

Contrata tu nuevo servidor ahora, y sumérgete en fascinante mundo de Linux

Iptables es el nombre de la herramienta de espacio de usuario (User Space, es decir, área de memoria donde todas las aplicaciones, en modo de usuario, pueden ser intercambiadas hacia memoria virtual cuando sea necesario) a través de la cual los administradores crean reglas para cada filtrado de paquetes y módulos de NAT. Iptables es la herramienta estándar de todas las distribuciones modernas de GNU/Linux.

URL: http://www.netfilter.org/

Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: http://www.alcancelibre.org/
Jabber ID: darkshram@jabber.org

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

Procedimientos.
Cadenas.

Las cadenas pueden ser para tráfico entrante (INPUT), tráfico saliente (OUTPUT) o tráfico reenviado (FORWARD).
Reglas de destino.

Las reglas de destino pueden ser aceptar conexiones (ACCEPT), descartar conexiones (DROP), rechazar conexiones (REJECT), encaminamiento posterior (POSTROUTING), encaminamiento previo (PREROUTING), SNAT, NAT, entre otras.
Políticas por defecto.

Establecen cual es la acción a tomar por defecto ante cualquier tipo de conexión. La opeción -P cambia una política para una cadena. En el siguiente ejemplo se descartan (DROP) todas las conexiones que ingresen (INPUT), todas las conexiones que se reenvíen (FORWARD) y todas las conexiones que salgan (OUTPUT), es decir, se descarta todo el tráfico que entre desde una red pública y el que trate de salir desde la red local.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Limpieza de reglas específicas.

A fin de poder crear nuevas reglas, se deben borrar las existentes, para el tráfico entrante, tráfico reenviado y tráfico saliente así como el NAT.

iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat

Reglas específicas.

Las opciones más comunes son:

* -A añade una cadena, la opción -i define una interfaz de tráfico entrante
* -o define una interfaz para trafico saliente
* -j establece una regla de destino del tráfico, que puede ser ACCEPT, DROP o REJECT. La
* -m define que se aplica la regla si hay una coincidencia específica
* –state define una lista separada por comas de distinto tipos de estados de las conexiones (INVALID, ESTABLISHED, NEW, RELATED).
* –to-source define que IP reportar al tráfico externo
* -s define trafico de origen
* -d define tráfico de destino
* –source-port define el puerto desde el que se origina la conexión
* –destination-port define el puerto hacia el que se dirige la conexión
* -t tabla a utilizar, pueden ser nat, filter, mangle o raw.

Ejemplos de reglas.

Reenvío de paquetes desde una interfaz de red local (eth1) hacia una interfaz de red pública (eth0):

iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

Aceptar reenviar los paquetes que son parte de conexiones existentes (ESTABLISHED) o relacionadas de tráfico entrante desde la interfaz eth1 para tráfico saliente por la interfaz eth0:

iptables -A FORWARD -i eth0 -o eth1 -m state –state ESTABLISHED,RELATED -j ACCEPT

Permitir paquetes en el propio muro cortafuegos para tráfico saliente a través de la interfaz eth0 que son parte de conexiones existentes o relacionadas:

iptables -A INPUT -i eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT

Permitir (ACCEPT) todo el tráfico entrante (INPUT) desde (-s) cualquier dirección (0/0) la red local (eth1) y desde el retorno del sistema (lo) hacia (-d) cualquier destino (0/0):

iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

Hacer (-j) SNAT para el tráfico saliente (-o) a tráves de la interfaz eth0 proveniente desde (-s) la red local (192.168.0.0/24) utilizando (–to-source) la dirección IP w.x.y.z.

iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT –to-source x.y.z.c

Descartar (DROP) todo el tráfico entrante (-i) desde la interfaz eth0 que trate de utilizar la dirección IP pública del servidor (w.x.y.z), alguna dirección IP de la red local (192.168.0.0/24) o la dirección IP del retorno del sistema (127.0.01)

iptables -A INPUT -i eth0 -s w.x.y.x/32 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP

Aceptar (ACCEPT) todos los paquetes SYN (–syn) del protocolo TCP (-p tcp) para los puertos (–destination-port) de los protocolos SMTP (25), HTTP(80), HTTPS (443) y SSH (22):

iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 25 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 80 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 443 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 22 –syn -j ACCEPT

Aceptar (ACCEPT) todos los paquetes SYN (–syn) del protocolo TCP (-tcp) para los puertos (–destination-port) del protocolos SMTP (25) en el servidor (w.x.y.z/32), desde (-s) cualquier lugar (0/0) hacia (-d) cualquier lugar (0/0).

iptables -A INPUT -p tcp -s 0/0 -d w.x.y.z/32 –destination-port 25 –syn -j ACCEPT

Aceptar (ACCEPT) todos los paquetes SYN (–syn) del protocolo TCP (-p tcp) para los puertos (–destination-port) de los protocolos POP3 (110), POP3S (995), IMAP (143) y IMAPS (993):

iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 110 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 995 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 143 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 993 –syn -j ACCEPT

Aceptar (ACCEPT) el tráfico entrante (-i) proveniente desde la interfaz eth1 cuando las conexiones se establezcan desde el puerto (–sport) 67 por protocolos (-p) TCP y UDP.

iptables -A INPUT -i eth1 -p tcp –sport 68 –dport 67 -j ACCEPT
iptables -A INPUT -i eth1 -p udp –sport 68 –dport 67 -j ACCEPT

Aceptar (ACCEPT) conexiones de tráfico entrante (INPUT) por protocolo (-p) UDP cuando se establezcan desde (-s) el servidor DNS 200.33.145.217 desde el puerto (–source-port) 53 hacia (-d) cualquier destino (0/0):

iptables -A INPUT -p udp -s 200.33.146.217/32 –source-port 53 -d 0/0 -j ACCEPT

Cerrar accesos.

Descartar (DROP) el tráfico entrante (INPUT) para el protocolo (-p) TCP hacia los puerto (–destination-port) de SSH (22) y Telnet (23):

iptables -A INPUT -p tcp –destination-port 22 -j DROP
iptables -A INPUT -p tcp –destination-port 23 -j DROP

Descartar (DROP) todo tipo de conexiones de tráfico entrante (INPUT) desde (-s) la dirección IP a.b.c.d:

iptables -A INPUT -s a.b.c.d -j DROP

Rechazar (REJECT) conexiones hacia (OUTPUT) la dirección IP a.b.c.d desde la red local:

iptables -A OUTPUT -d a.b.c.d -s 192.168.0.0/24 -j REJECT

Eliminar reglas.

En general se utiliza la misma regla, pero en lugar de utilizar -A (append), se utiliza -D (delete).

Elininar la regla que descarta (DROP) todo tipo de conexiones de tráfico entrante (INPUT) desde (-s) la dirección IP a.b.c.d:

iptables -D INPUT -s a.b.c.d -j DROP

Mostrar la lista de cadenas y reglas.

Una vez cargadas todas las cadenas y reglas de iptables es posible visualizar éstas utilizando el mandato iptables con las opciones -n, para ver las listas en formato numérico, y -L, para solicitar la lista de éstas cadenas.

iptables -nL

Cuando no hay reglas ni cadenas cargadas, la salida debe devolver lo siguiente:

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

Cuando hay cadenas presentes, la salida, suponiendo que se utilizarón los ejemplos de este documento, debe devolver algo similar a lo siguiente:

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
DROP all — 192.168.1.64 0.0.0.0/0
DROP all — 172.16.0.0/24 0.0.0.0/0
DROP all — 127.0.0.0/8 0.0.0.0/0
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 192.168.1.64 tcp dpt:25 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:110 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:995 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:143 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:993 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp spt:68 dpt:67
ACCEPT udp — 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
ACCEPT udp — 200.33.146.217 0.0.0.0/0 udp spt:53

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@m064 ~]# iptables -nL
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
DROP all — 192.168.1.64 0.0.0.0/0
DROP all — 172.16.0.0/24 0.0.0.0/0
DROP all — 127.0.0.0/8 0.0.0.0/0
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 192.168.1.64 tcp dpt:25 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:110 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:995 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:143 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:993 flags:0×17/0×02
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp spt:68 dpt:67
ACCEPT udp — 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
ACCEPT udp — 200.33.146.217 0.0.0.0/0 udp spt:53

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Iniciar, detener y reiniciar el servicio iptables.

Si está de acuerdo con las reglas generadas de iptables, utilice el siguiente mandato para guardar éstas:

service iptables save

Las reglas quedarán almacenadas en el fichero /etc/sysconfig/iptables.

Para ejecutar por primera vez el servicio iptables, utilice:

service iptables start

Para hacer que los cambios hechos tras modificar la configuración surtan efecto, utilice:

service iptables restart

Para detener el servicio iptables y borrar todas las reglas utilice:

service iptables stop

Agregar el servicio iptables al arranque del sistema.

Para hacer que el servicio de iptables esté activo con el siguiente inicio del sistema, en todos los niveles de corrida (2, 3, 4, y 5), se utiliza lo siguiente:

chkconfig iptables on

Bibliografía.

* Wikipedia: http://en.wikipedia.org/wiki/Iptables
* Dennis G. Allard y Don Cohen http://oceanpark.com/notes/firewall_example.html

Última Edición sábado 31 de mayo, 2008 @15:36

Contiene entre otras cosas:

• Instalación del Daemon de Telnet
• Revisión de correo por utilizando Telnet con el protocolo POP3
• Envío de correo utilizando Telnet con el protocolo SMTP
• Instalación del Daemon para SSH
• Protocolo scp
• Utilización de SSH sin contraseña.
• Introducción al Firewall.
• Utilización de FiresStarter
• Instalación del cliente de FTP Pure-FTP
• Comandos en FTP
• Creación de Usuarios Virtuales en Pure – FTP
• Instalación de LAMP (Linux, Apache, MySQL, PHP) en Ubuntu
• Utilización de Apache.
• Visualizar archivo de Información de PHP
• Instalación de PHP Free Chat
• Comandos básicos de MySQL

TELNET, SSH, FTP Y LAMP En Ubuntu

¿Necesitas Hosting a tu medida, por un precio justo? Haz click aquí