|
|
F.A.Q.
DE SEG-L (LISTA DE SEGURIDAD EN CASTELLANO) Esta FAQ es Copyright (C) 1997, 1998 por el Grupo de documentacion de seg-l. Se prohibe la venta de este texto en cualquier medio presente o futuro, incluyendo formato electrónico, CD-ROM, o publicación del mismo sin la expresa autorización por escrito de los autores. |
PARTE I -
INTRODUCCIÓN
I. Sobre el objetivo del
documento
II. Sobre la lista seg-l
III. Cómo colaborar
IV. Agradecimientos
PARTE
II. INTRODUCCION A LA SEGURIDAD INFORMATICA O SEGURIDAD EN COMPUTO.
1.- Antecedentes y
definiciones
1.1. ¿ Qué es la seguridad en
cómputo, o seguridad informática ?
1.2. Propiedades de la
Información que protege la Seguridad Informática
1.3. División de las áreas de
administración de la seguridad.
1.4. ¿Cómo se pueden
clasificar factores intervienen en seguridad?
1.5. ¿ Cuáles serían algunos
métodos de protección ?
1.6. Algunos consejos
aplicables en cualquier ambiente:
2. Organismos de
seguridad
2.1. ¿ Qué es un equipo de
respuesta a incidentes ?
2.2. Certs y equipos de
respuesta
PARTE III - REDES
Y SEGURIDAD FISICA
3. Sniffers,
Monitores de red, y otras herramientas
3.1. ¿ Qué es un Sniffer
? ¿ Qué es un analizador de protocolos ?
3.2. ¿ Qué quiere decir
que lee información a nivel de enlace ?
3.3. Tengo una red con
topologia en estrella, ¿ Soy vulnerable ?
3.4. Quiero dar acceso a
mi red vía modem. ¿ Pueden leer la información que circula por mi red
ejecutando un sniffer al otro lado de la línea ?
3.5. ¿ Cómo puedo saber
si hay alguien corriendo un sniffer en mi red ?
3.6. Recursos
4.0 Cortafuegos
(firewalls)
4.1 ¿ Qué es un firewall
?
4.2 ¿ Cómo actúa un
firewall ?
4.3 ¿ Qué tipos de Firewall
existen ?
4.4 ¿ Qué
servicios/puertos conviene bloquear en un cortafuegos ?
4.5 ¿ Qué riesgos puedo
correr habilitando el servicio... ?
5.0 Filtrado de
Paquetes
5.1 ¿ En qué consiste un
fitro de paquetes ?
5.2 ¿ Dónde puedo
instalar un fitro de paquetes ?
5.3 ¿Cómo defino
correctamente un filtro de paquetes ?
5.4 Como programar un
filtro en un router Cisco.
5.5 ¿ Porqué mi filtro
no funciona correctamente ?
5.9 Recursos
PARTE IV .-
SEGURIDAD A NIVEL DE SOFTWARE
6. UN*X
6.1. ¿ Cuáles son algunas
consideraciones que debo tomar para hacer seguro mi UN*X?
6.2 ¿ Cómo separar cuentas
shell y de correo en UN*X ?
6.3 ¿ Cómo utilizar syslog en
modo remoto ?
6.9. Recursos
7. WINDOWS
7.1 ¿ Cómo realizo una
instalación segura de una máquina Windows NT conectada a Internet ?
7.2. ¿Qué es el Back Orifice /
Netbus?
7.9 Recursos
I. Sobre el
objetivo del documento
Este documento contiene
algunas de las preguntas más frecuentes formuladas en la lista de correo
electrónico seg-l. El propósito de esta lista no es otro que difundir
información acerca de seguridad informática en castellano, cubriendo así una
(en opinión de los participantes de ella) acuciante necesidad de la comunidad
hispanoparlante.
Se ha tratado que la
información se encuentre amena en la medida de lo posible, así como con la
menor cantidad de tecnicismos y regionalismos, haciendo que una mayor audiencia
se beneficie con el contenido del texto.
II.- Sobre la lista
seg-l
Para suscribirse a la lista
seg-l, envíe un mail a http://moon.act.uji.es/~inigo/majordomo@core-sdi.com
con el texto:
subscribe seg-l [su.dirección.de.correo@su.host.de.email]
en el cuerpo del mensaje. El programa majordomo (manipulador de listas de correo) se le enviará un e-mail a su dirección de correo indicando si ha podido suscribirle o no.
Una vez subscrito a la lista,
puede enviar mensajes a la lista a través de la dirección
<seg-l@core-sdi.com>. Recuerde que esta
lista está moderada (afortunadamente el moderador, Iván Arce es bastante
benévolo con el correo que llega ;) por lo que no se extrañe si alguna
vez su mensaje no aparece; o bien incluye comentarios del moderador.
Para borrarse de la lista, envíe a <majordomo@core-sdi.com> un mensaje con:
unsubscribe seg-l [su.dirección.de.correo@su.host.de.email]
en el cuerpo del mensaje. (Espero que nadie tenga que cancelar ninguna suscripción por no encontrar interesante seg-l ;)
Como una cortesía, y tratando de reducir la carga de trabajo del moderador (de por sí profusa), envíe mensajes que respeten las reglas generales de etiqueta de la Internet.
Este documento puede obtenerse en el WWW gracias a la ayuda de Manuel Mollar que me ofreció hospedar el documento en:
http://moon.inf.uji.es/~inigo/seg-l/faq
Hay un espejo del documento
publicado en:
http://master.cic.uanl.mx/~mhoz/seguridad/
Nota: Debido a las
peticiones que he recibido por parte de suscriptores de la lista, hemos
incluido algunos temas que no se han discutido en la misma; pero que son de
gran ayuda para aquella gente que está empezando en el campo de la seguridad.
III.- Cómo colaborar
Si estás interesado en remitir
información que consideres es importante incluir en la FAQ, por favor hazla
llegar a:
Iñigo González Ponce: igonzalez@ati.es
Martín Humberto Hoz Salvador: mhoz@master.cic.uanl.mx
IV. Agradecimientos
Sin todos vosotros, este
documento nunca habría sido posible: María del Olmo y Lidia Elena Gómez
(personas especiales para los principales contribuyentes ;) Javier Romeu,
vIERJa, Jeimy José Cano Martinez, Manuel Mollar (por hospedar el Web),
jsyn, se7en.
Es necesario agradecer también
a la gente de CORE-SDI por alentar la promoción de la cultura de la seguridad
informática entre la comunidad hispanoparlante: ¡Bravo por ellos!
PARTE II.
INTRODUCCION A LA SEGURIDAD INFORMATICA O SEGURIDAD EN COMPUTO.
1.- Antecedentes y definiciones
1.1. ¿ Qué es la
seguridad en cómputo, o seguridad informática ?
n realidad es un concepto cuya
definición exacta es difícil de proporcionar, debido a la gran cantidad de
factores que intervienen. Sin embargo es posible enunciar que Seguridad es el
conjunto de recursos (metodologías, documentos, programas y dispositivos
físicos) encaminados a lograr que los recursos de cómputo disponibles en un
ambiente dado, sean accedidos única y exclusivamente por quienes tienen la
autorización para hacerlo.
Existe una medida
cualitativa para la Seguridad que dice "Un sistema es seguro si se
comporta como los usuarios esperan que lo haga" (Dr. Eugene Spafford).
1.2. Propiedades de la
Información que protege la Seguridad Informática
La Seguridad Informática debe
vigilar principalmente por las siguientes propiedades:
Privacidad - La información debe ser vista y
manipulada únicamente por quienes tienen el derecho o la autoridad de
hacerlo. Un ejemplo de ataque a la Privacidad es la Divulgación de Información
Confidencial.
Integridad - La información debe ser
consistente, fiable y no propensa a alteraciones no deseadas. Un ejemplo de
ataque a la Integridad es la modificación no autorizada de saldos en un sistema
bancario o de calificaciones en un sistema escolar.
Disponibilidad - La información debe estar en el
momento que el usuario requiera de ella. Un ataque a la disponibilidad es la
negación de servicio (En Inglés Denial of Service o DoS) o “tirar” el servidor
1.3. División de las
áreas de administración de la seguridad.
Para simplificar, es posible
dividir las tareas de administración de seguridad en tres grandes rubros. Estos
son:
Autenticación .- Se refiere a establecer las
entidades que pueden tener acceso al universo de recursos de cómputo que cierto
medio ambiente puede ofrecer.
Autorización .- Es el hecho de que las entidades
autorizadas a tener acceso a los recursos de cómputo, tengan efectivamente
acceso únicamente a las áreas de trabajo sobre las cuales ellas deben tener
dominio.
Auditoría .- Se refiere a la contínua
vigilancia de los servicios en producción. Entra dentro de este rubro el
mantener estadísticas de acceso, estadísticas de uso y políticas de acceso
físico a los recursos.
Para ejemplificar lo anterior, tomemos el ejemplo de una compañía ficticia a la que llamaremos "Servicios de Cómputo". Esta compañía dispone de un servidor donde corre el software a través del cual se lleva a cabo el procesamiento de las nóminas y el control de recursos humanos. (Ambos muy relacionados)
Autenticación se refiere a
que sólo las personas de esos departamento tengan cuentas de acceso a dichos
equipos, puesto que sería peligroso que algún otro departamento lo tuviera. El
responsable de los equipos de cómputo llevaría a cabo la labor de Autorización,
al no permitir que todas las personas responsables de recursos humanos tuvieran
acceso a las Bases de Datos de Nóminas, si no lo necesitan. La Auditoría se
lleva a cabo al establecer políticas de uso y acceso a los recursos, así
como reglamentos que rijan la no-divulgación de información confidencial.
También aquí se debe llevar un registro de los recursos utilizados para
prevenir, por ejemplo, que un uso del 100% en un disco provoque que el sistema
deje de funcionar. Debe vigilarse también los intentos de acceso legal e ilegal
al mismo.
1.4. ¿Cómo se pueden
clasificar factores intervienen en seguridad?
La clasificación dentro de cada
una de las áreas arriba expuestas es también un tanto compleja. Pero a
grandes razgos podemos decir que la seguridad en un sistema está determinada
por:
- EL FACTOR ORGANIZACIONAL:
a) Usuarios
Tipo
de usuarios que se tienen
Reglamentos y políticas que rigen su comportamiento
Vigilar que esos reglamentos y políticas se cumplan, y no queden sólo en papel
b) La alta dirección
Inversión en capacitación de los administradores
Apoyo
económico orientado a la adquisición de tecnología de seguridad
Negociar acuerdos de soporte técnico con los proveedores de equipo.
- EL FACTOR SOFTWARE:
a) La aplicación
Vigilar que tenga mecanismos para control de acceso integrados
Observar las facilidades de respaldo de información que se tienen
Establecer qué tan crítica es la aplicación y desprender su disponibilidad de
ahí
b) El sistema operativo
Mostrar preferencias por los sistemas abiertos (UNIX)
Vigilar que soporte estándares de seguridad como C2
Observar las recomendaciones del fabricante y aplicar los parches que libere...
Vigilar siempre las bitácoras
Mantenerse informado sobre las alertas de seguridad
c) Software de red
Vigilar de cerca las estadísticas de acceso y tráficos de la red
Procurar implementar cortafuegos (firewalls), pero no confiar en ellos
En la
medida de lo posible, apoyar las conexiones cifradas.
- EL FACTOR HARDWARE:
a) Hardware de red
Elegir adecuadamente el tipo de tecnología de transporte (Ethernet, FDDI, etc)
Proteger muy bien el cableado, las antenas y cualquier dispositivo de red
Proporcionar periódicamente mantenimiento a las instalaciones
b) Servidores
Mantenerlos en condiciones de humedad y temperatura adecuados.
Establecer políticas de acceso físico al servidor.
El
mantenimiento también es importante aquí.
1.5.- ¿ Cuáles serían
algunos métodos de protección ?
Por regla general, las
políticas son el primer paso que dispone a una organización para entrar en un
ambiente de seguridad, puesto que reflejan su voluntad de hacer algo que
permita detener un posible ataque antes de que éste suceda (proactividad).
Hecha la aclaración, enumeremos algunos otros métodos:
I.- Sistemas de detección de intrusos.- Son sistemas que permiten analizar las bitácoras de los sistemas en busca de patrones de comportamiento o eventos que puedan considerarse sospechosos, en base a la información con la que han sido previamente alimentados. Pueden considerarse como monitores.
II.- Sistemas orientados a conexión de red.- Monitorean las conexiones de red que se intentan establecer con una red o un equipo en particular, siendo capaces de efectuar una acción en base a métricas como: origen de la conexión, destino de la conexión, servicio solicitado, etc. Las acciones que pueden emprender suelen ir desde el rechazo de la conexión hasta alerta al administrador vía correo electrónico o vía pager. En esta categoría están los cortafuegos (firewalls) y los wrappers.
III.- Sistemas de análisis de vulnerabilidades.- Analizan sistemas en busca de vulnerabilidades conocidas anticipadamente. La desventaja de estos sistemas es que pueden ser utilizados tanto por personas autorizadas como por personas que busquen acceso no autorizado al sistema
IV.- Sistemas de protección a la privacidad de la información.- Herramientas que utilizan criptografía para asegurar que la información sólo es visible a quien tiene autorización de verla. Su aplicación es principalmente en las comunicaciones entre dos entidades. Dentro de este tipo de herramientas podemos situar a Pretty Good Privacy (PGP), Secure Sockets Layer (SSL) y los certificados digitales tipo X.509
V.- Sistemas de
protección a la integridad de información.- Sistemas que mediante
criptografía o sumas de verificación tratan de asegurar que no ha habido
alteraciones indeseadas en la información que se intenta proteger. Algunos
ejemplos son los programas que implementan algoritmos como Message Digest 5
(MD5) o Secure Hash Algorithm 1 (SHA-1), o bien sistemas que utilizan varios de
ellos como Tripwire.
1.6.- Algunos consejos
aplicables en cualquier ambiente:
a) Informar al
usuario/administrador – Si usted es un administrador, notifique a sus
usuarios de los mecanismos de seguridad que usted tiene implementados, y
anímelos a utilizarlos haciendo de su conocimiento las posibles consecuencias
de no cumplir con ellos. Así pues hágales saber que si prestan su password
están cometiendo una falta, y que igualmente serán responsables por los actos,
de buena o mala fe, que alguien más realice con su cuenta si logra adivinar
dicho password. Si usted es un usuario por otra parte, observe siempre una
conducta acorde a lo que su administrador ha determinado como válida para el
sistema al que tiene acceso. Así mismo, dé a conocer a su administrador,
cualquier sospecha de violación a cualquier recurso al que usted tiene acceso
legítimo.
b) Respaldar siempre.-
Sin embargo no basta con efectuar respaldos. Una buena política de respaldos
contempla, entre otras cosas: tiempos óptimos de respaldo y recuperación,
periodicidad del respaldo y verificación de integridad (de nada sirve un
respaldo no íntegro), necesidad de duplicidad y expiración de los
respaldos. Si es usted un usuario, haga además un respaldo propio adicional al
que hace el administrador siempre que le sea posible, dependiendo también de la
importancia de su información.
c) Realizar verificaciones
no predecibles.- Si un ladrón conoce las horas a las que la guardia de un
banco hace su rondín, seguramente decidirá no robarlo a esas horas. Lo mismo
sucede con los sistemas: si se hacen verificaciones periódicas, y alguien más
conoce qué y cuándo se realizan, será necesario además hacer verificaciones de
periodicidad no predecible, a fín de obtener una estadística más real del
comportamiento del sistema.
d) Leer las bitácoras.-
Las bitácoras del sistema reflejan lo que ocurre en el mismo. De nada sirve
tenerlas si no son leídas. Ahí es donde pueden descubrirse ataques no exitosos
perpetrados contra su sistema, por ejemplo.
e) Aplicar “parches” o
tener las últimas versiones del software.- Las vulnerabilidades sobre algún
producto o plataforma, pueden dar la vuelta al mundo rápidamente gracias a
internet. Es recomendable por ello contar siempre con la versión más
actualizada del software, o bien aplicar los “parches” respectivos cuando son
liberados. En este rubro, el software libre (Como Linux o Apache) cuenta con
una ventaja sobre software comercial, pues el tiempo de respuesta es
dramáticamente más rápido para el software libre.
f) Leer noticias sobre
seguridad: Si su proveedor mantiene una lista de seguridad, únase a ella.
Así mismo suscríbase a listas que le informen sobre seguridad en general de
modo que obtenga un panorama amplio pero conciso sobre el tema. Seg-l es en
este sentido una excelente opción ;)
g) Cancelación de cuentas.-
Todo lo anterior no sirve si personas que han trabajado para la organización
poseen sus cuentas de acceso después de haber dejado de colaborar con ella. Las
estadísticas demuestran que un 85% de los ataques de seguridad son realizados
desde dentro de la organización, o bien a través de cuentas de personal que
estuvo dentro de ella.
2.- Organismos de seguridad
2.1. ¿ Qué es un equipo
de respuesta a incidentes ?
Es una organización, que
investiga sobre seguridad a nivel técnico y difunde información a la comunidad
en general sobre el tema. Se les conoce como CERT’s (Computer Emergency
Response Team ó Equipo de Respuesta a Emergencias de Cómputo) o IRT (Incident
Response Team ó Equipo de Respuesta a Incidentes)
2.2. Certs y equipos de respuesta
ESPAÑA
ESCERT
ESCERT, Cl. Jordi Girona 1-3
Módul D6, CP 08034.
Barcelona, España
http://escert.upc.es/
e-mail: cert@escert.upc.es
Tel: +34-3-4015795, +34-3-4016984
Fax: +34-3-4017055
IRIS-CERT (Ámbito
Académico)
http://www.rediris.es/cert
e-mail: cert@rediris.es
MÉXICO
MxCERT - DINF - DTCI:
ITESM, Campus Monterrey
Suc. de Correos J, C.P. 64849
Monterrey, N.L.; México
http://www.mxcert.org.mx/
e-mail: mxcert@mxcert.org.mx
Tel: (8) 328-4088 Atencion
personal días hábiles
de 8:00-13:00 y 15:00-18:00
GMT-0600/GMT-0500.
(8) 319-0779 PIN No.628
0508 >> Emergencia 24h <<
Fax: (8) 328-4129
Area de Seguridad en
Cómputo – UNAM
Dirección General de Servicios
de Cómputo Académico
Circuito Exterior, C. U.
(frente a la FCA)
04510 México D. F.
http://www.asc.unam.mx/
e-mail: asc@asc.unam.mx
Tel: (5) 622-81-69
Fax: (5) 622-80-43
E.E.U.U
CERT/CC: (Centro
coordinación CERTs)
http://www.cert.org/
e-mail: cert@cert.org
Tel: +1 412 268-7090
FIRST [ Forum of Incident
and Response Teams ]:
http://www.first.org/
email: http://moon.act.uji.es/~inigo/first-sec@first.org
Asociación que aglutina
a los equipos de Incidencia y respuesta de
todo el mundo (no solo a los
CERTs públicos).
Listado CERTs Europeos:
http://www.cert.dfn.de/eng/csir/europe/certs.html
PARTE III - REDES Y
SEGURIDAD FISICA
3. Sniffers, Monitores de red, y otras herramientas.
3.1. ¿ Qué es un
Sniffer ? ¿ Qué es un analizador de protocolos ?
Un sniffer es un proceso que
olfatea el tráfico que se genera en la red a nivel de enlace; de este modo
puede leer toda la información que circule por el tramo (segmento) de red en el
que se encuentre. Por este método se pueden capturar claves de acceso, datos
que se transmiten, numeros de secuencia, etc...
Un analizador de protocolos es un sniffer al que se le ha añadido funcionalidad suficiente como para entender y traducir los protocolos que se están hablando en la red. Debe tener suficiente funcionalidad como para entender las tramas de nivel de enlace, y los paquetes que transporten.
Truco: Normalmente la
diferencia entre un sniffer y un analizador de protocolos, es que el segundo
está a la venta en las tiendas y no muestra claves de acceso.
3.2. ¿ Qué quiere
decir que lee información a nivel de enlace ?
Quiere decir que el sniffer se
dedica a leer TRAMAS de red, por lo que los datos que obtendremos de él serán
tramas que transporán paquetes (IP, IPX, etc...). En estos paquetes se incluyen
los datos de aplicación (entre ellos claves de acceso).
Estos programas ponen al
menos un interfaz de red (o tarjeta de red o NIC) en _modo promiscuo_; es decir
que al menos uno de los interfaces de red de la máquina está programado para
leer toda la información que transcurra por el tramo de red al que esté
conectado, y no solamentelos paquetes con dirigidos a él.
3.3. Tengo una red
con topologia en estrella, ¿ Soy vulnerable ?
Muy probablemente Sí.
Cualquier tipo de red basada en BUS o ANILLO lógicos es vulnerable. Aunque los
cables se envíen a un concentrador (hub) haciendo que la topología física sea
de estrella, si la topología lógica de la red es en bus o en anillo las tramas
podrán escucharse desde cualquier host conectado al concentrador.
En general, IEEE 802.3
(ethernet), 802.4 (token bus), 802.5 (token ring), Ethernet 2, etc.. suelen ser
vulnerables con la siguiente salvedad: algunos concentradores de nueva
generación aíslan el tráfico entre hosts conectados a una misma red; por lo que
en estas redes la utilización de sniffers es poco menos que inútil (excepto en
ciertos casos donde la carga de la red obliga al concentrador a unir varios buses
lógicos en uno físico - - -- esta salvedad puede no cumplirse dependiendo del
concentrador utilizado).
3.4. Quiero dar
acceso a mi red vía modem. ¿ Pueden leer la información que circula por mi red
ejecutando un sniffer al otro lado de la línea ?
Depende de cómo se configure
la conexión.
En este caso tendrás que engañar al router para que crea que las direcciones que se asignan para acceso telefónico pertenecen a tu misma red. Si tienes (un poco de) cuidado al configurar la máquina que controla estos hosts remotos no deberías tener ningún problema, ya que las tramas que se enviarán a estas máquinas serán únicamente aquellas que les corresponda recibir.
Casi siempre los
proveedores de acceso a internet (Como Infovía en España, Infosel en México o
similares) interponen entre tu red y el usuario remoto una serie de mecanismos
(routers y conexiones punto a punto) que hacen inefectivo el uso un
Sniffer en la máquina remota.
3.5. ¿ Cómo puedo
saber si hay alguien corriendo un sniffer en mi red ?
Esto es más difícil de lo que
parece.
La forma más común de saber si un interfaz de red está en modo promiscuo consiste en ejecutar (en máquinas UNIX) el programa ifconfig de la siguiente forma:
$ifconfig –a [ Muestra el estado de las placas de red. La salida sería similar a esto ]
eth0 Link Encap: 10Mbps Ethernet HWaddr:
xx:xx:xx:xx:xx:xx
inet addr: a.b.c.d Bcast: a.b.c.f Mask: m.m.m.m
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets: 0 errors:0 dropped:0
overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Interrupt:15 Base Address:0x300
El problema de esta solución es que se necesita tener acceso root a todas las máquinas que deben comprobarse (otra opción sería hacer un crontab que compruebe el estado cada cierto tiempo, sin embargo un cracker con acceso al sistema puede ver los trabajos en cron y deshabilitar esta verificación).
Según vIERJa <vIERJa@cyberdude.com>, corre el rumor de que algunas tarjetas de red ethernet envían un broadcast al entrar en modo promiscuo; sin embargo hasta el momento nadie ha podido confirmar este punto.
[Nota: No disponemos
todavía de información acerca de cómo detectar sniffers en Windows NT y/o PPC.
Cualquier aportación al respecto sería de gran ayuda.]
3.9. Recursos
Algunos de los sniffers más conocidos son:
sniffit: Difícil de encontrar ¿ verdad ? ;)
http://reptile.rug.ac.be/~coder/sniffit.html
también en http://www.iti.upv.es/seguridad/
tcpdump: UNIX
Este programa vuelca toda la
información que entra o sale de la tarjeta de red. Hay una versión
disponible para SCO en http://unix.hensa.ac.uk/ftp/mirrors/uunet/sco-archive/TLS/(esta
puede ser una buena ocasión para comprobar la compatibilidad binaria con
ejecutables de SCO).
esniff.c:
Publicado en Phrack #45
Esta es la madre de todos los
sniffers. La mayoría de los que se hicieron después han estado basados en este
programa para SunOS (nota: necesita una máquina con /dev/nit).
juggernault:
Publicado en Phrack Magazine
#50
Ademas de actuar como sniffer,
puede tomar conexiones suplantando a otros hosts.
ethload.exe y ethdump.exe (DOS): ¿ ftp://ftp.cdrom.com/?
Se han utilizado especialmente
para estadísticas de tráfico en LAN (ethernet, por supuesto ;). Problema: El
DOS no permite multitarea; por lo que si no tenemos un 386 viejo sin otro uso,
tendremos que inutilizar (¿temporalmente?) una máquina. Prueba a buscarlos en:
http://oak.oakland.edu/pub/msdos/lan
http://ub4b.eunet.be/pub/ub4b/network/msdos
netXray (Windows 95/NT):
Producto comercial; sin
embargo existen versiones de evaluación por 30 días.
SessionWall:
Poderoso analizador de
protocolos. Es también software comercial
Otros:
netzhack.exe [DOS]
4.0 Cortafuegos (firewalls)
4.1 ¿ Qué es un
firewall ?
Un cortafuegos o firewall es
un sistema de defensa basado en el hecho de que todo el trafico de entrada o
salida a la red debe pasar obligatoriamente por un sistema de seguridad capaz
de autorizar, denegar, y tomar nota de aquello que ocurre en la red.
Aunque hay programas que se
venden bajo la denominación de firewall, un firewall NO es un programa. Un
firewall consiste en un conjunto de medidas HARDWARE y SOFTWARE destinadas a
asegurar una instalación de red.
4.2 ¿ Cómo actúa
un firewall ?
Un Firewall actúa en los
niveles 3 (red) a 7 (aplicación) de OSI. Sus funciones son básicamente las
siguientes:
- - - Llevar contabilidad de las transacciones realizadas en la red.
- - - Filtrar accesos no autorizados a máquinas (mediante filtrado de paquetes,
o bien observando el contenido de las unidades de protocolo de Transporte,
Sesión, Presentación, y aplicación).
- - - Alertar en caso de ataques o comportamiento extraño de los sistemas de
comunicación.
El Common Criteria define
en el apartado cuarto del estándar a modo de ejemplo un protection
profile que correspondería a un firewall a nivel de red y de transporte.
4.3 ¿ Qué tipos de
Firewall existen ?
Cualquier Firewall puede
clasificarse dentro de uno de los tipos siguientes (o como una combinación de
los mismos):
Filtros (Packet
Filters).
Su cometido consiste en
filtrar paquetes dejando pasar por el tamiz únicamente cierto tipo de tráfico.
Estos filtros pueden implementarse a partir de routers (p.ej: en un Cisco,
podemos definir access-lists asociadas a cada uno de los interfaces de red
disponible). (véase Apartado 4.0 de esta sección: Filtros de paquetes).
Problemas: No son capaces de discernir si el paquete cuya entrada se permite incluye algún tipo de datos “maliciosos". Además, cualquier tipo de paquetes no permitidos puede viajar en el interior de tráfico permitido (ej: IP sobre IP). Desgraciadamente son difíciles de definir y depurar.
Proxy (Circuit Gateways)
En este caso la pasarela actúa
del mismo modo que un simple cable (vía software) conectando nuestra red
interna con el exterior. En general se requiere que el usuario esté autorizado
para acceder al exterior o interior y que tenga una cuenta de salida en el
proxy.
Problemas: Ciertos sistemas como SOCKS necesitan programas cliente modificados para soportarlo.
Pasarelas a nivel de
Aplicación (Application Gateway)
Estas pasarelas se ocupan de
comprobar que los protocolos a nivel de aplicación (ftp,http,etc...) se están
utilizando de forma correcta sin tratar de explotar algunos problemas que
pudiese tener el software de red.
Problemas: Deben estar
actualizados; de otro modo no habría forma de saber si alguien está tratando de
atacar nuestro sistema.
4.4 ¿ Qué
servicios/puertos conviene bloquear en un cortafuegos ?
Bloquee todos los servicios
basados en datagramas que no hagan uso de autentificación (todos los basados en
UDP no cifrados), y todos los servicios basados en TCP que no se
consideren estrictamente necesarios (evidentemente existen excepciones a esta
regla).
Por favor, lea en apartado
siguiente para sopesar los riesgos que implica habilitar ciertos servicios en
una Internet.
4.5 ¿ Qué riesgos
puedo correr habilitando el servicio... ?
A continuación se presenta una
lista de servicios accesibles en una Internet junto su descripción y posibles
problemas que pueden surgir con cada uno de ellos. Ciertos servicios de esta
lista sólo se han definido bajo TCP, y sin embargo tienen asignado también un
puerto UDP. Esto es debido a la política que sigue la IANA en la asignación de
puertos, por lo que no se descarta que alguno de estos protocolos pudiese
eventualmente ser implementado bajo UDP:
echo (7/tcp,udp)
Se utiliza únicamente para
depuración. Sin embargo, un atacante puede realizar "labores de depuración"
creando bucles en la red a partir de este puerto (véase udp chargen/19).
BLOQUEAR.
systat (11/tcp/udp)
Muestra información acerca del
host como usuarios conectados, carga del sistema, procesos en funcionamiento,
etc..
BLOQUEAR.
chargen (19/tcp,udp)
Se utiliza únicamente para
depuración. Basta con enviar un paquete a este puerto aparentemente originado
en el puerto de echo (7/udp) para provocar un bucle en la red.
BLOQUEAR.
telnet (23/tcp,udp)
Vulnerable a "toma de
sesiones". Es preferible utilizar en su lugar otras soluciones como SSH.
smtp (25/tcp,udp)
Históricamente la mayoría de
las entradas en hosts han venido a través de este puerto. Se debe FILTRAR este
puerto y mantener SIEMPRE la última versión estable conocida de cualquier
programa de correo, especialmente si trabajamos con sendmail.
time (37/tcp,udp)
Devuelve la hora del sistema
en un formato legible por la máquina (4 bytes mas o menos). Puede ser accedido
tras un ataque vía ntp(123/tcp,udp).
nameserver (42/tcp,udp)
Si dispone de una red privada,
debe instalar un servidor de nombres para ella. Bloquee el acceso a dicho
servidor desde el exterior, y utilice siempre la última versión de BIND para
resolver nombres. En este caso, puede cortar sin excesivos problemas el acceso
al DNS sobre UDP.
tftp (69/tcp,udp)
Falta de autentificación.
Bloquear si no se dispone de máquina alguna con arranque remoto.
private dialout
(75/tcp,udp) - - - [RFC1700]
Si encontramos una traza de
este puerto en los diarios del sistema (logs), en el mejor de los casos
estaremos siendo analizados por un scanner de puertos.
BLOQUEAR.
finger (79/tcp,udp)
Puede obtenerse información
acerca de usuarios concretos, información que puede utilizarse para adivinar
claves de acceso. BLOQUEAR o SUSTITUIR por una política coherente de asignación
de direcciones de correo (Juan Fernadez - - -> juan.fernandez@host.com) y un
mensaje advirtiendo de dicha política.
http (80/tcp,udp)
¡¡¡Cuidado!!! los servidores
web son cada vez más complejos y permiten demasiadas cosas. Conviene redirigir
el acceso a un puerto no privilegiado en maquinas unix. A ser posible, utilice
servidores http específicos para la tarea a realizar (servir archivos, acceso a
Bases de datos, etc...).
npp (92/tcp,udp) - [Network
Printing Protocol]
Nadie quiere imprimir
documentos ajenos ¿ verdad ?.
objcall (94/tcp,udp) -
[Tivoli Object Dispatcher]
Utilizado por la herramienta
de Gestión de redes Tivoli. Si utilizamos tivoli, aplicar las mismas
precauciones que con SNMP.
sunrpc (111/tcp,udp)
Especialmente peligroso sobre
UDP. No autentifica fuentes, y es la base para otros servicios como NFS.
auth (113/tcp,udp)
No debería permitirse obtener
información acerca de puertos privilegiados (puede utilizarse para realizar un
portscan). No se utiliza mas que en Unix.
ntp (123/tcp,udp)
[Network Time Protocol]
Se utiliza para sincronizar
los relojes de las máquinas de una subred. Un ejemplo de ataque clásico
consiste en enviar paquetes a este puerto para distorsionar los logs de la
máquina.
netbios
(137,138,139/tcp,udp)
No dispone de suficiente
autenticación. Afortunadamente según los RFC2001 y 2002 NetBIOS es capaz de
funcionar correctamente a pesar de que se estén enviando bloques de datos con
información errónea o corrompida.
snmp (161/tcp,udp) –
¿ Quién puede querer
administrar nuestra red desde el exterior ? Se puede obtener mucha información
a través de este servicio, como por ejemplo estado de los interfaces de red,
conexiones concurrentes en la máquina, etc...
BLOQUEAR.
snmp-trap (162/tcp,udp)
Traps de SNMP. A través de
este puerto se realizan solicitudes que pueden cambiar la configuración del
host.
BLOQUEAR.
irc (194/tcp,udp) –
No es peligroso en sí; sin
embargo sus usuarios suelen divertirse atacando los hosts de otras personas con
el fin de echarlos cuando no pueden hacer uso de la orden 'kick'. Generalmente
conviene bloquear los puertos 6666, 6667 y 6668 ya que son a los que se
enganchan los servidores de IRC.
exec (512/tcp)
Ejecuta ordenes en estaciones
remotas. Como todos los comandos 'r' (rexec, rcp, rlogin) en la otra partes
cuando se accede desde un conjunto de direcciones IP definidas por el usuario.
No se realiza más autentificación que la basada en dirección IP y usuario
remoto. MUY PELIGROSO (aunque muy potente).
BLOQUEAR.
biff (512/udp)
Notifica de la llegada de
correo. Buen candidato para posibles desbordamientos de buffer, o simplemente
para obligar a abandonar la sesión a un usuario debido a la llegada
masiva de mensajes de correo. (biff suele funcionar incluso con mesg n)
BLOQUEAR.
login (513/tcp) - rlogin. (ver
exec)
BLOQUEAR.
who (513/udp)
Muestra quien está utilizando
el host remoto. Se puede obtener información bastante detallada acerca de quién
utiliza una máquina y desde que terminal, uptime (tiempo que lleva en
funcionamiento), carga de la máquina, etc...
BLOQUEAR.
cmd (514/tcp) –
Similar a exec (512/tcp),
mismas precauciones.
BLOQUEAR.
syslog (514/udp)
BLOQUEAR a menos que existan
suficientes razones como para mantenerlo. Suele atacarse para corromper los
diarios (logs) del sistema con entradas falsas.
printer (515/tcp,udp)
router (520/tcp,udp) -
Local routing process.
BLOQUEAR
ingreslock (1524/tcp) –
En la mayoría de los Un*x se
puede encontrar esta entrada en /etc/services. Ya que está dado de alta y es un
puerto no privilegiado es un buen lugar para una puerta trasera (no sería la
primera vez que ocurre).
Hay más puertos
considerados poco seguros; por lo que la lista crecerá en futuras ediciones...
4.9 Recursos
Estándares
CCITSE-1.0 - Common Criteria
for Information Security (CEE-96/14)
En el apartado cuarto del
estandar (Predefined Protection Profiles) se definen (a modo de ejemplo) las
características que debería tener un Firewall para filtrado de paquetes a nivel
de red y transporte.
ISO-7498-2 OSI/RM -
Information Processing Systems Open Systems Interconnection. Basic Reference
Model. Part 2: Security Architecture. 1989
Cabe destacar que, a pesar del
tiempo trancurrido desde su aparición, la norma ISO-7498-2 (tb. publicada como
norma X.800 del ITU-TSS) mantiene su vigencia, ya que no han aparecido nuevos
mecanismos de seguridad no catalogados por la norma.
Grupos de Noticias
comp.security.*
- - - Seguridad en entornos informáticos.
comp.protocols.tcpip - -
- Discusión sobre la pila de protocolos TCP/IP
Libros
"Firewalls and Internet
Security", William Cheswick & Bellowin.
Ed. Addison-Wesley, 1990.
"Building Internet
Firewalls", Brent Chapman & Elizabeth D. Wicky.
Existe una traducción al
castellano publicada por McGraw-Hill con
el título "Construya
Firewalls para Internet".
Listas de Correo
seg-l@securenetworks.com
(¡por supuesto!)
WWW
http://www.netcraft.co.uk/security/diary.html
Muy útil para ponerse al día
con los últimos problemas encontrados en la red, especialmente si has
estado unos días desconectado.
http://www.rootshell.com/
“La casa de los exploits”
http://www.hispasec.com/
Un nuevo web dedicado a noticias acerca de seguridad informática en castellano
http://www.trinux.org/
Una distribución de Linux en disquete. Pensado para cuando se necesita disponer
de una máquina Unix con programas de seguridad y no hay ninguna a mano :(
http://www.cs.purdue.edu/coast
Casa del laboratorio COAST de
la Universidad de Purdue
5.0 Filtrado de Paquetes
5.1 ¿ En qué
consiste un fitro de paquetes ?
Un filtro de paquetes consiste
en una tupla <regla,accion> aplicada a los paquetes que circulan
por una red. Generalmente estas reglas se aplican en los niveles OSI de red,
transporte, y sesión definiendo mecanismos mediante los cuales se deniega o se
otorga el acceso a determinados servicios.
5.2 ¿ Dónde puedo
instalar un fitro de paquetes ?
El mejor sitio para instalar
un filtro de paquetes es en el router que contecta nuestra red con el exterior
(tras el punto de demarcación interna), de este modo ponemos una primera línea
de defensa en nuestra red.
Si disponemos de dos
routers, o una combinación router/circuit level firewall, se puede utilizar un
doble filtro de paquetes (dual screened subnet) tal como describen Cheswick y
Bellowin en su libro "Firewalls and Internet security".
5.3 ¿Cómo defino correctamente un filtro de paquetes ?
Con cuidado, mucho cuidado: En primer lugar toma el documento con la política de seguridad de la organización, y conviértelo en una tabla que contenga los siguientes apartados: Permitido, Servicio, sentido, y Hosts. Esto nos va a ser de mucha ayuda a la hora de codificar en el router la lista de acceso.
Veamos el siguiente ejemplo de tabla:
Interfaz:
internet-intranet1/eth0
|
Permitir |
Servicio |
Sentido |
Hosts |
|
SI |
* |
entrada/salida |
* |
|
NO |
ftp |
entrada |
172.125.9.9/24 |
|
NO |
smtp |
entrada/salida |
172.125.9.8-14 |
|
SI |
smtp |
entrada/salida |
172.125.9.10 |
Nota: Algunos gateways no permiten especificar el sentido de los paquetes a los que se va a aplicar el filtro
En la mayoría de los
routers y cortafuegos estas reglas se verifican en el orden en el que aparecen
en la tabla hasta que puede aplicarse una de ellas. Esto obliga a ordenar las
entradas en la tabla de forma que aparezcan primero las de menor ámbito de
aplicación y después las de mayor ámbito. Por ejemplo:
Interfaz:
internet-intranet/eth0
|
Permitir |
Servicio |
Sentido |
Hosts |
|
SI |
smtp |
entrada/salida |
172.125.9.10 |
|
NO |
ftp |
entrada |
172.125.0/24 |
|
NO |
ftp-data |
entrada |
172.125.9.0/24 |
|
NO |
smtp |
entrada/salida |
172.125.9.8-14 |
|
SI |
* |
entrada/salida |
* |
5.4 Como programar un filtro en un router Cisco.
En este ejemplo vamos a partir de la tabla que confeccionamos en el ejemplo anterior. Asumimos que disponemos de un router SIN NINGUNA lista de acceso (access-list) definida, y que se encuentra en funcionamiento con sus interfaces configuradas y activas (no shutdown).
Tras habernos conectado al router debemos entrar en modo preferente. Para ello teclearemos:
router>enable
Password: password (teclear la clave de enable)
Si la clave que hemos introducido es correcta, en este momento podeemos acceder a la configuración del router y modificarla. No se asuste si el prompt cambia: eso significa que hemos cambiado a modo preferente.
Para modificar la configuración ello teclearemos la orden:
router#conf t
router(config)# <--- Hemos entrado en modo de
configuracion
En primer lugar vamos a definir las listas de acceso para cada uno de los interfaces (en nuestro caso solo es uno). Debemos tener cuidado al introducirlas ya que cometer un error podría hacer que no pudiésemos alcanzar el router al aplicar las listas de acceso (si accedemos vía telnet).
Para ello tendremos que convertir cada entrada en la tabla que habíamos preparado antes en una entrada como esta:
access-list lista_acceso {permit|deny} protocolo (tcp,udp,icmp...)
dir_ip mascara_red
[dir_ip mascara_red ...]
{eq, gt, lt} {puerto, servicio}
{in, out, any }
{established,...}
De este modo, nuestra tabla
quedaría de la siguiente forma:
|
Permitir |
Servicio |
Sentido |
Hosts |
|
SI |
smtp |
entrada/salida |
172.125.9.10 |
access-list 102 permit tcp 172.125.9.10 host
eq smtp
o bien:
access-list 102 permit tcp 172.125.9.10
255.255.255.0 eq 25
|
Permitir |
Servicio |
Sentido |
Hosts |
|
NO |
ftp |
entrada |
172.125.9.0/24 |
|
NO |
ftp-data |
entrada |
172.125.9.0/24 |
access-list 102 deny tcp 172.125.9.0
255.255.255.0 eq 21
access-list 102 deny tcp 172.125.9.0
255.255.255.0 eq 22
|
Permitir |
Servicio |
Sentido |
Hosts |
|
NO |
smtp |
entrada/salida |
172.125.9.8-14 |
access-list 102 deny tcp 172.125.9.8-14
255.255.255.0 eq smtp
|
Permitir |
Servicio |
Sentido |
Hosts |
|
SI |
* |
entrada/salida |
* |
access-list 102 permit tcp any host gt 0
Resumiendo, tendremos la siguiente lista de acceso:
access-list 102 permit tcp 172.125.9.10
255.255.255.0 eq 25
access-list 102 deny tcp 172.125.9.0
255.255.255.0 eq 21
access-list 102 deny tcp 172.125.9.0
255.255.255.0 eq 22
access-list 102 deny tcp 172.125.9.8-14
255.255.255.0 eq smtp
access-list 102 permit tcp any host gt 0
Una vez definida y revisada la lista de acceso, debemos aplicarla a uno (o varios) de los interfaces de la siguiente forma:
router(config)# interface ethernet0
router(config-int)# ip access-group 102 in
En este momento el router ya está aplicando el filto que le hemos especificado para cada uno de los paquetes que atraviesan la interfaz.
Finalmente, almacenamos la configuracion del router:
#wr
5.5 ¿ Porqué mi filtro no funciona correctamente ?
Puede haber varias razones:
* Las reglas definidas no son
suficientes.
* Las reglas son suficientes;
pero su disposición no es correcta.
* El filtro anula la tabla de
routing de la máquina (poco probable)
* No permitimos que vengan de
vuelta los paquetes de conexiones ya establecidas previamente. Esto se arregla
añadiendo a nuestra lista de acceso la línea:
access-list 102 tcp permit dir_ip mascara_red gt
1023
5.9 Recursos
Libros y Manuales
Cisco Connection Documentation:
Cisco IOS reference guide,
Router Products Configuration Guide
La documentación en línea de
routers Cisco incluye ejemplos acerca de cómo definir y aplicar filtros para
cada interface. Esta documentación se encuentra también disponible para
clientes de Cisco en el WWW.
WWW
http://www.cisco.com/
http://www.core-sdi.com/Core-SDI/spanish/FreeSoft.html
PARTE IV .- SEGURIDAD
A NIVEL DE SOFTWARE
6. UN*X
6.1.- ¿ Cuáles son
algunas consideraciones que debo tomar para hacer seguro mi UN*X?
UN*X es un sistema operativo
muy potente y capaz de manejar una gran cantidad de servicios.
Desgraciadamente, esa flexibilidad provoca en ocasiones que se vuelva complejo
administrar el sistema si éste crece rápidamente. Sin embargo, lo que jamás
debemos olvidar es:
? Evitar hacer tareas no
administrativas como root: En especial, leer correo electrónico, conectarse a
internet y compilar programas nuevos. Siempre que tenga que conectarse a
su equipo vía telnet, hágalo con una cuenta de usuario normal y luego ejecute
su – para obtener privilegios de superusuario. Deshabilite también accesos al
equipo para root desde locaciones diferentes a la consola.
? Usar software de seguridad:
TCP Wrappers, Tripwire, COPS, Secure Syslog, son algunos de los títulos que
debieran aparecer en la lista de software instalado (y siendo utilizado) en el
sistema que usted utiliza.
6.2. ¿ Cómo separar cuentas shell y de correo en UN*X ?
Hay varias opciones posibles:
La más sencilla de ellas consiste en utilizar un paquete que integre el sistema de correo electrónico (smtp) y la estafeta de correos (pop). De este modo que habría que hacer sería definir en este paquete los usuarios de correo electrónico; mientras que aquellos usuarios con una cuenta shell se definirían usualmente.
Otra opción consiste en asignar una shell especial para los usuarios de correo. El cometido de esta shell será mostrar un mensaje en pantalla avisando al usuario de que no está autorizado para hacer telnet a la máquina (esto es mas conveniente que especificar como shell /usr/bin/yes ya que este programa no temina por sí mismo).
-----8<---------- Cortar Aquí ----------8<-----
#!/bin/sh
#
Archivo: /root/noshell
#
Shell que echa al usuario tras mostrarle un mensaje.
cat
<< EOF
Lo siento, usted no está autorizado para utilizar
una cuenta shell en esta máquina.
EOF
-----8<---------- Cortar Aquí
----------8<-----
De este modo, la entrada en
el archivo /etc/passwd para el usuario
sin cuenta shell en la máquina
quedaría como:
usuario:Clave:XXX:YYY:Usuario de Correo:/home/usuario:/root/noshell
donde XXX e YYY corresponden a los identificadores de usuario (UID) y grupo al que pertenece dicho usuario (GID).
No olvidemos activar los permisos de ejecución para el archivo anterior; o de lo contrario nos sería imposible ejecutar el script.
Además necesitamos dar de alta este script en el archivo /etc/shells con el fin de que el servicio de FTP funcione correctamente (algunos servidores FTP comprueban que el usuario disponga de una shell válida antes de permitirle el acceso). Para ello sólo necesitamos añadir al archivo una línea con el nombre y ruta de acceso de la shell que hemos creado:
----- Archivo /etc/shells - - -----
/bin/sh
/bin/ksh
/root/noshell <---- Esta es la
que hemos añadido.
----- Archivo /etc/shells - - -----
El problema que tiene este método es que ocasionalmente podemos quedarnos sin suficientes UID, o bien que dispongamos de excesivos directorios /home/usuario.
Hay otras muchas soluciones
tales como hacer uso de un deflector (relay) o crear un nuevo directorio raíz
mediante chroot; pero son mucho más complejas que esta.
6.3 ¿ Cómo utilizar syslog en modo remoto ?
Si la versión de syslog que está utilizando es la 1.3 o superior, debe especificar el argumento '-r' en la línea de ordenes:
/usr/sbin/syslogd -r
En versiones anteriores a la 1.3, syslog asume por defecto que se desea ejecutar en modo remoto.
Debe incluir además la siguiente línea en el archivo /etc/syslog.conf:
#
<nivel-de-mensaje> @maquina.remota
* @loggerhost.com
No es recomendable utilizar syslog en modo remoto; ya que utiliza UDP como protocolo de transporte (y por lo tanto es vulnerable a cualquier ataque de suplantación de direcciones IP <-> IP Spoofing).
Si se desea disponer de logs de una forma segura es muy recomedable redirigirlos a /dev/printer (donde dudo que nadie sea capaz de borrarlos).
Otra posible estrategia podría consistir en almacenar los logs localmente y en una o varias máquinas. De este modo se puede contrastar el contenido de los logs en varias máquinas con lo que se podría llegar a averiguar el estado real del sistema en ese momento. OJO: Hay que tener cuidado de no formar un bucle de mensajes syslog en la red.
Una opción a lo
anterior es utilizar un syslog seguro, que permita al menos saber si los logs
que tenemos almacenados en el sistema son confiables, es decir, que no han sido
alterados dolosamente. Este paquete se encuentra ya implementado y fue diseñado
por personal de Core-SDI. Lleva por nombre Secure Syslog
6.9 Recursos
Libros
"Security in
Computing" PFLEEGER, Segunda Edición (1997). Prentice-Hall
Libro especial para ofrecer un
curso completo sobre seguridad informática, el cual trata los temas de manera
clara y profunda: tanto la parte tecnica como la administrativa, pasando por
ética y delitos informáticos.
"Practical Unix and
Internet Security", SPAFFORD & GARFINKEL, Segunda Edición. O'Reilly
& Associates
Ofrece information práctica
sobre Unix, útil tanto para administadores como para usuarios. Cubre
temas de seguridad en internet tales como: wrappers, proxies, integrity
management tools, programacion segura, seguridad en servicios TCP/IP, detalles
de break-in’s, ideas para prevenir negaciones de servicio
(denial-of-service), entre otros.
WWW
http://www.cs.purdue.edu/homes/spaf/hotlists/csec-plain.html
http://www.alw.nih.gov/Security/fist-papers.html
http://www.underground.org/ - -
- (Mantenido por Aleph1)
http://www.rootshell.com/ - (exploits)
http://csrc.nist.gov/
7. WINDOWS
7.1 ¿ Cómo realizo una instalación segura de una máquina Windows NT conectada a Internet ?
* NO utilice el Sistema de
archivos FAT (x86).
* Elimine o renombre la cuenta
de administrador (Administrator).
* Active la Auditoría del
sistema. De ser posible utilice SecureLogger
como remplazo del EventLogger. (ver sección de recursos)
* Deshabilite transporte Netbios/NetBeui
sobre TCP/IP.
* Bloquee los puertos TCP/UDP
de servicios no esenciales.
* Deshabilite el privilegio de
"Acceso desde la red" (Ojo!)
Debe evitarse cualquier tipo de acceso que se realice a través del Protocolo NetBios (o sus derivados). En entorno Windows, se puede acceder de esta forma al sistema de archivos (definido como compartido); al registro de la máquina; e incluso se pueden encender y apagar estaciones remotas desde un Windows NT (documentado en el API de Win32).
Sospecho que podría ser
posible ejecutar de forma no autorizada aplicaciones y/o controles
OLE/COM/ActiveX si estos tuviesen definida una interfaz con el sistema de
archivos, o capacidad RPC.
7.2.- ¿Qué es el Back Orifice / Netbus?
Back Orifice es un programa troyano para Windows (95/NT) desarrollado por el grupo de hackers "The Cult of the Dead Cow". El programa contiene una parte servidor y otra cliente. La parte servidor consiste de un archivo de 124.928 bytes. Puede tener varios nombres y utiliza un puerto configurable para establecer comunicación cliente-servidor. Durante la instalación, se ubica en el directorio windows/system por lo que es posible buscar un ejecutable que coincida con el tamaño del archivo. El puerto default que utiliza para comunicarse es el 31337, por lo que un posible método de detección (aunque no muy efectivo, ya que este puerto puede configurarse fácilmente) es buscar si se esta escuchando ese número de puerto, mediante el programa netstat
Netbus es otro programa
troyano que en esencia, realiza las mismas funciones de Back Orifice.
7.9 Recursos
Libros
Existe un libro titulado
"Windows NT Security" recientemente traducido al castellano
(por la editorial McGraw-Hill) que puede ser una buena iniciación a la
seguridad en WNT.
WWW
http://www.core-sdi.com/Core-SDI/spanish/FreeSoft.html
Casa del Secure Logger (que
por cierto es gratuito).
Broadcast (Difusión)
Mensaje cuya dirección de
destino está codificada de forma especial para poder ser escuchado
simultáneamente por todas las máquinas conectadas al mismo segmento de red en
el que se originó.
Cracker
Delincuente informático con
amplios conocimientos sobre sistemas de cómputo (aunque esto último a veces
queda en tela de duda ;). Ver hacker.
Exploit
Código que es escrito para
automatizar el proceso de utilizar la vulnerabilidad conocida en un servicio o
sistema en específico, para obtener ilegalmente acceso a recursos que normalmente
debieran estar denegados para el individuo atacante.
Hacker
Persona con amplios
conocimientos de informática, cuya pasión es exclusivamente aprender más. Tiene
un sentido de responsabilidad y ética fuerte, así como espíritu de servicio
hacia la comunidad del cómputo en general. No confundir con cracker.
Niveles OSI
Estructura definida por ISO http://www.iso.ch/ con el objeto de normalizar la
estructura de las redes de computadoras. Se compone de las siguientes capas:
7 Aplicación
6 Presentación
5 Sesión
4 Transporte
3 Red (Network)
2 Enlace (Data Link)
1 Físico
Proxy
Un proxy actúa de forma
similar a como actúa un router con la excepción de que un router se encuentra a
nivel de red y únicamente entiende de paquetes. Un proxy sin embargo se
encuentra a nivel de aplicación; por lo que en lugar de trabajar con paquetes
trabaja con elementos de nivel de aplicación como mensajes, peticiones,
respuestas, autenticaciones, etc... resumiendo, un _proxy_ es una
entidad a nivel de APLICACION que actúa de puente entre dos extremos de
una comunicación.
Samba
Samba es el demonio (daemon)
de Unix encargado de implementar el protocolo Netbios (SMB). Mediante este
demonio se pueden compartir archivos de un sistema Unix con otras estaciones de
trabajo o servidores que hablen Netbios de IBM, NetBeui (Microsoft), etc...
Una de las características del
Protocolo NetBios consiste en que puede transportarse de forma estandar tanto sobre
TCP como sobre UDP; por lo que, en el segundo caso, podría ser muy
vulnerable a ataques de suplantación de direcciones (IP Spoofing).