Las 16 prioridades para proteger el Sistema Operativo UNIX. The Canaudit Perspective. Parte II

Transcripción

1 SAFE Consulting Group Publicaciones presenta:: Canaudit Perspective Las 16 prioridades para proteger el Sistema Operativo UNIX The Canaudit Perspective ( Canaudit, Inc translated with Permission by SAFE Consulting Group, Puntos de especial interés: Las 16 prioridades para proteger el Sistema Operativo UNIX Parte II Las 16 prioridades para proteger el Sistema Operativo UNIX. por Gordon Smith Una vez que los datos están protegidos segú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

2 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. 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 fuerte? 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

3 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 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.

4 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 facilidad 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. 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 Auditoria 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 lograr la contención de 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 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 Winds 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

5 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 próximo 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. 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.- El Software mas avanzado en Inteligencia de Negocios para Auditores análisis de logs, archivos y datos, Monitoreo Contínuo, Auditoria, Detección de Fraude y Lavado de Dinero Conózcalo descargando un DEMO Operativo desde nuestra página Web La herramienta de Análisis de Datos más avanzada y fácil de usar del mercado En breve IDEA Web Server e IDEA