Adivinar contraseñas con DTRACE

Una de las nuevas funcionalidades de Solaris 10 y Opensolaris reside en la incorporacion de todo un framewok de instrumentacion como DTRACE.

Si nos descargamos el DtraceToolKit, el cual es un conjunto de scripts dtrace, bien documentados y desarrollados directamente por la comunidad, podemos fijarmos en particular en la utilizacion de sshkeysnoop.d como una variante del script dtrace shellsnoop. En su ejecucion nos permite capturar todas las contraseñas (incluso a traves de ssh) que se establezcan desde nuestro sistema con destino otros hosts, asi:

# uname -iX
i86pcSystem = SunOS
Node = opensolaris
Release = 5.11
KernelID = snv_57
Machine = i86pc
BusType =
Serial =
Users =
OEM# = 0
Origin# = 1
NumCPU = 1

Identificado nuestro sistema, lanzamos el sshkeysnoop.d.

# pwd
/opt/DTT/Apps

# ./sshkeysnoop.d
UID PID PPID TYPE TEXT

Y esperamos que desde cualquier sesión de terminal o consola, algun usuario de nuestro sistema intente establecer una sesion ssh con otro host.

# ssh pepe@opensolaris
Contraseña:
Last login: Tue Aug 7 12:12:53 2007 from opensolaris
Sun Microsystems Inc. SunOS 5.11 snv_57 October 2007
$ bash
$ hostname
opensolaris

Esto es lo que observamos en la captura del sshkeysnoop.d.

# ./sshkeysnoop.d
UID PID PPID TYPE TEXT
0 10873 10852 cmd ssh pepe@opensolaris
lib/libc.so.1
0 10873 10852 key 8
0 10873 10852 key L
0 10873 10852 key u
0 10873 10852 key c
0 10873 10852 key a
0 10873 10852 key s
0 10873 10852 key 0
0 10873 10852 key 1
^C

Luego vemos claramente como en el sistema opensolaris, el usuario pepe tiene como contraseña para acceder 8Lucas01.

Zonas, Contenedores y recursos CPU

Si tenemos dos Zonas definidas en nuestro sistema a parte de la global (zonepruebas y zonepruebas2), podemos gestionar sus consumos de recusros CPU a través del (FSS). Fair Share Scheduler: Este software permite asignar a cada aplicacion los recusos maximos de CPU del total de procesadores del sistema, por si se producen situaciones de competencia.

bash-3.00# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
7 zonepruebas running /zonas/pruebas native shared
9 zonepruebas2 running /zonas/pruebas2 native shared

Vemos como las zonas estan corriendo y podemos comenzar a definir los limites en los pooles que posteriormente asociaremos a cada una de ellas.

bash-3.00# cat > /etc/poolcfg
create pool zone1-pool ( string pool.scheduler = "FSS" )
create pool zone2-pool ( string pool.scheduler = "FSS" )
^C

Recargamos la configuración definida en el fichero /etc/poolcfg.

bash-3.00# pooladm -x; pooladm -s; poolcfg -f /etc/poolcfg ; pooladm -c

bash-3.00# psrset

Y la comprobamos:

bash-3.00# pooladm

system default
string system.comment
int system.version 1
boolean system.bind-default true
string system.poold.objectives wt-load

pool zone2-pool
int pool.sys_id 3
boolean pool.active true
boolean pool.default false
string pool.scheduler FSS
int pool.importance 1
string pool.comment
pset pset_default

pool pool_default
int pool.sys_id 0
boolean pool.active true
boolean pool.default true
int pool.importance 1
string pool.comment
pset pset_default

pool zone1-pool
int pool.sys_id 2
boolean pool.active true
boolean pool.default false
string pool.scheduler FSS
int pool.importance 1
string pool.comment
pset pset_default

pset pset_default
int pset.sys_id -1
boolean pset.default true
uint pset.min 1
uint pset.max 65536
string pset.units population
uint pset.load 9699
uint pset.size 1
string pset.comment

cpu
int cpu.sys_id 0
string cpu.comment
string cpu.status on-line

Si todo ha ido OK, podemos habilitar el FSS en nuestro anfitrion y reiniciarlo.

bash-3.00# dispadmin -d FSS

bash-3.00# hostname
opensolaris

bash-3.00# init 6

Al arrancar el anfitrión (zona global), comprobamos la gestión de recursos en los procesos del sistema mediante el FSS.

bash-3.00# ps -feac
UID PID PPID CLS PRI STIME TTY TIME CMD
root 0 0 SYS 96 14:38:21 ? 0:03 sched
root 1 0 FSS 39 14:38:24 ? 0:00 /sbin/init
root 2 0 SYS 98 14:38:24 ? 0:00 pageout
root 3 0 SYS 60 14:38:24 ? 0:00 fsflush
root 261 1 FSS 54 14:39:27 ? 0:01 /usr/lib/hal/hald --daemon=yes
root 7 1 FSS 59 14:38:28 ? 0:05 /lib/svc/bin/svc.startd
root 9 1 FSS 29 14:38:28 ? 0:11 /lib/svc/bin/svc.configd
root 342 1 FSS 59 14:39:52 ? 0:00 /usr/sbin/syslogd
root 333 305 FSS 57 14:39:51 ? 0:00 /usr/lib/saf/ttymon
root 295 262 FSS 59 14:39:34 ? 0:00 /usr/lib/hal/hald-addon-storage
un38134 468 467 FSS 1 14:43:00 syscon 0:00 -bash
root 472 468 FSS 59 14:43:02 syscon 0:00 -sh
root 163 1 FSS 59 14:39:11 ? 0:00 /usr/sbin/nscd
root 316 7 FSS 46 14:39:51 console 0:00 /usr/lib/saf/ttymon -g -d /dev/console -l console -m ldterm,ttcompat -h -p open
root 100 1 FSS 29 14:39:00 ? 0:00 /usr/lib/sysevent/syseventd
root 255 1 FSS 59 14:39:25 ? 0:01 /usr/lib/fm/fmd/fmd
root 127 1 FSS 54 14:39:05 ? 0:00 /usr/sbin/mdmonitord
root 133 1 FSS 58 14:39:06 ? 0:00 /usr/lib/power/powerd
root 460 1 FSS 3 14:40:55 ? 0:00 /usr/lib/sendmail -bd -q15m -C /etc/mail/local.cf
daemon 134 1 FSS 59 14:39:07 ? 0:00 /usr/lib/crypto/kcfd
smmsp 461 1 FSS 52 14:40:55 ? 0:00 /usr/lib/sendmail -Ac -q15m
root 121 1 FSS 57 14:39:03 ? 0:00 /usr/lib/picl/picld
root 190 1 FSS 53 14:39:14 ? 0:00 /usr/sbin/cron
root 132 1 FSS 29 14:39:06 ? 0:00 devfsadmd
un38134 467 464 FSS 59 14:43:00 ? 0:00 /usr/lib/ssh/sshd
root 262 261 FSS 59 14:39:28 ? 0:00 hald-runner
root 315 1 FSS 59 14:39:51 ? 0:00 /usr/lib/rmvolmgr -s
root 305 7 FSS 58 14:39:50 ? 0:00 /usr/lib/saf/sac -t 300
daemon 242 1 FSS 56 14:39:19 ? 0:00 /usr/lib/dbus-daemon --system
root 367 1 FSS 1 14:39:55 ? 0:00 /usr/lib/ssh/sshd
root 476 472 FSS 1 14:43:06 syscon 0:00 bash
root 318 1 FSS 58 14:39:51 ? 0:00 /usr/lib/utmpd
root 477 476 FSS 59 14:43:14 syscon 0:00 ps -feac
root 387 1 FSS 17 14:39:56 ? 0:00 /usr/perl5/bin/perl /usr/lib/intrd
noaccess 458 1 FSS 57 14:40:18 ? 0:13 /usr/java/bin/java -server -Xmx128m -XX:+BackgroundCompilation -XX:PermSize=32m
root 464 367 FSS 59 14:42:44 ? 0:00 /usr/lib/ssh/sshd

En este momento ya podemos asociar los valores definidos en los distintos pooles para cada una de nuestras zonas, convirtiendolas en Contenedores.

bash-3.00# zonecfg -z zonepruebas
zonecfg:zonepruebas> set pool=zone1-pool
zonecfg:zonepruebas> add rctl
zonecfg:zonepruebas:rctl> set name=zone.cpu-shares
zonecfg:zonepruebas:rctl> add value (priv=privileged,limit=30,action=none)
zonecfg:zonepruebas:rctl> end
zonecfg:zonepruebas> verify
zonecfg:zonepruebas> exit

bash-3.00# zonecfg -z zonepruebas2
zonecfg:zonepruebas> set pool=zone1-pool
zonecfg:zonepruebas> add rctl
zonecfg:zonepruebas:rctl> set name=zone.cpu-shares
zonecfg:zonepruebas:rctl> add value (priv=privileged,limit=15,action=none)
zonecfg:zonepruebas:rctl> end
zonecfg:zonepruebas> verify
zonecfg:zonepruebas> exit

bash-3.00# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
7 zonepruebas installed /zonas/pruebas native shared
9 zonepruebas2 installed /zonas/pruebas2 native shared

Arrancamos las zonas zonepruebas y zonepruebas2.

bash-3.00# zoneadm -z zonepruebas boot

bash-3.00# zoneadm -z zonepruebas2 boot

y ademas podemos comprobar la gestión de recursos de ambas zonas.

bash-3.00# zonefss -l
ID NAME SHARES
0 global 1
7 zonepruebas 30
9 zonepruebas2 15

Vamos a utilizar este scrpit en Perl para estresar las zonas y medir sus consumo de CPU del total de procesadores del sistema.

bash-3.00# more cpuhog.pl
#!/usr/bin/perl
print "eating the CPUs\n";
foreach $i (1..16) {
$pid = fork();
last if $pid == 0;
print "created PID $pid\n";
}
while (1) {
$x++;
}

Por tanto, ejecutamos el cpuhog.pl tanto en el solaris anfitrion(zona global), como en las zonas definidas zonepruebas y zonepruebas2 y obervamos que al establecerse competencia por el uso de todos los recursos de CPU del sistema nunca se limitan los limites establecidos a traves del FSS.

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3825 root 3272K 1112K run 54 0 0:00:04 3,5% cpuhog.pl/1
3821 root 3272K 1112K run 54 0 0:00:03 3,4% cpuhog.pl/1
3819 root 3272K 1112K run 52 0 0:00:03 3,3% cpuhog.pl/1
3830 root 3272K 1112K run 52 0 0:00:03 3,3% cpuhog.pl/1
3829 root 3272K 1112K run 54 0 0:00:04 3,2% cpuhog.pl/1
3827 root 3272K 1112K run 51 0 0:00:03 3,2% cpuhog.pl/1
3815 root 3272K 1112K run 54 0 0:00:03 3,1% cpuhog.pl/1
3826 root 3272K 1112K run 54 0 0:00:03 3,1% cpuhog.pl/1
3807 root 3272K 1176K run 51 0 0:00:04 3,0% cpuhog.pl/1
3817 root 3272K 1112K run 54 0 0:00:03 3,0% cpuhog.pl/1
3828 root 3272K 1112K run 52 0 0:00:03 3,0% cpuhog.pl/1
3813 root 3272K 1112K run 54 0 0:00:03 3,0% cpuhog.pl/1
3823 root 3272K 1112K run 52 0 0:00:03 3,0% cpuhog.pl/1
3811 root 3272K 1112K run 52 0 0:00:04 2,9% cpuhog.pl/1
3805 root 3276K 1996K run 53 0 0:00:03 2,8% cpuhog.pl/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
7 38 94M 87M 11% 0:01:24 52% zonepruebas
9 39 98M 91M 11% 0:01:01 32% zonepruebas2
0 54 113M 111M 13% 0:00:46 7,8% global

Total: 131 processes, 452 lwps, load averages: 52,23, 22,69, 16,04

Pero si matamos el proceso cpuhog.pl de las zona zonepruebas2 unicamente, el FSS permite a la zona zonepruebas (conde si corre todavia el cpuhog.pl) utilizar la suma de los limites de ambas en cuanto a su utilización de los recursos de CPU del sistema, ya que todavia entra en competencia con el anfitrion (zona global), asi:

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3827 root 3272K 1112K run 59 0 0:00:11 6,9% cpuhog.pl/1
3830 root 3272K 1112K run 59 0 0:00:10 5,0% cpuhog.pl/1
3805 root 3276K 1996K run 59 0 0:00:10 4,9% cpuhog.pl/1
3811 root 3272K 1112K run 59 0 0:00:10 4,8% cpuhog.pl/1
3825 root 3272K 1112K run 59 0 0:00:11 4,8% cpuhog.pl/1
3808 root 3272K 1112K run 59 0 0:00:10 4,8% cpuhog.pl/1
3809 root 3272K 1112K run 59 0 0:00:11 4,8% cpuhog.pl/1
3823 root 3272K 1112K run 59 0 0:00:10 4,8% cpuhog.pl/1
3815 root 3272K 1112K run 59 0 0:00:10 4,8% cpuhog.pl/1
3807 root 3272K 1176K run 59 0 0:00:11 4,7% cpuhog.pl/1
3813 root 3272K 1112K run 59 0 0:00:10 4,7% cpuhog.pl/1
3826 root 3272K 1112K run 59 0 0:00:10 4,7% cpuhog.pl/1
3828 root 3272K 1112K run 59 0 0:00:10 4,7% cpuhog.pl/1
3819 root 3272K 1112K run 59 0 0:00:10 4,6% cpuhog.pl/1
3817 root 3272K 1112K run 59 0 0:00:10 4,6% cpuhog.pl/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
7 38 94M 87M 11% 0:03:23 82% zonepruebas
0 54 113M 111M 13% 0:01:07 13% global
9 22 93M 88M 11% 0:00:23 0,1% zonepruebas2

Total: 114 processes, 435 lwps, load averages: 43,77, 32,25, 20,90

Y unicamente consumira practicamente el 100% de la CPU del sistema, cuando matamos el proceso cpuhog.pl en el anfitrion (zona global), asi:

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3813 root 3272K 1112K run 1 0 0:00:21 5,7% cpuhog.pl/1
3807 root 3272K 1176K run 2 0 0:00:21 5,7% cpuhog.pl/1
3828 root 3272K 1112K run 1 0 0:00:20 5,7% cpuhog.pl/1
3830 root 3272K 1112K run 1 0 0:00:20 5,6% cpuhog.pl/1
3809 root 3272K 1112K run 1 0 0:00:21 5,5% cpuhog.pl/1
3808 root 3272K 1112K run 3 0 0:00:21 5,5% cpuhog.pl/1
3826 root 3272K 1112K run 1 0 0:00:20 5,5% cpuhog.pl/1
3829 root 3272K 1112K run 3 0 0:00:21 5,5% cpuhog.pl/1
3821 root 3272K 1112K run 1 0 0:00:21 5,5% cpuhog.pl/1
3825 root 3272K 1112K run 1 0 0:00:21 5,5% cpuhog.pl/1
3811 root 3272K 1112K run 2 0 0:00:21 5,4% cpuhog.pl/1
3823 root 3272K 1112K run 17 0 0:00:20 5,3% cpuhog.pl/1
3805 root 3276K 1996K run 15 0 0:00:21 5,3% cpuhog.pl/1
3815 root 3272K 1112K run 3 0 0:00:20 5,3% cpuhog.pl/1
3819 root 3272K 1112K run 8 0 0:00:20 5,2% cpuhog.pl/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
7 38 94M 87M 11% 0:06:18 94% zonepruebas
0 37 108M 109M 13% 0:00:49 3,8% global
9 22 93M 88M 11% 0:00:23 0,1% zonepruebas2

Total: 97 processes, 418 lwps, load averages: 29,05, 33,26, 23,69

Y todo vuelve a la normalidad cuando matamos el proceso cpuhog.pl en la zona zonepruebas.

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3779 root 5660K 3504K cpu0 1 0 0:00:08 3,0% prstat/1
3769 un38134 10M 2400K sleep 59 0 0:00:00 0,3% sshd/1
456 noaccess 77M 53M sleep 56 0 0:00:29 0,2% java/24
3234 noaccess 76M 53M sleep 52 0 0:00:15 0,1% java/24
3600 noaccess 78M 55M sleep 56 0 0:00:13 0,1% java/24
3482 root 3456K 1684K sleep 59 0 0:00:00 0,0% syslogd/11
3267 root 7904K 2020K sleep 59 0 0:00:00 0,0% sendmail/1
3609 root 7904K 2024K sleep 59 0 0:00:00 0,0% sendmail/1
125 root 1556K 1104K sleep 6 0 0:00:00 0,0% powerd/3
121 root 2984K 1976K sleep 29 0 0:00:00 0,0% picld/4
315 root 2096K 1368K sleep 59 0 0:00:00 0,0% hald-addon-stor/1
307 root 1232K 844K sleep 59 0 0:00:00 0,0% utmpd/1
308 root 1920K 1160K sleep 59 0 0:00:00 0,0% sac/1
291 root 5260K 3672K sleep 59 0 0:00:00 0,0% hald/4
132 root 5748K 2404K sleep 29 0 0:00:00 0,0% mdmonitord/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
0 37 108M 109M 13% 0:00:56 3,5% global
7 21 89M 84M 10% 0:00:28 0,2% zonepruebas
9 22 93M 88M 11% 0:00:23 0,1% zonepruebas2

Total: 80 processes, 401 lwps, load averages: 11,29, 25,84, 22,50

Pero podemos asegurarnos que el anfitrion (zona global) tenga asegurado un limite en modo privilegiado del total de recursos de CPU para la ejecucion de sus procesos al igual que hemos realizado con las Zonas zonepruebas y zonepruebas2.

bash-3.00# prctl -n zone.cpu-shares -i zone global
zone: 0: global
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.cpu-shares
privileged 1 - none -
system 65,5K max none -
bash-3.00# prctl -n zone.cpu-shares -v 20 -r -i zone global

bash-3.00# prctl -n zone.cpu-shares -i zone global
zone: 0: global
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.cpu-shares
privileged 20 - none -
system 65,5K max none -

bash-3.00# zonefss -l
ID NAME SHARES
0 global 20
7 zonepruebas 30
9 zonepruebas2 15

Luego si ejecutamos de nuevo el script cpuhog.pl tanto en el anfitrion, como en las zonas zonepruebas y zonepruebas2, podemos ver que el limte de consumo de los recursos CPU por parte de la zona global ha aumentado significativamente.

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3918 root 3272K 1112K run 43 0 0:00:01 2,9% cpuhog.pl/1
3893 root 3272K 1176K run 45 0 0:00:01 2,7% cpuhog.pl/1
3899 root 3272K 1112K run 45 0 0:00:01 2,6% cpuhog.pl/1
3917 root 3272K 1112K run 45 0 0:00:01 2,5% cpuhog.pl/1
3916 root 3272K 1112K run 1 0 0:00:01 2,3% cpuhog.pl/1
3911 root 3272K 1112K run 3 0 0:00:01 2,3% cpuhog.pl/1
3914 root 3272K 1112K run 2 0 0:00:01 2,3% cpuhog.pl/1
3903 root 3272K 1112K run 3 0 0:00:01 2,2% cpuhog.pl/1
3895 root 3272K 1112K run 3 0 0:00:01 2,2% cpuhog.pl/1
3871 root 3272K 1108K run 48 0 0:00:01 2,2% cpuhog.pl/1
3909 root 3272K 1112K run 45 0 0:00:01 2,1% cpuhog.pl/1
3915 root 3272K 1112K run 33 0 0:00:01 2,1% cpuhog.pl/1
3897 root 3272K 1112K run 17 0 0:00:01 2,1% cpuhog.pl/1
3891 root 3276K 1996K run 3 0 0:00:01 2,0% cpuhog.pl/1
3880 root 3272K 1108K run 24 0 0:00:01 2,0% cpuhog.pl/1
3888 root 3272K 1108K run 27 0 0:00:01 1,9% cpuhog.pl/1
3906 root 3272K 1112K run 1 0 0:00:01 1,9% cpuhog.pl/1
3872 root 3272K 1108K run 44 0 0:00:01 1,9% cpuhog.pl/1
3867 root 5660K 3504K cpu0 53 0 0:00:01 1,9% prstat/1
3901 root 3272K 1112K run 45 0 0:00:01 1,9% cpuhog.pl/1
3877 root 3272K 1108K run 48 0 0:00:01 1,8% cpuhog.pl/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
7 38 94M 87M 11% 0:00:47 37% zonepruebas
0 54 113M 111M 13% 0:01:06 31% global
9 39 98M 91M 11% 0:00:32 24% zonepruebas2

Total: 131 processes, 452 lwps, load averages: 34,82, 11,46, 11,51

Como conclusión podemos ver que con el mecanismo de pooles de Solaris 10 y Opensolaris asignamos mediante el FSS los recursos de CPU del total de nuestro sistema (2, 4, 8, 16, etc...) a cada una de las Zonas, convirtiendolas en contenedores que nunca superaran su umbral definido como consumo maximo.