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.

Otros ejemplo sobre una firewall a nivel de red es el mostrado en la figura anterior.En este ejemplo se representa una firewall a nivel de red llamada "screened subnet firewall". En dicha firewall se accede a y desde el conjunto de la red, la cual es controlada por un router operando a nivel de red. Es similar al firewall indicada en 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 permiten trá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 entra por un extremo hasta que sale por el otro. Las primeras firewalls a nivel de aplicación eran poco transparentes a los usuarios finales, pero las modernas firewalls a nivel de aplicación son bastante transparentes. Las firewalls a nivel de aplicación, tienden a proporcionar mayor detalle en los informes auditados e implementan modelos de conservació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 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 con claves 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).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 partir de 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 confeccionada utilizando 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 ldapshadow: files ldapgroup: files ldap

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.shNetInfo si migrate_all_netinfo_online.shNetInfo no migrate_all_netinfo_offline.shNIS (YP) si migrate_all_nis_online.shNIS (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/.

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.

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 beincorporated into your certificate request.What you are about to enter is what is called a Distinguished Name ora DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [GB]:MXState or Province Name (full name) [Berkshire]:Distrito FederalLocality Name (eg, city) [Newbury]:MexicoOrganization Name (eg, company) [My Company Ltd]:Empresa, S.A. de C.V.Organizational Unit Name (eg, section) []:Direccion ComercialCommon Name (eg, your name or your server's hostname) []:*.dominio.tldEmail Address []:webmaster@dominio.tldPlease enter the following 'extra' attributesto be sent with your certificate requestA 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.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.tldDocumentRoot /var/www/dominio.tld/htmlServerName www.dominio.tldServerAlias dominio.tldRedirect 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.tldDocumentRoot /var/www/dominio.tld/htmlServerName www.dominio.tldScriptAlias /cgi-bin/ /var/www/dominio.tld/cgi-bin/<Directory "/var/www/dominio.tld/cgi-bin">

SSLOptions +StdEnvVars</Directory>SSLEngine onSSLProtocol all -SSLv2SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:

+MEDIUM:+LOWSSLCertificateFile /etc/pki/tls/certs/dominio.tld.crtSSLCertificateKeyFile /etc/pki/tls/private/dominio.tld.pemSetEnvIf 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_logTransferLog logs/dominio.tld-ssl_access_logLogLevel 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:#ACTION SOURCE DEST PROTO DEST SOURCE# PORT PORT(S)1ACCEPT 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 LicencianteEs el organismo del Estado que habilita a una Empresa de Certificación Digital como Autoridad de Certificación.Entidad AuditanteEs la Entidad que ha sido designada para efectuar la Auditoría y Control de la Autoridad de Certificación.Autoridad de CertificaciónLa 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 la misma. 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 RegistroLa 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 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: Tiene la lista de clientes que están autorizados para usar los servicios de AAA 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 configurar 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 chrootPara 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-nameserverArchivo de configuraciónAbra 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

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.zoneAhora 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.comNS ServidorDNS2.comCree el fichero named.conf, ejecutando la siguiente sintaxis;touch /var/named/chroot/etc/named.confAsigne los permisos de propietario y grupo root:named al fichero named.conf y con permisos 644;chown root:named named.confchmod 644 named.confPosteriormente edite y configurar el archivo named.conf;vim /var/named/chroot/etc/named.confVolcar 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.confAgregar la configuración de las dos zonas creadas con anterioridad en el named.conf ;