Administración de red servidores y seguridad

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

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 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

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
--- 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

se reinicie el sistema, automáticamente se levantara la interfaz de red con la
conﬁguració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,
especiﬁcando 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
--- 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

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

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

# 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

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 ﬁnalidad
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 conﬁgu-
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

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

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 conﬁguració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

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

#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

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

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

50 AllowAll
51 </Limit >
52
53 </Anonymous >
Una vez realizada esta conﬁguració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 conﬁguración del servidor permitía
subir archivos, se intentó transferir el archivo bienvenida.msg de la siguiente
manera:
15

ftp > put bienvenida.msg
local: bienvenida.msg remote: bienvenida.msg
150 Opening BINARY mode data connection for bienvenida.msg
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
150 Opening ASCII mode data connection for file list
-rw -r--r-- 1 ftp ftp 80 Dec 17 16:04 bienvenida.msg
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

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

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

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
> -d 192.168.2.10 -j ACCEPT
> -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

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

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)
(00:34)
(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

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

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 biﬀ Sistema de notiﬁcaciones 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
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 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

Conﬁgurar 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 conﬁguración de reglas con iptables para no
cualquier usuario pueda alcanzar los puertos abiertos
24

Administración de red servidores y seguridad

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Administración de red servidores y seguridad

Semelhante a Administración de red servidores y seguridad (20)

Mais de Emilio

Mais de Emilio (7)

Último

Último (20)

Administración de red servidores y seguridad