Documentos de Académico
Documentos de Profesional
Documentos de Cultura
TFG Final
TFG Final
Ingeniería de Computadores
Autor
2019
Grado en Ingeniería Informática
Ingeniería de Computadores
Autor
Directores
José Miguel Alonso y José Miguel Blanco Arbe
Resumen
Debido a este motivo, se ha realizado una comparación tecnológica entre dos herramientas
de software libre cuyo propósito es el control de acceso sobre una red y se ha seleccionado
la más adecuada para la situación del BCBL que ha resultado ser PacketFence.
Teniendo en cuenta que para realizar un despliegue de este tipo en una red en producción
24 horas al día hay que encontrar el momento oportuno, se ha realizado la planificación
para un despliegue global en la red que será implementado cuando el departamento de IT
del BCBL lo encuentre oportuno.
I
Índice general
Resumen I
Índice de figuras IX
1. Introducción 3
2. Antecedentes 7
2.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.5. SCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.6. NDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
III
ÍNDICE GENERAL
3. Objetivos y alcance 13
3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1. PacketFence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
IV
6. Despliegue en subred en producción 53
6.5. Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
V
ÍNDICE GENERAL
9. Conclusiones 111
9.1. Lecciones aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.2. Posibles mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Anexos
VI
B. Instalación y configuración inicial de PacketFence en CentOS 7 131
VII
Índice de figuras
5.10. Detalles sobre el estado de la interfaz que intenta acceder a la red (pre-auth) 46
IX
ÍNDICE DE FIGURAS
5.15. Datos sobre los equipos que han intentado acceder a la red (pestaña Nodes) 50
6.15. Perfil de red por modificado con éxito mediante el script if_conf_default.sh. 70
X
6.17. Perfiles existentes en el equipo para la interfaz Ethernet . . . . . . . . . . 72
7.2. Vista de las configuraciones creadas mediante GPO desde los equipos
Windows 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
XI
ÍNDICE DE FIGURAS
XII
Índice de tablas
XIII
Glosario
1
2 ÍNDICE DE TABLAS
Introducción
Por ejemplo, puede afirmarse que hoy en día todo el mundo lleva un pequeño ordenador
portátil en el bolsillo, y que no todas las personas son conscientes de ello, si no que para
muchas de estas personas ese ordenador no es más que un teléfono.
Debido a esto, muchas empresas recurren a instalar Controles de Acceso o NAC (Network
Access Control) en sus redes privadas. Esto no significa que los departamentos de seguri-
dad informática de las empresas sospechen de que los mismos empleados o usuarios de la
red vayan a realizar acciones delictivas o peligrosas a propósito (aunque también podría
darse el caso), significa que el departamento de seguridad informática es consciente sobre
la inconsciencia general y social respecto a este tipo de seguridad.
Este TFG ha sido realizado en el BCBL (Basque center on Cognition, Brain and Language),
un centro donde se realizan numerosas investigaciones por un grupo de unos 100 investi-
gadores en total. Estos investigadores utilizan equipos propios del BCBL conectados de
forma cableada a la LAN (Local Area Network).
3
4 Introducción
Estos equipos están configurados mediante políticas GPO (Group Policy Object) por lo
que los usuarios finales no tienen permisos para realizar ciertas acciones, ya sean cam-
biar configuraciones internas del equipo o instalar software que no esté permitido por los
administradores.
El problema comienza cuando cualquiera de estos usuarios puede traer un equipo personal
(por ejemplo un ordenador portátil) y conectarlo a la LAN utilizando el mismo cable que,
en teoría, únicamente debería utilizarse para conectar los equipos propios del BCBL.
Una vez que un equipo personal ha conseguido acceso a la LAN de la empresa podrían
darse multitud de situaciones en las que tanto los servidores como los datos internos del
BCBL pudieran quedar comprometidos. Teniendo en cuenta que muchas investigaciones
se realizan con sujetos reales, hay una gran cantidad de datos personales sujetos al nivel
más estricto de la LOPD que, bajo ningún concepto, pueden salir del centro.
Para evitar este tipo de situaciones se ha implantado un control de acceso sobre la LAN del
centro. Este control de acceso está basado en certificados PKI (Public Key Infraestructure),
lo que evitará que ningún equipo que no disponga de un certificado emitido por la CA
(Certification Authority) local del BCBL pueda tener acceso a la red. En otras palabras,
la autenticación se basará en las máquinas y no en los usuarios finales de las mismas, ya
que si se impone únicamente una autenticación basada en usuario/contraseña, la situación
mencionada anteriormente podría darse igualmente.
Objetivos y alcance: En este capítulo se exponen cuales han sido los objetivos
principales del proyecto y cómo han sido realizados.
Anexos: Documentos donde se explican diferentes acciones que han tenido que
realizarse para poder llevar a cabo el proyecto, pero no se ha visto la necesidad
incluir en la documentación.
Antecedentes
Cabe mencionar que en este capítulo se hará una breve introducción a los diferentes con-
ceptos que serán necesarios conocer mínimamente para poder tener una mayor compren-
sión sobre el proyecto. Se incluirán tanto herramientas como protocolos y estándares que,
o bien son necesarios incluir en la red para la realización del proyecto, o simplemente
son elementos que ya forman parte de la misma y por tanto he considerado oportuna su
comprensión para poder seguir adelante.
7
8 Antecedentes
2.1. Motivación
Este centro utiliza una red local moderadamente grande, con más de un centenar de dispo-
sitivos conectados a ella. Esta red tiene como objetivo, entre otras cosas, la comunicación
entre los diferentes departamentos del centro, así como el acceso al clúster de cómputo
por parte de los investigadores residentes y el acceso a Internet y a los servicios del BCBL.
Teniendo en cuenta que es una red privada en la que se manejan una gran cantidad de
datos, incluidos datos personales, tanto de los trabajadores del centro como de los sujetos
de investigación que participan en las diversas investigaciones que se realizan en él, es más
que razonable pensar que ésta pueda ser víctima de la intrusión de usuarios no deseados.
Este control de acceso se basará en evitar que ninguna máquina pueda conectarse a la red
sin tener permiso previo para ello. Para ello se realizará una autenticación 802.1X basada
certificados emitidos por la propia CA del centro. Los equipos que no tengan soporte
para instalar o configurar un cliente para realizar la autenticación mediante el protocolo
802.1X (Impresoras, faxes, escáneres, etc.) serán autenticados mediante sus direcciones
físicas o MACs.
2.2 Introducción a tecnologías y herramientas utilizadas 9
Esta sección constituye una introducción a dichos elementos y no una guía técnica de-
tallada de los mismos, aunque los más importantes se explicarán con más detalle en el
capítulo 4 “Estudio de tecnologías y herramientas”.
2.2.1. RADIUS
IEEE 802.1X es un estándar IEEE para el control de acceso a la red basado en puertos
(Port-based Network Access Control o PNAC). Forma parte del grupo de protocolos de
red IEEE 802.1y proporciona un mecanismo de autenticación para los dispositivos que
desean conectarse a una LAN o WLAN.
1 https://es.wikipedia.org/wiki/RADIUS
2 https://es.wikipedia.org/wiki/IEEE_802.1X
10 Antecedentes
Active Directory (AD) o Directorio Activo son los términos que utiliza Microsoft para
referirse a su implementación de servicio de directorio en una red distribuida de compu-
tadores. Utiliza distintos protocolos, principalmente LDAP, DNS, DHCP y Kerberos.
De forma sencilla se puede decir que es un servicio establecido en uno o varios servido-
res en donde se crean objetos tales como usuarios, equipos o grupos, con el objetivo de
administrar los inicios de sesión en los equipos conectados a la red, así como también la
administración de políticas en toda la red.
La tecnología PKI permite a los usuarios autenticarse frente a otros usuarios y usar la
información de los certificados de identidad (por ejemplo, las claves públicas de otros
usuarios) para cifrar y descifrar mensajes, firmar digitalmente información, garantizar el
no repudio de un envío, y otros usos.
Todo certificado válido ha de ser emitido por una autoridad de certificación reconocida,
que garantiza la validez de la asociación entre el poseedor del certificado y el certificado
en sí. 4
3 https://es.wikipedia.org/wiki/Active_Directory
4 https://es.wikipedia.org/wiki/Infraestructura_de_clave_p%C3%BAblica
2.2 Introducción a tecnologías y herramientas utilizadas 11
2.2.5. SCEP
El protocolo está diseñado para que la emisión de certificados digitales sea lo más es-
calable posible. La idea es que cualquier usuario estándar de la red pueda solicitar su
certificado digital de forma electrónica y lo más sencilla posible. Por lo general, estos
procesos han requerido una intensa aportación de los administradores de red, por lo que
no han sido adecuados para despliegues a gran escala. 5
2.2.6. NDES
5 https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_Protocol
6 https://social.technet.microsoft.com/wiki/contents/articles/9063.
active-directory-certificate-services-ad-cs-network-device-enrollment-service-ndes.
aspx
3. CAPÍTULO
Objetivos y alcance
En este capítulo se explicarán cuales son los objetivos más importantes de este proyecto,
así como la manera de la que se han conseguido cumplir, mencionando también ciertos
inconvenientes o trabas que se han encontrado por el camino y la manera en la que han
sido solventados.
3.1. Objetivos
En esta sección se expondrán los objetivos principales de este TFG, los cuales fueron
establecidos por el BCBL al comienzo del proyecto. Estos objetivos han sufrido varias
modificaciones durante el transcurso y desarrollo del proyecto, por lo que esta sección
recogerá únicamente los objetivos que han resultado ser definitivos.
La idea del BCBL es utilizar algún software gratuito y de código libre para realizar el
control de acceso a la red. Para ello se han propuesto dos herramientas por el administra-
dor de redes de la empresa: PacketFence y openNAC. La selección de la herramienta no
es algo arbitrario por lo que se ha requerido una comparativa de ambas herramientas para
seleccionar la más adecuada.
13
14 Objetivos y alcance
El plan principal del BCBL con este proyecto consiste en implementar un NAC en la red
de producción de la empresa. Para ello se requiere preparar un servidor específico situado
en esa red en producción donde se instalará el software seleccionado en la Comparativa
Tecnológica, desde donde se realizará el control de acceso a la red.
El objetivo principal del BCBL con este proyecto consiste en realizar una autenticación de
los equipos que se conecten a la red. Para ello disponen de un servidor Windows Server
2008 R2 donde tienen instalados los servicios de Directorio Activo (donde se crean y
almacenan cuentas de usuario, máquinas, servicios, etc.) y de Autoridad Certificadora
(donde se crean y almacenan certificados para las diferentes máquinas, usuarios, servicios
etc.).
Utilizando estos servicios se desea realizar una autenticación basada en los certificados
que han sido previamente creados por la Autoridad Certificadora y que deberán de estar
instalados en los equipos del BCBL. De esta manera se evita que cualquier usuario pueda
utilizar el cable ethernet conectado a un equipo corporativo para conectarlo a un equipo
personal y tener acceso a la red.
Teniendo en cuenta el tipo de autenticación sobre la que quieren basar el control de acceso,
será necesario un despliegue automático de los certificados para evitar tener que hacerlo
manualmente.
3.2 Alcance 15
3.2. Alcance
En esta sección se explicará cómo se han logrado completar los objetivos del punto an-
terior durante el desarrollo del proyecto. Para ello se tomará como referencia la EDT
mostrada en la siguiente página.
Puede observarse que la EDT está descompuesta en tres ramas principales, dos de las
cuales se refieren a la gestión del proyecto y a la parte académica del mismo. Estas dos
ramas no se comentarán en esta sección, sino que se centrará en la parte del desarrollo del
proyecto bajo la rama principal llamada Servicio.
Esta rama es la que recoge el desarrollo del proyecto en su totalidad y ha sido dividida
en 4 subramas nombradas “Estudio de tecnologías y herramientas”, “Implementación en
entorno virtual controlado”, “Despliegue en subred real controlada” y “Planificación
del despliegue global en la red”.
Además de esto, para la realización del proyecto ha sido obligatorio tener que realizar un
estudio previo de las tecnologías que se han utilizado en el mismo. Estas tecnologías se
refieren a diferentes protocolos, estándares y servicios que se han sido necesarios para el
desarrollo del proyecto, tanto de forma activa como de forma pasiva.
Una vez conforme con el manejo y comprensión de PacketFence, se decidió dar paso a la
configuración para la autenticación basada en certificados, método elegido por el BCBL
para la implementación final.
Para ello es requisito fundamental que cada equipo disponga de un certificado válido1 ,
y para ello es necesario realizar un despliegue de los certificados. Este despliegue se ha
tenido que realizar únicamente para equipos que no dispongan de un Sistema Operati-
vo Windows instalado, ya que al momento de comenzar con el proyecto, el Directorio
Activo ya desplegaba dichos certificados a las máquinas incluidas en el dominio con el
mencionado Sistema Operativo.
El despliegue automático de los certificados para equipos CentOS fue mucho más costosa
y laboriosa de lo esperado, ya que tuvieron que estudiarse nuevas tecnologías y herra-
mientas además de instalar un nuevo servidor Windows Server 2008, dado que la versión
del servidor en funcionamiento en la red de producción no era compatible con uno de los
protocolos necesarios para el despliegue.
Puede encontrarse un documento más extenso sobre la instalación del Windows Server así
como de su configuración para el despliegue de certificados mediante el protocolo SCEP
en el Anexo C.
Habiendo desplegado los certificados necesarios a todas las máquinas de prueba se proce-
dieron a realizar autenticaciones basadas en certificados para estos equipos en la maqueta
antes de pasarla a producción. Al comprobar que PacketFence se comportaba correcta-
mente, se preparó un nuevo servidor ubicado en una red de producción para realizar una
instalación/implementación desde cero.
Una vez que PacketFence estaba instalado y configurado se procedió a desplegar el con-
trol de acceso sobre la red del departamento de IT, a la cual hay conectados cinco equipos
mediante dos switches. El despliegue fue un éxito y la red del departamento de IT fue
reforzada con seguridad basada en el protocolo 802.1X con autenticación mediante certi-
ficados emitidos por la CA local del BCBL.
1 Refiriéndose como válidos únicamente a los certificados emitidos por la CA local del BCBL.
3.2 Alcance 19
Teniendo en cuenta que para realizar un despliegue de este tipo en una red en produc-
ción 24 horas al día hay que encontrar el momento oportuno, en el BCBL aún no tenían
decidido cuando iba a realizarse dicho despliegue.
Además de esto, se realizó una planificación para el despliegue global junto al adminis-
trador de redes del BCBL. Esta planificación puede encontrarse en el capítulo 7 “Planifi-
cación del despliegue global en la red”.
4. CAPÍTULO
En este capítulo se explicarán con más detalle las tecnologías y herramientas que han sido
necesarias utilizar para el desarrollo del proyecto.
4.1. Tecnologías
4.1.1. RADIUS
Antes de entrar en más detalle sobre el protocolo, es conveniente mencionar y conocer los
diferentes elementos que toman parte en él:
Solicitante: Elemento hardware desde el que el usuario intenta acceder a la red. (Ejemplo:
un PC de escritorio)
21
22 Estudio de tecnologías y herramientas
Funcionamiento
1- El solicitante realiza una petición de acceso a la red al NAS con el cual establece una
comunicación punto a punto a nivel de enlace (PPP), enviando sus credenciales de usuario
(o máquina).
2- El NAS actuará como cliente del Servidor RADIUS, al que reenviará los datos recibidos
por el Solicitante mediante el protocolo RADIUS.
4- Si el servidor RADIUS autoriza el acceso a la red (o a una parte concreta de ella) al so-
licitante, responderá con un mensaje Access Accept, que contiene una serie de parámetros
que caracterizan su conexión, como pueden ser la dirección IP o el ancho de banda.
5- El NAS responderá ante el solicitante dependiendo del mensaje que haya recibido del
Servidor RADIUS, permitiendo o no el acceso a la red al mismo.
1 https://www.incibe-cert.es/blog/protocolos-aaa-radius
4.1 Tecnologías 23
4.1.2. 802.1X
Solicitante: Es el dispositivo cliente (por ejemplo un ordenador portátil) que quiere acce-
der a la red. Este término puede referirse igualmente al software que está ejecutando el
dispositivo y el encargado de enviar las credenciales al Autenticador.
Este estándar utiliza los protocolos RADIUS y EAPoL para el flujo de mensajes entre los
diferentes elementos del sistema.
2 Campo en la cabecera de la trama ethernet cuyo valor representa el protocolo en el que están encapsu-
Funcionamiento
Una vez el Autenticador recibe las credenciales las reenvía al Servidor de Autenticación
para que decida qué tipo de acceso tiene permitido el Solicitante. Si el Servidor de Auten-
ticación determina que las credenciales son correctas, informará de ello al Autenticador,
quién permitirá el acceso del Solicitante a la red (o subred) a la que el Solicitante esté
autorizado a conectarse.
3 https://www.youtube.com/watch?v=3obzgqslnL8
4.2 Herramientas 25
4.2. Herramientas
4.2.1. PacketFence
En pocas palabras, podría decirse que PacketFence es un software de código libre dise-
ñado para realizar controles de acceso en redes en producción. Cabe mencionar que para
este proyecto se barajaba la posibilidad de utilizar openNAC, una herramienta de carac-
terísticas similares utilizada para el mismo fin, y que puede encontrarse una comparativa
entre ambas en el Anexo A.
Esta herramienta ha sido desarrollada por Inverse en el año 2009 y desde entonces no han
dejado de ampliar y mejorar el software hasta convertirlo en una herramienta muy potente
que permite centralizar y monitorizar todos los accesos a la red en un solo servidor.
Para realizar una implementación basada en la asignación de VLANs, el único cambio que
tendremos que realizar sobre nuestra red, sera únicamente la de crear dos nuevas VLANs:
Registration (VLAN que se asignará a los dispositivos mientras realizan la autenticación
para acceder a la red) e Isolation (VLAN que se asignará a los equipos que no cumplan
con ciertos requisitos y no cumplan la política ce acceso establecida).
PacketFence incorporará el servicio de DHCP dentro de estas dos VLANs, mientras que
el servicio DHCP en las VLAN en producción de la red seguirá siendo el que se utilizaba
hasta ese momento.
En conjunto con la asignación de VLANs pueden establecerse diferentes reglas, por ejem-
plo basadas en diferentes atributos de las cuentas de usuario almacenadas en el Directorio
Activo, que asignarán un Role a los usuarios que se accedan a la red, pudiendo estable-
cer una política de asignación de VLANs basada en estos Roles, lo que otorga un amplio
abanico de posibilidades para el administrador de redes.
4.3 Estudio de la red local del BCBL 27
Este centro cuenta con una red local o LAN de tamaño medio. Esta red, entre otras cosas,
comunica los diferentes departamentos del centro y ofrece diversos servicios.
Planta 0: Aquí se encuentran tanto el clúster del Data Center como las instala-
ciones de los laboratorios donde se realizan diversos estudios, tales como estudios
conductuales, Eyetracking (Registro de movimientos oculares), estudio de bebés,
magnetoencefalografía, escáneres de resonancia magnética, etc.
Planta 2: La segunda planta se trata de la planta más grande del dentro. Aquí es
donde están situados los puestos de trabajo de todos los investigadores del centro
(la mayoría de los cuales lanzan procesos a ejecutar al Data Center), además del
Departamento de Administración.
El BCBL está distribuido en tres plantas pero parte de su LAN está situada en el edificio
de IZFE, ubicado también en el parque tecnológico de Miramón. El Switch Router mo-
delo HP Procurve 5406zl con el nombre AXON01 es el core de la red. Estos switches se
conocen como Core Switches (switches troncales). Para evitar cortes de conexión en caso
de AXON01 sufra algún problema, hay otro switch del mismo modelo llamado AXON02
conectado en el mismo punto para crear redundancia y evitar que toda la red quede in-
comunicada. Estos switches estan intercomunicados mediante un trunk de 2x10Gb en
BaseT y tienen conexiones hacia la salida a Internet, a otro CPD que se encuentra en el
dificio IZFE y a redes dedicadas a los servicios del BCBL (webservers, bases de datos,
zona DMZ, etc.).
Al ser AXON01 y AXON02 Core Switches, están conectados a todo resto de componentes
que forman la LAN. Para una mejor comprensión de la estructura física de la red, utilizaré
las agrupaciones que pueden observarse en la Figura 4.4.
Floor 0: En esta planta hay 3 switches para dar soporte a todos los equipos de la-
boratorio. Dos de ellos (AXON03 y AXON06) son del modelo HP ProCurve 2810.
El switch restante (AXON21) es del modelo HP ProCurve 2910. Este switch incor-
pora la característica conocida como PoE (Power over Ethernet o alimentación a
través de ethernet), la cual ha permitido conectar los 4 APs Wi-Fi de las plantas 0
y 1 sin necesidad de conectarlos a la corriente, ya que será el mismo switch el que
alimente el hardware mediante el cable de conexión ethernet.
Las conexiones desde los Core Switches hasta los switches de esta planta se realizan
mediante dos trunk de 2x1Gb BaseT, uno por cada Switch Core.
IZFE: Tal y como se ha comentado en la página anterior, parte de la LAN del BCBL
está ubicada en un edificio situado cerca del centro. La parte de la LAN de situada
en el edificio IZFE se compone de 4 elementos, dos routers (AXON19 y AXON20)
HP Aruba 3810 16 y dos switches (AXON07 y AXON08) HP Aruba 2930 que dan
soporte a los servidores que el BCBL aloja en este edificio.
Las conexiones entre los Core Switches y los routers del edificio de IZFE, tanto
la interconexión entre estos routers, como la conexión con los switches del mismo
edificio son mediante enlaces de 10Gb de fibra.
30
La idea es crear una pequeña red virtual utilizando esta herramienta. Se creará una máqui-
na virtual donde se instalará la herramienta seleccionada, y se creará también un vSwitch
donde se definirán las diferentes VLANs que serán necesarias para el correcto funcio-
namiento de la herramienta y poder simular un entorno ”real“ aunque sea en pequeña
escala.
Una vez conseguido el objetivo de esta fase, el cual únicamente consistirá en la familia-
rización con la herramienta y sobre todo con el abanico de configuraciones que ofrece,
y la implementación de una medida de seguridad basada en puertos mediante el estándar
802.1X. El acceso a la red se realizará mediante una autenticación de usuario y contra-
seña utilizando credenciales de usuario de BCBL. Aunque el producto final no vaya a
consistir en una autenticación de usuario, se ha decidido hacerlo de esta manera para la
familiarización con la herramienta, ya que se trata de una configuración más sencilla para
la autenticación.
31
32 Implementación en entorno virtual controlado
Como puede observarse en la figura superior (Figura 5.1), se ha creado una máquina vir-
tual con el nombre Tfg01. Esta máquina está conectada a tres diferentes VLANs mediante
tres interfaces de red. Esto se debe a que una de las ideas principales del NAC se basa en
la asociación de VLANs a los equipos que tengan acceso a la red, es decir, cada máqui-
na será dirigida a una VLAN dependiendo del rol de la misma, o dicho de otra manera,
dependiendo del departamento al que pertenezca.
Este documento no repara en la instalación del software, pero puede encontrarse la guía
de instalación y configuración inicial de PacketFence en una máquina CentOS 7 puede
encontrarse en el Anexo B.
5.1 Configuración de PacketFence para la autenticación de usuarios 33
Para conectar PacketFence con el Directorio Activo, lo primero que tendremos que hacer
será añadir el host donde está instalado el software al dominio del BCBL. Para ello te-
nemos que acceder a la sección Configuration –>Policies and Acces Control –>Domains
–>Active Directory Domains y hacer click sobre el botón “ADD DOMAIN”. Aparecerá
una ventana con un formulario donde tendremos que ingresar los datos acerca del domi-
nio. Estos son los datos que se han ingresado en el formulario:
Workgroup: BCBL
OU: Computers
Además de estos datos son necesarias las credenciales de un administrador del dominio
para poder ingresar en él, y para ello se han utilizado mis credenciales personales del
BCBL. Una vez ingresados todos los datos correctamente, tenemos que hacer click sobre
el botón “SAVE AND JOIN” y obtendremos un mensaje de confirmación.
34 Implementación en entorno virtual controlado
Una vez el host ya está en el dominio, tenemos que hacer click sobre la pestaña que dice
“REALMS”, y una vez ahí, hacer click sobre “DEFAULT” y “LOCAL” y asociar a estos
el dominio que acabamos de crear.
PacketFence dispone de una característica que se basa en el Rol del usuario autenticado,
al cual se le podrá asignar una VLAN específica. La creación de los diferentes Roles se
realiza en Configuration –>Policies and Acces Control –>Roles. Haciendo click sobre
el botón “ADD ROLE” aparecerá una pequeña ventana donde tendremos que definir un
nombre, una descripción y establecer un número máximo de nodos que podrán registrarse
con el Rol en cuestión asignado.
En este punto se han definido dos Roles: Users y IT. Ambos Roles se han definido sin
número máximo de nodos, ya que estamos en un entorno de pruebas y será irrelevante en
esta fase del proyecto.
En este punto podremos añadir el Directorio Activo para poder utilizarlo como fuente de
autenticación. Para ello tenemos que navegar hasta Configuration –>Policies and Acces
Control –>Authentication Sources y hacer click sobre el botón ADD SOURCE –>Internal
–>AD.
En esta ventana se configuran las reglas que van a utilizarse para la autenticación. Los
datos ingresados han sido los siguientes:
Name: ACC
Host: acc.bcbl.local:389
Scope: Subtree
Password: ***********
5.1 Configuración de PacketFence para la autenticación de usuarios 35
Authentication Rules:
1. IT_Staff
Name: IT_Staff
Description: Authentication for BCBL IT Staff
Matches: All
Conditions:
a) department equals IT
Actions
a) Role = IT
b) Access duration = 12 hours
2. BCBL_Users
Name: BCBL_Users
Description: BCBL User account authentication
Matches: All
Conditions:
a) distinguishedName ends DC=bcbl,DC=local
Actions
a) Role = Users
b) Access duration = 12 hours
36 Implementación en entorno virtual controlado
Administration Rules:
1. BCBL_Admins
Name: PacketFence_Admins
Description: BCBLian PacketFence Admins
Matches: All
Conditions:
a) cn equals jcaballero
Actions
a) Access level = ALL
Cabe mencionar que en el momento de la autenticación del usuario, éste será contrastado
con las reglas en orden ascendente. Siguiendo el ejemplo anterior primero se comprobará
si el usuario que está siendo autenticado pertenece al departamento de IT, en cuyo caso
se le asignaría el Role IT, y en caso de no hacerlo, se comprobará si el usuario pertenece
al dominio del BCBL, en cuyo caso se le asignará el Role User. Si el usuario ha cumplido
alguna de las reglas denominadas Authentication Rules, el usuario será contrastado con
las reglas incluidas en Administration Rules para saber si es un usuario corriente o tiene
derechos de administrador en PacketFence.
Antes de hacer click sobre el botón “SAVE” y guardar la configuración, PacketFence tiene
que comprobar que la información añadida sobre el dominio y la dirección del Directorio
Activo (entre otras cosas) son correctas. Para ello, tendremos que hacer click sobre el
botón “TEST” que aparece tras el recuadro de Password.
5.1 Configuración de PacketFence para la autenticación de usuarios 37
Los datos para poder establecer unas reglas coherentes han sido recogidos directamente de
las cuentas existentes en el Directorio Activo del BCBL. Estos son algunos de los atributos
que pueden verse sobre mi cuenta personal jcaballero del BCBL en el Directorio Activo:
Para asegurar la correcta adición del Directorio Activo a PacketFence y la correcta lec-
tura de los atributos de las cuentas, se procederá a comprobar que estas cuentas pueden
ser autenticadas correctamente. Para ello PacketFence dispone de un comando para la
comprobación de cuentas frente a diferentes fuentes de autenticación. Primero comproba-
remos la autenticación de un usuario no perteneciente al departamento de IT. El uso del
comando se realiza de la siguiente manera:
cd /usr/local/pf/bin/
./pftest authentication [username] [password] [authentication source]
En el listado del hardware soportado por PacketFence no aparece el modelo del switch que
se utilizará en el BCBL para la autenticación. El switch que se utilizará es el modelo HP
ProCurve 2810-48g. Aunque este switch no aparece en esta lista, buscando información
en diversos foros de PacketFence se ha encontrado una entrada de un usuario que dice
haberlo configurado como un HP ProCurve 2600 con muy buenos resultados, por lo que
se ha decidido probar esta solución.
PacketFence ofrece una guía para configurar diferentes modelos de switches, en la que
está incluida la configuración para los switches HP ProCurve 2600 Series, por lo que se
utilizará dicha guía como referencia para configurar el switch HP ProCurve 2810-48g,
buscando similaridades entre los comandos que aparecen en la guía de PacketFence y los
disponibles en nuestro switch. La configuración que se ha realizado en el switch es la
siguiente:
40 Implementación en entorno virtual controlado
Configurar autenticación:
Notas:
Las keys utilizadas durante la configuración del switch aparecerán como “xxxxxxxxx”
para mantener la privacidad del BCBL.
Un requisito imprescindible para que PacketFence sepa como manejar una conexión en-
trante ya sea cableada o mediante WiFi, es el de crear un Perfil de Conexión (Connection
Profile). En este caso, procederemos a crear un nuevo Connection Profile para utilizar la
fuente de autenticación basada en el Directorio Activo creada anteriormente, y hacer que
PacketFence registre de modo automático cualquier dispositivo que se autentique correc-
tamente mediante el protocolo 802.1X.
Para ello tendremos que navegar a Configuration –>Policies and Access Control –>Connection
Profiles y hacer click sobre Add Profile, donde añadiremos la siguiente información:
El resto de configuraciones se han dejado con las opciones que PacketFence trae por
defecto, ya que no se ha visto necesario cambiar ninguna de ellas.
42 Implementación en entorno virtual controlado
En la pestaña Definition:
• IP Address/MAC: 192.168.221.23
• Type: HP ProCurve 2600 Series
• Description: axon23
• Mode: Production
En la pestaña Roles
En la pestaña RADIUS
En la pestaña SNMP
Notas:
La VLAN -1 hace referencia a una VLAN inexistente, por lo que el usuario no será asig-
nado a ninguna VLAN quedando excluido de la red.
La configuración en el cliente varía dependiendo del Sistema Operativo que tenga ins-
talado. Ya que se trata de una implementación de pruebas, se considerará válido si se
consiguen los resultados esperados haciendo las pruebas pertinentes en un único Sistema
Operativo, que en este caso será Windows 7 ya que es el Sistema Operativo más utilizado
por los usuarios en el BCBL.
En esta ventana tendremos que asegurarnos de que “Validate server certificate” está
activado, y de que la opción “Select Authentication Method: Secured password (EAP-
MSCHAP v2)” está seleccionada para después hacer click sobre el botón Configure y
desmarcar la casilla “Automatically use my Windows logon name and password (and do-
main if any)”.
Como último paso tendremos que asegurarnos de que dentro de la ventana de configu-
ración que aparece tras pulsar el botón Additional Settings... está seleccionada la opción
“Specify authentication mode” y en la lista desplegable está seleccionada la opción “User
authentication”.
5.3 Testeo de la autenticación de usuarios 45
Como primera prueba se va a intentar acceder a la red utilizando un usuario del departa-
mento de IT (más concretamente mi usuario personal). Para ello conectamos vía ethernet
la interfaz configurada para la autenticación en el switch (interfaz 1) a la interfaz confi-
gurada para conexión LAN en el equipo Windows. En pocos instantes deberá de aparecer
un mensaje como el de la siguiente imagen:
Figura 5.8: Mensaje sobre la necesidad de información adicional para autenticación en la red
Al hacer click sobre dicho mensaje, aparecerá una ventana emergente donde hay que
introducir unas credenciales válidas para el dominio.
Si antes de enviar las credenciales hacemos click derecho sobre la interfaz y después sobre
Status –>Details.... Podrás observarse lo siguiente:
Figura 5.10: Detalles sobre el estado de la interfaz que intenta acceder a la red (pre-auth)
Una vez introducidas unas credenciales válidas, puede comprobarse el cambio en la ven-
tana de detalles sobre el estado de la interfaz:
A primera vista puede parecer que no ha funcionado correctamente, ya que falta infor-
mación acerca de los servidores DNS y DHCP, sobre la VLAN a la que se encuentra
conectado el equipo en este momento, etc., pero la verdad es que ha funcionado correc-
tamente. El problema reside en que la VLAN que se ha asignado al equipo es la VLAN
70, tal y como se había configurado en el último paso de la configuración del switch, y
esta VLAN es no es más que una VLAN de prueba donde no hay servidores DHCP ni
DNS, únicamente unas pocas máquinas virtuales con IPs estáticas. Para comprobar que
todo lo comentado es cierto, se realizará una conexión ssh al switch axon23 y se ejecutará
el comando sh vlan port 1, con lo que se obtendrá el siguiente resultado por consola:
Para cambiar la VLAN asignada al Role de IT, es necesario acceder a la interfaz web de
PacketFence y navegar hasta Configuration –>Policies and Access Control –>Switches.
Una vez aquí, hacer click sobre el identificador del switch que había sido configurado
en pasos anteriores y en la pestaña “Roles” cambiar el valor de IT por el valor 45. Una
vez terminada la configuración hay que hacer click en el botón “SAVE” para salvar los
cambios realizados.
Una vez cambiada la configuración de PacketFence hay que volver a conectar el ordenador
a la red mediante un cable ethernet y volver a introducir unas credenciales válidas. Una
vez accedido a la red se pueden volver a observar los detalles del estado de la interfaz de
red para ver las diferencias con el caso anterior:
Figura 5.14: Detalles sobre los mensajes RADIUS intercambiados en la autentición de un usuario
Además de la información acerca de la conexión RADIUS también hay una pestaña lla-
mada Switch Information, donde aparece información acerca del switch que realizó la
autenticación para el nodo sobre el que estamos mirando. Dentro de esta pestaña puede
encontrarse la dirección IP del switch, el puerto/interfaz sobre el que se realizó la auten-
ticación, el tipo de conexión que se utilizó, dirección MAC del switch, etc.
50 Implementación en entorno virtual controlado
Figura 5.15: Datos sobre los equipos que han intentado acceder a la red (pestaña Nodes)
Si se hace click sobre la dirección MAC de uno de los nodos, aparecerá una ventana con
todos los datos guardados en el sistema sobre ese nodo.
Puede observarse como se le ha asignado información acerca del usuario al nodo a la hora
de realizar el registro. En este caso, al haber introducido credenciales de un usuario del
departamento de IT se le ha asignado el Role de IT durante 12 horas (el tiempo de acceso
establecido a este Role en pasos anteriores).
También se puede apreciar como la IP asignada por PacketFence no ha sido utilizada por
el nodo en un tiempo y aparece marcada de color rojo. Esto se debe a que una vez el nodo
se ha registrado, durante el periodo de duración del registro (12 horas en este caso) la
dirección IP asignada al nodo por PacketFence no será necesaria, ya que al tener acceso a
la red, la dirección IP asignada a este nodo será una dirección IP asignada por el servidor
DHCP en producción en la red del BCBL.
5.3 Testeo de la autenticación de usuarios 51
Dentro de esta ventana hay diferentes pestañas que pueden visitarse, pero la que más
información puede proporcionar en base a la autenticación es la pestaña Location, donde
aparece información acerca de los cambios de VLAN y Role del nodo durante el proceso
de autenticación.
Figura 5.18: Fragmento del log packetfence.log tras una autenticación exitosa
6. CAPÍTULO
Esta autenticación se realizará en base a los certificados que estén instalados dichas má-
quinas. Estos certificados tendrán que haber sido emitidos por la Autoridad Certificadora
(CA) propia del BCBL. Esta CA está instalada en el mismo servidor Windows Server
2008 que el Directorio Activo que se ha utilizado para la autenticación de usuarios en la
implementación anterior. Esta CA emite certificados tanto de máquinas como de usuarios,
además de certificados para ciertos servicios.
La VLAN en producción que se utilizará para testear el NAC será la VLAN 45, que
corresponde a la VLAN del departamento de IT del BCBL.
53
54 Despliegue en subred en producción
En esta sección se mostrarán los cambios que se han realizado en la configuración dentro
de PacketFence para realizar una autenticación basada en certificados. Han sido necesa-
rias pocas modificaciones en la configuración de PacketFence, ya que va a utilizarse el
mismo dominio, mismo punto de acceso (switch), etc. Una de las modificaciones que se
han requerido realizar ha sido la de añadir una nueva fuente de autenticación y añadir
ciertas reglas en la misma. Para ello hay que acceder a Configuration –>Policies and Ac-
cess Control –>Authentication Sources, y una vez en esta ventana hacer click sobre ADD
SOURCE –>Internal –>EAPTLS. Para esta fuente de autenticación se han añadido los
siguientes datos:
Name: Cert_Authentication
Y al igual que en configuraciones anteriores, hay que elegir ciertas reglas para la autenticar
al usuario.
Authentication Rules:
1. BCBL_workstations
Name: BCBL_workstations
Description: Authentication based on certificates issued by bcbl-PFC-CA
Conditions:
a) TLS-Client-Cert-Issuer contains bcbl-PFC-CA
Actions:
a) Role = IT
b) Access duration = 12 hours
La regla que se ha establecido permitirá el acceso a todos los equipos que dispongan de
un certificado que haya sido emitido por la CA del BCBL: bcbl-PFC-CA.
Además de esto, hay que asignar esta nueva fuente de autenticación al Connection Pro-
file que ya estaba creado (llamado 802.1x). Para ello hay que navegar a Configuration
–>Policies and Access Control –>Connection Profiles y hacer click sobre el nombre del
perfil para cambiar el valor del parámetro “Source” por “Cert_Authentication”.
6.1 Configuración de PacketFence 55
Una vez realizados los cambios explicados en las páginas anteriores, tendremos que crear
un certificado para PacketFence y descargar el certificado de la CA en la máquina donde
se encuentra instalado (TFG01 en este caso). Estos certificados pueden descargarse direc-
tamente desde la interfaz web de la CA https://acc.bcbl.local/certsrv/mscep,
donde también realizaremos la petición del certificado para PacketFence que tendrá que
ser del tipo Web-Server.
Una vez hecho esto, tendremos que configurar cierto fichero de configuración de Pac-
ketFence para especificarle las rutas donde hemos alojado los certificados. Este fiche-
ro se encuentra en /usr/local/pf/conf/radiusd/eap.conf. En este fichero tendre-
mos que buscar el bloque de configuración referido a las conexiones TLS con el nombre
tls-config tls-common. Una vez localizado dicho bloque de configuración tendremos
que especificar as rutas para los siguientes ficheros: certificado de PacketFence, clave
privada de PacketFence y el certificado de la CA.
Para realizar una autenticación basada en certificados, uno de los requisitos más importan-
tes será el correcto despliegue de los certificados en cuestión. Teniendo en cuenta que en
la empresa hay usuarios trabajando con diferentes Sistemas Operativos, habrá que con-
figurar correctamente el despliegue de los certificados para cada uno de estos Sistemas
Operativos.
Para el despliegue de los certificados en este Sistema Operativo, será suficiente con in-
gresar la máquina dentro del dominio. Esto se debe a que el controlador de dominio es
la máquina acc.bcbl.local, que es la misma máquina donde está instalado el Directorio
Activo y estaba configurada de antemano para desplegar el certificado Computers a todas
las máquinas Windows pertenecientes al dominio bcbl.local.
Una vez realizados estos cambios se tendrmos que reiniciar el equipo y éste ya pertenecerá
al dominio.
Para realizar el despliegue de los certificados en este Sistema Operativo, será necesario el
uso del protocolo SCEP (Simple Certificate Enrollment Protocol).
Figura 6.2: La opción NDES no aparece en Windows Active Directory 2008 R2 Standard
58 Despliegue en subred en producción
1. Los equipos con Sistema Operativo CentOS 7 tendrán que descargar e instalar los
certificados de manera manual
La opción escogida ha sido la número 2 a petición del BCBL. Puede encontrarse una guía
de configuración y testeo de un Windows Server 2008 R2 Enterprise para su utilización
como servidor de autoenrollment en el Anexo C.
Una vez configurado el servidor Windows Server 2008 R2 Enterprise, se realizará una
prueba con la máquina glia21 con Sistema Operativo CentOS 7. La prueba consistirá en
intentar conseguir instalar un certificado a nombre de la máquina mediante la línea de
comandos, utilizando sscep. Para ello hay que acceder a la terminal de la máquina en
modo administrador y realizamos las siguientes acciones:
Como primer paso crearemos el fichero de petición de certificado y para ello puede utili-
zarse tanto openssl como el script /etc/bin/mkrequest. Para esta primera prueba se va
a utilizar openssl:
openssl req -new -newkey rsa:2048 -nodes -keyout local.key -out local.csr
-subj ’/C=ES/ST=Guipuzcoa/L=Donostia/O=BCBL/OU=IT/CN=glia21.bcbl.local’
Figura 6.3: Creación de la petición para un certificado y clave privada para la máquina glia21
Una vez creadas la petición de certificado para la máquina y su clave privada asociada,
podría hacerse la petición y descarga del certificado de dos maneras, una manual y la otra
utilizando SCEP. En esta prueba se utilizará SCEP para la petición del certificado, aunque
en las siguientes líneas se explicará de forma breve como podría hacerse de forma manual.
Una vez se haya accedido al servidor vía web, hay que hacer click sobre el enlace “Re-
quest a certificate” seguido de “Submit a certificate request by using a base-64-encoded
CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS
#7 file.”. En esta ventana tendría que aparecer lo que se ve en la imagen C.12. En este
formulario hay que copiar el contenido del fichero local.csr y tras hacer click sobre el
botón “Submit” la CA generará el certificado y podrá se descargado haciendo click sobre
el enlace “Download Certificate”.
El método mediante SCEP es mucho más sencillo y rápido, ya que consiste en ejecutar dos
comandos desde la consola de la máquina. El primero de ellos descargará en la máquina
local el certificado de la CA además de dos certificados adicionales que son necesarios
para enrolarse mediante SCEP. Estos certificados adicionales se conocen como “CEP
encryption certificate” y “Enrollment agent certificate”. Para ello hay que ejecutar el
siguiente comando sscep:
Figura 6.5: Parte del contenido del certificado CA-0 en texto plano
60 Despliegue en subred en producción
Una vez generados los certificados pertinentes, el último paso consiste en el “enrollmen”
en sí. Para ello se requieren los archivos “CA-0”, “CA-1”, “local.key” y “local.csr”.
El anterior comando generará el archivo “local.crt”, que será el certificado para la máquina
glia21.
Para no tener que ejecutar estos comandos a mano por cada máquina CentOS que se
añada al dominio, se ha utilizado un script encontrado en la dirección https://blogs.
technet.microsoft.com/jeffbutte/2016/12/16/236/. Se han definido las varia-
bles en base a la configuración actual además de corregir algún pequeño error que impe-
día la correcta ejecución del script. Puede encontrarse el código completo del script en el
Anexo E.
6.2 Despliegue automático de los certificados 61
Una vez comprobado el correcto funcionamiento del script será añadido para que sea
ejecutado durante el arranque de las máquinas Linux, ya que este script también renueva
el certificado en caso de que ésta haya caducado.
Cabe mencionar que este script (llamado autoenrollment.sh) almacena los certificados de
la máquina local en el directorio /etc/pki/tls/private/, además de crear una copia
del certificado (*.crt) en el directorio /etc/pki/tls/certs, y los certificados prove-
nientes de la CA en /etc/pki/ca-trust/source/anchors/.
Esta sección únicamente recogerá los cambios que hay que realizar sobre una interfaz
previamente configurada para la autenticación de usuarios basada en el protocolo 802.1X,
tal y como se muestra en la sección 5.2 Configuración del cliente para autenticación de
usuarios.
Una vez la interfaz está configurada para la autenticación mediante el protocolo 802.1X,
los cambios a realizar serán mínimos. Primero tendremos que abrir la ventana de Propie-
dades de la interfaz LAN que vamos a utilizar para acceder a la red y navegar a la pestaña
de Authentication, ya que todos los cambios de configuración se harán en ella. En esta
ventana sustituiremos “Microsoft: Protected EAP (PEAP)” por “Microsoft: Smart Card
or other certificate”, y después haremos click sobre el botón Settings para acceder a una
nueva ventana de configuración.
En esta ventana nos aseguraremos de que están marcadas las casillas “Use a certificate on
this computer” y “Use simple certificate selection (Recommended)”, y de que la casilla
“Validate server certificate” está marcada. Una vez realizados estos cambios clicaremos
sobre el botón OK para que se guarden los cambios realizados y se cierre la ventana.
Para finalizar con la configuración de la interfaz será necesario hacer click sobre Additio-
nal settings... y cambiar la selección de la lista desplegable por “Computer authentica-
tion”.
6.3 Configuración del cliente para la autenticación basada en certificados 63
Esta acción puede realizarse mediante la interfaz gráfica o modificando ficheros de confi-
guración. Se ha decidido hacerlo mediante la interfaz gráfica para facilitar el trabajo. Aún
así, la idea es crear un script para no tener que configurar manualmente todos los equipos
CentOS, por lo que este apartado también se trabajará más adelante.
Para configurar una interfaz web mediante la interfaz gráfica en CentOS tendremos que
pulsar el botón de inicio, escribir settings y pulsar Enter. Una vez se abra la ventana de
configuración, clicaremos sobre Network en la columna de la izquierda para acceder al
menú de configuración de interfaces.
Figura 6.9: Ventana de creación y modificación de perfiles sobre una interfaz de red.
64 Despliegue en subred en producción
802.1x Security: ON
Authentication: TLS
Identity: glia21.bcbl.local
CA certificate: tfg03CA.crt-2
Figura 6.10: Mensaje de error al seleccionar una clave privada sin contraseña.
6.3 Configuración del cliente para la autenticación basada en certificados 65
Una vez que el Perfil para la interfaz de red ha sido configurado aparecerá en la lista como
opción seleccionable. La primera vez que se haga click sobre él aparecerá una pequeña
ventana emergente donde hay que introducir la contraseña con la que se cifró la clave
privada. Si la contraseña introducida es correcta, el Perfil podrá empezar a utilizarse como
método de conexión.
66 Despliegue en subred en producción
TYPE=Ethernet
KEY_MGMT=IEEE8021X
IEEE_8021X_EAP_METHODS=TLS
IEEE_8021X_IDENTITY=glia21.bcbl.local
IEEE_8021X_PRIVATE_KEY=/etc/pki/tls/private/glia21.encrypted.key
IEEE_8021X_CLIENT_CERT=/etc/pki/tls/certs/glia21.crt
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME="Wired 802.1x"
UUID=5aca2f64-6369-4ffd-9c14-89f05a6096c6
ONBOOT=yes
Tras analizar el fichero de configuración creado por el sistema se puede intuir como podría
crearse un script que realice estas configuraciones.
6.3 Configuración del cliente para la autenticación basada en certificados 67
#!/bin/bash
PASS=$(cat /etc/pki/tls/private/.dirinfo/.p)
echo "Creating new 802.1x TLS based Network Profile..."
nmcli connection add type ethernet con-name Wired_802 ifname "*" \
autoconnect true 802-1x.eap tls 802-1x.identity $(hostname) \
802-1x.client-cert /etc/pki/tls/certs/$(hostname).crt \
802-1x.private-key /etc/pki/tls/private/$(hostname).encrypted.key \
802-1x.private-key-password $PASS
if [ $? -eq 0 ]
then
echo "Network Profile created successfully!"
nmcli connection show
else
echo "An error ocurred while trying to create the Network Profile"
fi
Este script funciona correctamente y crea un nuevo Perfil llamado Wired_802 sobre que
puede ser utilizado sobre cualquier interfaz de red. Cabe mencionar que la contraseña
para desencriptar la clave está almacenada en el directorio /etc/pki/tls/private/
.dirinfo/.p.
Figura 6.12: Perfil de red creado con éxito utilizando el script if_conf_new.sh.
68 Despliegue en subred en producción
La siguiente imagen muestra como, tras reiniciar el equipo, aparece un bug visual en el
menú rápido de conexiones:
Se puede observar como además del icono de conexión y el estado de la misma (Wired
Connected en la imagen 6.13), ni siquiera aparece el Perfil “Wired_802” en la lista de
Perfiles del menú de acceso rápido de red, aunque es el que se está utilizando para la
conexión y funciona correctamente con una IP de la VLAN 45 asignada.
6.3 Configuración del cliente para la autenticación basada en certificados 69
Por un lado para evitar confusiones entre los usuarios finales de los equipos, y por otro
para no tener más Perfiles de red de los necesarios (uno) configurados en el equipo, se ha
decidido modificar el script para que no añada un nuevo Perfil de red a la interfaz, sino
para que modifique el existente y lo configure de forma que realice la conexión a la red
mediante el protocolo 802.1X basado en certificados.
Para ello, el primer paso será conseguir el nombre del Perfil por defecto configurado en
el equipo, ya que estos nombres pueden variar dependiendo del equipo (ens, eth, p8p1,
Wired Connection, etc.). Para ello se ha utilizado el siguiente comando:
Sin entrar en más detalle sobre este comando, el resultado será un string con el nombre
del Perfil de conexión que se esté utilizando (en los equipos recién formateados solamente
habrá uno). Gracias a esto se ha podido modificar el script de la siguiente manera para
configurar el Perfil una vez encontrado su nombre:
if [ $? -eq 0 ]
then
echo "Network Profile $IF modified successfully!"
nmcli -p connection show
else
echo "An error ocurred while trying to modify the Network Profile"
fi
70 Despliegue en subred en producción
Figura 6.15: Perfil de red por modificado con éxito mediante el script if_conf_default.sh.
Además del script anterior, también ha tenido que modificarse el script autoenrollment.sh,
ya que la clave privada generada por el mismo no es encriptada mediante una contraseña
tal y como lo requiere la configuración de interfaces de CentOS para la autenticación
mediante el protocolo 802.1X. Las líneas añadidas al script son las siguientes:
El funcionamiento del script será probado más adelante en la sección Testeo de autenti-
cación basada en certificados (6.4) para comprobar que tanto las creación de las claves
como la encriptación de la clave privada se realiza correctamente.
6.3 Configuración del cliente para la autenticación basada en certificados 71
Tal y como puede observarse en la figura superior, la interfaz de Ethernet tiene un perfil
para autenticación 802.1X configurado llamado SSID eduroam. Este perfil fue creado
por eduroam para el BCBL, ya que además de la red WiFi para invitados del BCBL,
también disponen de una red eduroam.
Se ha procedido a crear un nuevo perfil de conexión sobre la red Ethernet haciendo click
sobre el botón Advanced... de esa misma ventana. Una vez aquí, se ha navegado hasta
la pestaña 802.1x, donde se encuentran listados todos los perfiles de configuración sobre
la interfaz. En este caso, únicamente aparece el perfil SSID eduroam ya que es el único
existente hasta el momento.
72 Despliegue en subred en producción
Lo que se buscaba en esta ventana era una forma de crear un nuevo perfil (en versio-
nes anteriores del Sistema Operativo aparecía un símbolo “+” para ello), pero no se ha
encontrado ninguna forma de hacerlo desde esta ventana.
Como segunda opción se ha accedido al apartado Profiles del menú de configuraciones del
sistema, donde aparecen listados todos los perfiles creados para este equipo (únicamente
eduroam por ahora), y en este caso sí que aparece el símbolo “+” en la parte inferior
izquierda para añadir un nuevo perfil.
Una vez hecho click sobre el botón “+” se esperaba que se abriese una ventana de con-
figuración del perfil (al igual que en el caso de la creación de un perfil de configuración
para una interfaz en CentOS 7), pero en lugar de eso, se ha abierto una ventana donde hay
que seleccionar un archivo de perfil para poder asignarlo a la interfaz de red.
Se ha comentado todo lo anterior a los superiores del BCBL, quienes han optado por no
instalar el servidor ya que hay muy pocos equipos MAC, y además no siempre están en
funcionamiento, por lo que se ha decidido ofrecer únicamente conexión mediante WiFi a
estos equipos.
Aún así, a petición del BCBL, se procederá a explicar cómo se realizaría la configuración
del perfil para la autenticación 802.1X basada en certificados para una interfaz de red
cableada. Este documento puede encontrarse en el Anexo D.
74 Despliegue en subred en producción
En esta sección se comprobarán tanto el correcto despliegue de los certificados para todos
los Sistemas Operativos configurados, como la autenticación de acceso a la red basada en
los mismos.
El testeo para este tipo de autenticación es más simple que el anterior, ya que es totalmente
transparente para el usuario y el acceso a la red debería de estar garantizado con solamente
conectar el cable a la interfaz de red si el equipo dispone de un certificado válido.
Una vez aquí haremos click sobre File –>Add/Remove Snap-in... para abrir una nueva
ventana donde seleccionaremos “Certificates” del cuadro de la izquierda y pulsaremos
el botón “Add >”. En la ventana emergente que aparecerá tendremos que seleccionar
“Computer account” y hacer click sobre Next. En el siguiente paso seleccionaremos “Lo-
cal computer: (the computer this console is running on)” y clicaremos sobre Finish para
cerrar la ventana actual y en el botón OK para terminar la importación del Snap-in.
Para comprobar que no hay ningún certificado instalado en la máquina, tenemos que re-
correr el árbol de directorios de la parte izquierda hasta Certificates (Local Computer)
–>Personal –>Certificates y una vez aquí podremos comprobar cómo no aparece lista-
do ningún certificado, indicando que no existe ningún certificado asociado a la máquina
instalado en ella.
Figura 6.21: Mensaje de alerta al intentar acceder a la red sin un certificado válido.
De la misma manera que para el caso anterior, lo primero que realizaremos será compro-
bar que la descarga automática del certificado de máquina se realiza correctamente. Para
ello utilizaremos el script autoenrollment.sh generado anteriormente.
Tal y como puede apreciarse en la figura superior, la ejecución del script ha descargado
correctamente el certificado y su clave privada en el directorio etc/pki/tls/private,
además de que la clave privada ha sido encriptada correctamente mediante las modifi-
caciones realizadas al script en la sección Configuración del cliente para autenticación
basada en certificados (6.3). También se crea una copia del certificado (glia21.crt) al di-
rectorio /etc/pki/tls/certs, ya que es, por defecto, el directorio donde se guardan los
certificados públicos.
6.4 Testeo de autenticación basado en certificados 77
Teniendo en cuenta que en este punto todos los equipos que forman parte en la autentica-
ción deberían de estar correctamente configurados, la conexión debería de ser inmediata
una vez se haya seleccionado el perfil creado anteriormente (Wired_802.1x) estando el
cable ethernet de la interfaz conectado al switch de acceso que comunica con PacketFen-
ce.
Primero intentaremos conectarnos a la red mediante el perfil por defecto p8p1 para las
interfaces de red cableadas y demostrar que no se tiene acceso a la red. Al conectar el
cable de red no parece haber ningún problema, ya que el símbolo de conexión que aparece
en la parte superior derecha de la pantalla es el mismo que cuando tenemos acceso a la
red.
Esto se debe a que en realidad hemos obtenido acceso a la red, concretamente PacketFence
ha otorgado una dirección IP válida al ordenador, pero esta IP corresponde a la VLAN 75
Registration desde la que no tendremos acceso hacia el exterior, ni tampoco hacia ninguna
otra sección privada de la red.
Para comprobar que no se tiene acceso a la red se ha intentado acceder a una página web
cualquiera mediante un navegador web y el resultado ha sido el siguiente:
Figura 6.25: Mensaje de error en el navegador al intentar acceder a cualquier sitio web.
78 Despliegue en subred en producción
Puede observarse que los datos del emisor del certificado no coinciden con los datos de
Google. Esto se debe a que el certificado pertenece al servidor de PacketFence, con los
datos de Inverse de Montreal, la empresa que lo ha diseñado.
Éste es el motivo de que aparezca este mensaje de error tan extraño; PacketFence envía su
propio certificado al navegador del equipo que intenta acceder a la red, lo que da lugar a
confusiones, ya que el mensaje de error que aparece da a pensar que realmente hay acceso
a la red y que ha habido contacto con el otro extremo, aunque no haya sido así.
Figura 6.28: El certificado descargado del navegador y el del servidor PacketFence son iguales.
6.4 Testeo de autenticación basado en certificados 79
Figura 6.30: Acceso con éxito a la VLAN 45 mediante autenticación basada en certificados.
También podremos comprobar como la VLAN asignada al puerto 1 del punto de acceso
es la VLAN 45. Para ello nos conectaremos al switch mediante ssh y ejecutaremos el
comando sh vlan port 1:
6.5. Despliegue
Para ello, a petición del BCBL se ha creado una nueva máquina virtual (llamada Charlie)
en el hipervisor en la que se realizará una instalación y configuración de PacketFence
desde cero. La instalación ha sido exactamente igual que en la máquina anterior, aunque la
versión de PacketFence haya sido actualizada. Esta guía de instalación puede encontrarse
en el capítulo B incluido en los Anexos.
Configuración de PacketFence.
En las siguientes páginas se procederá a explicar la realización de cada una de estas tareas.
6.5 Despliegue 81
1 - Creación de Roles:
En la pestaña Definition:
• IP Address/MAC: 192.168.221.X 1
• Type: HP ProCurve 2600 Series 2
• Description: AXONXX 3
• Mode: Production
En la pestaña Roles
En la pestaña RADIUS
En la pestaña SNMP
Las configuración en ambos switches ha sido idéntica dado que se tratan de switches de
la misma familia. Las configuraciones realizadas han sido las siguientes 4 :
Una vez ejecutado el comando aaa port-access authenticator active, los puertos
([PORT-LIST]) configurados mediante los comandos anteriores pasarán a estar securiza-
dos mediante el protocolo 802.1X, por lo que se requerirá un método de autenticación
para acceder a la red a través de estos puertos.
En esta sección se explicará como se procederá a configurar los switches necesarios para
el despliegue global del control de acceso a la red. Se han identificado los switches que
serán necesarios configurar para realizar dicho despliegue en masa:
1. AXON03 –>192.168.221.3
2. AXON04 –>192.168.221.4
3. AXON05 –>192.168.221.5
4. AXON06 –>192.168.221.6
5. AXON09 –>192.168.221.9
7. AXON21 –>192.168.221.21
8. AXON22 –>192.168.221.22
85
86 Planificación del despliegue global en la red
Estos 8 switches están distribuídos por todo el BCBL y ofrecen conexión a diferentes
departamentos, por lo que podrían agruparse de la siguiente manera:
Antes de realizar la configuración definitiva de los switches, pueden ejecutarse los si-
guientes comandos genéricos a todo ellos, ya que estas configuraciones no serán efectivas
hasta ejecutar el comando aaa port-access authenticator active. Los comandos
a ejecutar en todos los switches identificados en la lista anterior son los siguientes:
Estos comandos definen cuáles serán los servidores RADIUS y SNMP para el switch en
cuestión además de definir dos comunidades, una llamada public que tendrá permisos de
lectura SNMP y otra llamada BCBL_Ch@rl13 que también tendrá permisos de escritura
(estas comunidades fueron definidas también en el switch AXON18 (6.5.2) y configura-
dos en PacketFence (6.5.1) para el despliegue en el departamento de IT). Los servidores
RADIUS y SNMP serán el mismo para todos los switches; Charlie (192.168.241.250), el
servidor donde está instalado PacketFence.
Una vez realizada esta configuración genérica podrán empezar a configurarse los switches
uno a uno, pero primero añadiremos estos switches a PacketFence.
7.2 Configuración de PacketFence 87
Lo primero será crear tres nuevos Roles: Users, Printers y Mac_OS_X. Más adelante se
explicará como se realizará la autenticación para los dispositivos Printers y MAC_OS_X.
En la pestaña Definition:
• IP Address/MAC: 192.168.221.X 1
• Type: HP ProCurve 2600 Series
• Description: AXONXX 2
• Mode: Production
En la pestaña Roles
En la pestaña RADIUS
En la pestaña SNMP
Aunque los switches vayan a configurarse en un orden específico para mantener un con-
trol, la configuración a realizar en cada uno de ellos es prácticamente idéntica a la del
resto, ya que la única diferencia relevante entre ellos será la lista de puertos a configurar
en cada uno.
Estos comandos configuran los puertos [PORT-LIST] para realizar autenticaciones me-
diante el protocolo EAP-RADIUS, especificando un número máximo de clientes permiti-
dos en cada uno de ellos. Además de esto también se le especifica que debe de controlar
los paquetes de entrada en los puertos no securizados y que debe de enviar una SNMP-trap
en caso de no autorizar el acceso a algún dispositivo que intenta conectarse.
7.3 Configuración individual de los switches 89
Estos comandos configuran los puertos sobre los que se realizará una autenticación basada
en direcciones MAC. Estos switches permiten que un mismo puerto pueda realizar tanto
autenticaciones 802.1X como autenticaciones basadas en direcciones MAC. El switch
intentará primero autenticar el dispositivo mediante el protocolo 802.1X, pero en caso de
que el dispositivo cliente no disponga del “802.1X supplicant”3 , el switch realizará una
autenticación basada en la dirección MAC mediante una conexión NoEAP.
Por último, una vez el switch esté completamente configurado (podremos asegurarnos
de su correcta configuración ejecutando el comando sh run) tendremos que ejecutar el
siguiente comando:
Por último y una vez comprobado que el sistema funciona correctamente podremos eje-
cutar el comando write memory en el switch para guardar la configuración actual y que
no se pierda la siguiente vez que se apague.
3 Software necesario en el cliente para poder realizar una autenticación basada en puertos
90 Planificación del despliegue global en la red
Los equipos sobre los que habrá que realizar configuraciones son únicamente los equi-
pos con Sistemas Operativos Windows 7 y CentOS (más adelante se explicará como se
realizará la autorización para equipos con Sistema Operativo Mac OS X).
Los equipos que están conectados a la red se configurarán mediante GPO (Group Policy
Object) desde el Directorio Activo, lo que es muy útil para centralizar todas las configu-
raciones de los equipos desde un único punto y aplicar dichas configuraciones en masa.
Estas configuraciones se aplicarán a todos los equipos con Sistema Operativo Windows 7
que formen parte del dominio del BCBL. Las configuraciones son exactamente iguales a
las que se describieron en el capítulo 6.3.1, por lo que únicamente serán listadas:
En la pestaña Authentication
Las siguientes imágenes muestran la configuración realizada para todos los equipos con
Sistema Operativo Windows 7 del dominio y cómo se ven reflejadas dichas configuracio-
nes en los equipos.
Figura 7.1: Configuraciones establecidas en el Directorio Activo para los equipos Windows 7.
Figura 7.2: Vista de las configuraciones creadas mediante GPO desde los equipos Windows 7.
92 Planificación del despliegue global en la red
Para los equipos con Sistema Operativo CentOS 7 instalado se ha utilizado Puppet para
realizar configuraciones en masa. Ya que se habían creado scripts para la configuración
de los equipos con estos Sistemas Operativos, únicamente se ha ordenado la ejecución
de dichos scripts en caso de cumplir ciertas condiciones. El código para configuración
mediante Puppet es el siguiente:
class portsecurity {
file { ’/etc/pki/tls/private/.dirinfo’:
ensure => directory,
owner => root,
group => root,
mode => 700,
}
file { "/etc/pki/tls/private/.dirinfo/.p":
owner => root,
group => root,
mode => 400,
source => "puppet://medulla01.bcbl.local/extra_files/scripts/p.txt"
}
file { "/root/scripts/autoenrollment.sh":
owner => root,
group => root,
mode => 700,
source => "puppet://medulla01.bcbl.local/extra_files/scripts/autoenrollment.sh"
}
file { "/root/scripts/if_conf_default.sh":
owner => root,
group => root,
mode => 700,
source => "puppet://medulla01.bcbl.local/extra_files/scripts/\
7.4 Configuración de los equipos conectados a la red 93
if_conf_default.sh"
}
exec { ’autoenrollment’:
command => "sh /root/scripts/autoenrollment.sh",
provider => shell,
user => root,
onlyif => ’test ‘ls /etc/pki/tls/private/$HOSTNAME.* | wc -l‘ -ne 4’,
path => ’/usr/sbin:/usr/bin:/sbin:/bin’,
require => [ File [’/root/scripts/autoenrollment.sh’], File \
[’/etc/pki/tls/private/.dirinfo/.p’] ],
}
exec { ’ifcfg_802.1x’:
command => "sh /root/scripts/if_conf_default.sh",
provider => shell,
user => root,
onlyif => ’test ‘cat /etc/sysconfig/network-scripts/ifcfg-* | \
grep "IEEE_8021X" | wc -l‘ -eq 0’,
path => ’/usr/sbin:/usr/bin:/sbin:/bin’,
require => [ File [’/root/scripts/if_conf_default.sh’], File \
[’/etc/pki/tls/private/.dirinfo/.p’] ],
}
Los bloques de configuración que comienzan por file crean los directorios y ficheros ne-
cesarios (scripts y fichero de contraseñas) con los permisos necesarios, mientras que los
bloques exec realizan ciertas comprobaciones para saber si los scripts tienen que ejecutar-
se o no.
Para ello no es necesaria ninguna configuración en estos equipos, sino que la configura-
ción se realizará en PacketFence.
PacketFence dispone de una característica llamada Security Events (conocida como Vio-
lations en versiones anteriores) que recomiendan utilizar para la adición de impresoras a
redes securizadas mediante 802.1X.
ID del evento
Triggers
Acciones a realizar
Cabe mencionar que a la hora de realizar de estas pruebas, PacketFence había publicado
una nueva versión (versión 9.01 a fecha del 24 de mayo de 2019) en la que estos Secu-
rity Events no funcionan correctamente. En la versión anterior esta característica tenía el
nombre de Violations y puede que al realizar ciertos cambios en las configuraciones de
estos Eventos hayan creado bugs.
2. Los Eventos no “saltan” cuando coinciden con las condiciones especificadas como
Triggers: En este caso se han especificado diferentes direcciones MAC (pertene-
cientes a impresoras y ordenadores portátiles Mac OS X) y ninguno de estos Even-
tos ha “saltado” de forma automática, aunque se ha comprobado que la dirección
MAC del equipo que ha realizado la petición RADIUS para la autenticación (mi-
rando con detenimiento en el fichero de log /usr/local/pf/logs/radius.log
los mensajes RADIUS recibidos) coincide con una de las direcciones MAC esta-
blecidas como Trigger.
priority=1
trigger=mac::3C:D9:2B:A4:7C:80,mac::3c:d9:2b:a4:7c:80,mac::3CD92BA47C80,
mac::3cd92ba47c80,mac::3C-D9-2B-A4-7C-80,mac::3c-d9-2b-a4-7c-80
actions=autoreg,role
desc=Printers
enabled=Y
access_duration=5D
target_category=Printers
Estos Eventos pueden ser disparados manualmente, la cual ha sido la mejor solución que
se ha encontrado para el registro de esos equipos en PacketFence y garantizarles acceso.
Para ello hay que Acceder a la pestaña Nodes de PacketFence una vez se haya conectado
la impresora o equipo Mac OS X a la red. Este dispositivo quedará atrapado en la VLAN
75 (Registration) ya que no tiene forma de autenticarse, y una vez ahí aparecerán en la
lista de la pestaña Nodes en estado unregistered.
Una vez detectado el dispositivo, haremos click sobre él para abrir una ventana donde
aparecerá información acerca de ese dispositivo (VLAN y rol asignado, mensajes RA-
DIUS recibidos, etc.) y donde podremos ver una pestaña llamada Security Events sobre la
que tendremos que hacer click.
Esta ventana trata de una lista de los Eventos relacionados con este dispositivo que hayan
sido disparados en algún momento, donde también se podrán disparar manualmente. Para
ello no hay más que seleccionar un Evento de la lista y hacer click sobre el botón “Trigger
New Security Event”. Una vez hecho esto el dispositivo quedará registrado y se le añadirá
el Role establecido en la condición target_category en la configuración del Evento (Printer
o Mac_OS_X) dependiendo del dispositivo y del Evento lanzado.
Para no tener que recurrir a realizar este registro manualmente, la mejor práctica será
acceder a la pestaña Edit y establecer una duración de acceso de, por ejemplo, 5 años.
De este modo, a la hora de incorporar un equipo Windows podrá añadirse al dominio y por
tanto descargar su propio certificado y el de la CA, y se realizarán las configuraciones por
GPO establecidas por el BCBL. Una vez realizado este paso, el equipo podrá conectarse a
la red securizada utilizando uno de los puertos configurados para realizar autenticaciones
802.1X.
En este capítulo se expone cómo se ha llevado a cabo la gestión de todo el Proyecto de Fin
de Grado, incluyendo la gestión del calendario, del alcance, del tiempo y de los riesgos.
99
100 Gestión del Proyecto
Las semanas están numeradas desde el día 1 de febrero siendo la semana 1 hasta la semana
del 13 de mayo siendo la semana 15. A partir de este momento, cada vez que se quiera
hacer referencia a una semana en concreto, se utilizará la siguiente nomenclatura: SX.
Siendo X el número de semana a la que se está haciendo referencia (ej. semana 3 = S3).
Las jornadas en la empresa serán de 5.5 horas (9:00 - 14:30) excepto martes y jueves
que serán 5 horas (9:00 - 14:00) debido a las clases presenciales de la asignatura SRDSI
que comienzan a las 15:00. Este horario suma un total de 26.5 horas semanales en la
empresa.
También se ha decidido hacer un seguimiento del TFG por parte de la empresa, por lo que
me reuniré con ellos una vez a la semana.
Se ha estipulado que el proyecto tendrá que estar terminado (memoria aparte) para finales
de abril o principios de mayo. Suponiendo que el proyecto esté terminado para la S13
y habiendo empezado el 1 de febrero de la S1, sumarían un total de 302.5 horas en la
empresa, teniendo pendiente la realización de la memoria (que también será supervisada
por el BCBL).
8.2 Gestión de los riesgos 101
En este apartado se intentan listar todos los posibles riesgos que pudiera correr la realiza-
ción del proyecto. Identificar estos riesgos e intentar proponer soluciones para mitigarlos
en la mayor medida posible es una labor que en un futuro podría determinar la correcta
finalización del proyecto en el plazo especificado.
Problemas relacionados con mi persona, tanto físicos como mentales, tales como podrían
ser problemas de salud o sucesos que puedan afectar directamente a mi estado emocional.
En este apartado también se incluyen sucesos que puedan ocurrir a familiares o seres
queridos y que puedan tener efectos emocionales negativos sobre mí o la necesidad de
tener que desplazarme.
Mitigaciones:
Las mitigaciones de este riesgo, podrían ser, a priori, establecer las fechas de los hitos de
una manera en la que pueda tener cierta holgura en caso de que suceda algo de lo men-
cionado. Si la planificación para los hitos no es demasiado justa, y dispongo del tiempo
suficiente para terminarlos con cierto tiempo de adelanto, este riesgo no debería de ser
demasiado costoso.
En caso de no terminar los hitos a tiempo por culpa alguno de estos motivos, existe otra
solución a posteriori, que consiste básicamente en trabajar horas fuera del horario esta-
blecido por el BCBL hasta recuperar el tiempo perdido.
Este riesgo podría condicionar la finalización del TFG en el plazo para el que estaba
planificado, con sus posteriores repercusiones, como podrían ser no poder realizar la de-
fensa del TFG en la fecha planificada o incluso recibir rechazo por parte del BCBL para
continuar con ellos.
102 Gestión del Proyecto
Mitigaciones:
Podría evitarse una situación como ésta, siendo “algo pesimista” con los tiempos en la
planificación, es decir, haciendo una planificación pensando que seguramente me encon-
traré con más problemas de lo pensado y añadiendo unas horas de más a las tareas que
puedan parecer más abstractas a la hora de hacer la planificación. De esta manera siempre
tendré tendré un pequeño margen que podrían evitar la situación mencionada en el punto
anterior.
La pérdida del trabajo realizado podría ser una catástrofe que seguramente se traduciría en
la imposibilidad de poder realizar la defensa del proyecto en plazo. Se trata de uno de los
mayores riesgos que podría correr el proyecto, aunque tomando las medidas oportunas,
es un riesgo con una probabilidad muy baja de suceder.
Mitigaciones:
Esta situación podría evitarse haciendo las suficientes copias de seguridad en diferentes
dispositivos. La memoria que ahora mismo estoy escribiendo, está siendo replicada cada
día de desarrollo tanto en una nube privada que se encuentra en el BCBL (NextCloud),
como en el PC de trabajo que estoy utilizando y en un directorio personal montado en
dicho PC, pero sobre el que se hacen backups todos los días. Además de esto, descargo
una copia en mi PC personal todas las semanas.
En el caso del proyecto en sí, también habrá copias de seguridad del mismo, ya que
se realizan backups tanto del hipervisor como de los servidores que ofrecen servicio al
centro.
8.2 Gestión de los riesgos 103
Las herramientas a utilizar en este proyecto son totalmente desconocidas para mí, lo que
significa que tendré que pasar por un proceso de aprendizaje autodidacta en lo que se refie-
re a las mismas. En el caso de no ser capaz de dominarlas lo necesario como para alcanzar
las expectativas que cubren al proyecto significaría no poder ser capaz de realizarlo, o co-
mo mínimo, necesitar más tiempo para la realización del mismo. Las consecuencias en el
caso de que se diera este riesgo podrían abarcar desde el retraso de los plazos marcados
para los hitos hasta la completa cancelación del proyecto, con su posterior realización de
otro proyecto diferente desde cero.
Mitigaciones:
La única manera de evitar este riesgo es el de estudiar las herramientas a utilizar hasta
un punto en el que tenga un punto de partida para prácticamente cualquier situación, o
pedir ayuda en caso de encontrarme con un problema que me requiera demasiado tiempo
solucionar.
Podría darse la situación en la que el proyecto no pueda seguir adelante una vez haya
comenzado su desarrollo debido a alguna incompatibilidad o falta de algún software o
componente hardware requerido. Esto se debería a una mala planificación, ya que, en
caso de encontrarse en una situación como esta debería de haberse detectado antes de
comenzar con la fase de desarrollo. Esta situación podría ver comprometida la finalización
del proyecto.
Mitigaciones:
Dependiendo del momento en el que se diera esta situación, podría replantearse el pro-
yecto, o en caso de verlo necesario, comenzar uno nuevo. En el caso de que esta situación
se diera con el proyecto muy avanzado con poco margen para las fechas de entrega el
proyecto no podría terminarse y tendría que ser aplazada su entrega.
104 Gestión del Proyecto
En esta sección se desglosará la EDT (figura 3.1) en tareas más pequeñas mostrando los
tiempos de dedicación para cada una de ellas.
Esta rama está compuesta por tres sub-bloques: Tecnologías, Herramientas y Red BCBL.
Bloque “Tecnologías”
Lectura y comprensión del manual del switch HP ProCurve 2810 –>3 horas
Bloque “Herramientas”
Bloque “Configuraciones”
Configuración del equipo portátil con Sistema Operativo Windows 7 –>1.5 horas
Bloque “Pruebas”
Esta rama está compuesta por tres sub-bloques: Configuraciones, Pruebas y Despliegue.
Bloque “Configuraciones”
Bloque “Pruebas”
Bloque “Despliegue”
8.3.6. Total
La mejor manera de representar la gestión del tiempo es hacerlo de manera gráfica me-
diante un diagrama de Gantt:
El seguimiento y control del correcto desarrollo del proyecto se ha realizado con frecuen-
cia por parte del BCBL. En un principio se decidió hacer reuniones semanales comen-
zando en la semana S4, aunque por diversos motivos no ha podido cumplirse a rajatabla,
pero se han podido realizar las suficientes reuniones para un correcto seguimiento sobre
el proyecto.
Las reuniones realizadas con los superiores del BCBL han sido las siguientes:
Fecha: 20/02/2019
Fecha: 27/02/2019
Fecha: 13/03/2019
• Lugar: Departamento de IT
• Asistentes: José Corral, Javier Gutiérrez, Borja Chantre y Jose Mª Caballero
• Duración: 20 minutos
• Motivo: Demostración del funcionamiento de una autenticación basada en
usuario y contraseña al departamento de IT
8.5 Gestión del alcance 109
Fecha: 20/03/2019
• Lugar: Departamento de IT
• Asistentes: José Corral, Javier Gutiérrez, Borja Chantre y Jose Mª Caballero
• Duración: 25 minutos
• Motivo: Demostración del funcionamiento de la asignación de VLANs basada
en roles al departamento de IT
Fecha: 17/04/2019
• Lugar: Departamento de IT
• Asistentes: José Corral, Javier Gutiérrez, Borja Chantre y Jose Mª Caballero
• Duración: 15 minutos
• Motivo: Seguimiento y control
Fecha: 09/05/2019
• Lugar: Departamento de IT
• Asistentes: José Corral, Javier Gutiérrez, Borja Chantre y Jose Mª Caballero
• Duración: 20 minutos
• Motivo: Demostración del funcionamiento de una autenticación basada en cer-
tificados al departamento de IT
Fecha: 22/05/2019
Fecha: 12/06/2019
• Lugar: Departamento de IT
• Asistentes: José Corral, Javier Gutiérrez, Borja Chantre y Jose Mª Caballero
• Duración: 45 minutos
• Motivo: Despliegue de la securización 802.1X en el departamento de IT
9. CAPÍTULO
Conclusiones
En este breve capítulo se exponen las conclusiones obtenidas tras la realización del pro-
yecto. Este capítulo ha sido dividido en dos secciones diferentes; las lecciones aprendidas
por una parte, y las posibles mejoras aplicables al proyecto por otra.
Partiendo de la base de que en la carrera únicamente se han visto muchos de estos concep-
tos de forma teórica, puedo afirmar que he adquirido cierta experiencia en la utilización
y/o configuración de ciertas tecnologías y herramientas, como por ejemplo la configu-
ración de un sistema (switches, equipos finales y servidores RADIUS) para realizar una
autenticación 802.1X basada en puertos.
Además, también puedo afirmar que he aprendido mucho sobre PacketFence, la herra-
mienta principal del proyecto, además de la instalación, configuración y gestión de un
Windows Server para los servicios tanto de Directorio Activo como de Autoridad Certifi-
cadora.
111
112 Conclusiones
Aunque he quedado satisfecho con el resultado del proyecto, pueden modificarse ciertos
aspectos para mejorarlo:
Bibliografía
https://wernicke.bcbl.local/wiki/index.php/
https://packetfence.org/about.html
https://packetfence.org/doc/PacketFence_Installation_Guide.html
https://packetfence.org/doc/PacketFence_Administration_Guide
https://support.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0126241
https://www.incibe-cert.es/blog/protocolos-aaa-radius
https://redmine-opennac.opencloudfactory.com/projects/opennac/wiki/
113
114 Bibliografía
https://social.technet.microsoft.com/wiki/contents/articles/9063.active-
directory-certificate-services-ad-cs-network-device-enrollment-
service-ndes.aspx
https://wiki.openssl.org/index.php/Command_Line_Utilities#Key_Generation
https://www.afp548.com/2012/11/20/802-1x-eaptls-machine-auth-mtlion-adcerts/
Anexos
115
A. ANEXO
Necesidades del centro: Este será el motivo de más peso para la elección del soft-
ware. En caso de que una de las dos herramientas no cumpla cualquiera de las
necesidades exigidas por el centro será descartada automáticamente.
Compatibilidad con los equipos que forman parte de la red del centro: En ca-
so de haber algún tipo de incompatibilidad con algún elemento que forma parte
de la red, se estudiarán alternativas que puedan solucionar el problema sin tener
repercusión en el funcionamiento actual de la misma . En caso de no encontrar nin-
guna solución capaz de compatibilizar dicho elemento con la alternativa software
en cuestión, ésta será descartada automáticamente.
117
118 Anexo A
En las siguientes páginas se recopilará toda la información posible acerca de ambas he-
rramientas y sus características utilizando únicamente su documentación oficial.
A.1. PacketFence
A.1.1. Características
1 https://packetfence.org/about.html#/overview
120 Anexo A
Autenticación y registro:
Registro de dispositivos:
Packetfence ofrece una solución parecida a la de los portales cautivos, pero con un
distintivo importante. A diferencia de la mayoría de soluciones basadas en porta-
les cautivos, los miembros de PacketFence que hayan sido previamente registrados
tendrán acceso automático sin requerir ninguna otra autenticación, aunque esta op-
ción es también configurable. Puede especificarse una Política de Uso para que los
usuarios no puedan tener acceso a la red hasta que la acepten.
Integración inalámbrica:
PacketFence se integra perfectamente en redes inalámbricas gracias al módulo Free-
RADIUS que está incluido en el paquete. Esto puede permitir securizar redes ca-
bleadas o inalámbricas de la misma manera, utilizando la misma base de datos de
usuarios y utilizando el mismo portal cautivo. Además ofrece soporte para diferen-
tes fabricantes de Puntos de Acceso (AP) y controladores inalámbricos.
Estado de salud:
A la hora de hacer una autenticación de usuario mediante 802.1x, PacketFence pue-
de realizar una completa evaluación del dispositivo que realiza la petición de co-
nexión utilizando el protocolo de Estado de Salud TNC (Trusted Network Connect
Statement of Health protocol). Por ejemplo, PacketFence puede verificar si el dispo-
sitivo tiene instalado algún antivirus y si está actualizado, si se han aplicado parches
al sistema operativo, etc. Una de las grandes ventajas de esta característica es que
no será necesario instalar ningún tipo de software en los dispositivos extremos.
Agentes de seguridad:
PacketFence se integra con soluciones de agentes de seguridad como OPSWAT Me-
tadefender Endopoint Management, Symantec SEPM y otros. Puede asegurarse de
que el agente está siempre instalado antes de conceder el acceso a la red.También
puede comprobar la situación en la que se encuentra un dispositivo extremo y ais-
larlo.
122 Anexo A
Además, el método Por Switch puede combinarse con los demás. Por ejemplo, con
una configuración por defecto de PacketFence, puede asignarse una VLAN o un
rol a impresoras o PCs (en caso de estar categorizadas correctamente) basándose
sobre a qué equipo están conectados. Esto implica que pueden conseguirse de forma
sencilla VLANs del tipo “por edificio” o “por dispositivo”.
Registro automático:
Despliegue gradual
Extensible y personalizable
Comparativa tecnológica: PacketFence vs openNAC 125
Autenticación flexible:
PacketFence puede autenticar a los usuarios utilizando varios protocolos/estánda-
res. Esto permite integrar PacketFence en la red sin la necesidad de que los usuarios
finales tenga que memorizar otra cuenta y contraseña. Las fuentes de autenticación
soportadas son las siguientes:
• LDAP:
◦ Directorio Activo de Microsoft
◦ Novell eDirectory
◦ OpenLDAP
• RADIUS:
◦ Cisco ACS
◦ RADIUS (FreeRADIUS, Radiator, etc.)
◦ Microsoft NPS
• Fichero local de usuarios (formato htpasswd de Apache)
• OAuth2:
◦ Facebook
◦ Google
◦ GitHub
◦ LinkedIn
◦ Microsoft Live
◦ Twitter
Basado en estándares:
PacketFence está construido para utilizar estándares abiertos y evitar el bloqueo de
proveedores. Entre estos estándares se encuentran:
• 802.1X
• Simple Network Management Protocol (SNMP)
• RADIUS
• Netflow / PIFIX
• Wireless ISP Roaming (WISPR)
126 Anexo A
A.2. openNAC
Por último, pero no por ello menos importante, proporciona servicios de valor añadido
como la gestión de la configuración, la red, las configuraciones de backup, la detección
de redes y la monitorización de redes.” 2
A.2.1. Características
2 http://www.opennac.org/opennac/en/about/what-is-opennac.html
Comparativa tecnológica: PacketFence vs openNAC 127
A.3. Resumen
Teniendo en cuenta la información obtenida a través de las páginas web oficiales de cada
una de las herramientas, se puede comprobar como en la web de PacketFence puede
encontrarse muchísima más información acerca de su producto, así como una explicación
breve de cada una de las características que incluye, mientras que en la página web de
openNAC únicamente podemos encontrar un listado de las características que incluye e
información acerca de las utilidades del producto en general, y un breve resumen sobre
cada uno de los módulos que lo componen. Esta primera impresión decanta la balanza a
favor de PacketFence, sin ni siquiera haber entrado en detalle aún.
A continuación se expondrán las diferencias acerca de las características más útiles para
este proyecto de cada una de estas herramientas ilustradas mediante una tabla.
A.4. Conclusiones
Puede comprobarse a simple vista cómo PacketFence contiene muchas más características
que openNAC. Aunque algunas de ellas no vayan a ser utilizadas en este momento, no está
de más que las incluya, ya que pueden ser útiles en un futuro una vez la herramienta esté
desplegada en el sistema.
Cierto es que hay utilidades de openNAC que podrían resultar útiles como por ejemplo
la detección y monitorización de redes, que no es absolutamente necesaria, o la configu-
ración en masa para dispositivos en línea, que tampoco es necesaria ya que en el BCBL
cuentan con herramientas en funcionamiento que cumplen el mismo propósito.
8GB de RAM
131
132 Anexo B
El primer paso para los Sistemas Operativos basados en Red-Hat será desactivar el Fire-
wall y SELinux, además de asegurarnos de que la base de datos de yum está debidamente
actualizada, para ello ejecutaremos los siguientes comandos:
Además de esto, también debemos decir explícitamente al Network Manager que nunca
interactúe con nuestra configuración DNS, para ello ejecutamos lo siguiente:
Una vez realizados estos pasos, podemos acceder a descargar e instalar PacketFence. Para
ello tendremos que añadir el repositorio de PacketFence a yum y después descargarlo e
instalarlo:
Tras realizar estos pasos, PacketFence ya estará instalado en la máquina. A partir de es-
te punto, la mayoría de configuraciones se realizarán mediante la interfaz web, ya que
es una manera más sencilla y visual que la de editar ficheros de configuración, aunque
habrá configuraciones que requieran de ello. Para acceder a la interfaz web de Packet-
Fence, tendremos que escribir https://@ip_packetfence:1443/configurator en la
barra de búsqueda de cualquier navegador web, donde encontraremos el asistente para la
cofiguración inicial de PacketFence.
En este primer paso tendremos que elegir un tipo de implementación (enforcement), que
en este caso será la opción VLAN enforcement.
134 Anexo B
Una vez seleccionado el tipo de implementación, el segundo paso será configurar las
interfaces de la máquina virtual. Tal y como se explica en el capítulo 5, esta máquina
virtual dispone de tres interfaces de red, cada una conectada a una VLAN:
Estas interfaces tendrán que aparecer listadas en este segundo paso de la configuración.
Para configurarlas, haremos click sobre el nombre de cada una de ellas donde tendremos
que rellenar un pequeño formulario como el que se muestra en la siguiente imagen:
En este formulario tendremos que escribir la dirección IP de la interfaz que estamos con-
figurando, la máscara de la red a la que está conectada y el “tipo” de VLAN, es decir, si
se trata de una VLAN de registro, de aislamiento o de administración.
Instalación y configuración inicial de PacketFence en CentOS 7 135
Nótese que cuando asignamos el tipo Isolation o Registration a una de las interfaces
aparecerá un pequeño checkbox activado que dice “Enable DHCP Server”. Esto se debe
a que PacketFence asignará direcciones IP a las máquinas que accedan a dichas VLANs
mediante DHCP. En el resto de VLANs será el servidor DHCP del dominio quien asigne
las direcciones IP.
En el siguiente paso, tendremos que crear un usuario root para la base de datos, crear la
propia base de datos y crear una cuenta de usuario para el propio PacketFence. En esta
base de datos se almacenarán todos los nodos que intenten acceder a la red a través de
PacketFence, así como los usuarios autenticados, usuarios administradores, ciertas confi-
guraciones de PacketFence e incluso algún que otro archivo de log.
Una vez configurados los usuarios y creada la base de datos, en el siguiente paso Packet-
Fence requerirá información acerca del dominio:
En el paso número 5 de este asistente de configuración tendremos que asignar una con-
traseña a la cuenta de administrador (de nombre “admin”) para PacketFence. Esta cuenta
será la cuenta desde la que se realizará toda la configuración, al menos por defecto, ya que
más tarde podremos añadir usuarios con privilegios de administración para que, por ejem-
plo, cualquier empleado del departamento de IT pueda tener acceso a la configuración de
PacketFence.
Instalación y configuración inicial de PacketFence en CentOS 7 137
Para cambiar la contraseña, solamente hay que rellenar el formulario que aparece en pan-
talla escribiendo dos veces la contraseña que queremos asignarle. Una vez hecho esto,
hacer click sobre el botón que dice “MODIFY THE PASSWORD”. En caso de no haber
ningún error, aparecerá una mensaje de confirmación.
Una vez realizados estos 5 pasos de configuración, PacketFence estará listo para empezar
a funcionar, aunque obviamente habrá que configurar muchísimas cosas más, ya que esta
configuración no es más que una configuración mínima para poder poner en funciona-
miento la herramienta.
El último paso de este asistente será nada menos que la confirmación de que todas las
configuraciones anteriores eran correctas. En esta ventana aparecerán todos los servicios
o demonios que PacketFence pondrá en marcha en un estado “Stopped”. En el momento
que pulsemos sobre el botón “START PACKETFENCE” pasarán a un estado “Starting”
para terminar (si todo ha ido correctamente) en el estado “Started”.
138 Anexo B
El primer paso será crear un usuario administrador del servidor y otro para correr el servi-
cio en sí. Estos usuarios han sido nombrados SCEPAdmin y SCEPSvc respectivamente.
El usuario SCEPAdmin tendrá derechos de administrador sobre el propio servidor, mien-
tras que el usuario SCEPSvc tendrá que ser parte del grupo IIS_IUSRS.
139
140 Anexo C
Una vez creados los usuarios necesarios, el siguiente paso será instalar un “rol” ADCS
(Active Directory Certificate Services). Para ello hay que hacer click sobre el enlace “Add
Roles”. Realizado este paso, aparecerá un asistente de instalación de roles, donde hay que
seleccionar la casilla Active Directory Certificate Services y pulsar sobre el botón Next >.
En este momento se puede comprobar como la opción Network Device Enrollment Service
sí aparece en la lista, por lo que el siguiente paso consistirá en eleccionar la casilla NDES
y pulsar sobre el botón Next >:
Figura C.3: La opción NDES sí aparece en Windows Active Directory 2008 R2 Enterprise
Configuración de Microsoft Active Directory 2008 R2 Enterprise 141
En el tercer paso dentro de este asistente, hay que especificar la Certification Authority
(CA) que emitirá los certificados. Podría utilizarse el mismo servidor que está siendo
configurado, pero ya que existe una CA activa y en funcionamiento en la red, será la que
se utilizará. Para ello se puede añadir el nombre que la CA tiene en el dominio, en este
caso acc.bcbl.local.
El cuarto paso consiste en introducir información acerca del Registration Authority (RA)
que estamos configurando. La información introducida en el formulario es la siguiente:
RA NAME: TFG03-MSCEP-RA
Country/Region: ES (Spain)
E-mail: [email protected]
Company: BCBL
Department: IT
City: Donostia
State/Province: Guipúzcoa
142 Anexo C
En el siguiente paso hay que especificar la criptografía que se utilizará para la Clave de
Firma y la Clave de Encriptado. Ya que no hay requisitos específicos por parte del BCBL,
se utilizarán los valores por defecto que aparecen en la ventana.
El último paso de este asistente será la confirmación de los datos introducidos hasta este
punto. Para ello comprobamos que los datos que aparecen en la ventana son correctos y
hacemos click sobre el botón “Install”.
Una vez que los servicios se hayan instalado correctamente en el servidor hay que pasar
a configurarlos. El protocolo SCEP está configurado de forma en que si un usuario (o
máquina) realiza una petición para recibir un certificado, tendrá que saber una contraseña
que se encuentra en la dirección http://TFG03/certsrv/mscep_admin/ y para acceder
a dicha dirección se requieren credenciales de administrador del servidor.
Esta opción está bien si se quiere que todos los usuarios que requieran un certificado
tengan que pasar este control de seguridad, el cual no podrán traspasar sin ponerse en
contacto con el departamento de IT y poder conseguir esa contraseña para poder pedir el
certificado, aunque no es el escenario que desean en el BCBL, ya que la idea es que los
equipos conectados a la red puedan enrolarse automáticamente (autoenrollment) por lo
que tendremos que configurar esta característica.
Configuración de Microsoft Active Directory 2008 R2 Enterprise 143
Para ello tendremos que hacer click sobre la tecla de Windows, escribir regedit y pul-
sar Enter. Se abrirá una ventana por la cual iremos navegando en el árbol de directo-
rios que aparece en la columna de la izquierda hasta llegar a HKEY_LOCAL_MACHINE
–>SOFTWARE –>Microsoft –>Cryptography –>MSCEP –>UseSinglePassword y una
vez aquí cambiar el valor del registro “UseSinglePassword” a 1. Mediante este cambio
forzaremos a que la contraseña necesaria para “autoenrrolarse” sea la misma para todos
los equipos, así podrá ser añadida al script autoenrollment.sh (Anexo E). De esta manera,
todos los equipos que ejecuten dicho script obtendrán un certificado, pero si un usuario
quiere descargarlo manualmente no podrá hacerlo ya que no dispondrá de dicha contrase-
ña para realizar la petición.
Se recomienda extender la longitud máxima permitida para las URL para evitar proble-
mas, para ello hay que escribir las siguientes líneas en la línea de comandos del servidor:
En este punto hay que proceder a crear un duplicado de la plantilla del certificado que se
quiere distribuir a través del protocolo SCEP. En este caso se ha decidido duplicar la plan-
tilla llamada “Computers” puesto que es el certificado que se emite automáticamente en
los equipos con Sistema Operativo Windows. Para ello hay que acceder a la CA del dominio
y navegar por el árbol de directorios que aparece en la parte izquierda hasta llegar a Roles
–>Active Directory Certificate Services –>Certificate Templates (acc.bcbl.local).
En este directorio aparecerá una lista de todas las plantillas de certificados que hay guar-
dados en la CA. Para crear un duplicado de una plantilla hay que hacer click derecho
sobre el nombre de cualquiera de ellas, hacer click sobre “Duplicate Template” y en la
ventana emergente seleccionar “Windows Server 2003 Enterprise”.
Se abrirá una nueva ventana donde se podrán establecer diferentes parámetros asociados
al certificado que se emitirá utilizando la actual plantilla. En este caso se ha cambiado el
nombre por NDES_Computers, y se ha seleccionado la opción “Supply in the request”
dentro de la pestaña “Subject Name”, y los demás parámetros se han dejado con sus
valores por defecto.
Una vez creada la plantilla para los nuevos certificados hay que realizar un último paso
para que puedan ser emitidos. Para ello hay que acceder al directorio Roles –>Active
Directory Certificate Services –>bcbl-PFC-CA (nombre de la CA), hacer click derecho
sobre el directorio “Certificate Templates –>New –>Certificate Template to Issue” y en
la lista que aparecerá en pantalla seleccionar la plantilla que se acaba de crear y hacer
click sobre el botón “OK”.
Configuración de Microsoft Active Directory 2008 R2 Enterprise 145
Como último paso para terminar de configurar el servidor web, y por tanto, la configura-
ción del Directorio Activo, hay que navegar hasta Roles –>Web Server (IIS) –>Internet
Information Services (IIS) Manager. En este punto hay que navegar por el árbol de direc-
torios que aparecerá en la ventana del centro hasta llegar a TFG03 (BCBL/SCEPAdmin)
–>Application Pools.
La primera será “DefaultAppPool”, sobre la que hay que hacer click derecho y seleccio-
nar “Advanced Settings...” y una vez ahí, buscar el bloque de opciones “Process Model”.
Una vez encontrado hay que cambiar dos parámetros dentro del mismo, el primero será
“Identity”, donde habrá que seleccionar la opción “Built-in account:” y elegir Network-
Service en la lista desplegable. El segundo parámetro a cambiar es el que dice “Load
User Profile”, al cual habrá que asignar el valor False.
La segunda será “SCEP”. De la misma manera, click derecho sobre el nombre y selec-
cionar “Advanced Settings...” y buscar el bloque de opciones “Process Model”. El único
parámetro a cambiar es el que dice “Load User Profile”, al cual habrá que asignar el valor
True.
Tal y como puede observarse en la imágen superior, la Autoridad Certificadora sigue sien-
do bcbl-PFC-CA (acc.bcbl.local en el dominio), lo que significa que seguirá siendo éste
servidor el que emita los certificados, pero a través de TFG03 podrán enrolarse auto-
máticamente diferentes tipos de dispositivos, entre ellos los PCs con Sistema Operativo
Linux.
Con esto concluye la instalación y configuración del servidor Microsoft Active Directory
2008 R2 Enterprise, por lo que los equipos con Sistema Operativo Linux deberían de ser
capaces de “autoenrrolarse”. Para ello se utilizará el comando sscep, que se trata de la
implementación de un cliente de SCEP que se utiliza mediante línea de comandos.
Configuración de Microsoft Active Directory 2008 R2 Enterprise 149
La única modificación a realizar en la parte del Directorio Activo para permitir el auto-
enrollment se refiere al certificado en sí. Para ello hay que acceder a la CA y navegar
hasta el directorio Roles –>Active Directory Certificate Services –>Certificate Templates
(acc.bcbl.local), buscar el nombre del certificado al que queremos otorgar permisos de
autoenrollment, hacer click derecho sobre él y después hacer click sobre “Properties”.
En la ventana de propiedades del certificado, navegar a la pestaña “Security” y en la lista
superior seleccionar el usuario/máquina o grupo de usuarios/máquinas a los que queremos
permitir “autoenrrolarse”, en este caso “Domain Computers”.
Para crear un nuevo perfil en un servidor macOS Server hay que hacer click sobre el
botón “Profile Manager” que aparece en la columna situada en la parte izquierda de la
pantalla principal del servidor. Una vez aparezca la ventana de creación del perfil podrán
observarse diversos apartados posibles de configurar para el mismo en la parte izquierda
de la ventana. Para crear un perfil que consista en realizar una autenticación basada en
certificados para una interfaz específica hay que configurar cuatro apartados:
1. General:
En esta sección hay que añadir información acerca del perfil, así como el nombre,
descripción o método de distribución.
2. AD Certificate:
En este apartado hay una línea en la que dice “Certificate Template”. El nombre
que se añada aquí tiene que coincidir con el nombre del certificado que se utilizará
para la autenticación de la máquina, en este caso NDES_Computers.
3. Certificates:
En esta sección será imprescindible incluir todos los certificados en los que será
necesario confiar para que se pueda confiar en el certificado que generará el Direc-
torio Activo. También habrá que añadir cualquier certificado que vaya a utilizarse
en la negociación TLS entre el cliente y el servidor RADIUS.
151
152 Anexo D
4. Network:
Aquí es donde se configuran las opciones acerca de los ajustes de red. Si estas con-
figuraciones se han realizado en el orden indicado, en este último apartado debería
aparecer cierta información añadida en los apartados anteriores una vez se haya se-
leccionado TLS como “EAP type”. Además de esto, también tendrán que aparecer
listados los certificados que se añadieron en el paso número 3, junto a un recuadro
que podrá checkearse o no, dependiendo si queremos confiar en ese certificado. Co-
mo último paso será necesario añadir el FQDN del servidor RADIUS, que en este
caso será la máquina donde está funcionando PacketFence, tfg01.bcbl.local.
E. ANEXO
#!/bin/bash
# Linux Certificate Enrollment Using NDES and SCEP
##################################################################
# This script is provided as an example for illustration only,
# without warranty either expressed or implied, including, but not
# limited to, the implied warranties of merchantability and/or
# fitness for a particular purpose.
##################################################################
#
# Insert the NDES Enrollment Password here.
# ndeskey=
# Insert the NDES server FQDN
ndesserver=tfg03.bcbl.local
# CA Filename
cafilename=tfg03
# Number of days ahead of cert expiration to renew
warning_days=45
############################################################
#EDIT ONLY THE VALUES ABOVE
############################################################
shopt -s -o nounset
153
154 Anexo E
then
writelog "sscep: openssl is installed."
else
yum -y install openssl 2>&1 >> $LOGFILE
fi
MKREQUESTSCRIPT=/usr/bin/mkrequest
sed -i ’s/KEYBITS=1024/KEYBITS=2048/g’ $MKREQUESTSCRIPT
if ! grep -q "string_mask = nombstr" $MKREQUESTSCRIPT ; then
sed -i ’/\[ req \]/a string_mask = nombstr’ $MKREQUESTSCRIPT
fi
if [ ! -f /etc/pki/tls/certs/$(hostname).crt ] ; then
writelog "sscep: $(hostname) does not have an existing certificate. \
Executing initial enrollment."
writelog "sscep: Requesting CA certificate chain as x509 .crt files."
sscep getca -F sha1 -c /etc/pki/ca-trust/source/anchors/\
${cafilename}CA.crt -u http://${ndesserver}/certsrv/mscep/mscep.dll/\
pkiclient.exe? 2>&1 >> $LOGFILE
writelog "sscep: Adding the CA chain to the host CA trusted chain."
update-ca-trust enable 2>&1 >> $LOGFILE
update-ca-trust extract 2>&1 >> $LOGFILE
writelog "sscep: Generating CSR."
mkrequest -dns $(hostname) 2>&1 >> $LOGFILE
writelog "sscep: Moving CSR and new private key."
mv local.key /etc/pki/tls/private/$(hostname).key
mv local.csr /etc/pki/tls/private/$(hostname).csr
openssl rsa -aes256 -in /etc/pki/tls/private/$(hostname).key\
-out/etc/pki/tls/private/$(hostname).encrypted.key -passout pass:file:\
/etc/pki/tls/private/.dirinfo/.p
writelog "sscep: Executing enrollment using NDES key."
sscep enroll -E 3des -S sha1 -c /etc/pki/ca-trust/source/anchors/\
${cafilename}CA.crt-0 -e /etc/pki/ca-trust/source/anchors/\
${cafilename}CA.crt-1 -k /etc/pki/tls/private/$(hostname).key -r
156 Anexo E
/etc/pki/tls/private/$(hostname).csr -l /etc/pki/tls/private/\
$(hostname).crt -u http://${ndesserver}/certsrv/mscep/mscep.dll/\
pkiclient.exe? -d -v 2>&1 >> $LOGFILE
writelog "sscep: Checking generated certificate status."
CERTSTATUS=$(openssl verify /etc/pki/tls/private/$(hostname).crt\
| cut -d: -f2)
if [ $CERTSTATUS == "OK" ]; then
writelog "sscep: Certificate status is: " $CERTSTATUS
writelog "sscep: Copying new certificate to /etc/pki/tls/\
certs/$(hostname).crt"
cp /etc/pki/tls/private/$(hostname).crt /etc/pki/tls/certs/\
$(hostname).crt 2>&1 >> $LOGFILE
else
writelog "sscep: The certificate is not valid per $CERTSTATUS"
fi
else
output=$(openssl x509 -in /etc/pki/tls/certs/$(hostname).crt -noout \
-subject -dates 2>/dev/null)
cert=$(echo $output | sed ’s/.*CN=\(.*\).*not.*/\1/g’)
start_date=$(echo $output | sed ’s/.*notBefore=\(.*\).*not.*/\1/g’)
end_date=$(echo $output | sed ’s/.*notAfter=\(.*\)$/\1/g’)
start_epoch=$(date +%s -d "$start_date")
end_epoch=$(date +%s -d "$end_date")
epoch_now=$(date +%s)
if [ "$start_epoch" -gt "$epoch_now" ]; then
writelog "sscep: Certificate for [$cert] is not yet valid"
writelog $output
fi
seconds_to_expire=$(($end_epoch - $epoch_now))
days_to_expire=$(($seconds_to_expire / 86400))
writelog "existing certificate found"
writelog "sscep: Days to expiry: ($days_to_expire)"
warning_seconds=$((86400 * $warning_days))
if [ "$seconds_to_expire" -lt 0 ]; then
Código del script Autoenrollment.sh 157
private/$(hostname).crt"
cp -f /etc/pki/tls/private/$(hostname).crt /etc/pki/tls/
certs/$(hostname).crt
else
writelog "sscep: The certificate is not valid per \
$CERTSTATUS"
writelog "sscep: Restoring the backup existing \
certificate and keys."
mv -f /etc/pki/tls/private/$(hostname).crt.bak
/etc/pki/tls/private/$(hostname).crt
mv -f /etc/pki/tls/private/$(hostname).key.bak
/etc/pki/tls/private/$(hostname).key
fi
fi
fi
fi
F. ANEXO
159
160 Anexo F