1. 1.- ¿Que son los circuitos virtuales?
El X.25 es una red de conmutación de paquetes que utiliza circuitos virtuales. Los circuitos virtuales son
creados en el nivel de red, esto significa que una conexión física entre un DTE y un DCE puede transportar
varios circuitos virtuales en el nivel de red, siendo cada circuito responsable de la transmisión de datos o de
control (señalización en banda).
Cada circuito virtual debe estar identificado para ser usado por los paquetes, y este identificador se
denomina: número de canal lógico (LCN), cuando se establece un canal virtual siempre hay un par de LCN:
uno define el circuito virtual entre el DTE y el DCE locales y el otro el circuito virtual entre el DCE y el DTE
remotos. La razón de tener dos LCN es hacer al LCN de dominio local. El LCN local permite que el mismo
conjunto de LCN pueda ser utilizado por dos pares diferentes de enlaces DTE-DCE sin ninguna confusión.
2.- ¿Cuales son los tipos de firewall incluir imágenes explicadas?
Las firewalls a nivel de red generalmente, toman las decisiones basándose en la fuente, dirección de
destino y puertos, todo ello en paquetes individuales IP. Un simple router es un "tradicional" firewall a nivel
de red, particularmente, desde el momento que no puede tomar decisiones sofisticadas en relación con
quién está hablando un paquete ahora o desde donde está llegando en este momento. Las modernas
firewall a nivel de red se han sofisticado ampliamente, y ahora mantienen información interna sobre el
estado de las conexiones que están pasando a través de ellas, los contenidos de algunos datagramas y
más cosas. Un aspecto importante que distingue a las firewall a nivel de red es que ellas enrutan el tráfico
directamente a través de ellas, de forma que un usuario cualquiera necesita tener un bloque válido de
dirección IP asignado. Las firewalls a nivel de red tienden a ser más veloces y más transparentes a los
usuarios.
Un ejemplo de una firewall a nivel de red se muestra en la figura anterior. En este ejemplo se representa
una firewall a nivel de red llamada "Screend Host Firewall". En dicha firewall, se accede a y desde un único
host el cual es controlado por un router operando a nivel de red. El host es como un bastión, dado que está
muy defendido y es un punto seguro para refugiarse contra los ataques.

2. Otros ejemplo sobre una firewall a nivel de red es el mostrado en la figura anterior.En este ejemplo
serepresenta una firewall a nivel de red llamada "screened subnet firewall". En dicha firewall se accede a y
desdeel conjunto de la red, la cual es controlada por un router operando a nivel de red. Es similar al firewall
indicadaen el ejemplo anterior salvo que esta si que es una red efectiva de hosts protegidos.
Los Firewalls a nivel de aplicación son generalmente, hosts que corren bajo servidores proxy, que no
permitentráfico directo entre redes y que realizan logines elaborados y auditan el tráfico que pasa a través
de ellas. Las firewall a nivel de aplicación se puede usar como traductoras de direcciones de red, desde
que el tráfico entrapor un extremo hasta que sale por el otro. Las primeras firewalls a nivel de aplicación
eran poco transparentes alos usuarios finales, pero las modernas firewalls a nivel de aplicación son
bastante transparentes. Las firewalls anivel de aplicación, tienden a proporcionar mayor detalle en los
informes auditados e implementan modelos deconservación de la seguridad. Esto las hace diferenciarse de
las firewalls a nivel de red.
3.- ¿Que es una DMZ?
Una DMZ (del inglés Demilitarized zone) o Zona DesMilitarizada. Una zona desmilitarizada (DMZ) o red
perimetral es una red local que se ubica entre la red interna de una organización y una red externa,
generalmente Internet.
El objetivo de una DMZ es que las conexiones desde la red interna y la externa a la DMZ estén permitidas,
mientras que las conexiones desde la DMZ sólo se permitan a la red externa, es decir: los equipos locales
(hosts) en la DMZ no pueden conectar con la red interna.
Esto permite que los equipos (hosts) de la DMZ’s puedan dar servicios a la red externa a la vez que
protegen la red interna en el caso de que intrusos comprometan la seguridad de los equipos (host) situados
en la zona desmilitarizada. Para cualquiera de la red externa que quiera conectarse ilegalmente a la red
interna, la zona desmilitarizada se convierte en un callejón sin salida.
La DMZ se usa habitualmente para ubicar servidores que es necesario que sean accedidos desde fuera,
como servidores de e-mail, Web y DNS.
4.-Mencione y explique por lo menos 5 algoritmos de encriptación
DES y 3DES
El algoritmo DES (Data Encryption Standard) creado en 1976 requiere una clave de 64 bits, de los cuales
utiliza únicamente 56 bits siendo los otros 8 un control de paridad.
Para mejorar la seguridad se creo Triple DES (TDES o 3DES), que consiste en utilizar tres veces DES,
cifrando y/o descifrando con una, dos o tres claves diferentes. Así DES-EEE1 cifra tres veces con la misma

3. clave, mientras que DES-EDE3 cifra-descifra-cifra con tres claves diferentes (al usar para descifrar una
clave diferente que para cifrar, en realidad se complica el cifrado). Las variantes más seguras son DES-
EEE3 y DES-EDE354.
Si se utilizan 3 claves diferentes la longitud de la clave usada es de 168 bits (56x3) pero la seguridad
efectiva55 es de 112 bits.
3DES es un algoritmo seguro pero lento, que permitió seguir utilizando dispositivos creados para DES. Sin
embargo está siendo sustituido por AES (Advanced Encryption Standard).
AES
AES (Advanced Encryption Standard) es uno de los algoritmos más utilizados, ya que se convirtió en
estándar en 2002. Utiliza un tamaño de bloque de 128 bits y claves de 128, 192 o 256 bits. AES es rápido
tanto por software como por hardware, es relativamente sencillo de implementar y requiere poca memoria
en el proceso.
RCx
RC4 (Rivest Cipher o Rons Code) era el algoritmo de cifrado por software más utilizado en parte por ser el
algoritmo utilizado por SSL y WEP. Este algoritmo utiliza un sistema de cifrado de flujo (stream cipher) no
de trasposición de bloques. Esto hace que sea rápido y sencillo. Sin embargo este algoritmo es fácilmente
atacable si la clave de flujo (keystream) no se descarta, o no es aleatoria o cambia en relación a la clave
anterior o se usa varias veces la misma.
Utiliza una clave de entre 40 y 256 bits y no se recomienda su uso ya que no aporta seguridad suficiente.
RC4 ha sido sustituido por RC5 y RC6 que utilizan trasposición de bloques. RC6 utiliza un tamaño de
bloque de 128 bits y claves de 128, 192 o 256 bits (como AES), aunque puede parametrizarse con otros
valores. ARCFour (Alleged RC4) es un algoritmo libre al parecer compatible con RC4 (algoritmo patentado
y cerrado).
IDEA
IDEA (International Data Encryption Algorithm) es un algoritmo de trasposici ón de bloques de 64 bits con
clave de 128 bits. Se usa en PGPv2 (Pretty Good Privacy) y es opcional en OpenPGP dado que está sujeto
a licencia en algunos paises.
RSA (Rivest, Shamir and Adlman)
Es el más popular y utilizado de los algoritmos asimétricos. Fue inventado en 1978 por Rivest, Shamir
y Adlman que dan nombre al algoritmo. Patentaron el algoritmo y cuando alcanzó popularidad fundaron una
empresa, RSA Data Security Inc., para la explotación comercial. Para su implementación y
comercialización se deben pagar derechos a esta empresa, pero actualmente se encuentran muchas
versiones gratuitas en Internet. Fuera de los EE.UU. sólo está permita la utilización del algoritmo
conclaves menores o iguales a 512 bits.
El algoritmo utiliza las siguientes claves:
· Como públicas dos números grandes elegidos por un programa: e y n.
· Como privada un número grande d, consecuencia de los anteriores.
El cálculo de estas claves se realiza en secreto en la máquina depositaria de la privada.
Este proceso tiene mucha importancia para la posterior seguridad del sistema. El proceso es el siguiente:
1. Se buscan dos número grandes (entre 100 y 300 dígitos) y primos: p y q.
2. Se calcula f = (p-1) * (q-1) y n = p * q.
3. Se busca e como un número sin múltiplos comunes a f.
4. Se calcula d = e-1 mod f. (mod = resto de la división de enteros).

4. 5. Se hace públicas las claves n y e, se guarda d como clave privada y se destruyen p, q y f.
Mediante “prueba y ensayo” es muy difícil calcular d ya que es un número de 512 bits o más. Así el
sistema de criptoanálisis utilizado es buscar la clave privada d a partirde las públicas e y n. Para
esto basta con encontrar los números p y q, estos son la descomposición en factores primos de n, ya que n
= p * q. No se ha descubierto aún ninguna forma analítica de descomponer números grandes en factores
primos.
5.- ¿Qué son las firmas digitales?
Una firma digital es un esquema matemático que sirve para demostrar la autenticidad de un mensaje
digital, que puede ser por ejemplo un documento electrónico. Una firma digital da al destinatario seguridad
de que el mensaje fue creado por el remitente (autenticidad de origen), y que no fue alterado durante la
transmisión (integridad). La firma digital consiste en un método criptográfico que asocia la identidad de una
persona o de un equipo informático, al mensaje o documento. En función del tipo de firma, puede además
asegurar la integridad del documento o mensaje.
El proceso de firma consiste en cifrar una cadena de texto llamada digesto, que es
confeccionadautilizando funciones que resumen un texto a una cadena de caracteres de longitud fija
predeterminada.
6.- ¿Cómo configurar un servidor de autenticación?
Instale el paquete LDAP necesario
Primero, debería asegurarse de tener los paquetes apropiados en ambos, el servidor LDAP y las máquinas
cliente LDAP. El servidor LDAP requiere el paquete openldap-server.
Los paquetes openldap, openldap-clients, y nss_ldap necesitan estar instalados en todas las máquinas
LDAP clientes.
Modifique los archivos de configuración
En el servidor, modifique el archivo /etc/openldap/slapd.conf en el servidor LDAP para asegurarse de que
se corresponde con las especificaciones de su organización. Por favor refiérase a Sección 13.6.1 para
instrucciones sobre la modificación de slapd.conf.
En las máquinas clientes, ambos archivos /etc/ldap.conf y /etc/openldap/ldap.conf necesitan contener el
servidor apropiado y la información base de búsqueda para la organización.
Para hacer esto, ejecute la Herramienta de configuración de autenticación (system-config-authentication) y
seleccione Activar soporte LDAP bajo la pestaña Información de usuario.
También puede editar estos archivos manualmente.
En las máquinas clientes, el archivo /etc/nsswitch.conf debe ser editado para usar LDAP.
Para hacer esto, ejecute la Herramienta de configuración de autenticación (system-config-authentication) y
seleccione Activar soporte LDAP bajo la pestaña Información de usuario.
Si está modificando el archivo /etc/nsswitch.conf manualmente, agregue ldap a las líneas adecuadas.
Por ejemplo: passwd: files ldap
shadow: files ldap
group: files ldap

5. 13.7.1. PAM y LDAP
Para tener aplicaciones PAM estándar utilice LDAP para la autenticación, ejecutando la Herramienta de
configuración de autenticación (system-config-authentication) y luego seleccionando Activar soporte LDAP
bajo la pestaña Autenticación. Para más información sobre la configuración de PAM, consulte el Capítulo
16 y las páginas del manual de PAM .
13.7.2. Migrar la información de autenticación antigua al formato LDAP
El directorio /usr/share/openldap/migration/ contiene un conjunto de scripts de shell y Perl para la migración
de información de autenticación en el formato LDAP.
Primero, modifique el archivo migrate_common.ph para que refleje el dominio correcto. El dominio DNS por
defecto debería ser modificado desde su valor por defecto a algo como lo siguiente:
$DEFAULT_MAIL_DOMAIN = "example";
La base por defecto también debería ser modificada, para que se parezca a: $DEFAULT_BASE =
"dc=example,dc=com";
La tarea de migrar una base de datos de usuario a un formato que pueda leer LDAP le corresponde a un
grupo de scripts de migración instalado en el mismo directorio. Usando la Tabla 13-1, decida cúal script va
a ejecutar para poder migrar su base de datos de usuario.
Ejecute el script apropiado basándose en el nombre del servicio actual.
Los archivos README y migration-tools.txt en el directorio /usr/share/openldap/migration/ dan más detalles
sobre cómo migrar la información.
Nombre del servicio actual ¿Está LDAP ejecutándose? Utilice este script
/etc archivos planos si migrate_all_online.sh
/etc archivos planos no migrate_all_offline.sh
NetInfo si migrate_all_netinfo_online.sh
NetInfo no migrate_all_netinfo_offline.sh
NIS (YP) si migrate_all_nis_online.sh
NIS (YP) no migrate_all_nis_offline.sh
7.- Explique como configurar apache con ssl
Requisitos.
Es necesario disponer de una dirección IP pública para cada sitio de red virtual que se quiera configurar
con soporte SSL/TLS. Debido a la naturaleza de los protocolos SSL y TLS, no es posible utilizar múltiples
sitios de red virtuales con soporte SSL/TLS utilizando una misma dirección IP. Cada certificado utilizado
requerirá una dirección IP independiente en el anfitrión virtual.
El paquete mod_ssl instala el archivo /etc/httpd/conf.d/ssl.conf, mismo que no es necesario modificar,
puesto que se utilizarán archivos de inclusión, con extensión *.conf, dentro del directorio /etc/httpd/conf.d/,
a fin de respetar la configuración predeterminada y podre contar con la misma, que es funcional, brindando
un punto de retorno en el caso de que algo saliera mal.
Equipamiento lógico necesario.
Instalación a través de yum.Si se utiliza de CentOS 5 o 6, o bien Red Hat Enterprise Linux 5 o 6, ejecute
lo siguiente:
yum -y install mod_ssl
Procedimientos.
Generando firma digital y certificado.
Acceda al sistema como el usuario root.
Acceda al directorio /etc/pki/tls/.

6. cd /etc/pki/tls
En caso de que existieran previamente, debe eliminar los archivos certs/dominio.tld.crt,
certs/dominio.tld.crs, private/dominio.tld.key y private/dominio.tld.pem.
rm -f certs/dominio.tld.crt private/dominio.tld.key
rm -f certs/dominio.tld.csr private/dominio.tld.pem
Se debe crear una clave con algoritmo RSA de 2048 octetos y estructura x509, la cual se cifra utilizado
Triple DES (Data Encryption Standard), almacenado en formato PEM de modo que sea interpretable como
texto ASCII. se solicitará una clave de acceso para asignar a la firma digital, por lo que se recomienda
utilizar una muy buena clave de acceso, la cual, mientras más complicada y difícil sea, mejor.
openssl genrsa -des3 -out private/dominio.tld.key 2048
Si se utiliza este archivo (dominio.tld.key) para la configuración del anfitrión virtual, se requerirá de
interacción del administrador cada vez que se tenga que iniciar, o reiniciar, el servicio httpd, ingresando la
clave de acceso de la firma digital. Este es el procedimiento más seguro, sin embargo, debido a que
resultaría poco práctico tener que ingresar una clave de acceso cada vez que se inicie el servicio httpd,
resulta más conveniente generar una firma digital RSA, la cual permita iniciar normalmente y sin interacción
alguna, al servicio httpd.
openssl rsa -in private/dominio.tld.key -out private/dominio.tld.pem
El archivo dominio.tld.pem será el que se especifique más adelante como valor del parámetro
SSLCertificateKeyFile en la configuración de Apache.
A continuación, genere el archivo CSR (Certificate Signing Request), el cual es el archivo de solicitud que
se hace llegar a una RA (Registration Authority o Autoridad de Registro), como Verisign, quienes, tras el
correspondiente pago, envían de vuelta un certificado (para ser utilizado como el archivo dominio.tld.crt)
firmado por dicha autoridad certificadora.
openssl req -new -key private/dominio.tld.key -out certs/dominio.tld.csr
Lo anterior solicitará se ingresen varios datos:
Código de dos letras para el país.
Estado o provincia.
Ciudad.
Nombre de la empresa o razón social.
Unidad o sección.

7. Nombre del anfitrión. Debe ser el nombre con el que se accederá hacia el servidor, y dicho nombre
deberá estar resuelto en un DNS. SI lo desea, puede utilizar también *.dominio.tld.
Dirección de correo electrónico válida del administrador del sistema.
De manera opcional se puede añadir otra clave de acceso y nuevamente el nombre de la empresa.
Poco recomendado, a menos que quiera ingresar ésta cada vez que se inicie o reinicie el servicio
httpd.
La salida devuelta sería similar a la siguiente:
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or
a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:MX
State or Province Name (full name) [Berkshire]:Distrito Federal
Locality Name (eg, city) [Newbury]:Mexico
Organization Name (eg, company) [My Company Ltd]:Empresa, S.A. de C.V.
Organizational Unit Name (eg, section) []:Direccion Comercial
Common Name (eg, your name or your server's hostname) []:*.dominio.tld
Email Address []:webmaster@dominio.tld
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Si requiere un certificado auto-firmado, en lugar de un certificado firmado por un RA, puede generarse
éste utilizando el archivo de petición CSR (dominio.tld.csr). En el ejemplo a continuación, se crea un
certificado con estructura X.509 en el que se establece una validez por 730 días (dos años).
openssl x509 -req -days 730 -in certs/dominio.tld.csr -signkey private/dominio.tld.key -out
certs/dominio.tld.crt
Con la finalidad de que sólo el usuario root pueda acceder a los archivos creados, se deben cambiar los
permisos de éstos a sólo lectura para root.
chmod 400 private/dominio.tld.key private/dominio.tld.pem
chmod 400 certs/dominio.tld.csr certs/dominio.tld.crt
Configuración simple de Apache para un solo dominio.
Edite el archivo /etc/httpd/conf.d/ssl.conf:
vim /etc/httpd/conf.d/ssl.conf
Localice lo siguiente:
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.

8. SSLCertificateFile /etc/pki/tls/certs/localhost.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
Cambie localhost.crt y localhost.key, por dominio.tld.crt y dominio.tld.pem:
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/dominio.tld.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/dominio.tld.pem
A fin de que surtan efecto los cambios, es necesario reiniciar el servicio httpd.
service httpd restart
Lo anterior deberá de proceder sin solicitar la clave de acceso de la firma digital (la que asignó cuando se
creo dominio.tld.key). En caso contrario, significa que estableció dominio.tld.key como valor del
parámetro SSLCertificateKeyFile en la configuración de Apache.
Configuración de Apache para múltiples dominios.
Omita el procedimiento anterior.
Es importante resaltar que cada dominio deberá contar con su propia dirección IP, pues el protocolo
HTTPS impedirá utilizar más de un certificado por dirección IP.
El primer paso consiste en crear la estructura de directorios para el anfitrión virtual.
mkdir -p /var/www/dominio.tld/{cgi-bin,html,logs,etc}
De todos directorios creados, sólo /var/www/dominio.tld/html, /var/www/dominio.tld/etc y
/var/www/dominio.tld/cgi-bin pueden pertenecer a un usuario sin privilegios, quien administrará este
anfitrión virtual.
Crear el archivo /etc/httpd/conf.d/dominio.conf:
vim /etc/httpd/conf.d/dominio.conf
Adaptar la siguiente plantilla como contenido de este archivo, donde a.b.c.d corresponde a una dirección
IP, y dominio.tld corresponde al nombre de dominio a configurar para el anfitrión virtual:
### dominio.tld ###
NameVirtualHost a.b.c.d:80
<VirtualHost a.b.c.d:80>
ServerAdmin webmaster@dominio.tld

9. DocumentRoot /var/www/dominio.tld/html
ServerName www.dominio.tld
ServerAlias dominio.tld
Redirect 301 / https://www.dominio.tld/
CustomLog logs/dominio.tld-access_log combined
Errorlog logs/dominio.tld-error_log
</VirtualHost>
NameVirtualHost a.b.c.d:443
<VirtualHost a.b.c.d:443>
ServerAdmin webmaster@dominio.tld
DocumentRoot /var/www/dominio.tld/html
ServerName www.dominio.tld
ScriptAlias /cgi-bin/ /var/www/dominio.tld/cgi-bin/
<Directory "/var/www/dominio.tld/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite
ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/pki/tls/certs/dominio.tld.crt
SSLCertificateKeyFile /etc/pki/tls/private/dominio.tld.pem
SetEnvIf User-Agent ".*MSIE.*"
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
CustomLog logs/dominio.tld-ssl_request_log
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x "%r" %b"
Errorlog logs/dominio.tld-ssl_error_log
TransferLog logs/dominio.tld-ssl_access_log
LogLevel warn
</VirtualHost>
A fin de que surtan efecto los cambios, es necesario reiniciar el servicio httpd.
service httpd restart
Lo anterior deberá de proceder sin solicitar la clave de acceso de la firma digital (la que asignó cuando se
creo dominio.tld.key). En caso contrario, significa que estableció dominio.tld.key como valor del
parámetro SSLCertificateKeyFile en la configuración de Apache.
Comprobación.
Sólo basta dirigir cualquier navegador HTTP hacia https://www.dominio.tld/ a fin de verificar que todo
esté trabajando correctamente. Tras aceptar el certificado, en el caso de que éste no haya sido firmado por
un RA, deberá poderse observar un signo en la barra de estado del navegador, el cual indica que se trata
de una conexión segura.
Modificaciones necesarias en el muro cortafuegos.
Si se utiliza un cortafuegos, es necesario abrir, además del puerto 80 por TCP (HTTP), el puerto 443 por
TCP (HTTPS).
Si utiliza Shorewall, edite el archivo /etc/shorewall/rules:
vim /etc/shorewall/rules
Las reglas corresponderían a algo similar a lo siguiente:

10. #ACTION SOURCE DEST PROTO DEST SOURCE
# PORT PORT(S)1
ACCEPT all fw tcp 80,443
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Al terminar de configurar las reglas para Shorewall, reinicie el muro cortafuegos, ejecutando el siguiente
mandato:
service shorewall restart
8.- ¿Que es un certificado y como se obtiene uno?
El Certificado Digital es un Documento Digital que nos permite :
Identificarnos.
Firmar digitalmente un Documento Digital.
Trabajar con Documentos Digitales firmados digitalmente teniendo certeza respecto del remitente y
el destinatario.
Efectuar transacciones de tipo comercial con total seguridad y sustento legal.
Mantener la confidencialidad de la información entre el Remitente y el Destinatario utilizando cifrado.
Estar seguros de que un Documento Digital no ha sido alterado.
En síntesis, la utilización de Certificados Digitales garantiza Autentificación, Integridad, Confidencialidad,
No Repudio.
A la Entidad que otorga Certificados Digitales se la llama Autoridad de Certificación.
Es un Documento Digital emitido por una Autoridad de Certificación a solicitud de una Autoridad de
Registro que garantiza la veracidad de los datos contenidos referentes a una persona física o jurídica.
El Certificado Digital está compuesto de 2 partes. Una de ellas es Privada (Porción Privada) y la otra parte
es Pública (Porción Pública). (Ver el tema : ¿Cómo es un Certificado Digital?)
Estas dos partes son generadas en el mismo momento por el usuario ejecutando un programa provisto por
la Autoridad de Certificación desde su sitio en la web (www.certificadodigital.com.ar).
Según qué datos están verificados por la Autoridad de Registro y cual fue el procedimiento de verificación,
se otorgan diferentes Clases de Certificado Digital.
Podemos encontrar que los Certificados Digitales también se utilizan, entre otras cosas, para :
Verificar autenticidad de un Sitio Web.
Verificar autenticidad e integridad de un programa de computación.
Verificar el Momento en que fue firmado o enviado un Documento Digital
Órgano Licenciante
Es el organismo del Estado que habilita a una Empresa de Certificación Digital como Autoridad de
Certificación.
Entidad Auditante
Es la Entidad que ha sido designada para efectuar la Auditoría y Control de la Autoridad de Certificación.
Autoridad de Certificación
La Autoridad de Certificación es responsable de brindar las herramientas para poder emitir, con calidad
técnica y de manera segura e irrepetible por otros medios o en otras circunstancias, el par de claves,
pública y privada, que constituye el eje del certificado, así como de :
Aprobar o Rechazar las Solicitudes generadas por la Autoridad de Registro.
Poner a salvo su propia clave privada (Clave Privada Raíz) que es la que utiliza para aprobar las
Solicitudes.
Garantizar la calidad técnica del sistema informático.
Proveer el libre y fácil acceso a las listas y directorios de claves públicas para la verificación de
firmas emitidas por lamisma.

11. Publicar las Claves Públicas que ha aprobado y las Revocaciones de Certificados Digitales que ha
realizado.
La potestad para Emitir Certificados Digitales le es concedida por el Órgano Licenciante y la calidad del
servicio es controlada por una Entidad Auditante.
En nuestro país este esquema ya está siendo usado en el Ámbito Público del Estado, sin embargo las
leyes que regulan la actividad privada están en vías de promulgación.
Es por ello que en el Ámbito Privado se aplica actualmente la legislación que rige el Acuerdo de Partes.
Autoridad de Registro
La Autoridad de Registro es responsable de realizar la identificación de la persona física o jurídica en
forma fehaciente y completa, debe efectuar los trámites con fidelidad a la realidad.
Además es quien se encarga de solicitar la Aprobación, y/o Revocación de un Certificado Digital.
Su objetivo primario es asegurarse de la veracidad de los datos que fueron utilizados para solicitar el
Certificado Digital.
9.- Explique paso a paso como configurar RADIUS
Una vez preparada la máquina para la compilación, podremos ir al directorio en el que se ha
descomprimido (“cd freeradius-server-2.1.1”). El proceso básico de la instalación se encuentra descrito en
el fichero de texto INSTALL (lo puedes editar usando gedit). En primer lugar, debemos hacer una operación
de configuración. Mediante la orden “./configure --help” podemos ver las opciones disponibles, nosotros
usaremos las opciones por defecto.
Una vez configurado el proceso, realizaremos la compilación mediante “make”, y posteriormente, si no ha
ocurrido ningún error, instalaremos el software en el sistema mediante “make install” como superusuario.
Si el proceso es correcto, ya podremos ejecutar el servidor. Sin embargo, como la primera vez que se
ejecute el servidor se crearán los certificados necesarios para operar con EAP, antes de esta primera
ejecución es conveniente que configuremos estos certificados con los atributos que más se ajusten a
nuestra instalación.
En concreto la configuración de los certificados se puede realizar editando los ficheros de configuración que
se encuentran en /usr/local/etc/raddb/certs. Aquí podremos editar la configuración de los certificados de la
autoridad certificadora (fichero ca.cnf), los usados como servidor (server.cnf), y los de cliente (client.cnf).
Los atributos a configurar son el país, provincia, localidad, organización, dirección de correo electrónico y
nombre común. Observa que para su correcto funcionamiento, el servidor y la autoridad certificadora deben
coincidir en país, estado y organización.
Una vez configurados los certificados, ya podremos ejecutar el servidor (como root), mediante la orden
“radiusd –X” (la X se utiliza para funcionar en modo debug, y así recibir información sobre los eventos que
se suceden en el servidor). Tal y como hemos dicho previamente, la primera vez que se ejecute el servidor
se crearán los certificados necesarios. Si todo va bien, el servidor debe quedarse escuchando en los
puertos asociados a los servicios que ofrece.
Para comprobar que el servidor está funcionando correctamente, podremos hacer uso de la herramienta
“radtest” como root, de la siguiente manera:
$ radtest usuario contraseña localhost 10 testing123
donde “usuario” y “contraseña” son las credenciales de un usuario local de la máquina. “tesing123” es lo
que se denomina un secreto, que permite asociar de manera segura un cliente al servidor. Este cliente ya
está configurado en la máquina, tal y como veremos posteriormente, por tanto, y si todo es correcto la
respuesta debe ser “Access-Accept”.
4.3 Configuración básica del servidor
La configuración del servidor se hace mediante el fichero “radiusd.conf” del directorio /usr/local/etc/raddb.
Aquí podemos seleccionar aspectos relacionados con el servidor (ficheros de log, parámetros de uso

12. máximo, usuarios, grupos, …), bases de datos a utilizar para autenticar y autorizar (ficheros, SQL, LDAP,
…), métodos de AAA.
Para evitar una excesiva longitud de este fichero y por cuestiones de organización, “radiusd.conf” se
subdivide en varios ficheros mediante la directiva “$INCLUDE”:
 eap.conf: Se utiliza para configurar el tipo de EAP a emplear
 clients.conf: Tien la lista de clientes que están autorizados para usar los servicios de AAA
e
proporcionados.
 proxy.conf: Este fichero configura directivas relacionadas con el funcionamiento en modo proxy y la lista
de realms.
 Otros ficheros como sql.conf (para config urar el acceso a bases de datos SQL), policy.conf, etc.
Además, el fichero “users” contiene información sobre la autenticación de suplicantes, de forma que incluso
podemos añadir credenciales en forma de usuario y contraseña para permitir una configuración sencilla de
usuarios (ten en cuenta que estos usuarios serán realmente clientes del NAS, y no directamente del
servidor RADIUS).
Como vamos a trabajar con suplicantes bajo Windows XP, configurados como en hemos visto previamente
para eduroam en la UPV, vamos a necesitar soporte de PEAP y mschapv2. Para esto editamos el fichero
eap.conf, y cambiamos el atributo “default_eap_type” general, de “md5” a “peap” (en minúsculas), y en el
apartado de peap asegúrate de que “default_eap_type” esté a “mschapv2”. En principio, si usamos la
versión 2.1.1 de Radius no deberíamos necesitar cambiar nada más en este fichero, ya que la parte de
“peap” está descomentada por defecto.
A continuación tenemos que informar al servidor RADIUS de que va a tener como cliente un punto de
acceso. Para ello, editamos el fichero clients.conf, y añadimos las siguientes líneas:
client 192.168.1.1 {
secret = secretotra
shortname = ap
nastype = cisco
}
Fíjate que el punto de acceso va a tener como dirección IP por defecto “192.168.1.1”, por la configuración
del propio punto de acceso que vamos a emplear, y que como secreto para la configuración posterior de
NAS e el punto de acceso usaremos “secretotra” 12
10.- Explique paso a paso como configurar Linux centos 5 o superior las jaulas chroot
Para empezar como usuario root ejecuta la siguiente sintaxis, la cual instalara los paquetes
correspondientes al servidor DNS;
yum install -y bind bind-chroot bind-libs bind-utils caching-nameserver
Archivo de configuración
Abra el fichero hosts que se encuentra ubicado en la ruta /etc/hosts. En donde se ingresara la dirección IP
del servidor de ejemplo; 192.168.5.119 y el dominio ficticio de nombre dns1.grupo7vesp.edu. luego de
haber ingresado los campos correspondientes en el archivo cerrarlo y guardar los cambios.
Abrir el archivo o fichero network que se encuentra en la ruta;
/etc/sysconfig/network

13. En el parámetro HOSTNAME se declara el nombre de dominio del servidor que desempeña la función de
servicio DNS en nuestro caso sustituiremos localhost.localdomain por dns1.grupo7vesp.edu.
Cree en la jaula chroot los ficheros de zonas, los cuales serán invocados por el fichero named.conf;
touch /var/named/chroot/var/named/grupo7vesp.edu.zone
Ahora el archivo de zona inversa;
touch /var/named/chroot/var/named/5.168.191.in-addr-arpa.zone
Edite el fichero de zona de nombre grupo7vesp.edu.zone (recuerde que se encuentra en la ruta
/var/named/chroot/var/named/grupo7vesp.edu.zone);
Edite el fichero de zona inversa 5.168.191.in-addr.arpa.zone (recuerde que se encuentra en la ruta
/var/named/chroot/var/named/5.168.191.in-addr-arpa.zone);
Donde; los equipos clientes , pertenecen a partir de las direcciones IP´s 192.168.5.120 a 192.168.5.126.
Nota: En el parámetro NS (Name Server) de ambos archivos de zonas puede ingresar los servidores DNS
de su Proveedor de Servicio de Internet (I.S.P), así;
NS ServidorDNS1.com
NS ServidorDNS2.com
Cree el fichero named.conf, ejecutando la siguiente sintaxis;
touch /var/named/chroot/etc/named.conf
Asigne los permisos de propietario y grupo root:named al fichero named.conf y con permisos 644;
chown root:named named.conf
chmod 644 named.conf
Posteriormente edite y configurar el archivo named.conf;
vim /var/named/chroot/etc/named.conf
Volcar el contenido del archivo configuración de ejemplo de nombre named.rfc1912.zones ubicado en
/var/named/chroot/etc;
cat /var/named/chroot/etc/named.rfc1912.zones >> /var/named/chroot/etc/named.conf
Agregar la configuración de las dos zonas creadas con anterioridad en el named.conf ;