¿Como puedo saber si un sistema Linux ha sido comprometido? (TEXTO)

[Rojodos]

Bueno, haciendo "limpieza" en mi PC, pues me encontrado unos 70 textos xD, de diversa indole. Uno de los que mas me gusto, y que he vuelto a leer es este. Creo que a los que traten de "asaltar" un sistema Linux les vendra muy bien, asi como a los que traten de hacer auditorias de seguridad post ataque.

Creo que lo saque en su tiempo de www.infohackers.org, pero no estoy seguro. Si alguien sabe de donde salio este texto, por favor, me lo comunique y sera añadido.

Que lo disfruteis

---------------------------------------------------------------------
---------------------------------------------------------------------

Cómo puedo saber si un sistema Linux ha sido comprometido?

Examina los ficheros de log buscando conexiones desde lugares inusuales o cualquier actividad fuera de lo normal. Por ejemplo, mira el ultimo log, "process accounting", todos los logs creados por syslog, y otros logs de seguridad. Si tu firewall o tu router escriben logs en lugares distintos de donde los escribe el sistema estudiado, recuerda chequear también esos logs. Esta no es una garantía completa a no ser que "los logs se escriban en un append-only media"; muchos intrusos editan los ficheros de log para intentar ocultar su actividad.

Busca los ficheros con los bits setid y setgid activados (especialmente los setuid de root) en todo el sistema. Los intrusos suelen dejar copias de programas como /bin/sh o /bin/time con el bit "setuid" activado para permitirles acceso a root mas tarde. Se puede usar el programa de UNIX find(1) para encontrar ficheros con setuid y/o setgid activados.

Comprueba los binarios del sistema para asegurarte de que no han sido alterados. Hay intrusos que cambian programas en sistemas UNIX tales como login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync, cualquier binario referenciado en /etc/inetd.conf, y otros programas de red y del sistema críticos, así como librerías de objetos compartidas.

Ten cuidado a la hora de confiar en los backups; tus backups pueden contener a su vez caballos de Troya.

Comprueba que en tu sistema no existan programas no autorizados de monitorización de red, comúnmente llamados sniffer "packet sniffer". Un intruso puede usar un sniffer para capturar información de la cuenta y password de un usuario.

Examina todos los ficheros que son ejecutados por cron y at. Hay intrusos que dejan puertas traseras en ficheros ejecutados por cron o enviados a at, pues permiten al intruso volver al sistema.

También, verifica que todos los ficheros/programas referenciados por los jobs de cron y at, y los ficheros del job en sí mismos, no tienen permisos de escritura para todo el mundo.

Comprueba que no haya servicios no autorizados. Inspecciona el /etc/inetd.conf buscando cambios no autorizados. Busca entradas que ejecuten un programa shell, y verifica todos los programas especificados en /etc/inetd.conf para comprobar que son correctos y que no han sido reemplazados por un caballo de Troya.

También chequea servicios legítimos que hayas comentado en el /etc/inetd.conf. Algún intruso puede haber habilitado un servicio que previamente habías deshabilitado o sustituir el programa inetd por un caballo de Troya.

Examina el fichero /etc/passwd y comprueba las modificaciones de dicho fichero. Verifica que no haya nuevas cuentas creadas sin autorización, cuentas sin password, o cambios en el UID (especialmente UID 0).

Comprueba que no existan entradas no autorizadas en los ficheros de configuración de red y del sistema. En particular, busca entradas con '+' y nombres de hosts externos no apropiados en el fichero /etc/hosts.equiv, /etc/hosts.lpd, y en todos los ficheros .rhosts. Estos ficheros no deben tener permisos de escritura para todo el mundo. Además, confirma que estos ficheros existían previamente a ninguna intrusión y que no han sido creados por el intruso.

Busca por todo el sistema ficheros raros u ocultos, pues estos ficheros pueden usarse para ocultar herramientas e información.

Examina todas las maquinas de la red local cuando busques señales de una intrusión. Si la seguridad de un host se ha visto comprometida, la seguridad de otros en la red también.

CUOTAS

Las cuotas permiten especificar limites en dos aspectos del almacenamiento en disco: El numero de inodos que puede poseer un usuario o un grupo; y el  número de bloques de disco que puede ocupar un usuario o un grupo.

La idea que se esconde detrás de las cuotas es que se obliga a los usuarios a mantenerse debajo de su limite de consumo de disco, quitándoles su habilidad de consumir espacio ilimitado de disco en un sistema.

Las cuotas se manejan en base al usuario y al sistema de ficheros. Si el usuario espera crear ficheros en mas de un sistema de ficheros, las cuotas deben activarse en cada sistema de ficheros por separado.

DETECCION DE INTRUSOS MEDIANTE ANALISIS DE HUELLAS

Ficheros que guardan registros:

utmp: Guarda un registro (log) de los usuarios que están utilizando el sistema mientras estan conectados al sistema. Directorios: /var/adm/utmp y /etc/utmp

wtmp: Guarda un log cada vez que un usuario se introduce en el sistema o sale del sistema. Directorios: /var/adm/wtmp y /etc/wtmp

lastlog: Guarda un log del momento exacto en que un usuario entro por ultima vez. Directorio: /var/adm/lastlog

acct o pacct: Registra todos los comandos ejecutados por cada usuario (aunque no registra los argumentos con que dichos comandos fueron ejecutados). Directorio: /var/adm/acct

Comandos que permiten ver el estado del sistema:

who y users: Permite saber quién esta conectado al sistema en el momento en que ejecutamos el comando.

finger: Lo mismo que el comando who, con el añadido de que podemos saber qué usuarios están conectados a una determinada máquina en el momento en que ejecutamos el comando.

last: Muestra la última vez que se conecto un usuario. Last toma la información que saca en pantalla del fichero wtmp.

ps: Permite saber qué procesos estan siendo ejecutados por el sistema y qué usuarios los ejecutan.

accton: Activa un proceso llamado accounting, que es el que proporciona informacion al fichero acct.

lastcomm: Permite saber qué comandos han ejecutado los usuarios. Lastcomm toma la información que saca por pantalla del fichero acct.

Por lo tanto, si queremos borrar nuestras huellas del sistema, bastar con borrar cualquier log relativo a nuestro usuario de los ficheros utmp, wtmp y acct. Esto se puede hacer de dos formas:

No borramos los ficheros pero los dejamos con cero bytes.

Editar los ficheros con un 'zapper' que pueden borrar los datos relativos a un usuario; en particular de estos ficheros dejando el resto de los datos intacto.

Eliminar huellas de acct

Es bastante complicado borrar nuestras huellas de este fichero; de hecho no se pueden borrar del todo, aunque se puede reducir a una mínima parte nuestra presencia en el sistema.

Más sistemas de log:

Syslog: Mediante el syslog se puede configurar de tal forma que determinados programas, procesos o aplicaciones, generen mensajes que son enviados a determinados ficheros donde quedan registrados dichos mensajes. Este fichero sí puede ser editado en modo texto y puede ser analizado para ver dónde hemos ido dejando rastros y posteriormente borrar esas huellas. Aunque por supuesto, necesitaremos ser root para poder hacerlo.
TCP-Wrapper: Se trata de una aplicacion que proporciona una serie de mecanismos para el registro y filtro de aquellos servicios invocados o llamados a través del inetd (internet daemon). Con esta herramienta el administrador posee un control absoluto de las conexiones hacia y desde su máquina y es informado en todo momento de las conexiones que se han hecho desde su maquina y hacia su máquina.

------------------------------------------------------------------------
------------------------------------------------------------------------

[zhyzura]

excelente texto, no lo habia leido hasta hoy.
(el de hacking en unix lo tendre que traducir primero para poderlo leer... es una lata no saber ingles y la verdad me siento menos :'( ).

pero me ha entrado la curiosidad con esta parte:

Eliminar huellas de acct

Es bastante complicado borrar nuestras huellas de este fichero; de hecho no se pueden borrar del todo, aunque se puede reducir a una mínima parte nuestra presencia en el sistema.

haber si me quedo claro....
a la hora de que yo intento borrar mis huellas con un zapper (en especial este fichero, que es el mas me llamo la atencion), ¿quedara registrado en este archivo que utilice el zapper?.
en caso de ser asi...quedaria reistrado el proceso con mi nombre de usuario.

lo que yo yengo pensado seria si es posible dejar un algun script que modificara o "borrara todo su contenido", pero no ejecutarlo nosotros, sino dejarlo como "cebo" para que otro usuario lo ejecutara y automaticamente se borrara.
al hacer esto, el proceso ya no seria ejecutado por nossotros sino por otro user (que la pagara por nosotros xDDD).

es algo loca mi idea pero me gustaria alguna opinion por parte vuestra.

[Rojodos]

El tema de los logs en Unix es siempre un cachondeo. Si el administrador del sistema Unix/Linux es bueno, es casi imposible eliminar tu presencia en el sistema.

No solo me refiero a los logs de /var/log, sino que seguramente, tendra por ejemplo un sistema "remoto" de logs (syslog o syslog-ng permiten enviar los logs a otros sistemas por UDP, a otro demonio syslog, con lo que tendriamos que asaltar ese otro sistema para eliminar los logs). Antes de nada, para usar el zapper debes ser root o similiar (UID 0). Y claro, la actividad del zapper quedara reflejada, pero solo, como que la uso el usuario root. No tendran datos de la IP por ejemplo, si el zapper los elimina.

Hay tecnicas incluso, que recomiendan mandar una enorme cantidad de informacion a los logs,y que estos, cuando alcanzan un tamaño especificado, se rotan. Cuando hayan rotado todos (o los que estes tratando de rotar), pues tus huellas "desaparecen". Pero creo que esta tecnica, con los HDs de hoy en dia, es completamente inutil.

Por no hablar de si hay un IDS presente en el sistema (Snort, LIDS...) entonces ya la cosa se complica, pues precisamente estan hechos para que te detecten y tu no puedas hacer nada xD.

Yo creo que la mejor forma, en vez de usar scripts a traves de cron o algo asi (eso es muy sospechoso, ver la tabla del cron, y ver que rula un programa zapper) es a traves de rootkits (aparte de cepillarte los logs con buenos zappers, que editen los logs ascii de /var/log/ y que tambien editen los ficheros binarios /var/log/wtmp y /var/log/utmp). Con un buen rootkit, y si es posible, a nivel de LKM, es practicamente imposible que te detecten, a no ser que detecten el rootkit.

Pero el problema de los rootkits, es Tripwire xDDDDDDD. Supongo que sabeis la principal funcion de este programa. El caso es que mientras mejor sea el admin y mas medidas de defensa tenga, pues mas chungo lo tienes....

Me podria estar aki hablando de la seguridad de Unix un buen rato (aunque no lo parezca, he leido MUCHISIMO sobre el tema), pero tampoco es plan.

Salu2

[zhyzura]

Por no hablar de si hay un IDS presente en el sistema (Snort, LIDS...) entonces ya la cosa se complica, pues precisamente estan hechos para que te detecten y tu no puedas hacer nada xD.

para los IDS se podria realizar un ataque en las debilidades inherentes en el protocolo del RPC.
Un método de la evasión constituye un ataque del Negacio de Servicio (DOS) contra los servidores y las escalas del RPC fácilmente y rápidamente en un ataque distribuido completo del Negacion de Servicio (DDoS).

ademas de que los IDS tienes otros incombenientes.
los NIDS tiene una fuerte debilidad en los paquetes cifrados, cosa que no ocurre con los HIDS.
y los HIDS no son totalmente seguros en ataques desde dentro de una red.


En la implementacion de Tripwire, es donde no tengo ni un pero .

[Rojodos]

Los ultimos IDS son realmente la leche, hacen de todo (vease como ya he dicho, Snort o LIDS).

De los HIBS o los NIDS no he leido mucho, si nos puedes contar....

Tripwire es un programa bastante "sencillo". Lo unico que hace es hacer un md5 a todos o gran parte de los ficheros de un sistema Unix/Linux (los mas importantes, normalmente, se salta los directorios personales de home)y guardarlos en una BD.

Si tu metes un rootkit a nivel de LKM por ejemplo (tambien puede ser modificando un binario o una libreria, infectado sources, paquetes RPM o .deb, etc...), como todos los rootkits, pues tienes que modificar librerias e incluso binarios.

Si el adminha usado Tripwire, solo tiene que volverlo a pasar. El programa detectara inmediatamenet que el MD5 de los ficheros (los infectados o troyanizados) no coinciden con la BD guardada. Entonces el admin se dara cuenta de que algo falla...

Por supuesto, el hacker lo unico que tiene que hacer para librarse de este problema, es modificar la BD de Tripwire... pero y si el admin se lleva dicha BD todos los dias en su USB o en un CD regrabable?

Pues.... ajo y agua xD

Salu2

[zhyzura]

como tu ya sabras los IDS (sistemas de detección de intrusos), alertan a los administradores de ataques hechos con exito en un sistema o incluso de los que se estan llevando a cabo.
los IDS se dividen a su vez en dos clases: NIDS (Network Intrusion Detection Systems, basados en la observación de la red) y HIDS (Host Intrusion Detection Systems, basados en agentes instalados en los host a vigilar).

los NIDS observan todo el trasiego de paquetes, buscando anomalias en ellos las cuales pueden alertarnos de una intrusion. este sistema tiene muy buenas ventajas ya que se despliega rapidamente en la red y alerta de una manera asombrosa (en tiempo real para ser excatos xDD), sin importar la plataforma en la que nos encontremos, la manera en que detecta las anomalias es por medio de los paquetes y la ip de la maquina que los esta realizando.
una de las debilidades que le veo a los NIDS, es que tiene una mayor dificultad para revisar los paquetes cifrados(algo que dije mas arriba), ademas de que al aumentar la velocidad de envio de los paquetes (que muchas veces alcanza  los Gbps, si hay mucho trafico es mas dificil la tarea).

en el caso de los HIDS, estan formados por un conjunto de agentes que se instalan en los host a vigilar y un gestor o servidor con el que éstos se comunican. Cada agente monitoriza los logs y eventos de seguridad en la máquina que lo acoge.(suena mejor no lo creen  ). tiene mejores ventajas ya que puede revisar todo el trafico difrado que pasa por la red, y ademas alerta de ataques desde adentro de esta. pero...como todo siempre hay algun incombeniente, y en este caso es la lentitud con que responde y ademas su dificil implantacion(por lo mismo de que se utiliza en varis maquinas, son diferentes las plataformas).


por cierto si no me equivoco hay una manera de evadir el snort y esta es utilizando el "fragroute". deja me informo bien para poder poner el procedimiento a seguir (tenia ese texto por alguna parte pero ahora no lo encuentro, mejor mañana lo busco en mi casa, aqui en el trabajo no lo tengo xDDD)

[zhyzura]

pues me he encontrado el texto en cual se demuestra como "fragroute" evade la deteccion por snort  .


¿Cómo Fragroute evade la detección de NIDS? 
Michael Holstein

Los sistemas basados red de la detección de la intrusión (NIDS) se configuran típicamente supervisan pasivo tráfico de la red en el segmento por un golpecito del hardware o la otra táctica tal como uso del comando del switchport-monitor (IOS del Cisco) que permite que el NIDS supervise, y en algunos casos, inyectan el tráfico para todos los anfitriones y destinaciones que pasan con el segmento.

La mayoría de los sistemas de NIDS son patrón basado, requiriendo firmas grandes de un sistema (típicamente ~1500+) alertar basado en una combinación específica de las banderas del TCP en el jefe, o un patrón del sistema en la carga útil. La exactitud de este acercamiento depende, por supuesto, en la habilidad del administrador que escribe la firma, pero en la mayoría de los casos ésta preve la detección muy exacta de un ataque específico, y no cogerá nuevos o modificados ataques.

¿Los sistemas estadístico basados de NIDS, que se utilizan generalmente conjuntamente con la concordancia con el modelo, intentan establecer una línea de fondo de la actividad y alertar cuando los paquetes son?statistically significativos? ¿en su desviación de la norma? una manera matemática de decir el paquete del?weird?. Desemejante de la concordancia con el modelo, esta táctica puede coger nuevos (y solamente de vez en cuando, más creativos) ataques en el coste de ser algo ruidosa y de requerir el análisis humano de todas las alarmas.

Porque la mayoría de los sistemas de NIDS funcionan en la capa 2 (OSI), alimentan simplemente tráfico crudo en un motor de la detección y confían en la concordancia con el modelo y/o el análisis estadístico para determinarse cuál es malévolo. ¿Los paquetes no son procesados por el apilado de los host?s TCP/IP? permitiendo que el NIDS analice tráfico el anfitrión desecharía de otra manera. Este acercamiento también tiene la desventaja que los paquetes se pueden hacer a mano intencionalmente de tal manera en cuanto a confunden sistemas de NIDS patro'n-que emparejan, mientras que todavía correctamente siendo montado por el apilado del anfitrión TCP/IP para rendir la carga útil del ataque.

Inserción, evasión, y negación del servicio: La detección de la intrusión de la red que elude , escrita por Ptacek y Newsham (1998), detalla un número de estos métodos del ataque, que se resumen abajo. Las técnicas descritas en Ptacek y Newsham fueron utilizadas por la canción cavada programador para crear Fragroute .

Fragroute , por su propia página de la aserción [ man(8) ], los??intercepts, modifica, y reescribe el tráfico de la salida destinado para el anfitrión especificado, poniendo la mayoría de los ataques descritos en el?Insertion seguro de las redes, la evasión, y la negación en ejecucio'n del?Insertion del servicio, de la evasión, y de la negación del servicio: ¿Detección De la Intrusión De la Red Que elude? ¿papel de enero 1998?

Términos y convenciones usadas en este documento
Software:
Snort: Detección De la Intrusión De la Red (NIDS).
www.snort.org/dl/snort-1.8.6.tar.gz

Tcpdump: Utilidad de la captura del paquete.
www.tcpdump.org/release/tcpdump-3.7.1.tar.gz

Etéreo: Utilidad del análisis del paquete.
www.ethereal.com/distribution/ethereal-0.9.3.tar.gz

Fragroute: Talladora del paquete. www.monkey.org/~dugsong/fragroute/fragroute-1.2.tar.gz
Ofuscación: la fuente y la destinación hosts/networks son aliased como sigue:
Attack.source: anfitrión que inicia el ataque
Attach.target: anfitrión que funciona al demonio bajo ataque.
Registros de la sesión: los operandos matemáticos se utilizan para indicar la dirección de la comunicación:
¿? >? los comandos publicaron del attack.source
¿? Cómo Trabaja
Para determinar la eficacia de Fragroute en obscurecer un ataque potencial, utilizaron a tres anfitriones: un fragroute corriente como la fuente, un segundo wu-ftpd corriente como la blanco, y un tercer Tcpdump, Snort, y etéreo corrientes para la captura y el análisis. Los tres anfitriones fueron conectados con un segmento aislado de la red.

¿Porque el propósito de este análisis era la técnica y no el ataque sí mismo de la evasión, elegí una hazaña común del ftp? ¿el procurar al ~root del?cd? mientras que está authenticado como usuario no privilegiado. Esta hazaña se documenta bien [ Cve-1999-0082 ] y es detectada confiablemente por la mayoría de los sistemas de NIDS.

Implica los comandos siguientes (los comentarios indican donde registración del paquete comenzada y parada por todos los ejemplos que siguen):

Attack.source > ftp attack.target
de < FTP SERVER 220 attack.target listo
> usuario no privilegiado
< contraseña 331 requerida para no privilegiado
> mypassword del paso
< el usuario 230 no privilegiado entró
> el rastro "copia más oscura"del ~root # de la red comienza
de < el comando 250 CWD acertado # rastro de la red termina

Para una línea de fondo, la secuencia antedicha (registrada donde indicado) fue ejecutada sin el uso de Fragroute usando Tcpdump para la captura y etéreo para el análisis:



Snort se quejó inmediatamente:



El ataque entonces fue repetido usando Fragroute para obscurecer la tentativa. El ruleset estándar (proporcionado cuando se compila Fragroute) fue utilizado para probar. La función de cada regla se explica como comentarios:



La sesión fue registrada con Tcpdump y analizada otra vez con etéreo:



Un request/response que ahora requeriría típicamente solamente 3 paquetes utiliza 38. ¿Nuestra petición original del ~root del?cd? se envía de orden en los paquetes 7, 11, 18, 19 y 22 con 1 o 2 cargas útiles del octeto. ¿Los paquetes 1, 2, 3, 4, 5, 6, 7 son?chaf duplicado? los paquetes publicaron como parte de la sesión del ftp.

¿Los paquetes restantes del are?chaf de attack.source? los paquetes con una variedad de problemas, incluyendo jefes cortos, de sumas de comprobación inválidas, o son duplicados. Los paquetes del attack.target vuelto son ACKs para los paquetes del chaf que checksumed correctamente por el apilado alejado del IP.



¿La corriente hecha fragmentos fue vuelta a montar correctamente por el apilado del IP de los target?s, dando por resultado el?250? comando del éxito en el paquete 35. Fragroute no manipula tráfico reverso.

Snort?1.8.6 no pudo detectar ningunos elementos de la tentativa.

Naturaleza de la amenaza
El pensamiento de un atacante potencial que puede descargar un 83k del software y hacerse invisibles a una red bien-puesta y meticulously mantenida del hardware y del software de la seguridad agitaría incluso el la mayoría calmantes del personal de la seguridad. Los sistemas de la detección de la intrusión proporcionan la advertencia valiosa mientras que las amenazas potenciales prueban su red, y (generalmente) proporcione la evidencia a la figura fuera de qué sucedió si él le batió en encontrar algo de interés.

¿Según Marty Roesch??deals del snort 1,9 (actualmente bajo desarrollo) con algunos de los ataques más interesantes del fragroute?? (Roesch, 1). ¿Probando esta compilación implicada teoría snort-actual de CVS y jugar de nuevo el mismo archivo del tcpdump usado previamente con él el usar snortrules-actual, también de CVS. Snort detectó algo del?chaf? ¿fragmentos como un portscan, y las respuestas de los paquetes de la basura como RST?Evasive? ¿? ni unos ni otros de las cuales identifica el ataque original. Siguiendo voluntad snort-actual trate la edición eventual, pero aparece actualmente que los sistemas de NIDS todavía no pueden hacer frente a un ataque envuelto por Fragroute.

[ * * ] [ 100:1:1 ] spp_portscan: PORTSCAN DETECTADO al puerto 22646 de attack.source (STEALTH) [ * * ] 05/06-11:30:43.912934

[ * * ] [ 111:2:1 ] spp_stream4: detección EVASIVA posible de RST [ * * ]
05/02-20:58:16.589253 attack.target:12139 - > attack.source:21862
TCP TTL:59 TCOcS:0x10 ID:47366 IPCLen:20 DGMCLen:42 DF
** Del *** A*R Seq: 0x55626D41 Ack: triunfo 0x726E5455: 0x4733 TcpLen: 20

[ * * ] [ 111:2:1 ] spp_stream4: detección EVASIVA posible de RST [ * * ]
05/02-20:58:16.599253 attack.target:13398 - > attack.source:26951
TCP TTL:59 TCOcS:0x10 ID:49947 IPCLen:20 DGMCLen:40 DF
** Del *** A*R Seq: 0x5447766C Ack: triunfo 0x68534F74: 0x36Ê TcpLen: 20

Soluciones Posibles A la Vulnerabilidad
Utilice un sistema host-based de las identificaciones en sistemas expuestos. Los sistemas basados anfitrión de las identificaciones pueden detectar actividad malévola supervisando en la capa de uso, y pueden divulgar sobre las entradas creadas en el sistema o tener acceso a registros. Logsnorter es un tal ejemplo [ www.snort.org/dl/contrib./logsnorter-0.2.tar.gz ].
Aumente su software de NIDS. Los vendedores están revolviendo para tratar las ediciones creadas por Fragroute y lo calcularán actualmente hacia fuera eventual. <
Referencias
Lemos, Roberto. La herramienta nueva camufla programas del hacker. ZdNet Australia. el 22 de abril de 2002. http://www.zdnet.com.au/newstech/security/story/0,2000024985,20264745,00.htm

Inglete. Vulnerabilidades y exposiciones comunes. el 27 de agosto de 1999. http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0082

Ptacek, Thomas Y Newsham, Timothy. evasión, y negación del servicio: Detección De la Intrusión De la Red Que elude?. Asegure Las Redes, Enero De 1998. http://www.insecure.org/stf/secnet_ids/secnet_ids.html

Roesch, Marty. Noticias. el 7 de mayo de 2002. www.snort.org/index.html

¿Canción, Cavada?Fragroute(8)? http://www.monkey.org/~dugsong/fragroute/fragroute.8.txt

Timm, técnicas de la evasión de Kevin.IDS y táctica. SecurityFocus (Infocus). el 7 de mayo, 2002 http://online.securityfocus.com/infocus/1577

[!|@"·#$%~¬&/()=?¿]

Esa técnica ya no funciona, es detectada (por lo menos con el Snort), ese texto como se puede ver es de hacer 2 años, y  los IDS han evolucionado muchísimo desde entonces.

Decir también que el tripwire es una *****, que pasa si troyanizamos el binario del tripwire en sí para que no chequee cierto archivo que hemos modificado para nuestro uso y disfrute? La solución sería tener el binario en un disket o algo así que no se pueda acceder a él.

Y por último los rootkits a nivel de kernel que existen hoy en día se detectan muy fácilmente porque las técnicas que usan son ampliamente conocidas, vease como ejemplo el detector Prosum (http://prosum.sf.net), el proyecto parece abandonado pero detecta cualuiqera de las técnicas actuales.

Aún con todo ésto anterior es muy posible que si el intruso tiene los conocimientos necesarios como para modificar las cosas adecuadas en el sistema no sea detectado después de la intrusión, otra cosa son los logs que dejas en la intrusión que esos si son dificiles de borrar ya que como dice Rojodos pueden ir a un host remoto o incluso sacarlos directamente por una impresora (parece increible pero yo lo he visto hacer y no era una red pequeña), con lo cual eso sería imposible de borrar y tendrán una evidencia de que el sistema ha sido comprometido, si la empresa es seria tendrán un backup del sistema de hace no demasiado tiempo (quizás horas) y si la política de la empresa es correcta reinstalarían el sistema completo con el backup de antes de estar comprometido el sistema, con lo cual te comerías una *****.

Como veis garantizar el acceso futuro a un sistema comprometido si las políticas de seguridad son las correctas es imposible.

[Rojodos]

Bueno, no estoy del todo de acuerdo (aunque solo un poco xD)

Si un sistema esta bien "seguro" como tu dices, el problema seria "entrar", no "permanecer". Es decir, obviamente, es mucho mas dificil entrar en un sistema (y mas aun hacerse root) que, ya siendo root, troyanizar o instalar backdoors.

Lo de Tripwire es verdad, es tonteria que tanto el binario como las tablas de MD5 estuvieran en el HD, eso deberian estar en otros HDs (extraibles), USB sticks, CDs regrabables, host remotos, etc....

Con el sistema de logs pasa lo mismo, si los logs son locales (se decir, no se envian a host remotos, no se imprimen, no se graban en CDs) es posible tanto modificarlos como impedir que se usen (hablando de distros Linux "normales", no me meto en SELinux o cosas como Bastille).

Hay zappers que eliminan al 100% cualquier evidencia en los logs, y por supuesto, rootkits que los eliminan y desactivan.

Si un sistema no usa programas como Tripwire (o cualquiera parecido) ni detectores de rootkits (rkhunter por ejemplo), es muy facil troyanizar cualquier cosa (aunque solo sean lineas de codigo, en vez de rootkits mas avanzados).

No entiendo bien lo de "rootkits a nivel de kernel". Te refieres a LKMs? Esos, teniendo modprobe o ismod desactivados, no funcionan (creo). Yo creo que lo mejor es, o troyanizar algunas lineas de codigo, o meter troyanos a nivel de librerias.

Obviamente, eso es detectado por Tripwire o anti rootkits, pero.... es lo que hay

Salu2

[EL_ZoRRo]

Otro buen texto para detectactar y destripar ataques que haya sufrido nuestro sistema

http://es.tldp.org/Presentaciones/200103hispalinux/monserrat/pdf/texto.pdf

Salu2