SAFE Consulting Group Publicaciones presenta:

Canaudit Perspective

Laass 1166 p
L orriid
prriio deess
daad
paarraa p
p geerr U
otteeg
prro NIIX
UN X

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 estn protegidos sen indicamos en nuestro nmero anterior, el sistema
operativo debe reforzarse para evitar que los hackers que penetren la red puedan lograr tener acceso
a la mquina y luego potenciar sus capacidades a nivel de root utilizando las vulnerabilidades de la
instalacin. Aqu estn las 16 prioridades de Gordon para proteger el sistema operativo UNIX.

1. Asegure que todas las cuentas tienen contraseas y que la contrasea 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 elimnelos. Luego cree un archivo .rhost en blanco,
colquelo 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 tambin puede utilizarse para crear una relacin confiable (trusted). Vace
este archivo y asegrese 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 implementacin). 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 solucin 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 relacin confiable y ellos
no estn dispuestos a brindar una solucin en un lapso de tiempo razonable, haga que sus abogados
enven 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 solucin al problema.; por lo tanto si se produjera un incidente informtico relacionado con el uso
de las relaciones confiables (trust relationships), su organizacin hara responsable al proveedor de
dicho incidente. Dado que el proveedor fue notificado y los principios de seguridad generalmente
aceptados establecen la eliminacin de las relaciones confiables, el proveedor puede ser considerado
negligente, en tanto y en cuanto usted lo puso en conocimiento del riesgo de esta situacin y ellos
rechazaron corregir el problema y encontrar una solucin. Cre que esto es jugar duro? Si, por
cierto lo es. Sin embargo, si le roban sus datos por una relacin confiable y en forma resultante se
comprometen los datos de sus clientes, usted puede esperar un accin 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
mquina hubiese estado protegida de manera adecuada. De hecho su organizacin puede sufrir
cargos de negligencia y terribles daos y prdida de reputacin y clientes.

5. Asegure que el servicio tftp, que permite que los invitados se conecten al sistema sin autenticacin
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 podrn descargarlos de los servidores
libremente. Adems todos los archivos con escritura al mundo (world write), podran 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 ms 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 podra alterar el proceso para crear una cuenta nueva la prxima vez que ejecuten los
procesos. Por lo tanto verifique los procesos sobre todos los archivos en el inittab y en el crontab y
asegrese de que solo pueden ser accedidos por usuarios de bajo nivel o a travs 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 denegacin de
servicios contra la mquina podra forzar un re-booteo y la ejecucin del cdigo maligno del hacker.

7. Un simple ataque de denegacin 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 mquina est ocupada creando caracteres y replicndolos en un ciclo
infinito. Por lo tanto, inhabilitar ambos servicios para evitar que generen una re-inicializacin 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 descripcin Gordon Smith en el campo comentario del
archivo de contraseas, el finger le dir al atacante que la cuenta gsmith existe en la mquina.
Automatizando este proceso un hacker puede ennumerar cuentas mltiples de un sistema, luego

www.safecg.com
SAFE Consulting Group
adivinar las contraseas utilizando un diccionario o una herramienta de software de fuerza bruta para
obtener una combinacin vlida de cuenta/contrasea.

9. El archivo de grupos (Group) se utiliza para asignar cuentas de usuarios a grupos especficos para
otorgarles los accesos requeridos para realizar su funcin. 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 ms accesos que los que requieren.

10. El archivo de permisos (permissions) si se utiliza, puede contener entradas que permitirn
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 telfono, nombre de cuenta y una contrasea encriptada. Estas entradas deben
eliminarse del archivo para evitar que los hackers, que comprometen un mquina para lograr acceso
a otra, las exploten.

12. Uno de los controles ms importantes para asegurar que el bloqueo de cuentas est operativo
(normalmente tres contraseas incorrectas inhabilitan la cuenta). Tambin debe llevarse un log de las
contraseas invlidas, si es posible generar una alerta cuando se observa un flujo continuado de
contraseas invlidas contra una cuenta o una serie de cuentas. Esto marca el patrn de un ataque
automatizado o de fuerza bruta.

13. Si bien puede sonar elemental recalcar la necesidad de cambiar las contraseas en forma
frecuente, la mayora de las mquinas UNIX que he auditado no requieren que los usuarios cambien
sus contraseas. Los usuarios con cuentas normales deberan cambiar sus contraseas cada 35 das
aproximadamente. Los usuarios con cuentas con mayor poder tales como root o administradores de
bases de datos, deberan cambiarlas en forma mas frecuente o utilizar tcnicas de autenticacin
secundaria tales como biomtricas (escan del iris), un dispositivo (Escurrid) o un certificado digital.

14. La contrasea de la cuenta root no debe ser compartida. Si algn usuario requiere privilegios de
este tipo, es mejor darle estos privilegios utilizando la funcin sudo. Si un usuario necesita realizar
backups, podemos darle acceso root (no recomendable), o podemos usar la funcin sudo para darle
la facilida de realizar backups (recomendable). Sudo es un script de dominio pblico que ejecuta en la
mayora 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 cada del sistema operativo o una falla
de aplicacin. Sin embargo, deben balancearse los riesgos de que los hackers al escuchar de la
nueva vulnerabilidad, quieran salir de cacera por sistemas no reparados antes de que los patches se
liberen. Los que implementan los patches en forma tarda 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 crticos de seguridad. Luego generar un
mensaje al beeper o mvil del administrador para que pueda tomar accin inmediata. La deteccin
temprana le permitir a su organizacin minimizar los daos y posiblemente capturar al perpetrador.

www.safecg.com
SAFE Consulting Group
Existen muchos otros riesgos en UNIX; sin embargo los mencionados arriba son los ms comunes.
Asegrese de revisar esta lista con su administrador de sistemas y asistirlo en obtener la aprobacin
gerencial para implementarlo. Despus de todo, el sistema operativo protege los datos y los
programas. Sin controles slidos, sus datos pueden ser comprometidos o robados (si necesita
algunos scripts de Auditora 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
artculo es necesario cubrir los puntos principales para asegurar que la red y los dispositivos protegen
a los servidores y alos datos. El control ms importante es segmentar la red utilizando routers,
switches y firewalls internas. La segmentacin de redes, utilizada en forma adecuada puede
contener un incidente de hackeo en un nico segmento de red. Esto limita el dao que puede
realizarse cuando se penetra la red e incrementa la probabilidad de que la intrusin 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 podran utilizarse para documentar la red. Los
equipos de red, servidores y estaciones de trabajo, impresoras y otros dispositivos que utilicen la
(contrasea SNMP) pueden brindar valiosa informacin si se adivina o es atacado por fuerza bruta
por Solar Wins u otras herramientas.

Muchos de nuestros clientes han tenido community string (contraseas SNMP) pblicas lo que nos
permita ver informacin tal como nombres de cuentas, servicios ejecutando en la mquina y las rutas
de red existentes. Con un community string privado, podemos obtener configuracin de dispositivos
de red lo que nos permite modificar la configuracin, o aun peor tomar control de los servicios de red.
Si usted utiliza SNMP en la parte interna de su red, asegrese que los community strings son
complejos (ocho caracteres de longitud, con caracteres especiales en las posiciones 2 a 6). Tambin
las contraseas 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 mquina 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 encripcin 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, contraseas y datos en la red.

Por lo general ahora cubrira los temas de modems y redes inalmbricas. Sin embargo, ya he escrito
sobre los controles en redes inalmbricas y los modems sern tratados en el proximo nmero. Solo
asegrese que los modems y conexiones inalmbricas estn en su cantidad mnima y bien
protegidos.

Este artculo 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 publicacin por John Wiley and Sons.
www.safecg.com
SAFE Consulting Group

Si usted considera interesante este artculo por favor reenvelo a sus colegas o asociados
profesionales. Por cualquier comentario por favor enve 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 informacin adicional no dude en contactarnos en: info@safecg.com

www.safecg.com

SAFE Consulting Group

AMRICA: ARGENTINA, BRASIL, CHILE, MEXICO, PARAGUAY, URUGUAY

EUROPA: ESPAA

www.safecg.com