Administración de red servidores y seguridad

916 views

Published on

Administración de red servidores y seguridad

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
916
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
40
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Administración de red servidores y seguridad

  1. 1. PEC 3 - Administración de red, servidores y seguridad Carlos David González Abraham Máster en Software Libre, Universitat Oberta de Catalunya carlosdavid@gonzalez-abraham.com.mx 19 de diciembre de 2008 Índice 1. Administración de red 2 1.1. Configuración de la interfaz de red . . . . . . . . . . . . . . . 2 2. Administración de servidores 5 2.1. Configuración del servicio DHCP . . . . . . . . . . . . . . . . 5 2.2. Configuración de los servicios NFS y NIS . . . . . . . . . . . . 7 2.2.1. Servicio NFS . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Servidor NIS . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.3. Cliente NIS . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Configuración de los servicios FTP y HTTP . . . . . . . . . . 13 2.3.1. Servidor FTP . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2. Servidor HTTP . . . . . . . . . . . . . . . . . . . . . . 16 3. Administración de seguridad 18 3.1. Implementación de firewall . . . . . . . . . . . . . . . . . . . . 18 3.2. Análisis de seguridad . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.1. Detección de intrusiones . . . . . . . . . . . . . . . . . 20 3.2.2. Seguridad Local . . . . . . . . . . . . . . . . . . . . . . 22 3.2.3. Seguridad de Red . . . . . . . . . . . . . . . . . . . . . 22 1
  2. 2. Administración de red, servidores y seguridad 1. Administración de red 1.1. Configuración de la interfaz de red Realizar la configuración desde el inicio de la interfaz de red considerando el tipo de conexión hardware que se disponga (mó- dem, módem/router ADSL, cable, LAN, etc) y los servicios que crea necesarios para un entorno de red. Para verificar este ejerci- cio se deberán realizar unas pruebas mínimas de conectividad en la misma red y hacia internet analizando la calidad de la conexión (por ejemplo contabilizando los paquetes perdidos). En la PEC se deberán describir todos los pasos realizados para configurar el dispositivo y los servicios en los ficheros de configuración sin uti- lizar herramientas automáticas o gráficas. Tener en cuenta de extremar las precauciones si es el único ordenador que se dispone conectado a la red ya que si se configura en forma inadecuada no se podrá disponer de ella para solicitar ayuda (a los foros de la UOC por ejemplo). En este caso particular no se aceptarán configuraciones automáticas hechas por dhcp (de un router local por ejemplo). En los siguientes párrafos se describe el proceso seguido para la config- uración de una interfaz de red en Slackware. El primer paso fue determinar que interfaces de red tenía el equipo, para esto ejecutó el comando ifconfig como se muestra a continuación: # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:16:36:4f:2b:bf inet6 addr: fe80 ::216:36 ff:fe4f :2bbf /64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU :1500 Metric :1 RX packets :2761 errors :0 dropped :0 overruns :0 frame :0 TX packets :2302 errors :0 dropped :0 overruns :0 carrier :0 collisions :0 txqueuelen :1000 RX bytes :807752 (788.8 KiB) TX bytes :231828 (226.3 KiB) lo Link encap:Local Loopback inet addr :127.0.0.1 Mask :255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU :16436 Metric :1 RX packets :0 errors :0 dropped :0 overruns :0 frame :0 TX packets :0 errors :0 dropped :0 overruns :0 carrier :0 collisions :0 txqueuelen :0 RX bytes :0 (0.0 B) TX bytes :0 (0.0 B) wlan0 Link encap:Ethernet HWaddr 00:13:02:1c:6c:93 inet6 addr: fe80 ::213:2 ff:fe1c :6c93 /64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU :1500 Metric :1 2
  3. 3. Administración de red, servidores y seguridad RX packets :561 errors :0 dropped :0 overruns :0 frame :0 TX packets :12 errors :0 dropped :0 overruns :0 carrier :0 collisions :0 txqueuelen :1000 RX bytes :192414 (187.9 KiB) TX bytes :1152 (1.1 KiB) En la salida anterior se observa que existen varias opciones, eth0 que es una interfaz ethernet, wlan0 que es una interfaz wi-fi y lo que hace referencia a la direccion bucle (loop). Debido a la arquitectura de la red disponible, se configuró la interfaz eth0 para lo que fue necesario hacer uso una vez más del comando ifconfig, pasandole los parámetros necesarios de la siguiente manera: # ifconfig eth0 inet 192.168.2.10 netmask 255.255.255.0 up El comando ping puede ser utilizado para revisar el estado de la conexión. Como ejemplo se probó alcanzar a un equipo dentro de la red local cuya la dirección IP es 192.168.1.11. De la prueba anterior se obtuvo la siguiente salida: # ping 192.168.2.11 PING 192.168.2.11 (192.168.2.11) 56(84) bytes of data. 64 bytes from 192.168.2.11: icmp_seq =1 ttl =64 time =0.188 ms 64 bytes from 192.168.2.11: icmp_seq =2 ttl =64 time =0.179 ms 64 bytes from 192.168.2.11: icmp_seq =3 ttl =64 time =0.180 ms 64 bytes from 192.168.2.11: icmp_seq =4 ttl =64 time =0.180 ms 64 bytes from 192.168.2.11: icmp_seq =5 ttl =64 time =0.180 ms --- 192.168.2.11 ping statistics --- 5 packets transmitted , 5 received , 0 % packet loss , time 4000 ms rtt min/avg/max/mdev = 0.179/0.181/0.188/0.012 ms En las últimas tres lineas se observan las estadisticas de la ejecución del ping. En este caso, de los cinco paquetes enviados no se perdió ninguno y los tiempos de respuesta menor, promedio y mayor fueron de: 0.179 ms, 0.181 ms y 0.188ms respectivamente. Desde luego los tiempos de respuesta han sido muy pequeños para este caso, ya que se trata de un equipo preteneciente a la red local. Para poder acceder a Internet, fue necesario configurar la dirección IP de la puerta de enlace (la dirección 192.168.2.1, un pequeño router/firewall dentro de la red local). Se especificó la dirección de la puerta de enlace a través de la linea GATEWAY del archivo /etc/rc.d/rc.inet1.conf. Esto último se configura en el archivo /etc/resolv.conf. En este mismo archivo, Slackware al igual que otras distribuciones, permite fijar la configuración de la interfaz de red de forma permanente. Esto permite que cada vez que 3
  4. 4. Administración de red, servidores y seguridad se reinicie el sistema, automáticamente se levantara la interfaz de red con la configuración deseada. El archivo rc.inet1.conf se actualizó de la siguiente manera: 1 ... 2 # Config information for eth0: 3 IPADDR [0]="192.168.2.10" 4 NETMASK [0]="255.255.255.0" 5 USE_DHCP [0]="" 6 DHCP_HOSTNAME [0]="" 7 ... 8 GATEWAY="192.168.2.1" 9 ... También fue necesario añadir la siguiente línea al archivo /etc/resolv.conf, especificando la dirección del servidor DNS para que el sistema supiera como resolver los nombres de dominio: 1 nameserver 200.23.242.209 Una vez más haciendo uso del comando ping se revisó el estado de la conexión, pero en esta ocación utilizando el nombre de dominio de un equipo fuera de la red local (un servidor en Internet). # ping google.com PING google.com (72.14.205.100) 56(84) bytes of data. 64 bytes from qb -in -f100.google.com (72.14.205.100): icmp_seq =1 ttl =242 time =133 ms 64 bytes from qb -in -f100.google.com (72.14.205.100): icmp_seq =2 ttl =242 time =136 ms 64 bytes from qb -in -f100.google.com (72.14.205.100): icmp_seq =3 ttl =242 time =134 ms 64 bytes from qb -in -f100.google.com (72.14.205.100): icmp_seq =4 ttl =242 time =135 ms --- google.com ping statistics --- 4 packets transmitted , 4 received , 0 % packet loss , time 2999 ms rtt min/avg/max/mdev = 133.873/135.113/136.240/0.944 ms El resultado fue que se pudo alacanzar sin problemas dicha dirección. También se puede observar que los tiempos de respuesta son considerable- mente mayores que en la prueba con un equipo local. 4
  5. 5. Administración de red, servidores y seguridad 2. Administración de servidores 2.1. Configuración del servicio DHCP Configurar un servidor de DHCP y verificar que el mismo funciona adecuadamente asignando como mínimo los parámetros necesarios para la configuración de una tarjeta de red. Para ello lo más fácil es utilizar otra máquina como cliente (indistintamente del operativo que disponga) para probar que se asignan correcta- mente las direcciones. Prestar atención en redes domésticas con router ADSL ya generalmente en la mayoría de los casos llevan activo un servidor de dhcp y podría dar servicio antes que nuestro servidor. En caso de no disponer dos máquinas para realizar las pruebas, utilizar algunos de los verificadores de configuración de DHCP que existen o utilizarlo en modo depuración (debug). Con la finalidad de comprobar el funcionamiento de un servidor DHCP se han utilizado dos equipos disponibles en el segmento de red 192.168.2.0. El primero, un equipo con Slackware cuya dirección MAC es 00:16:36:4F:2B:BF (laptop) y el segundo, una computadora con Ubuntu cuya dirección MAC es 00:13:D3:35:F4:9E (desktop). El primer equipo fue configurado como servidor DHCP para lo cual se modificó el archivo /etc/dhcpd.conf de la siguiente manera: 1 # Configuraciones globales 2 ddns -update -style none; 3 default -lease -time 1200; 4 deny bootp; 5 6 # hosts 7 host laptop { 8 hardware ethernet 00:16:36:4F:2B:BF; 9 fixed -address 192.168.2.10; 10 option host -name "laptop"; 11 } 12 13 host desktop { 14 hardware ethernet 00:13: D3 :35: F4:9E; 15 fixed -address 192.168.2.11; 16 option host -name "desktop"; 17 } 18 19 # red local 20 subnet 192.168.2.0 netmask 255.255.255.0 { 21 not authoritative; 22 option routers 192.168.2.1; 23 option broadcast -address 192.168.2.255; 5
  6. 6. Administración de red, servidores y seguridad 24 25 pool { 26 range 192.168.2.21 192.168.2.30; 27 max -lease -time 9200; 28 allow unknown -clients; 29 } 30 31 } La configuración anterior permite tener dos equipos (00:16:36:4F:2B:BF y 00:13:D3:35:F4:9E) a los cuales el servidor DHCP siempre les asignará las mismas direcciones IP. Al resto de los equipos se les asignará una IP del rango 192.168.2.21 al 192.168.2.30. Para comprobar la correcta configu- ración de este archivo, se ejecutó el comando dhcpd con el modificador -t. Lo anterior solo revisa que la sintaxis del archivo esta bien formada, sin embar- go no arranca el servicio en forma real. Para comprobar el funcionamiento del servidor DHCP, se utilizaron los modificadores -d -f al momento de iniciarlo: # dhcpd -d -f Internet Systems Consortium DHCP Server V3 .0.6 Copyright 2004 -2007 Internet Systems Consortium. All rights reserved. For info , please visit http :// www.isc.org/sw/dhcp/ Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 0 leases to leases file. Listening on LPF/eth0 /00:16:36:4f:2b:bf /192.168.2/24 Sending on LPF/eth0 /00:16:36:4f:2b:bf /192.168.2/24 Sending on Socket/fallback/fallback -net Lo anterior provoca que todos los mensajes del servicio DHCP vayan a parar a la salida estándar. Para comprobar el comportamiento del servidor, se hizo una petición de asignación de IP desde la máquina 00:13:D3:35:F4:9E utilizando el programa dhclient3 (cliente DHCP utilizado por Ubuntu). El servidor inmediatamente contestó asignado la dirección 192.168.2.11 de la siguiente manera: DHCPREQUEST for 192.168.2.11 from 00:13: D3 :35: F4:9E via eth0 DHCPACK on 192.168.2.11 to 00:13: D3 :35: F4:9E via eth0 Debido a la imposibilidad de contar con otro equipo al momento de re- alizar la prueba, se alteró la dirección MAC de la máquina cliente 00:13:D3:35:F4:9E para que simulara ser otro equipo que solicitara una dirección IP: 6
  7. 7. Administración de red, servidores y seguridad # ifconfig eth0 hw ether 0013 D335F48E Después se repitió el proceso de solicitud de asignación de una direc- ción IP con dhclient3, a lo que el servidor DHCP respondió asignando la dirección 192.168.2.30 de la siguiente manera: DHCPREQUEST for 192.168.2.11 from 00:13: d3 :35: f4:8e via eth0 : unknown lease 192.168.2.11. DHCPREQUEST for 192.168.2.11 from 00:13: d3 :35: f4:8e via eth0 : unknown lease 192.168.2.11. DHCPDISCOVER from 00:13: d3 :35: f4:8e via eth0 DHCPOFFER on 192.168.2.30 to 00:13: d3 :35: f4:8e (desktop) via eth0 DHCPREQUEST for 192.168.2.30 (192.168.2.10) from 00:13: d3:35 :f4:8e (desktop) via eth0 DHCPACK on 192.168.2.30 to 00:13: d3 :35: f4:8e (desktop) via et h0 Debido a que esta dirección MAC no estaba configurada para alguna IP en concreto, el servidor DHCP tomó una disponible del rango configurado (pool). En esta ocasión el servidor asigno la dirección 192.168.2.30. 2.2. Configuración de los servicios NFS y NIS Configurar un servidor NIS y un servidor de ficheros NFS en la misma máquina para que clientes remotos o locales se conecten solo a través de NIS montando su directorio HOME por NFS (en caso del servidor no es necesario). Para el servidor NFS se debe verificar su funcionamiento con restricciones de tipo de acceso (p.e. sólo lectura), usuarios, máquinas clientes (esta prueba se puede realizar desde un cliente externo montando el directorio en cuestión o desde la misma máquina (no tiene ningún ben- eficio sino simplemente hacer la prueba). Para el sistema NIS las pruebas se pueden hacer configurando el cliente tanto en una máquina externa como en el mismo servidor (para probar clien- te/servidor en la misma máquina deben crearse usuarios/grupos NIS -es decir que no estén dados de alta en el /etc/passwd ni en el /etc/group- y verificar su conexión a través de un terminal -AltFi o CrtlAltFi-). Se deben incluir en este ejercicio todos los cambios realizados en archivos de configuración (incluido el del /etc/passwd, /etc/- group). 7
  8. 8. Administración de red, servidores y seguridad 2.2.1. Servicio NFS Para habilitar el servicio NFS en Slackware fue necesario como primer pa- so, instalar los paquetes portmap y nfs-utils disponibles en la distribución (serie n): # installpkg portmap -6.0-i486 -1. tgz # installpkg nfs -utils -1.1.2 - i486 -1. tgz Se creó el directorio /export para ser compartido vía NFS con la finalidad de hospedar ahí los directorios personales de los usuarios. Esto se realizó mediante la adición de la siguiente línea al archivo /etc/exports: /export 192.168.2.0/255.255.255.0( rw , no_root_squash ) El siguiente paso fue arrancar los servicios de portmap y nfs usando sus guiones de arranque instalados en /etc/rc.d: # sh /etc/rc.d/rc.rpc start # sh /etc/rc.d/rc.nfsd start Con el programa showmount se puede revisar que directorios se están compartiendo vía NFS. Se uso este programa para asegurar que la configu- ración fuera correcta: # showmount -e localhost Export list for localhost: /export 192.168.2.0/255.255.255.0 Como última prueba, se intentó montar el directorio compartido desde otra computadora (192.168.2.11) usando el comando mount: # sudo mount 192.168.2.10:/ export /mnt # mount S.ficheros Bloques de 1K Usado Dispon Uso % Montado en ... 192.168.2.10:/ export 39657600 36852864 1193088 97 % /mnt 8
  9. 9. Administración de red, servidores y seguridad 2.2.2. Servidor NIS Para poder configurar tanto un cliente como un servidor NIS en Slack- ware, es necesario instalar el paquete yptools que viene incluido los CDs de instalación (serie n). # installpkg yptools -2.9-i486 -1. tgz Para la configuración del servidor, al igual que los ejercicios anteriores, se ha utilizado la máquina con Slackware (192.168.2.10). El primer paso para la puesta en marcha de una arquitectura NIS, es la elección de un nombre de dominio. Se eligió pec como nombre de domnio NIS y para establecerlo se utilizó el comando domainname y posteriormente se guardó en el archivo /etc/defaultdomain: # domainname pec # domainname > /etc/defaultdomain Se creo un par de guiones en /etc para los directorios de los usuarios vía NFS. El guión auto.master controla como debe funcionar el automontaje de los directorios: 1 # Archivo mapa para el automontaje NFS 2 # 3 /export auto.export --timeout 60 Y el guión auto.export define el mapeo /export: 1 # Archivo de configuracion del automontaje NFS 2 # 3 home -fstype=nfs 192.168.2.10:/ export/home Después se configuró el archivo /var/yp/Makefile, el cual define entre otras cosas que información se compartirá a través de NIS. Debido a la exten- sión de este archivo, solo se incluyen algunas de las lineas más importantes para la configuración: 1 # Evita realizar push de los mapas a los servidores esclavos 2 NOPUSH=true 3 # Evita la mezcla de los archivos passwd y shadow 4 MERGE_PASSWD=false 5 # Evita la mezcla de los archivos group y gshadow 6 MERGE_GROUP=false 7 # Objetivos 9
  10. 10. Administración de red, servidores y seguridad 8 all: passwd group hosts rpc services netid protocols netgrp mail 9 shadow auto.master auto.export 10 ... 11 AUTO_LOCAL = $(YPSRCDIR )/ auto.local 12 AUTO_EXPORT = $(YPSRCDIR )/ auto.export 13 ... 14 auto.export: $(AUTO_EXPORT) $(YPDIR )/ Makefile 15 @echo "Updating $@..." 16 -@sed -e "/^#/d" -e s/#.*$$// $(AUTO_EXPORT) | $(DBLOAD) 17 -i $(AUTO_EXPORT) -o $(YPMAPDIR )/$@ - $@ 18 -@$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@ 19 ... Por razones de seguridad, también se substituyó la red 0.0.0.0 por la red local (192.168.2.0) en el archivo /var/yp/securenets. Este paso es importante ya que restringe desde que subredes se podrá accesar a NIS. 1 255.0.0.0 127.0.0.0 2 255.255.255.0 192.168.2.0 Para iniciar el servidor NIS (además de un cliente local) desde el arranque del sistema, se habilitaron los siguientes bloques de configuración en el guión /etc/rc.d/rc.yp: 1 # Configuracion del nombre de dominio 2 if [ -r /etc/defaultdomain ]; then 3 nisdomainname ‘cat /etc/defaultdomain ‘ 4 fi 5 ... 6 # Configuracion del servidor NIS 7 if [ -x /usr/sbin/ypserv ]; then 8 echo "Starting NIS server: /usr/sbin/ypserv" 9 /usr/sbin/ypserv 10 fi 11 ... 12 # Configuracion del servidor de password 13 if [ -x /usr/sbin/rpc.yppasswdd ]; then 14 echo "Starting NIS master password server: 15 /usr/sbin/rpc.yppasswdd" 16 /usr/sbin/rpc.yppasswdd 17 # echo "Starting NIS master password server: 18 # /usr/sbin/rpc.yppasswdd -e chsh -e chfn" 19 # /usr/sbin/rpc.yppasswdd -e chsh -e chfn 20 fi 21 ... 22 # Configuracion del cliente NIS 23 if [ -d /var/yp ]; then 10
  11. 11. Administración de red, servidores y seguridad 24 echo "Starting NIS services: /usr/sbin/ypbind -broadcast" 25 /usr/sbin/ypbind -broadcast 26 fi Como último paso en la configuración, se iniciaron los servicios necesarios a través de los guiones de arranque en /etc/rc.d y se construyeron los mapas con el comando make: # sh /etc/rc.d/rc.rpc start # sh /etc/rc.d/rc.yp # make -C /var/yp 2.2.3. Cliente NIS Para las pruebas de funcionamiento se configuró un cliente NIS utilizan- do el equipo con Ubuntu (192.168.2.11). Al igual que con Slackware, fue necesario instalar los paquetes correspondientes a las herramientas para NIS. $ sudo apt -get install nis Como parte del proceso de instalación con apt-get, se eligió el nombre de dominio NIS correspondiente (en este caso pec). Una vez finalizado, se ejecutó el guión de arranque del servicio portmap. $ sudo /etc/init.d/portmap start * Starting portmap daemon ... [ OK ] Fue necesario además, modificar el archivo /etc/yp.conf para especificar la dirección IP del servidor NIS como se muestra a continuación: ypserver 192.168.2.10 También fue necesario modificar el archivo /etc/nsswitch.conf para especificar que servicios se deben usar (y en que orden) para determinar los archivos de contraseñas, grupos y el automontaje de los directorios de usuario. Particularmente se modificaron las secciones referentes a passwd, shadow, group y automount de la siguiente manera: passwd: compat group: compat shadow: compat hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 11
  12. 12. Administración de red, servidores y seguridad #hosts: files nis networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis automount: nis Una vez realizadas estas configuraciones, se añadió una línea extra (+::::::, +:::, +::::::::) al final de los archivos /etc/passwd, /etc/shadow y /etc/group. Todas estas configuraciones en el lado del cliente se iniciaron ejecutando el guión de arranque de NIS bajo el directorio /etc/init.d. $ sudo /etc/init.d/nis start * Starting NIS services Para comprobar que tanto la configuración del servidor, como del cliente estaba correctas, se siguieron estas serie de pasos que muestran la respuesta del servidor NIS. $ rpcinfo -u localhost ypbind program 100007 version 1 ready and waiting program 100007 version 2 ready and waiting $ ypcat passwd carvid:x:2000:100::/ export/home/carvid :/bin/bash Como prueba final, desde el lado del cliente se inicio una sesión del usuario carvid el cual no se encontraba definido localmente (solamente del lado del servidor NIS), pudiendo autenticarse con éxito: $ ssh -l carvid localhost password: Linux desktop 2.6.22 -14 - generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc /*/ copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY , to the extent permitted by applicable law. carvid@desktop :~$ 12
  13. 13. Administración de red, servidores y seguridad 2.3. Configuración de los servicios FTP y HTTP a) Montar un servidor de ftp que permita también usuarios anónimos teniendo en cuenta cuestiones de seguridad. Los usuar- ios anónimos además de bajar archivos también podrán subir archivos al servidor pero no los podrán borrar una vez subidos. b) Montar un servidor de ficheros vía un servidor web (Apache por ejemplo) que permita que por lo menos un directorio se acceda con usuario y passwd. En esteapartado solo se podrán descargar archivos del servidor (no se podrán subir archivos al servidor). Para gestionar los archivos y usuarios/passwd recomendamos uti- lizar simplemente la interfaz web y acceso a través de .htacces pero también se pueden utilizar módulos específicos por ejemplo WebDav. En ambos ejercicios describir todos los pasos para la instalación, configuración y las pruebas realizadas para verificar su seguridad. 2.3.1. Servidor FTP Para iniciar la configuración del servicio FTP, primero fue necesario in- stalar el paquete de binarios correspondiente. Slackware incluye por defecto dos programas para este fin, ProFTPD y vsftpd. Se optó por configurar ProFTPD, el cual viene en la serie n en los disco de instalación. # installpkg proftp En la instalación de ProFTPD se crea por defecto el usuario ftp así como su directorio en /home/ftp. Se conservó a este usuario tal cual para la configuración de la conexión anónima al servidor, aunque es posible modificar este comportamiento preconfigurado (usar otro usuario, otro directorio, etc). Fue necesario conceder permisos de lectura, escritura y ejecución sobre el directorio /home/ftp al usuario ftp. # chown -R ftp.ftp ftp # chmod 775 -R ftp También fue necesario quitar al usuario ftp del archivo /etc/ftpusers, ya que de lo contrario no se podría acceder al servidor FTP de forma anónima aún cuando todo estuviera correctamente configurado. La instalación de ProFTPD en Slackware viene con un archivo de config- uración por defecto. Este archivo ha sido muy útil ya que solo fue necesario ajustar algunos puntos para lograr las restricciones planteadas. A contin- uación se lista el contenido de archivo /etc/proftpd.conf tal como quedo: 13
  14. 14. Administración de red, servidores y seguridad 1 # Configuraciones generales 2 ServerName "Servidor FTP publico de Carvid" 3 ServerType inetd 4 DefaultServer on 5 6 Port 21 7 Umask 022 8 9 MaxInstances 30 10 11 User nobody 12 Group nogroup 13 14 SystemLog /var/log/proftpd.log 15 TransferLog /var/log/xferlog 16 17 <Directory /*> 18 AllowOverwrite on 19 </Directory > 20 21 # Configuraciones para usuarios conocidos 22 <Global > 23 DefaultRoot ~ 24 DefaultTransferMode binary 25 DisplayLogin .bienvenida.msg 26 MaxClients 30 27 </Global > 28 29 30 # Configuraciones para usuario anonimo 31 <Anonymous ~ftp > 32 User ftp 33 Group ftp 34 UserAlias anonymous ftp 35 36 RequireValidShell off 37 AnonRequirePassword off 38 DisplayLogin bienvenida.msg 39 MaxClients 50 40 41 # Limita todas las acciones de escritura 42 # para el usuario anonimo 43 <Limit WRITE > 44 DenyAll 45 </Limit > 46 47 # Habilita la creacion de directorio y la 48 # subida de archivos 49 <Limit MKD STOR > 14
  15. 15. Administración de red, servidores y seguridad 50 AllowAll 51 </Limit > 52 53 </Anonymous > Una vez realizada esta configuración, se inició el servicio FTP utilizando el daemon inetd. Para ello fue necesario habilitar una línea en el archivo /etc/inetd.conf: 1 ... 2 # Profesional File Transfer Protocol (FTP) server. 3 ftp stream tcp nowait root /usr/sbin/tcpd proftpd 4 ... Para comprobar que el funcionamiento del servidor FTP fuera el deseado, se inició una sesión desde otro equipo en la red local utilizando el usuario anónimo: $ ftp 192.168.2.10 Connected to laptop. 220 ProFTPD 1.3.1 Server (Servidor FTP para la PEC 3) [:: fff f:192.168.2.10] Name (latop:desktop ): anonymous 331 Anonymous login ok , send your complete email address as your password Password: 230 Anonymous access granted , restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp > Una vez iniciada la sesión, se utilizó el comando ls para listar el contenido del directorio. Desde luego al ser esta la primera sesión, el directorio no contenía ningún archivo. ftp > ls 200 PORT command successful 150 Opening ASCII mode data connection for file list 226 Transfer complete Para comprobar que efectivamente la configuración del servidor permitía subir archivos, se intentó transferir el archivo bienvenida.msg de la siguiente manera: 15
  16. 16. Administración de red, servidores y seguridad ftp > put bienvenida.msg local: bienvenida.msg remote: bienvenida.msg 200 PORT command successful 150 Opening BINARY mode data connection for bienvenida.msg 226 Transfer complete 80 bytes sent in 0.00 secs (1474.1 kB/s) Lo anterior indica que la transferencia se realizó con exito, para corrob- orarlo se listó otra vez los archivos del directorio: ftp > ls 200 PORT command successful 150 Opening ASCII mode data connection for file list -rw -r--r-- 1 ftp ftp 80 Dec 17 16:04 bienvenida.msg 226 Transfer complete Se puede apreciar que directorio ahora no se encuentra vacío. Final- mente, con la finalidad de probar que los archivos una vez en el servidor no pueden ser borrados por el usuario anónimo, se intentó eliminar el archi- vo bienvenida.msg usando el comando delete: ftp > delete bienvenida.msg 550 bienvenida.msg: No such file or directory El servidor ha impedido la eliminación del archivo bienvenida.msg, re- gresando como respuesta el mensaje de error no se ha encontrado el archivo o directorio. 2.3.2. Servidor HTTP Como parte del proceso para levantar el servicio HTTP, fue necesario instalar el paquete del servidor web Apache que incluye Slackware como parte de la distribución. # installpkg httpd -2.2.8 - i486 -1. tgz El proceso de instalación crea una estructura de archivos bajo /etc/httd con las configuraciones por defecto para el servidor (muchas de ellas inicial- mente desactivadas). Siguiendo esta estructura de configuración propuesta por Slackware, se ha creado el archivo /etc/httpd/extra/httpd-ftpdir.conf con el siguiente contenido: 16
  17. 17. Administración de red, servidores y seguridad 1 # Configuraciones para el directorio ftp via web 2 # 3 Alias /ftp /home/ftp 4 <Directory /home/ftp > 5 AllowOverride None 6 Options Indexes 7 IndexOptions FancyIndexing 8 Order allow ,deny 9 Allow from all 10 11 # Autenticacion 12 AuthType Basic 13 AuthName "Directorio FTP" 14 AuthBasicProvider file 15 AuthUserFile /usr/local/apache/passwd/passwords 16 Require valid -user 17 </Directory > Esta configuración permite que desde cualquier sitio se pueda acceder al directorio /home/ftp por medio del alias /ftp (directivas Order y Allow). También desabilita el poder de añadir configuraciones extras desde un archi- vo .htaccess, útil ya que el directorio /home/ftp es de acceso público a través de protocolo FTP (directiva AllowOverride). Finalmente requiere que el acceso sea restringido a través un usuario y contraseña que exista en el archivo /usr/local/apache/passwd/passwords, por lo que fue necesario crear dicho archivo usando el programa htpasswd: # htpasswd -c passwd carlos New password: Re -type new password: También fue necesario modificar un par de lineas en el archivo /etc/httpd/http.conf para que incluyera el nuevo archivo de configuración: ... # Fancy directory listings Include /etc/httpd/extra/httpd -autoindex.conf # Configuracion de acceso al directorio /home/ftp Include /etc/httpd/extra/httpd -ftpdir.conf ... Finalmente se concedieron permisos de ejecución al guión de arranque /etc/rc.d/rc.httpd para que el servicio HTTP esté disponibles desde el inicio del sistema. 17
  18. 18. Administración de red, servidores y seguridad Para comprobar el funcionamiento del servidor, se acceso desde un nave- gador a la dirección: http://192.168.2.10/ftp. Al tratar de acceder a este url, se desplegó un dialogo para introducir usuario y contraseña. Fue hasta que se proporcionaron estos datos que se mostró el listado de archivos disponibles vía web. 3. Administración de seguridad 3.1. Implementación de firewall Implementar un firewall, que sólo permita acceso a Apache y SSH desde una(s) IP(s) determinadas descartando (DROP) todos los restantes paquetes. Verificar desde una máquina externa que el firewall funciona analizando que puertos permanecen abiertos utilizando alguna de las herramientas propuestas como nmap. En caso de no disponer otra máquina para probar el firewall se puede utilizar alguno de los sitios web que permiten verificar el acceso como por ejemplo GRC (http://grc.com) a través de ShieldsUP! Como resultado del ejercicio se debe incluir que pasos se han seguido en la configuración, una descripción de cada regla y las verificaciones realizadas de funcionamiento. Para este ejercicio se eligieron tres equipos dentro de la red local. El servidor http y ssh (192.168.2.10) y dos máquinas clientes (192.168.2.11 y 192.168.2.13) para realizar las pruebas del firewall una vez configurado. Además de los servicios de http y ssh, el servidor tenía una serie de puertos abiertos como se puede observar en la salida del comando netstat: $ netstat -lut Active Internet connections (only servers) Proto Recv -Q Send -Q Local Address Foreign Address State tcp 0 0 *: nfsd *:* LISTEN tcp 0 0 *: time *:* LISTEN tcp 0 0 *:47241 *:* LISTEN tcp 0 0 *:x11 *:* LISTEN tcp 0 0 *: auth *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 *:45336 *:* LISTEN 18
  19. 19. Administración de red, servidores y seguridad tcp6 0 0 [::]: http [::]:* LISTEN tcp6 0 0 [::]: x11 [::]:* LISTEN tcp6 0 0 [::]: ssh [::]:* LISTEN udp 0 0 *: biff *:* udp 0 0 *: nfsd *:* udp 0 0 *: time *:* udp 0 0 *:59831 *:* udp 0 0 *:37829 *:* Para prevenir el acceso a otros puertos que no fueran el 80 (http) o el 22 (ssh), se configuraron reglas de filtrado con iptables de la siguiente manera: # iptables -A INPUT -p tcp --dport 22:80 -s 127.0.0.1 > -d 192.168.2.10 -j ACCEPT # iptables -A INPUT -p tcp --dport 22:80 -s 192.168.2.11 > -d 192.168.2.10 -j ACCEPT # iptables -A INPUT -p tcp --dport 22:80 -s 192.168.2.12 > -d 192.168.2.10 -j ACCEPT # iptables -A INPUT -p tcp -d 192.168.2.10 -j DROP # iptables -A INPUT -p udp -d 192.168.2.10 -j DROP Las primeras tres reglas permiten el acceso a los puertos 22 y 80 a las direcciones 127.0.0.1 (localhost), 192.168.2.11 y 192.168.2.12 cuando la dirección destino sea 192.168.2.10 (servidor). Las últimas dos lineas desechan todos los paquetes entrantes por el protocolo tcp y udp. Con lo anterior se consigue evitar que cualquier otra IP, que no sea las configuradas en las primeras tres líneas, pueda acceder a los puertos abiertos. Para corroborar el funcionamiento del las reglas recién configuradas, se utilizó el programa nmap desde dos equipos diferentes. Desde el primer equipo, el cual fue configurado para poder acceder a los servicios (192.168.2.11), se obtuvieron los siguientes resultados: $ nmap -sT 192.168.2.10 Starting Nmap 4.53 ( http :// insecure.org ) at 2008 -12 -14 19: 45 CST Interesting ports on laptop (192.168.2.10): Not shown: 1655 filtered ports , 56 closed ports PORT STATE SERVICE 22/ tcp open ssh 37/ tcp open time 80/ tcp open http Nmap done: 1 IP address (1 host up) scanned in 5.093 seconds 19
  20. 20. Administración de red, servidores y seguridad Se puede observar que de los 15 puertos abiertos en el servidor (listados con el comando netstat), solo se han conseguido detectar tres. Las reglas de filtrado configuradas han evitado revelar el resto de los puertos, a excepción del 37 (por alguna extraña razón escapo al filtrado). Como segunda prueba se escogío una computadora cliente que no estu- viera en las primeras tres reglas (192.168.2.13), es decir que no debería poder acceder a ningún puerto del servidor. $ nmap -sT 192.168.2.10 Starting Nmap 4.53 ( http :// insecure.org ) at 2008 -12 -14 19: 46 CST Note: Host seems down. If it is really up , but blocking our ping probes , try -PN Nmap done: 1 IP address (0 hosts up) scanned in 2.091 seconds El resultado fue que nmap no detectó ningún puerto abierto en el sevidor, por lo que las reglas de filtrado cumplieron su proposito. 3.2. Análisis de seguridad Tomando como referencia el capítulo de Administración de seguridad, realizar un análisis de seguridad completo de vuestra máquina centrado en la utilización de herramientas y archivos de información/configuración (generados por Uds o del sistema). Se deberá analizar: a) si han habido o no (intentos) intrusiones (comentando que se ha analizado y como han llegado a la con- clusión final), b) un análisis de seguridad de local, y c) un análisis de seguridad de red. El resultado final deberá ser un informe que permita definir los puntos débiles y su corrección y si no los hay que se ha analizado para llegar a esta conclusión. 3.2.1. Detección de intrusiones Lo primero que se hizo fue revisar las sesiones activas, haciendo uso del comando who, y verificar que todos los usuarios fueran validos, no hubieran estado un autenticados un periodo anormal de tiempo y que no estuvieran corriendo software sospechoso. A continuación se presentan los resultados de la ejecución del comando who en el servidor: # who carvid pts/0 Dec 16 19:32 (desktop) En esta salida no se aprecia ninguna evidencia clara de intrusión ya que carvid es un usuario valido y desktop (192.168.2.11) una ubicación per- mitida. 20
  21. 21. Administración de red, servidores y seguridad También se han revisado los procesos en ejecución del sistema, para esto se usó el comando ps. Básicamente se puso atención en aquellos procesos que hubieran tomado mucho tiempo, hubieran iniciado a horas inusuales, tuvieran nombres desconocidos o consumieran gran porcentaje del CPU. En este análisis no se encontró nada fuera de lo común y que diera indicios de una posible intrusión. El siguiente paso fue indagar en búsqueda de huellas que un intruso pudiera haber dejado. Lo primero que se hizo fue verificar que el archivo /var/log/wtmp existiera, la falta de el sería una clara evidencia de intrusión. Una vez verificada la existencia de wtmp se corrió el comando last: # last carvid pts/0 desktop Tue Dec 16 19:26 - 19:44 (00:18) carvid pts/0 desktop Mon Dec 15 11:04 - 11:53 (00:48) carvid pts/0 desktop Thu Dec 11 13:07 - 13:08 (00:00) carvid pts/0 desktop Thu Dec 11 08:48 - 08:58 (00:10) carvid pts/1 desktop Wed Dec 10 19:30 - 19:41 (00:11) carvid pts/0 desktop Wed Dec 10 19:26 - 20:00 (00:34) carvid pts/0 desktop Wed Dec 10 12:17 - 12:36 (00:19) carvid pts/0 desktop Sat Dec 6 12:52 - 14:51 (01:58) carvid pts/0 desktop Fri Dec 5 19:45 - 20:32 (00:47) carvid pts/0 desktop Mon Dec 1 10:34 - 10:42 (00:08) En los resultados obtenidos tampoco se observó ninguna entrada sospe- chosa ya que tanto los tiempos de acceso, como la permanencia en el sistema fueron normales en relación a las actividades de los usuarios. Además de los resultados de last también se revisaron los archivos /var/log/syslog y /var/log/messages en búsqueda que cosas fuera de lo ordinario, como fallos en el inicio de sesión o intentos de su por parte usuarios no autorizados. Esta revisión tampoco mostró datos que implicaran algún intento de intrusión. Finalmente se hizo una exploración del sistema de archivos, revisando todos aquellos que hubieran sido modificados en los últimos días usando el comando find. Se puso especial atención en los resultados que involucraran los directorios /bin, /sbin, /usr/bin y /usr/sbin ya que pudieran ser sín- toma de la implantación de un troyano. En este análisis tampoco se detectó una actividad sospechosa. 21
  22. 22. Administración de red, servidores y seguridad La conclusión de este análisis es que es poco probable que hubiera una intrusión en el sistema. Cabe hacer mención que no existe la completa se- guridad de que esto sea así, ya que cada uno de los métodos presenta debil- idades propias (p.e. eliminación de entradas en los logs, archivos, alteración de fechas, etc) y que un atacante experimentado conoce perfectamente. 3.2.2. Seguridad Local Se hizo una revisión de los siguientes puntos en el sistema Slackware (192.168.2.10): Característica Disponibilidad BIOS con contraseña no Bootloader con contraseña no Reinicio con CTRL+ALT+DEL sí Lilo.conf seguro (600) no (644) Contraseñas en shadow sí Contraseñas encriptadas con MD5 sí Archivos .rhost no Archivo /etc/host.equiv no Archivo /etc/host.lpd no Modulos PAM no Auditoria de cambios no De la tabla anterior las vulnerabilidades más urgentes de solucionar pre- sentadas por el sistema son: la carencia de contraseña para entrar a la con- figuración del BIOS, la posibilidad de reiniciar el equipo con la secuencia de teclas CTRL+ALT+DEL y la posibilidad de especificar parámetros de inicio en el arranque del sistema con lilo. Además sería muy conveniente implementar un mecanismo de auditoría de cambios que permitiera evaluar si el sistema ha sufrido alguna alteración relacionada con la introducción de troyanos o puertas traseras (backdoors). 3.2.3. Seguridad de Red En este rubro se analizaron los puertos que el sistema tenía abiertos, ya sea a través de inetd o a través de los guiones de arranque específicos para ciertos daemons. La siguiente tabla muestra los puertos encontrados así como una breve descripción de su función. 22
  23. 23. Administración de red, servidores y seguridad Puerto Servicio Descripción 21/tcp ftp Protocolo de transferencia de archivos (proftpd daemon) 22/tcp ssh Protocolo Secure Shell (sshd daemon) 37/tcp time Protocolo time 80/tcp http Protocolo de transferencia de hipertexto (httpd daemon) 111/tcp sunrpc Servicio de mapeo de números RPC 113/tcp auth Protocolo ident (identd daemon) 512/udp biff Sistema de notificaciones de correo para UNIX (comsat daemon) Además de estos puertos, también existen otra serie de puertos relaciona- dos con los programas RPC (como los servicios NFS y NIS). Haciendo uso del programa rpcinfo se obtuvieron los siguientes resultados: # rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100005 1 udp 59831 mountd 100005 1 tcp 47241 mountd 100005 2 udp 59831 mountd 100005 2 tcp 47241 mountd 100005 3 udp 59831 mountd 100005 3 tcp 47241 mountd 100021 1 udp 37829 nlockmgr 100021 3 udp 37829 nlockmgr 100021 4 udp 37829 nlockmgr 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 tcp 45336 nlockmgr 100021 3 tcp 45336 nlockmgr 100021 4 tcp 45336 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100024 1 udp 39385 status 100024 1 tcp 47565 status 100004 2 udp 1011 ypserv 100004 1 udp 1011 ypserv 100004 2 tcp 1014 ypserv 100004 1 tcp 1014 ypserv 100009 1 udp 1013 yppasswdd 100007 2 udp 1017 ypbind 100007 1 udp 1017 ypbind 100007 2 tcp 1020 ypbind 100007 1 tcp 1020 ypbind Como resultado de este análisis, algunas acciones se pueden tomar para mejorar la seguridad de la red: 23
  24. 24. Administración de red, servidores y seguridad Configurar el servicio FTP para que solo acepte las conexiones del usuario anónimo, los usuarios del sistema pueden utilizar sftp que es más seguro. Apagar los servicios time y biff los cuales no son utilizados y no es necesario tener abiertos. Valorar el uso de los servicios NFS y NIS por los riesgos de seguridad que pueden implicar Realizar una buena configuración de reglas con iptables para no cualquier usuario pueda alcanzar los puertos abiertos 24

×