Archive

You are currently browsing the archives for the Tutoriales category.

Nov

30

Protecci?n contra ataques de fuerza bruta mediante fail2ban en Debian Jessie

By Jose Antonio Cely Saidiza

Fail2ban ( http://www.fail2ban.org/ ) es una aplicaci?n que se usa para bloquear conexiones remotas despu?s de una cantidad de intentos fallidos. El funcionamiento de Fail2ban es muy simple, comprueba archivos de log y si detecta registros de intentos fallidos, ejecuta autom?ticamente los comandos de IPTables para bloquear al host que esta intentando realizar la conexi?n. Fail2ban soporta muchos servicios como lo son ftp, apache, imap, pop, etc; incluso tambi?n aplicaciones web.
Para este caso documentar? el t?pico escenario, donde tenemos un servidor Linux conectado a internet permanente y por cuestiones administrativas tenemos el servicio SSH abierto a cualquier IP (!!!). Un servidor de este tipo es muy atacado por robots o creckers con t?cnicas de fuerza bruta, usando sencillamente un script que mediante un diccionario de claves o generador de palabras intenta frecuentemente autenticarse como usuario root.
Por ejemplo viendo los logs de un servidor personal que mont? hace poco, v? como tengo miles de intentos de login remoto. Por ejemplo viendo los ?ltimos intentos de login mediante el comando:

# tail /var/log/auth.log

Veo como un hijo de puta con la direcci?n IP 116.31.116.28 se est? intentando conectar como root. Por los tiempos de diferencia entre cada conexi?n de pocos segundos seguramente es un robot. As? pues, a instalar fail2ban!.

Instalaci?n y configuraci?n

Los siguiente comando se ejecutan como usuario root en el servidor. Si usa sudo antepongalo a los comandos.

Instalamos el paquete est?ndar de Debian Jessie estable:

# apt-get install fail2ban

Una vez instalado copiamos el archivo de configuraci?n para crear una configuraci?n local:

# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Ahora editamos el archivo recientemente copiado /etc/fail2ban/jail.local, el archivo es extenso y viene casi listo y documentado. Un par?metro t?pico por ejemplo para cambiar es ?bantime?, que es el tiempo que el host remoto tardar? bloqueado hasta que nuevamente fail2ban permita el intento de conexi?n, en mi caso lo edit? para 1200 segundos, es decir, 20 minutos:

bantime = 1200

Por otro lado, confirm? que el servicio SSH este activado y en el caso de esta versi?n de Jessie viene activado por default la supervisi?n:

[ssh]
enabled = true

Si hicimos alg?n cambio, se puede reiniciar fail2ban mediante el comando:

# service fail2ban restart

Esto es todo, failban inciar? a supervisar y bloquear los servicios que hemos definido. Por ejemplo en la siguiente captura realic? tres intentos intencionalmente fallidos al servidor y vemos como en el tercer intento me bloquea:

Ante este caso solo queda esperar el ?bantime? para poder volver intentar a conectarme. Como vemos muy facilmente se puede aumentar la seguridad de nuestros servidores.

??

?Dudas, comentarios, sugerencias?

Sigueme en twitter?@josecely

Abr

13

Montando Gitlab en Debian Wheezy

By Jose Antonio Cely Saidiza

El presente artículo explica paso a paso como montar un servidor de repositorios de código fuente con Git (SCV). Hace años escribí sobre los sistemas de control de versiones, aunque ese artículo hablaba sobre el difunto subversion los conceptos de versionamiento son los mismos. Vale la pena aclarar que Git es mucho más avanzado en funcionalidades respecto a Subversion, una de las principales ventajas de Git, es que este es descentralizado, es decir que cada copia o checkout de código fuente puede ser un repositorio independiente. En este caso el servidor es simplemente el oficial para un proyecto, por decirlo así.

Ahora bien, si estamos hablando de un proyecto de desarrollo en el que hay múltiples desarrolladores, ejemplo en un entorno corporativo; tenemos que poder controlar usuarios, grupos, proyectos, ramas, forks, etc. y en este caso es donde la aplicación Gitlab facilita toda esta administración con una fácil interfaz web. Además esta interfaz es muy similar a el práctico (y no tan económico) GitHub Enterprise.

Instalando el servidor

Para la instalación solo necesitamos un sistema debian Wheezy recién instalado lo más limpio posible.

Actualizamos paquetes

# apt-get update -y
# apt-get upgrade -y

Instalamos dependencias

# apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl openssh-server redis-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev logrotate mysql-server mysql-client libmysqlclient-dev sudo python-docutils

Mysql pedirá password de administrador, poner algo seguro y no olvidarlo!

Instalamos el core git

# apt-get install -y git-core

Instalamos Ruby

Removemos viejas versiones de Ruby 1.8 en caso de tenerlo instalado

# apt-get remove ruby1.8

Bajamos Ruby y lo compilamos:

# mkdir /tmp/ruby && cd /tmp/ruby
# curl –progress ftp://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p353.tar.gz | tar xz
# cd ruby-2.0.0-p353
# ./configure –disable-install-rdoc
# make
# make install
# gem install bundler –no-ri –no-rdoc

Creamos el usuario necesario

# adduser –disabled-login –gecos ‘GitLab’ git

Instalamos GitLab shell

# cd /home/git # su git
# git clone https://gitlab.com/gitlab-org/gitlab-shell.git -b v1.9.1
# cd gitlab-shell
# cp config.yml.example config.yml

Editamos el archivo de configuración con el dominio de nuestro servidor (Ej. suservidordecodigo.com)

# vi config.yml

Después instalamos

# ./bin/install
# exit

Base de datos

Aseguaramos MySQL con el siguiente comando (responder si a todo)

# mysql_secure_installation

Luego nos logueamos como administrador de MySQL

# mysql -u root -p

Creamos el usuario para gitlab (No olvidar cambiar el password por algo más seguro)

mysql> CREATE USER ‘git’@’localhost’ IDENTIFIED BY ‘$password’;
mysql> SET storage_engine=INNODB;
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO ‘git’@’localhost’;
mysql> exit;

Comprobamos que podamos ingresar como el usuario git de mysql

# mysql -u git -p -D gitlabhq_production

Si todo es correcto obtendremos el prompot de Mysql después de ingresar el password

mysql>

Salimos

mysql> exit;

GitLab

Nos ubicamos en el directorio de gitlab

# cd /home/git

Hacemos un clone del código fuente

# su git
# git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-7-stable gitlab

Nos ubicamos en el directorio de git

# cd /home/git/gitlab

Copiamos el archivo de configuración de ejemplo

# cp config/gitlab.yml.example config/gitlab.yml

Editamos el dominio cambiando «localhost» por el que corresponda

# vi config/gitlab.yml

Salimos del usuario git

# exit 
# cd /home/git/gitlab

Aseguramos permisos en log/ y tmp/

# chown -R git log/
# chown -R git tmp/
# chmod -R u+rwX log/
# chmod -R u+rwX tmp/
# su git
# mkdir /home/git/gitlab-satellites
# exit
# chmod u+rwx,g+rx,o-rwx /home/git/gitlab-satellites
# cd /home/git/gitlab
# chmod -R u+rwX tmp/pids/
# chmod -R u+rwX tmp/sockets/
# chmod -R u+rwX public/uploads

Copiamos el archivo de configuración de Unicorn

# su git
# cp config/unicorn.rb.example config/unicorn.rb
# cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb
Configuramos las variables para el usuario git y editamos user.email tal cual como este en gitlab.yml
# git config –global user.name «GitLab»
# git config –global user.email «alfuncorreo@algundominio»
# git config –global core.autocrlf input

Editamos para que el email de gitlab coincida con el usuario git (## Email settings)

# vi config/gitlab.yml

Copiamos archivo de configuración de git

# cp config/database.yml.mysql config/database.yml
# chmod o-rwx config/database.yml

Editamos el archivo de configuración con las credenciales establecidas de mysql

# vi config/database.yml

Instalamos

# cd /home/git/gitlab
# bundle install –deployment –without development test postgres aws
# bundle exec rake gitlab:setup RAILS_ENV=production
# exit

Script de inicio

# cp lib/support/init.d/gitlab /etc/init.d/gitlab
# cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab

Comprobamos que funciona la aplicación

# su git
# bundle exec rake gitlab:env:info RAILS_ENV=production

Si todo está bien

# bundle exec rake assets:precompile RAILS_ENV=production
# exit

Reiniciamos gitlab

# /etc/init.d/gitlab restart

Servidor web Nginx

# apt-get install -y nginx
# cp lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab

Editamos el archivo de configuración para que coincida con la configuración (server_name)

# vi /etc/nginx/sites-available/gitlab

Reiniciamos Nginx para que tome los cambios

# service nginx restart

Primer login

En un navegaor accedemos a la URL de nuestro servidor

Primer login en gitlab

El usuario y contraseña por defecto son:
root
5iveL!fe
La primera página nos envía a un formulario para actualizar el password. Obviamente se debe editar por algo seguro.
Después de esto ya podremos acceder a gitlab, crear proyectos, usuarios, etc.

Dashboard de Gitlab

———————————————–

Dudas, comentarios, sugerencias? Sigueme en twitter @josecely

Links
https://www.gitlab.com/
https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md

Ago

14

Montando Dropbox en FreeBSD 9.1

By Jose Antonio Cely Saidiza

 

A la fecha Dropbox no tiene cliente para *BSD, aunque muy solicitado, no hay fechas de RELEASE.
Buscando alternativas en las que no perdiera la sensación de tiempo real con Dropbox en mi Gnome en FreeBSD 9.1, y pensando en no tener que ejecutar comandos constantes para sincronizar, e inspirado en algunas búsquedas; encontré una técnica para que funcione de la manera más transparente Dropbpx en mi Gnome. Supongo con un par de cambios aplica a OpenBSD.

La técnica guerrillera consiste en instalar una máquina virtual (con VirtualBOX, KVM, etc) o usar un computador viejo, y en este montar un Linux y Dropbox, a este combo lo llamaré «servidor Dropbox» (Para Linux si hay daemon oficial para Dropbox). Entonces en FreeBSD solo es montar la partición remota.

Si eres usuario avanzado BSD y lees esto, tal vez te sientas engañado el título del artículo, mis disculpas :)

Hay varias formas de montar la partición remota (NFS, SMB, FUSE, etc); en este caso opté por usar SSHFS (fuse), pues es la más «limpia», por decirlo así, de configurar el pequeño «servidor» Dropbox, solo se instala el sistema base, el servicio ssh y el sistema Dropbox en modo daemon, lo cual es muy «light». Además se puede montar como usuario, nada de editar el fstab o cosas similares.
En mi caso el servidor virtualizado es un i386, con 128Mb RAM, y Debian wheezy y corre como perfectamente bien.
Entonces, primero explicaré como instalar el servidor Dropbox, y luego como configurar FreeBSD para que monte la partición.

Instalando Dropbox en un servidor Linux sin entorno gráfico:

Para el servidor, sirve cualquier Debian básico, entorno mínimo, con sshd. Con el sistema básico, solo hay que seguir las instrucciones para la instalación en la página oficial de www.dropbox.com, con unos pequeños ajustes.

TODOS estos pasos se ejecutan como usuario (en mi caso josecely), ajustenlo a su usuario y por favor… no usen el root para estos menesteres!

Descargamos el instalador de Dropbox de https://www.dropbox.com/install2.

En mi caso para el «servidor Dropbox» virtualicé una máquina de 32 bit, por lo tanto descargue

$cd ~ && wget -O – «https://www.dropbox.com/download?plat=lnx.x86» > dropbox.tar

Descomprimo el instalador:

$tar xf dropbox.tar

Eso es todo, al descomprimir crea una carpeta oculta llamada

~/.dropbox-dist/

En esta carpeta esta el ejecutable y archivos de configuración, no hay que compilar, en hora buena!

Ahora a configurar con su cuenta de Dropbox,. Para esto ejecuto el demonio Dropbox por primera vez manualmente, para que me cree el vínculo temporal de configuración y autorización del servdor.

$~/.dropbox-dist/dropboxd

El comando me informa:

Este cliente no está vinculado a una cuenta…
Visita https://www.dropbox.com/cli_link?host_id=xxxxxxxxxxxxxxxxxxxxxxxxxxe para vincular este equipo.

Tal cual como lo dice, copie y pegué el vínculo en un navegador, ingresé la contraseña de mi cuenta en Dropbox

Dropbox URL

De esta manera se autorizó la cuenta para el sevidor «El cliente se vinculó correctamente. Te damos la bienvenida, Jose Antonio.»

Confirmación autorización

Ahora descargo el script CLI oficial de Dropbox, una herramienta muy útil para administrar Dropbox desde el shell.

$wget https://www.dropbox.com/download?dl=packages/dropbox.py

Le asigno permisos de ejecución:

$chmod +x dropbox.py

Lo ejecuto para confirmar que funciona correctamente:

$./dropbox.py
Dropbox command-line interface

commands:

Note: use dropbox help <command> to view usage for a specific command.

status get current status of the dropboxd
help provide help
puburl get public url of a file in your dropbox
stop stop dropboxd
running return whether dropbox is running
start start dropboxd
filestatus get current sync status of one or more files
ls list directory contents with current sync status
autostart automatically start dropbox at login
exclude ignores/excludes a directory from syncing
lansync enables or disables LAN sync
Por ejemplo para arrancarlo ejecuto:

$~/dropbox.py start
Starting Dropbox…Done!

Como ya esta autorizada la máquina y tenemos un útil scrip CLI, lo siguiente es configurar el «servidor» para que arranque siempre Dropbox como el usuario. (No olvidar ajustarlo a su usuario). De las cincuenta mil formas de hacerlo, lo agregaremos al arranque CRON:

$crontab -e -u josecely

Agregamos la linea

@reboot ~/dropbox.py start

Reiniciamos el servidor, y comprobamos que arrancó el demonio Dropbox bajo el respectivo usuario, esto lo podemos comprobar con:

$ps aux | grep dropbox
josecely 2900 37.0 15.4 267652 56948 ? Ssl 01:27 1:18 /home/josecely/.dropbox-dist/dropbox

Montando la carpeta remota Dropbox en FreeBSD

Secure SHell FileSystem (SSHFS) es un sistema de archivos para FreeBSD, Linux y otros. Permite montar de modo seguro (sobre ssh) un directorio remoto, como si fuera local, además del lado del servidor, no necesita instalar ni configurar nada especial, el módulo FUSE solo se necesita en el cliente que va a montar el directorio remoto. El servidor remoto solo necesita tener el servicio sshd corriendo.
Los siguientes comandos y configuraciones se probaron en FreeBSD 9.1.

Como usuario root, en la máquina FreeBSD agregamos el package sshfs:

#pkg_add -r fusefs-sshfs

Editamos el archivo /etc/sysctl.conf, agredando la línea:

vfs.usermount=1

Editamos el archivo /etc/rc.conf, agredando la línea:

fusefs_enable=»YES»

Ahora agregamos el usuario que montará la partición al grupo operator, para que quede habilitado para montar y desmontar (No olvidar ajustarlo a su usuario):

#pw usermod josecely -G operator,wheel

Sería prudente, un reinicio:
# reboot

Una vez reiniciado, como usuario en la máquina FreeBSD, creamos el directorio para montar la carpeta Dropbox:

$ cd ~
$mkdir Dropbox

Y viene la magia!, montamos la carpeta remota del «servidor» Dropbox.

$ sshfs -o idmap=user josecely@10.0.0.4:/home/josecely/Dropbox Dropbox

Nótese el «-o idmap=user», es necesario para evitar errores del tipo «Bad file descriptor».

Ingresamos la contraseña del usuario remoto, y listo, la carpeta remota se ve como local, y es transparente para nuestro sistema operativo!

Gnome en freebsd con Dropbox
Podemos automatizar aun más, por ejemplo creando un par de llaves para que no pida contraseña, y pegando el comando de montaje al arranque de Gnome.

Dudas, comentarios, sugerencias?

Sigueme en twitter @josecely

——

Links

http://www.freebsd.org/
http://forums.freebsd.org/showthread.php?t=36449

Abr

19

Servidor web verdaderamente seguro: OpenBSD 5.2, Apache, Php 5.3, MySQL 5.1.6

By Jose Antonio Cely Saidiza

 

< offtopic> Retomando este abandonado Weblog, regreso con un artículo de algo poco documentado, para la élite :D, espero no haber perdido el tono a veces ácido y sarcástico de antiguos tutoriales, claro que es con el fin que no sean aburridos ñ_ñ
Tal vez deje de documentar Linux, pues ya es muy usado en la industria, y Ubuntu facilitó las cosas para el escritorio (cosas que me hacen sentir muy bien), pero… quiero ser siempre el chico raro, el de la minoría ;), y linux ya no lo es!. No solo eso, algunos clientes nos piden soluciones sobre este sistema (OpenBSD), dada su seguridad de facto cuando se maneja información sensible (Ej. grandes ISP, la industria del petróleo, etc.).</offtopic>

OpenBSD

OpenBSD es una leyenda en cuanto a seguridad informática nativa en el sistema operativo, y que mejor descripción como lo dice el primer parrafo en su página (http://www.openbsd.org/):

Pufffy, la mascota de OpenBSD

Pufffy, la mascota de OpenBSD

«El proyecto OpenBSD produce un sistema operativo LIBRE de tipo Unix, multiplataforma y basado en 4.4BSD. Nuestros esfuerzos se concentran en la portabilidad, estandarización, corrección, seguridad proactiva y criptografía integrada«.

Estas dos últimas palabras «criptografía integrada«, no consiste solo en encriptar fuertemente contraseñas y otras yerbas!… consiste en toda una serie de sistemas y subsistemas  (OpenSSH, PRNG, hash functions, Componentes criptográficos por hardware, etc) que funcionan orquestadamente.
En la documentación aparece la pregunta, ¿Por qué incluimos criptografía?, con su merecida y modesta respuesta «because we can.».

Estados Unidos y otros paises (China, Rusia, Irán, Irak, Myanmar, etc.) tienen políticas «raras» en cuanto a la exportación/importación de software que maneje algún tipo de criptografía, Incluso en Estados Unidos se específica un límite en la cantidad de bits para RSA!, pero mejor este tema interesante y político podría ser asunto de otro artículo.

Afortudamente el proyecto Open BSD es Canadiense, y esas políticas raras no aplican.
http://www.efc.ca/pages/doc/crypto-export.html

Para finalizar la introducción no sobra decir que el equipo de OpenBSD, también es el autor de SSH, con su legendario proyecto OpenSSH, que esta en todas la versiones de Linux, *nix.
http://www.openssh.com/
Gracias señores, SSH es mi pan de cada día, no concibo el trabajo sin él.

¿ Por que servidor web verdaderamente seguro ?

Así como en la industria al combo Linux, Apache, MySQL y PHP se le conoce como LAMP, podemos llamar a este combo OAMP.

  • OpenBSD: Sistema operativo descrito anteriormente como seguro. Configuraciones por defecto seguras (Ej. ssh no permte root remoto). entre otros.
  • Apache: Instalado en modo chroot jail (más detalles abajo), entre otros.
  • MySQL: Configurado en modo secure
  • PHP: El mismo de siempre ¬¬

Así pues tenemos un gran márgen de seguridad al inicio. Sin embargo a veces no es suficiente, todo depende de una buena admnistración.

Instalando OpenBSD

Esto es de las cosas que me gustan de OpenBSD y FreeBSD, es la documentación de calidad y que esta unificada en el sitio oficial. Nada de rebotar en miles de páginas como pasa en Linux, algunas veces contradiciendose entre ellas por apoyar su distro de turno O.o!

La documentación sobre instalación esta en (No profundizaré mucho en el tema de instalación):
http://www.openbsd.org/faq/faq4.html.

Para este tutorial usé la imágen de CDROM de :
http://mirror.esc7.net/pub/OpenBSD/5.2/i386/install52.iso

Pueden descargarla y quemarla en un CDROM como acostumbren hacerlo para estos menesteres ;).

Una vez con el CDROM en el servidor a instalar, solo es arrancar la máquina y tenemos un bonito y espartano arranque Unix!

Inicio instalador

Inicio instalador

Si señores, solo hay que leer y seguir los pasos, en mi caso, detectó todo como debía ser, tarjeta de red, dhcp, disco duro, etc. casi que el 95% de las opciones por default funcionaron!

OpenBSD instalando paquetes

OpenBSD instalando paquetes

Una vez instalado, hay que reiniciar el sistema con el clásico comando:

# reboot

Reboot final en la instlación de OpenBSD

Reboot final en la instlación de OpenBSD

Y listo, una vez reiniciado tenemos un bonito BSD, con el clásico XDM… a que mola!

XDM en OpenBSD

XDM en OpenBSD

En realidad no necesitamos el entorno gráfico para el servidor web verdaderamente seguro, solo lo instalé por impresionar a las chicas.

Paquetes

Los paquetes son los binarios pre-compilados por terceros de algunos de los programas más utilizados (http://www.openbsd.org/faq/faq15.html).

Cada paquete es un archivo con extensión .tgz que incluye información de dependencias y scripts para instalar y desinstalar, para manejarlos se emplean los programas pkg_add, pkg_delete, pkg_info y pkg_create.
El programa pkg_add instala un paquete y todos los que este requiera. Los descargarga de lo(s) repositorio(s) especificada(s) en la variable de entorno PKG_PATH, y en las rutas especificadas en el archivo /etc/pkg.conf

Instalando los paquetes para el servidor Web

En este caso usarmos los repositorios oficiales de BSD.

Para esto ejecutamos como root en el servidor:

# echo installpath=ftp://ftp5.usa.openbsd.org/pub/OpenBSD/$(uname -r)/packages/$(uname -m) | sudo tee /etc/pkg.conf

Una vez agregdo el repositorio, ya podemos empezar a instalar paquetes

1. Apache

Ejecutamos:

# pkg_add apache-httpd

2. PHP-MySql

Ejecutamos:

# pkg_add php-mysql

El cual nos pregunta:

# pkg_add php-mysql
Ambiguous: choose package for php-mysql
a 0:
1: php-mysql-5.2.17p6
2: php-mysql-5.3.14p0
Your choice: 2

Seleccionamos la opción 2.

Cuando termine de descargar e instalar, ejecutamos los siguientes comandos

# cp /var/www/conf/modules.sample/php-5.3.conf /var/www/conf/modules/php.conf
# cp /etc/php-5.3.sample/mysql.ini /etc/php-5.3/mysql.ini

3. MySql Server

Ejecutamos:
# pkg_add mysql-server

Cuando termine de descargar e instalar, ejecutamos los siguientes comandos

# /usr/local/bin/mysql_install_db
# /usr/local/share/mysql/mysql.server start
# /usr/local/bin/mysqladmin -u root password ‘your-password’

Obviamente se debe cambiar your-password por algo más seguro!

4. Aseguramos MySql

Ejecutamos:
# /usr/local/bin/mysql_secure_installation

El anterior script, hace los cambios pertinentes que todo servidor de producción debe tener respondiendo a las siguientes preguntas:
Remove anonymous users? [Y/n]
Disallow root login remotely? [Y/n]
Remove test database and access to it? [Y/n]
Reload privilege tables now? [Y/n]
Recomendaría SI (Y) a todo.

5. PhpMyAdmin

Ejecutamos:
#pkg_add phpMyAdmin

Cuando termine de descargar e instalar, ejecutamos los siguientes comandos

# cp /etc/php-5.3.sample/gd.ini /etc/php-5.3/gd.ini
# cp /etc/php-5.3.sample/mcrypt.ini /etc/php-5.3/mcrypt.ini
# cd /var/www/htdocs
# ln -s ../phpMyAdmin /var/www/htdocs/phpMyAdmin

Comunicando Apache con MySQL

Apache esta enjaulado por defecto (chroot jail), que bonito!, otra muestra más de la seguridad, esto quiere decir que Apache NO puede ver directorios fuera de su entorno de usuario, y mucho menos comunicarse con MySQL (Que obviamente también esta enjaulada), es imposible que los dos se comuniquen.
Entonces es necesario mover el archivo de la comunicación de MySQL /var/run/mysql/mysql.sock :

Para esto, creamos los directorios:

# mkdir /var/www/var/
# mkdir /var/www/var/run/
# mkdir /var/www/var/run/mysql/

Y editamos el archivo /etc/rc.local

# vi /etc/rc.local

Agregando las siguientes líneas

if [ -x /usr/local/bin/mysqld_safe ]; then
echo -n » mysqld»
/usr/local/bin/mysqld_safe –user=_mysql –log=/var/log/mysqld
sleep 4
rm -f /var/www/var/run/mysql/mysql.sock
ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock
fi

Iniciando el servidor OAMP automáticamente

Editamos el archivo /etc/rc.conf.local:

# vi /etc/rc.conf.local

Agregando las siguientes líneas

mysqld_flags=»»
httpd_flags=»»
pkg_scripts=»mysqld»

Sería prudente, un reinicio:
# reboot

Probando el servidor

La ruta por defecto para el contenido del servidor web es /var/www/htdocs/

Podemos crear un script de prueba, con el comando.

# echo «< ?php phpinfo(); ?>» | sudo tee /var/www/htdocs/phpinfo.php

El cual debe responder desde un navegdor a la dirección http://sudirecionip/phpinfo.php

En mi caso la dirección de mi intranet http://10.0.0.228/

Phpinfo en OpenBSD

Phpinfo en OpenBSD

Lo mismo para PhpMyAdmin, a la dirección http://sudirecionip/phpMyAdmin/index.php

En mi caso http://10.0.0.228/phpMyAdmin/index.php

PhpMyAdmin en OpenBSD

PhpMyAdmin en OpenBSD

——

Dudas, comentarios, sugerencias?

PD.
El servidor web verdaderamente seguro, es para cosas verdaderamente serias. Ej. no pretendas instalar Joomla y catapum! Joomla se volvio seguro XD! Una cosa es la seguridad del servidor, otra cosa una aplicación web vulnerable, y que mejor ejemplo que Joomla para aplicación web vulnerable!. Lo mismo sucede con las contraseñas, puedes tener el mejor BSD, con los últimos guariches, pero si tu contraseña es 123456… mejor ni hablemos….

Sigueme en twitter @josecely

——

Links

http://www.openbsd.org/
http://www.asep.us/2013/01/27/openbsd-5-2-web-server-apache-mysql-php/
http://www.serverschool.com/dedicated-servers/what-is-a-chroot-jail/

Sep

17

Utilizando Exim4 en Debian para enviar mensajes a través de Gmail

By Jose Antonio Cely Saidiza

El presente tutorial explica como configurar en servidor de correo por default en Debian (exim), par a que envíe correos a través de una cuenta de gmail. (smarthost on email Google servers).
No es necesario tener IP publica, solo tu cuenta de Gmail!, y un sistema operativo decente (Debian Lenny).
Entre las utilidades, podemos citar la creación de scripts que nos envien información del estado de la máquina. También se podría aprovechar para que nuestros scripts en php envíen email, o aplicaciones que hacen uso intensivo de correo (Ej. Nagios, Asterisk, Gforge, etc).
Además, tienes el registro de email enviados, bien sea con los logs, o en los correos enviados de tu cuenta de Gmail ;) .

INSTALACION Y CONFIGURACION

Ejecutamos:

dpkg-reconfigure exim4-config
(Si no esta instalado, lo sintalamos con apt-get install exim4)

En la reconfiguración/instalación seleccionamos:

* El correo se envía mediante un «smarthost»; se recibe a través de SMTP
* Nombre del sistema de correo: tudominio.xxx
* Direcciones IP en las que recibir conexiones SMTP entrantes: 127.0.0.1
* Otros dominios para los que se acepta el correo: en blanco
* Máquinas para las cuales reenviar correo: en blanco
* Direccion IP o nombre del equipo (smarthost) saliente: smtp.gmail.com::587
* Desea ocultar el nombre de correo local en los mensajes salientes? NO
* Limitar el numero de consultas DNS (Marcación bajo demanda)? NO
* Dividir la configuración en pequeños ficheros?

Ahora editamos el archivo /etc/exim4/passwd.client

vi /etc/exim4/passwd.client

# password file used when the local exim is authenticating to a remote
# host as a client.
#
# see exim4_passwd_client(5) for more documentation
#
# Example:
### target.mail.server.example:login:password
gmail-smtp.l.google.com:yourAccountName@gmail.com:y0uRpaSsw0RD
*.google.com:yourAccountName@gmail.com:y0uRpaSsw0RD
smtp.gmail.com:yourAccountName@gmail.com:y0uRpaSsw0RD

Cambiamos permisos del archivo

chown root:Debian-exim /etc/exim4/passwd.client

Reiniciamos el servidor de correo

/etc/init.d/exim4 restart

Con esto hemos finalizado la configuración, ahora nuestro sistema tendrá la capacidad de enviar email!

EJEMPLO DE USO

* No hay nada mas elegante que enviar un email a traves del shell XD, con el comando mail:

mail jose.cely@xxxx.xxx
Subject: Hola, email enviado desde el Shell
Esto es el cuerpo del mensaje. Es una prueba de mailx.
Un mensaje se acaba con un punto (.) al principio de línea.
.
Cc:

Se podrían hacer scripts para que nos envíen información automática y periódica del estado del estado de la máquina donde corre el servidor!

Para depurar errores en configuraciones, o ver en más detalle que esta pasando, no existe mejor alternativa que ver los logs!
tail /var/log/exim4/mainlog

Dudas, comentarios, sugerencias?

May

31

Virtualización de Servidores con KVM en Debian Lenny

By Jose Antonio Cely Saidiza

 

La gran mayoría de servidores actuales, posee la potencia suficiente y cantidad de memoria, para poder virtualizar máquinas y en estas correr instancias de sistemas operativos. De esta manera podremos sacarle más provecho a nuestro hardware, y posiblemente reducir costos.

En mi caso de ejemplo, antes usaba 3 máquinas para mi trabajo de desarrollo de software, (1) Mi portátil, en el cual tengo todo lo de producción, el código final, las release oficiales. (2) El servidor de pruebas, (3) El servidor de integración. Pero eso, es historia pasada XD, ahora las dos últimas corren virtualizadas en el portátil (DELL inspiron, 2Gb RAM, Athlon 64 X2).

El siguiente articulo explicará como instalar, crear y configurar maquinas virtuales en un servidor Debian GNU/Linux, utilizando KVM. Estas maquinas virtuales se podrán usar y serán visibles como cualquier otro host de la red.
Para este tutorial necesitamos
1 – Servidor con el sistema Debian (Lenny) base instalado, no es necesario entorno gráfico
2 – Computador con cliente VNC (vncviewer, xtightvncviewer, etc), y cliente ssh.

POR QUE KVM

Las alternativas libres de alto rendimiento que tenemos son 3 (En mi opinión las más importantes):
1 – Virtual Box: Desarrollado por la empresa innotek GmbH, pero SUN Microsystems lo compro, y ahora Oracle compro a SUN… mmmm.. muchos intereses de por medio, no quiero correr riesgos, descarte su uso sin probarlo :D.

2 – XEN: Desarrollado por la Universidad de Cambridge. En este caso Citrix lo compro en el 2007. Citrix cerro el proyecto, tiene un producto gratuito, el XenServer Express Edition, aunque solo puede soportar cuatro máquinas virtuales.
Las versiones actuales se basan en el código ante de su cierre. XEN es el de más alto rendimiento (sin embargo KVM lo supera en varios aspectos).
En el caso de Debian requiere unas versiones empaquetadas especiales del Kernel:
Etch: xen-linux-system-2.6.18-6-xen-686 and xen-linux-system-2.6.18-6-xen-amd64.
Lenny: xen-linux-system-2.6.26-2-xen-686 and xen-linux-system-2.6.26-2-xen-amd64
Y esto fue lo que no me convenció, tener que usar un kernel especifico, en algunas pruebas, después de instalar el kernel el sistema no arranco! Se imaginan si hubiese sido en un servidor remoto!!!. Obviamente buscando en Internet encontré bastante documentación a los problemas que se me presentaban (que fueron bastantes), entonces eran muchos riesgos para una instalación remota, descarte su uso.

3 – KVM (Kernel virtual Machine): Desarrollado por la empresa Qumranet. KVM, como su nombre lo indica, hace parte del núcleo (desde la versión 2.6.20) y herramientas en el espacio de usuario. Por lo tanto no tengo que cambiar el Kernel en ejecución!. La única pega es que requiere un procesador x86 con soporte Virtualization Technology. Sin embargo la mayoría de los procesadores actuales lo soportan, sin embargo si tu procesador es anterior al 2008, lo más probables es que no funcione.
Se está trabajando para utilizar más características de la Virtualization Technology, por lo tanto el tema de rendimiento (que en mis pruebas es más que satisfactorio para usar en producción) mejorara constantemente.

INSTALACIÓN DE KVM Y CONFIGURACIÓN DE RED EN EL SERVIDOR

Asumimos que el servidor tiene el servicio ssh, y podemos acceder a él.
Desde el computador cliente accederemos al servidor para configurar todo lo que necesitamos, aunque esto se puede hacer desde el propio servidor, incluso con herramientas gráficas. Este tutorial esta previsto para el caso que solo tengamos acceso ssh al servidor, es un servidor decente, por ende, no tiene entorno gráfico XD.

Una vez el en servidor;
Detectamos si nuestro procesador soporta virtualización de Hardware

egrep '(vmx|svm)' --color=always /proc/cpuinfo

En mi caso, tengo un procesador AMD Athlon(tm) 64 X2 Dual-Core (se puede ver con cat /proc/cpuinfo), y la salida es la siguiente:

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch

Lo cual significa que si soporta virtualización. Si al ejecutar el comando no produce ninguna salida, puede llorar, su hardware no soporta virtualización y NO HAY NADA QUE HACER!
, lo más probable es que estés trabajan en un procesador un poco viejo, por ejemplo el procesador de mi Desktop ( AMD Sempron) no lo soporta :'( …

Si tenemos suerte, continuamos
// Como buenos Debianitas, primero actualizamos lista de paquetes
apt-get update

// luego instalamos el módulo y utilidades de red
apt-get install kvm bridge-utils

Ahora tenemos que establecer un puente (bridgue) de red en nuestro servidor, para que nuestras máquinas virtuales se puede acceder desde otros hosts como si se trataran de sistemas físicos de red.
Para eso editamos el clásico archivo /etc/network/interfaces:
Por ejemplo, en mi caso esta asi
cat /etc/network/interfaces


# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1

Lo editamos ( vi /etc/network/interfaces), modificando algunas lineas para que quede así:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface

auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off

Obviamente, se debe acondicionar los archivos a su direccionamiento IP.
Después de editado, reiniciamos la red

/etc/init.d/networking restart

Y listo, si ejecutáramos el comando ifconfig, veríamos algo como esto (atención a la interfaz br0):

br0 Link encap:Ethernet HWaddr 00:1c:23:92:4e:d8
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::21c:23ff:fe92:4ed8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18143 errors:0 dropped:0 overruns:0 frame:0
TX packets:27478 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1084126 (1.0 MiB) TX bytes:16915847 (16.1 MiB)

eth0 Link encap:Ethernet HWaddr 00:1c:23:92:4e:d8
inet6 addr: fe80::21c:23ff:fe92:4ed8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:112400 errors:0 dropped:0 overruns:0 frame:0
TX packets:92086 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:144800236 (138.0 MiB) TX bytes:22306616 (21.2 MiB)
Interrupt:21

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:42 errors:0 dropped:0 overruns:0 frame:0
TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2908 (2.8 KiB) TX bytes:2908 (2.8 KiB)

TRABAJANDO CON MAQUINAS VIRTUALES

Antes que nada necesitamos una partición, o un archivo para que sea usado por la máquina virtual como disco duro, en el caso de usar un archivo, ejecutamos:

qemu-img create disk.deb 4G

El anterior comando crea un archivo, que la maquina virtual interpretara como un disco de 4Gb. Por cada máquina que virtualicemos, obiamente debemos crear su archivo
En nuestro ejemplo, instalaremos un sistema Debian en nuestra maquina virtual (Debian virtualizando Debian, que bonito :P ). Para eso necesitamos descargar una imagen ISO del instalador, en mi caso descargue la ISO del netinstall en la carpeta /home
El comando kvm, trae infinidad de opciones interesantes ( man kvm-qemu ).

Para virtualizar una máquina con 256Mb de Ram, con un adaptador de red Realtek compatible, que arranque desde CDROM, y que el CDROM sea nuestra imagen ISO, ejecutamos:

kvm -hda disk.deb -cdrom /home/debian-501-i386-netinst.iso -boot d -m 256 -net nic,vlan=0,model=rtl8139 -net tap,vlan=0 -vnc :0

Como podemos ver, el final agregamos –vnc :0, lo cual significa que podremos desde ya conectarnos vía VNC al servidor como nuestro cliente de preferencia, desde aca podremos seguir la instalación de Debian sin ninguna novedad! En hora buena.

Instalando Debian por VNC

Después de haber instalado el sistema base, ya no es necesario arrancar desde el CDROM, por lo tanto, siempre que se quiera arrancar esta máquina y acceder desde VNC, ejecutamos:

kvm -hda disk.deb -boot c -m 256 -net nic,vlan=0,model=rtl8139 -net tap,vlan=0 -vnc :0

Nótese que al parametro -boot, se cambio por “c “,. Boot permite los siguiente parametros:
Boot on floppy (a), hard disk (c), CD-ROM (d), or Etherboot (n).

Muy seguramente después de configurada nuestra máquina, algunas veces necesitamos iniciarla sin sesión VNC, o por cuestiones de seguridad. Además también podremos necesitar que corra en modo daemon, entonces ejecutamos:

kvm -hda disk.deb -boot c -m 256 -net nic,vlan=0,model=rtl8139 -net tap,vlan=0 -vnc none -daemonize

Este comando lo podríamos poner (tantas veces como sea necesario por cada maquina) en los scripts de arranque del sistema para que inicien siempre junto con el servidor.

NOTA FINAL

Vimos el funcionamiento básico de virtualización con KVM, para casos de manejar muchas maquinas virtuales, existen front-ends que facilitan mucho el trabajo (virt-install, virt-manager, etc). Tambien se pueden setear inumerables parametros en las maquinas a virtualizar, como en numero de cores del procesador, parametros avanzados de red, más seguridad a VNC, etc.

Dudas, comentarios, sugerencias?

http://www.linux-kvm.org
http://blog.bodhizazen.net/linux/how-to-run-kvm-without-x/
http://www.phoronix.com/scan.php?page=article&item=623&num=4