On Sun, Jun 15, 2003 at 09:54:50AM +0200, Antonio Castro wrote: > On Sat, 14 Jun 2003, Fernando M. Maresca wrote: > > > ... > > la estructura de directorio bajo /chroot es donde corre el proceso > > enjaulado, esa es la jaula. De esta forma, el proceso enjaulado _cree_ > > que /chroot es /, y no puede evitar de ning�n(?) modo creerlo. Por > > tanto, cuando desde dentro de la jaula se hace "cd /" se va a parar a > > /chroot. > > Ahora, si alguien logra explotar una vulnerabilidad de BIND pongamos por > > caso, puede ser que altere cosas dentro de la jaula, pero: tenemos > > El chroot es una jaula para un proceso. Por esa raz�n se puede salir > de esa jaula buscando una vulnerabilidad no ya en BIND sino en cualquier > otro servicio. Hum... No lo dudo. Lo que posiblemente omit� decir es que esa m�quina no presta otros servicios. O sea, si mi servidor bind est� en una jaula y decido usar esa misma m�quina como servidor de correo pop (dentro o fuera de la jaula), bueno, eso ya es una decisi�n del administrador de la red, que sabr� hasta donde puede comprometer sus servicios. en m� opini�n est� loco. >Hay que advertir que para el intruso estar dentro de una > jaula chroot ya supone un peque�o avance, Un gran avance. Pero si por ejemplo ese server loggea en otro distinto (cosa obligatoria en cualquier sistema serio), ya el intruso va a ir necesitando mas tiempo para alterar los logs y borrar sus huellas, y le da mas posibilidades al admin de percibir su presencia antes; adem�s, es relativamente f�cil para el administrador tarrear y copiar la jaula para luego investigar y reponer desde un backup limpio en un rato. >ya que algunos servicios > invulnerables desde un acceso remoto ser�n vulnerables desde un acceso > local aunque sea desde una jaula chroot. Si, ok. Pero una cosa es entrar en la jaula y otra distinta salir de ella, lo que seguramente supondr� hacerse root antes. > > En general chroot es una concesi�n peque�a pero una concesi�n afin de > cuentas. Casi cualquier cosa que se conceda ya es algo que un buen > hacker puede usar para empezar a tirar del hilo y terminar haciendose > con el control de la m�quina. Seguro, pero me parece (por lo menos mi punto de vista como administrador es este) que no se trata de esto. Quiero decir que la m�quina segura es la que est� apagada, mientras lo est�. Yo no tengo ninguna garant�a de que nadie se va a colar en mi DMZ o a�n mas adentro, pero lo que s� tengo que hacer es complicar las cosas de modo tal que le cueste un huevo; de eso se trata la seguridad, y no solo la de sistemas. De esa forma, yo tengo mas tiempo para percibirlo y cagarlo. Posiblemente contest� a algo puntual, no al mas general problema de como hacer un sitio seguro con m�ltiples sevicios; no era el objeto del comentario. Una cosa mas en este t�pico (el de la seguridad): los logs servers de una red son lo mas importante de todo el sistema; todav�a nadie ha escrito un programa que excuse al administrador de pasar un buen rato durante cada ma�ana leyendo logs para enterarse de como va todo, ni chroot ni ninguna otra cosa que yo conozca. Saludos > > > -- > Un saludo > Antonio Castro > > /\ /\ Ciberdroide Inform�tica > \\W// << http://www.ciberdroide.com >> > _|0 0|_ > +-oOOO-(___o___)-OOOo---------------------+ > | . . . . U U . Antonio Castro Snurmacher | > | . . . . . . . [EMAIL PROTECTED] | > +()()()---------()()()--------------------+ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-- Fernando M.
