[oceano]

Hola Suicidal,

En teoría no se debería poder. En esto consiste una de las bases y filosofía de los sistemas Unix.

Un usuario no puede acceder a los archivos y directorios de otro usuario, por defecto está con permisos 755 /directorios y 644 /ficheros.

Fuente
http://www.iec.csic.es/criptonomicon.../permisos.html

" Sticky bit: El sticky bit tiene su significado propio cuando se aplica a directorios. Si el sticky bit está activo en un directorio, entonces un usuario sólo puede borrar ficheros que son de su propiedad o para los que tiene permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está pensado para directorios como /tmp, que tienen permiso de escritura global, pero no es deseable permitir a cualquier usuario borrar los ficheros que quiera. El sticky bit aparece como 't' en los listados largos de directorios. "

[suicidal]

Hola Suicidal,

Ese archivo que has creado y luego has modificado con root, estaba dentro todo contenido del mismo servidor ?

Es decir, dentro de servidor xxx123.ovh.net, creas un usuario y luego le das permisos para el sólo a cierto archivo. Con un superadmin, digamos root, dentro de xxx123.ovh.net vas a poder siempre modificar todo el contenido que hay dentro de ese mismo servidor.

Un saludo !

Sí, así es.

Si envio pues un fichero con permisos 770 no podrá leerlo NADIE?

PD: he enviado un fichero a otro usuario, con permisos 644, y le he metido un rm con root, y se ha ido el fichero a tomar por saco.

[oceano]

Hola Suicidal,

Ese archivo que has creado y luego has modificado con root, estaba dentro todo contenido del mismo servidor ?

Es decir, dentro de servidor xxx123.ovh.net, creas un usuario y luego le das permisos para el sólo a cierto archivo. Con un superadmin, digamos root, dentro de xxx123.ovh.net vas a poder siempre modificar todo el contenido que hay dentro de ese mismo servidor.

Un saludo !

[suicidal]

Hola Suicidal,

Creo, debería ser como he explicado, por lo menos tiene toda su lógica.

Nunca he utilizado el método que has comentado, pero si intentas acceder o modificar un archivo en el cual no tienes los permisos correspondientes, nunca vas a poder.

Y pensando esto, si ese archivo interceptado no es tuyo, cómo es posible cambiar los permisos ? Para ello deberías ser el administrador de ese archivo.

No crees ?

Un saludo !

Creo con mi usuario A el fichero llamado a.txt, le asigno permiso 700

Voy con mi usuario root y hago un nano a.txt, y veo todo el contenido. Hago rm a.txt y ha desaparecido.

Pues si alguien intercepta los ficheros, más de lo mismo... Vamos, salvo que algo cambie en el funcionamiento de rsync, que ni idea, todo son conjeturas.

[oceano]

Hola Suicidal,

Creo, debería ser como he explicado, por lo menos tiene toda su lógica.

Nunca he utilizado el método que has comentado, pero si intentas acceder o modificar un archivo en el cual no tienes los permisos correspondientes, nunca vas a poder.

Y pensando esto, si ese archivo interceptado no es tuyo, cómo es posible cambiar los permisos ? Para ello deberías ser el administrador de ese archivo.

No crees ?

Un saludo !

[suicidal]

Hola Suicidal, buenos días.

Si, así es, pero para ello debes ser el propietario del archivo y en tal caso, debes entrar dentro del fichero para serlo y poder cambiar los permisos. Es decir, averigua primero el pass de superadmin y luego, cambias permisos.

Un saludo !

Pero por qué debo ser el propietario?

Si yo intercepto (es decir, un man in the middle), no necesito ser propietario de nada, simplemente con mi root puedo cambiar el propietario y pista (igual que puedes hacer con un root normal?, no?

No me aclaro mucho

Bueno, aparte, aporto mi granito de arena, para que no te pregunte password cada vez que vas a sincronizar (ideal para hacer un cron)

(En el servidor ORIGEN)
$ ssh-keygen
$ ssh-copy-id -i ~/.ssh/id_rsa.pub IP_SERVIDOR_DESTINO

(metemos la password...)

LISTO! Probamos a conectarnos ssh al servidor y ya no nos pide contraseña!

[oceano]

Hola Suicidal, buenos días.

mmmm lo del permiso de usuario/grupo... nose, creo que no sirve de nada. Ya que es tan fácil como hacer un chmod nuevo desde el root del que interceptó los archivos y listo.

Si, así es, pero para ello debes ser el propietario del archivo y en tal caso, debes entrar dentro del fichero para serlo y poder cambiar los permisos. Es decir, averigua primero el pass de superadmin y luego, cambias permisos.

Un saludo !

[suicidal]

mmmm lo del permiso de usuario/grupo... nose, creo que no sirve de nada. Ya que es tan fácil como hacer un chmod nuevo desde el root del que interceptó los archivos y listo.

[oceano]

Hola, buenos días

ACTUALIZADO + Sticky Bit

* " Sticky bit: El sticky bit tiene su significado propio cuando se aplica a directorios. Si el sticky bit está activo en un directorio, entonces un usuario sólo puede borrar ficheros que son de su propiedad o para los que tiene permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está pensado para directorios como /tmp, que tienen permiso de escritura global, pero no es deseable permitir a cualquier usuario borrar los ficheros que quiera. El sticky bit aparece como 't' en los listados largos de directorios. "

Cuando queremos trasferir archivos de un servidor a otro, debemos tener en cuenta que los archivos que vamos a trasferir tendrán que tener un 7 en sus permisos, es decir:

Archivos que serán trasferidos al server B

Server A

# chmod 1770 -R /ruta/ . " ( usuario/propietario ) leer, escribir, ejecutar ( grupo ) leer, escribir, ejecutar ( otros ) 0 NADA "

Con esto conseguimos que otros usuarios que no están dentro de nuestro planteamiento de permisos para poder acceder a cualquiera de nuestros archivos trasferidos, pueda poder en algún momento a éstos ficheros/archivos leer, escribir o ejecutar. Una medida más de seguridad, puesto que si fueran interceptados en la trasferencia, deberían ser propietario o pertenecer al grupo que ha enviado esos archivos.

Deberemos tener en cuenta, en el lugar destino de poner un

Server B

# groupadd USUARIO_REALIZARA_TRASFERENCIA
# chgrp -R USUARIO_REALIZARA_TRASFERENCIA /inicio/lugar/guardo/copias
# chmod 1770 -R /ruta/ . " ( usuario/propietario ) leer, escribir, ejecutar ( grupo ) leer, escribir, ejecutar ( otros ) 0 NADA "

* Es decir,

# ls -l /ruta/
# drwxrwx---t (1770)

Con este planteamiento, ya nos permitirá realizar las copias correctamente con éste comando de una forma segura.

# rsync -avzr --progress -e "ssh -c aes128-ctr" /ruta/server1 user@IP:/ruta/server2


Si alguien está utilizando Authy hay que realizar unos ajustes muy sencillos en los dos servidores, lo explico !!

* Debemos tener en cuenta que tenemos que tener realizada la instalación y validación da Authy en su correcto funcionamiento antes de nada.

- How-To
https://github.com/authy/authy-ssh
- Video Instalación
https://www.authy.com/products/ssh

Básicamente es realizar:

# vi /etc/ssh/sshd_config ( dentro añadir )
AcceptEnv AUTHY_TOKEN

# vi ~/.ssh/config ( dentro añadir, si no existe se crea ) * añadir tal cuál
Host *
(Mover a la posición debajo del * )SendEnv AUTHY_TOKEN

Posteriormente para realizar la trasferencia

AUTHY_TOKEN="TOKEN_DE_NUESTRO_TELEFONO" rsync -avzr --progress -e "ssh -c aes128-ctr" /ruta/server1 user@IP:/ruta/server2

* Debemos tener instalado para los tokens el APP de Authy en nuestro Teléfono anteriormente.



Un saludo !

[oceano]

Hola Guille,

Pues vaya, es curioso el tema... He estado leyendo y parece ser que el optimo realmente es el del 128, será cuestión de utilizar este a partir de ahora.

Muchas gracias por la info !

RE - ACTUALIZADO

# rsync -aczr --progress -e "ssh -c aes128-ctr" /ruta/server1 user@IP:/ruta/server2


Un saludo !

[Guille]

Por lo visto la encriptacion por defecto para ssh2 es aes128-ctr y luego en orden de preferencia:

aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc,arcfour

¿Hay mucha diferencia entre aes128 y aes256?

De hecho, el AES, a pesar de ser un algoritmo público y de uso público, está considerado como la NSA (Agencia de Seguridad Nacional de los EEUU) desde el año 2003, como algoritmo seguro para proteger información clasificada de nivel SECRETO usando claves de 128 bits y de ALTO SECRETO, si se usan claves de 192 o 256 bits

fuente: http://fernando-acero.livejournal.com/78069.html

Sin embargo expertos en seguridad recomiendan AES-128:

AES is the best known and most widely used block cipher. Its three versions (AES-128, AES-192, and AES-256) differ in their key sizes (128 bits, 192 bits and 256 bits) and in their number of rounds (10, 12, and 14, respectively). In the case of AES-128, there is no known attack which is faster than the 2^128 complexity of exhaustive search. However, AES-192 and AES-256 were recently shown to be breakable by attacks which require 2^176 and 2^119 time, respectively. While these complexities are much faster than exhaustive search, they are completely non-practical, and do not seem to pose any real threat to the security of AES-based systems.

And for new applications I suggest that people don't use AES-256. AES-128 provides more than enough security margin for the forseeable future. But if you're already using AES-256, there's no reason to change.

Fuente: http://www.schneier.com/blog/archive...r_new_aes.html

[oceano]

Hola, buenos días.

Buen aporte y mejor reflexión.

Muchas gracias Drpks !!


ACTUALIZADO

# rsync -aczr --progress -e "ssh -c aes256-ctr" /ruta/server1 user@IP:/ruta/server2



Un saludo !

[drpks]

Una red wifi con seguridad WEP es "más segura" que una sin seguridad, pero menos segura que una con WPA.

Por tanto, yo no usaría "ssh -c arcfour256". Aunque sea más seguro que arcfour, es menos seguro que AES256.

[oceano]

Hola Drpks, buenas noches

1.- They use a key of 128-bit or 256-bit, respectively.

2.- "arcfour128" and "arcfour256" are thus "more secure" than plain "arcfour".



Un saludo !

[drpks]

Hola, buenos días RME

Yo suelo utilizar este comando

rsync -aczr --progess -e "ssh -c arcfour256" /ruta/server1 user@IP:/ruta/server2

Info Link
http://security.stackexchange.com/qu...our256-ciphers

- The "arcfour" cipher is defined in RFC 4253; it is plain RC4 with a 128-bit key. -

"arcfour128" and "arcfour256" are defined in RFC 4345. They use a key of 128-bit or 256-bit, respectively. Moreover, and contrary to plain "arcfour", they also include a "discard" step: the very first 1536 bytes produced by the cipher are dropped. This is done because the first bytes of RC4 output tend to exhibit biases, which are rarely fatal to your security, but worrisome nonetheless. "arcfour128" and "arcfour256" are thus "more secure" than plain "arcfour".


Un saludo !

Yo no usaría RC4, tú mismo indicas que es "débil".

[oceano]

Hola, buenos días RME

Yo suelo utilizar este comando

rsync -aczr --progress -e "ssh -c arcfour256" /ruta/server1 user@IP:/ruta/server2

Info Link
http://security.stackexchange.com/qu...our256-ciphers

- The "arcfour" cipher is defined in RFC 4253; it is plain RC4 with a 128-bit key. -

"arcfour128" and "arcfour256" are defined in RFC 4345. They use a key of 128-bit or 256-bit, respectively. Moreover, and contrary to plain "arcfour", they also include a "discard" step: the very first 1536 bytes produced by the cipher are dropped. This is done because the first bytes of RC4 output tend to exhibit biases, which are rarely fatal to your security, but worrisome nonetheless. "arcfour128" and "arcfour256" are thus "more secure" than plain "arcfour".


Un saludo !

[RME]

Sincronizando ficheros en Linux entre dos servidores:

100.100.100.100 es la IP de nuestro dedicado A
200.200.200.200 es la IP de nuestro dedicado B

Queremos que los cambios (en los archivos) hechos en A se repliquen en B de la carpeta /var/www/ que es donde alojamos una web (o lo que sea).

Configuramos un cron en A cada X tiempo (evitar cada poco tiempo no vaya a ser que no le de tiempo a terminar al anterior).

rsync -avz /var/www/ root@200.200.200.200:/var/www/

Este comando se pone en el SSH del servidor A.
root es el usuario del servidor B y te pedirá la contraseña root del servidor B.

Parámetros:
-a (Recursivo, guarda timestamps y propiedades)
-v (verbose, con texto que te va diciendo como va)
-z (Compresión, mayormente tienes ficheros no comprimibles (video, musica o imágenes) desactivalo, pues pierde mucho tiempo y no ahorra.

Si el destino ya tiene algunos de los archivos estos se omitirán (si son exactamente iguales).

Aclaraciones:
- Antes de añadir algo al cron comprueba en SSH que funciona, pruebalo manualmente
- Para ponerlo en el cron y que no pida la pass del server B hay que añadir una clave SSH al servidor A
- Este comando copia ficheros, yo no lo usaría para bases de datos (para eso hay otras cosas).
- Cuidado con el directorio que quieres replicar, no vale poner / por que hay otros archivos que no quieres que se repliquen, pon una carpeta tuya (que no haya nada del sistema operativo).
- Este comando solo copia de A -> B, no de B -> A.

Cualquier duda preguntad.


Nota: Si hay alguna información incorrecta o alguien sabe más acerca de este tema que deje un mensaje en este hilo.