1  

TOMA UNA IP, RESUELVE UNA URL Y NAVEGA CON LINUX Diego Ademir Duarte Santana1 En muchas oportunidades conectamos nuestras computadoras personales en la oficina o en casa buscando poder visitar aquella página de internet que tanto nos interesa y no nos percatamos de la cantidad de herramientas que permiten visualizar aquella simple dirección digitada en la barra de direcciones de nuestro navegador, ni de la identidad que tenemos en internet y mucho menos de algunos filtros de seguridad que permiten acceder a un sitio web o restringirme de otros de manera controlada y auditable. El presente artículo pretende profundizar sobre aquellas tareas que se realizan a nivel de software en los servidores de nuestra empresa o en las entidades proveedoras de internet, como son los servicios de resolución de nombres, asignación dinámica de direcciones IP y definición de reglas de acceso y control hacia direcciones de internet. Asimismo se observarán algunas recomendaciones en cuanto a versiones de software sin olvidar, por supuesto, el alcance de seguridad que pueden brindarnos estas herramientas. DNS, DHCP, PROXY, SERVICIOS, LINUX. A lot of opportunities connect our personal computers in the office or home searching visit this website very interesting and we do not realize of a lot of tools that permit watch this simple address written into address-bar of our browser, neither the identity we have into internet and much less of some security filters that permit access of a website or restricted of others so controlled or auditable. This article is intended to deepen about those asks being made to software level in the enterprise servers or in the Internet Service Provider, such as resolution name services, dynamic assign of ip address and definition access rule and control to internet address. Also be observed some recommendations about software versions well, of course, the security scope that these tools can give. DNS, DHCP, PROXY, SERVICES, LINUX                                                             1 Ingeniero de Sistemas, Universidad Industrial de Santander UPB CTIC Bucaramanga, email: dadhemir@gmail.com  

1. INTRODUCCION La presente investigación brinda las herramientas a profesionales en las tecnologías de información y comunicaciones de cuales herramientas utilizar bajo ambientes de software libre, específicamente LINUX para instalar, configurar y poner en marcha en sus redes corporativas servicios como son DNS, DHCP y PROXY. Para resolver direcciones de internet, el software de servicio DNS que utilizaremos bajo licencia GPL2 es BIND en su versión 9.0 como la versión más estable y menos vulnerada hasta el momento. El protocolo DHCP se presenta como el encargado de asignar direcciones IP de manera dinámica a un grupo de usuarios sin la modificación de sus configuraciones de red. Para esto trabajaremos con la versión DHCP 3.0 para Linux. Finalmente, para describir el concepto de PROXY asociado a un primer nivel de seguridad en redes corporativas utilizaremos el software SQUID. En general, iniciaremos con una descripción del software seguido por la instalación y configuración para finalizar con una sencilla prueba a través de un cliente. 2. PLANTEAMIENTO DEL PROBLEMA Introducción al DNS El internet u otras redes trabajan local o globalmente asignando direcciones IP3 a puntos finales como son hosts, servidores, enrutadores, etc. Pero sin la habilidad de asignar un nombre correspondiente a cada dispositivo; cada vez que se quiere acceder a un dispositivo de la red, por ejemplo,                                                             2 General Public License 3 Internet Protocol 

2  

www.tuconsulta.net debería conocerse la dirección IP tal como 192.168.12.12. Con miles de millones de hosts y más de 50 millones de sitios web, esto es una tarea imposible. Para resolver el problema, el concepto de servidores de nombres fue creado a mediados de 1970 para asociar direcciones físicas a nombres. La idea era que fuera más simple recordar una dirección física camuflada en un nombre claro y relativo al contenido, a funciones o a un propósito. Algo de historia El problema de convertir nombres a direcciones físicas es tan antiguo como las redes de computadoras. Incluso desde mucho tiempo atrás las personas encontraron un método fácil para recordar los nombres utilizando un dispositivo de teletipo llamado “tty2” ó “puerto 57 del MCCU”. En los años 70’s, con el auge de las redes de computadoras el problema se tornó más agudo. La arquitectura de sistema red de IBM (SNA4), probablemente el abuelo de las redes, contenía una enorme base de datos para traducción de nombres que fue publicada en 1974. Hacia 1978 surge el modelo OSI5 desarrollado por la ISO6, el cual definió servicios de traducción de nombres en direcciones en su capa de transporte (capa 4). NetBIOS propuso luego el NetBIOS Name Server (NBNS) en 1984, el cual luego se transformó en Microsoft Windows Internet Naming Services (WINS). El proyecto ARPANET RFC7, que luego sería la base de Internet, manejaría un

                                                            4 Systems Network Architecture 5 Open System Interconnection 6 Organización Internacional de Normalización 7 Request For Comments 

concepto de dominio de nombres desde 1981 (RFC 799), y las especificaciones definitivas del Sistema de Nombres de Dominio de Internet que conocemos hoy en día fue publicado en 1987. Conceptos Básicos DNS Es una base de datos distribuida jerárquicamente. Almacena información sobre mapeo de nombres de host en internet a direcciones IP o viceversa, información de enrutamiento de correos y otros datos usados por aplicaciones web. Los usuarios observan información en el DNS gracias a una librería resolver la cual envía consultas a uno o más servidores que interpretan las diferentes respuestas. El software BIND9 contiene un servidor de nombres llamado named y dos librerías que resuelven nombres, libwres y libbind. Dominios y Nombres de Dominios Los datos almacenados en el DNS son organizados jerárquicamente como un árbol organizacional. Cada nodo de ése árbol es un dominio y posee una etiqueta. El nombre de dominio del nodo es la concatenación de todas las etiquetas desde el nodo actual hasta el nodo padre (root). Esto es lo que conocemos como cada palabra separada por el carácter punto (.). Ver figura 1.

Fig. #1 Tomada de http://technet.microsoft.com/en-us/library/Bb727085.dsgn0117_big(en-us,TechNet.10).gif

3  

Observamos en la figura que existe un host server.com en el primer nivel del árbol bajo el dominio com. Luego existe otro host como extremo del árbol al cual se le bautizó con el nombre server.contoso.com bajo el dominio contoso.com. Este último es sub-dominio de com. De esta forma se crea toda la estructura de dominios que conocemos en internet y que utilizamos diariamente. Para propósitos administrativos, el espacio de nombres es particionado en áreas llamadas zonas, cada una de ellas define un nodo de la cual se extienden otros nodos que inician otras zonas. Los datos de cada zona se almacenan en un servidor de nombres, el cual responde consultas utilizando el protocolo DNS. Servidor de Autorización de Nombres Cada zona sirve al menos a un servidor de autorización de nombres, el cual contiene datos completos de la zona. Para hacer el DNS tolerante a fallas de red, la mayoría de las zonas tienen más servidores de autorización. Primario Maestro Aquí es donde se realiza el mantenimiento de los datos de una zona previamente definida. Normalmente está contenida toda la configuración en un archivo editable. Servidor Esclavo Son servidores de autorización también llamados servidores secundarios que cargan la información de una zona desde otros servidores usando un proceso de replicación llamado transferencia de zona. Normalmente lo hacen tomando información de un servidor maestro.

Forwarders Son aquellos servidores que sirven de respaldo a nuestro servidor maestro para que en caso de no poder resolver algún nombre remita su petición a otro que sí está en capacidad de hacerlo. A continuación observaremos la fortaleza de los servidores de nombres utilizando una de las herramientas más usadas en millones de servidores del mundo bajo plataformas LINUX, BIND. ¿Qué es BIND? Sigla de Berkeley Internet Name Domain es la más común de las implementaciones del protocolo DNS en Internet. Es gratuito y se rige por la licencia BSD. Los servidores BIND DNS se cree que acaparan el 80% de los servicios DNS del mundo. Fue desarrollado por la universidad de California en Berkeley. La más reciente versión en la 9.4.2 y desde la 9 soporta DNS SEC, TSIG, IPv6 y otros protocolos. Aspectos de seguridad Una de las más importantes consideraciones de seguridad que maneja BIND son las listas de control de acceso (ACL). Con ellas se puede quien accede a su servidor de nombres. Con esto se pueden prevenir ataques tipo spoofing o de Denegación de servicios. A continuación podemos ver una configuración básica de seguridad. // Set up an ACL named "bogusnets" that will block RFC 1918 space, // which is commonly used in spoofing attacks. acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; // Set up an ACL called our-nets. Replace this with the real IP numbers. acl our-nets { x.x.x.x/24; x.x.x.x/21; }; options { ... ...

4  

allow-query { our-nets; }; allow-recursion { our-nets; }; ... blackhole { bogusnets; }; ... }; zone "example.com" { type master; file "m/example.com"; allow-query { any; }; }; Configuración Básica Basados sobre una plataforma LINUX, específicamente la distribución Ubuntu 8.10 para servidores procederemos a realizar la configuración básica de un servidor BIND DNS. Instalación y configuración Abrimos una terminal Linux e ingresamos el siguiente comando: sudo apt-get install bind9 Además instalamos un paquete de utilidades muy importante. sudo apt-get install dnsutils Nuestro directorio referencia en el proceso de configuración es /etc/bind/ y aquí se encuentran una serie de archivos muy importantes en el proceso. Ahora definimos los forwarders modificando named.conf.options : forwarders { 1.2.3.4; 5.6.7.8; }; Para tomar los cambios realizados reiniciamos el servicio: sudo /etc/init.d/bind9 restart

Ahora configuraremos el servidor maestro para el dominio tuconsulta.net de la siguiente forma: Editamos el archivo named.conf.local zone "tuconsulta.net" { type master; file "/etc/bind/db.tuconsulta.net"; }; Ahora usamos la zona existente como plantilla para crear la nuestra. Creamos el archivo db.tuconsulta.net. sudo cp /etc/bind/db.local /etc/bind/db.tuconsulta.net Editamos el archivo anterior de la siguiente forma: ; ; BIND data file for local loopback interface ; $TTL 604800 @ IN SOA ns.tuconsulta.net. root.tuconsulta.net. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns.tuconsulta.net. @ IN A 192.168.1.10 ns IN A 192.168.1.10 Reiniciamos el servicio DNS y por último definimos las zonas inversas para en casos de recibir una dirección física la traduzca a un nombre. Para ello editamos el archivo named.conf.local y agregamos lo siguiente: zone "1.168.192.in-addr.arpa" {

5  

type master; notify no; file "/etc/bind/db.192"; }; Recordemos que las direcciones IP debe asignarlas de acuerdo a sus necesidades y en sincronía con el administrador de la red. Creamos el archivo db.192 teniendo en cuenta el primer octeto de la dirección IP. sudo cp /etc/bind/db.127 /etc/bind/db.192 Ahora editamos el archivo cambiando básicamente las mismas opciones del archivo db.tuconsulta.net. ; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA ns.tuconsulta.net. root. tuconsulta.net. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns. 10 IN PTR ns. tuconsulta.net. Por último reiniciamos el servicio BIND para que tome los cambios anteriores. De esta forma realizamos una configuración básica de un servicio DNS y procedemos a realizar algunas pruebas que ratifican el exitoso proceso. Pruebas Podemos realizarlas con comandos simples digitados desde consolas LINUX o DOS tal como se presenta a continuación:

ping tuconsulta.net El anterior comando hace una petición al dominio y de acuerdo a lo ingresado en el archivo /etc/resolv.conf, donde asocio direcciones IP con el nombre de servidor, se observa el siguiente resultado: PING tuconsulta.net (192.168.1.10) 56(84) bytes of data. 64 bytes from ns (192.168.1.10): icmp_seq=1 ttl=64 time=0.800 ms 64 bytes from ns (192.168.1.10): icmp_seq=2 ttl=64 time=0.813 ms Existe otro comando que permite probar la resolución de nombres y es: dig tuconsulta.net Observamos el resultado: ;; Query time: 1 msec ;; SERVER: 192.168.1.10#53(192.168.1.10)

6  

DHCP Sigla de Dynamic Host Configuration Protocol es un servicio de red que habilita a computadores o hosts tomar automáticamente configuraciones asignadas desde un servidor para evitar tareas manuales que deben realizarse equipo por equipo. Los hosts configurados como clientes DHCP no tienen acceso o privilegios para modificar sus definiciones de red, esto lo reciben desde el servidor DHCP y es transparente para el usuario. Las configuraciones más comunes provistas por un servidor DHCP hacia sus clientes son:

- Dirección IP y máscara de red - DNS - WINS

Sin embargo un servidor DNS puede proveer propiedades como:

- Nombre de host - Nombre de dominio - Puerta de enlace - Servidor de tiempo - Servidor de impresión

A continuación observamos una estructura de red que nos permite ubicar un servidor DHCP y un ejemplo de cómo asigna direcciones IP.

Fig. #2. Tomada de http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/rzakg/rzakg507.gif Es importante aclarar que DHCP trabaja bajo el protocolo UDP8 utilizando los puertos 67 y 68. Historia DHCP fué creado por el Dynamic Host Configuration Working Group de la Internet Engineering Task Force (IETF; una organización voluntaria que define protocolos para usar en Internet). Esta definición fue radicada en una Internet RFC y se ratifica como un estándar de Internet. A partir de éste escrito (Junio 1998), DHCP se presenta como un protocolo estándar y es de opcional manejo. DHCP es basado en BOOTP9 pero tienen algunas diferencias. La principal es que BOOTP fue diseñado para pre-configuración manual de información de los hosts en un servidor de base de datos, mientras que DHCP ofrece información dinámica de direcciones de red y                                                             8 User Datagram Protocol (UDP) es un protocolo del nivel de transporte basado en el intercambio de datagramas 9 Bootstrap Protocol. Es un protocolo de red UDP utilizado por los clientes de red para obtener su dirección IP automáticamente 

7  

configuraciones a los nuevos hosts vinculados a la red. Adicionalmente DHCP permite recuperar y reubicar direcciones de red a través de mecanismos de préstamo o arrendamiento. Existen otros protocolos de menor importancia como es RARP10 de Sun. Información General La ventaja de usar DHCP es que ante cambios en la red, como por ejemplo, dirección IP del servidor DNS se necesita sólo realizar un cambio en el servidor DHCP y no en cada host. También hace fácil la labor de integrar nuevo equipos a una red y no es necesario revisar la disponibilidad de direcciones IP. Conflictos con iguales direcciones es disminuido considerablemente. Un servidor DHCP provee configuraciones a los host usando dos métodos:

1. Dirección MAC11: éste método implica que usando DHCP se identifique la dirección de hardware conectada a la red y entonces realiza una configuración constante cada vez que el cliente DHCP hace alguna petición al servidor DHCP.

2. Pool de direcciones: Implica que se define un rango de direcciones IP que se asignan a cada hosts cada vez que hace peticiones a la red. Una vez la dirección IP asignada deje de recibir peticiones el servidor DHCP inactiva la IP y la asigna a un nuevo cliente DHCP que así la requiera.

                                                            10 Reverse Address Resolution Protocol (Protocolo de resolución de direcciones inverso) 11 Media Access Control address o dirección de control de acceso al medio 

Instalación y Configuración La versión utilizada en nuestro ejemplo es la dhcp 3 bajo Ubuntu 8.10 server. Primero iniciamos con la instalación del paquete: sudo apt-get install dhcp3-server De esta forma se instala el paquete dhcpd; notemos que el último carácter del software indica daemon o demonio, término propio de los procesos o servicios en Linux. Nuestro archivo de configuración está ubicado en /etc/dhcp3/dhcp.conf y necesita una configuración especial de acuerdo a las necesidades de la red. También es posible editar el archivo dhcp3-server para especificar qué interfaces de red van a recibir las peticiones. La configuración básica se define a continuación y observamos los rangos de direcciones que puede asignar el servidor DHCP, los tiempos de préstamo por cada dirección IP y el nombre de dominio al cual se hace referencia. # Sample /etc/dhcpd.conf # (add your comments here) default-lease-time 600; max-lease-time 7200; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; option routers 192.168.1.254; option domain-name-servers 192.168.1.1, 192.168.1.2; option domain-name "tuconsulta.net"; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.10 192.168.1.100; range 192.168.1.150 192.168.1.200; }

8  

Si por algún motivo se necesita especificar un servidor WINS para los clientes Windows, se necesitará incluir la siguiente línea en el archivo de configuración anterior: option netbios-name-servers 192.168.1.1; La prueba final es muy sencilla, desde un cliente Windows que se une a una red donde existe un servidor DHCP, éste último le asigna una dirección IP dentro de los rangos definidos. Direcciones entre 192.168.1.10 y 192.168.1.100 ó 192.168.1.150 192.168.1.200. SERVIDOR PROXY Un servidor proxy está situado entre una aplicación del cliente, que puede ser un navegador web, y un servidor real. Este intercepta todas las peticiones al servidor real para ver si es viable o no resolverlas o autorizarlas. Los servidores proxy tienen dos propósitos principales:

1. Ofrecen rendimiento para un grupo de usuarios en una red. Si un usuario X hace una petición a una dirección http://www.tuconsulta.net a través de un servidor proxy, dicha página se almacena en el servidor y cuando el usuario Y ubicado en la misma red realiza una petición a la misma página dentro un tiempo definido, ésta se resuelve más rápidamente ya que se encuentra almacenada en servidor gracias a la primera petición.

2. También pueden ser usados para filtras peticiones. Por ejemplo, una compañía podría usar un servidor

proxy para prevenir que sus empleados accedan a un grupo específico de sitios web.

En el siguiente gráfico observamos una estructura básica de red donde se ubica un

servidor proxy. Fig. #3. Tomada de http://www.criptos.com/IMG/pdf/ProxySquid-2.pdf

Beneficios Los servidores proxy ofrecen una serie de ventajas para las empresas que los manejan, las más importantes son:

- Ofrecen la posibilidad de acceso transparente hacia Internet por medio de cualquier software de navegación.

- Mayor velocidad en la navegación. Aquellas páginas que ya han sido visitadas se almacenan en el servidor gracias al cache proxy.

- Optimización de acceso a internet.

- Absoluto control de la navegación de una empresa u hogar gracias al almacenamiento de logs donde detalla información de hora, fecha de acceso, etc.

- Capacidad de controlar acceso a páginas prohibidas.

9  

Clases de Proxy Existen dos tipos de servidores proxy:

1. De aplicación: se instala en una máquina que administra peticiones y devuelve respuestas de acuerdo a políticas de seguridad definidas.

2. Socks: son muy similares a un panel de conmutación y tienen la desventaja de que no suministran autenticación a usuarios.

Para nuestro caso utilizaremos un proxy cache server llamado SQUID bajo sistema operativo LINUX. SQUID Servidor proxy de libre distribución que trabaja para protocolos como HTTP, FTP y otros protocolos de red populares como (ICP) Hyper Text Caching Protocol, (HTCP) Cache Array Routing Protocol (CARP), y Web Cache Coordination Protocol. (WCCP). Squid puede hacer su trabajo de caching y proxing para peticiones SSL, DNS lookup y ejecuciones transparentes a usuarios. Representa también una buena herramienta para monitorear parámetros críticos vía SNMP. Es necesario dotar de suficiente memoria física al servidor que va a cumplir labores de proxy en una corporación para incrementar el rendimiento y mejorar tiempos de respuesta ante innumerables peticiones. Instalación y Configuración Bajo la misma distribución Linux que hemos manejado en servicios anteriores procedemos al montaje del proxy cache server.

Ejecutamos la siguiente instrucción: sudo apt-get install squid Una vez instalado, configuramos las directivas contenidas en la carpeta de trabajo /etc/squid/ específicamente el archivo squid.conf. Recordemos que debemos realizar copias de archivos por motivos de seguridad y para controlar daños en la configuración. sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original Definimos los permisos necesarios, removemos permisos de escritura: sudo chmod a-w /etc/squid/squid.conf.original Explorando el archivo de configuración squid.conf observamos que el puerto por defecto por donde escucha el proxy es el 3128. http_port 8888 Definimos un nombre de host para nuestro proxy: visible_hostname myproxy Un término muy usado en la configuración del proxy son las ACL o Listas de Control de Acceso que permiten establecer reglas de seguridad y acceso. Primero definimos el rango de direcciones a aplicarles la regla. acl fortytwo_network src 192.168.42.0/24 Ahora le permitimos al rango anterior la política de acceso:

10  

http_access allow fortytwo_network También es posible definir reglas por intervalos de tiempo: acl biz_network src 10.1.42.0/24 acl biz_hours time M T W T F 9:00-17:00 http_access allow biz_network biz_hours Luego de realizar los cambios respectivos debemos reiniciar el servicio squid: sudo /etc/init.d/squid restart Como bien sabemos, todo servidor está expuesto a ataques y a continuación relaciono algunos que se han realizado los últimos años y que han sido debidamente corregidos: SQUID-2009:1, Feb 02, 2009 Fixed from 2.7.STABLE6, 3.0.STABLE13, 3.1.0.5 Denial of service in request processing SQUID-2008:1, Jun 22, 2008 Fixed from 2.5.STABLE7, 3.0.STABLE7 Remote Denial of Service in SNMP parser SQUID-2007:2, Dec 4, 2007 Fixed from 2.6.STABLE18, 3.0.STABLE1 Denial of service in cache updates SQUID-2007:1, Mar 20, 2007 Fixed from 2.6.STABLE12 Denial of service in TRACE method processing 3. CONCLUSIONES Con la información recolectada hasta el momento con éste artículo podemos tener una idea de la cantidad de herramientas que

intervienen en el proceso desde que hacemos una petición a nuestro navegador web hasta que recibimos en nuestra pantalla la información que esperamos. Es claro que debemos fomentar en nuestras empresas el uso de herramientas de libre distribución, ya que soportan grandes cantidades de usuarios y administran sin problemas cualquier cantidad de peticiones. LINUX nos ofrece una plataforma operacional segura, poco vulnerada y a la cual podemos realizarle las modificaciones necesarias para corregir problemas a nivel de aplicación. BIBLIOGRAFIA Ronald G. F. Aitchison. Pro DNS and BIND. Apress, 2005. 593 p. ISBN (pbk): 1-59059-494-0 Network Working Group, D. L. Mills. COMSAT Laboratories. RFC799 - Internet name domains. Septiembre de 1981. Disponible en internet: http://www.faqs.org/rfcs/rfc799.html Network Working Group, Internet Architecture Board. J. Postel, Editor. RFC2300 - Internet Official Protocol Standards. Mayo de 1998. Disponible en Internet: http://www.faqs.org/rfcs/rfc2300.html Duane Wessels. Squid: The Definitive Guide . O'Reilly, 2004. 496 p. ISBN: 0-596-00162-2 John Wobus. DHCP FAQ [online]. Octubre 26 de 1998. General. Disponible en http://www.dhcp-handbook.com/dhcp_faq.html#widxx