|
|
[0.0] Introduccion.
[0.1] Seguridad en Sistemas.
[0.2] Usuarios. Grupos. Passwords.
[0.3] CHRoot. Estructuracion del Arbol de Directorios.
[0.4] Sistema de Ficheros EXT2. Seguridad Implicita.
[0.5] Tipos de Ficheros.
[0.6] Permisos.
[0.7] SGID. SUID. UMask.
[0.8] Registros y Logs. SYSLOGd. Tipos de Registros.
[0.9] LiLo. LiNUX Loader.
[1.0] Teoria de Acceso Remoto. Modems.
[1.1] Maquinas de Red.
[1.1.1] Firewalls.
[1.1.2] Routers de Seleccion.
[1.1.3] Gateways.
[1.1.4] Bastions Hosts.
[1.1.5] Posibles Arquitecturas de Firewall. Sistemas 'Screened'.
[1.2] Referencias.
Introduccion.
En este documento tratare de ser lo más explícito posible, comentando aquellos
puntos que considere de vital importancia. El documento será enfocado mas hacia
la rama GNU/LiNUX, y siempre teniendo en cuenta que sea cual sea el SO de su
red, es importante mantener y conocer bien la estructura con la que se trabaja.
Comencemos pues x).
Seguridad en Sistemas.
Ante todo, y siempre cuando de montar y administrar una IntraNET se trata, se
plantea el problema de la seguridad y de los accesos a la misma. Principalmente,
hemos de saber cual es el fin que buscamos y contra qué o quién estamos defendiéndonos.
Un problema que he encontrado muchas veces a la hora de instalar es la definición
del término "seguro". Cuando hablamos de seguridad, no solo hemos de tomar precauciones
por conexiones no permitidas, por usuarios ajenos, sino también hemos de dar
un grado de robustez y fiabilidad a nuestras maquina de forma que la red sea
una piña.
Hemos de verificar que todo sistema que decidamos sea apto para responder, que
tenga la capacidad de depender o no de otros, y que actúe en consecuencia.
Un punto a nuestro favor es el conocimiento de nuestra estructura y planificación
de la red, de los sistemas operativos que actúen en ella, de los nodos de vital
importancia en la misma, etc. Existen numerosas herramientas de tipo ADM que
permiten catalogar el grado de robustez que posee un sistema, tales como SATAN,
O Nessus.
En lo referente a confidencialidad, hemos de tomar las oportunas precauciones
para que cada elemento sea solamente accedido por su propietario o personal
autorizado. La integridad de la informacion contenida no debe verse comprometida
por ningún usuario no apto y/o permitido en ningún momento.
El sistema debe estar disponible siempre que se le necesite y debe regular por
sí mismo quien puede acceder a sus recursos. Por el bien de todos, o más bien,
por la propia cabeza del administrador, es conveniente tener un buen sistema
de registro tal como SysLogd, que viene de serie con distribuciones LiNUX, o
similar. Considero oportuno decir, aunque Syslogd es una parte de esta serie
de charlas, que syslog no contiene funciones tales como controlar recibimiento
de paquetes I*MP, secuencias UDP , etc...
Usuarios. Grupos. Passwords.
Llegado a este punto, vamos a retomar brevemente el tema de usuarios en LiNUX.
Para el nuevo Windows 2000, sinceramente, consulten las webs oficiales de Microsoft
Corp, debido a que yo, y siento decirlo, no malgasto mi tiempo en analizar un
sistema operativo con mas de 63000 bugs declarados. ;-)
Ante todo, el usuario va a ser el objeto clave en nuestra red. De él dependerán
multitud de situaciones que afectaran, directa o indirectamente, al funcionamiento
de un sistema informático.
En 1º lugar, una normativa BASICA, y recalco, BASICA, será la de responsabilizar
al usuario de toda acción que sea llevada a cabo desde su acceso al sistema.
Ya sea en nuestra red, en una red externa a ella, o donde fuere, el uso de su
identificación le será achacada a él. Esto implica que el usuario, al aceptar
estos términos, totalmente legales, si se arriesga a liberar su acceso a terceros,
cargará él con la culpa de cualquier acción realizada desde su cuenta.
Otro aspecto a tener en cuenta, es la clave de acceso o PASSWD. Es un punto
de debilidad el uso de contraseñas tales como Nombre, Apellido, DNI... Si queremos
que el sistema de contraseñas sea aun más seguro, deberemos de ser NOSOTROS
quienes le asignemos una contraseña, y dar un tiempo de caducidad a esta ultima.
Un simple script en Perl, con la función RANDOM nos generara las secuencias
de caracteres que deseemos dependiendo de un valor introducido. Así pues, para
dar una periodicidad al passwd, podremos ejecutar:
> passwd -x dias_en_actividad usuario_local
Podríamos programar un tipo de fichero activo en procesos Back, tal que revise
estos datos cada vez que un usuario acceda al sistema y, mantenga al administrador
sobre aviso vía email de los próximos cambios de los próximos X días para los
usuarios US1, US2 ...
Otro elemento base, es la posibilidad de permitir el cambio de passwds a un
grupo predefinido en el sistema, mediante los comandos:
> chgrp GRUPO_PSWD /bin/passwd
> chgrp GRUPO_PSWD TODO_AQUELLO_QUE_USEMOS_EN_PSWDS
> chmod 4750 /bin/passwd
> chmod 4750 TODO_AQUELLO_QUE_USEMOS_EN_PSWDS
Tambien es recomendable comentar brevemente la existencia de SHADOW, una forma
de enmascarar los passwords en el fichero /etc/passwd evitandose asi su lectura
por parte de los usuarios. El fichero /etc/passwd debe tener permisos de lectura
a todos los usuarios para realizar el login correspondiente. Es por ello que
SHADOW enmascara en /etc/passwd las contraseñas y las inscribe en el fichero
/etc/shadow, de solo posible lectura para el superusuario.
Respecto a los Grupos, debemos tener exactamente las mismas precauciones que
con los usuarios, siempre adecuandolos al plan inicial de montaje de la Red.
Una buena política de grupos nos hará mas eficiente las restricciones necesarias
a diversas zonas calientes del sistema y limitaran mejor los suid root.
Para mas informacion acerca de Creación, Eliminación y Administración de Usuarios
y Grupos, UID, GID, etc, remítase al LiNUX Administration BookLab, disponible
en la web http://www.metalab.edu/.
CHRoot. Estructuración del Árbol de Directorios.
¿ Que es CHRoot ? CHRoot es una forma de alterar la estructura actual de directorios
para un proceso especifico. Esto deniega cualquier acción o uso de documentos,
ficheros, etc que se hallen fuera del roto ('/') actual. Su uso es útil y eficaz,
pero hemos de tener cuidado. Se recomienda analizar los contenidos 'man' de
CHRoot, disponibles en toda distribución LiNUX que se aprecie ;-)
CHRoot posee dos métodos de inicio: 1) Mediante llamada en Terminal (Comando)
2) Mediante llamada propia al Sistema.
CHRoot necesita ser invocado por el administrador del maquina, (roto), lo cual
nos deja patente lo peligroso que puede ser.
CHRoot prepara todo aquello necesario para que todo proceso que se inicie dentro
del nuevo árbol, dependa de él, e incluso, si se ejecutase otra llamada a CHRoot,
esta sería hijo del CHRoot(1).
En lo relativo al uso de Librerías, ejecutables, ficheros, etc que se necesiten,
es recomendable trazar los ejecutables (siempre que se pueda, y se tenga ganas,
tiempo y dedicacion ;-) ) y se copie y/o enlace mediante "hard" esos ficheros
originales a su destino futuro tras el CHRoot.
Un consejo es el de no utilizar ningún programa tal que necesite de SUID. Ah!
Se me olvidaba ... CUALQUIER proceso abierto ANTES del CHRoot no se vera afectado
por este, lo cual incluye un punto débil de seguridad en el sistema. Es NECESARIO
revisar procesos como CRON, AT, LPD, etc tales que usan SUID.
Nunca deberemos hacer cambios en el Kernel, como p.e. montar módulos o eliminarlos,
montar sistemas de ficheros en modo escritura, etc... También deberemos restringir
dichos movimientos a posibles "atacantes" que consigan explotar este nuevo montaje.
El uso de CHRoot es muy útil pero peligroso. Debemos andar con pie de plomo
si, por ejemplo, tratamos de estandarizar un script que nos facilite la tarea,
p.e., en Perl, respecto a los procesos actuales y/o que permisos daremos.
Sistema de Ficheros EXT2.
Hemos hablado de SUID, SGID, Passwds, etc... Pero donde realmente se almacena
la informacion y de que forma se estructura en LiNUX?
La respuesta es bien sencilla. Si bien en sistemas operativos como Microsoft(R)
Windows(TM) utilizamos sistemas de ficheros FAT*, en GNU/LiNUX, nuestro anfitrión
es EXT2.
Como bien sabréis, y si no, pues os lo defino ;-), el sistema de ficheros es
la forma de estructurar la informacion en medios tales que mantendrán esta informacion
durante un cierto periodo de tiempo (si, digo bien, no sabemos aun lo que ocurre
con informacion almacenada en discos duros que se guarda y no se vuelve a tocar
hasta 20 años después ;-)). Es decir, es la forma en la que el sistema puede
acceder a la informacion que posee, de modo que sea directo, lo más sencillo
posible y con la mayor fiabilidad (es ciertos casos, esto no ocurre, un ejemplo,
las primeras versiones de NTFS 5.0).
Bien, lo que nos aborda ahora mismo es EXT2. Este sistema de ficheros esta basado
en árbol de directorios, de cuya raíz (roto), cuelgan todos los directorios
y subdirectorios, además de los ficheros.
Un elemento importante de EXT2 es el tratamiento de todo elemento del sistema
como fichero, es decir, tanto discos duros, cdroms, floppy, tarjeta de sonido,
ratón... Todo es considerado como fichero.
El sistema de ficheros EXT2 mantiene como unidad principal el iNodo o Nodo Índice.
Su función es
almacenar informacion relativa a cada fichero y/o directorio. Los iNodos contienen
toda la informacion relevante al archivo o directorio sobre el cual actúan.
La informacion residente en un iNodo es bastante amplia (unos 10 parametros)
entre los que se encuentran el tipo de objeto (archivo y su tipo, directorio
...), el UID del poseedor del mismo, GID al que pertenece el poseedor del objeto,
numero de links que tiene ese objeto ... Podemos analizar la estructura del
iNodo en el fichero <ext2_fs.h>
Existen otros tipos de Nodos, tales como cNodes, los vNodes, los sNodes ...
Pero no nos interesa hoy por hoy su informacion ;-)
También decir, que se me olvidaba, que cada fichero posee una ruta de acceso,
la cual le define, dice donde se halla. Dado esto, surge la necesidad de declarar
una variable de entorno, PATH, normalmente localizada en el bash_rc, o en el
profile (más raro, pero puede) del usuario. Nunca deberemos contener el directorio
actual de trabajo ( ./ ) en el PATH.
Es una herramienta de inseguridad si trabajamos con programas SUID o SGID, ya
que es posible la "captura" del acceso administrador mediante los keyloggers,
que guardaran todo lo tecleado (para mas info, revise http://www.rootshell.com
o http://neworder.box.sk/).
Tipos de Ficheros.
Veamos los posibles tipos de ficheros disponibles en GNU/LiNUX. Tendremos que
hacer un listado de ficheros, de forma que se nos muestre la informacion relativa
a derechos y tipos de ficheros. La opción 'ls -la', nos mostrara lo siguiente
en el primer carácter de derechos del objeto:
* d -> El objeto es un directorio.
* s -> El objeto es un socket.
* l -> El objeto es un enlace simbólico. (ln -s).
* - -> El objeto no contiene informacion valida para el
sistema.
Los archivos relativos a dispositivos se hallan bajo el directorio '/dev/',
donde podemos hallar, entre otros:
* hd** -> Discos Duros IDE.
* sd** -> Discos Duros SCSI.
* fd* -> Unidades Floppy.
* lp* -> Puertos Paralelos.
* ppp* -> Interfaces PPP.
* ippp -> Interfaces RDSI.
* ttyS* -> Puertos Seriales.
* psaux -> Puerto PS2.
* null -> Es el 'reciclador' de LiNUX ;-)
Existen otros referentes a áreas del Kernel, generadores, etc.
Permisos y Derechos.
Hemos tratado de forma indirecta los famosos permisos. Bien, definamos permiso
como un conjunto octal ( del 0 al 7 ) que definirá que tipo de acceso permitimos
en estos tres niveles:
1) Poseedor del Objeto.
2) Grupo del Objeto.
3) Resto de Usuarios.
Cada punto anterior esta compuesto por una tripleta, rwx [ <r> (read),
<w> (write) y <x> (execute) ] de forma que podamos definir los valores
necesarios para cada "posible ejecutor" del objeto.
Para asignar derechos, usaremos el comando CHMOD de LiNUX con una secuencia
octal que definirá los derechos al objeto. Los valores numéricos asignables
son:
* 0 -> Nada.
* 1 -> x
* 2 -> w
* 3 -> wx
* 4 -> r
* 5 -> rx
* 6 -> rw
* 7 -> rwx
Por lo tanto, imaginemos que queremos dar total derecho al propietario, solo
lectura y ejecución al grupo, y lectura al resto:
> chmod 754 Objeto
Chmod lleva implícito un Flag para recursividad en directorios y su contenido,
'-R', que actuara sobre todo aquello contenido en una ruta especificada.
SGID. SUID. UMask.
La Umask ... ¿ Qué es la Umask ? :? Pues bien, es bastante sencillo, es el conjunto
de valores que serán por defecto los permisos de un fichero o directorio creado
nuevo. Esta formada por un grupo de 4 números en octal, luego del 0 al 7 [0..7].
Los valores por defecto son Umask(666) para ficheros NO ejecutables recién creados,
y Umask(777) para aquellos que lo son. Podemos ver el consecuente riesgo de
seguridad que supone MANTENER los Umask por defecto.
Pero para que esta aquí el Admin? Hombre, aunque no suela pensar muy a menudo,
a veces lo hace ... :-P. Mediante el comando Umask podemos reasignar los valores
que consideremos oportunos, por lo cual, es completamente moldeable a las necesidades
del Admin y sus maquinas.
Umask funciona de la siguiente forma:
> umask 027
Estamos dando el valor 027 al Umask. Ahora Umask hará lo siguiente: operara
mediante una operacion logica AND, los valores por defecto (666 ó 777) con el
complementario del valor asignado ahora, es decir, el 027. Esto nos produce
el valor - 640 - para un NO ejecutable. Por lo tanto, ahora tendremos el valor
640 para ficheros no ejecutables.
Vamos a tocar un poco los SUID y los SGID. Ambos son valores permisiales tales
que suplementan la UID y/o el GID del usuario en el período de ejecución. La
programación utilizando estos métodos es bastante amplia, pero lo consecuente
es que el Adm. mantenga bajo conocimiento aquellos scripts, programas, etc que
manejan estos "servicios" a su disposición.
Para buscar CUALES de los ficheros del sistema utilizan estos métodos, deberemos
revisar los permisos de éstos, si son 4000 (SUID) O 2000 (SGID). La verdad es
que una búsqueda recursiva nos ayudaría mucho, no? :-P
> find / \(-perm -004000 -o -perm -002000 \) -type f -print
o si queremos por un nombre o cláusula especifica:
> find / \(-perm -004000 -o -perm -002000 \) -type f -print -name *nombre*
Un ejemplo de programas que ejecuten o necesiten SUID es por ejemplo el 'passwd'.
También decir que existen Flags en determinados comandos ( -suid ) que permiten
que el programa NO UTILICE suid. Por ejemplo, el comando 'mount':
> mount -o nosuid dispositivo ruta.
Registros y Logs. SYSLOGd. Tipos de Registros.
En todo sistema que se precie, deberá existir un sistema o daemon de registro
de todo aquello que afecta al equipo informático. En Windows NT *.0, el sistema
de Log incorporado es bastante básico y muy abstracto. En GNU/LiNUX nos encontramos
con un demonio algo mas completo y fiable, el Syslogd.
Normalmente, nos podemos encontrar en las distribuciones base, los archivos
de Log en /var/log. Los ficheros contenidos aquí son relativos a eventos de
seguridad, efectos al Kernel, permisos, impresoras, email, etc.
Vamos a comenzar con aquel que le indica al usuario CUANDO utilizo por ultima
vez su cuenta en el sistema, es decir, cuando accedió por ultima vez al mismo.
Esta info se puede ver cuando iniciamos una nueva sesión (login) o mediante
un 'finger' a ese usuario. Esta informacion aparece reservada en el fichero
'lastlog'.
La informacion de lastlog, al igual que los *tmp, se almacena en codigo binario.
Las modificaciones LAST son accesibles a los usuarios por defecto. El fichero
'utmp' almacena los usuarios actualmente dentro del sistema, aquellos que al
hacer un 'who', un 'finger', o similar, nos revela quien esta logged in ;-).
Este fichero se halla disponible en /var/run.
El fichero 'wtmp', disponible en /var/log, guarda info acerca de entradas y
salidas de usuarios en el sistema. El comando 'last' nos permite acceder a la
info contenida en el. Su uso sería:
> last usuario
Y nos revelaría la info solicitada. El único problema que contiene wtmp es que
no almacena los SUID realizados por el usuario X, manteniéndose su ID constate.
Ambos ficheros, *tmp, almacenan la siguiente informacion: 1) Usuario 2) Terminal
3) Direccion IP 4) fecha y hora de conexion 5) fecha y hora de desconexion.
Al quizás yo le preste mas atención, es el 'messages', llamado así porque nos
da la gana ;-) Luego veremos por que ;-). 'messages' es un fichero disponible
normalmente en /var/log, que almacena la informacion que nosotros le indiquemos
desde la configuración de syslog.
Es un fichero de tipo texto, (Text.File_Type) de forma que es legible para todos
con un simple editor. En 'messages' se suele almacenar los accesos, los SUID
realizados por los usuarios, aquellas conexiones fallidas, etc etc ...
Existen otros ficheros dentro de /var/log como son 'mail', 'lp_*', etc ... Que
contienen aquella informacion relativa a sus daemons.
Syslog es un daemon muy centralizador, y por tanto, bastante bueno. Una gran
ventaja que tiene syslog es la posibilidad de ofrecer sus servicios a otros
programas. Se le puede llamar para permitir logear aquello que un programa necesite.
Syslog cuenta con un fichero de config, /etc/syslog.conf, que contiene informacion
IMPORTANTE acerca de donde se hallan los ficheros de Logs (Ojo ;-)) y de sus
contenidos. Es decir, que guardan esos ficheros ... Normalmente, y dependiendo
de como este todo montado, se debe restringir la lectura al fichero, con modo
700 sobre el roto, de forma que nadie pueda analizar donde se hallan los preciados
logs. Puede también ser peligroso dar esos derechos, así que cuidado con lo
que se hace.
Bajo Perl, existe un modulo dedicado a Syslogd, realizado por Larry Wall y Tom
Christiansen bastante bueno que nos permite el uso de syslog para CGIs, DBIs,
LWPs, etc ... esta disponible en la web de la CPAN en http://www.perl.com/CPAN.
Para aquellos que estéis interesados en mayor info sobre Syslogd o SysKlogd,
podéis echarle un vistazo al 'man' de syslog, donde se os comentan los niveles
de prioridad, los tipos de propiedades, etc.
Si nos pasamos al bando contrario, podríamos realizar un sencillo script en
Bash o Perl ( a parte de aquellos que hay en C ) para la eliminación de estos
registros. Seria bastante sencillo de realizar con unas simples llamadas al
sistema, y teniendo en cuenta que /var/log tiene permiso de lectura para todos
;-)
Ah! se me olvidaba. A mi, personalmente, me gusta crear una 'vista en tiempo
real' de todo aquello que accede a messages, añadiendo una linea al syslog.conf
que contenga una terminal, como p.e., la numero 10, /dev/tty10, donde podremos
visualizar que esta ocurriendo. también podríamos desviar los logs a otras maquinas
o a una impresora, por que no ;-P.
IPLog es un complemento para analizar intentos de acceso a puertos y envios
de ciertos tipos de paquetes como TCP, I*MP, UDP ... Es un complemento que además
utiliza syslog como medio de logeo en 'messages'. podéis pillarlo, al igual
que muchas otras tools, en nuestro FTP, ftp://ftp.neworking-center.org/.
LiLo. LiNUX Loader.
Bueno, LiLo es la reduccion de LiNUX LoADER, Cargador de LiNUX, el sistema que
permitira el arranque del sistema operativo nombrado. además, permite el inicio
de otros múltiples
sistemas tales como Windows 9X, Windows NT, Windows 2000 ...
LiLo es un programa desarrollado por Werner Almesberger con el fin de poder
iniciar diferentes OSs dependiendo de las necesidades de cada uno.
LiLo, como todos los boot loaders, se inician tras el proceso normal comenzado
por la BIOS del sistema, etc etc ... Para aquellos interesados en sistemas de
arranque, formatos, tipos de boot loaders, opciones, etc, remitanse a numerosos
websites de Internet. (ftp://sunsite.unc.edu/pub/Linux/system/boot/).
Vamos a tratar brevemente el proceso de inicio de un sistema informático, como
base para comprender en que medida actuan y funcionan los gestores de arranque.
En un primer momento, se comprueba que toda la informacion relativa a parametros
de la BIOS almacenada en CMOS es correcta. Tras ello, la BIOS mostrara todos
los parametros actuales con sus respectivos valores y procedera al inicio del
sistema.
Es entonces cuando se ha de buscar, en el orden dado a la BIOS por el usuario,
que dispositivos pueden tener medio de arranque. Imaginemos la secuencia 'A,
C, CDROM', bastante frecuente. Primero se revisara si la unidad A contiene en
su sector de arranque algo que permita el inicio del sistema. Este metodo es
el mismo que con los CDROMs; se analiza su primer sector. Respecto a los discos
duros, se analizara el MBR, Master Boot Record, el cual debe contener el programa
que iniciara el correspondiente sistema operativo. Es decir, tras analizar el
MBR, este iniciara el primer sector de la paghrticion que contiene el sistema
operativo. Este sector esta marcado como ACTIVO.
Numerosos programas nos permiten el analisis de las particiones actuales. El
FDisk, de Microsoft Corp. es uno de ellos, pero a mi, personalmente, 'fdisk'
y 'cfdisk' de LiNUX son los dos que mas me llaman la atención por su amplio
contenido.
Bien, respecto a LiLo, éste puede instalarse en Discos Duros (MBR, Particiones
Primarias, Partiones Extendidas) y/o Disquettes. LiLo se haya limitado a las
opciones de la BIOS, lo cual no indica la mala programación de LiLo, sino las
pauperrimas condiciones de alguna BIOS.
Nuestro gestor de arranque almacena su configuración en el fichero '/etc/lilo.conf'.
Este fichero contendra aquellos valores predefinidos para el inicio de nuestro
sistema, nuestro OS, etc etc ... No considero nada recomendable utilizar configuradores
de LiLo como los aportados por RedHat Software, ya que son una perdida de tiempo
y no permiten adaptar LiLo a nuestro gusto. La cuestion es hacer maleable el
gestor de arranque y eso solo se consigue editando e instalando nuestro fichero
de config. Una edicion basica de lilo.conf seria la siguiente:
boot=/dev/hda1 # Punto de Inicio Priniciapl. Particion Primaria.
compact # Inicio mas rapido. No funciona en todas las situaciones.
install=/boot/boot.d # Cargador de Arranque por Defecto.
vga=normal # Inicio Normal de la Tarjeta de Video.
timeout=30 # Tiempo de espera para seleccionar otro OS.
image=/vmlinuz # Punto desde donde se va a iniciar el Kernel.
root=/dev/hda2 # Raiz del Arbol de Direct. en esa particion.
label=Slackware # Etiqueta de Sistema a Seleccionar.
read-only # Solo lectura.
Las opciones de LiLo que mas nos interesan hoy por hoy, y dado el tema, son
las siguientes:
* APPEND.- Permite pasar parametros formales al Kernel a Iniciar, siempre entre
comillas.
* PASSWORD.- Añadiremos a nuestro lilo.conf la linea JUANA
password=contraseña', siempre en texto plano. De esta
forma podemos restringir el acceso a ciertas imagenes. Si la
contraseña introducida no es, la correcta imaagen no se iniciara. Es
necesario que, y debido al contenido en texto plano de la passwd,
lilo.conf, solo tenga derechos de lectura para el roto.
(Revisar Permisos [*]).
* RESTRICTED.- Es un metodo al mas complejo. La peticion de contraseña SOLO
se vera
ejecutada si el usuario intenta acceder al sistema mediante el paso de
parametros al kernel o forzando la entrada al sistema a traves de consola.
* LOCK.- Esta opción nos permite iniciar SIEMPRE la imagen arranacada por ultima
vez.
Esto es útil para casos de reboots, perdidas de luz, etc etc. Nos eviatara muchos
problemas.
Recordar siempre, que un arranque en modo SINGLE proporciona al usuario un acceso
como superusuario. Para ello es necesario tener acceso fisico al sistema y,
y tener presente que se le estan pasando unos parametros a LiLo.
Las opciones < lilo single > o < lilo -b > se inician ahora con
un /sbin/sulogin ( ver inittab ). Comentar tambien que linux init=/bin/sh cumple
con la funcion del hacker con acceso fisico, basta con remontar el disco duro
con lectura/escritura ( mount -o remount,rw / ).
Otro punto importante en lo referente a arranques del sistema es tener una tabla
de particiones siempre a mano por lo que pueda pasar. LiNUX proporciona el comando
'dd' que nos permitira hacerlo de la siguiente forma:
> dd if=/dev/hda of=/root/partiones/boot.lnx bs=512 count=1
Esto nos guardara la tabla de particiones del disco primario HDA en el fichero
vx boot.lnx. Para restaurar en su momento esta tabla de particiones, ejecutariamos:
> dd if=boot.lnx of=/dev/hda bs=446 count=1
podéis profundizar mas en este tema, analizando los MANPAGES de LiLo, los HowTos
disponibles en multiples distribuciones o en websites como http://sunsite.unc.edu/.
Teoria de Acceso Remoto. Modems.
Hoy en dia, y con el aumento del teletrabajo y la informatica personal, muchas
empresas, imaginemos una empresa de nombre Networking Center ( Como no ;-))
) dara soporte a sí misma, (empleados, medios de trabajo local, etc) en lo relativo
a informatica remota (acesos remotos con dispositivos como Modems, RDSIs, etc
etc ...).
Networking Center debe tener bajo su conocimiento todos los riesgos de seguridad
que implica el mantener lineas externas disponbles. Me explicare. Todo administrador
cuyo sistema contenga modems o similares deberá tener en cuenta los siguientes
puntos:
El modem no debe ser accesible fisicamente. Ya sea Externo o Interno, el modem debe estar protegido ante robos, sabotajes, etc etc.
La Línea telefonica que conecta ese dispositivo con el exterior deberá también estar lo mas restringida posible de cualquier usuario que pueda conectar a ella su propio dispositivo y utilizarla. Es decir, se debe mantener el cable lo mas oculto posible.El Numero de esa linea telefonica deberá mantenerse en secreto. Es complicado pero deberá intentar de ser así. Solo aquel personal autorizado debe saberlo, y mientras menos sean los conocedores del mismo, mejor. Una tecnica muy útil en estos casos es la identificacion de llamada en el propio Modem. Existen dispositivos capaces de analizar el numero llamador. También tenemos a nuestra disposición la posibilidad de restringir a una lista de usuarios X, que contendra los números de telefono autorizados a llamar y solo estos podran acceder al sistema.
Sistemas Operativos como Microsoft Windows NT(R) / 2000, nos permiten al configurar el modem, ponerlo a:
Solo Recibir llamadas.
Solo Hacer llamadas.
Actuar con Ambas.
De esta forma, podemos limitar el uso de una linea telefonica.
Un punto que siempre queda impune es el uso
de WarDialers, software encargado de realizar llamadas a un rango de números
especificado por el usuario, y que al conectar con un modem en un numero ABCDEFGH
nos indicara que ese numero es una linea informatica dedicada. El hacerlos,
aunque los hay en gran cantidad libres por la Red, es bastante sencillo.
Para seguir un estilo mas o menos lineal podéis echarle un vistazo a la forma
en la que ATRd es capaz de marcar números, y generando una lectura de fichero
que contenga los números, y editando una recursividad en la marcacion, junto
a la evaluacion de esta marcacion, nos proporcionara el efecto solicitado.
Me reitero que todo esto tiene fines educativos y que en ningún momento Networking
Center(R), ni yo, el autor, nos haremos responsables del mal uso de los contenidos
de este documento ;-)
Este tipo de programas son puntos clave en la búsqueda de números de acceso
a sistemas informaticos. Los bien conocidos números 900, pueden ser buscados
de esta forma. Siempre hemos de tener en cuenta, que nuestra linea sea capaz
de reconocer QUE números la llaman y CUALES son los que acceden a ella. De estar
forma podremos llevar un control de usuarios autorizados y no autorizados.
Introduciendonos en el area de LiNUX,
deberemos tomar las siguientes politicas de seguridad:
Restringir los derechos de Lectura/Escritura al dispositivo para cualquier usuario
que no sea el roto, o el grupo administrador que sea quien tenga acceso a ese
sistema.
Deberemos evitar cualquier tipo de programa SUID que acceda a dicho dispositivo,
para evitar los consecuentes riesgos de segurdad que se hayan inherentes al
SUID.
Utilizar medios de autentificacion como CHAP (Protocolo de Auth por Reto). CHAP
es un protocolo diseñado para aumentar la seguridad en acceso remotos. Es un
protocolo distinto a PAP (Basado en comparacion de passwd, al igual que hace
el 'login' de LiNUX). Un elemento bastante llamativo de CHAP es que cualquiera
de las 2 maquinas que intervienen en la comunicacion, puede solicitar a la otra
que se identifique en cualquier momento de la conexion cifrando. Solo las dos
maquinas conocen la clave, ese apreton de manos. De todas formas muchos isps
son reacios a identificarse totalmente y cuelgan la conexion ( noauth en ppp/options
). De esta forma, aseguramos que la conexion inicial y la final es la misma,
y que no ha habido accesos no deseados en la misma. Para mas informacion sobre
PAP y CHAP, revisar la informacion de PPPd disponible bajo licencia GNU/GPL,
los MANPAGES de PPPd, los HowTo de PPPd ... etc etc.
Siempre intentar restringir los ficheros como /etc/ppp/options, etc a los usuarios.
Revisad el programa ATRd, que realiza automaticamente la revision de seguridad
en el sistema en lo relativo a PPPd.
Una posible via para evitar intrusos remotos en el sistema a traves de línea
telefonica, son los llamados sistemas CallBack, de llamada devuelta. La empresa
dispone de un servicio tal que un usuario llama a la linea, y se identifica
como usuario X. Entonces el sistema mediante el reconocimiento de llamada, pilla
el numero lllamante y a continuacion corta la llamada y busca si el numero llamante
se haya en su lista de números permitidos, En caso afirmativo, el sistema devolvera
la llamada al usuario X, pasando el importe de la factura a la empresa.
Un intruso podrá llamar e identificarse, pero al no estar su numero en la lista
de autorizados, perdera totalmente el tiempo, y además, quedara ya bajo sospecha
el numero desde el cual se llama.
Actualmente, y con la nueva adaptacion de las lineas de la compañia telefonica
que lidera el mercado actual en España a los Caller-ID, siempre nos queda la
forma de ocultar el numero, mediante el prefijo 067. Podremos ocultar nuestro
numero, pero el sistema al no conocer la entrada, denegara igualmente los accesos
;-)
Maquinas de Red.
Llegados a este punto, nos iremos ya desviando un poco del sistema operativo
GNU por excelencia, para irnos introduciendo en áreas mas teoricas. En esta
parte de la charla, trataremos maquinas importantes en una red, maquinas seguras.
Existen numerosas charlas de Networking Center(R) que complementaran en gran
medida esta parte de la charla de seguridad en redes. Al paso por cada una de
ellas, indicare cual es la charla de ampliacion.
Firewalls.
En principio, el proposito generico de un firewall es controlar y auditar los
accesos a un servicio determinado. Su funcion es la de multiplexar los accesos
a una red interna desde Internet; es una puerta entre una IntraNET 'A' e InterNET.
La vigilancia que otrga el firewall requiere unas normativas de seguridad impuestas
por el propio adminisrador.
Una politica bastante correcta y fiable es la de hacer pasar siempre por el
firewall el trafico que se necesite originar entre a e Internet y viceversa,
de forma que se audite y controle todo lo que accede a A y/o sale de la misma.
Esto nos permitira sistemas de autentificacion segura, deteccion de posibles
intentos de acceso no autorizados, etc etc.
Una falacia es la idea que establece que un Firewall es inatacable. Esto es
totalmente falso, existen métodos, con mayor o menor riesgo para el sistema,
pero existen. Un ejemplo seria dar la oportunidad al atacante de reestablecer
las politicas de filtrado y seleccion. esto crearia un gran agujero de seguridad
que posiblemente le permita acceder a cualquier host de la red interna que desee.
El firewall debe ser capaz de evaluar los posibles daños ofertados por un ataque
e informar al administrador de ello. Tengamos en cuenta el bug propuesto antes.
Una eliminacion de politicas de auditoria podria darnos muchos dolores de cabeza.
Bajo GNU/LiNUX, tenemos a nuestra disposición numerosos programas capaces de
convertir nuestro sistema en un potente firewall. El ejemplo mas conocido quizás
sea IPFWAdm, o el actual IPChains, que viene incorporado en la mayoria de distribuciones.
Para mas informacion sobre Firewalls bajo LiNUX, es conveniente revisar la charla
ofrecida por VooDoo el pasado mes de febrero en Networking Center(R).
Vamos a ir describiendo poco a poco maquinas derivadas de la teoria de firewall
y algunas otras, que actuan en distinto nivel pero que pueden ser bastante utiles
en nuestra red.
Routers de Seleccion.
Llamamos router de seleccion a un un router capaz de gestionar y filtrar los
paquetes, basandose en criterios o reglas de filtrado. Muchas compañias fabrican
este tipo de dispositivos, tales como Cisco, 3Com, etc.
Llamaremos filtrado a la capacidad de seleccionar, analizar y marginar paquetes
basandonos en un criterio establecido. Este tipo de sistema es menos eficaz
que las soluciones tipo gateway, debido a que operan basandose en la informacion
de las capas
de transporte (4) y red (3) de la torre OSI. La evolucion de los firewalls hacia
Gateways y los tipos mas genericos los veremos en apartados posteriores.
Las reglas de filtrado se hallan disponibles en una tabla matricial de condicionales
y actuaciones. Estas reglas se aplicaran mientraS no se haya tomado una decision
relativa al apquete, es decir, si aun nom ha sido enrutado o desechado.
Gateways.
Definiremos Gateway como Pasarela. Se trata de un sistema que nos dara una serie
de facilidades segun sea necesario. Ahora veremos de que se trata.
Generalmente, se desconoce el significado read del termino 'PROXY'. Llamaremos
Proxy a una aplicacion que actua en un sistema de la red informatica, tal que
permirte hacer conexiones a diferentes servicios pasando por la maquina que
lo contiene, de forma que esta actua como gateway (o pasarela). Los proxies
suelen interpretar el protocolo que utilizan, luego nos ofreceran a su vez una
serie de mejoraS como son auditorias, control de accesos, etc.
Existen una gran cantidad de proxies, siemopre enfocados a protocolos, como
son los Web proxies, FTP proxies, Telnet proxies ... Los mas comunes son los
Socks Firewalls, que son proxies capaces de realizar conexiones a servicios
como IRC. Son los comunmente llamados "wingates". Esta denominacion aparece
gracias a un un proxy de bajo coste que funciona bajo sistemas operativos Microsoft
Windows(TM) de 32 Bits, el famoso WinGate (http://www.wingate.com). Los Socks
Firewalls actuan normalmente bajo el puerto 1080.
Los elementos de red de tipo Hardware, como los routers de seleccion pueden
ofrecernos un mayor rendimiento debido a que actuan en un nivel inferior de
la Torre OSI.
Los proxies actualmente incluyen algoritmos de autentificacion de usuarios,
para ofrecer una mayor seguridad a la red interna. Supongamos un usuario A,
que intenta acceder al sistema X23 de la Red NETWORKING. El proceso de dar permisividad
o no al usuario A es el siguiente:
ESQUEMA
DE RED: A ................. NETWORKING(PROXY) ...... NETWORKING(X23)
PETICION DE ACCESO: A .... LLAMADA .... NETWORKING(PROXY)
VERIFICACION DE USUARIO: A ..... AUTH ..... NETWORKING(PROXY)
SE AUTORIZA?: SI A ...... NETWORKING(PROXY) ...... NETWORKING(X23)
SE AUTORIZA?: NO A ... // ... NETWORKING(PROXY) ...... RED INTERNA
Normalmente, al actuar como
pasarela, el Proxy nos dejar pasar al interior de la red utilizando la misma
IP de el, es decir, si su direccion es x.x.x.x, cuando pasemos a traves de el,
saldremos a la red interna con su IP. De cualquier modo, todos los accesos al
proxy queddaran registrados en este, sin peligro de perder la informacion de
quien accedió a nuestro sistema informático.
Normalmente, en redes a pequeña escala, como redes familiares, etc el uso del
proxy nos dara un rendimiento/calidad/precio bastante bueno. Un sistema como
pueda ser Wingate para Windows, nos permitira compartir un acceso a internet
con modem, RDSI, etc y conectar a varios sistemas con una misma denominacion
IP.
Para sistemas LiNUX, SQUID2 es una solucion ventajosa, que unida con IRcache,
un complemento de servicios para SQUID2, se convierte en un maravilloso proxy.
SQUID en base solo permite mapear direcciones Web y FTP. El funcionamiento de
SQUID basado en almacenamiento (el famoso Cache) reduce los tiempos de conexion
de un sistema tras peticionar una pagina web o ftp que ha sido visitado en el
intervalo de tiempo permitido.
IRcache es un complemento que permite a SQUID mapear otro tipo de servicios
como puede ser IRC, DNS, Telnet ... Cosa que SQUID por si solo no puede. podéis
revisar el proyecto IRcache en http://www.ircache.net/.
Para aquellos interesados en montar SQUID, os recomiendo reviseis la Charla
"Proxies y SQUID" de Networking Center(R), disponible en el ultimo trimestre
de 1999.
Bastions Hosts.
Denominaremos como Bastion Host a un sistema informático catalogado como punto
peligroso en la seguridad de nuestro red informatica. En base, dispone de una
serie de medidas que le diferencia del resto, tales como mejores auditorias,
monitorizacion del sistema, control de accesos al mismo (conexiones de la red
interna, conexiones de la red externa ...). Este sistema debe haber sufrido
un proceso de testing para catalogar posibles fallos no solo en seguridad, sino
también en el propio software que utiliza.
Normalmente se suele permitir el paso del trafico de red autorizado a traves
del BH debido a que este nos detallara todo en todo momento, y además conociendo
correctamente su funcionamiento, podremos asegurar en un gran margen que el
sistema esta preparado para evitar posibles ataques o accesos no deseados a
nuestra red interna.
Un Bh deberá incluir, entre otros, una serie de normas de seguridad. En principio,
el sistema no deberá contener cuentas de de acceso a usuarios. En el caso de
GNU/LiNUX, solo deberá mantenerse aquellas derivadas a daemons y la del administrador.
Se recomienda eliminar el demonio SysKLogd, e instalar otro de los muchos disponibles
en web sites como http://www.freshmeat.net, que nos den un mayor rango de seguridad
inherente, de forma que ante posibles ataques a nuestro sistema, los ficheros,
de registro, etc corran menor peligro. Un buen ejemplo de ello, seria la codificacion
y encriptacion de los mismos. De cualquier modo, es recomendado leer previamente
toda documentacion y, como no, la parte relativa a registros de este documento
;-)
Como ya bien se especifico en la parte correspondiente en este documento, el
envio de los logs a otra maquina de nuestra red nos puede ser de gran utilidad.
Con Syslogd, es bastante sencillo, simplemente indicando en la configuración
del demonio que registros y politicas se han de enviar a la maquina mediante
el parametro "@" y a continuacion la IP de la Maquina en cuestion. Un ejemplo
seria:
# Envio de loas señales de Alerta a x50.networking-center.org
*.alert, *.emerg @x50.networking-center.org
Deberemos controlar todo lo relativo a enrutado desde el BH. Evitaremos situaciones
como encaminamientos no autorizados. También deberemos desechar todos aquellos
servicios de red como HTTPd, NNTPd, etc. excepto aquellos que nos permitan a
nosotros, administradores, el control remoto de la maquina. Estos podrian ser
el telnetd y el ftpd. Deberemos cambiar los puertos de acceso a los mismos,
o buscar formas de acceso a la maquina mediante una sola IP de acceso (Revisar
Hosts.deny y Hosts.allow). Los métodos personales mios de administracion prefiero
mantenerlos offside ;-) Simplemente es pensar en como actuaria una persona ajena
al encontrarse con un sistema de este tipo.
SSH nos ayudará mucho en esta tarea. Podeis encontrar mayor informacion acerca
de Herramientas de Acceso remoto y cifrado en http://www.freshmeat.net ó tambien
en http://www.winfiles.com.
A dia de hoy, y tras la presentacion oficial del Planning de Charlas de Networking
Center(R), podemos esperar por la charla que sera impartida el proximo dia 17
de Junio del 2000, por FsCk, y acerca de montaje y funcionamiento de BHs bajo
sistemas operativos Windows(TM).
Posibles Arquitecturas de Firewall. Sistemas 'Screened'.
[A] Screened Routers: Es el tipico router que todos usamos para dar acceso a
multiples maquina en Internet. Tenemos la siguiente estructura de Red:
Este tipo de router permite la
conexion de multiples terminales a internet. Si dicho router no contiene logger
y la contraseña del mismo es adivinada por un intruso, toda la red interna quedaria
descubierta. Existen multiples soluciones de este tipo de compañias como Cisco
Systems (http://www.cisco.com), 3Com (http://www.3com.com), Zyxel, Intel (http://www.intel.com),
etc.
Esta no es la solucion mas segura, pero mantiene una buena relacion calidad-precio.
Es recomendable que el administrador revise los sistemas conectados a este router
periodicamente, ya que el control de posibles atques, daños, etc es bastante
complicado.
[B] Screened Gateways: quizás sesa la solucion mas utilizada. Se basa en
un router de seleccion y un Bastion Host. El BH pertenece a la Red Interna,
y el RS solo permite el acceso al BH desde Internet. El RS filtrara una gran
mayoria de conexiones al BH, dependiendo del servicio solicitado, IP de origen,
etc.
Para conexiones salientes, los paquetes que superan la prueba del filtrado,
llegaran al RS. Para el entrante, sera el BH quien verifique a traves de procedimientos
del nivel de APLICACION, quien autorice o rechace los accesos solicitados.
Existe una configuración llamada
DMZ, que permite la insercion de maquinas que necesitemos o queramos dejar accesibles
a la red Internet entre el RS y el BH. El ejemplo siguiente se basa en una solo
seccion de red DMZ. Se podran añadir por niveles, segunlo requieran las circunstancias,
complicando cada vez mas la topologia de nuestro sistema informático.
Webs Recomendadas:
Networking Center(R), Charlas.Charla de Firewalls dia 26/2/2000. Networking Center(R).
Proyecto ATRd. Acceso Telefonico a Redes para LiNUX. Networking Center(R).Proyecto IRCache. (Relacion: PROXIES)
Web Site Oficial de SQUID.Articulo sobre Firewalling. LANTimes Magazine.
UNiX World. Seccion Tutoriales de Network Magazine. TI Magazine. Revista de las Tecnologias de la Informacion.
Bibliografia Interesante:
RFC 1244: Politicas de Seguridad.
Marcus J. Ranum. A toolkit and methods for Internet Firewalls.
Karanjit Siyan: Firewalls & Internet Security. Prentice Hall.
