facebook cdr twitter cdr   instagram cdr
Viernes, 29 September 2017 13:37

8. Enrutamiento, proxy y OpenLDAP

Escrito por
Valora este artículo
(1 Voto)

En este artículo veremos cómo hacer que un servidor Linux sea capaz de enrutar para compartir una conexión a Internet. También utilizaremos los cortafuegos iptables para restringir el uso de la conexión a Internet. Con el servidor proxy, aceleraremos la conexión a Internet. El servidor OpenLDAP permitira gestionar usuarios de una forma más eficiente.

8.1 Enrutamiento en Linux

Se puede definir el enrutamiento como la capacidad de transmitir datos entre redes interconectadas. Al agente encargado de realizar este encaminamiento de información entre redes se conoce como enrutador o router pudiendo ser de tipo hardware si es un dispositivo físico dedicado al encaminamiento y de tipo software en caso de ser un PC que ejecuta una aplicación que realice las funciones propias del enrutamiento.

Con el software adecuado, nuestro servidor Linux podrá actuar de enrutador en nuestra red de manera que permitirá que los equipos de la red local se conecten a Internet como si lo hicieran a través de un router.

La tecnología empleada para permitir que los equipos de la red local se conecten a Internet a través de nuestro servidor Linux se denomina NAT - Network Address Traslation (Traducción de Direcciones de Red). El software NAT que se ejecuta en nuestro servidor permite, que con una única dirección IP pública en el servidor, tengan acceso a Internet el resto de PCs de la red. En los PC's de la red local se deberá configurar como puerta de enlace (gateway) la dirección IP interna del servidor para que sea éste quien reciba y procese los paquetes provenientes de la red interna y con destino hacia Internet.

Cuando desde un PC de la red local se quiere acceder a Internet, el paquete de datos se enviará al servidor linux ya que es la puerta de enlace. El software NAT del servidor cambiará en el paquete de datos la dirección IP de origen del PC de la red local por la dirección IP pública del servidor y lanzará el paquete de datos hacia Internet. En una tabla interna almacenará el puerto de salida del paquete junto con la IP del PC de la red local con la finalidad de que cuando llegue la respuesta desde Internet, realizar el proceso inverso y poder redirigirlo hacia el PC que lanzó la petición.

Si nuestro servidor Linux, dispone además de servidor DHCP, la configuración de las direcciones IP, la puerta de enlace y el servidor DNS de nuestros PC's, podrá ser establecida automáticamente por el servidor DHCP.

Configuraciones establecidas automáticamente por el Servidor DHCP

configuraciones establecidas

Una alternativa podría ser instalar en el servidor un proxy como squid, de esa forma las páginas accedidas por los clientes serían cacheadas en el servidor con lo cual se aceleraría la conexión a Internet, especialmente cuando son muchos los clientes que acceden a los mismos sitios. Un proxy facilita también el control de la conexión impidiéndola o restringiéndola a medida de nuestras necesidades. El inconveniente de compartir una conexión a Internet con un proxy es que trabaja a nivel de aplicación y por tanto del protocolo de cada aplicación (HTTP, FTP, SMTP, etc...). Esto obliga a configurar las aplicaciones (navegador, clientes de correo, clientes ftp, etc...) para que utilicen el proxy, cosa que no es necesario hacer cuando se dispone de un router ya que el router NAT trabaja a nivel de red TCP/IP y es totalmente trasparente a las aplicaciones.

Otro servicio que se podría disponer en el servidor es un cortafuegos como iptables que permite filtrar qué paquetes de datos pueden entrar y qué paquetes de datos pueden salir, con la finalidad de controlar el acceso a Internet y ganar en seguridad frente a ataques externos.

Más adelante veremos una configuración básica de iptables que nos permitirá permitir o denegar las conexiones a diferentes redes y puertos, así como una configuración básica de squid para poder compartir y controlar la conexión a Internet mediante el proxy.

8.1.1 Situación de partida

En nuestra organización hemos venido detectando problemas de saturación de la línea de conexión a Internet sin motivo justificado. Hemos detectado que en algún ordenador de la sala de trabajadores y de algún departamento hay instalados programas de P2P (descarga masiva) y somos conscientes de que estos programas saturan el canal de salida a Internet de la compañía, además sospechamos que los usuarios también utiliza este tipo de programas.

El router ADSL está conectado a un switch y por lo tanto a través de múltiples utilidades es fácil conocer su dirección IP y configurar nuestro equipo como puerta de enlace, con el consiguiente acceso libre a Internet y a la descarga masiva. Nos encontramos con un esquema de este tipo:

Esquema en el que los PC's tienen acceso al router

esquema pc

Este esquema no permite controlar el tráfico de red puesto que los PC's tienen acceso directo al router.

Situando el servidor entre la red y el router, todo el tráfico hacia Internet pasa por el servidor lo que nos permitirá analizarlo, generar estadísticas, filtrar accesos, instalar un proxy-caché, etc; de forma sencilla y centralizada.

esquema servidor

8.1.2 Activación del enrutamiento en Linux

Las funciones de enrutamiento mediante NAT son realizadas por el cortafuegos que analizará los paquetes provenientes de la red local interna cuyo destino sea Internet y los modificará convenientemente para que salgan hacia Internet como si fueran emitidos por el servidor. A partir del núcleo 2.4 de Linux, los cortafuegos empleados son iptables.

Para posibilitar que nuestro servidor Linux sea capaz de comportarse como un router y hacer de puerta de enlace para los PC's de nuestra red local, será necesario crear un script que configure el cortafuegos iptables para que realice NAT desde dentro de la red local hacia Internet.

8.1.3 Creación del script para activar enrutamiento

Para activar el enrutamiento en un sistema Linux, tan solo basta con poner a '1' la variable ip_forward del sistema, es decir, basta con ejecutar desde una consola de root:

sudo echo "1" > /proc/sys/net/ipv4/ip_forward

Posteriormente tendríamos que configurar el filtrado para que acepte el redireccionamiento de paquetes desde dentro hacia fuera de nuestra red y mediante NAT permita que los PC's de la red interna naveguen con la dirección IP 'publica' del servidor. Supongamos que el router Linux tiene una tarjeta (eth0) configurada con la IP 192.168.1.2/24 y conectada al router, cuya IP es 192.168.1.1/24, y por otro lado, tenemos otra tarjeta (eth1) configurada con la IP 10.0.0.1/8 y conectada al switch para dar servicio a nuestra red interna que utiliza el rango 10.0.0.0/8. Nuestro esquema sería como el que vemos en la siguiente figura:

Router Linux

router linux

Tendríamos que indicar que se acepten todos los paquetes que son para reenviar, es decir, aquellos que llegan a nuestra máquina pero que no es ella la destinataria. Para ello, tendríamos que aceptar los paquetes de tipo FORWARD, como veremos en la siguiente sección. Por otro lado, tendríamos que indicar que los paquetes que llegan desde nuestra red interna (-s 10.0.0.0/8) y que salgan por la interfaz eth0 hacia el router (-o eth0), después de enrutarlos en nuestra máquina (POSTROUTING), debemos enmascararlos (MASQUERADE), es decir, hacer NAT. Los comandos a ejecutar serían:

Haciendo NAT en el servidor:

sudo iptables -A FORWARD -j ACCEPT

sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

Podríamos realizar un script que activara el enrutamiento y el NAT y otro para desactivarlo. Para activar-enrutamiento.sh.

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -j ACCEPT

iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

Desactivar-enrutamiento.sh

echo "0" > /proc/sys/net/ipv4/ip_forward

Así, nuestro servidor se convertiría en un router. Si todas las comunicaciones de la red pasan por nuestro servidor, podremos tenerlas controladas, como veremos en las siguientes secciones.

Cuando activamos el enrutamiento en Linux, nuestra máquina se convierte en un router automático, de forma que todo lo que entre por la interfaz eth0 con destino a una red diferente de la definida en eth0, lo reenviará por la interfaz eth1 y de igual forma, todo lo que entre por la interfaz eth1 con destino a una red diferente de la definida en eth1, lo reenviará por la interfaz eth0. Es el funcionamiento normal de un router, enrutar todo.

En algunos casos, puede que nos interese que ciertos paquetes salgan por una interfaz concreta. Por ejemplo, supongamos que en nuestra red disponemos de dos conexiones ADSL independientes, una para dar servicio de conexión a Internet al servidor (interfaz de producción) y otra, para conectarnos desde nuestra casa al servidor, para realizar tareas de administración (interfaz de administración).Supongamos que la interfaz eth0 está conectada al router ADSL de producción y la interfaz eth1 está conectada al router ADSL para realizar tareas de administración.

Rutas fijas

rutas fijas

Lo normal es que la interfaz eth0 tenga configurada como puerta de enlace la IP del router de conexión a Internet, pero la interfaz eth1 no debería tener configurada la puerta de enlace, para que no exista tráfico hacia Internet por dicha interfaz. Si en el ADSL de nuestra casa tenemos IP fija, podemos crear una ruta para que cuando la IP destino sea la IP fija de nuestra casa, los paquetes se enruten por eth1 en lugar de hacerlo por eth0. Ejemplo, si nuestra IP de casa es 80.58.12.27, el comando a ejecutar será:

sudo route add 80.58.12.27 eth1

En lugar de una IP concreta, quizás nos interese crear una ruta para toda una red. Supongamos que queremos que cuando la IP destino sea una IP del CNICE, salga por la interfaz eth1. Teniendo en cuenta que el rango de IP's públicas del CNICE es 192.144.238.0/24, el comando a ejecutar sería:

sudo route add -net 193.144.238.0/24 eth1

Si queremos eliminar una ruta, utilizaremos el parámetro 'del' seguido de la IP o la red destinataria. Ejecutaríamos el siguiente comando:

sudo route del -net 193.144.238.0/24

Si queremos ver la configuración de la tabla de rutas, debemos ejecutar el comando route sin parámetros:

sudo route

Establecer rutas puede ser muy interesante cuando queremos dividir nuestra red en diferentes subredes y disponemos de un servidor con varias tarjetas de red.

 8.2 Cortafuegos iptables

El cortafuegos utilizado para gestionar las conexiones en Linux son iptables. Las posibilidades de iptables son prácticamente infinitas y un administrador que quiera sacarle el máximo provecho, puede realizar configuraciones extremadamente complejas. Para simplificar, diremos que básicamente, los cortafuegos iptables permite crear reglas que analizarán los paquetes de datos que entran, salen o pasan por nuestra máquina, y en función de las condiciones que establezcamos, tomaremos una decisión que normalmente será permitir o denegar que dicho paquete siga su curso.

El cortafuegos controla las comunicaciones entre la red y el exterior

cortafuegos

Para crear las reglas, podemos analizar muchos aspectos de los paquetes de datos. Podemos filtrar paquetes en función de:

Tipo de paquete de datos:

  • Tipo INPUT: Paquetes que llegan a nuestra máquina
  • Tipo OUTPUT: Paquetes que salen de nuestra máquina
  • Tipo FORWARD: Paquetes que pasan por nuestra máquina

Interfaz por la que entran (-i = input) o salen (-o = output) los paquetes:

  • eth0
  • eth1
  • wlan0
  • ppp0

IP origen de los paquetes (-s = source):

  • IP concreta, ej: 10.0.1.3
  • Rango de red, ej: 10.0.1.0/8

IP destino de los paquetes (-d = destination):

  • IP concreta, ej: 10.0.1.3
  • Rango de red, ej: 10.0.1.0/8

Protocolo de los paquetes (-p = protocol):

  • TCP
  • UDP
  • ICMP

Hacer NAT (modificar IP origen y destino para conectar nuestra red a otra red o a Internet) y...

  • Filtrar antes de enrutar: PREROUTING
  • Filtrar después de enrutar: POSTROUTING

Los paquetes pueden entrar, salir o pasar

paquetes

Una forma sencilla de trabajar con cortafuegos iptables es permitir las comunicaciones que nos interesen y luego denegar el resto de las comunicaciones. Lo que se suele hacer es definir la política por defecto aceptar (ACCEPT), después crear reglas concretas para permitir las comunicaciones que nos interesen y finalmente, denegar el resto de comunicaciones. Lo mejor será crear un script en el que dispondremos la secuencia de reglas que queremos aplicar en nuestro sistema. Un ejemplo típico podría ser el siguiente:

!/bin/sh. Script cortafuegos.sh para la configuración de iptables. Primero borramos todas las reglas previas que puedan existir

iptables -F

iptables -X

iptables -Z

iptables -t nat -F

Después definimos que la politica por defecto sea ACEPTAR

iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT

iptables -P FORWARD ACCEPT

iptables -t nat -P PREROUTING ACCEPT

iptables -t nat -P POSTROUTING ACCEPT

Para evitar errores en el sistema, debemos aceptar todas las comunicaciones por la interfaz lo (localhost)

iptables -A INPUT -i lo -j ACCEPT

Aceptamos las comunicaciones que nos interesan y luego denegamos el resto. Ejemplo: Denegamos acceso al departamento 1

iptables -A FORWARD -s 10.0.1.0/24 -j DROP

Aceptamos SMTP, POP3 y FTP (correo electrónico y ftp)

iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 25 -j ACCEPT

iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 110 -j ACCEPT

iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 20 -j ACCEPT

iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 21 -j ACCEPT

HTTP y HTTPS no es necesario porque nuestro servidor será servidor proxy. Dejamos comentadas las líneas, por si algún día las necesitamos

#iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 80 -j ACCEPT

#iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 443 -j ACCEPT

DNS no es necesario porque nuestro servidor será servidor DNS. Dejamos comentadas las líneas (TCP y UDP), por si algún día las necesitamos

#iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 53 -j ACCEPT

#iptables -A FORWARD -s 10.0.0.0/8 -p udp --dport 53 -j ACCEPT

Al PC del Gerente le damos acceso a todo (cliente VIP)

iptables -A FORWARD -s 10.0.0.7 -j ACCEPT

Denegamos resto de comunicaciones (no funcionará el p2p)

iptables -A FORWARD -s 10.0.0.0/8 -j DROP

Hacemos NAT si IP origen 10.0.0.0/8 y salen por eth0

iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

Activamos el enrutamiento:

echo 1 > /proc/sys/net/ipv4/ip_forward

Comprobamos cómo quedan las reglas

iptables -L -n

En el script, vemos una serie de reglas que se van a ir ejecutando secuencialmente conformando la configuración del cortafuegos iptables. Cuando indicamos "-A FORWARD" nos referimos a paquetes que van a pasar por nuestro servidor. Otras opciones son "-A INPUT" y "-A OUTPUT". Acto seguido ponemos las condiciones. Si ponemos "-s 10.0.0.0/8" nos referimos a paquetes cuya IP origen está en el rango 10.0.0.0/8. Cuando ponemos "-p tcp" nos referimos a paquetes que utilizan el protocolo tcp. Cuando indicamos "--dport 25" nos referimos a paquetes cuyo puerto de destino es el 25, es decir, protocolo SMTP (correo saliente). Si en una regla no ponemos la condición -p ni la condición --dport, significa que no nos importa el protocolo (cualquier protocolo) ni nos importa el puerto destino (cualquier puerto destino). Por ejemplo, en la regla donde damos acceso al PC del Gerente, no hemos indicado ni protocolo ni puerto, por lo que dejará pasar todos los protocolos y todos los puertos.

8.3 Proxy Squid

Un proxy de conexión a Internet es un servidor que hace de intermediario entre los PC's de la red y el router de conexión a Internet, de forma que cuando un usuario quiere acceder a Internet, su PC realiza la petición al servidor Proxy y es el Proxy quien realmente accede a Internet. Posteriormente, el Proxy enviará los datos al PC del usuario para que los muestre en su pantalla. El PC del usuario no tendrá conexión directa con el router, sino que accederá a Internet por medio del proxy.

El proxy es un intermediario

proxy

8.3.1 Ventajas de disponer de un proxy:

  • Los PC's de los usuarios no tienen acceso al router, todas las comunicaciones exteriores pasarán por el Proxy, lo que nos permitirá tener las comunicaciones bajo control. Podemos permitir o denegar el acceso web, ftp, email, messenger, p2p, etc.
  • Las páginas se cachean en la memoria temporal del proxy lo cual acelera la descarga cuando varios usuarios acceden a las mismas páginas a la vez. Esta circunstancia se da mucho en las organizaciones cuando el trabajador está explicando un tema y todos los usuarios acceden a la vez a la misma página.
  • Es fácil crear una lista de URL's prohibidas a las que el proxy denegará el acceso.
  • Permite crear una lista de palabras prohibidas en URL. El proxy denegará el acceso cuando se introduzcan en formularios de búsqueda o en la barra de direcciones.
  • Se puede permitir o denegar el acceso a subredes o a PC's concretos. Si diseñamos la red de forma que cada departamento(aula) de la compañía u organización tenga un rango determinado, por ejemplo 10.0.X.Y donde X es el número de departamento e Y el número de PC, sería posible permitir o denegar la conexión a Internet departamento por departamento.
  • El proxy guarda informes de todas las conexiones que hacen los usuarios. Al principio puede ser interesante ver a qué páginas de contenido inadecuado acceden nuestros usuarios, para agregarlas a la lista de URL's prohibidas.
  • Los PC's de nuestra red están más seguros de ataques externos ya que el proxy hace de barrera cortafuegos.

8.3.2 Inconvenientes de la utilización de un Proxy

No todo son ventajas, también hay algún inconveniente en la utilización de un Proxy:

  • Para que las aplicaciones accedan a Internet a través del proxy, es necesario configurar cada aplicación: navegador web, cliente ftp, cliente de correo, etc.
  • Todas las comunicaciones con el exterior pasarán por el servidor. Si el proxy falla, la red se quedará sin conexión a Internet. Para subsanar lo más rápidamente posible el problema ante un fallo del Proxy, será conveniente disponer de un proxy de repuesto.
  • El proxy requiere mantenimiento. Para que todo funcione, es necesario que exista un administrador de la red que se encargue de actualizar, revisar, mantener y reparar el proxy cuando deje de funcionar.

8.3.3 Diseño recomendado de la red de la organización

Para facilitar la gestión del acceso a Internet en la organización, se recomienda diseñar la red de forma que cada aula tenga un rango de IP's determinado. Para no quedarnos cortos, lo mejor es utilizar el rango 10.0.0.0/8 siguiendo el esquema 10.W.X.Y donde W sería el número de edificio, X el número de departamento e Y el número de PC, que nos permitiría tener un máximo de 254 edificios con 254 departamentos cada uno y 254 PC's por departamento. Si disponemos de un único edificio con 3 aulas, un sencillo esquema de direccionamiento IP podría ser el siguiente:

Direccionamiento de nuestra red

direccionamiento

  • Utilizar el rango 10.0.0.0/8 para el direccionamiento de red de la organización
  • Utilizar la IP 10.0.0.1 para el servidor proxy. Conviene que dicho servidor sea también servidor DNS.
  • Las departamentos usarán la dirección 10.0.X.Y donde X sea el número de aula e Y sea el número de PC. Ejemplo, si en el departamento 1 hay 4 PC's, en el departamento 2 hay 3 y en el departamento 3 hay 3, el direccionamiento sería:

Nota: En los nombres de las PC's como a3pc1, 'a' es de 'area'.

Área PC Nom. IP Máscara P.Enlace DNS
--------------------------------------------------------------------------------

1 1 a1pc1 10.0.1.1 255.0.0.0 sin configurar 10.0.0.1

1 2 a1pc2 10.0.1.2 255.0.0.0 sin configurar 10.0.0.1

1 3 a1pc3 10.0.1.3 255.0.0.0 sin configurar 10.0.0.1

1 4 a1pc4 10.0.1.4 255.0.0.0 sin configurar 10.0.0.1

2 1 a2pc1 10.0.2.1 255.0.0.0 sin configurar 10.0.0.1

2 2 a2pc2 10.0.2.2 255.0.0.0 sin configurar 10.0.0.1

2 3 a2pc3 10.0.2.3 255.0.0.0 sin configurar 10.0.0.1

3 1 a3pc1 10.0.3.1 255.0.0.0 sin configurar 10.0.0.1

3 2 a3pc2 10.0.3.2 255.0.0.0 sin configurar 10.0.0.1

3 3 a3pc3 10.0.3.3 255.0.0.0 sin configurar 10.0.0.1

8.3.4 Instalación del Proxy squid

Linux dispone del Proxy squid. Se trata de una aplicación de gran éxito que se lleva utilizando muchos años y dispone de cientos de posibilidades para personalizar su funcionamiento a nuestras necesidades. Para instalar la última versión de squid, podemos hacerlo con apt-get desde una consola registrados como root:

sudo apt-get install squid

De esta forma instalaríamos los programas necesarios para disponer de un completo servidor Proxy en nuestra red. Tan solo será necesario configurarlo y ponerlo en marcha.

8.3.5 Arranque y parada del proxy squid

El servicio squid, al igual que todos los servicios, dispone de script's de arranque y parada en la carpeta /etc/init.d. Debemos ejecutarlos desde una consola registrados root.

sudo /etc/init.d/squid restart

Parar el servidor squid

sudo /etc/init.d/squid stop

// Recargar configuración del servidor squid

sudo /etc/init.d/squid reload

Para un arranque automático del servicio al iniciar el servidor, debemos crear los enlaces simbólicos correspondientes.

8.3.6 Configuración básica del proxy squid

El archivo de configuración del proxy es el archivo /etc/squid/squid.conf. Si observamos dicho archivo, veremos que es un archivo muy extenso en el que hay cientos de parámetros que podemos establecer, pero para una utilización básica, son unos pocos los parámetros que debemos configurar. De todos los apartados que dispone el archivo /etc/squid/squid.conf, solo destacaremos los siguientes:

8.3.6.1 OPTIONS FOR AUTHENTICATION (Opciones de autentificación)

Aquí se establecen las opciones de autentificación del Proxy. Aunque aquí no vamos a hablar de ello, existe la posibilidad de configurar squid para que solicite usuario y contraseña para poder navegar por Internet. Si se quiere hacer uso de esta funcionalidad, lo normal sería tener almacenados los usuarios y las contraseñas en un servidor LDAP y en función de los grupos a los que pertenezcan los usuarios, podríamos habilitar o deshabilitar el acceso. Esto puede ser interesante en empresas, donde el administrador de red da acceso a Internet solo a los usuarios que lo necesitan. En una organización supondría bastante trabajo llevar una administración de este tipo ya que habría que crear y gestionar unas credenciales para cada usuario de la organización y para cada trabajador. Es más fácil administrar por redes y por departamentos.

8.3.6.2 ACCESS CONTROL (Control de Acceso)

En esta sección estableceremos los permisos de acceso, es decir, quien puede navegar y quien no. Lo primero que tendremos que hacer es crear listas de control de acceso (Access Control List - ACL) y luego dar permisos a dichas listas.

Una lista de control de acceso (ACL) se crea utilizando la palabra acl seguido del nombre que queramos dar a la lista y seguido de una condición que cumplirán los miembros de la lista. Entre las condiciones más utilizadas destacamos:

  • src (IPs o URLs origen)
  • dst (IPs o URLs destino)
  • port (puertos)
  • proto (protocolos).

Ejemplos:

Si en mi red local utilizo el direccionamiento 10.0.0.0/8, puedo crear una lista para definir a toda mi red:

acl todos src 10.0.0.0/8

Si en mi red local utilizo el direccionamiento 10.0.X.0/24, para el aula X, puedo crear una lista para cada aula:

acl area1 src 10.0.1.0/24

acl area2 src 10.0.2.0/24

acl area3 src 10.0.3.0/24

acl area4 src 10.0.4.0/24

acl area5 src 10.0.5.0/24

Luego tendría que dar permiso a las listas. Para ello se utiliza la palabra clave http_access seguido del permiso allow (permitir) o deny (denegar) y seguido del nombre de la lista. Ejemplos:

Si quiero dar permiso a toda mi red para que navegue por Internet:

http_access allow todos

Si quiero dar permiso a las áreas 1, 2 y 3 para que navegue por Internet pero no quiero que naveguen las aulas 4 y 5:

http_access allow area1

http_access allow area2

http_access allow area3

http_access deny area4

http_access deny area5

Por defecto, squid viene configurado para actuar como caché de acceso a Internet, pero no tiene creadas listas de control de acceso. Si configuramos el navegador de Internet de los PC's cliente para que utilicen el Proxy, veremos que tenemos denegado el acceso al Proxy. Para empezar a disfrutar del Proxy, tendremos que crear una lista de control de acceso con el rango de nuestra red y darla permiso. Si en nuestra red utilizamos el rango 10.0.0.0/8, deberíamos añadir en /etc/squid/squid.conf:

acl todos src 10.0.0.0/8

http_access allow todos

Cuando creamos ACL's, podemos sustituir el rango de IP's por el nombre de un archivo externo, y de esa manera podemos indicar el en archivo externo el rango o los rangos de IP's a los que queremos referirnos, sin necesidad de estar continuamente modificando el archivo squid.conf. Más adelante veremos un ejemplo cómo tener un archivo externo con las URL´s prohibidas a las que no podrán navegar nuestros usuarios.

8.3.6.3 NETWORK OPTIONS (Opciones de red)

En esta sección estableceremos con el parámetro http_port, el puerto en el que escucha el Proxy. Lo mejor es dejar el valor por defecto que es el puerto 3128:

http_proxy 3128

Squid puede trabajar en modo transparente. La ventaja de configurar squid en dicho modo de trabajo, es que no sería necesario configurar el navegador de los PC's clientes para trabajar con el proxy, sino que simplemente configuramos la puerta de enlace del PC cliente con la IP del servidor proxy. Posteriormente tendremos que configurar el cortafuegos del servidor para que redirija las peticiones al puerto 80 hacia el puerto 3128 y así las reciba squid. Si deseamos poner el Proxy en modo transparente, deberemos indicarlo después del puerto. En tal caso, el parámetro http_port quedaría así:

http_proxy 3128 transparent

Luego, para redirigir las peticiones al puerto 80 hacia el puerto 3128, ejecutaremos como root:

sudo iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

El inconveniente de trabajar en modo transparente es que no sirve para el protocolo HTTPS.

8.3.6.4 MEMORY CACHE OPTIONS

En esta sección estableceremos la memoria RAM utilizada para la caché. Una buena opción es utilizar sobre un tercio de la memoria RAM del sistema. Ejemplo, si nuestro sistema tiene 512 MB de memoria RAM, una buena opción sería:

cache_mem 192 MB

8.3.6.5 DISK CACHE OPTIONS

En esta sección estableceremos el espacio de disco duro utilizado para la caché. Una buena opción es utilizar el 50% de la capacidad total del disco duro. Ejemplo, si nuestro disco tiene sistema tiene 80 GB de capacidad, una buena opción sería utilizar 40 GB. Deberemos utilizar la palabra clave cache_dir seguida de la palabra ufs que es el formato utilizado por squid, de la carpeta donde queremos que se almacene la cache, el tamaño de la caché en MB, el número de subdirectorios de primer nivel y el número de subdirectorios de segundo nivel. Ejemplo, si queremos que la caché se guarde en /var/spool/squid, que utilice 40 GB y que cachee hasta 16 subdirectorios de primer nivel y hasta 256 subdirectorios de segundo nivel, escribiremos:

cache_dir ufs /var/spool/squid 40000 16 256

8.3.7 Configuración del navegador de los PC's clientes, para que utilicen el Proxy

Supongamos que nuestro servidor Proxy tiene la IP 192.168.1.239 y el servidor squid está escuchando en el puerto 3128 que es el puerto que utiliza por defecto. Con estos dos datos, la IP y el puerto, ya podemos configurar el navegador de Internet de los PC's clientes.

8.3.7.1 Mozilla Firefox

Para que Firefox utilice nuestro Proxy en sus conexiones, debemos ir a Herramientas > Opciones > Avanzado > Red y en el apartado Conexión, hacer clic en el botón Configuración. En la ventana que aparece, debemos configurar la IP y el puerto de nuestro servidor Proxy:

Configuración del Proxy en Firefox

configuracion del proxy firefox

A partir de este momento, Firefox enviará a nuestro Proxy cualquier consulta web que realice, y será nuestro Proxy quien realizará la conexión en caso necesario.

8.3.7.2 Internet Explorer

Para indicar a Internet Explorer que debe utilizar un Proxy para realizar conexiones, debemos ir a Herramientas > Opciones de Internet > Conexiones > Configuración de LAN y activar la casilla 'Usar un servidor proxy para la LAN'. En la casilla 'Dirección' pondremos la IP de nuestro Proxy y el 'Puerto' el puerto, tal y como se muestra en la siguiente ventana:

Configuración del Proxy en Internet Explorer

configuracion del proxy ie

8.3.8 Archivo de configuración automática del proxy

Para no tener que recordar la dirección del proxy y facilitar la tarea a la hora de configurar el proxy en los PC's clientes, existe la posibilidad de crear un archivo de configuración automática del proxy. Dicho archivo indicará al navegador, en función de la URL a la que quiera conectarse, si debe hacerlo directamente o debe hacerlo a través del proxy. En un direccionamiento como el que tenemos en nuestra organización, cuando accedemos a nuestra red 10.0.0.0/8 o a la dirección de localhost 127.0.0.1, la conexión debe ser directa, en cambio, cuando accedemos a cualquier otra dirección, deberá ser a través de proxy. El archivo de configuración automática del proxy es el archivo /var/www/proxy.pac y en el escribiremos lo siguiente:

function FindProxyForURL(url,host){

if (isInNet(host, "10.0.0.0", "255.0.0.0"))

return "DIRECT";

else if (isInNet(host, "127.0.0.1", "255.255.255.255"))

return "DIRECT";

else return "PROXY 192.168.1.239:3128";

}

Configuración del Proxy a través de un archivo de configuración

configuracion del proxy archivo

8.3.9 Permitir o denegar el acceso desde ciertos rangos de IP's

Tal y como se ha comentado anteriormente, con squid es sencillo permitir o denegar el acceso a Internet por rangos de IP's. Si tenemos nuestra red diseñada de forma que cada aula utiliza un rango concreto, podremos permitir o denegar el acceso a un aula de forma sencilla.

Para no tener que tocar el archivo squid.conf, lo mejor es crear una acl que cargue los departamentos desde un archivo externo. Podemos crear con un editor de texto el archivo /etc/squid/areas-prohibidas.txt en el que indicaremos los rangos de IP's que no queremos que naveguen. Por ejemplo, si no queremos que naveguen las áreas 2 y 3, el contenido del archivo /etc/squid/areas-prohibidas.txt deberá ser:

10.0.2.0/24

10.0.3.0/24

Después tendremos que editar squid.conf para crear una ACL que cargue los rangos desde el archivo /etc/squid/areas-prohibidas.txt y deniegue el acceso a dichos rangos.

acl areas-prohibidas src "/etc/squid/areas-prohibidas.txt"

http_access deny areas-prohibidas

Por último, tan solo tenemos que recargar la configuración de squid para que entre en funcionamiento la nueva configuración:

sudo /etc/init.d/squid reload

Igualmente podemos crear una ACL para indicar las URL´s prohibidas desde un archivo externo:

Habrá que editar squid.conf e introducir estas dos líneas:

acl urls-prohibidas dst "/etc/squid/urls-prohibidas.txt"

http_access deny urls-prohibidas

Si no queremos que nuestros usuarios accedan a www.xnxx.com ni a www.xvideos.com, el contenido del archivo /etc/squid/urls-prohibidas.txt debería ser:

www.xnxx.com

www.xvideos.com

La filosofía sería denegar los departamentos prohibidos, denegar las URL´s prohibidas y luego permitir todo lo demás. Resumiendo, nuestro archivo squid.conf será como el original con las siguientes modificaciones, justo después de la línea # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS que podríamos traducir como: Inserte sus propias reglas para permitir acceso a sus clientes:

INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

acl areas-prohibidas src "/etc/squid/areas-prohibidas.txt"

http_access deny areas-prohibidas

acl urls-prohibidas dst "/etc/squid/urls-prohibidas.txt"

http_access deny urls-prohibidas

http_access allow all

Así, editando los archivos /etc/squid/areas-prohibidas.txt y /etc/squid/urls-prohibidas.txt y recargando la configuración de squid ejecutando /etc/init.d/squid reload, podemos reconfigurar squid sin necesidad de tocar el archivo de configuración squid.conf.

El inconveniente es que cada vez que queremos permitir o denegar el acceso a Internet a un aula, tenemos que andar editando el archivo areas-prohibidas.txt lo que puede resultar un poco engorroso. Podemos crear dos scripts de Unix que hagan el trabajo por nosotros y solamente tengamos que ejecutar los scripts indicando el número de aula que queremos prohibir o permitir:

Nombre del script: prohibir-area.sh

# /bin/bash

#

# Script para prohibir la navegación de un departamento # Se creará el rango del departamento en /etc/squid/areas-prohibidas.txt

# Indicar el número de area al ejecutar el script

if [ $# -ne 1 ]; then

echo "Es necesario introducir el numero de area a prohibir"

exit -1

fi

echo Prohibir navegar area $1, subred 10.0.$1.0/24

echo 10.0.$1.0/24 >> /etc/squid/areas-prohibidas.txt

/etc/init.d/squid reload

echo subredes denegadas:

cat /etc/squid/areas-prohibidas.txt

Nombre del script: permitir-area.sh

#/bin/bash

#

# Script para permitir la navegación de un departamento # Se eliminará el rango del departamento de /etc/squid/areas-prohibidas.txt

# Indicar el número de area al ejecutar el script

if [ $# -ne 1 ]; then

echo "Es necesario introducir el numero de area"

exit -1

fi

subred=10.0.$1.0/24

echo Permitir navegar area $1, subred $subred

patron=`echo /10.0.$1.0/d`

cat /etc/squid/areas-prohibidas.txt | sed -e $patron > /tmp/temp.txt

cat /tmp/temp.txt > /etc/squid/areas-prohibidas.txt

/etc/init.d/squid reload

echo Subredes denegadas:

cat /etc/squid/areas-prohibidas.txt

Si deseamos que el departamento 1 no navegue, deberíamos ejecutar: prohibir-area 1. Si luego deseamos permitir que el area 1 navegue, tendríamos que ejecutar: permitir-area 1.

Aún con los scripts prohibir-area.sh y permitir-area.sh, sigue siendo engorroso realizar cambios ya que el trabajador tendría que iniciar sesión en el servidor por ssh y lanzar el script. Lo mejor será crear una página en PHP con botones de comando, donde con un simple clic podamos ejecutar los scripts cómodamente desde el navegador.

8.3.10 Análisis de conexiones

Una de las funcionalidades principales que nos ofrece squid es que registra todos los accesos a Internet. Cada vez que un PC's accede a Internet, squid registrará en el archivo /var/log/squid/access.log la fecha y hora, el PC y la url a la que ha accedido.

/var/log/squid/access.log

8.4 OpenLDAP

Un servidor LDAP es un servidor de datos optimizado para la realización rápida de consultas de lectura y orientado al almacenamiento de datos de usuarios a modo de directorio.

La principal utilidad de un directorio LDAP es como servidor de autentificación para los distintos servicios de un sistema informático como puedan ser: autentificación para entrar en un PC, para entrar en una aplicación web, para acceder a un servidor ftp, para acceder a servidores de correo entrante POP3 y saliente SMTP, etc.

Servidor LDAP

servidor ldap

Si en nuestra red disponemos de un servidor LDAP y configuramos todos los PC's y todos los servicios de la red para que se autentifiquen en él, bastará con crear las cuentas de usuario y grupos de usuarios en nuestro servidor LDAP para que los usuarios puedan hacer uso del sistema y de sus servicios desde cualquier puesto de la red. Es un sistema ideal para centralizar la administración de usuarios en un único lugar.

En el curso veremos cómo poner en marcha un servidor LDAP y cómo configurar el resto de PC's clientes de la red para que se autentifiquen en él. También utilizaremos OpenSSL para que durante el proceso de autentificación los datos viajen encriptados por la red, así ningún curioso podrá averiguar nuestras contraseñas. Además utilizaremos LDAP para que autentifique el acceso al servidor ftp y el acceso a páginas restringidas en el servidor web.

8.5 Instalación y configuración de OpenLDAP

Para simplificar la administración de los usuarios del sistema es ideal utilizar una base de datos accesible mediante LDAP. Almacenar las cuentas de usuario de forma centralizada en un único repositorio facilitará la creación, modificación y eliminación de cuentas de usuario y grupos de usuarios. Será necesario configurar los PC's de la red para que utilicen el servidor LDAP como servidor de autentificación.

8.5.1 Instalación de OpenLDAP

El servidor OpenLDAP está disponible en el paquete slapd por tanto, lo instalaremos utilizando apt-get. También nos conviene instalar el paquete ldap-utils que contiene utilidades adicionales:

sudo apt-get install slapd ldap-utils

8.5.2 Configuración inicial de OpenLDAP

Los archivos de configuración del servidor LDAP se almacenan en la carpeta /etc/ldap/. En lugar de editar manualmente dichos archivos, es mejor lanzar el asistente de configuración de slapd. Para ello debemos ejecutar el siguiente comando:

sudo dpkg-reconfigure slapd

Lo primero que nos pregunta el asistente es si deseamos omitir la configuración del servidor LDAP:

Asistente de configuración de slapd

configuracion1 ldap

Obviamente responderemos que No, ya que precisamente lo que queremos es configurar el servidor LDAP.

Después nos preguntará si queremos que se elimine la base de datos cuando quitemos slapd. Para evitar confusiones con bases de datos anteriores, lo mejor es responder Sí:

configuracion2 ldap

Luego nos preguntará si deseamos utilizar LDAP versión 2, respondemos que No ya que apenas se utiliza.

configuracion3 ldap

Con esto habremos concluido la configuración inicial del servidor LDAP.

8.5.3 Arranque y parada manual del servidor LDAP

El servidor LDAP, al igual que todos los servicios en Debian, dispone de un script de arranque y parada en la carpeta /etc/init.d.

sudo /etc/init.d/slapd restart

Parar el servidor LDAP

sudo /etc/init.d/slapd stop

8.5.4 Arranque automático del servidor LDAP al iniciar el sistema

Para un arranque automático del servicio al iniciar el servidor, debemos crear los enlaces simbólicos correspondientes.

8.6 Administración de OpenLDAP

Una vez instalado y configurado el servidor LDAP, la siguiente tarea es la del diseño de la estructura y la introducción de datos en el directorio.

Puesto que la finalidad de nuestro servidor LDAP es que sirva de almacén de usuarios y grupos para autentificar sistemas linux y servicios como ftp y web, deberemos crear una estructura que parta de la base de nuestro directorio, para almacenar dicha información. Tal y como se explica más abajo, crearemos una unidad organizativa (ou) llamada groups, para almacenar los grupos de usuarios y crearemos otra unidad organizativa llamada users para almacenar a los usuarios.

8.6.1 Paso 1: Cargar plantillas

Al instalar el servidor LDAP, se instalan también unas plantillas que nos serviran para crear el esquema básico para almacenamiento de usuarios Unix para LDAP, lo que nos permitirá almacenar en nuestro directorio, cuentas de usuario. Para instalar las plantillas necesarias, debemos ejecutar los siguientes comandos:

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif

8.6.2 Paso 2: Archivo de configuración del esquema básico

Después crearemos un archivo en formato ldif con la configuración de nuestro esquema básico. En dicho archivo debemos configurar :

  • Base del directorio: Se configura en el parámetro olcSuffix del archivo de configuración del esquema básico. En nuestro ejemplo usaremos: dc=ieslapaloma,dc=com
  • Nombre de usuario administrador: Se configura en el parámetro olcRootDN del archivo de configuración del esquema básico. En nuestro ejemplo usaremos: cn=admin,dc=ieslapaloma,dc=com
  • Contraseña: Se configura en el parámetro olcRootPW del archivo de configuración del esquema básico. En nuestro ejemplo usaremos: ldapadmin
  • Permiso de acceso a contraseñas: Se configura en el parámetro olcAccess: to attrs=userPassword. Daremos al usuario administrador permiso de escritura y a cada usuario para cambiar su propia contraseña
  • Permiso de acceso global al directorio: Se configura en el parámetro olcAccess: to *. Daremos al usuario administrador permiso de escritura y a todos los usuarios, permisos de lectura

Almacenaremos el archivo en la carpeta temporal porque una vez procesado se debería borrar, ya que contiene la contraseña de administrador en texto plano.

# ---------- Archivo /tmp/ldapcurso-esquema-basico.ldif ----------

# Load dynamic backend modules

dn: cn=module,cn=config

objectClass: olcModuleList

cn: module

olcModulepath: /usr/lib/ldap

olcModuleload: back_hdb

 

# Database settings

dn: olcDatabase=hdb,cn=config

objectClass: olcDatabaseConfig

objectClass: olcHdbConfig

olcDatabase: {1}hdb

olcSuffix: dc=ieslapaloma,dc=com

olcDbDirectory: /var/lib/ldap

olcRootDN: cn=admin,dc=ieslapaloma,dc=com

olcRootPW: ldapadmin

olcDbConfig: set_cachesize 0 2097152 0

olcDbConfig: set_lk_max_objects 1500

olcDbConfig: set_lk_max_locks 1500

olcDbConfig: set_lk_max_lockers 1500

olcDbIndex: objectClass eq

olcLastMod: TRUE

olcDbCheckpoint: 512 30

olcAccess: to attrs=userPassword by dn="cn=admin,dc=ieslapaloma,dc=com" write by anonymous auth by self write by * none

olcAccess: to attrs=shadowLastChange by self write by * read

olcAccess: to dn.base="" by * read

olcAccess: to * by dn="cn=admin,dc=ieslapaloma,dc=com" write by * read

# ----------------------------------

Ahora habrá que cargar el servidor ldap con el archivo de configuración creado:

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/ldapcurso-esquema-basico.ldif

8.6.3 Paso 3: Creación de unidades organizativas para almacenar cuentas unix

Para que nuestro directorio LDAP pueda almacenar cuentas unix, necesitamos crear una unidad organizativa (dn: ou=users) para los usuarios y otra (dn: ou=groups) para los grupos de usuarios. Antes debemos crear la base del directorio (dn: dc=ieslapaloma,dc=com) y el usuario administrador (dn: cn=admin,dc=ieslapaloma,dc=com). Después podemos crear usuarios y grupos para hacer pruebas. Crearemos los usuarios nestor, daniel y emmanuel en el grupo trabajadores y jessica y maria en el grupo usuarios.

# ---------- Archivo /tmp/ldap-myorganization.ldif ----------

dn: dc=ieslapaloma,dc=com

objectClass: top

objectClass: dcObject

objectClass: organization

dc: ieslapaloma

o: ieslapaloma

 

dn: cn=admin,dc=ieslapaloma,dc=com

objectClass: simpleSecurityObject

objectClass: organizationalRole

cn: admin

description: LDAP administrator

userPassword:: e2NyeXB0fXdSVDNLMEpKSlQydmM=

 

dn: ou=users,dc=ieslapaloma,dc=com

objectClass: organizationalUnit

objectClass: top

ou: users

 

dn: ou=groups,dc=ieslapaloma,dc=com

objectClass: organizationalUnit

objectClass: top

ou: groups

 

dn: cn=Nestor Alejandro,ou=users,dc=ieslapaloma,dc=com

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: posixAccount

objectClass: top

cn: nestor

gidNumber: 1001

homeDirectory: /home/nestor

loginShell: /bin/bash

sn: Carreño

uid: nestor

uidNumber: 1001

 

dn: cn=Daniel Suarez,ou=users,dc=ieslapaloma,dc=com

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: posixAccount

objectClass: top

cn: daniel

gidNumber: 1001

homeDirectory: /home/daniel

loginShell: /bin/bash

sn: Suarez

uid: daniel

uidNumber: 1002

 

dn: cn=Emmanuel Martinez,ou=users,dc=ieslapaloma,dc=com

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: posixAccount

objectClass: top

cn: emmanuel

gidNumber: 1001

homeDirectory: /home/emmanuel

loginShell: /bin/bash

sn: Martinez

uid: miguel

uidNumber: 1003

 

dn: cn=Jessica Gomez,ou=users,dc=ieslapaloma,dc=com

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: posixAccount

objectClass: top

cn: jessica

gidNumber: 1002

homeDirectory: /home/jessica

loginShell: /bin/bash

sn: Gomez

uid: jessica

uidNumber: 1004

 

dn: cn=Maria Martinez,ou=users,dc=ieslapaloma,dc=com

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: posixAccount

objectClass: top

cn: maria

gidNumber: 1002

homeDirectory: /home/maria

loginShell: /bin/bash

sn: Martinez

uid: maria

uidNumber: 1005

 

dn: cn=trabajadores,ou=groups,dc=ieslapaloma,dc=com

objectClass: posixGroup

objectClass: top

cn: trabajadores

gidNumber: 1001

memberUid: nestor

memberUid: daniel

memberUid: emmanuel

 

dn: cn=usuarios,ou=groups,dc=ieslapaloma,dc=com

objectClass: posixGroup

objectClass: top

cn: usuarios

gidNumber: 1002

memberUid: jessica

memberUid: maria

# ----------------------------------

Ahora habrá que cargar el servidor LDAP con el archivo creado:

sudo ldapadd -c -x -D cn=admin,dc=ieslapaloma,dc=com -W -f /tmp/ldap-myorganization.ldif

A partir de este momento ya tendremos un servidor LDAP apto para almacenar usuarios y grupos de cuentas Unix.

8.6.4 Explorador de directorios LDAP

Aunque LDAP permite trabajar con comandos y archivos .ldif, para acceder al directorio LDAP y poder crear y modificar elementos en dicho directorio, es más práctico utilizar un explorador de directorios LDAP (LDAP browser). Existen muchos exploradores LDAP tanto de pago como libres. Entre las aplicaciones libres destacamos gq, phpldapadmin (aplicación web) y JXplorer.

Para instalar gq, podemos utilizar apt-get install gq. Una vez instalada, para ejecutar gq tan solo debemos pulsar Alt + F2 y escribir "gq".

Para instalar phpldapadmin, al igual que otras aplicaciones web, deberemos descargarla desde http://phpldapadmin.sourceforge.net/ y descomprimirla dentro del DocumentRoot de Apache, es decir, dentro de la carpeta /var/www, por ejemplo en /var/www/phpldapadmin. Para ejecutarla, si la hemos descomprimido en la carpeta anterior, debemos ir a http://ip_del_servidor_web/phpldapadmin/ con el navegador y veremos la página principal de la aplicación.

Página principal de phpldapadmin

phpldapadmin

8.6.5 JXplorer

Por su calidad superior, utilizaremos JXplorer para administrar el directorio LDAP.

8.6.6 Instalación de JXplorer

Previo a instalar JXplorer, es necesario instalar la máquina virtual Java de Sun, para lo cual utilizaremos apt-get, pero antes debemos activar los repositorios -partner- de Ubuntu.

sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-plugin sun-java6-fonts

El comando anterior instalará java en la carpeta /usr/lib/jvm/java-6-sun/jre/bin/. Posteriormente tendremos que editar el archivo /root/.bashrc y añadir las variables que permitan al shell encontrar los binarios del JRE:

CLASSPATH=/usr/lib/jvm/java-6-sun/jre/bin/

JAVA_HOME=/usr/lib/jvm/java-6-sun/jre/bin/

PATH=/usr/lib/jvm/java-6-sun/jre/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin

Una vez instalado el Java y establecidas las variables CLASSPATH, JAVA_HOME y PATH en el archivo /root/.bashrc, debes cerrar el terminal y volver a abrirlo, para que cargue nuevamente las variables de entorno. Si ejecutas el comando set en el terminal, podrás comprobar que ha cargado las variables de entorno y podrás instalar JXplorer. JXplorer no está disponible en los repositorios de paquetes de Debian, pero se pueden descargarse. Debemos copiar el archivo en la carpeta /tmp de nuestro sistema y ejecutar:

Instalando como usuario, no como root:

sh /tmp/jxplorer3.2_linux.bin

Se iniciará un sencillo asistente de instalación que al finalizar habrá creado la carpeta JXplorer en nuestra carpeta home y el script de inicio jxplorer.sh dentro de ella, por lo tanto para ejecutarlo debemos escribir:

~/JXplorer/jxplorer.sh

Luego veremos la pantalla principal de JXplorer:

jxplorer

8.6.7 Conexión con el servidor LDAP

La conexión con el servidor LDAP podemos hacerla como usuario anónimo o como usuario administrador. Si conectamos de forma anónima solo podremos visualizar los elementos pero no podremos hacer cambios. Si conectamos como administrador, podremos crear, modificar y eliminar elementos de cualquier tipo.

Para conectar al servidor LDAP como administrador necesitamos la siguiente información:

  • Dirección IP del servidor LDAP
  • Protocolo del servidor (LDAP v3 en nuestro caso)
  • Base del directorio (dc=ieslapaloma,dc=com en nuestro caso)
  • Nombre de usuario administrador (cn=admin,dc=ieslapaloma,dc=com en nuestro caso)
  • Contraseña (ldapadmin en nuestro caso)

La base del directorio se suele denominar en inglés 'base DN' o 'Nombre Distinguido de la base del directorio'. Se corresponde con el parámetro 'suffix' del archivo de configuración del servidor LDAP /etc/ldap/slapd.conf.

El nombre del usuario con el que nos conectamos se suele denominar en inglés 'user DN' o también 'bind DN'. El nombre de usuario administrador por defecto suele ser admin y a menudo hay que proporcionar nombre y base del directorio: cn=admin,dc=ieslapaloma,dc=com

Al hacer clic en el botón 'conectar' (marcado con círculo rojo en la figura) nos aparecerá el diálogo de conexión para que introduzcamos los datos de la conexión. Para no tener que introducir dicha información cada vez que conectemos, podemos grabar los datos pulsando 'Save'.

conexion openldap

Si pulsamos OK, JXplorer conectará con el servidor LDAP y mostrará el directorio:

directorio openldap

Vemos que en nuestro directorio ya tiene creada la organización llamada 'ieslapaloma', el usuario administrador llamado 'admin' y dos unidades organizativas: groups y users en las cuales se encuentran los grupos y los usuarios anteriormente creados.

8.6.8 Creación de usuarios y grupos con JXplorer

Anteriormente hemos creado el grupo usuarios y el grupo trabajadores mediante el archivo ldap-myorganization.ldif. Ahora veremos cómo crear usuarios y grupos desde la herramienta JXplorer. Como ejemplo, crearemos un nuevo grupo y un nuevo usuario. Crearemos el siguiente grupo: jefesdpto (gid=1003). Además, crearemos un usuario nuevo: carlos (uid=1006, jefesdpto).

8.6.9 Creación de grupos

Para crear los grupos, haremos clic con el derecho en la unidad organizativa 'groups' y haremos clic en 'New'. Observamos en 'Selected Classes' (clases seleccionadas) que está seleccionada la clase 'posixGroup'. El nombre (RDN) será jefesdpto, por tanto debemos escribir 'cn=jefesdpto' (cn= Common Name - Nombre Común):

grupos jxplorer

Al pulsar OK nos apacererá la siguente figura, en la cual observamos los atributos clásicos de un grupo posix. Debemos rellenar al menos el campo gidNumber. También podemos introducir miembros al grupo. En el parámetro memberUid añadimos nestor. Luego, haciendo clic con el derecho en nestor > Add another value podemos añadir más miembros.

Atributos clásicos de un grupo posix

atributos clasicos

8.6.10 Creación de usuarios

Para crear los usuarios, haremos clic con el derecho en la unidad organizativa 'users' y haremos clic en 'New'. Observamos en 'Selected Classes' (clases seleccionadas) que están seleccionadas las clases 'inetOrgPerson', 'organizationalPerson', 'person' y 'posixAccount'. Si su nombre es Carlos, podemos escribir en la casilla RDN 'cn=Carlos'.

usuarios jxplorer

Al pulsar OK nos apacerá la siguiente figura, en la cual observamos los atributos de las tres tipologías de nuestro elemento: persona, usuario de internet y cuenta posix. Debemos rellenar al menos los campos gidNumber (grupo primario que será el 1003), homeDirectory, uid (identificador), uidNumber y sn (surname - apellidos). También podemos configurar la contraseña en el atributo userPassword escribiendo la nueva contraseña cifrada con MD5.

Atributos de las tres tipologías de nuestro elemento

tipologias

Lo mismo haremos con el resto hasta que tengamos creados los cinco usuarios. Al final nuestro servidor LDAP tendrá la siguiente información:

Información ofrecida por nuestro servidor LDAP

directorio

Ya tendríamos creada la estructura, los grupos y los usuarios que necesitamos para nuestro sistema.

8.7 Autentificación del sistema con OpenLDAP

Como ya hemos comentado anteriormente, una de las utilidades más importantes de un servidor LDAP es como servidor de autentificación. Autentificarse es necesario para entrar en un sistema linux. También para acceder a algunos servicios como un servidor FTP o a páginas privadas en un servidor web. Aquí veremos las modificaciones que hay que realizar en un sistema Linux para que autentifique a los usuarios en un servidor LDAP en lugar de utilizar los clásicos archivos /etc/passwd, /etc/group y /etc/shadow.

8.7.1 Paso 1: Instalación de ldap-auth-client

Para que el PC cliente se autentifique por LDAP, instalaremos el meta que instalará los paquetes y herramientas necesarias para configurar el cliente. También instalaremos el paquete nscd que es un caché de nombres y acelerará todas las operaciones de autentificación:

sudo apt-get install ldap-auth-client nscd

Acto seguido ejecutaremos auth-client-config que configurará el archivo /etc/nsswitch.conf para que utilice ldap:

sudo auth-client-config -t nss -p lac_ldap

8.7.2 Paso 2: Instalación de libpam-ldapd

Después instalaremos y configuraremos libpam-ldapd para que conecte con nuestro servidor LDAP cuando haya que realizar alguna operación de autentificación. La librería libpam-ldapd permite que las aplicaciones que utilizan PAM para autentificarse, puedan hacerlo mediante un servidor LDAP. Para que el sistema linux se autentifique mediante un servidor LDAP es necesario instalar esta librería ya que utiliza PAM. El archivo de configuración de ésta librería es /etc/nslcd.conf. pero no será necesario editarlo ya que al instalar el paquete, se iniciará el asistente de configuración.

sudo apt-get install libpam-ldapd

Después se iniciará el asistente de configuración de libpam-ldapd al que tendremos que proporcionar los datos básicos como quién es el servidor LDAP (nombre o IP):

URI del servidor LDAP

uri servidor ldap

Después debemos indicar cuál es la base de nuestro directorio LDAP (base DN):

Base DN del directorio LDAP

base dn servidor ldap

Y finalmante debemos indicar los servicios que se habilitarán para búsquedas por LDAP. En nuestro caso solamente seleccionaremos el servicio group:

Servicios a configurar por LDAP

servicios ldap

8.7.3 Paso 3: Actualización de PAM

Para que el sistema PAM se reconfigure para utilizar LDAP, es necesario ejecutar el comando pam-auth-update:

sudo apt-get install pam-auth-update

Aparecerá el asistente de configuración de PAM: pulsaremos Aceptar:

aceptar

Posteriormente debemos indicar los perfiles PAM a habilitar. Seleccionaremos todos:

Perfiles PAM a habilitar

perfiles pam

Acto seguido debemos reiniciar el servico caché de nombres:

sudo /etc/init.d/nscd restart

A partir de este momento ya podemos comenzar a utilizar la autentificación del sistema por LDAP.

Nota: Si quieremos autentificarnos en el sistema con un usuario del LDAP, debemos previamente crear la carpeta home de dicho usuario y cambiar el propietario y el grupo de dicha carpeta para que coincida con el usuario y el grupo del usuario configurado en el LDAP.

8.7.4 Probar la autentificación

Nuestro servidor LDAP ya debería autentificar correctamente . Podemos probar la autentificación de los servicios mediante el comando pamtest. Si deseamos probar que funciona el servicio passwd (cambiar contraseña) sobre un usuario del directorio LDAP (ejemplo jessica) , podemos ejecutar:

Probando el cambio de contraseña:

pamtest passwd jessica

Trying to authenticate for service .

Password: // Introducimos el password de jessica

Authentication successful. // La autentificación ha sido satisfactoria

También podemos utilizar el comando finger sobre usuarios que estén solamente en el directorio LDAP, por ejemplo daniel:

Probando finger

finger daniel

Login: daniel Name: Daniel Suarez

Directory: /home/www/trabajadores Shell: /bin/sh

Last login Tue Sep 27 18:02 (CEST) on pts/3 from 192.168.1.213

No mail.

No Plan.

Podemos por ejemplo, desde una consola de root, cambiar mediante el comando 'su' (su=Switch User - cambiar de usuario) a un usuario que esté en el directorio LDAP, para lo cuál no nos pedirá contraseña ya que root tiene permiso para cambiar a cualquier usuario. Si posteriormente cambiamos a otro usuario del directorio, ahora sí que nos pedirá contraseña. Deberemos introducir la contraseña que esté almacenada en el directorio LDAP para dicho usuario:

su daniel // Somos root y cambiamos a daniel

daniel@ubuntu: // No nos pide password

daniel@ubuntu:/$ su jessica // Somos daniel, y cambiamos a jessica

Password: // Nos pide password, le introducimos

jessica@ubuntu:/$ // Ha cambiado correctamente

8.8 Autentificación segura OpenSSL y OpenLDAP

Los permisos que los usuarios tienen sobre los sistemas se basan en la autentificación del usuario. Aunque ya se han desarrollado sofisticados métodos de autentificación como sistemas de tarjeta electrónica (DNI electrónico) o sistemas biológicos como la huella dactilar o el iris del ojo, la realidad es que requieren de elementos caros para su aplicación. En organizaciones y en pequeñas y medianas empresas, se sigue utilizando el mecanismo tradicional de autentificación del usuario mediante su nombre de usuario (login) y su contraseña (password).

Desde que el usuario introduce su contraseña hasta que ésta llega al servidor para comprobar la autentificación, el paquete de datos que contiene la contraseña viaja por los cables de red atravesando concentradores (hubs), conmutadores (switches) y enrutadores (routers) hasta llegar al servidor. Durante el trayecto, cualquier persona con los conocimientos necesarios podría quedarse con una copia del paquete de datos para, posteriormente analizarlo y tratar de descubrir el nombre y la contraseña del usuario sin que éste se percatase.

Con la finalidad de dificultar que alguien trate de descubrir contraseñas analizando los datos que las contienen, existe la posibilidad de cifrar los paquetes de datos en el PC antes de enviarlos por la red, de manera que lleguen al servidor cifrados. De esta forma, aunque un usuario malintencionado capture un paquete de datos con la información del usuario y la contraseña, será muy dificil, por no decir imposible, que sea capaz de descifrarlos ya que se utiliza cifrado asimétrico

El cifrado asimétrico permite la generación de una pareja de claves comunmente denominadas clave pública y clave privada en el servidor. La pareja de claves es tal que, todo lo cifrado con una, solo se puede descifrar con la otra.

El servidor tiene guardada en un lugar seguro la clave privada. Cuando un cliente intenta autentificarse, el servidor le trasfiere la clave pública para que cifre los datos con dicha clave antes de enviarlos. El cliente utiliza la clave pública del servidor para cifrar los datos, así al llegar el paquete al servidor, éste podrá descifrarlo porque dispone de la clave privada. Si un usuario malintencionado intercepta el paquete de datos cifrado con la clave pública, no podrá hacer nada porque no dispone de la clave privada. Si el usuario malintencionado intercepta el primer paquete que envía el servidor con la clave pública, no le servirá para nada ya que no le permitirá descifrar los datos emitidos por el PC que se va autentificar.

Fundamentos de la autentificación segura

fundamentos autentificacion

8.8.1 LDAP seguro - ldaps

Al igual que el servidor web apache utiliza el puerto 80 para transmitir información sin encifrar (protocolo http) y el puerto 443 para transmitir información cifrada (protocolo https), OpenLDAP también se puede configurar para que utilice las prestaciones de cifrado que ofrece OpenSSL.

Normalmente las consultas al servidor LDAP se realizan por el puerto 389 (protocolo ldap) pero dichas consultas se transmiten sin cifrar. Para realizar consultas seguras cifrando los datos con SSL, es necesasrio utilizar el puerto 636 (protocolo ldaps o protocolo ldap seguro). Para ello, el servidor deberá disponer de un certificado firmado por una entidad certificadora (CA) y habrá que configurar slapd para que utilice los certificados. Se deberán realizar los siguentes pasos:

  • Crear una nueva entidad certificadora
  • Crear una petición de firma de certificado del servidor
  • Firmar el certificado con la CA
  • Copiar los certificados a la carpeta deseada, renombrar y proteger
  • Configurar slapd para que utilice los certificados
  • Modificar script de inicio de slapd para que utilice protocolo seguro ldaps
  • Reiniciar slapd

Crearemos un script que realizará automáticamente todos los pasos. Guardaremos el script en /tmp/ldap-seguro.sh:

# ------- Script /tmp/ldap-seguro.sh -------

apt-get install gnutls-bin

sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem"

 

echo cn = IES La Paloma>/etc/ssl/ca.info

echo ca>>/etc/ssl/ca.info

echo cert_signing_key>>/etc/ssl/ca.info

 

certtool --generate-self-signed --load-privkey /etc/ssl/private/cakey.pem --template /etc/ssl/ca.info --outfile /etc/ssl/certs/cacert.pem sh -c "certtool --generate-privkey > /etc/ssl/private/ldap01_slapd_key.pem"

 

echo organization = IES La Paloma>/etc/ssl/ldap01.info

echo cn = ldap01.example.com>>/etc/ssl/ldap01.info

echo tls_www_server>>/etc/ssl/ldap01.info

echo encryption_key>>/etc/ssl/ldap01.info

echo signing_key>>/etc/ssl/ldap01.info

 

certtool --generate-certificate --load-privkey /etc/ssl/private/ldap01_slapd_key.pem --load-ca-certificate /etc/ssl/certs/cacert.pem --load-ca-privkey /etc/ssl/private/cakey.pem --template /etc/ssl/ldap01.info --outfile /etc/ssl/certs/ldap01_slapd_cert.pem

 

ldapmodify -Y EXTERNAL -H ldapi:/// << EOF

dn: cn=config

add: olcTLSCACertificateFile

olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem

-

add: olcTLSCertificateFile

olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem

-

add: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem

EOF

 

adduser openldap ssl-cert

chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem

chmod g+r /etc/ssl/private/ldap01_slapd_key.pem

 

echo SLAPD_SERVICES=\"ldap:/// ldapi:/// ldaps:///\" >> /etc/default/slapd

/etc/init.d/slapd restart

# ----------- FIN del Script -----------

Una vez guardado el script, solo queda ejecutarlo:

sudo sh /tmp/ldap-seguro.sh

Al finalizar el script se habrá reinciado el servidor slapd y admitirá conexiones seguras por el puerto 636.

8.8.2 Probando el acceso por ssl

Si nuestro servidor LDAP está funcionando en modo seguro, estará escuchando en el puerto 636 ya que es el puerto utilizado por el protocolo ldaps. Para probarlo, iniciamos JXplorer pero la conexión la realizamos a dicho puerto y el nivel de seguridad seleccionamos SSL + User + Password ya que la autentificación va a ser por usuario y contraseña pero utilizando SSL:

acceso ssl

Al intentar conectar, nos aparecerá la información del certificado. Podremos aceptar el certificado para esta sesión (This session only) o para siempre (Always):

informacion del certificado

Una vez que hemos conectado, podemos apreciar en la parte inferior que la conexión se ha realizado al puerto 636:

puerto 636

8.9 Acceso a carpetas privadas con autentificación por LDAP

Otra posibilidad muy interesante es que los trabajadores e incluso el sitio web de la Intranet de nuestra organización, puedan disponer de carpetas privadas accesibles mediante el navegador pero no por cualquier usuario; por ejemplo los trabajadores podrían disponer de una carpeta donde almacenar información confidencial accesible desde la web -notas, por ejemplo-. Así mismo puede ocurrir que queremos tener en el servidor web de nuestra intranet páginas a las que sólo puedan tener acceso de lectura los trabajadores de la organización. Vamos a ver cómo conseguir todo esto.

Lo primero que hemos de tener en cuenta es que para que podamos autenticar a los usuarios en apache mediante LDAP, hemos de habilitar un módulo especial en nuestro servidor web para que apache pueda validar el acceso a las carpetas deseadas a través de la base de usuarios del servidor LDAP. Dicho módulo se habilita ejecutando el siguiente comando:

sudo a2enmod authnz_ldap

El siguiente paso es crear una carpeta de nombre "privada" colgando de "/var/www", lugar donde ubicaremos las páginas privadas de nuestro servidor web. Posteriormente introducimos en /etc/apache2/sites-available/default textualmente las siguientes líneas, mediante las cuales logramos definir la carpeta "privada" como aquella a partir de la cual el contenido allí contenido será privado y sólo accesible por los usuarios especificados

Añadir en /etc/apache2/sites-available/default

<directory "="" var="" www="" webprivada="">

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

AuthType basic

AuthBasicProvider ldap

AuthName "Identificacion LDAP ieslapaloma.com"

AuthLDAPUrl ldap://127.0.0.1:389/dc=ieslapaloma,dc=com?uid

AuthLDAPBindDN "cn=admin,dc=ieslapaloma,dc=com"

AuthLDAPBindPassword ldapadmin

AuthLDAPGroupAttributeIsDN off

AuthLDAPGroupAttribute memberUid

require user nestor emmanuel carlos

</directory>

En el parámetro AuthLDAPUrl sustituiremos 127.0.0.1 por la dirección IP o el nombre del servidor LDAP si fuera otro servidor distinto al servidor apache y en el parámetro "AuthLDAPBindPassword" la cadena "ldapadmin" por la contraseña que hayamos asignado al usuario "administrador (admin)" del servidor LDAP.

En el parámetro AuthLDAPUrl vemos que al final termina con '?uid'. Significa que lo que debe de introducir el usuario es su uid (login del usuario). Podemos filtrar la entrada del usuario y poner condiciones si terminamos la URL con '?uid??(atributo=valor)'. De esta forma solamente serían válidos aquellos usuarios que tengan un atributo con un valor determinado, ejemplo '?uid??(gidNumber=1001)' solo admitiría usuarios cuyo grupo primario sea 1001.

El parámetro AuthLDAPGroupAttributeIsDN debe estar en off para que no utilice el cn (nombre común) del usuario sino el uid a la hora de comprobar la pertenencia a un grupo.

En el parámetro AuthLDAPGroupAttribute debemos indicar el campo que se analizará para comprobar la pertenencia a un grupo.

El parámetro 'require user' seguido de una lista de usuarios permitidos, ejemplo 'require user nestor emmanuel carlos' solo permite el acceso a esos usuarios. Para permitir a cualquier usuario que exista en el servidor LDAP, podemos usar 'requiere valid-user'.

Guardamos los cambios realizados y para completar el proceso reiniciaremos el servidor Apache.

sudo /etc/init.d/apache2 restart

Si ubicamos un fichero de nombre "prueba.html" en dicha carpeta ("/var/www/privada"), podremos acceder a ella mediante la URL "http://www.ieslapaloma.com/privada/prueba.html" (en nuestro caso), mostrándose la siguiente pantalla en la cual se nos pedirá autenticación, y en la cual serán válidas las credenciales de los usuarios permitidos.

Nota: Editar /etc/hosts y añadir la línea 127.0.0.1 www.ieslapaloma.com para que resuelva correctamente el nombre www.ieslapaloma.com (o el que hayamos utilizado).

Petición de autenticación

peticion autenticacion

Una vez validado adecuadamente algún usuario con permisos de acceso a los contenidos privados se mostrará la página solicitada.

Se muestra la página solicitada

pagina web privada

Además podemos crear una carpeta privada para cada trabajador, de modo que el contenido allí existente sólo fuera accesible por él mismo previa autenticación; para ello crearemos una carpeta de nombre 'privada' colgando de la carpeta personal de cada trabajador (por ejemplo en el caso del trabajador Nestor, en '/home/nestor/public-html/'). Además de la creación de dicha carpeta 'privada' en la ruta correspondiente, hemos de editar el archivo /etc/apache2/sites-available/default e incluir la siguiente entrada en el apartado correspondiente a los directorios:

// Carpeta privada de nestor. Añadir en /etc/apache2/sites-available/default

Alias /nestor-p/ "/home/nestor/public_html/privada/"

<directory "="" home="" nestor="" public_html="" privada="">

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

AuthType basic

AuthBasicProvider ldap

AuthName "Identificacion LDAP ieslapaloma.com"

AuthLDAPUrl ldap://127.0.0.1:389/dc=ieslapaloma,dc=com?uid

AuthLDAPBindDN "cn=admin,dc=ieslapaloma,dc=com"

AuthLDAPBindPassword ldapadmin

require user nestor

Igual que antes, sustituiremos las cadenas '127.0.0.1' y "ldapadmin" por sus valores correctos. Además hemos de introducir esta entrada para cada uno de los trabajadores de la organización, sustituyendo en las rutas de las dos primeras líneas el valor "nestor" por el del trabajador que deseamos que tenga el acceso seguro, así como dicho valor también en la penúltima línea.

Tras almacenar los cambios en el fichero de configuración y reiniciar el Servicio Apache, para acceder a un fichero de nombre "prueba.html" ubicado en la carpeta privada del trabajador Nestor teclearemos la URL: 'http://www.ieslapaloma.com/nestor-p/prueba.html'

Es posible hacer, y de hecho es recomendable, que las carpetas privadas sean además seguras, es decir, utilicen un canal SSL, con lo cual el acceso a las carpetas seguras sería 'https' en el puerto '443', el resto de las rutas de las URL de acceso se mantendrían estables. Para lograrlo hemos de introducir en cada una de las entradas '' la instrucción 'SSLRequireSSL' ".

 

Visto 2436 veces Modificado por última vez en Viernes, 07 September 2018 09:42
Alejandro Carreño

Desarrollador, Programador, Web Master y Community Manager de CDR Consultores

Deja un comentario

Asegúrese de introducir toda la información requerida, indicada por un asterisco (*). No se permite código HTML.

Tweets

RT @cdrconsultores: #ProfitPlusNómina2KDoce es una solución "altamente" flexible que le ofrece soporte a sus principales procesos en el áre…
#ProfitPlusNómina2KDoce es una solución "altamente" flexible que le ofrece soporte a sus principales procesos en el… https://t.co/jYGfMU4dTK

Productos

Servicios

servicios off
website off
desarrollo off
formacion off
negocios off

Facebook

end-logo

 

Nestor M. Carreño T. - Todos los Derechos Reservados
Rescindir de Dios y de los valores morales, lleva no sólo al empobrecimiento espiritual, sino también al empobrecimiento material
Gracias a Usted, Muchas Gracias por Consultarnos, Dios le Bendiga!

Diseño y Desarrollo Nestor M. Carreño T. - CDR Consultores, C.A.