Servicios de Red
De GLASS
Tabla de contenidos |
DNS
Introducción
En este capítulo se pretende explicar la estructuración del espacio de nombres en una red TCP/IP, y la implementación de un servidor de nombres Bind 9 bajo Slackware Linux. En otras distribuciones puede cambiar la jerarquía del sistema de ficheros, así como la sintaxis en versiones de Bind anteriores en lo relativo a algunas implementaciones. La documentación oficial de Bind se puede encontrar en la siguiente dirección:
http://www.tldp.org/HOWTO/DNS-HOWTO.html
Del mismo modo, se puede encontrar el paquete de software oficial de Bind en el FTP de ISC (Internet Software Consortium).
Estructuración del espacio de nombres
DNS (Domain Name System), es el sistema que define un espacio de nombres con el que reconocer a los sistemas informáticos en una red. Como bien es sabido, en una red TCP/IP todos los ordenadores están identificados por una dirección IP.
En un principio, cuando los ordenadores interconectados eran pocos no suponía un problema identificarlos, pero con el aumento de las mismas, y con ellas, el incremento del número de usuarios, empezaron a aparecer los problemas para reconocer y recordar las direcciones IP.
En informática, la identificación de todos los objetos se ha traducido siempre en nombres simples y reconocibles, de modo que sean fáciles de recordar por la mente humana: tablas de sistema, periféricos, etc... En el caso la nomenclatura usada para identificar cada sistema por separado a sufrido una evolución donde en un principio los nombres se asignaban sin estructuración alguna, siendo escogidos al azar por el administrador de la red, hasta llegar a la actual jerarquización del espacio de nombres.
En el esquema original, el NIC (Network Information Center) se responsabilizaba de la no duplicidad de los nombres, así como de evitar la existencia en la red de nombres insultantes o con referencias obscenas. La organización ha evolucionado hasta convertirse en la actual INTERNIC (INTERnet Network Information Center), distribuyendo el espacio de nombres tal y como se muestra en el siguiente esquema:
Los root-servers contienen información sobre si mismos y sobre los servidores de nombres que alojan los nombres de dominio (google.com, linuxdoc.org, freshmeat.net, etc.), y cada uno de estos últimos a su vez, almacena la información sobre las direcciones a resolver dentro de cada dominio en particular (www.google.com, projects.freshmeat.net, mail.yahoo.com, etc.)
De este modo, cada nivel conoce la información de los niveles por debajo de si mismo. El camino que recorre una petición en el proceso de resolución de un nombre es el siguiente:
Resolución de una petición
Cuando un cliente (usuario, dentro de una red particular de una empresa o red doméstica), desea conocer la dirección IP correspondiente a una URL, como por ejemplo www.linux.org, la petición se dirige automáticamente al primer NS (Name Server) que el usuario haya configurado en su sistema. Por norma general debería ser un DNS interno, que forma parte de la red particular, aunque éste paso puede no ser cierto si la red a la que hacemos referencia es una red doméstica o es un sistema aislado.
El NS buscará primero en su caché si había resuelto anteriormente dicha petición, y si encuentra la dirección IP, se la entregará al cliente. En caso contrario, buscará en la configuración de los dominios que hospeda, y si dicho dominio es autoridad suya (lo hospeda) buscará el nombre de la máquina dentro del dominio ('WWW' dentro de linux.org), y después, lo entregará al cliente.
En caso de no ser autoridad suya, el dominio buscado (no lo hospeda), preguntará directamente a los root-servers por la dirección del servidor que posee la información buscada.
Un root-server, por definición, no contiene nombres de máquinas dentro de dominios, es decir, no relaciona nombres con direcciones IP de máquinas, sino que contiene los nombres y direcciones IP de los servidores que alojan cada dominio. De este modo, el root-server no devolverá al servidor de nivel inferior la dirección IP de la máquina que busca, sino la del NS que posee su autoridad, para que se dirija a éste último a preguntar por la dirección de la máquina. Finalmente, el primer NS se dirigirá al NS proporcionado por el root-server, y le preguntará por la dirección IP de la máquina. Es un proceso largo y complejo, pero completamente lógico, ya que observando la estructura con un poco de abstracción, podrá entenderse como un proceso en cadena. Veamos un ejemplo:
Una empresa dispone de varios departamentos, donde cada departamento tiene un jefe, y por encima de los jefes de departamento se encuentra el director gerente de la compañía.
Cuando un trabajador de departamento desea conocer el teléfono de otro trabajador cuyo departamento desconoce, lo primero que hace es mirar su propia agenda. En caso de no tener anotado el teléfono que necesita, lo pedirá a su superior. Si el superior no lo conoce, preguntará al jefe de departamento, y éste a su vez buscará en su agenda el contacto de un superior que conozca a dicho trabajador dentro del mismo departamento. Si no encuentra un superior que conozca al individuo buscado, preguntará al director, y éste le proporcionará el teléfono del jefe de departamento donde se encuentra el superior que conoce al trabajador, no el del propio trabajador. El jefe de departamento se pondrá entonces en contacto con el jefe de dicho departamento, y éste le proporcionará el contacto con el superior que conozca al trabajador. El jefe del departamento original, proporcionará esa información al superior que se la pidió para que se ponga directamente en contacto con él para que de este modo le facilite el teléfono del trabajador. En el momento en que ambos superiores hablen, y el primero tenga ya el teléfono que se le había pedido, se lo proporcionará al trabajador que originó la cadena.
Aunque este mecanismo pueda parecer rígido, es el modo de evitar sobrecargas en el procesador así como ancho de banda en los servidores de nombres, dado que en la actualidad existen cientos de millones de nombres a resolver. Así esta estructura es, cuanto menos, estable y funcional, y suficientemente jerarquizada como para comprender donde reside el problema en caso de que la cadena se rompa durante el proceso de resolución de un nombre. Es más, dada la carga que puede ocasionar llegar a ocasionar este servicio, es necesario que haya al menos dos NS que hospeden la autoridad de un mismo dominio. De ese modo si uno falla o está demasiado ocupado (procesador o ancho de banda) para atender una petición, queda al menos otro a quien pedir la resolución del nombre buscado.
Resolución inversa
Del mismo modo que cada máquina tiene un nombre que se relaciona con su IP, para ser reconocida o localizada rápidamente por la nuestro intelecto, también existe un proceso que relaciona las direcciones IP con los nombres. Es decir, el proceso de resolución directa es sencillo:
Petición: www.google.com Respuesta: 216.239.39.101
Ahora bien puede que se necesite una manera de resolver el nombre asociado a una dirección concreta. Tómese el ejemplo de un servidor DNS comercial que vende hosting de nombres para clientes que quieren dar de alta un dominio en Internet. Imagínese del mismo modo que el servidor DNS de este ejemplo es propiedad de una empresa llamada NETSERVERS, S.A.
Sus entradas pueden albergar el hosting de varios dominios, cada uno de ellos conteniendo las máquinas que el dueño del dominio quiera nombrar (asignar un nombre para su dirección IP). Puede entenderse con el siguiente ejemplo:
NS1.NETSERVERS.NET (199.213.76.123)
23:27 11 ene 2007 (CET)23:27 11 ene 2007 (CET)23:27 11 ene 2007 (CET)23:27 11 ene 2007 (CET)23:27 11 ene 2007 (CET)23:27 11
ene 2007 (CET) 23:27 11 ene 2007 (CET)
Autoridad de Barcelona.com:
www.barcelona.com -> 194.79.35.123
mail.barcelona.com -> 195.77.152.127
irc.barcelona.com -> 210.124.26.178
Autoridad de onlinemanuals.net:
www.onlinemanuals.net -> 187.14.183.126
mail.onlinemanuals.net -> 219.152.182.22
buy.onlinemanuals.net -> 193.128.218.97
france.onlinemanuals.net -> 198.234.221.11
spain.onlinemanuals.net -> 197.77.77.24
usa.onlinemanuals.net -> 217.87.89.124
Autoridad de ociolibre.org:
www.ociolibre.org -> 193.138.24.126
pop3.ociolibre.org -> 193.125.13.192
smtp.ociolibre.org -> 193.125.13.192
Como puede verse, ns1.netservers.net posee la autoridad de varios dominios, y en cada uno de ellos aloja la correlación entre las direcciones IP de las máquinas que ofrecen servicios para dicho dominio y su nombre. De este modo www.barcelona.com podría entenderse como www en barcelona.com. Es por ese motivo por lo que no importa que otras máquinas en Internet se llamen www, puesto que, siguiendo el ejemplo de este NS, serían [www en onlinemanuals.net] y [www en ociolibre.org]
Ahora bien. ¿ Qué pasará cuando pregunte por el nombre de una máquina, directamente con esa dirección ? Más concretamente cuando un cliente pregunte por el nombre de la máquina cuya dirección IP es, por ejemplo, 199.213.76.123, ¿ Qué nombre recibirá por respuesta, y quién se lo proporcionará ? La respuesta no será www.barcelona.com, ni mail.onlinemanuals.net, la respuesta será ns1.netservers.net, y la proporcionará aquel sistema capaz de conocer la información relativa a los NS que hospedan directamente los dominios de segundo nivel (.com primer nivel, barcelona.com segundo nivel, etc.) La respuesta es los TLD y los root-servers.
Aunque ns1.netservers.net hospedara 1 ó 2000 dominios, la resolución inversa (resolución de la dirección IP en busca del correspondiente nombre) respondería siempre igual; ns1.netservers.net
ISC BIND
Existen varias aplicaciones para realizar este servicio en un entorno Unix. Entre las más conocidas figuran Bind o DjbDNS. La que este documento se aborda es concretamente Bind (Berkeley Internet Name Domain), y la organización que lo distribuye es ISC (Internet Software Consortium). Como el resto de servidores DNS, y siguiendo lo que acabamos de ver, Bind distribuye el alojamiento de los dominios en dos partes; la resolución directa y la resolución inversa. Para llevar a cabo ambas, estructura el espacio de nombres reservado para cada dominio en ficheros separados, llamados zonas. De esta manera cada dominio tiene una zona directa, y sólo el dominio que da nombre a las máquinas de la red local, tiene una zona inversa para la resolución de este mismo tipo.
De cara a fuera (Internet), la resolución inversa nos la proporcionan los TLD o los root-servers, puesto que no conocen información alguna acerca de máquinas dentro de dominios de segundo nivel, esto es, nada acerca de los nombres de las máquinas finales, sino solamente las direcciones IP de los DNS que proporcionan la identificación de las máquinas. Como tales, su función es proporcionar un nombre a la IP del servidor, del mismo modo que relacionar la IP con el nombre del servidor.
Bind se compone de dos partes: el cliente y el servidor. La parte del cliente consta de varias herramientas con las cuales se realizan las peticiones a los servidores DNS desde una máquina cliente (nslookup, host, dig, etc.) La parte del servidor se compone básicamente del demonio (proceso residente en memoria principal) habilitado para el hospedaje de nombres de dominios, llamado named.
De este modo nslookup o host realiza la petición desde la máquina cliente, y named la recoge desde la máquina servidor, la procesa y devuelve la respuesta a la máquina cliente. Observemos el resultado de un query (petición) para resolver la IP de la máquina llamada hash:
ttyp0@coke:~/curso-redes$ nslookup hash.ttyp0.net Server: localhost Address: 127.0.0.1 Name: hash.ttyp0.net Address: 192.168.1.254
Como se puede observar, la petición está realizada directamente desde la shell (nslookup hash.ttyp0.net) con una utilidad de Bind, el nslookup. La respuesta se ve estructurada en dos partes:
- 1.Nombre e IP del servidor que va a responder
- 2.Nombre e IP de la máquina preguntada (nombre e IP de respuesta)
Si la parte del cliente ha quedado clara, véase la estructuración de la parte del servidor:
El proceso named nada más arrancar lee su fichero de configuración, en el cual se van a especificar algunas opciones con respecto a la misma, así como la declaración de las zonas (dominios) albergadas en el servidor. El fichero de configuración se encuentra, como el resto de configuraciones del sistema, en /etc, y se llama named.conf. Sirva el siguiente fichero como ejemplo:
ttyp0@coke:~/curso-redes$ cat /etc/named.conf
options {
directory "/var/named";
};
zone "ttyp0.net" in {
notify no;
type master;
file "ttyp0.net.zone";
};
zone "1.168.192.in-addr.arpa" in {
notify no;
type master;
file "ttyp0.net.rev";
};
zone "." in {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" in {
notify no;
type master;
file "named.local";
};
zone "localhost" in {
type master;
file "localhost.zone";
};
En la sección options se especifica el directorio donde se van a alojar las zonas, es decir, los ficheros que guardarán la información relativa a cada máquina, su dirección IP y su nombre dentro del dominio.
A partir de aquí, se declaran las zonas para cada dominio. La sintaxis de declaración de las zonas se hace para las zonas directas del siguiente modo:
zone "dominio.net" in {
y de este modo para las zonas inversas:
zone "1.168.192.in-addr.arpa" in {
Obviando el hecho que las zonas inversas no resuelven nombres para las direcciones IP, sino al contrario, podemos desechar la parte in-addr.arpa para entender el significado de la declaración de la zona, se obtiene 1.168.192, entendiendo que se declaran los rangos IP a resolver, y se declaran de una forma poco ortodoxa: al revés de como se escribiría normalmente. La zona 1.168.192, entonces indica el fichero donde se encuentra la resolución inversa para las máquinas del rango 192.168.1.0/24.
La opción file indica el nombre del fichero que contiene la zona que se está declarando, de modo que para la zona ttyp0.net</t> (zona de resolución directa) se especifica el fichero <tt>ttyp0.net.zone, y para la zona 1.168.192.in-addr.arpa se especifica el fichero ttyp0.net.rev (el sufijo .rev indica resolución inversa (rev = reverse)). Los nombres para los ficheros pueden asignarse como uno desee, aunque en el ejemplo se a elegido declarar las zonas directas con un nombre de fichero igual que el nombre del dominio procedido del sufijo .zone, y las zonas inversas con un nombre de fichero igual que el del dominio procedido del sufijo .rev.
Entendiendo que la primera parte de la configuración especificaba el directorio de almacenamiento de las zonas, veremos que en la declaración de cada una, el fichero ttyp0.net.zone hace referencia al path completo /var/named/ttyp0.net.zone, y el fichero ttyp0.net.rev hace referencia en realidad a /var/named/ttyp0.net.rev.
Las zonas localhost.zone y named.local, resuelven el nombre y la dirección IP (respectivamente) de la máquina localhost, cuya dirección IP es la 127.0.0.1. El localhost es la máquina local tal y como se entendería dentro de una misma red, es decir, no se comunica con otras máquinas a través de una tarjeta de red, sino consigo misma a través de un dispositivo lógico llamado loopback, que implementa el propio sistema operativo, y que sirve para implementar y probar aplicaciones que trabajen con sockets AF_INET ejerciendo la misma máquina como cliente y servidor simultáneamente, lo que es lo mismo, probar conexiones en red sin tener que estar conectado a la red.
La zona named.ca se declara como zona "." en el fichero de configuración de named, y contiene el listado de servidores a los que debe preguntar cuando un cliente le pide la resolución de una máquina que no tenga en su caché y cuya autoridad no posea.
Las zonas ttyp0.net.zone y </tt>ttyp0.net.rev</tt> contienen la lista de nombres y direcciones IP del dominio local ttyp0.net, siguiendo los apartados anteriores.
ttyp0@coke:~/curso-redes$ ls /var/named/
ttyp0.net.rev ttyp0.net.zone localhost.zone named.ca named.local
ttyp0@coke:~/curso-redes$
ttyp0@coke:/var/named$ cat localhost.zone
localhost. IN SOA coke.ttyp0.net. root.ttyp0.net.
(
2000101101 ;serial
10800 ;refresh (3h)
3600 ;retry (1h)
604800 ;expire (1 week)
86400) ;minium TTL (1 day)
localhost. IN NS coke.ttyp0.net.
localhost. IN A 127.0.0.1
En las cabeceras el texto antes del "." se conoce como ORIGIN. Después del ORIGIN se encuentra la sintaxis in SOA, donde SOA es un RR (Resource Record) que significa Start Of Authority.
De este modo se le especifica la autoridad de la zona del ORIGIN. A continuación encontramos coke.ttyp0.net., donde coke.ttyp0.net es la máquina que hospeda el servidor de DNS para esta zona. Nótese el “.“ al final del nombre.
Acto seguido se encuentra root.ttyp0.net, donde debe interpretarse este nombre, no como el nombre de una máquina sino como la dirección de correo electrónico del administrador del DNS, es decir, debemos interpretarlo como root@ttyp0.net.
Después, entre los paréntesis se encuentra la declaración de las variables de serial, refresco, reintento, expiración y TTL (Time To Live), que especifican la autenticidad y caducidad de la resolución de un nombre dentro de la zona. El serial es lo más importante en esta cabecera del SOA, puesto que hay que modificarlo cada vez que se realicen modificaciones en la zona, de lo contrario named no reconocerá las modificaciones, razón de múltiples dolores de cabeza entre administradores de servidores.
Debajo de la cabecera del SOA, se encuentra la especificación de los RR ( Resource Records ), de NS y A, los cuales indican lo siguiente:
- NS. Especifica el nombre de la maquina que hospeda el DNS
- A. Especifica la dirección IP para el nombre de la máquina que estamos declarando.
Es decir, la máquina con nombre localhost apunta a la dirección 127.0.0.1 La razón del “.“ al final de cada nombre se explicará más adelante, dado que la zona localhost es un tanto peculiar por solo contener una máquina, y no se ve clara la necesidad del "." Véase a continuación la zona inversa de localhost:
ttyp0@coke:/var/named$ cat named.local
;
; /var/named/named.local Traducción para 127.0.0
;
@ IN SOA ttyp0.net. root.ttyp0.net. (
1303200101 ;serial
360000 ;refresco:100 horas
3600 ;reintento:1 hora
3600000 ;expiración: 42 días
360000 ;mínimo:100 horas
)
IN NS coke.ttyp0.net.
1 IN PTR localhost.
La sintaxis es muy similar a la zona de resolución directa, aunque difiere en la definición del SOA, por el ORIGIN, así como por la máquina que hospeda el DNS. También puede verse que el Resource Record A se ha perdido, y en su lugar hay un Resource Record PTR, que especifica justamente lo contrario que el RR A. A relaciona un nombre con una IP, y PTR hace lo propio de modo contrario.
Examine ahora el fichero named.ca que define la zona ".":
; <<>> DiG 8.2 <<>> @A.ROOT-SERVERS.NET ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 ;; Total query time: 385 msec ;; FROM: coke to SERVER: A.ROOT-SERVERS.NET 198.41.0.4 ;; WHEN: Sun Mar 25 23:04:11 2001 ;; MSG SIZE sent: 17 rcvd: 436
El contenido de este fichero es un query (petición), realizado a un root-server, de la siguiente forma:
root@coke:/var/named# dig @A.ROOT-SERVERS.NET
La salida de este comando es el listado que puede verse en el contenido del fichero named.ca, y es la lista de los servidores a los que se debe preguntar cuando un nombre de dominio no es autoridad del propio servidor. Para crear el fichero named.ca basta con redirigir la salida estándar del comando a dicho fichero:
root@coke:/var/named# dig @A.ROOT-SERVERS.NET > named.ca
Una vez escritos estos tres archivos, ya puede disponer de un servidor DNS de sólo cacheo (caching only server), que resolverá las peticiones haciendo querys a los servidores que alojen cada dominio en particular, y las almacenará en su caché. Para arrancarlo, pude usarse el siguiente comando:
root@coke:/var/named# named
Debe ser consciente que los servidores DNS suelen tener fallos de seguridad con regularidad, cada vez menos, y que lanzar el demonio de named como usuario root, supone un riesgo que no deberíamos correr. Para lanzar el demonio de named con un usuario con menos privilegios puede hacerlo del siguiente modo:
root@coke:/var/named# named -u daemon -g daemon
Este comando lanzará el demonio named como usuario y grupo daemon, el cual no dispone casi privilegio alguno en el sistema. De este modo, si alguien lograse explotar su servidor DNS y conseguir acceso a una shell, se verá limitado a tan sólo unos pocos privilegios que tiene en el sistema dicho usuario. Aún así, sería recomendable leer la documentación relacionada con Bind in a chroot, para profundizar con más detalle.
Un dominio real
Para ver la resolución de nombres de un dominio, podemos fijarnos en las zonas directa e inversa de ttyp0.net. Veamos la sintaxis de ttyp0.net.zone:
;Start of Authority (SOA) record
ttyp0.net. IN SOA coke.ttyp0.net. root.ttyp0.net. (
2409200201 ;serial
10800 ;refresh (3 hours)
3600 ;retry (1 hour)
604800 ;expire (1 week)
86400 ) ;TTL (1 day)
;Name server (NS) records
ttyp0.net. IN NS coke.ttyp0.net.
;Mail Exchange (MX) records
ttyp0.net. IN MX 10 coke.ttyp0.net.
;Address (A) records
localhost.ttyp0.net. IN A 127.0.0.1
coke.ttyp0.net. IN A 192.168.1.10
hash.ttyp0.net. IN A 192.168.1.254
ovahflow.ttyp0.net. IN A 192.168.1.1
spy.ttyp0.net. IN A 192.168.1.20
routah.ttyp0.net. IN A 192.168.1.253
sun.ttyp0.net. IN A 192.168.1.30
backup.ttyp0.net. IN A 192.168.1.40
sergio.ttyp0.net. IN A 192.168.1.110
salva.ttyp0.net. IN A 192.168.1.100
*.ttyp0.net. IN A 192.168.1.1
;Aliases in Canonical Name (CNAME) records..
dns.ttyp0.net. IN CNAME coke.ttyp0.net.
ns.ttyp0.net. IN CNAME coke.ttyp0.net.
www.ttyp0.net. IN CNAME coke.ttyp0.net.
ftp.ttyp0.net. IN CNAME coke.ttyp0.net.
irc.ttyp0.net. IN CNAME spy.ttyp0.net.
fire.ttyp0.net. IN CNAME hash.ttyp0.net.
ttyp0.ttyp0.net. IN CNAME coke.ttyp0.net.
mrtg.ttyp0.net. IN CNAME coke.ttyp0.net.
router.ttyp0.net. IN CNAME routah.ttyp0.net.
netsaint.ttyp0.net. IN CNAME spy.ttyp0.net.
acid.ttyp0.net. IN CNAME spy.ttyp0.net.
Para empezar compruebe que es la misma estructura que en la zona directa de localhost, y al principio del fichero se encuentra, como era de esperar, el ORIGIN (ttyp0.net) seguido de un "."
Saltando la cabecera del SOA, siguen las declaraciones de los diferentes RR, como son NS, MX, A, CNAME (hay más, recomiendo la lectura de la documentación oficial de Bind). El RR "A", tal como se comentó anteriormente, relaciona un nombre con una dirección IP. El registro NS especifica la máquina que hospeda el DNS del dominio. El registro MX dice la máquina que va a alojar el servidor de correo del dominio. El número 10 es la prioridad del servidor de correo. Puede especificar más registros MX, uno bajo el otro, con diferentes niveles de prioridades (10, 20, 30, etc.) Los niveles de prioridad indican el orden en que deben usarse dichos servidores, es decir, en caso de que uno no responda, el siguiente es donde deben dirigirse los mensajes de correo eléctrico hasta su recuperación.
Por último, puede encontrar los registros CNAME, que son alias para las máquinas. Es decir, unavez declaradas las máquinas con sus correspondientes direcciones IP, puede añadir más nombres a modo de alias. En el ejemplo puede observarse como la máquina coke hace de servidor DNS, FTP, HTTP, etc., y por tanto tiene definidos unos alias para dirigirnos más fácilmente a ella, diferenciando según el servicio que se desee usar en cada momento. Estos alias reciben el nombre de canonical names.
Tal como se había apuntado en párrafos anteriores, el significado que tiene el "." al final de los nombres es evitar la deformación de estos mismos. Named recibe las peticiones, y busca la coincidencia de un nombre dentro de la zona correspondiente, que coincida con el que se le ha solicitado, y al comprobar los nombres dentro de las zonas, los va leyendo hasta encontrar un ".", indicador de que se ha llegado al final de la cadena. Si no encuentra un "." le añade el ORIGIN, de manera que un nombre sin él puede ocasionar que la petición para resolver coke.ttyp0.net se transforme en coke.ttyp0.net.ttyp0.net, nombre que obviamente no encontrará, y que ningún otro servidor le sabrá resolver. De este modo, hay quien prefiere definir los nombres sin el dominio, y sin acabar en ".", para que named añada el ORIGIN siempre al final del nombre buscado, y de esa manera coincidan, quedando todo ello de la siguiente manera:
coke IN A 192.168.1.10 hash IN A 192.168.1.254 ovahflow IN A 192.168.1.1 spy IN A 192.168.1.20 routah IN A 192.168.1.253 etc.
Veamos ahora la sintaxis de la zona inversa de este dominio:
; Start of Authority (SOA) record
1.168.192.in-addr.arpa. IN SOA coke.ttyp0.net. root.ttyp0.net. (
1303200103 ;serial
10800 ;refresh (3h)
3600 ;retry (1h)
604800 ;expire (1 week)
86400) ;minimum TTL (1 day)
;Name Server (NS) records
1.168.192.in-addr.arpa. IN NS coke.ttyp0.net.
;Addresses point to canonical names (PTR) for reverse lookups
254.1.168.192.in-addr.arpa. IN PTR hash.ttyp0.net.
1.1.168.192.in-addr.arpa. IN PTR ovahflow.ttyp0.net.
253.1.168.192.in-addr.arpa. IN PTR routah.ttyp0.net.
10.1.168.192.in-addr.arpa. IN PTR coke.ttyp0.net.
20.1.168.192.in-addr.arpa. IN PTR spy.ttyp0.net.
30.1.168.192.in-addr.arpa. IN PTR sun.ttyp0.net.
40.1.168.192.in-addr.arpa. IN PTR backup.ttyp0.net.
110.1.168.192.in-addr.arpa. IN PTR sergio.ttyp0.net.
100.1.168.192.in-addr.arpa. IN PTR salva.ttyp0.net.
Lo primero que podemos observar es que en la implementación de la zona inversa de un dominio no hay registros CNAME. Eso es lógico si pensando que los registros CNAME, son sólo alias para una misma máquina, de modo que en caso de especificar una relación inversa entre una dirección IP y un nombre, sólo se puede especificar un único nombre (relación uno a uno).
Aplicando lo expuesto anteriormente sobre el uso del "." al final del nombre, podemos entender ahora la sintaxis de la zona inversa de localhost, donde no se especificaba la dirección IP entera, sino solamente un "1", ya que se especificaba sin "." al final, y de ese modo se está pidiendo a named que le añada el ORIGIN al final (0.0.127.in-addr.arpa), para formar de este modo, la dirección IP entera a relacionar con el nombre localhost.
Más dominios
Del mismo modo que se ha seguido el proceso de creación de un servidor de nombres de sólo cacheo, y después la configuración del mismo para hospedar un dominio real, se van a añadir más dominios a nuestro DNS, aunque no sería necesario especificar una zona de resolución inversa para cada uno. Esto es así porque, si tratamos las direcciones IP como nombres a resolver, y los nombres resueltos como direcciones de máquinas, se da por entendido que ya dispone de una zona que resuelve las direcciones para los nombres, es decir, que tratando la dirección IP como un nombre a resolver, ya dispone de la siguiente relación:
ttyp0@coke:/var/named$ host 192.168.1.10 10.1.168.192.IN-ADDR.ARPA domain name pointer coke.ttyp0.net ttyp0@coke:/var/named$
La dirección IP 192.168.1.10 siempre será coke.ttyp0.net, y jamás podrá tener otro nombre, de modo que la resolución inversa para otros dominios es en este caso un extra que se podría ahorrar.
Ficheros relaccionados
Ficheros relacionados Ficheros relacionados con la resolución de nombres son:
- /etc/hosts Define los nombres de las máquinas asociadas a una serie de direcciones IP. Sólo lo puede leer la propia máquina.
- /etc/host.conf Define el orden de búsqueda para la resolución de un nombre (primero host, y luego Bind, por ejemplo)
- /etc/resolv.conf Define el orden de búsqueda de los servidores de DNS
Hay que tener en cuenta que en el fichero resolv.conf, la primera línea debería ser el ORIGIN de nuestro dominio sin acabar en ".", quedando del siguiente modo:
search ttyp0.net
De este modo, cuando hiciese una petición para resolver un nombre, podría especificar directamente nslookup coke, ya que Bind añadirá al final el dominio especificado en la linea de search, y enviará a named el nombre completo coke.ttyp0.net para resolver. Puede especificar varios dominios o subdominios en la linea de search, separados por espacios:
search ttyp0.net red-interna.net dominio.net ttyp0.red.net
Este proceso relentiza en extremo la resolución de nombres, analizando la causa en el siguiente ejemplo:
Si le pasa a named un nombre coke, Bind lo completaría primero con ttyp0.net, lo pasaría a named y éste lo resolvería sin problemas. En caso de que le pasase a named directamente coke.ttyp0.net, Bind completaría igualmente el nombre con la línea search, y pasaría a named coke.ttyp0.net.ttyp0.net, que al no encontrar modo alguno de resolver le pasaría a su vez a completarlo con el siguiente dominio de search; coke.ttyp0.net.red-interna.net, y tras no encontrar una respuesta, named, volvería a intentarlo con coke.ttyp0.net.dominio.net, y finalmente con coke.ttyp0.net.ttyp0.red.net. Tras no haber encontrado respuesta alguna para ninguno de los nombres buscados, buscará finalmente la petición original sin completar con dominio alguno, coke.ttyp0.net, y ésta vez sí que la encontraría finalizando el proceso de resolución. Puede parecer un proceso complejo, pero realmente ahorra mucho trabajo enumerando nombres de zonas en los ficheros de configuración.
Apache
El servidor Apache HTTP es un proyecto de la Apache Software Fundation, para desarrollar y mantener un servidor HTTP de código abierto para sistemas UNIX o Microsoft Windows. El objetivo de este proyecto es proporcionar un servidor seguro, eficiente y extensible que proporcione servicios HTTP en sintonía con los actuales estándares de HTTP.
Según sus propio creadores, “Apache es el servidor web más popular de Internet desde abril del 1996“. Como características principales del mismo destacan las siguientes:
- Soporte de los últimos protocolos incluyendo HTTP/1.1
- Es altamente configurable y extensible mediante módulos externos (Módulos dinámicos DSO).
- Puede ser personalizado mediante la programación de módulos personalizados utilizando la API de la que dispone.
- Se distribuye junto a su código fuente y dispone de una licencia no restrictiva.
- Funciona sobre plataformas Windows NT/9x, Netware, OS/2 y la mayoría de sistemas UNIX.
- Está en desarrollo constante y abierto a nuevas ideas, reporte de errores etc.
Actualmente se mantienen en desarrollo dos ramas de este servidor, la 1.X y la 2.X. Los desarrolladores de Apache trabajaron durante más de dos años, antes de liberar la primera versión beta de Apache 2.0, en abril de 2001. Una de las principales mejoras de la versión 2.0 es que se ha añadido soporte multi-threading para aumentar el rendimiento del proceso que sirve las peticiones, por lo que fue necesario reescribir totalmente el código.
La versión 1.X es actualmente la más utilizada en entornos de producción, si bien la segunda versión del servidor está llamada a sustituir definitivamente a la primera. Por el momento, ambas versiones gozan de pleno soporte y siguen siendo periódicamente actualizadas por parte de sus desarrolladores.
Instalando el paquete de Apache
En Slackware: La instalación del sistema Apache desde el sistema de paquetes se realiza de la siguiente manera:
root@rserver1:/#mount /dev/cdrom root@rserver1:/#installpkg /mnt/cdrom/slackware/n/apache-1.3-26-i386-1.tgz
Lanzando el servicio
Al instalar Apache como paquete se crea el archivo /etc/rc.d/rc.http, el cual es invocado por los archivos de inicio y detención del sistema. De esta manera, en función del parámetro que se le pasa al script, este lanzará el servicio con el típico apachectl start o lo detendrá con un apachectl stop. Así, el archivo de inicio del sistema /etc/rc.d/rc.M, mira si existe el archivo rc.httpd y si es así lo ejecuta pasándole como parámetro start.
Del mismo modo, es necesario parar el servicio, es posible hacerlo con apachectl stop. Se vuelve a lanzar con apachectl start y si lo que se busca es reiniciarlo para hacer efectivo un cambio en el archivo de configuración, es posible hacerlo de una sola vez con apachectl restart.
Configuración básica
Los archivos de configuración de Apache se encuentran en el directorio /etc/apache. El archivo de configuración del demonio del apache httpd es /etc/apache/httpd.conf. Para configurar el apache es necesario editar este archivo y descomentar la línea que hace referencia a la IP y el puerto por el cual ha de recibir las peticiones http.
Listen 192.168.10.102:80
Si una vez descomentada la línea anterior el apache no se lanza correctamente con un apachectl start lo más probable es que sea porque la configuración de la red de la máquina no es del todo correcta. Si no se dispone de acceso a un DNS y el archivo /etc/hosts no contiene una entrada capaz de resolver nuestra propia IP, el apache no funcionará. Basta entonces con añadir a este archivo una línea como esta:
192.168.10.102 rserver1.acade.net rserver1
Así, aunque no se pueda acceder a un DNS, la máquina es capaz de resolver el nombre asociado a la IP en la que ha de correr el httpd, ya que, antes de ir a consultar un DNS externo, el sistema consulta siempre antes de archivo /etc/hosts, motivo por el cual conviene siempre tener dicho archivo al día. En principio esto es suficiente para probar que el httpd funciona. Si no tocamos nada más en el archivo de configuración de Apache, éste servirá por defecto una web que nos indica que la instalación se ha realizado con éxito. El contenido de esta página está en /var/www/htdocs, pero podemos hacer que por defecto sirva otro contenido mediante la siguiente directiva:
DocumentRoot "/var/www/htdocs"
Si en lugar de /var/www/htdocs ponemos la ruta al directorio que contenga las páginas que se desea servir, serán estas las que se sirvan al cliente. Otra opción es redireccionar el directorio anterior mediante un link simbólico que apunte al lugar que contiene las páginas que queremos servir.
Configuración avanzada (Virtual Hosting)
Apache soporta virtual hosting, es decir, la posibilidad de alojar más de un sitio web en una misma máquina. Para ello es necesario comentar la directiva "Listen" del archivo de configuración de apache /etc/apache/httpd.conf. Y añadir una entrada "VirtualHost" para cada sitio web que deseamos ofrecer. De esta forma, cuando Apache reciba una petición de servicio http, será capaz de discernir qué contenido a de ser servido como respuesta a esa petición.
En primer lugar se especifica la dirección IP por la que haremos virtual host mediante la siguiente directiva:
NameVirtualHost xxx.xxx.xxx.xxx
Posteriormente, se añaden tantas entradas de virtual host como webs diferentes se han de servir por la IP especificada en NameVirtualHost.
<VirtualHost xxx.xxx.xxx.xxx>
ServerAdmin acade@acade.net
DocumentRoot /acade/sites/assl
ServerName assl.acade.net
ErrorLog logs/assl-error_log
Customlog logs/assl-access_log common
</VirtualHost>
<VirtualHost xxx.xxx.xxx.xxx>
ServerAdmin ...
DocumentRoot /acade/sites/prueba
ServerName prueba.acade.net
...
</VirtualHost>
Las directivas DocumentRoot y ServerName, son las que le dicen a Apache qué ha de mostrar y cuando. Así, si el cliente teclea en su navegador http://assl.acade.net, Apache le mostrará la página por defecto alojada en el directorio /acade/sites/assl. Si por el contrario el cliente introduce en su navegador http://prueba.acade.net, Apache le servirá la pagina por defecto que se encuentre en /acade/sites/prueba.
Es importante resaltar que los archivos /logs/assl-error_log y /logs/assl-access_log han de existir en nuestra máquina, de lo contrario Apache no arrancará. Estos archivos se buscan en /usr/logs, a no ser que se especifique la ruta completa al archivo.
Por defecto, Apache mostrará la pagina index.html del directorio especificado en DocumentRoot para la URL indicada por ServerName, ahora bien, es posible hacer que Apache busque otra página para servir por defecto. Basta con añadir el nombre de la página que deseamos que se muestre por defecto utilizando para ello la directiva DirectoryIndex de la siguiente manera:
<IfModule mod.dir.c> DirectoryIndex index.html index.htm index.php index.php3 index.php4 </IfModule>
De esta manera Apache buscará por este orden la página que ha de ser servida.
Por último, es necesario decirle a Apache que cargue los módulos de PHP para poder servir páginas programadas en PHP. Para ello, basta con introducir lo siguiente al final del archivo de configuración /etc/apache/httpd.conf:
Include /etc/apache/mod_php.conf Include /etc/apache/mod_ssl.conf
De esta manera Apache cargará los módulos externos necesarios para poder servir páginas PHP.
Para saber mas, la documentación Oficial para Apache 1.X esta disponible en: <http://httpd.apache.org/doc>
PHP
La mejor descripción de lo que es PHP sea quizás la aparecida en el prefacio del manual de PHP, disponible en su sitio web.
“PHP, acrónimo de ‘PHP: Hypertext Preprocesor’, es un lenguaje ‘Open Source’ interpretado de alto nivel, especialmente pensado para desarrollos web y el cual puede ser embebido en páginas HTML. La mayoría de su sintaxis es similar a C, Java y Perl y es fácil de aprender. La meta de este lenguaje es permitir escribir a los creadores de páginas web, páginas dinámicas de una manera rápida y fácil, aunque se pueda hacer mucho más con PHP.”
A diferencia de otros lenguajes como JavaScript, que se ejecuta en el cliente, PHP se ejecuta en el servidor y envía el resultado de esta ejecución al cliente junto con el resto del código HTML. El código PHP está embebido dentro del código HTML que se envía directamente al cliente. Así, mediante unas etiquetas especiales de inicio y final, se puede ir insertando código PHP. El navegador del cliente recibirá el código HTML y el resultado, si lo hay, producido tras la ejecución del código PHP.
PHP permite realizar fácilmente las mismas tareas que pueda realizar un script CGI, como procesar la información de formularios, generar páginas con contenidos dinámicos, o mandar y recibir cookies etc.
PHP puede ser ejecutado en la mayoría de los sistemas operativos. Así, existen versiones para Linux, Unix (incluido HP-UX, Solaris, FreeBSD y OpenBSD), Microsoft Windows y Mac OS X. También es capaz de operar con los servidores web más importantes, incluyendo Apache, Microsoft Internet Information Server, Personal Web Server, iPlanet (ahora Sun[tm] ONE Web Server), Oreilly Website Pro server, Caudium, Xitami, OmniHTTPd y muchos otros. PHP no sólo genera código HTML. Es posible crear código XHTM, XML, crear imágenes, archivos PDF, y películas Flash.
PHP es capaz de operar con multitud de diferentes tipos de bases de datos. El acceso a bases de datos es realmente sencillo mediante PHP. Éste puede operar directamente con las siguientes bases de datos: Adabas D, dBase, Empress, FilePro(sólo-lectura), Hyperwave, IBM DB2, Informix, Ingres, InterBase, FrontBase, MSQL, Direct MS-SQL, MySQL, ODBC, Oracle (OCI7 y OCI8), Ovrimos, PostgreSQL, Solid, Sysbase, Unix dbm y Velocid. También es posible trabajar con cualquier otra base de datos que soporte el estándar DBX u ODBC (The Open Database Connection Standard).
PHP permite comunicarse con otros servicios que utilicen los protocolos LDAP, IMAP, SNMP, NNTP, POP3, HTTP, COM (en Windows) y otros. Es capaz de utilizar objetos Java y la extensión de CORBA para acceder a objetos remotos.
Para el proceso de texto, dispone de características como las expresiones regulares POSIX Extended, Perl o el parseador de documentos XML. Además dispone de interesantes funciones para el comercio electrónico, entre las que destacan Cybercash, CyberMUT, VeriSign Payflow Pro y CCVS.
Instalación
Como siempre, la manera más sencilla de instalar PHP, es recurriendo al sistema de paquetes. El fichero del paquete de PHP en Slackware es este: php-4.2.1-i386-1.tgz
Para instalarlo:
root@rserver1:/#installpkg /mnt/cdrom/slackware/n/php-4.2.1-i386-1.tgz
Lo otra posibilidad es instalar PHP compilando las fuentes, para ello, se ha de compilar PHP, después es necesario cargar los módulos de PHP en la configuración de Apache.
# tar zxvfp php.tar.gz # cd php/ # ./configure --prefix=/usr --with-apxs=/usr/sbin/apxs --with-mod_charset --enable-force-cgi-redirect --enable-discard-path --with-config-file-path=/etc/apache --enable-safe-mode --with-openssl --enable-bcmath --with-bz2 --enable-calendar --enable-ctype --with-gdbm --with-db2 --with-db3 --enable-dbase --enable-ftp --enable-gd-imgstrttf --with-gd=/tmp/gd-1.8.2 --with-jpeg-dir=/tmp/gd-1.8.2 --with-gmp --with-mysql=/usr --with-xml=shared --with-readline=/usr --with-mm=/usr --enable-trans-sid --enable-shmop --enable-sockets --with-regex=php --enable-sysvsem --enable-sysvshm --enable-yp --enable-memory-limit --with-tsrm-pthreats --enable-shared --disable-debug --with-zlib=/usr # make # make install
Configuración
Al instalar el paquete de PHP se crean en /etc/apache los archivos de configuración de PHP php.ini y mod_php.conf. El primero de ellos deberá contener las siguientes entradas:
LoadModule php4_module libexec/libphp4.so
AddModule mod_php4.c
AddType application/x-httpd-php.php
El segundo archivo php.ini configura PHP. Para que pueda ejecutar correctamente el código PHP programado para versiones antiguas de PHP, es necesario activar las siguientes directivas de este archivo.
register_globals = On register_argc_argv = On
Nota: Activar estas opciones en el archivo de configuración de PHP supone un agujero de seguridad. Cualquier código que requiera tener activados estos parámetros, puede ser reprogramado de forma sencilla para que no se requiera la activación de las mismas. Consulte la documentación del manual de PHP para más información.
La mejor forma de introducirse en la programación en PHP, es consultando el “Manual de PHP“, disponible en <http://www.php.net/manual/es>.
MySQL
Según sus creadores, MySQL es la base de datos de código abierto más popular del mundo, diseñada para ser veloz, poderosa y precisa en misiones críticas y de gran capacidad de carga.
MySQL es un sistema de gestión de bases de datos relacionales, que sigue los estándares ANSI SQL y ODBC SQL, y usa la implementación de expresiones regulares de Henry Spencer que cumplen con POSIX 1003.2.
Por otra parte, MySQL dispone de capacidades para la replicación de bases de datos. Para ello, pueden seleccionarse dos tipos de modos: master fijo y master variable.
En el modo master fijo, uno de los servidores del cluster centraliza el proceso de escritura en la base de datos e informa periódicamente a los demás esclavos de las actualizaciones. Si el master sufre algún percance, todo el sistema se viene abajo. En este modo por tanto, los esclavos únicamente permite realizar operaciones de lectura en su base de datos.
En el modo master variable, cualquier nodo del cluster puede convertirse en master en caso de problemas, pero solamente de modo exclusivo, por lo que la escritura en la base de datos continua siendo centralizada por un solo elemento.
Instalando MySQL-Apache-PHP (como paquete)
Lo más habitual es que un servidor web disponga, además del servidor en si mismo, de un sistema capaz de ofrecer contenido dinámico. Esto implica generalmente el disponer del servidor Apache con PHP y de un sistema gestor de bases de datos. El mas popular hoy día es MySQL.
Para instalar MySQL , Apache y PHP desde los paquetes de la distribución base de Slackware, se han de utilizar los siguientes paquetes:
apache-1.3.26-i386-1.tgz php-4.2.1-i386-1.tgz mysql-3.23.51-i386-1.tgz
Que se instalan en el sistema de esta manera:
root@rserver1:/#mount /dev/cdrom root@rserver1:/#installpkg /mnt/cdrom/slackware/n/apache-1.3-26-i386-1.tgz root@rserver1:/#installpkg /mnt/cdrom/slackware/n/php-4.2.1-i386-1.tgz root@rserver1:/#installpkg /mnt/cdrom/slackware/ap/mysql-3.23.51-i386-1.tgz
Compilar MySQL desde las fuentes
Además se la opción de instalar MySQL como paquete, es posible compilarla para nuestro propio sistema. Los pasos para hacerlo serian los siguientes:
# tar zxvfp mysql.tar.gz # cd mysql/ # ./configure --prefix=/usr # make # make install # mysql_install_db # chown -R mysql:mysql /var/lib/mysql # chown -R mysql:mysql /var/run/mysql # chmod -R 777 /var/lib/mysql # chmod -R 777 /var/run/mysql
Configurando MySQL
Tras instalar el paquete de MySQL, deberemos hacer lo siguiente:
root@rserver1:/#mysql_isnstall_db
Esto crea los archivos necesarios para poder ejecutar mysql. Este script coloca estos archivos en /usr/lib/mysql/mysql pero para que MySQL los pueda leer al arrancar, es necesario cambiar el propietario de dichos archivos y del directorio que los contiene. Así, es necesario asegurarse de que el propietario de estos directorios y archivos es el usuario mysql, además de estar en el grupo mysql.
/usr/lib/mysql /usr/lib/mysql/mysql /usr/lib/mysql/mysql/*
Si no es así, se han de ejecutar los siguientes comandos:
root@rserver1:/var/lib/#chown mysql:mysql mysql root@rserver1:/var/lib/mysql/#chown mysql:mysql mysql root@rserver1:/var/lib/mysql/mysql/#chown mysql:mysql *
Ahora se esta en condiciones de lanzar el demonio mysqld.
root@rserver1:/safe_mysqld &
Si el demonio arranca sin problemas, se puede añadir la siguiente línea al archivo /etc/rc.d/rc.local:
/usr/bin/safe_mysqld &
Eso hará que el demonio de la MySQL sea lanzado de forma automática cada vez que arranca el sistema. Los pasos siguientes, una vez tenemos el demonio corriendo en nuestro sistema, serán los de asignar un password al usuario root, y crear las bases de datos y los usuarios que vamos a necesitar.
- Para asignar el password al usuario root:
root@rserver1:/#mysqladmin -u root password "mi_password"
- Para crear una base de datos:
root@rserver1:/#mysqladmin -u root -pmi_password create mi_base_de_datos
- Para borrar una base de datos:
root@rserver1:/#mysqladmin -u root -pmi_password drop mi_base_de_datos
Las consultas al demonio mysqld, se realizan mediante el cliente mysql.
Es muy importante crear más usuarios para acceder a nuestras bases de datos, ya que el usuario root tiene permisos en todas las tablas, además de permiso para crear tablas en todas las bases de datos. Lo normal es crear un usuario diferente con acceso únicamente a aquellas bases de datos que sea necesario, además éste podrá realizar sólo el tipo de consultas que el administrador quiera, por ejemplo "SELECT", "INSERT" y "UPDATE" de manera que no se permita crear (CERATE) o borrar (DROP) tablas de la base de datos a la que se le ha dado acceso.
- Crear un usuario nuevo.
Primero se ejecuta el cliente mysql:
root@rserver1:/#mysql -u root -pmi_password
Esto da el prompt de la consola cliente del demonio mysqld. Mediante este cliente, es posible realizar consultas al demonio de la MySQL. En este ejemplo las consultas que se introduzcan en la consola cliente de MySQL serán como usuario root.
Una ves situados ante la consola cliente de MySQL, se utiliza el siguiente comando para crear un usuario:
mysql>GRANT select,insert,update ON documentacion.* TO epito@localhost IDENTIFIED BY 'password_para_pepito';
Esto crea un usuario nuevo llamado "pepito". Este usuario tiene permisos para realizar consultas tipo SELECT, INSERT y UPDATE. Además se la ha dado permiso para consultar todas las tablas de la base de datos "documentación“ (documentacion.*) y su password de acceso será "password_para_pepito".
Ahora ya es posible ejecutar el cliente de MySQL como usuario "pepito", así:
root@rserver1:/mysql -u pepito -ppassword_para_pepito mysql>use documentacion;
También es posible realizar estode una sola vez:
root@rserver1:/mysql -u pepito -ppassword_para_pepito documentacion mysql>
Nota:Es importante no dejar espacios en blanco entre el parámetro "-p" y el password, de lo contrario no nada de lo anteriormente explicado funcionará. También es posible no pasar el parámetro “-p“, de esta forma, se nos instará a que lo introduzcamos en el paso siguiente.
Comandos básicos
Además de la orden "use" vista antes, son de gran útilidad los siguientes comandos:
| Algunos Comandos Básicos en MySQL | |
|---|---|
| Comando | Función |
| ? | Muestra una lista con los comandos MySQL. |
| use db_name | Cambia la base de datos acutal. Los siguiente comandos afectaran a esta base de datos. |
| status | Muestra información relativa a MySQL:
Versión del servidor, bases de datos actual, usuario logeado, versión del servidor, uptime, consultas realizadas etc, etc. |
| show databases | Muestras las tablas disponibles para la base de datos actual. |
| show tables | Muestra las bases de datos cargadas en el sistema. |
| describe | Muestra información sobre los campos y tipos de datos que permite albergar una tabla. |
Ejemplo:
mysql> use homesite_db; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> show tables; +-----------------------+ | Tables_in_homesite_db | +-----------------------+ | INFO | | users | +-----------------------+ 2 rows in set (0.00 sec) mysql> describe users; +----------+------------------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+------------------------------+------+-----+---------+----------------+ | id_user | tinyint(8) unsigned zerofill | | PRI | NULL | auto_increment | | nick | char(8) | | | | | | password | char(16) | | | | | +----------+------------------------------+------+-----+---------+----------------+ 3 rows in set (0.02 sec)
Consultas básicas
Mostrar las tablas de la base de datos actual.
mysql>SHOW tables;
Eliminar una tabla si tenemos permiso para ello.
mysql>DROP table <db_name>;
Crear una tabla en la base de datos:
mysql>CREATE TABLE <nombre_tabla> (
campo_1 tinyint(8) unsigned zerofill NOT NULL auto_increment,
campo_2 char(50) NOT NULL default 'valor_por_defecto',
campo_n ...,
PRIMARY KEY (campo_1)
) TYPE=MyISAM;
Insertar un dato en la tabla creada:
INSERT INTO <nombre_tabla> VALUES (00000001,'dato_campo_2','dato_campo_n');
Ejemplos: Una consulta así:
SELECT campo_1, campo_2 FROM nombre_tabla;
Retornará los campos campo_1 y campo_2 de la tabla nombre_tabla.
Una consulta así:
SELECT campo_1 FROM nombre_tabla WHERE campo_2='verde';
Retornará el campo_1 de todas los registros de la tabla cuyo campo_2 vale verde.
Herramientas útiles
Hasta ahora se ha visto como utilizar mysqladmin, safe_mysql y mysql para crear bases de datos, lanzar el demonio mysqld y realizar consultas a MySQL.
A continuación, se muestran algunos ejemplos de otros comandos que nos pueden resultar muy útiles:
root#rserver1:/#mysql -u root -pmi_password documentacion < backup_bd.sql
Este comando es muy útil para cargar los datos que definen la base de datos documentacion. Es decir, el archivo backup_bd.sql contiene todas las consultas necesarias para crear las tablas de la base de datos documentacion. Además, también contiene las consultas INSERT que nutren la base de datos.
Seguramente, se esté preguntando de dónde se saca el archivo backup_db.sql. Pues bien, existen dos opciones: editarlo manualmente, probablemente será necesario hacerlo la primera vez, o bien extraerlo de la base de datos con la utilidad mysqldump que trae MySQL. Así:
root@rserver1:/#mysqldump -u root -pmi_password documentacion > backup_bd.sql
Esto vuelca todas las consultas que crean y nutren la base de datos al archivo backup_bd.sql.
Para saber más es posible recurrir a la extensa documentación disponible en la web oficial de MySQL, en la cual destaca el manual de MySQL. <http://www.mysql.com/documentation/index.html>
NFS (Network File System)
NFS (Network File System) se desarrolló con el fin de permitir montar particiones remotamente entre máquinas situadas en una misma red. Puede entenderse como algo parecido a lo que es un servidor de ficheros en Windows. Para compartir particiones con otras máquinas dentro de una red, el servidor simplemente “comparte“ un directorio, y el cliente lo “monta“ de un modo similar a como sucede al montar un CD-ROM o una partición de un disco duro.
Configuración de un servidor NFS
Tan sólo es necesario editar un fichero para que el servidor de NFS funcione, en éste se especifican los directorios que se desean compartir y con quién, además de las condiciones en las cuales se hará. Haciendo esto, el servidor NFS funcionará perfectamente, aunque estará expuesto a un tremendo fallo de seguridad, de modo que se recomienda editar otros dos ficheros encargados del control de los accesos.
El primero de ellos, el fichero que especifica los directorios, máquinas y permisos, se encuentra en /etc/exports. Este fichero debe tener una estructura similar a la siguiente:
Directorio-local IP-cliente(opcion1, opcion2...) IP-cliente2(opcion1, opcion2...) Directorio-local2 IP-cliente(opciones...) IP-cliente2(opciones...) ...
Directorio local: puede ser cualquier directorio, normalmente suele utilizarse NFS para compartir “home's“ de usuarios en diferentes máquinas, o directorios a los que tengan que tener acceso varias máquinas. Al compartir un directorio TAMBIEN se comparten sus subdirectorios.
IP-cliente: dirección IP del cliente. Puede ser especificada como IP o como NOMBRE, es decir, es lo mismo especificar ttyp0.mine.nu que 217.126.51.143
Del mismo modo cabe decir que las IP's de los clientes pueden especificarse como un solo host, como un rango de IP's, mediante wildcards (comodines, '*' por ejemplo) y se puede hacer referencia a un grupo de red concreto. Aquí se muestran algunos ejemplos:
ttyp0.mine.nu markitos@assl.ath.cx *.mine.nu @assl 192.168.1.0/255.255.255.0 192.168.1.0/24 ttyp0@192.168.1.10
Opciones: especificación el modo en que se desea compartir ese directorio. Es posible especificar permisos de lectura solamente, de lectura y escritura, de escritura como root, de escritura, pero no como root, etc las posibles opciones son listadas a continuación:
| Diferentes tipos de permisos de lectura / escritura | |
|---|---|
| Directiva | Función |
| ro | El directorio se comparte en modo 'read-only', de manera que el cliente no podrá escribir en él una vez montado. |
| root_squash | Especifica justamente lo contrario, es decir, que se mapeen los uid de root a nobody. |
| all_squash | Especifica que se mapeen los uid de “cualquier usuario“ a nobody. |
| anonuid , anongid | Especifican los uid y gid se desea que figuren en las peticiones anónimas... es decir, por ejemplo si se tiene compartido el directorio /home/pedro quizá sea interesante que las peticiones para montar ese directorio aparezcan todas con el uid y el gid del usuario pedro. Se hace especificando estas dos opciones. |
| no_subtree_check | Si solamente está exportada parte de un volumen, una rutina llamada 'subtree checking' comprobará que el fichero pedido por el cliente se encuentra en la parte del volumen que está compartida. Si se sabe de antemano que el directorio que se está compartiendo se encuentra enteramente en el mismo volumen, se puede deshabilitar esta opción para evitar tráfico y tiempo. |
| sync | El servidor avisa al cliente de la escritura de un fichero cada vez que se finaliza dicha escritura. Es importante para la seguridad de los datos, ante la posibilidad de la caída del servidor. |
| nohide | Si la máquina cliente tiene un sistema montado en un directorio, y exporta este directorio, el cliente que lo monte deberá montar también el directorio 'hijo' que el servidor tiene montado, para poderlo ver. Esto sucede porque el directorio montado previamente por el servidor esta 'oculto'. Es posible evitar este contratiempo activando la opción 'nohide'. |
Con la especificación de estas opciones en el fichero /etc/exports junto a los directorios y las máquinas que deben tener acceso ya se dispone de un servidor de NFS que pueda funcionar perfectamente, aunque como se dijo antes, es una situación muy inseguro dejarlo así, de modo que deberá protegerse al servidor de los ataques malintencionados. De lo que se trata es de evitar que NADIE monte particiones del servidor salvo los usuarios y máquinas que el ADMINISTRADOR haya especificado expresamente.
Seguridad
Los ficheros que se han de editar ahora, a fin de controlar los accesos al servidor son: /etc/hosts.allow y /etc/hosts.deny. Lo que el servidor hará una vez recibida una petición será comprobar el fichero /etc/hosts.allow. Si encuentra una descripción que coincida con la petición del cliente, permitirá su acceso. Si ninguna entrada coincide con la descripción del cliente, buscará en /etc/hosts.deny si figura allí, y en tal caso la petición será rechazada. Finalmente, si en ninguno de los dos ficheros aparece descripción alguna que coincida con el cliente, por defecto “SE PERMITIRA EL ACCESO“.
El primer demonio al que se a de restringir el acceso es el portmapper, que especifica a los clientes la manera de encontrar en el sistema el servicio que buscan. Restringir el acceso al portmapper es posiblemente la mejor defensa que podemos tener contra los ataques de NFS, ya que de este modo impedimos que sepan encontrar los recursos que nuestro servidor de NFS ofrece.
La estructura que debería tener el archivo /etc/hosts.deny es la siguiente:
portmap:ALL lockd:ALL mountd:ALL rquotad:ALL statd:ALL
Algunos administradores de sistemas suelen especificar directamente ALL:ALL denegando el acceso a cualquier recurso o servicio. Realmente es la opción más segura, aunque posiblemente pueda dar problemas cuando dentro de algún tiempo se esté configurando algún servicio nuevo, habiéndose olvidado ya del /etc/hosts.deny , y el servicio no funcione sin tener idea de por qué. La sintaxis de /etc/hosts.allow resulta muy similar:
servicio: host [o red/mascara], host [o red/mascara]
La estructura de /etc/hosts.allow debe ser similar a la siguiente:
portmap: 192.168.1.10, 192.168.1.100, 172.26.0.0/24 lockd: 192.168.1.10, 192.168.1.100, 172.26.0.0/24 mountd: 192.168.1.10, 192.168.1.100, 172.26.0.0/24 rquotad: 192.168.1.10, 192.168.1.100, 172.26.0.0/24 statd: 192.168.1.10, 192.168.1.100, 172.26.0.0/24
Arrancando los servicios
Para arrancar los servicios del servidor NFS simplemente han de ejecutarse los RPC (Remote Procedure Call) que activan los demonios del portmapper, así como el mount y el demonio de NFS. Simplemente se han de ejecutar estos comandos:
/usr/sbin/exportfs -r /usr/sbin/rpc.quotad /usr/sbin/rpc.lockd /usr/sbin/rpc.statd /sbin/rpc.portmap /usr/sbin/rpc.mountd /usr/sbin/rpc.nfsd
Para comprobar que el servidor de NFS esta funcionando correctamente, basta con hacer un listado de los procesos (ps -aux, por ejemplo) y ver si realmente se han lanzado bien los demonios.
Si posteriormente se desean realizar cambios en el fichero /etc/exports, se ha de ejecutar /usr/sbin/exportfs -ra para obligar al demonio de NFS a re-leer la tabla de comparticiones al re-arrancarse. Una vez hecho esto, re-arrancamos el demonio de NFS, podemos hacerlo con las opciones -HUP del comando kill o killall.
El cliente
Para ejecutar un cliente de NFS simplemente se ha de comprobar que la versión de mount es superior a la 2.10m si se esta usando NFS versión 3. También se ha de tener soporte en la configuración de nuestro kernel para montar particiones NFS.
Para comenzar a usar una máquina como cliente de NFS solamente se deberá tener funcionando el portmapper, el statd y el lockd, por lo es posible arrancarlos de igual forma que en la parte del servidor:
/sbin/rpc.portmap /usr/sbin/rpc.lockd /usr/sbin/rpc.statd
Una vez funcionando los demonios necesarios, las particiones se montan usando el siguiente comando:
bash# mount ttyp0.mine.nu:/music /home/music
y para desmontarlas, simplemente:
bash# umount /home/music
Para especificar al cliente que monte las particiones al arrancar, se puede editar el fichero /etc/fstab y añadirle una linea como la siguiente:
#Device Mountpoint FStype Options Dump Pass# ... server.haxor.net:/home/hacker /home/hacker nfs rw 0 0 ...
Samba
Samba esta formado por un conjunto de aplicaciones que permiten utilizar el protocolo SMB (Server Message Block) en sistemas Linux y otros sistemas Unix-Like. El protocolo SMB, tambien conocido como NetBIOS, es utilizado en los sistemas Microsoft Windows 3.11, NT y 95/98 para compartir archivos e impresoras. Gracias a la suite de aplicaciones proporcionadas pos Samba, Linux puede compartir ficheros e impresoras con otras máquinas Windows y viceversa.
La suite de aplicaciones de samba esta compuesta de las siguientes utilidades:
| Suite de herramientas proporcionadas por Samba | |
|---|---|
| Directiva | Función |
| smbd | Demonio del Servidor del protocolo SMB |
| nmbd | Proporciona soporte para el servicio de servidor de nombres NetBIOS |
| smbcalcs | Obtiene o establece ACLs para un fichero o directorio NT. |
| smbclients | Cliente SMB para sistemas UNIX-LIKE |
| smbcontrol | Permite enviar mensajes a los demonios smbd, nmbd o winbindd |
| smbmount | Monta un sistema ficheros SMB. El kernel a de estar preparado para montar sistemas de archivos smbfs |
| smbpasswd | Permite cambiar el pasword del usuario de la sesión actual, o los passwords de una maquina que los contenga. |
| smbspool | Permite enviar un trabajo de impresion a un servidor impresora SMB. |
| smbstatus | Lista las conexiones SMB actuales de la maquina local |
| smbumount | Desmonta sistemas de ficheros SMB. |
| winbindd | El servicio proporcionado por winbindd, puede ser utilizado para resolver información de usuario o gurpo, de un servidor Windows NT. Este servicio, puede también proporcionar autenticacion mediante módulos PAM externos. |
Lanzar los demonios Existen dos formas de lanzar los demonios smbd y nmbd, una es hacerlo como un proceso independiente, la otra es hacerlo desde inetd (Internet Super Server Daemon). Samba responde mas rápidamente si es lanzado como un proceso independiente, pero si aun y asi se desea lanzar mediante inetd, sera necesario descomentar las siguientes lineas del archivo /etc/inetd.conf:
# These are to start Samba, an smb server that can export filesystems to # Pathworks, Lanmanager for DOS, Windows for Workgroups, Windows95, Lanmanager # for Windows, Lanmanager for OS/2, Windows NT, etc. # If you're running smbd and nmbd as daemons in /etc/rc.d/rc.samba, then you # shouldn't uncomment these lines. netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd
Tras esto, es necesario reiniciar el proceso inetd.
root@super8:~# kill -HUP `cat /var/run/inetd.pid`
Tras instalar el paquete de Samba, se crean los fichero /etc/rc.d/rc.samba y /etc/samba/smb.conf-sample. El primero de ellos permite lanzar los demonios de samba al arrancar el sistema, para ello es necesario, por un lado, dar permisos de ejecución al fichero rc.samba, y por el otro editar el fichero de configuración.
root@super8:~# chmod 755 /etc/rc.d/rc.samba root@super8:~# cp /etc/samba/smb.conf-sample /etc/samba/smb.conf
El archivo de configuraciones de samba puede llegar a ser muy complejo. Es por esto que para facilitar la creación de del mismo, se dispone del archivo smb.conf-sample, el cual esta perfectamente documentado y recoge las principales opciones que se pueden dar.
Un archivo smb.conf de ejemplo
En una red con diferentes máquinas windows y un servidor de ficheros Linux, se desea compartir un directorio con ficheros de administración. Para ello se ha creado un directorio /home/public donde se comparten dichos ficheros sin contraseña ni autenticación de usuario remota, con el fin de que cualquiera pueda acceder a ellos y moficiarlos, y el resto de la oficina se encuentre actualizada al momento. Imagine que el nombre de la red es trabajo.net, y que el rango de direcciones usado para la media docena de máquinas que forman la red, es 192.168.1.0/24. Veamos el ejemplo de la configuración de samba:
[global] guest account = nobody security = share workgroup = trabajo.net server string = Ficheros Administracion log file = /var/log/samba.%m max log size = 50 socket options = TCP_NODELAY dns proxy = No hosts allow = 192.168.1. 127. [tmp] comment = Temporary file space path = /tmp read only = Noguest ok = Yes [public] comment = Public Stuff path = /home/public write list = @users read only = No writable = yes public = Yes guest ok = Yes
Siguiendo el orden de la configuración, primero puede observar la ssección globals, que especifica el funcionamiento, el acceso y la generación de registros (logs), general de samba. Comentemos el contenido de cada línea:
[global]
Inicio de la sección global a modo de cabecera de la configuración
guest account = nobody
Nombre del usuario utilizado en el sistema local para los accesos remotos como usuario invitado. Se usa para la navegación por el servicio sin estar autenticado.
security = share
Tipo de seguridad que se implementa en el servidor. Utilizando share se explicita la no-necesidad de estar autenticado para navegar (browse) por el sistema de ficheros compartido.
workgroup = trabajo.net
Nombre de la red a la que se debe unir el servidor, debe coincidir con el nombre de dominio de la red Windows.
server string = Servidor de Archivos
Cadena de texto que identificará el servidor en la navegación de directorios de Windows (en la vista con detalles)
log file = /var/log/samba.%m
Fichero que se debe usar para almacenar los logs de samba. La variable %m hace referencia al cliente que ha accedido al servidor en el momento de generar el registro
max log size = 50
Tamaño máximo del registro en líneas
socket options = TCP_NODELAY
Ofrecer acceso inmediato a quien lo precise.
dns proxy = No
No existe ningún servidor proxy entre el servidor de ficheros y el servidor DNS que realice la resolución directa e inversa de los clientes que accedan al servicio.
hosts allow = 192.168.1. 127.
Rangos de direcciones a los que se permite el acceso, separadas por espacio.
Preste atención ahora a la sección tmp, que le generará un directorio temporal visible desde lo clientes Windows en el que podrán almacenar información carente de importancia:
[tmp]
Comienzo de la sección tmp
comment = Directorio de información temporal
Cadena de texto visible desde la navegación de directorios en los clientes Windows
path = /tmp
Ruta hacia el directorio que se va a compartir
read only = No
Condición de solo-lectura
guest ok = Yes
Permiso para acceder usuarios invitados Ahora fíjese en la implementación del directorio que contiene la información de los archivos de administración:
[public]
Comienzo de la sección public, acceso a ficheros del sistema servidor.
comment = Public Stuff
Comentario visible desde la navegación de directorios en lo clientes Windows con vista en detalles.
path = /home/public
Ruta hacia el directorio que se desea compartir
write list = @users
Grupo de usuarios del sistema local con acceso de escritura al directorio compartido.
read only = No
Condición de solo-lectura.
writable = yes
Condición de permiso para escritura.
public = Yes
Condición de visible públicamente a cualquier usuario
guest ok = Yes
Permiso para el acceso de usuarios invitados
Del mismo modo puede aplicar esta política a cualquier directorio que desee compartir. Si desease por ejemplo compartir un directorio con música entre los clientes de su red podría hacerlo del siguiente modo, partiendo del esquema propuesto anteriormente:
[mp3] comment = Musica en MP3 path = /mp3 write list = @users read only = No writable = yes public = Yes guest ok = Yes
Si desea que los usuarios se autentiquen y posean cada uno un directorio personal en el servidor de ficheros, deberá usar en la sección global el siguiente valor para la variable security:
security = user
Windows usa un método de encriptación desgraciadamente pobre para lo que deberíasuponer un control exahustivo de la seguridad a la hora de compartir recursos. Aun así, no deja de ser un algoritmo cerrado y propietario, de modo que los programadores que crearon Samba no implementaron soporte para dicha encriptación. Es por ello que Samba necesita que los passwords de acceso viajen en texto plano (configurar Windows para que no use encriptación) o encriptar sus passwords con un algoritmo compatible con el de Windows. Deberá habilitar esta característica, nosotros le proponemos deshabilitar la encriptación de Windows:
1)Si posee usted clientes con Windows anteriores a la versión 2000, deberá instalar en el registro el fichero llamado EtablePlainTextPasswords que acompaña la distribución de Samba, ello modificará el registro de Windows apropiadamente para que no se utilice encriptación en la transmisión de contraseñas por NetBIOS.
También puede hacerlo manualmente usando el editor del registro de Windows (Regedit), creando la clave HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP y añadirle un nuevo valor (DWOARD value), tal como sigue:
Value Name: EnablePlainTextPassword Data: 0x01.
2)Si posee usted clientes con versión NT de Windows, deberá añadir la clave HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters y añada un valor (DWORD value) como el que sigue:
Value Name: EnablePlainTextPassword Data: 0x01
3)Si posee usted clientes Windows 2000 deberá hacer lo propio con la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkStation\Parameters y añádale el valor (DWORD value) siguiente:
Value Name: EnablePlainTextPassword Data: 0x01
DHCP
DHCP (Dynamic Host Configuration Protocol) es un protocolo que permite la configuración dinámica de los parámetros de red de las máquinas conectadas a un servidor de DHCP. Para ello se utiliza el típico modelo cliente/servidor, en el cual las máquinas de la red ejecutan un cliente DHCP , el cual configura el hardware de red de equipo, con los datos recibidos del servidor de DCHP.
Existen varios programas para implementar clientes y servidores en Linux, tanto comerciales como libres. Slackware utiliza los programas libres dhcpcd y dhcpd de Paul Vixie/ISC (Internet Software Consortium).
Configuración de los clientes
En primer lugar es necesario instalar el paquete del demonio cliente. El CD-ROM de Slackware 9.0 viene con dos paquetes de DHCP ubicados en el directorio /slackware/n:
dhcp-3.0pl2-i386-1.tgz dhcpcd-1.3.22pl4-i386-1.tgz
El primero incluye tanto el demonio cliente como el servidor DHCP. El segundo es el correspondiente al demonio cliente.
root@super8:~# installpkg /mnt/cdrom/slackware/n/dhcpcd-1.3.22pl4-i386-1.tgz Installing package dhcpcd-1.3.22pl4-i386-1 ([recommended])... PACKAGE DESCRIPTION: dhcpcd: dhcpcd (DHCP client daemon) dhcpcd: dhcpcd: The DHCP client program dhcpcd is used to connect to a network by dhcpcd: contacting a DHCP server. dhcpcd gets an IP address and other dhcpcd: information from a corresponding DHCP server, configures the network dhcpcd: interface automatically, and tries to renew the lease time according dhcpcd: to RFC2131 or RFC1541 depending on the command line option. dhcpcd:
Para lanzar el demonio basta con ejecutar como root:
#/sbin/dhcpcd eth0
Esto lanza el demonio cliente de DHCP, el cual realizará una petición al servidor, que responde enviándole los datos necesarios para configurar la red. El demonio DHCP del cliente ejecutará entonces los comandos necesarios para configurar diferentes parámetros de la red.
Para que el demonio DHCP sea ejecutado automáticamente al arrancar el sistema, es necesario editar el archivo /etc/rc.d/rc.inet1. Este archivo puede ser generado mediante la herramienta netconfig o directamente con un editor de textos. Con netconfig, simplemente se han de responder a una serie de preguntas, entre ellas si se desea configurar el sistema mediante el protocolo DHCP o asignar una IP estática. Esta herramienta de configuración añade la linea siguiente al archivo rc.inet1.
/sbin/dhcpcd -t 10 -d eth0
Si se edita el archivo manualmente para configurar la red, es necesario añadir también las lineas para la configuración de la interfaz loopback, el resultado podría ser algo como esto:
#!bin/sh # # Configuración de las interfaces de red # # Configuración de la interfaz de loopback /sbin/ifconfig lo 127.0.0.1 /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo # Configuración de la tarjeta de red echo “Intentando configurar la red contactando con el servidor DHCP...“ /usr/sbin/dhcpd -t 10 -d eth0
Los parámetros -t y -d son opcionales, el primero especifica el tiempo de espera antes de obtener una respuesta por parte del servidor, el segundo informa y permite 'logear' la ejecución del demonio.
En ocasiones, se requiere especificar un hostname concreto, si esto sea así, basta con especificarlo como se muestra a continuación.
/sbin/dhcpcd -t 10 hostname_asignado -d eth0
Por defecto, el demonio dhcpcd reemplazará el contenido del archivo /etc/resolv.conf, en los casos en los que no se desea que esto suceda, es posible lanzar el demonio pasándole el parámetro -R.
Instalación del servidor (DHCPd)
En primer lugar es necesario instalar el paquete dhcp-3.0pl2-i386-1.tgz con la utilidad del sistema de paquetes installpkg.
root@super8:/etc# installpkg /mnt/cdrom/slackware/n/dhcp-3.0pl2-i386-1.tgz Installing package dhcp-3.0pl2-i386-1 ([optional])... PACKAGE DESCRIPTION: dhcp: dhcp (DHCP server and client utilities) dhcp: dhcp: This package provides the ISC's DHCP utilities, including both a dhcp: server and client. The DHCP protocol allows a host to contact a dhcp: central server which maintains a list of IP addresses which may be dhcp: assigned on one or more subnets. A DHCP client may request an dhcp: address from this pool, and then use it temporarily for communication dhcp: on the network. The DHCP protocol also provides a mechanism whereby dhcp: a client can learn important details about the network to which it is dhcp: attached, such as the location of a default router or name server. dhcp: Executing install script for dhcp-3.0pl2-i386-1...
Posteriormente hay que verificar que el kernel fue compilado con capacidades MULTICAST, para ello se puede utilizar utilizar el comando ifconfig -a. El kernel por defecto en Slackware 9.0 ya esta preparado para ello.
root@super8:/etc# ifconfig -a eth0| grep MULTICAST
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
El siguiente paso consiste en añadir una ruta para la IP 255.255.255.255, a fin de evitar problemas con algunas implementaciones de clientes Windows.
root@super8:/etc# route add -host 255.255.255.255 dev eth0
Configuración del servidor Cuando se instala el paquete dhcp-3.0pl2-i386-1.tgz, el scipt de instalación crea el archivo de configuración /etc/dhcpd.conf, el cual ha de ser editado, dado que no trae ninguna configuración por defecto. El siguiente podría ser un ejemplo de configuración de dicho archivo.
# dhcpd.conf
#
# Configuration file for ISC dhcpd (see 'man dhcpd.conf')
#
default-lease-time 300;
max-lease-time 6000;
ddns-update-style none;
# Mascara de la red cliente
option subnet-mask 255.255.255.0;
# Direccion de broacast de la red cliente
option broadcast-address 192.168.3.255;
# Gateway por defecto del sistema cliente
option routers 192.168.3.1;
# DNS que se asignaran a los clientes
option domain-name-servers 62.37.228.20, 62.37.225.58;
# Nombre de dominio
option domain-name "cosmo.pop";
# Rangos de direcciones asignados dinámicamente
subnet 192.168.3.0 netmask 255.255.255.0 {
range 192.168.3.1 192.168.3.10;
range 192.168.3.50 192.168.3.60;
}
# Direcciones estaticas a las MACs especificadas
host haagen {
hardware ethernet 00:0e:7d:ab:3c:17;
fixed-address 192.168.3.254;
}
Como se observa en el archivo, es posible especificar los parámetros de red que serán enviados al cliente. Mediante subnet, es posible especificar qué rangos de IPs, dentro del rango disponible en la clase especificada, podrán ser asignados a los clientes que lo soliciten. Por otro lado mediante la directiva host haagen, es posible asignar una determinada dirección IP a una maquina en concreto (mediante su dirección física). Combinando estas opciones, es posible asignar direcciones estáticas (a servidores por ejemplo), y direcciones dinámicas (a los equipos portátiles de nuestra red).
Lanzar el servidor
Para lanzar el servicio, tan sólo es necesario ejecutar el comando dhcpd. Las opciones -f (debug) y -d (foregraund) , pueden ser de gran utilidad para terminar de depurar el archivo de configuración, ya que lanzan el servidor en primer plano y muestran todas las acciones que realiza el servidor, respectivamente.
root@pepe:/home/melmak# dhcpd -d -f Internet Software Consortium DHCP Server V3.0pl2 Copyright 1995-2003 Internet Software Consortium. All rights reserved. For info, please visit http://www.isc.org/products/DHCP Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 1 leases to leases file. Listening on Socket/eth0/192.168.3.0/24 Sending on Socket/eth0/192.168.3.0/24 DHCPDISCOVER from 00:e0:7d:ab:3c:17 via eth0 DHCPOFFER on 192.168.3.60 to 00:e0:7d:ab:3c:17 via eth0 DHCPREQUEST for 192.168.3.60 (192.168.3.2) from 00:e0:7d:ab:3c:17 via eth0 DHCPACK on 192.168.3.60 to 00:e0:7d:ab:3c:17 via eth0
Para que el servicio DHCP sea iniciado al arrancar el sistema se puede de colocar el comando anterior (sin las opciones -f y -d) en el archivo /etc/rc.d/rc.local, ya que este es ejecutado en ultimo lugar al iniciar el sistema, estando destinado a lanzar servicios o establecer configuraciones adicionales.
FTP (ProFTPd)
El servicio FTP es un servicio TCP poco habitual, ya que usa dos puertos para funcionar. El 21 para que el cliente y servidor intercambien comandos (get, put, ls, etc.), y el 20 es el que se usa para la transferencia de los datos en si.
En modo activo el cliente se conecta usando un puerto no privilegiado (el primero libre que sea mayor de 1024, supongamos el 1037) al puerto 21 del servidor. Inmediatamente el cliente se pone a escuchar en el puerto 1037+1, esperando que el servidor establezca el nexo server:20 - maquina:1038. Si estamos detrás de un firewall, entonces esta configuración dejará de funcionar y nos veremos obligados a usar el modo pasivo, que es, como dicen algunos, "firewall-friendly".
FTP PASV (FTP en modo Pasivo). En una sesión de FTP normal el cliente abre una conexión en el puerto FTP (TCP 21), y es el servidor quién abre después un canal de datos desde su puerto TCP 20, y esto puede ser peligroso en términos de seguridad. Por ello se creó el FTP pasivo, en el que el propio cliente es quien se encarga de abrir el canal de datos.
ProFTP Proftp son las siglas del acrónimo de Professional File Transfer Protocol (FTP). Se recomienda que ProFTPd sea lanzado a través del inetd (Internet Super Server Daemon) cada vez que se realice una conexión al puerto de FTP, o como alternativa puede ejecutarse como daemon independiente.
En el caso de tener un servidor con poca carga, que haya de mantener activas, sólo unas cuantas sesiones FTP, se recomienda usar inetd. Esto se explica porque en este modo, inetd debe pasar el fichero de configuración al servidor, cada vez que recibe una petición.
Cuando ProFTPd se lanza como proceso independiente y recibe una señal de SIGHUP, entonces relee su configuración (generalmente almacenada en /etc/proftpd.conf). Para saber a que proceso hay que lanzar la señal de SIGHUP se puede hacer;
bash# ps -faxu | grep proftpd bash# nobody 243 0.0 0.4 2392 1136 ? S 23:45 0:00 proftpd
o
bash# cat /var/run/proftpd.pid bash# 243
A menos que sea lanzado con el modificador "-n", en cuyo caso se ejecutará como proceso de la shell que lo crea. La ventaja que presenta este método es que los registros o mensajes de error son enviados a la salida estándar, eso es a la consola. Para usar este método, hay que especificar en el fichero de configuración que vamos a lanzar el servidor en modo "standalone", por lo que cambiaríamos la siguiente línea:
#ServerType inetd ServerType standalone
Véase una captura de pantalla lanzando el servidor en modo "standalone":
root@belluguet:/home/joan# proftpd -n belluguet.Lmann.net - ProFTPD 1.2.5rc1 (release) (built Wed Dec 19 17:48:18 CST 2001) standalone mode STARTUP belluguet.Lmann.net (127.0.0.1[127.0.0.1]) - FTP session opened. belluguet.Lmann.net (127.0.0.1[127.0.0.1]) - USER joan: Login successful. belluguet.Lmann.net (127.0.0.1[127.0.0.1]) - FTP session closed.
Si se desea depurar posibles fallos de configuración u obtener información adicional del funcionamiento del servidor, es posible combinar el modificador -n, con el -d, que indica el nivel de depuración de los mensajes generados, con valores que oscilan entre 0 i 5. (Siendo el 5, el nivel de mayor grado de depuración). Las diferencias entre los modos 0 a 3 son muy pequeñas, siendo el 4 y el 5 los que ofrecen mayor volumen de salida. Para este tipo de configuración el siguiente comando puede resultar de ayuda para redireccionar la salida del ProFTPd a un fichero y poderlo estudiar más tarde con mayor detenimiento:
bash# proftpd -nd5 2>&1 >& /directorio/fichero.log
Los ficheros que participan en la ejecución del servidor proftpd son los siguientes;
| Ficheros involucrados en la ejecución del ProFTP | |
|---|---|
| Directiva | Función |
| /usr/sbin/proftpd | Servidor FTP |
| /usr/bin/ftpwho | Muestra información sobre los procesos de todas las conexiones activas |
| /usr/bin/ftpcount | Muestra el número actual de conexiones por servidor |
| /usr/sbin/ftpshut | Utilidad que permite apagar el servidor ftp automáticamente para las conexiones establecidas, y no permitir nuevas |
| /var/log/xferlog | Fichero que contiene los logs del proftpd. Cada entrada es una linea con los campos separados por espacios. Sólo se registran los uploads y los downloads, no la ejecución de comandos internos tales como ls |
| /var/run/proftpd-[pid] | Mapa de direcciones de memoria para el proceso con numero = pid, cuando es lanzado a través del inetd. Sólo deja registros a memoria en operaciones de upload o download |
| /var/run/proftpd.pid | Número de proceso del proftpd cuando se lanza en modo "standalone" |
| var/run/proftpd -netd | Mapa de direcciones de memoria cuando se lanza proftpd a través de inted |
Otras opciones disponibles para la ejecución de ProFTPd;
| Ficheros involucrados en la ejecución del ProFTP | |
|---|---|
| Directiva | Función |
| -c | Con esta opción podemos definir cualquier otro fichero como fuente de la configuración del programa. Por defecto se toma el fichero /etc/proftpd.conf. |
| -l | Lista todos los módulos compilados dentro de proftpd. |
Como complemento a este modificador, se puede usar el "-t". Esta opción será de gran ayuda porque permite testear nuestros ficheros de configuración y obtener un resumen de los posibles errores de sintaxis que pudieran existir. Sólo se indicará el primer error que se encuentre, de modo se debe repetir la operación hasta obtener el mensaje:
root@belluguet:/var/run# proftpd -c "/etc/proftpd.conf" -td5 Checking syntax of configuration file Syntax check complete
Configuración de ProFTPd
Como ya se ha visto el fichero de configuración de este servidor es /etc/proftpd.conf. La configuración de este fichero tiene una particularidad, que es su sintaxis, muy parecida a los tags del HTML.
Detención del servidor ProFTPd
Se puede detener el servidor, o bien enviando una señal al pid del proceso (en caso de que se ejecute como StandAlone) de este modo:
kill -TERM `cat /usr/local/var/proftpd.pid`
o
ftpshut -l 1
Configuración de ProFTPd detrás de un servidor de NAT
Lo primero es asegurar que el servidor funciona correctamente desde dentro de la red. Luego hay que editar el fichero de configuración /etc/proftpd.conf, y añadir dentro la siguiente directiva:
MasqueradeAddress ftp.midominio.org
o
MasqueradeAddress 123.45.67.89
Con ello se consigue que ProFTPd, oculte su dirección local y en vez de ella use la dirección pública del servidor de NAT. Esto por otro lado presenta una problemática, el FTP en modo pasivo, en el que se usarán puertos del 1024 para arriba. Para impedir la desagradable situación de haber de redirigir todos los puertos del NAT (1024-65535) al servidor de FTP, existe la directiva PassivePorts, donde se le puede indicar que rango de puertos debe ser usado para esta modalidad.
PassivePorts 65000 65535
Ahora al arrancar el demonio del FTP, veremos un log parecido a este:
192.168.1.30:21 masquerading as 192.168.1.254
Particularidades del chroot
Por lo general puede resultar interesante una configuración donde se restringa a los usuarios a sus directorios, y donde el administrador quiera tener un directorio de "upload" común, o lo que es lo mismo, tener el directorio /var/ftp/incoming, en el home de cada usuario. En estos casos los links simbólicos no suelen ser de ayuda (debido a la directiva DefaultRoot). Para superar esta aparente limitación, en los kernels superiores al 2.4.0 en Linux, se puede tener un duplicado exacto del /var/ftp/incoming en el /home/pepe/incoming usando el comando mount:
mount --bind /var/ftp/incoming /home/pepe/incoming
Ahora se acaba de “remontar“ una parte de la jerarquía de ficheros en otra parte. Si nos interesa que estos cambios permanezcan en el servidor, deberemos introducir la línea correspondiente en el /etc/fstab.
Ocultación de propietario de los ficheros
A menudo se tienen multitud de ficheros en los directorios visibles del el FTP, y el resultado después de algún tiempo es poco homogéneo al hacer un listado del contenido de los directorios. Si queremos enmascarar el nombre de usuario y de grupo dentro del servidor, se pueden añadir las directrices DirFakeUser y DirFakeGroup. Su uso es extremadamente sencillo, tal y como se muestra a continuación:
DirFakeGroup On wheel DirFakeUser On rueda DirFakeMode 0640
Si por el contrario se desea que los ficheros listados, parezcan pertenecer al usuario conectado a nuestro servicio, podemos hacer algo parecido:
DirFakeGroup On ~ DirFakeUser On ~ DirFakeMode 0640
Esto, todo y que son meras operaciones estéticas sobre el servidor, son totalmente inocuas a los permisos establecidos en los ficheros, y en consecuencia puede llevar a inducir errores a la hora de intentar acceder a un fichero, que parece “pertenecernos“, pero que en realidad no es así (root, por ejemplo). Para ello existe la directiva HideNoAccess, con la cual el servidor no nos listará como resultado aquellos ficheros para los cuales no tengamos permisos.
<Directory /usuario/muy_personal> HideNoAccess on </Directory>
Ejecutar un servidor ProFTPd como usuario
Puede que darse la situación de tener que configurar un servidor en cuya máquina no se dispone del nivel de superusuario, incluso en estas circunstancias es posible ejecutar un servidor sin estos privilegios. Se necesita:
Número de puerto mayor que 1024 (Por ejemplo el 20021)
Port 20021
Ficheros propios para la autentiticación de usuarios de ProFTPd
AuthUserFile /directorio/fichero/ftpd.passwd AuthGroupFile /directorio/fichero/ftpd.group
Deshabilitar la autentiticación PAM, la cual requiere permisos de root
AuthPAM off
Crear ficheros wtmp de registro, requiere privilegios de root. No pasa nada si no la desactivamos, pero obtendremos mensajes de errores en el servidor.
WtmpLog off
Para poder cambiar la identidad asociada al proceso del servidor, a las configuradas por las directivas User y Group, se necesitan, evidentemente, privilegios de root, por lo que es mejor configurar la directiva User a tu nombre de usuario, y Group al nombre de tu grupo primario, que por lo general es, el primero que aparece al ejecutar el comando groups:
User pepe Group users
Para finalizar, cabe decir que algunas directivas de configuración, pueden verse afectadas. De este modo DefaultRoot, dejará de funcionar. Básicamente cualquier directiva que precise permiso de root, dejará de funcionar.
Nociones sobre Umask
Por defecto, los valores de los permisos de los ficheros creados en el servidor FTP, son 0666. La directiva umask, puede ser usada para rebajar estos niveles, pero nunca para aumentarlos, esto es, dar permisos de ejecución a un fichero. Umask [valor para el fichero] [valor para el direcorio]
Si es necesario dar permisos de ejecución a los ficheros que se hayan subido, esto se puede hacer por medio del comando SITE_CHMOD:
SITE_CHMOD modo fichero
Si se desea restringir el uso de este comando, es posible crear una sección "limit" como la que sigue, en el fichero de configuración:
<Limit SITE_CHMOD> AllowUser ftpadmin DenyAll </Limit>
De este modo se prohíbe explícitamente su uso a cualquier usuario que no sea ftpadmin. Si un usuario desea subir un fichero con el mismo nombre que uno que ya existiera dentro del servidor, por defecto el servidor, no lo dejaría efectuar la operación a menos que se permita el sobreescribir por medio de la directiva AllowOverwrite que viene deshabilitada por defecto.
Normas de Seguridad General
Es recomendable filtrar el tipo de carácter es que van a ser enviados a ProFTPd. Para prevenir posibles ataques, es recomendable limitar el numero de caracteres por medio de la directiva AllowFilter:
AllowFiler "^[a-zA-Z0-9 ,]*$"
A este mismo respecto, es igualmente recomendable configurar la directiva CommandBufferSize, la cual controla la longitud máxima permitida para ser luego enviada al servidor. Es útil ante ataques de denegación de servicio.
No se recomienda habilitar la opción de restart, para las operaciones de subida de ficheros, ya que esto puede permitir a los usuarios, corromper o incrementar el tamaño de los ficheros previamente guardados.
De otro modo permite a los usuarios reanudar descargas fallidas por medio del comando REST. Complementando a lo visto en este punto, se encuentra la directiva DeleteAbortedStores,la cual se encarga de hacer la limpieza necesaria de los ficheros abortados.
Optativamente se puede usar también las Quotas, lo cual habilita o deshabilita su soporte.
Quotas on
Pedir password para el usuario anónimo, que por defecto no es necesario:
<Anonymous ~ftp>
User ftp
Group ftp
UserAlias anonymous ftp # Los clientes logeados como anónimos pasan
# a llamarse ftp
AnonRequirePassword on
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
<Limit READ WRITE>
DenyAll
</Limit>
<Limit STOR>
AllowAll
</Limit>
</Directory>
</Anonymous>
Este ejemplo muestra la sección anonymous más generalizada.
Limitar el número de conexiones desde cualquier segmento que se le defina por medio de mecanismos sencillos como son los controles por clase de acceso:
Classes on Class local limit 100 Class default limit 10 Class local ip 192.168.1.0/24
También se puede limitar este número de usuarios por medio de la directiva MaxClients, tanto a los que están logeados en el servidor como los que están usando cuentas anónimas.
Estos mecanismos usados conjuntamente con la directiva MaxLoginAttemps, la cual especifica el número máximo de intentos para logear dentro del servidor, confieren una especial granularidad a la hora de seleccionar los usuarios en nuestro servidor.
Anchos de banda usados en operaciones de upload/download:
| Opciones disponibles para limitar anchos de banda. | |
|---|---|
| Directiva | Función |
| RateReadBPS | Ancho de banda para la descarga en bytes/segundo |
| RateReadFreeBytes | Cantidad de bytes enviados sin los límites |
| RateReadHardBPS | Fuerza el ancho de banda para dar valores de RateReadBPS determinados |
| RateWriteBPS | Establece la cantidad de bytes por segundo de subid |
| RateWriteFreeBytes | Cantidad de bytes transferidos sin limitaciones de ancho de banda |
| RateWriteHardBPS | Fuerza el ancho de banda para dar los valores de RateWriteBPS |
Por defecto en un servidor de FTP decente, no se permite el login como root. Para habilitar o deshabilitar a voluntad esta característica, se usa la directiva RootLogin:
RootLogin on
La directiva TimeoutsIdle es el número de segundos que puede estar el servidor sin recibir respuesta del cliente. Del mismo modo TimeoutLogin, realiza una labor muy parecida pero en el proceso de autentiticación.
TimeoutsIdle 300 TimeoutLogin 300