En este capítulo usaremos el texto en
negrita para referirnos a una orden o
aplicación, y una fuente en cursiva
para
referirnos a órdenes específicas. Usaremos un tipo normal
para los protocolos. Esta diferencia tipográfica nos
será útil por ejemplo con ssh, que es tanto un
protocolo como una orden.
Las siguientes secciones cubren los métodos a seguir para asegurar su sistema FreeBSD que se mencionados en la sección anterior de este capítulo.
En primer lugar, no se moleste en asegurar las cuentas
administrativas (o “staff”) si no ha asegurado la
cuenta root
.
La mayoría de los sistemas tienen una contraseña
asignada para la cuenta root
. Lo primero que
se hace es asumir que la contraseña está
siempre amenazada.
Esto no significa que deba eliminar la contraseña. La
contraseña es casi siempre necesaria para el acceso por
consola a la máquina; significa que no se debe permitir
el uso de la contraseña fuera de la consola o, mejor
aún, mediante su(1). Por ejemplo,
asegúrese de que sus ptys aparezcan como
inseguras en el fichero
/etc/ttys
, con lo que hará que
los accesos como root
vía
telnet
o rlogin
no sean
posibles.
Si utiliza otros tipos de login como
sshd asegúrese de que
los accesos al sistema como root
estén también deshabilitados.
Para ello edite su
/etc/ssh/sshd_config
y asegúrese de
que PermitRootLogin
esté puesto a
NO
. Estudie cada método de acceso:
hay servicios como FTP que frecuentemente son origen de grietas
en la estructura del sistema. El acceso directo como usuario
root
sólamente debe permitirse
a través de la consola.
Es evidente que, como administrador del sistema, debe usted
tener la posibilidad de acceder a root
,
así que tendrá que abrir algunos agujeros, pero
debe asegurarse de que estos agujeros necesiten contraseñas
adicionales para verificar su correcto uso. Puede hacer
que root
sea accesible añadiendo
cuentas administrativas al grupo
wheel
(en
/etc/group
). El personal que administra los
sistemas que aparezcan en el grupo
en el grupo wheel
pueden hacer
su
a root
.
Nunca debe de proporcionar al personal administrativo el acceso
nativo a wheel
poniéndolos
en el grupo wheel
en su entrada de
contraseña. Las cuentas administrativas deben colocarse
en un grupo staff
, y agregarse
después al grupo wheel
en
/etc/group
. Sólo aquellos
administradores que realmente necesiten acceder a
root
deben pertenecer al grupo
wheel
. También es posible,
mediante un método de autentificación como
Kerberos, usar el fichero .k5login
en
la cuenta root
para permitir un
ksu(1) a root
sin tener que
colocar a nadie en el grupo
wheel
. Puede ser una mejor solución,
ya que el mecanismo wheel
aún
permite a un atacante comprometer root
si el intruso ha conseguido el fichero de contraseñas
y puede comprometer una cuenta de administración.
Recurrir al mecanismo wheel
es mejor que
no tener nada, pero no es necesariamente la opción
más segura.
Una manera indirecta de asegurar las cuentas de staff y
el acceso a root
es utilizar un método
de acceso alternativo: es lo que se conoce como
“estrellar” las contraseñas cifradas de las
cuentas administrativas. Use vipw(8) para reemplazar
cada contraseña cifrada por un sólo caracter
asterisco (“*
”). Esto
actualizará
/etc/master.passwd
y la base de datos de
usuario/contraseña y deshabilitará los accesos
al sistema validados mediante
contraseñas.
Veamos una cuenta administrativa típica:
foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
y cómo debería quedar:
foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
Este cambio evitará que se efectúen logins normales,
ya que la contraseña cifrada nunca se corresponderá
con “*
”. Hecho esto, el personal
de administración tendrá que usar otro mecanismo
de validación como kerberos(1) o
ssh(1) que use un par de llave pública/privada.
Si decide usar algo como Kerberos tendrá que asegurar
la máquina que ejecuta los servidores Kerberos
y su estación de trabajo. Si usa un par de llave
pública/privada con ssh, debe asegurar la
máquina desde desde la que se hace el
login (normalmente nuestra estación de trabajo). Puede
añadir una capa adicional de protección al par de
llaves protegiéndolas con contraseña al crearlo
con ssh-keygen(1).
El “estrellado” de las contraseñas
administrativas también garantiza que dicho personal
sólo pueda entrar a través de métodos de
acceso que haya usted configurado. Así obligará
al personal administrativo a usar conexiones seguras, cifradas,
en todas sus sesiones, lo que cierra un importante agujero
de seguridad al que recurren muchos intrusos: usar un
sniffer (olfateador) de red desde una máquina que le
permita hacer tal cosa.
Los mecanismos de seguridad más indirectos también asumen que está validando su identidad desde un servidor más restrictivo un servidor menos restrictivo. Por ejemplo, si su máquina principal ejecuta toda clase de servidores su estación de trabajo no debe ejecutar ninguno. Para que su estación de trabajo sea razonablemente segura debe ejecutar los mínimos servidores posibles, si es posible ninguno, y debe usar un salvapantallas protegido por contraseña. Es evidente que un atancante con acceso físico al sistema puede romper cualquier barrera de seguridad que se disponga. Es un problema a tener en cuenta, pero la mayoría de las intrusiones tienen lugar de forma remota, a través de la red, por parte de gente que no tiene acceso físico a su estación de trabajo ni a sus servidores.
Usar Kerberos le ofrece también el poder de deshabilitar o cambiar la contraseña para una cuenta administrativa en un lugar, y que tenga un efecto inmediato en todas las máquinas en las cuales ese administrador pueda tener una cuenta. Si una de esas cuentas se ve comprometida la posibilidad para cambiar instantáneamente su contraseña en todas las máquinas no debe ser desestimada. Con contraseñas distintas, el cambio de una contraseña en N máquinas puede ser un problema. También puede imponer restricciones de re-contraseñas con Kerberos: no sólo se puede hacer un ticket de Kerberos que expire después de un tiempo, sino que el sistema Kerberos puede requerir al usuario que escoja una nueva contraseña después de cierto tiempo (digamos una vez al mes).
Un administrador de sistemas prudente sólo
ejecutará los servidores que necesita, ni uno más
ni uno menos. Dese cuenta de que los servidores ajenos son
los más propensos a contener errores. Por ejemplo,
ejecutando una versión desfasada de
imapd o
popper es como dar una entrada universal
de root
al mundo entero.
Nunca ejecute un servidor que no haya revisado cuidadosamente.
Muchos servidores no necesitan ejecutarse como
root
. Por ejemplo, los dæmons
ntalk,
comsat y
finger pueden ejecutarse en una
caja de arena (sandbox) especial de usuario.
Una caja de arena no es perfecta, a menos que pase por muchos
problemas, pero la aproximación de cebolla a la seguridad
prevalece aún y todo: Si alguien es capaz de penetrar a
través de un servidor ejecutándose en una caja
de arena, todavía tendrá que salir de la caja de
arena. Cuantas más capas tenga que romper el atacante
menor será la posibilidad de éxito que tenga.
Se han encontrado vías de entrada a
root
en virtualmente todos los servidores
que se haya ejecutado como root
,
incluyendo servidores básicos del sistema.
Si está tiene una máquina a través de
la cual la gente sólo entra por
sshd, y nunca entra por
telnetd,
rshd, o
rlogind
apague esos servicios.
FreeBSD ejecuta por defecto
ntalkd,
comsat y
finger en una caja de arena.
Otro programa que puede ser candidato para ejecutarse en una
caja de arena es named(8).
/etc/defaults/rc.conf
contiene las directrices
necesarias (con comentarios) para usar named
en una caja de arena. Dependiendo de si
está instalando un nuevo sistema o actualizando un sistema
ya existente, las cuentas especiales de usuario que usan
estas cajas de arena puede que no estén instaladas.
El administrador de sistemas prudente debe investigar e
implementar cajas de arena para servidores siempre que sea
posible.
Existen numerosos servidores que no se suelen
ejecutar en cajas de arena:
sendmail,
imapd, ftpd,
y otros. Existen alternativas para algunos de ellos, pero
instalarlas puede requerir más trabajo del que tal vez
esté dispuesto a realizar (el factor comodidad ataca de
nuevo). Tal vez tenga que ejecutar estos servidores como
root
y depender de otros mecanismos para
detectar intrusiones que puedan tener lugar a través de
ellos.
Los otros grandes agujeros potenciales de
root
que encontramos en un sistema son los
binarios suid-root y sgid. La mayoría
de estos binarios, como rlogin,
están en /bin
, /sbin
,
/usr/bin
o /usr/sbin
.
Aunque no hay nada absolutamente seguro los binarios suid y sgid
del sistema por defecto pueden considerarse razonablemente
seguros. Aún así, de vez en cuando aparecen
agujeros root
en estos binarios.
En 1998 se encontró un agujero
root
en
Xlib
, que hacía a
xterm (que suele ser suid)
vulnerable. Es mejor prevenir que curar, y el administrador de
sistemas prudente restringirá los binarios suid, que
sólo el personal de administración debe ejecutar,
a un grupo especial al que sólo dicho personal pueda acceder,
y deshacerse de cualquier binario suid
(chmod 000
) que no se use.
Un servidor sin pantalla generalmente no necesita un binario
xterm. Los binarios sgid pueden ser
igual de peligrosos. Si un intruso logra comprometer un binario
sgid-kmem, el intruso podría leer
/dev/kmem
y llegar a leer el fichero
cifrado de contraseñas, poniendo en compromiso potencial
cualquier cuenta con contraseña. Por otra parte, un intruso
que comprometa el grupo kmem
puede monitorizar
las pulsaciones de teclado que se envien a través de ptys,
incluyendo las ptys a las que acceden usuarios que emplean
métodos seguros. Un intruso que comprometa el grupo
tty
puede escribir en la pty de casi
cualquier usuario. Si un usuario ejecuta un programa de terminal
o un emulador capaz de simular un teclado, el intruso podría
generar un flujo de datos que provoque que la terminal del
usuario muestre una orden en pantalla, orden que el usuario
ejecutará.
Las cuentas de usuario suelen ser las más difíciles de asegurar. Aunque puede imponer restricciones de acceso draconianas a su personal administrativo y “estrellar” sus contraseñas, tal vez no pueda hacerlo con todas las cuentas de todos sus usuarios. Si mantiene el control en un grado suficiente quizás lo logre y sea capaz de hacer que las cuentas de sus usuarios sean seguras. Si no, tendrá que ser más cuidadoso (aún) en la monitorización de esas cuentas. Usar ssh y Kerberos en cuentas de usuario da más problemas debido al soporte técnico y administrativo que requerirá, pero sigue siendo mejor solución que un fichero de contraseñas cifradas.
La única manera segura es ponerle *
a tantas contraseñas como sea posible y utilizar ssh o
Kerberos para acceder a esas cuentas. Aunque el fichero
cifrado de contraseñas (/etc/spwd.db
)
sólo puede ser legible para root
, puede
que un intruso consiga acceso de lectura a ese fichero, incluso sin
haber alcanzado el acceso de escritura como root.
Sus “scripts” de seguridad deben buscar siempre cambios en el fichero de contraseñas (consulte Revisión de integridad de ficheros más abajo) e informar de ellos.
Si un atacante compromete root
puede
hacer cualquier cosa, pero hay ciertas cosas que puede usted
preparar para “curarse en salud”. Por ejemplo,
la mayoría de los kernel modernos tienen un dispositivo
de los Kernels modernos tienen un integrado un
dispositivo de paquetes. En FreeBSD se llama
bpf
. Un intruso típico
tratará de ejecutar un “sniffer” de paquetes
en una máquina comprometida. No debería darle a
ese intruso tal recurso, y la mayoría de los sistemas no
necesitan el dispositivo
bpf
.
Pero si desactiva el dispositivo bpf
todavía tendrá que preocuparse por
/dev/mem
y
/dev/kmem
.
Desde ellos el intruso podría en dispositivos de disco
en bruto. También hay que tener muy en cuenta
una opción del kernel llamada cargador de módulos,
kldload(8). Un intruso con iniciativa puede usar un
módulo KLD para instalar su propio dispositivo
bpf
, u otro dispositivo
que le permita el “sniffing” en un kernel en
ejecución. Para prevenir estos problemas debe ejecutar el
kernel en un nivel de seguridad mayor, al menos en securelevel 1.
Puede configurar el securelevel mediante una sysctl
en la variable kern.securelevel
.
Una vez que tiene su securelevel a 1, los accesos de
escritura a dispositivos en bruto se
denegarán y se impondrán las banderas especiales
schg
.
También debe cerciorarse de activar la bandera
schg
en binarios críticos para el arranque,
directorios y scripts (dicho de otro modo, todo aquello que se
ejecuta antes de que se active el
securelevel). Puede ser que todo esto sea una exageración,
sobre todo teniendo en cuenta que la actualización del sistema
se complica bastante a medida que se incrementa el nivel de
seguridad. Puede ejecutar el sistema a un nivel de seguridad
superior pero no activar la bandera schg
en cada fichero y directorio del sistema. Otra posibilidad es
montar /
y /usr
como
sólo lectura. Recuerde que siendo demasiado draconiano
en aquello que busca proteger puede dificultar mucho la
detección de una intrusión.
Cuando se piensa de proteccón, sólo se puede
proteger la configuración central del sistema y los ficheros
de control hasta el momento en el que el factor comodidad salta
a la palestra. Por ejemplo, si usa
chflags
para activar el bit schg
en la mayoría de los ficheros de /
y /usr
probablemente sea contraproducente;
puede proteger los ficheros haciéndolo, pero también
cierra una vía de detección. La última capa
de su modelo de seguridad tipo cebolla es quizás la
más importante: la detección. El resto de su
estructura de seguridad será inútil (o peor
aún, le proporcionará un sentimiento de seguridad
totalmente infundado) si no puede detectar posibles intrusiones.
La mitad del trabajo de la cebolla es alentar al atacante, en lugar
de detenerlo, para darle a la parte de la ecuación de
detección una oportunidad de atraparlo con las manos en la
masa.
La mejor manera de detectar una intrusión es buscar ficheros modificados, perdidos, o cuya presencia o estado sea inesperado. La mejor forma de buscar ficheros modificados es desde otro sistema (que muchas veces es centralizado) con acceso restringido. Escribir sus “scripts” de seguridad en un sistema “extraseguro” y con acceso restringido los hace casi invisibles a posibles atacantes, y esto es algo muy importante. potenciales, y esto es importante. Para poderle sacar el máximo partido debe proporcionar a esa máquina con acceso restringido un acceso preferente al contenido de las otras máquinas de su entorno; suele hacerse mediante la importación vía NFS de sólo lectura de las demás máquinas, o configurando pares de llaves ssh para acceder a las otras máquinas desde la que tiene el acceso restringido. Si exceptuamos el tráfico de red, NFS es el método menos visible y le permite monitorizar los sistemas de ficheros de cada máquina cliente de forma prácticamente indetectable. Si su servidor de acceso restringido está conectado a las máquinas clientes a través de un concentrador o a través de varias capas de encaminamiento el método NFS puede ser muy inseguro, por lo que ssh puede ser la mejor opción, incluso con las huellas de auditoría que ssh va dejando.
Una vez que le da a una máquina de acceso restringido
(al menos) acceso de lectura a los sistemas cliente que va
a monitorizar, tendrá que escribir “scripts”
para efectuar la monitorización. Si va a usar un montaje
NFS puede escribir “scripts” utilizando simples
herramientas del sistema como
find(1) y md5(1). Es aconsejable ejecutar MD5
físicamente en los ficheros de las máquinas cliente
al menos una vez al día, y comprobar los ficheros de control
(los que hay en /etc
y
/usr/local/etc
) con una frecuencia incluso
mayor. Si aparecen discrepancias al compararlos con la
información basada en MD5 que la máquina de acceso
restringido usa como base debe hacer una comprobación
inmediata y profunda. Un buen “script” también
debe buscar binarios que sean suid sin razón aparente, y
ficheros nuevos o borrados en particiones del sistema como
/
y /usr
.
Si usa ssh en lugar de NFS será mucho más
complicado escribir el “script” de seguridad.
En esencia, tiene que pasar por scp
los
“scripts” a la máquina cliente para poder
ejecutarlos, haciéndolos visibles; por seguridad,
también tendrá que pasar vía
scp
los binarios (por ejemplo find) que
utilizan dichos “scripts”. El cliente
ssh de la máquina cliente
puede estar ya bajo el control del intruso. Con todo y con eso,
puede ser necesario usar ssh si trabaja sobre enlaces inseguros,
también es mucho más difícil de manejar.
Un buen “script” de seguridad buscará
también cambios en la configuración de los ficheros
de acceso de usuarios y miembros del personal de
administración:
.rhosts
, .shosts
,
.ssh/authorized_keys
, etc; en resumen,
ficheros fuera del rango de revisión
MD5
.
Si tiene que vérselas con una cantidad enorme de
espacio en disco para usuarios le llevará mucho tiempo
recorrer cada fichero de cada partición. En su caso
sería una buena idea configurar mediante opciones de
montaje la deshabilitación de binarios y dispositivos
suid en esas particiones. Revise las opciones
nodev
y nosuid
de
mount(8). Debería comprobarlos de todas maneras
al menos una vez por semana, ya que el objeto de esta capa es
detectar intrusiones, efectivas o no.
La contabilidad de procesos (vea accton(8)) es una opción con una carga relativamente ligera para el sistema operativo, y puede ayudarle como mecanismo de evaluación tras una intrusión. Es especialmente útil para rastrear cómo consiguión realmente acceder el intruso al sistema (asumiendo que el fichero esté intacto después de la intrusión).
Los “scripts” de seguridad deben procesar los logs, y los propios logs deben generarse de la forma más segura posible: un syslog remoto puede ser muy útil. Un intruso trata de cubrir sus huellas, los logs son un recurso crítico cuando el administrador de sistemas intenta determinar la hora y el método de la intrusión inicial. La ejecución de la consola del sistema en un puerto serie y recolectar la información de forma periódica en una máquina segura de monitorización de consolas es una forma de cumplir esta tarea.
Un poco de paranoia nunca está de más. Como norma, un administrador de sistemas puede añadir cualquier tipo de mecanismo de seguridad siempre y cuando no afecte a la comodidad, y puede añadir mecanismos de seguridad que sí afecten a la comodidad si tiene una buena razón para hacerlo. Más aún, un administrador de seguridad debe mezclar un poco de ambas cosas: si sigue al pie de la letra las recomendaciones que se dan en este documento también está sirviendo en bandeja de plata al posible atancante su metodología. Ese posible atacante también tiene acceso a este documento.
Esta sección cubre ataques de denegación de servicio. Un ataque DoS suele consistir en un ataque mediante paquetes. NO hay mucho que pueda hacerse contra un ataque mediante paquetes falsificados (“spoofed”) que busque saturar su red, pero puede limitar el daño asegurándose de que los ataques no tiren sus servidores.
Limitación de forks en el servidor.
Limitación de ataques “springboard” (ataques de respuesta ICMP, ping broadcast, etc.)
Caché de rutas del kernel.
Un típico ataque DoS contra un servidor con instancias
(forks) sería tratar de provocar que el servidor consuma
procesos, descriptores de fichero y memoria hasta tirar la
máquina.
inetd (consulte inetd(8))
dispone de varias opciones para limitar este tipo de ataque.
Recuerde que aunque es posible evitar que una máquina
caiga, generalmente no es posible evitar que un servicio sea
vea interrumpido a causa el ataque. Consulte la página
de manual de inetd atentamente y
sobre todo estudie las las opciones
-c
, -C
,
y -R
. Observe que los ataques con direcciones IP
falsificadas sortearán la opción -C
de
inetd, así que debe usar una
combinación de opciones. Algunos servidores
autónomos (“standalone”) cuentan con
parámetros de autolimitación de instancias.
Sendmail tiene la opción
-OMaxDaemonChildren
, que tiende a funcionar
mucho mejor que las opciones de límite
de carga de sendmail debido al retraso que provoca la carga.
Debe especificar un parámetro
MaxDaemonChildren
al inicio de
sendmail que sea lo suficientemente alto
como para gestionar la carga esperada, pero no tan alto que la
computadora no pueda absorber tal número de
sendmails sin caerse de boca.
También es prudente ejecutar sendmail en modo de cola
(-ODeliveryMode=queued
) y ejecutar el
dæmon (sendmail -bd
)
de manera independiente de las ejecuciones de cola
(sendmail -q15m
). Si a pesar de todo necesita
entregas en tiempo real puede ejecutar la cola a un intervalo
menor, como -q1m
, pero asegúrese de
especificar una opción MaxDaemonChildren
razonable para ese sendmail y así
evitar fallos en cascada.
Syslogd puede recibir ataques directos
y se recomienda encarecidamente que utilice la opción
-s
siempre que sea posible, y si no la opción
-a
.
También debe ser extremadamente cuidadoso con servicios de conexión inversa como el ident inverso de TCP Wrapper, que puede recibir ataques directos. No se suele usar el ident inverso de TCP Wrapper por esa misma razón.
Es una muy buena idea proteger los servicios internos
de acceso externo protegiéndolos vía con un cortafuegos
en los routers de frontera. La idea es prevenir ataques de
saturación desde el exterior de la LAN, y no tanto para
proteger servicios internos de compromisos
root
basados en red.
Configure siempre un cortafuegos exclusivo, esto es,
“restringir todo menos los puertos
A, B, C, D y M-Z”. De esta manera restringirá
todos sus puertos con números bajos excepto ciertos
servicios específicos como
named (si es el servidor primario de
una zona), ntalkd,
sendmail, y otros servicios accesibles
desde Internet. Si configura el cortafuegos de la otra
manera (como un cortafuegos inclusivo o permisivo), tiene grandes
posibilidades de que olvide “cerrar” un
par de servicios, o de que agregue un nuevo servicio interno y
olvide actualizar el cortafuegos. Puede incluso abrir el rango
de números de puerto altos en el cortafuegos para permitir
operaciones de tipo permisivo sin comprometer sus puertos
bajos. Recuerde también que FreeBSD le permite controlar
el rango de números de puerto utilizados para asignación
dinámica a través de las numerosas
net.inet.ip.portrange
de
sysctl
(sysctl -a | fgrep portrange
), lo cual
también facilita la complejidad de la configuración
de su cortafuegos. Por ejemplo, puede utilizar un rango normal
primero/último de 4000 ó 5000, y un rango de puerto
alto de 49152 a 65535; bloquée todo por debajo de
4000 (excepto para ciertos puertos específicos
accesibles desde Internet, por supuesto).
Otro ataque DoS común es llamado ataque
“springboard”: atacar un servidor de forma que
genere respuestas que lo sobrecarguen, sobrecarguen la red local
o alguna otra máquina. Los ataques más
comunes de este tipo son los
ataques ICMP ping broadcast.
El atacante falsifica paquetes ping enviados a la dirección
broadcast de su LAN simulando que la dirección IP origen
es la de la máquina que desean atacar. Si sus routers
de frontera no están configurados para lidiar con pings a
direcciones de broadcast su LAN termina generando suficientes
respuestas a la dirección origen falsificada como para saturar
a la víctima, especialmente cuando el atacante utiliza
el mismo truco en varias docenas de direcciones broadcast en
varias docenas de redes diferentes a la vez. Se han medido
ataques de broadcast de más de ciento veinte megabits.
Un segundo tipo de ataque “springboard” bastante
común se da contra el sistema de informe de error de ICMP.
Un atacante puede saturar la conexión entrante de red de un
servidor mediante la construcción de paquetes que generen
respuestas de error ICMP, provocando que el servidor sature su
conexión saliente de red con respuestas ICMP. Este tipo
de ataque también puede tumbar el servidor agotando sus
“mbufs”, especialmente si el servidor no puede
drenar lo suficientemente rápido las respuestas ICMP que
genera. El kernel de FreeBSD tiene una opción de
compilación llamada ICMP_BANDLIM
,
que limita la efectividad de este tipo de ataques.
La última gran categoría de ataques
“springboard” está relacionada con
ciertos servicios de inetd, como
el servicio de eco udp. El atacante simplemente imita un paquete
UDP con el puerdo de eco del servidor A como dirección de
origen, y el puerto eco del servidor B como dirección de
destino, estando ambos servidores en la misma LAN. Un atacante
puede sobrecargar ambos servidores y la propia LAN inyectando
simplemente un par de paquetes. Existen problemas similares
con el puerto
chargen. Un administrador de sistemas
competente apagará todos estos servicios internos de
verificación de inetd.
Los ataques con paquetes falsificados pueden utilizarse
también para sobrecargar la caché de rutas del kernel.
Consulte los parámetros de sysctl
net.inet.ip.rtexpire
,
rtminexpire
, y
rtmaxcache
.
Un ataque de paquetes falsificados que utiliza una dirección
IP origen aleatoria provocará que el kernel genere una
ruta temporal en caché en su tabla de rutas, visible con
netstat -rna | fgrep W3
. Estas rutas
suelen expiran en 1600 segundos más o menos. Si el
kernel detecta que la tabla de rutas en caché es ya
demasiado grande reducirá dinámicamente
rtexpire
, pero nunca la reducirá a un
valor que sea menor que rtminexpire
.
Esto nos presenta dos problemas:
El kernel no reacciona con suficiente rapidez cuando un servidor ligeramente cargado es atacado.
El rtminexpire
no es lo suficientemente
bajo para que el kernel sobreviva a un ataque sostenido.
Si sus servidores están conectados a Internet mediante
mediante una línea T3 o superior puede ser prudente corregir
manualmente
rtexpire
y rtminexpire
por medio de sysctl(8). Nunca ponga ambos parámetros
a cero (a menos que desée estrellar la máquina).
Configurar ambos parámetros a 2 segundos debería
bastar para proteger de ataques la tabla de rutas.
Existen un par de detalles con respecto a
Kerberos y ssh que debe analizar sy pretende usarlos.
Kerberos V es un excelente protocolo de
protocolo de autentificación, pero hay errores en la
versión kerberizada de telnet
y rlogin que las hacen
inapropiadas para gestionar flujos binarios.
Ademé Kerberos no cifra por defecto una
sesión a menos que utilice la opción
-x
. ssh cifra todo
por defecto.
ssh funciona bastante bien en todos los casos, con la sola
salvedad de que por defecto reenvía llaves de cifrado.
Esto significa que si usted tiene una estación de trabajo
segura, que contiene llaves que le dan acceso al resto del sistema,
y hace ssh a una máquina insegura, sus llaves se pueden
utilizar. Las llaves en sí no se exponen, pero ssh
crea un puerto de reenvío durante el login, y si un
atacante ha comprometido el root
de la máquina insegura, puede utilizar ese puerto
para usar sus llaves y obtener acceso a cualquier otra
máquina que sus llaves abran.
Le recomendamos que, siempre que sea posible, use ssh
combinado con Kerberos en los login de su personal de
administración.
para logins de staff. Puede compilar
ssh con soporte de Kerberos.
Esto reducirá su dependencia de llaves ssh expuestas,
al mismo tiempo que protege las contraseñas vía
Kerberos. Las llaves ssh deben usarse sólamente para
tareas automáticas desde máquinas seguras
(algo que Kerberos no hace por incompatibilidad). Recomendamos
también que desactive el reenvío de llaves
en la configuración de ssh, o que use la
opción from=IP/DOMAIN
que ssh incluye
en authorized_keys
; así la llave
sólo podrá ser utilizada por entidades que se
validen desde máquinas
específicas.
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Si tiene dudas sobre FreeBSD consulte la
documentación antes de escribir a la lista
<questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a
<doc@FreeBSD.org>.