Tag Archive: administración


Hoy, he visto este post “Fuga de información en Symfony al chequear requisitos” y me he preocupado al instante, ya que trabajo con este framework y tengo varios proyectos con él. Así que tras realizar un breve análisis de lo que explica en el post, he llegado a la conclusión que esas fugas son producidas por una mala configuración al subirlo al servidor web. Voy a explicar un poco mejor la organización de carpetas y los posibles fallos de configuración que podrían crear este error.

Estructura de carpetas en symfony

Estructura de carpetas en symfony

La imagen anterior muestra la estructura básica de un proyecto en Symfony2. Nos vamos a centrar en dos carpetas. La carpeta web es la parte pública del proyecto, donde tenemos el controlador principal (punto de entrada de todas las peticiones) y todos los recursos estátitcos que utilizarán nuestras páginas (imágenes, css, javascript, etc). Por otra parte, tenemos la carpeta app ,donde se guarda toda la configuración de nuestro proyecto y el archivo check.php. Según la filosofía de seguridad de Symfony la carpeta app NUNCA debería de ser accesible a través del servidor web, si eso ocurriera, sería desastroso ya que ahí tenemos contraseñas en texto plano, logs, etc. Así que cuando publiquemos un proyecto, siempre debermos dejar visible SOLO la carpeta web, para evitar problemas.  Si por desgracia hay que publicar la carpeta principal del proyecto, en principio no habría problema ya que por defecto todos los directorios críticos vienen protegidos mediante un archivo .htaccess con el siguiente contenido:


<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>

Por lo que es importante que nuestro apache permita sobreescribir estas directivas. Por que si no, tendríamos un problema mucho mayor que acceder al fichero check.php.

Fuga de Parameters.yml

Un ejemplo de lo que puede ocurrir con una mala configuración de Apache

Visto todo esto, he caido de que hay otro punto de fuga de información importante. Dentro del directorio web, tenemos el archivo app.php que es el controlador principal, el punto de entrada de todas las peticiones. También tenemos el fichero app_dev.php, también controlador principal pero que nos permite utilizar el entorno de desarrollo. Este entorno nos suele dar varias ventajas cuando estamos desarrollando y depurando un proyecto, una de ellas es la barra de “profiler” que nos permite hacer un seguimiendo de muchisima información.

El profiler en accion

El profiler en accion

Si se accede a esta información en producción, podrian obtener todas las rutas de nuestro proyecto, acceso al phpinfo, las consultas sql que utilicen nuestras páginas, bundles usados por el proyecto y la versión de symfony. Supongo que me dejaré alguna cosa en el tintero, pero cómo veis no es moco de pavo. Así que es importante no subir este fichero a los servidores de producción o modificarlos para incluir alguna restricción. Por defecto, incluyen este pedazo de código:


if (isset($_SERVER['HTTP_CLIENT_IP'])
|| isset($_SERVER['HTTP_X_FORWARDED_FOR'])
|| !in_array(@$_SERVER['REMOTE_ADDR'], array('127.0.0.1', 'fe80::1', '::1'))
) {
header('HTTP/1.0 403 Forbidden');
exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}

Que en principio, parece que nos protege. Pero según creo, de esto por ahora sólo son conjeturas, si nuestro servidor está detrás de un proxy, permite saltarse la restricción debido a que una de las condiciones (isset($_SERVER[‘HTTP_X_FORWARED_FOR’))  permite bypasearlo. Por lo que habría que editarlo.

Cómo recomendación final, es importante revisar todos estos puntos cuando tengamos el proyecto en producción para evitar dar demasiadas pistas a posibles atacantes y ahorrarno un disgusto en el futuro.

Instalando gitolite

Una vez que tenemos nuestro servidor de git funcionando de forma básica. Pero si queremos darle un uso serio y va a ser utilizado por más de una persona, lo mejor es añadirle un control de seguridad por usuarios. Para eso, podemos utilizar gitolite.
Los requisitos que hay que tener en el servidor:

  •  git 1.6.6+
  • perl 5.8.8+
  • openssh 5.0+
  • Un usuario dedicado para almacenar los repositorios. Como usuario ,vamos a utilizar el que usuario git creado anteriormente.

Cumpliendo estos requisitos, la instalación de gitolite es muy sencilla siguiendo los siguientes pasos:

  1. Nos logueamos con el usuario git.
    $ sudo su - git
    
  2. Hay que asegurarse que el archivo ~/.ssh/authorized_key no existe o está vacio.
    $ rm .ssh -rf
    
  3. Descargamos y configuramos gitolite:
    $ cd /home/git
    $ git clone git://github.com/sitaramc/gitolite
    $ mkdir bin -p
    $ gitolite/install -to ./bin
    $ bin/gitolite setup -pk git.pub
    

    Lo que estamos haciendo es lo siguiente, nos descargamos el proyecto de github, creamos una carpeta bin, donde se van a guardar los ejecutables de gitolite. Yo prefiero hacerlo dentro del home de git, para no guarrear mucho el servidor. Con el comando gitolite/install -to ./bin le indicamos que la instalación la haga en la carpeta que acabamos de crear. Por último, al hacer setup, configura automáticamente gitolite, con -pk git.pub le estamos diciendo que utilice el archivo git.pub, que contiene una clave pública, para hacer el logueo de usuario administrador. Este archivo con la clave pública, deberemos crearlo y pasarselo nosotros. Con esto ya tenemos gitolite configurado para empezar a trabajar.

Creación de la llave pública y privada

Para crear el par llave pública/privada, es tan sencillo como ejecutar:

$ ssh-keygen -t rsa

Nos preguntará donde queremos guardar la clave privada. En nuestro le ponemos el nombre git, para que lo haga en el directorio actual. Nos pedirá una passphrase para proteger la clave privada, en mi caso prefiero dejarla vacia. Nos creará dos archivos nuevo, uno llamado git a secas, que es la clave privada y otro llamado git.pub que es la clave pública. Esta clave pública es la que utilizamos en el apartado anterior. La clave privada, la tendremos que poner en el cliente para poder acceder a la configuración administrativa de gitolite.

Configuración de usuarios y repositorios

Ahora en el cliente, con nuestra clave privada, normalmente en ~/.ssh/id_rsa, hacemos un clone del panel administrativo de gitolite:

$ git clone git@host:gitolite-admin

Si todo está correctamente, hará el pull del proyecto directamente, sin pedir ninguna contraseña. En caso de que nos pida una contraseña, algo estamos haciendo mal con las claves privada/publica.

Dentro del proyecto gitolite-admin hay dos carpetas, config y keydir. En config tenemos el fichero de configuración de gitolite y en keydir, tendremos que poner las claves públicas de los usuarios.

Para configurar gitolite, os dejo el enlace de  la documentación oficial y de un libro de git que a mi me ha servido de mucha ayuda.
Una vez hecho todos los cambios necesarios, haremos un push al servidor y gitolite se encargará automaticamente de actualizar la configuración y el acceso a través de las claves.
Ahora desde nuestro cliente,  podremos ver los repositorios a los que tenemos acceso, así como los permisos:

ssh git@host info

Si pide contraseña, esque hay algún problema con las claves. Si muestra la informaci´no, todo ha ido perfecto y ya podremos trabajar tranquilamente, teniendo el control de seguridad extra, en nuestros repositorios.

Toca volver a reescribir el post, ya que por problemas de hosting, se me perdieron varios posts. Vuelvo a retomar el tema del control de versiones.  Últimamente se habla mucho de GIT,  y la verdad que con razón. Este sistema de control de versiones, es ligero y sencillo de utilizar, sobre todo desde un IDE con soporte para este sistema.

Lo ideal, aparte de utilizarlo en local, es tenerlo en un servidor remoto para poder tenerlo como copia de seguridad, colaborar con otros desarrolladores, etc. La comunidad de github es perfecta para esto. Aunque tiene la desventaja de que los repositorios han de ser públicos, a noser que quieras pasar por caja. Así que vamos a pasar a implementar nosotros en un servidor.

En este post, vamos a hacerlo de la forma más básica.  Como requisitos, nuestro servidor deberá tener ssh activo, ya que es el mejor sistema de los que utiliza git, para poder hacer clone y push de nuestros proyectos. Así que vamos a ponernos manos a la obra.

Primero, instalar git:


$ sudo aptitude install git

Con esto, nos instala todo lo necesario. En mi caso lo he hecho desde una Ubuntu 12.04, en versiones anteriores, el paquete era git-core, pero ahora lo marca como deprecated.

Ahora, con git instalado,  vamos a crear un usuario, que será el encargado de manejar el repositorio. De esta forma lo tenemos todo más ordenado.

$ sudo adduser git

Ya con esto, podemos empezar a trabajar sin problemas. Crearemos nuestro repositorio desde el servidor, antes de empezar a trabajar.

$ cd /home/git
$ sudo git init --bare miProyecto
$ sudo chown git.git miProyecto -R

Lo que hemos hecho aquí, es crear el repositorio vacio. Es importante la opción –bare, ya que necesitamos que cree solo el repositorio, si no lo ponemos, entenderá que estamos en un directorio de trabajo y nos creara el repositorio para el directorio actual. Esto después nos creará conflictos a la hora de trabajar y hacer push desde el cliente. Lo siguiente es cambiarle el propietario del proyecto, para no tener conflictos de permisos.

Con todo los pasos anteriores listos, ya podemos empezar a trabajar. Así que nos vamos a nuestro cliente y hacemos clone del repositorio:

$ git clone ssh://git@host/~/miProyecto
$ echo "Hola mundo" &gt; index.php
$ git add index.php
$ git commit -m "first commit"
$ git push origin master

Al hacer clone del repositorio remoto, seguramente nos de un warning de que el es un directorio de trabajo vacio. Es normal, ya que aún no hemos creado contenido. Así que creamos un fichero y hacemos commit. Por último, hacemos un push para subir los cambios al repositorio remoto. Ya que el clone está hecho desde el remoto, la conexión está establecida y no hace falta realizar ninguna configuración extra.

Después de mucho tiempo sin trabajar con mi servidor local de prueba, habia olvidado la contraseña del usuario root de la base de datos. Así que una googleada rápida he llegado a la siguiente solución:

Usted puede recuperar la contraseña del servidor de base de datos MySQL con los siguientes pasos:

Paso 1: Detener cualquier proceso del servidor MySQL.
Paso 2: Iniciar el proceso del servidor MySQL (mysqld) con la opción –skip-grant-tables por lo cual este no preguntará por la contraseña.
Paso 3: Conectar al servidor MySQL como el usuario root
Paso 4: Configurar una nueva contraseña para la nueva contraseña root
Paso 5: Salir y reiniciar el servidor MySQL

A continuación están los comandos necesarios para cada uno de los pasos mencionados anteriormente (iniciar sesión como el usuario root):

Paso # 1: Detener el servicio mysql

# /etc/init.d/mysql stop

Salida:

Stopping MySQL database server: mysqld.

Paso # 2: Iniciar el servidor MySQL sin contraseña:

# mysqld_safe --skip-grant-tables

Salida:

[1] 5988

Iniciando el motor de mysqld de las bases de datos desde /var/lib/mysql

mysqld_safe[6025]: started

Paso # 3: Conectar al servidor mysql usando el cliente mysql:

# mysql -u root

Salida:

Bienvenido al monitor de MySQL.  Comandos y con ; o \g.

Your MySQL connection id is 1 to server version: 5.0.21-log

Tipiar ‘help;’ o ‘\h’ para obtener ayuda. Tipiar ‘\c’ para en vaciar el buffer.

mysql>

Paso # 4: Configurar una nueva contraseña del servidor MySQL para el usuario root:

mysql> use mysql;
mysql> update user set password=PASSWORD("NEW-ROOT-PASSWORD") where User='root';
mysql> flush privileges;
mysql> quit

Paso # 5: Detener el servidor MySQL:

# /etc/init.d/mysql stop

Salida:

Stopping MySQL database server: mysqld

STOPPING server from pid file /var/run/mysqld/mysqld.pid

mysqld_safe[6121]: ended

[1]+  Done                    mysqld_safe –skip-grant-tables

Paso # 6: Iniciar el servidor MySQL y verificar la contraseña:

# /etc/init.d/mysql start
# mysql -u root -p

Fuente: http://www.codigomaestro.com/mysql/recuperar-contrasena-root-de-mysql/

Sé que esto lleva casi un mes sin actividad,  no esque haya abandonado el blog, es solo que estamos en época de exámenes, con lo cual mi tiempo actualmente está ocupado al completo con los estudios y el trabajo, con lo cual, no puedo dedicarle el esfuerzo necesario a este blog y otras ideas que tengo en mente.

Aun así, voy a  hacer un pequeño aporte. Si teneis algún servidor gestionado mediante la herramienta DirectAdmin, vereis que el acceso directo a base de datos está capado, con lo que si queremos crear una base de datos, siempre tendremos que hacerlo mediante esta herramienta y poniendo el prefijo del dominio.  Ahora, si somos el administrador del servidor, lo lógico esque tuvieramos acceso completo a todos nuestros servicios, incluido el gestor de bases de datos por consola, para poder crear/modificar/borrar ciertas cosas que a través de direct admin no pudieramos. En ese caso, si buscamos el directorio de instalación del DA y dentro de su directorio de configuraciones, tendremos un fichero mysql.conf , donde está el usuario y la contraseña que utiliza DA para acceder al gestor de base de datos y este usuario tiene permisos de administrador. También hay otro fichero, el directadmin.conf, donde encontraremos bastante información y podremos tocar parámetros de la aplicación.

En mi servidor, el directorio de la configuración del DA es el siguiente:  /usr/local/directadmin/conf

Espero que esta información os resulte de ayuda en algún momento de vuestra vida como administradores.