Re: Opciones de seguridad en servidor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El 27/11/2007, a las 8:13, Fernando escribió: No es lo mismo que un administrador de oracle con privilegios del root te ejecute un rm -rf ./* que con la papa que pillo el domingo llegue el lunes a currar dormio y se le olvide ejecutar el . y pongo rm -rf /* Después, quien tiene que solucionar el problema, él o yo? De quien es la responsabilidad del server? A las personas, si le das la mano te cojen el brazo. Hay que limitar el acceso y el poco acceso que haya debe estár monitorizado. Creo que no estás hablando de lo mismo. Aqui había alguien que quería limitar a los usuarios normales el uso de programas permitiendo solo el acceso a los que él quisiera. Si te dan una cuenta de root por supuesto que puedes borrarlo todo. Con un usuario normal y si no hay dejadez del administrador, lo mas que puede hacer es cargarse sus ficheros y los del grupo al que le des acceso. Y cargar recursos de la máquina si no aplicas ulimit, y colapsar el mysql con consultas gigantescas, y producir un cuello de botella en disco por (por poner un ejemplo) búsquedas mastodónticas con find, y poner un programa a escuchar en un puerto alto 'por experimentar' Hay que permitir que todos realicen su trabajo, pero intentando ajustar los límites en los que se pueden mover. Todo depende de prioridad de la máquina y de los datos que almacena/sirve; si esto lo justifica, pues limitar los programas que se pueden utilizar puede ser buena idea. Todo, como siempre, depende del escenario. Un saludo. Hilario Ortigosa Monteoliva Octanio Sistemas informáticos [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFHTTao1sbP3dW7ZYkRAvmZAKCWEs1U20Ci18eutzWVCASD0zeV1QCg2oBe g9hq3x+2yEURJAMf4mJGdnQ= =fGC7 -END PGP SIGNATURE-
Re: Opciones de seguridad en servidor
Hilario Ortigosa - Octanio Sistemas informático s wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El 27/11/2007, a las 8:13, Fernando escribió:
No es lo mismo que un administrador de oracle con privilegios del
root
te ejecute un rm -rf ./* que con la papa que pillo el domingo
llegue el
lunes a currar dormio y se le olvide ejecutar el . y pongo rm -rf /*
Después, quien tiene que solucionar el problema, él o yo? De quien
es la
responsabilidad del server?
A las personas, si le das la mano te cojen el brazo. Hay que
limitar el
acceso y el poco acceso que haya debe estár monitorizado.
Creo que no estás hablando de lo mismo.
Aqui había alguien que quería limitar a los usuarios normales el uso
de
programas permitiendo solo el acceso a los que él quisiera.
Si te dan una cuenta de root por supuesto que puedes borrarlo todo.
Con un usuario normal y si no hay dejadez del administrador, lo mas
que
puede hacer es cargarse sus ficheros y los del grupo al que le des
acceso.
Y cargar recursos de la máquina si no aplicas ulimit, y colapsar el
mysql con consultas gigantescas, y producir un cuello de botella en
disco por (por poner un ejemplo) búsquedas mastodónticas con find, y
poner un programa a escuchar en un puerto alto 'por experimentar'
Hay que permitir que todos realicen su trabajo, pero intentando
ajustar los límites en los que se pueden mover. Todo depende de
prioridad de la máquina y de los datos que almacena/sirve; si esto lo
justifica, pues limitar los programas que se pueden utilizar puede ser
buena idea.
Todo, como siempre, depende del escenario.
Un saludo.
Hilario Ortigosa Monteoliva
Octanio Sistemas informáticos
[EMAIL PROTECTED]
Por supuesto que cualquiera que tenga una cuenta shell puede hacer
daño
pero sabe que ese daño es detectable y se cuidará mucho de hacerlo.
Es posible hacer daño como dices con un find, pero con un ps sé quien es
el graciosillo. La base de datos gestiona sus usuarios, así que ahí no
veo problema. Un simple ping puede saturar una red local...
Estamos de acuerdo en ello, hay que permitir que la gente trabaje, pero
sin imposiciones innecesarias como comentaba en el hilo. No hay razón
por ejemplo para solo permitir el vi, pudiéndose usar otros editores a
preferencia de cada uno...
Los comandos importantes solo root puede ejecutarlos.
Mi comentarío iba en el sentido de tolerancia, veo mucho fascismo en
algunos administradores o aspirantes a serlo.
Creo que se puede cerrar ya este hilo.
Saludos.
--
Fernando.
{:-{D
Hackers do it with fewer instructions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opciones de seguridad en servidor
Marco wrote:
On Nov 23, 2007 5:20 AM, Fernando [EMAIL PROTECTED] wrote:
Israel Gutierrez wrote:
El Thursday 22 November 2007 17:13:09 Fernando escribió:
No entiendo por que tanto control sobre la gente, que problema hay
en que puedan ejecutar los comandos que ellos quieran.
Estás de coña ¿no?
--
No sé, no, si tu les das un usuario en una maquina, por supuesto no
root,
que problema hay en que ejecuten los programas que alli tengas
instalados.
Si alguno abusa pues podrás reprenderlo, pero por lo demás...
http://www.iec.csic.es/CRIPTonOMICon/linux/proteger.html
Pero vamos que no conozco la situación y no puedo decir mucho.
Simplemente que no me gustan los administradores que deciden que puedes
o no
usar: usas el vi porque lo digo yo, cuando tu prefieres emacs :)
Un saludo.
Me parece muy bien dar consejos de seguridad, pero lo que yo comentaba
es
que cuando das una cuenta shell a un usuario, por ejemplo en el trabajo,
es de esperar que este no vaya a atacar el sistema y si lo hace sabe las
posibles consecuencias. Cuanto mas accesible sea la máquina, mas énfasis
debemos tener en la seguridad, por supuesto.
Una Debian bien administrada es en principio segura para la mayor parte
de los usos, y restringir la posibilidad de usar comandos no me parece
una buena idea, si tu no autorizas por ejemplo el comando diff a un
usuario le estarás limitando. Si no quieres que se use el Gaim, pues no
lo instales, o es que lo que vale para ti no vale para los demás...
Un saludo.
--
Fernando.
{:-{D
Hackers do it with fewer instructions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opciones de seguridad en servidor
Fernando wrote: Marco wrote: On Nov 23, 2007 5:20 AM, Fernando [EMAIL PROTECTED] wrote: Israel Gutierrez wrote: El Thursday 22 November 2007 17:13:09 Fernando escribió: No entiendo por que tanto control sobre la gente, que problema hay en que puedan ejecutar los comandos que ellos quieran. Estás de coña ¿no? -- No sé, no, si tu les das un usuario en una maquina, por supuesto no root, que problema hay en que ejecuten los programas que alli tengas instalados. Si alguno abusa pues podrás reprenderlo, pero por lo demás... http://www.iec.csic.es/CRIPTonOMICon/linux/proteger.html Pero vamos que no conozco la situación y no puedo decir mucho. Simplemente que no me gustan los administradores que deciden que puedes o no usar: usas el vi porque lo digo yo, cuando tu prefieres emacs :) Un saludo. Me parece muy bien dar consejos de seguridad, pero lo que yo comentaba es que cuando das una cuenta shell a un usuario, por ejemplo en el trabajo, es de esperar que este no vaya a atacar el sistema y si lo hace sabe las posibles consecuencias. Cuanto mas accesible sea la máquina, mas énfasis debemos tener en la seguridad, por supuesto. Una Debian bien administrada es en principio segura para la mayor parte de los usos, y restringir la posibilidad de usar comandos no me parece una buena idea, si tu no autorizas por ejemplo el comando diff a un usuario le estarás limitando. Si no quieres que se use el Gaim, pues no lo instales, o es que lo que vale para ti no vale para los demás... Un saludo. No es lo mismo que un administrador de oracle con privilegios del root te ejecute un rm -rf ./* que con la papa que pillo el domingo llegue el lunes a currar dormio y se le olvide ejecutar el . y pongo rm -rf /* Después, quien tiene que solucionar el problema, él o yo? De quien es la responsabilidad del server? A las personas, si le das la mano te cojen el brazo. Hay que limitar el acceso y el poco acceso que haya debe estár monitorizado. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opciones de seguridad en servidor
Esteban Torres wrote:
Fernando wrote:
Me parece muy bien dar consejos de seguridad, pero lo que yo comentaba
es
que cuando das una cuenta shell a un usuario, por ejemplo en el trabajo,
es de esperar que este no vaya a atacar el sistema y si lo hace sabe las
posibles consecuencias. Cuanto mas accesible sea la máquina, mas énfasis
debemos tener en la seguridad, por supuesto.
Una Debian bien administrada es en principio segura para la mayor parte
de los usos, y restringir la posibilidad de usar comandos no me parece
una buena idea, si tu no autorizas por ejemplo el comando diff a un
usuario le estarás limitando. Si no quieres que se use el Gaim, pues no
lo instales, o es que lo que vale para ti no vale para los demás...
Un saludo.
No es lo mismo que un administrador de oracle con privilegios del root
te ejecute un rm -rf ./* que con la papa que pillo el domingo llegue el
lunes a currar dormio y se le olvide ejecutar el . y pongo rm -rf /*
Después, quien tiene que solucionar el problema, él o yo? De quien es la
responsabilidad del server?
A las personas, si le das la mano te cojen el brazo. Hay que limitar el
acceso y el poco acceso que haya debe estár monitorizado.
Creo que no estás hablando de lo mismo.
Aqui había alguien que quería limitar a los usuarios normales el uso de
programas permitiendo solo el acceso a los que él quisiera.
Si te dan una cuenta de root por supuesto que puedes borrarlo todo.
Con un usuario normal y si no hay dejadez del administrador, lo mas que
puede hacer es cargarse sus ficheros y los del grupo al que le des
acceso.
Saludos.
--
Fernando.
{:-{D
Hackers do it with fewer instructions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opciones de seguridad en servidor
[EMAIL PROTECTED] escreveu: Hola a todos. Estoy mejorando la seguridad de los servidores que se administran en mi empresa. Para ello he decidido utilizar el fichero sudoers y a través de este fichero digo quien entra y lo que puede hacer. Lo primero que he quitado es el logado del root por ssh. Así obligo a todo el mundo a pasar por el fichero sudoers. Después pretendo mandar un email con las entradas en el sistema y lo que ha realizado cada usuario (esta es mi idea, es sudoers la mejor solución?). Bueno, mi duda es que cuando el usuario user1 se loga por ssh puede ejecutar cualquier comando del sistema, entre ellos el su, entonces, he estado probando para evitar que pueda hacer entre otras cosas el su, y lo he conseguido pero pasando por el sudo su. Como podría hacer para evitar que el user1 pueda ejecutar cualquier comando del sistema? osea, obligarle a pasar siempre por el comando sudo y ahí ya le puedo limitar que comandos va a utilizar. Es conveniente tocar los permisos de los comandos? Saludos. Hace un tiempo empecé a trabajar con gente terca que en vez de usar el sudo seguía con la mala costumbre de hacer su root y hacer lo que tenían que hacer... Entonces me acordé de Gentoo y su grupo wheel. Entonces hice unos cambios en el PAM y habilité el grupo wheel en Debian también. Así que, por ejemplo, el comando su funciona solamente para los que están en el grupo wheel... jajajajajaja (como aquellas risas de los villanos). Buscá en Google sobre como habilitar este grupo en Debian. Saludos. -- Miguel Da Silva Administrador de Red Centro de Matemática - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la República - http://www.rau.edu.uy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opciones de seguridad en servidor
El Thursday 22 November 2007 17:13:09 Fernando escribió: No entiendo por que tanto control sobre la gente, que problema hay en que puedan ejecutar los comandos que ellos quieran. Estás de coña ¿no? -- BOFH excuse #306: CPU-angle has to be adjusted because of vibrations coming from the nearby road signature.asc Description: This is a digitally signed message part.
Re: Opciones de seguridad en servidor
Israel Gutierrez wrote:
El Thursday 22 November 2007 17:13:09 Fernando escribió:
No entiendo por que tanto control sobre la gente, que problema hay
en que puedan ejecutar los comandos que ellos quieran.
Estás de coña ¿no?
--
No sé, no, si tu les das un usuario en una maquina, por supuesto no
root,
que problema hay en que ejecuten los programas que alli tengas
instalados.
Si alguno abusa pues podrás reprenderlo, pero por lo demás...
Pero vamos que no conozco la situación y no puedo decir mucho.
Simplemente que no me gustan los administradores que deciden que puedes
o no
usar: usas el vi porque lo digo yo, cuando tu prefieres emacs :)
Un saludo.
--
Fernando.
{:-{D
Hackers do it with fewer instructions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opciones de seguridad en servidor
On Nov 23, 2007 5:20 AM, Fernando [EMAIL PROTECTED] wrote:
Israel Gutierrez wrote:
El Thursday 22 November 2007 17:13:09 Fernando escribió:
No entiendo por que tanto control sobre la gente, que problema hay
en que puedan ejecutar los comandos que ellos quieran.
Estás de coña ¿no?
--
No sé, no, si tu les das un usuario en una maquina, por supuesto no
root,
que problema hay en que ejecuten los programas que alli tengas
instalados.
Si alguno abusa pues podrás reprenderlo, pero por lo demás...
http://www.iec.csic.es/CRIPTonOMICon/linux/proteger.html
Pero vamos que no conozco la situación y no puedo decir mucho.
Simplemente que no me gustan los administradores que deciden que puedes
o no
usar: usas el vi porque lo digo yo, cuando tu prefieres emacs :)
Un saludo.
Saludos
--
Fernando.
{:-{D
Hackers do it with fewer instructions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
Cuando la oscuridad nuble tú vista, deja que la paranoia sea tu guía.
Re: Opciones de seguridad en servidor
podrías cambiar el grupo de su y dar permisos de ejecución al grupo y sacarle para el resto -- http://fishblues.blogspot.com/ http://gonzalor.blogspot.com/ No se tome la vida tan seriamente: Igualmente no va a salir vivo de ella.
Opciones de seguridad en servidor
Hola a todos. Estoy mejorando la seguridad de los servidores que se administran en mi empresa. Para ello he decidido utilizar el fichero sudoers y a través de este fichero digo quien entra y lo que puede hacer. Lo primero que he quitado es el logado del root por ssh. Así obligo a todo el mundo a pasar por el fichero sudoers. Después pretendo mandar un email con las entradas en el sistema y lo que ha realizado cada usuario (esta es mi idea, es sudoers la mejor solución?). Bueno, mi duda es que cuando el usuario user1 se loga por ssh puede ejecutar cualquier comando del sistema, entre ellos el su, entonces, he estado probando para evitar que pueda hacer entre otras cosas el su, y lo he conseguido pero pasando por el sudo su. Como podría hacer para evitar que el user1 pueda ejecutar cualquier comando del sistema? osea, obligarle a pasar siempre por el comando sudo y ahí ya le puedo limitar que comandos va a utilizar. Es conveniente tocar los permisos de los comandos? Saludos.
Re: Opciones de seguridad en servidor
[EMAIL PROTECTED] wrote:
Hola a todos.
Estoy mejorando la seguridad de los servidores que se administran en
mi empresa. Para ello he decidido utilizar el fichero sudoers y a
través de este fichero digo quien entra y lo que puede hacer.
Lo primero que he quitado es el logado del root por ssh. Asà obligo a
todo el mundo a pasar por el fichero sudoers. Después pretendo mandar
un email con las entradas en el sistema y lo que ha realizado cada
usuario (esta es mi idea, es sudoers la mejor solución?).
Bueno, mi duda es que cuando el usuario user1 se loga por ssh puede
ejecutar cualquier comando del sistema, entre ellos el su, entonces, he
estado probando para evitar que pueda hacer entre otras cosas el su, y
lo he conseguido pero pasando por el sudo su.
Como podrÃa hacer para evitar que el user1 pueda ejecutar cualquier
comando del sistema? osea, obligarle a pasar siempre por el comando
sudo y ahà ya le puedo limitar que comandos va a utilizar. Es
conveniente tocar los permisos de los comandos?
Saludos.
Parece mas apropiado que los metas en una jaula.
(mira chroot)
No entiendo por que tanto control sobre la gente, que problema hay
en que puedan ejecutar los comandos que ellos quieran.
--
Fernando.
{:-{D
Hackers do it with fewer instructions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opciones de seguridad en servidor
On Thu, Nov 22, 2007 at 05:07:30PM +0100, [EMAIL PROTECTED] wrote: Hola a todos. Estoy mejorando la seguridad de los servidores que se administran en mi empresa. Para ello he decidido utilizar el fichero sudoers y a través de este fichero digo quien entra y lo que puede hacer. Lo primero que he quitado es el logado del root por ssh. Así obligo a todo el mundo a pasar por el fichero sudoers. Después pretendo mandar un email con las entradas en el sistema y lo que ha realizado cada usuario (esta es mi idea, es sudoers la mejor solución?). Bueno, mi duda es que cuando el usuario user1 se loga por ssh puede ejecutar cualquier comando del sistema, entre ellos el su, entonces, he estado probando para evitar que pueda hacer entre otras cosas el su, y lo he conseguido pero pasando por el sudo su. Como podría hacer para evitar que el user1 pueda ejecutar cualquier comando del sistema? osea, obligarle a pasar siempre por el comando sudo y ahí ya le puedo limitar que comandos va a utilizar. Es conveniente tocar los permisos de los comandos? Saludos. segun lo que entendi no haz cambiado el pass del root a uno que solo tu conozcas. Si es asi podrias partir por eso. signature.asc Description: Digital signature
