DPD Servicios de red

De Gleducar, http://www.gleducar.org.ar

Superservidor xinetd, inetd y servicios relacionados

xinetd

Descripción

xinetd (eXtended InterNET Daemon), Demonio EXtendido de Internet, es un servicio ó demonio que usan gran parte de los sistemas Unix dedicado a administrar la conectividad basada en Internet. xinetd es una extensión más segura del servicio de Internet inetd.

xinetd contiene mecanismos de control de acceso como Wrappers TCP, ACLs, y la posibilidad de habilitar los Servicios_de_red basandose en el tiempo. Puede limitar la cantidad de servicios que se ejecutan, y contiene un sistema de protección contra escaneos de puertos.

Básicamente, este demonio nos permitira administrar los servicios relacionados con Internet, como FTP, Telnet u otros. Es una forma efectiva y centralizada de manejarlos.

Configuración

Archivos de configuración

Los archivos de configuración para xinetd son los siguientes:

• /etc/xinetd.conf — El archivo de configuración global de xinetd.
• /etc/xinetd.d/ — El directorio que contiene todos los archivos específicos al servicio.

Configurar /etc/xinetd.conf

El archivo /etc/xinetd.conf contiene parámetros de configuración generales los cuales afectan cada servicio bajo el control de xinetd. Se lee una vez cuando el servicio xinetd es iniciado, por esto, para que los cambios de la configuración tomen efecto, el administrador debe reiniciar el servicio xinetd. Abajo se muestra un ejemplo del archivo /etc/xinetd.conf:

defaults
{
       instances               = 60
       log_type                = SYSLOG authpriv
       log_on_success          = HOST PID
       log_on_failure          = HOST
       cps                     = 25 30
}
includedir /etc/xinetd.d

Estas líneas controlan los siguientes aspectos de xinetd:

• instances — Configura el máximo número de peticiones que xinetd puede manejar simultáneamente.
• log_type — Configura xinetd para usar la facilidad de registro authpriv, el cual escribe las entradas de registro al archivo /var/log/secure. Al agregar una directiva tal como FILE /var/log/xinetdlog aquí, creará un archivo de registro personalizado llamado xinetdlog en el directorio /var/log/.
• log_on_success — Configura xinetd a registrar si la conexión es exitosa. Por defecto, la dirección IP del host remoto y el ID del proceso del servidor procesando la petición son grabados.
• log_on_failure — Configura xinetd para registrar si hay una falla de conexión o si la conexión no es permitida.
• cps — Configura xinetd para no permitir más de 25 conexiones por segundo a cualquier servicio dado. Si se alcanza este límite, el servicio es retirado por 30 segundos.
• includedir /etc/xinetd.d/ — Incluye las opciones declaradas en los archivos de configuración específicos del servicio localizados en el directorio /etc/xinetd.d/.

El directorio /etc/xinetd.d/

El directorio /etc/xinetd.d/ contiene los archivos de configuración para cada servicio manejado por xinetd y los nombres de los archivos que se correlacionan con el servicio. Como sucede con xinetd.conf, este archivo sólo es leído cuando el servicio xinetd es arrancado. Para que los cambios tengan efecto, el administrador debe reiniciar el servicio xinetd.

El formato de los archivos en el directorio /etc/xinetd.d/ usan las mismas convenciones que /etc/xinetd.conf. La razón principal por la que la configuración para cada servicio es almacenada en un archivo separado es hacer más fácil la personalización y que sea menos probable afectar otros servicios.

Para tener una idea de cómo estos archivos están estructurados, considere el archivo /etc/xinetd.d/telnet:

service telnet
{
       flags           = REUSE
       socket_type     = stream
       wait            = no
       user            = root
       server          = /usr/sbin/in.telnetd
       log_on_failure  += USERID
       disable         = yes
}

Estas líneas controlan varios aspectos del servicio telnet:

• service — Define el nombre del servicio, usualmente uno listado en el archivo /etc/services.
• flags — Configura cualquier número de atributos para la conexión. REUSE instruye xinetd a reutilizar el socket para una conexión Telnet.
• socket_type — Configura el socket de red a escribir a stream.
• wait — Define si el servicio es de un sólo hilo (yes) o de múltiples hilos (no).
• user — Define bajo qué ID de usuario se ejecutará el proceso.
• server — Define el binario ejecutable a lanzar.
• log_on_failure — Define los parámetros de registro para log_on_failure además de aquellos ya definidos en xinetd.conf.
• disable — Define si el servicio está activo o no.

Configurar los demonios que utiliza xinetd

Antes de que puedas comprobar si funciona xinetd, tenes que hacer algo más, asegurarte de que los demonios que vayas a emplear los lanza xinetd y no están corriendo por sí mismos.

En el caso de sshd (el demonio para SSH, ver más adelante en este mismo DPD) se logra pasándole un parámetro adicional. "server_args = -i" le indica al demonio SSH que debe ejecutarse en modo inetd.

Apache, Proftpd y muchos otros probablemente, gestionan este punto desde su archivo de configuración. Busca la línea /etc/httpd.conf y/o /etc/proftpd.conf que dicen:

"ServerType standalone"

y cambia "standalone" por "inetd"

Ejecutá a continuación xinetd como root y asegurate de que funciona.

inetd

Descripción

inetd es un demonio presente en la mayoría de sistemas tipo Unix, conocido como el "Super Servidor de Internet", ya que gestiona las conexiones de varios demonios. La ejecución de una única instancia de inetd reduce la carga del sistema, en comparación con lo que significaría ejecutar cada uno de los demonios que gestiona, de forma individual.

xinetd es un versión más avanzada de inetd. Debido a que muchas distribuciones de GNU/Linux y demás sistemas del tipo Unix aun lo implementan, es necesario conocer su existencia y su forma de operar.

Configuración

Los servicios de red que presta su máquina están descritos en /etc/inetd.conf (y en /etc/services los números de puertos). Por ejemplo, en /etc/inetd.conf podemos encontrar líneas con la siguiente estructura:

servicio socket protocolo concurrencia usuario programa

En un ejemplo del contenido de /etc/inetd.conf encontrariamos algo como esto:

pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
# imap stream tcp nowait root /usr/sbin/tcpd imapd

Veamos ahora cada campo en detalle:

• Servicio

Este campo indica el nombre del servicio asociado a la línea correspondiente de /etc/inetd.conf; el nombre ha de existir en /etc/services para ser considerado correcto, o en /etc/rpc si se trata de servicios basados en el RPC (Remote Procedure Call) de Sun Microsystems. En este último caso se ha de acompañar el nombre del servicio con el número de versión RPC, separando ambos con el carácter /.

• Socket

Aquí se indica el tipo de socket asociado a la conexión. Aunque dependiendo del clon de Unix utilizado existen una serie de identificadores válidos, lo normal es que asociado al protocolo TCP se utilicen sockets de tipo stream, mientras que si el protocolo es UDP el tipo del socket sea dgram (datagrama).

• Protocolo

El protocolo debe ser un protocolo definido en /etc/protocols, generalmente TCP o UDP. Si se trata de servicios RPC, de nuevo hay que indicarlo utilizando rpc antes del nombre del protocolo, separado de él por el carácter / al igual que sucedía con el nombre; por ejemplo, en este caso podríamos tener protocolos como rpc/tcp o rpc/udp.

• Concurrencia

El campo de concurrencia sólamente es aplicable a sockets de tipo datagrama (dgram); el resto de tipos han de contener una entrada nowait en este campo. Si el servidor que ha de atender la petición es multihilo (es decir, puede anteder varias peticiones simultáneamente), hemos de indicarle al sistema de red que libere el socket asociado a una conexión de forma que inetd pueda seguir aceptando peticiones en dicho socket; en este caso utilizaremos la opción nowait. Si por el contrario se trata de un servidor unihilo (acepta peticiones de forma secuencial, hasta que no finaliza con una no puede escuchar la siguiente) especificaremos wait.

• Usuario

En este campo se ha de indicar el nombre de usuario bajo cuya identidad se ha de ejecutar el programa que atiende cada servicio; esto es así para poder lanzar servidores sin que posean los privilegios del root, con lo que un posible error en su funcionamiento no tenga consecuencias excesivamente graves. Para el grupo, se asume el grupo primario del usuario especificado, aunque se puede indicar un grupo diferente indicándolo junto al nombre, separado de éste por un punto.

• Programa

Por último, en cada línea de /etc/inetd.conf hemos de indicar la ruta del programa encargado de servir cada petición que inetd recibe en un puerto determinado, junto a los argumentos de dicho programa. El servidor inetd es capaz de ofrecer pequeños servicios basado en TCP por sí mismo, sin necesidad de invocar a otros programas; ejemplos de este tipo de servicios son time, echo o chargen.

Agente de transferencia de correo (MTA)

Descripción

MTA es una sigla en inglés que significa Mail Transport Agent (Agente de Transporte de Correos), y también Message Transport Agent (Agente de Transporte de Mensajes).

En otras palabras, es el servidor de correo (SMTP) en sí y no la parte que usa el usuario para recuperar los mensajes que éste recibió.

El MTA, recibe los mensajes desde otro MTA (relaying), un MSA (Mail submission Agent) que toma por sí mismo el mensaje electrónico desde un MUA (Mail user agent), o recibe directamente el correo desde un MUA, actuando como un MSA. El MTA trabaja en trasfondo, mientras el usuario usualmente interactúa con el MUA.

Algunos de los más conocidos son Sendmail, Postfix, QMail, Exim.

En nuestro caso, emplearemos Sendmail y Postfix para explicar la configuración de un MTA a modo de ejemplos.

Información sobre Sendmail

El propósito principal de Sendmail, como cualquier otro MTA, es el de transferir correo de forma segura entre hosts, usualmente usando el protocolo SMTP. Sin embargo, Sendmail es altamente configurable, permitiendo el control sobre casi cada aspecto del manejo de correos, incluyendo el protocolo utilizado. Muchos administradores de sistemas seleccionan Sendmail como su MTA debido a su poder y escalabilidad.

Configuración de Sendmail

El archivo de configuración largo y detallado de Sendmail es /etc/mail/sendmail.cf. No es buena idea modificar este archivo sendmail.cf directamente. En vez de esto, para hacer cambios en la configuración, editamos el archivo /etc/mail/sendmail.mc, creando una copia de respaldo del original /etc/mail/sendmail.cf.

Varios archivos de configuración de Sendmail son instalados en el directorio /etc/mail/ incluyendo:

• access — Especifica los sistemas que pueden utilizar Sendmail para enviar correo saliente.
• domaintable — Le permite crear asignaciones de nombres de dominio.
• local-host-names — Especifica aliases para el host.
• mailertable — Especifica instrucciones para ignorar la ruta de determinados dominios.
• virtusertable — Le permite especificar una forma de alias para dominios específicos, permitiendo a múltiples dominios virtuales ser hospedados en una misma máquina.

Cuando se esté modificando el archivo de configuración de Sendmail, es mejor generar un archivo completamete nuevo /etc/mail/sendmail.cf en vez de modificar el existente.

Para añadir funcionalidad a Sendmail, modifique el archivo /etc/mail/sendmail.mc como usuario root. Cuando termine, utilice el procesador de macros m4 para generar un nuevo sendmail.cf ejecutando el comando siguiente:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Por defecto, el procesador de macros m4 se instala con Sendmail pero es parte del paquete m4.

Después de crear un archivo /etc/mail/sendmail.cf nuevo, reinicie Sedmail para que los cambios tomen efecto. La forma más fácil de hacer esto es ejecutando el comando siguiente:

• En Red Hat

/sbin/service sendmail restart

• En Debian

/etc/init.d/sendmail restart

Creación de máscaras

Una configuración común de Sendmail es tener una sola máquina actuando como el gateway de correo para todas las máquinas en la red. Por ejemplo, una compañía puede querer tener una máquina llamada mail.example.com que maneja todo su correo y asigna una dirección de retorno consistente para todo el correo saliente.

En esta situación, el servidor Sendmail debe enmascarar los nombres de las máquinas en la red de la compañía para que la dirección de retorno sea user@example.com en vez de user@host.example.com.

Para hacer esto, añadimos las líneas siguientes /etc/mail/sendmail.mc:

FEATURE(always_add_domain)dnl
FEATURE(`masquerade_entire_domain')
FEATURE(`masquerade_envelope')
FEATURE(`allmasquerade')
MASQUERADE_AS(`bigcorp.com.')
MASQUERADE_DOMAIN(`bigcorp.com.')
MASQUERADE_AS(bigcorp.com)

Después de generar un nuevo sendmail.cf usando m4, esta configuración hará que todo el correo dentro de la red aparezca como que si se hubiese enviado desde bigcorp.com.

Configurar Sendmail contra el SPAM

El correo basura se puede definir como correo no deseado e innecesario recibido por un usuario que nunca solicitó tal comunicación. Es un abuso costoso y molesto de las comunicaciones de Internet estándar.

Sendmail hace relativamente fácil bloquear nuevas técnicas de difusión de correo basura. Hasta bloquea por defecto muchos de los métodos comunes de difusión de correo basura.

Por ejemplo, el reenvío de mensajes SMTP, también conocido como relaying, está por defecto desactivado en Sendmail desde la versión 8.9. Antes de que se produjese este cambio, Sendmail indicaba al host (x.edu) que aceptara mensajes desde un ente (y.com) y que los enviara a un ente diferente (z.net). Ahora, sin embargo, se debe configurar Sendmail para permitir que cualquier dominio transmita correo a través del servidor. Para configurar dominios de transmisión, modifique el archivo /etc/mail/relay-domains y reinicie Sendmail.

Sin embargo, en muchas ocasiones, los usuarios reciben bombardeos de correo basura de otros servidores a través de Internet. En estos casos, puede utilizar las funciones de control de acceso de Sendmail que están disponibles en el archivo /etc/mail/access para prevenir conexiones desde host indeseados. El ejemplo siguiente ilustra como este archivo puede ser usado para bloquear y también para permitir el acceso al servidor Sendmail:

badspammer.com       ERROR:550 "No vuelvas a enviarme SPAM!"
tux.badspammer.com   OK
10.0                 RELAY

Este ejemplo indica que cualquier correo que se envia desde badspammer.com se bloqueará con un código de error 550 RFC-821, con un mensaje para el emisor. Los correos enviados desde el sub-dominio tux.badspammer.com, seran aceptados. La última línea muestra que cualquier correo enviado desde la red 10.0.*.* se puede transmitir a través del servidor de correo.

Debido a que /etc/mail/access.db es una base de datos, use makemap para activar los cambios. Haga esto usando el comando siguiente como root:

makemap hash /etc/mail/access < /etc/mail/access 

Para más información y ejemplos sobre Sendmail consulte /usr/share/sendmail-cf/README.

Información sobre Postfix

Postfix utiliza un diseño modular para mejorar la seguridad, en el que los procesos pequeños con privilegios limitados son lanzados por un demonio master. Los procesos más pequeños, con menos privilegios, realizan tareas muy específicas relacionada con las diferentes etapas de la entrega de correos y se ejecutan en un ambiente de cambio de root para limitar los efectos de ataques.

Configurar Postfix para que acepte conexiones de red desde otros hosts además de la computadora local sólo toma unos pequeños cambios en su archivo de configuración. Para aquellos con necesidades más complejas, Postfix ofrece una variedad de opciones de configuración, así como también complementos de terceros que lo hacen un MTA rico en funcionalidades.

Los archivos de configuración de Postfix son legibles y aceptan hasta 250 directrices. A diferencia de Sendmail, no se requiere procesar ninguna macro para que los cambios tomen efecto y la mayoría de las opciones usadas frecuentemente se describen en archivos muy bien comentados.

Configuración de Postfix

Postfix almacena sus archivos de configuración en el directorio /etc/postfix/. A continuación se muestra una lista de los archivos usados más a menudo:

• access — Utilizado para el control de acceso, este archivo especifica los sistemas que pueden conectarse a Postfix.
• aliases — Una lista configurable que el protocolo de correo requiere.
• main.cf — El archivo global de configuración de Postfix. La mayoría de las opciones de configuración se especifican en este archivo.
• master.cf — Especifica la forma en que Postfix interactua con diferentes procesos para lograr la entrega de correo.
• transport — Hace las correspondencias entre direcciones de correo electrónico y los hosts de transmisiones.

A veces, puede ser necesario reiniciar el servicio postfix cuando se cambien algunas opciones dentro de archivos en el directorio /etc/postfix/ para que se apliquen los cambios. La forma más fácil de lograr esto es a través del comando:

• En Red Hat

/sbin/service postfix restart

• En Debian

/etc/init.d/postfix restart

Por defecto, no acepta conexiones de red desde ningún otro host excepto la máquina local. Ejecute los pasos siguientes como superusuario para activar la entrega de correo desde otros hosts en la red:

1. Modifique el archivo /etc/postfix/main.cf con un editor de texto, tal como vi.
2. Quite el comentario de la línea mydomain removiendo la almohadilla (#) y reemplace domain.tld con el dominio que está sirviendo el servidor de correo, tal como example.com.
3. Quite el comentario de la línea myorigin = $mydomain.
4. Elimine el comentario de la línea myhostname y reemplace host.domain.tld con el nombre de host para la máquina.
5. Elimine el comentario de la línea mydestination = $myhostname, localhost.$mydomain.
6. Elimine el comentario de la línea mynetworks y sustituya 168.100.189.0/28 con un valor de red válido para que los hosts se puedan conectar al servidor.
7. Remueva el comentario de la línea inet_interfaces = all.
8. Reinicie el servicio postfix.

Luego de completar estos pasos, el host acepta correos externos.

Lo básico de Apache

Descripción

El servidor HTTP Apache es un software (libre) servidor HTTP de código abierto para plataformas Unix (BSD, GNU/Linux, etcétera), Windows y otras, que implementa el protocolo HTTP/1.1 y la noción de sitio virtual. Cuando comenzó su desarrollo en 1995 se basó inicialmente en código del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo. Su nombre se debe a que originalmente Apache consistía solamente en un conjunto de parches a aplicar al servidor de NCSA. Era, en inglés, a patchy server (un servidor "parcheado").

El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software Foundation.

Apache presenta entre otras características mensajes de error altamente configurables, bases de datos de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz gráfica que ayude en su configuración.

Apache tiene amplia aceptación en la red: en el 2005, Apache es el servidor HTTP más usado, siendo el servidor HTTP del 70% de los sitios web en el mundo y creciendo aún su cuota de mercado (estadísticas históricas y de uso diario proporcionadas por Netcraft).

Configuración

El servidor lee la información de tres ficheros con directivas de configuración. Cualquier directiva puede aparecer en cualquiera de estos ficheros:

• httpd.conf:

Contiene las directivas que controlan el funcionamiento del demonio servidor (httpd).

• srm.conf:

contiene las directivas que controlan la especificación de documentos que el servidor proporciona a los clientes.

• access.conf:

Contiene directivas que controlan el acceso a los documentos

Además, el servidor también leerá un fichero conteniendo los tipos mime de los documentos. Por defecto el fichero será conf/mime.types.

Sin embargo, la tendencia es que solo se utilice como fichero principal del servidor Web a httpd.conf, agrupando las directivas de configuración en tres secciones. Veamos cada una de ellas en detalle.

Configuración de httpd.conf (o apache2.conf)

Sección Global Enviroment

En esta sección se definen las directivas que controlan el funcionamiento general de Apache, como pueden ser el número de peticiones concurrentes que puede manejar, donde puede encontrar los ficheros de configuración...

• ServerType { standalone | inetd }:

El servidor se lanza bien como un servicio independiente que está corriendo como un demonio esperando alguna petición (standalone) o bien es lanzado por el superservidor de internet (inetd) como un servicio bajo demanda.

• ServerRoot:

Define el directorio donde reside toda la información de configuración y registro que necesita el servidor.

• PidFile:

Indica el fichero en el cual el servidor registrará el identificador de proceso con el que se lanza.

• ScoreBoardFile:

Fichero utilizado para almacenar información interna del proceso servidor. Se requiere para algunas arquitecturas para comunicar entre los procesos hijos y el padre.

• Timeout:

Número de segundos tras los cuales el servidor cierra la conexión.

• KeepAlive:

Si se permiten o no conexiones persistentes.

• MaxKeepAliveRequest:

El número máximo de peticiones permitidas durante una conexión persistente.

• MinSpareServers

Define el número de procesos servidores hijo desocupados que no atienden una petición.

• MaxSpareServers:

Define el nº máximo de procesos servidor hijo desocupados que no manejan una petición. Si existieran mas de lo que define la directiva, el proceso padre mataría los procesos que exceden.

• StartServers:

Número de procesos servidor hijo que serán creados cuando arranca Apache por primera vez.

• Maxclients:

Define el número de peticiones simultáneas que apache puede soportar. Como máximo se crean este nº de procesos servidores hijo.

• MaxRequestPerChild:

Define el nº de peticiones que cada proceso hijo tiene permitido procesar antes de morir.

• ThreadsPerChild:

Nº de hilos concurrentes que el servidor permitirá utilizar. Este valor representa el nº máximo de conexiones que el servidor puede manejar a la vez.

• Listen:

Esta directiva instruye al servidor Apache para que escuche en mas de una dirección IP o en mas de un puerto.

• LoadModule:

Esta directiva enlaza dentro del servidor la librería o fichero objeto nombrado cuando se arranca el servidor y añade la estructura del modulo a la lista de módulos activos.

Sección Main Server

Estas directivas definen los parámetros del servidor principal, el cual responde a las peticiones que no son manejadas por un host virtual. También proporciona parámetros por defecto para todos los hosts virtuales.

• Port:

Define el puerto en el cual escucha el servidor (0 - 65535). Hay que tener en cuenta la relación que tiene esta directiva con el fichero /etc/services y que algunos puertos, especialmente los situados por debajo del 1024, están reservados para protocolos específicos. El puerto estándar para el protocolo HTTP es el 80.

• User/Group:

Definen el usuario y el grupo con el que el servidor contestará las peticiones. Para poder utilizar esta directiva, el servidor standalone debe ejecutarse inicialmente como usuario root. El usuario no debería poseer privilegios que otorguen acceso a ficheros que no deseemos.

• ServerAdmin:

Define la dirección de correo que el servidor incluirá en cualquier mensaje de error que devuelva al cliente.

• ServerName:

Define el nombre de host del servidor. Se suele utilizar cuando se crean redirecciones. Sino se define el nombre de servidor, intentará deducirlo a través de su dirección IP.

• DocumentRoot:

Define el directorio desde el cual el servidor servirá los documentos. A menos que la URL solicitada coincida con una directiva Alias, el servidor añadirá el PATH a la URL.

• Directory:

<Directory></Directory> se utilizan para encerrar un grupo de directivas que se aplicarán al directorio en cuestión y sus sub-directorios. El parámetro directorio, puede ser una trayectoria completa o un metacaracter.

• Options: [+|-] opcion :

Controla que características están disponibles para un directorio en particular. La opción se puede definir a None, de forma que ninguna característica extra se habilita o a All de forma que todas se habilitan menos MultiViews. Otras características extra son: ExecCGI , FollowSymLinks, Includes, IncludesNOEXEC, Indexes, MultiViews, SymLinksIfOwnerMatch.

• AllowOverride override:

Cuando el servidor encuentra un fichero .htaccess (definido por la directiva AccessFileName) necesita conocer que directivas declaradas en este fichero pueden sobreescribir información de acceso.

El parámetro override puede ser definido a None y en tal caso el servidor no leerá el fichero o puede ser definido a All, de forma que permitirá todas las directivas. El parámetro override también puede ser definido a: AuthConfig, FileInfo, Indexes, Limit, Options.

• UserDir directorio :

Define el nombre del directorio que será añadido al directorio HOME del usuario si se recibe una petición ~usuario.

• DirectoyIndex fichero :

Nombre/s del fichero/s a usar como página de inicio de un directorio.

• AccessFileName fichero :

El nombre del fichero a buscar en cada directorio para información de control de acceso.

• Alias url directorio :

Esta directiva permite que los documentos sean almacenados en un sistema de ficheros diferente al definido por la directiva DocumentRoot.

• Location url :

La directiva proporciona control de acceso por URL. Es similar a la directiva Directory.

• ScriptAlias url directorio :

Tiene el mismo comportamiento que la directiva Alias, excepto que además define el directorio para que pueda contener scripts CGI.

Dominios Virtuales

Buscamos la dentro de httpd.conf el siguiente termino;

NameVirtualHost *:80

Esto hará que todas las peticiones que se le hagan a Apache sean escuchadas por el puerto 80 venga de cualquier IP o Host.

Pasamos a la parte de las definiciones de los vitual hosts en nuestro apache. Para eso dejare acá un ejemplo de configuración que pueden tomar de ejemplo.

Dominios Completos

<VirtualHost *:80>
ServerName www.xtech.com.ar
ServerAdmin admin@xtech.com.ar
DocumentRoot /var/www/html/tech
VirtualDocumentRoot /var/www/html/xtech
ErrorLog logs/xtech-error.log
CustomLog logs/xtech-access.log common
<Directory "/var/www/html/xtech">
Options Indexes FollowSymLinks
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Subdominios

<VirtualHost *:80>
ServerName curso.xtech.com.ar
ServerAlias curso.xtech.com.ar
ServerAdmin admin@xtech.com.ar
DocumentRoot /var/www/html/curso
VirtualDocumentRoot /var/www/html/curso
ErrorLog logs/curso-error.log
CustomLog logs/curso-access.log common
</VirtualHost> 

Lo hecho arriba lo vamos a explicar acá:

# Se crea un genérico
# Se le asigna una dirección ServerName subdominio xtech.com.ar
# Se le añade un alias (por si quieres que dos direcciones apunten al mismo sitio): ServerAlias
  subdominio.lo_que_decees.com
# Se le indica donde estará el documento raíz: DocumentRoot /var/www/html/curso
# Definimos un VirtualDocumentetRoot para que el apache lo lea sin modo a equivocarse VirtualDocumentRoot
  /var/www/html/curso
# Y configuramos las direcciones donde estarán los logs de los acceso y errores.

Módulos

Los múdulos de Apache permiten darle funcionalidades y trabajar con otros servicios y compatibilizar con distintas tecnologias. Para la configuración de los módulos que correra Apache, tienen que fijarse en el listado de módulos (los que comienzan con LoadModule) estén siendo cargados los de php y de mysql, en caso que no sea así los incluimos así:

LoadModule php_module modules/mod_php.so
LoadModule mysql_module modules/mod_mysql.so

La lista completa de módulos para Apache puede verse a a continuación:

• mod_ssl - Comunicaciones Seguras vía TLS.
• mod_rewrite - reescritura de direcciones servidas (generalmente utilizado para transformar páginas dinámicas como php en páginas estáticas html para así engañar a los navegantes o a los motores de búsqueda en cuanto a como fueron desarrolladas estas páginas).
• mod_dav - Soporte del protocolo WebDAV (RFC 2518).
• mod_deflate - Compresión transparente con el algoritmo Deflación (algoritmo)deflate del contenido enviado al cliente.
• mod_auth_ldap - Permite autentificar usuarios contra un servidor LDAP.
• mod_proxy_ajp - Conector para enlazar con el servidor Jakarta Tomcat de páginas dinámicas en Java (servlets y JSP).

El servidor de base puede ser extendido con la inclusión de módulos externos entre los cuales se encuentran:

• mod_perl - Páginas dinámicas en Perl.
• mod_php - Páginas dinámicas en PHP.
• mod_python - Páginas dinámicas en Python.
• mod_rexx - Páginas dinámicas en REXX y Object REXX.
• mod_ruby - Páginas dinámicas en Ruby.
• mod_aspdotnet - Páginas dinámicas en .NET_de_Microsoft.
• mod_security - Filtrado a nivel de aplicación, para seguridad.

Invocación del servicio de apache

Para poner en marcha apache debemos invocar el servicio para poner en marcha el demonio. Para que en el caso que Apache no se pueda iniciar porqué haya algún tipo de error, el sistema nos muestre dichos errores, debemos usar el comando apachectl, en el caso que no deseemos que se muestren los errores también podemos usar la directiva httpd.

Las dos directivas aceptan los parámetros start, stop y restart.

NFS

Descripción

El Network File System (Sistema de archivos de red), o NFS, es un sistema de archivos distribuido para un entorno de red de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales.

La utilización de NFS es ideal cuando contamos con una red compuesta por clientes que operan mediante GNU/Linux o sistemas del tipo Unix, ya que este sistema de archivos de red es el estándar en estos sistemas.

Configuración

NFS significa Sistema de Archivos en Red y es la forma de compartir ficheros entre máquinas como si estuviesen en su disco duro local. Linux puede ser tanto un serivdor NFS como un cliente NFS, que significa que puede exportar sistemas de archivos a otros sistemas y montar sistemas de archivos exportados de otras máquinas.

Exportar sistemas de archivos NFS

Primero vamos a compartir algunos directorios de nuestra PC, los vamos a "exportar".

El fichero que controla que sistema de archivos desea exportar es /etc/exports. Su formato es:

   directorio       nombre_del_host(opciones)

Las (opciones) son opcionales. Por ejemplo:

   /mnt/export     cardaci

permitiría a speedy.redhat.com montar /mnt/export, pero:

   /mnt/export     cardaci(ro)

permitiría al cliente cardaci montar /mnt/export de sólo-lectura (read-only).

Montar un sistema de archivos NFS

Use el comando mount para montar un sistema de archivos NFS de otra máquina:

mount gelbort:/mnt/export /mnt/local

En este comando, gelbort es el nombre del servidor de ficheros NFS, /mnt/export es el sistema de archivos que gelbort está exportando y /mnt/local es un directorio en mi máquina local donde queremos montar el sistema de archivos. Después de ejecutar el comando mount (y si tenemos los permisos apropiados de gelbort) podemos introducir el comando ls /mnt/local y obtener un listado de los ficheros de /mnt/export en gelbort.

Cada vez que cambie /etc/exports, necesita decirle a los demonios de NFS que lo examine para buscar la información nueva. Una manera simple de hacerlo es parar (stop) e inicar (start) los demonios:

   /etc/rc.d/init.d/nfs stop
   /etc/rc.d/init.d/nfs start

SAMBA

Descripción

Samba es una implementación libre del protocolo de archivos compartidos de Microsoft Windows (antiguamente llamado SMB, renombrado recientemente a CIFS) para sistemas de tipo UNIX.

De esta forma, es posible que ordenadores con Linux o Mac OS X se vean como servidores o actúen como clientes en redes de Windows. Samba también permite validar usuarios haciendo de Controlador Principal de Dominio (PDC), como miembro de dominio e incluso como un dominio Active Directory para redes basadas en Windows; aparte de ser capaz de servir colas de impresión, directorios compartidos y autenticar con su propio archivo de usuarios.

Configuración

Ejecutando los demonios

Los dos demonios de SMB son /usr/bin/smbd y /usr/sbin/nmbd.

Puedes ejecutar los demonios de Samba desde inetd o como procesos independientes . Si estás configurando un servidor de ficheros permanente, deberían ejecutarse desde inetd para que sean reejecutados si 'mueren'. Si solo quieres usar los servicios SMB de vez en cuando o como ayuda a la administración del sistema, puedes ejecutarlos con un script en /etc/rc.d/init.d o incluso a mano cuando los necesites.

Para ejecutar los demonios desde inetd, pon las siguientes líneas en el archivo de configuración, /etc/inetd.conf:

   # Servicios SAMBA NetBIOS (para compartición de ficheros e impresoras
    en PC)
   netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
   netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd

Entonces reejecuta inetd con el siguiente comando:

   kill -HUP 1

Para ejecutarlos desde los scripts de inicio del sistema, pon las siguientes líneas en /etc/rc.d/init.d/smb y hazle un enlace simbólico con los ficheros indicados en los comentarios:

   #!/bin/sh
   #
   # /etc/rc.d/init.d/smb - comienza y termina los servicios SMB.
   #
   # Se deben crear los siguientes ficheros como enlaces simbolicos a 
     este fichero:
   # symlinks: /etc/rc.d/rc1.d/K35smb  (Termina los servicios SMB al
     cerrar el sistema)
   #           /etc/rc.d/rc3.d/S91smb  (Comienza los servicios SMB en 
               modo multiusuario)
   #           /etc/rc.d/rc6.d/K35smb  (Termina los servicios SMB al 
               hacer un reboot)
   #

   # Libreria de funciones
   . /etc/rc.d/init.d/functions

   # Configuracion de red
   . /etc/sysconfig/network

   # Asegurarse que la red esta a punto
   [ ${NETWORKING} = "no" ] && exit 0

   # Comprobar como fuimos llamados
   case "$1" in
     empezar)
       echo -n "Poniendo en marcha los servicios SMB: "
       daemon smbd -D  
       daemon nmbd -D 
       echo
       touch /var/lock/subsys/smb
       ;;
     parar)
       echo -n "Terminando los servicios SMB: "
       killproc smbd
       killproc nmbd
       rm -f /var/lock/subsys/smb
       echo ""
       ;;
     *)
       echo "Modo de uso: smb {empezar|parar}"
       exit 1
   esac

Configurando /etc/samba/smb.conf

La primera etiqueta o más bien la mas importante es la etiqueta [global]. Cualquier texto que esté encerrado entre corchetes, significa el inicio de una estructura de configuraciones, y a su vez implica el fin de la estructura de configuraciones anterior.

La Etiqueta global, permite definir las opciones fijas que tiene para todas las máquinas por defecto en la red. Se compone de distintas etiquetas de menu. Estas son las más importantes:

workgroup = GRUPO-DE-TRABAJO

Esta opción nos presenta ante el servidor, para estar en un grupo dentro de la red.

netbios name = Mi-Linux

Esta etiqueta nos presentara como la computadora con el nombre Mi-Linux (es solo un ejemplo).

netbios aliases = Mi-Linux-2

Esta opción, nos presenta en la red con otro nombre además del que le hemos dado con la anterior, es decir en este caso estaremos como si fueramos 2 máquinas de la red distintas. Ovbiamente, esto no es obligatorio.

server string = Mi computador con Linux

Como lo dice su nombre, esta opción le dará una breve descripción a nuestra Máquina al presentarse dentro de la Red.

interfaces = eth0

La interfaz mediante la cual nos conectamos a la red, puede ser eth0 eth1, eth2... ppp0, etc.

encrypt passwords = No

Esta opción define si las contraseñas que envian las máquinas con Windows, para autentificarse en nuestro servidor Linux, deben ser encriptadas con los métodos de encriptación de Linux. Es recomendable dejar esta opción como no, si las máquinas están con Windows, pues la manera que tiene Windows, de encriptar las claves de los usuarios, no es la misma que la de Linux.

hosts allow = 192.168.0.0

nos permite definir a la red que tendrá acceso a nuestros directorios compartidos.En este caso definimos para

que los usuarios que provengan de cualquier dirección que empiece con 192.168.0, tenga acceso.

host deny = 192.168.0.33

Al cotrario de la opción anterior, ésta permite definir usuarios que quedan fuera de nuestro sistema compartido.

domain logons = Yes

Esta opción permite, en conjunto con las siguientes, a ser servidor de Dominio dentro de la red, es decir, los usuarios se identificarán en la máquina de nosotros y no en la máquina de cada uno. Si esta opción esta habilitada, entonces la opción domain masters, se activara por defecto.

log file = /var/log/samba.%m

Ubicación donde quedarán los logs, en este caso la extensión sera acompañada de la máquina desde la cual se hizo la conección.

max log size = 50

Tamaño máximo para los archivos de logs.

Existen muchas otras opciones, que no son relevantes dentro de la configuración a primer nivel, pero si son importantes para las configuraciones mas específicas y dedicadas.

La segunda sección consta de los directorios compartidos. Al igual que la etiqueta global, cada recurso compartido, debe estar encerrado por corchetes. pongamos un ejemplo básico y simple:

[homes]
   comment = Directorios de Usuarios
   read only = No
   browseable = No

Este recurso compartido, que es muy recomendable, crea el recurso del direcotio home del usuario que se esta conectando. Es decir, cuando el cliente se conecte (Supongamos usuario: "Invitado"), este verá el recurso compartido "Invitado" y no "Home".

Las opciones read-only = No hacen que el directorio tenga acceso de tanto escritura como de lectura para el usuario dueño del Recurso. La opción Browseable = No, hace imposible que el usuario tenga acceso o visión a los recursos compartidos del resto de los usuarios. La linea comment, hará de Información acerca del recurso compartido.

Este último recurso compartido, es específico sobre los directorios de usuario, Nosotros podemos incluir una variedad de recursos, asignados a la ruta que nosotros queramos.

Tip: no darle acceso a nadie a /proc y /dev. Creo que esta de más explicarlo.

Creemos otro recuros:

[Cdrom]
  comment = Unidad de Cdrom
  path = /mnt/cdrom
  users = JoTe Invitado Scrub Daniela
  writeable = yes    hide dot files = yes

La línea Path especifica la ruta donde se encuentra el recurso a compartir.

Por otra parte, la línea users, le permitirá el acceso a los usuarios mencionados en la misma.

La línea writeable, le da la opción de que los usuarios puedan escribir dentro de ese recurso.

La opción hide dot files, es muy recomendable para los usuarios inexpertos, o que desconocen el sistema de archivos de linux, pues en Linux los archivos "ocultos" comienzan con un punto al incio.

La opción guest ok nos permite que usuarios no reconocidos en nuestro sistema, tengan acceso al recurso compartido. Es decir, no le solicitará una clave para aceder al recurso.

Estas son algunas de las opciones que permiten el acceso a nuestros recursos compartidos. La tercera sección es igual de simple que la anterior, y corresponde a la impresora [Printers], puede tener las mismas opciones pero además debe tener la opción: printeable = yes y la opción Browseable = no. La ruta por defecto de esta es path = /var/spool/samba.

Si quieres conocer todas las opciones que tiene samba, puedes ver la página man de ella (man smbd.conf).

Ahora que tienes creada la configuración de samba, debes ver si estan acivados en /etc/inetd:

netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd

La última opción es la creación de los usuarios. El usuario debe existir en la máquina como tal, despues de verificado, generamos el usuario para samba con el comando smbpasswd -a user.

La opcion -a crea al usuario dentro de los usuarios de samba, asi que se usa solo la primera vez.

Tip: crea usuarios solo en minúsculas, los usuarios con mayúsculas suelen tener problemas, pues Windows no distingue entre ambas.

Para montar un recurso compartido desde el Linux, podemos hacerlo con

mount -t smbfs \\host\recurso /path/to/recurso

Es recomendable agregar la máquina al /etc/hosts y llamar a la misma por su nombre y no por la ip, muchas veces se marean con los nombres mal asignados.

Para ver que recursos compartidos tiene una máquina, puedes usar el comando smbclient -L host Nos mostrara algo asi como lo siguiente:

Domain=[Mi-Grupo] OS=[Unix] Server=[Samba 2.2.0a]

       Sharename      Type      Comment
       ---------      ----      -------
       Mp3            Disk      Mp3 en Server
       MySQL          Disk      MySQL
       Cdrom          Disk      Unidad de Cdrom
       Program        Disk      Programas
       IPC$           IPC       IPC Service (Servidor Linux)
       ADMIN$         Disk      IPC Service (Servidor Linux)
       lp             Printer

       Server               Comment
       ---------            -------
       Mi-Linux            Servidor Linux
       Mi-Linux-2          Servidor Linux

       Workgroup            Master
       ---------            -------
       Mi-Grupo            Mi-Linux

Compartiendo Una Unidad Linux Con Máquinas Windows

Como se muestra en el fichero smb.conf anterior, compartir una unidad Linux con usuarios Windows es fácil. De todas maneras, como todo lo demás con Samba, puedes tener las cosas MUY controladas. Aquí tienes unos pocos ejemplos:

Para compartir un directorio con todo el mundo, crea una copia de la sección [tmp] añadiendo algo como esto al smb.conf:

[public]
  comment = Cosas publicas
  path = /home/public
  public = yes
  writable = yes
  printable = yes

Para que este directorio lo pueda leer todo el mundo, pero que sólo lo puedan cambiar gente del grupo 'laborales', modifica la entrada de esta manera:

[public]
  comment = Cosas publicas
  path = /home/public
  public = yes
  writable = yes
  printable = no
  write list = @laborales

Para aprender otros truquillos con que jugar con las unidades compartidas, mira la documentación de Samba o las páginas del man.

Compartiendo Una Unidad Windows Con Máquinas Linux

Se incluye un programa cliente de SMB para máquinas UNIX con la distribución de Samba. Provee un interfaz estilo ftp para la línea de comandos. Puedes usar esta utilidad para transferir ficheros entre un 'servidor' Windows y un cliente unix.

Para ver qué recursos están disponibles en un host dado, ejecuta:

   /usr/sbin/smbclient -L host

donde 'host' es el nombre de la máquina que quieres 'ver'. Esto devolverá un lista de nombres de 'servicios' --esto es, nombres de unidades o impresoras que puede compartir contigo--. A menos que el servidor SMB no tenga la seguridad configurada, te preguntará por una clave. Dale la clave de la cuenta de 'invitados' o de tu cuenta personal en esa máquina.

Por ejemplo:

   smbclient -L zimmerman

La salida de este comando debería ser algo parecido a esto:

Server time is Sat Aug 10 15:58:27 1996
Timezone is UTC+10.0
Password: 
Domain=[WORKGROUP] OS=[Windows NT 3.51] Server=[NT LAN Manager 3.51]

Server=[ZIMMERMAN] User=[] Workgroup=[WORKGROUP] Domain=[]

       Sharename      Type      Comment
       ---------      ----      -------
       ADMIN$         Disk      Remote Admin
       public         Disk      Public 
       C$             Disk      Default share
       IPC$           IPC       Remote IPC
       OReilly        Printer   OReilly
       print$         Disk      Printer Drivers

This machine has a browse list:

       Server               Comment
       ---------            -------
       HOPPER               Samba 1.9.15p8
       KERNIGAN             Samba 1.9.15p8
       LOVELACE             Samba 1.9.15p8
       RITCHIE              Samba 1.9.15p8
       ZIMMERMAN            

La lista muestra otros servidores SMB con recursos para compartir con la red.

Para usar el cliente, ejecuta:

   /usr/sbin/smbclient servicio <password>

donde 'servicio' es una máquina y un servicio. Por ejemplo, si estás intentando entrar en un directorio que ha sido compartido como 'public' en una máquina llamada zimmerman, el servicio debería llamarse \\zimmerman\public. De todas maneras, debido a restricciones del shell, necesitarás poner las barras invertidas con secuencias de escape, por lo que al final saldrá algo parecido a esto:

   /usr/sbin/smbclient \\\\zimmerman\\public miclave

donde 'miclave' es una cadena literal con tu password.

Entonces te aparecerá el 'prompt' del smbclient:

Server time is Sat Aug 10 15:58:44 1996
Timezone is UTC+10.0
Domain=[WORKGROUP] OS=[Windows NT 3.51] Server=[NT LAN Manager 3.51]
smb: \> 

Escribe 'h' para obtener una ayuda de como usar el cliente:

smb: \> h
ls             dir            lcd            cd             pwd            
get            mget           put            mput           rename         
more           mask           del            rm             mkdir          
md             rmdir          rd             prompt         recurse        
translate      lowercase      print          printmode      queue          
cancel         stat           quit           q              exit           
newer          archive        tar            blocksize      tarmode        
setmode        help           ?              !              
smb: \> 

Si sabes usar el ftp, no deberías necesitar las páginas del man del smbclient.

Compartiendo Una Impresora Linux Con Máquinas Windows

Para compartir una impresora Linux con máquinas Windows, necesitas asegurarte de que la impresora está preparada para trabajar bajo Linux. Si puedes imprimir desde Linux, preparar una 'compartición' SMB de la impresora es automático.

Mírate el COMO Imprimir (Printing HOWTO) para poner a punto la impresora con Linux.

Como el autor usa una impresora conectada a una máquina Windows NT, esta sección no debería ser vista como algo definitivo, sino como mera sugerencia. Cualquiera que tenga detalles que compartir con el autor, por favor, que los mande a dwood@plugged.net.au para que esta sección pueda ser completada.

Añade la configuración de la impresora a tu smb.conf:

[global]
  printing = bsd
  printcap name = /etc/printcap
  load printers = yes
  log file = /var/log/samba-log.%m
  lock directory = /var/lock/samba

[printers]
  comment = Todas las impresoras
  security = server
  path = /var/spool/lpd/lp
  browseable = no
  printable = yes
  public = yes
  writable = no
  create mode = 0700

[ljet]
  security = server
  path = /var/spool/lpd/lp
  printer name = lp
  writable = yes
  public = yes
  printable = yes
  print command = lpr -r -h -P %p %s

¡Asegúrate de que el 'path' de la impresora (en este caso bajo [ljet]) se corresponde al directorio de 'spool' en /etc/printcap!

NOTA: Hay algunos problemas compartiendo impresoras conectadas a UNIX con máquinas Windows NT usando Samba. Un problema es que NT 'vea' la impresora compartida correctamente. Para conseguirlo, mírate las notas en la distribución de Samba en el fichero docs/WinNT.txt. El otro va con problemas con las claves. Mírate los comentarios en ese mismo fichero para conseguir una molesta ganancia de conocimientos y fallos (jejeje) para arreglar el problema.

Compartiendo Una Impresora Windows Con Máquinas Linux

Para compartir una impresora en una máquina Windows, debes hacer lo siguiente:

a) Debes tener las entradas adecuadas en /etc/printcap y deben corresponderse a la estructura de directorios local (el directorio de spool, etc)

b) Debes tener el script /usr/bin/smbprint. Viene con las fuentes de Samba, pero no con la distribución de ejecutables del Samba. Más abajo comentamos una copia ligeramente modificada.

c) Si quieres convertir ficheros ASCII a PostScript, debes tener el 'nenscript' o su equivalente. nenscript es un conversor de PostScript y habitualmente está instalado en /usr/bin.

d) Puedes desear que las impresiones de Samba sean más sencillas teniendo un front end fácil de usar. Más abajo tienes un sencillo script en perl para manejar ASCII, PostScript o PostScript generado.

La entrada para /etc/printcap que tenemos debajo es para una impresora HP 5MP en un host Windows NT. Las entradas son las siguientes:

       cm - comentario
       lp - nombre del dispositivo a abrir para salida
       sd - el directorio de spool de la impresora (en la máquina local)
       af - el fichero de cuentas
       mx - el tamano maximo del fichero (cero es ilimitado)
       if - nombre del fichero de entrada (script)

Para más información, lee el COMO Imprimir (Printing HOWTO) o la página del man de printcap.

# /etc/printcap
#
# //zimmerman/oreilly via smbprint
#
lp:\
       :cm=HP 5MP PostScript OReilly en zimmerman:\
       :lp=/dev/lp1:\
       :sd=/var/spool/lpd/lp:\
       :af=/var/spool/lpd/lp/acct:\
       :mx#0:\
       :if=/usr/bin/smbprint:

Asegúrate de que los directorios de spool y cuentas existe y se puede escribir en ellos. Asegura también que la línea 'if' tiene el path adecuado para el script smbprint (que damos debajo) y que apunta al dispositivo adecuado. (el fichero /dev especial).

Lo siguiente es el propio script smbprint. Normalmente está en /usr/bin y es atribuible a Andrew Tridgell, la persona que creó el Samba (que yo sepa). Viene con la distribución de las fuentes del Samba, pero está ausente de algunas distribuciones de ejecutables, por lo que lo he recreado aquí.

Te podría interesar mirarlo con cuidado. Hay algunas pequeñas alteraciones que han demostrado ser útiles.

Lo básico del DNS

Descripción

DNS es un sistema jerárquico con estructura de árbol. El inicio se escribe "." y se denomina raíz, al igual que en las estructuras de datos en árbol. Bajo la raíz se hallan los dominios de más alto nivel (TLD, del inglés, Top Level Domain), cuyos ejemplos más representativos son ORG, COM, EDU y NET, si bien hay muchos más.

El DNS como un árbol de búsqueda, será capaz de encontrar en él los nodos buscados.

Cuando se busca una máquina, la consulta se ejecuta recursivamente en la jerarquía, empezando por la raíz. Si se desea encontrar la dirección IP de www.yahoo.com., el servidor de nombres (del inglés, nameserver) tiene que empezar a preguntar en algún sitio.

Empieza mirando en su caché. Si conoce la respuesta, pues la había buscado anteriormente y guardado en dicha caché, contestará directamente. Si no la sabe, entonces eliminará partes del nombre, empezando por la izquierda, comprobando si sabe algo de yahoo.com., luego de com. y, finalmente, de ".", del cual siempre se tiene información ya que se encuentra en uno de los ficheros de configuración en el disco duro.

A continuación preguntará al servidor "." acerca de www.yahoo.com. Dicho servidor "." no sabrá la contestación, pero ayudará a nuestro servidor en su búsqueda dándole una referencia de dónde seguir buscando. Estas referencias llevarán a nuestro servidor hasta el servidor de nombres que conoce la respuesta.

Otro concepto son los dominios in-addr.arpa. Estos dominios nos permite hacer consultas de dominios, teniendo el IP correspondiente. Es decir, si en vez de tener el dominio de Yahoo, tenemos el IP, y queremos saber que dominio esta apuntado ese IP, se lo proporcionamos al Nameserver y este podrá encontrarlo.

Configuración

Nociones introductorias

Idealmente se deben definir primero los siguiente datos:

1. Dominio a resolver.
2. Servidor de nombres principal (SOA). Éste debe ser un nombre que ya esté plenamente resuelto.
3. Lista de todos los servidores de nombres (NS) que se utilizarán para efectos de redundancia. Éstos deben ser nombres que ya estén plenamente resueltos.
4. Cuenta de correo del administrador responsable de esta zona. Dicha cuenta debe existir y no debe pertenecer a la misma zona que se está tratando de resolver.
5. Al menos un servidor de correo (MX), con un registro A, nunca CNAME.
6. IP predeterminada del dominio.
7. Sub-dominios dentro del dominio (www, mail, ftp, ns, etc.) y las direcciones IP que estarán asociadas a estos.

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

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

Todos los ficheros de zona deben pertenecer al usuario «named» a fin de que el daemon named pueda acceder a estos o bien modificarlos en el caso de tratarse de zonas esclavas. Creación de los ficheros de zona.

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

Variables/Directivas

$TTL 1d: directiva obligatoria a partir de la versión 9 de Bind, indica el tiempo de vida (TTL, del inglés, Time To Live) de la información contenida en el fichero. Por defecto se usan segundos, pero pueden usarse también semanas ($TTL 1w), días ($TTL 7d), horas ($TTL 168h) y minutos ($TTL 10080m).

$ORIGIN mi-red-local.org.: define cual va a ser la Zona de la DB. Yo no la incluí porque por default va a tomar la zona especificada en la configuración (el valor marcado con un (1) en el archivo de configuración). Esta variable se puede usar con el valor @ o va a completar los dominios que no terminen en .. Por ejemplo: www va a ser reemplazado por www.$ORIGIN o www.@ que en definitiva, en nuestro ejemplo, es mi-red-local.org.

SOA: el registro SOA (del inglés, Start Of Authority) se encuentra siempre tras las directivas y proclama información relevante sobre la autoridad de un dominio al servidor de nombres. Es siempre el primer recurso en un fichero de zona. El @ es la zona a la cual vamos a definir dominios en este archivo. El esquema del SOA es el siguiente:

@ IN SOA primary-name-server hostmaster-email (
 serial-number
 time-to-refresh
 time-to-retry
 time-to-expire
 minimum-TTL )

serial-number: es un número que se incrementa cada vez que se modifica un fichero de una zona, de forma que Bind se dé cuenta de que tiene que recargar esta zona.

time-to-refresh: indica a los servidores slave cuánto tiempo deben esperar antes de preguntar a su servidor master si se ha hecho algún cambio en la zona.

time-to-retry: indica el tiempo que el slave tiene que esperar para reintentar conectarse con el master en caso que este falle.

time-to-expire: indica al slave que si en ese tiempo no hubo comunicación con el master, toda la información del primero se vuelve inservible y deja de responder peticiones.

minimum-TTL: indica a los DNS que almacenen la información de esta DB, que mantengan la misma en su caché el tiempo indicado en este campo.

NS: define los Nameserver que tienen autoridad sobre los dominios espeficados a la derecha. Estructura:

dominio IN NS nameserver

A (Address): define un IP para el dominio. Estructura:

dominio IN A IP-Address

CNAME (Canonical NAME): Define un alias para el dominio. El dominio tiene que tener una definición de Address. Estructura:

alias IN CNAME dominio

MX (Mail eXchange): Define cual va a ser el servidor de mail de este dominio, el número indica el nivel de importancia entre los servidores de mail, donde el 0 es el más importante. Estructura:

dominio IN MX level[0-999] mail-server

OpenSSH

Descripción

SSH (Secure SHell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo el ordenador mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X arrancado.

Configuración

Servidor de SSH

El demonio sshd es el programa que espera conexiones de red de los clientes ssh, controla la autenticación y ejecuta el comando requerido. El puerto por defecto en el que escucha es el 22 y su fichero de configuración es /etc/ssh/sshd_config.

Otras opciones a destacar son:

• X11Forwarding yes|no:

habilitar o deshabilitar la redirección X

• PasswordAuthentication yes|no: especifica si deseamos utilizar la autenticación básica

En esta configuración se indica también la ruta en la que encontrar las claves que identifican nuestro servidor. Estas son la base de la autenticación mediante clave publica y los valores por defecto son:

HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key 

Estas claves generales al sistema, junto con su correspondiente clave pública, se crean al instalar el servidor mediante el comando ssh-keygen.

Se pueden configurar opciones generales al sistema en el fichero /etc/ssh/ssh_config como por ejemplo:

• PasswordAuthentication yes|no : especifica si deseamos utilizar la autenticación básica en nuestros clientes.

En él se indican las rutas para obtener las claves públicas y privadas de cada usuario:

IdentityFile ~/.ssh/identity
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_dsa 

Estas entradas indican que las claves privada y publica de cada usuario se encontrarán en el directorio .ssh del HOME del usuario. En este directorio se encuentra también el fichero authorized_keys2 que controla la autenticación mediante claves, como veremos más adelante.

BIBLIOGRAFIA

• Wikipedia en español
• Red Hat Enterprise Linux 4: Manual de referencia
• Las recetas de LFS
• Proyecto LuCAS
• XTech - Wiki