Rkhunter (o Rootkit Hunter) es una herramienta de Linux que detecta los rootkits, los backdoors y los exploit locales mediante la comparación de los hashes MD5 de archivos importantes con su firma correcta en una base de datos en línea, buscando los directorios por defecto (de rootkits), los permisos incorrectos, los archivos ocultos, las cadenas sospechosas en los módulos del kernel, y las pruebas especiales para Linux.
Instalación:
Para instalar RKHunter se debe ejecutar:
cd /usr/local/src wget 'http://downloads.sourceforge.net/project/rkhunter/rkhunter/1.4.2/rkhunter-1.4.2.tar.gz' tar xvzf rkhunter-1.4.2.tar.gz cd rkhunter-1.4.2 ./installer.sh --layout default --install
Para probarlo se debe ejecutar:
/usr/local/bin/rkhunter -c
Para crear un Email diario con los resultados del RKHunter, se debe ejecutar:
nano -w /etc/cron.daily/rkhunter.sh
Y colocar en el archivo:
#!/bin/bash (/usr/local/bin/rkhunter -c --nocolors --cronjob --createlogfile --skip-keypress --quiet --summary --rwo 2>&1 | mail -s "Informe Diario de Rkhunter en el Servidor N" hostmaster@sudominio.com)
Salir y Guardar.
Luego debemos colocar los permisivos de ejecución:
chmod 755 /etc/cron.daily/rkhunter.sh
Ahora debemos actualizar la base de datos del RKHunter con:
rkhunter --update
Y crear el archivo inicial con:
rkhunter --propupd
Adicionalmente se puede editar el archivo de configuración:
nano /etc/rkhunter.conf
Buscar las siguientes variables y configurar el email:
MAIL-ON-WARNING=hostmaster@sudominio.com MAIL_CMD=mail -s "[rkhunter] Advertencias encontradas en el Servidor N"
Adicionalmente, es posible configurar para que no de falsas alarmas en CentOS por scripts, por ejemplo:
Luego de finalizado, para ver un reporte detallado de las advertencias (warnings) debemos ejecutar:
nano /var/log/rkhunter.log
ó
cat /var/log/rkhunter.log | more
Finalmente, para que se actualice solo diariamente el RKHunter, debemos entrar por webmin (Desarrollo) y crear una tarea planificada (cron) con los siguientes datos:
Un rootkit es una herramienta, o un grupo de ellas que tiene como finalidad esconderse a sí misma y esconder otros programas, procesos, archivos, directorios, claves de registro, y puertos que permiten al intruso mantener el acceso a un sistema para remotamente comandar acciones o extraer información sensible.
Chkrootkit (Check Rootkit) es una aplicación por consola que permite localizar rootkits conocidos, realizando múltiples pruebas en las que busca entre los binarios modificados por dicho software. Usa herramientas comunes de Linux como las órdenes strings y grep para buscar las bases de las firmas de los programas del sistema y correlacionar los resultados del archivo /proc con la salida de la orden ps (estado de los procesos (process status) para buscar discrepancias. Básicamente hace múltiples comprobaciones para detectar todo tipo de rootkits y archivos maliciosos.
Existen limitaciones inherentes en la confiabilidad de cualquier programa que procure detectar compromisos (tales como rootkits y virus informáticos). Los nuevos rootkits pueden específicamente intentar detectar y comprometer copias del programa chkrootkit o tomar otras medidas para evadir las detecciones que éste efectúa.
Instalación
Para instalar ChkRootKit debe ejecutarse:
cd /usr/local/src wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz tar xvzf chkrootkit.tar.gz cd chkrootkit* make sense
Nota: Verificar el md5, ingresando en ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.md5
Para ejecutar manualmente el comando es:
./chkrootkit [opciones] [nombre-a-probar]
Las [opciones] son:
-h Muestra la ayuda y sale
-V Muestra la versión y sale
-l Muestra las pruebas disponibles
-d Depuración
-q Modo Silencio
-x Modo Experto
-r dir Utiliza a dir como el directorio raiz
-p dir1:dir2:dirN Ubicación de los comandos externos usados por chkrootkit
-n Salta los directorios montados con NFS
Es de hacer notar que las opciones no funcionan sin los nombres de las pruebas a realizar [nombre-a-probar].
Los [nombre-a-probar] son:
aliens asp bindshell lkm rexedcs sniffer w55808 wted scalper slapper
z2 chkutmp amd basename biff chfn chsh cron crontab date du dirname
slogin sendmail sshd syslogd tar tcpd tcpdump top telnetd timed
traceroute vdir w write
Por ejemplo, el siguiente comando verifica si los ejecutables de ps y ls tienen troyanos y también verifica si la interfaz de red está en modo promiscuo:
./chkrootkit ps ls sniffer
La opción ‘-q’ puede usarse para colocar al chkrootkit en Modo Silencio. En este modo la salida resultante solo mostrará los mensajes con el estado infectado (`infected’) para las pruebas escogidas en [nombre-a-probar].
Con la opción `-x’ el usuario puede examinar cadenas sospechosas en los programas ejecutables que podrían indicar la existencia de un troyano. Todo el análisis se deja en manos del administrador del sistema. Puede verse mucha información ejecutando:
./chkrootkit -x | more
ó
./chkrootkit -x | egrep '^/'
chkrootkit utiliza los siguientes comandos para ejecutar sus pruebas:
Es posible usar la opción `-p’ para indicar la ubicación alternativa al chkrootkit de tal forma que no haga uso de los ejecutables del sistema posiblemente comprometido para realizar sus pruebas. Por ejemplo para utilizar los ejecutables ubicados en CD ROM (/cdrom/bin) puede ejecutarse:
./chkrootkit -p /cdrom/bin
Para lograr que nos envíe un email diario de ejecución debemos seguir los pasos a continuación:
nano /etc/cron.daily/chkrootkit.sh
Colocar dentro del archivo lo siguiente:
#!/bin/bash cd /usr/local/src/chkrootkit-0.50/ ./chkrootkit | grep INFECTED | mail -s "Ejecucion diaria de chkrootkit en el Servidor N" hostmaster@sudominio.com
Salir y Guardar.
Nota: En el texto del mensaje cambiar N por el número o nombre del servidor correspondiente.
Luego se debe colocar el permisivo adecuado al archivo creado con:
chmod 755 /etc/cron.daily/chkrootkit.sh
Para ejecutar una prueba ingresar en:
cd /etc/cron.daily/
y luego ejecutar
./chkrootkit.sh
Falso Positivo:
En los emails recibidos de chkrootkit se anuncia:
Checking `bindshell'... INFECTED (PORTS: 465)
Esto es un falso positivo para los servidores basados en Fedora y CentOS
Una de las formas como los intrusos tratan de violar el correcto funcionamiento de un servidor y abusar del mismo es instalando y ejecutando programas en perl y/o cgis en los directorios temporales que tienen permisología 777. Para evitar esto debemos bloquear dicho tipo de ejecuciones ejecutando:
nano -w /etc/fstab
Buscar las líneas donde aparece /tmp, /var/tmp, y:
Donde diga defaults, eliminar defaults y agregar loop,noexec,nosuid,rw
(Esto no existe normalmente en los servidores CentOS)
A su vez, buscar la línea donde aparece /dev/shm, y:
Donde diga defaults, eliminar defaults y agregar noexec,nosuid
Una de las tareas que debe hacer a diario un Administrador de Servidores Linux es realizar un análisis de los archivos de registro de eventos (logs) de las aplicaciones principales.
Logwatch es un servicio de monitorización y detección de intrusiones basado en el análisis de los archivos de registro de eventos (logs) del sistema que suelen estar localizados en /var/log/. Con una frecuencia determinada (se suele ejecutar cada noche) analiza los logs del sistema y realiza un reporte que es enviado de inmediato al administrador vía correo electrónico.
Los registros que se llevan a cabo en un sistema Linux son manejados por el demonio syslogd-ng y su archivo de configuración suele estar localizado en /etc/syslog-ng/syslog-ng.conf.
LogWatch es bastante útil para saber que ha estado haciendo el servidor cada día sin tener que leerse decenas de logs ya que proporciona un resumen de cada servicio del sistema, tales como los paquetes instalados, emails enviados por el servidor, errores de autentificación, estadísticas de apache, espacio en disco, información sobre posibles ataques, etc.
Instalación
Para realizar la instalación de LogWatch se debe ejecutar:
cd /usr/local/src wget ftp://rpmfind.net/linux/sourceforge/l/lo/logwatch/logwatch-7.4.1/logwatch-7.4.1-1.noarch.rpm rpm -Uvh logwatch-7.4.1-1.noarch.rpm
Asegurar definir el correo electrónico, el nivel de detalle del reporte y que la salida del programa no vaya a una impresora, para ello colocar los siguientes valores a las variables indicadas:
Mailto = hostmaster@sudominio.com (no debe ser root sino una cuenta externa por seguridad) Detail = Low Print = No
Luego Guardar el archivo.
Para ejecutarlo se ejecuta directamente:
logwatch
Para eliminar problemas de emails muy largos debemos editar su configuración:
nano /etc/logwatch/conf/ignore.conf
Y agregar las líneas:
GETDISKUSED CP-Wrapper
Guardar y listo.
Análisis de Registros Típicos del Logwatch
A continuación colocamos algunos ejemplos de la información recibida en los emails del Logwatch y el análisis de los mismos:
——————— BFD Begin ————————
Mensaje:
Banned: 218.38.30.208 : (bfd.courier)
Análisis:
El BFD detectó un intento de ataque de fuerza bruta en el servicio indicado entre paréntesis y agregó al APF la IP indicada para bloquearla.
———————- BFD End ————————-
——————— clam-update Begin ————————
Mensaje:
Last ClamAV update process started at Sat Mar 20 22:10:40 2010
Last Status:
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.93 Recommended version: 0.95.3
Database updated (734890 signatures) from database.clamav.net (IP: 65.120.238.5)
Análisis:
El Clamav es el antivirus que se maneja en los servidores. Estos mensajes corresponden a la actualización diaria de sus bases de datos. Mayor información está en: http://www.clamav.net/support/faq
———————- clam-update End ————————-
——————— Cron Begin ————————
Mensaje:
Files with bad mode:
/etc/cron.d/bfd
/etc/cron.d/lsm
Análisis:
El servicio crond reporta que dos crones colocados en la carpeta correspondiente tienen permisología incorrecta. En el caso del ejemplo los archivos bfd y lsm tenían permisos 755 y deben ser 644 ya que no son ejecutables sino que guardan la información de los crones a ejecutar.
———————- Cron End ————————-
——————— IMAP Begin ————————
Mensaje:
[IMAPd] Logout stats:
====================
User | Logouts | Downloaded | Mbox Size
—————————————- | ———– | —————– | —————
Nombre1@dominio1.net | 95 | 0 | 0
Nombre2@dominio2.com.ve | 101 | 18214 |
—————————————————————————
8937 | 404711617 | 0
Análisis:
Resumen de todos los usuarios de correo electrónico que se conectaron al servidor incluyendo la cantidad de conexiones en el día y la cantidad de bytes descargados por emails. El análisis de estos números permite diagnosticar abusos y desviaciones en las tendencias normales de la emisión de emails.
Mensaje:
**Unmatched Entries** /usr/lib/courier-imap/etc/shared/index: No such file or directory: 36 Time(s)
Análisis:
El archivo en referencia es usado cada vez que un usuario se conecta al Horde. Es un bug típico de cPanel que se soluciona ejecutando el comando touch para crear dicho archivo vacío.
Mensaje:
44 active connections.: 2 Time(s)
47 active connections.: 208 Time(s)
48 active connections.: 700 Time(s)
49 active connections.: 305 Time(s)
50 maximum active connections.: 166 Time(s)
Análisis:
Indica la cantidad de conexiones al servicio de email simultáneas activas. Normalmente el límite en el exim del cPanel es de 50 conexiones activas, sin embargo se puede cambiar de ser necesario ingresando en: WHM > Service Configuration > Mailserver Configuration
Indica que la dirección de email señalada ha fallado en el login la cantidad de veces mostrada al final desde dicha IP. Esto permite analizar cuando una cuenta de email esta tratando de ser violada y normalmente deberíamos bloquearla. En pe articular la IP mostrada en el ejemplo pertenece a la empresa Research In Motion (RIM) a la cual pertenece la red blackberry lo que nos indica que el problema de la clave lo tiene un usuario específico en un teléfono celular y deberíamos informarle al administrador de dicho dominio para que lo resuelva.
———————- IMAP End ————————-
——————— Kernel Begin ————————
Mensaje:
WARNING: Kernel Errors Present
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x40) …: 1 Time(s)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4) …: 3 Time(s)
Análisis:
Reporte de advertencia del Kernel respect al driver de manejo de discos. Aparentemente puede estar relacionado con bugs de drivers de dicso o del kernel para Fedora.
———————- Kernel End ————————-
——————— Named Begin ————————
Mensaje:
Zone update refused:
190.202.101.242 (dominio.com.ve/IN): 3 Time(s)
Análisis:
Desde la IP indicada se solicitó la actualización de la Zona DNS para el dominio y fue rechazada.
Los dominios señalados no estan respondiendo desde el servidor. Esto es típico cuando los DNS asignados a los dominios apuntan hacia nuestro servidor pero dichos dominios no han sido configurados en el servidor. Esto se soluciona parqueando los dominios a nuestro dominio principal del servidor y/o a otros dominios principales con los que se relacionen si existen en el mismo.
———————- Named End ————————-
——————— pam_unix Begin ————————
Mensaje:
su:
Authentication Failures:
miusuario(32078) -> root: 1 Time(s)
Sessions Opened:
root -> root: 6 Time(s)
Análisis:
Indica que “miusuario” se conectó por SSH y al ejecutar “su” para pasarse como “root” colocó mal la contraseña una vez. Adicionalmente hubo seis conexiones exitosas por SSH como root (usando su).
———————- pam_unix End ————————-
——————— POP-3 Begin ————————
Mensaje:
[POP3] Logout stats (in MB):
============================
User | Logouts | Downloaded | Mbox Size
————————————— | ———- | —————– | ———-
nombre@dominio.com.ve | 6 | 7.41 | 0
nombre2@dominio.com.ve | 4 | 21.00 |
Análisis:
Resumen de las veces en que las cuentas de correo se conectaron para recibir emails por POP3 y la cantidad de bytes descargados. El análisis de estos números permite diagnosticar abusos y desviaciones en las tendencias normales de la emisión de emails.
Indica que la dirección de email señalada ha fallado en el login la cantidad de veces mostrada al final desde dicha IP. Esto permite analizar cuando una cuenta de email esta tratando de ser violada y normalmente deberíamos bloquearla. En pe articular la IP mostrada en el ejemplo pertenece a la empresa Research In Motion (RIM) a la cual pertenece la red blackberry lo que nos indica que el problema de la clave lo tiene un usuario específico en un teléfono celular y deberíamos informarle al administrador de dicho dominio para que lo resuelva.
———————- POP-3 End ————————-
——————— Connections (secure-log) Begin ————————
Mensaje:
**Unmatched Entries**
Cp-Wrap: Pushing “32151 NULLIFY grupodiga.com.ve eantonio ” to ‘/usr/local/cpanel/bin/mxadmin’ for UID: 32151 : 3 Time(s)
Análisis:
Aparentemente es causado por errores en las conexiones cuando se ha estado administrando funciones en el panel del reseller.
———————- Connections (secure-log) End ————————-
——————— Smartd Begin ————————
Mensaje:
Warnings:
Warning via mail to root: successful – 2 Time(s)
Sending warning via mail to root … – 2 Time(s)
Análisis:
Se emitió por email al root el mensaje de advertencia de fallas de smartd acerca del comportamiento del disco duro.
Mensaje:
**Unmatched Entries**
Device: /dev/sdc, failed to read SMART Attribute Data
Análisis:
El disco /dev/sdc ha fallado al leer la información de atributos del smartd. Debe verificarse
———————- Smartd End ————————-
——————— SSHD Begin ————————
Mensaje:
Users logging in through sshd:
miusuario:
201.242.236.103 (201-242-236-103.genericrev.cantv.net): 3 times
Análisis:
Indica la dirección IP, red y el usuario que se ha conectado por SSH así como las veces que lo ha hecho.
Mensaje:
**Unmatched Entries**
reverse mapping checking getaddrinfo for 201-242-236-103.genericrev.cantv.net [201.242.236.103] failed – POSSIBLE BREAK-IN ATTEMPT! : 3 time(s)
Análisis:
Indica que se ha hecho un análisis inverso y la IP desde la cual se conectó el usuario por SSH posiblemente sea un intento de intrusión. En el caso del ejemplo es un falso positivo ya que la IP fue usada por nosotros mismos para conectarnos en un momento dado.
———————- SSHD End ————————-
——————— Disk Space Begin ————————
Mensaje:
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 2.9G 305M 2.4G 12% /
/dev/sda8 48G 18G 28G 39% /home
/dev/sda7 996M 139M 806M 15% /tmp
/dev/sda3 9.5G 4.2G 4.8G 47% /var
/dev/sda2 9.5G 4.4G 4.6G 49% /usr
/dev/sda1 99M 12M 83M 13% /boot
/dev/sdb1 74G 28G 43G 40% /backup
Análisis:
Provee un resumen del uso de espacio en disco. Hay que estar pendientes de las particiones donde se guardan los logs (/var y /usr).
OPCIONAL: Se prefiere instalar como prevención de fuerza bruta la funcionalidad LFD para los servidores de producción ya que esta integrado al CSF y este al WHM y permite una mejor interacción y manejo de aspectos de seguridad el cPanel/WHM.
Ataque de fuerza bruta
Se denomina “ataque de fuerza bruta” a la forma de obtener una contraseña probando todas las combinaciones posibles hasta encontrar aquella que permite el acceso. Estos intentos múltiples pueden hacerse tanto a nivel de interfaces web como a través de conexiones SSH, FTP, entre otros.
Analizando el registro de eventos de las aplicaciones (archivos logs) para verificar los errores de autenticación (errores de login y contraseñas de acceso), es posible determinar si existen múltiples intentos de violación de usuarios y/o contraseñas.
BFD es un script de consola modular para el análisis de registros de eventos de aplicaciones y comprobación de errores de autenticación. Esto se consigue mediante un sistema de reglas donde se almacenan opciones específicas de aplicaciones incluyendo expresiones regulares para cada formato único auth. Las expresiones regulares se analizan contra los registros de eventos con la herramienta ‘sed’ (editor de secuencias) que permite un rendimiento excelente en todos los entornos. Además de los beneficios del análisis de registros de eventos en secuencias con “sed”, BFD también utiliza un sistema de seguimiento de los registros de eventos para que sólo se analicen los registros desde el último punto leído previamente. Esto ayuda a ampliar enormemente el rendimiento de BFD ya que no estamos leyendo continuamente los mismos registros. El sistema de seguimiento de registros de eventos es compatible con las rotaciones de registros de eventos al estilo de syslog/logrotate que le permite detectar cuando han ocurrido rotaciones y agarrar colas de registros del nuevo archivo de registros y del archivo de registro rotado.
Es posible utilizar al BFD para bloquear atacantes utilizando cualquier número de herramientas tales como el firewall APF, así como, iptables crudas, enrutamiento de ips o ejecutar cualquier comando personalizado. También permite crear un mensaje de correo electrónico completamente personalizable con las alertas del sistema utilizando una sencilla plantilla de correo electrónico editable por el administrador. El seguimiento de atacantes en BFD se administra mediante archivos de texto plano simples, que están controlados en tamaño para evitar las limitaciones de espacio con el tiempo, haciéndolo ideal para dispositivos sin disco. También hay un histórico de ataques que almacena datos de las tendencias de todos los hosts que se han bloqueado, incluyendo qué reglas de bloqueo fueron aplicadas.
El proceso de ejecución es simplemente una tarea de cron que ejecuta el BFD una vez cada 3 minutos en forma predeterminada. El cronjob puede ejecutarse con más frecuencia para aquellos que deseen hacerlo y no provocará ningún problema de rendimiento (no colocar con menos de una vez por minuto). Aunque la ejecución del cron no permite al BFD actuar en tiempo real, el sistema de seguimiento de registros de eventos asegura que nunca se pierda nada en errores de autenticación.
Instalación
Para realizar la instalación de BFD debemos ejecutar:
cd /usr/local/src wget http://www.rfxn.com/downloads/bfd-current.tar.gz tar -xvzf bfd-current.tar.gz cd bfd-1.5-2
Ejecutar el archive de instalación:
./install.sh
Se presentará un mensaje indicando que ha sido instalado con la siguiente información:
Ahora debemos editar la configuración del BFD con:
nano /usr/local/bfd/conf.bfd
Debemos habilitar las Alertas de Fuerza Bruta y configurar el Email:
Buscar:
ALERT_USR="0" EMAIL_USR="root"
Y cambiar a:
ALERT_USR="1" (EMAIL_ALERTS="1") EMAIL_USR="hostmaster@sudominio.com" (EMAIL_ADDRESS="hostmaster@sudominio.com") EMAIL_SUBJECT="ADVERTENCIA: Intento de Ataque de Fuerza Bruta en el servidor $HOSTNAME"
Guardar los cambios (CTRL X, Y, Enter)
Luego debemos prevenir que nos bloquee a nosotros mismos, para ello:
nano -w /usr/local/bfd/ignore.hosts
Colocar nuestras direcciones IP posibles, por ejemplo:
OPCIONAL: Se prefiere instalar como firewall el CSF para los servidores de producción ya que esta integrado al WHM y permite una mejor interacción y manejo de aspectos de seguridad el cPanel/WHM. A su vez, existe un módulo de dicho firewall para el Webmin, es por ello que la instalación del firewall APF explicada aquí es opcional (Por ejemplo, lo usamos para servidores de centrales telefónicas basadas en VoIP).
Generalidades
Para impedir la intrusión indebida a través de puertos del servidor hacemos uso del Firewall APF.
El Firewall de Directivas Avanzadas (APF) es un sistema de cortafuegos de basado en iptables (netfilter) diseñado en torno a las necesidades esenciales de los servidores Linux. La configuración está diseñada para ser muy informativa y fácil de seguir. La gestión diaria se lleva a cabo desde la línea de comandos con el comando ‘apf’, que incluye información de uso detallada sobre todas las funciones.
El punto de vista técnico de APF es tal que utiliza las últimas características estables del proyecto de iptables (netfilter) para proporcionar un servidor de seguridad muy robusto y potente. El filtrado interpretado por APF se basa en tres niveles:
Políticas Basadas en Regla Estáticas (no confundir con un “cortafuegos estático”)
Conexión Basada en Políticas con Estados
Políticas Basadas en Cordura
El primer nivel de Políticas Basadas en Regla Estáticas es el método más tradicional de cortafuegos. Esto aplica cuando el servidor de seguridad tiene un conjunto de instrucciones (reglas) que no cambian acerca de cómo debe controlarse el tráfico en ciertas condiciones. Un ejemplo de una política basada en reglas estáticas sería al permitir/denegar el acceso de una dirección al servidor con el sistema de confianza o abriendo un nuevo puerto a través del archivo conf.apf. Por lo tanto, son reglas que con poca frecuencia o nunca cambian mientras se está ejecutando el servidor de seguridad.
El segundo método, Conexión Basada en Políticas con Estados, es un medio para distinguir paquetes legítimos de diferentes tipos de conexiones. Se permitirán sólo los paquetes que coincidan con una conexión conocida por el servidor de seguridad; otros paquetes serán rechazados. Un ejemplo de esto serían las transferencias de datos por FTP. Anteriormente, los cortafuegos tenían que definir un conjunto complejo de directivas estáticas para permitir las transferencias de datos para que el FTP fluyera sin problemas. En el caso de las Políticas de Estados, el cortafuegos puede ver que una dirección ha establecido una conexión en el puerto estándar para FTP (21) y a entonces relaciona dicha dirección con la porción de transferencia de datos de la conexión modificando dinámicamente el cortafuegos para permitir el tráfico.
El tercer método, Políticas Basadas en Cordura, es la capacidad del servidor de seguridad para comparar patrones que coinciden con diversos métodos de ataque conocidos o analizar el tráfico para ajustarse a los estándares de Internet. Un ejemplo de esto sería cuando un potencial atacante intenta forjar la dirección IP desde la que se originan los datos que se le envían al servidor, el APF puede simplemente descartar este tráfico u opcionalmente registrarlo y luego descartarlo. En la misma medida, otro ejemplo podría ser cuando un enrutador con fallas en la Internet comienza a retransmitir paquetes malos a su servidor, el APF puede simplemente descartarlos o re-enviárselos al enrutador para que deje de enviarle estos paquetes de nuevo (TCP reset).
Estos tres métodos claves de filtrado empleados por el APF son una generalización de cómo se construye el cortafuegos a nivel técnico. A su vez, hay muchas características en el APF que pueden ser utilizadas. A continuación se indica en forma resumida la mayoría de las características del APF para su referencia y revisión:
Archivo de configuración detallado y bien comentado
Filtrado de red de entrantes y salientes granular
Filtrado de red saliente en función de la Identificación de usuario
Filtrado de red basada en aplicaciones
Archivos de reglas de confianza con una sintaxis avanzada opcional
Sistema de confianza mundial donde las reglas se pueden descargar desde un servidor de administración central.
Bloqueo por Dirección Reactiva (RAB), próxima generación en línea de prevención de intrusiones
Modo de depuración para probar nuevas características y configuraciones
Característica de Carga Rápida que permite más de 1000 reglas cargadas en menos de 1 segundo
Se pueden configurar de forma independiente interfaces de red entrantes y salientes
Filtrado de puertos tcp/udp global e icmp con varios métodos de ejecución de filtros (colocar, rechazar, prohibir)
Políticas configurables para cada dirección ip en el sistema con variables de conveniencia para importar parámetros de configuración
Límite de tasa de flujo de paquetes que impide el abuso en el protocolo más abusado, icmp
Reglas de pre-enrutamiento y post-enrutamiento para un rendimiento óptimo de red
Soporte a la lista de bloqueo de dshield.org para prohibir redes expuestas con actividades sospechosas
Soporte a la Lista Peer y de No Enrutar de Spamhaus para prohibir los bloques de Ips conocidos como “zombis secuestrados”.
Puede ser configurado cualquier número de interfaces adicionales como confiables (no bloqueadas) o no confiables (bloqueadas)
Interfaces adicionales de cortafuegos pueden aplicar políticas propias
Verificación inteligente de rutas para evitar errores de configuración embarazosos
Avanzada comprobación de paquetes para asegurar que el tráfico entrando y saliendo cumple las normas más estrictas
Filtraje de ataques como UDP fragmentado, inundaciones de puerto cero, rellenos de enrutamiento, intoxicación arp, etc.
Opciones de tipo de servicio configurables para dictar la prioridad de los diferentes tipos de tráfico de red
Configuración predeterminada inteligente para satisfacer configuraciones de servidores típicas
Configuración dinámica de los servidores locales de resolución de DNS en el cortafuegos
Filtrado opcional de aplicaciones p2p comunes
Filtrado opcional de espacio de direcciones IP privadas & reservadas
Bloques implícitos del servicio ident opcionales
Parámetros de seguimiento de conexiones configurable para escalar el servidor de seguridad al tamaño de la red
Ganchos al núcleo (kernel) configurables para endurecer el sistema contra ataques de inundaciones syn y abusos de enrutamiento
Controles de red Avanzados tales como la notificación de congestión explícita y control de sobreflujo
Cadenas especiales que están conscientes del estado de las conexiones de datos por FTP y SSH para evitar problemas del lado cliente
Control sobre la tasa de sucesos registrados (desea filtrar sólo 30 eventos por minuto? É ¿300 en un minuto?, usted decide)
Subsistema de registro de eventos que permite los datos de registro para programas de espacio de usuario o archivos syslog estándar
Registro que detalla cada regla agregada y comprueba un conjunto integral de errores para evitar errores de configuración
Si está familiarizado con netfilter puede crear sus propias reglas en cualquiera de los archivos de política
Preparado para la conexión y uso avanzado de algoritmos de Calidad de Servicios (QoS) proporcionados por Linux
Proyectos de terceros que complementan las características del APF.
Instalación
Para instalar el APF se debe ingresar como root al SSH y ejecutar:
cd /usr/local/src wget http://www.rfxn.com/downloads/apf-current.tar.gz tar -xvzf apf-current.tar.gz cd apf-9.7/ (ó la versión que corresponda)
Ejecutar el archivo de instalación:
./install.sh
Se recibirá un mensaje en pantalla indicando que se instaló correctamente; como el siguiente:
Installation Details: Install path: /etc/apf/ Config path: /etc/apf/conf.apf Executable path: /usr/local/sbin/apf AntiDos install path: /etc/apf/ad/ AntiDos config path: /etc/apf/ad/conf.antidos DShield Client Parser: /etc/apf/extras/dshield/ Other Details: Listening TCP ports: 21,25,53,81,111,139,445,679,953,3306,29996 Listening UDP ports: 53,111,123,137,138,219,631,673,676,5353,29996,32770,32773 Note: These ports are not auto-configured; they are simply presented for information purposes. You must manually configure all port options.
Para configurar el firewall se debe editar el archivo conf.apf con:
nano /etc/apf/conf.apf
Buscar DLIST_DSHIELD y colocarlo en 1
Desbloquear los puertos bloqueados:
BLK_PORTS="111,513,520,1434,1234,1524,3127"
Configurar los puertos permitidos de entrada y salida y parámetros relacionados como sigue:
Nota: No confundirse con lo que esta comentado con # en el archivo, debe ser lo que no está comentado (si se usa CTRL+W para buscar las variables, lo primero que se consigue es lo comentado por lo que si no estamos pendientes nos podemos equivocar).
Con la finalidad de que el cursor de la consola del servidor (prompt) nos informe acerca del usuario que estamos usando en la conexión y la ubicación en la que estamos, debemos ejecutar:
nano /etc/profile
y agregar:
export PS1='\u@\h [\w]#'
Para verlo sin salirse del SSH ejecutar:
source /etc/profile
Para asegurar siempre el perfil adecuado al ingresar como root se debe ejecutar:
Normalmente un servidor Linux permite la conexión remota al servidor utilizando el puerto estándar del protocolo SSH (22) bajo el usuario root, ya que este usuario es estándar en Linux y tiene los permisos máximos para controlar el servidor. Esto se corrige limitando el acceso directo al SSH para el usuario root y asignando dicho acceso a otro usuario solo conocido por el verdadero administrador del servidor.
Para limitar el acceso del usuario root por SSH y no hacer uso del puerto estándar (22) debemos:
Vía SSH:
Debe haberse creado primero el usuario principal del servidor (adminXX) de acuerdo al punto 2.7 de este curso, asegurando que dicha cuenta tenga acceso SSH y que el usuario pertenece al grupo Wheel como lo indica dicho punto.
Debe probarse el acceso por SSH a través del puerto 22 usando el usuario adminXX y luego de ingresar ejecutar su con la contraseña de root para verificar que con dicho usuario es posible ingresar al servidor y convertirlo en root.
Si podemos ingresar con dicho usuario sin problemas y pudimos acceder con su como root entonces podemos proceder a cambiar el puerto de acceso y cerrar el acceso directo a SSH por root.
Para esto debemos ejecutar:
nano /etc/ssh/sshd_config
Buscar “Port 22“, y reemplazarlo por “Port XXXXX” (Sin las comillas, cambiando XXXXX por el número del puerto deseado – ej. 39563 – y quitándole el # para que no quede como comentario)
Buscar “PermitRootLogin yes” y reemplazarlo por “PermitRootLogin no” (Sin las comillas y quitándole el # para que no quede como comentario)
Buscar “useDNS yes” y reemplazarlo con “useDNS no“ (Sin las comillas y quitándole el # para que no quede como comentario)
Guardar el archivo
Reiniciar el servicio SSH ejecutando:
service sshd restart
(ó /etc/init.d/sshd restart )
Listo.
Ahora podemos entrar con el usuario adminXX por el puerto XXXXX con su respectiva contraseña y luego ejecutar su y colocar la contarseña de root para convertirlo en root.
Otro método, para los servidores de Desarrollo es usando el Webmin de la siguiente forma:
Usando Webmin (preferiblemente debe evitarse instalar el webmin):
1. Usar webmin para crear un administrador del servidor (ej. adminXX) con el Password correspondiente.
2. Asignar el usuario al grupo primario wheel y secundarios root y cualquier otro grupo interno que se desee.
3. Entrar al manejador del Módulo de SSH de Webmin y en:
a. Autenticación: Prohibir el acceso al root.
b. Red: Cambiar la IP de escuchar a la IP del servidor y el puerto estándar 22 al XXXXX (según el número de puerto deseado).
c. Control de Acceso: Colocar el acceso sólo al usuario configurado arriba.
d. Buscar useDNS y colocarlo en no
e. Reiniciar el servicio con el botón correspondiente.
OPCIONAL: En servidores de producción no se recomienda instalar el Webmin.
La primera manera de impedir que terceros intenten ingresar al servidor de manera forzada a través de intentos de uso de múltiples contraseñas para ingresar al webmin usando el usuario root (fuerza bruta) vía web, es limitar las direcciones IP´s de origen de tales conexiones para que sólo sean permitidas las direcciones de la ubicación de nuestra empresa. Para limitar que el acceso sólo se realice desde direcciones IP específicas debemos ingresar en:
Webmin > Configuración de Webmin > Control de Acceso a IP
Marcar “Sólo permitir desde las direcciones listadas“, colocar en el recuadro las direcciones desde donde nos conectaremos (ejemplo):
190.199.193.0/255.255.255.0
201.208.115.0/255.255.255.0
200.44.189.0/255.255.255.0
Clic al botón Salvar y esto reiniciará el webmin. Esperar unos segundos y continuar.
Otro aspecto de seguridad que se debe hacer es cambiar el Puerto estándar de Conexión al Webmin (10000) ya que es conocido por todos los usuarios del mismo, para ello se debe ingresar:
Webmin > Configuración de Webmin > Puertos y Direcciones
Cambiar el puerto para Escuchar de 10000 (estándar) a cualquier otro que sea alto (por ejemplo 39592).
Clic al botón Salvar y esto reconectará el webmin a través del puerto especificado.
En el caso de que se presentan problemas con el webmin podemos desinstalarlo vía SSH con:
En el mundo de los servidores en línea, los protocolos de comunicación utilizados carecen (en su mayoría) de seguridad o esta ha sido implementada en forma de “parche” tiempo después de su creación.
Existen agujeros de seguridad en los sistemas operativos.
Existen agujeros de seguridad en las aplicaciones.
Existen errores en las configuraciones de los sistemas.
Los usuarios carecen de información respecto al tema.
Esta lista podría seguir extendiéndose a medida que se evalúen mayor cantidad de elementos de un Sistema Informático.
Las empresas u organizaciones no se pueden permitir el lujo de denunciar ataques a sus sistemas, pues el nivel de confianza de los clientes (ciudadanos) bajaría enormemente.
Los Administradores de Servidores tienen cada vez mayor conciencia respecto de la seguridad de sus sistemas y arreglan por sí mismos las deficiencias detectadas. A esto hay que añadir las nuevas herramientas de seguridad disponibles en el mercado.
Los “advisories” (documentos explicativos) sobre los nuevos agujeros de seguridad detectados y la forma de solucionarlos, lanzados por el CERT (Laboratorio suizo donde nació la WWW), han dado sus frutos.
Acceso – Uso – Autorización
La identificación de estas palabras es muy importante ya que el uso de algunas implica un uso desapropiado de las otras.
Específicamente “Acceso” y “Hacer Uso” no son el mismo concepto cuando se estudian desde el punto de vista de un usuario y de un intruso. Por ejemplo:
Cuando un usuario tiene acceso autorizado, implica que tiene autorizado el uso de un recurso.
Cuando un atacante tiene acceso desautorizado está haciendo uso desautorizado del sistema.
Pero, cuando un atacante hace uso desautorizado de un sistema, esto implica que el acceso fue autorizado (simulación de usuario).
Luego un Ataque será un intento de acceso, o uso desautorizado de un recurso, sea satisfactorio o no. Un Incidente envuelve un conjunto de ataques que pueden ser distinguidos de otro grupo por las características del mismo (grado, similitud, técnicas utilizadas, tiempos, etc.).
Identificación de las Amenazas
La identificación de amenazas requiere conocer los tipos de ataques, el tipo de acceso, la forma operacional y los objetivos del atacante.
Las consecuencias de los ataques se podrían clasificar en:
Corrupción de Datos (Data Corruption): La información que no contenía defectos pasa a tenerlos.
Denegación de Servicios (Denial of Service – DoS): Servicios que deberían estar disponibles no lo están.
Colación (Leakage): Los datos llegan a destinos a los que no deberían llegar.
Cualquier adolescente de 15 años (Script Kiddies), sin tener grandes conocimientos, pero con una potente y estable herramienta de ataque desarrollada por los Gurús, es capaz de dejar fuera de servicio cualquier servidor de información de cualquier organismo en Internet, simplemente siguiendo las instrucciones que acompañan la herramienta. Vale decir que existen mecanismos legales para penalizar a dicha persona, tales como la Ley de Delitos Informáticos, Ley de Datos y Firmas Electrónicas, entre otras.
Tipos de Ataques
A continuación se expondrán diferentes tipos de ataques perpetrados, principalmente, por Hackers. Estos ataques pueden ser realizados sobre cualquier tipo de red, sistema operativo, usando diferentes protocolos, etc.
En los primeros tiempos, los ataques involucraban poca sofisticación técnica. Los Insiders (operadores, programadores, data entrys) utilizaban sus permisos para alterar archivos o registros. Los Outsiders ingresaban a la red simplemente averiguando una contraseña válida. A través de los años se han desarrollado formas cada vez más sofisticadas de ataque para explotar “agujeros” en el diseño, configuración y operación de los sistemas, como son:
Ingeniería Social: Es la manipulación de las personas para convencerlas de que ejecuten acciones o actos que normalmente no realizan para que revele todo lo necesario para superar las barreras de seguridad. Si el atacante tiene la experiencia suficiente (generalmente es así), puede engañar fácilmente a un usuario (que desconoce las mínimas medidas de seguridad) en beneficio propio. Esta técnica es una de las más usadas y efectivas a la hora de averiguar nombres de usuarios y contraseñas.
Por ejemplo, suele llamarse a un usuario haciéndose pasar por el administrador del sistema y requerirle la contraseña con alguna excusa convincente. O bien, podría enviarse un mail (falsificando la dirección origen a nombre del administrador) pidiendo al usuario que modifique su contraseña a una palabra que el atacante suministra.
Para evitar situaciones de IS es conveniente tener en cuenta estas recomendaciones:
Tener servicio técnico propio o de confianza.
Instruir a los usuarios para que no respondan ninguna pregunta sobre cualquier característica del sistema y deriven la inquietud a los responsables que tengan competencia para dar esa información.
Asegurarse que las personas que llaman por teléfono son quien dicen ser. Por ejemplo si la persona que llama se identifica como proveedor de Internet lo mejor es cortar y devolver la llamada a forma de confirmación.
Ingeniería Social Inversa: Consiste en la generación, por parte de los intrusos, de una situación inversa a la originada en Ingeniería Social.
En este caso el intruso publicita de alguna manera que es capaz de brindar ayuda a los usuarios, y estos lo llaman ante algún imprevisto. El intruso aprovechará esta oportunidad para pedir información necesaria para solucionar el problema del usuario y el suyo propio (la forma de acceso al sistema).
La ISI es más difícil de llevar a cabo y por lo general se aplica cuando los usuarios están alertados acerca de las técnicas de IS. Puede usarse en algunas situaciones específicas y después de mucha preparación e investigación por parte del intruso:
Generación de una falla en el funcionamiento normal del sistema. Generalmente esta falla es fácil de solucionar pero puede ser difícil de encontrar por los usuarios inexpertos (sabotaje). Requiere que el intruso tenga un mínimo contacto con el sistema.
Comunicación a los usuarios de que la solución es brindada por el intruso (publicidad).
Provisión de ayuda por parte del intruso encubierto como servicio técnico.
Trashing (Cartoneo): Generalmente, un usuario anota su login y contraseña en un papelito y luego, cuando lo recuerda, lo arroja a la basura. Este procedimiento por más inocente que parezca es el que puede aprovechar un atacante para hacerse de una llave para entrar el sistema…”nada se destruye, todo se transforma”.
El Trashing puede ser físico (como el caso descrito) o lógico, como analizar buffers de impresora y memoria, bloques de discos, etc.
El Trashing físico suele ser común en organizaciones que no disponen de alta confidencialidad, como colegios y universidades.
Ataques de Monitorización
Este tipo de ataque se realiza para observar a la víctima y su sistema, con el objetivo de establecer sus vulnerabilidades y posibles formas de acceso futuro.
Shoulder Surfing:
Consiste en espiar físicamente a los usuarios para obtener el login y su password correspondiente. El Surfing explota el error de los usuarios de dejar su login y password anotadas cerca de la computadora (generalmente en post”it adheridos al monitor, teclado o dentro de un cuaderno). Cualquier intruso puede pasar por ahí, verlos y memorizarlos para su posterior uso. Otra técnica relacionada al surfing es aquella mediante la cual se ve, por encima del hombro, al usuario cuando teclea su nombre y password.
Decoy (Señuelos):
Los Decoy son programas diseñados con la misma interface que otro original. En ellos se imita la solicitud de un logeo y el usuario desprevenido lo hace. Luego, el programa guardará esta información y dejará paso a las actividades normales del sistema. La información recopilada será utilizada por el atacante para futuras “visitas”. Una técnica semejante es aquella que, mediante un programa se guardan todas las teclas presionadas durante una sesión (Keylogger). Luego solo hará falta estudiar el archivo generado para conocer nombres de usuarios y claves.
Scanning (Búsqueda):
El rastreo (Scaneo), como método de descubrir canales de comunicación susceptibles de ser explotados, lleva en uso mucho tiempo. La idea es recorrer (scanear) tantos puertos de escucha como sea posible, y guardar información de aquellos que sean receptivos o de utilidad para cada necesidad en particular. Muchas utilidades de auditoría también se basan en este paradigma. El Scaneo de puertos pertenece a la Seguridad Informática desde que era utilizado en los sistemas de telefonía. Dado que actualmente existen millones de números de teléfono a los que se pueden acceder con una simple llamada, la solución lógica (para encontrar números que puedan interesar) es intentar conectarlos a todos. La idea básica es simple: llamar a un número y si el módem devuelve un mensaje de conectado, grabar el número. En otro caso, la computadora cuelga el teléfono y llama al siguiente número. Scanear puertos implica las mismas técnicas de fuerza bruta. Se envía una serie de paquetes para varios protocolos y se deduce que servicios están “escuchando” por las respuestas recibidas o no recibidas. Existen diversos tipos de Scanning según las técnicas, puertos y protocolos explotados:
TCP Connect Scanning:
Esta es la forma básica del scaneo de puertos TCP. Si el puerto está escuchando, devolverá una respuesta de éxito; cualquier otro caso significará que el puerto no está abierto o que no se puede establecer conexión con él. Las ventajas que caracterizan esta técnica es que no necesita de privilegios especiales y su gran velocidad. Su principal desventaja es que este método es fácilmente detectable por el administrador del sistema. Se verá un gran número de conexiones y mensajes de error para los servicios en los que se ha conseguido conectar la máquina, que lanza el scanner, y también se verá su inmediata desconexión.
TCP SYN Scanning:
Cuando dos procesos establecen una comunicación usan el modelo Cliente/Servidor para establecerla. La aplicación del Servidor “escucha” todo lo que ingresa por los puertos. La identificación del Servidor se efectúa a través de la dirección IP del sistema en el que se ejecuta y del número de puerto del que depende para la conexión. El Cliente establece la conexión con el Servidor a través del puerto disponible para luego intercambiar datos. La información de control de llamada HandShake (saludo) se intercambia entre el Cliente y el Servidor para establecer un dialogo antes de transmitir datos. Los “paquetes” o segmentos TCP tienen banderas que indican el estado del mismo. El protocolo TCP de Internet, sobre el que se basa la mayoría de los servicios (incluyendo el correo electrónico, el web y el IRC) implica esta conexión entre dos máquinas. El establecimiento de dicha conexión se realiza mediante lo que se llama Three-Way Handshake (“conexión en tres pasos”) ya que intercambian tres segmentos.
En forma esquemática se tiene:
El programa Cliente (C) pide conexión al Servidor (S) enviándole un segmento SYN. Este segmento le dice a S que C desea establecer una conexión.
S (si está abierto y escuchando) al recibir este segmento SYN (activa el indicador) y envía una autentificación ACK de manera de acuse de recibo a C. Si S está cerrado envía un indicador RST.
C entonces ACKea (autentifica) a S. Ahora ya puede tener lugar la transferencia de datos.
Cuando las aplicaciones conectadas terminan la transferencia, realizaran otra negociación a tres bandas con segmentos FIN en vez SYN.
La técnica TCP SYN Scanning, implementa un scaneo de “media-apertura”, dado que nunca se abre una sesión TCP completa. Se envía un paquete SYN (como si se fuera a usar una conexión real) y se espera por la respuesta. Al recibir un SYN/ACK se envía, inmediatamente, un RST para terminar la conexión y se registra este puerto como abierto.
La principal ventaja de esta técnica de escaneo es que pocos sitios están preparados para registrarlos. La desventaja es que en algunos sistemas Unix, se necesitan privilegios de administrador para construir estos paquetes SYN.
TCP FIN Scanning-Stealth Port Scanning:
Hay veces en que incluso el scaneo SYN no es lo suficientemente “clandestino” o limpio. Algunos sistemas (Firewalls y filtros de paquetes) monitorizan la red en busca de paquetes SYN a puertos restringidos. Para subsanar este inconveniente los paquetes FIN, en cambio, podrían ser capaces de pasar sin ser advertidos. Este tipo de Scaneo está basado en la idea de que los puertos cerrados tienden a responder a los paquetes FIN con el RST correspondiente. Los puertos abiertos, en cambio, suelen ignorar el paquete en cuestión. Este es un comportamiento correcto del protocolo TCP, aunque algunos sistemas, entre los que se hallan los de Microsoft®, no cumplen con este requerimiento, enviando paquetes RST siempre, independientemente de si el puerto está abierto o cerrado. Como resultado, no son vulnerables a este tipo de scaneo. Sin embargo, es posible realizarlo en otros sistemas Unix. Este último es un ejemplo en el que se puede apreciar que algunas vulnerabilidades se presentan en las aplicación de tecnologías (en este caso el protocolo TCP nacido en los años ´70) y no sobre sus implementaciones. Es más, se observa que una implementación incorrecta (la de Microsoft®) soluciona el problema.
Fragmentation Scanning:
Esta no es una nueva técnica de scaneo como tal, sino una modificación de las anteriores. En lugar de enviar paquetes completos de sondeo, los mismos se particionan en un par de pequeños fragmentos IP. Así, se logra partir una cabecera IP en distintos paquetes para hacerlo más difícil de monitorizar por los filtros que pudieran estar ejecutándose en la máquina objetivo.
Sin embargo, algunas implementaciones de estas técnicas tienen problemas con la gestión de este tipo de paquetes tan pequeños, causando una caída de rendimiento en el sistema del intruso o en el de la víctima. Problemas de esta índole convierte en detectables a este tipo de ataque.
Eavesdropping-Packet Sniffing:
Muchas redes son vulnerables al Eavesdropping, o a la pasiva intercepción (sin modificación) del tráfico de red. Esto se realiza con Packet Sniffers, los cuales son programas que monitorean los paquetes que circulan por la red. Los Sniffers pueden ser colocados tanto en una estación de trabajo conectada a la red, como a un equipo Router o a un Gateway de Internet, y esto puede ser realizado por un usuario con legítimo acceso, o por un intruso que ha ingresado por otras vías. Cada máquina conectada a la red (mediante una tarjeta con una dirección única) verifica la dirección destino de los paquetes TCP. Si estas direcciones son iguales asume que el paquete enviado es para ella, caso contrario libera el paquete para que otras tarjetas lo analicen. Un Sniffer consiste en colocar a la tarjeta de red en un modo llamado promiscuo, el cual desactiva el filtro de verificación de direcciones y por lo tanto todos los paquetes enviados a la red llegan a esta tarjeta (computadora donde está instalado el Sniffer). Inicialmente este tipo de software, era únicamente utilizado por los administradores de redes locales, aunque con el tiempo llegó a convertirse en una herramienta muy usada por los intrusos. Actualmente existen Sniffers para capturar cualquier tipo de información específica. Por ejemplo passwords de un recurso compartido o de acceso a una cuenta, que generalmente viajan sin cifrar al ingresar a sistemas de acceso remoto. También son utilizados para capturar números de tarjetas de crédito y direcciones de e-mails entrantes y salientes. El análisis de tráfico puede ser utilizado también para determinar relaciones entre organizaciones e individuos. Para realizar estas funciones se analizan las tramas de un segmento de red, y presentan al usuario sólo las que interesan. Normalmente, los buenos Sniffers, no se pueden detectar, aunque la inmensa mayoría, y debido a que están demasiado relacionados con el protocolo TCP/IP, si pueden ser detectados con algunos trucos.
Snooping-Downloading:
Los ataques de esta categoría tienen el mismo objetivo que el Sniffing: obtener la información sin modificarla. Sin embargo los métodos son diferentes. Aquí, además de interceptar el tráfico de red, el atacante ingresa a los documentos, mensajes de correo electrónico y otra información guardada, realizando en la mayoría de los casos un downloading (copia de documentos) de esa información a su propia computadora, para luego hacer un análisis exhaustivo de la misma. El Snooping puede ser realizado por simple curiosidad, pero también es realizado con fines de espionaje y robo de información o software. Los casos más resonantes de este tipo de ataques fueron: el robo de un archivo con más de 1700 números de tarjetas de crédito desde una compañía de música mundialmente famosa, y la difusión ilegal de reportes oficiales reservados de las Naciones Unidas, acerca de la violación de derechos humanos en algunos países europeos en estado de guerra.
Ataques de Autenticación: Este tipo de ataque tiene como objetivo engañar al sistema de la víctima para ingresar al mismo. Generalmente este engaño se realiza tomando las sesiones ya establecidas por la víctima u obteniendo su nombre de usuario y password.
Spoofing-Looping
Spoofing puede traducirse como “hacerse pasar por otro” y el objetivo de esta técnica, justamente, es actuar en nombre de otros usuarios, usualmente para realizar tareas de Snooping o Tampering (ver a continuación Ataques de Modificación y Daño). Una forma común de Spoofing es conseguir el nombre y password de un usuario legítimo para, una vez ingresado al sistema, tomar acciones en nombre de él. El intruso usualmente utiliza un sistema para obtener información e ingresar en otro, y luego utiliza este para entrar en otro, y así sucesivamente. Este proceso, llamado Looping, tiene la finalidad de “evaporar” la identificación y la ubicación del atacante. El camino tomado desde el origen hasta el destino puede tener muchas estaciones, que exceden obviamente los límites de un país. Otra consecuencia del Looping es que una compañía o gobierno pueden suponer que están siendo atacados por un competidor o una agencia de gobierno extranjera, cuando en realidad están seguramente siendo atacado por un Insider, o por un estudiante a miles de Kilómetros de distancia, pero que ha tomado la identidad de otros. La investigación de procedencia de un Looping es casi imposible, ya que el investigador debe contar con la colaboración de cada administrador de cada red utilizada en la ruta.
El envío de falsos e-mails es otra forma de Spoofing que las redes permiten. Aquí el atacante envía e-mails a nombre de otra persona con cualquier motivo y objetivo. Tal fue el caso de una universidad en EE.UU. que en 1998, que debió reprogramar una fecha completa de exámenes ya que alguien en nombre de la secretaría había cancelado la fecha verdadera y enviado el mensaje a toda la nómina de estudiantes. Muchos ataques de este tipo comienzan con Ingeniería Social, y los usuarios, por falta de cultura, facilitan a extraños sus identificaciones dentro del sistema usualmente través de una simple llamada telefónica.
Spoofing
Este tipo de ataques (sobre protolocos) suele implicar un buen conocimiento del protocolo en el que se va a basar el ataque. Los ataques tipo Spoofing bastante conocidos son el IP Spoofing, el DNS Spoofing y el Web Spoofing
IP Spoofing:
Con el IP Spoofing, el atacante genera paquetes de Internet con una dirección de red falsa en el campo From, pero que es aceptada por el destinatario del paquete. Su utilización más común es enviar los paquetes con la dirección de un tercero, de forma que la víctima “ve” un ataque proveniente de esa tercera red, y no la dirección real del intruso.
En el caso Web Spoofing el atacante crea un sitio web completo (falso) similar al que la víctima desea entrar. Los accesos a este sitio están dirigidos por el atacante, permitiéndole monitorear todas las acciones de la víctima, desde sus datos hasta las passwords, números de tarjeta de créditos, etc. El atacante también es libre de modificar cualquier dato que se esté transmitiendo entre el servidor original y la víctima o viceversa.
IP Splicing-Hijacking:
Se produce cuando un atacante consigue interceptar una sesión ya establecida. El atacante espera a que la víctima se identifique ante el sistema y tras ello le suplanta como usuario autorizado. Para entender el procedimiento supongamos la siguiente situación:
El cliente establece una conexión con su servidor enviando un paquete que contendrá la dirección origen, destino, número de secuencia (para luego armar el paquete) y un número de autentificación utilizado por el servidor para “reconocer” el paquete siguiente en la secuencia. Supongamos que este paquete contiene:
El servidor, luego de recibir el primer paquete contesta al cliente con paquete Echo (recibido).
El cliente envía un paquete ACK al servidor, sin datos, en donde le comunica lo “perfecto” de la comunicación.
El atacante que ha visto, mediante un Sniffer, los paquete que circularon por la red calcula el número de secuencia siguiente: el actual + tamaño del campo de datos. Para calcular el tamaño de este campo:
Hecho esto el atacante envía un paquete con la siguiente aspecto:
El servidor al recibir estos datos no detectará el cambio de origen ya que los campos que ha recibido como secuencia y ACK son los que esperaba recibir. El cliente, a su vez, quedará esperando datos como si su conexión estuviera colgada y el atacante podrá seguir enviando datos mediante el procedimiento descripto.
Utilización de BackDoors:
Las puertas traseras son trozos de código en un programa que permiten a quien las conoce saltarse los métodos usuales de autentificación para realizar ciertas tareas. Habitualmente son insertados por los programadores del sistema para agilizar la tarea de probar código durante la fase de desarrollo. Esta situación se convierte en una falla de seguridad si se mantiene, involuntaria o intencionalmente, una vez terminado el producto ya que cualquiera que conozca el agujero o lo encuentre en su código podrá saltarse los mecanismos de control normales.
Utilización de Exploits:
Es muy frecuente ingresar a un sistema explotando agujeros en los algoritmos de encriptación utilizados, en la administración de las claves por parte la empresa, o simplemente encontrando un error en los programas utilizados. Los programas para explotar estos “agujeros” reciben el nombre de Exploits y lo que realizan es aprovechar la debilidad, fallo o error hallado en el sistema (hardware o software) para ingresar al mismo. Nuevos Exploits (explotando nuevos errores en los sistemas) se publican cada día por lo que mantenerse informado de los mismos y de las herramientas para combatirlos es de vital importancia.
Obtención de Passwords:
Este método comprende la obtención por “Fuerza Bruta” de aquellas claves que permiten ingresar a los sistemas, aplicaciones, cuentas, etc. atacados. Muchas passwords de acceso son obtenidas fácilmente porque involucran el nombre u otro dato familiar del usuario y, además, esta nunca (o rara vez) se cambia. En está caso el ataque se simplifica e involucra algún tiempo de prueba y error. Otras veces se realizan ataques sistemáticos (incluso con varias computadoras a la vez) con la ayuda de programas especiales y “diccionarios” que prueban millones de posibles claves hasta encontrar la password correcta. La política de administración de password será discutida en capítulos posteriores.
Uso de Diccionarios
Los Diccionarios son archivos con millones de palabras, las cuales pueden ser posibles passwords de los usuarios. Este archivo es utilizado para descubrir dicha password en pruebas de fuerza bruta. El programa encargado de probar cada una de las palabras encripta cada una de ellas, mediante el algoritmo utilizado por el sistema atacado, y compara la palabra encriptada contra el archivo de passwords del sistema atacado (previamente obtenido). Si coinciden se ha encontrado la clave de acceso al sistema, mediante el usuario correspondiente a la clave hallada. Actualmente es posible encontrar diccionarios de gran tamaño orientados, incluso, a un área específico de acuerdo al tipo de organización que se esté atacando. La velocidad de búsqueda se supone en 100.000 passwords por segundo, aunque este número suele ser mucho mayor dependiendo del programa utilizado. Aquí puede observarse la importancia de la utilización de passwords con al menos 8 caracteres de longitud y combinando todos los caracteres disponibles. En el siguiente Capítulo podrá estudiarse las normas de claves relativamente seguras y resistentes.
Denial of Service (DoS): Los protocolos existentes actualmente fueron diseñados para ser empleados en una comunidad abierta y con una relación de confianza mutua. La realidad indica que es más fácil desorganizar el funcionamiento de un sistema que acceder al mismo; así los ataques de Negación de Servicio tienen como objetivo saturar los recursos de la víctima de forma tal que se inhabilita los servicios brindados por la misma.
Más allá del simple hecho de bloquear los servicios del cliente, existen algunas razones importantes por las cuales este tipo de ataques pueden ser útiles a un atacante:
Se ha instalado un troyano y se necesita que la víctima reinicie la máquina para que surta efecto.
Se necesita cubrir inmediatamente sus acciones o un uso abusivo de CPU. Para ello provoca un “crash” del sistema, generando así la sensación de que ha sido algo pasajero y raro.
El intruso cree que actúa bien al dejar fuera de servicio algún sitio web que le disgusta. Este accionar es común en sitios pornográficos, religiosos o de abuso de menores.
El administrador del sistema quiere comprobar que sus instalaciones no son vulnerables a este tipo de ataques.
El administrador del sistema tiene un proceso que no puede “matar” en su servidor y, debido a este, no puede acceder al sistema. Para ello, lanza contra sí mismo un ataque DoS deteniendo los servicios.
A continuación se presentan los diversos tipos de ataques de DoS:
Jamming o Flooding
Este tipo de ataques desactivan o saturan los recursos del sistema. Por ejemplo, un atacante puede consumir toda la memoria o espacio en disco disponible, así como enviar tanto tráfico a la red que nadie más pueda utilizarla. Aquí el atacante satura el sistema con mensajes que requieren establecer conexión. Sin embargo, en vez de proveer la dirección IP del emisor, el mensaje contiene falsas direcciones IP usando Spoofing y Looping. El sistema responde al mensaje, pero como no recibe respuesta, acumula buffers con información de las conexiones abiertas, no dejando lugar a las conexiones legítimas. Muchos ISPs (proveedores de Internet) han sufrido bajas temporales del servicio por ataques que explotan el protocolo TCP. Muchos Hosts de Internet han sido dados de baja por el “ping de la muerte” (una versión-trampa del comando ping). Mientras que el ping normal simplemente verifica si un sistema esta enlazado a la red, el ping de la muerte causa el bloqueo instantáneo del equipo. Esta vulnerabilidad ha sido ampliamente utilizada en el pasado pero, aún hoy pueden encontrarse sistemas vulnerables. Otra acción común es la de enviar millares de e-mails sin sentido a todos los usuarios posibles en forma continua, saturando los sistemas destinos.
Syn Flood
Como ya se explicó en el TCP SYN Scanning el protocolo TCP se basa en una conexión en tres pasos. Pero, si el paso final no llega a establecerse, la conexión permanece en un estado denominado “semiabierto”. El SYN Flood es el más famoso de los ataques del tipo Denial of Service, publicado por primera vez en la revista under Phrack; y se basa en un “saludo” incompleto entre los dos hosts. El Cliente envía un paquete SYN pero no responde al paquete ACK ocasionando que la pila TCP/IP espere cierta cantidad de tiempo a que el Host hostil responda antes de cerrar la conexión. Si se crean muchas peticiones incompletas de conexión (no se responde a ninguna), el Servidor estará inactivo mucho tiempo esperando respuesta. Esto ocasiona la lentitud en los demás servicios. SYN Flood aprovecha la mala implementación del protocolo TCP, funcionando de la siguiente manera:
Se envía al destino, una serie de paquetes TCP con el bit SYN activado, (petición de conexión) desde una dirección IP Spoofeada. Esta última debe ser inexistente para que el destino no pueda completar el saludo con el cliente.
Aquí radica el fallo de TCP: ICMP reporta que el cliente es inexistente, pero TCP ignora el mensaje y sigue intentando terminar el saludo con el cliente de forma continua.
Cuando se realiza un Ping a una maquina, esta tiene que procesarlo. Y aunque se trate de un proceso sencillo, (no es más que ver la dirección de origen y enviarle un paquete Reply), siempre consume recursos del sistema. Si no es un Ping, sino que son varios a la vez, la máquina se vuelve más lenta… si lo que se recibe son miles de solicitudes, puede que el equipo deje de responder (Flood).
Es obligatorio que la IP origen sea inexistente, ya que sino el objetivo, logrará responderle al cliente con un SYN/ACK, y como esa IP no pidió ninguna conexión, le va a responder al objetivo con un RST, y el ataque no tendrá efecto.El problema es que muchos sistemas operativos tienen un límite muy bajo en el número de conexiones “semiabiertas” que pueden manejar en un momento determinado (5 a 30). Si se supera ese límite, el servidor sencillamente dejará de responder a las nuevas peticiones de conexión que le vayan llegando. Las conexiones “semiabiertas” van caducando tras un tiempo, liberando “huecos” para nuevas conexiones, pero mientras el atacante mantenga el SYN Flood, la probabilidad de que una conexión recién liberada sea capturada por un nuevo SYN malicioso es muy alta.
Connection Flood
La mayoría de las empresas que brindan servicios de Internet (ISP) tienen un límite máximo en el número de conexiones simultáneas. Una vez que se alcanza ese límite, no se admitirán conexiones nuevas. Así, por ejemplo, un servidor Web puede tener, por ejemplo, capacidad para atender a mil usuarios simultáneos. Si un atacante establece mil conexiones y no realiza ninguna petición sobre ellas, monopolizará la capacidad del servidor. Las conexiones van caducando por inactividad poco a poco, pero el atacante sólo necesita intentar nuevas conexiones, (como ocurre con el caso del SYN Flood) para mantener fuera de servicio el servidor.
Net Flood
En estos casos, la red víctima no puede hacer nada. Aunque filtre el tráfico en sus sistemas, sus líneas estarán saturadas con tráfico malicioso, incapacitándolas para cursar tráfico útil. Un ejemplo habitual es el de un teléfono: si alguien quiere molestar, sólo tiene que llamar, de forma continua. Si se descuelga el teléfono (para que deje de molestar), tampoco se puede recibir llamadas de otras personas. Este problema es habitual, por ejemplo, cuando alguien intenta mandar un fax empleando el número de voz: el fax insiste durante horas, sin que el usuario llamado pueda hacer nada al respecto. En el caso de Net Flooding ocurre algo similar. El atacante envía tantos paquetes de solicitud de conexión que las conexiones auténticas simplemente no pueden competir. En casos así el primer paso a realizar es el ponerse en contacto con el Proveedor del servicio para que intente determinar la fuente del ataque y, como medida provisional, filtre el ataque en su extremo de la línea.
El siguiente paso consiste en localizar las fuentes del ataque e informar a sus administradores, ya que seguramente se estarán usando sus recursos sin su conocimiento y consentimiento. Si el atacante emplea IP Spoofing, el rastreo puede ser casi imposible, ya que en muchos casos la fuente del ataque es, a su vez, víctima y el origen último puede ser prácticamente imposible de determinar (Looping).
Este ataque es bastante simple y a su vez devastador. Consiste en recolectar una serie de direcciones BroadCast para, a continuación, mandar una petición ICMP (simulando un Ping) a cada una de ellas en serie, varias veces, falsificando la dirección IP de origen (máquina víctima).
Este paquete maliciosamente manipulado, será repetido en difusión (Broadcast), y cientos ó miles de hosts mandarán una respuesta a la víctima cuya dirección IP figura en el paquete ICMP.
Suponiendo que se considere una red de tipo C la dirección de BroadCast sería .255; por lo que el “simple” envío de un paquete se convierte en un efecto multiplicador devastador.
Desgraciadamente la víctima no puede hacer nada para evitarlo. La solución está en manos de los administradores de red, los cuales deben configurar adecuadamente sus Routers para filtrar los paquetes ICMP de petición indeseados (Broadcast); o bien configurar sus máquinas para que no respondan a dichos paquetes. Es decir, que lo que se parchea son las máquinas/redes que puedan actuar de intermediarias (inocentes) en el ataque y no la máquina víctima.
También se podría evitar el ataque si el Router/Firewall de salida del atacante estuviera convenientemente configurado para evitar Spoofing. Esto se haría filtrando todos los paquetes de salida que tuvieran una dirección de origen que no perteneciera a la red interna.
Generalmente se envían fragmentos de paquetes Out Of Band, que la máquina víctima detecta como inválidos pasando a un estado inestable. OOB es el término normal, pero realmente consiste en configurar el bit Urgente (URG) en los indicadores del encabezamiento TCP, lo que significa que este bit es válido.
Este ataque puede prevenirse instalando los parches adecuados suministrado por el fabricante del sistema operativo afectado. Un filtro efectivo debería garantizar la detección de una inundación de bits Urgentes.
El e-mail Bombing consiste en enviar muchas veces un mensaje idéntico a una misma dirección, saturando así el mailbox del destinatario.
El Spamming, en cambio se refiere a enviar un e-mail a miles de usuarios, hayan estos solicitados el mensaje o no. Es muy utilizado por las empresas para publicitar sus productos.
El Spamming está siendo actualmente tratado por las leyes europeas (principalmente España) como una violación de los derechos de privacidad del usuario.
Ataques de Modificación – Daño: Este tipo de ataques realizan modificaciones y daños a los sistemas y se clasifican en los siguientes:
Tampering o Data Diddling
Esta categoría se refiere a la modificación desautorizada de los datos o el software instalado en el sistema víctima (incluyendo borrado de archivos). Son particularmente serios cuando el que lo realiza ha obtenido derechos de Administrador o Supervisor, con la capacidad de disparar cualquier comando y por ende alterar o borrar cualquier información que puede incluso terminar en la baja total del sistema. Aún así, si no hubo intenciones de “bajar” el sistema por parte del atacante; el Administrador posiblemente necesite darlo de baja por horas o días hasta chequear y tratar de recuperar aquella información que ha sido alterada o borrada. Como siempre, esto puede ser realizado por Insiders o Outsiders, generalmente con el propósito de fraude o de dejar fuera de servicio a un competidor.
Son innumerables los casos de este tipo: empleados bancarios (o externos) que crean falsas cuentas para derivar fondos de otras cuentas, estudiantes que modifican calificaciones de exámenes, o contribuyentes que pagan para que se les anule una deuda impositiva.
Múltiples Web Sites han sido víctimas del cambio en sus páginas por imágenes (o manifiestos) terroristas o humorísticos, como el ataque de The Mentor, ya visto, a la NASA; o la reciente modificación del Web Site del CERT (mayo de 2001).
Otras veces se reemplazan versiones de software por otros con el mismo nombre pero que incorporan código malicioso (virus, troyanos, etc.). La utilización de programas troyanos y difusión de virus esta dentro de esta categoría, y se profundizará sobre el tema en otra sección el presente capítulo.
Borrado de Huellas
El borrado de huellas es una de las tareas más importantes que debe realizar el intruso después de ingresar en un sistema, ya que, si se detecta su ingreso, el administrador buscará como conseguir “tapar el hueco” de seguridad, evitar ataques futuros e incluso rastrear al atacante.
Las Huellas son todas las tareas que realizó el intruso en el sistema y por lo general son almacenadas en Logs (archivo que guarda la información de lo que se realiza en el sistema) por el sistema operativo.
Los archivos Logs son una de las principales herramientas (y el principal enemigo del atacante) con las que cuenta un administrador para conocer los detalles de las tareas realizadas en el sistema y la detección de intrusos.
Ataques Mediante Java Applets
Java es un lenguaje de programación interpretado, desarrollado inicialmente por la empresa SUN. Su mayor popularidad la merece por su alto grado de seguridad. Los más usados navegadores actuales, implementan Máquinas Virtuales Java (MVJ) para ser capaces de ejecutar programas (Applets) de Java.
Estos Applets, al fin y al cabo, no son más que código ejecutable y como tal, susceptible de ser manipulado por intrusos. Sin embargo, partiendo del diseño, Java siempre ha pensado en la seguridad del sistema. Las restricciones a las que somete a los Applets son de tal envergadura (imposibilidad de trabajar con archivos a no ser que el usuario especifique lo contrario, imposibilidad de acceso a zonas de memoria y disco directamente, firma digital, etc.) que es muy difícil lanzar ataques. Sin embargo, existe un grupo de expertos especializados en descubrir fallas de seguridad en las implementaciones de las MVJ.
Ataques Mediante JavaScript y VBScript
JavaScript (de la empresa Netscape®) y VBScript (de Microsoft®) son dos lenguajes usados por los diseñadores de sitios Web para evitar el uso de Java. Los programas realizados son interpretados por el navegador.
Aunque los fallos son mucho más numerosos en versiones antiguas de JavaScript, actualmente se utilizan para explotar vulnerabilidades específicas de navegadores y servidores de correo ya que no se realiza ninguna evaluación sobre si el código.
Ataques Mediante ActiveX
ActiveX es una de las tecnologías más potentes que ha desarrollado Microsoft®. Mediante ActiveX es posible reutilizar código, descargar código totalmente funcional de un sitio remoto, etc. Esta tecnología es considerada la respuesta de Microsoft® a Java.
ActiveX soluciona los problemas de seguridad mediante certificados y firmas digitales. Una Autoridad Certificadora (AC) expende un certificado que acompaña a los controles activos y a una firma digital del programador.
Cuando un usuario descarga una página con un control, se le preguntará si confía en la AC que expendió el certificado y/o en el control ActiveX. Si el usuario acepta el control, éste puede pasar a ejecutarse sin ningún tipo de restricciones (sólo las propias que tenga el usuario en el sistema operativo). Es decir, la responsabilidad de la seguridad del sistema se deja en manos del usuario, ya sea este un experto cibernauta consciente de los riesgos que puede acarrear la acción o un perfecto novato en la materia.
Esta última característica es el mayor punto débil de los controles ActiveX ya que la mayoría de los usuarios aceptan el certificado sin siquiera leerlo, pudiendo ser esta la fuente de un ataque con un control dañino.
La filosofía ActiveX es que las Autoridades de Certificación se fían de la palabra del programador del control. Es decir, el programador se compromete a firmar un documento que asegura que el control no es nocivo. Evidentemente siempre hay programadores con pocos escrúpulos o con ganas de experimentar.
Otro control ActiveX muy especialmente “malévolo” es aquel que manipula el código de ciertos exploradores, para que éste no solicite confirmación al usuario a la hora de descargar otro control activo de la Web. Es decir, deja totalmente descubierto, el sistema de la víctima, a ataques con tecnología ActiveX.
La autentificación de usuarios mediante Certificados y las Autoridades Certificadoras será abordada con profundidad en capítulos posteriores.
Vulnerabilidades en los Navegadores
Generalmente los navegadores no fallan por fallos intrínsecos, sino que fallan las tecnologías que implementan, aunque en este punto analizaremos realmente fallos intrínsecos de los navegadores, como pueden ser los “Buffer Overflow”.
Los “Buffer Overflows” consisten en explotar una debilidad relacionada con los buffers que la aplicación usa para almacenar las entradas de usuario. Por ejemplo, cuando el usuario escribe una dirección en formato URL ésta se guarda en un buffer para luego procesarla.Si no se realizan las oportunas operaciones de comprobación, un usuario podría manipular estas direcciones.
devuelve el directorio de la unidad c: del servidor deseado.
Para poder lanzar este tipo de ataques hay que tener un buen conocimiento de lenguaje Assembler y de la estructura interna de la memoria del sistema operativo utilizado o bien, leer la documentación de sitios web donde explican estas fallas.
Muchos sistemas están expuestos a “agujeros” de seguridad que son explotados para acceder a archivos, obtener privilegios o realizar sabotaje. Estas vulnerabilidades ocurren por variadas razones, y miles de “puertas invisibles” son descubiertas (cada día) en sistemas operativos, aplicaciones de software, protocolos de red, navegadores de Internet, correo electrónico y toda clase de servicios informáticos disponibles.
Constantemente encontramos en Internet avisos de nuevos descubrimientos de problemas de seguridad (y herramientas de Hacking que los explotan), por lo que hoy también se hace indispensable contar con productos que conocen esas debilidades, puedan diagnosticarlas y actualizar el programa afectado con el parche adecuado.
¿Cómo defenderse de estos Ataques?
La mayoría de los ataques mencionados se basan en fallos de diseño inherentes a Internet (y sus protocolos) y a los sistemas operativos utilizados, por lo que no son “solucionables” en un plazo breve de tiempo.
La solución inmediata en cada caso es mantenerse informado sobre todos los tipos de ataques existentes y las actualizaciones que permanentemente lanzan las empresas desarrolladoras de software, principalmente de sistemas operativos.
Las siguientes son medidas preventivas. Medidas que toda red y administrador deben conocer y desplegar cuanto antes:
Mantener las máquinas actualizadas y seguras físicamente
Mantener personal especializado en cuestiones de seguridad (o subcontratarlo).
Aunque una máquina no contenga información valiosa, hay que tener en cuenta que puede resultar útil para un atacante, a la hora de ser empleada en un DoS coordinado o para ocultar su verdadera dirección.
No permitir el tráfico “broadcast” desde fuera de nuestra red. De esta forma evitamos ser empleados como “multiplicadores” durante un ataque Smurf.
Filtrar el tráfico IP Spoof.
Auditorias de seguridad y sistemas de detección.
Mantenerse informado constantemente sobre cada una de las vulnerabilidades encontradas y parches lanzados. Para esto es recomendable estar suscripto a listas que brinden este servicio de información.
Por último, pero quizás lo más importante, la capacitación contínua del usuario.
Aplicaciones para la Seguridad
En los siguientes puntos vamos a indicar los procedimientos de instalación de múltiples aplicaciones que permiten reforzar la seguridad de un Servidor Linux tanto de Desarrollo como de Producción.
