Lista

#Tipo de sistema de ficheros en Linux: tipo ext3 (en Microsoft es tipo NTFS) #Árbol de directorios en Linux: #(Explicación del contenido de cada directorio en el libro de texto, páginas 46 a 51) #(Libro de texto: Membrey, P. & Verhoeven, T. & Angenendt, R. (2010). The Definitive Guide to CentOS. New #York: Apress.) / /root /etc /proc /var /boot /bin /sbin /dev /home /lib /lost+found /media /mnt /usr /opt /srv /sys /tmp *******COMANDOS BÁSICOS.*************************************** uname información del sistema Ejemplos uname -a hostname indicar el nombre del equipo clear limpiar la pantalla man manual de comandos Ejemplos: man su startx arrancar interfaz gráfica de Linux (GNOME o KDE) exit salir del terminal cd cambiar directorio Ejemplos: cd # ir al directorio del usuario cd ~ # ídem cd - # regresar al último directorio cd . #cambiarse al directorio actual cd .. #cambiarse al directorio padre del directorio actual pwd imprimir información del directorio actual de trabajo (print working directory) mkdir make directory: crear directorios Ejemplos: mkdir -p /etc/Wireless/RT61STA # crea el directorio RT61STA y sus padres, si no existían rmdir remove directory: eliminar directorios vacíos ls list directory contents (En UNIX, los archivos no dependen de su extensión, sino de sus permisos) Ejemplos: ls -ahl ls -R ls / -R ls -hd ls -ld lspci lista los dispositivos pci conectados update-pciids descargar e instalar la actual versión del archivo pci.ids disponible en el sitio primario de la distribución de Linux lsusb lista los dispositivos usb conectados redireccionamiento | (=usar la salida de un comando como entrada de otro comando), ``(=escribir un comando como parámetro de otro comando), > (grabar en), > (= apendizar a), Administración->Configuración de Servidores->Servicios->Servicios bajo Demanda 3)Permitir en el firewall el puerto de Telnet Demonio asociado: /etc/init.d/xinetd.d Archivos de configuracion: /etc/xinetd.d/telnet /etc/xinetd.conf /etc/securetty (Para iniciar automáticamente el servidor telnet, poner en "no" la variable "disable" del archivo /etc/xinetd.d/telnet ) (para reiniciar el demonio xinetd: /etc/xinetd reload) (Para permitir al usuario root hacer telnet, debe editar el archivo /etc/securetty y apendizar: pts/0 pts/1 pts/2 pts/3 Esto permite hasta 4 sesiones de telnet para el usuario root.) Nota1: pts significa "pseudo-terminal slave". Nota2: tty significa teletypewriter. ssh

Secure Shell remote login program (programa de registro remoto y seguro en el shell del S.O.) Usa el puerto TCP 22. CONTIENE: Un demonio: sshd (Demonio: Programa que se ejecuta en modalidad desatendida y efectúa funciones continuadas o periódicas en todo el sistema.) Tres programas: ssh = sesión remota criptográficamente segura entre host y cliente scp = copia de archivos criptográficamente segura entre host y cliente sftp = transferencia de archivos criptográficamente segura entre host y cliente FUNCIONAMIENTO: Son verificados el nombre y la clave pública del host a conectar, mediante la huella digital de la clave pública del host, que es una suma de verificación de la clave pública. Si la verificación es exitosa, se establece un canal seguro entre cliente y host, mediante una clave de sesión basada en las claves públicas de cliente y host. Esta clave de sesión es una clave para cifrado de datos entre host y cliente, y es igual en ambos extremos. Las claves de sesión pueden usar los protocolos de cifrado 3DES, Blowfish o IDEA. Después de establecer el canal seguro, el usuario en el cliente es preguntado por sus credenciales: username y password. PARES DE CLAVES PÚBLICA/PRIVADA RSA o DSA: criptografía ASIMÉTRICA, criptografiar, autenticar y no repudiar (= confirmar que un mensaje no ha cambiado desde su creación). (RSA= Rivest-Shamir-Adleman)

(DSA= Digital Signature Algorithm, ¡ES MÁS FUERTE QUE RSA porque no trabaja con números primos sino con logaritmos, el algoritmo es más complejo!) El host debe conocer la clave pública del cliente, el cliente produce una cadena (= string) cifrada a partir de su clave privada, si el host puede descifrar esa cadena cifrada a partir de la clave pública del cliente, la identidad del cliente es autenticada. El cliente escoge el algoritmo de cifrado que usará, RSA o DSA. La clave privada del cliente debe ser protegida con una frase de paso (= passphrase). CONFIGURACIÓN: cualquier nudo puede ser cliente y host ssh a la vez Archivo de configuración de host: /etc/ssh/sshd_config (MÁS FÁCIL) Archivo de configuración de cliente: /etc/ssh/ssh_config (MÁS COMPLICADO) Un usuario puede ignorar este archivo y usar: /home/Mi_directorio/.ssh/ssh_config (PARA MÁS DETALLES SOBRE CONFIGURACIÓN Y FUNCIONAMIENTO DE SSH, VER: "Beginning the Linux Command line", Sander van Vugt, pp. 266-271) Ejemplos ssh -l root servidor.com #conexión segura al servidor servidor.com con el usuario root ssh [email protected] #ídem ssh [email protected] ls /etc #conexión segura para listar el contenido del dir. /etc (para cerrar la sesión, escribir exit o pulsar CTRL+D) ls -ahl ./.ssh ls -ahl /etc/ssh ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key # conocer la clave pública RSA para ssh de un host #para registrar la propia clave pública en un servidor y que no nos pida password: #en el cliente incorporar los siguientes comandos: (EJEMPLO PARA EL USUARIO root): ssh-keygen -t dsa -b 1024 # crear un par de claves DSA pública/privada de 1024 bits scp /root/.ssh/id_dsa.pub root@host:/root/miclave.dsa.pub #en el host incorporar los siguientes comandos: mkdir -p /root/.ssh #sólo si no existe este directorio cd /root ls -ahld .ssh #comprobar permisos, propietario y grupo de .ssh chmod 700 .ssh #asegurarse de que solamente el usuario, en este caso root, tenga permisos chown root .ssh chgrp root .ssh cat miclave.dsa.pub >> /root/.ssh/authorized_keys #Finalmente, desde el cliente, acceder a una sesión ssh, sólo nos pedirá el "passphrase". #Para evitar incorporar la passphrase cada vez que establezcamos una sesión, se la puede incorporar una vez en la memoria RAM local antes de iniciar sesiones ssh: ssh-agent /bin/bash ssh-add #Repetir el procedimiento con cada host con el que deseemos sesiones seguras. ssh-keygen scp

sftp ftp

vncviewer

generar nuevas claves pública/privada para ssh (como descrito anteriormente) copia segura de archivos Usa el puerto TCP 22. Ejemplos: scp [email protected]:/etc/resolv.conf ./copia_de_seguridad/etc/resolv.conf scp -r [email protected]:/etc ./copia_de_seguridad/etc #copia /ect y subdirectorios Transferencia segura de archivos (ver "Beginning the Linux Command line", Sander van Vugt, p. 265) Usa el puerto TCP 22. (No confundir con Simple File Transfer Protocol, en el puerto TCP 115 y que ya no se usa.) Transferencia insegura de archivos Usa el puerto TCP 21. Demonio asociado: /etc/init.d/xinetd.d (Para iniciar automáticamente el servidor ftp, poner en "no" la variable "disable" del archivo /etc/xinetd.d/wu-ftpd ) Hacer control remoto completo de servidores y PCs. USA EL PROTOCOLO RFB. Usa el puerto TCP 5900, y en formato WEB el puerto TCP 5800. Pasos para el funcionamiento de VNC en Centos: -instalar servidor de VNC (vncserver) con yumex -activar el servicio-demonio de VNC en Sistema->Administración->Configuración de Servidores->Servicios -instalar cliente visor (viewer) de VNC con yumex -permitir en el firewall el puerto 5900: hacerlo en Sistema->Administración->Nivel de seguridad y cortafuegos->Otros puertos->Añadir -habilitar el acceso a escritorio remoto en el servidor donde está instalado el vncserver: ir a Sistema->Preferencias->Escritorio Remoto (Tiene versión para usarla desde el i-phone.) Ejemplos vncviewer 10.2.4.1:0 #el :0 indica el número de display

*************************** DNS ****************************** 1. Razones para usar DNS: ¿Quién usa qué nombre de host? ¿Qué nombres de host son apropiados? ¿Cómo registramos todos los nombres de host de todas las redes? ¿Manualmente? ¿Cómo distribuimos una copia de los nombres a quien lo solicite? ¿Cómo mantenemos actualizada la lista de nombres si hay cambios? ¿Manualmente? SOLUCIONES: Microsoft Wins, SUN NIS, DNS 2. Conceptos importantes en DNS: -DNS Tree (= árbol DNS) Ejemplo: pág. 158 del libro de texto -ROOT (= raíz del árbol DNS) -DOMAIN (=DOMINIO = conjunto de nudos asociados por vínculos comunes) -ZONE (= ZONA = entidad organizacional gestionada por un servidor DNS) Hay 2 tipos básicos de zonas -de avance (FORWARD ZONE: búsqueda de direcciones IP a partir de nombres DNS) -inversas (REVERSE ZONE: búsqueda de nombres DNS a partir de direcciones IP) -TLD (= top-level domains Ejemplos: Generic Top-Level Domains (gTLD): .com, .edu, .net, .org, .mil, etcétera Country Code Top-Level Domains (ccTLD): .us, .ca, .tv, .uk, etcétera. -SLD (= SUB LEVEL DOMAIN Ejemplos: ubuntu.com NOTA: Cada subdominio puede tener máximo 127 niveles de sub-subdominios) -DELEGATION (= delegar el control de un nombre y sus subdominios a la autoridad correspondiente de una organización, siempre que esta garantice que su gestión no afecte a otros nombres y sus subdominios) -LOOKUP (= buscar una dirección IP por su nombre DNS. Paralelismo con arp.) -DNS resolver (= programa en cada nudo conectado a Internet, que busca en el árbol DNS un nombre DNS y su dirección IP, desde el nudo raíz hacia bajo. El resultado sin error del lookup es la dirección IP buscada, que se pasa al programa que la solicitó.) -DNS authoritative server (= servidor DNS responsable de un dominio y con autoridad para encaminar la búsqueda de un nombre DNS y su dirección IP. Los servidores DNS autorizados del nudo raíz del árbol DNS se llaman DNS root servers.) -NAME SERVER (= servidor DNS que contiene nombres DNS y direcciones IP de una organización y sus subdominios. Es de este servidor que finalmente obtiene el RESOLVER la información que necesita para localizar un host: nombre DNS y dirección IP) -DNS server (= servidor que cumple alguna función DNS en el sistema de servidores para DNS.

En cada nudo del árbol DNS hay servidores DNS.) -DNS caching (= almacenamiento temporal de direcciones IP y nombres más solicitados) -FQDN = Fully qualified domain name = nombre que indica el lugar exacto de un nudo en la jerarquía del árbol DNS Ejemplo: www.microsoft.com. #¡Note el punto y el espacio en blanco al final! -DNS usa el protocolo UDP en el puerto 53. Si la respuesta a la consulta DNS es mayor a 512 bytes, entonces usa protocolo TCP en el puerto 53. Para tareas como transferencias de datos DNS entre zonas, también usa TCP en el puerto 53. -El DNS resolver de algunos sistemas operativos, como HP-UX, sólo usa TCP, aunque UDP sea suficiente. 3. CONFIGURACIONES PARA SER CLIENTE DE UN SERVIDOR DNS: Archivo hosts: AQUÍ PUEDE INTRODUCIR MANUALMENTE NOMBRES DNS CON SUS DIRECCIONES IP cat /etc/hosts Archivo resolv.conf: ¡AQUÍ PONER LA DIRECCIÓN IP DEL SERVIDOR DNS QUE ESTE NUDO VA A CONSULTAR! cat /etc/resolv.conf Archivo nsswitch.conf: INDICA EN QUÉ ORDEN EL NUDO CONSULTA PARA BUSCAR NOMBRES DNS cat /etc/nsswitch.conf nscd

Name Service Caching Daemon (Si no está instalado por defecto, instalarlo con yum.) NOTA: ES ÚTIL SI LA CONEXIÓN A INTERNET ES DE BAJA VELOCIDAD. NO ES ÚTIL SI LA CONEXIÓN A INTERNET ES DE ALTA VELOCIDAD y ENTONCES CONVIENE DESHABILITARLO. Ejemplos yum install nscd #actualizar el nscd (similar a "ipconfig /flushdns" en Microsoft) nscd –i hosts #lo mismo que el comando anterior pero con otra sintaxis: nscd --invalidate=hosts #iniciar el demonio de ns caching service nscd start #detener el demonio de ns caching service nscd stop #reiniciar el demonio de ns caching service nscd restart #configurar el inicio automático de nscd cada vez que inicie el S.O. chkconfig nscd on #editar el archivo de configuración de nscd cat /etc/nscd.conf

4. CONFIGURACIÓN DE SERVIDOR DNS: BIND -Berkeley Internet Name Domain: servidor de nombres, es el estándar en Unix. Usa el protocolo UDP en el puerto 53. Si la respuesta a la consulta DNS es superior a 512 bytes, usará protocolo TCP en el puerto 53. -Por SEGURIDAD TELEMÁTICA, usar siempre la última versión disponible de BIND. -Roles de servidores DNS: (un sólo servidor DNS puede simultáneamente desempeñar todos los roles) MASTER -PRIMARY NAME SERVER: servidor DNS que contiene la DOMAIN MASTER ZONE (= zona maestra del dominio = información verificada sobre el dominio). -Este servidor primario de nombres es responsable de un dominio y tiene autoridad para encaminar la búsqueda de un nombre DNS y su dirección IP. Sin embargo, no hay garantía de que sea siempre el primero en ser consultado por los usuarios. -Por lo anterior se llama también AUTHORITATIVE SERVER del dominio. -Mantiene registrada la información verificada del dominio en el archivo MASTER ZONE FILE -Si hay más de 1 servidor DNS en un dominio, el primero en ser declarado debe ser el PRIMARY NAME SERVER. Slave -SECONDARY NAME SERVER: servidor DNS que contiene una copia del MASTER ZONE FILE, que se llama SLAVE ZONE FILE. -El proceso de copia del MASTER ZONE FILE al SLAVE ZONE FILE se llama ZONE TRANSFER. -Los cambios que se efectúan en el PRIMARY NAME SERVER, también se registran en el SECONDARY NAME SERVER. -NO se debe efectuar cambios directamente en el SECONDARY NAME SERVER CACHING Almacenamiento temporal de información DNS. FORWARDING Remisión de consultas DNS si no hay información local. -Ejemplos: #instalación o actualización completa de BIND yum install bind bind-chroot bind-libs bind-utils #bind-chroot asegura el directorio de instalación de BIND contra ataques #y accesos no autorizados #instalar interfaz gráfica de gestión para BIND yum install system-config-bind #instalación de bind-sdb: yum install bind-sdb #sdb significa Simplified Database Backend, es decir, #capacidad para soportar bases alternas de datos sobre ZONAS #almacenadas en servidores LDAP (ldapdb), bases postgreSQL (pgsqldb), #bases sqlite (sqlitedb) o en el sistema de archivos (dirdb), además de hacerlo por #defecto en memoria RAM en la base RBT (Red Black Tree) zone database. #También incluye soporte para DLZ (Dynamic Loadable Zones). #instalación de caching-nameserver yum install caching-nameserver #La necesidad de un caching-nameserver se hace evidente al pensar en #las miles de consultas en Internet por nombres como www.google.com or www.facebook.com. #Así reducimos tráfico en Internet por consultas de nombres frecuentemente consultados. #Navegar en Internet puede crear miles de consultas de nombres DNS por navegador. #Además, distribuimos la carga por consultas de nombres entre varios caching-nameserver. #En su configuración es importante el parámetro TIME TO LIVE (TTL), #que indica cuánto tiempo mantendrá el caching-server información sobre nombres #recientemente consultados. NOTA: ¡¡¡ANTES DE MODIFICAR CUALQUIER ARCHIVO DE CONFIGURACIÓN, HACER UNA COPIA DE LA VERSIÓN ANTERIOR DE DICHO ARCHIVO!!!

named

Demonio del servidor de nombres DNS Ejemplos: #iniciar el demonio servidor de nombres service named start

#OJO: le presentará un error si no ha instalado antes el caching-nameserver. #determinar la versión de BIND named -v #pruebas del funcionamiento del demonio named con el comando host: #Buscar información DNS del nombre www.centosbook.com en el servidor #DNS llamado localhost: host www.centosbook.com localhost host www.ibm.com localhost host www.microsoft.com localhost #Si no indica el nombre del servidor DNS a consultar, el comando host #consultará el servidor DNS declarado en el archivo /etc/resolv.conf host www.microsoft.com #pruebas del funcionamiento del demonio named con el comando nslookup: #Buscar información DNS del nombre www.centosbook.com en el servidor #DNS llamado localhost: nslookup www.centosbook.com localhost nslookup www.ibm.com localhost nslookup www.microsoft.com localhost #Pruebas del funcionamiento del demonio named con el #comando dig (=domain information groper = contador de información de dominios): dig microsoft.com #Para ver otras opciones del comando dig: dig -h #El problema de este comando es que tiene demasiadas opciones.

USO DEL DNS CACHING-NAMESERVER: #Hacer que el servidor DNS escuche en todas sus direcciones IP, además de la #dirección de loopback y también busque en otros servidores DNS: vi /etc/named.caching-nameserver.conf #dejar como comentarios las líneas: # listen-on-port 53 { 127.0.0.1 }; #después guardar el archivo y finalmente reiniciar el servicio de BIND: service named restart #Comprobación de funcionamiento: host www.google.com www.centosbook.com #indicar a BIND que acepte consultas desde cualquier lugar: vi /etc/named.caching-nameserver.conf #dejar como comentarios también las líneas: # allow-query { localhost; }; # match-clients { localhost;}; # match-destinations {localhost;}; #después guardar el archivo y finalmente reiniciar el servicio de BIND: service named restart #Comprobación de funcionamiento: host www.google.com www.centosbook.com CONFIGURACION DE BIND COMO HOST DE DOMINIOS: #Creación de un archivo propio de configuración vi /var/named/chroot/etc/named.conf #pegar como primeras configuraciones las que aparecen en el libro de texto en la página 170: options { directory "/etc"; pid-file "/var/run/named/named.pid"; recursion no; }; #Con estas primeras configuraciones, el servidor DNS aún no está listo para funcionar. #NOTA: en la elección de nombres DNS para los nudos, escoger nombres descriptivos que faciliten #la inspección del archivo de configuración de DNS. #Buenos ejemplos de nombres: dns1, dns2, ... mail1, mail2, ... srv_uio1, srv_uio2, srv_gye1, srv_cue1, ... pc_uio1, pc_gye23, pc_iba12, ... rtr_cisco_uio1, rtr_huawei_gye3, ... #Malos ejemplos de nombres: frodo, gandalf, bilbo, ... mercurio, saturno, marte, ... hercules, afrodita, zeus, .. neron, julio, herodes, ... bolivar, sucre, ... finanzas, inventario, marketing, ... #¡UN BUEN NOMBRE PERMITE ACCEDER RÁPIDAMENTE A INFORMACIÓN BÁSICA PERO ÚTIL SOBRE UN NUDO!

#CREACIÓN DE UN MASTER ZONE FILE: #Para conocer con exhaustividad la sintaxis de un ZONE File, debe hacer la lectura completa de #las págs. 23-39 y 483-551 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress #$TTL directive: Directriz TTL (Time to Live), indica el valor por defecto del tiempo máximo que un registro puede almacenarse temporalmente o guardarse en otro servidor DNS. #Esta directriz es obligatoria. #Puede valer entre 0 y 2147483647 (= 2^31) segundos (más de 68 años). #Un TTL de 12 horas (= 43200s) es un valor promedio. #Un TTL de 2 días es razonable para zonas muy estables. #Si un registro necesita un valor TTL diferente al valor defecto $TTL, #simplemente lo indica en su configuración de registro. # Ejemplos: $TTL 2d $TTL 48h $TTL 2880m $TTL 1d24h #Más información ver págs. 27-28 y 487 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress #$ORIGIN directive: Directriz que indica el nombre del dominio para la zona que #se está definiendo. Esta directriz es opcional. #Ejemplos: $ORIGIN example.com. $ORIGIN us.example.com. $ORIGIN uio.miservidor.com.ec. #Más información ver págs. 28-29 y 484-486 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress

#SOA record (= start of authority record = registro de inicio de autoridad) #Está estandarizado en el RFC 1035. #Es el registro que primero debe aparecer en un zone file. #Describe las características globales de la zona o dominio. #Sólo puede haber 1 SOA record en un archivo de zona. #Este registro es obligatorio. #La sintaxis para declarar este registro es: name ttl class record-type name-server e-mail ( sn; número serial refresh; refresh time retry; update retry expiry; min; minimum ) #Ejemplo1: ver págs. 30-32 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress #Ejemplo2: ver págs. 540-543 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress

#A Record (= Address record = registro de dirección) #Está estandarizado en el RFC 1035. #Hace corresponder la dirección IPv4 de un host con su nombre dentro del dominio o #zona del dominio. #El equivalente en IPv6 es el AAAA Resource Record. #Más información: # -ver págs. 170 y 171 del libro de texto # -más información ver págs. 35-36 y 500-503 de # Aitchison, R. (2011). Pro DNS and BIND. New York: Apress #Sintaxis: # name ttl class rr ipv4 #Ejemplo: # ns1 IN A 192.168.254.2 # mail IN A 192.168.254.4 # joe IN A 192.168.254.6 # www IN A 192.168.254.7 # www.example.org. IN A 192.168.1.1 #Las clases posibles de los registros son IN (Internet), HS (Hesiod), CH (Chaos) y ANY. #Sus usos se encuentran descritos en las págs. 214, 219, 230, 251, 259, 497 y 597 de #Aitchison, R. (2011). Pro DNS and BIND. New York: Apress #NS record (= name server record = registro de servidor de nombres) #Está estandarizado en el RFC 1035. #Define los servidores de nombres que son responsables de un dominio y con #autoridad (= AUTHORITATIVE) para encaminar la búsqueda de un nombre DNS y su dirección IP. #Debe haber al menos 2 NS record en un zone file. #Los 2 NS record mínimos son obligatorios. #Los NS record pueden citar servidores dentro del dominio, fuera de él o en otro dominio. #Ejemplo1: example.org. IN NS dns0.example.com. ; esta declaración es incorrecta pues causa una situación catch-22 (¿por qué?) #Ejemplo2: 2 servidores DNS internos y 1 externo example.org. IN NS dns0.example.com. example.org. IN NS dns1.example.com. example.org. IN NS dns3.example.net. dns0.example.com. IN A 10.20.1.5 dns1.example.com. IN A 10.20.1.50 #Más información ver págs. 33 y 527-530 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress

#CNAME Record (= Canonical name record = registro de nombre canónico) #Nombre canónico en este contexto quiere decir nombre esperado o nombre real. #Está estandarizado en el RFC 1035. #Hace corresponder un alias de un host (o servicio en un host) #con su nombre real previamente definido en un A Record. #Más información: # -ver págs. 171 y 172 del libro de texto # -más información ver págs. 36-38 y 507-508 de # Aitchison, R. (2011). Pro DNS and BIND. New York: Apress #Sintaxis: # name ttl class rr canonical-name #Ejemplo1: #En vez de estos A records en la configuración del servidor DNS: www IN A 192.168.1.1 ftp IN A 192.168.1.1 #Podemos simplificar con un alias mediante CNAME: www IN A 192.168.1.1 ftp IN CNAME www #Así, si cambiamos la dirección IP de la máquina, no tendremos que cambiar cada registro A. #Ejemplo2: # ftp IN CNAME bill # www IN CNAME bill # bill IN A 192.168.254.21 #Ejemplo3: ftp IN CNAME ftp.example.net. #Los dos únicos casos en que es OBLIGATORIO usar un CNAME record son: # 1. Cuando el host real se encuentra fuera del dominio o en un dominio externo. ; si el dominio que estamos configurando se llama ejemplo.org ; y queremos usar el servidor de correo del dominio ejemplo.com mail IN CNAME mail.example.com NOTA: también funciona si creamos un A record en el dominio ejemplo.org con la dirección IP del servidor de correo en el dominio ejemplo.com # 2. Cuando el usuario desea poner a un sitio web simultáneamente las direcciones http://www.ejemplo.com y http://ejemplo.com, en cuyo caso la configuración correcta en DNS es: ; definir una IP que se resuelva como ejemplo.com ejemplo.com. IN A 192.168.0.3 ; ahora el alias www.ejemplo.com de ejemplo.com www IN CNAME ejemplo.com. NOTA: el servidor http también debe adaptar su configuración. Ver ejemplo completo en las págs. 177-179 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress #¡NO ABUSAR DE LOS ALIAS QUE PERMITEN LOS CNAME Records #PORQUE REDUCEN EL RENDIMIENTO DEL DNS SERVER (= el DNS debe hacer consultas de las consultas, y además puede verse forzado a cambiar de protocolo UDP a TCP debido al tamaño mayor a 512 bytes de las respuestas.)

#MX record (= mail exchanger record = registro de intercambiador de correo) #Está estandarizado en el RFC 1035.

#Define los servidores de mail para la zona. #Es un registro opcional, depende de la existencia de servidores de correo. #Si no hay servidores de correo, no hay ningún MX record. #Por cada servidor de correo debe haber un MX record. #Un registro MX también puede citar a un servidor de mail fuera del dominio #o en otro dominio. #NO FUNCIONA DECLARAR UN SERVIDOR DE MAIL CON UN A RECORD O UN CNAME RECORD. #El MX record indica a los clientes qué servidores deben usar para entregar correo #y en qué orden deben hacerlo. #¡Por cada MX record debe existir un A record asociado! #Ejemplo1: 1 SERVIDOR DE CORREO mailserver.example.org. IN A 192.168.1.1 example.org. IN MX 10 mailserver ; 10 indica la MEJOR prioridad del servidor de mail. ; Las prioridades se incrementan de 10 en 10 para los siguientes ; servidores de correo, Y SON INFERIORES EN PRIORIDAD A LA PRIORIDAD 10. #Ejemplo2: 2 SERVIDORES DE CORREO mailserver.example.org. IN A 192.168.1.1 mailserver2.example.org. IN A 192.168.1.2 example.org. IN MX 10 mailserver example.org. IN MX 20 mailserver2 #Ejemplo3: 2 SERVIDORES DE CORREO con igual prioridad # (útil en grandes redes con muchos usuarios) mailserver.example.org. IN A 192.168.1.1 mailserver2.example.org. IN A 192.168.1.2 example.org. IN MX 10 mailserver example.org. IN MX 10 mailserver2 #Ejemplo4: 1 SERVIDOR DE CORREO fuera del dominio mailserver.example.org. IN A 192.168.1.1 example.org. IN MX 10 mailserver example.org. IN MX 20 backup-email.example.com. ; No aumentamos un A record para backup-email.example.com. ; para evitarnos tener que actualizar su dirección IP ; si esta es cambiada por el administrador del otro dominio. #De esta forma, es el cliente (no el servidor DNS) el que decide a cuál servidor contactar. #NOTA: el registro MX sólo proporciona la información para encontrar a un servidor #de correo. El registro MX no recibe, procesa o envía correos electrónicos. #Más información ver págs. 34-35 y 521-524 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress

#EJEMPLO CONJUNTO DE UN MASTER ZONE FILE: #editar el archivo /var/named/chroot/etc/named.conf vi /var/named/chroot/etc/named.conf #Introducir las siguientes declaraciones (es el ejemplo del libro de texto, págs. 175-176): options { directory "/etc"; pid-file "/var/run/named/named.pid"; recursion no; }; zone "example.org" { type master; file "/var/named/chroot/var/named/example.org.hosts"; }; #editar el archivo /var/named/chroot/var/named/example.org.hosts vi /var/named/chroot/var/named/example.org.hosts #introducir (es el ejemplo del libro de texto, págs. 175-176): $ttl 38400 example.org. IN SOA dns0.example.com. pmembrey.example.org. ( 1187790697 ; serial number 10800 ; refresh 3600 ; retry 604800 ; expiry 38400 ) ; minimum www.example.org. IN A 192.168.1.1 ftp.example.org. IN CNAME www mail.example.org. IN A 192.168.1.2 mail2.example.org. IN A 192.168.1.3 example.org. IN NS dns0.example.com. example.org. IN NS ns1.example.net. example.org. IN MX 10 mail example.org. IN MX 20 mail2 dns0.example.com. IN A 192.168.1.4 #(Re)iniciar el servidor DNS: service named restart #Probar el servidor DNS: host www.example.org localhost #SEGUNDO EJEMPLO CONJUNTO DE MASTER ZONE FILE: #CONTENIDO DEL ARCHIVO /var/named/chroot/etc/named.conf options { directory "/etc"; pid-file "/var/run/named/named.pid"; recursion no; }; zone "dominioesc.org.ec" { type master; file "/var/named/dominioesc.org.ec.hosts"; }; zone "." IN { type hint; file "named.root"; }; #CONTENIDO DEL ARCHIVO /var/named/chroot/var/named/dominioesc.org.hosts $TTL 38400 $ORIGIN dominioesc.org.ec. @ IN SOA dns1.dominioesc.org.ec. hostmaster.dominioesc.org.ec. ( 2010112801 10800 3600 604800 38400 ) dominioesc.org.ec. IN NS dns1.dominioesc.org.ec. dominioesc.org.ec. IN NS dns2.dominioesc.org.ec. dns1.dominioesc.org.ec. IN A 192.168.1.4 dns2.dominioesc.org.ec. IN A 192.168.1.3 www.dominioesc.org.ec. IN A 192.168.1.4 ftp.dominioesc.org.ec. IN CNAME www dominioesc.org.ec. IN MX 10 mail1 dominioesc.org.ec. IN MX 20 mail2 mail1.dominioesc.org.ec. IN A 192.168.1.4

mail2 IN CNAME mail1.dominioesc.com.

#NOTA: para ejemplos más complejo ver págs. 483-551 de #Aitchison, R. (2011). Pro DNS and BIND. New York: Apress

#CREACIÓN DE UNA SLAVE ZONE: (CREA REDUNDANCIA Y DISTRIBUYE CARGA Y TRÁFICO) #editar el archivo /var/named/chroot/etc/named.conf #en el servidor DNS slave: vi /var/named/chroot/etc/named.conf #Introducir: zone "example.org" { type slave; file "/var/named/example.org.hosts"; masters { 192.168.1.1; esta es la dir IP del Master server }; }; #Guardar. #(Re)iniciar el servicio DNS: service named restart

#HABILITACIÓN DE ZONE TRANSFERS: #Aumentar "allow-transfer" en el archivo "named.conf" del MASTER server. #Ejemplo: vi /var/named/chroot/var/named/example.org.hosts #Introducir: allow-transfer {192.168.1.5;}; esta es la dir IP del SLAVE server #Grabar. #Reiniciar el servicio named en servidores MASTER y SLAVE. #Finalmente, editar el archivo /etc/hosts para que registre el nuevo nombre dominio. #Ejemplo: # Do not remove the following line, or various programs # that require network functionality will fail. #127.0.0.1 centos1 localhost.localdomain localhost 127.0.0.1 centos1 centos1.midominio.org localhost #CONSEJOS PRÁCTICOS: # a. Incrementar el número serial después de cada cambio al servidor master de DNS. El número serial es un número entre 0 y 4294967295 (2^32 - 1). Es arbitrario, pero se recomienda poner los números de serie así: YYYYMMDDSS donde YYYY = año MM = mes DD = día del mes SS = número de cambio hecho en el día Ejemplo: 2011052302 Para resolver problemas con números seriales fuera de secuencia, vea págs. 196-197 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress # b. Usar la declaración "recursion no;" para evitar el ataque al servidor DNS # llamado "Envenenamiento del cache de DNS". # c. No olvidar los puntos al final en los nombres canónicos declarados en # los RECORD de DNS. # d. Una guía de referencia completa sobre todas las declaraciones DNS posibles en un ZONE FILE se encuentra en las págs. 483-551 de Aitchison, R. (2011). Pro DNS and BIND. New York: Apress e. Si usted va a trabajar como administrador de una red grande y compleja que usa BIND como su software de servidor DNS, debe leer completamente la siguiente documentación; -Aitchison, R. (2011). Pro DNS and BIND 10. New York: Apress -Manuales del menú de ayuda del BIND configuration GUI (system-config-bind): -BIND Administrator Reference Manual -System-config-bind User Guide and Manual

**************** SMTP ************************* #Instalación del MTA (Mail Tranfer Agent) postfix: yum install postfix system-switch-mail #Escoger Postfix como MTA por defecto con system-switch-mail: system-switch-mail #Permitir en el firewall el puerto 25. #Confirmar que el puerto 25 acepta conexiones SMTP: iptables -L | grep smtp #Configurar postfix para que inicie cuando arranque el servidor Centos chkconfig postfix on #Confirmar lo anterior, que el servicio Postfix arranque en los RUNLEVEL 3 y 5: chkconfig postfix --list #Arrancar el servicio postfix: service postfix start #Probar el funcionamiento básico del servicio de mail. #Envío de un mensaje de correo. echo "hello" | mail -s "asunto_prueba" root #Ver el log del servidor de correo. cat /var/log/maillog #ver el buzón de entrada del usuario actual (root): mail

#CONFIGURACION DE POSTFIX: #Confirmar que postfix esté instalado: rpm -q postfix #El directorio más importante para la configuración de postfix es /etc/postfix ls /etc/postfix #CONFIGURACIÓN PARA ENVIAR CORREO: #(NOTA: Postfix no envía mensajes de correo al usuario root por seguridad. #Para ello usa los alias creados en el archivo /etc/aliases.)

#En el siguiente directorio almacena postfix los archivos para gestionar el sistema de correo. ls /var/spool/postfix #En el siguiente directorio almacena postfix los buzones de correo de los usuarios. ls /var/spool/mail/ #Editar con el usuario root el archivo principal de configuración de postfix: vi /etc/postfix/main.cf #Modificar las siguientes líneas. #Ejemplo: myhostname = mail1.dominioesc.org.ec mydomain = dominioesc.org.ec myorigin = $mydomain #La dirección del servidor "repetidor" de mail, que en este caso es #la de mail.andinanet.net relayhost = 200.107.10.14 #permitir que postfix escuche mail en todas sus direcciones ip inet_interfaces = all #permitir que todos los clientes del servidor le envíen mail mynetworks = 192.168.1.0/29,127.0.0.1/8 #NOTA: la dirección del relayhost del laboratorio de la UCE es 10.3.0.9 #Para ver un resumen de los cambios realizados al archivo /etc/postfix/main.cf postconf -n #Para ver todos los parámetros por defecto de postconf: postconf -d #Para ver el valor actual de parámetros específicos, por ejemplo: postconf myhostname #Para editar un parámetro en línea y que su cambio entre en efecto de inmediato, por ejemplo: postconf -e "myorigin = midominio.org" #NOTA: para ver todas las opciones de configuración de este archivo, ejecutar el comando: man 5 postconf #Enviar un mensaje de correo a una cuenta en cualquier servicio de correo externo. #Ejemplo: #Recuerde que no se puede usar la cuenta de root para enviar-recibir mails. su huesped echo "prueba desde centos hacia yahoo" | mail -s "centos a yahoo" [email protected] #después de pulsar enter, introducir el cuerpo del mensaje, finalizarlo con CTRL+D y #pulsar enter en el campo de CC: exit #Ver el estado del log del servicio de correo. cat /var/log/maillog #Información sobre cómo funciona el gestor de colas de mensajes se puede ver en: man 8 qmgr

#Configuración para cifrar el envío de mails por la conexión SMTP: #Ejemplo con el relay host de la cnt.com.ec #Instalación de bibliotecas para cifrado SASL (=Simple Authentication and Security Layer): yum install cyrus-sasl cyrus-sasl-lib cyrus-sasl-plain #Comprobar que el servidor mail.andinanet.net soporta cifrado TLS telnet 200.107.10.14 25 help ehlo 200.107.10.14 starttls quit #Añadir las siguientes entradas al archivo /etc/postfix/main.cf: vi /etc/postfix/main.cf smtp_sasl_auth_enable = yes smtp_sasl_security_options = noanonymous smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_tls_security_level = may tls_random_source = /dev/urandom #Añadir la contraseña para que postfix se identifique: vi /etc/postfix/sasl_passwd mail.andinanet.net usuario:contraseña #Transformar la información anterior en archivo .db postmap /etc/postfix/sasl_passwd #Usar el archivo .db creado: service postfix reload

#CONFIGURACIÓN PARA RECIBIR CORREO: #Primero comprobar que el servidor DNS cuenta con registros MX #Ejemplo: host -t MX dominioesc.org.ec centos1 #Añadir las siguientes entradas al archivo /etc/postfix/main.cf: vi /etc/postfix/main.cf #Si es que los mensajes son rechazados, que sea rechazo temporal y haya reintento: soft_bounce = yes unknown_local_recipient_reject_code = 450 #Indicar a postfix que es el último salto hacia [email protected], # [email protected], [email protected] #y user@centos1: mydestination = $mydomain, $myhostname, localhost.$mydomain, localhost #Confirmar que los usuarios que van a recibir mail realmente existan en el servidor getent passwd huesped getent passwd eduardo ... #NOTA: tan pronto como se crea un usuario, ya está listo para recibir mail. #Para crear alias para los usuarios, determinar primero el archivo de alias: postconf alias_maps #Luego, vi /etc/aliases #Quitar el símbolo de comentario y cambiar el nombre del usuario #que va a recibir los mails dirigidos a root: root: eduardo #Luego, introducir los alias que sean necesarios. #Ejemplos: mama: [email protected] support: eduardo,huesped,cecilia #Después, obtener un archivo .db del anterior: newaliases #Reiniciar postfix. service postfix restart #Recuperación del mail como cliente: #DOVECOT: Servidor de IMAP4 y POP3 yum install dovecot service dovecot start #Comprobar el funcionamiento de DOVECOT POP3: #(Este es un protocolo menos complejo que IMAP4, pues solamente controla la descarga #del buzón de correo desde el servidor hacia el cliente.)

telnet localhost 110 user eduardo pass stat list 1 retr 1 quit #Comprobar el funcionamiento de DOVECOT IMAP4: #(Este es un protocolo más complejo que POP3, pues debe gestionar todo desde el servidor.) telnet localhost 143 login eduardo select Inbox fetch 1 body[text] logout #Permitir en el firewall los puertos TCP 993 (IMAP4S) y 995 (POP3S). #(Usar para ello Sistema->Administración->Nivel de seguridad y Cortafuegos) #Comprobación de que aquellos puertos estén abiertos: iptables -L -v | grep -E "pop3|imap" #¡NO HAY NECESIDAD DE ABRIR LOS PUERTOS 110 y 143 SI TODOS LOS ACCESOS VAN A #SER UNICAMENTE CIFRADOS! #Instalar cliente gráfico de correo electrónico: yum install thunderbird #El cliente de correo Novell Evolution es mejor, pues le permite comprobar los algoritmos de cifrado #configurados en el servidor de correo. #Para comprobar el funcionamiento pleno del cliente gráfico de correo electrónico, #crear 3 cuentas de correo: i)Una para enviar y recibir correo de un servidor público de correo como yahoo, gmail, hotmail, etc: -en el caso de servidores públicos de correo es muy posible que el puerto para enviar correo no sea 25 sino 587 ii)Otra para enviar y recibir correo del propio servidor de correo ya instalado: -el protocolo del cliente para enviar correo siempre es SMTP en el puerto 25, a menos que lo haya configurado de otra forma -el protocolo del cliente para recibir correo puede ser POP, IMAP o spool -NOTA: si va acceder a su correo desde otro equipo que no sea aquel en el que está instalado el servidor de correo, debe ser capaz de localizar vía DNS a dicho servidor. Si el nombre de dominio no está registrado, añada una entrada correspondiente al servidor DNS respectivo en /etc/resolv.conf, o añada una entrada correspondiente al servidor de mail en /etc/hosts. Haga lo mismo para otros servidores de mail cuyo nombre no esté registrado. iii)Otra para enviar y recibir correo del servidor de correo de otro grupo de compañeros en el laboratorio NOTA1: EN TODOS LOS CASOS, NO USAR CIFRADO (a menos que lo haya activado en la configuración de su servidor) NOTA2: EN TODOS LOS CASOS, SELECCIONAR EL ALGORITMO DE AUTENTICACIÓN CORRECTO, caso contrario el servidor de correo no podrá leer la contraseña del usuario. #Configurar certificados de seguridad en dovecot: ver págs. 139 a 151 del libro de texto #Si tiene instalado nmap, puede comprobar los puertos activados con nmap: nmap localhost -p 110,143,993,995 #Comprobar el cifrado: openssl s_client -connect localhost:995 openssl s_client -connect localhost:993 #Para filtrar spam: Instalar SpamAssassin #Para filtrar virus: Instalar ClamAV #Para integrar SpamAssassin y ClamAV con el servidor de mail: Instalar MailScanner **************** HTTP ************************* 1. INTRODUCCIÓN -Historia del HTTP, el HTML y la WWW: ver hiperenlaces relacionados en la página del grupo UCE_TIC en yahoo -HTTP y HTTPS -puerto TCP por defecto para HTTP: 80 -puerto TCP por defecto para HTTPS: 443 -URL = uniform resource locator = hiperenlace -Dimensiones actuales del hipertexto: -texto plano -gráficos -vídeo -audio -metadatos -Virtual Hosting: -Alojamiento virtual de sitios web -Un único servidor web puede manejar muchos diferentes sitios web simultáneamente -Funcionamiento básico de HTTP -El usuario introduce un URL. -A partir del URL, el cliente HTTP (= el navegador) pide al DNS la traducción del nombre del servidor HTTP en dirección IP. -El cliente HTTP establece la conexión IP con el servidor HTTP. -El navegador del cliente envía una petición GET con el URL como parámetro al servidor. Ejemplo: GET http://www.apress.com/book/catalog/ -El servidor HTTP envía un código de respuesta y el resultado de la petición del cliente (= del navegador). -OJO: todos los códigos de respuesta (= Reply codes) se encuentran explicados en el RFC 2616. -El navegador sigue el mismo procedimiento para descargar gráficos, Cascading Style Sheets (=CSS) y JavaScripts: -Fácilmente puede haber más de 50 peticiones para descargar una página completa. -En HTTP hay mucho caching de archivos para mejorar los tiempos de descarga. -¿Por qué instalar un servidor web propio en vez de alquilar uno? Por la flexibilidad y libertad para hacer cambios. La mayoría de empresas de WEB HOSTING restringen lo que uno puede hacer en su servidor web. -APACHE HTTP: es el servidor HTTP más usado del mundo, hay abundante soporte y documentación. -ESTADÍSTICAS DE USO DE WEB SERVERS Y WEB BROWSERS: ver hiperenlaces en la página de yahoo para el grupo UCE_TIC. -Historia -NCSA Mosaic=>Netscape Navigator=>Internet Explorer, Opera=>Mozilla=>Chrome, RockMelt -El proyecto Mozilla empezó a consolidarse con el desarrollo de Phoenix (hoy Firefox) y Minotaur (hoy Thunderbird)

-TAXONOMÍA -TUX Linux in-kernel web server -APACHE HTTP SERVER / APACHE TOMCAT /Java software platform (Apache ya tiene más de 15 años de desarrollo) -NGINX ("Mr. Jinks", a.k.a. Jinksy) -lighttpd -IBM HTTP/WEBSPHERE -Microsoft Internet Information Services /MICROSOFT ASP.NET /MS .NET FRAMEWORK -Algo sobre los 3 marcos de desarrollo de SW más importantes: -PILA .NET (ver http://en.wikipedia.org/wiki/File:DotNet.svg) -PILA JAVA (ver http://en.wikipedia.org/wiki/Java_(software_platform) ) -PILA IBM Websphere (ver http://en.wikipedia.org/wiki/IBM_WebSphere) -¿CUÁL ES MEJOR? MICROSOFT VS. ORACLE VS. IBM = ¡TRIOPOLIO! http://en.wikipedia.org/wiki/Comparison_of_the_Java_and_.NET_platforms http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java -NOTA: ¡Antes de probar servidores web más exóticos, aprenda a usar bien Apache! -NOTA: Sobre los navegadores, pruebe y compare OBJETIVAMENTE los siguientes -Google Chrome -Rockmelt -Opera -Mozilla Firefox -MS Internet Explorer

2. Secure Sockets Layer (SSL) -Fue desarrollado por Netscape (Javascript también fue desarrollado por Netscape). -SITIOS WEB SEGUROS -CORREO SEGURO -DOS servicios: -conexión segura mediante cifrado del transporte entre las capas simétricas participantes -las capas simétricas negocian (acuerdan) el más alto algoritmo mutuo de cifrado -certificados para que el cliente pueda identificar al servidor -al conectarse, el servidor presenta sus certificados al cliente -el cliente tiene una base de datos de autoridades de certificación (= CA = certificate authorities) en las cuales confía -el cliente verifica con estas autoridades para ver si alguna a firmado el certificado presentado por el servidor -si el certificado ha sido firmado, si no ha expirado y si el nombre de host coincide, el cliente mostrará la página web sin pedir más credenciales -Caso contrario, WARNING: ver ejemplo de página de notas de la EDC-UCE 3. Instalación de Apache yum install httpd #Habilitar HTTP y HTTPS en el firewall #Asegurarse de httpd arranque siempre que arranque el sistema operativo: chkconfig httpd on #Confirmar lo anterior: chkconfig --list httpd #Iniciar el demonio httpd: service httpd start #Confirmar el estado del demonio: note los varios procesos que necesita httpd para funcionar... service httpd status #Los números de los procesos (PIDs) son útiles cuando se hace depuración del kernel. #Arranque el navegador y pruebe navegar en # http:// #El comando elinks también es útil para verificar el buen funcionamiento del servidor http: yum install elinks elinks http://localhost #Pulsar Q para salir. #Para ver la versión de Apache que ha instalado, puede introducir en su navegador lo siguiente: http:///xyz #O en la línea de comandos de una venta de terminal: httpd -v 4. Configuración de Apache #NOTA: La documentación completa y oficial de Apache se encuentra en http://httpd.apache.org/docs/ #Todos los archivos de configuración de Apache en el servidor se encuentran en: cd /etc/httpd/ #El siguiente directorio contiene el archivo central de configuración de Apache (httpd.conf): ls /etc/httpd/conf #El siguiente directorio contiene los archivos de configuración de software complementario de Apache: ls /etc/httpd/conf.d #Primeros cambios necesarios en el archivo de configuración: vi /etc/httpd/conf/httpd.conf #Buscar la variable ServerAdmin y modificarla con la dirección de correo electrónico #con la cual ponerse en contacto en caso de errores del servidor web: ServerAdmin [email protected] #Nombre del servidor y puerto TCP: ServerName www.su-dominio.com:80 #NOTA: si el nombre de dominio no está registrado, añada una entrada correspondiente al servidor DNS respectivo en /etc/resolv.conf, o añada una entrada correspondiente al servidor web en /etc/hosts. Haga lo mismo para otros servidores web cuyo nombre no esté registrado. #Verifique la correctitud actual de la sintaxis en el archivo de configuración de Apache: service httpd configtest #El anterior comando es muy útil para determinar errores en las declaraciones sintácticas #para configurar Apache, si tomamos en cuenta que es un archivo con 1000 líneas de #configuración en promedio. #Compruebe que el servicio httpd arranca correctamente con los cambios efectuados a la configuración: service httpd restart

#HABILITAR .htaccess (permite controlar permisos sobre contenidos web y usuarios autorizados #para navegar en su sitio web): vi /etc/httpd/conf/httpd.conf #Cambiar el valor de la variable AllowOverride None a AllowOverride All #Reiniciar httpd service httpd restart

#PROTEGER DIRECTORIOS DE CONTENIDOS WEB MEDIANTE CONTRASEÑA: #Por ejemplo, proteger el directorio principal de contenidos web de Apache: vi /var/www/html/.htaccess #Introducir lo siguiente: order allow,deny deny from all order allow,deny deny from all AuthUserFile /etc/httpd/htpasswd AuthName "Secret Secure Area" AuthType Basic require valid-user #La primera y segunda partes impedirán que los usuarios puedan descargar los #archivos .htaccess o .htpasswd #NOTA: Es mejor situar los archivos .htpasswd en /etc/httpd para evitar problemas en el control de acceso a dichos archivos. #La tercera parte: #AuthUserFile apunta al archivo .htpasswd que contiene información #de login (= apertura de la sesión) de los usuarios en el servidor web. #AuthName es el texto que aparecerá en la ventana de login. #AuthType es el tipo de autenticación, casi siempre es de tipo básico (= Basic). #Hay otros modos de autenticación, pero este es el más usado. El tipo Basic #consiste en el intercambio de nombre de usuario y contraseña. #require valid-user indica a Apache que cualquier usuario válido en el #archivo .htpasswd tendrá acceso al sitio web. #Si lo desea, puede especificar l#El algoritmo de cifrado de contraseñas que usa Apache por defecto es crypt(). #Otros algoritmos disponibles para cifrar contraseñas en Apache son MD5 y SHA. #Además, es posible no cifrarlas si escoge el método PLAINTEXT. os usuarios que tendrán acceso así: require user #Ejemplo: require user admin #CREAR CUENTAS DE USUARIO EN EL SITIO WEB: #Debe usar el comando htpasswd. Ejemplo: htpasswd -c /etc/httpd/htpasswd admin #La opción -c crea el archivo si no existía. Por ello, en futuros usos ya no será necesaria. #Ejemplo: htpasswd /etc/httpd/htpasswd huesped #Para ver todas opciones del comando: man htpasswd #Reinicie el servidor http: service httpd restart #Compruebe con su navegador que ahora su sitio web le pide autenticarse (= identificarse).

#INSTALACIÓN DE SSL: yum install mod_ssl service httpd restart #Comprobar la instalación con el navegador y la siguiente página web: https:// #Ahora ya puede usar https, pero con un certificado SSL auto-firmado, por eso la advertencia. #Acéptela y conéctese. #Si usa Firefox, note el candado (= padlock) en la parte inferior del navegador. #Para obtener un certificado SSL firmado por una autoridad de certificación #(= Certificate Authority, CA), por ejemplo Verisign o Thawte, #debe pagar por aquel certificado. Cuesta aproximadamente US$1.000 por año. #Certificados SSL relativamente más baratos son ofrecidos por DynDNS y GoDaddy. #Antes de obtener un certificado de una CA, debe genera una CSR (certificate-signing request). #Antes de generar la CSR, debe crear una clave: mkdir /etc/certs/ #NOTA: el directorio /etc contiene mucha información importante, por ello... #... ¡HAGA UNA COPIA DE SEGURIDAD DE ÉL!!! cd /etc/certs/ #DEBE CREAR UNA CLAVE PARA CADA SITIO WEB. Ejemplo: openssl genrsa -des3 -out www_sudominio_com.key 1024 #Note que el nombre del archivo en el que se guarda la clave alude al nombre de su dominio. #Durante la creación de la clave RSA le pedirá una frase de paso (= passphrase). #El archivo contendrá la clave privada RSA de su servidor Apache. ¡NO PERMITA A NADIE ACCEDER A ESTE ARCHIVO! (Si hace público dicho archivo, algún hacker podría usar el siguiente comando para descargarse el archivo: wget https://sudominio.com/www_sudominio.key Note lo útil que podría ser el comando wget.) #Cree la petición CSR: openssl req -new -key www_sudominio_com.key -out www_sudominio_com.csr #Cumplimente la información que le solicitan con cuidado. #En especial, cuando le pidan "common name", introduzca el nombre FQDN de su servidor web #pero sin el punto final. #Compruebe la creación de la CSR: cat www_sudominio_com.csr #El contenido de este archivo le será solicitado por la CA para crear su certificado digital. #La CA generará su certificado a partir de su CSR, la clave pública de su servidor Apache y #la firma digital de la CA. #Copie ABSOULTAMENTE TODA LA SALIDA de "cat www_sudominio_com.csr" en la página de la CA, #cuando esta la solicite, SIN BLANCOS NI LÍNEAS EN BLANCO ANTES O DESPUÉS. #NOTA: debido al precio que cobran las CA por los certificados digitales, y para finalizar este #ejercicio de SSL, firme usted mismo su certificado. Ejemplo: openssl x509 -req -days 365 -in www_sudominio_com.csr -signkey \ www_sudominio_com.key -out www_sudominio_com.crt #Le pedirá una frase de paso. #En criptografía, X509 es el estándar ITU (= International Telecommunication Union) #para infraestructuras de claves públicas. #Especifica los formatos de los certificados de clave pública y algoritmos para validación #de la ruta de certificación. #Compruebe el contenido del directorio /etc/certs: ls -ahl /etc/certs #Modificar la variable SSLCertificateFile vi /etc/httpd/conf.d/ssl.conf SSLCertificateFile /etc/certs/www_sudominio_com.crt #Modificar la variable SSLCertificateKeyFile vi /etc/httpd/conf.d/ssl.conf SSLCertificateKeyFile /etc/certs/www_sudominio_com.key

#Otros variables importantes en ssl.conf: #intermediary certificate: Son generalmente certificados más baratos ofrecidos por CAs más pequeñas. Los archivos correspondientes le son entregados por dichas CA. #certificate bundle: si tiene más de un certificado, puede agruparlos todos en un sólo archivo (= bundle). Debe cifrarlo con algoritmo PEM. Puede pedirlo a su CA. #certificate chain: archivo con información para validar la ruta de certificación. Lo debe proveer su CA. #Reinice el demonio httpd: service httpd restart #Ahora su servidor http le pide clave para arrancar. #Si no desea que aquello suceda: openssl rsa -in www_sudominio_com.key -out www_sudominio_com.key #Pruebe su certificado con su navegador, preferentemente desde otro equipo distinto al que #alberga su servidor http.

#VIRTUAL HOSTING para albergar varios sitios web en el mismo servidor: (ver págs. 100-104 del libro de texto.) #UN PAR DE TRUCOS PARA MEJORAR EL RENDIMIENTO (= PERFORMANCE) DE APACHE: (ver págs. 97-100 del libro de texto.) #EJERCICIO1: instalar WEBMAIL (págs. 152-154 del libro de texto)

************************** SNMP ************************* 1. INTRODUCCIÓN -ES NECESARIO UN PROTOCOLO PARA GESTIONAR LA INFRAESTRUCUTURA DE RED EN SUS 7 CAPAS: -MONITORIZAR EL ESTADO ACTUAL DE ¡TODOS! SUS COMPONENTES, FORMALMENTE LLAMADOS DISPOSITIVOS GESTIONADOS (= MANAGED DEVICES = MD) EN TERMINOLOGÍA SNMP, O ELEMENTOS DE CONFIGURACIÓN (= CONFIGURATION ITEMS = CI) EN TERMINOLOGÍA ITIL. -EJEMPLOS DE MDs: -NUDOS DE RED: SERVIDORES, PCs, ROUTERS, SWITCHES, IMPRESORAS, ETC. -HARDWARE DE HOSTS: PROCESADORES, DISCOS, MEMORIAS, NICs, MOTHERBOARDs, TEMPERATURAS, VENTILADORES, VOLTAJES, HUMEDAD, ETC. -SERVICIOS Y DEMONIOS EN HOSTS: SMTP, POP, HTTP, DNS, ETC. -LOGs (=ARCHIVOS DE REGISTRO DE EVENTOS EN HOSTS) -EL ESTADO DE UN MD PUEDE SER DE 4 TIPOS: VERDE: EN BUEN ESTADO, FUNCIONANDO CORRECTAMENTE AMARILLO: ADVERTENCIA, PUEDE SEGUIR FUNCIONANDO PERO HAY ANOMALÍAS ROJO: ALARMA, PELIGRO INMINENTE DE MAL FUNCIONAMIENTO APAGADO: NO HAY COMUNICACIÓN SNMP CON EL MD -NOTA SOBRE LA PALABRA ALERTA: -LA PALABRA ALERTA SE USA TAMBIÉN EN TIC, PERO SU ORIGEN ESTÁ EN LA GESTIÓN DE DESASTRES NATURALES, LOS SISTEMAS DE "ALERTA TEMPRANA" DE FENÓMENOS NATURALES, Y EN SITUACIONES DE GUERRA O DE EXCEPCIÓN (PANDEMIAS, EPIDEMIAS, TERRORISMO, ETC.) -LOS COLORES Y SIGNIFICADOS DE LAS ALERTAS SON: -ALERTA BLANCA: LOCALIDAD SIN RIESGO SIGNIFICATIVO -ALERTA VERDE: LOCALIDAD CON RIESGO PERO BAJO CONTROL -ALERTA AMARILLA: LOCALIDAD CON RIESGO EN DESARROLLO PERO BAJO OBSERVACIÓN -ALERTA NARANJA: LOCALIDAD CON RIESGO INMINENTE + EVACUACIÓN INMEDIATA DE LA POBLACIÓN -ALERTA ROJA: LOCALIDAD EN LA QUE EL RIESGO SE HA MATERIALIZADO, EL DESASTRE SE HA PRODUCIDO -Definición general de la palabra MONITORIZAR: Observar mediante aparatos especiales el curso de uno o varios parámetros fisiológicos o de otra naturaleza para detectar posibles anomalías. -MANTENER EL INVENTARIO CENTRALIZADO DE LA CONFIGURACIÓN DE CADA MD -CONTROLAR CENTRALIZADAMENTE CADA MD -APAGAR -REINICIAR -DESACTIVAR/ACTIVAR PUERTOS -DETERMINAR LA VERSIÓN ACTUAL DE SW, DISTRIBUIR SOFTWARE, INSTALARLO. -SOLUCIÓN DE TCP/IP: SNMP = SIMPLE NETWORK MANAGEMENT PROTOCOL -EL SNMP ES UN PROTOCOLO DE CAPA 7 QUE USA COMO PROTOCOLO DE TRANSPORTE (= CAPA 4) AL UDP EN LOS PUERTOS 161 (PARA ENVIAR) Y 162 (PARA RECIBIR). -ARQUITECTURA DE SNMP: -UN SISTEMA CENTRAL PARA GESTIÓN DE RED VÍA SNMP (= NETWORK MANAGEMENT SYSTEM = NMS) -UN AGENTE SNMP (= SNMP AGENT) EN CADA MD, ES DECIR, UN PROGRAMA EN CADA NUDO DE RED QUE EJECUTE INSTRUCCIONES EN REPRESENTACIÓN DEL NMS. -UNA BASE DE INFORMACIÓN PARA GESTION DE RED (= MANAGEMENT INFORMATION BASE = MIB), ES DECIR, UN ARCHIVO LOCALIZADO EN CADA NUDO DE RED, EN EL QUE EL AGENTE SNMP RESPECTIVO GUARDA INFORMACIÓN SOBRE DICHO NUDO PARA USO POSTERIOR EN EL NMS. -AQUELLA INFORMACIÓN ES GUARDADA POR EL AGENTE SNMP EN ¡VARIABLES SNMP! (= SNMP VARIABLES) DENTRO DEL ARCHIVO MIB DEL NUDO CORRESPONDIENTE. -HAY UNA VARIABLE SNMP POR CADA OBJETO GESTIONADO (= MANAGED OBJECT = MO). -UN OBJETO GESTIONADO (= MO) ES UN SUBCOMPONENTE DE UN MD. EJEMPLO: -EL MD SERVIDOR TIENE AL MENOS UN MO PROCESADOR, UN MO MEMORIA, UN MO DISCO DURO Y UN MO NIC. -EL ARCHIVO MIB GUARDA LAS VARIABLES SNMP EN UNA ESTRUCTURA DE ÁRBOL JERÁRQUICO. -UNA BASE DE DATOS CENTRAL EN EL NMS, EN LA CUAL SE ALMACENAN COPIAS DE LOS MIBs DE TODOS LOS MDs PARA COMPONER EL SISTEMA DE INFORMACIÓN DE RED GESTIONADO POR EL NMS. -UN PROTOCOLO DE COMUNICACIONES PARA INTERCONECTAR AL NMS CON LOS AGENTES SNMP. -ESTE ES EL PROTOCOLO SNMP PROPIAMENTE DICHO (= SIMPLE NETWORK MANAGEMENT PROTOCOL) -LOS PDUs DE SNMP PUEDEN SER DE 7 TIPOS: -GET: PARA ORDENAR EL NMS AL AGENTE SNMP QUE ENVÍE EL VALOR DE UNA VARIABLE SNMP GUARDADA EN EL MIB DEL MD RESPECTIVO. -GETNEXT: PARA ORDENAR EL NMS AL AGENTE SNMP QUE ENVÍE EL VALOR DE LA SIGUIENTE VARIABLE SNMP GUARDADA EN EL MIB DEL MD RESPECTIVO. -GETBULK: PARA ORDENAR EL NMS AL AGENTE SNMP QUE ENVÍE LOS VALORES DE VARIAS VARIABLES SNMP GUARDADAS EN EL MIB DEL MD RESPECTIVO. -SET: PDU QUE EL NMS ENVÍA PARA ORDENAR AL AGENTE QUE MODIFIQUE EL VALOR DE ALGUNA VARIABLE EN EL MIB DEL MD. -TRAP: PDU ENVIADO POR UN AGENTE AL NMS, SIN QUE ESTE ÚLTIMO LA HAYA SOLICITADO, PARA NOTIFICAR ALGUNA NOVEDAD EN EL MD. -RESPONSE: RESPUESTA A ALGUNO DE LOS PDUs ANTERIORES -INFORMREQUEST: PARA ENVIAR UN RECONOCIMIENTO (=ACKNOWLEDGEMENT = ACK) ENTRE 2 NMS, O UN RECONOCIMIENTO DE UN NMS A UN TRAP ENVIADO POR UN AGENTE.

-NOTA: EL SNMP USA UDP. A SU VEZ, EL PROTOCOLO UDP ES UN PROTOCOLO NO ORIENTADO A CONEXIÓN QUE NO NOTIFICA NI CORRIGE ERRORES EN EL TRANSPORTE DE DATOS. DE AHÍ LA NECESIDAD DEL PDU INFORMREQUEST. -EJEMPLO DE TRAP E INFORMREQUEST: -EL ADMINISTRADOR DE UNA RED HA AUMENTADO MEMORIA RAM EN LA i-ésima PC (= "PC-i") DE UN SISTEMA DE INFORMACIÓN. -EL AGENTE SNMP DEL MD "PC-i" NOTIFICA AL NMS MEDIANTE UN TRAP QUE LA CONFIGURACIÓN DEL MD "PC-i" HA CAMBIADO. -EL NMS RESPONDE (= RESPONSE) AL AGENTE SNMP, ORDENÁNDOLE QUE ACTUALICE (= SET) TODAS LAS VARIABLES EN EL MIB DEL MD "PC-i". -EL AGENTE SNMP ENVÍA AL NMS UNA RESPUESTA (= RESPONSE) EN LA QUE INDICA QUE LA ACTUALIZACIÓN DEL MIB DEL MD SE HA EFECTUADO CON ÉXITO. -EL NMS ENVÍA UN INFORMREQUEST PARA INDICAR QUE HA RECIBIDO SATISFACTORIAMENTE LA RESPUESTA DEL AGENTE SNMP. -DESCUBRIMIENTO (= DISCOVERY): PROCEDIMIENTO MEDIANTE EL CUAL EL NMS DETECTA AGENTES SNMP Y SUS RESPECTIVOS MIBs EN LAS REDES IP A LAS QUE TIENE ACCESO. -AUTODESCUBRIMIENTO (= AUTODISCOVERY): PROCEDIMIENTO AUTOMÁTICO (SIN INICIACIÓN DELIBERADA POR EL INGENIERO RESPONSABLE DE GESTIONAR EL NMS), MEDIANTE EL CUAL EL NMS DETECTA AGENTES SNMP Y SUS RESPECTIVOS MIBs EN LAS REDES IP A LAS QUE TIENE ACCESO. -COMUNIDAD SNMP (= SNMP COMMUNITY): -CONJUNTO DE MDs QUE SON GESTIONADOS CLAVE DE SEGURIDAD QUE LES AUTENTICA -SI LA CLAVE DE LA COMUNIDAD SNMP ES CASO CONTRARIO SE LLAMARÁ PRIVADA (= -EL NMS SÓLO PUEDE GESTIONAR MDs SIN O MDs DE LOS CUÁLES CONOZCA SU CLAVE

POR UN NMS VÍA SNMP Y QUE COMPARTEN UNA COMO MIEMBROS DE ESE CONJUNTO SNMP. NULA, LA COMUNIDAD SE LLAMA PÚBLICA (= PUBLIC). PRIVATE). CLAVE DE COMUNIDAD SNMP, DE COMUNIDAD SNMP.

-EJEMPLOS DE NMS: -MICROSOFT SYSTEM CENTER CONFIGURATION MANAGER (MS SCCM) -IBM TIVOLI -HP OPENVIEW -HP Systems Insight Manager (Originalmente COMPAQ Insight Manager, actualmente versión muy reducida y limitada de HP Openview) -BMC PATROL -CISCO WORKS -OPEN SOURCE -PRTG -ZENOSS -NAGIOS -NOTA: El protocolo SNMP, la norma ISO/IEC 7498-4 para Gestión de Redes de Comunicaciones, la norma ISO/IEC 20000 para Gestión de Servicios de Tecnología de la Información y las metodologías de-facto ITIL y COBIT son los pilares tecnológicos y metodológicos para la GESTIÓN DE LAS TIC en los actuales sistemas de información y comunicaciones empresariales. (Ver páginas web correspondientes en http://es.groups.yahoo.com/group/UCE_TIC ) 2. CONFIGURACIÓN DE NAGIOS #Instalación de nagios y nagios plug-ins: yum install nagios nagios-plugins rpm -ivh http://packages.sw.be/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm #Al final de la instalación, todos los archivos de configuración de Nagios #se encontrarán en /etc/nagios #El principal archivo de configuración es nagios.cfg #Las definiciones para objetos gestionados (=Managed Objects = MO) #se encuentran en /etc/nagios/objects #Managed objects en Nagios: host object, service object, contact object. #El archivo /etc/httpd/conf.d/nagios.conf contiene la configuración #de Nagios para el Apache web server. #El archivo /usr/lib/nagios/cgi contiene scripts CGI de configuración #para la interface web de Nagios. #El archivo /usr/lib/nagios/plugins contiene scripts para leer MIBs #y enviar alertas al administrador. #El archivo /usr/share/nagios contiene la parte estática de la interface web de Nagios. #Los logs de Nagios se encuentran en /var/log/nagios #En el directorio /var/nagios se registra la información sobre el estado de los MDs. #CONFIGURACIÓN INICIAL: #Cambiar la dirección de contacto del administrador, a la cual Nagios enviará alertas: vi /etc/nagios/objects/contacts.cfg cambie la dirección nagios@localhost por su dirección de correo electrónico #Crear la clave de administrador de Nagios: htpasswd -c /etc/nagios/htpasswd.users nagiosadmin #El archivo /etc/nagios/htpasswd.users contiene los nombres y contraseñas (cifradas) #de los usuarios creados en Nagios y es usado por el servidor web Apache para autenticarlos. #Configurar el demonio de Nagios para arrancar siempre que arranque el SO del servidor: chkconfig nagios on #Arrancar el demonio de Nagios: service nagios start #Asegúrese de que el servidor HTTP Apache también arranque cuando el SO inicie: chkconfig httpd on #Asegúrese de que el demonio de Apache arranque: service httpd start #Abra la interfaz web de nagios con su navegador en la siguiente dirección: #http:///nagios/ #O también: #http:///nagios/ #Le pedirá nombre de usuario y contraseña. Introduzca el nombre "nagiosadmin" y la contraseña #que creó para esta cuenta de usuario. #CONFIGURACIÓN BÁSICA DE NAGIOS:

#Ver el libro de texto, págs. 303-311. vi /etc/nagios/nagios.cfg #CONFIGURACIÓN AVANZADA DE NAGIOS: #Ver pautas bibliográficas en el libro de texto, pág. 312. #Leer la documentación de Nagios en http://www.nagios.org/documentation #Instalación de NSClient++ para gestionar desde Nagios clientes Windows. #Ver los detalles de la instalación en http://nsclient.org/nscp/