Recomendaciones PSI

Recomendaciones de seguridadChelo Malagn Poyato ([email protected]) o Francisco Monserrat Coll ([email protected]) David Mart nez Moreno ([email protected]) 15 de diciembre de 2000. Versin 0.1 o

INDICE GENERAL INDICE GENERAL

Indice General1 Introduccin o 2 Recomendaciones Generales 3 Seguridad en nivel de red 3.1 Filtrado de paquetes . . . . . . . . . . . . . . . . . . 3.2 Conguracin de las pilas TCP/IP en equipos nales o 3.3 Monitorizacin de routers y equipos de acceso . . . . o 3.4 Separacin de las redes y ltros anti-sning . . . . . o 4 6 8 . 8 . 12 . 12 . 13 15 15 15 16 17 18 18 19 19 20 20 21 22 22 23 23 24 24 24 25 26 27

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4 Recomendaciones en nivel de sistema 4.1 Conguracin de equipos Unix . . . . . . . . . . . . . . . . . . . . . . . . o 4.1.1 Actualizacin y control de fallos . . . . . . . . . . . . . . . . . . . o 4.1.2 Directivas generales . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Seguridad en sistemas de archivos . . . . . . . . . . . . . . . . . . 4.2 Filtrado de servicios en equipos Unix . . . . . . . . . . . . . . . . . . . . 4.2.1 Servicios dependientes de inetd . . . . . . . . . . . . . . . . . . . 4.2.2 Servicios dependientes de RPC . . . . . . . . . . . . . . . . . . . 4.2.3 Servicios arrancados en los scripts de inicio del sistema operativo 4.3 Pol tica de contraseas . . . . . . . . . . . . . . . . . . . . . . . . . . . . n 4.3.1 Contraseas dbiles . . . . . . . . . . . . . . . . . . . . . . . . . . n e 4.3.2 Cuentas sin contrasea o contraseas por defecto. . . . . . . . . . n n 4.3.3 Contraseas reutilizables . . . . . . . . . . . . . . . . . . . . . . . n 4.4 Pol tica de cuentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Administracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.4.2 Cuentas especiales . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Usuario root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Conguracin de servicios ms usuales . . . . . . . . . . . . . . . . . . . o a 4.5.1 Conguracin del sistema de correo . . . . . . . . . . . . . . . . . o 4.5.2 Conguracin del DNS . . . . . . . . . . . . . . . . . . . . . . . . o 4.5.3 Conguracin de los servidores WWW . . . . . . . . . . . . . . . o 4.5.4 Conguracin de los servidores FTP . . . . . . . . . . . . . . . . o

. . . . . . . . . . . . . . . . . . . . .

IRIS-CERT

1


4.6

4.7

4.8 4.9

4.5.5 Servidores de cheros . . . . . . Monitorizacin de archivos de registro . o 4.6.1 Conguracin . . . . . . . . . . o 4.6.2 Particularidades . . . . . . . . . 4.6.3 Uso desde programas . . . . . . 4.6.4 Rotacin de cheros de registro o 4.6.5 Otros aspectos relacionados . . Comprobacin de integridad . . . . . . o 4.7.1 Instalacin de Tripwire . . . . . o 4.7.2 Conguracin de Tripwire . . . o Seguimiento de procesos . . . . . . . . Actualizaciones de software . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

27 29 30 30 31 31 32 32 33 33 34 34 36 36 36 37 38 38 40 40 40 40 41 41 42 43 44 44 45 45 49 49 50 50 50 50 51 52 52

5 Recomendaciones para usuarios nales 5.1 Introduccin . . . . . . . . . . . . . . . . . . . . . . o 5.2 Gu Bsica de Seguridad para Windows 95/98/ME a a 5.2.1 Seguridad en red . . . . . . . . . . . . . . . 5.2.2 Antivirus, virus y caballos de troya. . . . . . 5.2.3 Algunos apuntes ms . . . . . . . . . . . . . a 6 Gu bsica de seguridad de Windows NT a a 6.1 Introduccin . . . . . . . . . . . . . . . . . o 6.2 Conceptos Bsicos . . . . . . . . . . . . . a 6.2.1 Dominio . . . . . . . . . . . . . . . 6.2.2 Cuentas de usuarios . . . . . . . . . 6.2.3 Cuentas de grupos . . . . . . . . . 6.3 Pol ticas de passwords y cuentas . . . . . . 6.4 Permisos y derechos de usuario . . . . . . 6.4.1 Permisos para directorios . . . . . . 6.4.2 Permisos para cheros . . . . . . . 6.5 Comparticin de recursos de red . . . . . . o 6.6 Seguridad del registro . . . . . . . . . . . . 6.7 Auditor . . . . . . . . . . . . . . . . . . as 6.7.1 Auditor de cuentas de usuario . . a 6.7.2 Auditor del sistema de archivos . a 6.7.3 Auditor de impresoras . . . . . . a 6.8 Seguridad en Red . . . . . . . . . . . . . . 6.8.1 Protocolos de Red . . . . . . . . . 6.9 Service Packs . . . . . . . . . . . . . . . . 6.10 Cortafuegos . . . . . . . . . . . . . . . . . 6.11 Consideraciones generales . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

IRIS-CERT

2


A Informacin de seguridad en Internet o A.1 Listas de distribucin . . . . . . . . . . . . . . . . . . . . . . . . . o A.1.1 Listas de RedIRIS . . . . . . . . . . . . . . . . . . . . . . A.1.2 Otras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Boletines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Areas de Documentacin . . . . . . . . . . . . . . . . . . . . . . . o A.4 Sitios de hackers . . . . . . . . . . . . . . . . . . . . . . . . . . . A.5 Herramientas y software de Seguridad . . . . . . . . . . . . . . . . A.6 Avisos de seguridad, parches, etc... de varias empresas de software A.7 Herramientas de evaluacin de la seguridad para Windows NT . . o A.7.1 Herramientas para escanear virus . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

53 53 53 53 54 54 54 55 55 55 56

B Contribuciones 57 B.1 Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 C Registro de Cambios C.0.1 Versin 0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o C.0.2 Versin 0.0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o C.0.3 Versin 0.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 58 58 59 59

IRIS-CERT

3

CAP ITULO 1. INTRODUCCION

Cap tulo 1 Introduccin oCada vez son ms frecuentes los incidentes en los que se ven involucradas las instituciones a aliadas a RedIRIS. El tiempo necesario para la atencin de estos incidentes es cada vez o mayor, ya que suelen involucrar a varias instituciones y muchas veces lo unico que se puede conseguir es parar al intruso, sin llegar a menudo a conocer la identidad del atacante o los motivos por los cuales se produjo. Con el incremento de usuarios en Internet, y en la comunidad RedIRIS en particular, es cada vez ms fcil obtener informacin sobre vulnerabilidades de un equipo o a a o sistema operativo, pudiendo atacar con facilidad y total impunidad equipos situados en cualquier organizacin . Adems, son cada vez ms los equipos conectados permanenteo a a mente a Internet que no disponen de un responsable de administracin y gestin, y que o o estn congurados por defecto para ofrecer una serie de servicios que no se suelen emplear. a Estos motivos nos han llevado a plantear unas recomendaciones generales de seguridad, al igual que se hace en otras reas, para tratar de limitar el nmero y alcance a u de estos incidentes. Somos conscientes de que estas recomendaciones no se podrn implantar en su a totalidad, que llevarn algo de tiempo y que se debern debatir antes de ser de uso a a comn en RedIRIS, pero esperamos que este borrador aporte su granito de arena a este u proyecto. No creemos que la seguridad tenga que ser algo perteneciente a un rea detera minada dentro de los servicios informticos de las organizaciones, sino que prcticamente a a depende de todos los niveles de servicio. Nosotros a la hora realizar este borrador lo hemos clasicado en diversos niveles: Directivas generales: Lo primero que creemos que se echa en falta en gran parte de las organizaciones aliadas son unas directivas generales sobre seguridad, indicando a los usuarios internos y externos de la organizacin cules son los servicios y recursos o a que se estn ofreciendo, los mtodos de acceso, etc, y hasta formas de organizacin a e o de los servicios que proporcionen ms seguridad a las organizaciones. a Seguridad en nivel de Red: En esta seccin trataremos sobre todo las medidas para o IRIS-CERT 4

CAP ITULO 1. INTRODUCCION

evitar los ataques desde el exterior de una organizacin, comentando los ltros que se o deber instalar en los routers externos de las mismas para evitar diversos ataques an t picos que se producen. Seguridad en nivel de Sistema: Comentaremos aqu diversos aspectos de conguracin o de los equipos, centrndonos sobre todo en aquellos equipos multiusuario (equipos a de correo, servidores de cheros, etc).

IRIS-CERT

5

CAP ITULO 2. RECOMENDACIONES GENERALES

Cap tulo 2 Recomendaciones GeneralesEn esta seccin trataremos aspectos generales organizativos que creemos pueden ayudar o a la hora de aumentar la seguridad de las instituciones aliadas. El primero de estos aspectos, que creemos que se echa en falta en gran parte de las organizaciones aliadas, es el relativo a las pol ticas de seguridad. Muchas organizaciones no tienen establecida una pol tica de seguridad en la que se indiquen los derechos y obligaciones, o las sanciones en las que pueden incurrir los usuarios. En las pginas a del CERT (http://www.rediris.es/cert/docs/poliseg.es.html) se indican los aspectos que deber contemplar una pol a tica de seguridad. En organizaciones pequeas todav es frecuente emplear el mismo equipo como n a servidor de Internet (DNS, FTP, WWW, correo, etc) y como equipo multiusuario. Sin embargo, los problemas que pudieran derivarse de un robo de claves de usuario o de las acciones de los propios usuarios de la organizacin ser fcilmente evitables si los o an a mencionados servicios de Internet estuvieran instalados en un equipo al que slo tuvieran o acceso un grupo reducido de usuarios. Otro aspecto en el que creemos que se debe hacer un nfasis especial es en la e denicin de los puntos de contacto de cada organizacin. NO EXISTE ahora mismo o o en muchas instituciones un responsable denido para el rea de seguridad, o incluso una a direccin de correo a la que se pudieran enviar los avisos y noticaciones de seguridad. o Por lo tanto nos parece muy importante el que exista un alias de correo, redirigido despus e a cuentas de usuarios nales, para poder contactar con los responsables de seguridad de cada institucin, al igual que debe existir el alias de correo postmaster para tratar los o asuntos relacionados con el correo electrnico. o En aquellas organizaciones en las que por su complejidad interna existan varios responsables de rea, es evidente que tambin deber contar con este tipo de direccin. a e an o As se evitar tener que contactar con el PER de una institucin por telfono para a o e advertirle de un incidente, y que ste lo tenga que reenviar al responsable de un equipo, e el cual despes vuelve a noticarlo al PER, con lo que al nal no existe un seguimiento u real del incidente. Si una organizacin delega en un grupo la gestin de los servicios de comunicao o IRIS-CERT 6

CAP ITULO 2. RECOMENDACIONES GENERALES

ciones para una seccin, es lgico pensar que el personal de RedIris tiene que conocer o o esta situacin para poder contactar con los responsables de este departamento cuando sea o preciso. Por ultimo hay que destacar las dicultades que estn surgiendo en las institu a ciones que disponen de aulas o espacios de uso compartido, desde donde surgen ataques de denegacin de servicio y barridos de puertos y redes hac otras localizaciones, sin que o a muchas veces exista un control sobre quin ha sido el usuario que ha realizado la accin. e o Creemos que el acceso a estas instalaciones debe realizarse de una forma ms controlada. a

IRIS-CERT

7

CAP ITULO 3. SEGURIDAD EN NIVEL DE RED

Cap tulo 3 Seguridad en nivel de redLos ataques a nivel de red siguen siendo bastante frecuentes. Aunque las pilas TCP/IP de los distintos sistemas operativos son cada vez ms robustas, todav son frecuentes a a los ataques de denegacin de servicio en servidores NT y Unix debidos al empleo de o generadores de datagramas IP errneos o complicados de procesar. o Es tambin frecuente el empleo de herramientas automatizadas de escaneo y come probacin de vulnerabilidades en redes, as como la utilizacin de programas especif o o cos que explotan una determinada vulnerabilidad de un servidor o servicio concreto para atacarlo. En esta seccin vamos a tratar sobre todo las medidas que creemos que se deben o establecer en las organizaciones mediante el ltrado de diversos protocolos en los routers de acceso, para as evitar el acceso desde fuera a estos servicios. Estas medidas no sern a efectivas contra ataques internos, salvo que se apliquen medidas internas concretas en aquellas organizaciones que tienen un direccionamiento plano de red para su red f sica, pero permitirn como m a nimo reducir ciertos problemas como el SPAM o los ataques contra servicios bien conocidos como NFS, NetBios, etc. Adems permitirn que incluso a a si los usuarios nales activan esos servicios en sus mquinas, stos no sern accesibles a e a desde el exterior, evitando as mltiples problemas. u

3.1

Filtrado de paquetes

Aunque la seguridad a nivel de sistema sigue teniendo una importancia vital, los fallos en varios servicios TCP/IP y la existencia de protocolos defectuosos hace imprescindible el uso de ltros en el nivel de red, que permitan a una organizacin restringir el acceso o externo a estos servicios. De esta forma, slo aquellos servicios que deban estar accesibles o desde fuera del rea local sern permitidos a travs de ltros en los routers. Adems es a a e a importante que estos ltros determinen las condiciones de acceso a los servicios permitidos. Aunque el ltrado es dif de implementar correctamente, queremos dar algunos cil consejos que ayudarn a las organizaciones a implementar sus propios ltros en funcin a a o sus necesidades y a su topolog de red concreta. En particular, se recomienda encarecia IRIS-CERT 8

CAP ITULO 3. SEGURIDAD EN NIVEL DE RED 3.1. FILTRADO DE PAQUETES

damente que se ltren los siguientes servicios si no es necesario su acceso desde fuera de una organizacin concreta: oNombre echo systat netstat chargen SMTP domain bootp tftp link supdup sunrpc news Puerto 7 11 15 19 25 53 67 69 87 95 111 119 Tipo de conexin o tcp/udp tcp tcp tcp/udp tcp tcp/udp udp udp udp udp tcp/udp tcp Servicio Eco: Devuelve los datos que se reciben Informacin del sistema o Informacin sobre la red o Generador de caracteres continuo Puerto de correo Servidor de Nombres (DNS) Arranque de estaciones remotas sin disco Arranque de equipos remotos, carga de conguraciones

NetBios snmp xdmpc exec login shell bi who

137-139 161 177 512 513 514 512 513

udp/tcp udp udp tcp tcp tcp udp udp

Servicio de RPC (portmapper) Servidores de News (deber an estar ya ltrados en todos los routers de las organizaciones aliadas a RedIRIS) Servicios NetBios sobre TCP/IP (Windows) Gestin remota de equipos medio ante SNMP Llegada de correo Ejecucin remota de comandos o (rexec) Acceso remoto a un sistema (rlogin) Shell remoto Informacin sobre los usuarios o que hay conectados en un equipo remoto Almacenamiento de los logs de los sistemas en remoto Env de cheros y mensajes o mediante uucp, actualmente en desuso Informacin sobre enrutamientos o Sistema de cheros remotos de Sun y Unix en general Servidor X-Windows

syslog uucp

514 540

udp tcp

route openwin NFS X-Windows

520 2000 2049 6000 +n

udp tcp tcp/udp tcp

CHARGEN y ECHO: Puertos 11 y 19 (TCP/UDP) Es muy importante para eviIRIS-CERT 9


tar ataques de denegacin de servicio por puertos UDP (http://www.cert.org/advisories/CAo 96.01.UDP service denial.html), ltrar a nivel de router o rewall los servicios chargeny echoy en general todos los servicios UDP que operen por debajo del puerto 900, con excepcin de aquellos que se necesiten expl o citamente. Sistema de nombres de dominio (DNS): Puerto 53 (TCP/UDP) Es necesario ltrar el acceso desde el exterior a todos los equipos excepto a los servidores de DNS primarios y secundarios establecidos en una organizacin. 1 o TFTPD: Puerto 69 (UDP) En general cualquier servicio UDP que responde a un paquete de entrada puede ser v ctima de un ataque de denegacin de servicio (DoS). o Un acceso no restringido al servicio TFTP permite a sitios remotos recuperar una copia de cualquier chero word-readable, entre los que se pueden incluir cheros cr ticos como cheros de conguracin de routers y cheros de claves. Es por ello, o que aquellas organizaciones que no necesiten usar este servicio deber ltrarlo y an aquellas que necesiten usarlo, lo conguren adecuadamente teniendo en cuenta las medidas de seguridad a nivel de aplicacin. o Comandos r de BSD UNIX: Puertos 512, 513 y 514 (TCP) Los comandos r incrementan el peligro de que sean interceptados contraseas en texto plano cuando n se presenta un ataque utilizando sniers de red, pero lo ms importante es que son a una fuente bastante frecuente de ataques y vulnerabilidades. Filtrando los puertos 512, 513 y 514 (TCP) en el hardware de red se evitar que personas ajenas a su a organizacin puedan explotar estos comandos, pero no lo evitar a personas de su o a propia organizacin. Para ellos, aconsejamos el uso de otras herramientas como el o ssh, uso de versiones seguras de los comandos r (Wietse Venemas logdaemon), uso o de tcp wrapper para proporcionar una monitorizacin del acceso a estos servicios, etc... SunRPC y NFS: Puertos 111 y 2049 (TCP/UDP) Filtrar el trco NFS evitar a a que sitios ajenos a su organizacin accedan a sistemas de archivos exportados por o mquinas de su red, pero como ocurr en el caso anterior, no se evitar que se a a a realicen ataques desde dentro del rea local. La mayor de las implementaciones a a NFS emplean el protocolo UDP, por lo que es posible, en algunos casos, el env de o peticiones NFS falsicando la direccin origen de los paquetes (IP-spoong o http://www.cert.org/advisories/CA-1996-21.html. Es por tanto muy aconsejable la instalacin de las ultimas versiones actualizadas de los servidores y clientes NFS que o tienen en cuenta estas caracter sticas. SMTP Puerto 25 (TCP) Es importante congurar el router de manera que todas las conexiones SMTP procedentes de fuera de una organizacin pasen a una estafeta o central y que sea desde sta desde donde se distribuya el correo internamente. Este e1

Consultar la documentacin relativa a la conguracin del servidor de DNS en la seguridad de sistemas o o

IRIS-CERT

10


tipo de ltros permitir que no existan puertos 25 descontrolados dentro de una a organizacin, ya que suelen ser foco de importantes problemas de seguridad, adems o a de un registro centralizado de informacin, que podr ayudar a la hora de detectar o a el origen de intentos de ataque. El administrador del sistema o el responsable de seguridad slo se tendr que preocupar de tener actua lizado este servidor para evitar o a ataques aprovechando vulnerabilidades o fallos bien conocidos en los mismos. Para obtener ms informacin sobre diseo de un servicio de correo electrnico puede a o n o consultar la siguiente pgina: a http://www.rediris.es/mail/coord/sendmail/estafeta.html. NetBios. Puertos 137, 138 y 139 (TCP/UDP) Estos puertos son los empleados en las redes Microsoft (Windows para Trabajo en Grupo, dominios NT, y LANManager), tanto para la autenticacin de usuarios como para la comparticin de recursos o o (impresoras y discos). Es frecuente el permitir el acceso global a uno de estos dispositivos, ignorando que es posible el acceso a estos recursos desde cualquier direccin o de Internet. SNMP Puerto 161 (UDP/TCP) Muchos equipos disponen en la actualidad de gestin o SNMP incorporada. Dado que estas facilidades de gestin no suelen necesitar aco cesos externos, se deben establecer ltros a nivel de router que eviten que se pueda obtener informacin sobre los dispositivos (routers, hubs, switches) desde el exterior o o incluso se gestionen los equipos en remoto. Filtros de datagramas IP Por otro lado, para prevenir los ataques basados en bombas ICMP, se deben ltrar los paquetes de redireccin ICMP y los paquetes de destino o ICMP inalcanzables. Adems, y dado que actualmente el campo de opciones de los a paquetes IP apenas se utiliza, se pueden ltrar en la totalidad de las organizaciones los paquetes de origen enrutado (source routed packets). Estos paquetes indican el camino de vuelta que ha de seguir el paquete, lo cual es algo inseguro, ya que alguno de los puntos intermedios por los que pase el paquete puede estar comprometido. Si una organizacin determinada no necesita proveer de otros servicios a usuarios externos o deber ltrarse igualmente esos otros servicios. Por poner un ejemplo, ltrar conexiones an POP e IMAP a todos los sistemas excepto a los que deben ser accesibles desde el exterior. Esta misma regla es aplicable a otros servicios como WWW, SMTP, NTP, etc...). Con el protocolo IP que actualmente est mayoritariamente en uso, es casi imposia ble eliminar el problema del IP-spoong (falsicacin de la IP). Sin embargo, se pueden o tomar algunas medidas que reducirn el nmero de paquetes de este tipo que entran y a u existen en una red local. Actualmente, el mejor modo de realizar esto es restringir la entrada en el interfaz externo (ltro de entrada), no permitiendo que un paquete entre a nuestra red si tiene la direccin origen de la red interna. De la misma forma, se debern o a ltrar los paquetes salientes que tengan una direccin origen distinta a la correspondio ente a la red interna (con esto ultimo se evitarn ataque de IP-spoong originados desde a IRIS-CERT 11

CAP ITULO 3. SEGURIDAD EN NIVEL DE RED DE LAS PILAS TCP/IP EN EQUIPOS FINALES 3.2. CONFIGURACION

nuestra red). La combinacin de estos dos ltros prevendrn que un atacante de fuera o a de nuestra red env paquetes simulando hacerlo desde dentro de nuestra red, as como e que paquetes generados dentro de nuestra red parezcan haber sido generados fuera de la mismas. En la entrada al interfaz interno de una organizacin se deben ltrar los bloques o de paquetes con las siguientes direcciones: Redes Broadcast: Para evitar que su organizacin sea utilizada como intermediaria o en un ataque de denegacin de servicio de tipo smurf (http://www.cert.org/advisories/CAo 1998-01.html) es necesario bloquear el trco ICMP a las direcciones de broadcast a (bits dedicados a hosts todos a uno) y de red (bits dedicados a hosts todos iguales a cero). Su rea local. a Nmeros de red privada reservados: No se debe recibir trco desde o hacia las u a siguientes direcciones a travs de los routers puesto que se trata de redes privadas e reservadas: 10.0.0.0 - 10.255.255.255 10/8 (reservada) 127.0.0.0 - 127.255.255.255 127/8 (loopback) 172.16.0.0 - 172.31.255.255 172.16/12 (reservada) 192.168.0.0 - 192.168.255.255 192.168/16 (reservada)

3.2

Conguracin de las pilas TCP/IP en equipos o nales

Gran parte de los ataques de denegacin de servicio (DoS) se producen debido a fallos en o las implantaciones de las pilas TCP/IP en los sistemas operativos. As son famosos los , ataques de denegacin de servicio mediante el env de datagramas IP con informacin o o o ICMP errnea, que provocan el reinicio del equipo, o los ataques mediante inundacin o o SYN y FIN, impidiendo el normal funcionamiento de los servidores. En la medida de lo posible, se debe revisar la conguracin de estos sistemas, en especial la conguracin de o o reenv de datagramas IP (ip-forwarding), que permite que un sistema funcione como o un router.

3.3

Monitorizacin de routers y equipos de acceso o

Hace algunos aos era frecuente el empleo de equipos de acceso (servidores de pools de n mdems, routers de acceso, etc.) para la conexin a los servidores de las organizaciones o o desde el domicilio de los usuarios. Con la aparicin de Infov y los proveedores de acceso a o a IRIS-CERT 12

CAP ITULO 3. SEGURIDAD EN NIVEL DE RED DE LAS REDES Y FILTROS ANTI-SNIFFING 3.4. SEPARACION

Internet, el uso de estos sistemas ha ido disminuyendo, aunque siguen estando operativos en muchas instituciones. Tanto estos equipos como los routers de interconexin y cualquier dispositivo o (switch, concentrador ATM, etc. que disponga de esta opcin), deben estar monitorizados. o Los syslog deben congurarse para ir enviando los mensajes de la consola a un equipo central donde se deben almacenar durante un periodo razonable de tiempo, de forma que se puedan comprobar los intentos de conexin no autorizados y las ca o das que se producen en estos equipos. Esta monitorizacin es muchas veces muy sencilla de establecer y la o recepcin y almacenamiento de los registros no requiere mucha carga del procesador. o En instalaciones con mucho equipamiento de red puede ser recomendable el empleo de alguna herramienta de monitorizacin SNMP de los equipos, de forma que las o incidencias que vayan ocurriendo sean noticadas en tiempo real a los administradores de la red. Es necesaria la instalacin de versiones recientes de los sistemas operativos de o estos equipos, puesto que muchas instalaciones disponen de versiones antiguas susceptibles a ataques de denegacin de servicio que pueden ser fcilmente evitables si se actualizan o a peridicamente los sistemas. o

3.4

Separacin de las redes y ltros anti-sning o

Gran parte de los ataques que se producen son debidos a la obtencin de las claves emo pleando un programa de sning en una red ethernet. En muchas ocasiones, la separacin o de las redes y el empleo de switches y routers hace falta para permitir una mayor descongestin del trco interno de una organizacin, pero adems es muy necesario para lograr o a o a una mayor seguridad dentro de esta. Las salas de acceso general (bibliotecas, salas de prcticas comunes, aulas de estua diantes, etc.) deben estar separadas mediante puentes (bridges) o conmutadores (switches) del resto de la red, para evitar que se puedan obtener, mediante sniers, claves de acceso de otros grupos de usuarios. En general los equipos que necesiten el empleo de sistemas inseguros de transmisin de claves deber estar aislados de la red, de forma o an que estas claves no se transmitan por toda la organizacin. o Hay que considerar adems las posibilidades de gestin y consola remota que a o disponen muchos hubs y switches: hay que cambiar las claves por defecto que suelen tener estos equipos y deshabilitar la gestin remota de stos si no se va a hacer uso de o e ella (SNMP, consolas remotas, servidor de HTTP...). Consulte la ponencia presentada en los Grupos de Trabajo de Barcelona Implantacin de un sistema de securizacin global o o a nivel de red, (http://www.rediris.es/rediris/boletin/46-47/ponencia8.html). Hay que indicar que existen ya versiones de sniers para los sistemas Windows, siendo posible muchas veces la obtencin de contraseas de acceso a sistemas de cheros o n remotos de Netbios, pudiendo modicar fcilmente cualquier aplicacin existente en estos a o servidores. Adems en muchos servidores Samba la clave de conexin de Windows coincide a o

IRIS-CERT

13

CAP ITULO 3. SEGURIDAD EN NIVEL DE RED DE LAS REDES Y FILTROS ANTI-SNIFFING 3.4. SEPARACION

con la clave del usuario, por lo que estas medidas anti-sning se deben aplicar a cualquier protocolo que circule por la red.

IRIS-CERT

14

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA

Cap tulo 4 Recomendaciones en nivel de sistemaLas conguraciones establecidas por defecto en muchos sistemas operativos no son las ms adecuadas desde el punto de vista de seguridad. Adems, el desconocimiento y la a a desinformacin de los responsables de estos equipos es motivo frecuente de problemas de o seguridad. En este apartado vamos a comentar diversas medidas que se deber adoptar an en los sistemas para evitar gran parte de estos problemas.

4.14.1.1

Conguracin de equipos Unix oActualizacin y control de fallos o

Los ataques con ms xito en los sistemas informticos se basan en aprovechar vulneraa e a bilidades en el software que no ha sido actualizado a la ultima versin facilitada por el o fabricante, o que no ha sido parcheado convenientemente. Esto afecta tanto al software de red de grandes mquinas y sistemas operativos, como al software de PC de usuarios. a Esta tarea es laboriosa porque supone mantenerse al d de la evolucin de los a o productos, as como conocerlos a fondo para poder congurarlos correctamente. La may or de los vendedores mantienen listas con los parches recomendados (Sun, IRIX, etc...). a A la hora de instalar un parche, se recomienda comprobar la rma digital, si existiera, y el checksum para vericar que se trata de una copia vlida. El MD5 comprueba la a integridad y la no alteracin del paquete, y la rma PGP la autenticidad de su autor. o Es muy importante estar al d y revisar el software que se utiliza, especialmente a aquel que tenga que ver con la conectividad a Internet, administracin de servicios de red, o etc... y actualizarlo o parchearlo con las ultimas actualizaciones disponibles. A menudo no resulta buena idea utilizar la ultima versin disponible, sino la penltima, ya que al o u ritmo al que se lanzan nuevas versiones de productos, la ultima, con casi toda seguridad, no habr sido puesta a prueba en su fase de diseo ni ha sido sucientemente validada a n por los usuarios. A veces, merece la pena esperar un per odo de tiempo, aunque eso s , no con la primera versin del producto. o

IRIS-CERT

15

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.1. CONFIGURACION DE EQUIPOS UNIX

Por ultimo, comentar que no es suciente con instalar la ultima versin o actu o alizacin disponible, sino que es necesario congurarla convenientemente, de manera que o se cierren los resquicios que puedan dejar las instalaciones por defecto. Esta correccin o es importante no slo en los sistemas operativos, sino tambin en el software en general. o e

4.1.2

Directivas generales

En esta seccin, daremos algunas ideas a los administradores sobre la conguracin de o o los equipos Unix. Algunas de las directivas generales a la hora de congurar un sistema teniendo en cuenta la seguridad se pueden sintetizar en los siguientes puntos: La presencia de archivos .rhosts y /etc/hosts.equiv merece especial cuidado, pues garantizan el acceso a la mquina sin necesidad de autenticacin. Si no es necesario a o el uso de comandos r (aconsejado en cap tulos anteriores, e insistentemente por IRIS-CERT), no se necesita la presencia de estos archivos al no ser una alternativa segura a telnet. Se recomienda usar clientes ssh, ampliamente descritos ya en este documento. Se puede establecer qu terminales son seguros, y por lo tanto desde qu terminales e e se puede conectar el usuario root. En los terminales declarados como no seguros el usuario antes de llegar a ser root, necesitar conectarse utilizando una cuenta sin a privilegios en el sistema y despus utilizar el comando supara cambiar a root, lo e que aade un nivel extra de seguridad. n Desactivar IP forwarding y source routing. Es especialmente importante en el caso de estar usando una Sun como host bastin o como dual-homed. o Es importante deshabilitar la posibilidad de ejecucin de cdigo en pila de usuario, o o lo que evitar algunos problemas de buer-overow(pero no todos). En el caso a de mquinas Solaris lo podemos hacer incluyendo en el chero de especicacin del a o sistema /etc/systemlas l neas: set noexec_user_stack=1 set noexec_user_stack_log=1 y reiniciando a continuacin. o Evitar que el correo del root se almacene sin que nadie lo lea. Para ello establezca un archivo .forwarden el home del root para redirigir el correo a una cuenta real en el sistema. As mismo, ser necesario asegurarse que estos archivos, si existen a en los directorios home de los usuarios, no ejecuten ningn comando. u Desactivar la ejecucin de comandos en los dispositivos montables por los usuarios. o

IRIS-CERT

16

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.1. CONFIGURACION DE EQUIPOS UNIX

Separar las mquinas de los usuarios de aquellas que ofrecen algn servicio a la a u comunidad (servidores), y restringir en la medida de lo posible el acceso a las mismas. El administrador debe prevenir posibles escuchas en la red. Un snierescucha todo lo que pasa por una puerta ethernet, incluyendo contraseas de cuentas de usuario, n de superusuario, claves de POP, etc.. Para evitarlo, se recomienda el uso de Shell Seguro (ssh) (http://www.ssh.org/) u otros mtodos de cifrado de contraseas. e n Revisar el path de la cuenta root en los cheros de inicio (.login, .cshrc, .prole, ...). El comando path o la variable de entorno PATH denen los directorios de bsqueda u de los ejecutables. El directorio ., es decir, el actual, nunca debe aparecer en el path del root.

4.1.3

Seguridad en sistemas de archivos

El aspecto ms vulnerable en la proteccin de archivos son los modos de acceso SUID y a o SGID. Se aconseja realizar frecuentemente una auditor de los mismos, monitorizando a los cambios, puesto que son cheros especialmente explotados por intrusos potenciales. Algunas sugerencias son: Los sistemas Unix/Linux proporcionan otras maneras de limitar el acceso a varios recursos del sistema a usuarios que no sean el usuario root, como las cuotas de disco, la limitacin de los recursos del sistema por proceso y/o usuario, y la proteccin para o o los subsistemas restringiendo el acceso a las colas de procesos batch y de impresin o para los usuarios no autorizados. Si no hay mas remedio que usar NFS, se debe congurar de la forma ms restrictiva a posible. En el chero /etc/exports se especica a quin se exporta y cmo se exporta e o un sistema de cheros (de slo lectura, sin permiso de escritura al root, etc.). El o comando showmountpermite vericar que el chero de conguracin /etc/exports o es correcto. Establecer en el /etc/prole una umask para los usuarios lo ms restrictiva posible a (022, 033 incluso 077). La mscara del root debe ser 077. o a No usar Samba en la medida de lo posible. Si es necesaria su utilizacin, se debe o congurar muy restrictivamente el chero /etc/smb.conf. Asegrese de que todos los cheros que cuelgan del directorio /dev son cheros u especiales y que del mismo modo no existen archivos de dispositivo fuera de la estructura de /dev. Considere eliminar el acceso a lectura de todos aquellos archivos que no necesiten tener dicho acceso. Tambin es aconsejable revisar los cheros y directorios ese cribibles por todo el mundo. IRIS-CERT 17

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.2. FILTRADO DE SERVICIOS EN EQUIPOS UNIX

Asegrese de que el usuario root es el propietario de los directorios /etc, /usr/etc, u /bin, /usr/bin, /sbin, /usr/sbin, /tmp y /var/tmp. Adems, los directorios /tmp y a /var/tmp deben tener el sticky bit establecido. AUSCERT recomienda que todos los archivos ejecutados por el usuario root deben ser propiedad de dicho usuario, no ser escribibles ni por el grupo ni por otros (es decir, con modo 755 o mejor) y localizados en un directorio donde cada directorio en el path sea propiedad del usuario root. En este sentido, una prctica general a consistir en examinar la proteccin de los cheros y directorios antes y despus de a o e instalar software o de ejecutar utilidades de vericacin. o Es recomendable comparar las versiones de programas en el sistema con una copia vlida de las mismas (por ejemplo del CD-ROM). Hay que tener especial cuidado a con las copias de seguridad, pues pueden contener cheros alterados o Caballos de Troya. Los Caballos de Troya pueden tener el mismo standard checksumy timestamp que la versin original. Por esto, el comando de UNIX sum(1) y el timestamp o asociado a los programas no es suciente para determinar si estos han sido alterados o reemplazados. El uso de cmp(1), MD5, Tripwire y otras utilidades para generar un checksum criptogrco son necesarios para detectar estos caballos de troya. a

4.2

Filtrado de servicios en equipos Unix

Para evitar riesgos innecesarios, se deben congurar TODAS las mquinas de una orgaa nizacin para que ofrezcan unicamente los servicios que se tenga en mente ofrecer y no o otros. Esto disminuir considerablemente el riesgo de que estas mquinas sean atacadas a a aprovechando servicios completamente descuidados y que en muchas ocasiones no se es consciente que se estn ofreciendo. a Es necesario asegurarse de que no existen debilidades en los archivos de conguracin de los servicios ofrecidos y que los servicios se ofrezcan slo al conjunto de usuarios o o para los cuales se dise. no

4.2.1

Servicios dependientes de inetd

El archivo inetd.conf contiene una lista con todos los servicios que el demonio inetd1 invoca cuando recibe una peticin sobre un socket. o Por defecto, a la hora de instalar el sistema operativo, se establece un archivo inetd.conf con gran cantidad de servicios activados por defecto, que en la grand simaEl proceso inetd es un superservidor congurable, empleado para escuchar en varios puertos simultneamente y lanzar el programa adecuado para cada servicio. Para ms informacin, consulte las a a o pginas de manual de este comando. a1

IRIS-CERT

18

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.2. FILTRADO DE SERVICIOS EN EQUIPOS UNIX

mayor de los casos no son necesarios. Es completamente necesario revisar este archia vo con el n de comentar las l neas de todos aquellos servicios que no sean necesarios expl citamente, y que en muchas ocasiones son causa de ataques y vulnerabilidades. Nuestra recomendacin es comentar todos los servicios que se lanzan desde el o a inetd.conf anteponiendo un carcter #l principio de cada una de las l a neas. Una vez hecho esto, se pueden descomentar (quitando el carcter #) aquellos servicios que sean a necesarios en esa mquina en concreto. a Para que los cambios realizados en este archivo de conguracin tengan efecto, o recuerde reiniciar el proceso inetd. Puesto que en muchos casos, cuando se ofrece un servicio, ste est dirigido a e a un sector de la comunidad de Internet, es muy util contar con algn mecanismo que u permita rechazar conexiones dependiendo de su origen y/o de su ident, y que proporcione adems, una monitorizacin del acceso. En este contexto, recomendamos la instalacin a o o de tcp wrapper (http://www.rediris.es/cert/doc/docu rediris/wrappers.es.html), que se puede descargar en el FTP de RedIRIS. El tcp wrapper (tcpd) acta de intermediario u transparente en las conexiones TCP, aadiendo un nivel extra de registro de conexiones, n control de acceso y acciones congurables por conexin.2 o

4.2.2

Servicios dependientes de RPC

En general, los clientes de los servicios dependientes de RPC (Remote Procedure Control) hacen una llamada al gestor de RPC (rpcbind en Solaris, portmap en Linux, pero siempre el puerto 111/tcp), para averiguar donde estn los servicios de cada procedimiento. a Esta informacin se puede ver como usuario, con el comando rpcinfo -p, que o implementa una llamada al procedimiento remoto dump. Si alguno de los servicios que aparecen al ejecutar este comando no son necesarios, ser imprescindible desactivarlos en a los scripts de inicializacin del sistema, lugar desde donde son lanzados. o En cuanto al tcp wrapper, no puede usarse para controlar el acceso a estos servicios, pero si se puede usar para controlar y registrar el acceso al gestor RPC. Para hacerlo, es necesario tratar rpcinfo/portmap como un servidor independiente que implementa un servicio en el puerto 111. En Linux, portmap ya est compilado de esta manera, por lo que a el acceso se puede controlar directamente con los archivos hosts.allow y hosts.deny. En Solaris, se requiere compilar una versin especial del rpcbind y enlazarlo con la biblioteca o libwrap.a (Solaris: /usr/local/lib/libwrap.a, Linux: /usr/lib/libwrap.a).

4.2.3

Servicios arrancados en los scripts de inicio del sistema operativo

Aparte de los servicios dependientes de RPC y de los dependientes de inetd, comentados con anterioridad, en el proceso de instalacin del sistema operativo en una mquina se o aEn servidores que generan una carga elevada y que tienen su propio sistema de control de acceso y de histricos no es necesario el empleo de tcp wrapper. o2

IRIS-CERT

19

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.3. POL ITICA DE CONTRASENAS

activan una serie de servicios por defecto que se ejecutan desde el /etc/rc* correspondiente (por ejemplo el smtp, o el domain) que en la mayor de los casos no son necesarios. Si a ste es el caso, recomendamos que sean desactivados y que se modiquen los scripts de e inicio para que en subsiguientes arranques de la mquina no se vuelvan a lanzar. a

4.3

Pol tica de contrase as n

Sin duda, uno de los mtodos ms habituales usados por los hackers para comprometer e a un sistema es el robo de contraseas. Robando un nombre de usuario y su contrasea n n correspondiente, un intruso puede, reduciendo las probabilidades de ser detectado, ganar acceso a un sistema, modicarlo, y usarlo como lanzadera para atacar a otros sistemas. La mayor de los sistemas no tienen ningn mecanismo de control de las contraseas a u n que utilizan sus usuarios y en la mayor de los casos existe por lo menos una contrasea a n en el sistema que puede ser fcil de descubrir, comprometiendo la seguridad del sistema a completo. La proteccin de las contraseas es uno de los principios ms importantes en seo n a guridad, por lo que es necesario que las organizaciones posean una pol tica de contraseas n bien denida. Las tcnicas utilizadas por los crackers para obtener contraseas ajenas son muy e n variadas (desde aprovechar vulnerabilidades en ciertas aplicaciones hasta utilizar Caballos de Troya, usualmente enmascarados en el programa /bin/login). Si un intruso obtiene un chero passwd de una mquina ajena, normalmente realiza una copia del mismo a otra a mquina y ejecuta programas crackeadores contra l, que son relativamente rpidos y que a e a realizan ataques de fuerza bruta, de diccionario o h bridos sobre las contraseas robadas. n A continuacin daremos algunas directivas a tener en cuenta por los admino istradores de sistemas o responsables de seguridad para implementar una pol tica de contraseas adecuada en sus organizaciones. n

4.3.1

Contraseas dbiles n e

La primera directiva, y en nuestra opinin la ms importante, es desarrollar una o a gu que ayuden a los usuarios a la hora de escoger contraseas lo sucientemente as n robustas para que no sean vulnerables a los ataques de diccionario o de fuerza bruta que suelen realizar la mayor de las utilidades diseadas para romper contraseas. a n n Estas medidas vienen ampliamente descritas en multitud de documentos por lo que no creemos necesario que sean repetidas aqu pero a modo de ejemplo: no , se deben escoger palabras del diccionario, palabras de estn relacionadas con el e usuario (nombre de la mujer o marido, domicilio, fecha de nacimiento, etc...), utilizar contraseas con una longitud m n nima de 8 caracteres, no usar el nombre de usuario o una variante, como el nombre de usuario al revs, etc. e

IRIS-CERT

20

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.3. POL ITICA DE CONTRASENAS

Informar a los usuarios de que no almacenen informacin sobre su cuenta/contrasea o n en archivos de texto en ningn sistema. u Si se tiene ms de una cuenta en distintos sistemas no es aconsejable utilizar la a misma contrasea en todas, pues si la contrasea quedara comprometida en una n n mquina, lo quedar igualmente en el resto. a a Cuando se utiliza el servicio de nger (puerto 79 tcp/udp) para interrogar a un servidor, a menudo ste revela ms informacin sobre s mismo y sus usuarios de la e a o que ser deseable (el shell que est utilizando cada usuario, su directorio personal, a a el grupo al que pertenece, y lo que en este caso es ms importante, el nombre del a usuario en la mquina, con lo que el atacante ya poseer la mitad de la informacin a a o que necesita para entrar en un sistema). Debido a que adems suele proporcionar a informacin sobre la hora del ultimo login, un atacante podr confeccionar patrones o a de trabajo de los distintos usuarios. En denitiva, se trata de informacin demasiado o valiosa para distribuirla sin control, por lo que es aconsejable eliminar este servicio de las mquinas si no es estrictamente necesario su uso. a Utilizar con cierta frecuencia programas tipo crack para chequear la robustez de las contraseas del sistema y de esta forma encontrar claves dbiles forzando el cambio n e de las mismas. Es mejor que nosotros conozcamos antes que el atacante la debilidad de nuestras contraseas. n Establecer un pol tica de cambios peridicos de contraseas (sobre todo en las o n mquinas ms importantes y las de cuentas privilegiadas). Adems es aconsejable a a a no reutilizar contraseas antiguas. n

4.3.2

Cuentas sin contrase a o contrase as por defecto. n n

Cambiar todos las contraseas instalados por defecto en el proceso de instalacin n o del sistema operativo. Escanear el chero de contraseas (/etc/shadow o /etc/passwd) peridicamente en n o busca de cuentas con UID igual a 0 (reservada para el usuario root). Revisar el chero de contraseas en busca de cuentas nuevas de las que no se tiene n conocimiento y que en la mayor de los casos son indicativo de intrusin. a o No permitir la existencia de cuentas sin contrasea. n Eliminar cuentas de usuarios que se hayan dado de baja en la organizacin o que o no se estn utilizando. e Es aconsejable el uso de programas como noshell (ftp://ftp.rediris.es/mirror/coast/tools/unix/noshell) que permiten al administrador IRIS-CERT 21

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.4. POL ITICA DE CUENTAS

obtener informacin adicional sobre intentos de conexin a cuentas canceladas o o o bloqueadas en una mquina. Utilizando este mecanismo, cada intento de conexin a o queda registrada, mediante correo electrnico o syslogd, dando informacin sobre el o o usuario remoto, la direccin IP, el d y la hora del intento de login y el tty utilizado o a en la conexin. o

4.3.3

Contraseas reutilizables n

Reducir o eliminar la transmisin de contraseas reutilizables en texto claro sobre o n la red. De esta forma se evitar que las contraseas sean capturadas por lo que se a n denomina packet sniers3 . Utilice contraseas de un slo uso (one-time passwords)(S/Key, Secure Net Key, n o Secure ID, etc...) para el acceso autenticado desde redes externas o para acceder a recursos sensibles como routers, servidores de nombres, etc. Si se trata de sistemas UNIX, recomendamos el uso del chero /etc/shadow, o lo que es igual, un segundo chero que contiene las contraseas cifradas y es slo n o accesible por el usuario root, quedando el /etc/passwd con una xen el lugar donde deber aparecer las contraseas cifradas. La mayor de sistemas Linux, por an n a ejemplo, vienen con PAM congurado. PAM (Pluggable Authentication Modules) es un mtodo mucho ms potente de gestin de seguridad y contraseas que se e a o n adapta perfectamente a cualquier entorno UNIX. Si su sistema tiene la posibilidad de aplicar una serie de reglas en la introduccin de o palabras clave, es aconsejable que lo utilice. Por ejemplo, en el caso de un sistema Solaris, en el archivo /etc/default/passwd, o en un sistema con PAM, en el chero /etc/pam.conf, se pueden establecer algunos valores por defecto, como son el nmero u m nimo de caracteres que debe tener un contrasea, el mximo per n a odo de tiempo en el cual es vlida, el m a nimo per odo antes de que la contrasea pueda cambiarse, n etc.

4.4

Pol tica de cuentas

Desde el punto de vista de la seguridad, el chero /etc/passwd tiene una importancia vital. Si tiene acceso a este archivo, lo puede alterar para cambiar el contrasea de cualquier n usuario, o incluso tener privilegios de superusuario cambiando su UID a 0. Entre las recomendaciones que podemos dar para establecer una pol tica adecuada de cuentas y grupos en un sistema podemos destacar:Herramientas de monitorizacin y de red que permiten leer toda la informacin que circula por un o o segmento de la red, pudiendo as obtener las claves de acceso a las sesiones de terminal(telnet), ftp, http y servicios ms comunes a3

IRIS-CERT

22

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.4. POL ITICA DE CUENTAS

4.4.1

Administracin o

Del mismo modo que alentamos a las organizaciones para que posean una pol tica de contraseas bien denida, es necesario que tambin dispongan de un formulario n e para el registro de usuarios bien denido, donde se incluya una seccin, que deber o a ser rmada por el beneciario, aceptando las condiciones y responsabilidades que supone tener una cuenta en el sistema. Se deber contemplar tambin la posibilidad a e de acreditacin por parte de los mismos. o Asegurarse de que existen copias de seguridad del rea de disco de usuarios siempre a que esto sea posible y se dispongan de los medios para hacerlo. Considere el agrupar los directorios de los usuarios de una forma lgica, especialo mente si espera tener muchos usuarios en el sistema. Monitorice los registros en busca de intentos suno autorizados o fallidos. Compruebe frecuentemente los intentos de conexin no autorizados. o Establezca una pol tica de asignacin de cuotas de disco a usuarios y grupos, as o como la preparacin de procedimientos de comprobacin de los mismos con el n o o de controlar que ningn usuario sobrepase el l u mite de espacio asignado.

4.4.2

Cuentas especiales

Evitar la existencia de cuentas compartidas. Evitar la existencia de cuentas guesto de invitados. En este sentido, como varios sistemas instalan cuentas para invitados por defecto, ser pues necesario desactivar a o eliminar del sistema este tipo de cuentas. Usar grupos espec cos para restringir qu usuarios pueden utilizar el comando su. e Comprobar el archivo de contraseas del sistema una vez haya terminado el proceso n de instalacin del sistema operativo a n de asegurarse de que todas las cuentas o predeterminadas tienen contraseas invlidas o han sido desactivadas o eliminadas. n a Eliminar todas las cuentas que permiten unicamente la ejecucin de un comando o (por ejemplo sync). Si se permiten este tipo de cuentas, el administrador deber a cerciorarse de que ninguno de los comandos que ejecutan acepta entradas de l nea de comandos y de que no permiten ningn tipo de escape al shell que pueda permitir u acceder a un shell de forma externa.

IRIS-CERT

23

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.5. CONFIGURACION DE SERVICIOS MAS USUALES

4.4.3

Usuario root

La contrasea de root ha de ser especial, por lo que es necesario seleccionarla con n cuidado, guardarla en lugar seguro y modicarla a menudo. Restringir el nmero de usuarios en el sistema que tienen acceso a esta cuenta. u Evitar la existencia de archivos .rhosts en el directorio base del usuario root (normalmente /, o en Linux, /root/). Evitar la existencia del .en el path de bsqueda del usuario root y de los adminu istradores. Hacer uso de rutas completas para ejecutar rdenes como root. o Evitar entrar por telnet como root a las mquinas, para as evitar la intercepcin del a o contrasea en texto en claro, que dar a un intruso acceso total al sistema. Queda n a entonces doblemente marcado como importante el uso de ssh como herramienta indispensable para entrar en las mquinas remotamente. a

4.5

Conguracin de servicios ms usuales o a

En este apartado vamos a comentar la conguracin de algunos de los servicios ms o a usuales que son ofrecidos por las organizaciones, sin entrar en detalle, pues estos temas ya se tratan en los Grupos de Trabajo correspondientes.

4.5.1

Conguracin del sistema de correo o

El servicio de correo es uno de los ms fciles de congurar en la actualidad, aunque a a paradjicamente sigue siendo uno de los ms problemticos en lo que a seguridad se reere. o a a En principio podemos clasicar los equipos en funcin de su papel en la transferencia del o correo, en: Equipos de usuario : Sistemas que leen y almacenan localmente el correo de uno o varios usuarios. Estos equipos suelen ejecutar un lector de correo o agente de usuario para obtener los correos. Suelen ser Pcs con Eudora, Outlook, Netscape o sistemas multiusuarios Unix con mh, pine, mutt, etc. En cualquier caso, para la lectura y almacenamiento de los correos en equipos Unix no es necesario que exista un proceso escuchando en el puerto 25 (SMTP), ni en los puertos de lectura de correo (110 (POP3) o 141(IMAP)). Equipos de almacenamiento de correo : Equipos en los que se almacena el correo a la espera de ser le desde los equipos de usuario. Para ello suelen emplear do el protocolo pop3 (puerto 110), y en algunos casos emplean imap (141). Para la IRIS-CERT 24


recepcin de correo suelen ejecutar el programa sendmail en el puerto 25, aunque o tambin es posible emplear otros programas, como smap/smapd del fwtk (rewalle toolkit), para no tener que ejecutar sendmail. Equipos de intercambio de correo : Son los encargados de transferir el correo entre Internet y las organizaciones. Estos equipos deben tener un registro MX en el DNS, y tener establecido su direccionamiento inverso. Adems en el router se debe ltrar a el trco de la organizacin para que slamente se produzcan accesos al puerto 25 a o o de las servidores que estn denidos en el DNS como MX (Mail eXchanger). Deben a ejecutar sendmail, Postx o un programa similar escuchando continuamente en el puerto 25. La conguracin de este servidor es crucial para el buen funcionamiento del sero vicio de correo. Se debe instalar la versin ms actual del programa sendmail (el o a suministrado en muchos S.O., salvo Linux o FreeBSD, suele ser bastante antiguo) y congurarlo adecuadamente para que no pueda ser empleado para la distribucin o de correo basura (SPAM). Consulte http://www.rediris.es/mail para ms informacin sobre como congurar a o el servicio de correo en las organizaciones aliadas a RedIRIS. En los equipos de almacenamiento, procure que las cuentas de correo no estn e vinculadas directamente a una cuenta del sistema, o que sta est bloqueada salvo e e que sea necesaria. Evite la circulacin de las claves en claro mediante el uso de o APOP, desactive las cuentas de los usuarios que han dejado de pertenecer a la organizacin, sustituyendo las cuentas por alias a sus nuevas direcciones de correo. o

4.5.2

Conguracin del DNS o

El servicio de DNS es crucial para la conexin a Internet. Sin embargo en muchas orgao nizaciones no est congurado adecuadamente. Como en el correo, la conguracin de a o este servicio ha sido explicada en el Grupo de Trabajo correspondiente, pero sin embargo creemos que se debe destacar: 1. Tener una versin actualizada del servidor de nombres: Es conveniente actualizar a o una versin moderna del servidor. Las ultimas versiones son ms seguras y permiten o a establecer ltros y limitaciones en las transferencias de zonas, actualizaciones no solicitadas de datos, etc. 2. Tener congurado el direccionamiento inverso: Muchas instituciones no tienen establecido el direccionamiento inverso para los equipos, lo que diculta muchas veces el acceso a determinados servicios o la monitorizacin en los registros. o 3. Denegar el acceso a las zonas a otros servidores: Es conveniente que los servidores DNS estn congurados para permitir las transferencias de zona solamente a los e IRIS-CERT 25


servidores que estn denidos como secundarios; as se evita el que se pueda obtener e informacin sobre la topolog y conguracin de la red desde el exterior. o a o 4. No poner conguraciones de equipos en el DNS: Es posible indicar en los registros de DNS qu sistema operativo, arquitectura hardware, e incluso qu servicios se e e estn ejecutando en la mquina. Esta informacin se puede emplear para atacar a a o desde fuera de la organizacin. o 5. Conguracin en los clientes: En los ltrados de puertos (con tcp wrapper) o en o listas de acceso (en cheros hosts.allow y hosts.deny), emplear nombres cualicados por completo y no slo el nombre del equipo, para evitar que un equipo de otra o organizacin que se llama igual pueda tener acceso al sistema. o 6. Aspectos generales de conguracin: Como norma general, se debe cumplir que: o No se deben congurar los servidores de DNS para que reenv las peticiones en (hagan forward) a equipos de RedIRIS. No se deben congurar DNS como secundarios de otra organizacin, salvo o autorizacin expl o cita de la otra parte. A ser posible se deben tener dos servidores, primario y secundario, en una misma organizacin, y por tanto tener especicados ambos equipos como servidores o de nombres en la conguracin de todos los equipos. o

4.5.3

Conguracin de los servidores WWW o

Los equipos servidores WWW son susceptibles a varios tipos de ataques. Algunas medidas para evitarlos: 1. Dimensione el equipo adecuadamente, para evitar que se produzcan ataques de denegacin de servicio (DoS). o 2. Instale una versin actualizada del servidor WWW. o 3. Salvo que sea necesario, deniegue el uso de CGIs que no sean los empleados por los administradores, elimine los CGIs de prueba, que suelen tener vulnerabilidades de seguridad, y desactive las extensiones del servidor (PHP, Server-Side Includes, servlets de java, etc.) salvo que sean necesarios. 4. En caso de que los usuarios deban programar CGIs, advirtales de los fallos ms e a comunes que pueden existir y como solucionarlos (ftp://ftp.cert.org/pub/techtips/cgimetacharacters). 5. No comparta las pginas de los servidores mediante un sistema de cheros; emplee a un sistema de replicacin (wget, mirror, etc.) para realizar el intercambio de las o pginas. a IRIS-CERT 26


4.5.4

Conguracin de los servidores FTP o

Lo servidores de FTP se han empleado en muchas ocasiones para el almacenamiento de software ilegal, propiciando el abuso de este servicio y muchas veces la sobrecarga de procesamiento de los servidores. Unas recomendaciones generales sobre este servicio son: 1. Instalar una versin del servidor actualizada, y able: Las versiones del servidor FTP o que vienen con los sistemas operativos comerciales suelen tener pocos parmetros a de conguracin, y tambin varios fallos de seguridad. An en el caso de que no o e u se vaya a emplear el equipo como servidor de FTP, instale una versin actual de o ProFTPd o wuFTPD, que proporcionan bastantes opciones a la hora de congurar el nmero mximo de conexiones, or u a genes de la conexin,etc. o 2. En caso de que no se emplee el servicio de FTP annimo, deshabilitarlo. En caso de o que se emplee, salvo que sea necesario no permitir que el usuario FTP tenga permisos de escritura en ningn directorio, y en caso de que tenga que escribir, mantener este u directorio en otro sistema de cheros y evitar que el usuario tenga permisos de lectura y/o creacin de directorios, para evitar la creacin de repositorios de programas o o pirateados (http://www.rediris.es/cert/doc/docu rediris/ftpcong.es.html). 3. No emplear el servicio de FTP para la transmisin de documentos o cheros imporo tantes entre equipos, pues las claves de conexin se transmiten en claro. Use en su o lugar scp, un reemplazo de rcp que viene con el paquete ssh.

4.5.5

Servidores de cheros

Hace algunos aos era frecuente el empleo de servidores de cheros en los sistema Unix n para la comparticin de software entre las diversas estaciones de trabajo. En la actualo idad es frecuente encontrar sistemas de cheros en red, de los que el ms conocido es el a soporte de NetBios sobre IP (Windows 3.11/9x/ME/NT/2000 principalmente, pero tambin Unix con Samba). Su incorporacin a la red se debe hacer tomando algunas medidas e o de seguridad. Servidores NFS El acceso NFS es frecuente en entornos Unix puros, aunque existen clientes y servidores para Windows 9x/NT/2000 y Novell Netware. Algunos puntos que hay que comprobar a la hora de congurar un servidor NFS deben ser: 1. Emplear servidores/clientes de NFS recientes. Inicialmente los servidores de NFS empleaban UDP como protocolo de transporte, pudiendo alterarse fcilmente las a conexiones y realizar ataques simulando ser tanto el origen como el destino de las conexiones. La versin 3 del protocolo NFS permite usar TCP y emplea claves o criptogrcas para evitar la suplantacin de los equipos. a o IRIS-CERT 27


2. No exportar directorios con permisos de escritura. Salvo que sea estrictamente necesario, exportar los sistemas de cheros con permisos de slo lectura, de forma que o no se pueda escribir en ellos. En caso de que se tengan que exportar sistemas de cheros con permisos de escritura (directorios personales de usuarios, por ejemplo), no exporte jerarqu de directorios que contengan binarios. En las estaciones as clientes evitar montar sistemas de cheros con permiso de ejecucin. o 3. Restringir los accesos. No exportar cheros de conguracin, indicar en las opciones o de exportacin qu equipos son los que pueden montar los recursos, y emplear o e para ello las direcciones IP o los nombres DNS **COMPLETOS**, para evitar suplantaciones de los equipos. Servidores NetBios NetBios se puede emplear sobre diversos protocolos de transporte. Su utilizacin original o empleaba un protocolo denominado NetBEUI, que no permite el enrutado de los paquetes. Sin embargo, ahora mismo NetBios se emplea sobre TCP/IP, en servidores Windows y Unix. Algunos problemas de seguridad que tiene este protocolo son: Recomendamos, con toda rotundidad, que Windows 9x/ME se considere comprometido desde el mismo momento en que se arranca. Ninguna versin de Windows o 9x/ME deber ser jams utilizada en cualquier ordenador de una red donde algn a a u recurso necesite ser asegurado. En sistemas NT/2000 es preciso tener instaladas las ultimas versiones de los parches existentes (Service Packs), ya que las primeras implementaciones de los servidores tienen diversos problemas que abren la puerta a ataques de denegacin de servicio o (DoS). Evitar la exportacin de sistemas de cheros que contengan ejecutables con permisos o de escritura, tanto para evitar la suplantacin de los binarios como para evitar la o proliferacin de virus. o En los servidores NT/2000 tener restringido y especicado siempre el acceso al grupo Todos y despus permitir los accesos en funcin de los grupos de usuario. Hay que e o tener en cuenta que si estos servicios estn abiertos a todo el mundo es posible a acceder a ellos desde cualquier direccin IP. o En servidores NT/2000 emplear como sistema de cheros NTFS, ya que permite especicar derechos individuales a los usuarios. Por ello recomendamos no emplear FAT. En el caso de exportar directorios particulares de usuarios, emplear un sistema de cuotas en el servidor, ya sea mediante la instalacin del parche correspondiente o IRIS-CERT 28

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.6. MONITORIZACION DE ARCHIVOS DE REGISTRO

(Service Pack 4 o superior en NT), empleando las utilidades de Windows 2000, o empleando un equipo Unix con Samba y cuotas de disco, para evitar que un usuario pueda llenar la particin. o Si se emplea Samba, procurar que las claves de acceso no sean las mismas que las de las cuentas de usuarios en los equipos. Emplear, si es posible, un servidor de autenticacin externo (PDC) para evitar que las claves puedan ser obtenidas o mediante un snier de red o por alguno de los virus y troyanos que estn apareciendo e cada vez con ms frecuencia en entornos Windows. a

4.6

Monitorizacin de archivos de registro o

En Unix existen diversos mecanismos para que quede constancia de toda la actividad de un proceso. El ms simple de estos mecanismos es que el proceso en cuestin vaya a o escribiendo una especie de registro de todo lo que hace en un chero (lo normal es llamar a estos registros logs, aunque hay palabras en castellano de sobra, como registroso histricos). o Este mtodo tendr sus limitaciones: e a si dos procesos escriben sus informes simultneamente al mismo chero el resultado a nal puede ser confuso. no nos sirve de mucho si queremos almacenar, a medida que se producen, copias de estos informes en otra mquina distinta. a en algunos casos no nos basta con llevar un registro: hay situaciones de emergencia que deben avisarse inmediatamente. lo ideal es que estos cheros no puedan ser modicados por cualquiera (o poco valor tendr como registro able), pero interesa que cualquier programa tenga an capacidad de generarlos, lo cual es una contradiccin. o Para solucionar estas limitaciones se cre el sistema syslog de Unix. Est como a puesto por lo siguiente: Un proceso privilegiado (syslogd), capaz de generar cheros de log y avisos bassndose a en determinadas conguraciones hechas por el administrador. Un servicio TCP/IP (514/udp), que permite enviar mensajes syslog de una mquina a a otra. Un chero de conguracin (/etc/syslog.conf). o

IRIS-CERT

29


4.6.1

Conguracin o

El chero /etc/syslog.conf permite especicar qu acciones se llevan a cabo cuando un e determinado programa solicita registrar una actividad. Syslog clasica las actividades a registrar segn dos parmetros: subsistema (facility) y severidad. u a El subsistema depende de quin ha generado el informe: el ncleo, sistema de e u correo, news, etc. La severidad indica la prioridad que se le asigna a cada uno de los mensajes, desde los de depuracin (debug) hasta los de emergencia y/o pnico. Consulte o a la pgina de manual de syslogd.conf para ms informacin. a a o El chero de conguracin permite asignar acciones por subsistema y severidad. o Por ejemplo: mail.info /var/log/mail mail.err /var/log/mail-errores kern.crit root kern.emerg * auth.info /var/log/auth auth.info @otramaquina

Esto signica: Los informes relacionados con correo, que tengan severidad informativa o mayor se almacenan en el chero /var/log/mail. Si tienen severidad error o mayor, se almacenan en otro chero /var/log/mail-errores. Si se produce un mensaje cr tico del sistema, no esperamos a almacenarlo en ningn u sitio; se escribe inmediatamente un mensaje a root donde quiera que est, para e que sepa lo que pasa. Si ese mensaje es adems del tipo emergencia, no slo avisaremos a root sino a a o todos los usuarios (es lo que pasa cuando se hace un shutdown, por ejemplo). Los informes de seguridad, de severidad info o mayor, no slo se guardan en el o chero /var/log/auth sino que adems se mandan a la mquina otramaquina (sto a a e asume que hay un syslog corriendo en otramaquina, que el puerto 514/udp de la misma est accesible y que ese syslog est a su vez congurado). a a

4.6.2

Particularidades

Se deben utilizar tabuladores y no espacios en el chero /etc/syslog.conf.

IRIS-CERT

30


Si se genera un informe que no est previsto en el chero de conguracin, syslog lo e o volcar a la consola. a Los cheros donde vamos a volcar estos logs deben estar creados de antemano, aunque estn vac e os. El valor de severidad notice no se puede combinar con otros, debe aparecer solo en una l nea. El comod * equivale a todos los subsistemas excepto mark. n

4.6.3

Uso desde programas

Los programas en C usan llamadas al sistema para acceder a syslog. Sin embargo, los scripts tambin pueden hacerlo. Si son en Perl, la forma ms fcil es usar el mdulo Perl e a a o Sys::Syslog (man Sys::Syslog). Tanto en Perl como desde el shell se puede usar el programa logger: logger -p mail.err Error entregando mensaje. que enviar dicho informe como subsistema mail y severidad err. a Existen otras opciones (ver man logger).

4.6.4

Rotacin de cheros de registro o

El problema de almacenar registros histricos o logs es que stos crecen, y tarde o temo e prano llenan el disco. Para evitar esto, se recurre a la rotacin de logs. o Ejemplo de chero rotado mensualmente: 1. Antes de empezar: /var/log/milog se crea vac o. 2. Al primer mes: /var/log/milog se renombra como /var/log/milog.1 /var/log/milog se vac ade nuevo (se copia /dev/null sobre l). e 3. Al segundo mes: /var/log/milog.1 se renombra como /var/log/milog.2 /var/log/milog se renombra como /var/log/milog.1 /var/log/milog se vac ade nuevo.

IRIS-CERT

31

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.7. COMPROBACION DE INTEGRIDAD

Por supuesto, almacenaremos un nmero limitado de meses (o semanas, o d u as), o sto e no servir de nada. Adems, los registros de meses (semanas, d anteriores se pueden a a as) comprimir. Hacer esto tiene su truco. No se puede borrar impunemente un chero que est a abierto por un proceso (syslogd, en este caso), mejor dicho, no se debe, ya que los resultados no sern los que nos imaginamos. a La manera correcta de vaciar un chero abierto es: cp /dev/null

4.6.5

Otros aspectos relacionados

Algo ms sobre los aspectos de seguridad: cuando se almacenan registros con nalidad a informativa (estad sticas, etc) suele bastar con almacenarlos en la misma mquina donde a se generan. Cuando se almacenan por motivos de seguridad, sin embargo, nos interesa preservar una copia en otra mquina. El motivo es que si hay una intrusin en la primera a o mquina podrn borrar o modicar los registros, pero esas mismas actividades quedarn a a a registradas en la segunda, avisando as a los operadores. Normalmente, la mquina que reciba los logs (loghost) no debe recibir otra cosa a (para no ser susceptible de ataques) ni debe poder recibir logs desde fuera de la red local (para evitar ataques por saturacin). Para evitar consultas al DNS cada vez que se o genere un informe, la direccin IP de esta mquina debe estar en el chero /etc/hosts de o a las mquinas que manden informes. a

4.7

Comprobacin de integridad o

Una vez que se ha accedido a un sistema es frecuente modicar los binarios de algunos servicios y programas del sistema operativo para permitir su acceso posterior. As mismo se pueden modicar los cheros de conguracin de los servicios para hacerlos ms vulo a nerables. Para evitar esto se suele emplear herramientas de comprobacin de integridad. o Estos programas funcionan en dos fases; primero se crea la base de datos de integridad, empleando varios algoritmos criptogrcos para obtener una huella dactilar de cada a uno de los cheros. En una fase posterior se comprueban peridicamente los cheros exo istentes en el sistema de cheros con las rmas que ha generado este programa, pudiendo as averiguar si se ha producido alguna modicacin en los mismos. o Existen varias herramientas que permiten realizar esta comprobacin de integrio dad. La ms conocida es quiz Tripwire. Este programa permite emplear varios algorita a mos criptogrcos a la hora de generar la base de datos (MD2, MD4, MD5, SHA, Snefru, a CRC-32), para evitar que un atacante pueda modicar los cheros. La ultima versin o de Tripwire disponible de uso general es la versin 1.3, disponible en el servidor FTP de o Rediris. Desde el ao pasado la Universidad de Purdue transri la licencia a la empresa n o

IRIS-CERT

32

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.7. COMPROBACION DE INTEGRIDAD

Tripwire Security System, que ha desarrollado una nueva versin, la 2.0 disponible tamo bin para entornos Windows NT. Sin embargo, y dado que las diferencias son m e nimas con respecto a la versin 1.3, emplearemos sta como referencia. o e

4.7.1

Instalacin de Tripwire o

Tripwire est disponible en el repositorio de programas de seguridad de RedIRIS (ftp.rediris.es/soft/red a en cdigo fuente para los sistemas Unix. As mismo est compilado en formato de paqueo a te para algunas distribuciones Linux. La compilacin no suele dar problemas y una vez o instalado se emplea el chero de conguracin /usr/local/bin/tw/tw.cong para indicar o qu cheros se deben comprobar. e

4.7.2

Conguracin de Tripwire oR R R R R R R R L L R L R R L-am R R L L L L L R E

Un ejemplo ser a: /root / /vmlinuz /boot /etc /etc/inetd.conf /etc/rc.d /etc/exports /etc/mtab /etc/motd /etc/group /etc/passwd /usr /usr/local /dev /usr/etc =/home /var/spool /var/log /var/spool/cron /var/spool/mqueue /var/spool/mail /sbin =/proc =/tmp =/cdrom

IRIS-CERT

33

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.8. SEGUIMIENTO DE PROCESOS

Como se ve, cada una de las entradas est formada por un identicador del a directorio o chero que se debe monitorizar y despues una serie de ags. Tripwire por defecto viene con una serie de identicadores predenidos (R, L, E, etc.) para indicar distintas situaciones, como por ejemplo el que los cheros sean de slo lectura (R), cheros o de log (L), o cheros que se deben excluir (E), etc. Consulte la pgina del manual para a ver las distintas opciones de Tripwire. Una vez denido el chero de conguracin se debe ejecutar el comando tripwire o con la opcin de crear la base de datos (tripwire -initialize). De esta forma Tripwire o calcular los hash (las huellas) de cada uno de los cheros y almacenar la informacin a a o en los cheros de la base de datos. Una vez generada la base de datos se debe almacenar en un dispositivo de slo lectura (como un CD-ROM) o copiada a otro equipo para evitar o que un intruso pueda modicarla. En sistemas con dispositivos removibles donde se pueda bloquear f sicamente la escritura (disquetes), se puede copiar ah la base de datos y despus protegerlos contra escritura (en las unidades ZIP el bloqueo se realiza a nivel e software, por lo que esta medida no es vlida). a De esta forma es posible lanzar un proceso peridicamente que compruebe la o integridad de los cheros para evitar modicaciones, y actualizar manualmente la base de datos cuando se actualice el sistema operativo o se apliquen parches a ste. e

4.8

Seguimiento de procesos

En gran parte de los sistemas Unix es posible ejecutar procesos de accounting o contabilidad para ir registrando el uso de los recursos de los equipos por parte de los usuarios y los procesos. La forma de congurar el sistema para que realize estos mtodos de ace counting suele depender mucho del sistema operativo del equipo, ya que suele realizarlo el ncleo (kernel) de ste, volcndose a cheros cada cierto per u e a odo de tiempo y realizando un procesamiento estad stico de estos datos. Antiguamente los procesos de accounting sol requerir bastante tiempo de procesamiento y eran dif an ciles de congurar y administrar. Sin embargo en la actualidad, la activacin del accounting se suele realizar por o la ejecucin de un script en el arranque del sistema y la utilizacin de otro script para o o realizar las estad sticas durante la noche. Las principales ventajas que tiene este sistema es poder analizar qu procesos se e estn ejecutando en el sistema, as como los usuarios que los realizan, pudiendo ver si a algn usuario est ejecutando algn proceso en segundo plano o se ha producido algn u a u u ataque de saturacin contra un servidor. Consulte la documentacin del sistema operativo o o para ver cmo activar estos procesos de accounting. o

4.9

Actualizaciones de software

Ser conveniente dar algunas recomendaciones que permitan a los administradores dispona er de un sistema automatizado para la recogida, instalacin y noticacin de parches. o o IRIS-CERT 34

CAP ITULO 4. RECOMENDACIONES EN NIVEL DE SISTEMA 4.9. ACTUALIZACIONES DE SOFTWARE

Algunas de estas recomendaciones se pueden resumir en los siguientes puntos: Actualizacin de los sistemas, tan pronto sea posible, a la ultima versin facilitada o o por el fabricante. Aplicacin de todos los parches recomendados hasta el momento para esa versin o o del sistema operativo. Ser aconsejable la utilizacin de un script que se conectase a o al servidor FTP del fabricante concreto y aplicase los parches necesarios de forma automtica. a Mantenga correctamente parcheados los sistemas utilizando algunos de los siguientes mtodos: e 1. Parcheado incremental. Utilizacin de un script que peridicamente aplique o o los parches necesarios desde la ultima aplicacin, sin intervencin humana y o o con noticacin al administrador. o 2. Obtener una lista de parches necesarios (incremental), despus decidir qu e e parches son realmente necesarios para el sistema concreto y aplicarlos. Hay parches que aunque se recomiendan para una versin de un sistema operativo o concreto, si no se posee un determinado software o paquete instalado, no es necesario aplicarlo. Tambin ocurre al contrario, hay parches necesarios para e una determinada versin de software instalado que no se incluyen en los parches o recomendados para esa versin del S.O. o Para aquellos administradores que dispongan de mquinas Solaris, se puede obtena er un sistema de recogida automtica de parches en: a http://www.um.es/alfonso/

IRIS-CERT

35

CAP ITULO 5. RECOMENDACIONES PARA USUARIOS FINALES

Cap tulo 5 Recomendaciones para usuarios nales5.1 Introduccin o

Los administradores de red preocupados por la seguridad de sus sistemas deben estar continuamente informados de las nuevas versiones de los productos instalados en sus mquinas. Pero no slo los profesionales deben preocuparse de estos detalles, los usuara o ios nales tambin se pueden ver afectados por mltiples problemas si no actualizan su e u software. Muchos pueden pensar que el problema de la seguridad slo atae a los admino n istradores, informticos y profesionales del sector: nada ms lejos de la realidad. El a a usuario nal tambin debe preocuparse por la integridad de su sistema domstico. e e Desde el clsico antivirus, perfectamente actualizado, hasta el propio navegador, a hay programas imprescindibles dentro del PC y que deben actualizarse con regularidad. George Guninski y Juan Carlos Cuartango descubren continuamente nuevos fallos de seguridad para Windows que dejan los datos del disco duro accesibles a travs del e navegador. Una conguracin incorrecta del sistema operativo puede dejar abierto el sistema o a cualquier intruso. Un virus puede inutilizar todo nuestro ordenador, o un troyano puede desvelar todas nuestras cuentas de acceso a Internet. Por todo ello, la seguridad tambin e afecta a los usuarios domsticos. e En esta seccin, vamos a dar unas gu bsicas de seguridad para distintos o as a sistemas operativos dirigidas a los usuarios nales.

5.2

Gu Bsica de Seguridad para Windows 95/98/ME a a

Windows 95/98/ME son sistemas operativos que estn principalmente diseados para a n trabajar como clientes, por lo que su uso y conguracin ser ms facil que cuando o a a IRIS-CERT 36

CAP ITULO 5. RECOMENDACIONES PARA USUARIOS FINALES 5.2. GU BASICA DE SEGURIDAD PARA WINDOWS 95/98/ME IA

hablamos de un servidor (Linux, Windows NT/2000, etc.), pero no los libera de que tengan serios problemas de seguridad. Aunque ya lo hemos citado en el apartado de servidores NetBios, no vendr mal a repetir una frase que resuma la capacidad de Windows 95/98/ME en red: Recomendamos, con toda rotundidad, que Windows 9x/ME se considere comprometido desde el mismo momento en que se arranca. Ninguna versin de Windows 9x/ME o debera ser jams utilizada en cualquier ordenador de una red donde algn recurso necesite a u ser asegurado. No debemos olvidar, que al tener un equipo conectado a la red de una institucin, o la persona responsable de ese equipo es, as mismo, el responsable de la seguridad del mismo. Si un hacker se cuela en ese equipo y ataca, por ejemplo, a un equipo de la NASA, usted tendr parte de responsabilidad por el hecho de que el ataque provenga de a su mquina. a Este documento pretende dar unas recomendaciones sobre la conguracin y uso o adecuado que debemos hacer de nuestro ordenador cuando tenemos instalado Windows 95/98/ME.

5.2.1

Seguridad en red

Si tenemos el PC con Windows conectado a una red, lo ms probable es que tengamos a congurada la red para Trabajo en Grupo de Microsoft. Esta red nos permite intercambiar informacin entre los distintos ordenadores que integran la red, de manera que podamos o compartir recursos (directorios, impresoras, etc...) para que el resto de los equipos tengan acceso a ellos. Si esto es as deberemos tener en cuenta algunas medidas de seguridad: , 1.No comparta recursos si no es necesario. 2.Si necesita compartirlos, hgalo siempre con una buena contrasea y asegures a n e de que el recurso se comparte con las personas que lo necesitan y no ste accesible para e todo el mundo. 3.Siempre que sea posible, comprtalos como de slo lectura. As evitar que, a o a accidentalmente o por maldad, le borren informacin o le llenen el disco duro escribiendo o en el directorio compartido. 4.NUNCA comparta su disco duro con privilegios de escritura ni siquiera con contrasea. Aunque comparta con contrasea, hay programas que realizan diversos tipos n n de ataque (de fuerza bruta, diccionario, etc..) hasta que dan con la contrasea correcta. n Un hacker tiene todo el tiempo del mundo para probar, y Windows no le avisa que que lo est haciendo. a En general, le recomendamos que no comparta informacin importante de forma o permanente por este mtodo, pues no proporciona demasiada seguridad. e

IRIS-CERT

37


5.2.2

Antivirus, virus y caballos de troya.

Uno de los problemas ms graves de seguridad en los Windows son los virus y ultimamente a los troyanos: Virus. Son programas hechos por alguien y su funcin es muy diversa, pero o bsicamente todos tienen la capacidad de reproducirse y una estrategia de propagacin. a o Lo ms peligroso del virus es su payloado efecto, que puede ir desde mostrar una pelotita a rebotando en los bordes de la pantalla hasta el formateo del disco. Caballos de Troya. Son programas que tras una funcin aparentemente inocente o encierran en su interior otra funcin. Por ejemplo, un troyano t o pico puede presentarnos una pantalla igual a aquella en la que tenemos que escribir nuestro login y nuestra contrasea. Cuando los introduzcamos, los almacenar. Lamentablemente los troyanos en n a Windows estn muy de moda desde que aparecieron los ya famosos BackOrice o Netbus, a que tras instalase en el equipo, permiten el acceso y control remoto del ordenador desde Internet. Peridicamente aparecen ms troyanos de este tipo. o a Algunas soluciones para evitar este tipo de problemas son: 1. Antivirus. Buscan virus (y troyanos) en nuestro ordenador y los eliminan. En la actualidad muchos no slo se limitan a buscar en nuestro disco duro y memoria, o sino tambin en los mensajes que nos llegan por correo o los que nos bajamos de e Internet. Sin embargo, la ecacia de un antivirus depende de su actualizacin, por lo o que es important simo actualizarlo al menos una vez al mes. Diariamente aparecen en Internet decenas de virus que podrn atacarnos hasta que, primero, los antivirus a los detecten, y segundo, nosotros actualicemos el antivirus en nuestro PC. Por lo tanto, un antivirus no protege totalmente contra los virus nuevos, por lo que es necesario tomar otro tipo de medidas: 2. Si le llega un ejecutable por correo que no haya solicitado, NO LO EJECUTE, incluso aunque venga de una persona conocida. Los ultimos virus como el conocido Melissa usaban la agenda del equipo infectado para mandar correos con el virus contenido en un gracioso chero adjunto. Lo ms recomendable es borrarlo (si no a lo ejecuta no le infectar) o en todo caso, comprobar si el remitente realmente se lo a ha enviado conscientemente. En caso contrario, brrelo denitivamente. o 3. Abra los documentos de Oce (Word, Excel...) sin macros: si cuando abre un chero de este tipo, le avisa que el chero tiene macros, bralo sin macros; probablemente a sea un virus.

5.2.3

Algunos apuntes ms a

Windows 9x/ME no es un sistema operativo que se hiciera pensando en la seguridad y al margen de la red debemos tener en cuenta algunas cosas ms: a Vigile el acceso f sico a su equipo. Si alguien tiene acceso a su PC, puede encender el ordenador y ya tendr a su disposicin toda la informacin que en l est contenida. a o o e a IRIS-CERT 38


Windows no provee ningn mecanismo para validar usuarios, para conseguir esto, deberu emos recurrir a software de terceros. La contrasea que Windows nos pide al arrancar no es ninguna medida de sen guridad: con pulsar Cancelaro la tecla ESC entraremos igualmente. Por tanto, cierre las puertas con llave cuando se ausente, no permita que nadie desconocido se siente en su PC, etc. Su Ordenador Personal debe ser Personal. Aunque tericamente Windows es un o sistema operativo multitarea y multiusuario, esto no es del todo cierto. En realidad es ms un entorno monousuario, ya que no distingue realmente entre usuarios. Por eso es a totalmente desaconsejable compartir un PC entre varias personas. Cualquiera por error o maldad puede ver, modicar o borrar sus datos.

IRIS-CERT

39

CAP ITULO 6. GU BASICA DE SEGURIDAD DE WINDOWS NT IA

Cap tulo 6 Gu bsica de seguridad de a a Windows NT6.1 Introduccin o

Windows NT fue, segn Microsoft, diseado y desarrollado con la seguridad en mente; u n por lo tanto, podr amos pensar, no tengo que preocuparme de su seguridad. Esto es falso. Lo primero es que ningn programa nos va dar solucin a la seguridad denitiva y u o total (y el que lo prometa miente). Todos tienen fallos y vulnerabilidades que para cuando son parcheados, el programa ser tildado de obsoleto. Lo segundo es que la seguridad de a un sistema depende en gran medida de nuestras pol ticas y de la conguracin del sistema. o Esta gu trata las recomendaciones de conguracin que se deben tener en cuenta a o si est usando Windows NT. No es objetivo de esta gu ensearle a usar Windows a a n NT, aunque s se hace una pequea introduccin de los conceptos bsicos para unicar n o a trminos. e

6.26.2.1

Conceptos Bsicos aDominio

Es un grupo lgico de mquinas que comparten cuentas de usuarios y seguridad de los o a recursos. Un dominio est integrado por una mquina NT servidor de dominio que ada a ministra las cuentas y recursos del dominio en cuestin, y/o servidores y/o estaciones o de trabajo. Los usuarios de un mismo dominio tendrn un inicio de sesin unico en el a o servidor del dominio para acceder a los recursos de cualquier parte de la red, una cuenta unica para acceder a las mquinas del dominio, etc. a

IRIS-CERT

40

CAP ITULO 6. GU BASICA DE SEGURIDAD DE WINDOWS NT IA 6.2. CONCEPTOS BASICOS

6.2.2

Cuentas de usuarios

En las cuentas de los usuarios se establecen datos como el propietario de la misma, contrasea de acceso, localizacin de su directorio de inicio de sesin, grupo al que pertenece, n o o etc. Windows NT distingue las cuentas locales y las cuentas de dominio: Cuenta local de usuario: pertenecen a una unica estacin Windows NT. El proced o imiento de login de las mismas se valida en una base de datos local de la estacin. o La herramienta administrativa de la estacin para crearlas, modicarlas, bo

Date post:	09-Jul-2015
Category:	Documents
Upload:	manuel-sotelo
View:	75 times
Download:	0 times

Recomendaciones PSI

Documents