System monitoring with top

Probably the most important tool for any Linux systems administrator is top, which has got an interface that provides a real time view of the main events that are happening in the system, such as CPU consumption, memory, processes state, etc.

[root@centos ~]# top
top - 11:29:56 up 53 min,  1 user,  load average: 0.16, 0.05, 0.05
Tasks: 136 total,   1 running, 135 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.5%us,  0.6%sy,  0.0%ni, 98.2%id,  0.5%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   2059768k total,   352036k used,  1707732k free,    21248k buffers
Swap:  4095992k total,        0k used,  4095992k free,   207520k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
3057 root      15   0 12732 1004  716 R  2.0  0.0   0:00.01 top
1 root      15   0 10344  672  560 S  0.0  0.0   0:00.45 init
2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
3 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
5 root      10  -5     0    0    0 S  0.0  0.0   0:04.19 events/0
6 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 khelper
23 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kthread
27 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
28 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
85 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 cqueue/0
88 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 khubd
90 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kseriod
154 root      25   0     0    0    0 S  0.0  0.0   0:00.00 pdflush
155 root      15   0     0    0    0 S  0.0  0.0   0:00.03 pdflush
156 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kswapd0
157 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0
298 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 kpsmoused
...

We have a first line where the two most important data are the time that the machine is on (11:29:56 up) and the average number of system processes (load average) which have been waiting for any system resource (CPU, disk access, network, etc.) during the last 1, 5 and 15 minutes.

Then there is a data block where are showed the overall features of the system:

Tasks indicates the processes number which are up, where some of them will be able to be in running, sleeping, stopped or zombie state.

Cpu(s) shows the CPU use, by both the user (%us) and the system (%sy), as well as the percentage of CPU idle (%id).

Mem indicates the distribution which is being done of the RAM memory, offering the total amount available (total), the memory currently in use (used), the free memory (free), the buffers used (buffers) and within the total memory used, how much is cached (cached).

Swap shows the distribution of swap memory, providing the total amount available (total) and the part which is being used (used).

The other block of information presented by top is a set of columns with information about each process.

• PID: process ID number.


• USER: user name who has run the process.


• PR: process priority.


• NI: process priority change.


• VIRT: amount of virtual memory for process (including all code, data and shared libraries - if you have N instances of the same program running at the same time, the context of the application will be only once in memory). VIRT = SWAP + RES.


• RES: total physical memory (RAM) used by the process.


• SHR: amount of memory that can be shared with other processes.


• S: process status; D (sleeping and interruptible), S (sleeping), T (stopped) and Z (zombie).


• %CPU: percentage of CPU usage.


• %MEM: percentage of physical memory usage.


• TIME+: total CPU time used by the process.


• COMMAND: application which has run the process.

There are other fields associated with the tasks which are not displayed by default by top. If you want to view them, first you must press the 'f' key in order to see all available fields, and then press the key associated with the field to be added (e.g. 'p' key for SWAP).

Also say that the column values displayed by top can be ordered according to the memory (shift + m), PID (shift + n), CPU (shift + p) and the total CPU time used by the process (shift + t).

Finally also say that sometimes we can get that almost all physical memory is in use, but to sort the processes by memory, do not add the total amount of memory used. At this moment we will must look at the cached field, since in this way we will be able to see that the operating system is caching part of that memory, and the fact that a system caches memory is really the optimal situation.

Google hacking

Google stores a large amount of information in their databases related with all the websites indexed on Internet. We can consult those indexes at a given time to localize specific information.

The term Google hacking is refered to the fact of using certain searches, as well known as queries, to detect or find different types of information, such as hidden directories, sensitive data, passwords, credit card numbers, vulnerabilities, exploits, etc. These actions can be made through Google search or other applications based on this search engine.

For example, to locate websites that offer directory listings we can use the next query:

intitle:"index.of"

If we are examining a concrete website to look at whether it has got some hidden directory, we can also add the URL:

intitle:"index.of" site:redes-privadas-virtuales.blogspot.com

Handle these techniques correctly is very important to develop a good security audit, since this form we can find and revise security breaches that can be used by an attacker.

intitle:"index.of" (inurl:temp | inurl:tmp | inurl:private | inurl:admin)

intext:(password | passcode | pass) intext:(username | userid | user)

allinurl:”exchange/logon.asp”

filetype:c exploit

“Microsoft-IIS/5.0 server at”

We have been able to view that Google hacking is not an intrusive hacking method, since we can gather sensitive information without sending a single TCP packet against the target site.

There are lots of books written about the topic, and there is also a website named Google Hacking Database which contains many examples.

SNMP basic commands

In this article we are going to see the main SNMP commands that are provided by the net-snmp and net-snmp-utils packages.

The MIBs used by these tools normally reside in the /usr/share/snmp/mibs/ directory. Therefore, if we have ever to install new MIBs (e.g. for a VMware ESXi) we will have to leave them into that directory.

[root@centos ~]# ls -l /usr/share/snmp/mibs/
total 2364
...
-r--r--r-- 1 root root   8259 feb 16 12:09 SNMPv2-CONF.mib
-rw-r--r-- 1 root root   8263 feb 16 11:19 SNMPv2-CONF.txt
-r--r--r-- 1 root root  31588 feb 16 12:09 SNMPv2-MIB.mib
-rw-r--r-- 1 root root  29305 feb 16 11:19 SNMPv2-MIB.txt

snmpget

The snmpget command provides information about a specific OID.

For instance, to request the name of the device (system.sysName OID, belonging to the SNMPv2-MIB module) we will run the following order:

[root@centos ~]# snmpget -v 2c -c centos-community 192.168.1.10 SNMPv2-MIB::system.sysName.0
SNMPv2-MIB::sysName.0 = STRING: centos

We can also use abbreviations as follows:

[root@centos ~]# snmpget -v 2c -c centos-community 192.168.1.10 system.sysName.0
SNMPv2-MIB::sysName.0 = STRING: centos

[root@centos ~]# snmpget -v 2c -c centos-community 192.168.1.10 sysName.0
SNMPv2-MIB::sysName.0 = STRING: centos

Also say that multiple queries and use the OID in numeric format can be done.

[root@centos ~]# snmpget -v 2c -c centos-community 192.168.1.10 sysName.0 sysUpTime.0
SNMPv2-MIB::sysName.0 = STRING: centos
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (69808) 0:11:38

[root@centos ~]# snmpget -v 2c -c centos-community 192.168.1.10 .1.3.6.1.2.1.1.5.0
SNMPv2-MIB::sysName.0 = STRING: centos

snmptranslate

The snmptranslate command allows to make translations of OIDs from numeric format to variable and vice versa.

[root@centos ~]# snmptranslate .1.3.6.1.2.1.2.2.1.4.2
IF-MIB::ifMtu.2

[root@centos ~]# snmptranslate -On IF-MIB::ifMtu.2
.1.3.6.1.2.1.2.2.1.4.2

In order to get the complete OID, we must use the -Of parameter.

[root@centos ~]# snmptranslate -Of IF-MIB::ifMtu.2
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry

For example it can happend that we don't remember the complete OID name. In this case, the -Ib parameter will provide us the best match.

[root@centos ~]# snmptranslate -Ib 'i*tu'
IF-MIB::ifMtu

But if we want to get all the matches that fit with the selected pattern, we will use the -TB option.

[root@centos ~]# snmptranslate -TB 'sys.*ime'
SNMPv2-MIB::sysORUpTime
SNMPv2-MIB::sysUpTime
DISMAN-EVENT-MIB::sysUpTimeInstance
IP-MIB::ipSystemStatsDiscontinuityTime

Finally, also say that the snmptranslate command is very useful to show the entire OIDs tree or all branches that hang of a particular OID.

[root@centos ~]# snmptranslate -Tp -IR | more
+--iso(1)                    
|
+--org(3)
|
+--dod(6)
|
+--internet(1)
...

[root@centos ~]# snmptranslate -Tp -IR system
+--system(1)
|
+-- -R-- String    sysDescr(1)
|        Textual Convention: DisplayString
|        Size: 0..255
+-- -R-- ObjID     sysObjectID(2)
+-- -R-- TimeTicks sysUpTime(3)
|  |
|  +--sysUpTimeInstance(0)
...

snmpwalk

The snmpwalk command is utilized to perform a series of followed GETNEXTS instructions, and thus to obtain for example all the values of a specific branch.

[root@centos ~]# snmpwalk -v 2c -c centos-community 192.168.1.10 system
SNMPv2-MIB::sysDescr.0 = STRING: Linux server 2.6.18-164.11.1.el5 #1 SMP Wed Jan 20 07:32:21 EST 2010 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (342908) 0:57:09.08
SNMPv2-MIB::sysContact.0 = STRING: Root  (configure /etc/snmp/snmp.local.conf)
SNMPv2-MIB::sysName.0 = STRING: centos
...

VMware vSphere (ESXi): There is no more space for virtual disk

El título de este artículo refleja un error que nos puede ocurrir al administrar un VMware vSphere si no tenemos en cuenta ciertos detalles relacionados con la estructura de ficheros que emplea una máquina virtual.

Concretamente el mensaje de error al que me refiero es el siguiente: msg.hbacommon.outofspace: There is no more space for virtual disk xxxxxx. You may be able to continue this session by freeing disk space on the relevant partition, and clicking Retry. Otherwise, click Abort to terminate this session.


El problema es muy sencillo: alguna de nuestras máquinas virtuales ha ido creciendo de tamaño de tal manera que se ha agotado el espacio de nuestro datastore.

Vamos a poner un ejemplo para entender el asunto: supongamos que tenemos un datastore con un tamaño de 32 GB, y dentro de él creamos una máquina virtual a la que le asignamos 2 GB de memoria RAM y un disco virtual de 16 GB (vmdk).

Ya de primeras podremos pensar que nos quedan libres 16 GB, y estaremos en lo cierto. Pero en el momento en el que arranquemos dicha máquina virtual, se creará un nuevo archivo temporal con extensión vswp (fichero de swap creado por vSphere que coincidirá en tamaño con la cantidad de memoria RAM asignada) dentro del directorio donde resida la máquina virtual. El tamaño de dicho archivo será de 2 GB, luego ya no nos quedarán 16 GB libres, sino 14 GB.

Y el tema no se acaba aquí. Si en algún momento creamos un snapshot, el fichero vmdk que alberga la máquina virtual pasará a ser de sólo lectura (se congela), y se creará un nuevo archivo vmdk donde se irán guardando los cambios (incrementales) que afecten al vmdk congelado. Por lo tanto al hacer el snapshot, nos encontramos ante un nuevo archivo que podrá ir creciendo de forma dinámica en el tiempo.


Luego si en un momento dado el snapshot de esa máquina virtual (o de otras) aumenta de tal manera que nos quedemos sin espacio libre en el datastore, la máquina virtual que crezca dinámicamente sufrirá un crash y tendremos un mensaje como el de la imagen.

Por todo esto siempre he pensado que el snapshot debe de ser una herramienta que se utilice de forma temporal, por ejemplo cuando vayamos a actualizar un sistema operativo o aplicación. Transcurrido un tiempo prudencial, deberemos eliminarlo.

El rendimiento de una máquina virtual no puede ser el mismo si se trabaja con un disco virtual estático que si se hace sobre otro que varía su tamaño de forma dinámica.

Instalación y configuración de SNMP

En el presente artículo vamos a ver cómo configurar el servicio SNMP en una distribución CentOS 5.5 de 64 bits.

Lo primero que haremos será instalar los paquetes necesarios en el sistema:

[root@centos ~]# yum install net-snmp net-snmp-utils

A continuación definiremos las ACL (Access Control Lists) o listas de control de acceso dentro del fichero de configuración del demonio (snmpd.conf), a través de las cuáles indicaremos quién podrá conectarse al servicio SNMP y con qué permisos.

Básicamente vamos a crear dos ACLs, local y mynetwork, ambas pertenecientes a la comunidad centos-community. La primera de ellas tendrá permisos de lectura y escritura sobre las ramas de OIDs, y la segunda de ellas, únicamente permisos de lectura.

[root@centos ~]# cat /etc/snmp/snmpd.conf
...
com2sec local           127.0.0.1/32    centos-community
com2sec mynetwork       192.168.1.0/8   centos-community

A continuación crearemos dos grupos, uno de sólo lectura (MyROGroup) y otro de lectura/escritura (MyRWGroup) que podrán utilizar cualquier versión del protocolo SNMP (any).

[root@centos ~]# cat /etc/snmp/snmpd.conf
...
group   MyROGroup       any     mynetwork
group   MyRWGroup       any     local

access  MyROGroup       ""      any     noauth  exact   all     none    none
access  MyRWGroup       ""      any     noauth  exact   all     all     all

Y por último, definiremos las ramas que permitiremos visualizar.

[root@centos ~]# cat /etc/snmp/snmpd.conf
...
view    all     included        .1

Ahora sólo tendremos que reiniciar el servicio y hacer que éste se inicie automáticamente cada vez que arranque el sistema.

[root@centos ~]# service snmpd restart

[root@centos ~]# chkconfig snmpd on

Para comprobar que todo funciona correctamente, podremos hacer la prueba de listar la estructura de system.

[root@centos ~]# snmpwalk -v 2c localhost -c centos-community system

Datastore USB en VMware vSphere (ESXi)

En el artículo anterior vimos cómo conectar un dispositivo USB a un VMware vSphere (ESXi). Si analizamos el texto, podremos extraer dos importantes limitaciones: por un lado que el sistema de ficheros es FAT16 (tamaño máximo del volumen y de los ficheros de 2 GB) y por otro, que no podemos utilizarlo como un datastore.

Pues bien, me propuse intentar convertir la unidad USB en un hipotético datastore. Para ello sabía que previamente tendría que formatear dicho espacio de almacenamiento como VMFS, y posteriormente crear un datastore dentro del volumen, el cual pudiera ser reconocido por el VMkernel y utilizado para almacenar las máquinas virtuales.

Para ello se puede emplear la herramienta que proporciona VMware a través de su service console: vmkfstools (permite crear y manipular discos virtuales, sistemas de archivos, volúmenes lógicos y dispositivos de almacenamiento físico).

~ # vmkfstools -C vmfs3 -b 2M -S datastoreusb /vmfs/devices/disks/mpx.vmhba33\:C0\:T0\:L0\:1
Creating vmfs3 file system on "mpx.vmhba33:C0:T0:L0:1" with blockSize 1048576 and volume label "none".
/vmfs/devices/disks/mpx.vmhba33:C0:T0:L0:1: Permission denied.  (Have you set the partition type to 0xfb?)
Error: Permission denied

Al ejecutar el comando anterior nos encontramos con el primer problema: el tipo de partición no es válida. Esto lo podemos arreglar fácilmente a través de fdisk.

~ # fdisk /vmfs/devices/disks/mpx.vmhba33\:C0\:T0\:L0

Command (m for help): p

Disk /vmfs/devices/disks/mpx.vmhba33:C0:T0:L0: 2004 MB, 2004877312 bytes
255 heads, 63 sectors/track, 243 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

                          Device Boot      Start         End      Blocks  Id System
/vmfs/devices/disks/mpx.vmhba33:C0:T0:L0p1   *         1       243   1951866    6  FAT16

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): fb
Changed system type of partition 1 to fb (VMFS)

Command (m for help): p

Disk /vmfs/devices/disks/mpx.vmhba33:C0:T0:L0: 2004 MB, 2004877312 bytes
255 heads, 63 sectors/track, 243 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

                          Device Boot      Start         End      Blocks  Id System
/vmfs/devices/disks/mpx.vmhba33:C0:T0:L0p1   *         1       243   1951866   fb  VMFS

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table

Al volver a ejecutar el comando de creación del datastore, obtenemos un nuevo error: el VMkernel no está cargado o el tipo de llamada no está implementada.

~ # vmkfstools -C vmfs3 -b 2M -S datastoreusb /vmfs/devices/disks/mpx.vmhba33\:C0\:T0\:L0\:1
Creating vmfs3 file system on "mpx.vmhba33:C0:T0:L0:1" with blockSize 8388608 and volume label "datastoreusb".
Usage: vmkfstools -C vmfs3 /vmfs/devices/disks/vml... or,
vmkfstools -C vmfs3 /vmfs/devices/disks/naa... or,
vmkfstools -C vmfs3 /vmfs/devices/disks/mpx.vmhbaA:T:L:P
Error: vmkfstools failed: vmkernel is not loaded or call not implemented.

La primera posibilidad la descartamos:

~ # vmkload_mod -l | grep vmkernel
vmkernel            0x418037800000    0x29bfc5    0x0               0x0           0  Yes

Si observamos el fichero /var/log/messages podremos ver que lo que realmente está ocurriendo es que no se puede formatear la memoria USB como VMFS; la operación no está soportada por el VMkernel (qué listos estos ingenieros de VMware...).

~ # tail -f /var/log/messages
...
vmkernel: 0:00:32:01.819 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x16 (0x410004106a00) to NMP device "mpx.vmhba33:C0:T0:L0" failed
vmkernel: 0:00:32:01.819 cpu1:4097)ScsiDeviceIO: 770: Command 0x16 to device "mpx.vmhba33:C0:T0:L0" failed H:0x0 D:0x2 P:0x0 Valid sense data:
vmkernel: 0:00:32:01.819 cpu3:14174)Resv: 276: SCSI-2 Reservations are not supported by device mpx.vmhba33:C0:T0:L0.
vmkernel: 0:00:32:01.821 cpu3:14174)LVM: 6491: LVMProbeDevice failed on (4152466112, mpx.vmhba33:C0:T0:L0:1): Device does not contain a logica

Por lo tanto podemos concluir que sólo puede crearse un datastore bien conectando un nuevo disco (a través de fibra, iSCSI, SCSI o montando un volumen VMFS ya existente) o montando una carpeta compartida por NFS.

Conectar una unidad USB a un VMware vSphere (ESXi)

En este artículo vamos a ver cómo conectar y montar una unidad USB (en mi caso una memoria USB de 2 GB) a un VMware vSphere (ESXi). Para las pruebas voy a utilizar un VMware ESXi 4.0 (updated02).

Los requerimientos son dos: tener acceso a la service console y tener formateada la unidad de almacenamiento USB como FAT16 (recordar que VMware vSphere sólo reconoce dos clases de sistemas de archivos, FAT16 y VMFS).

En primer lugar, al conectar el dispositivo USB a la máquina podremos ver en el fichero /var/log/messages que una nueva unidad de almacenamiento USB ha sido encontrada.

~ # tail -f /var/log/messages
...
vmkernel: 0:00:09:58.654 cpu2:4316)<6>usb 1-7: new high speed USB device using ehci_hcd and address 2
...
vmkernel: 0:00:10:00.816 cpu1:9814)ScsiPath: 3715: Plugin 'NMP' claimed path 'vmhba33:C0:T0:L0'
vmkernel: 0:00:10:00.819 cpu1:9813)usb-storage: detected SCSI revision number 0 on vmhba33

Si le echamos un ojo a la tabla de particiones, podremos ver que el dispositivo ha sido detectado por el VMkernel.

~ # fdisk -l

Disk /dev/disks/mpx.vmhba33:C0:T0:L0: 2004 MB, 2004877312 bytes
255 heads, 63 sectors/track, 243 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

                  Device Boot      Start         End      Blocks  Id System
/dev/disks/mpx.vmhba33:C0:T0:L0p1   *         1       243   1951866    6  FAT16

...

También si listamos todos los adaptadores de almacenamiento del sistema, podremos ver que disponemos de un nuevo dispositivo USB.

~ # esxcfg-mpath -l
...

usb.vmhba33-usb.0:0-mpx.vmhba33:C0:T0:L0
Runtime Name: vmhba33:C0:T0:L0
Device: mpx.vmhba33:C0:T0:L0
Device Display Name: Local USB Direct-Access (mpx.vmhba33:C0:T0:L0)
Adapter: vmhba33 Channel: 0 Target: 0 LUN: 0
Adapter Identifier: usb.vmhba33
Target Identifier: usb.0:0
Plugin: NMP
State: active
Transport: usb

Lo curioso de todo esto es que el VMkernel monta automáticamente el dispositivo en el directorio /vmfs/volumes/NO NAME, el cual es realmente un enlace simbólico a /vmfs/volumes/mpx.vmhba33:C0:T0:L0:1.

~ # ls -al /vmfs/volumes
...
l---------    0 root     root               1984 Jan  1  1970 NO NAME -> mpx.vmhba33:C0:T0:L0:1
drwxr-xr-x    1 root     root                  8 Jan  1  1970 c2a427e4-2d317086-fef9-b5750d88536c
l---------    0 root     root               1984 Jan  1  1970 datastore1 -> 4c0d40f4-c5706eb3-98db-001560a6d735
drwxr-xr-x    1 root     root                  8 Jan  1  1970 mpx.vmhba33:C0:T0:L0:1