Archivo del Autor: Angel

Solución al error “password check failed for user (root)” del comando su

Posted on por
1

Por alguna razón, en una máquina me era imposible utilizar el comando su para moverme de un usuario sin privilegios al usuario root.

Googleando un poco, otros usuarios sugerían acciones como las siguientes:

  • Revisar que efectívamente el password era correcto: sí, era un password correcto.
  • Revisar que la entrada para root en /etc/passwd y /etc/shadow no tuviera algún error: se veía todo normal.
  • Verificar que los archivos en /etc/pam.d/ (particularmente /etc/pam.d/su, así como los archivos common-auth, common-password, etc.) no tuvieran alguna linea de configuración que nos impidiera utilizar el comando correctamente: para esto comparé los archivos contra los de otro sistema funcionando bien, y todo era idéntico.

Pues bien, tras estar seguro de que no era ningún problema de los anteriores, revisando el archivo auth.log (En Debian está en /var/log), noté los siguientes errores:

Mar 20 04:53:42 ih unix_chkpwd[23238]: check pass; user unknown
Mar 20 04:53:42 ih unix_chkpwd[23238]: password check failed for user (root)

Así que, tras buscar un poco más, mi problema era de permisos en el comando su.

Por algún motivo, en mi servidor este archivo tenía permisos incorrectos 755, cuando debe tener permisos 4755 (setuid).

Así que lo solucionamos con un chmod

chmod 4755 /bin/su

Y ahora podemos utilizar normalmente el comando.

Nota: Este problema me ha pasado anteriormente en otros servidores virtuales, y mi teoría es que está relacionado con un template de OpenVZ con los permisos mal configurados en este archivo.

Obtener permisos numéricos de un archivo en Linux

Posted on por
Responder

Una entrada rápida.

Cuando hacemos un comando ls -l sobre un archivo

# ls -al file
 -rwxr-xr-x 1 root root 29152 Feb 15 2011 file

 

Podemos observar los permisos que le corresponden

-rwxr-xr-x

Por si en alguna ocasión no recordamos como se traducen estos permisos al formato de permisos numéricos, que es la manera básica en que el comando chmod trabaja, podemos obtenerlos del siguiente modo

#stat -c %a file

755

 

IPMItool Solución al error Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0

Posted on por
Responder

IPMI o Intelligent Platform Management Interface, es un sistema para realizar monitoreo y administración de forma remota mediante un hardware especial acoplado a un sistema de cómputo que trabaja de forma independiente a este. En palabras simples, si nuestro sistema se encuentra apagado, el módulo IPMI puede seguir funcionando, e incluso nos permite encender nuevamente el sistema. Generalmente, viene combinado con una interfaz KVM over IP, que nos permite realizar una conexión tipo VNC al sistema, y realizar acciones como si estuviéramos frente a él.

Este tipo de hardware se utiliza comúnmente en entornos de servidor, y en mi caso particular es muy útil porque me es posible realizar la instalación remota  del sistema operativo.

Hoy intentaba utilizar la interfaz IPMI para la parte de monitoreo. Lo más típico, es monitorear las temperaturas de nuestro sistema.

En Linux, la herramienta más popular, además de las propietarias que vienen con cada sistema, es IPMItool.

Pues bien, tras instalar el paquete (Debian), y ejecutar el comando:

ipmitool chassis power status

obtengo el error:

 

Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory

Tras googlear un poco, he notado que es un problema típico, así que para solucionarlo debemos cargar algunos módulos de kernel adicionales

modprobe ipmi_si
modprobe ipmi_msghandler
modprobe ipmi_devintf

Con esto ya podemos ejecutar otra vez el comando y tenemos

Chassis Power is on

O por ejemplo, para los sensores
# ipmitool sensor
CPU 1 Temp | 43.000 | degrees C | ok | na | na | na | 81.000 | 89.000 | 93.000
CPU 2 Temp | 49.000 | degrees C | ok | na | na | na | 81.000 | 89.000 | 93.000
Ambient Temp | 20.000 | degrees C | ok | na | na | na | 38.000 | 40.000 | 45.000
P12V | 12.222 | Volts | ok | na | 10.773 | 11.151 | 12.789 | 13.167 | na
P1.5V | 1.474 | Volts | ok | na | 1.346 | 1.392 | 1.603 | 1.650 | na
P3.3V | 3.373 | Volts | ok | na | 2.958 | 3.062 | 3.529 | 3.616 | na
P5V | 5.200 | Volts | ok | na | 4.498 | 4.628 | 5.330 | 5.486 | na
Vtt 1.2V | 1.100 | Volts | ok | na | 0.986 | 1.021 | 1.276 | 1.320 | na
Vcc 3.3V AUX | 3.339 | Volts | ok | na | 2.975 | 3.079 | 3.546 | 3.633 | na
...

 

Habilitar y deshabilitar la interfaz XML-RPC en WordPress

Posted on por
1

XML-RPC es una característica utilizada como una interfaz estándar para realizar comunicaciones entre el servidor de WordPress y diversos clientes, de modo que se pueden realizar cambios en el sistema como normalmente se harían desde el panel de control.

Con esto se han podido desarrollar clientes como la app de WordPress para iOS.

En versiones recientes (3.5+) esta interfaz viene habilitada por defecto.

Sin embargo, hace poco se documentó una vulnerabilidad que permitía utilizar esta interfaz para realizar un escaneo de puertos a otros sistemas y peor aún, realizar ataques de DoS a traves de nosotros, de modo que el atacante se vuelve indetectable (más información aquí).

De modo que lo más sensato, es deshabilitar esta interfaz mientras los desarrolladores eliminaban este problema.

Así que en mi búsqueda hay diversas maneras de realizar esto.

  • Mediante un plugin:

http://wordpress.org/extend/plugins/prevent-xmlrpc/

 

  • Mediante las opciones de WordPress

La opción que existían para hacerlo mediante el panel de control ya no existe más, y hacerlo mediante la base de datos (pre_option_enable_xmlrpc y option_enable_xmlrpc) ya no están recomendadas y en algún momento dejarán de funcionar.

Así que la manera correcta de hacerlo ahora es agregando al final en wp-config.php

add_filter('xmlrpc_enabled', '__return_false');

Fuente: http://wpengineer.com/2484/xml-rpc-enabled-by-default-in-wordpress-3-5/

 

  • Directamente con ayuda del servidor Web

Finalmente, todos los servidores Web modernos tienen mecanismos para denegar el acceso a archivos y directorios específicos, de modo que en este caso hay que denegar el acceso a /xmlrpc.php. No documentaré más sobre esto por el momento.

 

 

Como recomendación final, siempre hay que tratar de mantener actualizados nuestros sistemas, y estar al pendiente de posibles agujeros de seguridad que se pudieran publicar en Internet.

Nota: La última versión de WordPress (3.5.1 al día de hoy) arregla este problema.

Esto puede ser útil posteriormente, ya que este tipo de APIs suelen volver a tener problemas en algún momento, o alguno de nuestros plugins que utilice XML-RPC podría tener algún problema de seguridad, y mientras tanto lo mejor sería aplicar esta medida.