[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: compilar nucleo por seguridad solucionado



El vie, 23-11-2012 a las 14:23 -0300, Matías Bellone escribió:
> 2012/11/23 Trujillo Carmona, Antonio
> <antonio.trujillo.sspa@juntadeandalucia.es>:
> > El vie, 23-11-2012 a las 13:49 -0300, Matías Bellone escribió:
> >> 2012/11/23 Camaleón <noelamac@gmail.com>:
> >> > El Fri, 23 Nov 2012 17:17:56 +0100, Trujillo Carmona, Antonio escribió:
> >> >
> >> >> La compañera encargada de virus me ha pasado este enlace
> >> >> https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections
> >> >> en la que analizan un rootkit espesifico para el núcleo de debian
> >> >> stable.
> >> >
> >> > Lo leí (en español) desde Hispasec:
> >> >
> >> > Descubierto un nuevo rootkit para servidores Linux
> >> > http://unaaldia.hispasec.com/2012/11/descubierto-un-nuevo-rootkit-para.html
> >> >
> >> > Pero no me quedó claro cómo se infectó el servidor.
> >> >
> >> >> ¿Seria útil, y como medida de seguridad, compilar el propio nucleo con
> >> >> apt-build solo para cambiarlo?.
> >> >> No tengo tiempo (ni ganas) de crear configuraciones especificas por
> >> >> servidor, me refiero a recompilar partiendo del fuente usando apt-build
> >> >> con nivel medio de agresividad.
> >> >
> >> > Pues no sé sabría decirte porque no me queda claro qué es vulnerable en
> >> > este caso (¿una versión del kernel en concreto?). Si es así, no tardarán
> >> > en sacar un parche ¿no? :-?
> >> >
> >>
> >> En realidad es a la inversa. El rootkit no es una vulnerabilidad en el
> >> kernel ni una forma de utilizar un programa para ganar privilegios en
> >> un sistema limpio. Una vez que el atacante gana acceso root a un
> >> servidor (por otro medio) instala un módulo de kernel que intercepta
> >> las llamadas a funciones de red del kernel específicas para inyectar
> >> un iframe o redirección a otras páginas.
> >>
> >> La particularidad de la versión de kernel (2.6.32-5) y arquitectura
> >> (amd64) es porque la única versión conocida del rootkit tiene el
> >> módulo de kernel compilado exclusivamente para esa combinación. Esto
> >> no implica que otras versiones y arquitecturas no sean afectadas;
> >> pero, nuevamente, este rootkit es aparentemente sólo aplicable a esta
> >> arquitectura una vez que el atacante ya ha ganado acceso root al
> >> equipo.
> >>
> >>
> >
> > Si claro lo tengo claro que no es un virus ni tiene forma de infectar un
> > servidor no accedido antes, pero seria muy fácil recompilar los núcleos
> > (igual que hago, aveces, con algunas aplicaciones para ganar
> > rendimiento), bastaría usar apt-build install en lugar de apt-get
> > install para tener un núcleo propio, lo que no tengo tan claro es si un
> > modulo de un núcleo funciona en otro núcleo igual pero de distinta
> > compilación.
> > Generalmente cuando compilo módulos con m-a exige tener las fuentes o
> > cabeceras del núcleo especifico, pero an algún lado leí que se permitía
> > cierta portabilidad de núcleos, por eso lo pregunto.
> > ¿Un modulo compilado para debian stable sin tocar funcionara en un
> > núcleo compilado con apt-build con agresividad media (entiendo que los
> > de los repositorios van con agresividad baja) sin tocar nada de la
> > configuración?
> >
> 
> Por lo general, los módulos son compatibles entre versiones menores de
> kernel. Es decir que un módulo de kernel compilado para 2.6.32-5
> también va a funcionar en cualquier versión que comience con 2.6.32.
> 
> Esto, sin embargo, es particular del kernel Linux. En el caso de
> FreeBSD, la compatibilidad es dentro de versiones mayores; es decir
> que cualquier módulo compilado para 6.2 va a funcionar en cualquier
> kernel FreeBSD 6.X (pero no con otras versiones).
> 
> Personalmente, hace rato que no compilo nada con module-assistant ya
> que utilizo los paquetes dkms que se encargan de llamar a
> module-assistant cuando se actualiza el kernel a una versión que no es
> compatible con la versión actual del módulo.
> 
> Saludos,
> Toote
De acuerdo no sirve.

-- 
trujo <antonio.trujillo.sspa@juntadeandalucia.es>


Reply to: