Download Las “16 prioridades” para proteger UNIX SAFE Consulting Group

SAFE Consulting Group Publicaciones presenta:
Canaudit Perspective
L
deess””
daad
orriid
prriio
Laass ““1166 p
p
X
NIIX
UN
geerr U
otteeg
prro
paarraa p
Las “16 prioridades” para proteger el Sistema Operativo UNIX
(Traducido al Castellano por: SAFE Consulting Group, www.safecg.com )
Por Gordon Smith - Presidente, Canaudit Inc.
Una vez que los datos están protegidos seún indicamos en nuestro número anterior, el sistema
operativo debe reforzarse para evitar que los hackers que penetren la red puedan lograr tener acceso
a la máquina y luego potenciar sus capacidades a nivel de root utilizando las vulnerabilidades de la
instalación. Aquí están las “16 prioridades de Gordon” para proteger el sistema operativo UNIX.
1. Asegure que todas las cuentas tienen contraseñas y que la contraseña no es igual al nombre de la
cuenta.
2. Asegure que todas las relaciones confiables (trusted) son eliminadas. Busque todas las copias de
los archivos .rhost, especialmente el root .rhost y elimínelos. Luego cree un archivo .rhost en blanco,
colóquelo en el directorio root y configure permisos para no leer, no escribir y no ejecutar para el
propietario, el grupo y el mundo (world). Esto evitará que un hacker coloque un archivo .rhost en el
directorio root y utilice ese archivo para escalar en sus capacidades.
3. El archivo host.equiv también puede utilizarse para crear una relación confiable (trusted). Vacíe
este archivo y asegúrese de que está protegido de manera adecuada.
www.safecg.com
SAFE Consulting Group
4. Junto con lo indicado anteriormente, inhabilite los servicios rlogin, rexec y rshell en el archivo Inetd.
Los administradores normalmente se oponen a esto diciendo que el software no podrá ejecutar.
Sugerimos que utilicen secure shell y tcp wrappers para crear conexiones seguras entre servidores
(esto requiere pruebas antes de la implementación). Puede ser necesario contactar al proveedor de
software para que asista en este esfuerzo. Muchos de nuestros clientes tuvieron dificultades al
intentar que los proveedores cooperasen. Recientemente encontramos una solución que hace que el
proveedor se de cuenta de que usted está hablando en serio y de que ellos tienen que rendir como
corresponde. Si el proveedor dice que el software no podrá ejecutar sin una relación confiable y ellos
no están dispuestos a brindar una solución en un lapso de tiempo razonable, haga que sus abogados
envíen al CEO y a los abogados del proveedor un aviso que indique que su software está
exponiendo a riesgos su ambiente operativo, y que ellos han sido advertidos y han rechazado brindar
una solución al problema.; por lo tanto si se produjera un incidente informático relacionado con el uso
de las relaciones confiables (trust relationships), su organización haría responsable al proveedor de
dicho incidente. Dado que el proveedor fue notificado y los principios de seguridad generalmente
aceptados establecen la eliminación de las relaciones confiables, el proveedor puede ser considerado
negligente, en tanto y en cuanto usted lo puso en conocimiento del riesgo de esta situación y ellos
rechazaron corregir el problema y encontrar una solución. ¿Creé que esto es “jugar duro”? Si, por
cierto lo es. Sin embargo, si le roban sus datos por una relación confiable y en forma resultante se
comprometen los datos de sus clientes, usted puede esperar un acción legal fuerte. No creo que un
juez o un jurado pueda aceptar la excusa de “El software del proveedor no iba a funcionar si la
máquina hubiese estado protegida de manera adecuada”. De hecho su organización puede sufrir
cargos de negligencia y terribles daños y pérdida de reputación y clientes.
5. Asegure que el servicio tftp, que permite que los invitados se conecten al sistema sin autenticación
esté inhabilitado. Si el tftp está activo, todos los archivos con lectura al mundo caeran en manos de
personas no autorizadas, staff, proveedores o hackers ya que podrán descargarlos de los servidores
libremente. Además todos los archivos con escritura al mundo (world write), podrían ser alterados o
borrados utilizando tftp. Elimine este servicio toda vez que lo encuentre.
6. Algunos archivos contienen procesos que ejecutan con capacidad de root. Los dos que más me
preocupan son el inittab y el crontab. El inittab ejecuta los procesos cuando usted inicializa o bootea
el sistema. El crontab contiene procesos que ejecutan en horarios predefinidos. Si los permisos sobre
cualquiera de estos archivos son de escritura al mundo (world write), un usuario descontento o un
hacker podría alterar el proceso para crear una cuenta nueva la próxima vez que ejecuten los
procesos. Por lo tanto verifique los procesos sobre todos los archivos en el inittab y en el crontab y
asegúrese de que solo pueden ser accedidos por usuarios de bajo nivel o a través de tftp. Para lanzar
un proceso modificado en el crontab, solo tiene que esperar hasta que la tarea ejecute en el tiempo
previsto, y sus procesos pueden recrear una nueva cuenta root con todo el poder. Para el inittab, el
sistema tiene que ser booteado o reinicializado, por lo tanto lanzar un ataque de denegación de
servicios contra la máquina podría forzar un re-booteo y la ejecución del código maligno del hacker.
7. Un simple ataque de denegación de servicios puede lanzarse utilizando dos servicios
conjuntamente. Charlen genera caracteres y echo los repite. Lanzando charlen y echo en conjunto es
posible que se provoque que la máquina esté ocupada creando caracteres y replicándolos en un ciclo
infinito. Por lo tanto, inhabilitar ambos servicios para evitar que generen una re-inicialización del
sistema que contenga un inittab alterado como se describió anteriormente.
8. El siguiente ítem en mi lista es para asegurar que el servicio finger está inhabilitado. Un hacker
utiliza este servicio para identificar cuentas en el sistema. Por ejemplo, si hago un finger con el valor
Gord y no existe una cuenta gsmith con la descripción “Gordon Smith” en el campo comentario del
archivo de contraseñas, el finger le dirá al atacante que la cuenta gsmith existe en la máquina.
Automatizando este proceso un hacker puede ennumerar cuentas múltiples de un sistema, luego
www.safecg.com
SAFE Consulting Group
adivinar las contraseñas utilizando un diccionario o una herramienta de software de fuerza bruta para
obtener una combinación válida de cuenta/contraseña.
9. El archivo de grupos (Group) se utiliza para asignar cuentas de usuarios a grupos específicos para
otorgarles los accesos requeridos para realizar su función. Este archivo nunca debe tener permiso de
escritura al mundo (world write), en segundo lugar, deben revisarse regularmente los usuarios que
pertenecen a cada grupo para asegurar que no tienen más accesos que los que requieren.
10. El archivo de permisos (permissions) si se utiliza, puede contener entradas que permitirán
accesos no autenticados al sistema. Estos permisos deben revisarse en forma frecuente para
asegurar que no contienen entradas no autorizadas.
11. El archivo del sistema (systems file) puede contener una lista de entradas que incluyan el nombre
del servidor, o un teléfono, nombre de cuenta y una contraseña encriptada. Estas entradas deben
eliminarse del archivo para evitar que los hackers, que comprometen un máquina para lograr acceso
a otra, las exploten.
12. Uno de los controles más importantes para asegurar que el bloqueo de cuentas está operativo
(normalmente tres contraseñas incorrectas inhabilitan la cuenta). También debe llevarse un log de las
contraseñas inválidas, si es posible generar una alerta cuando se observa un flujo continuado de
contraseñas inválidas contra una cuenta o una serie de cuentas. Esto marca el patrón de un ataque
automatizado o de fuerza bruta.
13. Si bien puede sonar elemental recalcar la necesidad de cambiar las contraseñas en forma
frecuente, la mayoría de las máquinas UNIX que he auditado no requieren que los usuarios cambien
sus contraseñas. Los usuarios con cuentas normales deberían cambiar sus contraseñas cada 35 días
aproximadamente. Los usuarios con cuentas con mayor poder tales como root o administradores de
bases de datos, deberían cambiarlas en forma mas frecuente o utilizar técnicas de autenticación
secundaria tales como biométricas (escan del iris), un dispositivo (Escurrid) o un certificado digital.
14. La contraseña de la cuenta root no debe ser compartida. Si algún usuario requiere privilegios de
este tipo, es mejor darle estos privilegios utilizando la función sudo. Si un usuario necesita realizar
backups, podemos darle acceso root (no recomendable), o podemos usar la función sudo para darle
la facilida de realizar backups (recomendable). Sudo es un script de dominio público que ejecuta en la
mayoría de las versiones de UNIX.
15. Los patches y mejoras de seguridad de UNIX deben aplicarse tan pronto como son liberados. Se
que esto incrementa el riesgo de que el match produzca una caída del sistema operativo o una falla
de aplicación. Sin embargo, deben balancearse los riesgos de que los hackers al escuchar de la
nueva vulnerabilidad, quieran salir de cacería por sistemas no reparados antes de que los patches se
liberen. Los que implementan los patches en forma tardía pueden ver que sus sistemas ya han sido
comprometidos.
16. Por último, los logs del sistema deben revisarse en forma frecuente. Para un mejor control crear
una rutina de software que rastree los logs buscando eventos críticos de seguridad. Luego generar un
mensaje al beeper o móvil del administrador para que pueda tomar acción inmediata. La detección
temprana le permitirá a su organización minimizar los daños y posiblemente capturar al perpetrador.
www.safecg.com
SAFE Consulting Group
Existen muchos otros riesgos en UNIX; sin embargo los mencionados arriba son los más comunes.
Asegúrese de revisar esta lista con su administrador de sistemas y asistirlo en obtener la aprobación
gerencial para implementarlo. Después de todo, el sistema operativo protege los datos y los
programas. Sin controles sólidos, sus datos pueden ser comprometidos o robados (si necesita
algunos scripts de Auditoría y Seguridad de UNIX, haga click aquí)
Una vez que los sistemas operativos se refuerzan, el nivel siguiente de seguridad es la red en si
misma. Mi libro Network Auditing: A Control Assessment Approach cubre este tema muy bien. En este
artículo es necesario cubrir los puntos principales para asegurar que la red y los dispositivos protegen
a los servidores y alos datos. El control más importante es segmentar la red utilizando routers,
switches y firewalls internas. La segmentación de redes, utilizada en forma adecuada puede
contener un incidente de hackeo en un único segmento de red. Esto limita el daño que puede
realizarse cuando se penetra la red e incrementa la probabilidad de que la intrusión sea detectada a
tiempo.
Dicho esto hay algunos algunos puntos del lado de la red que deben tenerse en cuenta. Una de mis
principales preocupaciones es el del protocolo SNMP activo cuando no es necesario. Si el SNMP está
activo en su red, herramientas tales como Solar Winds podrían utilizarse para documentar la red. Los
equipos de red, servidores y estaciones de trabajo, impresoras y otros dispositivos que utilicen la
(contraseña SNMP) pueden brindar valiosa información si se adivina o es atacado por fuerza bruta
por Solar Wins u otras herramientas.
Muchos de nuestros clientes han tenido community string (contraseñas SNMP) públicas lo que nos
permitía ver información tal como nombres de cuentas, servicios ejecutando en la máquina y las rutas
de red existentes. Con un community string privado, podemos obtener configuración de dispositivos
de red lo que nos permite modificar la configuración, o aun peor tomar control de los servicios de red.
Si usted utiliza SNMP en la parte interna de su red, asegúrese que los community strings son
complejos (ocho caracteres de longitud, con caracteres especiales en las posiciones 2 a 6). También
las contraseñas SNMP deben modificarse regularmente especialmente si hay cambios de personal.
Otro control posible es crear colocar un cebo (conocido como “Honey pot” , “Jarra de miel”) dentro de
la red. Este identificará cuando una máquina es sometida a un scan con un producto como Solar
Wind o SuperScan. Me gusta una herramienta gratuita llamada Back Officer Friendly, que indica
cuando mi caja está siendo escaneada. No hay versiones comerciales de este producto. El punto a
recordar aquí es que normalmente un SNMP o escan de puerto es una de las primeras cosas que un
hacker hará cuando penetra una red.
Me gustan los controles gratuitos porque a menudo este es el presupuesto de la Seguridad de Redes.
Uno de mis controles favoritos “gratuitos” es la habilidad para utilizar la encripción del router para
encriptar y decriptar datos antes de que se transmitan a los segmentos de la red. Encriptar estos
datos evita que los hackers y otros personajes nefastos puedan hacer un sniffing (olfatear) sobre la
cuentas, contraseñas y datos en la red.
Por lo general ahora cubriría los temas de modems y redes inalámbricas. Sin embargo, ya he escrito
sobre los controles en redes inalámbricas y los modems serán tratados en el proximo número. Solo
asegúrese que los modems y conexiones inalámbricas están en su cantidad mínima y bien
protegidos.
Este artículo está basado en nuestro nuevo seminario Control and Security of Enterprise Wide
E-Commerce. Una version detallada estará incluida en el Nuevo libro de Gordon Smith: Control
and Security of E-Commerce, en publicación por John Wiley and Sons.
www.safecg.com
SAFE Consulting Group
Si usted considera interesante este artículo por favor reenvíelo a sus colegas o asociados
profesionales. Por cualquier comentario por favor envíe un mail a publicaciones@safecg.com
Importante: Las opiniones expresadas representan los puntos de vista del autor de las mismas.-
© Canaudit Inc. Printed with permission
Por información adicional no dude en contactarnos en: info@safecg.com
www.safecg.com
SAFE Consulting Group
AMÉRICA: ARGENTINA, BRASIL, CHILE, MEXICO, PARAGUAY, URUGUAY
EUROPA: ESPAÑA
www.safecg.com