viernes, 19 de enero de 2018

Criterio para determinar el host virtual que atiende la solicitud HTTP recibida en el servidor web Apache

El criterio para asociar una solicitud con un host virtual de entre todos los que integran la lista será el siguiente.

A partir de la información procedente de las cabeceras de la solicitud HTTP realizada por el cliente se usarán los siguientes datos (entre paréntesis con que parametro del host virtual se compara):

- Nombre DNS utilizado (ServerName)
- puerto TCP (puerto)
- IP a la que se resuelve el nombre DNS (Addresss)
- IP especificada explícitamente, si se ha usado directamente la IP en la URL en lugar de un nombre DNS. (Address)


El criterio para seleccionar el host virtual que atiende la petición HTTP recibida en el servidor se basa en el número de parámetros que coinciden con los de la solicitud, pero en un orden de prioridad. En primero lugar la IP, a continuación el número de puerto y por último el ServerName.

Por lo tanto, si encontramos en la lista de hosts virtuales un solo host virtual con la IP establecida de forma explicita y esta coinicide con la IP de la solicitud (o la IP del nombre DNS una vez resuelto) este será el host virtual asociado con la solicitud.

Si existieran varios hosts virtuales con la IP coincidente, entonces entre ellos se escogerá aquel que explicite el número de puerto TCP y este coincida con el de la solicitud HTTP recibida.

Nuevamente, en caso de haber varios hosts, se debe seguir probando con el siguiente criterio, y este ya, por fin, es el parametro ServerName, de modo que aquel host virtual que coincida con el valor del ServerName será el seleccionado.

El último criterio para desempatar, caso de que no se haya podido decidir todavía que host virtual atiende la petición, sera el nombre del fichero de configuración del host virtual en orden alfabético descendente.

No obstante, puede suceder que, mientras se está seleccionando el host virtual, aparte del caso en que exista uno o varios host virtuales que cumplen el criterio, también puede ocurrir el caso de que no exista ninguno. En este caso se pasa al criterio siguiente, es decir, si se trata de la IP se pasará al puerto, y si se trata del puerto se pasará al ServerName y finalmente si no hay mas remedio al nombre del fichero de configuración.


Certificados de cliente en Apache


 Si queremos validar un usuario mediante un certificado emitido por alguna autoridad de certificación...

Fuentes:
http://www.garex.net/apache/#CCCreate

Generar una solicitud de certificado para una autoridad de certificación




Un CSR (Certificate Signing Request) es un archivo que contiene la información necesaria para solicitar un certificado a una CA Autoridad de Certificación, incluida una clave publica.

Usaremos el comand:

openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr


openssl req -nodes -newkey rsa:2048 -keyout servidorweb.key -out servidorweb.csr

-nodes no encriptar la clave generada con una frase de paso DES
-newkey rsa:bits -> genera un clave RSA de el numero tamaño 'bits' bits
-keyout fichero -> archivo donde ser va a escribir la clave privada
-out -> fichero donde se va a escribir la solicitud de certificado para la CA


La solicitud la tendremos que autofirmar con nuestra propia CA.


Fuentes:
http://acidx.net/wordpress/2013/02/enabling-ssl-on-your-webserver/

http://acidx.net/wordpress/2012/09/creating-a-certification-authority-and-a-server-certificate-on-ubuntu/

Configurar los servidores virtuales en Apache

El servidor principal o por defecto atiende las peticiones a menos que se configuren servidores virtuales.
Su cofiguración está definida directamente en los ficheros de configuración de apache, concretamente en el fichero /etc/apache2.conf.

Podemos comprobar como da igual lo que escribamos en la barra direcciones del navegador siempre que el nombre DNS se pueda resolver a la IP 192.168.100.254, es decir, la del propio servidor web.

Podemos probar con

http://servidor.aulasri.com
http://192.168.100.254
http://127.0.0.1

Y también con los alias

http://www.aulasri.com
http://dns1.aulasri.com
http://smtp.aulasri.com

Estos alias y en general toda la información para resolver el nombre DNS a la IP del servidor se crearon cuando vimos BIND9 y ahora vemos su utilidad.

El directorio raiz de documentos predeterminado del servidor web Apache para Ubuntu es /var/www/html.

Podemos abrir este archivo con el navegador y ver su contenido.
Comprobamos de este modo que se trata del mismo documento que el servidor web nos está sirviendo via web, usando el puerto 80 tcp, cuando lo hacemos a través del servidor escribiendo en la barra de direcciones las URLs anteriormente citadas.

 
Para cada host virtual definido en Apache se pueden establecer 3 parámetros diferentes. Estos son:

- Address (direccion)
- port (puerto)
- ServerName (nombre DNS del servidor / host virtual)

Para Address y port se puede establecer un valor explicito o dejarlo sin definir mediante Any en webmin o * directamente en la directiva VirtualHost (para la dirección o el puerto).

En el caso del ServerName se puede utilizar el valor por defecto de la configuración global o establecer un valor diferente que lo reemplace.


Estos parámetros permitirán establecer los criterios de correspondencia o no con el sitio web (host virtual) una vez confrontados con los propios valores de la solicitud.

Si hemos establecido el valor Any para algo de ellos estaremos indicando que nos valdría cualquier valor proporcionado en la solicitud (request) para ese parámetro a la hora de admitirlo como acierto (match).





Comparando todos datos proporcionados por la solicitud con los parámetros de cada host virtual de la lista en el servidor, se eligen aquellos que mejor se ajustan a la solicitud.

Se entiende que los host virtuales que mejor se ajustan son aquellos en lo que coinciden un mayor número de parámetros explícitos (no cuentan los establecidos como Any, ya que estos solo sirven para descartar)

Primero, se descartan hosts cuyo puerto o dirección no coincide con el de la solicitud. Para saber si la dirección no coincide se resuelve el nombre DNS proporcionado en la solicitud.

Aunque para aquellos hosts virtuales que estén configurados con la opción Any se entenderá que pueden corresponder con la solicitud y no serán descartados de la lista.




Si al final, después de tener en cuenta estos filtros solamente hay un ganador en cuanto número de parámetros coincidentes (3,2,1 o 0 y los Any no cuentan) ese será el host virtual al que se asociará la solicitud.

En caso de empate, habrá que tener en cuenta criterios de desempate.

El criterio para desempatar será escoger a aquel que se encuentre antes en la lista, que será aquel cuyo archivo de configuración tiene un nombre en el sistema de archivos menor en orden alfabético.

Hay que tener en muy en cuenta que pasa cuando usamos al mismo tiempo hosts virtuales basados en IP y host virtuales basados en nombre. La precaución que hay que tener en cuenta es la siguiente:

Toda solicitud HTTP recibida indicando un nombre DNS es resuelta a su correspondiente IP mediante el servicio DNS. Si existiera un host virtual basado en IP asociado a ese nombre que además indica número de puerto, este tendría preferencia sobre un host virtual que si coincidiera el nombre DNS pero que no indica número de puerto.


De DNS a IP.

Primero aquel que coincida la IP de forma explicita, si varios, aquel que explicite el puerto y coincida, y si varios (o ninguno explicita el puerto) entonces aquel que coincida en ServerName,

y después el primero fichero alfabético.


Criterio para determinar el host virtual que atiende la solicitud HTTP recibida en el servidor web Aache

sábado, 28 de octubre de 2017

Recuperar todos los registros de recursos de una zona DNS

Mediante las transferencias de zona, un servidor secundario (para una determinada zona) recibe la información de los RR (registros de recursos) que un servidor primario (de esa zona) almacena y mantiene sobre esa zona. El servidor secundario, de este modo alberga una copia de solo lectura de los RR definidos para la zona en el servidor primario.

El mensaje DNS que se debe enviar al servidor primario para recuperar esta informacion es similar al de una consulta DNS (Query) entre un cliente y el servidor DNS. No obstante, la conexión se realiza mediante TCP y no UDP aunque se utiliza el mismo número de puerto, el 53. Además de esto, el tipo de RR que se especifica en la consulta DNS es el tipo AXFR.

Podemos hacer una prueba para ver que respuesta se obtiene cuando se realiza un consulta al servidor DNS y se indica como tipo de registro AXFR mediante dig.

>dig @servidordns [FQDN] AXFR

El resultado será la totalidad de registros de recursos de la zona, sea cual sea su tipo.

jueves, 25 de mayo de 2017

nameserver 127.0.1.1 en resolv.conf no se quita!!

 Cuando no funciona directamente la orden
>dig FQDN

y si
>dig @127.0.0.1 FQDN

El fichero de configuracion de las opciones de cliente de dns resilv.conf está controlado por el programa NetworkManager. Este programa es la altinativa a la configuración manual de los ficheros de configuracion de red de un equipo. Por eso, sobreescribe todo lo que se escriba manulamente en el fichero resolv.conf. Otros ficheros no los resscribe, pero su contenido es directamente ignorado.

NetworkManager añada una linea nameserver 127.0.1.1 si en su fichero de configuracion se le indica que utlice el programa dnsmasp para hacer de servidor de fowarding de dns local. En ese caso el lugar de insertar las direcciones IP de los servidores DNS primarios, secunadrios, etc configurados en las interfaces de red insertará una unica linea nameserver 127.0.1.1 para contactar con el programa dnsmasq.

Si no queremos usar el servidor local de forwarding entonces haremos lo siguiente:
Editar el fichero y comentar la linea dns=dnsmasq

sudo nano /etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile,ofono
#dns=dnsmasq
 
Y reiniciar el servicio del NetworkManager:
 
sudo service network-manager restart

Comprobar el contenido del archivo /etc/resolv.conf


Fuentes
https://askubuntu.com/questions/627899/nameserver-127-0-1-1-in-resolv-conf-wont-go-away

miércoles, 14 de diciembre de 2016

Actualizaciones dinamicas de DNS mediante DHCP



DNS Dinamico

Es el mecanismo mediante el cual modificamos la información contenida en los ficheros de registros de recursos de las zonas definidas como primarias en un servidor DNS, mientras este se encuentra en ejecución, sin tener que editar ningún fichero de zona.

Mediante este sistema podemos configurar el servidor DNS para que reciba actualizaciones dinámicas que el servidor DHCP le enviará cuando asigne una direccion IP a un cliente.

El cliente informará al servidor DHCP de su cual es su nombre y el servidor DHCP le cede una IP. Por tanto, el servidor DHCP cuenta con la información tanto de la IP como del nombre del equipo cliente, y puede entonces solicitar al sercidor DNS que incluya un registro tipo A que asocie ese nombre con la IP en el dominio de resolucion directa y la IP con el nombre en un registro PTR en la zona de resolución inversa.

Por ejemplo, si el cliente se llama portatil y la IP que le ha sido asignada dinamicamente mediante DHCP es 192.168.100.199 dentro de la red 192.168.100.0/24 y el dominio aulaser.com entonces se deberia añadir un registro de tipo A a la zona de resolucion directa del dominio y un registro de tipo PTR en la zona de resolcion inversa.


En aulaser.com.

portatil IN A 192.168.100.199

En 100.168.192.in-addr.arpa.

199 IN PTR portatil.aulaser.com.

Para que una zona sea dinamica basta con configurar que permite actualizaciones como opcion en la definicion de la zona.

allow-update { }

Si la zona es dinamica estará sufriendo modificaciones, y para asegurarnos que no se pierden cuando queramos realizar nuevas modificaciones manuales en el fichero debemos previamente congelar la zona.

Paso 1. Crear una clave dnssec

Mediante el siguiente comando:

sudo dnssec-keygen -K /etc/bind -a HMAC-MD5 -b 128 -n USER dhcpupdate

opciones:
K - directorio donde guarda los ficheros con las claves
a - algoritmo
b - tamaño en bits
n - tipo de clave
y finalmente el nombre de la clave

Cuando termina nos hará un eco del nombre del fichero .key

Kdhcpupdate.+157+05787.key

Lo abrimos para ver la clave y el token

dhcpupdate. IN KEY 0 3 157 isgrJD32SZV0f0zaWIS7pw==


Paso 2. Configurar BIND

Ahora configuraremos el named.conf de BIND

Añadimos la siguiente entrada

key dhcpupdate {
    algorithm hmac-md5;
    secret "isgrJD32SZV0f0zaWIS7pw==";
    };

Podemos hacerlo desde la opcion DNS Keys en Webmin

Paso 3. Permitir actualizacion a las zonas

En el fichero named.conf.local añadir la opcion

allow-update { dhcpupdate };

dentro de la configuracion de la zona



zone "aulaser.com" {
    type master;
    file "/var/lib/bind/aulaser.com.hosts";
    allow-transfer {
        192.168.100.11;
        };
    allow-update {
        key dhcpupdate;
        };
    };

zone "100.168.192.in-addr.arpa" {
    type master;
    file "/var/lib/bind/192.168.100.rev";
    allow-update {
        key dhcpupdate;
        };
    };

No olvidarse de actualizar la configuracion del servidor

Paso 4. Prueba

Para probar que el servidor DNS permite actualizaciones automaticas de DNS
tenemos el comando

nsupdate

lo usaremos en modo interactivo y le iremos enviando comandos

>server servidor.aulaser.com
>key dhcpupdate isgrJD32SZV0f0zaWIS7pw==
>zone aulaser.com
>update add prueba.aulaser.com. 3600 IN A 192.168.100.199
>send
>zone 100.168.192.in-addr.arpa
>update add 199.100.168.192.in-addr.arpa. 3600 IN PTR prueba.aulaser.com.
>send

Salimos del programa nsupdate  con el commando
>quit

y hacemos un

>dig prueba.aulaser.com

y un

>dig -x 192.168.100.199


Paso 5. Configuración de DHCP

En dhcpd.conf

ddns-update-style interim;
update-static-leases on;

key dhcpupdate {
    secret isgrJD32SZV0f0zaWIS7pw==;
    algorithm hmac-md5;
    }

# Zona de resolucion directa aulaser.com
zone aulaser.com. {
    primary servidor.aulaser.com;
    key dhcpupdate;
    }

# Zona de resolucion inversa de aulaser.com - red 192.168.100.0/24
zone 100.168.192.in-addr.arpa. {
    primary servidor.aulaser.com;
    key dhcpupdate;
    }


# Aula de SER
subnet 192.168.100.0 netmask 255.255.255.0 {
    allow unknown-clients;
    allow client-updates;
    ddns-rev-domainname "in-addr.arpa";
    ddns-domainname "aulaser.com.";
    default-lease-time 60;
    ddns-updates on;
    option domain-name-servers 192.168.100.254;
    option domain-name "aulaser.com";
    option broadcast-address 192.168.100.255;
    option subnet-mask 255.255.255.0;
    option routers 192.168.100.254;
    pool {
        range 192.168.100.101 192.168.100.150;
        }

    }


Los cambios de IP no surtiran efecto inmediato ya que se guardan las resoluciones en cache local de los equipos, para vaciar/limpiar la cache ejecutamos el comando

>sudo systemd-resolve --flush-caches


Fuentes:

http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/#id2255993

https://lani78.com/2012/07/23/make-your-dhcp-server-dynamically-update-your-dns-records-on-ubuntu-12-04-precise-pangolin/

https://lani78.com/2008/08/12/dhcp-server-update-dns-records/

http://www.zytrax.com/books/dns/ch9/dhcp.html

http://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address/

https://askubuntu.com/questions/2219/how-do-i-clear-the-dns-cache






viernes, 7 de octubre de 2016

Iniciar, detener, recargar la configuración y mostrar el estado actual de servidor DNS BIND

Ademas de poder hacer todas estas acciones desde webmin, debemos saber que podemos realizarlas desde la linea de comandos.
Para ello tenemos 2 opciones:
  1. Utilizar el comando service bind opcion
  2. Mediante la orden  /etc/init.d/bind9 opción

Como opciones tenemos:
- start: iniciar el servicio DNS
- stop: detener el servicio DNS
- restart: reiniciar el servicio DNS
- reload: recargar los cambios habidos en el fichero de configuración y los ficheros de zonas
- status: Ver información del estado actual del servicio

Fuente:
http://www.cyberciti.biz/faq/start-stop-restart-bind9-linux-command/

Ver información de log relacionada con la actividad del servidor BIND

El servidor DNS Bind registra todos sus mensajes de actividad en fichero /var/log/syslog del sistema.

Podemos ver las ultimas lineas de este fichero desde webmin si desplegamos el grupo System y vamos a la opción System logs. Una vez ahí, elegimos el enlace que dice "ver" de la fila correspondiente al fichero syslog.

Tambien podemos ejecutar el comando cat para visualizar el contenido de un fichero

>cat /var/log/syslog

o abrirlo en un editor de texto con

>leafpad /var/log/syslog

Y buscar información detallada sobre los posibles errores que puedan estar ocurriendo en el servicio.

El servidor local de DNS bind9 no resuelve consultas DNS externas

El problema radica en que tenemos habilitado el DNSSEC en la configuración inicial tras la instalación de BIND.

Para deshabilitarlo debemos acceder al fichero de configuración /etc/bind/named.conf.options y cambiar las opciones de dnssec para que queden así:

dnssec-enable no;
dnssec-valitation no;

Aplicar la configuración y listo.

Fuente:
https://spectlog.com/content/BIND_named:_error_(no_valid_DS)_resolving