Bloquear solo ejecucion de binarios y permitir ejecucion de shell script (RHEL)

Sultanovich

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 

ikarudelabasto

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.

qlixed

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?.

msx

*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.

Saknussemm

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.