bind – tecnocracia .es

A la hora de administrar un servidor de nombres DNS sobre bind, debemos tener en cuenta algunos aspectos importantes.

Chroot

Es mejor aislar mediante chroot el servicio de DNS, de forma que los ataques sobre bind, no comprometan el resto de la máquina. En el caso de redhat enterprise linux, nos lo paquetizan como named-chroot

yum install -y named-chroot

Administración gráfica: webmin

Para evitar errores de escritura, la interfaz de webmin, es una ayuda para hacer cambios, y verificar la sintáxis de todos los archivos.

Comprobación de sintáxis tras los cambios named-checkconf

Si preferimos usar el editor de textos, antes de cargar el servicio y, ante la posibilidad de que haya errores de sintáxis, lo mejor es usar named-checkconf.

named-checkconf -t /var/named/chroot /etc/named.conf

Replicando los cambios mediante puppet

Si estamos usando puppet para replicar los cambios en distintos DNS, es mejor poner un indicador en los archivos que, tras un cambio, deben reiniciar el servicio de nombres.

 # add a notify to the file resource
  file { '/var/named/chroot/etc/named.conf':
    notify  => Service['named-chroot'],  # this sets up the relationship
    ......
  }

Queremos que una serie de máquinas con apache, usen el siguiente método de autenticación:

Validar usuario en directorio activo
Validar usuario local (si hay problemas con el directorio activo).

Instalamos los módulos de apache para aceptar ldap:

apt-get install -y libapache-authznetldap-perl libapache-session-ldap-perl libapache2-mod-ldap-userdir

Activamos el módulo de ldap en apache

a2enmod authnz_ldap

Versión 1: Usuario válido en dominio

El excelente tutorial de adam.shand.net , nos propone una primera versión:
<Location /aplicacion1> AuthType Basic AuthBasicProvider ldap AuthName "Restricted Directory" require valid-user

AuthLDAPURL ldap://adserver.domain.com/dc=domain,dc=com?sAMAccountName?sub
AuthLDAPBindDN anonymous@domain.com
AuthLDAPBindPassword secretpassword
</Location>

Para probar la cadena de conexión, se puede usar Apache Directory Studio.

Versión 2: Usuario válido en dominio de un grupo concreto (member of)

Añadimos en el parámetro AuthLDAPURL, la consulta después de sub, para que coja los usuarios de un dominio concreto.

<Location /aplicacion1> AuthType Basic AuthBasicProvider ldap AuthName "Restricted Directory" require valid-user

AuthLDAPURL ldap://adserver.domain.com/dc=domain,dc=com?sAMAccountName?sub?(memberOf=CN=departmentA,CN=Users,DC=domain,DC=com)
AuthLDAPBindDN anonymous@domain.com
AuthLDAPBindPassword secretpassword
</Location>

Versión 3: Aceptar también usuarios locales

Cambiamos el comportamiento de la autenticación ldap, para que no sea la única opción, con AuthzLDAPAuthoritative off

Además, aceptamos también la configuración desde nuestro fichero local de usuarios

<Location /aplicacion1> AuthType Basic AuthName "Restricted Directory" AuthBasicProvider ldap require valid-user

# Configuracion contra directorio activo:
AuthLDAPURL
ldap://adserver.domain.com/dc=domain,dc=com?sAMAccountName?sub?(memberOf=CN=departmentA,CN=Users,DC=domain,DC=com)
AuthLDAPBindDN anonymous@domain.com
AuthLDAPBindPassword secretpassword

AuthzLDAPAuthoritative off

# Configuración local

AuthUserFile /etc/apache/.htpasswd
AuthGroupFile /dev/null

Para crear el archivo local de contraseñas en apache:

htpasswd -c .htpasswd user

Para editar las contraseñas de un usuario concreto:

htpasswd .htpasswd user

Versión 4: aceptando también ntlm

Para rizar el rizo, querríamos que acepte las credenciales de windows de forma directa, sin que el usuario tenga que introducir las credenciales.

Vamos a usar el módulo Apache2::AuthenNTLM

El problema es que no se verifica el grupo de dominio, cualquier usuario que exista en dominio, entra en el apache.

<Location /aplicacion1> AuthType ntlm, Basic AuthBasicProvider ldap AuthName "Restricted Directory" require valid-user

AuthzLDAPAuthoritative off

# Configuración local
# Configuración ntlm:
# domain pdc bdc
# pdc: primary domain controller
# bdc: backup domain controller
PerlAddVar ntdomain “name_domain1 name_of_pdc1”
PerlAddVar ntdomain “other_domain pdc_for_domain bdc_for_domain”

PerlSetVar defaultdomain wingr1
PerlSetVar splitdomainprefix 1
PerlSetVar ntlmdebug 1

AuthUserFile /etc/apache/.htpasswd
AuthGroupFile /dev/null

Versión 5: ntlm con módulo python

Legrandin nos propone un módulo python para hacer más sencilla la integración con ntlm version 2.

El problema de este tipo de acceso, es que no permite autenticar sin el dominio. En caso de caida o aislamiento del dominio, no se puede recaer en los usuarios locales de nagios.

Existe opción de especificar grupos de dominios, aunque es experimental.

Instalar módulos que nos faltan:

sudo apt-get update sudo apt-get install libapache2-mod-python python-crypto git git clone https://github.com/Legrandin/PyAuthenNTLM2.git cd PyAuthenNTLM2 sudo python setup.py install -f

La configuración de apache quedaría:

<Location /aplicacion1> AuthType ntlm AuthName "Restricted Directory" require valid-user # Configuración de autenticación ntlm: PythonAuthenHandler pyntlm PythonOption Domain adserver.domain.com # pdc : Primary Domain Controller PythonOption PDC 192.1.2.45 # bdc : Backup Domain controller. PythonOption BDC 192.1.2.46 Require group grupo_dominio1,grupo_dominio2

Versión 6: libapache2-authenntlm-perl

Vamos a probar authenntlm-perl, que, según este tutorial es ridículamente fácil:

apt-get install libapache2-authenntlm-perl

Etiqueta: bind

DNS: named-chroot comandos comunes