Indice

1. Introducción 4. Autentificación
– Que asegurar y Como – PAM
asegurarlo – Seguridad de contraseñas
– Instalacion segura – Almacenamiento de
– Conceptos generales contraseñas
2. Seguridad física y de arranque 5. Acceso Remoto
– Seguridad física – Introducción
– La BIOS – Herramientas administrativas
– LILO – Telnet
3. Sistema de ficheros – SSH
– Ficheros del sistema – Cifrado de servicios
– Seguridad de ficheros 6. Links
1. Introducción
1.1.Que asegurar y como asegurarlo
Es necesario listar todos aquellos recursos que
contengan datos, den servicios, formen parte de la
infraestructura de tu compañía, etc... A continuación se
detalla una pequeña lista:

Servidores físicos
Servidores de correo y servicios.
Servidores de DNS y servicios.
Servidores de WWW y servicios.
Servidores de ficheros y servicios.
Datos internos de la compañía, como registros contables.
Infraestructura de la red (cables, hubs, switches, routers, etc.).
Sistema telefónico (PBX, buzones de voz, etc.).
 Después necesitas averiguar contra qué lo queremos
proteger:

Daños físicos (humo, agua, comida, etc.).

Borrado / modificación de datos (registros contables, deterioro

de tu sitio web, etc.).

Exposición de datos (registros contables, etc.).

Continuidad de servicios (mantenimiento activo de los

servidores de correo/www/ficheros).

Evitar que otros hagan uso ilegal/impropio de tus servicios

(envíos masivos de correos, etc.).
 Finalmente, ¿cuál es la probabilidad de que se dé un suceso
determinado?

Escaneos de red - puedes apostar que a diario.

Ingeniería social – varía, normalmente suelen ser objetivo la

gente más vulnerable.

Intrusión física – depende, bastante rara, pero un empleado

hostil con un par de alicates podría causar mucho daño en un
armario de telecomunicaciones.

Empleados que venden datos a la competencia – ocurre.

La competencia, que alquile a gente especializada para

penetrar activamente en tu red – nadie suele hablar de esto,
pero también ocurre.
 Una vez redactada una lista de recursos y de
aquello que es necesario hacer, hay que empezar a
implementar la seguridad.

Algunas técnicas son bastante evidentes, en estos

temas existen unas pautas de comportamiento de
seguridad que por lo general están implementadas.

La gran mayoría de los problemas de seguridad

suelen ser de origen humano, y la mayoría de los
problemas están debidos a la falta de
educación/comunicación entre gente.
 Los posibles resultados derivados de un incidente de
seguridad son:

Pérdidas de datos
Perdida directa de beneficios (ventas vía web, el
servidor de ficheros inactivo, etc)
Costes en tiempo de personal
Pérdida de productividad del departamento de
informática, así como de los trabajadores
dependientes de su infraestructura
Implicaciones legales (registros médicos, registros
contables de clientes, etc.)
Pérdida de la confianza por parte del cliente
Publicidad por parte de los medios de comunicación
 1.2.Instalación segura de Linux
Una adecuada instalación de Linux es el primer paso
para tener un sistema estable y seguro. La elección del medio
de instalación es el elemento nº 1, que afectará a la velocidad
de instalación y en buena medida a la seguridad.

FTP – rápida, requiere una tarjeta de red, y un servidor de ftp.

HTTP – también rápida, y algo más segura que hacer una

llamada a un FTP público

Samba – rápida, un buen método si dispones de una máquina

windows (comparte el cdrom).
NFS – no tan rápida, pero puesto que el nfs está implementado
en la mayoría de las redes UNIX existentes (y NT tiene un
servidor NFS de MS gratis), es casi indolora. El método por
NFS es el único método soportado por la opción kickstart de
Red Hat.

CDROM – si tienes un lector de cdrom rápido, la mejor apuesta

es introducir el cd y arrancar desde él, pulsar enter unas
cuantas veces y ya estás listo. Ahora, se puede arrancar desde
la mayoría de los CDROMs de Linux.

Disco duro – generalmente la más dolorosa, las ventanas

confunden los nombres de fichero, la instalación desde una
partición ext2 suele ser algo menos dolorosa.
 Y aquí no acaba todo…

Una vez instalado Linux es posible que desees instalar una

gran cantidad de software extra, y paquetes que quizás quisieras
actualizar, o cosas que más te vale actualizar si no quieres que el
sistema se vea comprometido en los primeros 15 segundos de vida.

Mantener una copia local del directorio de actualizaciones

de tu distribución es una buena idea, y tenerlo disponible vía nfs/ftp o
tostar un CD generalmente suele ser la forma más rápida de tenerlo
disponible.

También querrás eliminar cualquier tipo de software que no

estés usando, así como reemplazarlo por otras versiones más seguras.
 1.3.Conceptos generales

Hay muchos elementos que afectan a la seguridad de

un ordenador:

¿Cómo de seguro necesita ser?¿Está en red la

máquina? ¿Habrán cuentas interactivas de usuarios
(telnet/ssh)?¿Se utilizarán las máquinas como estaciones de
trabajo o se trata de un servidor?

Esta última cuestión es de gran relevancia, pues las

"estaciones de trabajo" y los "servidores" tradicionalmente
han sido animales muy diferentes, aunque la línea se
difumina con la introducción de potentes y baratos PCs, a
medida que los sistemas operativos se aprovechan de ello.
 Algunas reglas de carácter general que te ahorrarán
bastantes penurias son las siguientes:

Mantén a los usuarios alejados de los servidores. Es decir: no

les proporciones shells de login interactivos, a menos que sea
un requerimiento absoluto.

Bloquea las estaciones de trabajo, da por hecho que los

usuarios intentarán "arreglar" las cosas (qué caramba, incluso
podrían ser hostiles, trabajadores temporales/etc).

Utiliza la criptografía allí donde sea posible para almacenar

claves en texto simple, números de tarjetas de crédito y otro tipo
de información delicada.

Escanea regularmente la red en busca de puertos abiertos,

software instalado que no debería estar ahí, compáralo con
resultados anteriores.
 Recuerda: la seguridad no es una solución, es un
modo de vida.

Utiliza las claves de las BIOS para mantener a los usuarios

alejados de la BIOS (nunca deberían estar ahí, recuerda
también que las BIOS viejas tienen claves universales.)

Configura la máquina para que arranque únicamente del disco

duro adecuado.

Pon clave al prompt de LILO.

No les des acceso de root a los usuarios, utiliza sudo para

proporcionar acceso a comandos privilegiados cuando sea
necesario.
Utiliza cortafuegos para que incluso si instalan servicios estos
no sean accesibles al resto del mundo.

Observa regularmente la tabla de procesos, puertos abiertos,

software instalado, etc. en busca de cambios.

Ten una política de seguridad escrita que los usuarios puedan

entender, y fortalécela.

Borra todo tipo de objetos peligrosos (compiladores, etc), a

menos que sean necesarios en un sistema.
 Recuerda: seguridad en profundidad.

Restringe el acceso físico a los servidores.

Política del menor privilegio, así pueden estropearse menos

cosas.

¡HAZ COPIAS DE SEGURIDAD!

Comprueba con regularidad los servidores en busca de

cambios (puertos, software, etc), para esto son estupendas las
herramientas automatizadas.

Los cambios de software deberían estar cuidadosamente

planeados/probados, pues pueden implicar efectos inversos.
2.Seguridad Física y de Arranque
2.1.Acceso Físico

¿Quien puede acceder a nuestro sistema y que puede

hacerle?. Personal de limpieza, el chico de los recados un
usuario malintencionado, etc.

Teniendo esto en cuenta tiene sentido bloquear los

servidores en una habitación segura (o incluso en un
armario).

También es una buena idea situar a los servidores en

una superficie elevada, para evitar daños en el caso de
inundaciones (ya sea por un agujero en el techo o lo que sea).
 2.2.La Bios
La BIOS del ordenador controla la forma en que el
ordenador arranca y otro tipo de cosas.

Las BIOS viejas tiene fama de tener claves

universales, asegúrate de que tu bios es reciente y que no
contiene semejante puerta trasera.

La bios se puede utilizar para bloquear la secuencia

de arranque de un equipo, limitándola a C: únicamente, por
ejemplo, al primer disco duro, lo cual es una buena idea.

Deberías utilizar la bios para eliminar la disquetera

(el servidor típico no va a necesitar utilizarla), y puede evitar
que los usuarios copien datos de la máquina a disquetes.
 También puedes eliminar los puertos serie en las
máquinas de los usuarios, de tal forma que puedan instalar
módems.

Lo mismo sirve para el puerto paralelo, permitiendo

a los usuarios imprimir obviando la red, o dándoles la
oportunidad de instalar una grabadora de CDROM o un
disco duro externo, lo cual puede disminuir la
seguridad en buena medida.

Esto es un añadido a la política del menor privilegio,

y puede disminuir considerablemente los riesgos, al igual que
facilitar la administración de la red.
 2.3.LILO
Una vez que el ordenador ha decidido arrancar de
C:, LILO (o cualquier otro gestor de arranque que utilices)
despega.

La mayoría de los gestores de arranque permiten

algún tipo de flexibilidad en el modo en que se arranca el
sistema, especialmente LILO, pero también es una espada de
dos filos.

Puedes pasarle argumentos a LILO a la hora de

arrancar, siendo el argumento más dañino "imagename
single", lo cual arranca Linux en modo de único usuario, y
por defecto, la mayoría de las distribuciones te vuelcan a un
prompt de root en un shell de comandos sin preguntar
contraseñas u otro tipo de mecanismos de seguridad.
 Hay varias tecnicas para minimizar este riesgo:

delay=x

• esto controla la cantidad de tiempo (en décimas de segundo) que LILO

espera a que el usuario introduzca datos antes de arrancar la opción
por defecto.

Prompt

• fuerza al usuario a introducir algo, LILO no arrancará el sistema

automáticamente. Si le añades una opción de cuenta atrás, el sistema
continuará arrancando después de que haya terminado la cuenta atrás.

Restricted

• pide una contraseña si se pasan opciones de tiempo de arranque

(tales como "linux single").
3. Sistema de Ficheros
3.1.Ficheros del Sistema
/etc/passwd

El fichero de contraseñas es sin discusión el fichero más crítico

en Linux. Contiene el mapa de nombres de usuarios, identificaciones de
usuarios y la ID del grupo primario al que pertenece esa persona. También
puede contener el fichero real, aunque es más probable (y mucho más
seguro) que utilice contraseñas con shadow para mantener las contraseñas
en /etc/shadow. Este fichero TIENE que ser legible por todo el mundo, o si
no comandos tan simples como ls dejarían de funcionar correctamente. El
formato es:

nombreusuario:contraseña_cifrada:UID:GID:campo_GECOS:direct_personal:login_shell

Las contraseñas se guardan utilizando un hash de un sólo

sentido. Las contraseñas no pueden obtenerse a partir de la forma cifrada,
sin embargo, se puede tratar de encontrar una contraseña utilizando
fuerza bruta para pasar por el hash cadenas de texto y compararlas, una
vez que encuentres una que coincide, sabes que has conseguido la
contraseña.
/etc/shadow

El fichero de shadow alberga pares de nombres de usuario y

contraseñas, así como información contable, como la fecha de expiración,
y otros campos especiales. Este fichero debería protegerse a toda costa, y
sólo el root debería tener acceso de lectura a él.

/etc/groups

El fichero de grupos contiene toda la información de

pertenencia a grupos, y opcionalmente elementos como la contraseña del
grupo (generalmente almacenado en gshadow en los sistemas actuales),
este fichero debe ser legible por el mundo para que el sistema funcione
correctamente. El formato es:

nombregrupo:contraseña_cifrada:GID:miembro1,miembro2,miembro3

Un grupo puede no contener miembros (p. ej., no está usado),

sólo un miembro o múltiples miembros, y la contraseña es opcional (y no
se suele usar).
/etc/gshadow

Similar al fichero shadow de contraseñas, este fichero contiene

los grupos, contraseñas y miembros. De nuevo, este fichero debería ser
protegido a toda costa, y sólo el usuario root debería tener permiso de
lectura al mismo.

/etc/login.defs

Este fichero (/etc/login.defs) te permite definir algunos valores

por defecto para diferentes programas como useradd y expiración de
contraseñas.

/etc/shells

El fichero de shells contiene una lista de shells válidos, si el shell

por defecto de un usuario no aparece listado aquí, quizás no pueda hacer
login interactivamente.
/etc/securetty

Este fichero contiene una lista de tty’s desde los que el root
puede hacer un login. Los tty’s de la consola suelen ir de /dev/tty1 a
/dev/tty6. Los puertos serie son /dev/ttyS0 y superiores por lo
general. Generalmente, sólo se debería permitir conectar al root
desde /dev/tty1, y es aconsejable desabilitar la cuenta de root, sin
embargo antes de hacer esto, por favor, instala sudo o un programa
que permita al root acceder a comandos.
 3.2.Seguridad de Ficheros

Una casa sólida necesita cimientos sólidos, si no se

derrumbará. En el caso de Linux, esto es el sistema de ficheros ext2
(EXTendido, versión 2). Algo así como el standard UNIX de toda la
vida. Soporta permisos de ficheros (lectura, escritura, ejecución,
sticky bit, suid, guid, etc.), propiedad de ficheros (usuario, grupo,
otros), y otro tipo de standards.

Las utilidades básicas para interactuar con ficheros son:

"ls", "chown", "chmod" y "find". Otras incluyen ln (para
creación de enlaces), stat (muestra información de un fichero) y
muchas más. En cuanto a la creación y mantenimiento de sistemas
de ficheros por sí mismos, tenemos "fdisk" (el viejo fdisk), "mkfs"
(MaKe FileSystem, que formatea particiones), y "fsck"
(FileSystem ChecK, que suele arreglar problemas).
 ¿Qué es lo que estamos tratando de evitar que haga la gente
hostil?. Se puede comprometer con facilidad un sistema Linux si se
consigue acceso a ciertos ficheros, por ejemplo la capacidad para leer un
fichero de claves sin shadow da como resultado la posibilidad de ejecutar
contraseñas cifradas contra crack, encontrando con facilidad las
contraseñas débiles. De otra forma, si un atacante puede escribir en el
fichero de contraseñas, el o ella puede irrumpir en el sistema, o
conseguir cualquier nivel de acceso que quiera. ¿Cómo se pueden
prevenir?

Configurando el sistema de ficheros correctamente cuando se

instale. Dos directorios habituales a los que los usuarios tienen acceso son
/tmp y /home, dividir esto en particiones separadas también evita que los
usuarios llenen cualquier sistema de ficheros crítico (un / lleno es algo
bastante malo). Un /home lleno podría dar como resultado la incapacidad
de que los usuarios pudieran hacer un login (por eso el directorio del root
está en /root). Poner /tmp y /home en particiones separadas es algo así
como obligatorio si los usuarios tienen acceso al servidor, poner /etc, /var, y
/usr en particiones separadas también es una muy buena idea.
 Las herramientas principales para conseguir información
sobre ficheros y sistemas de ficheros son relativamente simples y
fáciles de usar:

"df" (muestra el uso del disco)

"du" (saca un listado de todo lo que hay en el directorio

actual y por debajo de él a lo que tengas acceso)

ls (similar al comando "dir" del DOS), "ls" sólo saca nombres

de ficheros/directorios, "ls –l" muestra información como los permisos
de los ficheros, el tamaño, etc.,

"stat", que símplemente da información de las estadísticas

vitales de un fichero(s) dado, y es muy útil para ver si un fichero está
en uso, etc.
 Para manipular ficheros y carpetas, están las
herramientas generales como cp, mv, rm (CoPy, MoVe y ReMove,
copiar, mover y eliminar), al igual que herramientas para
manipular la información de seguridad.

chown es responsable de cambiar la propiedad del usuario y

grupo de un determinado fichero.

chmod (CHange MODe, cambio de modo) cambia los

atributos de un fichero, siendo los básicos lectura, escritura y
ejecución.

find encuentra ficheros (en esencia, lista ficheros), y también

se puede utilizar con filtros basados en permisos/propiedad
 Borrado seguro de ficheros

Algo que muchos de nosotros olvidamos es que cuando se borra

un fichero, en realidad no se ha ido, hay posibilidades de que pueda ser
recuperado. El truco consiste en desordenar los datos, alterando los bits
magnéticos (alias los 1’s y 0’s) para que una vez hubiera terminado, no
quedasen trazas del original (es decir, bits magnéticos cargados de la
misma forma que estaban originariamente). Se han escrito dos
programas (ambos llamados wipe) a tal efecto.

wipe (durakb@crit2.univ-montp2.fr)

wipe borra datos con seguridad, sobreescribiendo el fichero

múltiples veces con varios patrones de bits. Se puede utilizar
wipe en ficheros o en dispositivos.

wipe (thomassr@erols.com)

Este también borra datos de forma segura, sobreescribiéndolos

múltiples veces, sin embargo este no soporta el borrado de
dispositivos.
4. Autentificación
4.1.PAM
"Pluggable Authentication Modules" para Linux, es una suite de
librerías compartidas que permiten al administrador local del sistema
escoger cómo autentifican a los usuarios las aplicaciones.

¿Qué significa en realidad? Por ejemplo, tomemos "login", cuando

un usuario se conecta, un programa responde la llamada e inicia "login", y
luego pide el típico nombre de usuario, seguido de la contraseña, lo cual se
compara con el fichero /etc/passwd. Todo esto está bien, hasta que tienes una
fenomenal tarjeta de autentificación nueva y quieres utilizarla. Bueno, pues
tendrás que recompilar login de modo que soporten el sistema nuevo. Como
te puedes imaginar, esto lleva bastante trabajo y está sujeto a errores.

PAM introduce una capa de middleware entre la aplicación y el

mecanismo real de autentificación. Una vez que el programa está
PAMificado, podrá ser utilizado por el programa cualquier método de
autentificación que soporte PAM. Además de esto, PAM puede manejar
cuentas y datos de sesiones, lo cual no suelen hacer bien los mecanismos
habituales de autentificación.
 4.2.Seguridad de contraseñas
Para que la autentificación de usuario funcione correctamente se
necesitan (como mínimo) algún tipo de fichero(s) con UID a mapas de
nombres de usuarios, GID a mapas de nombres de grupos, contraseñas para
todos los usuarios y demás información variada.

El problema es que todo el mundo necesita acceso al fichero de

contraseñas, cada vez que se hace un ls, se verifica el fichero de contraseñas,
de modo que ¿cómo se consigue almacenar todas las contraseñas con
seguridad y a la vez mantenerlas legibles por el mundo?

Durante muchos años, la solución ha sido bastante simple y

efectiva, simplemente, haz un hash de las contraseñas y guarda el hash,
cuando un usuario necesite autentificar, toma la contraseña que introduce,
pásala por el hash y si coincide, evidentemente se trataba de la misma
contraseña. El problema que tiene esto es que la potencia computacional ha
crecido enormemente, y ahora se puede coger una copia del fichero de
contraseñas e intentar abrirlo mediante fuerza bruta en una cantidad de
tiempo razonable.
 Para resolver esto hay varias solucione s:

•Utiliza un algoritmo de hashing "mejor", como MD5.

•Almacena las contraseñas en alguna otra parte.

Linux ha implementado la segunda desde hace tiempo, se llama

contraseñas con shadow. En el fichero de contraseñas, se reemplaza la
contraseña por una ‘x’, lo cual le indica al sistema que verifique tu
contraseña contra el fichero shadow.

Para implementar contraseñas con shadow hay que hacer dos

cosas. La primera es relativamente simple, cambiar el fichero de
contraseñas, pero la segunda puede ser un calvario. Hay que asegurarse que
todos tus programas tienen soporte para contraseñas con shadow, lo cual
puede ser bastante penoso en algunos casos.

Debido a la confianza de Red Hat en PAM para la autentificación,

para implementar un esquema nuevo de autentificación todo lo que se
necesita es añadir un módulo PAM que lo entienda y editar el fichero de
configuración para cualquier programa (digamos el login) permitiéndole que
use ese módulo para hacer la autentificación.
 4.3.Almacenamiento de contraseñas.

Esto es algo que la mayoría de la gente no suele tener en

cuenta. ¿Cómo se pueden almacenar las contraseñas de forma
segura? El método más obvio es memorizarlas, pero suele tener sus
inconvenientes, si se administran 30 sitios diferentes, por lo general
se tendrán 30 contraseñas diferentes, y una buena contraseña tiene
más de 8 caracteres de longitud, y por lo general no es la cosa más
fácil de recordar.

Esto conduce a que mucha gente utilice la misma contraseña

en diferentes sistemas. Una de las formas más sencillas es escribir las
contraseñas. Por lo general, esto suele ser muy malo. Una mejor
opción es almacenar las contraseñas en un formato cifrado,
generalmente de forma electrónica en tu ordenador o en el palm
pilot, de forma sólo hay que recordar una contraseña para
desbloquear el resto.
5. Acceso Remoto
5.1.Introduccion
No se pueden empezar a segurar servicios hasta que no se sepa qué
se está ejecutando. Para este tipo de tareas, ps y netstat no tienen precio; ps
dice qué se está ejecutando (httpd, inetd, etc) y netstat te dirá cuál es el
estado de los puertos.

Salida de PS

El programa ps nos muestra el estado de procesos. Las opciones

más comúnmente utilizadas son "ps -xau", que muestra algo así como toda
la información que siempre quisiste saber.

Lo que viene a continuación es una salida típica de una máquina

(utilizando "ps -xau").

USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND

bin 320 0.0 0.6 760 380 ? S Feb 12 0:00 portmap

...
 Salida de Netstat

netstat informa acerca de casi cualquier cosa que se pueda

imaginar relacionada con la red. Es especialmente buena para sacar listados
de conexiones y sockets activos. Al usar netstat se puede encontrar qué
interfaces están activas en qué puertos.

Lo que viene a continuación es la salida típica de un servidor, con

netstat –an.

Active Internet connections (including servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 24.108.11.200:80 205.253.183.122:3661 ESTABLISHED

udp 0 0 127.0.0.1:1031 0.0.0.0:*

raw 0 0 0.0.0.0:1 0.0.0.0:*

...
 Salida de lsof

lsof es un práctico programa cuya idea es similar a la de ps,

excepto en que muestra qué ficheros/etc están abiertos, lo cual puede
incluir sockets de red. Desafortunadamente, el lsof medio saca
bastante información, de modo que será necesario utilizar grep o
redireccionarlo mediante less ("lsof | less") para hacerlo más cómodo
de leer.

squid 9726 root 4u inet 78774 TCP localhost:2074->localhost:2073 (ESTABLISHED)

squid 9726 root 5u inet 78777 TCP localhost:2076->localhost:2075 (ESTABLISHED)

squid 9726 root 6u inet 78780 TCP localhost:2078->localhost:2077 (ESTABLISHED)

squid 9726 root 7w CHR 1,3 6205 /dev/null

...
 Ficheros básicos de configuración de red

Hay varios ficheros de configuración importantes, que controlan

qué servicios ejecuta Linux y cómo lo hacen. Los lugares de localizacion mas
habituales son:

Fichero de configuración del servidor Inetd:

/etc/inetd.conf

Ficheros de inicio de varios tipos:

/etc/rc.d/*

/etc/*

Lo mejor que se puede hacer es imaginarse qué servicios se quiere

ejecutar, y deshabilitar/borrar el resto.
 inetd.conf

inetd.conf es el responsable de iniciar los servicios, generalmente

aquellos que no necesitan ejecutarse de continuo, o que están basados en
sesiones (como telnet o ftpd).

Ello es debido a que la sobrecarga que supondría ejecutar un

servicio constantemente sería mayor que el costo de inicio ocasional cuando
el usuario quisiera utilizarlo.

Para algunos servicios (como DNS) que sirven a muchas

conexiones rápidas, la sobrecarga de arrancar servicios cada pocos segundos
sería mayor que tenerlo constantemente ejecutándose.

Se aconseja desabilitar tantos servicios de inetd.conf como sea

posible, por lo general los que se suelen usar son ftp, pop e imap. Se debería
reemplazar telnet y los servicios r por el SSH y servicios como systat/netstat
y finger proporcionan demasiada información. El acceso a programas
arrancados por inetd se puede controlar con facilidad mediante eluso de
TCP_WRAPPERS.
 TCP_WRAPPERS

Usar TCP_WRAPPERS hace que el asegurar servidores

contra intrusiones externas sea bastante más simple y menos
doloroso de lo que te imaginas. TCP_WRAPPERS se controla desde
dos ficheros:

/etc/hosts.allow

/etc/hosts.deny

Primero se comprueba hosts.allow, y las reglas se

comprueban desde la primera a la última. Si encuentra una regla que
te permita específicamente entrar te deja conectarte al servicio.

Si no puede encontrar ninguna regla que te corresponda en

hosts.allow, entonces va a comprobar hosts.deny en busca de una
regla que te deniegue la entrada. De nuevo comprueba las reglas de
hosts.deny desde la primera a la última, y la primera regla que
encuentre que te deniega acceso.
 Si tampoco puede encontrar una regla denegándote la entrada,
entonces por defecto te deja entrar. Si eres tan paranoico como yo, la última
regla (o la única regla si se va a utilizar una política por defecto no optimista
en cuanto a seguridad) debería ser:

ALL: 0.0.0.0/0.0.0.0

lo que significa que todos los servicios, todos los lugares, de modo
que cualquier servicio al que no se le permita específicamente acceder, queda
bloqueado (recuerda que por defecto es permitir). Quizás también
preferirías simplemente denegar el acceso por defecto a, digamos, telnet, y
dejar el ftp abierto al mundo. Habría que hacer lo siguiente:

en hosts.allow:

in.telnetd: 10.0.0.0/255.255.255.0 # permitir acceso desde la red interna de 10.0.0.*

in.ftpd: 0.0.0.0/0.0.0.0 # permitir acceso desde cualquier parte del mundo

en hosts.deny:

in.telnetd: 0.0.0.0/0.0.0.0 # denegar acceso a telnetd desde cualquier parte

 /etc/services

El fichero de servicios es una lista de números de puertos, el

protocolo y el nombre correspondiente. El formato es:

nombre-de-servicio puerto/protocolo alias

# comentario opcional

Por ejemplo, este fichero se utiliza cuando se ejecuta ‘netstat -a’, y

por supuesto no se utiliza cuando se ejecuta ‘netstat -an’:

time 37/udp timserver

rlp 39/udp resource # localización de recursos

name 42/udp nameserver

whois 43/tcp nicname # generalmente al sri-nic

domain 53/tcp

domain 53/udp
 5.2.Herramientas

Telnet

Telnet es con mucho la herramienta remota más vieja y conocida. Telnet es

increíblemente inseguro, las contraseñas y los nombres de usuarios, al igual
que los datos de las sesiones vuelan en texto simple.

SSL Telnet

SSL Telnet es telnet con el añadido de cifrado SSL, lo cual lo hace bastante
más seguro.

SSH

Soporta diferentes tipos de autentificación (contraseña, basada en rhosts,

llaves RSA), permite redireccionar puertos, y se puede configurar fácilmente
a qué usuarios se les permite usarlo.
 LSH

LSH es una implementación gratuita del protocolo SSH.

REXEC

REXEC es una de las utilidades UNIX más antiguas, te permite ejecutar

comandos en un sistema remoto, aunque tiene el serio fallo de no tener un
modelo de seguridad real. La seguridad se consigue mediante el uso de
ficheros ‘rhosts’, que especifican qué hosts/etc. pueden ejecutar comandos, lo
cual está sujeto a spoofing y otro tipo de exploits.

Slush

Slush está basado en OpenSSL, está completamente basado en software de

código abierto, dejando pocas posibilidades a que pueda tener puertas
traseras/etc. En último caso, podría reemplazar al SSH por algo mejor.
 NSH

NSH es un producto comercial con todos sus detalles. Tiene soporte para
cifrado, de modo que es relativamente seguro de usar.

Fsh

Fsh significa "Ejecución rápida de comandos remotos", y el concepto es

similar al de rsh/rcp. Evita el costo de estar creando continuamente sesiones
cifradas, habilitando un túnel cifrado utilizando ssh o lsh, y ejecutando todos
los comandos sobre él.

secsh

secsh (Shell Seguro) aporta otra capa más de seguridad de login, una vez que
has hecho log vía ssh o telnet SSL te pide otra contraseña, si introduces una
errónea, secsh mata el intento de login.
 5.3.Telnet

Telnet permite hacer login interactivo en una máquina

remota, lanzar comandos y ver sus resultados. Es uno de los
protocolos más inseguros. La mejor solución para asegurar el telnet
es deshabilitarlo y utilizar telnet con SSL o el ssh.

Los problemas con telnet incluyen:

Autentificación en texto claro, nombre de usuario y contraseña.

Texto en claro de todos los comandos.

Ataques de adivinación de contraseñas.

 La mejor solución es desactivar el telnet y utilizar ssh. Si es
necesario utilizar telnet, sugeriría encarecidamente filtrarlo mediante un
cortafuegos, tener reglas para permitir a los hosts/redes acceso a puerto 23, y
después tener una regla general denegando acceso al puerto 23, al igual que
utilizar TCP_WRAPPERS

Un ejemplo de reglas del cortafuegos:

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 23

ipfwadm –I –a accept –P tcp –S un.host.fiable –d 0.0.0.0/0 23

ipchains –A input –p all –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 23

Un ejemplo de lo mismo utilizando TCP_WRAPPERS:

En /etc/hosts.allow

in.telnetd: 10.0.0.0/255.0.0.0, un.host.fiable

Y en /etc/hosts.deny

in.telnetd: ALL
 Existen varias alternativas cifradas al telnet, como ya se
mencionó más arriba, ssh, SSLeay Telnet y otras utilidades de
terceros, a mi personalmente me parece que la "mejor" alternativa si
te vas a tomar la molestia de cambiar el telnet por algo mejor es
utilizar ssh.

Para asegurar las cuentas de los usuarios con respecto a

telnet, se pueden hacer varias cosas:

•La primera sería no permitir al root hacer login vía telnet, lo cual se
controla mediante el /etc/securetty y por defecto en la mayoría de las
distribuciones el root tiene restringido el acceso a la consola.

• Para que un usuario haga login con éxito, su shell tiene que ser
válido (lo cual viene determinado por la lista de shells de /etc/shells),
de modo que configurar cuentas de usuario a las que se les permita
hacer login es simplemente cuestión de configurar su shell a alguno
de los listados en /etc/shells.
 5.4. SSH

SSH es un protocolo seguro y un conjunto de herramientas para

reemplazar otras más comunes (inseguras). Fue diseñado desde el principio
para ofrecer un máximo de seguridad y permitir el acceso remoto a
servidores de forma segura. SSH se puede utilizar para asegurar cualquier
tráfico basado en red, configurándolo como un pipe.

No existen tantos problemas con el SSH per se como existen con

telnet, todo el tráfico de la sesión va cifrado y el intercambio de llaves se hace
de forma relativamente segura. SSH se suele ejecutar como un demonio, y se
puede cerrar utilizando el fichero sshd_config. También se puede ejecutar
sshd desde inetd, y de tal forma utilizar TCP_WRAPPERS.

Las reglas del cortafuegos para ssh son bastante parecidas a telnet.
Por supuesto que está TCP_WRAPPERS, el problema con
TCP_WRAPPERS es que un atacante se conecta al puerto, pero no consigue
un demonio, SIN EMBARGO sabe que hay algo en ese puerto, mientras que
mediante el cortafuegos, ni siquiera se consigue conexión con el puerto.
 5.5. Cifrado de servicios

Prácticamente todo el tráfico de red viaja sin cifrar y puede

ser leído con facilidad por un atacante. Si alguien revienta una
máquina del lado de Internet e instala un sniffer de contraseñas, la
red entera puede verse comprometida en cuestión de horas.

Existen o se están desarrollando varios mecanismos para

cifrar el tráfico de red, en diferentes niveles de la pila de red.

Algunos esquemas sólo cifran los datos que se envían (como

el correo cifrado con PGP), algunos cifran la sesión (SSL), y algunos
cifran la carga de datos de los paquetes (IPSec y otros VPN’s). A la
larga, la mejor solución será el IPSec, puesto que no requiere
modificar las aplicaciones, y proporciona un nivel de seguridad entre
ordenadores bastante elevado.
6. Links
Guia de Seguridad del Administrador de Linux
puedes encontrarla en español en el Proyecto Lucas
http://lucas.linux.org.mx/htmls/manuales.html (gsal-19991128)

Security Portal (El portal de la Seguridad)

http://www.securityportal.com/

Hispalinux (Asociación de usuarios Españoles de Linux)

http://www.hispalinux.es/

Linux.org http://www.linux.org/

Linux.com
http://www.linux.com/