Servidoreswed

Servidor de Servicio de Nombres de Dominio
Las direcciones IP son la base de la internet, sin embargo, normalmente nosotros no usamos las
direcciones IP sino que nos referimos por nombres a los sitios.
Estos nombres son conocidos por nombre de dominios.
Los nombres de dominios se separan por niveles, estos niveles se separan por puntos, por ejemplo
nuestroserver.com es un dominio de segundo nivel (nuestroserver . com) y .com es un dominio de
primer nivel.
Existen una cantidad limitada y normalizada de nombres de dominios de primer nivel. Estos son por
ejemplo:
.com
.net
.org
.biz
.name
.info
Estos dominios de primer nivel pueden ser adquiridos por quien desee y por supuesto existe control
para evitar nombres repetidos. Este control se realiza a través de la centralización de los dominios
en registrars (registradoras autorizadas) y los dominios son manejados por verisign-grs.
Existen dominios de países que son llamados ccTLD (country code top level domains), estos
dominios son manejados normalmente por entidades autorizadas dentro de cada país. Los dominios
se rigen por una convención ISO que clasifica a los países por un código de dos letras:
.ec
.co
.pe
.nl
.de
.es
.us
.ca
.cu
.fr
.de
Etcétera.
También existen varios dominios con efectos restringidos como son:

.int : dominios para organizaciones internacionales, normalmente afiliadas a la unesco
.mil : dominios para las instituciones militares norteamericanas
.edu : dominios para instituciones educativas norteamericanas
.gov : dominios para instituciones gubernamentales norteamericanas
Este manejo de dominios debe interpretarse como la búsqueda en una guía telefónica. Uno tiene un
nombre y pregunta en la guía por el teléfono. Así mismo se hace con los dominios, uno tiene un
nombre de dominio y la máquina nuestra pregunta en su "guía" por la IP de ese dominio.
Los dominios son un artilugio creado para memorizar fácilmente una dirección de internet. La
entidad autorizada para registrar dominios se llama internic. Ellos realmente no registran dominios
de internet sino que delegan en ciertas organizaciones llamadas registrars para realizar el registro.
internic cobra por cada dominio registrado 2usd por año. verisign es la empresa que mantiene una
lista centralizada de todos los dominios y cobra igualmente 2usd por cada uno registrado.
Esto es, cualquier precio por encima de los 4USD que nosotros paguemos por un dominio
consideremos que lo estamos dando como lucro a alguien. Por supuesto, los registrars autorizados
por internic tienen gastos de mantenimiento que hacen que un dominio no cueste exactamente 4usd
sino posiblemente un poquito más.
Anteriormente existía solamente una empresa registradora, esta se llama network solutions, ellos al
tener el monopolio del registro de dominios vendían a precios exhorbitantes superando si mal no
recuerdo los 50usd por cada año que se registrara un dominio. Digo exhorbitante porque,
definitivamente, pagar 4 y ganar unos 45usd (pensando que tienen 1usd de gasto por cada dominio)
es una ganancia muy buena.
Para evitar el monopolio es que se autorizaron a operar otros registrars, que están enlazados entre
ellos a través de verisign-grs, esto es, cuando alguien registra un dominio, el registrar primero
verifica en verisign-grs si ese dominio no lo acaba de registrar alguien y sino, lo asigna a esta
persona y le reporta a verisign-grs que lo registró para su cliente.
Los rangos de precios de los registrars son variables, todo depende, hay registrars que cobran cerca
de los 35usd/año, otros que cobran menos de 10usd/año por dominio. Todo depende de la fama que
tengan en el mercado y de cómo vean la posibilidad de lucrar.
Algunas personas nos han sorprendido con la idea de que está bien, que con network solutions es
caro (35usd/año) pero son seguros porque tienen muchos dominios y porque son conocidos. Y esta
es una afirmación falsa:
1. Network Solutions ha estado perdiendo dominios de forma alarmante en los últimos tiempos
debido a la cantidad de personas que migran los dominios hacia otros registrars más baratos.
2. Todo registrar autorizado debe tener un convenio con otro registrar, de forma tal que en el
evento inusual de que vayan a la quiebra y tengan que cerrar, los dominios serían asignados
por verisign-grs al registrar de respaldo. Esto es, si hay un registrar X y uno Y, y nosotros
tenemos registrados 200 dominios con Y, y resulta que Y se va a la quiebra, no debemos
preocuparnos, nuestros 200 dominios (y todos los dominios que registró Y) pasarán
automáticamente a ser parte de X el cual nos brindará el mismo nivel de soporte.
Este evento 2 es muy alarmante, un registrar quebrado?! Pero en realidad no ha ocurrido mucho, es
más, sólo conocemos de un caso de un registrar que cerró y los dominios que tenía (pocos pues no
eran muy conocidos) pasaron al registrar de respaldo.
Los dominios se pueden registrar hasta por 10 años consecutivos y por un mínimo de 1 año. Esto
para evitar la especulación de que alguien compre un dominio para un evento que ocurrirá en agosto
(por ejemplo) y en setiembre ya no quiera el dominio, no, un dominio se compra por un año
mínimo, independientemente de qué tiempo se usará.
Los dominios pueden ser transferidos entre registrars, esto es, un dominio que pertenezca a network
solutions (sería el que pierde el dominio, llamado: losing registrar) y lo querramos transferir a enom
(el que gana el dominio, llamado: gaining registrar) seguiría un proceso muy simple. Le solicitamos
la transferencia del dominio en el gaining registrar, este le enviará un mail a los contactos del
dominio, solicitándole que aprueben comenzar la transferencia. Estas personas (los emails listados
en el dominio) al aceptar esta transferencia le indicarán al gaining registrar que se comuniquen con
el losing registrar. Este último, en un plazo de 5 días deberá liberarlo y pasará a control del registrar
que ganó el dominio.
Toda transferencia cuesta el equivalente a un año de registro. Y de hecho al culminar

satisfactoriamente la transferencia, se renovará por todo un año el dominio transferido. Por ejemplo
si ponemos la transferencia el día 10 de octubre del 2005 de un dominio que expira el 15 de julio
del 2008, al culminar la transferencia satisfactoriamente el dominio estaría registrado hasta el 15 de
julio del 2009 (un año completo desde la fecha de expiración anterior del dominio).
Si la transferencia fallase, el dinero no se efectiviza y lo podremos usar para reintentarlo.
Las causas más comunes del fallo de una transferencia son:

1. El dominio expira en menos de 5 días: como el losing registrar lo puede retener por 5 días,
entonces no nos dará tiempo
2. La persona de contacto administrativo que recibe la solicitud de transferencia a propósito o
por error no aprueba el mail de transferencia
3. El dominio se encuentra en estado (status) bloqueado.
Los dominios .com, .net, .org, .biz, .bz y algunos más pueden ser comprados por cualquier persona
natural o jurídica que esté interesada dado que el dominio esté disponible (no tomado).
whois
Básicamente en efecto podemos determinar si un dominio existe yéndonos a un registrar y

preguntando por el dominio. Pero existe una forma más directa y cómoda que es preguntando por el
dominio usando la utilería whois
Esta utilería la podemos instalar con el paquete jwhois
verifiquemos que lo tenemos instalado:

rpm -q jwhois
si no lo tuviéramos podríamos hacerlo con:

yum install jwhois
Una vez verificado y/o instalado, podremos comenzar a preguntar por dominios. Veamos:
whois nuestroserver.com
[Preguntando whois.verisign-grs.com]
[whois.verisign-grs.com]
Whois Server Version 2.0
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to
http://www.internic.net
for detailed information.
Domain Name: NUESTROSERVER.COM
Registrar: ENOM, INC.
Whois Server: whois.enom.com
Referral URL: http://www.enom.com
Name Server: DNS1.NUESTRODNS.COM
Name Server: DNS2.NUESTRODNS.COM
Status: clientTransferProhibited
Updated Date: 19-aug-2008
Creation Date: 13-jul-2005
Expiration Date: 13-jul-2013
>>> Last update of whois database: Mon, 10 Nov 2008 17:50:29 EST
<<<
NOTICE: The expiration date displayed in this record is the date

the
registrar's sponsorship of the domain name registration in the
registry is
currently set to expire. This date does not necessarily reflect
the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois

database to
view the registrar's reported date of expiration for this
registration.
TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-
volume and
automated except as reasonably necessary to register domain names
or
modify existing registrations; the Data in VeriSign Global
Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining
information
about or related to a domain name registration record. VeriSign
does not
guarantee its accuracy. By submitting a Whois query, you agree to
abide
by the following terms of use: You agree that you may use this
Data only
for lawful purposes and that under no circumstances will you use
this Data
to: (1) allow, enable, or otherwise support the transmission of
mass
unsolicited, commercial advertising or solicitations via e-mail,
telephone,
or facsimile; or (2) enable high volume, automated, electronic
processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly

prohibited without the prior written consent of VeriSign. You
agree not to
use electronic processes that are automated and high-volume to
access or
query the Whois database except as reasonably necessary to
register
domain names or modify existing registrations. VeriSign reserves
the right
to restrict your access to the Whois database in its sole
discretion to ensure
operational stability. VeriSign may restrict or terminate your
access to the
Whois database for failure to abide by these terms of use.
VeriSign
reserves the right to modify these terms at any time.
The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
Básicamente aquí podemos obtener toda la información de un dominio, llamado ecualinux.com, si

ustedes desean pueden verificar cualquier otro dominio.
Veamos poco a poco la información interesante, se lee de arriba a abajo y vamos viendo diferentes
detalles de un dominio como:
• Registrant Contact: Es el nombre del dueño, del registrante, de la persona que registra,
normalmente es alguien que tiene relación con la empresa y en última instancia será a quién
se recurra para recuperar información perdida de un dominio o alguna otra situación. Los
datos de los contactos, ya sea el registrante o cualquier otro, deben ser siempre correctos. La
información de contacto siempre consistirá en el nombre de la persona, dirección, teléfono,
país y sobre todo del email mediante el cual se le puede alcanzar.
• Administrative Contact: Es el nombre del contacto administrativo, la persona que se
encarga de manejar el dominio, aprobar cambios realizados, básicamente es el administrador
del dominio, puede ser alguna otra persona, pero sugiero que siempre sea el dueño
(registrant) del contacto. El contacto administrativo es tanto o más importante que el
registrant, pues las solicitudes de transferencias son enviadas al email listado en el contacto
administrativo.
• Technical Contact: Es el nombre del contacto técnico, básicamente no se usa mucho.
Normalmente se pone a la persona que registra el dominio (registrant)
• Billing Contact: Es el nombre de la persona que recibirá las indicaciones de que el dominio
va a expirar y los datos sobre cómo renovarlo. La información de renovación también
llegará al Admin Contact. Pero en caso de que tengamos una empresa grande con un
administrador del dominio y una contadora (o varias) siempre es bueno aqui poner a la
contadora (o contador) para que sepa que no somos alarmistas, que el dominio en efecto está
al expirar y deben hacer el trámite de renovación.
De los anteriormente expuestos, los más importantes son los Registrant (dueño) y Admin (el que
autoriza cambios). Y siempre debemos tener presente que un dominio nuestro o de nuestra empresa
esté registrado correctamente con nuestros datos y no con los de otra persona.
• Status: Es el estado de un dominio, básicamente hay algunos estados pero veamos los más
importantes:
• Locked: Bloqueado, indica que el dominio está activo pero que no se permiten las
transferencias. Esto es para evitar que por error se aprueben las transferencias o que
les vayan a robar un dominio mediante una transferencia maliciosa. Si quisiéramos
transferir un dominio, debemos quitarle el estado de bloqueado y dejarlo en el
estado:
• Active: Es básicamente igual que el anterior, sólo que el dominio no está bloqueado,
es decir, puede ser transferido. Este estado es el que debemos tener cuando queremos
transferir un dominio. Una vez transferido podemos bloquear nuevamente un
dominio. Esto es, los estados Active y Locked son mutuamente exclusivos y
podemos cambiarlos a voluntad entre uno y otro.
• Registrar-Hold: Este es el estado que alcanzan los dominios cuando expiran. Una
vez que un dominio expira, básicamente no puede ser usado a no ser que se le
renueve. Este periodo no tiene fecha exacta pero normalmente está entre los 30 y 120
días después de expirado un dominio. Durante este tiempo podemos renovar al
dominio por el mismo costo que nos tomó registrarlo la primera vez. Durante este
periodo no tenemos el dominio a nuestra disposición, es decir, no lo podemos usar
mientras no lo paguemos la renovación.
• Redemption Period: Periodo de redempcion, es un periodo posterior al registrar-hold
que indica que el registrar ha solicitado que este dominio sea borrado de las listas,
dura 30 días y durante este periodo todavía se puede renovar un dominio pero por un
costo de alrededor de 200usd. Casi nadie saca un dominio de redempción sobre todo
por los altos costos.
• Pending Delete: Es el periodo inmediatamente después del de redemción,
básicamente indica que el dominio ya va a ser borrado. Este periodo dura 5 días y no
se puede sacar un dominio que está en este estado. A los 5 días pasará a
disponibilidad de cualquier interesado.
• Name Servers: Son los servidores de DNS que resolverán las direcciones de nuestro
dominio, podemos tener entre 2 y 13 servidores de dns para cada dominio. Ahora
hablaremos más sobre dns.
DNS:
Las "guías" encargadas de resolver los nombres a direcciones IP (y su reversa) se llaman en la
internet "DNS" que es el acrónimo de Domain Name Servers o Domain Name System.
Básicamente, al inicio de la internet también existió la necesidad de usar algún sistema que
permitiera convertir de un nombre de fácil recordación hacia una dirección IP, para eso se crearon
unas listas que contenían todas las direcciones IP y sus hosts según sus creadores las fueran
necesitando.
Esta lista todavía se usa y se llama hostable, o sencillamente /etc/hosts por el lugar donde están
puestos.
Ahora, sucede que realmente, al seguir creciendo la internet, esta lista se fue haciendo muy grande y
lo peor es que las máquinas que quisieran estar al día necesitaban bajar una vez al día por lo menos
estas listas actualizadas lo que hacía que el tráfico se incrementara y algunas máquinas no pudieran
bajar listas actualizadas. Por supuesto se inventaron sistemas para bajar sólo actualizaciones y
demás, pero aún así se hacía muy inmanejable, ya que en ciertos casos habían máquinas que no
estaban actualizadas pero lo peor era que por cada una de las máquinas que tuviéramos en nuestra
red, debíamos tener una lista actualizada de este /etc/hosts.
Es básicamente lo mismo que ocurre con las guías telefónicas ahora, y es que son muy voluminosas
para manejarse.
El uso de DNS para nuestros dominios deben cumplir dos requisitos fundamentales, estos son:
1. Deben existir al menos dos (2) DNS para un dominio en particular.
2. Los dns de un dominio no deben tener punto de falla en común.
El primer punto es importante, ya que nos indica que no debemos tener un sólo dns para resolver un
dominio, esto por la lógica razón de que si tuviéramos uno y este se nos cayera, nadie podría
acceder a nuestro dominio pues no habría quién nos dijera qué dirección IP es la de nuestro
dominio.
El segundo punto es el más importante y definitivamente es una definición más clara del primero:
no basta con tener dos DNS; si los tenemos en el mismo sitio, si cae un rayo, caerá para ambos, si se
va la luz, se irá para ambos, si se roban uno, mejor se los roban a ambos, y si se cae la conexión de
internet, se caerá para ambos, ya que están ambos en el mismo sitio exactamente.
Es por esto que es necesario, pero imperioso, el tener dns sin punto de falla en común. Esto se logra
buscando redes alternativas donde alojar los DNS.
Verifiquemos los dns de Ecualinux:

Servidor DNS Dirección IP
dns1.name-services.com 69.25.142.1
Si nos fijamos bien, las direcciones IP ni se parecen en lo absoluto unas de otras. Si trazáramos una
ruta desde nuestra máquina hacia cada una de ellas, veremos que al salir de nuestro proveedor,
ninguna de ellas tiene rutas iguales (por supuesto que la ruta de nuestro proveedor seguramente será
una para la salida nuestra).
¿Qué ventaja tiene esto?
Básicamente, su cualquier elemento intermedio (ruteador) de la red que nos permite acceder hacia
un DNS determinado se cayera, es totalmente seguro que es un equipo que no afectará el acceso a
los otros 4 que tenemos.
Si el preguntarle a un DNS falla, los sistemas automáticamente preguntan a cualquier otro dns que
exista y así hasta agotar los dns a preguntar. Por tanto es muy difícil que los 5 DNS nuestros estén
caídos.
En efecto a veces han estado caídos dos o tres, pero el impacto es mínimo y no se nota casi,
precisamente por el hecho de tenerlos distribuidos.
Dónde podemos conseguir DNS distribuidos? En ecualinux.com con cada dominio que registramos,
tenemos incluidos 5 dns totalmente distribuidos en el costo de los dominios.
También podemos usar los dns de www.everydns.net que son gratuitos los primeros 20 dominios y
son distribuidos también.
TAREA: ¿Qué podemos decir de los dns de?:
elcomercio.com
Sugerencia: usemos el comando traceroute para trazar una ruta hacia una dirección IP determinada.
Como sugerencia aqui les mando la ruta de ambos dns del comercio:
NS.ACCESSINTER.NET (64.46.64.254) dns.elcomercio.org (64.46.84.2)
1 67.15.12.1 1 67.15.12.1
2 66.98.241.4 2 66.98.241.4
3 129.250.10.105 3 129.250.10.105
4 129.250.2.50 4 129.250.2.50
5 129.250.3.21 5 129.250.3.21
6 204.255.174.229 6 204.255.174.229
7 152.63.103.77 7 152.63.97.57
8 152.63.86.185 8 152.63.81.82
9 152.63.101.45 9 152.63.101.41
10 152.63.83.181 10 152.63.83.177
11 206.113.90.210 11 206.113.90.210
12 63.245.64.230 12 63.245.64.230
13 208.29.133.10 13 208.29.133.10
14 64.46.86.254
15 64.46.64.254
Tipos de DNS
Los DNS se clasifican en dos tipos fundamentales:

1. DNS de caché (o forward)
2. DNS de zona
Los DNS de caché son aquellos que no contienen zonas, por zonas se entienden básicamente los
records que componen un dominio, al no contener zonas (dominios) ellos tienen que preguntar a
otros.
Estos DNS son importantísimos, son los que usamos normalmente para preguntar por dominios en
internet, por ejemplo, cuando preguntamos por www.google.com no le preguntamos a los DNS que
tiene listado el dominio google.com sino que le preguntamos a unos DNS definidos por el
administrador de nuestra red o por nuestro proveedor. Estos son los dns de caché.
Estos DNS a su vez, verificarán con los root servers, cuáles son los DNS que google tiene listado
para su dominio google.com y entonces acudirán prestos a preguntarle a uno de esos DNS sobre el
sitio www.google.com.
Por supuesto, si uno de esos DNS estuviera caído, nuestro DNS de caché ya tiene una lista de los
DNS de google y por lo tanto le procederá a preguntar a otro y a otro, hasta alcanzar la respuesta.
Los DNS de caché tienen una peculiaridad, es que no usan disco, básicamente ellos almacenan toda
la información que vamos preguntando, con el objetivo de que si la preguntamos de nuevo, ellos no
tengan que salir a buscarla, sino que inmediatamente la obtienen de su caché. Es por eso que se
llaman DNS de caché.
Tienden a usar toda la memoria disponible, pero realmente no consumen mucha memoria, porque
los tamaños de las respuestas son pequeños.
Por supuesto un proveedor de internet debe tener al menos dos DNS de caché los que seguramente
sí consumirán memoria pues almacenarán records de muchos miles de usuarios. Pero normalmente
con menos de 1GB de memoria basta.
Los records cacheados son refrescados cada vez que el tiempo de vida de los records se cumplen.
Este valor se llama TTL y ya veremos cómo ponerlo. Un TTL adecuado puede ser 2 horas
(7200segundos) pero algunas personas gustan de usar un día (86400segundos). El problema de un
TTL de un día es que si decidimos cambiar de IP, no podremos hacerlo rápidamente pues algunos
DNS de caché tendrán una respuesta cacheada por un día y durará un día el cambio de IP.
Es por esto último que algunos proveedores dicen que el cambio de DNS toma 24 horas o más, es
porque el TTL puede ser alto y al estar cacheado por cientos o miles de DNS alrededor del mundo,
estos no volverán a preguntar por ese record en un día ya que considerarán válida una respuesta
mientras el TTL no sea cero.
Cómo montamos un servidor de caché? Es muy simple, sencillamente tenemos que asegurarnos de
que los siguientes paquetes estén instalados:
• bind
• bind-chroot
• caching-nameserver
y por supuesto tener levantado el servicio named:
chkconfig --level 2345 named on
service named start
Con esto tendremos un servidor de dns de caché activo. Entonces, cualquier máquina que use a
nuestro servidor linux como un servidor de DNS (es decir, cualquier máquina windows o linux que
tenga definido como DNS a nuestro servidor linux) podrá preguntar por cualquier dominio de
internet y recibir una respuesta.
Cómo le indicamos a un servidor linux qué servidor de DNS de caché usar?
En el archivo:
/etc/resolv.conf
Podemos tener hasta 255 lineas que comiencen con "nameserver" estos son los servidores de DNS a
los que nuestro servidor preguntará sobre un record.
Por ejemplo, pongamos en la segunda línea:
nameserver 127.0.0.1
esto significará que primero pregunte a localhost (a nuestro mismo servidor dns) sobre cualquier
record requerido. Si no lo encontrara, que pregunte a los siguientes en la lista. Posiblemente los
siguientes serán los dns que nuestro proveedor nos dió.
Records de un DNS
Las respuestas de los DNS se definen según un concepto que se llama records. Cada record se
refiere a una propiedad de una zona (dominio) y tiene diferentes valores.
Por ejemplo, los records más conocidos son:

• SOA : Start Of Authority, define los valores comunes e iniciales para una zona determinada.
Estos valores son un número de identificación, el nombre del contacto para esa zona y
algunos valores por defecto como el tiempo de vida de los records, de la zona, etc.
• A : Es quizá el record más usado, y el más fácil de entender, definitivamente define dado un
nombre, su dirección IP. Es básicamente el concepto fundamental de los DNS. Cuando
preguntas por www.ecualinux.com realmente estás preguntando por el record A de www de
la zona ecualinux.com y nos devolverá una dirección IP (o varias) que se correspondan con
www.ecualinux.com
• CNAME : Es un concepto que personalmente me disgusta, pero indica un alias, una forma
de referirte a un dominio. Básicamente podemos decir que mail.ecualinux.com es un
CNAME que apunta a www.ecualinux.com. Esto genera dos búsquedas y es por eso que no
me gusta, una búsqueda preguntará por mail.ecualinux.com y obtendrá no una dirección IP,
sino obtendrá un apuntador, algo que le dirá: mira, busca en www.ecualinux.com y entonces
tendríamos que preguntar de nuevo por el record A de www.ecualinux.com para obtener la
IP. Es como un enlace directo, una forma de referirte a un sitio web o record de muchas
formas. Personalmente prefiero definir un record A por cada record que querramos y no
estarlos enlazando mediante CNAMES.
• MX : Es el segundo más importante después del A. Significa Mail eXchange,
intercambiador de mails. Es el record al que los sistemas de mensajería se referirán al
encontrar la necesidad de enviar un mail. Los records MX se componen de dos respuestas:
El record A del servidor de mensajería y un peso o prioridad. Esta prioridad existe ya que
algunos sistemas de mensajería no tienen un sólo servidor de mensajería sino varios, y se les
pone prioridad para indicarle a los sistemas remotos cuál será el servidor prioritario, el
principal, ese servidor será el que menos valor tenga. El que un servidor tenga peso 10 no
significa que el mensaje llegará más lento o más rápido. Sencillamente este peso permitirá a
los servidores remotos ordenar los potenciales servidores y tratar de enviar los mails en ese
orden. Es un concepto que se usa poco, pero vale la pena conocerlo.
Verifiquemos ahora algunos servidores, para realizar preguntas sobre DNS podemos hacerlo con el
comando: nslookup
por defecto nslookup abre y cualquier pregunta que hagamos la hace en records A.
Si lo ejecutamos sencillamente como nslookup, él se intentará conectar al primer servidor DNS que
tengamos definido en /etc/resolv.conf
Si quisiéramos hacerle preguntas específicas a un determinado servidor de DNS podríamos hacerlo

con:
nslookup - IPDELSERVIDORAPREGUNTAR
Esto sirve a veces cuando tenemos duda de que un servidor no funciona y queremos verificarlo a él,
o queremos verificar contra otro.
En el caso nuestro del CEC, debido a que nuestras máquinas no tienen salida directa a internet, si
quisiéramos preguntar sobre un dominio externo, deberemos preguntarle al DNS que el CEC nos
brinda.
Comencemos, usemos el nslookup para preguntar por algunos records A, en mi caso se verá así:
nslookup
> www.elcomercio.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: www.elcomercio.com
Address: 69.65.159.179
Pregunté por www.elcomercio.com
El servidor al que se le hizo la pregunta fué 127.0.0.1 (mi propia máquina).
La respuesta que se obtuvo fué no autoritativa, esto es, la respuesta no estaba en el DNS nuestro
(127.0.0.1 en mi caso) sino que estaba en un DNS externo.
Nuestro nslookup mandó a nuestro servidor de DNS (127.0.0.1) a buscar a internet, éste preguntó a
los rootservers sobre los dns de elcomercio.com y le preguntó a uno de los DNS de elcomercio.com
sobre el record A llamado: www
La respuesta fué que www.elcomercio.com (record A www, de la zona elcomercio.com) es:

69.65.159.179
Normalmente cualquier aplicación que pregunte por un record A, usará esta IP para dirigirse hacia
el sitio del dominio en cuestión.
Preguntemos algo más:

www.ecualinux.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: www.ecualinux.com
Address: 209.172.33.209
Lo mismo de elcomercio.com, preguntará a 127.0.0.1 (nuestro servidor) sobre ecualinux.com y
nuestro servidor dirá que no tiene la zona en su control y por lo tanto la respuesta salió a buscarla
(non-authoritative), y que la respuesta que encontró fue: 209.172.33.209 para el record A www de
la zona ecualinux.com
Preguntemos ahora sobre un record MX, lo primero que hay es que cambiar el tipo de A hacia MX
[root@linuxcasa ~]# nslookup
> set type=mx
> ecualinux.com
Server: 127.0.0.1
Address: 127.0.0.1#53
ecualinux.com mail exchanger = 10 mail.ecualinux.com.
Authoritative answers can be found from:
ecualinux.com nameserver = dns4.name-services.com.
dns1.name-services.com internet address = 69.25.142.1
set type=mx cambiará las preguntas a tipo MX. Los records MX se preguntan para los dominios,
solo para LOS DOMINIOS. por lo tanto cuando pregunten por un record mx no pongan www ni
mail, sólo pongan el nombre del dominio.
La respuesta básicamente dice que para la zona ecualinux.com el mail exchanger tiene un peso 10 y
es el record A: mail.ecualinux.com
Esto es, tengo un sólo servidor de mensajería para mi dominio que tiene un peso 10 y es
mail.ecualinux.com
el segundo paso que haría un sistema de mensajería es averiguar el record A de mail.ecualinux.com

para poderse conectar a enviar el correo.
El que tenga el peso 10 no significa que el correo llegará más lento que si tuviera el peso 0 o 5,
sencillamente es un valor que permitiría ordenar los MX en caso de haber más de uno. En mi caso
hay sólo uno, por qué no le pongo 0?
Hay una razón, y es que los pesos van de 0 a 255
Si tengo 0 como peso y un día tengo una necesidad imperiosa de insertar un nuevo servidor MX
delante del servidor actual tendría que primero cambiar el peso de este servidor actual hacia otro
valor pues no puedo poner nada menor a 0. Es por esto que un valor como 5 o 10 sería bueno, pues
en caso de emergencia podemos poner uno o varios valores delante.
Es un caso bien raro, realmente nunca lo he usado, pero esto no significa que no pueda existir una
situación así.
TAREA: Revisar los mx y A de algunos sitios conocidos por ustedes.
Ahora, ya sabemos que existen records A, SOA, CNAME, MX, etc. Dónde podemos definir estos
records?
Para eso tenemos que trabajar lo que son los DNS de zona. Estos DNS son los que contienen
información específica sobre una zona. Cuando uno compra un dominio, básicamente le define los
DNS de zona que manejarán este dominio, una vez comprado el dominio, tenemos que
inmediatamente crear en esos DNS definidos por nosotros las zonas del dominio.
Los DNS de zona se dividen en dos tipos:

• DNS máster (maestro, principal)
• DNS esclavo (slave, secundario)
Los DNS de un mismo dominio, deben mantener la información sincronizada entre ellos para que
las respuestas sean consistentemente las mismas independientemente de a cual de los DNS de un
dominio le preguntemos.
Cómo se mantiene la información sincronizada? Básicamente, dados los DNS que tenemos para un
dominio (supongamos que tendremos dos) definimos un DNS como maestro o máster, de ser
posible que sea el que mejor conectividad tenga y al segundo (en general a todos los otros) le
definimos como esclavo para la zona.
Esclavo significa que este DNS no lo tendremos que configurar, cualquier cambio que hagamos en
el máster, enseguida se reflejará de forma automática en el esclavo. El esclavo siempre estará atento
a cualquier cambio en su DNS principal, de ocurrir, él replicaría esta información en su base de
datos.
De esta forma no tenemos inconsistencias, si algo está mal en nuestro DNS primario igual de mal
estará en los esclavos. Si algo cambiamos o corregimos en el master, enseguida los esclavos lo
cambiarán o corregirán. Así nos ahorramos tener que cambiar todos y cada uno de los DNS de un
dominio y con sólo cambiar el máster sabremos que los esclavos tomarán los datos.
Definiendo un DNS máster

Para definir un DNS máster tenemos que hacer dos acciones principales:
1. Tenemos que definir una nueva zona indicando el nombre del dominio que vamos a alojar y
que será máster.
2. Para la zona en cuestión, debemos agregar los records necesarios o requeridos por nosotros.
Ahora, manejar un archivo de zonas es un tema bien difícil, yo prefiero que instalemos el webmin,
que es una herramienta via web que nos permite configurar muchísimos parámetros para manejar el
sistema, entre ellos los DNS:
yum install webmin
Se nos demorará un poco, pero al final podremos entrar al webmin usando nuestro browser y
apuntando a:
https://127.0.0.1:10000
Esto nos mostrará la pantalla de login del webmin, por defecto usaremos root y la clave de root de
nuestra máquina:
Aqui podemos agregar todos los records que nosotros necesitemos para un dominio.
Al entrar veremos diferentes TABS (ver arriba en el webmin), el módulo para adminitrar los DNS
lo tendremos en el TAB "servers", vayamos allá, el módulo en cuestión se llama "Bind DNS
Server"
Una vez entremos, veremos la siguiente configuración:
Para crear una zona master, sencillamente hacemos click en el enlace de abajo que dice: Create
Master Zone
Una vez en Create Master Zone, nos pedirá una serie de datos, los más importantes son el nombre
del dominio que pondremos (sin www ni nada, sólo nombre de dominio!) que va en el box llamado:
Domain name / Network y el email del contacto administrativo (Email address), los demás
valores, por favor dejarlos intactos.
De estos otros valores, podremos observar 3 que son de potencial interés:

• Transfer Retry Time: Cuando un DNS esclavo no pueda contactar al master para este
dominio, le indicamos que espere esta cantidad de segundos (3600 por defecto) para volver a
intentar transferir la zona. Transferir=obtener los datos de la zona
• Expiry time: En caso de que haya pasado este tiempo (604800 segundos) sin haber podido
contactar al master, el esclavo deberá desechar los datos. Los datá por expirados.
• Default Time To Live: este es el TTL que se le dará a cualquier DNS que pregunte sobre
cualquier record de nuestro dominio. Por defecto está en 38400 (cerca de 10 horas), yo
realmente prefiero usar 7200 (2 horas), cambiemos a 7200 este valor.
Una vez hayamos puesto el email, el nombre del dominio y hayamos cambiado el default TTL,
procedamos a apretar en el botón Create
Veremos que ahora estamos ya dentro de la zona que recién creamos y que podemos crear ya los
diferentes records (A, MX son los que nos interesan), se verá una pantalla así para mi zona de
prueba: "dominio.com"
Sugiero siempre agregar los siguientes records:

RECORD TIPO VALOR
www.dominio.com. A ip del servidor www
mail.dominio.com. A ip del servidor de mail.dominio.com.
ftp.dominio.com. A ip del servidor de ftp.dominio.com.
dominio.com. A ip del servidor www.dominio.com.
dominio.com. MX 10 mail.dominio.com.
Las dos últimas al no tener valor en RECORD se refieren al dominio en sí. Esto es, sencillamente
estamos hablando de nuestro dominio (dominio.com en el caso de ejemplo)
Al hacer click sobre el ícono A iremos a la parte de creación de records A, al hacer click sobre MX
iremos a la creación de MX.
A propósito, si se han fijado bien, habrán notado que siempre me refiero a los subdominios con su
dominio incluido ( no www sino www.dominio.com) y que a la final de cualquier nombre ponemos
un .
De no poner el punto, le estaremos indicando al webmin que complete este record con el nombre
del dominio. Es decir si pusiéramos www.dominio.com sin el punto, el webmin pensará que es
www.dominio.com.dominio.com. es decir, le agregará el nombre del dominio.
El punto sirve para deternerlo, le estamos dicienteo que es exactamente eso y punto, no más.
Al agregar los Records A, por favor hagámoslo con la IP de nuestra máquina.
A la final de agregar todos los records A veremos algo así:

Básicamente definimos 4 records A www.dominio.com, ftp.dominio.com, mail.dominio.com y
dominio.com
esto nos servirá para que cualquier persona que pregunte sobre cualquiera de esos records de mi
dominio, reciban una respuesta adecuada. Cualquier record que no hayamos definido no podrá ser
usado por nadie.
Agreguemos el MX (Return to Record Types -> icono de MX)
Lo que hicimos fue en el nombre poner el nombre de nuestro dominio y en el mailserver poner el
record A por el que se debe preguntar para enviar los mails a mi dominio. En priority, poner el peso
o prioridad de este servidor.
Listo, con estos sencillos pasos logramos configurar los records más usados para cualquier dominio
de internet, por supuesto si tenemos necesidad de algún otro record o necesitamos apuntarlos a
alguna otra IP, somos libres de hacerlo, siempre planificadamente para no pasar sustos.
Los DNS son la base de la internet, y su incomprensión es lo que acarrea un mal uso de ellos y
normalmente son el servicio que genera la mayor cantidad de quejas por parte de los usuarios.
Realmente los usuarios no se dan cuenta de que es el dns el que falla, ellos sólo notan que una
página no se abre o dá timeout... pero esos son síntomas de que un dns anda dando respuestas
malas.
Para verificar las respuestas de un DNS podemos usar: www.squish.net/dnscheck
Una vez creados todos los records y zonas que querramos, podemos ir a la lista de zonas (ver enlace
al final de cada página del webmin) y apretar en el botón aplicar. Por favor hacerlo en la página
principal del bind, donde se muestran todas las zonas.
El bind no actualiza los datos instantáneamente, esto es, hasta que no hagamos click en "Apply
Changes" el bind no tomará estos cambios. Cada cambio que hagamos, también debemos ir a
apretar apply changes o sino, no tomará los cambios hasta que se reinicie el bind.
TAREA: con nslookup - 127.0.0.1 preguntarle a nuestro DNS (127.0.0.1) sobre los nuevos records
creados. Todos deben responder bien.
Definiendo un DNS esclavo
Definir un DNS esclavo es una tarea fácil, desde una segunda máquina, sencillamente apretamos el
enlace que dice: Create slave zone
El DNS esclavo requiere de solamente dos datos:

1. nombre de la zona para la que seremos esclavos (Domain name / Network)
2. nombre del servidor que será nuestro master (Master servers)
Existe un pequeño problema y es que el webmin escribe las zonas esclavas en

/var/named/chroot/var/named/slaves pero el dueño es root, por lo tanto la primera vez que hagamos
esto, debemos ponerle a este directorio a named como dueño, porque named escribe temporalmente
los datos de la zona en un archivo por si acaso hay que reiniciar el servidor, que queden
permanentemente los datos para cuando levante:
chown named.named /var/named/chroot/var/named -R
Esto nos cambiará al usuario named el directorio /var/named/chroot/var/named pues sino, no se

podrán escribir los datos de las zonas esclavas.
TAREA: Para cada una de las zonas máster de las otras máquinas del curso (todas menos la de
usted mismo) definirnos como esclavos.
Tema 2
Instalación
Instalar un servidor DNS de Caché es una de las tareas más importantes en nuestra red.
Instalar los paquetes de bind:

yum -y install bind-chroot caching-nameserver
Estos son los paquetes necesarios para el uso de un servidor de caché.

Configuración
Named trabaja enjaulado en el directorio /var/named/chroot/ por lo tanto las referencias que se
realicen dentro de los archivos de configuración son relativas a /var/named/chroot/
El servicio de named en centos-5 no viene con un archivo de configuración predefinido, por lo tanto
hay que cambiarse al directorio de configuración (/var/named/chroot/named/etc) y crear un archivo
llamado named.conf:
cd /var/named/chroot/etc
vi named.conf
En este archivo sólo cambiamos las dos líneas que van en rojo, las cuales indican las redes
autorizadas a hacer preguntas (Queries)
options {
allow-recursion {
192.168.0.0/24; 127.0.0.1; };
allow-query { 192.168.0.0/24; 127.0.0.1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt"; };
zone "." IN {
type hint;
file "named.ca";
};
zone "localdomain." IN {
type master;
file "localdomain.zone";
allow-update { none; };
};
zone "localhost." IN {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa." IN {
type master;
file "named.local";
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." IN {
type master;
file "named.ip6.local";
};
zone "255.in-addr.arpa." IN {
type master;
file "named.broadcast";
};
zone "0.in-addr.arpa." IN {
type master;
file "named.zero";
};
include "/etc/rndc.key";
Activar el servicio
chkconfig --level 2345 named on
service named start
Con esto ya tenemos configurado nuestro servidor de DNS de caché, sólo nos queda usarlo.
Ahora en cada máquina de la red local nuestra debemos especificar que el servidor DNS de ellas es
la IP de nuestro linux. Con esto tendremos un DNS De caché en nuestra red y habremos ahorrado
tiempo y ancho de banda.
Tema 3
Maestro
El siguiente ejemplo es para un supuesto dominio llamado: dominio.com en rojo remarcamos el
ejemplo. En el caso de que usted haya adquirido un dominio, debe sustituir el nombre en rojo del
ejemplo por su propio dominio.
Al final de /etc/named.conf agregar:

zone "dominio.com" IN {
type master;
file "/var/named/dominio.com.hosts";
// Esto es solo si tenemos un esclavo
allow-transfer { 192.168.0.101; };
};
En /var/named/chroot/var/named/dominio.com.hosts
$ttl 7200
dominio.com. IN SOA localhost.localdomain. mi.email.com. (

2008010701
10800 ; Tiempo de refrescamiento
3600 ; Tiempo de reintento si falla el refresh
604800 ; Tiempo para mantener los esclavos su info si no contactan al master
7200 ) ; TTL
dominio.com. IN NS localhost.localdomain
www IN A 192.168.0.89
mail IN A 192.168.0.89
ftp IN A 192.168.0.89
dominio.com. IN MX 5 mail.dominio.com.
dominio.com. IN A 192.168.0.89
Activar el servicio de named:

service named start
chkconfig named on
Cada cambio que se realice en el named requiere que recarguemos (reload) o reiniciemos (restart) el
named.
Esclavo:
En /etc/named.conf agregar:
zone "dominio.com" IN {
type slave;
file "slaves/dominio.com.zone";
// Esta es la IP del master
masters { 192.168.0.89; };
};
Activar el servicio de named:

service named start
chkconfig named on
Tema 4
1. ¿ Qué podemos decir de los dns de elcomercio.com ?. Sugerencia: usemos el comando

traceroute para trazar una ruta hacia una dirección IP determinada.
2. Revisar los mx y A de algunos sitios conocidos por ustedes.
3. Crear la zona master en cada equipo y con nslookup - 127.0.0.1 preguntarle a nuestro DNS
(127.0.0.1) sobre los nuevos records creados. Todos deben responder bien.
4. Para cada una de las zonas máster de las otras máquinas del curso (todas menos la de usted
mismo) definirnos como esclavos.
Tema 5
Servidor HTTP (Apache)
El Servidor Apache HTTP es un servidor Web de tecnología Open Source sólido y para uso
comercial desarrollado por la Apache Software Foundation (http://www.apache.org). Red Hat
Enterprise Linux incluye el Servidor Apache HTTP versión 2.0 así como también una serie de
módulos de servidor diseñados para mejorar su funcionalidad.
El archivo de configuración predeterminado instalado en el Servidor Apache HTTP funciona sin
necesidad de modificarlo, en la mayor parte de los casos. Este capítulo da una idea general de las
directrices dentro de este archivo de configuración (/etc/httpd/conf/httpd.conf) para
ayudar a aquellos que requieren una configuración personalizada.
Características del Servidor Apache HTTP 2.0
El Servidor Apache HTTP 2.0, incluye las siguientes funcionalidades:
• Los módulos Apache API se utiliza un nuevo conjunto de interfaces de programación de
aplicaciones (APIs).
• Filtrado Los módulos pueden actuar como filtros de contenido.
• Soporte a IPv6 Se soporta la próxima generación de formato de direcciones IP.
• Directrices simplificadas Se han eliminado una serie de directrices complicadas y otras se
han simplificado.
• Respuestas a errores en diversos idiomas Cuando usa documentos Server Side Include
(SSI), las páginas de errores personalizables se pueden entregar en diversos idiomas
En el siguiente sitio web se muestra una lista completa de los cambios realizados:
http://httpd.apache.org/docs-2.0/.
Cambios en los paquetes del Servidor Apache HTTP 2.0

A partir de la versión 3 de Red Hat Enterprise Linux, los paquetes del Servidor Apache HTTP han
sido renombrados. Además otros paquetes se han eliminado, renombrado y otros se han introducido
en otros paquetes.
La siguiente lista contiene los cambios de los paquetes:
• Los paquetes apache, apache-devel y apache-manual, fueron renombrados a
httpd, httpd-devel y httpd-manual repectivamente.
• Se ha incorporado el paquete mod_dav en el paquete httpd.
• Los paquetes mod_put y mod_roaming se han eliminado, ya que su funcionalidad
aparece recogida en mod_dav (el cual forma parte ahora del paquete httpd).
• Los paquetes mod_auth_any y mod_bandwidth se han eliminado.
• El número de versión del paquete mod_ssl se ha sincronizado con el paquete httpd. Esto
significa que el paquete mod_ssl para el Servidor Apache HTTP 2.0 tiene un número de
versión menor que el paquete mod_ssl del Servidor Apache HTTP 1.3.
Otros servidores web (httpd)

Aparte del servidor apache, existen una serie de servidores web para linux, aunque debemos hacer
notar que apache ocupa un enorme porcentaje del mercado, superando a cualquier otro servidor web
de cualquier otro SO por la cantidad de sitios web que maneja.
• thttpd: Es un servidor web pequeño, no supera los 1024KB de tamaño. Ligero y rápido
• tux: Es un servidor web embebido en el kernel, sólo sirve páginas web estáticas y es
extremadamente simple pero muy rápido en su trabajo
• boa: miniservidor, extremadamente simple y rápido
• LightTPD: servidor que clama ser super rápido, más que apache y muy fácil de configurar
respecto al tux. También es capaz de trabajar con cgi.
Popularidad del apache
El apache es extremadamente popular, sobre todo porque es un servidor web portable entre
diferentes plataformas de sistemas operativos, tales como windows, linux, bsd, digital, sco, etc.
El sitio de internet www.netcraft.com se dedica a realizar diversos análisis del comportamiento de

la internet, registro de dominios y servidores de internet determinó en Noviembre del 2005 que el
apache era el servidor web que más sitios web alojaba, y que se mantenía con un incremento ligero
con respecto a análisis pasados.:
http://news.netcraft.com/archives/2005/11/07/november_2005_web_server_survey.html
Como podemos observar, el apache ocupa casi un 70% del mercado de alojamiento de sitios web. Si
se fijan el más cercano tiene un 20% del mercado y es el IIS, los demás son muy pequeños para
contar.
El apache basa su popularidad, como ya habíamos dicho en:

1. Portabilidad: Puede ser instalado en casi cualquier sistema operativo
2. Modularidad: Acepta la instalación de módulos realizados por terceras personas para
agregarle funcionalidad
3. Facilidad de configuración
4. Independencia de los lenguajes de generación de páginas: Esto es, los lenguajes que se usan
para programar en web son independientes del apache, por lo que cualquier lenguaje que su
autor decida, puede ser modularizado (ver punto 2) y usado para generar páginas web.
El apache tiene las siguientes características:
• Soporte de scripts del tipo CGI (Common Gateway Interface).
• Dispone del llamado DSO (Dynamic Shared Object) que permite la carga y descarga de
módulos de forma dinámica.
• Soporta lenguajes Perl y Php entre otros.
• Permite autentificación con contraseña.
• Puede manejar varios sitios web, tantos como el sistema operativo pueda aguantar.
• Soporta código XML
• Permite conexiones encriptadas vía SSL
• Permite ejecutar código generado usando la tecnología .NET
tema 6
Apache no es un sólo servidor que podemos instalar desde un paquete, en realidad apache hace uso
de una variedad de paquetes que le permiten ofrecer diferentes funcionalidades a nuestro servidor
web.
Para instalar el servidor apache, sencillamente podemos:

yum install httpd php
yum install php httpd
Setting up Install Process
Setting up repositories
dag 100% |=========================| 1.1 kB 00:00
update 100% |=========================| 951 B 00:00
base 100% |=========================| 1.1 kB 00:00
addons 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package php.i386 0:4.3.9-3.8 set to be updated
---> Downloading header for httpd to pack into transaction set.
httpd-2.0.52-19.ent.cento 100% |=========================| 61 kB 00:27
---> Package httpd.i386 0:2.0.52-19.ent.centos4 set to be updated
--> Running transaction check
--> Processing Dependency: php-pear for package: php
--> Processing Dependency: libaprutil-0.so.0 for package: httpd
--> Processing Dependency: httpd-suexec for package: httpd
--> Processing Dependency: libapr-0.so.0 for package: httpd
--> Processing Dependency: apr >= 0.9.4-24.2 for package: httpd
--> Restarting Dependency Resolution with new changes.
---> Downloading header for apr-util to pack into transaction set.
apr-util-0.9.4-21.i386.rp 100% |=========================| 5.2 kB 00:01
---> Package apr-util.i386 0:0.9.4-21 set to be updated
---> Downloading header for httpd-suexec to pack into transaction set.
httpd-suexec-2.0.52-19.en 100% |=========================| 21 kB 00:05
---> Package httpd-suexec.i386 0:2.0.52-19.ent.centos4 set to be updated
---> Downloading header for php-pear to pack into transaction set.

php-pear-4.3.9-3.8.i386.r 100% |=========================| 32 kB 00:09
---> Package php-pear.i386 0:4.3.9-3.8 set to be updated
---> Downloading header for apr to pack into transaction set.
apr-0.9.4-24.5.i386.rpm 100% |=========================| 7.4 kB 00:02
---> Package apr.i386 0:0.9.4-24.5 set to be updated
Dependencies Resolved
=============================================================================
Package Arch Version Repository Size
=============================================================================
Installing:
httpd i386 2.0.52-19.ent.centos4 base 886 k
php i386 4.3.9-3.8 base 1.3 M
Installing for dependencies:
apr i386 0.9.4-24.5 base 88 k
apr-util i386 0.9.4-21 base 51 k
httpd-suexec i386 2.0.52-19.ent.centos4 base 27 k
php-pear i386 4.3.9-3.8 base 265 k
Transaction Summary
=============================================================================
Install 6 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 2.6 M
Is this ok [y/N]: y
Downloading Packages:
(1/6): apr-util-0.9.4-21. 100% |=========================| 51 kB 00:07
(2/6): httpd-suexec-2.0.5 100% |=========================| 27 kB 00:04

(3/6): php-4.3.9-3.8.i386 100% |=========================| 1.3 MB 03:08
(4/6): httpd-2.0.52-19.en 100% |=========================| 886 kB 03:54
(5/6): php-pear-4.3.9-3.8 100% |=========================| 265 kB 00:57
(6/6): apr-0.9.4-24.5.i38 100% |=========================| 88 kB 00:24
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing: apr ######################### [1/6]
Installing: apr-util ######################### [2/6]
Installing: httpd ######################### [3/6]
Installing: httpd-suexec ######################### [4/6]
Installing: php-pear ######################### [5/6]
Installing: php ######################### [6/6]
Installed: httpd.i386 0:2.0.52-19.ent.centos4 php.i386 0:4.3.9-3.8
Dependency Installed: apr.i386 0:0.9.4-24.5 apr-util.i386 0:0.9.4-21

httpd-suexec.i386 0:2.0.52-19.ent.centos4 php-pear.i386 0:4.3.9-3.8
Complete!
Con esto logramos instalar algunos paquetes adicionales como php-pear, apr, apr-utils, httpd-
suexec, etc.
Básicamente el php es el lenguaje de programación web más usado para la programación en Linux,
por eso pido que se instale.
A medida que vayamos requiriendo paquetes los podremos ir instalando independientemente.
Si deseáramos usar bases de datos en nuestro servidor, sugiero también instalar los paquetes: php-
mysql y mysql-server
yum install php-mysql mysql-server
dag 100% |=========================| 1.1 kB 00:00

update 100% |=========================| 951 B 00:00
base 100% |=========================| 1.1 kB 00:00
addons 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
---> Downloading header for mysql-server to pack into transaction set.
mysql-server-4.1.12-3.RHE 100% |=========================| 28 kB 00:06
---> Package mysql-server.i386 0:4.1.12-3.RHEL4.1 set to be updated
---> Downloading header for php-mysql to pack into transaction set.
php-mysql-4.3.9-3.8.i386. 100% |=========================| 17 kB 00:08
---> Package php-mysql.i386 0:4.3.9-3.8 set to be updated
--> Processing Dependency: perl-DBD-MySQL for package: mysql-server
--> Processing Dependency: perl(DBI) for package: mysql-server
--> Processing Dependency: libmysqlclient_r.so.14 for package: mysql-server
--> Processing Dependency: libmysqlclient.so.14 for package: mysql-server
--> Processing Dependency: perl-DBI for package: mysql-server
--> Processing Dependency: mysql = 4.1.12-3.RHEL4.1 for package: mysql-server
--> Processing Dependency: libmysqlclient.so.14 for package: php-mysql
--> Restarting Dependency Resolution with new changes.
---> Downloading header for perl-DBD-MySQL to pack into transaction set.
perl-DBD-MySQL-2.9004-3.1 100% |=========================| 5.4 kB 00:06
---> Package perl-DBD-MySQL.i386 0:2.9004-3.1 set to be updated
---> Downloading header for mysql to pack into transaction set.

mysql-4.1.12-3.RHEL4.1.i3 100% |=========================| 35 kB 00:08
---> Package mysql.i386 0:4.1.12-3.RHEL4.1 set to be updated
---> Downloading header for perl-DBI to pack into transaction set.
perl-DBI-1.40-8.i386.rpm 100% |=========================| 11 kB 00:04
---> Package perl-DBI.i386 0:1.40-8 set to be updated
=============================================================================
=============================================================================
Installing:
mysql-server i386 4.1.12-3.RHEL4.1 base 6.7 M
php-mysql i386 4.3.9-3.8 base 34 k
Installing for dependencies:
mysql i386 4.1.12-3.RHEL4.1 base 2.8 M
perl-DBD-MySQL i386 2.9004-3.1 base 111 k
perl-DBI i386 1.40-8 base 466 k
Transaction Summary
=============================================================================
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 10 M
Is this ok [y/N]: y
El trabajo con bases de datos no lo veremos, pero básicamente esto es un gran paso de avance, pues
el resto sería configurarle accesos a la BD y estudiar cómo conectarnos a la BD desde nuestro
lenguaje de programación web (php).
Activando automáticamente el servicio apache
Activar el servicio es muy simple:
chkconfig --level 2345 httpd on
service httpd start
Si deseamos activar mysql:

chkconfig --level 2345 mysqld on
service mysqld start
El php y cualquier lenguaje de programación no es necesario activarlo como servicio pues ellos son
módulos del httpd y por lo tanto se activarán al activarse httpd.
Configurando el servicio httpd

Una vez instalado apache podemos proceder a revisar la configuración.
La configuración de apache está situada fundamentalmente en el directorio /etc/httpd
Dentro de /etc/httpd, veremos dos directorios básicos de configuración que son:

conf/
conf.d/
En el directorio conf.d se ponen los archivos particulares de configuración para cualquier módulo o
aplicación que corra vía apache. Estos archivos de configuración deben tener de extensión .conf
En el directorio conf tendremos el archivo básico, fundamental, de configuración que es httpd.conf.
Por defecto el apache viene configurado para trabajar sin tenerse que modificar, pero siempre es
bueno comprender un poquito el archivo de configuración:
Veamos este archivo: /etc/httpd/conf/httpd.conf , en este caso he dejado solamente las directivas de
configuración que nos interesa ver. Hemos removido los comentarios para facilitar la lectura:
### Section 1: Global Environment
ServerTokens OS
#Listen 12.34.56.78:80
Listen 80
#ServerName new.host.name:80
DocumentRoot "/var/www/html"
DirectoryIndex index.html index.html.var
# LogLevel: Control the number of messages logged to the error_log.

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn
Alias /icons/ "/var/www/icons/"
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

AddDefaultCharset ISO-8859-1
Aunque existen una enorme cantidad de directivas de configuración del apache, las cuales podemos
leer y estudiar en los mismos comentarios del archivo de configuración y/o en el sitio web de
apache, yo considero importante estudiar las siguientes:
• ServerTokens: Indica qué datos muestra el servidor cuando se realiza una conexión. Por
defecto apache muestra la versión del servidor apache, la versión del Sistema Operativo, etc.
básicamente expone mucha información sobre el sistema que no tiene por qué conocerse.
Por esto, sugiero en este parámetro poner: Prod en vez de OS, de esta forma se mostrará
solamente el nombre del producto (apache) mas no la versión del producto ni la versión del
sistema operativo.
• Listen: Este parámetro no hay por qué cambiarlo, pero básicamente indica en qué puerto
ponemos al apache a escuchar (por defecto está en el puerto 80) pero también le podemos
indicar en qué interfaz de red le ponemos. Por defecto escucha en todas las interfaces.
Sugiero no tocarlo a no ser que sea necesario.
• ServerName: Aunque el apache le asigna el nombre al servidor apache basado en el nombre
de la máquina, para acelerar el proceso de arranque y para evitar potenciales problemas,
siempre es bueno poner el nombre del servidor directamente en este parámetro
(www.misitio.com:80)
• DocumentRoot: Es el directorio raíz del servidor apache, básicamente cuando el servidor
apache necesite buscar por /index.html para mostrarlo, realmente buscará en
/var/www/html/index.html, es la base desde donde se parte para mostrar un sitio web.
Sugiero dejarlo así.
• DirectoryIndex: Son los diferentes archivos índice que se muestran en caso de que el
cliente no especifique un archivo a mostrar. Por ejemplo: http://www.misitio.com/ mostrará
realmente a http://www.misitio.com/index.html puesto que en directoryindex le hemos
dicho que cuando no se especifique un archivo muestre el index.html. Le podemos poner
varias opciones, pero mientras más pongamos más posibilidades hay de que el servidor
demore buscando un archivo para mostrarlo. Y se muestra en ese orden. Por ejemplo:
• DirectoryIndex index.php index.php4 index.htm index.html : buscará primero a
index.php, si no hay ninguno, buscará index.php4, después index.htm y por último
index.html para mostrarlo.
• LogLevel: Es el nivel de verbosidad conque se guardan los logs. Mientras más verbosos,
más consumen recursos del disco. Normalmente lo bajo a nivel de crit (críticos) en vez de
warn (warning).
• Alias: Sirve para enmascarar un directorio que no existe, por ejemplo cuando alguien
escribe: www.misitio.com/icons realmente no hay un directorio icons, sino que es un alias
hacia /var/www/icons
• ScriptAlias: Lo mismo que el anterior, pero le indica al servidor apache que ahi hay un
directorio con archivos que puede ejecutar.
• AddDefaultCharset: Usar por defecto ISO-8859-1 en vez del UTF-8 que viene por defecto.
De lo contrario no saldrán bien los caracteres con acentos.
Al realizar cualquier cambio en la configuración del apache necesitamos reiniciarlo para que este
arranque con los nuevos valores:
service httpd restart
Subiendo las paginas web
Las páginas web normalmente se suben por ftp, pero como todavía no hemos visto cómo configurar
este servicio, sugiero que sencillamente creemos una página (o varias) de forma manual, vayamos al
directorio raíz: /var/www/html y ahi podemos crear un index.html o un index.php si conocemos
cómo hacerlo.
Básicamente dentro del directorio /var/www/html van todos los contenidos de nuestro sitio web. Es
el directorio base, lo que se vería si se accede a www.misitio.com/ (en caso de que
www.misitio.com sea el sitio alojado en mi sitio web).
Redireccionando el sitio web hacia mi servidor

Realmente el manejar un dominio y apuntarlo hacia un servidor no tiene que ver con el servidor
apache sino con el servidor de DNS al que tengamos asignado nuestro dominio.
Esto es, en el servidor DNS que maneja a nuestro dominio es al que debemos decirle que envíe los
records de www.midominio.com y midominio.com (suponiendo que sea midominio.com el dominio
del que hablamos) hacia la IP donde está mi servidor apache.
TAREA: Revisar que los dns estén configurados para nuestros dominios de prueba y apuntando a
la IP de nuestro sitio web.
Tema 7
Muchas veces no basta con tener un servidor apache, sino que también debemos asegurarlo. Todas
las medidas anteriormente tomadas durante el curso son buenas, pero nunca está de más protegernos
con seguridades adicionales.
Primero veamos algunas recomendaciones genéricas:

1. actualizar el código php
2. realizar una buena programación
3. usar conexiones encriptadas en caso de que los datos sean sensitivos
4. Distribuir los servicios que sean esenciales
Pero muchas veces con esto no nos basta, los atacantes tienen muchas formas de entrar al sistema,
es por esto que aquí estudiaremos algunas variantes para asegurar el sistema:
mod_evasive
Conocido anteriormente como mod_dosevasive o dosevasive, es un módulo muy simple pero a la
vez muy efectivo.
Lamentablemente las RPM que ellos sugieren instalemos están un poquito viejas, y aunque es
potencialmente posible crear un RPM desde el archivo de código fuente (tar.gz) perfiero instalemos
este pequeño módulo directamente.
El mod_evasive es un módulo que compilaremos para apache y le indicaremos al apache que lo
ejecute. Este módulo tiene una funcionalidad muy sencilla: Antes de pasarle la petición al apache,
determinará si la IP que está realizando la petición ha hecho otras peticiones en los últimos
segundos, si estas peticiones pasan de un valor determinado, el dosevasive bloqueará la solicitud y
devolverá un error temporal.
El objetivo? Sencillo, si están haciendo un flooding o inundando nuestro servidor de peticiones, el

apache puede colapsar de tantas peticiones desde la misma IP, el dosevasive ayudará a evitar que
esto pase, si nota que hay una inundación de peticiones desde una misma ip, no le pasará esta
petición al apache y él mismo responderá que hay un error temporal, paa evitar que colapsen al
apache y para darle la impresión al atacante de que logró su objetivo.
Segundos o minutos después el dosevasive volverá a activar a la IP ofensora, para así evitar que un
falso positivo esté castigado por siempre.
Instalación
Bajemos el dosevasive de su sitio, abramos el paquete y entremos al directorio que crea:

wget http://www.zdziarski.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz
--10:14:23-- http://www.nuclearelephant.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz
=> `mod_evasive_1.10.1.tar.gz'
Resolving www.nuclearelephant.com... 209.51.159.242
Connecting to www.nuclearelephant.com|209.51.159.242|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 20,454 (20K) [application/x-tar]
100%[====================================>] 20,454 2.56K/s ETA 00:00
10:14:32 (2.56 KB/s) - `mod_evasive_1.10.1.tar.gz' saved [20454/20454]
tar -zxf mod_evasive_1.10.1.tar.gz
cd mod_evasive
En este caso hemos bajado la última versión actual que es la 1.10.1, pero a medida que el tiempo
pase, pueden ir surgiendo otras versiones. Siempre recuerden bajar la más actual del sitio.
Dentro de este directorio que hemos abierto, podemos leer el README que nos explicará que con
el comando apxs podemos crear el módulo para nuestro apache2.
Atención: Siempre recordar que para compilar algún módulo de apache debemos tener instalado el
paquete httpd-devel (yum install httpd-devel) de lo contrario nos podría fallar la compilación
Compilemos con apxs el módulo:

apxs -i -a -c mod_evasive20.c
/bin/sh /usr/lib/apr/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -g \

-pipe -m32 -march=i386 -mtune=pentium4 -DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 \
-D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/include/apr-0 -I/usr/include/httpd -c -o \
mod_evasive20.lo mod_evasive20.c && touch mod_evasive20.slo
/bin/sh /usr/lib/apr/build/libtool --silent --mode=link gcc -o mod_evasive20.la \

-rpath /usr/lib/httpd/modules -module -avoid-version mod_evasive20.lo
/usr/lib/httpd/build/instdso.sh SH_LIBTOOL='/bin/sh /usr/lib/apr/build/libtool' \

mod_evasive20.la /usr/lib/httpd/modules
/bin/sh /usr/lib/apr/build/libtool --mode=install cp mod_evasive20.la /usr/lib/httpd/modul
cp .libs/mod_evasive20.so /usr/lib/httpd/modules/mod_evasive20.so
cp .libs/mod_evasive20.lai /usr/lib/httpd/modules/mod_evasive20.la
cp .libs/mod_evasive20.a /usr/lib/httpd/modules/mod_evasive20.a
ranlib /usr/lib/httpd/modules/mod_evasive20.a
chmod 644 /usr/lib/httpd/modules/mod_evasive20.a
PATH="$PATH:/sbin" ldconfig -n /usr/lib/httpd/modules
----------------------------------------------------------------------
Libraries have been installed in:
/usr/lib/httpd/modules
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 755 /usr/lib/httpd/modules/mod_evasive20.so
[activating module èvasive20' in /etc/httpd/conf/httpd.conf]
Si se fijan el las dos últimas líneas, el apxs se encarga de instalar el módulo (mod_evasive20.so) en
el directorio de módulos del apache (/usr/lib/httpd/modules) y además de "activar" el módulo en el
archivo de configuración (/etc/httpd/conf/httpd.conf), echémosle un vistazo a los cambios que ha
realizado en este archivo:
LoadModule evasive20_module /usr/lib/httpd/modules/mod_evasive20.so
Sólo eso, al final de las directivas LoadModule, agregó una llamada al módulo dosevasive.
Realmente con esto nos basta, esto es, el dosevasive funcionará con sencillamente agregar el
módulo, y funcionará bien.
El dosevasive trabaja con todas sus directivas por defecto y son bastante buenas, pero nosotros
podemos modificarlas si agregamos algo así a nuestro archivo de configuración del httpd (estas
líneas las podemos poner justo debajo de los LoadModules:
<IfModule mod_dosevasive20.c>
DOSHashTableSize 3097
DOSPageCount 5
DOSSiteCount 100
DOSPageInterval 2
DOSSiteInterval 2
DOSBlockingPeriod 600
</IfModule>
• DOSHashTableSize: Define el tamaño en memoria requerido para realizar un hashing o

búsqueda de un record en memoria. Mientras más grande sea la hash table, más rápido se
encontrará un nodo en ella, pero más memoria consumirá. Este valor por defecto está bien,
pero si tenemos un servidor bien ocupado, se debe elevar el valor para permitir búsquedas
más rápidas.
• DOSPageCount: Para una misma página, si un cliente la ve más de este número de veces
durante un intervalo de tiempo, el cliente será bloqueado. Esto es para este caso de ejemplo:
si una página la ve un mismo cliente durante 5 veces en el intervalo de tiempo definido en el
intervalo de tiempo, esta IP será bloqueada.
• DOSSiteCount: Es el número de páginas que en general un cliente puede ver durante el
intervalo de tiempo. 100 páginas en un intervalo de tiempo es bastante.
• DOSPageInterval: Es el intervalo de tiempo en segundos para el contador de páginas
(DOSPageCount)
• DOSSiteInterval: Es el intervalo de tiempo en segundos para el contador de sitio
(DOSSiteCount)
• DOSBlockingPeriod: Es el periodo de tiempo en segundos durante el cuál el cliente será
bloqueado, es decir, durante el cual recibirá un mensaje de error estándar. Durante el
bloqueo, el cliente recibirá el mensaje 403 (forbidden) pero además reseteará el contador de
tiempo a 0, esto es, si un cliente está bloqueado por 600 segundos y al segundo 599 realiza
otra petición, entonces será reseteado a 0 el contador por lo que será bloqueado por 600
segundos así hasta que se esté quieto sin atacar al servidor durante 600 segundos que le
hemos puesto al bloqueo.
• DOSEmailNotify: Si incluimos este comando, dos_evasive enviará un mail por cada
dirección que bloquee, permitiéndonos informarnos al momento de que está ocurriendo un
ataque. Puede ser agobiante la cantidad de solicitudes que se reciban. Además que puede
conducir a un ataque de negación de servicio por muchos envíos de mails. Usar con cautela
o no usar.
• DOSSystemCommand: Ejecutará este comando cuando se detecte un ataque, el comando se
ejecutará por el usuario del servidor web (apache normalmente) por lo que este usuario debe
tener accesos para el comando. Lo normal es usarlo para bloquear a la IP agresora vía
iptables. Debe usarse con cautela pues es un comando externo y puede sobrecargar al
sistema de tantas llamadas. No usarlo de ser posible.
• DOSWhitelist: De usarse, le podemos indicar al dosevasive que no bloquee a esta IP (ej:
DOSWhitelist 127.0.0.*)
Reiniciando el apache
Para que cualquier cambio en la configuración tenga efecto debemos reiniciar el apache, así
cargaría a este nuevo módulo:
Probando al dosevasive
Bueno, queremos probarlo? el paquete dosevasive viene con una pequeña utilería llamara test.pl que
ejecuta un ataque a 127.0.0.1 (nosotros mismos) si quisiéramos probarlo con otra IP debemos
obtener permiso del dueño de esa otra IP, editar test.pl y proceder a probarlo.
En mi caso probaré a mi mismo servidor.

perl test.pl
HTTP/1.1 403 Forbidden




Ahi está, test.pl envió 100 solicitudes a mi servidor, pero a partir de un determinado momento
comenzamos a recibir el mensaje: Forbidden
Además otro signo es que en /tmp se nos guardó un archivo con el nombre dos* que contiene la IP
agresora (127.0.0.1) esto es: /tmp/dos-127.0.0.1 nos indica que esta IP nos agredió y fue bloqueada.
Conclusión
El dosevasive es un módulo muy simple pero que nos puede ahorrar algunos dolores de cabeza, al
menos minimizarlos bastante pues previene ataques de flooding que son comunes estos días, esto
sin dejar fuera del servicio a los clientes válidos que hacen peticiones razonables (no es razonable
hacer 100 peticiones en 2 segundos o 5 de una misma página en 2 segundos, a no ser que seamos
obsesivos compulsivos)
Mod_security
Es un módulo bien complejo pero muy útil. El servidor apache es comunmente sometido a algunos
tipos de ataques especiales para sitios web, como son:
• Uso de caracteres en formato unicode para insertar espacios: %20 es espacio %00 es nulo
• Inyección de sql: Inyectar comandos sql vía la URL
• Cruce o sobrepasado de directorios (http://www.elsitio.com/../../../etc/passwd por ejemplo
permitirá cruzarme las fronteras del sitio web y llegar hasta /etc/passwd de mi sistema y
verlo)
• Ejecución de comandos en la URL: /bin/bash, wget, id, tar, etc) Esto se puede lograr si algún
script no está bien programado y permite que se le envíen comandos los cuales él ejecutaría.
Básicamente no hay nada como una buena programación, esto es, los puntos anteriores se pueden
evitar si se programan correctamente los scripts que usamos y si se mantiene actualizado al servidor
apache para evitar cruces (XSS).
Sin embargo no siempre somos nosotros los que programamos, esto es, a veces usamos scripts y
sistemas completos hechos por 3ros de los cuales no tenemos la menor idea ni tiempo para revisar
su programación.
Es por esto que sería útil el poder instalar un sistema que permita validar que las URL que envían al
servidor no contengan ciertos caracteres o cadenas. Para esto el mod_security.
Igualmente es un módulo de apache, que se interpone entre el apache y la petición que le hacen, la
analiza y determina si la debe dejar pasar al apache o la debe descartar con un error.
Mediante éste módulo podemos evitar todos los puntos anteriormente expuestos, con algunas reglas
que le podemos insertar al mod_security y que evitarían estos ataques.
Obteniendo el mod_security
La última versión de su sitio es la 1.9, como siempre, a medida que el tiempo pase puede que salgan
nuevas versiones al mercado, por lo que siempre es recomendable usar la última disponible que no
sea beta.
La versión 1.9 es extremadamente nueva y no ha salido un rpm para compilar, así que tendremos
que instalarlo desde el tar.gz
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.5.tar.gz
tar -zxf modsecurity-apache-2.5.5.tar.gz
cd modsecurity-apache_2.5.5/
Dentro de este directorio tendremos un archivo llamado INSTALL que nos permitirá aprender
cómo instalarlo.
Primero tenemos que movernos al directorio apache2 y después proceder a llamar
al apx:
cd apache2
apxs -cia mod_security.c
Listo, como veremos en las dos últimas líneas de compilación ha instalado el módulo
(mod_security.so) en el directorio de módulos de apache: /usr/lib/httpd/modules/ y además activó
el módulo en el archivo principal de configuración de apache: /etc/httpd/conf/httpd.conf
Veamos lo que ha cambiado en este último archivo:

LoadModule security_module /usr/lib/httpd/modules/mod_security.so
Listo, con esto tenemos activo el módulo y trabajando con sus parámetros por defecto que no están
mal pero podemos pulir.
Sugiero en este archivo httpd.conf agregar debajo de la sección LoadModules la siguiente sección:
LoadModule security_module modules/mod_security.so
<IfModule mod_security.c>
# Turn the filtering engine On or Off
SecFilterEngine DynamicOnly
# The audit engine works independently and
# can be turned On of Off on the per-server or
# on the per-directory basis
SecAuditEngine Off
# Make sure that URL encoding is valid
SecFilterCheckURLEncoding On
# Unicode encoding check
SecFilterCheckUnicodeEncoding On
# Only allow bytes from this range
SecFilterForceByteRange 10 255
# Cookie format checks.
SecFilterCheckCookieFormat On
# The name of the audit log file
SecAuditEngine Off
#SecAuditLog logs/audit_log
# Should mod_security inspect POST payloads
SecFilterScanPOST Off
# Default action set
SecFilterDefaultAction "deny,log,status:406"
# Require HTTP_USER_AGENT and HTTP_HOST headers
SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"
# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^GET$" chain
SecFilterSelective HTTP_Content-Type \
"!(^$|âpplication/x-www-form-urlencoded$| \
âpplication/x-vermeer-urlencoded$| \
^multipart/form-data)"
# Require Content-Length to be provided with
# every POST request
SecFilterSelective REQUEST_METHOD "^POST$" chain
SecFilterSelective HTTP_Content-Length "^$"
# Don't accept transfer encodings we know we don't handle
# (and you don't need it anyway)
SecFilterSelective HTTP_Transfer-Encoding "!^$"

#SecFilter "<(.|\n)+>"
SecFilter /tmp/
#SecFilter /var/
SecFilter /root/
SecFilter /etc/
SecFilter /dev/
SecFilter /bin/
#SecFilter /sbin/
SecFilter "\;id"
SecFilter "uname\x20-a"
SecFilter "perl\x20-a"
SecFilter "wget\x20"
SecFilter "ftp\x20"
SecFilter "cat\x20"
<Location /MyAdmin>
SecFilterInheritance Off
</Location>
#Esto afecta al fp las dos siguientes
SecFilter "\.\./"
SecFilter "<[[:space:]]*script"
SecFilter "insert[[:space:]]+into"
SecFilter "delete( |\n)+from"
SecFilter "select( |\n)+from"
SecFilterSelective REMOTE_ADDR "^127.0.0.1$" nolog,allow
SecFilterSelective ARGS_NAMES 777
SecFilterSelective ARG_b2inc "!^$"
SecFilterSelective ARG_PHPSESSID "!^[0-9a-z]*$"
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-z]*$"

</IfModule>
Para una completa identificación de cada parámetro podemos ver en

http://www.modsecurity.org/documentation/modsecurity-apache/2.5.5/modsecurity2-apache-
reference.html
Básicamente todo lo que le hemos indicado son modos de transferencia que debemos o no aceptar,
filtros para que no se acepten ciertas cadenas (/bin/, /tmp/, etc,etc) y así evitamos que nos envíen
ciertas cadenas vía URL. También le indicamos los caracteres ascii a usar así como a filtrar
caracteres unicode.
Una de las primeras líneas le indica al mod_security que sólo filtre páginas dinámicas (php, perl,
cgi) pues las páginas estáticas al no ser ejecutadas no pueden usarse para realizar ataques, así
mejoramos el performance del servidor.
Conclusión
Definitivamente el mod_security nos ayuda a evitar que un atacante se base en fallas de la
programación o de nuestro servidor web, para acceder a él, trabaja con patrones y filtros que son
genéricos y que pueden interferir el normal funcionamiento si escogemos un filtro de una forma
incorrecta (si en vez de /bin/ filtramos bin (sin /) entonces si una URL contiene cualquier palabra
que diga: binario o binladen o binoculares, será bloqueada.
Pero el mod_security nos puede ayudar muchísimo a coartar accesos no autorizados al sistema
mediante este sencillo sistema.
El mod_security introduce una sobrecarga al sistema, pues tiene que realizarse un análisis de las
URL, pero esta carga muchas veces se compensa con las muchas veces que podemos evitar ataques,
yo estimo que la carga esté entre un 5% a un 25% más del uso del procesador del sistema.
Tema 8
eaccelerator
No todo es protegerse contra ataques conocidos o desconocidos, muchas veces podemos proteger a
nuestro servidor de una caída con simplemente acelerar su funcionamiento.
PHP que es el lenguaje de programación dinámica más usado es un intérprete, esto es, cada vez que
se llama a un script, el servidor simplemente toma el script, lo interpreta y muestra su resultado. Si
el script es un poco grande, esto de interpretarlo siempre una y otra vez puede hacerse penosamente
lento y llegar a hacer que el servidor funcione muy mal o deje de funcionar.
Ahora, el php ofrece una versión pagada que está en www.zend.com la cual cambia un poco el
comportamiento del php y le introduce al php un módulo que permite que se cacheen las respuestas
y que se realice una especie de precompilación del código de forma tal que cada vez que se lea un
script no se tenga que interpretar sino que se interprete solamente la primera vez que lo leamos y
después quede precompilado.
El precompilar scripts es buenísimo y realmente ayuda a mejorar el rendimiento de un servidor y los
tiempos de respuesta pueden bajar absurdamente.
Ahora, pagar 600 o más dólares por un acelerador de php no está en los bolsillos de todo el mundo,
así que mucha gente opta por no acelerar los scripts.
En todo caso existe un acelerador de código php gratuito y disponible en internet, se llama
eaccelerator y lo mejor de todo es que está disponible en el sitio de dag
(http://dag.wieers.com/packages/php-eaccelerator) pero sólo hasta la versión EL4 de RedHat.
Así que si tenemos el repositorio de dag instalado podemos instalar este acelerador de forma muy
simple:
yum -y install php-eaccelerator
Yum Version: 2.4.0
COMMAND: yum
Installroot: /
Ext Commands:
php-eaccelerator
Baseurl(s) for repo: ['http://apt.sw.be/redhat/el4/en/i386/dag']
dag 100% |=========================| 1.1 kB 00:00
Baseurl(s) for repo: ['http://mirror.centos.org/centos/4/updates/i386/']
update 100% |=========================| 951 B 00:00
Baseurl(s) for repo: ['http://mirror.centos.org/centos/4/os/i386/']
base 100% |=========================| 1.1 kB 00:00
Baseurl(s) for repo: ['http://mirror.centos.org/centos/4/addons/i386/']
addons 100% |=========================| 951 B 00:00
Baseurl(s) for repo: ['http://mirror.centos.org/centos/4/extras/i386/']
extras 100% |=========================| 1.1 kB 00:00
Setting up Package Sacks
Excluding Incompatible Archs

Finished
Reading Local RPMDB
reduced installs :
php-eaccelerator.i386 0:4.3.9_0.9.3-4.2.el4.rf
1131553760.64
---> Downloading header for php-eaccelerator to pack into transaction set.
php-eaccelerator-4.3.9_0. 100% |=========================| 4.3 kB 00:01
---> Package php-eaccelerator.i386 0:4.3.9_0.9.3-4.2.el4.rf set to be updated
1131553762.58
=============================================================================
=============================================================================
Installing:
php-eaccelerator i386 4.3.9_0.9.3-4.2.el4.rf dag 96 k
Transaction Summary
=============================================================================
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 96 k
Downloading Packages:
(1/1): php-eaccelerator-4 100% |=========================| 96 kB 00:42
Running Transaction Test

Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing: php-eaccelerator ######################### [1/1]
Installed: php-eaccelerator.i386 0:4.3.9_0.9.3-4.2.el4.rf
Complete!
Y listo, el eaccelerator es un módulo que se inserta en el php (/etc/php.d/eaccelerator.ini). Y con

sencillamente reiniciar el apache podemos hacer uso de él:
Ya está funcionando.
Si queremos en realidad ver si el eaccelerator está activo, podemos escribir un pequeño script de
php que pondremos en nuestro sitio web (/var/www/html) para que nos indique qué puede hacer el
php:
vi /var/www/html/prueba.php
<? phpinfo(); ?>
phpinfo(); es una función de php que llamamos dentro del script php (los scripts php comienzan
con <? y terminan en ?>
Ahora accedamos a este archivito de prueba vía nuestro browser:

http://localhost/prueba.php
Y nos dará una salida grandísima, pero podremos observar lo siguiente:
This program makes use of the Zend Scripting Language Engine:

Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies with eAccelerator v0.9.3,
Copyright (c) 2004-2005 eAccelerator, by eAccelerator
Esto es: El php ya está trabajando con el eaccelerator!
Y un poco más abajo veremos una sección completa dedicada al eaccelerator:

eAccelerator
eAccelerator support enabled
Version 0.9.3
Caching Enabled true
Optimizer Enabled true
Memory Size 33,554,404 Bytes
Memory Available 33,552,044 Bytes
Memory Allocated 2,360 Bytes
Cached Scripts 1
Removed Scripts 0
Cached Keys 0
Si no salen estas informaciones, entonces significa que el eaccelerator no lo tenemos instalado lo
más común que es que no hemos reiniciado el demonio del apache y por lo tanto no ha tomado este
nuevo módulo.
Conclusiones
El eaccelerator es una excelente alternativa que va a hacer que nuestros scripts corran
definitivamente más rápido que de forma interpretada. Realmente puede acelerar enormemente el
trabajo con php. No por un 50 ni un 100, sino posiblemente en un 1000% o más, puesto que al tener
precompilado los scripts, sencillamente es cuestión de mostrarlos sin tener que reinterpretarlos.
Compresión de páginas web

Otro de los temas más importantes a la hora de optimizar el uso de nuestro servidor apache es el de
la compresión de páginas web.
Básicamente todos los browsers actuales son capaces de recibir una página comprimida y antes de
mostrarla pueden descomprimir esta página.
La idea es que la información viaje entre el servidor apache y nuestro browser de una forma
comprimida.
De esta forma podemos lograr reducir el tamaño de una página web hasta un 30% o menos en
dependencia de la cantidad de información. Por supuesto, al tener un menor tamaño, la página web
demora mucho menos en viajar hasta nosotros y por lo tanto no sólo la recibimos más rápido sino
que molestamos menos al servidor web que se puede desocupar de la conexión del cliente y atender
a otro cliente de una forma más efectiva.
La compresión de páginas web tiene lugar al vuelo, esto es, el servidor toma nuestra página en
formato .html, la comprime gastando ciclos de su cpu y la envía al cliente que se ocupará de
descomprimirla.
La única desventaja potencial es que se consumen más ciclos de cpu por parte del servidor en
encriptar la página, pero muchas veces esto es negligible dado el gran avance que obtenemos en
salir rápido de una solicitud.
El servidor apache es capaz de comprimir páginas estáticas (html), no tiene mucho sentido
comprimir .jpg o .gif ya que son archivos ya previamente comprimidos que no se lograría mayor
ventaja con hacerlo de nuevo.
Para activar la compresión de páginas web, sencillamente editamos el /etc/httpd/conf/httpd.conf y

posterior a los LoadModules. Yo siempre lo hago justo encima de UserDir, justo encima del
siguiente comentario:
# UserDir: The name of the directory that is appended onto a user's home
y ponemos lo siguiente:
SetOutputFilter DEFLATE
DeflateFilterNote ratio
DeflateCompressionLevel 3
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
• SetOutputFilter: Activa la compresión (deflation, o deflate)

• DeflateCompressionLevel: Es el nivel de compresión de 1 (la más baja pero a la vez más
rápida) hasta 9 (la compresión más alta pero más lenta)
• SetEnvIfNoCase: esto permite definir ciertos casos en los que no comprimiremos, esto es
gif, jpeg, png, exe, tgz, zip, bz2, sit, rar, pdf ya que estos formatos ya vienen comprimidos y
nos harían gastar tiempo.
El valor por defecto del compression level es de 5, pues está demostrado que comprimir mayor a 5
sencillamente no avanza mucho, se comprimen unos 10 bytes mejor, pero no vale la pena tanto
esfuerzo. En mi caso, como tengo un servidor un poco cargado de peticiones, prefiero acelerar el
proceso de compresión y bajarlo a nivel 2. Comprimirá menos (unos 100 o 200 bytes menos) pero
será más rápido pues necesito la CPU.
En todo caso, si tenemos un servidor poco cargado podemos subir la compresión a 5 o más, puesto
que no nos preocupará la CPU. Normalmente podemos ponerlo en 5 o más sinque nos afecte
mucho.
Al terminar de editar el archivo procedemos a reiniciar el httpd:

Y listo, ya está el apache nuestro comprimiendo las páginas html (estáticas).
Comprobando la compresión
Podemos usar el siguiente sitio http://www.whatsmyip.org/http_compression/ para comprobar si la
compresión ha sido efectiva o no, por supuesto nuestro servidor httpd debe estar en internet para
que desde este sitio se pueda ver.
leknor como ejemplo nos muestra un sitio que no está comprimido, y nos indica el tamaño real del
index.html así como cuánto podría haber bajado el tamaño del index.html si se enviara comprimido.
Fíjense que para este sitio de ejemplo, el tamaño real es de 45KB y demoraría unos 12 segundos si
se estuviera transfiriendo desde una conexión de 32kbs (3.5kbs).
sin embargo, si estuviera comprimido, podríamos observar que con un nivel 5, lograríamos reducir
su index.html a: 24KB, esto es casi un 50%, y por lo tanto sólo tomaría 3.1 segundos en bajarse este
archivo desde una conexión de 32kbs (3.5KB/s).
Conclusiones
Como vemos, sí logramos una rapidez real, absolutamente mejor que si no comprimiéramos, lo que
da una mejor sensación de navegación por nuestro sitio y además permite que el servidor apache se
libere más rápidamente de nuestra conexión y pueda servir otras.
ahora, existe una pequeña desventaja, y es que el apache sólo comprime por alguna razón archivos
estáticos, mas no páginas dinámicas (php). Es por esto que a continuación estudiaremos la forma de
comprimir estas páginas igualmente.
TAREA: Está el sitio del comercio (www.elcomercio.com/) comprimiendo páginas web? y

www.elmercurio.com.ec/web/ ? Y www.eluniverso.com/ ? Noten el / al final, noten cuánto podrían
ahorrar.
Comprimiendo páginas dinámicas con php

Ahora, comprimir páginas en php es muy simple, sencillamente tenemos que editar el archivo
/etc/php.ini y activar los siguientes dos parámetros:
zlib.output_compression = On
zlib.output_compression_level = 3
Realmente el segundo sencillamente indica el nivel de compresión que por defecto es 5. Esto es,
podemos no poner este segundo parámetro puesto que por defecto se toma como 5. Siempre es
bueno recordar que mientras mejor compresión, mayor demora a la hora de comprimir y mayor
consumo de cpu, por esto no es bueno subir mucho la compresión pues se nos podría agotar el
sistema de tanto uso de cpu.
El primer parámetro activa la compresión para nuestro php (zlib.output_compression), ahora con
sencillamente reiniciar el httpd, podemos ver que ya están comprimiéndose también los scripts de
php:
Igual con whatsmyip podemos comprobar que el script de php está siendo encriptado.
Tema 9
Apache no solamente es capaz de manejar un sitio web como anteriormente vimos, sino que
también es capaz de manejar diversos sitios web en una sola máquina.
Para esto usa una tecnología llamada de servidores virtuales (Virtual Hosts).
Los servidores virtuales se crearon para sobreponerse a dos dificultades fundamentales de los
servidores de internet y las redes tcpip:
1. Llegado un momento en el tiempo, no fue factible el mantener un servidor web en una

máquina y una máquina para un servidor web.. esto es, dada la cantidad de sitios web no era
rentable económicamente ni en términos de espacio y mantenimiento el tener una máquina
dedicada a alojar solamente un servidor web.
2. Como todos conocemos, las direcciones IPv4 están llegando a su fin, se predice que en unos
10 años a lo sumo ya no habrán direcciones IPs para asignarse a nuevos servidores de
internet, por lo que hace falta ahorrar y de hecho todos los proveedores son muy escasos a la
hora de asignar IPs.
Por estas razones, y posiblemente por algunas razones más, es que se concibió la idea de permitir
que el servidor apache pudiera alojar varios sitios web a la vez.
Un servidor apache normalmente es capaz de alojar sin mayor inconveniente hasta unos 1024 sitios
web simultáneamente, por supuesto los inconvenientes provienen mayormente de la capacidad
física de la máquina, esto es, depende mucho de la cantidad de memoria RAM, del tamaño en disco
del sistema, del ancho de banda asignado, de la capacidad de él o los procesadores.
Pero teóricamente es posible tener más de 1 sitio web y el límite depende de las características del
sistema operativo y de las características físicas y de conectividad de las máquinas.
Preparación de los sitios a ser dirigidos al servidor

El preparar los dominios para apuntarlos a un servidor apache es sencillo. Debemos definir en
nuestros DNS los records A apropiados para que estos apunten a la dirección IP de nuestro servidor
apache. Cada una de las zonas de DNS correspondientes a los dominios que vamos a alojar las
apuntamos hacia la IP del servidor apache.
Por ejemplo, usando everydns.net tengo estos sitios apuntando al mismo lugar:
Si nos fijamos, ambos sitios apuntan a la misma dirección IP (209.172.33.209), como podemos
notar también, everydns usa records *, esto significa que cualquier subdominio lo apuntamos hacia
esa IP (www.ascofame.org.co, mail.ascofame.org.co, ftp.ascofame.org.co, etc).
Configurando el apache para manejar sitios virtuales

Entonces, si ambos apuntan hacia la misma IP, cómo hace apache para diferenciar un sitio de otro?
Bueno, apache se fija en la solicitud que hace el browser en cuestión pues esta viene con el nombre
del sitio que se está intentando visualizar (vendrá pidiendo www.ascofame.org.ec) así que para el
apache no es mayor complicación, buscará en su lista de sitios y mostrará la página web.
El algoritmo para trabajar sitios virtuales en apache es el siguiente:

1. Definimos un sitio virtual y le asignamos el nombre del sitio (www.ascofame.org.ec)
2. Es bueno también asignarle un alias que comprenda los otros nombres del sitio,
normalmente el sitio pero sin www (ascofame.org.ec). De esta forma será un punto de
enlace para ambas modalidades de entrada al sitio web.
3. Al sitio virtual le definimos un directorio raíz, donde estarán los contenidos del sitio web en
cuestión. Por supuesto este directorio raíz será diferente del de los otros sitios virutales, es
precisamente aqui donde diverge un sitio del otro, en el nombre pero sobre todo en este
directorio raíz, por lo tanto apache mostrará una página para un sitio y otra para otro ya que
están en directorios raíces diferentes.
4. Al sitio virtual le podemos definir archivos de logs independientes. Si no lo hacemos los
logs se guardarán en /var/log/httpd/access_log y error_log esto es en los archivos de logs
estándar. Yo sugiero separar los logs para después poder generar las estadísticas
separadamente.
Esto es básicamente lo necesario, después que lo configuremos podemos reiniciar el servicio y ya
estará activo.
Para los efectos de la prueba, por favor editar /etc/hosts y poner la siguiente línea:
127.0.0.1 www.dominio.com www.dominio1.com dominio.com dominio1.com
Así no tendremos que configurar los dns para realizar las pruebas y tendremos dos dominios
(dominio.com y dominio1.com) apuntando a la misma IP (localhost).
Así que ahora podremos entrar a la configuración de nuestro apache (/etc/httpd/conf/httpd.conf) y

crear los dos virtual hosts para dominio.com y dominio1.com
NameVirtualHost *:80
<VirtualHost *:80>
ServerAdmin info@ecualinux.com
DocumentRoot /var/www/html/dominio.com
ServerName www.dominio.com
ServerAlias dominio.com
ErrorLog logs/dominio.com-error_log
CustomLog logs/dominio.com-access_log common
</VirtualHost>
<VirtualHost *:80>
ServerAdmin info@ecualinux.com
DocumentRoot /var/www/html/dominio1.com
ServerName www.dominio1.com
ServerAlias dominio1.com
ErrorLog logs/dominio1.com-error_log
CustomLog logs/dominio1.com-access_log common
</VirtualHost>
La única directiva nueva es ServerAlias que indica con qué otros nombres se conoce al servidor
(con y sin www)
Antes de reiniciar el apache debemos crear los directorios donde se alojarán ambos dominios (Los
definidos por DocumentRoot) sino nos fallará el apache al levantar.
mkdir /var/www/html/dominio.com
mkdir /var/www/html/dominio1.com
Probando los virtualhosts

Bueno, antes de probar si los virtualhosts funcionan, sugiero crear un pequeño archivo index.html
dentro de cada uno de los directorios ( /var/www/html/dominio.com y
/var/www/html/dominio1.com ) de forma tal que podamos diferenciar entre un sitio y el otro.
Entonces podremos proceder a visualizar ambos sitios, verán que son diferentes.
El problema más común es la gente que define el mismo directorio como raíz para dos o más sitios,
por lo tanto no se verán sitios diferentes sino el mismo
tema 10
Generando cerficados SSL para apache:
El primer paso es crear la clave RSA privada. Esta clave es del tipo RSA de 1024 bits y estará
encriptada usando Triple DES y guardada en formato PEM de forma tal que sea visible como texto
ASCII.
Usaremos varios archivos como fuente de numeros aleatorios lo que ayudará a hacer la clave más
segura. Un buen formato son archivos texto comprimidos en formato gzip. La clave es generada
usando el siguiente comando (file1 a file5 son los archivos a ser usados para mejorar los numeros
aleatorios), en nuestro caso de ejemplo, yo usaré dos archivos binarios. En la vida real les
recomiendo poner algunos archivos más
openssl genrsa -rand /usr/bin/lsattr:/bin/cat -out server.key 1024
26976 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
.........++++++
.......++++++
e is 65537 (0x10001)
Aquí está generada la server.key, la clave privada de nuestro servidor.
Es muy importante mantener una copia de ésta clave pues es la base para la encriptación usando un
certificado. De ser posible mantener un respaldo en un disquete o cinta. El costo de un
certificado,aunque varía, está entre los 30 y los 600usd aproximadamente (al año, ver
www.nuestroserver.com) y es sumamente doloroso tener que regenerar un certificado nuevamente
por no haber guardado los archivos utilizados para la generación de éste.
Ahora procedamos a generar una petición de certificación (Certificate Signed Request). Con esta
podremos realizar la petición de un certificado a la entidad certificadora de nuestra elección. Este es
el archivo que se les envía cuando ellos solicitan el CSR. Sin embargo, también podemos hacer que
nuestro sistema genere un Certificado AutoGenerado el cual nos permitirá operar de forma segura,
pero siempre le sacará a los clientes una advertencia de que el certificado no puede ser validado en
una entidad certificadora.
En negrita está lo que nosotros debemos ir escribiendo. El ejemplo es para Quito, Pichincha,
Ecuador, pero debe ponerse los datos de su organización propiamente dichos.
openssl req -new -key server.key -out server.csr
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:EC
State or Province Name (full name) [Berkshire]:Pichincha
Locality Name (eg, city) [Newbury]:Quito
Organization Name (eg, company) [My Company Ltd]:EcuaLinux
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server's hostname) []:www.ecualinux.com
Email Address []:info@ecualinux.com
Please enter the following 'extra' attributes to be sent with your certificate request
A challenge password []:
An optional company name []:
Cuando vayamos a comprar un certificado, enviaremos éste archivo a la entidad certificadora.

Ahora, como esto toma un tiempo y cuesta dinero, procedamos nosotros a generarnos un certificado
autogenerado a partir de estos datos y seguir operando hasta que idealmente nos llegue el
certificado válido. Este certificado de ejemplo será válido por 60 días, podemos poner más (1400 o
algo así) si es que nunca vamos a pedir un certificado válido a una entidad certificadora.
openssl x509 -req -days 60 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=EC/ST=Pichincha/L=Quito/O=Ecualinux/OU=IT/CN=Ernesto
Perez/emailAddress=direccionvalida@hotmail.com
Getting Private key
Listo.. ya tendremos nuestro certificado autogenerado.
En el caso de que hayamos solicitado un certificado de autenticidad a una

entidad certificadora:
Es éste certificado el que nos enviaría una entidad certificadora para que usemos. Cuado lo envían,
normalmente lo hacen en el cuerpo del mensaje, lo que tenemos que hacer realmente es crear un
nuevo archivo llamado server.crt y pegarle todos los datos que nos indiquen.
Instalando el certificado en apache

primero verificar que apache y mod_ssl estén instalado, estos dos paquetes son necesarios para
trabajar con ssl en apache:
rpm -q httpd mod_ssl
Si no están instalados, instalarlo conjuntamente con el php y el módulo para el manejo de ssl:
yum install php php-imap php-mysql httpd mod_ssl
probemos que el apache arranque

Una vez instalado el apache, los certificados SSL estarán activos. Puesto que por defecto mod_ssl
busca en /etc/httpd/conf.d/ssl.conf e intenta usar los certificados nombrados server.crt y
server.key
[root@laptop ~]# cp server.crt /etc/httpd/conf/ssl.crt/
[root@laptop ~]# cp server.key /etc/httpd/conf/ssl.key/
[root@laptop ~]# service httpd restart
Stopping httpd: [FAILED]
Starting httpd: [ OK ]
Nota:
Si quisiéramos agregar un servidor virtual con ssl, sugiero editar el archivo
/etc/httpd/conf.d/ssl.conf ahi se definen los servidores virtuales en ssl. Tener en consideración que
el archivo .crt y el .key deben ser diferentes para cada sitio virtual. También debemos tener en
cuenta que apache permite sólo un certificado SSL por cada IP. Esto es, si quisiéramos más de un
certificado SSL en el servidor, debemos obtener más de una dirección IP para el servidor.
y listo.. ya tenemos nuestro certificado instalado para esa IP del servidor.

Servidoreswed

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Servidoreswed

Uploaded by

Copyright:

Available Formats

Servidor de Servicio de Nombres de Dominio

Estos nombres son conocidos por nombre de dominios.

También existen varios dominios con efectos restringidos como son:

Toda transferencia cuesta el equivalente a un año de registro. Y de hecho al culminar

Si la transferencia fallase, el dinero no se efectiviza y lo podremos usar para reintentarlo.

Las causas más comunes del fallo de una transferencia son:

Básicamente en efecto podemos determinar si un dominio existe yéndonos a un registrar y

Esta utilería la podemos instalar con el paquete jwhois

verifiquemos que lo tenemos instalado:

si no lo tuviéramos podríamos hacerlo con:

Whois Server Version 2.0

NOTICE: The expiration date displayed in this record is the date

registrar. Users may consult the sponsoring registrar's Whois

repackaging, dissemination or other use of this Data is expressly

Básicamente aquí podemos obtener toda la información de un dominio, llamado ecualinux.com, si

Verifiquemos los dns de Ecualinux:

¿Qué ventaja tiene esto?

Los DNS se clasifican en dos tipos fundamentales:

Cómo le indicamos a un servidor linux qué servidor de DNS de caché usar?

Por ejemplo, los records más conocidos son:

Si quisiéramos hacerle preguntas específicas a un determinado servidor de DNS podríamos hacerlo

Pregunté por www.elcomercio.com

El servidor al que se le hizo la pregunta fué 127.0.0.1 (mi propia máquina).

La respuesta fué que www.elcomercio.com (record A www, de la zona elcomercio.com) es:

Preguntemos algo más:

> set type=mx

ecualinux.com mail exchanger = 10 mail.ecualinux.com.

Authoritative answers can be found from:

ecualinux.com nameserver = dns4.name-services.com.

ecualinux.com nameserver = dns5.name-services.com.

ecualinux.com nameserver = dns1.name-services.com.

ecualinux.com nameserver = dns2.name-services.com.

ecualinux.com nameserver = dns3.name-services.com.

dns1.name-services.com internet address = 69.25.142.1

dns2.name-services.com internet address = 216.52.184.230

dns3.name-services.com internet address = 63.251.92.193

dns4.name-services.com internet address = 64.74.96.242

dns5.name-services.com internet address = 212.118.243.118

el segundo paso que haría un sistema de mensajería es averiguar el record A de mail.ecualinux.com

Hay una razón, y es que los pesos van de 0 a 255

TAREA: Revisar los mx y A de algunos sitios conocidos por ustedes.

Los DNS de zona se dividen en dos tipos:

Definiendo un DNS máster

Una vez entremos, veremos la siguiente configuración:

De estos otros valores, podremos observar 3 que son de potencial interés:

Sugiero siempre agregar los siguientes records:

www.dominio.com. A ip del servidor www

mail.dominio.com. A ip del servidor de mail.dominio.com.

ftp.dominio.com. A ip del servidor de ftp.dominio.com.

dominio.com. A ip del servidor www.dominio.com.

Al agregar los Records A, por favor hagámoslo con la IP de nuestra máquina.

A la final de agregar todos los records A veremos algo así:

Agreguemos el MX (Return to Record Types -> icono de MX)

Para verificar las respuestas de un DNS podemos usar: www.squish.net/dnscheck

Definiendo un DNS esclavo

El DNS esclavo requiere de solamente dos datos:

Existe un pequeño problema y es que el webmin escribe las zonas esclavas en

Esto nos cambiará al usuario named el directorio /var/named/chroot/var/named pues sino, no se

Instalar los paquetes de bind:

Estos son los paquetes necesarios para el uso de un servidor de caché.

Al final de /etc/named.conf agregar:

dominio.com. IN SOA localhost.localdomain. mi.email.com. (

Activar el servicio de named: