-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-06-21 a las 11:19 +0200, aux escribió:

# Bueno yo creo que si existen SSOO (y proyectos en general) mas seguros que otros, o almenos mas probados y mas auditados. Tienes varios ejemplos de proyectos. Un claro ejemplo es OpenBSD (www.openbsd.org) un Un*x BSD orientado a la seguridad (Only one remote hole in the default install, in more than 8 years), otro ejemplo cercano es Qmail que se ha programado pensando en la seguridad. En este ultimo caso por ejemplo su creador en 1997 ofreció 500$ a quien descubriera alguna vulnerabilidad (aun está esperando).

Pero eso es relativo. El programa será seguro, pero el usuario puede meter la pata. SuSE, que usa qmail precisamente para la lista (pero no para lo demás) metió una vez la gamba y se convirtió en un coladero. Le metieron la IP en las listas negras unos dias por culpa de la gambada. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCt/cPtTMYHG2NR9URAqrvAJ99JNNyNlKn0MxjBzNKLS3K4CI9qwCggyZf XZeFkoRHdvvbuVxqehuXQB8= =Xjnl -----END PGP SIGNATURE-----

On Tue, 21 Jun 2005 14:11:30 +0200 "aux" wrote: aux> Dejando de lado las 'gambadas' que pueda hacer una persona, si yo monto un aux> web server con suse y otro con openbsd está claro que el servidor de suse aux> tiene mas probabilidades de ser 'petado', Y porque? pues porque el otro S.O aux> pone mas interés en la seguridad, tendran mas auditado el codigo y vendra aux> con unas funcionalidades de serie que quizá suse no trae (chroot, parches aux> extras, etc, etc) Yo disiento de esta afirmación. Salvo en los casos del "innombrable" en que los intereses comerciales priman sobre los criterios de seguridad, con el resto de sistemas dependerás mucho más del administrador del mismo que del sistema que utilice. "A priori" un Suse puede parecer más seguro que un Red Hat o que un FreeBDS, sin embargo las vulnerabilidades existen para todos los S.O. y si no estan en el sistema estaran en alguna de las aplicaciones que se utilizan (por ejemplo en PHP inferior a 4.3.10 o en Java Runtime inferiores a la 1.5.03), y una incorrecta política de actualizaciones, el no estar suscrito a boletines de seguridad o un uso incorrecto del control de los permisos por poner algunos ejemplos pueden llevar al fracaso al sistema más seguro. -- Salutacions - Saludos, Josep M. Queralt

Carlos E. R. escribió:

El 2005-06-21 a las 11:19 +0200, aux escribió:

...

...

# Bueno yo creo que si existen SSOO (y proyectos en general) mas seguros que otros, o almenos mas probados y mas auditados. Tienes varios ejemplos de proyectos. Un claro ejemplo es OpenBSD (www.openbsd.org) un Un*x BSD orientado a la seguridad (Only one remote hole in the default install, in more than 8 years), otro ejemplo cercano es Qmail que se ha programado pensando en la seguridad. En este ultimo caso por ejemplo su creador en 1997 ofreció 500$ a quien descubriera alguna vulnerabilidad (aun está esperando).

Pero eso es relativo. El programa será seguro, pero el usuario puede meter la pata. SuSE, que usa qmail precisamente para la lista (pero no para lo demás) metió una vez la gamba y se convirtió en un coladero. Le metieron la IP en las listas negras unos dias por culpa de la gambada.

La seguridad debe ser algo redundante. Un proceso que es seguro cuando falla debe darse una circustancia de fallos concurrentes. Esto es el error de una máquina, o de una persona no deben desencadenar el fallo. Si uno da una orden de formatear el disco duro debe advertirle la máquina de las consecuencias y preguntarle si está seguro de ello. El concepto de seguridad que se basa en el "no error" del operador es algo que está desechado hace un par de décadas -y en paises más avanzados hasta tres o cuatro décadas-. Si yo diseño un proceso y se produce un accidente no puedo decirle a mis superiores que es que falló el ordenador o falló una válvula de seguridad... porque me ponen directamente en la calle y si alguna persona sufre daños me pueden meter en el trullo. Tengo que explicarle que fallaron varias cosas a la vez por lo menos si quiero salvar el pellejo.

aux escribió:

...

La seguridad debe ser algo redundante. Un proceso que es seguro cuando falla debe darse una circustancia de fallos concurrentes. Esto es el error de una máquina, o de una persona no deben desencadenar el fallo.

Si uno da una orden de formatear el disco duro debe advertirle la máquina de las consecuencias y preguntarle si está seguro de ello.

El concepto de seguridad que se basa en el "no error" del operador es algo que está desechado hace un par de décadas -y en paises más avanzados hasta tres o cuatro décadas-.

Si yo diseño un proceso y se produce un accidente no puedo decirle a mis superiores que es que falló el ordenador o falló una válvula de seguridad... porque me ponen directamente en la calle y si alguna persona sufre daños me pueden meter en el trullo.

Tengo que explicarle que fallaron varias cosas a la vez por lo menos si quiero salvar el pellejo.

Todo eso está muy bien, siempre y cuando cumplas las normas de seguridad establecidas. Si tu estas en una obra y no te pones casco, o pasas por zonas que no puedes pasar (ignorando todos los carteles con las medidas de seguridad a seguir) y pasa algo, dile a tus superiores algo... que veras que te dicen. Pues en informatica igual.

Te equivocas, para eso están las protecciones colectivas, -redes y vallas de seguridad, que impiden que te muevas por dónde no debes y que te caigan objetos y te hagan daño aunqueno lleves casco. (Soy técnico de Seguridad, Higiene y Ergonomía, con algo un poco bastante de experiencia. Si te puedes mover por una zona peligrosa el fallo es que esa zona no estaba acotada -y en informática ocurre igual-.

Hay mucha gente que sigue usando el usuario root para todo (aun y sabiendo que es peligroso),

Bueno, al menos SuSE te advierte de que no se debe utilizar la cuenta root para navegar... y eso no es un fallo de seguridad es una negligencia. o que hacen borrados recursivos con

parametros que no pida confirmación.

Si la máquina no te pregunta es un fallo del sistema y si lo que haces es poner un parámetro para que no te pregunte es una negligencia... eso ya no se puede considerar un fallo de seguridad. Hay muchos usuarios que no se leen

los manuales y a veces ejecutan cosas sin saber que hacen exactamente o que consecuencias tendrá.

Lógicamente... otro fallo, la formación. Pero claro si lo haces con el ordenador de tu casa tú eres el responsable. Si te permiten hacerlo enun servidor crítico acceder sin formación entonces falla el sistema de seguridad.

Con esto lo que quiero decir es que no se puede controlar todo, y siempre el usuario ha de poner de su parte.

El usuario siempre ha de poner de su parte... pero un especialista en seguridad te dirá y te dice que todos los accidentes -informáticos- son evitables, al menos evitables consecuencias desagradables -ya sabes copias de seguridad, discos raid, alimentación sai... etc. etc. etc.

...

-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-06-22 a las 12:39 +0200, aux escribió:

...

experiencia. Si te puedes mover por una zona peligrosa el fallo es que esa zona no estaba acotada -y en informática ocurre igual-.

Te equivocas tu, tal como digo "siempre que cumplas las normas de seguridad". De nada sirven las vallas y carteles de aviso para que te pongas casco si yo no hago caso. Pues en informatica igual. Vuelve a leerte mi e-mail

No, porque para eso está el vigilante de seguridad, que no te deja pasar. Y si te lo saltas, para eso está el jefe que te pone una sanción de empleo y sueldo de una semana :-P - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCuVdjtTMYHG2NR9URAr/DAJ912U1wUDLACNXZfHKbXjP36lnuJQCeL5JI XMLZ676Ckjfb94Ud2korBJk= =H2YT -----END PGP SIGNATURE-----

que

...

esa zona no estaba acotada -y en informática ocurre igual-.

Te equivocas tu, tal como digo "siempre que cumplas las normas de seguridad". De nada sirven las vallas y carteles de aviso para que te pongas casco si yo no hago caso. Pues en informatica igual. Vuelve a leerte mi e-mail

Te repito entonces no es un fallo de seguridad es una negligencia.

Un fallo del sistema? Mira lo que no se puede hacer es tener un s.o que te vaya preguntando y vaya comprobando todo lo que hagas tu,

"que te pida confirmación para todo y que contemple todos los fallos que el ser humano pueda cometer". Paradógicamente acabas de definir el "antiobjetivo de la seguridad". "Lo siento pero Un*X (y linux) no son asi". Evidentemente todo es mejorable... el que no sea así está bien para ti... otros piensan que la seguridad se puede mejorar de muchas maneras. Pero si para ti está bien. Me alegro por ti porque hallaste el Nirvana... a veces no está mal ser conformista. y su misión o proposito no son ese. Para todo eso que cuentas seguro que hay

sistemas mas adecuados para eso. Un administrador de sistema ha de ser cauto y saber en todo momento que hace, tener experiencia y conocer los tipicos problemas o los posibles errores que pueden suceder. Para eso está el administrador de sistema, y la politica y la manera de entender la filosofia de Un*x (o linux) no ha cambiado practicamente desde sus inicios (hace mas de 30 años). Para algo está el administrador del sistema, para conocer lo que es peligroso y lo que no. Y perdoname pero yo no necesito que me suelte un mensajito el sistema de que vaya cuidado con la cuenta root. El profesional ha de ser profesional y conocer lo que puede y lo que no puede hacer y que riesgos tiene. Y si aun asi te equivocas... pues chico... estate mas atento a lo que pones o simplemente dedicate a otra cosa.

...

La seguridad es una filosofía no es algo propio de la computación y te pongo a grandes rasgos los requisitos -fíjate que se parecen a los de calidad-. Equipo seguro Proceso seguro Personal adiestrado Formación Información Previsión de fallos y emergencias. Sistemas concurrentes. Planificación Control Auditoría Revisión Mejora contínua (Obvamente algunos para tí no tienen sentido con lo que te conformas con una seguridad muy antigua). Si se lo dejas todo al administrador no es seguro ni linux ni windows ni el sonajero de tu niño. Si basas la seguridad del sistema dependiente de un único punto -el administrador-, el equipo o lo que sea, pues la seguridad no la conocerás ni en pintura-. En calidad dicen que el fallo del operador no existe, es un fallo del sistema gobal porque un sistema perfecto no permite fallar al operador. Es algo un poco más moderno de lo que tú dices. Claro que para eso hace falta llegar a la mejora contínua y tú te quedaste en hace 30 años de unix. Eres feliz pero no eres seguro. :) Saludos.

No hagas mucho caso de Theo, es un tio muy extremista (al igual que muchos otros usuarios de *BSD y muchos usuarios de linux). Realmente es un tio muy orgulloso pero es un crack. Es comun en el ver 'peleas' con otras personas. Sin ir mas lejos con la gente de NetBSD (cuando abandonó el proyecto para formar OpenBSD), o con Darren Reed creador de ipf (cuando hubieron problemas de licencia y ni corto ni perezoso creó su propio firewall, pf). Lo dicho... un personaje (que sabe mucho). Si no recuerdo mal se llevó el premio de este año 2004 que la Free Software Foundation da cada año a la persona que ha contribuido mas con el SW libre (Alan Cox se lo llevo en 2003). ----- Original Message ----- From: "Peter Holm" To: Sent: Tuesday, June 21, 2005 12:11 PM Subject: Re: [suse-linux-s] La seguridad ... un proceso, no un producto