Guía de Seguridad en Red

Enviado por Myrian el 21 Noviembre, 2007 - 22:33.

Artículos

Guía de Seguridad en Red

Licencia y Garantía

Este documento se presenta sin ningún tipo de garantía.
El uso de esta
guía así como de sus consejos se encuentran bajo tu
completa y
exclusiva responsabilidad. El autor no se responsabiliza de los
daños
que se puedan ocasionar al seguir esta guía, sean del tipo que
sean.

La última versión de este documento la puedes encontrar aquí

Copyright Jesús Sutil (chacal) 2005 - versión 1.0

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
published by the Free Software Foundation; with no Invariant Sections,
no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is
included in the section entitled "GNU Free
Documentation License".

Requisitos

Como requisitos para el lector, espero que no sea necesario ninguno, al
menos para entender la razón de las medidas tomadas, otra cosa
sería
ponerlas en práctica, para la cual se necesita un cierto manejo
en el
uso de un sistema GNU/Linux, puesto que voy a dar por supuesto que
tenemos instalado lo que necesitamos, y en cuanto a las
configuraciones, tampoco voy a hacer demasiado hincapié puesto
que
cualquiera con ayuda de la documentación del programa
pertinente, podrá
llevarla a cabo.

Prólogo

La seguridad, está tomando mayor
importancia día a día, puesto que cada vez hay más
conexiones a
Internet y más prolongadas, y los servidores caseros, que
están
permanentemente conectados a la red, proliferan como setas. Y eso sin
contar con los grandes servidores, aunque eso ya es otra historia
puesto que muchos de ellos están detrás de un firewall
implementado
directamente en hardware, y estos no se cansan tanto. A estos se les
suele llamar firewalls perimetrales, puesto que normalmente son los que
cubren los primeros accesos de la red, a causa de su mayor robustez,
por lo que muchas veces el peligro está dentro.

Al hablar de seguridad en red, nos referimos a seguridad
remota es decir sin que el atacante tenga acceso físico al
equipo
atacado, porque entonces no hay seguridad que valga. Por lo tanto este
aspecto no lo voy a tratar, no porque no sea interesante, sino porque
tirando del cable de la luz o simplemente pulsando el botón de
apagado,
no hay mucho que hacer, salvo proteger la bios con contraseña
para que
la secuencia de arranque no permita al intruso arrancar otros sistema
etc, etc, pero aún así, contra un destornillador todo
está perdido, y
eso si el ordenador no es pequeño, porque entonces sobra hasta
el
destornillador.

Introducción

A lo largo de esta guía, vamos
a ver los principales aspectos a tener en cuenta a la hora de proteger
un sistema. Vamos a usar un sistema GNU/Linux como banco de pruebas, es
decir como equipo atacado, y en el vamos a probar y comprobar los
distintos medios (software) que tenemos para proteger el equipo.

Hoy día al hablar de seguridad muchos lo asocian a un
firewall, y la verdad que nada más lejos de la realidad. Es
cierto que
un firewall ayuda, pero no lo es todo. Los firewalls se deberían
de
poner como último recurso, esto no quiere decir que no se
pongan, sino
que se tienen que poner después de haber configurado
correctamente la
red. Un error que causa muchos disgustos es el dejar TODA la
responsabilidad en cuanto a la seguridad a un firewall, y más
cuando se
trata de una red grande.

Nunca está de más dar un toque de atención, y
recordar que por
mucha seguridad que instalemos, si usamos passwords del tipo 12345,
todo nuestro esfuerzo será en vano.

Reconociendo en entorno

Lo primero que vamos a hacer es echar un vistazo a la seguridad
intrínseca de un sistema UNIX-like en nuestro caso GNU/Linux.

Antes de nada, dejar clara una cosa, el uso de la cuenta de
administrador (root) queda restringida a tareas de
administración. Lo
normal si necesitamos permisos de root para realizar una tarea es
utilizar 'su' el cual abre un shell con identificadores distintos.

Una tarea común a realizar por root es la administración
de
usuarios y grupos. Comprender esto es fundamental. Aquí entran
en juego
varios archivos del sistema, y todos se encuentran bajo '/etc'. Esto
archivos son passwd, shadow y group principalmente.

/etc/passwd

/etc/shadow

/etc/group

/etc/gshadow

/etc/securetty

Llegados a este punto, podemos plantearnos serias dudas en
cuanto a la seguridad se refiere. Hace unos años no importaba
que el
archivo /etc/passwd pudiera ser leído por cualquiera, puesto que
reventarlos era algo bastante difícil. La única forma era
un ataque por
diccionario o fuerza bruta. Por fuerza bruta, lo que hacemos es probar
todas las combinaciones de palabras desde '00000' a 'zzzzz', esto puede
ser útil contra contraseñas de pocos caracteres, pero
según llegamos a
7, se hace casi imposible usar este método. El ataque por
diccionario,
consiste en lo mismo pero con unas palabras ya definidas. ¿Como
hacemos
esto?, para esta ardua labor existen varios programas, entre ellos el
que más me gusta es John
the Ripper,
el cual cifra y compara todas las palabras que le metamos por
diccionario o en modo incremental con el password cifrado que nosotros
queramos.

John the Ripper ofrece
muchas opciones, y es muy rápido. Aunque parezca que este tipo
de
programas solo valen para hacer el mal, un administrador los
encontrará
muy útiles para buscar leak passwords, es decir
contraseñas del tipo
'casa', 'pepe','12345', etc. , de esta manera puede poner sobre aviso a
ese usuario para que la cambie.

Aquí no voy a explicar el funcionamiento de este crackeador de
contraseñas, por la red podéis encontrar numerosos
manuales con
ejemplos prácticos, pero lo mejor es intentar ponerlos en
práctica
aunque sea de forma local con las claves de nuestro propio ordenador.

Reconociendo en entorno II - Servidores y características.

Vamos
a ver servicios de red típicos, como pueden ser de TFP, http,
ssh,
telnet ... y los problemas de seguridad intrínsecos que nos
pueden
plantear.

Telnet

SSH

FTP

aquí

Secure FTP

HTTP

SMTP

POP-IMAP

DNS

Samba

Existen muchos otros servicios (muchos de ellos obsoletos),
como por ejemplo DHCP, NFS etc pero no los vamos a tratar de forma
concreta. Solo daré cuenta de que un servidor DHCP, puede llegar
a
agotar sus recursos disponibles por medio de un ataque DOS.

Siendo paranoico habría que ejecutar los procesos servidor con
chroot (los que pueden ...), aunque en algunos no es muy recomendable,
pero no voy a entrar en casos concretos, para eso hay que leerse la
documentación de cada servidor.

También es lógico ejecutar esos procesos como usuarios NO
privilegiados
(y menos como root), por ejemplo como nobody. Tampoco hay que caer en
la dinámica de hacer que nobody haga todo, puesto que muchas
veces, y
sobre todo en servidores administrados por varios admin, se usa a
nobody (sin saberlo) para todo, convirtiéndolo en un usuario con
muchos
permisos. (Aunque hay algunos servicios que SI hay que ejecutarlos como
root.)

Reconociendo en entorno III - Parches de Seguridad.

Desde
hace tiempo, GCC incluye en el compilador las extensiones para compilar
aplicaciones con protección extra y evitar así que las
aplicaciones
escriban en direcciones de memoria que NO deberían escribir.

En cuanto a los parches de seguridad disponibles para el
Kernel, hay varios, destaco principalmente, el parche Skas, con el que
conseguimos "Separate Kernel Address Space" es decir un espacio de
direcciones separado.

Como comentario, hacer notar que SuSE
desde hace tiempo trae de serie el parche skas.

Métodos avanzados de seguridad

De forma
intuitiva, lo que voy a proponer, consiste en hacer que cada servicio
(servidor), se ejecute con un kernel distinto. Esto lo vamos a
conseguir mediante máquinas virtuales.

Existen varios proyectos, pero hay concretamente 2 que para
nuestro cometido son mucho más flexibles, y consumen muy pocos
recursos. Uno es User-Mode-Linux
y el otro es VServer.

Con esto conseguimos aislar mejor cada servicio, teniendo que romper la
seguridad de un kernel adicional, y en este podemos incrementar mucho
la seguridad, concretamente con UML no necesitamos a root para (casi)
nada.

Esta técnica cada día es más usada entre las
empresas de hosting para ofrecer servidores virtuales a sus clientes.

Configuración de red

Aquí vamos a ver los archivos típicos de
configuración en un sistema GNU/Linux

/etc/inetd.conf

Como ejemplo, podemos ver una configuración para el puerto
discard

Por norma general NO es conveniente tener servicios en inetd,
así que deshabilitaremos todos los que podamos.

/etc/services

www 80/tcp http # WorldWideWeb HTTP

/etc/hosts.allow y /etc/hosts.deny

Al final del /etc/hosts.deny es bastante frecuente encontrarnos con
líneas como estas

Con las cuales sin la conexión no ha sido aceptada en
/etc/hosts.allow, por defecto el acceso será denegado.

Si no existe archivo de control de acceso, se tratará como que
existe un archivo vacío

Logs - Seguridad Pasiva

Esta es una parte fundamental
de cualquier sistema que se precie, y un buen administrador debe de
revisar a menudo los logs, para comprobar si se ha puesto en juego la
integridad del sistema, (y otros aspectos que no vamos a tratar
aquí).

En Linux, la herramienta de log es syslogd, el archivo de
configuración principal se encuentra en /etc/syslog.conf, en el
se
indica que se loguea y donde se guardan estos logs. Para núcleo
(kernel), el login se hace mediante klogd. Lo normal es que klogd
envíe
sus mensajes a syslogd, pero no siempre es así, sobre todo en
los
eventos de alta prioridad, que directamente salen por pantalla. Aunque
bueno, esto siempre es configurable a gusto del consumidor.

Y como siempre podemos encontrar información adicional en los
respectivos 'man'.

Como regla general los logs se encuentran dentro del directorio
/var/log. Muchos programas, manejan sus propios logs, y suelen crear
una carpeta con el nombre del programa dentro de /var/log.

Una cosa muy importante a tener en cuenta en los logs, sean de
la naturaleza que sean, es que la configuración que viene por
defecto
suele estar bien para ir tirando. Pero hay veces que un servicio
necesita información adicional, pero ojo, no la vayamos a
preparar. Los
logs ocupan espacio, y podemos llegar a hacernos un DOS a nosotros
mismos, así como llegar a saturar nuestro disco. Por ello hay
que saber
lo que se hace, y leer detenidamente la documentación de cada
uno.

Los logs aunque pueda parecer raro, contienen información
valiosa. Hay veces en las que conviene enviar los logs a un servidor
aislado que exclusivamente trate nuestros logs. De esta forma si un
agresor se hace con nuestra máquina, podríamos seguir
teniendo la baza
de los logs, es decir, la certeza de que no han sido modificados o
borrados, eliminando así cualquier rastro. Por eso aunque sea
más
seguro el cifrar los logs, no tiene mucho sentido si en atacante tiene
acceso a ellos, puesto que nos da igual no tener logs que tenerlos
modificados. Realmente no nos da igual, porque si el atacante modifica
los logs, podemos tenerle espiando nuestro sistema indefinidamente sin
que nosotros nos demos cuenta. Aún así veo más
conveniente el enviarlos
a otro servidor.

Aunque creo que es evidente, dentro de nuestro sistema lo lógico
es que nadie pueda ver nuestros logs, y menos modificarlos, por eso les
daremos permisos únicamente a root y su grupo (man chown y man
chmod).

zcat

Ahora vamos a ver algunos de los log más comunes y útiles
para nuestro
propósito, y como habilitar otros. Por orden alfabético,
nos
encontramos con

/var/log/auth.log

/var/log/kern.log

Aquí se almacenan principalmente los logs producidos por klogd.

/var/log/lastlog

/var/log/messages

Si en nuestro sistema se permite (por necesidad claro está) que
los usuarios tengan cuenta shell en el servidor y se logueen,
deberíamos tener activos tanto el faillog, cuyo log se encuentra
normalmente en /var/log/faillog, para poder controlar las cuentas a las
que se intenta acceder mediante "try'n'error" (ensayo y error), porque
puede ser que el usuario haya olvidado su contraseña, pero
también
puede ser que alguien de forma malintencionada esté intentando
acceder
al sistema con esa cuenta.

En el archivo /etc/login.defs podemos definir que los intentos
de log de superusuario se guarden en por ejemplo /var/log/sulog, sin
más que editar el /etc/login.defs, y escribir (o descomentar) la
línea
SULOG_FILE /var/log/sulog, y SYSLOG_SU_ENAB yes. Esto al igual que lo
comentado anteriormente, puede ser útil. Y en caso de sufrir
múltiples
intentos para escalar permisos, podemos bloquear temporalmente esta
cuenta.

Controlar a los usuarios

Controlar a usuarios con una cuenta shell es una tarea un tanto
tediosa y pesada. Y aunque creamos tener controlados todos los aspectos
posibles (el usuario no puede hacer nada no permitido), hay que tener
en cuenta que ese usuario puede consumir mucha CPU, tiempo (y espacio)
de disco, memoria, etc. etc., por eso hay que regularlo.

Mediante quote, podemos evitar que los usuarios nos saturen el
disco. Para habilitar las quotas, necesitamos tenerlas habilitadas en
el kernel, en caso de no tenerlas, toca recompilar.

Para controlar la memoria, el tiempo de acceso a disco y demás
opciones, lo podemos hacer con ulimit, pero ya está obsoleta,
así que
lo hacemos con getrlimit, getusage y setrlimit. Para más
información
mirar las correspondientes páginas del man.

Herramientas I - Escaneadores de Red

Aunque
hay muchos, los más destacables hoy día por sus
múltiples
funcionalidades que los hacen imprescindibles para cualquier
administrador de red son Nesus y NMap (Network MAPper).

Nessus es un escaneador de redes un tanto peculiar, y es que consta de
dos partes, cliente y servidor (aunque se pueden instalar los dos en el
mismo sistema) y además, se pueden ver informes sobre la
vulnerabilidad
y como explotarla, pero como no todo es malo, también los hay
para
saber como evitarla. La parte servidor es la que escanea, y la parte
cliente no es más que el interfaz de usuario.

NMap es quizás el escaneador de red más potente que
existe,
tiene una gran cantidad de opciones de escaneo como escaneo Stealth (lo
cual es muy útil para escanear sin ser descubierto) o
búsqueda de
conexiones semiabiertas. Es ideal para comprobar nuestros sistemas (y a
veces los de otro, pero solo por hacer un favor :)

Herramientas II - Herramientas de Detección de Intrusos

Un
sistema de detección de intrusos (IDS - Intrusion Detection
System), lo
que hace es buscar patrones sospechosos previamente definidos. En
principio no están diseñados para evitar un ataque solo
para preverlo y
monitorizarlo, estos son los llamados IDS pasivos. Los que si
actúan
sobre el "presunto" atacante son los IDS activos, estos lo que hacen es
tirar la conexión o bloquearla (si es posible).

Como ejemplo de patrón sospechoso, principalmente tenemos un
escaneo de puertos sea cual sea su magnitud.

Snort lo que hace es precisamente
lo que hemos comentado, rastrea los paquetes que circulan por la red y
al encontrar un paquete sospechoso lo loguea, de esa manera tendremos
localizado el ataque. Snort puede funcionar como HIDS (Host) o NIDS
(Network). Normalmente el uso como NIDS lo llevan a cabo gateways
perimetrales que tienen otras funciones como firewall etc, y son
configurados como IDS activos, puesto que la conexión tiene que
pasar
por ellos y de esa forma la pueden bloquear.

La configuración de Snort se puede llevar a cabo de manera
fácil junto con mysql para guardar los logs en una base de datos
y con ACID (Analisys
Console for Intrusion Databases) para poder verlos de una forma
cómoda.

Una ventaja de Snort es que tiene gran cantidad de filtros ya
definidos, así como actualizaciones en las que se van
añadiendo nuevos
métodos que van apareciendo.

A la hora de configurar un IDS, hay que tener muy en cuenta la
velocidad de la red y el tráfico que soporta, puesto que se
puede
saturar, y colapsar la red (o el segmento que controla).

PortSentry
es un IDS especial con el cual podemos conseguir "burlarnos" del
atacante. Lo que hace Portsentry es escuchar en un montón de
puertos.
Es decir que si un atacante nos escanea verá que hay un
montón de
puertos abiertos, pero NO es cierto, pero a ojos del atacante puede
resultar tentador.

Si tenemos un servicio escuchando en un puerto, el Portsentry
lógicamente no estará escuchando en ese puerto puesto que
ya hay un
servicio haciéndolo. Por eso cuanto mayor sea el número
de servicios
que tiene el servidor menos efectivo será el Portsentry. Por eso
también es recomendable tenerlo en un router.

En cualquier caso a priori no se puede determinar que puertos
son "reales" sin que salte la alarma, y es aquí donde radica el
potencial de Portsentry. Si intentamos establece una conexión
remota
con un puerto abierto por Portsentry, automáticamente lo loguea
y tira
la conexión. Esto hace que aparezcan muchos logs, aunque si lo
pensamos
detenidamente nos damos cuenta que ese alguien ya está buscando
"algo
más".

En cambio, si el atacante envía un SYN y nosotros enviamos un
SYN-ACK en nos mandará un RESET, y de esta manera no
terminará la
conexión (Three Way Handshake) y no llegará a existir
log. Esta técnica
se denomina Stealth Scan, y la podemos llevar a cabo con NMap con la
opción "-sS".

Pero la historia no acaba aquí, porque Portsentry también
puede detectar stealth scan, pero no a nivel de establecimiento de
conexión, lo cual lo hace más difícil de detectar,
pero aún así
Portsentry se porta excepcionalmente bien.

Lo comentado es aplicable a escaneos TCP no a UDP. Comentar
también que los escaneos UDP son menos fiables y además
bastante más
lentos al no ser un protocolo orientado a conexión. Existen
muchas más
formas de escaneo con los que se puede intentar engañar al IDS
para que
no loguee el escaneo de puertos, pero sea como sea si tenemos el
Portsentry en modo no stealth, no hay forma de diferenciar los
realmente abiertos de los que el Portsentry "abre", por lo que
acabará
siendo logueado.

Configurar unas buenas reglas de Firewall (Iptables) siempre
es altamente recomendable aunque en el caso del Portsentry pueda
interferir negativamente, es decir se puede ver que está el
Portsentry
activo. Pero con una configuración adecuada se puede subsanar.
Básicamente consistiría en abrir los puertos en los que
el Portsentry
está escuchando.

Herramientas III - Sniffers

Hoy día Snort es
uno de los sniffers más usados gracias al éxito que ha
tenido con IDS
como ya comentábamos en el punto Herramientas II, al ser un
solución
rápida y barata sobretodo si las comparamos con ISS RealSecure.

Ethereal es un sniffer capaz de
reconocer casi todos los protocolos existentes. Tiene una gran potencia
gracias a sus filtros que usan el mismo formato que el tcpdump.
Comentar que su uso es bastante complejo.

Un sniffer por software necesita de un equipo bastante potente, para
que pueda escanear todo lo que pasa.

HoneyNETs - HoneyPOTs

Para "cazar" a los
malos podemos recurrir a los HoneyPOTs que no son más que
ordenadores
trampa, que se hacen pasar por sistemas vulnerables o por el servidor
al que teóricamente se está lanzando el ataque.

Las configuraciones son múltiples y variadas, pero siempre
dependientes de la cantidad de dinero empleada.

Los usos pueden ser muchos, desde guardar/loguear el tráfico de
un posible ataque, hasta ralentizarlo.

En linux tenemos honeyd
principalmente. Lo que hacen es simular nuevos hosts en la red con
determinados servicios, para que se hagan pasar por lo que queramos.
Como ya comentaba antes, la creación de honeypot-(nets) depende
mucho
del dinero invertido, programas como honeyd nos abaratan mucho los
costes, pero no dan tanta versatilidad ni potencia como una red real

Una implementación bastante simple pero efectiva es usar un
pequeño
router de 4 u 8 puertos para segmentar la red en subredes, de esta
forma podemos usar el router como firewall para esa pequeña red,
y
dentro de esa red poner un honeypot con los puertos típicos
abiertos
mediante NAT en el router. Después en los otros ordenadores,
abrimos
los servicios que necesitemos en puertos elevados, de esa forma
cualquier escaneo que a priori no conozca los puertos será
logueado.

A la hora de instalar un honeypot, podemos hacer que sea mucho
más "dulce" simulando además que es un sistema operativo
totalmente
diferente o lleno de bugs conocidos, para lograr entretener más
al
atacante.

Si nuestra red en muy extensa viene muy bien centralizar los
logs en una colmena, para que en caso de tener que hacer uso de ellos
no sea una tarea excesivamente tediosa el tener que ir recolectando
logs de todos los honeypots.

Copias de Seguridad

La copias de seguridad
hay que acostumbrarse a hacerlas periódicamente. Por ejemplo
cada 3
meses en un formato óptico (cds, dvds) y cada mes en una
réplica (otros
discos duros). Las cintas a pesar de ser más lentas tampoco
están mal
si la disponibilidad en caso de fallo no es inmediata.

Si eres de los que te preguntas, ¿por qué hacer copias de
seguridad?, la respuesta es, "por lo que pueda pasar". Esto es un poco
como la ley de Murphi, nunca pasa nada hasta que pasa. Ya sea por un
"rm *" de forma accidental desde un mal sitio (por no poner otros
parámetros...), pasando por un apagón o porque al disco
duro le llegó
la hora o como venimos viendo, por un ataque.

Para este propósito podemos usar bacula, con el cual podemos
centralizar el backup. Esto es especialmente útil en redes
heterogéneas.

¿Qué hacer si somos atacados?

Esto es una
decisión que tiene que tener en cuenta muchos factores, pero
sobre todo
saber si ese ataque se sigue produciendo en ese momento o ya ha
finalizado.

Si el ataque se está produciendo, es posible identificar al
atacante, y también es recomendable sobre todo a la hora de
tomar
acciones legales contra el agresor. Pero lo más acuciante es
comprobar
la integridad del sistema y hasta el punto al que ha llegado la
incidencia. Una vez hecho esto hay que parchear el agujero de
seguridad, ya sea con una actualización (en caso de no existir
actualización, reportarlo) o tirando el servicio hasta que se
pueda
actualizar.

En caso de no poder actualizar y no poder prescindir del servicio,
habría que iniciar el servicio con un mínimo de opciones
(si es
posible) y optar por bloquear la IP del atacante y si pertenece a un
ISP identificado, quizás convenga bloquear el rango completo de
IP's de
ese ISP, especialmente si el ataque viene desde otro país con un
idioma
distinto al que damos desde ese servicio, puesto que el número
de
clientes potenciales desde esas IP's será bajo y hay más
posibilidades
de librarnos de un segundo ataque.

Si el ataque ya se ha producido, tenemos que jugar con lo que
tenemos que normalmente son los logs. Y digo "normalmente" porque no
siempre los tenemos. Por este motivo toman un especial sentido las
HoneyNETs.

Tomar medidas legales no siempre puede resultar adecuado,
sobretodo en el caso de una empresa que haga gala de la seguridad, lo
cual llevaría a una publicidad muy poco adecuada.

A tener en cuenta a la hora de conectar un PC a la red

Conectar
un PC a Internet entraña sus riesgos. Normalmente un ordenador
personal
no está encendido las 24 horas como lo está un servidor
por lo tanto la
probabilidad de sufrir un ataque es menor. Pero esto no quiere decir
que podamos descuidar la seguridad.

Si alguien toma el control del sistema y no nos damos cuenta, todo lo
que se haga desde nuestro PC es como si lo hubiéramos hecho
nosotros,
lo cual puede traer desagradable sorpresas.

Si usamos un sistema "unix-like" tampoco hay que volverse paranoico con
estos temas si el uso que le damos va a ser de PC de sobremesa.

A pesar de que la seguridad en sistema linux medianamente bien
configurado es bastante alta, sigue sin ser un sistema adecuado para
guardar información sensible. Para guardar información
sensible, de
forma simple y rápida, se puede recurrir al cifrado, ¡pero
OJO! no
dejemos las claves en el ordenador, si es posible las movemos a un CD o
un lápiz USB.

NOTAS

amule

Conclusiones

Con esta guía pretendo dar una visión general sin entrar
en demasiados
detalles sobre métodos de seguridad en red con los que es estoy
más
familiarizado, concretamente con sistemas unix-like y más
concretamente
debian.
La idea principal que quiero dejar patente es que la seguridad no es
algo secundario y de lo que se pueda prescindir, sino que es muy
necesario.

En estas breves conclusiones voy a comentar un par de aspectos por los
que he pasado de puntillas en el resto de la guía.

- Un aspecto por el que no he pasado es el de los antivirus, y
no lo he hecho por la simple razón de que no existen. Esta
afirmación
es un tanto arbitraria e incierta, porque si existen virus para
sistemas Unix-like, pero tal y como está diseñado su
impacto sería
mínimo. De hecho el término virus en Unix se confunde con
el de
troyano. No obstante existen potentes antivirus para sistemas Unix-like
por ejemplo el ClamAV, aunque su
uso común es para buscar en busca de virus en un gateway que da
salida a una red con sistemas NO Unix-like.

- Otro tipo de ataque del cual no he hecho una mención
explícita, es un
ataque DOS (Denial Of Service - Denegación de Servicio). La
problemática de estos ataques es que son casi imposibles de
evitar sin
tener ningún tipo de secuelas, ya sea carga de cpu, una
reducción del
ancho de banda etc. Son un tipo de ataques muy molestos porque no
tienen solución directa, es decir que cualquier sistema los
puede
sufrir, otra cosa es que ese sistema que lo sufre sea capaz de aguantar
la embestida sin colgarse.

Referencias

Sería imposible llegar a nombrar
todas las fuentes de información que directa o indirectamente he
consultado, o he encontrado por el camino, durante todo el tiempo que
estado escribiendo esta guía. Por lo tanto estas Referencias
más bien
se van a convertir en agradecimientos a todos aquellos que colaboran en
la gran comunidad que se ha formado en torno a la red. Sobre todo a la
comunidad OPEN SOURCE.

Última Edición 05 Apr 06 02:39 CDT

Artículo publicado en www.esdebian.org

Inicie sesión o regístrese para enviar comentarios
2875 lecturas

esLinux

Guía de Seguridad en Red