Dise no e Implementaci on de una Red Empresarial utilizando Software Libre

Alejandro Tamayo Castillo aletc1@gmail.com Abril 2007

 Indice general
Prefacio Licencia Retroalimentaci on / Feedback 1. Introducci on 2. Necesidades de la Organizaci on Ficticia BSDLand 3. Dise no de Red 3.1. TCP/IP . . . . . . . . . . . 3.2. Uni on de las Redes . . . . . 3.2.1. T unel PPTP/L2TP 3.2.2. T unel IP/IPSec . . . 3.2.3. IPSec . . . . . . . . 3.3. Esquema de Red . . . . . .
VII IX XI

1 3 5 5 6 6 7 7 8 11 12 12 13 13 15 15 18 19 19 20 20 20 20 21 21

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4. Estructura Organizativa 4.1. Modelos de Servidores LDAP . . . . . . 4.1.1. Single Master (Maestro u nico) . 4.1.2. Dual Master (Maestro Doble) . . 4.1.3. Multi-Master (Maestro M ultiple)

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

5. Selecci on del Software a Utilizar 5.1. Seleccion del Sistema Operativo . . . . . . . . . . . . . . . . . . . 5.1.1. FreeBSD vs Linux . . . . . . . . . . . . . . . . . . . . . . 5.2. Selecci on del Software de Aplicaci on (Servicios) . . . . . . . . . . 5.2.1. Servicio de Seguridad Kerberos . . . . . . . . . . . . . . . 5.2.2. Servicio de Directorio . . . . . . . . . . . . . . . . . . . . 5.2.3. Servicio de Encaminamiento, Cortafuegos y Conversi on de 5.2.4. Integraci on con Redes Windows . . . . . . . . . . . . . . . 5.2.5. Servidor Web y Servidor de Administraci on v a Web . . . 5.2.6. Servicio MTA (Mail Transfer Agent) . . . . . . . . . . . . 5.2.7. Servicio de Cuentas de Correo . . . . . . . . . . . . . . . i

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6. Instalando el Sistema Operativo 6.1. Instalando FreeBSD . . . . . . . . . . . . 6.2. Conguraci on Inicial . . . . . . . . . . . . 6.3. Servicios en FreeBSD . . . . . . . . . . . . 6.4. Congurando el Kernel . . . . . . . . . . . 6.5. Activando ACLs en FreeBSD . . . . . . . 6.6. Congurando el Firewall . . . . . . . . . . 6.6.1. Reglas de Acceso . . . . . . . . . . 6.6.2. Sincronizando los Firewalls: CARP 6.7. Congurando T uneles IP . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

23 23 28 29 30 33 36 37 42 43 45 45 45 45 48 49 52 52 53 54 56 56 57 58 59 64 68 71 75 80 80 81 83 83 85 87 95 97

7. Instalaci on y Conguraci on de Servicios 7.1. Administraci on del Software . . . . . . . . . . . . . . . . . . . . . 7.1.1. Administrador de Paquetes Binarios . . . . . . . . . . . . 7.1.2. Sistema de Ports . . . . . . . . . . . . . . . . . . . . . . . 7.1.3. Manteniendo los Ports Actualizados . . . . . . . . . . . . 7.2. Congurando Servidor de Nombres de Dominio (BIND) . . . . . 7.3. Congurando Kerberos V . . . . . . . . . . . . . . . . . . . . . . 7.3.1. Servidor Heimdal Kerberos . . . . . . . . . . . . . . . . . 7.3.2. Cliente Kerberos . . . . . . . . . . . . . . . . . . . . . . . 7.3.3. Kerberizando SSH . . . . . . . . . . . . . . . . . . . . . . 7.4. OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1. Usuarios y Grupos en Unix/Windows . . . . . . . . . . . 7.4.2. Grupo Wheel (GID 0) . . . . . . . . . . . . . . . . . . . . 7.4.3. Esquema del Directorio . . . . . . . . . . . . . . . . . . . 7.4.4. Servidor Maestro . . . . . . . . . . . . . . . . . . . . . . . 7.4.5. Estructura del Directorio . . . . . . . . . . . . . . . . . . 7.4.6. Asociando el Sistema con el Directorio: PAM & NSSwitch 7.5. Extendiendo BIND (Servidor DNS) sobre LDAP . . . . . . . . . 7.6. Congurando Controlador de Dominio para Windows: Samba . . 7.7. Congurando MTA: Postx . . . . . . . . . . . . . . . . . . . . . 7.7.1. Cluster de Correo . . . . . . . . . . . . . . . . . . . . . . 7.7.2. Sistema de correo distribuido . . . . . . . . . . . . . . . . 7.7.3. Entorno Mixto . . . . . . . . . . . . . . . . . . . . . . . . 7.7.4. Instalando Prerequisitos . . . . . . . . . . . . . . . . . . . 7.7.5. Organizaci on y Esquema de Directorio . . . . . . . . . . . 7.7.6. Postx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8. Congurando POP3/IMAP: Courier . . . . . . . . . . . . . . . . 8. Si algo va mal

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

 Indice de guras
2.1. Estructira de la organizaci on BSDLand . . . . . . . . . . . . . . . . . . . . . 3.1. Dise no Conceptual de la Red . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Estructura Real de la Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. Estructura B asica del Directorio LDAP para BSDLand . . . . . . . . . . . . . 5.1. FreeBSD vs Linux, AMD64 8-Core SMP Multithread . . . . . . . . . . . . . . 5.2. FreeBSD vs Linux, AMD64 8-Core SMP Single-Thread . . . . . . . . . . . . . 6.1. Men u de Instalaci on/Conguraci on de FreeBSD - sysinstall . . . 6.2. Opciones de Instalaci on . . . . . . . . . . . . . . . . . . . . . . . 6.3. Listado de Elementos a Instalar . . . . . . . . . . . . . . . . . . . 6.4. Men u de Conguraci on . . . . . . . . . . . . . . . . . . . . . . . . 6.5. Interfaces de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6. Interface de Red lnc0 . . . . . . . . . . . . . . . . . . . . . . . . . 6.7. Servicios de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8. Conguraci on de Inicio . . . . . . . . . . . . . . . . . . . . . . . . 6.9. Listado de las ACL de la carpeta netlogon desde Windows Vista 6.10. Diagrama de un Firewall Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8 9 13 18 19 24 24 25 25 26 26 27 28 35 37 80 82

7.1. Cluster de Correos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. Granja de Servidores Distribuidos . . . . . . . . . . . . . . . . . . . . . . . . .

iii

 Indice de cuadros
3.1. Conguraci on de las Interfaces en el Nodo A . . . . . . . . . . . . . . . . . . 3.2. Conguraci on de las Interfaces en el Nodo B . . . . . . . . . . . . . . . . . . . 6.1. Conguraci on de la Interface lnc0 . . . . . . . . . . . . . . . . . . . . . . . . . 7.1. Tabla Comparativa prara Usuarios Windows/Unix . . . . . . . . . . . . . . . 6 6 27 57

Prefacio
Este libro representa un esfuerzo para mostrarle a los lectores la potencialidad del Software Libre en el campo de las Redes Empresariales y contribuir as con el crecimiento de la Comunidad. Va dedicado a todos aquellos Cubanos que han hecho su aporte de una forma u otra al fortalecimiento del Movimiento del Software Libre.

vii

Licencia
Copyright (c) 2007 Alejandro Tamayo Castillo - All rights reserved. Redistribution and use in source (Latex) and compiled forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modication, are permitted provided that the following conditions are met: 1. 2. Redistributions of source code (Latex) must retain the above copyright notice, this list of conditions and the following disclaimer as the rst lines of this le unmodied. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS DOCUMENTATION IS PROVIDED BY ALEJANDRO TAMAYO CASTILLO AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ALEJANDRO TAMAYO CASTILLO BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

ix

Retroalimentaci on / Feedback
Estimado lector, usted puede enviar sus opiniones y sugerencias a la siguiente direcci on: aletc1@gmail.com y as contribuir con el mejoramiento de este libro que tiene como objetivo facilitar el aprendizaje y promover el trabajo con FreeBSD y en general con aplicaciones/servicios Libres. Por favor, no utilice la direcci on electr onica que se ha publicado anteriormente como destino de SPAM y/o basti on para encabezar una guerra (Flamewar) entre software.

xi

Cap tulo 1

Introducci on
El dise no, instalaci on y mantenimiento de redes empresariales hoy en d a puede decirse que es un aspecto crucial para la productividad y el desarrollo de cualquier empresa. Esta gu a tiene como objetivo explicar de una manera sencilla (o al menos esa es la idea) como dise nar y desplegar una red que se ajuste a las necesidades y caracter sticas de su organizaci on. Existen muchos software como Windows 2003 Enterprise Server, Productos Microsoft en general, RedHat Enterprise Server, SuSE Linux Enterprise Server, Solaris, entre otros que solucionan estas necesidades, sin embargo el costo de implantaci on y mantenimiento puede ser elevado en cuanto a presupuesto y recursos, debido al monto de las licencias y el costo del hardware especializado necesario para correr este tipo de sistemas. En esta gu a veremos como hacer lo mismo o casi lo mismo que puede lograrse con este tipo de sistemas usando software libre y hardware barato (Tenga en cuenta que tratamos de minimizar el costo, no hacer Magia! As que barato es una palabra relativa, ya que si piensa brindar servicios para +1000 usuarios no creo que barato cobre el signicado y sentido tradicional de la palabra). Pues hemos hasta ahora mencionado m as de una vez el t ermino Red Empresarial as que me parece buena idea hacer una denici on del mismo ya que puede en Internet encontrarse con varios signicados. Una Red Empresarial (como la estoy deniendo) es una gran red que engloba a todas las divisiones, entidades y unidades pertenecientes a una misma organizaci on, est a acorde con el dise no estructural (organizativo) de la misma y puede o no superar los limites geogr acos. En otras palabras, es una gran WAN (Wide Area Network) que puede tener varios nodos (redes locales) separados y distribuidos geogr acamente. En este documento no se toca ninguno de estos temas: Clusters, Balance de Red (Load Balancing), Failover, Network Storage (SAN), Protocolos de Encaminamiento Avanzado (Routing Protocols), Data Backup, entre otras cosas, ya que este tipo de tecnolog as necesitan hardware y software especializado (los llamados High End) los cuales son sumamente costosos y entran en contradicci on con mi objetivo as que disc ulpenme aquellos que esperaban leer algo acerca de este tipo de cosas. Pienso que estas tecnolog as son sumamente importantes, sin embargo, no todas las organizaciones pueden obtenerlas, por lo cual no las incluyo.

CAP ITULO 1. INTRODUCCION

Cap tulo 2

Necesidades de la Organizaci on Ficticia BSDLand

Denamos para nuestro trabajo una organizaci on totalmente inventada por nosotros llamada BSDLand (En caso de que alguien ya haya denido una organizaci on con este nombre en la vida real, que nos disculpen entonces) dedicada a la producci on de software. Supongamos tambi en que compramos el dominio bsdland.com y hagamos ahora una lista de las necesidades de esta empresa: Debe poder alojarse digitalmente la estructura de la organizaci on (Direcci on, Divisiones, Unidades, Departamentos, etc.), as como el perl de cada trabajador y debe dise narse de tal manera que admita futuros cambios estructurales (Fusi on de Departamentos, Eliminaci on de Divisiones, etc.) en otras palabras, se desea Escalaridad. Todas las redes LAN (Local Area Network) deben poderse intercomunicar seg un convenga, as como deben poder acceder a Internet y debe existir un control de todas estas operaciones. Cada LAN debe estar congurada con los servicios necesarios para servir tanto clientes Windows como UNIX. Se deben brindar diferentes servicios como correo, almacenamiento de cheros, colaboraci on, entre otros. Se desea unicidad. Cada trabajador deber a poder recibir correos tanto desde @unidad.division.bsdland.com como @bsdland.com. Se desean m ultiples puntos de acceso. Los trabajadores pueden estar en constante movimiento y deben poder acceder a su perl y correo desde cualquier nodo. Estos puntos de Acceso aceptar an comunicaciones v a Internet o v a Modem. Se debe proteger las comunicaciones con ltros Anti-Spam, Anti-Virus y utilizaci on de protocolos seguros. Cada nodo (unidad, divisi on) deber a tener sus servidores propios y la comunicaci on entre los nodos deber a ser la m nima necesaria con el objetivo de ahorrar ancho de banda. 3

FICTICIA BSDLAND CAP ITULO 2. NECESIDADES DE LA ORGANIZACION

El servicio de correos es de cr tica importancia para la organizaci on, as que no pueden perderse los mismos en caso de alguna rotura en alg un servidor. Hemos denido una organizaci on Abstracta, sin embargo es necesario tener m as informaci on acerca de la misma as que personalicemos un poco m as la estructura de BSDLand:

Figura 2.1: Estructira de la organizaci on BSDLand Como vemos en la gura 2.1 BSDLand es una empresa que desarrolla software tanto para BSD, como para Windows, as que cuenta con dos divisiones (Verde y Azul): La divisi on principal (Headquarters) ubicada en el pa s A. La divisi on dedicada al desarrollo de aplicaciones para Windows ubicada en el pa s B. La divisi on principal, cuenta con dos departamentos: Dpto de Ventas Dpto dedicado al desarrollo de aplicaciones para BSD Como puede apreciarse BSDLand es una peque na empresa con dos Edicios ubicados en dos pa ses diferentes que tiene un dise no bastante simple. El mismo ha sido escogido ya que cualquier otro que ud. cree no va a ser m as que una combinaci on de los elementos de este, es decir, puede que existan mas divisiones, unidades, departamentos y se ponga tan complejo como desee, sin embargo veremos que las explicaciones que daremos en esta gu a son totalmente extensibles para cualquier dise no. Entonces hemos creado una organizaci on con necesidades virtuales que pueden ser las reales de una empresa no cticia.

Cap tulo 3

Dise no de Red
3.1. TCP/IP

Entrando en materia, lo primero que debemos hacer es el dise no de la Red TCP/IP que vamos a utilizar. Llam emosle Nodo a cada Divisi on denida en el ep grafe anterior. Pues en cada nodo tendremos entonces un enlace a Internet que le alquilaremos al ISP (Internet Service Provider) de cada pa s y adem as tendremos un enlace a la red LAN as que como m nimo tenemos que utilizar un servidor por Nodo y cada servidor debe tener al menos 2 NIC (Network Interface Card). Para uso de nuestro documento, supongamos que la red 10.0.0.0/8 son los IPs que asignan los proveedores de Internet a los cuales BSDLand le arrendar a/comprar a el enlace.

Esto es realmente un error ya que la red 10.0.0.0/8 est a clasicada para uso privado y no publico, sin embargo, y a pesar de que no me gusta esta idea, en aras de no utilizar IPs p ublicos (Segmentos P ublicos Reales) hagamos esta suposici on. Por tanto 10.0.0.1 ser a el IP publico del nodo principal y 10.0.2.1 ser a el IP publico del nodo Windows. Tenga en cuenta que normalmente los ISPs asignan segmentos de redes (Rangos de 8, 16,... IPs) sin embargo para nuestro ejemplo solo es necesario tener en cuenta los IPs que tienen los servidores as que da igual cualquiera que se escoja (Los segmentos ser an 10.0.0.0/24 y 10.0.2.0/24). Ahora tenemos que denir los segmentos de red privados de cada nodo. Esto es una tarea que puede ser tan compleja como se desee en dependencia de la cantidad de computadoras por nodo y las divisiones f sicas que se deseen tener en cada uno. Como este documento realmente no es un curso de redes, doy por sentado que el lector sabe como efectuar esta tarea. Supongamos que la cantidad de PCs, no excede los 255 para simplicar el dise no. Entonces podremos utilizar los segmentos de red privados 192.168.0.0/24 y 192.168.1.0/24 para cada nodo. Resumiendo, los adaptadores de red quedar an as : Note que cada segmento de red LAN tiene que ser diferente en cada Nodo, ya que cuando unamos todas las redes locales si se solapan algunos segmentos, van a ocurrir graves errores de encaminamiento as que es extremadamente importante que este paso se efect ue correctamente. Note tambi en que la red 192.168.0.0/16 ha sido dividida en 256 Nodos de Red (192.168.0.0/24, 5

DE RED CAP ITULO 3. DISENO Interface Internet Lan IP 10.0.0.1 192.168.0.1 Red 10.0.0.0/24 192.168.0.0/24

Cuadro 3.1: Conguraci on de las Interfaces en el Nodo A Interface Internet Lan IP 10.0.2.1 192.168.1.1 Red 10.0.2.0/24 192.168.1.0/24

Cuadro 3.2: Conguraci on de las Interfaces en el Nodo B 192.168.1.0/24, ... ,192.168.255.0/24,) donde cada uno puede tener hasta 255 PC. Lo que signica que se pueden crear hasta 254 nuevas divisiones en BSDLand. Es muy importante prever el crecimiento de la red y crear un dise no consecuente. En esta partici on, se ha presupuesto que ning un nodo tendr a m as de 255 computadoras. La idea es tratar de no desperdiciar direcciones IP.

3.2.

Uni on de las Redes

Teniendo ya creado los dos nodos pasemos ahora a la uni on de los mismos. La idea es crear un t unel entre ellos y para lograr esta tarea existen varias soluciones:

T unel PPTP T unel L2TP T unel IP T unel IPSec IPSec

3.2.1.
1.

T unel PPTP/L2TP

Los protocolos PPTP y L2TP est an orientados a conexi on y se realizan en la capa TCP El funcionamiento es el siguiente: un paquete IP que desee llegar a la red privada en el nodo externo, se encapsula, se le env a al nodo externo a trav es del protocolo PPTP (L2TP) y este desencapsula el contenido recibido y encamina el paquete original. La diferencia entre PPTP y L2TP es que los datos con L2TP viajan codicados utilizando un certicado digital. La desventaja de este sistema es que un fallo en la conexi on desconectar a el t unel y este demorar a unos segundos en volver a conectar. Adem as se necesita software especializado en cada punto y este no es muy est andar que digamos. 2 .
1 2

Recuerde que el protocolo TCP/IP est a desglosado en capas: Ethernet, IP, TCP/UPD, Aplicaci on Las Microsoft Virtual Private Network o simplemente VPN implementan PPTP y L2TP

 DE LAS REDES 3.2. UNION

3.2.2.

T unel IP/IPSec

Los t uneles IP/IPSec no son orientadas a conexi on y se realizan en la capa IP. El funcionamiento es similar a PPTP/L2TP con la diferencia que el paquete no se env a a trav es de un protocolo, sino se encapsula dentro de otro paquete IP y se encamina directamente. La diferencia entre un t unel IP y uno IPSec es que con un t unel IP los paquetes viajan tal y como son y cualquiera puede ver que es lo que se est a trasmitiendo y con IPSec la regi on de Datos del paquete viaja codicada usando un certicado digital o una palabra clave.

3.2.3.

IPSec

Un t unel IPSec y utilizar IPSec para transmitir datos son cosas diferentes. Cuando se utiliza IPSec en la interface de Red, este codica todo el traco entrante y saliente desde un IP hacia un IP (La regi on de datos del paquete IP) usando un certicado digital o una palabra clave. Nosotros no querr amos que las personas ajenas a nuestra organizaci on chismearan en nuestras comunicaciones, as que las variantes a considerar son aquellas que codican la informaci on. En esta gu a nos iremos por las variantes T unel IPSec e IPSec+T unel IP. La ventaja de un T unel IPSec es que puede utilizarse un Certicado o Clave por T unel (Suponiendo que hayan 3 nodos, para comunicar todos con todos deber an hacerse 6 t uneles) y el traco no importante o p ublico entre los nodos viajar a sin codicar. Note que codicar informaci on toma tiempo y se ha demostrado que puede rebajar el rendimiento un 25 porciento cuando hay mucha carga. La desventaja es la cantidad de t uneles que habr a que crear cuando la cantidad de nodos aumenta. La ventaja de IPSec+T unel IP es que el traco entre nodos que pasa por el Adaptador de Red es el que se codica y el traco entre redes privadas simplemente se encamina sin codicaci on (el adaptador hace el trabajo sucio). Adem as con un solo certicado/clave se resuelve la codicaci on. No es necesario crear t uneles ya que se puede encaminar el paquete libremente entre nodos, aunque no seria mala idea crear t uneles sin codicaci on. La desventaja es que todo el tr aco entre nodos que pasa por la tarjeta de red se codica y esto puede que no sea necesario siempre. Ambas variantes superan a PPTP (L2TP) en el sentido de que como no son orientadas a conexi on un problema de red solo retrasar a los paquetes, no desconectar a a las redes, as que la recuperaci on ante un fallo es inmediata, adem as por ubicarse en una de las capas mas bajas de TCP/IP est a exento de los problemas que pueden ocurrir con los servicios orientados a conexi on (Time-Outs, etc). Una desventaja es que es m as complicado de congurar en algunos sistemas operativos. Sin embargo esto no es una desventaja para nosotros ya que como lo demostraremos aqu con el Sistema Operativo que propondremos es realmente f acil congurarlo. Los protocolos PPTP (L2TP) se idearon para la conexi on Usuario Final Servidor debido a la facilidad que implica crear conexiones de este estilo. IPSec est a concebido para la conexi on Servidor Servidor debido a la complejidad de implantaci on

DE RED CAP ITULO 3. DISENO

Figura 3.1: Dise no Conceptual de la Red

3.3.

Esquema de Red

Resumiendo, tenemos un dise no de estrella donde el mundo exterior (Internet) est a separado de la Red Privada y a su vez esta u ltima est a distribuida por los nodos de la organizaci on y protegida mediante codicaci on de los datos. El servidor que separa Internet de la Red Privada se le llama Gateway o Punto de Acceso. La gura 3.1 muestra el dise no conceptual de nuestra red (Suponiendo que existan 3 nodos). La Red privada se muestra como un todo ya que desde cualquier segmento se puede acceder a cualquier segmento (de eso se encargan los T uneles IP y/o IPSec). Cada Servidor Gateway es un Punto de Acceso a la Red Privada. Sin embargo, el dise no real (F sico) es el que se muestra en la gura 3.2. Note que esto es un dise no b asico en donde supuestamente todos los nodos pueden acceder a la informaci on de todos los nodos. En un dise no real es posible que algunos nodos no deban acceder a otros. En cualquier caso cada punto de acceso es responsable del tr aco que pasa hacia su nodo, as que limitar la conectividad es responsabilidad del Firewall. Cada Nodo tiene un segmento de red asociado. En este ejemplo es simple, pero pudiese complicarse. Ejemplo: Que cada departamento (En un mismo Nodo - LAN) tenga su propio segmento de red para limitar tr aco entre los mismos.

3.3. ESQUEMA DE RED

Figura 3.2: Estructura Real de la Red En ese caso, el punto de acceso deber a tener un NIC, por cada segmento de red (Departamento) o se deber a a nadir un Switch capa 3 (Un poco costoso) para distribuir el tr aco.

10

DE RED CAP ITULO 3. DISENO

Cap tulo 4

Estructura Organizativa
Es tiempo de tomar una de las decisiones m as importantes: como almacenar la estructura organizativa. Cuando denimos la estructura de BSDLand vimos que ten amos Divisiones, Departamentos y por supuesto, cada departamento tiene trabajadores. Es necesario guardar esa informaci on y organizarla seg un su estructura jer arquica (Adem as de la informaci on, hay que guardar la contrase na de cada trabajador, y en general todos los datos necesarios para autenticar el usuario en la red). Pues para ello puede usarse la base de datos de usuarios del sistema operativo, una base de datos SQL como MySQL o PostgreSQL o pudi eramos usar un servidor LDAPv3 como OpenLDAP. Veamos r apidamente por que OpenLDAP supera a todas las variantes anteriores. La base de datos de usuarios del sistema operativo queda descartada ya que los usuarios no pertenecen a un servidor sino a la organizaci on. Adem as en la base de datos del sistema no podemos adicionar ning un objeto/dato/meta dato (como direcci on y foto) que no sean los predenidos por el sistema. Con un servidor SQL ya podemos hacer mas cosas. Podemos crear los campos b asicos del sistema (nombre de usuario, contrase na, homedir, etc.) y m as a un, podemos denir por usuario cualquier caracter stica que deseemos ya que MySQL (PostgreSQL) son sistemas de bases de datos relacionales. Sin embargo, queda a un un problema: el hospedaje y la replica de los datos. El servidor SQL no puede hospedarse solo en uno de los servidores, sino que tiene que estar distribuido por todos los nodos por si alguno falla, no se caiga la red completa (Note que si los usuarios no pueden validarse, ning un servicio va a funcionar). Adem as los cambios tienen que replicarse: si se agrega un usuario en un servidor debe noticarse/enviarse este cambio hacia todas las r eplicas. Tanto PostgreSQL como MySQL, tienen sistemas de replicas, pero son extremadamente complicados de congurar. Por Ejemplo: PgCluster (PostgreSQL), necesita un Servidor Maestro, Un Servidor de Sincronizaci on, y las Replicas... en n, si quisi esemos solamente tener un Maestro y un Esclavo, necesitar amos obligatoriamente tener un servidor de sincronizaci on (Mucho Gasto!). Adem as tenemos otro problema m as Como manejamos la creaci on de un mismo usuario por dos administradores en nodos diferentes? Simplemente es un poco complejo... y que nadie me malinterprete! PgCluster es extremadamente eciente para Balance de cargas y replicas de Bases de Datos... el punto es que existe ya un sistema totalmente preparado que resuelve todos estos detalles por nosotros: OpenLDAP y no es necesario gastar energ as en un servidor de Bases de Datos. 11

12

CAP ITULO 4. ESTRUCTURA ORGANIZATIVA

OpenLDAP implementa el protocolo LDAPv3 (Lightweight Data Access Protocol versi on 3) el cual est a dise nado espec camente para almacenar la estructura organizativa de la empresa y resolver todos estos detalles que anteriormente mencion abamos. En el caso de OpenLDAP, este usa como backend un sistema de base de datos que de manera predeterminada es BDB (Berkeley Database) pero puede cambiarse por cualquier otro (Y aqu puede entrar a jugar MySQL o PostgreSQL). Sin embargo BDB es un motor de base de datos sencillo, compacto, eciente y realmente no es recomendable cambiarlo a menos que sepamos lo que estamos haciendo. El papel fundamental del servidor OpenLDAP no lo juega el backend sino la implementaci on del protocolo LDAP como tal. Este es, como su nombre lo dice, extremadamente r apido y liviano y permite crear una estructura jer arquica de manera que podemos dise nar nuestra empresa de manera f acil. Voy a saltarme la explicaci on de como funciona OpenLDAP (LDAPv3 en general), ya que existen cursos detallados que explican esto (http://www.openldap.org/). Solo voy a tocar los aspectos de m as inter es. Microsoft Active Directory, el sistema de validaci on de los usuarios (y otras cosas m as) que viene con Windows 2000 (2k3) no es m as que una implementaci on del protocolo LDAPv3. Existen otros servidores compatibles con LDAPv3 libres, sin embargo hemos escogido OpenLDAP debido a que es el m as est andar y portable de todos. Los otros servidores solo se pueden instalar en uno o dos sistemas operativos, algo que limita y corta la libertad de decisi on.

4.1.

Modelos de Servidores LDAP

Un servidor LDAP puede ser solo lectura (RO) o lectura escritura (RW). Supongamos que tenemos dos servidores RW y dos administradores desean crear al usuario alex y cada uno lo hace en un servidor diferente. Si los servidores permiten esta operaci on, los datos quedar an inconsistentes, ya que cual de los dos alex ser a el real? Supongamos que no permitan esa operaci on, entonces, cual se agrega y cual se deniega? Pues ese tipo de decisiones se toma de maneras diferentes en dependencia de los siguientes criterios o modelos:

4.1.1.

Single Master (Maestro u nico)

De todos los servidores LDAP que hospedan una misma organizaci on, solo uno es RW. Esto asegura que no existan inconsistencias ya que las operaciones de escrituras son sincr onicas (una primero y otra despu es). La desventaja de este modelo es que si se cae el servidor maestro solo se pueden efectuar lecturas a la organizaci on hasta que se recupere el mismo o se promueva un servidor replica (shadow) a maestro (master). Este modelo lo implementa el servidor OpenLDAP.

4.1. MODELOS DE SERVIDORES LDAP

13

4.1.2.

Dual Master (Maestro Doble)

Este modelo, permite tener dos servidores maestros RW. Si uno cae, el otro contin ua las operaciones. Seg un los expertos a pesar de los algoritmos que se implementen para mantener la consistencia de los datos existen escenarios en los cuales falla y se requiere intervenci on humana. Este modelo lo implementa Fedora Directory Services.

4.1.3.

Multi-Master (Maestro M ultiple)

Se permiten varios servidores maestros RW con algunas restricciones. Es un modelo altamente riesgoso el cual si no se maneja bien puede traer malas consecuencias. Adem as generalmente existen tipos especiales de servidores RW donde la escritura es solo parcial y/o Global. Un ejemplo de esto es Microsoft Active Directory en el cual existen servidores RO (Backup Domain Controler), RW Parcial (Domain Controler) y RW Totales o Globales (Global Catalog). Hay muchas personas que aseguran que el modelo m as eciente es el Single Master y que no existe necesidad de utilizar ning un otro. Yo comparto esa idea y veremos en esta gu a cuando implementemos de manera concreta OpenLDAP como podemos manejar la ca da del u nico servidor maestro. Tambi en es verdad que el modelo Multi-Master provee muchas ventajas, sin embargo se necesita m as trabajo para mantenerlo funcional y mucho hardware en dependencia de la implementaci on que utilicemos. Pues veamos como quedar a nuestro dise no LDAP.

Figura 4.1: Estructura B asica del Directorio LDAP para BSDLand Como se muestra en la gura 4.1 tenemos el dominio dc=bsdland,dc=com (bsdland.com) que tiene como unidades organizativas (Departamentos) Ventas y Desarrolladores BSD. Adem as tenemos un subdominio dc=windows,dc=bsdland,dc=com (windows.bsdland.com) que tiene como unidad organizativa a Desarrolladores Windows. Cuando efectuemos el despliegue de OpenLDAP veremos que esta estructura es totalmente b asica, ya que necesitaremos agregar muchos objetos m as para poder crear totalmente a nuestra organizaci on.

14

CAP ITULO 4. ESTRUCTURA ORGANIZATIVA

Cap tulo 5

Selecci on del Software a Utilizar

De una correcta selecci on del software de aplicaci on y sistema operativo depende en gran medida el resultado nal en cuanto a rendimiento y usabilidad de nuestro sistema as que antes de empezar a congurar, creo que se le debe dedicar unos puntos en este documento a ese aspecto.

5.1.

Seleccion del Sistema Operativo

Esto es una decisi on un tanto dif cil y que siempre va a ser un tema pol emico, ya que existe una gran variedad de sistemas operativos libres con gran calidad y tras cada uno de ellos existen grupos de fans que aseguran cual sistema sirve y cual no y realmente a ciencia cierta no existe como tal una verdad absoluta que dena al mejor sistema operativo; cada uno tiene buenas prestaciones y otras no tan buenas. As que simplemente seleccionar e uno y explicar e el porqu e de mi selecci on. Ah! Por supuesto que los sistemas comerciales no entran en la selecci on. As que nos quedaremos con los BSDs y las distribuciones Linux que son los dos grupos que llevan digamos que la vanguardia en cuanto a popularidad. En los BSDs tenemos a FreeBSD, NetBSD y OpenBSD y en los Linux, pues creo que no me alcanzar an las p aginas para nombrar cada distribuci on que existe. Sin embargo me voy a limitar a 3 de las m as conocidas: Fedora, Open SuSE y Debian (En realidad las u nicas tres que he probado). No divagar e m as y dir e cual es mi selecci on: FreeBSD (http://www.freebsd.org/). Creo que las razones que me han llevado a esta selecci on son m as bien personales ya que he trabajado con FreeBSD desde la versi on 3.0 y he tenido muchos problemas con RedHat Linux (Actualmente la versi on libre es Fedora) y en general con las distribuciones Linux que he instalado y nunca he presentado ning un problema con FreeBSD. El sistema operativo OpenBSD es mucho mejor que FreeBSD cuando de seguridad se trata (Firewall, Routing - tiene un gran historial) sin embargo, busco un servidor All Purpose f acil de trabajar, estable, escalable, conable, disponible y eciente, cosa que en algunos escenarios OpenBSD queda desplazado por FreeBSD1 .Pero como siempre digo es una cuesti on de gustos ya que con todos se puede de una manera u otra hacer lo mismo. Ahora, apartando mis gustos a un lado, hay tres cosas que me hacen seleccionar FreeBSD
Hoy en d a OpenBSD y FreeBSD comparten el mismo c odigo base para muchas cosas. Por ejemplo FreeBSD implementa Packet Filter, el Firewall por excelencia de OpenBSD, as que es muy dif cil decir que OpenBSD es mejor o peor que FreeBSD
1

15

16

DEL SOFTWARE A UTILIZAR CAP ITULO 5. SELECCION

por sobre todos los OS que he mencionado: Dise no y ciclo de producci on: Existen varios art culos que catalogan a BSD como ordenado y a los Linux de ca oticos. En principio el desarrollo y mantenimiento de FreeBSD es cerrado, es decir, las modicaciones est an a cargo del grupo de sus desarrolladores y siguen reglas estrictas para mantener el c odigo seguro y ordenado: Todo el c odigo est a bajo CVS y se marca como freeze si los cambios deben ser aprobados por un supervisor u open si se pueden hacer cambios libremente. Si visitamos http://www.freebsd.org/releng podemos ver el estado de todas las ramas del Sistema. Adem as en FreeBSD existen capas: Kernel, Base System, Userland y Packages y cada elemento que se a nade a alguna de estas capas se reescribe, en dependencia de las necesidades, para mantener el rendimiento del sistema, en su totalidad, al m aximo. Sin embargo la mayor a de las distribuciones Linux siguen el concepto de armar un sistema a pedacitos, es decir: toma el Kernel Linux, a nade GCC, a nade Xorg, y as b asicamente se logra el sistema. Un ejemplo de esto es OpenSSH: en la mayor a de las distribuciones Linux es un paquete m as que se compila desde el sitio ocial y se a nade al sistema. En FreeBSD, OpenSSH no puede ser instalado como paquete ya que est a integrado a la base del sistema y realmente no es el OpenSSH cl asico sino una versi on personalizada (rescrita) que se integra a bajo nivel con el sistema. Este nivel de integraci on/separaci on controlado por los desarrolladores de FreeBSD le brindan al sistema una ganancia en cuanto a rendimiento y estabilidad. Adem as, de una misma versi on de FreeBSD existen tres ramas diferentes: CURRENT, RELEASE y STABLE. CURRENT es donde constantemente se agregan nuevas tecnolog as y est a en constante desarrollo (Es la versi on de desarrollo/prueba de FreeBSD ya que en alg un escenario puede fallar). Cuando se considera que estas tecnolog as est an aptas para un entorno productivo (despu es de una serie de pruebas) se agrega a la rama STABLE. Sin embargo, esta rama puede tener algunos bugs todav a y es por eso que se crea la rama RELEASE que no es m as que un snapshot de la rama STABLE que se mantiene independiente (solo se efect uan modicaciones al c odigo para eliminar bugs y errores de seguridad, no para a nadir nuevas caracter sticas) por lo cual se recomienda para entornos que necesiten una gran estabilidad. Lo bueno de estas divisiones es que ud. como administrador puede escoger la versi on que m as se ajuste a sus necesidades. Instalaci on/Actualizaci on de todo el Sistema basada en C odigo fuente: Normalmente la Instalaci on/Actualizaci on de las distribuciones de Linux vienen orientadas a paquetes binarios precompilados. Es decir, si queremos actualizar a la u ltima versi on del Kernel o simplemente deseamos la ultima versi on de nuestro servidor Web, utilizamos el administrador de paquetes del sistema (Yast, Apt, en dependencia) que autom aticamente baja de Internet el paquete precompilado requerido y lo instala. Y esto puede parecer muy natural, sin embargo cada hardware es diferente y un programa no corre igual en un procesador con SSE2 (si se compila con soporte para SSE2) que en uno con solo MMX, y los paquetes binarios normalmente vienen precompilados para procesadores gen ericos y no utilizan tecnolog as espec cas. Es por eso que compilar un software (y m as en un servidor productivo) es muy recomendado para as usar instrucciones espec cas que siempre son m as r apidas que las gen ericas. Y hasta ahora no he dicho nada novedoso, ya que sobre linux pudi esemos bajar manualmente (o usando aptget build source paquete) cada software, compilarlo e instalarlo... pero todos los d as

5.1. SELECCION DEL SISTEMA OPERATIVO

17

salen parches de seguridad, actualizaciones y mejoras, as que compilar/instalar manualmente es un rollo. FreeBSD resuelve este problema de una manera muy inteligente. Cuando se instala el sistema base, se instala tambi en un snapshot del c odigo fuente de todo el sistema y cuando digo todo es todo! tanto utilitarios como kernel. Entonces basta con sincronizar el c odigo local con el hospedado en el sitio de FreeBSD mediante CVS. No es necesario bajar ning un binario, simplemente se descargan los cambios del c odigo, por lo cual es un proceso extremadamente r apido y optimizado. Entonces se recompila el mundo y se tiene un sistema operativo totalmente nuevo/actualizado. Cuando compilas una vez y haces una actualizaci on del c odigo solo se recompila la parte cambiada por lo cual la compilaci on es extremadamente r apida. FreeBSD provee algunos scripts que automatizan este proceso por lo cual es totalmente f acil de utilizar y con esto se garantiza que el Sistema corra con el mayor rendimiento posible en su hardware. Y eso no es todo! Todos los programas populares como Apache, Squid, Samba, OpenLDAP, Postx, etc entran en este sistema (A esto se le llama los Ports). Hay un grupo de personas bastante extenso ligado a FreeBSD que se encarga de mantener m as de 100000 puertos actualizados con las u ltimas versiones. Y todav a hay m as. El c odigo de cada uno de estos programas se modica para que corran sobre FreeBSD de la manera m as eciente posible. El sistema de Ports garantiza obtener el u ltimo c odigo fuente, parchear el c odigo para freebsd, compilar de manera optima seg un el hardware, crear un paquete binario y registrarlo en el sistema de manera autom atica y f acil el cual en el futuro puede ser desinstalado como un paquete binario m as. Adem as se brinda con los puertos una base de datos actualizable con los u ltimos detalles de seguridad para que ud. como administrador pueda conocer el estado de los paquetes instalados en el sistema. Resumiendo, lo que hacemos manualmente en Linux, puede hacerse aqu de manera autom atica. Y si no os gusta este sistema, pueden ignorarlo ya que freebsd tiene un administrador de paquetes que es funcionalmente parecido a Yast o Apt. Rendimiento hist orico: Los BSDs son sistemas operativos que tienen muchos a nos de experiencia y han demostrado ser estables y potentes. Muchas de las versiones comerciales de los sistemas operativos de alto rendimiento como Solaris est an basados en alg un BSD. Adem as hablando de FreeBSD espec camente creo que puedo decir que es un sistema conservador donde no todo hardware funciona. En Linux esto no es as ya que todos hacen drivers y modicaciones al Kernel, y esto es muy bueno en algunos casos... pero no siempre resulta ya que si el driver no es seguro y estable el sistema se desploma con mucha facilidad. Esos son los encantos b asicos de FreeBSD, aunque si nos ponemos a hacer un poco de propaganda podemos hablar de las opciones de seguridad que brinda como los SecureLevels del Kernel y los Jails adem as de los tipos de rewalls que trae (Packet Filter, IPFW) y del dise no del Stack TCP/IP que brinda seg un algunos tests, un rendimiento de hasta un 15 porciento comparado con Linux en algunos escenarios. Pero como mi objetivo no es iniciar una guerra, digo una vez m as que no existe el sistema operativo mejor. Un ejemplo de esto es la distribuci on Linux Debian que ha demostrado ser estable y potente. Para m as informaci on recomiendo que se busque en Google FreeBSD vs Linux y aparecer an muchos art culos interesantes explicando los pro y los contra de cada uno. Hay varias distribuciones de Linux que implementan algo como los Ports de FreeBSD, llamado Backports, sin embargo no lo tengo en cuenta ya que

18

DEL SOFTWARE A UTILIZAR CAP ITULO 5. SELECCION

no es algo maduro (hasta donde he le do). No obstante puede que existan m as variantes de este estilo, sin embargo, al no estar integradas al sistema o no tener popularidad simplemente no se tienen en cuenta. Y cuando digo popularidad no me reero a fama sino a gran cantidad de personal trabajando para mantener el sistema/programa actualizado y funcionalmente estable.

5.1.1.

FreeBSD vs Linux

Hist oricamente FreeBSD (hasta la versi on 4) ha tenido mayor rendimiento que Linux 2.4 bajo presi on de carga. Sin embargo, la comunidad ha quedado un poco decepcionada con la aparici on de FreeBSD 5.x debido a que Linux 2.6 ha digamos que ganado la mayor a de los test de rendimiento bajo gran cantidad de carga utilizando SMP (Symmetric Multiprocessing). No obstante hay que tambi en resaltar que la versi on 5.x se marc o por los productores de FreeBSD como New Technology y la versi on 4.x sigui o siendo Production Release, as que podemos ver a la serie 5.x como una BETA tecnol ogica. Ahora FreeBSD 6.x ha alcanzado su madures y ya es una versi on para entornos productivos. Veamos entonces los gr acos benchmark obtenidos con SysBench comparando FreeBSDCurrent contra Fedora Core.2 Los resultados que aparecen en las Figuras 5.1 y 5.2 son

Figura 5.1: FreeBSD vs Linux, AMD64 8-Core SMP Multithread

2

Gr aco obtenido desde http://jer-tech.livejournal.com/6268.html

 DEL SOFTWARE DE APLICACION (SERVICIOS) 5.2. SELECCION

19

Figura 5.2: FreeBSD vs Linux, AMD64 8-Core SMP Single-Thread producto de las mejoras inicialmente introducidas en la serie 5.x y que ahora han madurado. Especialmente el nuevo ULE-Scheduler de FreeBSD que es quien garantiza la administraci on de los procesos.

5.2.

Selecci on del Software de Aplicaci on (Servicios)

Ya tenemos el sistema operativo, ahora seleccionemos el software que utilizaremos para poder realizar las tareas que al inicio nos propusimos.

5.2.1.

Servicio de Seguridad Kerberos

Las contrase nas de las cuentas de usuarios cr ticas en nuestra organizaci on como por ejemplo aquellas con permiso a efectuar tareas de administraci on deben protegerse de alguna manera. Por ning un motivo estas deben viajar sin codicaci on (Text Plain) a trav es de la red privada y en realidad, ni siquiera deber an viajar o al menos hacerlo solo la cantidad de veces necesarias. Es por ello que se implementar a un servidor Kerberos 5, y espec camente Heimdal Krb5 que viene ya integrado con FreeBSD 6.0. Pues kerberos es un protocolo dise nado para acometer esta tarea. Cuando un usuario se valida contra un servidor kerberos (KDC) este le devuelve al mismo un ticket por un tiempo de vida espec co (lifetime). Entonces cada vez

20

DEL SOFTWARE A UTILIZAR CAP ITULO 5. SELECCION

que el usuario necesite utilizar alg un servicio (que est e Kerberizado) lo que viaja por la red no es la contrase na sino el ticket. La contrase na solo viaja por primera vez o cuando el ticket caduca. Ah! Y por supuesto, esas veces en que la contrase na viaja por la red lo hace de manera segura.

5.2.2.

Servicio de Directorio

Pues a esto ya le dedicamos una tem atica completa: OpenLDAP. Solo falta que resaltar que todos los servicios que se conguren en esta gu a ser an integrados con este servidor. En cuanto al tema de las contrase nas, las cr ticas se almacenar an en el servidor Kerberos y las normales como un hash irreversible (MD5) en la base de datos del Servidor OpenLDAP. Tambi en se explicar a como almacenarlas Text Plain en el directorio para que otros servicios ajenos a este puedan validar cuentas con formatos como CRAM-MD5.

5.2.3.

Servicio de Encaminamiento, Cortafuegos y Conversi on de Direcciones

La funci on de router, rewall y NAT la implementa el n ucleo (Kernel) del sistema operativo FreeBSD as que no hace falta software de terceros. Existen tres versiones que funcionan en diferentes capas del modelo OSI y tienen diferentes prestaciones. Personalmente recomiendo Packet Filter por dos razones fundamentales: Es el que utiliza OpenBSD, sistema operativo con una seguridad demostrada. Las funcionalidades NAT, Trac Shaping, Port Filtering, Port Redirecting e IP Filtering todas se efect uan a nivel de Kernel y son congurables desde el PF (Packet Filter), no siendo as , por ejemplo, en IPFW donde el NAT es una funcionalidad externa que se ejecuta como programa en la capa Userland.

5.2.4.

Integraci on con Redes Windows

El Compartir Impresoras y Archivos va a ser implementado con Samba 3 (http://www.samba.org/). Dentro de unos meses es posible (a partir de la fecha de escritura de este art culo) que aparezca Samba 4 con una implementaci on de Active Directory (Reemplazo a LDAP). Esta gu a est a dise nada exclusivamente para la versi on 3 debido a que todav a no se sabe con exactitud cuales van a ser las prestaciones y los cambios que van a integrar nalmente la versi on 4. FreeBSD 6.0 incluye en su n ucleo (Kernel) una implementaci on del protocolo SMB as que si el servidor no va a jugar el rol de controlador de dominios o servidor de archivos, no es necesaria la instalaci on de Samba.

5.2.5.

Servidor Web y Servidor de Administraci on v a Web

Creo que este punto no necesita debate: Apache 2 para servidor Web y Webmin para administraci on remota (y digo v a Web ya que la administraci on remota se har a con la implementaci on del servidor SSH que integra FreeBSD).

 DEL SOFTWARE DE APLICACION (SERVICIOS) 5.2. SELECCION

21

5.2.6.

Servicio MTA (Mail Transfer Agent)

En este punto podemos escoger entre una gran cantidad de aplicaciones. Los m as conocidos son Sendmail, Qmail, Postx y Exim. Cada uno de estos MTAs tiene caracter sticas u nicas que lo diferencia de los dem as. Sendmail es el m as antiguo y popular por lo que tradicionalmente se incluye en casi todos los sistemas operativos UNIX Like, y seg un los expertos su dise no est a obsoleto producto de que fue creado para ejecutarse en un entorno y en condiciones que actualmente han cambiado totalmente. Qmail es el segundo m as popular y tiene dos caracter sticas interesantes: su dise no modular y el soporte para clusters de correo; sin embargo carece de opciones de seguridad como por ejemplo: el ltrado/reescritura de direcciones. Exim, es un servidor con muchas prestaciones y caracter sticas modernas, sin embargo no cuenta con la madurez de Postx o Qmail. Postx ha sido dise nado para proveer seguridad, estabilidad, rendimiento y reemplazar a Sendmail. Mi selecci on es: Postx. Este servidor adem as de la gran cantidad de opciones para seguridad que incluye, tiene adem as much simas prestaciones interesantes como: un potente motor de reescritura (Rewriting Engine), m ultiples transportes de correo y soporte para m ultiples dominios y cuentas virtuales (Virtual Delivery Agent). Sin embargo carece del soporte para clusters de correo (caracter stica que implementa Qmail, espec camente Qmail-Ldap); elemento fundamental para nosotros en esta gu a. Entonces se preguntar an por qu e se escogi o Postx si carece de esta posibilidad. Pues en realidad puede hacerse un cl uster de correos con Postx con la misma calidad que se hace con Qmail (y hasta mejor), simplemente hay que hacer algunas conguraciones un poco rebuscadas. Personalmente no he encontrado ning un art culo en Internet que hable de Postx ligado a Clusters de correo y es por eso que digo que carece del soporte... sin embargo el Rewriting Engine y el VDA est an ah , herramientas poderos simas que nos permitir an implementar esta caracter stica.

5.2.7.

Servicio de Cuentas de Correo

Pues si, son cosas diferentes. El MTA es el que se encarga de distribuir los correos, y la manera de acceder a los buzones (POP3, IMAP) se implementa en otras aplicaciones. Hay muchos servidores que integran todo lo necesario para enviar y recibir correos en una sola aplicaci on y a lo mejor eso ha colaborado a mezclar los conceptos. Pues hay muchas aplicaciones que implementan los protocolos POP3 e IMAP, sin embargo hemos seleccionado Courier (Courier-IMAP y Courier-AUTH) simplemente por la integraci on a LDAP que implementa (incluye un Esquema que usaremos para denir las cuentas de los usuarios). Algunas personas aclaman que bajo grandes cargas Cyrus brinda mejor rendimiento que Courier, sin embargo Cyrus es m as complicado de congurar y no brinda tanta integraci on a LDAP como Courier. Resumiendo, usaremos Postx+Courier.

22

DEL SOFTWARE A UTILIZAR CAP ITULO 5. SELECCION

Cap tulo 6

Instalando el Sistema Operativo

Antes de empezar hay que hacer una aclaraci on muy importante. En Windows las l neas en un documento de texto se separan por CR+LF (Retorno + Nueva L nea). En UNIX solo por LF, por lo cual el car acter CR se considera parte del texto de la l nea. Esto trae muchos problemas debido a que los cheros de conguraci on pueden interpretar el CR como un car acter m as y pueden tener como elementos diferentes a nombre y nombre\r sin embargo esto no es lo que necesitamos. Por tanto es recomendable instalar dos programitas: dosunix y unix2dos que se encargan de convertir cheros de texto creados en Windows (Notepad) a UNIX y viceversa. Para ello podemos en nuestro shell introducir los siguientes comandos: #portinstall dosunix #portinstall unix2dos El comando portinstall se explicar a posteriormente en este documento.

6.1.

Instalando FreeBSD

Para una correcta instalaci on de FreeBSD, es recomendable leer el Manual de Usuario FreeBSD Handbook antes de comenzar. Este se puede obtener desde http://www.freebsd.org/. En el, existe un cap tulo que explica paso a paso y de una manera muy asequible (en espa nol) todo lo que usted necesita saber. En este punto solo daremos una gu a r apida de como proceder para instalar/congurar el sistema operativo con las caracter sticas b asicas necesarias. Note que no haremos ninguna conguraci on avanzada, por lo cual es necesario que lea el manual de usuario y personalice el sistema para satisfacer sus necesidades. Ahora mostraremos los pasos a seguir para instalar FreeBSD. Inicie con el CD1 de FreeBSD insertado en el lector y cuando aparezca el men u de instalaci on (gura 6.1), seleccione la opci on Custom. Al seleccionar la opci on Custom aparecer a la pantalla que muestra la gura 6.2. Note que todos los pasos est an numerados y se deben seguir en ese orden. Seleccione el administrador de particiones (3) y una vez all presione A para usar el HDD completo y luego presione Q para nalizar. Seleccione BootMgr para instalar el administrador de particiones de FreeBSD. Seleccione la opci on (4) Label, y una vez m as A y luego Q. Esto congurar a el disco de manera predeterminada. 23

24

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

Figura 6.1: Men u de Instalaci on/Conguraci on de FreeBSD - sysinstall

Figura 6.2: Opciones de Instalaci on Para seleccionar la distribuci on que desea instalar seleccione la opci on (5) Distributions. Luego pasar a a la pantalla que muestra la gura 6.3. De todas las variantes, dir jase a la u ltima B Custom para personalizar lo que queremos instalar y no gastar HDD innecesariamente. Estas son las opciones necesarias: base. Los programas del sistema operativo. man. La ayuda. doc. (Opcional) Handbook de FreeBSD. src. Es el c odigo fuente de todo el Sistema Operativo. Es muy necesario para mantener el sistema actualizado usando la v a de sincronizaci on de c odigo con los servidores CVS de FreeBSD. ports. Es el arbol CVS que contiene todo el software de terceros que funciona sobre FreeBSD. Es necesario para mantener actualizado todos los programas del servidor (Apache, Squid, Postx, etc).

6.1. INSTALANDO FREEBSD

25

Figura 6.3: Listado de Elementos a Instalar X.org. (Opcional) En un servidor productivo, realmente no es necesario tener una interfase gr aca, pero si es primera vez que trabaja con FreeBSD y est a instalando sobre un servidor de pruebas, puede ser de gran utilidad. No obstante le advierto, los administradores de escritorio como Gnome utilizan gran cantidad de librer as dependientes que luego pueden traer conictos de versiones con otras librer as necesarias para algunos servidores. Este tipo de error es casi improbable, pero suele suceder en algunos casos. Vuelva al men u principal (El que tiene los pasos de instalaci on numerados) seleccionando Exit y una vez all , seleccione la opci on (6) Media. Asumiendo que est a instalando desde CD, seleccione la primera opci on que aparece. Seleccione la opci on (7) Commit para comenzar con la instalaci on. Ahora la instalaci on se encargar a de crear la estructura de directorios, copiar los programas y activar las opciones predeterminadas. Esta operaci on va a tardas algunos minutos en dependencia del Hardware. Despu es que termine este proceso, la instalaci on preguntar a si desea retornar al men u inicial y diremos que s para poder personalizar el sistema: Nombre, IP, etc (gura 6.4).

Figura 6.4: Men u de Conguraci on

26

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

Seleccione Root Password para congurar una contrase na de administraci on. Si desea a nadir otro usuario, puede hacerlo a trav es de la opci on User Management. Seleccione la opci on Networking para comenzar a congurar la Red. Seleccione Interfaces. Ver a un listado de todas las interfaces de Red ( Figura 6.5). Deber an aparecer dos adaptadores de red mas los puertos COM (Que son tambi en interfaces de red). Los nombres de los adaptadores van a cambiar en dependencia del tipo de tarjeta. En esta gu a los llamaremos lnc0 y lnc1 (Usando dos tarjetas de Red Lance/PCNet). Sin perder generalidad diremos que lnc0 estar a conectado f sicamente a la Red Privada y lnc1 a Internet. Seleccione el primer adaptador. D gale no a usar IPv6 debido a que estamos trabajando con IPv4 (Lo mismo cuando pregunte si usa DHCP ya que los IP los asignaremos de manera est atica). Estas son las opciones a congurar (Figura 6.6 y/o Cuadro 6.1):

Figura 6.5: Interfaces de Red

Figura 6.6: Interface de Red lnc0 Presione OK, y el sistema preguntar a si desea activar el dispositivo. Despu es de aceptar, volver a a la pantalla con las interfaces de red. Seleccione la segunda (lnc1) e introduzca la siguiente informaci on: IPv4 Address: 10.0.0.1

6.1. INSTALANDO FREEBSD Campo Host Domain IPv4 Gateway Name Server IPv4 Address Netmask Valor server1 bsdland.com [IP Router] [IP Name Server] 192.168.0.1 255.255.255.0 Descripci on Es el nombre del servidor Dominio IP del Router hacia Internet Servidor DNS. IP de la Interface lnc0 Mascara de Red

27

Cuadro 6.1: Conguraci on de la Interface lnc0 Netmask: 255.0.0.0 Presione OK, y vuelva al men u conguraci on de red (Figura 6.7) . Ahora ya tenemos congurados los dos adaptadores de red (Publico y Privado). Seleccione sshd para activar un servidor seguro (SSH) necesario para administraci on remo-

Figura 6.7: Servicios de Red ta. Note que tambi en puede desde aqu activar un servidor FTP an onimo, Mail, entre otras opciones, pero esto no lo haremos debido a que es mejor personalizar (para FTP, SMTP, etc.) el software a instalar y no usar el que FreeBSD trae de manera predeterminada. Ahora salga hacia el men u de conguraci on principal. Seleccione la opci on Startup. Luego Seleccione named (Figura 6.8) para activar/crear nuestro propio servidor DNS. Seleccione tambi en las opciones Accounting para llevar las estad sticas de los procesos y Linux si desea activar compatibilidad binaria con Linux (Opcional). Salga al men u de conguraci on principal. Salga hacia el men u inicial y presione Exit Install para terminar la instalaci on. Quite el CD/DVD de su lector. Ya tiene una versi on de FreeBSD 6.0 instalada. Ahora el sistema iniciar a por primera vez. FreeBSD es un UNIX Like Operating System as que existen much simas diferencias comparado con Windows (No existen los servicios, no hay registro de sistema, etc.). Es muy importante que lea el cap tulo Unix Basics del Handbook de FreeBSD incluso si ha trabajado con Linux alguna vez debido a que muchas cosas cambian, como por ejemplo la organizaci on de los directorios y la manera en que se aplican los permisos.

28

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

Figura 6.8: Conguraci on de Inicio Lo primero que har a FreeBSD al iniciar es generar una clave RSA para codicar todas las comunicaciones seguras (SSH) que se efect uen posteriormente. Para ello, nos pedir a que rellenemos la pantalla de basura (caracteres sin sentido) o que presionemos ENTER para que autom aticamente sean generados y as poder obtener un certicado digital para uso local. Solo queda decir: Bienvenidos a FreeBSD!

6.2.

Conguraci on Inicial

Todos los pasos que efectuamos en la secci on 6 lo que realmente hicieron fue modicar los cheros de conguraciones del Sistema Operativo y especialmente uno llamado rc.conf (se encuentra en /etc) que puede decirse que es el archivo de conguraci on principal de FreeBSD ya que es ah donde se agregan las opciones de inicio as como la carga de los servicios/aplicaciones que se desean ejecutar cuando el sistema levante. Valid emonos como root y visualicemos el chero /etc/rc.conf. Para ello ejecutemos la siguiente l nea de comandos: #ee /etc/rc.conf El Programa Easy Edit ee es el editor de textos predeterminado en FreeBSD. Aquellos que vienen de Linux tambi en pueden usar vi. A continuaci on se visualizar a el chero rc.conf: accounting_enable="YES" hostname="server1.bsdland.com" ifconfig_lnc0="inet 192.168.0.1 netmask 255.255.255.0" ifconfig_lnc1="inet 10.0.0.1 netmask 255.255.255.0" moused_enable="YES" moused_type="auto" named_enable="YES" sshd_enable="YES" Como puede observar, ah se encuentra toda la conguraci on que efectuamos con el asistente de instalaci on. A partir de ahora cada vez que queramos cambiar algo de sistema,

6.3. SERVICIOS EN FREEBSD

29

simplemente accedemos a este chero y hacemos las modicaciones directamente. Si desea utilizar el asistente de instalaci on puede acceder al mismo con la siguiente l nea: #sysinstall

6.3.

Servicios en FreeBSD

En Windows, los programas se clasican en: aplicaciones que son aquellas que el usuario ve y servicios que son programas administrados por el sistema operativo. Los servicios tienen una estructura diferente a las aplicaciones y se registran utilizando APIs (Funciones del Sistema) de Windows. En FreeBSD todos los programas son iguales: aplicaciones de consola (aunque utilicen alguna interfase gr aca). Las aplicaciones de consola tienen una entrada de datos (Standard Input STDIN) y dos salidas (Standard Output STDOUT y Standard Error STDERR). Usualmente el STDIN es el teclado, el STDOUT es la pantalla y el STDERR es el registro de errores (chero Log). Estas entrada y salidas pueden redireccionarse a gusto e inclusive interconectarse entre aplicaciones (v ease pipes en el Handbook). Un servicio en FreeBSD, no es m as que una aplicaci on de consola, que el sistema ejecuta, asociado a una cuenta de usuario, mediante un script (c odigo texto ejecutable sobre BSD Shell) de inicio previamente congurado. Los scripts de inicio se almacenan en /etc/rc.d/ o /usr/local/etc/rc.d/ y la carga autom atica se controla desde /etc/rc.conf. Entonces, como crear un servicio? Supongamos que tenemos una aplicaci on de consola en /usr/local/sbin/utilidad que queremos ejecutar como servicio. Los pasos a seguir son los siguientes: 1. Crear un chero ejecutable con nombre utilidad.sh, almacenarlo en /usr/local/etc/rc.d/ y comenzar a editarlo. #cd /usr/local/etc/rc.d/ #cp /dev/null utilidad.sh #chmod 755 utilidad.sh #ee utilidad.sh #ee /etc/rc.conf El chero utilidad.sh debe quedar como la siguiente plantilla: #!/bin/sh # PROVIDE: utilidad # REQUIRE: DAEMON # KEYWORD: shutdown # # DO NOT CHANGE THESE DEFAULT VALUES HERE # SET THEM IN THE /etc/rc.conf FILE #

30

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

utilidad_enable=${utilidad_enable-"NO"} utilidad_flags=${utilidad_flags-""} . /etc/rc.subr name="utilidad" rcvar=set_rcvar command="/usr/local/sbin/${name}" pidfile="/var/run/${name}.pid" start_cmd="echo \"Starting ${name}.\"; /usr/bin/nice -5 ${command} ${utilidad_flags}" load_rc_config $name run_rc_command "$1" 2. Agregar la siguiente l nea a /etc/rc.conf utilidad_enable="YES" 3. Para cargar el servicio: #/usr/local/etc/rc.d/utility.sh start 4. Para pararlo: #/usr/local/etc/rc.d/utility.sh stop Cuando el sistema inicie la pr oxima vez el servicio cargar a autom aticamente. El orden de ejecuci on de los servicios depende del orden alfab etico de la carpeta /usr/local/etc/rc.d as que si desea ejecutar alguno primero que otro cambie los nombres o a nada como prejo un orden de ejecuci on (Ejemplo: 001.servicio1.sh, 002.servicio2.sh) Se ha explicado como crear un servicio simplemente para que usted tenga una idea de como funcionan los mismos. Sin embargo, cuando instalemos una aplicaci on como Apache, Squid u otras, FreeBSD crear a el script de inicio autom aticamente.

6.4.

Congurando el Kernel

En FreeBSD, como en muchos Unix-Like Operating Systems, el N ucleo del Sistema es congurable y en dependencia de las opciones que se agreguen o desactiven el rendimiento general aumentar a o disminuir a considerablemente. Dado el dise no modular del Kernel, es posible en tiempo real cambiar algunas opciones de rendimiento (Tunning Options) as como cargar algunos drivers sin necesidad de recompilar todo el c odigo fuente o reiniciar el Sistema Operativo. Sin embargo, hay cosas que solo pueden hacerse de manera est atica (Recompilando) y a veces es mejor hacerlo as . Por ejemplo, el

6.4. CONFIGURANDO EL KERNEL

31

soporte SMP (Symmetric Multiprocessing) para poder manejar m ultiples procesadores o el soporte para grandes bloques de memoria RAM (>4GB) solo es posible activarlo recompilando el Kernel. Y esto tiene su explicaci on: si usas una Arquitectura de 32 Bits y a lo sumo 4GB de Memoria RAM, el puntero de direccionamiento de memoria virtual es de 4 Bytes (32 Bits), sin embargo en otro caso este puntero puede ser de 8 Bytes (64 Bits) permitiendo as el manejo de gran cantidad de memoria. Ahora, ser a un desperdicio de espacio compilar ese puntero a 64 Bits (aunque es posible) si solo vas a manejar a lo sumo 4GB RAM. Los Sistemas Operativos de c odigo cerrado lo que hacen para resolver este problema es proveer varias versiones precompiladas del Kernel y cargarlas din amicamente en dependencia de las necesidades. Pues no divaguemos m as y veamos como se congura el N ucleo del Sistema y no se asuste que no tendr a que programar nada. En el camino /usr/src es donde FreeBSD almacena el c odigo fuente de todo el sistema, tanto el Kernel como las aplicaciones del Sistema Operativo y esto es a lo que se le llama The World. Dentro de El Mundo se encuentra The Kernel ubicado en /usr/src/sys/i386/ donde i386, es la arquitectura correspondiente a Intel x86. Dentro de este camino se encuentra una carpeta llamada conf (/usr/src/sys/i386/conf/) donde aparecen distintas variantes de cheros de conguraci on del Nucleo: GENERIC - Conguraci on B asica SMP1 - Conguraci on para Multiprocesamiento Lo primero que ud. debe de hacer es crear su propio chero de conguraci on o bien hacer una copia de los bases que aparecen y comenzar a editar sus opciones: #cd /usr/src/sys/i386/conf #cp SMP BSDLAND #ee BSDLAND Ahora veamos la conguraci on del Kernel (Sin optimizaciones avanzadas) que vamos a utilizar: # Kernel Personalizado: BSDLAND # Incluye la configuraci on Gen erica include GENERIC # Nombre/Identificacdor del Kernel ident CINET-SMP # Optimizaciones para GCC makeoptions COPTFLAGS="-O2 -pipe -funroll-loops -ffast-math" # Activar SMP options

SMP

# Symmetric MultiProcessor Kernel

1 La conguraci on SMP incluye a GENERIC y solo agrega la compatibilidad para multiprocesamiento, nada m as.

32

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

# Activando el Firewall de OpenBSD (Packet Filter) device pf device pflog # Interfase deestad sticas device pfsync # Interfase para sincronizaci on options ALTQ # Soporte ALTQ - Calidad de Paquetes & Traffic Shaping options ALTQ_CBQ # Class Base Queueing options ALTQ_RED # Random Early Drop options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierachical Packet Scheduler options ALTQ_CDNR # Traffic Conditioner options ALTQ_PRIQ # Priority Queueing # Algunas Opciones de Rendimiento options SYSVMSG options MSGMNB=8192 # options MSGMNI=40 # options MSGSEG=2048 # options MSGSSZ=64 # options MSGTQL=2048 # options SYSVMSG options SYSVSEM options SHMMAXPGS=262144 options SHMSEG=512 options SHMMNI=512 options SEMMNI=512 options SEMMNS=1024 options SEMMNU=512 options SEMMAP=512 # Activar options options options device (Ver Handbook de FreeBSD) max # of bytes in a queue number of message queue identifiers number of message segments per queue size of a message segment max messages in system

tunel IP & IPSec IPSEC #IP security IPSEC_ESP #IP security (crypto; define w/ IPSEC) IPSEC_FILTERGIF gif

Para compilar el kernel, podemos ir por dos v as, la antigua y la moderna. La antigua ser a: #cd /usr/src/sys/i386/conf #/usr/sbin/config BSDLAND #cd ../.. #make cleandepend && make depend && make && make install Y por la nueva v a ser a: #cd /usr/src #make buildkernel KERNCONF=BSDLAND #make installkernel KERNCONF=BSDLAND

6.5. ACTIVANDO ACLS EN FREEBSD

33

Si todo sale bien, entonces al reiniciar el servidor, tendr a la nueva versi on del Kernel. Note que este nuevo n ucleo puede no cargar, pero no se preocupe, ud. siempre puede cargar la versi on anterior del Kernel o la versi on gen erica, seleccion andola en el men u de inicio (Boot).

6.5.

Activando ACLs en FreeBSD

Los permisos en UNIX fueron dise nados con otras condiciones y necesidades diferentes a las actuales y realmente resuelven una gran cantidad de problemas, sin embargo, que pasa si un objeto del sistema de archivos se desea compartir por m ultiples usuarios y/o grupos? Esto no tiene soluci on. Es por eso que nacen las ACL (Access Control Lists). La mayor a de los sistemas operativos comerciales como Windows y Solaris incluyen en sus sistemas de archivos ACL. Entonces, por que no incluirlas en FreeBSD? Inicialmente los esc epticos y los conservadores dir an que no hay necesidad de modicar el sistema de permisos en UNIX, sin embargo, es una necesidad y una obligaci on si se desea interactuar con otros sistemas operativos. Por ejemplo, utilizando Samba (Windows Domain Controller) se pueden compartir carpetas, y si se desea cambiar los permisos de acceso a la carpeta dando clic derecho sobre la misma desde Windows, es necesario que el sistema de archivos en el servidor soporte ACL (Para compatibilizar con NTFS). Inclusive si se copia desde Windows (NTFS) una estructura de directorio hacia una carpeta de red (Hospedada con FreeBSD) se pueden mantener los permisos por cada objeto. Y que no le quede duda a nadie, no se sustituyen las mascaras de UNIX por ACL sino que las ACL son una capa sobre UFS2 (En FreeBSD 5/6). Esto signica que se pueden utilizar indistintamente los dos sistemas. Entonces activemos las ACL en FreeBSD (Desactivadas con la conguraci on predeterminada). Las ACL pertenecen al Sistema de Archivos y requieren obligatoriamente soporte para atributos extendidos (UFS2). Debemos reiniciar en Single User Mode para poder acceder directamente al sistema de archivos y modicarle las propiedades. Para ello: #shutdown -r now Cuando est e iniciando FreeBSD seleccione Boot FreeBSD in Single User Mode. Una vez en este modo: #/sbin/tunefs -a enable /dev/da0s1f Donde /dev/da0s1f es la partici on donde est a /usr. Esto puede cambiar en dependencia de los tipos de discos duros que ud tenga, por lo que recomiendo que verique el chero /etc/fstab donde est an todos los mount points y los discos. Una vez activadas las ACL veamos algunos comandos para trabajar con ellas desde FreeBSD. Primero, supongamos que estamos validados como alex:wheel (UID 0, GID 0). #cd ~ #cp /dev/null acl-test Esto crea un chero llamado acl-test en nuesto Home Directory. #setfacl -b acl-test Esta opci on inicializa las ACL (solo incluye las reglas equivalentes a la mascara de UNIX)

34

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

# ls -l acl-test -rw-r--r--+ 1 alex

wheel

0 Dec 19 17:27 acl-test

Adem as de los permisos est andares de UNIX, aparecer a un + que signica que ese chero tiene permisos denidos v a ACL. Para ver esos permisos: # getfacl acl-test # file:acl-test # owner:500 # group:0 user::rwgroup::r-other::r-(La primera l nea es el comando, las restantes # son comentarios que emite el utilitario getfacl) Note que es equivalente estas ACL con la mascara/permisos de UNIX. Ahora, sin cambiar estos permisos, permitamos que los miembros del grupo Domain Users puedan leer este chero: # setfacl -m group:Domain Admins:r-- acl-test Veamos que se mantienen intocables los permisos de UNIX y que de manera adicional es que se agrega el nuevo permiso. #ls -l acl-test -rw-r--r--+ 1 alex wheel #getfacl act-test # file:acl-test # owner:500 # group:0 user::rwgroup::r-group:Domain Admins:rmask::r-other::r-0 Dec 19 17:30 acl-test

Hemos estado trabajando con un chero. Con directorios las ACL se comportan de igual manera, pero hay algo nuevo: herencia. Cada vez que se cree un chero dentro de una carpeta con ACL activadas hay ocasiones en que se desea que se hereden las ACL. Las ACL no se heredan de manera predeterminada, hay que forzar la herencia con la opci on -d (Default) en el utilitario setfacl. Para poder especicar una ACL heredable hay que tambi en especicar la mascara de UNIX, sino la utilidad lanza un error (Tiene sentido, ya que a cada chero nuevo hay que obligatoriamente especicarle una nueva mascara UNIX). Ejemplo: # setfacl -d -m user::rw-,group::r--,other::r--,u:alex:rwx carpeta Para eliminar las ACL predeterminadas se utiliza la opci on -k. Veamos ahora un ejemplo de interoperaci on con Microsoft Windows Vista (NT 6.0). Supongamos que compartimos una carpeta llamada netlogon (Luego cuando conguremos Samba

6.5. ACTIVANDO ACLS EN FREEBSD

35

veremos como compartir carpetas) donde almacenaremos nuestro chero act-test con las ACL del ejemplo anterior activadas.

Figura 6.9: Listado de las ACL de la carpeta netlogon desde Windows Vista

En la Figura 6.9 se ven todas las ACL que hemos denido. Everyone en Windows es other en UNIX. Alex y Wheel es el user:group propietario de los permisos del chero y Domain Users es el grupo con la ultima ACL que se agreg o en el ejemplo anterior. Ahora, probemos modicar estas ACL desde Windows. Vamos a poner a Domain Users como Lectura, aceptemos los cambios y veamos si se modicaron los permisos en nuestro sistema de archivos en FreeBSD: #getfacl act-test # file:acl-test

36

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

# owner:500 # group:0 user::rwgroup::r-group:Domain Admins:rwmask::r-other::r-Wow! Como hab amos pensando! Las ACL se modicaron. Esto demuestra lo poderosa que son las ACL y la necesidad de estas para interactuar con otros sistemas operativos como Windows.

6.6.

Congurando el Firewall

Existen varios tipos de cortafuegos: Stateless y Statefull (Nombre en ingl es). Los rewalls Stateless ignoran el estado de las conexiones y se limitan a ltrar (permitir/denegar) los paquetes en dependencia de un grupo de reglas estaticamente denidas. Los rewalls Statefull, mantienen un conjunto de reglas din amicas adem as del grupo est atico as como un estado en memoria de todas las conexiones que pasan a trav es (o para) el servidor. Las reglas din amicas garantizan el ujo din amico de informaci on y esta es una caracter stica importante para las puertas (Gateways). Como las comunicaciones TCP/UDP se efect uan desde un IP:Puerto hasta otro IP:Puerto cada vez que se efect ua desde una PC interna un pedido HTTP a un servidor externo, el puerto de la PC interna se selecciona aleatoriamente (generalmente un n umero alto: 32343 o 15674) y esto es un problema para los Firewalls Stateless, ya que no pueden saber el traco entrante (Respuesta del Servidor HTTP) hacia donde va ni a que sesi on TCP pertenece, trayendo as problemas de exibilidad a la hora de crear reglas de este estilo. Un rewall Statefull al inicializar la conexi on crear a una regla din amica inversa para la sesi on TCP espec ca, permitiendo as que las respuestas (Paquetes entrantes) lleguen a su destino y que cualquier otra comunicaci on que no coincida con la sesi on sea descartada (Si no coincide con otra regla). Packet Filter es un Firewall Statefull. Estas son las caracter sticas fundamentales de Packet Filter: Stateful packet ltering Mantiene el estado de las comunicaciones. Network Address Translation (NAT) Permite mediante traducci on de direcciones que grupos de IP privados puedan acceder a redes p ublicas (IP Relaes). Port Forwarding Permite publicar servidores internos o en el DMZ hacia redes externas. Passive Operating System Fingerprinting El rewall puede detectar el sistema operativo de los clientes en dependencia de las marcas de los paquetes IP. Packet Queueing and Quality of Service Implementa diversos algoritmos para la administraci on del ancho de banda y la priorizaci on del tr aco por regla.

6.6. CONFIGURANDO EL FIREWALL

37

Load Balancing & Firewall Puede congurarse el rewall para que se sincronice con otro rewall que tenga instalado Packet Filter y as balancear la carga y tener una alta disponibilidad de los servicios (Failover).

Veamos ahora como congurar Packet Filter. La Figura 6.10 muestra un dise no conocido como 3-Leg Firewall ya que el Gateway est a conectado a la LAN, a la red desmilitarizada (DMZ) y a Internet. Sin embargo, existen dos rewalls: fw1.bsdland.com y fw2.bsdland.com haciendo de Gateway. El objetivo de esta dualidad es sincronizarlos, balancear la carga y si por alguna raz on uno de ellos falla, pues el otro asuma todo el tr aco y el cliente nal no note ning un cambio o problema.

Figura 6.10: Diagrama de un Firewall Cluster

6.6.1.

Reglas de Acceso

Veamos primero la conguraci on de las reglas del rewall, que deben ser id enticas en ambos servidores exceptuando que los IP var an en cada caso. Por ejemplo, nuestra LAN es 192.168.0.0/24. El IP f sico de fw1.bsdland.com ser a 192.168.0.2 y el de fw2.bsdland.com 192.168.0.3. El IP 192.168.0.1 ser a el virtual utilizado para el balance de carga. Esto signica que ambos servidores (fw1 y fw2) van a recibir los pedidos de conexi on en 192.168.0.1 y se van a poner de acuerdo sobre quien responde y quien no. El Load Balancing se efectuar a utilizando C.A.R.P (Common Address Redundancy Protocol). La

38

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

conguraci on del Packet Filter la encontramos en /etc/pf.conf (En caso de no aparecer cr eela y utilice la plantilla que a continuaci on aparece): ################################## # BSDLAND FW1 - OpenBSD Firewall # ################################## ########## # Macros # ########## ext_if="lnc0" dmz_if="lnc1" lan_if="lnc2"

# INTERNET # DMZ # LAN

# Redes lan_net="192.168.0.0/24" dmz_net="192.168.5.0/24" ext_net="10.0.0.0/8" # Algunas macros u tiles table <firewall> const { self } table <all_net> {$lan_net,$dmz_net} table <internal_net> {$lan_net,$dmz_net} # Opciones generales (Tunning) de Packet Filter set timeout { interval 10, frag 30 } set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 } set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 } set timeout { udp.first 60, udp.single 30, udp.multiple 60 } set timeout { icmp.first 20, icmp.error 10 } set timeout { other.first 60, other.single 30, other.multiple 60 } set timeout { adaptive.start 0, adaptive.end 0 } set limit { states 10000, frags 5000 } set loginterface none set optimization normal set block-policy drop set require-order yes set fingerprints "/etc/pf.os" # Normalizaci on: reensambla fragmentos y resuelve o reduce # ambig uedades en el tr afico scrub in on $ext_if # Colas: Control de Ancho de banda para enlace externo (128Kb) # y priorizaci on del trafico. altq on $ext_if bandwidth 128Kb priq queue { normal, medium, high, critical }

6.6. CONFIGURANDO EL FIREWALL

39

queue queue queue queue

normal priority 1 priq(default) medium priority 3 high priority 5 critical priority 7

################# # NAT # ################# # Se efect ua NAT desde las redes internas hacia Internet # Hay que permitir todav a quien sale y quien no nat on $ext_if from $dmz_if:network to any -> ($ext_if) nat on $ext_if from $lan_if:network to any -> ($ext_if) # Estas son reglas para la publicaci on de servidores # internos. Hay que definir las variables $web_server1 etc # en dependencia de las necesidades. # HTTP - Server Mapping # rdr on $ext_if proto tcp from any to any port 80 -> $web_server1 port 80 # rdr on $ext_if proto tcp from any to any port 443 -> $web_server1 port 443 # SMTP - Server Mapping # rdr on $ext_if inet proto tcp from any to any port 25 -> $smtp_server1 port 25 # POP - Server Mapping # rdr on $ext_if proto tcp from any to any port 110 -> $pop_server1 port 110 # IMAP - Server Mapping # rdr on $ext_if proto tcp from any to any port 143 -> $imap_server1 port 143 # Transparent Proxying - Filtrar la navegaci on con Squid Proxy Server # escuchando en el puerto 8080 # rdr on {$ppp_if,$cedi_if} inet proto tcp from any to any port www -> 127.0.0.1 port 8080 ################## # DEFAULT POLICY # ################## # De manera predeterminada se bloquea todo el tr afico. block all # Loopback Access - Se permite acceder a 127.0.0.1 pass quick on lo0 all ########################## # Server Port Publishing # ##########################

40

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

# Si el servidor Firewall adem as incluye alg un servicio hay que # permitirlo. Esta opci on es exclusiva: O se publica el puerto (rdr forward) # o se instala un servidor local y se permite el acceso. # Note que el tr afico se prioriza: SSH tiene la mayor prioridad. # DNS Server pass proto {tcp,udp} from any to <firewall> port 53 keep state queue high # SMTP Server pass proto {tcp} from any to <firewall> port 25 keep state queue medium # HTTP Server pass proto {tcp} from any to <firewall> port 80 keep state queue normal # POP3 Server pass proto {tcp} from any to <firewall> port 110 keep state queue normal # IMAP Server pass proto {tcp} from any to <firewall> port 143 keep state queue normal # SSH Server pass proto {tcp,udp} from any to <firewall> port 22 keep state queue critical # DHCP Server (INTERNAL) pass on $lan_if proto {udp} from any to any port 67 pass on $dmz_if proto {udp} from any to any port 67 # Squid Proxy Server (INTERNAL) pass on $lan_if proto {tcp} from any to <firewall> port 8080 keep state pass on $dmz_if proto {tcp} from any to <firewall> port 8080 keep state # Samba Server (INTERNAL) pass proto {tcp} from <internal_net> pass proto {tcp} from <internal_net> pass proto {tcp} from <internal_net> pass proto {udp} from <internal_net> pass proto {udp} from <internal_net>

to to to to to

<firewall> <firewall> <firewall> <firewall> <firewall>

port port port port port

135 139 445 137 138

keep keep keep keep keep

state state state state state

# LDAP Server (DMZ) pass proto {tcp} from $dmz_net to <firewall> port 389 keep state # PostgreSQL Server (DMZ) pass proto {tcp} from $dmz_net to <firewall> port 5432 keep state # Jabber Server pass proto {tcp} from any to <firewall> port 5222 keep state

6.6. CONFIGURANDO EL FIREWALL

41

pass pass pass pass

proto proto proto proto

{tcp} {tcp} {tcp} {tcp}

from from from from

any any any any

to to to to

<firewall> <firewall> <firewall> <firewall>

port port port port

5223 5269 5280 8888

keep keep keep keep

state state state state

########################## # Firewall Access Rules # ########################## # Permitir Firewall SSH -> Anywhere pass proto {tcp} from <firewall> to any port ssh keep state queue critical # Permitir Firewall -> Anywhere pass from <firewall> to any keep state # Permitir DMZ -> Internet pass from $dmz_net to $ext_net keep state # Tunel IP: NODO1 <-> NODO2 pass on gif0 from any to any keep state # CARP pass quick on { $dmz_if } proto pfsync keep state (no-sync) pass on { $dmz_if $lan_if } proto carp keep state Podemos ver que en el chero de conguraci on aparecen los siguientes grupos: Denici on de las interfaces y direcciones IP que intervienen en el NAT. Conguraciones generales del Packet Filter Control de Ancho de Banda y Priorizaci on de Tr aco. NAT Publicaci on de Servidores Internos (Port Forwarding) Permisos para tr aco entrante Reglas de Acceso Ahora, en dependencia de su conguraci on ud. deber a comentariar y/o modicar esta plantilla respetando el orden y la agrupaci on, debido a que de otra manera puede no funcionar correctamente el Firewall. Para activar el Firewall agregue las siguientes l neas al chero /etc/rc.conf pf_enable="YES" pflog_enable="YES"

42

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

6.6.2.

Sincronizando los Firewalls: CARP

Primero hay que crear una lista de interfaces virtuales: carp1 y carp2. Note que vamos a congurar Balance de Carga para la red LAN y para la DMZ. Para crear las interfaces virtuales, abra el archivo /etc/rc.conf y agregue las siguientes l neas: # Clonando Interfaces... cloned_interfaces="carp1 carp2" # CARP LAN ifconfig_carp1="vhid 1 advskew 50 pass clave1 192.168.0.1" # CARP DMZ ifconfig_carp2="vhid 2 advskew 50 pass clave2 192.168.5.1" # PFSYNC ifconfig_pfsync0="syncdev lnc1" La u ltima l nea le dice a la interfase de sincronizaci on del Packet Filter sobre que interfase de Red va a enviar el tr aco de sincronizaci on. Para ello utilizaremos la red DMZ. La sintaxis del comando ifcong para congurar las interfaces virtuales es el siguiente:

ifconfig_carpXX="vhid <carp-interface-id> advskew <priority> pass <password> <carp-ip-address> <carp-interface-id>: Es un n umero que identica la interface. Tiene que ser el mismo en todos los rewalls. <priority>: Prioridad. Si el numero es el mismo para todos los rewalls en el cluster, el tr aco se balancea. Si var a se dene el menor n umero como MASTER y el mayor como SLAVE y solo el maestro maneja el tr aco. El SLAVE entra en funci on si el maestro falla. <password>: contrase na para codicar el tr aco entre rewalls a la hora de sincronizar el estado. <carp-ip-address>: ip virtual utilizado para el balance de carga. Para congurar el Failover autom atico en caso de que no deseemos tener un Cluster Active-Active debemos agregar al chero /etc/sysctl.conf la l nea: net.inet.carp.preempt=1 Esto le dice al Kernel de FreeBSD que sincronice las interfaces CARP y que si el servidor maestro falla, el tr aco se redireccione al rewall backup. Tenga en cuenta que los nodos tienen que poder comunicarse v a protocolo pfsync, por lo cual cada Firewall debe tener las reglas necesarias para permitir esta comunicaci on. Se recomienda agregar una tarjeta de red adicional a cada servidor y utilizar un cable cruzado para la sincronizaci on (Puto adicional para el Failover) y por supuesto, permitir los paquetes entre los rewalls mediante esta interfase.

 6.7. CONFIGURANDO TUNELES IP

43

6.7.

Congurando T uneles IP

Cuando conguramos el Kernel de FreeBSD incluimos un dispositivo llamado gif. Esta no es m as que una interfase virtual que empaqueta los paquetes para poder encaminarlos sobre otras interfases. Retomemos el dise no inicial: Dos nodos geogracamente separados con redes privadas 192.168.0.0/24 y 192.168.1.0/24 y conectados mediante las redes publicas 10.0.0.0/24 y 10.0.2.0/24 (Ver Cuadros 3.1 y 3.2). Para unir estos nodos basta con a nadir la siguiente conguraci on al chero rc.conf en cada nodo. Nodo A # IP Tunnel NODOA->NODOB gif_interfaces="gif0" gifconfig_gif0="10.0.0.1 10.0.2.1" ifconfig_gif0="inet 192.168.0.1 192.168.1.1 netmask 255.255.255.255" route_nodob="192.168.1.0 192.168.1.1 -netmask 0xffffff00" static_routes="nodob" Nodo B # IP Tunnel NODOB->NODOA gif_interfaces="gif0" gifconfig_gif0="10.0.2.1 10.0.0.1" ifconfig_gif0="inet 192.168.1.1 192.168.0.1 netmask 255.255.255.255" route_nodoa="192.168.0.0 192.168.0.1 -netmask 0xffffff00" static_routes="nodoa" ublicos (desde Note que la conguraci on de la interfase base (gifcong gif0) dene los IPs p hasta) que van a encaminar los paquetes y la conguraci on de la interfase virtual (ifcong gif0) dene los IP privados que van a utilizarse para encaminar virtualmente los paquetes, siguiendo tambi en el patr on desde hasta. Entonces existen dos grupos de routers: los f sicos que se encargan de encapsular y transportar los paquetes y los virtuales, utilizados por la Red privada para comunicarse con la red privada del otro nodo. Esto garantiza la separaci on del tr aco creando as un T unel virtual entre los nodos. Una vez creado el T unel entonces puede codicarse s olo ese tr aco utilizando IPSec. Por razones Legales no se incluir a la conguraci on de IPSec para los t uneles IP en este documento. Rem tase al Handbook de FreeBSD y encontrar a una gu a muy completa sobre este tema.

44

CAP ITULO 6. INSTALANDO EL SISTEMA OPERATIVO

Cap tulo 7

Instalaci on y Conguraci on de Servicios

7.1. Administraci on del Software

En esta secci on veremos como instalar y mantener actualizado los paquetes (aplicaciones) que se instalen en FreeBSD.

7.1.1.

Administrador de Paquetes Binarios

Veamos primero como trabajar con paquetes binarios: listar, agregar nuevos y eliminar existentes. Para ver los paquetes instalados en el sistema as como su versi on y descripci on simplemente escribimos: #pkg_info Si deseamos agregar un nuevo paquete (baj andolo autom aticamente desde Internet) de manera binaria, pues escribimos: #pkg_add -r nombre El par ametro Nombre es el nombre de la aplicaci on a instalar. El sistema se encarga de localizarlo y bajarlo autom aticamente. En esta gu a no seguiremos esta opci on ya que se considera que los Ports es una herramienta mucho m as poderosa. Para eliminar una aplicaci on existente, siguiendo el mismo patr on escribimos: #pkg_delete nombre Existen otros comandos para crear paquetes y efectuar conguraciones avanzadas. Se recomienda la lectura del Handbook para profundizar en este tema.

7.1.2.

Sistema de Ports

Como hab amos dicho al principio existe una gran colecci on de Instrucciones de compilaci on llamada Ports que se utiliza para la instalaci on y mantenimiento de aplicaciones 45

46

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

basado en c odigo fuente. Y digo Instrucciones de Compilaci on ya que los Ports no incluyen el c odigo fuente de cada programa, sino solo parches e instrucciones de compilaci on. El c odigo fuente se baja desde Internet autom aticamente por demanda. Lo bueno del sistema de Ports es que es una gran base de datos en donde se puede ver el software compatible con FreeBSD, mantener actualizada la u ltima versi on, ver los boletines de seguridad asociado a cada paquete (audit) y por supuesto compilar de la manera mas o ptima y crear un paquete binario administrable luego por el Administrador de Paquetes (visto previamente). Supongamos que queremos localizar todo lo asociado con OpenLDAP, para ello escribimos los siguientes comandos: #cd /usr/ports #make search name="openldap" Estos comandos nos posicionan en /usr/ports donde residen los Ports y luego pues ejecutamos la opci on search que se encarga de buscar en toda la base de datos. La salida ser a algo as : Port: openldap-client-2.3.4_1 Path: /usr/ports/net/openldap23-client Info: Open source LDAP client implementation Maint: vsevolod@FreeBSD.org B-deps: libtool-1.5.18 R-deps: WWW: http://www.OpenLDAP.org/ Port: openldap-server-2.3.4 Path: /usr/ports/net/openldap23-server Info: Open source LDAP server implementation Maint: vsevolod@FreeBSD.org B-deps: db43-4.3.28 libltdl-1.5.18 libtool-1.5.18 R-deps: db43-4.3.28 libltdl-1.5.18 openldap-client-2.3.4_1 WWW: http://www.OpenLDAP.org/ Note que por cada paquete aparece un listado de dependencias necesarias para la compilaci on/instalaci on del mismo. Los sistemas de Administraci on de paquetes binarios que vienen con las distribuciones de Linux (como apt-get o yast) tienen un problema. Si dos aplicaciones utilizan, por ejemplo, libtool-1.5.18 y una de ellas es actualizada y ha sido precompilada con libtool-1.5.22 pues o se mantienen las dos versiones de libtool u obligatoriamente se actualiza la segunda aplicaci on. Con FreeBSD esto no pasa ya que la segunda aplicaci on se recompila con la nueva versi on de libtool y no hay necesidad de mantener dos versiones de esta librer a. Es importante siempre mantener el sistema operativo lo mas limpio posible. Por supuesto que los Ports no son Dios y si la aplicaci on no es compatible con la nueva versi on de alguna librer a, pues lo m as recomendable es actualizar toda la base de datos de Ports donde probablemente el problema haya sido resuelto ya por aquellos que mantienen este sistema (agregando un parche o actualizando la versi on del software). Es importante instalar dos paquetes que facilitan el trabajo con este sistema. Ellos son: Portaudit

 DEL SOFTWARE 7.1. ADMINISTRACION

47

Portupgrade El primero, se encarga de mantener la base de datos de seguridad actualizada y el segundo es una utilidad para instalar/actualizar los Ports de manera f acil. El sistema operativo env a diariamente un reporte de seguridad al administrador (root) donde incluye los accesos fallidos, intrusiones, y gracias al Portaudit un reporte de cuales son los paquetes desactualizados y que tan cr tico es mantenerlos as . Estos dos programas vienen con la distribuci on de paquetes incluidos en el CD de instalaci on de FreeBSD, as que pueden ser agregados utilizando SysInstall desde la instalaci on del sistema. Un ejemplo de la utilizaci on del Portaudit: #portaudit Affected package: php5-5.0.4_2 Type of problem: php -- _ecalloc Integer Overflow Vulnerability. Reference: http://www.FreeBSD.org/ports/portaudit/e329550b-54f7-11db-a5ae-00508d6a62df.html Affected package: ruby-1.8.4_4,1 Type of problem: ruby -- cgi.rb library Denial of Service. Reference: http://www.FreeBSD.org/ports/portaudit/ab8dbe98-6be4-11db-ae91-0012f06707f0.html Para instalar alg un Port tenemos dos variantes: manual y utilizando portinstall. La segunda es la que recomiendo debido a que hace algunos chequeos y operaciones adicionales que mantienen el sistema Healthy. Manualmente ser a algo as : #cd /usr/ports/net/openldap23-server #make config && make && make install Make cong - muestra el cartel de conguraci on del Port (en caso de que exista) Make - compila el Port Make Install - Instala el Port y crea un paquete asociado a este en el Adm on. de paquetes. Normalmente con Make Install se efect uan las otras dos operaciones. Utilizando PortInstall: #portinstall openldap-server El PortInstall tiene algunas opciones interesantes. Recomiendo la lectura del Manpage asociado. Para actualizar un paquete de manera autom atica (utilizando PortInstall) as como la actualizaci on de todas las dependencias (hacia arriba y/o abajo) recursivamente se utiliza la siguiente l nea: #portupgrade -rR openldap-server Note que esto ejecuta el proceso de compilaci on e instalaci on de las dependencias recursivas. Manualmente ud tendr a que ir por las carpetas de /usr/ports que desee actualizar. Adem as el portupgrade garantiza un Roll-Back (restaura la conguraci on anterior) en caso de que exista alg un error en el proceso de actualizaci on.

48

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

A pesar de que la actualizaci on de paquetes es un proceso autom atico, no se debe automatizar debido a que al cambiar de versi on puede ser que cambie la sintaxis de los cheros de conguraci on del software y esto traer a el mal funcionamiento de alg un servicio. La actualizaci on debe ser supervisada por un humano.

7.1.3.

Manteniendo los Ports Actualizados

La base de datos de Ports as como la estructura CVS (/usr/ports) debe ser actualizada peri odicamente. Para ello necesitamos un programa llamado CvsUp (versi on command line) que se encarga de sincronizar de manera optima dos arboles CVS. La idea es sincronizar los Mirros de FreeBSD con nuestra estructura local. Para efectuar esta operaci on de manera r apida podemos ayudarnos de un programa llamado Fastest CvsUp que se encarga de localizar el Mirror m as cercano a nuestra posici on geogr aca. #portinstall cvsup #portinstall fastest_cvsup Una vez instalado, en la carpeta /usr/share/examples/cvsup encontraremos un chero llamado ports-suple que contiene las instrucciones de actualizaci on de los ports. En el Handbook de FreeBSD se explica muy bien este aspecto, as que me limitar e a introducir un script que autom aticamente actualiza el sistema de Ports. Es recomendable crear una carpeta en donde guardar tanto el script como el chero ports-suple. La ubicaci on puede ser cualquiera, sin embargo me gusta /usr/local/etc/cvsup. #mkdir /usr/local/etc/cvsup #cd /usr/local/etc/cvsup #cp /usr/share/examples/cvsup/ports-supfile . Veamos el contenido del script de actualizaci on update-ports.sh #!/bin/sh # Script para la actualizacion del Sistema de Ports # Busca el Mirror mas cercano en USA y Mexico if SERVER=fastest_cvsup -q -c us,mx then echo "1/2 Ejecutando cvsup (Updating Ports)" cvsup -L2 -h $SERVER /usr/local/etc/cvsup/ports-supfile fi echo "2/2 Actualizando Indice de Ports" cd /usr/ports make fetchindex portsdb -u echo "Los Ports siguientes necesitan ser actualizados:" portversion -l .<. echo "Terminado en: /bin/date."

7.2. CONFIGURANDO SERVIDOR DE NOMBRES DE DOMINIO (BIND)

49

7.2.

Congurando Servidor de Nombres de Dominio (BIND)

El sistema operativo viene con BIND incluido, por lo cual solo debemos crear/modicar los cheros de conguraci on y activar el servicio en el rc.conf (Agregando la l nea named enable=YES). BIND es un servidor DNS que guarda la conguraci on y la base de datos de registros en cheros almacenados en el sistema de archivo del servidor en donde se hospeda el servicio (usualmente /etc/namedb/master). Vamos a mostrar como congurar BIND por cultura general debido a que posteriormente instalaremos y conguraremos un servidor DNS llamado LdapDns que tiene la caracter stica de almacenar los registros en el directorio LDAP, d andole as un car acter global y no local a las zonas dns. El chero principal de conguraci on del BIND se encuentra en /etc/namedb/named.conf. Inicialmente aparece el grupo options en el cual se especican las opciones generales del servidor dns y a continuaci on grupos que denen las zonas que se desean publicar. En nuestro caso, tenemos bsdland.com y las zonas de DNS Reverso para 192.168.0.0/24 y 10.0.0.0/24. Se ha eliminado la conguraci on para IPv6 que FreeBSD incluye de manera predeterminada en named.conf debido a que no es inter es nuestro. Veamos el contenido del chero /etc/namedb/named.conf: acl interna { 192.168.0.0/24; 192.168.1.0/24; }; options { directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; listen-on { 127.0.0.1;192.168.0.1;10.0.0.1;}; allow-recursion { interna;}; }; zone "." { type hint; file "named.root"; }; zone "bsdland.com" { type master; file "master/bsdland.com"; }; zone "0.168.192.in-addr.arpa" { type master; file "master/0.168.192.in-addr.arpa"; };

50

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

zone "0.0.10.in-addr.arpa" { type master; file "master/0.0.10.in-addr.arpa"; }; Lo m as signicativo adem as de la denici on de Zonas es la creacion de la ACL interna deniendo los IP de la red local para luego restringir los pedidos recursivos. Note que si no se dene esta opci on el DNS se marcar a como Abierto y esto puede traer algunos problemas. Para vericar su conguraci on DNS dir jase a www.dnsreports.com. Por cada zona existe un chero (hay que crearlo manualmente en la mayor a de los casos) ubicado en /etc/namedb/master/[Zona] en el cual se especican los registros que se desean publicar. Zona: /etc/namedb/master/bsdland.com $ORIGIN . $TTL 86400 ; 1 day bsdland.com IN SOA bsdland.com. ns1.bsdland.com. ( 2007041301 ; serial 3600 ; refresh (1 hour) 300 ; retry (5 minutes) 1209600 ; expire (2 weeks 6 days 16 hours) 3600 ; minimum (1 hour) ) NS ns1.bsdland.com. TXT "BSD Land Corporation" $ORIGIN bsdland.com. server1 A 192.168.0.1 Zona: /etc/namedb/master/0.168.192.in-addr.arpa @ IN SOA bsdland.com. root.bsdland.com. ( 2007041301 ; Serial 3600 ; Refresh 300 ; Retry 1209600 ; Expire 3600 ; Minimum ) IN NS bsdland.com. 1 IN PTR server1.bsdland.com. Zona: /etc/namedb/master/0.0.10.in-addr.arpa @ IN SOA bsdland.com. root.bsdland.com. ( 2007041301 ; Serial 3600 ; Refresh 300 ; Retry 1209600 ; Expire

7.2. CONFIGURANDO SERVIDOR DE NOMBRES DE DOMINIO (BIND)

51

3600 ; Minimum ) IN NS bsdland.com. 1 IN PTR ns1.bsdland.com.

52

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

7.3.

Congurando Kerberos V

Heimdal Kerberos 5 es el servidor de seguridad Kerberos (RFC 1510) que viene con el sistema FreeBSD. Existen otras implementaciones como MIT Kerberos, sin embargo utilizaremos Heimdal por la integraci on que esta tiene con el sistema operativo. Para que el servicio Kerberos funcione correctamente, los relojes de todas las PC/Servers de la red tienen que obligatoriamente estar sincronizados. En este documento se utilizar a Kerberos solo para el almacenamiento de las cuentas de administraci on o usuarios con poder. Los usuarios normales se almacenar an en el directorio Ldap con un hash MD5.

7.3.1.

Servidor Heimdal Kerberos

Primero debemos adicionar las siguientes l neas al chero /etc/rc.conf para activar el servicio: kerberos5_server_enable="YES" kadmind5_server_enable="YES" Luego debemos crear un chero llamado /etc/krb5.conf y agregar las siguientes l neas: [libdefaults] default_realm = BSDLAND.COM [realms] BSDLAND.COM = { kdc = kerberos.bsdland.com admin_server = kerberos.bsdland.com } [domain_realm] .bsdland.com = BSDLAND.COM En este chero de conguraci on hemos denido un Realm llamado BSDLAND.COM hospedado por el servidor kerberos.bsdland.com y adem as hemos relacionado BSDLAND.COM con el nombre de dominio bsdland.com. Debemos tambi en agregar los siguientes registros a nuestro servidor DNS para un correcto funcionamiento de este servicio: _kerberos._udp IN SRV _kerberos._tcp IN SRV _kpasswd._udp IN SRV _kerberos-adm._tcp IN SRV _kerberos IN TXT kerberos.bsdland.com. IN A 01 00 88 kerberos.bsdland.com. 01 00 88 kerberos.bsdland.com. 01 00 464 kerberos.bsdland.com. 01 00 749 kerberos.bsdland.com. BSDLAND.COM 192.168.0.1

Los registros de tipo SRV se utilizan para la localizaci on del servidor Kerberos en la Red. El registro TXT especica el Realm predeterminado a utilizar y el registro A dene el IP del servidor que hospeda f sicamente el servicio. Teniendo ya el servicio Kerberos congurado debemos inicializar la base de datos.

7.3. CONFIGURANDO KERBEROS V

53

#kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx kstash: writing key to /var/heimdal/m-key La llave maestra se utiliza para codicar la base de datos. No necesita recordar esta contrase na ya que se almacenar a en /var/heimdal/m-key. Se recomienda que escriba una clave compleja y que haga un backup de ese chero, debido a que si se pierde la base de datos se vuelve inutilizable. Para inicializar el Realm y agregar el primer usuario (En esta gu a alex ser a el usuario administrador) utilizaremos el utilitario kadmin de la siguiente manera: #kadmin -l kadmin> init BSDLAND.COM Realm max ticket life [unlimited]: kadmin> add alex Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx kadmin> quit Es tiempo de ejecutar el servicio: #/etc/rc.d/kerberos start #/etc/rc.d/kadmind start Para probar que todo haya salido como se esperaba obtengamos un ticket para alex: #kinit alex kinit: NOTICE: ticket renewable lifetime is 1 week Si efect ua alg un cambio en el servidor o hay alg un error oscuro (poco informativo/raro), es recomendable destruir la sesi on/ticket Kerberos y volverlo a crear: #kdestroy #kinit alex

7.3.2.

Cliente Kerberos

Una vez congurado el servidor Kerberos solo falta congurar los clientes que acceder an al servicio Kerberos. El servidor Kerberos es algo restrictivo, ya que no se comunica con ninguna otra computadora a menos que no la conozca. Para agregar un cliente Kerberos al servidor: #kadmin -l kadmin> add -r host/server1.bsdland.com Para agregar un servicio espec co (Servicio Kerberizado), por ejemplo OpenLDAP:

54

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

#kadmin -l kadmin> add -r ldap/server1.bsdland.com Luego debemos exportar el keytab que no es mas que una clave que debe tener el cliente para poderse validar con el servidor: kadmin> exp -keytab=/tmp/krb5.keytab host/server1.bsdland.com kadmim> exp -keytab=/tmp/krb5.keytab ldap/server1.bsdland.com Entonces para el cliente serve1.bsdland.com (que en nuestro ejemplo es el propio servidor Kerberos) hay que copiar los cheros /etc/krb5.conf y /tmp/krb5.keytab para la ubicaci on /etc. Es necesario cambiar los permisos de /etc/krb5.keytab a 755: #chmod 755 /etc/krb5.keytab

7.3.3.

Kerberizando SSH

Ahora conguremos el servidor SSH para permitir validaci on Kerberos. Primero modiemonos de que la siguiente quemos el chero /etc/ssh/sshd cong (Servidor SSH) y cercior conguraci on est a agregada: KerberosAuthentication yes KerberosOrLocalPasswd no KerberosTicketCleanup yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes GSSAPIDelegateCredentials yes neas: En el chero /etc/ssh/ssh cong (Cliente SSH) solo agreguemos las siguientes l GSSAPIAuthentication yes GSSAPIDelegateCredentials yes Luego accedamos al chero /etc/pam.d/sshd y descomentemos cualquier l nea que contenga pam krb5.so Reiniciemos entonces el servidor SSH: #/etc/rc.d/sshd restart Recuerde que para acceder al servidor v a SSH utilizando Kerberos 5, debe tener el Principal host/FQDN registrado en el Servidor Kerberos y agregado a /etc/krb5.keytab en la PC cliente. Para agregar un principal y exportarlo hacia un keytab (en el servidor): #kadmin kadmin> kadmin> kadmin> -l add -r host/server1.bsdland.com ext -k /tmp/krb5.keytab host/server1.bsdland.com exit

7.3. CONFIGURANDO KERBEROS V

55

Luego copie el chero /tmp/krb5.keytab para /etc/krb5.keytab en el cliente server1.bsdland.com (que en nuestro caso es el propio servidor). Esta conguraci on garantizar a no tener que teclear la contrase na cada vez que se inicie una sesi on SSH ya que se inicializa el Principal user@REALM una sola vez y al servidor SSH lo que se le pasa es un ticket. #kinit alex #alex@BSDLAND.COM Password: clave #kinit: NOTICE: ticket renewable lifetime is 1 week Entonces se puede acceder v a SSH sin contrase na. #ssh alex@server1.bsdland.com

56

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

7.4.

OpenLDAP

Instalemos ahora el servidor OpenLDAP. Para ello vimos que utilizando los Ports se hace de manera muy f acil: #portinstall openldap-server El Servidor OpenLDAP es un servicio cr tico para el sistema operativo por lo cual debe iniciarse antes que cualquier otro, entonces es necesario efectuar la siguiente conguraci on: #mv /usr/local/etc/rc.d/slapd.sh /etc/rc.d/slapd Esto garantiza que el servidor OpenLDAP sea el primero en ejecutar debido a que los scripts en /etc/rc.d se ejecutan primero que los almacenados en /usr/local/etc/rc.d. Pero instalar no es el problema, sino la conguraci on y puesta en marcha del servicio. Esta es una tarea tit anica debido a que debemos denir un esquema de directorio y no hay una receta para ello, ya que podemos hacer lo que queramos y en Internet cada documentaci on o How-To dene generalmente un esquema diferente.

7.4.1.

Usuarios y Grupos en Unix/Windows

Antes de empezar a congurar el directorio LDAP, creo que hay que hablar sobre los usuarios, grupos y sistema de permisos tanto en Unix/Linux como en Windows. Esto es necesario debido a que vamos a montar un servicio de directorio que hospedar a la informaci on necesaria para que un usuario pueda validarse desde estaciones con Windows o UNIX/Linux. En UNIX/Linux un usuario tiene un nombre y un identicador que se llama UID (User Id) que es un n umero entero. El UID 0 representa a root en UNIX/Linux. Un grupo tambi en tiene un identicador entero llamado GID (Group Id) y un nombre. Ahora un grupo puede tener varios miembros y cada usuario obligatoriamente tiene que pertenecer a al menos un grupo que inicialmente es lo que se le llama grupo efectivo (EGID). El grupo efectivo de cada usuario es el grupo que se aplica al efectuar cualquier operaci on en el sistema. Este EGID puede cambiarse a cualquier GID al cual el usuario pertenezca. En s ntesis un usuario pertenece a uno o varios grupos, pero solo uno es efectivo. Los permisos de los objetos del sistema se determinan por el EUID/EGID vigente. En Windows cada usuario/grupo tiene un identicador que no es un entero, sino un SID (Ejemplo: S-1-5-21-2547222302-1596225915-2414751004-512) con un formato espec co: SDOMAIN-RID. Un grupo puede contener varios usuarios y cada usuario tiene que tener un grupo predeterminado que generalmente es Domain Users o Domain Admins. Los permisos en Unix/Linux generalmente se especican con M ascaras y sobre Windows con ACL1 . Ahora, hay que llegar a una conguraci on h brida que permita que un usuario/grupo pueda ser visible desde Windows y Unix/Linux sin necesidad de duplicar el objeto. Adem as a la hora de agregar un usuario a alg un grupo, que autom aticamente esa relaci on sea visible desde ambos grupos de Sistemas Operativos. Por tanto hagamos una tabla donde especiquemos los campos necesarios (relacionados entre ellos) para que UNIX/Linux/Windows reconozcan la funcionalidad espec ca de los siguientes objetos (Tabla 7.1). El campo [nombre-usuario] debe ser remplazado por un nombre (en este documento utilizaremos alex) y no por palabras archiconocidas como administrator o root (por razones de
1

FreeBSD 5.x/6.x admite ACL. Ya vimos en el Cap tulo 6.5 como activarlas

7.4. OPENLDAP Nombre Domain Admins Domain Users Domain Guests [nombre-usuario] Descripci on Grupo de Administradores Usuarios Usuarios Invitados Usuario Administrador RID 512 513 514 500 UID 0 GID 0 513 65533 0 SID S-[DOM]-512 S-[DOM]-513 S-[DOM]-514 S-[DOM]-500

57

Cuadro 7.1: Tabla Comparativa prara Usuarios Windows/Unix seguridad para evitar algunos ataques). El campo [DOM] debe ser reemplazado por un n umero aleatorio de la forma: S-1-5-21298858960-1863792627-3661451959 (Los n umeros en negritas no se modican) Cada dominio debe tener un identicador diferente por lo cual se recomienda que modique los n umeros anteriores (sin negritas) y obtenga una nueva secuencia aleatoria. Los elementos especicados en la tabla anterior tienen que obligatoriamente existir en el directorio. Ahora cualquier otro objeto que se agregue para que sea visible para todos los sistemas operativos tiene que cumplir con las siguientes restricciones: Los UID/GID tienen que ser > 1000 para que no interera con los de sistema. Rid = 2 uidN umber + 1000 primaryGroup = 2 gidN umber + 1000 + 1 Las u ltimas dos f ormulas se utilizan para tener una relaci on equivalente entre los UID/GID de UNIX/Linux y los RID de Windows.

7.4.2.

Grupo Wheel (GID 0)

El grupo Wheel en FreeBSD es el grupo de los Administradores del Sistema (GID 0). Sin embargo, no muchas cosas se pueden hacer en el sistema con esto, ya que se necesita UID 0. Ahora, los usuarios que pertenecen a este grupo (Wheel - GID 0) pueden hacer su (Impersonar al usuario root) y realmente son los u nicos que pueden efectuar esta acci on. Sin embargo, la conguraci on predeterminada pide la contrase na de root para hacer su y realmente no deseamos que los administradores conozcan la contrase na de root y trabajen con su propia clave (suponga que existan m as de un administrador). Entonces para hacer su con el requerimiento m nimo de pertenecer al grupo Wheel, editamos el chero de conguraci on /etc/pam.d/su y la l nea: auth required pam_group.so no_warn group=wheel root_only fail_safe la cambiamos por: auth sufficient pam_group.so no_warn group=wheel root_only fail_safe Cuidado! Si alguien logra de alguna manera obtener un EGID 0, va a poder acceder a TODO el sistema sin restricciones!

58

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

7.4.3.

Esquema del Directorio

Primero debemos analizar que servicio vamos a instalar, ya que el directorio debe reejar/almacenar la informaci on necesaria para el correcto funcionamiento de los mismos: Cuenta POSIX (Usuario Unix/Linux) Cuenta Windows (Samba) MTA (Postx) Mail Account (Courier) PPP Access (Acceso Telef onico) DNS Zones DHCP Nets Un directorio LDAP es un contenedor jer arquico de objetos (Objects). Con esto digo que un objeto tiene un padre u nico y puede contener m ultiples hijos en dependencia de la clase (ObjectClass). Las clases son unidades que describen la forma de cada objeto. Cada objeto contiene atributos (Attributes) que no son m as que unidades descriptivas (nombre: valor). Un objeto puede implementar varias clases y tiene un tipo base. A la agrupaci on de clases seg un su funcionamiento conceptual se llama esquema (Schema). Un servidor LDAP implementa m ultiples esquemas. Los objetos son localizables seg un su identicador (DN), ejemplo: uid=Usuario,ou=Grupo,dc=dominio,dc=com De derecha a izquierda, utilizando la coma, se dene el nivel en que se encuentra el objeto en la jerarqu a. La sintaxis tipo=nombre se utiliza para nombrar de manera u nica al objeto. Entonces dc (RFC2247 Domain Component), ou (RFC2256 Organizational Unit) y uid (RFC2377 User Id) son tipos de objetos y Usuario, Grupo, dominio y com son nombres de objetos donde Usuario es hijo de Grupo que a su vez es hijo de dominio.com (dc=dominio,dc=com). Ahora, veamos en este ejemplo la forma del objeto dominio.com: # dominio.com dn: dc=dominio,dc=com dc: dominio associatedDomain: dominio.com objectClass: top objectClass: domain objectClass: domainRelatedObject Este objeto es de tipo especial, ya que el nombre es dc=dominio,dc=com. A este objeto se le llama Ra z y es el u nico que puede tener esa forma, todos los dem as se nombran como tipo=nombre. El primer atributo a analizar es objectClass. Este dene los atributos que puede tener el objeto. La clase top dene el atributo objectClass, as que la l nea objectClass: top tiene que

7.4. OPENLDAP

59

estar en cada objeto. La clase domain es de tipo estructural y es la que dene el tipo del objeto as como el atributo dc. La clase domainRelatedObject es de tipo auxiliar (tiene que ser utilizada obligatoriamente con una clase estructural) y dene el atributo asssociatedDomain. Las clases tambi en forman una jerarqu a y no todas las clases se pueden utilizar con todas, hay ciertas leyes para esto. Para m as informaci on es recomendable leer la Gu a de Usuario del servidor OpenLDAP, que brinda una descripci on avanzada sobre este tema. Veamos ahora algunos esquemas creados para OpenLDAP que vamos a utilizar en nuestra implementaci on. Core.schema - Estructura general del directorio Cosine.schema - RFC1274 COSINE, X.500 & Dns Zone Nis.schema - Dene un usuario POSIX (Unix/Linux) dyngroup.schema - Grupos Din amicos (OpenLDAP Overlay) InetOrgPerson.schema - Dene una entidad/persona de Red (RFC2798) Samba.schema - Esquema utilizado por el Servidor Samba 3.x Postx.schema - Esquema utilizado por el Servidor Postx (MTA) Authldap.schema - Esquema que dene un buz on de correo (Courier) RADIUS-LDAPv3.schema - Clases utilizadas por el servidor FreeRadius (PPP Access) Existen otros muchos esquemas, pero en esta gu a solo utilizaremos estos.

7.4.4.

Servidor Maestro

Una vez denido lo que queremos conguremos el servidor OpenLDAP. La conguraci on se encuentra en /usr/local/etc/openldap/slapd.conf. Es posible que aparezca como slapd.conf.default, asi que debemos hacer una copia hacia slapd.conf. #cd /usr/local/etc/openldap/ #cp slapd.conf.default slapd.conf La conguraci on que propongo para el servidor maestro (RW) es la siguiente: # Incluyendo Esquemas include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/postfix.schema include /usr/local/etc/openldap/schema/RADIUS-LDAPv3.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/authldap.schema

60

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

include

/usr/local/etc/openldap/schema/dnszone.schema

# Verificar los Esquemas y permitir LDAPv2 schemacheck on allow bind_v2 pidfile argsfile /var/run/openldap/slapd.pid /var/run/openldap/slapd.args

# Como se almacenan las contrasenas (MD5, CLEARTEXT) password-hash {MD5} #loglevel 256 # Como Habiliar SSL #TLSCipherSuite #TLSCertificateFile #TLSCertificateKeyFile #TLSCACertificateFile #TLSVerifyClient none

HIGH:MEDIUM:+SSLv2 /usr/local/etc/openldap/server.pem /usr/local/etc/openldap/server.pem /usr/local/etc/openldap/server.pem

# Integrando Kerberos con LDAP sasl-realm BSLAND.COM sasl-host server1.bsdland.com sasl-secprops none sasl-regexp uid=(.*),cn=.*,cn=.*,cn=auth ldap:///dc=bsdland,dc=com??sub?(uid=$1) sasl-regexp uid=(.*),cn=.*,cn=DIGEST-MD5,cn=auth ldap:///dc=bsdland,com =cu??sub?(uid=$1) sasl-regexp uid=(.+),cn=(.+),cn=.+,cn=auth ldap:///dc=basland,dc=com??sub?(|(uid=$1)(cn=$1@$2)) sasl-regexp uid=(.+),cn=.+,cn=auth ldap:///dc=bsdland,dc=com??sub?(|(uid=$1) (krb5PrincipalName=$1@BSDLAND.COM)) sasl-regexp gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth cn=administrator,dc=bsdland,dc=com # Sample security restrictions # Require integrity protection (prevent hijacking)

7.4. OPENLDAP

61

# Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind #security ssf=1 update_ssf=112 simple_bind=64 #security simple_bind=64 ###################################################################### # Access List - GENERAL ###################################################################### # Acceso a RootDSE & Schema access to dn.base="" by * read break access to dn.base="cn=Subschema" by * read break # Los usuarios pueden cambiar su contrasena access to attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdLastSet ,sambaPwdMustChange by self write by anonymous auth by * none break # Algunos atributos necesitan ser leidos anonimamente access to attrs=objectClass,homeDirectory,uidNumber,gidNumber,memberUid by * read break # Los usuarios pueden escribir su informacion personal access to attrs=cn,sn,description,telephoneNumber,roomNumber,homePhone,gecos,cn,sn ,givenname,homephone,givenname,title,ou,facsimiletelephonenumber,cn,mobile,o,l ,uid,initials,st,description,pager,street,sn,telephonenumber,labeleduri,postalcode by self write by * read break # El servicio samba debe poder escribir en los siguientes atributos access to attrs=sambaPwdLastSet,sambaLogonTime,sambaLogoffTime,sambaKickoffTime ,sambaPwdCanChange,sambaPwdMustChange,sambaAcctFlags,displayName,sambaHomePath ,sambaHomeDrive,sambaLogonScript,sambaProfilePath,description,sambaUserWorkstations ,sambaPrimaryGroupSID,sambaDomainName,sambaMungedDial,sambaBadPasswordCount ,sambaBadPasswordTime,sambaPasswordHistory,sambaLogonHours,sambaSID,sambaSIDList ,sambaTrustFlags,sambaGroupType,sambaNextRid,sambaNextGroupRid,sambaNextUserRid ,sambaAlgorithmicRidBase,sambaShareName,sambaOptionName,sambaBoolOption ,sambaIntegerOption,sambaStringOption,sambaStringListoption,sambaPrivilegeList by self read break by * none break # Los administradores controlan TODO access to * by group="cn=Directory Admins,ou=Groups,dc=bsdland,dc=com" write

62

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

by * read by self read by anonymous auth ###################################################################### # BDB database definitions - BSDLAND ###################################################################### modulepath moduleload database suffix rootdn rootpw directory lastmod index index index index index index index index index index index /usr/local/libexec/openldap back_bdb bdb "dc=bsdland,dc=com" "cn=Administrator,dc=bsdland,dc=com" clave /var/db/openldap-data on entryCSN,entryUUID eq objectClass,uidNumber,gidNumber userPassword,loginShell,homeDirectory dialupAccess eq cn,sn,uid,displayName memberUid,givenname sambaSID,sambaPrimaryGroupSID,sambaDomainName sambaGroupType,sambaSIDList eq mail,mailDrop eq,sub associatedDomain default eq,sub

eq eq pres,sub,eq eq,subinitial eq

eq,sub

replica host=192.168.1.1:389 binddn="cn=Administrator,dc=basland,dc=com" bindmethod=simple credentials=clave replogfile /var/db/openldap-data/bsdland.com.log # Listas Dinamicas overlay dynlist dynlist-oc groupOfURLs dynlist-ad memberURL # Unicidad overlay unique unique_base dc=bsdland,dc=com unique_attributes uid, maildrop

7.4. OPENLDAP

63

El chero de conguraci on est a dividido en varias secciones: Includes: Se denen los esquemas que se van a utilizar. TLS/SSL: Directivas para congurar el servicio de conexi on segura. En esta gu a no vamos a trabajar con LDAPS. SASL/Kerberos: OpenLDAP es un servicio Kerberizado por con un ticket v alido puede accederse al directorio. Sin embargo de alguna manera hay que mapear a los usuarios del servidor Kerberos con los usuarios LDAP. Eso se logra con las instrucciones sasl. Access List: Listado est atico de permisos y acceso al directorio. De esta manera se dene quien puede acceder a donde. Versiones m as modernas de OpenLDAP permiten permisos din amicos en el propio directorio, sin embargo, es conveniente mantener los permisos est aticos por razones de seguridad. Database: Secci on en donde se dene el Backend, base de datos donde se va a almacenar f sicamente la informaci on. Es normalmente BDB (Berkeley DB). Por cada Base de Datos hay que denir un dominio (sux), en nuestro caso dc=bsdland,dc=com, y un DN est atico y una contrase na para denir el usuario administrador. Inicialmente el directorio est a vaci o por tanto hay que especicar una cuenta inicial para poder insertar/agregar la estructura del directorio. Indexs: Los ndices juegan un papel importante en las b usquedas en el directorio. Note que, por ejemplo, cada vez que llegue un correo al servidor, se efectuar a una b usqueda LDAP sobre el atributo mail por lo cual es conveniente indexar el mismo (utilizando un B-Tree) para que sean logar tmicas y no lineales estas b usquedas. Replica: Pueden especicarse m as de un servidor Shadow (RO) al cual replicar los cambios del directorio. Esto se hace para balance de carga y para asegurar el funcionamiento de otros servicios en caso de la ca a del servidor maestro. Overlay: Son m odulos adicionales que se le agregan al servidor para extender la funcionalidad del mismo. Para utilizar Kerberos con OpenLDAP deben tenerse almacenados en el servidor Kerberos los elementos host/FQDN y ldap/FQDN donde FQDN es el nombre de dominio del servidor OpenLDAP (Ejemplo: server1.bsdland.com) El chero slapd.conf almacena la conguraci on del servidor. Ahora, existe otro chero de conguraci on llamado ldap.conf que almacena la conguraci on de los clientes Ldap. Los clientes Ldap son generalmente utilidades como ldapsearch, ldapadd entre otras. BASE dc=bsdland,dc=com URI ldap://master.bsdland.com ldap://ldap.bsdland.com El chero ldap.log se localiza generalmente en /usr/local/etc/openldap. El par ametro URI especica los servidores (separados por espacio) a los cuales se conectar a (en orden) para efectuar un pedido LDAP. Generalmente el primer servidor es el m as cercano (mas r apido) o el servidor maestro (RW). Para el caso del servidor maestro, el URI puede ser:

64

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

URI ldap://localhost Se recomienda que si se utilizan nombres de dominio, estos se denan est aticamente el en chero /etc/hosts o se utilicen direcciones IP, ya que luego se congurar a el Servidor DNS sobre LDAP y ser a redundante la resoluci on de estos nombres.

7.4.5.

Estructura del Directorio

Teniendo un servidor OpenLDAP funcional solo nos queda rellenarlo con la estructura de nuestra organizaci on. Para ello, cree un chero bsdland.com.ldif (puede ser cualquier nombre) y agregue los siguientes elementos (cambie esta plantilla seg un convenga): # Domain & Root bsdland.com dn: dc=bsdland,dc=com dc: bsdland associatedDomain: bsdland.com objectClass: top objectClass: domain objectClass: domainRelatedObject # Users, bsdland.com dn: ou=Users,dc=bsdland,dc=com ou: Users objectClass: organizationalUnit objectClass: top # Groups, bsdland.com dn: ou=Groups,dc=bsdland,dc=com ou: Groups objectClass: organizationalUnit objectClass: top # Grupo: Directory Admins, bsdland.com dn: cn=Directory Admins,ou=Groups,dc=bsdland,dc=com cn: Directory Admins objectClass: groupOfNames objectClass: top member: uid=alex,ou=Users,dc=bsdland,dc=com # Grupo: Domain Admins, bsdland.com dn: cn=Domain Admins,ou=Groups,dc=bsdland,dc=com cn: Domain Admins objectClass: posixGroup objectClass: sambaGroupMapping objectClass: top memberUid: alex

7.4. OPENLDAP

65

gidNumber: 0 sambaSID: S-1-5-21-298858960-1863792627-3661451959-512 sambaGroupType: 2 displayName: Domain Admins # Grupo: Domain Users, bsdland.com dn: cn=Domain Users,ou=Groups,dc=bsdland,dc=com cn: Domain Users objectClass: posixGroup objectClass: sambaGroupMapping objectClass: top memberUid: alex gidNumber: 513 sambaSID: S-1-5-21-298858960-1863792627-3661451959-513 sambaGroupType: 2 displayName: Domain Users # Grupo: Domain Guests, bsdland.com dn: cn=Domain Guests,ou=Groups,dc=bsdland,dc=com cn: Domain Guests objectClass: posixGroup objectClass: sambaGroupMapping objectClass: top gidNumber: 65533 sambaSID: S-1-5-21-298858960-1863792627-3661451959-514 sambaGroupType: 2 displayName: Domain Guests # Computers, bsdland.com dn: ou=Computers,dc=bsdland,dc=com ou: Computers objectClass: organizationalUnit objectClass: top # Idmap, bsdland.com dn: ou=Idmap,dc=bsdland,dc=com ou: Idmap objectClass: organizationalUnit objectClass: top # BSDLAND, bsdland.com dn: sambaDomainName=BSDLAND,dc=bsdland,dc=com sambaDomainName: BSDLAND sambaNextGroupRid: 90000 sambaNextUserRid: 90000 sambaSID: S-1-5-21-298858960-1863792627-3661451959

66

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

sambaNextRid: 90000 sambaAlgorithmicRidBase: 1000 uidNumber: 1004 gidNumber: 1000 objectClass: sambaDomain objectClass: sambaUnixIdPool objectClass: top Ahora, expliquemos para qu e se utilizan estos objetos: dc=bsdland,dc=com Ra z del directorio, sirve de base para el almacenamiento de los objetos restantes y dene un dominio de trabajo. ou=Users,dc=bsdland,dc=com Unidad Organizativa (Organizational Unit) que se utilizar a pr oximamente para almacenar los objetos que representan a cada usuario de nuestra organizaci on. ou=Groups,dc=bsdland,dc=com Es donde se almacenar an los grupos de usuarios. cn=DirectoryAdmins,ou=Groups,dc=bsdland,dc=com Grupo de Administradores. Todo usuario que pertenezca a este grupo podr a modicar libremente el directorio. Inicialmente debemos agregar un usuario que ser a el administrador. Denamos a alex como administrador. cn=DomainAdmins,ou=Groups,dc=bsdland,dc=com Grupo de Administradores de Dominio (Windows). cn=DomainUsers,ou=Groups,dc=bsdland,dc=com Grupo de Usuarios. Todos los usuarios del dominio deben pertenecer a este grupo. cn=DomainGuest,ou=Groups,dc=bsdland,dc=com Grupo de Invitados. Grupo requerido por Windows. ou=Computers,dc=bsdland,dc=com Unidad Organizativa en donde se almacenar an las cuentas de las PC (Windows NT, 2000, XP & Vista) que acceden al servidor Samba (Controlador de Dominio Windows) ou=Idmap,dc=bsdland,dc=com Utilizado por el servidor Samba (No se utiliza en esta gu a) sambaDomainName=BSDLAND,dc=bsdland,dc=com Objeto que dene un dominio de Windows. Necesario para que el servidor Samba pueda hospedar un PDC (Primary Domain Controller) Note que el grupo Directory Admins es un grupo de tipo GroupOfNames, sin embargo los restantes grupos son de tipo posixGroup. La diferencia consiste en que GroupOfNames es un grupo de seguridad y se utiliza por las ACL (Permisos) del servidor OpenLDAP para almacenar los administradores del directorio (aquellos que pueden cambiar la informaci on del directorio). Los restantes grupos son grupos est andares de Unix/Linux (Posix) y/o Windows.

7.4. OPENLDAP

67

Para agregar esta conguraci on al servidor LDAP, ejecute el siguiente comando: #ldapadd -xa -D "cn=administrator,dc=bsdland,dc=com" -W -f ldap.ldif Este comando producir a la siguiente salida en caso de que todo ocurra sin errores: adding adding adding adding adding adding new new new new new new entry entry entry entry entry entry "dc=bsdland,dc=com" "ou=Users,dc=bsdland,dc=com" "ou=Groups,dc=bsdland,dc=com" "dc=Directory Admins,ou=Groups,dc=bsdland,dc=com" "ou=Computers,dc=bsdland,dc=com" "ou=Idmap,dc=bsdland,dc=com"

Entonces ya podemos conectarnos al directorio. Para vericar los objetos entrados podemos utilizar la siguiente utilidad: # ldapsearch -x -b "dc=bsdland,dc=com" Esto listar a el contenido p ublico del directorio debido a que nos estamos conectando de manera an onima: # # # # # # # extended LDIF LDAPv3 base <dc=bsdland,dc=com> with scope subtree filter: (objectclass=*) requesting: ALL

# bsdland.com dn: dc=bsdland,dc=com ... (Omitido para simplificaci on) ... # search result search: 2 result: 0 Success # numResponses: 6 # numEntries: 5 Agreguemos ahora a nuestro usuario administrador: dn: uid=alex,ou=Users,dc=bsdland,dc=com uid: alex objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: person

68

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

objectClass: organizationalPerson objectClass: sambaSamAccount cn: alex givenName: Alex sn: Hernandez displayName: alex gecos: alex description: Usuario Administrador uidNumber: 0 loginShell: /usr/local/bin/bash homeDirectory: /home/alex userPassword: {MD5}+8cc42zCB5Dy7u0hl4mOcQ== gidNumber: 0 sambaAcctFlags: [UX] sambaDomainName: BSDLAND sambaLMPassword: ACAC9347DFF38B41AAD3B435B51404EE sambaNTPassword: 4B267A5F5FA0FEF17CFCB09AEBE96B34 sambaPrimaryGroupSID: S-1-5-21-298858960-1863792627-3661451959-512 sambaPwdCanChange: 2147483647 sambaPwdLastSet: 1151269389 sambaPwdMustChange: 2147483647 sambaSID: S-1-5-21-298858960-1863792627-3661451959-2000 Este usuario puede validarse tanto en estaciones de trabajos Windows (luego veremos como adicionarlas al dominio) y UNIX/Linux. Note que hay tres tipos de contrase nas especicadas en tres atributos diferentes: userPassword (MD5), sambaNTPassword y sambaLMPassword. Para generar estos hash podemos auxiliarnos de los siguientes utilitarios: # slappasswd -h {MD5} -s contrase~ na Este utilitario generar a un hash MD5 utilizado por el atributo userPassword. Para generar las contrase nas de Samba, se pueden utilizar un programa llamado LDAP Administrator. Los hash del usuario alex se han generado para la contrase na clave (sin las comillas). Si se utiliza Kerberos y se desea administrar el Servidor OpenLDAP de manera segura es recomendable eliminar el atributo userPassword de los administradores, para as no poder validarse en el directorio por ninguna otra v a que no sea GSSAPI. Recuerde que la contrase na de los administradores se guarda en el Servidor Kerberos. La desventaja es que la cuenta que no tenga userPassword solo podr a utilizarse en servicios Kerberizados. A media que se avance en la lectura de este documento se agregar an nuevos objetos en el directorio y la cuenta de Alex ser a extendida para que pueda acceder a otros servicios como correo y acceso telef onico.

7.4.6.

Asociando el Sistema con el Directorio: PAM & NSSwitch

Una vez creado el servicio de directorio, debemos decirle al sistema operativo de alguna manera que en vez de sacar los usuarios, grupos y contrase nas de la base de datos local

7.4. OPENLDAP

69

(/etc/passwd) haga la b usqueda sobre el directorio LDAP. Para ello tenemos dos herramientas: PAM (Pluggable Authentication System) y Nsswitch (Name Service Switch - RFC 2307 NSS Module). PAM es el sistema de autenticaci on de la mayor a de los UNIX/Linux. Le permite al sistema operativo validar las contrase nas de los usuarios contra m ultiples (y diferentes) sistemas de almacenamiento (backends) como UNIX Est andar, RSA, MySQL, Kerberos o LDAP. NSS (Nss Ldap) le permite al sistema operativo una vez el usuario validado obtener informaci on asociada al mismo (grupos al que pertenece, shell, directorio home, id, direcci on de correo electr onico, entre otras). Primero conguremos NSS LDAP, para ello instalemos el port nss ldap: #portinstall nss_ldap Luego accedamos a la carpeta /usr/local/etc/ y editemos el chero llamado nss ldap.conf: #cp nss_ldap.conf.example nss_ldap.conf #ee nss_ldap.conf uri ldap://localhost base dc=bsdland,dc=com timelimit 5 bind_timelimit 5 bind_policy soft Una vez congurado el modulo hay que decirle al sistema operativo como utilizarlo: #ee /etc/nsswitch.conf group: ldap files host: files dns networks: files passwd: ldap files shells: ldap files Luego conguremos pam ldap: #portinstall pam_ldap Este comando instalar a un chero llamado ldap.conf.dist en /usr/local/etc/ldap.conf.dist que debemos renombrar (eliminar .dist). Este chero de conguraci on almacena la informaci on necesaria para que pam ldap pueda conectarse al servidor LDAP. Note que anteriormente ten amos un ldap.conf con dos l neas. Este ldap.conf.dist incluye esas dos l neas mas otras conguraciones necesarias. uri ldap://localhost base dc=bsdland,dc=com timelimit 5 bind_timelimit 5 bind_policy soft

70

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

Este chero contiene muchas m as opciones de conguraci on. Las m nimas necesarias son las mostradas anteriormente, sin embargo ud puede explorar el funcionamiento de este modulo descomentariando las restantes opciones (cuidado!). En versiones modernas de FreeBSD (6.2/7.x) los cheros ldap.conf, nss ldap.conf que pueden ser nombres (Hard Links) y pam ldap.conf tienen el mismo formato as para un mismo chero Una vez congurado el m odulo debemos decirle al sistema operativo que lo utilice. Para ello accedemos a la carpeta /etc/pam.d donde se almacena la conguraci on del sistema PAM. Luego creamos un chero llamado ldap y agregamos la siguiente l nea: login auth sufficient /usr/local/lib/pam_ldap.so Ahora editemos el chero llamado system y agreguemos la siguiente l nea: auth sufficient /usr/local/lib/pam_ldap.so Para probar si funciona NSS podemos ejecutar el siguiente commando: # id alex uid=500(alex) gid=0(wheel) groups=0(wheel), 513(Domain Users) Para probar PAM abramos otra terminar (Alt+F2) y valid emonos como alex. El servidor OpenLDAP puede tardar unos segundos en arrancar debido a que el m odulo NSS intentar a buscar en el directorio informaci on sobre el usuario que est a corriendo el servidor. Sin embargo no existe todav a el directorio, por lo que NSS va a tardar un poco en darse cuenta de ese detalle.

7.5. EXTENDIENDO BIND (SERVIDOR DNS) SOBRE LDAP

71

7.5.

Extendiendo BIND (Servidor DNS) sobre LDAP

Como vimos anteriormente con BIND debemos guardar la conguraci on de manera local en el Server. Sin embargo, la conguraci on de las Zonas DNS tiene car acter global (no pertenece a ning un servidor espec co) por lo que debe estar almacenada en el directorio. Esto garantiza tener varios servidores DNS hospedando la misma Zona y al efectuar alg un cambio este se har a efectivo en todos los servidores al instante. Microsoft DNS Server (Windows 2000, 2003) hospeda las Zonas DNS en una partici on de Active Directory (Servicio de Directorio de Microsoft) Hay un parche para BIND 9 llamado bind9-sdb-ldap, que le permite obtener la informaci on de las zonas Dns desde el directorio LDAP y no desde cheros como tradicionalmente lo hace. Es necesario tener congurado el servidor OpenLDAP con el esquema dnszone.schema Es nuestro objetivo que el Port bind9-sdb-ldap reemplace la instalaci on de BIND que viene con el sistema operativo, por tanto debemos especicar una opci on extra en la instalaci on de este Port: # cd /usr/ports/dns/bind9-sdb-ldap # make WITH_PORT_REPLACES_BASE_BIND9=yes install && make clean La nueva versi on de BIND, sigue teniendo un archivo de conguraci on en /etc/namedb/named.conf el cual vamos a modicar para sacar la informaci on del directorio. Debemos cambiar: zone "bsdland.com" { type master; file "master/bsdland.com"; }; Por: zone "bsdland.com" { type master; database "ldap ldap://127.0.0.1/dc=DNSZones,dc=bsdland,dc=com??sub?? 172800"; }; El formato de la nueva l nea es de la forma: Database "ldap ldap://IP/BASE TTL-PREDETERMINADO" Ahora solo falta agregar al directorio la conguraci on de las zonas DNS. Para ello podemos crear un chero temporal llamado dns.ldif con el siguiente contenido: # GRUPO DE ZONAS DNS dn: dc=DNSZones,dc=bsdland,dc=com dc: DNSZones objectClass: top objectClass: dcObject objectClass: dNSDomain

72

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

# ZONA: BSDLAND.COM dn: zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: bsdland.com zoneName: bsdland.com # SOA: BSDLAND.COM dn: relativeDomainName=bsdland.com,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: bsdland.com zoneName: bsdland.com dNSTTL: 86400 dNSClass: IN SOARecord: bsdland.com. ns1.bsdland.com. 2007041301 3600 300 1209600 3600 NSRecord: ns1.bsdland.com. TXTRecord: "BSD Land Corporation" # A HOST: server1.bsdland.com dn: relativeDomainName=server1,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: server1 zoneName: bsdland.com dNSTTL: 86400 dNSClass: IN ARecord: 192.168.0.1 # SRV: _kerberos._udp.bsdland.com dn: relativeDomainName=_kerberos._udp,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: _kerberos._udp zoneName: bsdland.com dNSTTL: 86400 dNSClass: IN SRVRecord: 01 00 88 kerberos.bsdland.com. # SRV: _kerberos._tcp.bsdland.com dn: relativeDomainName=_kerberos._tcp,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: _kerberos._tcp zoneName: bsdland.com

7.5. EXTENDIENDO BIND (SERVIDOR DNS) SOBRE LDAP

73

dNSTTL: 86400 dNSClass: IN SRVRecord: 01 00 88 kerberos.bsdland.com. # SRV: _kpasswd._udp.bsdland.com dn: relativeDomainName=_kpasswd._udp,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: _kpasswd._udp zoneName: bsdland.com dNSTTL: 86400 dNSClass: IN SRVRecord: 01 00 464 kerberos.bsdland.com. # SRV: _kerberos-adm._tcp.bsdland.com dn: relativeDomainName=_kerberos-adm._tcp,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: _kerberos-adm._tcp zoneName: bsdland.com dNSTTL: 86400 dNSClass: IN SRVRecord: 01 00 749 kerberos.bsdland.com. # TXT: _kerberos.bsdland.com dn: relativeDomainName=_kerberos,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: _kerberos zoneName: bsdland.com dNSTTL: 86400 dNSClass: IN TXTRecord: BSDLAND.COM # CNAME: kerberos.bsdland.com dn: relativeDomainName=kerberos,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: kerberos zoneName: bsdland.com dNSTTL: 86400 dNSClass: IN CNAMERecord: server1.bsdland.com. # CNAME: master.bsdland.com dn: relativeDomainName=master,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com

74

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

objectClass: top objectClass: dNSZone relativeDomainName: master zoneName: bsdland.com dNSTTL: 86400 dNSClass: IN CNAMERecord: server1.bsdland.com. # CNAME: ldap.bsdland.com dn: relativeDomainName=ldap,zoneName=bsdland.com,dc=DNSZones,dc=bsdland,dc=com objectClass: top objectClass: dNSZone relativeDomainName: ldap zoneName: bsdland.com dNSTTL: 86400 dNSClass: IN CNAMERecord: server1.bsdland.com. Entonces podemos agregar la informaci on al directorio: #ldapadd -f dns.ldif Probemos algunos registros: # dig server1.bsdland.com ; <<>> DiG 9.3.2 <<>> server1.bsdland.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37116 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;server1.bsdland.com. IN A ;; ANSWER SECTION: server1.bsdland.com. 86400 IN A 192.168.0.1 ;; ;; ;; ;; Query time: 42 msec SERVER: 192.168.0.1#53(192.168.0.1) WHEN: Mon Dec 11 01:34:29 2006 MSG SIZE rcvd: 53

7.6. CONFIGURANDO CONTROLADOR DE DOMINIO PARA WINDOWS: SAMBA 75

7.6.

Congurando Controlador de Dominio para Windows: Samba

Conguremos ahora un controlador de dominio para Windows. El servicio de directorio ha sido anteriormente actualizado con la informaci on necesaria para ejecutar un servidor Samba. Solo queda la instalaci on y conguraci on del servidor Samba en s . #portinstall samba Tambi en necesitamos instalar un Port llamado FAM (File Alteration Monitor) que es utilizado por el servidor samba para monitorear los cambios en las carpetas compartidas. Posteriormente este Port ser a utilizado tambi en por el servidor POP3/IMAP Courier. #portinstall fam Una vez instalado, debemos congurarlo. Primero hay que vericar que el chero /etc/rpc contenga la siguiente l nea: sgi_fam 391002 Podemos vericarlo de la siguiente manera: #cat /etc/rpc | grep sgi Si no existe pues lo agregamos: #echo sqi_fam 391002 >> /etc/rpc Despu es hay que ejecutar FAM con el servidor Inet. Para ello se agrega la siguiente l nea al chero /etc/inetd.conf sgi_fam/1-2 stream rpc/tcp wait root /usr/local/bin/fam fam Tambi en hay que agregar al chero /etc/rc.conf las siguientes l neas para activar el servidor Inet y el servidor RPC: inetd_enable="YES" rpcbind_enable="YES" Una vez terminada esta conguraci on pues se inician ambos servicios: #/etc/rc.d/inetd start #/etc/rc.d/rpcbind start Ahora conguremos el servidor Samba. Para ello modique el chero de conguraci on /usr/local/etc/samba.conf # Configuracion Global [global] # Nombre del Servidor netbios name = server1 # Dominio de Red

76

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

workgroup = BSDLAND server string = Controlador de Dominio Primario # Sobre Seguridad & Contrase~ nas security = user null passwords = yes encrypt passwords = yes # Opciones de Seguridad para limitar el acceso por IP hosts allow = 192.168.0. 127. interfaces = 192.168.0.1/24 127.0.0.1/8 socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192 # IMPRESORAS load printers = yes printcap name = /etc/printcap printcap name = lpstat printing = cups guest account = nobody # Logs log file = /var/log/samba/log.%m max log size = 50 # Controlador de Dominio Primario (PDC) local master = yes os level = 255 domain master = yes preferred master = yes domain logons = yes # Si se desea crear un script de inicio por PC o por Usuario logon script = %m.bat logon script = %U.bat # Roaming Profiles logon path = \\%L\Profiles\%U # Si desea desactivar Roaming Profiles... logon home= logon path= unix password sync = no # Activar compatibilidad con todos los Windows

# # # #

# #

# #

7.6. CONFIGURANDO CONTROLADOR DE DOMINIO PARA WINDOWS: SAMBA 77

client schannel = auto server schannel = auto server signing = auto # Servidor WINS y Proxy DNS wins support = yes dns proxy = yes # Permitir nombres con tildes y Unicode display charset = koi8-r unix charset = cp850 dos charset = cp866 # Permitir almacenar atributos MS-DOS (FAT) store dos attributes = yes map hidden = no map system = no map archive = no # Permitir ACL nt acl support = yes inherit acls = yes map acl inherit = yes # Obtener los Usuarios/Grupos/Dominio del directorio LDAP passdb backend = ldapsam:ldap://server1.bsdland.com ldap suffix = dc=bsdland,dc=com ldap machine suffix = ou=Computers ldap user suffix = ou=Users ldap group suffix = ou=Groups ldap admin dn = "cn=Administrator,dc=bsdland,dc=com" ldap ssl = No time server = yes ldap passwd sync = yes #============================ Share Definitions ============================== # Permite acceder al perfil del usuario con la direccion \\server\usuario [homes] comment = Home Directories browseable = no writable = yes # Carpeta necesaria para validar usuarios en la red [netlogon] comment = Network Logon Service path = /usr/home/samba/netlogon

78

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

guest ok = yes writable = yes write list = wheel "Domain Admins" share modes = no # Activa los profiles de los usuarios # Normalmente se encuentran en /usr/home/usuario [Profiles] path = /usr/home browseable = no guest ok = yes # IMPRESORAS #[printers] # comment = All Printers # path = /var/spool/samba # browseable = no # Set public = yes to allow user guest account to print # guest ok = no # writable = no # printable = yes # Carpeta Temporal #[tmp] # comment = Temporary file space # path = /tmp # read only = no # public = yes Note que la conguraci on de las impresoras se ha comentariado. Puede activarlos seg un convenga (Tiene que congurar CUPS si desea instalar una impresora en FreeBSD). Hay que crear la carpeta /usr/home/samba/netlogon que es donde se almacenar a la informaci on necesaria para la validaci on de Windows (Scripts de Inicio, entre otras opciones). Para ello: # mkdir -p /usr/home/samba/netlogon # chown -R root:wheel /usr/home/samba/netlogon # chmod -R 775 /usr/home/samba/netlogon Los administradores tendr an acceso de escritura a esta carpeta. Es necesario que samba tenga permisos de escritura en el directorio, para que desde Windows se pueda efectuar acciones como cambiar la contrase na de usuario. Sin embargo, solo hemos denido el usuario con el cual nos vamos a validar en el directorio. Para especicar la contrase na se utiliza el siguiente comando: #smbpasswd -W Agregue el servicio en /etc/rc.conf

7.6. CONFIGURANDO CONTROLADOR DE DOMINIO PARA WINDOWS: SAMBA 79

samba_enable="YES" Para arrancar el servicio: #/usr/local/etc/rc.d/samba.sh start Para probar si el servidor ha sido cargado satisfactoriamente: #smbclient -L localhost Cuando pida contrase na simplemente presione enter para validarse an onimamente. Si desea validarse como alex puede hacerlo de la siguiente manera: #smbclient -L localhost -U alex Samba guarda toda la informaci on necesaria para su correcto funcionamiento en forma de base de datos en la carpeta /var/db/samba. Si aparece alg un problema sin explicaci on aparente es recomendable borrar el contenido de la misma (no la carpeta en s ), ejecutar el comando smbpasswd -W y volver a cargar Samba para que se recree toda la informaci on. Esto es posible hacerlo porque la informaci on de las cuentas se almacena en el directorio LDAP.

80

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

7.7.

Congurando MTA: Postx

Antes de pasar a la conguraci on de Postx, veamos tres esquemas que se utilizan en la actualidad para la conguraci on de m ultiples servidores de correos en conjunto: Cluster de correo Sistema de Correo distribuido Entorno Mixto

7.7.1.

Cluster de Correo

Un cluster de servidores en general no es m as que la utilizaci on de dos o m as equipos f sicos para hospedar el mismo servicio y mantener as una alta disponibilidad en caso de que uno de ellos por causas t ecnicas o de mantenimiento tenga que permanecer apagado o desconectado (Figura 7.1). Generalmente este tipo de conguraci on necesita un dispositivo de almacenamiento externo

Figura 7.1: Cluster de Correos (Cluster Storage) independiente a cada servidor para mantener la informaci on sincronizada entre ellos. Cada cambio que se efect ue en alg un nodo del cluster (servidor) se guarda inmediatamente hacia el dispositivo de almacenamiento para que as en caso de fallo otro nodo pueda seguir trabajando y no se caiga el servicio. almacenamiento para que as en caso de fallo otro nodo pueda seguir trabajando y no se caiga el servicio. La t ecnica m as popular para compartir una direcci on IP entre dos o m as

7.7. CONFIGURANDO MTA: POSTFIX

81

servidores se llama NLB (Network Load Balancing) que signica Balance de carga de Red y lo que hace b asicamente es enmascarar la direcci on IP en cada nodo activando el modo promiscuo de cada tarjeta de red y aceptando/rechazando los paquetes IP seg un ciertos algoritmos que no vamos a tocar en este documento. En dependencia del software utilizado ser a el hardware requerido, pero normalmente, se necesita un n umero impar n de servidores para tener un fallo de n 2 . Esto signica que para poder tener un servidor fuera de servicio es necesario instalar 3 servidores en el cluster. En caso de que falle otro servidor m as, falla el cluster entero y se cae el servicio. Es posible tambi en crear un cluster con dos servidores (al menos con UNIX), pero no se recomienda por la cantidad de problemas que pueden ocurrir con esa disposici on. En nuestro caso (Servicio de Correos), la informaci on que hay que proteger/mantener disponible es la cuenta y el buz on de cada usuario (mailbox) y la cola de correos (correos salientes, reenv os, etc). Este tipo de conguraciones requiere hardware y software especializado y los costos de implantaci on pueden ser elevados.

7.7.2.

Sistema de correo distribuido

Los clusters garantizan alta disponibilidad contra fallos y/o cat astrofes, sin embargo, cuando la cantidad de cuentas de correo aumenta considerablemente, un cluster de correo no es capaz de almacenar y/o manejar todos estos buzones. Adem as el tr aco generado puede ser considerablemente alto. Para solucionar este problema se ide o una nueva alternativa que consisti o en dividir un mismo dominio de correos (Por ejemplo: bsdland.com) en varios grupos de servidores independientes (Figura 7.2) (inclusive en diferentes posiciones geogr acas y con diferentes enlaces a Internet) que de alguna manera se relacionasen entre ellos y que fueran capaces de: Distribuirse la carga de red en servidores.
c n

donde c es el coeciente de carga y n la cantidad de

Dividir la cantidad de buzones entre los n servidores. Esto tiene como ventaja que distribuye el trabajo, pero si alguno de los servidores deja de funcionar, los usuarios pertenecientes a ese servidor no van a poder acceder a sus cuentas de correo. No obstante, los correos de entrada no se pierden ya que son recibidos por cualquier otro servidor, que los almacena temporalmente hasta que el servidor autoritativo vuelva al servicio. Veamos te oricamente como funciona este sistema y demostremos que efectivamente se distribuye la carga. Primero, cada usuario tiene dos (o m as) direcciones de correo electr onico, una autoritativa que dene el servidor al cual pertenece el buz on y las restantes son alias. Ejemplo: Usuario: alex Direcci on Autoritativa: alex@mx2.bsdland.com Direccion Email: alex@bsdland.com Note que el usuario alex puede recibir correos con alex@bsdland.com, sin embargo, el servidor de correos (cualquiera del conjunto) localiza la direcci on autoritativa alex@mx2.bsdland.com y le env a el mensaje al servidor mx2.bsdland.com que a su vez detecta que esa cuenta le pertenece y almacena la informaci on recibida en el buz on de alex. Para el usuario esta reescritura de direcciones es transparente, ya que la direcci on autoritativa solo se usa por el

82

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

Figura 7.2: Granja de Servidores Distribuidos

protocolo SMTP para el env o del mensaje. En el cuerpo del mismo aparece solamente la direcci on de env o alex@bsdland.com. Para poder recibir correos tienen que existir dos cosas: un servidor DNS que registre los MX (mail exchanger) para un dominio determinado y un servidor SMTP (Simple Mail Transfer Protocol) que sea capaz de reconocer el dominio registrado. Los servidores SMTP se clasican como servidor autoritativo si almacenan los buzones de un dominio determinado o Relay si es un servidor que reconoce la direcci on electr onica, pero solo puede reenviarla hacia un servidor autoritativo. Entonces en un conjunto de servidores distribuidos todos act uan como autoritativos para una porci on de los buzones y como Relay para el resto de las cuentas. Ahora, para que el mundo pueda localizar los servidores de correo tenemos que congurar los MX que quedar an de la siguiente manera: mx1.bsdland.com ip-servidor-1 mx2.bsdland.com ip-servidor-2 bsdland.com ip-servidor-1, ip-servidor-2 Note que el Servidor 1 puede recibir correos desde @bsdland.com y @mx1.bsdland.com, sin embargo solo va a ser autoritativo para @mx1.bsdland.com, y para el resto de los dominios va a actuar como Relay. Entonces la mitad de las cuentas de usuarios las creamos con @mx1.bsdland.com y la otra porci on con @mx2.bsdland.com garantizando as que se dividan las cuentas entre esos servers. Entonces, Por qu e se balancean las cargas? No puede darse el caso de que todos los mensajes entren por un solo servidor? La respuesta es simple. Cuando un servidor de correos externo va a entregar un correo a @bsdland.com, lo primero que hace es una b usqueda DNS por los MX de este dominio. Los servidores DNS est an preparados para devolver la lista de

7.7. CONFIGURANDO MTA: POSTFIX

83

registros MX con un orden aleatorio (para MX de un mismo peso) y el funcionamiento de los servidores de env o correos es iterar por la lista hasta que se env e el mensaje, haya un error o se acabe la lista. En caso de que ocurra un error y no sea grave, se espera un tiempo (que va creciendo exponencialmente en cada reintento) y se vuelve a comenzar la operaci on de env o volviendo a hacer un pedido DNS. Si ocurre un error grave se le env a una noticaci on del error al remitente. Por tanto, para una lista de n servidores MX con igual peso la 1 y si se env an c correos probabilidad de que encabece la lista un servidor determinado es n c la probabilidad de que lo reciba ese servidor es n . Esto es teniendo en cuenta que cada correo es equivalente (mismo tama no). Ahora, suponiendo que el servidor autoritativo para una cuenta determinada est e saturado y no acepte, por problemas de ancho de banda, ning un mensaje nuevo, en el pr oximo reintento del servidor externo se seleccionar a otro servidor de la lista de MX y se enviar a el mensaje. Luego el servidor Relay que esta almacenando el correo temporalmente, se encargar a de entreg arselo al servidor autoritativo cuando este termine las tareas pendientes y acepte denuevo informaci on. Esto es en cuanto al env o/recibo de correo electr onico, sin embargo no se ha hablado de c omo el usuario nal revisa su buzon de correo. Para esto hay varias t ecnicas. Primero, agregar nuevos servidores llamados Front-End a los que los usuarios se conecten y transparentemente accedan a sus cuentas. El servidor Front-End tiene que saber a que servidor Back-End del conjunto conectarse para obtener la informaci on. Esta t ecnica es muy utilizada sin embargo requiere de hardware adicional. Nosotros vamos a permitir que cada usuario pueda conectarse a cualquier servidor del conjunto y que estos sean capaces de extraer la informaci on en caso de que no sean autoritativos para esa cuenta. Esto lo vamos a lograr v a software compartiendo los buzones de usuarios a trav es de una red segura (IPSec) utilizando NFS. Entonces cada servidor POP/IMAP va a ser capaz de acceder a cualquier buz on. Por supuesto que va a ser m as r apido que el usuario se conecte al servidor autoritativo que a un relay. Si se desea hacer imagen de las cuentas para cada servidor en cada servidor (cosa no recomendable) puede utilizarse para sustituir NFS el sistema OpenAFS que hace espejos y cache. Se hablar a m as acerca de este tema en la implementaci on del servidor de correo postx/courier.

7.7.3.

Entorno Mixto

Un entorno mixto no es m as que la uni on de los esquemas anteriores. Primero se crea un sistema de correos distribuidos y cada servidor autoritativo se convierte en un cluster de correo. Esta es la opci on m as costosa, pero la que brinda mayor disponibilidad y rendimiento. Generalmente las grandes compa n as que brindan servicios de correo electr onico p ublico tienen una conguraci on de este estilo.

7.7.4.

Instalando Prerequisitos

Un servidor de correos por si mismo no resuelve los problemas de las organizaciones actuales debido a que han surgido nuevos aspectos a tener en cuenta, como son los ataques de Virus y los Correos SPAM. Por tanto, vamos a ver como instalar y congurar junto a Postx ltros SPAM y Software Anti-Virus. Veamos el software a utilizar:

84

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

Como ltro SPAM, puede utilizarse Spamd y/o SpamAssasin. Como Anti-Virus, puede utilizarse Kaspersky, NOD32, F-Secure sin embargo estos son Anti-Virus comerciales. Existe una variante libre: Clamav. Ahora, estos son programas separados que no se integran entre ellos, ni siquiera se integran a Postx por lo cual hay que buscar una interfase entre ellos y el MTA. Esta interfase se llama AMAVIS. Amavis es un programilla escrito en Perl, que adem as de las opciones y ltros que brinda es capaz de utilizar simultaneamente todos estos ltros Spam y Anti-Virus y se integra con Postx. Y digo simultanemamente ya que si se desea puede tenerse tres Anti-Virus y dos ltros Spam trabajando en conjunto y revisando un mismo correo. Esto es una buena pr actica si se tienen los sucientes recursos de hardware ya que sabemos que los tiempos de actualizaci on de los anti-virus var an seg un el proveedor y pr actiamente se ha comprobado que unas versiones cazan virus que otras no detectan y as . Ahora, el orden de instalaci on puede variar, con la u nica excepci on que AMAVIS tiene que obligatoriamente ser el u ltimo en instalar ya que el Script de instalaci on (al menos el que viene con los Ports de FreeBSD) detecta los ltros y antivirus instalados en el sistema y genera un chero precongurado para ellos, y esto facilita mucho las cosas ya que en otro caso habr a que incluirlos manualmente. Entonces, escoja usted los ltros y anti-virus que va a utilizar e inst alelos. Siempre utilice los Ports de FreeBSD para que la instalaci on quede registrada en la base de datos del sistema. No se explicar a como instalar los ltros y/o antivirus debido a la variedad existente, solo nos dedicaremos a instalar/congurar Amavis+Postx. Como de costumbre, utilicemos los Ports para instalar amavis: #portinstall amavisd-new Luego agregue la l nea siguiente al chero /etc/rc.conf: amavisd_enable="YES" Hay dos versiones de amavis: amavisd y amavisd-new. La versi on que estamos utilizando es la nueva. Rem tase al sitio para ver las diferencias entre una y otra. El script de instalaci on detectar a el software a utilizar y generar a un chero de conguraci on en /usr/local/etc/amavisd.conf. Este chero es considerablemente grande pero lo vale ya que pueden congurarse desde que expresi on regular (nombre del adjunto) a bloquear hasta los motores de b usqueda de virus a utilizar as como el comportamiento general de la aplicaci on. Otra caracter stica fundamental del Amavis es que la comunicaci on con Postx se efect ua v a SMTP, permitiendo as tener un Servidor de Revisi on de Correos separado del o de los MTA. El funcionamiento es simple: Un correo llega al MTA (Puerto 25), este se lo env a al Servidor Amavis (Puerto 10024) que revisa el correo y en dependencia de la conguraci on se le env a al Postx (Puerto 10025) y entonces es Entregado a su destinatario. Note que Postx escucha por dos puertos 25 y 10025. El puerto 10025 debe ser solo accedido por el servidor Amavis ya que Postx va a conar en todo lo que entre por esta v a. Veamos ahora algunas entradas del chero de conguraci on del Amavis: # Dominio de Correos Predeterminado $mydomain = bsdland.com;

7.7. CONFIGURANDO MTA: POSTFIX

85

# Definici on de la Red Local @mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10 192.168.0.0/24); # Acci on a Tomar en dependencia del resultado del inspector Amavis $final_virus_destiny = D_DISCARD; # Eliminaci on Silenciosa si se encuentra un Virus $final_banned_destiny = D_REJECT; # Si el destino est a prohibido no aceptar el correo $final_spam_destiny = D_DISCARD; # Eliminaci on Silenciosa si es correo Spam $final_bad_header_destiny = D_PASS; # Permitir correos con encabezados incorrectos # Nombre del Servidor $myhostname = server01.bsdland.cu; # Luego de una revisi on se debe enviar denuevo al servidor Postfix $notify_method = smtp:[127.0.0.1]:10025; $forward_method = smtp:[127.0.0.1]:10025; # Puerto escucha para el Amavisd $inet_socket_port = 10024; # listen on this local TCP port(s) (see $protocol) Existen muchas m as opciones que usted debe congurar, como por ejemplo las extensiones de los adjuntos que desea bloquear o que nivel de Spam (Numero con formato X.X que devuelve el SpamAssasin) que desea considerar como Spam Verdadero. El chero amavisd.conf esta comentariado y es relativamente sencillo de entender. Es necesario que los puertos 10024 y 10025 est en protegidos por el Firewall.

7.7.5.

Organizaci on y Esquema de Directorio

Antes de instalar y congurar Postx veamos dos aspectos fundamentales: 1. 2. Como almacenar los correos del usuario El patr on de un usuario en el directorio

Existen varios formatos para almacenar el buz on de correos del usuarios. Los dos m as conocidos son MAILBOX y MAILDIR. En esta gu a nos iremos por MAILDIR debido a la integraci on con Postx y con Courier-Imap (Servidor POP3/IMAP) y las facilidades que le brinda al protocolo IMAP: denir cuotas, atributos crear personalizados y adicionar carpetas de usuario entre otras. Ya tenemos el C omo pero tambi en es necesario denir donde se va a almacenar el buz on. De manera predeterminada este se localiza en [homedir]/Maildir/ donde [homedir] es el directorio home del usuario. Sin embargo, vamos a seguir otro patr on: /[root_path]/[server]/[user] Ejemplo (Buz on de Alex):

86

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

/usr/home/maildirs/mx1.bsdland.com/alex/Maildir Este patr on viene pensado para un cluster distribuido. Supongamos que tenemos dos servidores (mx1 y mx2 para abreviar) y que cada uno utiliza el patr on anteriormente denido. Supongamos que alex pertenece a mx1 y juan pertenece a mx2 y que ambos servidores adem as del MTA tienen instalado el servicio POP3/IMAP (Courier). Que pasar a si el usuario juan accede al servidor mx1 buscando su buz on? Evidentemente esto dar a error ya que la ruta /usr/home/maildirs/mx2.bsdland.com/juan/M aildir no existe en el servidor mx1, sin embargo si montamos en mx1 con NFS la ruta /usr/home/maildirs/mx2.bsdland.com entonces mx1 har a referencia a mx2 y el usuario juan pudiese acceder a su buz on desde cualquiera de los servidores sin importar donde f sicamente se encuentra su buz on. Resumiendo, el homedir del usuario quedar a como: /usr/home/maildirs/[server ]/[usuario] y la carpeta Maildir seguir a de manera predeterminada en [homedir ]/M aildir/. Ahora hay que tener otra consideraci on: los permisos. Al homedir tienen que tener acceso el propietario y postx, por lo que se recomienda congurar los propietarios como usuario:vmail y permitirles todos los permisos al grupo y al usuario. El grupo vmail es con el que postx arranca y trabaja. Ejemplo: #chown -R alex:vmail /usr/home/maildirs/mx1.bsdland.com/alex/Maildir #chmod -R 770 /usr/home/maildirs/mx1.bsdland.com/alex/Maildir Pasemos ahora al segundo punto: El esquema del directorio. Las entradas que hay que agregarle a cada usuario en el directorio para denirle un buz on de correos son las siguientes: # alex, Users, bsdland.com dn: uid=alex,ou=Users,dc=bsdland,dc=com maildrop: alex@mx1.bsdland.com mail: alex@bsdland.com mailbox: ./Maildir/ quota: 25000000 homeDirectory: /usr/home/maildirs/mx1.bsdland.cu/alex objectClass: posixAccount objectClass: CourierMailAccount maildrop: Direcci on Autoritativa para Alex mail: Grupo de direcciones virtuales para Alex mailbox: Es siempre ./Maildir/ quota: Dene la cuota en Bytes del buz on (-1 desactiva la cuenta) homeDirectory: Homedir del usuario. Sigue el patr on anteriormente expuesto. Note que estas son las entradas adicionales para alex, y digo adicionales ya que se mantienen las entradas denidas en los cap tulos anteriores (uid, cn, userPassword, etc). Adicionalmente podr an agregarse dos entradas m as: mailaccess y maildest para limitar el env o y recibo de correos por diversos criterios. Este tema se tocar a cuando se explique el chero de conguraci on de Postx.

7.7. CONFIGURANDO MTA: POSTFIX

87

7.7.6.

Postx

Para instalar postx simplemente utilizamos una vez m as los ports: #portinstall postfix Luego agregue la l nea siguiente al chero /etc/rc.conf: postfix_enable="YES" En los Ports existen tres versiones de postx: 2.1, 2.2 y current. Las versiones 2.x son versiones estables que no van a cambiar a menos que se encuentren errores de seguridad. La versi on current est a en constante cambio y puede que no sea lo sucientemente estable para su organizaci on. Usted decide cual instalar. En las opciones adicionales de instalaci on de Postx hay que seleccionar instalar el VDA (Virtual Delivery Agent) y la compatibilidad con LDAP. Luego de instalar se crear a la carpeta /usr/local/etc/postf ix donde se almacenar an diversos cheros de conguraci on donde los dos m as importantes son: master.cf - Dene los servidores virtuales, puertos a escuchar y servicios de postx en general. main.cf - Fichero de conguraci on principal. Veamos el chero master.cf y publiquemos el servidor SMTP virtual por el puerto 10025 para la retroalimentaci on con Amavis: # # Postfix master process configuration file. For details on the format # of the file, see the Postfix master(5) manual page. # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n n smtpd #submission inet n n smtpd # -o smtpd_enforce_tls=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #smtps inet n n smtpd # -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject 628 inet n n qmqpd pickup fifo n n 60 1 pickup cleanup unix n n 0 cleanup qmgr fifo n n 300 1 qmgr #qmgr fifo n n 300 1 oqmgr

88

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

tlsmgr unix n 1000? 1 tlsmgr rewrite unix n trivial-rewrite bounce unix n 0 bounce defer unix n 0 bounce trace unix n 0 bounce verify unix n 1 verify flush unix n n 1000? 0 flush proxymap unix n proxymap smtp unix n smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix n smtp -o fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n n showq error unix n error discard unix n discard local unix n n local virtual unix n n virtual lmtp unix n lmtp anvil unix n 1 anvil scache unix n 1 scache # # ==================================================================== # Interfaces to non-Postfix software. Be sure to examine the manual # pages of the non-Postfix software to find out what options it wants. # # Many of the following services use the Postfix pipe(8) delivery # agent. See the pipe(8) man page for information about ${recipient} # and other message envelope options. # ==================================================================== # # maildrop. See the Postfix MAILDROP_README file for details. # Also specify in main.cf: maildrop_destination_recipient_limit=1 # maildrop unix n n pipe flags=DRhu user=vmail group=vmail argv=/usr/local/bin/maildrop -d ${recipient} # # The Cyrus deliver program has changed incompatibly, multiple times. # old-cyrus unix n n pipe flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user} # Cyrus 2.1.5 (Amos Gouaux) # Also specify in main.cf: cyrus_destination_recipient_limit=1 cyrus unix n n pipe user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} #

7.7. CONFIGURANDO MTA: POSTFIX

89

# See the Postfix UUCP_README file for configuration details. # uucp unix n n pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) # # Other external delivery methods. # ifmail unix n n pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix n n pipe flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient smtp-amavis unix y 2 smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes 127.0.0.1:10025 inet n y smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtp_send_xforward_command=yes -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes A partir de la l nea smtp-amavis unix... est a la conguraci on que hemos agregado, el contenido anterior a esta l nea viene predeterminado. Note que hemos publicado un servidor virtual SMTP (smtpd) que escucha en 127.0.0.1:10025 y que solo acepta correos desde 127.0.0.0/8. Esto es as ya que vamos a suponer que tenemos el Amavis y el Postx en el mismo servidor. Luego habr a que congurar el chero main.cf que alberga la conguraci on principal del postx. Para una mejor comprensi on dividiremos el mismo en secciones que explicaremos por separado: ################################################################# # Configurationes Generales # ################################################################# # Camino hacia varias utilidades/directorios queue_directory = /var/spool/postfix command_directory = /usr/local/sbin daemon_directory = /usr/local/libexec/postfix sendmail_path = /usr/local/sbin/sendmail newaliases_path = /usr/local/bin/newaliases manpage_directory = /usr/local/man

90

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

sample_directory = /usr/local/etc/postfix mailq_path = /usr/local/bin/mailq html_directory = no readme_directory = no # Propietario del SMTPD mail_owner = postfix setguid_group = postdrop # Servidor y Dominio Predeterminado de Correo myhostname = mx1.bsdland.com mydomain = bsdland.com myorigin = $myhostname smtpd_banner = $myhostname ESMTP $mail_name (BSDLAND) # Interfases donde escuchar inet_interfaces = all # Redes Privadas mynetworks_style = subnet mynetworks = 192.168.0.0/24 unknown_local_recipient_reject_code = 550 unverified_recipient_reject_code = 450 # Mapas de alias est aticos bounce_template_file = /usr/local/etc/postfix/bounce.cf recipient_bcc_maps = hash:/usr/local/etc/postfix/recipient_bcc_maps sender_bcc_maps = hash:/usr/local/etc/postfix/sender_bcc_maps alias_maps = hash:/usr/local/etc/postfix/aliases alias_database = hash:/usr/local/etc/postfix/aliases in_flow_delay = 1s header_checks = regexp:/usr/local/etc/postfix/header_checks # L mites de Concurrencia local_destination_concurrency_limit = 50 default_destination_concurrency_limit = 50 # Opciones de DEBUG debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 # Definici on del Filtro de Contenidos (en nuestro caso smtp-amavis # que se ha definido anteriormente en el master.cf) content_filter=smtp-amavis:[127.0.0.1]:10024 Se han mostrado las opciones generales del servidor SMTP, sin embargo falta denir el comportamiento y lo mas importante, las opciones de seguridad del servidor: ################################################################# # Opciones de Seguridad # ################################################################# # Rechazar destinatarios y/o remitentes desconocidos para # los dominios conocidos

7.7. CONFIGURANDO MTA: POSTFIX

91

smtpd_reject_unlisted_recipient = yes smtpd_reject_unlisted_sender = yes # Rechazar dominio desconocido (Se efect ua una b usqueda DNS) #smtpd_helo_restrictions = reject_unknown_helo_hostname smtpd_helo_required = yes # Varias restricciones para el HELO smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit # Solo las redes privadas y/o los remitentes conocidos pueden # enviar correos (Se efect ua una b usqueda en el directorio) smtpd_client_restrictions = permit_mynetworks hash:/usr/local/etc/postfix/access, smtpd_sender_restrictions = permit_mynetworks hash:/usr/local/etc/postfix/access, reject_unknown_sender_domain,

# El formato de los destinatarios se verifica estrictamente, se filtra seg un # la configuraci on en el directorio LDAP y se verifica con el RBL para ver # si la direcci on est a bloqueada smtpd_recipient_restrictions = check_client_access hash:/usr/local/etc/postfix/amavis_internal check_sender_access ldap:solo_cuba_out_ldap, check_recipient_access ldap:solo_cuba_in_ldap, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_hostname, reject_rbl_client opm.blitzed.org, reject_rbl_client list.dsbl.org, reject_rbl_client bl.spamcop.net, reject_rbl_client sbl-xbl.spamhaus.orgpermit_sasl_authenticate smtpd_data_restrictions = reject_unauth_pipelining #smtpd_end_of_data_restrictions = check_policy_service unix:private/policy # Solo pueden transmitise hasta 2MB por mensaje. message_size_limit = 2097152

92

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

Note que en Postx se puede restringir el funcionamiento de los comandos HELO, MAIL FROM, MAIL TO as como vericar las direcciones y en general mantener la seguridad. Pero hay dos l neas que quiero resaltar: check_sender_access ldap:solo_cuba_out_ldap, check_recipient_access ldap:solo_cuba_in_ldap Suponga que usted brinda servicios de correo nacional e internacional. Los usuarios nacionales no pueden recibir o enviar correos a direcciones que no pertenezcan a su pa s (En mi caso *.cu). Las l neas anteriores fuerzan a que las direcciones se veriquen contra las pol ticas ticas se denen a continuaci on: solo cuba out ldap y solo cuba in ldap. Estas pol ################################################################# # Definicion de clases restrictivas # ################################################################# smtpd_restriction_classes = solo_cuba_in, solo_cuba_out, administradores solo_cuba_out = check_recipient_access hash:/usr/local/etc/postfix/cuba_domains, reject solo_cuba_in = check_sender_access hash:/usr/local/etc/postfix/cuba_domains, reject administradores = check_sender_access hash:/usr/local/etc/postfix/administradores, reject ################################################################# # Busqueda de Atributo Restrictivo mailaccess en LDAP # ################################################################# solo_cuba_in_ldap_server_host = ldap.bsdland.com solo_cuba_in_ldap_search_base = dc=bsdland,dc=com solo_cuba_in_ldap_query_filter = (&(mail=%s)(objectClass=mailUser)) solo_cuba_in_ldap_result_attribute = mailaccess solo_cuba_in_ldap_scope = sub solo_cuba_in_ldap_cache = yes solo_cuba_in_ldap_bind = no solo_cuba_in_ldap_version = 3 ################################################################# # Busqueda de Atributo Restrictivo maildest en LDAP # ################################################################# solo_cuba_out_ldap_server_host = ldap.bsdland.com solo_cuba_out_ldap_search_base = dc=bsdland,dc=com solo_cuba_out_ldap_query_filter = (&(mail=%s)(objectClass=mailUser)) solo_cuba_out_ldap_result_attribute = maildest solo_cuba_out_ldap_scope = sub solo_cuba_out_ldap_cache = yes solo_cuba_out_ldap_bind = no solo_cuba_out_ldap_version = 3 Las pol ticas solo cuba out ldap y solo cuba in ldap solo aceptan direcciones email denidas en la tabla hash /usr/local/etc/postf ix/cuba domains. La tabla hash cuba domains tiene el siguiente formato: cu OK

7.7. CONFIGURANDO MTA: POSTFIX

93

En esta tabla se denen dominios de correo. En nuestro caso denimos el dominio de primer nivel cu. Esto garantiza que cualquier dominio de nivel superior asociado a cu sea vericado como v alido. Pero, c omo restringimos a un usuario espec co? Pues utilizando los atributos mailaccess y maildest y se los denimos a la cuenta del usuario en el directorio LDAP donde el valor sea el nombre de la clase restrictiva. Ejemplo: mailaccess: solo_cuba_in maildest: solo_cuba_out En este ejemplo el usuario al que se le a nadan estos atributos solo podr a enviar y recibir correo desde y para Cuba. Veamos ahora el resto de la conguraci on necesaria para terminar de integrar a Postx con LDAP. ################################################################# # Busqueda de Direcciones Alternativas (usuarios) en LDAP # ################################################################# aliases_server_host = ldap.bsdland.com aliases_search_base = dc=bsdland,dc=com aliases_query_filter = (&(objectClass=mailUser)(mail=%s)) aliases_result_attribute = maildrop aliases_scope = sub aliases_cache = yes aliases_bind = no aliases_version = 3 ################################################################# # Busqueda de Direcciones Reales (usuarios) en LDAP # ################################################################# accounts_server_host = ldap.bsdland.com accounts_search_base = dc=bsdland,dc=com accounts_query_filter = (&(objectClass=mailUser)(maildrop=%s)(!(quota=-1))) accounts_result_attribute = uid accounts_result_format = %s/Maildir/ accounts_scope = sub accounts_cache = yes accounts_bind = no accounts_version = 3 ################################################################# # Busqueda de Atributo Restrictivo quota en LDAP # ################################################################# mailbox_quota_server_host = ldap.bsdland.com mailbox_quota_search_base = dc=bsdland,dc=com mailbox_quota_query_filter = (&(mail=%s)(objectClass=CourierMailAccount)) mailbox_quota_result_attribute = quota

94

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

mailbox_quota_scope = sub mailbox_quota_cache = yes mailbox_quota_bind = no mailbox_quota_version = 3 ################################################################# # Transporte de Distribucion de Correos # ################################################################# virtual_transport = virtual # El usuario 600 en este caso es vmail virtual_uid_maps = static:600 virtual_gid_maps = static:600 virtual_minimun_uid = 500 virtual_mailbox_base = /usr/home/maildirs/mx1.bsdland.com virtual_mailbox_maps = ldap:accounts # Dominios virtuales virtual_mailbox_domains = mx1.bsdland.com, bsdland.com virtual_alias_maps = ldap:aliases virtual_trash_count=yes virtual_trash_name=.Trash virtual_mailbox_limit_maps = ldap:mailbox_quota # L mite del Mailbox virtual_mailbox_limit = 25000000 virtual_maildir_extended = yes # Permitir crear el Maildir si no existe virtual_create_maildirsize = yes # Permitir hacer Relay a host privados relay_domains = localhost, $mynetworks Pues ya tenemos el primer MTA congurado. Para congurar MTA adicionales para el cluster distribuido se aplica la misma conguraci on variando solo los nombres mx1.bsdland.com por mx2.bsdland.com y as sucesivamente. Como siempre se recomienda leer el manpage o alguna documentaci on espec ca de Postx para ver ex actamente que hace cada elemento del chero de conguraci on.

7.8. CONFIGURANDO POP3/IMAP: COURIER

95

7.8.

Congurando POP3/IMAP: Courier

Para instalar courier, necesita tener instalados los siguientes paquetes: courier-authlib courier-authlib-ldap courier-imap Para ello utilice portinstall e inst alelos. Luego agregue las l neas siguientes al chero /etc/rc.conf: courier_authdaemond_enable="YES" courier_imap_imapd_enable="YES" courier_imap_pop3d_enable="YES" La conguraci on del Courier-Imap se encuentra en /usr/local/etc/courier, sin embargo, aqu no efectuaremos ning un cambio ya que la conguraci on predeterminada funciona. La conguraci on que modicaremos es el del mecanismo de validaci on (Authdaemond). Esta se encuentra en /usr/local/etc/authlib. El primer chero a modicar se llama authdaemonrc y la u nica l nea que debemos cambiar es la siguiente: authmodulelist="authldap" Esto le dice al demonio de validaci on que utilice el directorio LDAP para vericar el nombre de usuario y la contrase na as como extraer la informaci on de cuenta del usuario. El chero authldaprc almacena la conguraci on del m odulo del Authdaemond que se comunica con el directorio LDAP: LDAP_URI LDAP_PROTOCOL_VERSION LDAP_BASEDN LDAP_BINDDN LDAP_BINDPW LDAP_TIMEOUT LDAP_AUTHBIND LDAP_MAIL LDAP_FILTER LDAP_GLOB_UID LDAP_GLOB_GID LDAP_HOMEDIR LDAP_MAILROOT LDAP_MAILDIR LDAP_DEFAULTDELIVERY LDAP_MAILDIRQUOTA LDAP_FULLNAME LDAP_CLEARPW LDAP_CRYPTPW LDAP_DEREF LDAP_TLS ldap://ldap.bsdland.com 3 dc=bsdland,dc=com cn=administrator, dc=bsdland,dc=com xxx 5 1 uid (&(objectClass=CourierMailAccount)(!(quota=-1))) vmail vmail homeDirectory mailbox defaultDelivery quota cn clearPassword userPassword never 0

Note que la conguraci on de las cuotas, el mailbox, la direcci on del directorio home entre otras caracter sticas se obtienen del directorio.

96

Y CONFIGURACION DE SERVICIOS CAP ITULO 7. INSTALACION

Cap tulo 8

Si algo va mal
Cualquier cosa puede salir mal en el proceso de conguraci on del servidor y este quedar inaccesible. Hay tres razones por las cuales el servidor puede quedar inaccesible: El Kernel no carga La contrase na de root se ha olvidado Hay alg un error en la conguraci on de alg un servicio cr tico como OpenLDAP Para resolver los dos u ltimos problemas podemos iniciar en modo monousuario (Single User Mode) y acceder o editar la conguraci on. Para ello seleccione Single User Mode en el men u Boot de FreeBSD y luego cuando aparezca un shell ejecute: # mount -a Esto monta todos los discos con permisos de lectura escritura en los puntos de entradas denidos en el /etc/fstab. Entonces puede acceder a cualquier parte del sistema. Para cambiar la clave de root ejecute: # passwd root Si el servidor OpenLDAP es quien est a dando problemas y no permite que ning un usuario acceda al sistema, pues puede desactivarse esta opci on modicando el chero /etc/nsswitch.conf cambiando las siguientes l neas: passwd: files group: files shells: files Esto desactivar a la b usqueda de NSS sobre LDAP ya que solo permitir a buscar en cheros (/etc/passwd, /etc/grpups entre otros). Si el Kernel no carga siempre se puede cargar el sistema con el u ltimo Kernel congurado o con el kernel gen erico que viene con la instalaci on de FreeBSD. Para ello seleccione en el men u Boot Safe Mode y una vez cargado el sistema modique y recompile el Kernel con problemas.

97

98

CAP ITULO 8. SI ALGO VA MAL