Recomendaciones de seguridad

Chelo Malagon Poyato (chelo.malagon@rediris.es) Francisco Monserrat Coll (francisco.monserrat@rediris.es) 14 de julio de 1999. versi on 0.0.2

 Indice General
1 Introduccion 2 Recomendaciones Generales 3 Seguridad a nivel de Red 3.1 Filtrado de paquetes . . . . . . . . . . . . . . . . . . 3.2 Conguraci on de las pilas TCP/IP en equipos nales 3.3 Monitorizaci on de router y equipos de acceso . . . . . 3.4 Separaci on de las redes y ltros anti-sning . . . . . 4 6 8 8 14 14 15 16 16 16 17 18 20 20 21 22 22 23 24 24 25 25 26 27

. . . .

. . . .

. . . .

. . . .

. . . .

4 Recomendaciones a nivel de sistema 4.1 Conguraci on de equipos Unix . . . . . . . . . . . . . . . 4.1.1 Actualizaci on y control de bugs . . . . . . . . . . 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 del inetd . . . . . . . . . . 4.2.2 Servicios dependientes de RPC . . . . . . . . . . 4.2.3 Servicios arrancados en los scripts de inicializaci on sistema operativo . . . . . . . . . . . . . . . . . . 4.3 POLITICA DE PASSWORDS . . . . . . . . . . . . . . . 4.3.1 Passwords d ebiles . . . . . . . . . . . . . . . . . . 4.3.2 Cuentas sin password o passwords por defecto. . . 4.3.3 Passwords reusables . . . . . . . . . . . . . . . . . 4.4 POL ITICA DE CUENTAS . . . . . . . . . . . . . . . . . 4.4.1 Administraci on . . . . . . . . . . . . . . . . . . . 4.4.2 Cuentas especiales . . . . . . . . . . . . . . . . . 4.4.3 Usuario root . . . . . . . . . . . . . . . . . . . . . 1

. . . . . . . . . . . . . . del . . . . . . . . . . . . . . . . . .

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

4.5

4.6

4.7

4.8 4.9

Conguraci on de servicios m as usuales . . . . 4.5.1 Conguraci on del sistema de correo . . 4.5.2 Conguraci on del DNS . . . . . . . . . 4.5.3 Conguraci on de los servidores WWW 4.5.4 Conguraci on de los servidores FTP . 4.5.5 Servidores de cheros . . . . . . . . . . Monitorizaci on de logs . . . . . . . . . . . . . 4.6.1 Conguraci on . . . . . . . . . . . . . . 4.6.2 Particularidades . . . . . . . . . . . . . 4.6.3 Uso desde programas . . . . . . . . . . 4.6.4 Rotaci on de logs . . . . . . . . . . . . 4.6.5 Otros aspectos relacionados . . . . . . Comprobaci on de integridad . . . . . . . . . . 4.7.1 Instalaci on de Tripwire . . . . . . . . . 4.7.2 Conguraci on de Tripwire . . . . . . . Procesos de accounting . . . . . . . . . . . . . Actualizaciones software. . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

27 27 29 30 30 31 33 34 35 35 36 36 37 37 38 39 40 41 41 42 42 43 44 45 45 45 45 46 46 47 48 48 49

5 Recomendaciones para usuarios nales. 5.1 introducci on . . . . . . . . . . . . . . . . . . . . 5.2 Gu a B asica de Seguridad para Windows 95/98 5.2.1 Seguridad en la Red . . . . . . . . . . . 5.2.2 Antivirus, virus y caballos de troya. . . . 5.2.3 Algunos apuntes m as . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

A Informacion de Seguridad en Internet A.1 Listas de distribuci on . . . . . . . . . . . . . . . . A.1.1 Listas de RedIRIS. . . . . . . . . . . . . . A.1.2 Otras . . . . . . . . . . . . . . . . . . . . . A.2 Boletines . . . . . . . . . . . . . . . . . . . . . . . A.3 Areas de Documentaci on . . . . . . . . . . . . . . A.4 Sitios de Hackers. . . . . . . . . . . . . . . . . . . A.5 Herramientas y Software de Seguridad . . . . . . A.6 Avisos de seguridad, parches, etc.. de empresas de B contribuciones

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software .

. . . . . . . .

C Registro de Cambios C.0.1 Versi on 0.0.2 C.0.2 Versi on 0.0.1

50 . . . . . . . . . . . . . . . . . . . . . . . 50 . . . . . . . . . . . . . . . . . . . . . . . 51

Cap tulo 1 Introduccion

Cada vez son m as frecuentes los incidentes en los que se ven involucradas las instituciones aliadas a RedIris. El tiempo necesario para la atenci on de estos incidentes es cada vez mayor, ya que suelen involucrar a varias instituciones y muchas veces lo u nico 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 m as f acil obtener informaci on sobre vulnerabilidades de un equipo o sistema operativo, pudiendo atacar con facilidad y total impunidad equipos situados en cualquier organizaci on . Adem as, son cada vez m as los equipos conectados permanentemente a Internet que no disponen de un responsable de administraci on y gesti on, y que est an congurados por defecto para ofrecer una serie de servicios que no se suelen emplear. Estos motivos nos han llevado a plantear unas recomendaciones generales de seguridad, al igual que se van a plantear en otras areas, para tratar de limitar el n umero y alcance de estos incidentes. Somos conscientes de que estas recomendaciones no se podr an implantar en su totalidad, que llevar an algo de tiempo y que se deber an debatir antes de ser de uso com un en RedIris, pero esperamos que este borrador aporte su granito de arena a este proyecto. No creemos que la seguridad tenga que estar jamente indicada como perteneciente a un area determinada dentro de los servicios inform aticos de las organizaciones, sino quepr acticamente depende de todos los niveles de servicio. Nosotros a la hora realizar este borrador lo hemos clasicado en diversos niveles: 4

Directivas generales: Lo primero que creemos que se hecha en falta en gran parte de las organizaciones aliadas son unas directivas generales sobre seguridad, indicando a los usuarios internos y externos de la organizaci on cuales son los servicios y recursos que se est an ofreciendo, los m etodos de acceso, etc, y hasta formas de organizaci on de los servicios que proporcionen m as seguridad a las organizaciones. Seguridad a nivel de Red: En esta secci on trataremos sobre todo las medidas para evitar los ataques desde el exterior de una organizaci on, comentando los ltros que se deber an instalar en los routers externos de las mismas para evitar diversos ataques t picos que se producen. Seguridad a nivel de Sistema: Comentaremos diversos aspectos de conguraci on de los equipos, centr andonos sobre todo en aquellos equipos multiusuario (equipos de correo, servidores de cheros, etc).

Cap tulo 2 Recomendaciones Generales

En esta secci on trataremos aspectos generales organizativos que creemos pueden ayudar a la hora de aumentar la seguridad de las instituciones aliadas. El primero de estos aspectos, que creemos que se hecha 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, obligaciones, sanciones, etc en los que pueden incurrir los usuarios de las mismas. En las p aginas del CERT (http://www.rediris.es/cert/docs/poliseg.es.html) se indican los aspectos que deber a contemplar una pol tica de seguridad. En organizaciones peque nas todav a es frecuente emplear el mismo equipo como 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 organizaci on ser an f acilmente evitables si los mencionados servicios de Internet estuvieran instalados en un equipo al que s olo tuvieran acceso un grupo reducido de usuarios. Otro aspecto en el que creemos que se debe hacer un enfasis especial es en la denici on de los puntos de contacto de cada organizaci on. NO EXISTE ahora mismo en muchas instituciones un responsable denido para el area de seguridad, o incluso una direcci on de correo a la que se pudieran enviar los avisos y noticaciones de seguridad. Por lo tanto nos parece urgente el que exista un alias de correo, redirigido despu es a cuentas de usuarios nales, para poder contactar con los responsables de seguridad de cada instituci on, al igual que debe existir el alias de correo postmaster para tratar los asuntos 6

relacionados con el correo electr onico. En aquellas organizaciones en las que por su complejidad interna existan varios responsables de area, es evidente que tambi en deber an contar con este tipo de direcci on, as se evitar a tener que contactar con el PER de una instituci on v a telef onica para advertirle de un incidente, y que este lo tenga que reenviar al responsable de un equipo, el cual desp ues vuelve a noticarlo al PER, por lo que al nal no existe un seguimiento real del incidente. Si una organizaci on delega en un grupo la gesti on de los servicios de comunicaciones para una secci on, es l ogico pensar que el personal de RedIris tiene que conocer esta situaci on para poder contactar con los responsables de este departamento cuando sea preciso. Por u ltimo habr a que destacar las dicultades que est an surgiendo en las instituciones que disponen de aulas o espacios de uso compartido, desde donde surgen ataques de denegaci on de servicio y barridos de puertos y redes hac a otras localizaciones, sin que muchas veces exista un control sobre qui en ha sido el usuario que ha realizado la acci on. Creemos que el acceso a estas instalaciones debe realizarse de una forma m as controlada.

Cap tulo 3 Seguridad a nivel de Red

Los ataques a nivel de red siguen siendo bastante frecuentes. Aunque las pilas TCP/IP de los distintos sistemas operativos son cada vez m as robustas, todav a son frecuentes los ataques de denegaci on de servicio en servidores NT y Unix debidos al empleo de generadores de datagramas IP err oneos o complicados de procesar. Es tambi en frecuente el empleo de herramientas automatizadas de escaneo y comprobaci on de vulnerabilidades en redes, as como la utilizaci on de programas especif cos que explotan una determinada vulnerabilidad de un servidor o servicio concreto para atacarlo. En esta secci on vamos a tratar sobre todo las medidas que creemos que se deben establecer en las organizaciones a nivel de ltrado de diversos protocolos en los routers de acceso, para as evitar el acceso desde fuera a estos servicios. Estas medidas no ser an efectivas contra ataques internos, salvo que se apliquen medidas internas concretas en aquellas organizaciones que tienen un direccionamiento a nivel de red plano para su red, pero permitir an como m nimo reducir ciertos problemas como el SPAM o los ataques contra servicios bien conocidos como NFS, NetBios, etc. Adem as permitir an que incluso si los usuarios nales activan servicios en sus m aquinas, estos no ser an accesibles desde el exterior, evitando as m ultiples problemas.

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 defectu8

osos hace imprescindible el uso de ltros a nivel de red, que permitan a una organizaci on restringir el acceso externo a estos servicios. De esta forma, s olo aquellos servicios que deban estar accesibles desde fuera del area local ser an permitidos a trav es de ltros en los routers. Adem as es importante que estos ltros determinen las condiciones de acceso a los servicios permitidos. Aunque el ltrado es dif cil de implementar correctamente, queremos dar algunos consejos que ayudar an a las organizaciones a implementar sus propios ltros en funci on a sus necesidades y a su topolog a de red concreta. En particular, se recomienda encarecidamente que se ltren los siguientes servicios si no es necesario su acceso desde fuera de una organizaci on concreta:

Nombre echo systat netstat chargen SMTP domain bootp tftp

Puerto 7 11 15 19 25 53 67 69

link supdup sunrpc NetBios news

87 95 111 137-139 144

snmp xdmpc exec login shell bi who

161 177 512 513 514 512 513

syslog uucp

514 540

route openwin NFS

520 2000 2049

tipo de conexion Servicio tcp/udp eco: Devuelve los datos que se reciben tcp Informaci on del sistema tcp Informaci on sobre la red tcp/udp Generador de caracteres continuo tcp Puerto de correo tcp/udp Servidor de Nombres (DNS) udp Arranque de estaciones remotas sin disco udp Arranque de equipos remotos, carga de conguraciones udp udp tcp/udp Servicio de RPC (portmapper) udp/tcp Servicios NetBios sobre TCP/IP tcp Servidores de News, deben estar ya ltrados en todos los routers de las organizciones aliadas a rediris udp Gesti on remota de equipos mediante snmp upd tcp Ejecuci on remota de comandos (rexec) tcp Acceso remoto a un sistema (rlogin) tcp Shell remoto udp udp Informaci on sobre los usuarios que hay conectados en un equipo remoto udp Almacenamiento de los logs de los sistemas en remoto tcp Env o de cheros y men10 sajes mediante uucp, actualmente en desuso udp Informaci on sobre enrutamientos tcp tcp/udp Sistema de cheros remotos

CHARGEN y ECHO Puertos 11 y 19 (TCP/UDP) Es muy importante para evitar ataques de denegaci on de servicio por puertos UDP (http://www.cert.org/advisories/CA-96.01.UDP service denial.html) , ltrar a nivel de router o rewall los servicios chargen y echo y en general todos los servicios UDP que operen por debajo del puerto 900 con exepci on de aquellos que se necesiten impl citamente. Transferencias de zona DNS Puerto 53 (UDP/TCP) Es necesario ltrar el acceso desde el exterior a todos los equipos excepto a los servidores de DNS primarios y secundarios establecidos en una organizaci on.1 TFTPD Puerto 69 (UDP) En general cualquier servicio UDP que responde a un paquete de entrada puede ser v ctima de un ataque de denegaci on de servicio (DoS). Un acceso no restringido al servicio TFTP permite a sitios remotos recuperar una copia de cualquier chero wordreadable, entre los que se pueden incluir cheros cr ticos como cheros de conguraci on de routers y cheros de claves. Es por ello, que aquellas organizaciones que no necesiten usar este servicio deber an ltrarlo y aquellas que necesiten usarlo, lo conguren adecuadamente teniendo en cuenta las medidas de seguridad a nivel de aplicaci on. Comandos r de BSD UNIX Puertos 512, 513 y 514 (TCP) Los comandos r incrementan el peligro de que sean interceptados passwords en texto plano cuando se presenta un ataque utilizando sniers de red, pero lo m as importante es que son una fuente bastante frecuente de ataques y vulnerabilidades. Filtrando los puertos 512, 513 y 514 (TCP) a nivel de red se evitar a que personas ajenas a su organizaci on puedan explotar estos comandos, pero no lo evitar a a personas de su propia organizaci on. Para ellos, aconsejamos el uso de otras herramientas como el ssh, uso de versiones seguras de los comandos r (WietseVenemas logdaemon), uso de tcp wrapper para proporcionar una monitorizaci on del acceso a estos servicios, etc... SunRPC y NFS Puertos 111 y 2049 (TCP/UDP) Filtrar el tr aco NFS evitar a que sitios ajenos a su organizaci on accedan a sistemas de archivos
Consultar la documentaci on relativa a la conguraci on del servidor de DNS en la seguridad a nivel de sistemas
1

11

exportados por m aquinas de su red, pero como ocurr a en el caso anterior, no se evitar a que se realicen ataques desde dentro del area local. La mayor a de las implementaciones NFS emplean el protocolo UDP, por lo que es posible, en algunos casos, el env o de peticiones NFS falsicando la direcci on origen de los paquetes (IP-spoong http://www.cert.org/advisories/CA-95.01.IP.spoong.attacks.and.hijacked.terminal.connecti http://www.cert.org/advisories/CA-96.21.tcp syn ooding.html ), es por tanto muy aconsejable la instalaci on de las u ltimas versiones actualizadas de los servidores y clientes NFS que 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 organizaci on pasen a una estafeta central y que sea desde esta desde donde se distribuya el correo internamente. Este tipo de ltros permitir an, que no existan puertos 25 descontrolados dentro de una organizaci on que suelen ser foco de importantes problemas de seguridad, adem as de un logueo centralizado de informaci on, que podr a ayudar a la hora de detectar el origen de intentos de ataque. El administrador del sistema o el responsable de seguridad s olo se tendr a que preocupar de tener actualizado este servidor para evitar ataques aprovechando vulnerabilidades o fallos bien conocidos en los mismos. Para obtener m as informaci on sobre dise no de un servicio de correo electr onico puede consultar la siguiente p agina http://www.rediris.es/mail/coord/sendmail/estafeta.html. NetBios. Puertos 137, 138 y 139 (UDP/TCP) Estos puertos, son los empleados en las redes Microsoft (Windows para trabajo en Grupo, Dominios NT y LANManager), tanto para la autenticaci on de usua rios como para la compartici on de recursos (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 direcci on de Internet. SNMP Puerto 161 (UDP/TCP) Muchos equipos disponen en la actualidad de gesti on SNMP incorporada. Dado que estas facilidades de gesti on no suelen necesitar accesos externos, se deben establecer ltros a nivel de router que eviten que se pueda obtener informaci on sobre los dispositivos (routers, hubs, swithes) desde el exterior o incluso se gestionen los equipos en remoto. 12

Filtros de datagramas IP Por otro lado, para prevenir los ataques basados en bombas ICMP, se deben ltrar los paquetes de redirecci on ICMP y los paquetes de destino ICMP inalcanzables. Adem as, y dado que actualmente el campo de opciones de los paquetes IP no son casi utilizados se pueden ltrar en la mayor a de las organizaciones los paquetes de origen enrutado. Si una organizaci on determinada no necesita proveer de otros servicios a usuarios externos deber an ltrarse igualmente esos otros servicios. Por ejemplo, ltrar conexiones POP e IMAP a todos los sistemas excepto a los que deben ser accesibles desde el exterior (la misma regla es aplicable a otros servicios como www, smtp , ntp, etc...). Con el protocolo IP que actualmente est a mayoritariamente en uso, es casi imposible eliminar el problema del IP-spoong. Sin embargo, se pueden tomar algunas medidas que reducir an el n umero de paquetes de este tipo que entran y existen en una red local. Actualmente, el mejor modo de realizar esto es restringir la entrada en el interface externo (ltro de entrada), no permitiendo que un paquete entre a nuestra red si tiene la direcci on origen de la red interna. De la misma forma, se deber an ltrar los paquetes salientes que tengan una direcci on origen distinta a la correspondiente a la red interna (con esto u ltimo se evitar an ataque de IP-spoong originados desde nuestra red). La combinaci on de estos dos ltros prevendr an que un atacante de fuera de nuestra red env e paquetes simulando hacerlo desde dentro de nuestra red, as como que paquetes generados dentro de nuestra red parezcan haber sido generados fuera de la mismas. En la entrada al interface interno de una organizaci on se deber an ltrar los bloques de paquetes con las siguientes direcciones: Redes Broadcast: Para evitar que su organizaci on sea utilizada como intermediaria en un ataque de denegaci on de servicio de tipo smurf (http://www.cert.org/advisories/CA-98.01.smurf.html) es necesario bloquear el tr aco ICMP a las direcciones de broadcasts (bits dedicados a hosts todos a uno) y de red (bits dedicados a hosts todos igualesa cero). Su area local. N umeros de red privada reservados: No se debe recibirtr aco desde o hacia las siguientes direcciones a trav es de los routers puestoque se trata de redes privadas reservadas: 13

 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

Conguraci on de las pilas TCP/IP en equipos nales

Gran parte de los ataques de denegaci on de servio (DoS) se producen debido a fallos en las implantaciones de las pilas TCP/IP en los sistemas operativos. As son famosos los ataques de denegaci on de servicio mediante el env o de datagramas IP con informaci on ICMP err onea, que provocan el reseteo del equipo, o los ataques mediante SYN y FIN ood, impidiendo el normal funcionamiento de los servidores. En la medida de lo posible, se debe revisar la conguraci on de estos sistemas, en especial la conguraci on de reenv o de datagramas IP (ip-forwarding), que permite que un sistema funcione como un router, asi como deshabilitar el empleo de datagramas IP con el campo de enrutamiento fuente activado.

3.3

Monitorizaci on de router y equipos de acceso

Hace algunos a nos era frecuente el empleo de equipos de acceso (servidores de pools de modems, router de acceso, etc.) para la conexi on a los servidores de las organizaciones desde el domicilio de los usuarios. Con la aparici on de Infov a y los proveedores de acceso a Internet, el uso de estos sistemas ha ido disminuyendo, aunque siguen estando operativos en muchas instituciones. Tanto estos equipos como los routers de interconexi on y cualquier dispositivo (switch, concentrador ATM, etc. que disponga de esta opci on), deben estar monitorizados. 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 conexi on no autorizados y las ca das que se producen en estos equipos. Esta monitorizaci on es muchas veces muy sencilla de establecer y la recepci on y almacenamiento de los logs no requiere mucha carga del procesador. 14

En instalaciones con mucho equipamiento de red puede ser recomendable el empleo de alguna herramienta de monitorizaci on SNMP de los equipos, de forma que las incidencias que vayan ocurriendo sean noticadas en tiempo real a los administradores de la red. Es necesario la instalaci on de versiones recientes de los sistemas operativos de estos equipos, puesto que muchas instalaciones disponen de versiones antiguas susceptibles a ataques de denegaci on de servicio que pueden ser f acilmente evitables si se actualizan peri odicamente los sistemas.

3.4

Separaci on de las redes y ltros anti-sning

Gran parte de los ataques que se producen son debidos a la obtenci on de las claves empleando un programa de sning en una red ethernet. En muchas ocasiones, la separaci on de las redes y el empleo de switches y routers hace falta para permitir una mayor descongesti on del tr aco interno de una organizaci on, pero adem as es muy necesario para lograr una mayor seguridad dentro de esta. Las salas de acceso general (bibliotecas, salas de practicas comunes, aulas de acceso, etc.) deben estar separadas mediante puentes o switches del resto de la red, para evitar que se puedan obtener, mediante sniers, passwords de acceso de otros grupos de usuarios. En general los equipos que necesiten el empleo de sistemas inseguros de transmisi on de claves deber an estar aislados de la red, de forma que estas claves no se transmitan por toda la organizaci on. Hay que considerar adem as las posibilidades de gesti on y consola remota que disponen muchos hubs y switches, hay que cambiar las claves por defecto que suelen tener estos equipos y deshabilitar la gesti on remota de estos si no se va a hacer uso de ella. (snmp, consolas remotas, servidores de HTTP ). Consultar la ponencia presentada en los grupos de trabajo de Barcelona Implantaci on de un sistema de securizaci on global a nivel de red, (http://www.rediris.es/rediris/boletin/46-47/ponencia8.html). Hay que indicar que existen ya versiones de snier para los sistemas Windows, siendo posible muchas veces la obtenci on de password de acceso a sistemas de cheros remotos de Netbios, pudiendo modicar f acilmente cualquier aplicaci on existente en estos servidores. Adem as en muchos servidores samba el password de conexi on de Windows coincide con la clave del usuario, por lo que estas medidas anti-sning se deben aplicar a cualquier protocolo que circule por la red. 15

Cap tulo 4 Recomendaciones a nivel de sistema

Las conguraciones establecidas por defecto en muchos sistemas operativos no son las m as adecuadas desde el punto de vista de seguridad. Adem as el desconocimiento y desinformaci on de los responsables de estos equipos es motivo frecuente de problemas de seguridad. En este apartado vamos a comentar diversas medidas que se deber an adoptar en los sistemas para evitar gran parte de estos problemas.

4.1
4.1.1

Conguraci on de equipos Unix

Actualizaci on y control de bugs

Los ataques con m as exito en los sistemas inform aticos se basan en aprovechar vulnerabilidades en el software que no ha sido actualizado a la u ltima versi on facilitada por el fabricante, o que no ha sido parcheado convenientemente. Esto afecta tanto al software de red de grandes m aquinas y sistemas operativos, como al software de PC de usuarios. Esta tarea es laboriosa porque supone mantenerse al d a de la evoluci on de los productos, as como conocerlos a fondo para poder congurarlos correctamente. La mayor a de los vendedores mantienen listas con los parches recomendados (Sun, IRIX, etc..). 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 v alida. El MD5 comprueba la integridad y

16

no alteraci on del paquete, y la rma PGP la autenticidad de su autor. Es muy importante estar al d a y revisar el software que se utiliza, especialmente aquel que tenga que ver con la conectividad a Internet, administraci on de servicios de Red, etc.. y actualizarlo o parchearlo con las u ltimas actualizaciones disponibles. A menudo no resulta buena idea utilizar la u ltima versi on disponible, sino la pen ultima, ya que al ritmo al que se lanzan nuevas versiones de productos, la u ltima, con casi toda seguridad, no habr a sido puesta a prueba en su fase de dise no ni ha sido sucientemente validada por los usuarios. A veces, merece la pena esperar un periodo de tiempo, aunque eso si, no con la primera versi on del producto. Por u ltimo, comentar que no es suciente con instalar la u ltima versi on o actualizaci on disponible, sino que es necesario congurarla convenientemente, de manera que se cierren los resquicios que puedan dejar las instalaciones por defecto. Esta correcci on es importante no s olo en los sistemas operativos, sino tambi en en el software en general.

4.1.2

Directivas generales

En esta secci on, daremos algunas ideas a los administradores sobre la conguraci on de los equipos Unix. Algunas de las directivas generales a al hora de congurar un sistema teniendo en cuenta la seguridad se pueden sintetizar en los siguientes puntos: Especial cuidado merece la presencia de archivos .rhosts y /etc/hosts.equiv, pues garantizan el acceso a la m aquina sin necesidad de autenticaci on. Si no es necesario el uso de comandos r(aconsejado en cap tulos anteriores insistentemente por IRIS-CERT), no se necesita la presencia de estos archivos al no ser una alternativa segura al telnet. Se recomienda usar clientes ssh, ampliamente descritos ya en este documento. Se pueden establecer qu e terminales son seguros, y por lo tanto desde qu e terminales se puede conectar el usuario root. En los terminales declarados como no seguros el usuario antes de llegar a ser root, necesitar a conectarse utilizando una cuenta sin privilegios en el sistema y despu es utilizar el comando supara cambiar a root, lo que a nade un nivel extra de seguridad. Desactivar IP forwarding y source routing. Es especialmente importante en el caso de estar usando una Sun como hosts basti on o como 17

dual-homed. Es importante deshabilitar la posibilidad de ejecuci on de c odigo en pila de usuario, lo que evitar a algunos problemas de buer-overow. En el caso de m aquinas Solaris lo podemos hacer incluyendo en el chero de especicaci on del sistema /etc/systemlas l neas: set noexec_user_stack=1 set noexec_user_stack_log=1 Evitar que el correo del root se almacene sin que sea leido por nadie. Para ello establecer un archivo .forwarden el home del root para redirigir el correo a una cuenta real en el sistema. As mismo, ser a necesario asegurarse que estos archivos, si existen en los directorios home de los usuarios, no ejecuten ning un comando. Desactivar la ejecuci on de comandos en los dispositivos montables por los usuarios. Separar las m aquinas de los usuarios de aquellas que ofrecen alg un servicio a la comunidad (servidores), y restringir en la medida de lo posible el acceso a las mismas. El administrador debe prevenirse de posibles escuchas en la red. Un snierescucha todo lo que pasa por una puerta ethernet, incluyendo passwords de cuentas de usuario, de superusuario, password de POP, etc.. Para evitarlo, se recomienda el uso del ssh (http://www.cs.hut./ssh/) u otros m etodos de encriptaci on de passwords. Revisar el path de la cuenta root en los cheros de inicializaci on (.login, .cshrc, .prole ...). El comando path o la variable de entorno PATH denen los directorios de b usqueda 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 m as vulnerable en la protecci on de archivos son los modos de acceso SUID y SGID. Se aconseja realizar frecuentemente una auditor a de los mismos, monitorizando los cambios, puesto que son cheros especialmente explotados por intrusos potenciales. Algunas sugerencias podr an ser: 18

 Los sistemas Unix/Linux proporcionan otras maneras de limitar el acceso a varios recursos del sistema a usuarios que no sean el usuario root. Facilidades como la cuotas de disco, recursos del sistema limitados y protecci on para los subsistemas restringiendo el acceso a las colas de procesos batch y de impresi on para los usuarios no autorizados. El servidor NFS hace registro de todos los cheros montados en /etc/mtab. Si no hay mas remedio que usar este servicio, se debe congurar lo m as restrictivo posible. En el chero /etc/exports se especica a qui en se exporta y c omo se exporta un sistema de cheros (read-only, sin permiso de escritura al root...). El comando showmountpermite vericar que el chero de conguraci on /etc/exports es correcto. Establecer en el /etc/prole el umask para los usuarios lo m as restrictiva posible (022, 033 o incluso 077). La m ascara del root debe ser 077. No usar Samba. Si es necesaria su utilizaci on, se debe parchear convenientemente este paquete porque es fuente de numerosos problemas. Tambi en se debe congurar lo m as restrictivo posible el chero /etc/smb.conf. Aseg urese de que todos los cheros que cuelgan del directorio /dev son cheros especiales y que del mismo modo no existen archivos especiales fuera de la estructura /dev. Considere eliminar el acceso a lectura de todos aquellos archivos que no necesiten tener dicho acceso. Tambi en es aconsejable revisar los cheros y directorios word-writables. Aseg urese de que el usuario root es el propietario de los directorios /etc, /usr/etc, /bin, /usr/bin, /sbin, /usr/sbin, /tmp y /var/tmp. Adem as, los directorios /tmp y /var/tmp deben tenet 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 y localizados en un directorio donde cada directorio en el path sea propiedad del usuario root. En este sentido, una pr actica general consistir a en examinar la protecci on de los cheros y

19

directorios antes y despu es de instalar software o de ejecutar utilidades de vericaci on. Es recomendable comparar las versiones que tienen en el sistema con una copia v alida de las mismas (por ejemplo del CD-ROM). Hay que tener especial cuidado con los backups, pues pueden contener cheros alterados o Caballos de Troya. Los Caballos de Troya pueden tener el mismo standard checksum y timestamp que la versi on original. Por esto, el comando de UNIX sum(1) y el timestamps asociado a los programas no es suciente para determinar si estos han sido reemplazados. El uso de cmp(1), MD5, Tripwire u otras utilidades para generar un checksum criptogr aco son sucientes para detectar estos caballos de troya.

4.2

FILTRADO DE SERVICIOS EN EQUIPOS UNIX

Para evitar riesgos innecesarios, se deben congurar TODAS las m aquinas de una organizaci on para que ofrezcan u nicamente los servicios que se tenga en mente ofrecer y no otros. Esto disminuir a considerablemente el riesgo a que estas m aquinas sean atacadas aprovechando servicios completamente descuidados y que en muchas ocasiones ni siquiera se es consciente de que se est an ofreciendo. Es necesario asegurarse de que no existen debilidades en los archivos de conguraci on de los servicios ofrecidos y que los servicios se ofrezcan s olo al conjunto de usuarios para los cuales se dise no .

4.2.1

Servicios dependientes del inetd

El archivo inetd.conf contiene una lista con todos los servicios que el demonio inetd1 invoca cuando recibe una petici on sobre un socket. 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
El proceso inetd es un superservidor congurable, empleado para escuchar en varios puertos simultaneamente y lanzar el programa adecuado para cada servicio. Para m as informaci on consultar las p aginas de manual de este comando
1

20

en la mayor a de los casos no son necesarios. Es necesario revisar este archivo con el n de comentar todos aquellos servicios que nos sean necesarios impl citamente y que en muchas ocasiones son causa de ataques y vulnerabilidades. Nuestra recomendaci on es la de comentar todos los servicios que se lanzan desde el inetd.conf anteponiendo un caracter #al principio de cada una de las l neas. Una vez hecho esto, se pueden descomentar (quitando el caracter #) aquellos servicios que sean necesarios en la m aquina concreta. Para que los cambios realizados en este archivo de conguraci on tengan efecto, es necesario resetear el proceso inetd . Puesto que en muchos casos, cuando se ofrece un servicio, este est a dirigido a un sector de la comunidad de Internet, es muy u til contar con alg un mecanismo que permita rechazar conexiones dependiendo de su origen o/y de su ident, y que proporcione adem as, una monitorizaci on del acceso. En este contexto, recomendamos la instalaci on del TCP WRAPPERS (http://www.rediris.es/cert/docs/wrappers.es.html), que se puede descargar en el FTP de RedIRIS. El tcp wrapper (tcpd) act ua de intermediario transparente en la conexiones TCP, a nadiendo un nivel extra de registro de conexiones, control de acceso y acciones congurables por conexi on.2

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 est an los servicios de cada procedimiento. Esta informaci on, se puede ver como usuario, con el comando rpcinfo -p, que implementa una llamada al procedimiento remoto dump. Si alguno de los servicios que aparecen al ejecutar este comando no son necesarios, ser a imprescindibble desactivarlos en los scripts de incializaci on del sistema, lugar desde donde son lanzados. 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 LinEn servidores que generan una carga elevada y que tienen su propio sistema de control de acceso y de logs no es necesario el empleo de de tcp wrapper
2

21

ux, portmap ya est a compilado de esta manera, por lo que el acceso se puede controlar directamente con los archivos hosts.allow y hosts.deny. En Solaris, se requiere compilar una versi on especial del rpcbind y linkarlo con la librer a libwrap.a (Solaris: /usr/local/lib/libwrap.a, Linux: /usr/lob/libwrap.a).

4.2.3

Servicios arrancados en los scripts de inicializaci on del sistema operativo

A parte de los servicios dependientes de RPC y de los dependientes del inetd, comentados con anterioridad, en el proceso de instalaci on del sistema operativo en una m aquina, se activan una serie de servicios por defecto desde el /etc/rc* (por ejemplo el smtp, o el domain) que en la mayor a de los casos no son necesarios. Si este es el caso, recomendamos que sean desactivados y que se modiquen los scripts de inicializaci on para que en subsiguientes arranques de la m aquina no se vuelvan a lanzar.

4.3

POL ITICA DE PASSWORDS

Sin duda, uno de los m etodos m as habituales usados por los hackers para comprometer un sistema es el robo de passwords. Robando un nombre de usuario y su password correspondiente, un intruso puede, reduciendo las probabilidades de ser detectado, ganar el acceso a un sistema, modicarlo y usarlo como lanzadera para atacar a otros sistemas. La mayor a de los sistemas no tienen ning un mecanismo de control de los passwords que utilizan sus usua rios y en la mayor a de los casos existe por lo menos un password en el sistema que puede ser f acil de descubrir, comprometiendo la seguridad del sistema completo. La protecci on de los passwords es uno de los principios m as importantes en seguridad, por lo que es necesario que las organizaciones posean una pol tica de passwords bien denida. Las t ecnicas utilizadas por los crackers para obtener passwords ajenos son muy 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 de password de una m aquina ajena, normalmente realiza una copia del mismo a otra m aquina y ejecuta programas crakeadores que son relativamente r apidos y que realizan ataques de fuerza bruta, de diccionario o h bridos sobre los passwords hallados. 22

A continuaci on daremos algunas directivas a tener en cuenta por los administradores de sistemas o responsables de seguridad para implementar una pol tica de passwords adecuada en sus organizaciones.

4.3.1

Passwords d ebiles

La primera directiva, y en nuestra opini on la m as importante, es desarrollar una gu as que ayuden a los usuarios a la hora de escoger passwords lo sucientemente robustos para que no sean vulnerables a los ataques de diccionario o de fuerza bruta que suelen realizar la mayor a de las utilidades dise nadas para crakear passwords. 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 est en relacionadas con el usuario (nombre de la mujer o marido, domicilio, fecha de nacimiento, etc...), utilizar passwords con una longitud m nima de 8 caracteres, etc... Informar a los usuarios de que no almacenen informaci on sobre su cuenta/password en archivos en texto claro en ning un sistema. Si se tiene m as de una cuenta en distintos sistemas no es aconsejable utilizar el mismo password en todas, pues si el password quedara comprometido en una m aquina, quedar a igualmente en el resto. Cuando se utiliza el servicio de nger (puerto 79 tcp/udp) para interrogar a un servidor, a menudo este revela m as informaci on sobre s mismo y sus usuarios de la que ser a deseable (el shell que est a utilizando cada usuario, su directorio home, el grupo al que pertenece, y lo que en este caso es m as importante, el nombre del usuario en la m aquina con lo que el atacante ya poseer a la mitad de la informaci on que necesita para entrar en un sistema). Debido a que adem as suele proporcionar informaci on sobre la hora del u ltimo login, un atacante podr a confeccionar patrones de trabajo de los distintos usuarios. En denitiva, se trata de informaci on demasiado valiosa para distribuirla sin control por lo que es aconsejable eliminar este servicio de las m aquinas si no es estrictamente necesario su uso.

23

 Utilizar con cierta frecuencia programas tipo crack para chequear la robustez de los passwords del sistema y de esta forma averiguar passwords d ebiles forzando el cambio de los mismos. Establecer un pol tica de cambio de passwords peri odicos (sobre todo en las m aquinas m as importantes y de cuentas privilegiadas). Adem as es aconsejable no reutilizar passwords antiguos.

4.3.2

Cuentas sin password o passwords por defecto.

Cambiar todos los passwords instalados por defecto en el proceso de instalaci on del sistema operativo. Escanear el chero de password per odicamente en busca de cuentas con UID igual a 0 (reservado para el usuario privilegiado root). Escanear el chero de passwords en busca de cuentas nuevas de las que no se tiene conocimiento y que en la mayor a de los casos son indicativo de intrusi on. No permitir la existencia de cuentas sin password. Eliminar cuentas de usuarios que se hayan dado de baja en la organizaci on y de cuentas que no se est en utilizando. Es aconsejable el uso de programas como el noshell (ftp://ftp.rediris.es/mirror/coast/tools/unix/noshell) que permiten al administrador obtener informaci on adicional sobre intentos de conexi on a cuentas canceladas o bloqueadas en una m aquina. Utilizando este mecanismo, cada intento de conexi on queda registrada, v a correo electr onico o syslog, dando informaci on sobre el usuario remoto, la direcci on IP, el d a y la hora del intento de login y el tty utilizado en la conexi on.

4.3.3

Passwords reusables

Reducir o eliminar la transmisi on de passwords reusables en texto claro sobre la red. De esta forma se evitar a que los passwords sean capturados

24

por lo que se denomina packet sniers.3 Utilizar one-time passwords (S/Key, Secure Net Key, Secure ID, etc...) para el acceso autenticado desde redes externas o para acceder a recursos sensibles como routers, servidor de nombres, etc... Si se trata de sistemas UNIX, recomendamos el uso de cheros shadow, o lo que es igual, un segundo chero que contiene las contrase nas cifradas y es s olo accesible por el usuario root, quedando el /etc/passwd con un asterisco en el lugar donde deber a aparecer las contrase nas cifradas. Si su sistema tiene la posibilidad de aplicar una serie de reglas en la introducci on de palabras clave, es aconsejable que lo utilice. Por ejemplo, en el caso de un sistema Solaris en el archivo /etc/default/passwd se pueden establecer algunos valores por defecto como son el n umero m nimo de caracteres que debe tener un password, el m aximo periodo de tiempo en el cual es v alido, el m nimo periodo antes de que el password sea cambiado, etc..

4.4

POL ITICA 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 password de cualquier usuario, o incluso tener privilegios de superusuario cambiando el UID a 0. Entre las recomendaciones que podemos dar para establecer una pol tica adecuada de cuentas y grupos en un sistema podemos destacar:

4.4.1

Administraci on

Del mismo modo que alentamos a las organizaciones para que posean una pol tica de password bien denida, es necesario que tambi en dispongan de un formulario para el registro de usuarios bien denido, donde se incluya una secci on, que deber a ser rmada por el beneciario aceptando las condiciones y responsabilidades que supone tener una cuenta
Herramientas de monitorizaci on y de la red que permiten leer toda la informaci on que circula por un segmento de la red, pudiendo as obtener las claves de acceso a las sesiones de terminal(telnet), ftp, http y servicios m as comunes
3

25

en el sistema. Se deber a contemplar tambi en la posibilidad de acreditaci on por parte de los mismos. Asegurarse de que existen copias de seguridad del area de disco de los usuarios siempre que esto sea posible y se dispongan de los medios para hacerlo. Considerar el agrupamiento de los directorios de los usuarios de una forma l ogica, especialmente si se plantea tener muchos usuarios en el sistema. Monitorizar los registro de logs en busca de comandos suno autorizados o fallidos. Comprobar frecuentemente los intentos de conexi on no autorizados. Establecimiento de una pol tica de asignaci on de cuotas a usuarios y grupos, as como la preparaci on de procedimientos de comprobaci on de los mismos con el n de controlar que ning un usuario sobrepase el l 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, muchos sistemas instalan cuentas para invitados por defecto, ser a pues necesario desactivar o eliminar del sistema este tipo de cuentas. Usar grupos espec cos para restringir qu e usuarios pueden utilizar el comando su. Comprobar el archivo de contrase nas del sistema una vez haya terminado el proceso de instalaci on del sistema operativo a n de asegurarse de que todas las cuentas predeterminadas tienen contrase nas v alidas o han sido desactivadas o eliminadas. Eliminar todas las cuentas que permiten u nicamente la ejecuci on de un comando (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 permitan 26

ning un tipo de escape de shell que pueda permitir acceder a un shell interactivo.

4.4.3

Usuario root

La contrase na root es especial, por lo que es necesario seleccionarla con cuidado, guardarla en lugar seguro y modicarla a menudo. Restringir el n umero de usuarios en el sistema que tienen acceso a esta cuenta. Evitar la existencia de archivos .rhosts en el directorio base del usuario root. Evitar la existencia del .en el path de b usqueda del usuario root y de los administradores. Hacer uso de paths completos para ejecutar comandos como root. Evitar el logueo en la red como root para as evitar la intercepci on del password en texto en claro, que dar a a un intruso acceso total al sistema.

4.5

Conguraci on de servicios m as usuales

En este apartado vamos a comentar la conguraci on de algunos de los servicios m as usuales que son ofrecidos por las organizaciones, sin entrar en detalle, pues estos temas ya se han debido tratar en los grupos de trabajo correspondientes.

4.5.1

Conguraci on del sistema de correo

El servicio de correo es uno de los m as f aciles de congurar en la actualidad, aunque parad ojicamente sigue siendo uno de los m as problem aticos a nivel de seguridad. En principio podemos clasicar los equipos, en funci on de su papel en la transferencia del correo en: Equipos de usuario : Sistemas que leen y almacenan localmente el correo de uno o varios usuarios. Estos equipos suelen ejecutar un lector 27

de correo o agente de usuario para obtener los correos. Suelen ser los Pcs con el 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 a que sean le dos desde los equipos de lectura de correo (agentes de usuario). Para ello suelen emplear el protocolo pop3 (puerto 110) y en algunos casos emplean IMAP (141). Para la recepci on de correo suelen ejecutar el programa sendmail en el puerto 25, aunque tambi en es posible emplear otros programas como smap/smapd del fwtk 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, adem as a nivel de router se debe ltrar en la organizaci on para que no se produzcan accesos por el puerto 25 nada m as que a los que est an denidos en el DNS como MX. Deben ejecutar el sendmail o similar escuchando cont nuamente en el puerto 25. La conguraci on de este servidor es crucial para el buen funcionamiento del servicio de correo, se debe instalar una versi on actual del programa sendmail (el suministrado en muchos S.O., salvo Linux o FreeBSD, suele ser bastante antiguo) y congurarlo adecuadamente para que no pueda ser empleado para la distribuci on de correo basura (SPAM). Consultar http://www.rediris.es/mail para m as informaci on sobre como congurar el servicio de correo en la organizaciones. En los equipos de almacenamiento, procurar que las cuentas de correo no est en vinculadas directamente a una cuenta del sistema, o que esta est e bloqueada salvo que sea necesaria. Evitar la circulaci on de las claves en claro mediante el uso de APOP, desactivar las cuentas de los usuarios que han dejado de pertenecer a la organizaci on, sustituyendo las cuentas por alias a sus nuevas direcciones de correo.

28

4.5.2

Conguraci on del DNS

El servicio de DNS es crucial para la conexi on a Internet. Sin embargo en muchas organizaciones no est a congurado adecuadamente. Como en el correo, la conguraci on de este servicio ha debido ser explicada en el grupo de trabajo correspondiente, sin embargo creemos que se debe destacar: 1. Tener una versi on actualizada del servidor de nombres: Es conveniente actualizar a una versi on actual del servidor. Las u ltimas versiones son m as seguras y permiten 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 monitorizaci on en los logs. 3. Denegar el acceso a las zonas a otros servidores: Es conveniente que los servidores de DNS est en congurados para permitir las transferencias de zona solamente a los servidores que est en denidos como secundarios, as se evita el que se pueda obtener informaci on sobre la topolog a y conguraci on de la red desde el exterior. 4. No poner conguraciones de equipos en el DNS: Es posible indicar en registros de DNS qu e sistema operativo, arquitectura hardware, e incluso qu e servicios se est an ejecutando. Esta informaci on se puede emplear para atacar desde fuera la organizaci on. 5. Conguraci on en los clientes: A nivel de ltrado de puertos con el tcpwrapper o listas de acceso, emplear nombres cualicados por completo y no s olo el nombre del equipo, para evitar que un equipo de otra organizaci on que se llama igual pueda tener acceso al sistema. 6. Aspectos generales de conguraci on: Como norma general, se debe cumplir: No se deben congurar los servidores de DNS para que reenv en las peticiones (forward) a equipos de RedIRIS. No se deben congurar DNS como secundarios de otra organizaci on, salvo autorizaci on explicita de la otra parte. 29

 A ser posible se deben tener dos servidores, primario y secundario, en una misma organizaci on y tener denido ambos equipos como servidores de nombres en la conguraci on de los equipos (resolver).

4.5.3

Conguraci on de los servidores WWW

Los equipos servidores WWW son susceptibles a varios tipos de ataques. Algunas medidas para evitarlos: 1. Dimensionar el equipo adecuadamente, para evitar que se produzcan ataques de denegaci on de servicio (DoS). 2. Instalar una versi on actualizada del servidor WWW. 3. Salvo que sea necesario, denegar el empleo de cgi-bin fuera de los empleados por los administradores, eliminar los cgi-bin de prueba, que suelen tener vulnerabilidades de seguridad, y no emplear extensiones (php, server-side include, servler de java, etc.) salvo que sean necesarios. 4. En caso de que los usuarios deban programar cgis, advertirles de los fallos m as comunes que pueden existir y como solucionarlos (ftp://ftp.cert.org/pub/techtips/cgimetacharacters). 5. No compartir las p aginas de los servidores mediante un sistema de cheros, emplear un sistema de mirror (wget o mirror) para realizar el intercambio de las p aginas.

4.5.4

Conguraci on de los servidores FTP

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 ser an: 1. Instalar una versi on del servidor actualizada, y able: Las versiones del servidor que vienen con los sistemas operativos comerciales suelen tener pocos par ametros de conguraci on, pero tambi en varios fallos de seguridad. A un en el caso de que no se vaya a emplear el equipo como servidor de FTP instalar una versi on actual de ProFTPd o WuFTPD, 30

que proporcionan bastantes opciones a la hora de congurar el n umero m aximo de conexiones, or genes de la conexi on,etc. 2. En caso de que no se emplee el servicio de FTP an onimo, deshabilitarlo. En caso de que se emplee, salvo que sea necesario no permitir que el usuario FTP tenga permisos de escritura en ning un directorio, y en caso de que tenga que escribir, mantener este directorio en otro sistema de cheros y evitar que el usuario tenga permisos de lectura y/o creaci on de directorios, para evitar la creaci on de repositorios de programas pirateados (http://www.rediris.es/cert/docs/ftpcong.es.html). 3. No emplear el servicio de FTP para la transmisi on de documentos o cheros entre equipos, pues las claves de conexi on se transmiten en claro.

4.5.5

Servidores de cheros

Hace algunos a nos era frecuente el empleo de servidores de cheros en los sistema Unix para la compartici on de software entre las diversas estaciones de trabajo. Debido sobre todo al alto costo de los dispositivos de almacenamiento, en la actualidad aunque este coste ha disminuido mucho, todav a es frecuente encontrar sistemas de cheros en red. As mismo la incorporaci on de equipos con soporte de NetBios sobre IP (Windows 3.11/9x/NT sobre todo, pero tambi en Unix con Samba) a la red se debe hacer tomando algunas medidas de seguridad. Servidores NFS El acceso NFS es frecuente en entornos Unix puros, aunque existen clientes y servidores para Windows 9x/NT 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 alterar f acilmente las conexiones y realizar ataques simulando ser tanto el origen como el destino de las conexiones. La versi on 3 del protocolo permite emplear TCP y emplea claves criptogr acas para evitar la suplantaci on de los equipos.

31

2. No exportar directorios con permisos de escritura. Salvo que sea estrictamente necesario, exportar los sistemas de cheros con permisos de s olo lectura, de forma que no se pueda escribir en ellos. En caso de que se tengan que exportar sistemas de cheros con permisos de escritura (home de usuarios), no exportar jerarquias de directorios que contengan binarios. En las estaciones clientes evitar montar sistemas de cheros con permiso de ejecuci on. 3. Restringir los accesos. No exportar los accesos, indicar en las opciones de exportaci on qu e equipos son los que pueden montar los recursos, emplear 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 y su utilizaci on original empleaba un protocolo denominado NetBeui, que no permit a el enrutamiento de los paquetes. Sin embargo ahora mismo se emplea sobre todo con TCP/IP en servidores NT y Unix. Algunos problemas de seguridad que tiene este protocolo son: En sistemas NT y Windows es preciso tener instalados las ultimas versiones de los parches existentes (service packs), ya que las primeras implementaciones de los servidores ten an diversos problemas que provocaban ataques de denegaci on de servicio (DoS). Evitar la exportaci on de sistemas de cheros que contengan ejecutables con permisos de escritura, tanto para evitar la suplantaci on de los binarios como para evitar la proliferaci on de virus. En los servidores NT tener especicado siempre el acceso al grupo todos y despu es permitir los accesos en funci on de los grupos de usuario. Hay que tener en cuenta que si estos servicios est an abiertos a todo el mundo es posible acceder a ellos desde cualquier direcci on IP. En servidores NT emplear como sistema de cheros NTFS, ya que permite especicar derechos individuales a los usuarios. Adem as recomendamos no emplear FAT.

32

 En el caso de exportar directorios particulares de usuarios, emplear un sistema de quotas en el servidor, ya sea mediante la instalaci on del parche correspondiente (Service Pack 4 en NT) o empleando un equipo Unix con samba con quotafs, para evitar que un usuario pueda llenar la partici on. Si se emplea samba, procurar que los password de acceso no sean los mismos que los de las cuentas de usuarios en los equipos. Emplear, si es posible, un servidor de autenticaci on externo (PDC) para evitar que las claves puedan ser obtenidas mediante un snier de red o por alguno de los virus y troyanos que est en apareciendo cada vez con m as frecuencia en entornos Windows.

4.6

Monitorizaci on de logs

En Unix existen diversos mecanismos para que quede constancia de toda la actividad de un proceso. El m as simple de estos mecanismos es que el proceso en cuesti on vaya escribiendo una especie de registro de todo lo que hace en un chero (lo normal es llamar a estos registros logsaunque hay palabras en castellano de sobra). Esto tiene sus limitaciones: si dos procesos escriben sus informes simult aneamente al mismo chero el resultado nal puede ser confuso. no nos sirve de mucho si queremos almacenar, a medida que se producen, copias de estos informes en otra m aquina distinta. 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 an como registro able), pero interesa que cualquier programa tenga capacidad de generarlos, lo cual es una contradicci on. Para solucionar estas limitaciones se ha creado el sistema syslog de Unix. Est a compuesto por lo siguiente:

33

 Un proceso privilegiado (syslogd), capaz de generar cheros de log y avisos en base a determinadas peticiones hechas por los programas de usuario. Un servicio Internet (UDP 514), que permite enviar peticiones syslog de una m aquina a otra. Un chero de conguraci on (/etc/syslog.conf).

4.6.1

Conguraci on

El chero /etc/syslog.conf permite especicar qu e acciones se llevan a cabo cuando un determinado programa solicita registrar una actividad. Syslog clasica las actividades a registrar en base a dos par ametros: subsistema (facility) y severidad. El subsistema depende de qui en ha generado el informe, el n ucleo, sistema de correo, news, etc. La severidad indica la prioridad que se le asigna a cada uno los mensajes, desde los de debug hasta los de emergencia y/o p anico. Consultar la p agina del manual syslogd.conf para m as informaci on. El chero de conguraci on permite asignar acciones seg un subsistema y severidad. 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 informativoo mayor se almacenan en el chero /var/log/mail. Pero si tienen severidad erroro mayor, se almacenan en otro chero: /var/log/mail-errores. Si se produce un informe cr tico del sistema, no esperamos a almacenarlo en ning un sitio; se le escribe inmediatamente un mensaje a root donde quiera que est e, para que sepa lo que pasa. 34

 Si ese mensaje es adem as del tipo emergencia, no s olo avisaremos a root sino a todos los usuarios (es lo que pasa cuando se hace un shutdown). Los informes de seguridad, de severidad infoo mayor, no s olo se guardan en el chero /var/log/auth sino que adem as se mandan a la m aquina otramaquina ( esto asume que hay un syslog corriendo en otramaquina, que el puerto 514 UDP de la misma est a accesible y que ese syslog est a a su vez congurado).

4.6.2

Particularidades

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

4.6.3

Uso desde programas

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

35

4.6.4

Rotaci on de logs

El problema de almacenar logs es que estos crecen y tarde o temprano llenan el disco. Para evitar esto, se recurre a la rotaci on de logs. Ejemplo de log 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. 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. Por supuesto, almacenaremos un n umero limitado de meses (o semanas, o d as), o esto no servir a de nada. Adem as, los logs de meses (d as, semanas) anteriores se pueden comprimir. Hacer esto tiene su truco. No se puede borrar impunemente un chero que est a abierto por un proceso (syslogd, en este caso). Es decir, se puede, pero los resultados no ser an los que nos imaginamos. La manera correcta de vaciar un chero abierto es: cp /dev/null <fichero>

4.6.5

Otros aspectos relacionados

Algo m as sobre los aspectos de seguridad: cuando se almacenan logs con nalidad informativa (estad sticas, etc) suele bastar almacenarlos en la misma m aquina donde se generan. Cuando se almacenan por motivos de seguridad, sin embargo, nos interesa preservar una copia en otra m aquina. El motivo es que si hay una intrusi on en la primera m aquina podr an borrar o modicar los logs, pero esas mismas actividades quedar an registradas en la segunda, avisando as a los operadores. 36

Normalmente, la m aquina que reciba los logs (loghost) no debe recibir otra cosa (para no ser susceptible de ataques) ni debe poder recibir logs desde fuera de la red local (para evitar ataques por saturaci on). Para evitar consultas al DNS cada vez que se genere un informe, la direcci on IP de esta m aquina debe estar en el chero /etc/hosts de todas las dem as.

4.7

Comprobaci on de integridad

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 conguraci on de los servicios para hacerlos m as vulnerables. Para evitar esto se suele emplear herramientas de comprobaci on de integridad. Estos programas funcionan en dos fases; primero se crea la base de datos de integridad, empleando varios algoritmos criptogr acos para obtener una huella dactilar de cada uno de los cheros. En una fase posterior se comprueban los cheros existentes en el sistema de cheros con las rmas que ha generado este programa, pudiendo averiguar si se ha producido alguna modicaci on en los mismos. Existen varias herramientas que permiten realizar esta comprobaci on de integridad, la m as conocida es quiz a Tripwire. Este programa permite emplear varios algoritmos criptogr acos a la hora de generar la base de datos (MD2, MD4, MD5, SHA, Snefru, CRC-32), para evitar que un atacante pueda modicar los cheros. La ultima versi on de Tripwire disponible de uso general es la versi on 1.3, disponible en el servidor FTP de Rediris. Desde el a no pasado la Universidad de Purdue transri o la licencia a la empresa Tripwire Security System, que ha desarrollado una nueva versi on, la 2.0 disponible tambi en para entornos Windows NT. Sin embargo, y dado que las diferencias son m nimas con respecto a la versi on 1.3, emplearemos esta como referencia.

4.7.1

Instalaci on de Tripwire

Tripwire est a disponible en el repositorio de programas de seguridad de RedIRIS (ftp.rediris.es/soft/rediris/cert) en c odigo fuente para los sistemas Unix. As mismo est a compilado en formato de paquete para algunas distribuciones Linux. La compilaci on no suele dar problemas y una vez instalado se emplea el chero de conguraci on /usr/local/bin/tw/tw.cong para 37

indicar qu e se debe comprobar.

4.7.2

Conguraci on de Tripwire

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

L L L E

Como se, ve cada una de las entradas est a formada por un identicador del 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 38

cheros sean de solo lectura (R), cheros de Log (L), o cheros que se deben excluir (E),etc. Consultar la p agina del manual para ver las distintas opciones de Tripwire. Una vez denido el chero de conguraci on se debe ejecutar el comando tripwire con la opci on de crear la base de datos (tripwire -initialize), de esta forma tripwire calcular a los hash de cada uno de los cheros y almacenar a la informaci on en los cheros de la base de datos. Una vez generada la base de datos se debe almacenar en un dispositivo de s olo lectura (o copiada a otro equipo) para evitar 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 despu es protegerlos contra escritura (en las unidades ZIP el bloqueo se realiza a nivel software, por lo que esta medida no es v alida). De esta forma es posible lanzar un proceso peri odicamente que compruebe la 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 este.

4.8

Procesos de accounting

En gran parte de los sistemas Unix es posible ejecutar procesos de accounting para ir registrando el uso de los recursos de los equipos por parte de los usuarios y procesos. La forma de congurar el sistema para que realize estos m etodos de accounting suele depender mucho del sistema operativo del equipo, ya que suele realizarse en el n ucleo de este, volc andose a cheros cada cierto periodo de tiempo y realizando un procesamiento estad stico de estos datos. Antiguamente los procesos de accounting sol an requerir bastante tiempo de procesamiento y ser dif ciles de congurar y administrar. Sin embargo en la actualidad, la activaci on del accounting se suele realizar por la ejecuci on de un script en el arranque del sistema y la utilizaci on de otro script para realizar las estad sticas durante la noche. Las principales ventajas que tiene este sistema es poder analizar que procesos se est an ejecutando en el sistema, as como los usuarios que lo realizan, pudiendo ver si alg un usuario esta ejecutando alg un proceso en background o se ha producido un ataque de syn ood contra un servidor. Consultar la documentaci on del sistema operativo para ver como se pueden activar estos procesos de accounting. 39

4.9

Actualizaciones software.

Ser a conveniente dar algunas recomendaciones que permitan a los administradores disponer de un sistema automatizado para la recogida, instalaci on y noticaci on de parches. Algunas de estas recomendaciones se pueden resumir en los siguientes puntos: Actualizaci on de los sistemas, tan pronto sea posible, a la u ltima versi on facilitada por el fabricante. Aplicaci on de todos los parches recomendadoshasta el momento para esa versi on del sistema operativo. Ser a aconsejable la utilizaci on de un script que se conectase al servidor FTP del fabricante concreto y aplicase los parches necesarios de forma autom atica. Mantener correctamente parcheado los sistemas utilizando algunos de los siguientes m etodos: 1. Patching incremental. Utilizaci on de un script que peri odicamente aplique los parches necesarios desde la u ltima aplicaci on, sin intervenci on humana y con noticaci on al administrador. 2. Obtener una lista de parches necesarios (incremental), despu es decidir qu e parches son realmente necesarios para el sistema concreto y aplicarlos. Hay parches que aunque se recomiendan para una versi on de un sistema operativo concreto, si no se posee un determinado software o paquete instalado, no es necesario aplicarlo. Tambi e ocurre al contrario, hay parches necesarios para una determinada versi on de software instalado que no se incluyen en los parches recomendados para esa versi on del s.o. Para aquellos administradores que dispongan m aquinas Solaris, podeis obtener un sistema de recogida autom atica de parches en la siguiente URL: http://www.um.es/ alfonso/

40

Cap tulo 5 Recomendaciones para usuarios nales.

5.1 introducci on

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 m aquinas. Pero no s olo los profesionales deben preocuparse de estos detalles, los usuarios nales tambi en se pueden ver afectados por m ultiples problemas si no actualizan su software. Muchos pueden pensar que el problema de la seguridad s olo ata ne a los administradores, inform aticos y profesionales del sector, nada m as lejos de la realidad, el usuario nal tambi en debe preocuparse por la integridad de su sistema dom estico. Desde el cl asico antivirus, perfectamente actualizado, hasta el propio navegador son programas imprescindibles dentro del PC y que deben actualizarse con regularidad. Un nuevo problema viene a conrmar este hecho, los navegadores antiguos tienen la fecha de caducidad de los certicados digitales a nales de este a no. Tanto las versiones de Netscape 4.05 y anteriores como la 4.x de Explorer se ven afectadas por este hecho. Esto representa un grave problema a la hora de establecer una comunicaci on con un sitio de comercio electr onico para realizar una transacci on. Guninski y Cuartango descubren continuamente nuevos fallos de seguridad que ponen los datos del disco duro accesibles a trav es del navegador. Una conguraci on incorrecta del sistema operativo puede dejar abierto el sistema a cualquier intruso. Un virus puede inutilizar todo nuestro ordenador o un troyano puede desvelar todas nuestras

41

cuentas de acceso a Internet. Por todo ello, la seguridad tambi en afecta a los usuarios dom esticos. En esta secci on, vamos a dar unas gu as b asicas de seguridad para distintos Sistemas Operativos dirigidas a los usuarios nales1.

5.2

Gu a B asica de Seguridad para Windows 95/98

Windows 95/98 son sistemas operativos que est an principalmente dise nados para trabajar como clientes, por lo que su uso y conguraci on ser a m as facil que cuando hablamos de un servidor (Linux, Windows NT, etc), lo que no los libera de que existan problemas de seguridad. No debemos olvidar, que al tener un equipo conectado a la red de una instituci on, 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 a parte de responsabilidad por el hecho de venir el ataque desde su m aquina. Este documento, pretende dar unas recomendaciones sobre la conguraci on y uso adecuado que debemos hacer de nuestro ordenador cuando tenemos instalado Windows 95/98.

5.2.1

Seguridad en la Red

Si tenemos el PC con Windows conectado a una red, lo m as probable es que tengamos congurada la Red para Trabajo en Grupo de Microsoft. Esta red nos permite intercambiar informaci on entre los distintos ordenadores que integran la red, de manera que podamos 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, h agalo siempre con una buena contrase na y asegures e de que el recurso se comparte con las personas que lo necesitan y no este accesible para todo el mundo. 3.Siempre que sea posible comp artalos como de s olo lectura. As evitar a que ,accidentalmente o por maldad, le borren informaci on o le llenen el disco duro escribiendo en el directorio compartido. 4.NUNCA comparta su disco duro con privilegios de escritura ni siquiera con contrase na. Aunque comparta con contrase na, hay programas que realizan diversos tipos de ataque (de fuerza bruta, diccionario, etc..) hasta que dan con la contrase na correcta. Un hacker tiene todo el tiempo del mundo para probar y Windows no le avisa que lo 42

est a haciendo. En general, le recomendamos que no comparta informaci on importante de forma permanente por este m etodo, pues no proporciona demasiada seguridad.

5.2.2

Antivirus, virus y caballos de troya.

Uno de los problemas m as graves de seguridad en los Windows son los virus y u ltimamente los troyanos: Virus. Son programas hechos por alguien y su funci on es muy diversa, pero b asicamente todos tienen la capacidad de reproducirse y una estrategia de propagaci on. Lo m as peligroso del virus es su payloadque puede ser desde una pelotita rebotando en la pantalla hasta el formateo del disco. Caballos de Troya. Son programas que tras una aparente funci on encierran en su interior otra funci on. Por ejemplo, un troyano t pico, puede presentarnos una pantalla igual a aquella en la que tenemos que escribir nuestro login y nuestro password, cuando los introduzcamos, los almacenar a. Lamentablemente los troyanos en Windows est an muy de moda desde que aparecieron los ya famosos BackOrice o Netbus, que tras instalase en el equipo, permiten el acceso y control remoto de tu ordenador desde Internet. Diariamente aparecen m as troyanos de este tipo. Algunas soluciones para evitar este tipo de problemas: 1. Antivirus. Buscan virus (y troyanos) en nuestro ordenador y los eliminan. En la actualidad muchos no s olo se limitan a buscar en nuestro disco duro y memoria, sino tambi en en los mensajes que nos llegan por correo o los que nos bajamos de Internet. Sin embargo, la ecacia de un antivirus depende de su actualizaci on, por lo que es important simo actualizarlo al menos una vez al mes. Diariamente aparecen en Internet decenas de virus que podr an atacarnos hasta que, primero, los antivirus los detecten, y segundo, nosotros aztualicemos 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 u ltimos virus como el conocido Melisa usaban la agenda del equipo infectado para mandar mails con el virus contenido en un gracioso attach. Lo m as recomendable es borrarlo (si no lo ejecuta no le infectar a) o en 43

todo caso, comprobar si el remitente realmente se lo ha enviado conscientemente, en caso contrario borrarlo denitivamente. 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, abralo sin macros, probablemente sea un virus.

5.2.3

Algunos apuntes m as

Windows 95/98 no es un sistema operativo que se hiciera pensando en la seguridad y al margen de la red debemos tener en cuenta algunas cosas m as: Vigile el acceso f sico a su equipo. Si alguien tiene acceso a su PC, puede encender el ordenador y ya tendr a a su disposici on toda la informaci on que en el est a contenida. Windows no provee ning un mecanismo para validar usuarios, para conseguir esto, deberemos recurrir a software de terceros. La contrase na que nos pide al arrancar Windows no es ninguna medida de seguridad, con pulsar cancelaro escapeentraremos 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 te oricamente Windows es un sistema operativo multitarea y multiusuario, esto no es del todo cierto. En realidad es m as un entorno monousuario ya que no distingue realmente entre usuarios. Por eso es totalmente desaconsejable compartir un PC entre varias personas. Cualquiera por error o maldad puede ver, modicar o borrar sus datos.

44

Ap endice A Informacion de Seguridad en Internet

A.1
A.1.1

Listas de distribuci on
Listas de RedIRIS.

Puede encontrar informaci on sobre las listas de seguridad en RedIRIS en la URL http://www.rediris.es/cert/listserv.es.html De estas listas queremos destacar la lista IRIS-CERT. Esta lista restringida, tiene como objetivo tratar temas relacionados con la seguridad en las comunicaciones y en las m aquinas de la Comunidad de RedIRIS, con el n de coordinar servicios. Actualmente existen 84 suscriptores, pero desgraciadamente el tr aco es nulo. A partir de ahora deber a ser oblidatoria la existencia de al menos una persona de cada instituci on en esta lista. Lo mismo ocurrir an con otras listas IRIS-*: IRISMAIL, IRIS-DNS y IRIS-IP. En el caso de que no se proporcionen puntos de contacto para esta lista, ser a el PER. Desde IRIS-CERT queremos hacer un trabajo de potenciaci on de esta lista, esperando tener respaldo de todos aquellos responsables de seguridad interesados en mejorar su labor diaria.

A.1.2

Otras

Podr as encontrar informaci on u til sobre listas de distribuci on relativas a seguridad en las siguientes URLs: http://www.cica.es/seguridad/listas.es.html 45

 http://www.rediris.es/cert/listas.es.html

A.2

Boletines

Criptonomic on: http://www.iec.csic.es/criptonomicon/ Kript opolis (Criptogaf a, PGP y Seguridad en Internet): http://www.kriptopolis.com/boletin.htm Una al d a (Hispasec: Noticias diarias de seguridad inform atica): http://www.hispasec.com/

A.3

Areas de Documentaci on

CERT/CC (CERT Coordination Center): http://www.cert.org/ EuroCERT: http://www.eurocert.org/ Area de seguridad del CICA: http://www.cica.es/seguridad/index.es.html IRIS-CERT: http://www.rediris.es/cert esCERT-UPC: http://http://escert.upc.es/cert es.html Grupo de LinUxuarios de Bizkaia (Seguridad en Linux): http://web.jet.es/jillona/seguridad/ Linux Security HOWTO: ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO Web de seguridad Inform atica del Instituto Tecnol ogico de Inform atica : http://www.iti.upv.es/seguridad/ Hispasec: http://www.hispasec.com/ Security Portal: http://Securityportal.com/ X-Force (Internet Security System): http://www.iss.net/ Maximum Security (A Hackerss Guide to Protecting your Internet Site and Network): http://www.itlibrary.com/reference/library/1575212684/ewtoc.html

46

 Current top ten of smurf ampliers: http://www.powertech.no/smurf/ PatchDiag Tool: http://pogostick.net/ pdiag/english.html Netscan.org (List of the smurf ampliers): http://www.netscan.org/ COAST, Computer Operations, Audit, and Security Technology: http://www.cs.purdue.edu/coast/ Bug Net Home Page: http://www.bugnet.com/ Computer Security Information: http://www.alw.nih.gov/Security/security.html The WC3 Security Resources: http://www.w3.org/Security/ The WWW Security FAQ: http://www.w3.org/Security/Faq/www-securityfaq.html EPIC. Tool for protecting Online Privacy: http://www.epic.org/privacy/tools.html SunSolve Online(TM): http://online.sunsolve.sun.co.uk/ CIAC Security Website: http://www.ciac.org/ The passphrase FAQ, version 1.04: http://www.stack.nl/ galactus/remailers/passphrase-faq.html KhaOS Linux: http://www.kha0s.org/ Secury Unix Programming FAQ: http://www.whitefang.com/sup/

A.4

Sitios de Hackers.

RootShell: http://www.rootshell.com/ Nmap (Stealth Port Scanner for Network Security Auditing, General Internet Exploration Hacking): http://www.insecure.org/nmap/ Els Apostols: http://www.apostols.org/ HNN- HackerNewsNetwork: http://www.hackernews.com/

47

 HERT Computer Security (Hacker Emergency Response Team): http://www.hert.org/ Cult of the Dead Cow (cDc): http://www.cultdeadcow.com/ HackerShield Anti-hacker Software Closes Network Security Holes: http://www.netect.com/hs overview.html

A.5

Herramientas y Software de Seguridad

Area de Seguridad de RedIRIS: ftp://ftp.rediris.es/rediris/cert Software de Seguridad para Unix: http://www.alw.nih.gov/Security/progfull.html

Software de Seguridad para Windows 9x/NT: http://hotles.zdnet.com/cgibin/texis/swlib/hotles/search.html?link=1&UTcat=utilities&UTsubcat=security&Usrt=da Tocows (Secci on Security): http://tucows.uam.es/

A.6

Avisos de seguridad, parches, etc.. de empresas de Software

Microsoft: http://www.microsoft.com/security RedHat: http://www.redhat.com/corp/support/errata/ Debian: http://security.debian.org/ Sun: http://sunsolve.sun.com/ Suse: http://www.suse.de/e/patches/

48

Ap endice B contribuciones
Adem as de las personas de RedIRIS, las siguientes personas han contribuido al desarrollo de las recomendaciones de seguridad. Alfonso L opez Murcia (alfonso@fcu.um.es). Actualizaciones de software en equipos Unix. Victor Barona (victor.barahona@UAM.ES). Recomendaciones a nivel de usuario.

49

Ap endice C Registro de Cambios

Aunque no sea exhaustivo y tengamos que automatizarlo, nos parece adecuado ir poniendo un registro de los cambios entre las versiones. Este registro de cambios se publicar a tambi en aparte para que se puede consultar sin tener que recuperar el documento completo.

C.0.1

Versi on 0.0.2

Generada 14 de julio de 1999, una peque na revisi on, antes de las vacaciones. Cambios cosmeticos y de redacci on de algunas secciones. Incorporaci on de este documento de cambios. Incorporaci on de la secci on de contribuciones. Incorporaci on de la secci on de seguridad de usuarios. Incorporaci on de las notas de patching de S.O. Futuras v as Sin tener previsto para cuando realizar la siguiente revis on estas son algunas ideas sobre las posibles v as de desarrollo. Generaci on automatica de los documentos. COntribuci on global mediante un repositorio (CVS?). 50

 Generar automaticamente la documentaci on en HTML. Probar el pdftex o similar para evitar los cheros enormes que se generan con el ps2pdf de dominio publico. A nadir una secci on sobre seguridad en NT, Alguien quiere realizarla?. Separar las secciones, de forma que por un lado se traten los problemas de seguridad, con independencia del S.O. y desp ues se comenten las soluciones y problemas para los distintos sistemas, as por ejemplo se tratar a por un lado los problemas de intregridad en los sistemas de cheros y desp ues se tratar an las herramientas: Tripwire sobre todo, pero puede haber otras. Hacer la parte de referencias m as dinamica, viendo la forma que las referencias se puedan incluir en el texto y se generen despues correctamnete. Incorporar las referencias de la ultima reuni on del FIRST y estructurar el documento en funci on de las capas de protocolo OSI (Queda m as estructurado?)

C.0.2

Versi on 0.0.1

Primera versi on, presentada en los grupos de trabajo de Mayo de 1999 de RedIRIS, primer borrador para intentar encontrar voluntarios que contribuyan a la realizaci on de las recomendaciones.

51