Question

El tema es el siguiente. Necesito en el /home evitar que puedan ejecutar binarios, pero quiero continuar permitiendo scripts. No estoy seguro que el enfoque sea el correcto, escucho todo tipo de comentarios.

En un equipo que funciona como bastión, audito con una herramienta externa desde allí en adelante todas las conexiones ssh. Ahora lo que me preocupa es que alguien pueda traerse un binario del cliente ssh, renombrarlo y utilizarlo para conectarse desde allí (en ese caso no me quedaría ninguna auditoria de su accionar).

[ lnxtest20 - user20 ]/home/user20 $ ll
total 452
-rwxrwx--- 1 user20 idm      5 Aug  4 13:14 prueba.sh
-rwxr-x--- 1 user20 idm 446728 Aug  4 13:01 ssh
[ lnxtest20 - user20 ]/home/user20 $ mv ssh nutria
[ lnxtest20 - user20 ]/home/user20 $ ls -ld nutria
-rwxr-x--- 1 user20 idm 446728 Aug  4 13:01 nutria
[ lnxtest20 - user20 ]/home/user20 $ ./nutria -l root 10.75.255.220
The authenticity of host '10.75.255.220 (10.75.255.220)' cant be established.
RSA key fingerprint is c5:ca:24:cb:4e:d6:b5:c4:e0:2b:c5:3b:f3:58:7f:9c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.75.255.220' (RSA) to the list of known hosts.
Password: 

 

Probé con la opción noexec en el montado del filesystem, pero esto me bloquea ambas cosas.

[ lnxtest20 - user20 ]/home/user20 $ mount | grep home
/dev/mapper/vg_lnxtest20 -lv_home on /home type ext3 (rw,noexec,acl,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0)
[ lnxtest20 - user20 ]/home/user20 $ ./nutria -l root 10.75.255.2209
-bash: ./nutria: Permission denied
[ lnxtest20 - user20 ]/home/user20 $ cat prueba.sh
date
[ lnxtest20 - user20 ]/home/user20 $ ./prueba.sh
-bash: ./prueba.sh: Permission denied
[ lnxtest20 - user20 ]/home/user20 $
[ lnxtest20 - user20 ]/home/user20 $ file nutria
nutria: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
[ lnxtest20 - user20 ]/home/user20 $ file prueba.sh
prueba.sh: ASCII text
[ lnxtest20 - user20 ]/home/user20 $

 

Alguien tiene alguna opción o idea para comentarme?. De última lo que pensé es en armar un control de puertos abiertos contra procesos en ejecución para lanzar un kill, pero la verdad no me gusta mucho esta idea.

 

Saludos 

Answer 1

*EDIT*

Más tarde lo leo tranquilo de nuevo pero se me ocurre que apelando a tus más oscuros skills de ugly hacker podés armar un layer protector para lograr lo que buscás, la idea sería así:

1. Implementar incron o watcher para monitorear la acción CLOSE_FILE_WRITE en los directorios que te interesan (inclusive de forma recursiva);
2. Si el archivo que se acaba de escribir en disco es un binario ZAP! - lo eliminás, lo movés a un stash seguro para fines de análisis/auditoría, le quitás el bit de ejecución, whatever.
3. Con write podés enviarle un mensaje al usuario informándole del breaching...

Si en los directorios del jumphost a los que acceden tus usuarios hay muchas (muchas) escrituras este approach no va a resultar óptimo por el impacto en el sistema.

Comments

También hacen referencia a AppArmor y SELinux como comentaba @qlixed en su respuesta:
https://serverfault.com/questions/8820/preventing-users-from-running-certain-programs

---

gracias por la informacion, la verdad no conocia incron. Lo voy a revisar para ver si armo algo con esto.

Answer 2

podrías usar rbash supongo, le ponés un cierto PATH en el profile (readonly) a los usuarios, y solamente pueden ejecutar lo que hay en el PATH (véase <http://blog.bodhizazen.net/linux/how-to-restrict-access-with-rbash/>, por ej). No pueden crear scripts y correrlos (ni ejecutables), pero sí pueden correr scripts y ejecutables para los que estén autorizados

Comments

Gracias, pero no es lo que estoy buscando porque por lo que entiendi no tenes opciones de configuracion. El link no anda, pero hay info aca:
http://www.tecmint.com/rbash-a-restricted-bash-shell-explained-with-practical-examples/
Otra contra seria que tendria que deshabilitar bash para que no puedan ejecutarlo tampoco.

En realidad no me preocupa lo que ejecuten ahi mientras sean scripts (porque usaran las herramientas disponibles en el equipo) y no sean binarios.

Saludos

Answer 3

Como va, tal vez puedas hacer una combinación. Por un lado le seteás el PATH como te dijeron antes a algo que solo tenga los shell scripts que querés ejecutar.

Y por otro lado le cargas como shell el rbash. El rbash es un restricted bash que te ermite realizar ciertas cosas. Mejor dicho, tiene restringido lo siguiente:

 

1. cd command (Change Directory)
2. PATH (setting/ unsetting)
3. ENV aka BASH_ENV (Environment Setting/ unsetting)
4. Importing Function
5. Specifying file name containing argument ‘/’
6. Specifying file name containing argument ‘-‘
7. Redirecting output using ‘>‘, ‘>>‘, ‘>|‘, ‘<>‘, ‘>&‘, ‘&>‘
8. turning off restriction using ‘set +r‘ or ‘set +o‘

De es manera solo puede ejecutar tus scripts y no se va a poder escapar por ningun lado.

Comments

Voy a continuar investigando, pero me parece que es demasiado bloqueante para lo que estoy necesitando.

Saludos

Answer 4

Creo que se podria resolver con SELinux, pero antes de meterme a experimentar, te hago una pregunta:

En general los scripts van a requerir de algun binario para realizar su tarea, esto es asi? o vos estas ejecutando todos scripts de perl/python o algun otro lenguaje que interpretado que no require de binarios externos mas alla del obvio interprete?.

Comments

Tengo un FW local que no se lleva muy bien con SElinux, pero escucho cualquier idea.

El tema es el siguiente, pensemoslo como un equipo de salto en donde cada usuario puede hacer la magia que quiera. Lo unico que necesito es trazabilidad hoy, por lo que necesito que las conexiones ssh se hagan por mis script que llaman al ssh.

Para esto tengo que evitar que se puedan ejecutar binarios distintos a los que el equipo tiene actualmente. Quiero decir, puedo cronear un find que me borre todos los binarios de los home, pero no me parece lo mejor. No quiero evitar que creen/ejecuten sus script mientras utilicen los binarios del os.

Con respecto a lo que preguntas, la mayoria (por no decir todos) los script seguramente son en bash o python.

Saludos

Answer 5

Lo de limitar sólo por ejecutable en /home no parece que pudiera ser muy efectiva, estoy seguro de que hay alguna forma de saltearlo llamando a tu binario-ssh directamente, o ssh + telnet o ssh+netcat o subiendo un paramiko (ssh en python). Una idea, sin probar, tomada de http://stackoverflow.com/questions/4314163/create-iptables-rule-per-process-service :

1. Crear un grupo ezpezial. Nadie pertenece a ese grupo
2. Con iptables, bloquear todas las conexiones salientes nuevas al puerto 22 salvo para los procesos cuyo grupo sea el ezpezial ( -m owner )
3. En vez de que los usuarios llamen a tu script, crear un binario que llame a tu script. A este binario asignarlo al grupo ezpezial y ponerle setgid. Los usuarios tienen que llamar a este programa.

 

Ah también vi que hay en "iptables .... -j LOG" podés loguear el uid que generó el tráfico, así que supongo que en vez de tener un script especial de ssh podés analizar logs.