Apartamento En Familia

Apartamento En Familia
Apartamento de playa para vacaciones. http://www.apartamentoenfamilia.es. Número registro HUTT-005768

miércoles, 21 de octubre de 2015

Restablecer contraseña olvidada mediante LiveCD y chroot

chroot en los sistemas operativos derivados de Unix, es una operación que invoca un proceso, cambiando para este y sus hijos el directorio raíz del sistema. "chroot" puede referirse a la llamada de sistema chroot(2) o al programa ejecutable chroot(8). Comúnmente, el entorno virtual creado por chroot a partir de la nueva raíz del sistema se conoce como "jaula chroot".
El sistema chroot fue introducido por Bill Joy el 18 de marzo de 1982 (17 meses antes de que BSD 4.2 fuera publicado) para probar su sistema de instalación y construcción.
Al usar "chroot" para invocar un proceso, se impedirá al mismo y a sus procesos hijos acceder por su nombre a ningún fichero que esté por encima del nuevo directorio raíz. Esto es entendido a menudo como un dispositivo de seguridad, ya que en teoría crea una zona segura para ejecutar un programa que provoca desconfianza, no está probado, o de alguna forma puede presentar un comportamiento peligroso para la integridad del sistema. Sin embargo, cabe señalar que las jaulas chroot no son tan seguras como otro tipo de jaulas o la virtualización.
(Fuente Wikipedia)

Y ahora la pregunta sería... ¿y en qué nos podría ayudar chroot para restablecer nuestra contraseña?. Pues bien, de lo que se trata es primero ser root de nuestro PC. Una vez somos root, evidentemente ya tenemos acceso a las herramientas para cambiar contraseñas. Cuando cambiamos contraseñas, lo hacemos mediante el comando passwd, que lo que hace es leerlas y grabarlas en disco. Así pues, si arrancamos la máquina con un LiveCD ya tendremos root en esa máquina. Lo malo es que el sistema de archivos con el que arranca, evidentemente, está en memoria y no es donde realmente están las contraseñas, sino que están en el disco duro. Así pues, chroot nos ofrece la posibilidad de "cambiar" nuestra raíz del sistema de archivos (la del LiveCD) por otro sistema de archivos (la de la partición en donde se encuentran las contraseñas). Si miramos el esquema de arriba puede que entendamos mejor el cambio de sistema de archivos. Arriba de todo tenemos / (root) pero luego de hacer el chroot convertimos /mnt en nuestro nuevo / root. 

De acuerdo, ahora que vemos todas las herramientas que usaremos (LiveCD, passwd, mount, chroot) hagamos el procedimiento paso a paso (cada uno que lo adecue a su escenario):

Insertamos en LiveCD de 32 o 64bits. No hace falta que sea la misma distribución, pero si que si el sistema en donde estan las contraseñas es 32bits o 64bits, el LiveCD sea de los mismos bits. 

Una vez arrancado el sistema LiveCD, abrimos un terminal y escribimos

sudo -s

Con esto seremos ya root de la maquina. Crearemos una carpeta en donde montaremos la partición de nuestro disco duro en donde se encuentran las contraseñas (no montes la /boot o la swap!). Imaginemos que la partición que buscamos es la /dev/sda2 . 

mkdir /mnt/recuperar
mount /dev/sda2 /mnt/recuperar

Pues bien, ahora ya tenemos el sistema de archivos del PC montando como una carpeta del sistema de archivos del LiveCD. Ahora toca hacer el cambiazo:

chroot /mnt/recuperar

Ya lo tenemos cambiado. Ahora nuestro / (root), es el de la partición de nuestro disco duro. Ahora toca cambiar la contraseña, que lo hacemos como se hace habitualmente. 

passwd

Como somos root, no nos preguntará por nuestra anterior contraseña. Si por el contrario queremos cambiar la contraseña de otro usuario que no sea el root deberemos mandarlo por parámetro:

passwd user

Con esto ya habremos cambiado la contraseña. Ahora salimos del chroot mediante exit y desmontamos la partición:

exit
umount /mnt/recuperar

Ahora ya podemos apagar el sistema y arrancar con normalidad y con la contraseña restablecida. 


martes, 20 de octubre de 2015

Evitar bdb_equality_candidates en OpenLDAP creando índices

El índice de una base de datos es una estructura de datos que mejora la velocidad de las operaciones, por medio de identificador único de cada fila de una tabla, permitiendo un rápido acceso a los registros de una tabla en una base de datos. Al aumentar drásticamente la velocidad de acceso, se suelen usar, sobre aquellos campos sobre los cuales se hacen frecuentes búsquedas.
El índice tiene un funcionamiento similar al índice de un libro, guardando parejas de elementos: el elemento que se desea indexar y su posición en la base de datos. Para buscar un elemento que esté indexado, sólo hay que buscar en el índice dicho elemento para, una vez encontrado, devolver el registro que se encuentre en la posición marcada por el índice.
Los índices pueden ser creados usando una o más columnas, proporcionando la base tanto para búsquedas rápidas al azar como de un ordenado acceso a registros eficiente.
Los índices son construidos sobre árboles BB+B* o sobre una mezcla de ellos, funciones de cálculo u otros métodos.
El espacio en disco requerido para almacenar el índice es típicamente menor que el espacio de almacenamiento de la tabla (puesto que los índices generalmente contienen solamente los campos clave de acuerdo con los que la tabla será ordenada, y excluyen el resto de los detalles de la tabla), lo que da la posibilidad de almacenar en memoria los índices de tablas que no cabrían en ella. En una base de datos relacional un índice es una copia de una parte de la tabla.
(Fuente Wikipedia)

Cuando en nuestro log aparece algo como :

Oct 20 10:22:01 server slapd[16752]: <= bdb_equality_candidates: (memberUid) not indexed

quiere decir que se ha realizado una búsqueda por un campo el cual no esta indexado y ha sido consultado mediante equal (ya veremos más adelante que significa). De haber estado indexado, la búsqueda sería más rápida. Así pues, una vez creada nuestra base de datos deberíamos indexarla por aquellos campos que sabemos que van a ser consultados.

Creamos un archivo LDIF llamado, por ejemplo,  olcDbIndex.ldif con este contenido (puedes variarlo según tus necesidades):
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: cn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: sn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: uid pres,sub,eq
-
add: olcDbIndex
olcDbIndex: displayName pres,sub,eq
-
add: olcDbIndex
olcDbIndex: default sub
-
add: olcDbIndex
olcDbIndex: uidNumber eq
-
add: olcDbIndex
olcDbIndex: gidNumber eq
-
add: olcDbIndex
olcDbIndex: mail,givenName eq,subinitial
-
add: olcDbIndex
olcDbIndex: dc eq
Para saber exactamente que significa pres, sub y eq sería conveniente saber estas definiciones:
  • pres (presence) debe usarse si buscamos mediante un atributo especifico.
  • approx (Approximate) se debe usar si buscamos por resultados que sean similares a nuestra busqueda "sn~=person". Es decir, que el resultado se aproxime. 
  • sub (substring) debe utilizar en las búsquedas del timpo “sn=sm*”. Es decir, con comodines. 
  • eq (equality) se debe usar en comparaciones directas. Es decir, en comparaciones de igualdad.
Una vez entendido y generado el archivo LDIF, ahora tenemos que inyectarlo en la base de datos mediante el comando ldapmodify :

ldapmodify -Y EXTERNAL -H ldapi:/// -f ./olcDbIndex.ldif

Importante crear siempre una copia de seguridad antes de manipular la base de datos.


viernes, 16 de octubre de 2015

Reescanear manualmente el sistema de archivos de owncloud


En una entrada anterior explicaba como instalar un servidor owncloud:




En ocasiones podemos necesitar reescanear el sistema de archivos de owncloud. ¿Por qué podemos necesitarlo? Imaginemos el escenario en el cual usemos el sistema de archivos de owncloud de manera compartida con otros servicios como ftp o ssh. En esos casos, subir un archivo directamente al espacio de directorios de owncloud haría que hubiera una incongruencia entre lo que realmente está en el sistema de archivos y lo que la base de datos de owncloud cree que tiene. Este uso no corresponde con las buenas prácticas de uso de owncloud (Debugging Sync-Issues) , pero a la práctica es algo que se puede hacer y se hace. Un ejemplo claro es cuando un usuario pierde un archivo y quiere que se lo restauremos desde una copia de seguridad. Se lo hacemos y luego.. toca reescanear su directorio manualmente. Así pues.. vamos a ver como se hace:

Para escanear manualmente el sistema de archivos tenemos ejecutable php en el directorio del owncloud llamado console.php. Con este archivo podemos hacer diversas operaciones. La que nos interesa de escanear el directorio lo haremos mediante el parámetro files:scan . Para poder ejecutar dicho archivo, deberemos hacerlo desde el usuario al cual pertenece dicho archivo. Lo normal es que pertenezca a www-data o root. Así pues, si pertenece a www-data, como seguramente no tendrá una shell declarada y no tendrá password, lo haremos ejecutaremos mediante sudo. Primero entramos en la carpeta en donde tengamos en owncloud instalado y luego ejecutamos el console.php:

cd /var/www/owncloud

sudo -u www-data php console.php files:scan usuario


En donde usuario lo sustituiremos por el nombre de usuario al cual queramos reescanear su directorio. Si queremos reescanear TODO el sistema de archivos de owncloud:


sudo -u www-data php console.php files:scan --all


Si esta práctica de reescaneo es muy común, es posible que queramos definir trabajos en segundo plano









viernes, 9 de octubre de 2015

Un proceso de Apache me consume el 100% de CPU. ¿Quien? ¿Por qué?

El servidor HTTP Apache es un servidor web HTTP de código abierto, para plataformas Unix (BSDGNU/Linux, etc.), Microsoft WindowsMacintosh y otras, que implementa el protocolo HTTP/1.12 y la noción de sitio virtual. Cuando comenzó su desarrollo en 1995 se basó inicialmente en código del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo. Su nombre se debe a que alguien quería que tuviese la connotación de algo que es firme y enérgico pero no agresivo, y la tribu Apache fue la última en rendirse al que pronto se convertiría en gobierno de EEUU, y en esos momentos la preocupación de su grupo era que llegasen las empresas y "civilizasen" el paisaje que habían creado los primeros ingenieros de internet. Además Apache consistía solamente en un conjunto de parches a aplicar al servidor de NCSA. En inglés, a patchy server (un servidor "parcheado") suena igual que Apache Server.

(Fuente Wikipedia)

En ocasiones vemos que tenemos las CPUs de nuestro servidor al 100%. Algo parecido a esto:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
www-data 21882 99.3  3.2 560668 130204 ?       R    12:44   9:35  \_ /usr/sbin/apache2 -k start

En estos casos, parece fundamental averiguar quién se está conectando al servidor y como está haciendo para provocar un uso de la CPU del 100% . Para ello podemos hacerlo facilmente mediante el PID del proceso (en el ejemplo el 21882). Una vez tenemos el PID, usando la herramienta netstat con el parámetro -p podemos localizar el origen del problema.

Netstat (network statistics) es una herramienta de línea de comandos que muestra un listado de las conexiones activas de una computadora, tanto entrantes como salientes. Existen versiones de este comando en varios sistemas como Unix,GNU/LinuxMac OS XWindows y BeOS.
La información que resulta del uso del comando incluye el protocolo en uso, las tablas de ruteo, las estadísticas de las interfaces y el estado de la conexión. Existen, además de la versión para línea de comandos, herramientas con interfaz gráfica (GUI) en casi todos los sistemas operativos desarrollados por terceros.
(Fuente Wikipedia)

Así pues, siguiendo con el ejemplo:

netstat -p | grep 21882

Con esto obtendremos todas las conexiones, listadas junto a su PID/program y mediante la tuberia se lo pasamos al comando grep para que filtre y nos muestre solo lo que coincida con 21882 (el PID de nuestro ejemplo). Veremos algo similar a esto:

tcp        0      0 localhost:55933         localhost:ldap          ESTABLECIDO 21882/apache2


Interpretando la lectura (en el ejemplo) sería que el proceso 21882 pertenece a una conexión del apache2 al servidor ldap que esta instalado en local. Bueno.. es una buena pista ¿no?

jueves, 1 de octubre de 2015

Solucionar en Linux "Aplicación bloqueada por la seguridad de Java"

Java es un lenguaje de programación de propósito generalconcurrenteorientado a objetos que fue diseñado específicamente para tener tan pocas dependencias de implementación como fuera posible. Su intención es permitir que los desarrolladores de aplicaciones escriban el programa una vez y lo ejecuten en cualquier dispositivo (conocido en inglés como WORA, o "write once, run anywhere"), lo que quiere decir que el códigoque es ejecutado en una plataforma no tiene que ser recompilado para correr en otra. Java es, a partir de 2012, uno de los lenguajes de programación más populares en uso, particularmente para aplicaciones de cliente-servidor de web, con unos 10 millones de usuarios reportados

(Fuente Wikipedia)

En ocasiones miramos de ejecutar una aplicación escrita en java, usualmente web, en la que el archivo es un jnlp que debe ser lanzado por nuestra consola de java. Al hacerlo, según la política de seguridad configurada, nos saldrá un error "Aplicación bloqueada por la seguridad de Java". Para solucionar el problema tenemos que:

Abrir el Panel de Control de Java:


Seleccionamos Seguridad (Security) y lo configuramos en un modo menos restrictivo. Por ejemplo, si lo ponemos en seguridad Media (Medium) tendremos menos mensajes de advertencia.



Para finalizar, podemos añadir a la lista de excepciones la URL desde donde nos daba el error. 
Con estos cambios (o alguno de ellos al menos) podemos evitar el error de bloqueo.

En la página web de Oracle explica detalladamente como hacerlo, pero se centran en MacOS y Microsoft : https://www.java.com/es/download/help/appsecuritydialogs.xml

Este video muestra paso a paso lo anteriormente explicado:




That u don't know what you've got 'til it's gone