lunes, 5 de noviembre de 2018

Montar servidor de Nextcloud (nube privada estilo Dropbox) con Docker

Hoy vamos a aprender a montar nuestra propia nube privada de almacenamiento usando contenedores de Docker en nuestro servidor.
Si ya sabes de qué va todo esto de nube privada, Docker, Nextcloud, etc. y lo que quieres es ir al grano puedes hacer click aquí.

Empezaremos por responder a algunas preguntas que pueden surgir al leer el objetivo de este tutorial, vamos allá:

¿Qué es una "nube de almacenamiento"? 

Cuando hablamos de "nube" en un contexto informático nos referimos a los servicios que se ofrecen desde Internet. Es decir, cualquier servicio que se ofrezca a través de Internet como pueden ser el buscador de Google, Netflix, GMail, Dropbox, Facebook, etc.

Sabiendo esto, si hablamos de "almacenamiento en la nube" nos referimos a un servicio a través de Internet para guardar nuestros datos, una especie de disco duro virtual donde guardar nuestros archivos. Servicios como Dropbox, Mega, Box, Google Drive, Google Photos (sólo para fotos), etc. son algunos de ellos, donde se nos ofrece un almacenamiento en sus servidores para guardar nuestra información. Por regla general nos dan un almacenamiento limitado (1 GB, 15 GB, etc) y si queremos ampliarlo tenemos que pasar por caja, es decir, tenemos que pagarlo.

¿Para qué iba a necesitar yo una nube de almacenamiento?

Los usos que se le puede dar a este tipo de servicios son enormes: tener todos tus archivos disponibles en cualquier momento es una ventaja muy importante. Por ejemplo, estoy en casa trabajando con un documento, pero tengo que salir, mientras voy en el metro puedo seguir trabajando con el mismo documento desde el móvil. Tener siempre tu información disponible es muy importante, necesitas cualquier dato y lo puedes buscar al instante entre tus archivos desde cualquier parte del mundo mientras tengas acceso a una conexión a Internet. Una foto, un vídeo, un documento, cualquier cosa que puedas imaginarte la tendrás disponible a un par de clicks desde cualquier dispositivo mientras tengas acceso a Internet.

¿Y qué significa "privada"?

Cuando pones tus archivos en un servicio de los arriba mencionados, estás poniendo en los servidores de una empresa externa tus archivos. Es decir, tus fotos, vídeos, documentos... todos tus datos personales están en servidores que escapan a tu control gestionados por una empresa cuyo principal y único objetivo es ganar dinero. ¿Es esto malo? Para nada, es legítimo, y si no te importa que tus datos estén a merced de un tercero y no te importa pagar por ello no hará falta que sigas leyendo. Pero si para ti es importante tu privacidad, si piensas que tus datos son tuyos y de nadie más, si no quieres que cada GB que necesitas te salga por un ojo de la cara... este es tu tutorial ;-)

Sí, efectivamente cuando decimos "privada" nos referimos a que ese servicio lo gestiones tú mismo desde un ordenador que tengas en casa siempre encendido o incluso en un servidor dedicado o VPS siempre que cifres la información del disco (si queréis saber cómo se hace esto dejadlo en los comentarios).

¿Qué es Nextcloud?

Nextcloud es un desarrollo de código abierto para montar nuestra propia nube privada de almacenamiento. Es decir, podemos instalarlo en un ordenador que tengamos en casa y tener nuestro propio servicio de almacenamiento en la nube. Si queremos más espacio compraremos un disco duro más grande y no nos saldrá por un ojo de la cara comparado con lo que nos cobraría cualquiera de los servicios vistos anteriormente. Por ejemplo, con Dropbox tener 1 TB sale por 10 EUR/mes o 100 EUR/año, mientras que un disco duro de 1 TB nos costaría unos 40 EUR. Pero ya no es sólo la parte económica, es que nuestros datos estarán en nuestro servidor, nadie tendrá acceso a ellos.

¿Por qué pongo en negrita "código abierto"? Porque es muy importante en este tipo de servicios que juegan con nuestros datos más sensibles tener claro qué se hace con dichos datos. El hecho de que sea de código abierto te da la tranquilidad de que el programa hace lo que se supone que tiene que hacer, nada más. Si tienes los conocimientos necesarios podrías comprobar leyendo el código fuente que efectivamente es así, pero si no los tienes, otros los tendrán y lo harán, por eso los programas de código abierto son tan seguros, porque su seguridad no se basa en ocultar lo que hacen, sino en demostrar que lo que hacen está bien hecho.

¿Por qué usar Docker para esto?

Como hemos dicho, la idea es tener nuestro propio servidor con Nextcloud instalado.
Como vimos en la entrada sobre montar una VPN con Docker lo que nos permite hacer Docker es encapsular todo un servicio de nube privada en varios contenedores. Básicamente es como si virtualizáramos un servidor dentro de nuestro servidor. Los que conozcan la virtualización sabrán de sus ventajas, pero en este caso la ventaja es que no tenemos que tocar la configuración de nuestro servidor físico, ni modificar la configuración de la red, ni pelearnos con librerías, etc. Si actualizamos, cambiamos a otro sabor de Linux, cambiamos de servidor, etc. nuestros contenedores Docker funcionarán igual en otro servidor.

Preliminares

En mi caso la instalación la voy a hacer sobre un servidor con una CPU Intel Celeron
N3160 a 2.24 GHZ con 4GB de RAM y sistema operativo Ubuntu Server 18.04.1 LTS. Está fuera del alcance de este tutorial la instalación del sistema operativo, por lo que partiremos con el sistema operativo instalado (por supuesto no es necesario entorno gráfico) y acceso al terminal ya sea directamente o mediante SSH.

Lo primero que tendremos que hacer es instalar Docker en nuestro servidor. Para ello ejecutamos lo siguiente en un shell con permisos de root (o usando "sudo"):


1
2
3
4
5
# apt update
# apt dist-upgrade
# apt autoremove
# apt install docker.io
# apt install docker-compose

Es importante, por seguridad, que usemos Docker desde un usuario que no sea root, por tanto, a dicho usuario habrá que darle permisos para usar Docker. Esto lo hacemos con el siguiente comando cambiando "usuario_no_root" por nuestro usuario sin permisos de root:


1
# usermod -a -G docker usuario_no_root

A partir de aquí ya no necesitaremos permisos de root ya que instalaremos nuestro servidor usando Docker. Si lo hiciéramos de forma tradicional tendríamos que usar root para instalar todo el software necesario, por lo que ya podemos empezar a vislumbrar las ventajas de usar Docker.

Ahora abriremos un nuevo terminal con el "usuario_no_root" y comprobaremos que somos capaces de usar Docker normalmente con el siguiente comando:


$ docker version
Client:
 Version: 17.12.1-ce
 API version: 1.35
 Go version: go1.10.1
 Git commit: 7390fc6
 Built: Wed Apr 18 01:23:11 2018
 OS/Arch: linux/amd64

Server:
 Engine:
  Version: 17.12.1-ce
  API version: 1.35 (minimum version 1.12)
  Go version: go1.10.1
  Git commit: 7390fc6
  Built: Wed Feb 28 17:46:05 2018
  OS/Arch: linux/amd64
  Experimental: false

Debido a que la instalación de Nextcloud requiere de varios servicios vamos a usar docker-compose para automatizar el proceso de creación de los contenedores creando un archivo de texto con todo lo necesario para realizar dicha tarea.

A modo de resumen vamos a necesitar: un contenedor (una especie de máquina virtual) para instalar el propio Nextcloud, otro contenedor para instalar MariaDB (como si fuera MySQL) para la base de datos, otro contenedor para generar los certificados HTTPS para usar conexión segura y un proxy inverso para manejar las conexiones entre los clientes desde Internet y el motor de Nextcloud. No te preocupes si no has entendido todo lo expuesto en este párrafo, lo veremos paso a paso más adelante.

Crear red virtual

Lo primero que vamos a hacer es crear una red virtual dentro de Docker para que nuestros contenedores puedan comunicarse entre ellos. Esto es muy importante y es otra de las ventajas claras de usar Docker, ya que impide que si tenemos un problema de seguridad puedan acceder a nuestra red interna. Para crear la red ejecutamos lo siguiente:


1
$ docker network create nextcloud_network

Definir servidor proxy inverso

Como hemos dicho anteriormente, necesitaremos cuatro contenedores y el primero de ellos será el proxy inverso que será el que reciba las peticiones de los clientes desde Internet y las redirija a nuestro contenedor de Nextcloud.
Para empezar nos creamos un directorio al que llamaremos "nextcloud" desde nuestro usuario sin permisos de root, por ejemplo en su directorio HOME. Además dentro de él crearemos un directorio "proxy":


1
$ mkdir -p ./nextcloud/proxy

Ahora entramos en el directorio que acabamos de crear (cd nextcloud) y empezaremos a crear el fichero "docker-compose.yml" con la definición del proxy inverso. Para ello podemos usar nuestro editor de texto favorito, ya sea "vi", "nano", etc:


1
$ vi docker-compose.yml

Y pegamos lo siguiente en el fichero:


 proxy:
    image: jwilder/nginx-proxy:alpine
    labels:
      - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"
    container_name: nextcloud-proxy
    networks:
      - nextcloud_network
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./proxy/conf.d:/etc/nginx/conf.d:rw
      - ./proxy/vhost.d:/etc/nginx/vhost.d:rw
      - ./proxy/html:/usr/share/nginx/html:rw
      - ./proxy/certs:/etc/nginx/certs:ro
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./proxy/uploadsize.conf:/etc/nginx/conf.d/uploadsize.conf:ro
    restart: unless-stopped

Aquí básicamente definimos el contenedor al que llamaremos "nextcloud-proxy", que tendrá abiertos los puertos 80 (HTTP) y 443 (HTTPS) y también le definimos una configuración especial para que el proxy la tenga en cuenta en el fichero "uploadsize.conf" que crearemos enseguida. Además el label "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true" es necesario para que luego el contenedor de LetsEncrypt sepa a qué proxy le tiene que crear los certificados SSL.
Ahora vamos a crear el fichero con la configuración especial editándolo con el siguiente comando desde dentro de nuestro directorio "nextcloud":


1
vi ./proxy/uploadsize.conf

Y pondremos dentro del fichero el siguiente contenido:


client_max_body_size 10G;

Con esto conseguimos que el servidor proxy nos deje subir ficheros de hasta 10 GiB, que a priori parece suficiente. Si no pusiéramos esto la configuración por defecto está limitada a 1 MiB, lo que haría inservible nuestro servidor de Nextcloud.

Definir LetsEncrypt

Ahora definiremos el container que nos ayudará a generar y mantener nuestros certificados SSL para que la conexión HTTPS que hagamos con el servidor sea segura. Para quien no lo sepa, LetsEncrypt en un servicio gratuito y seguro para obtener certificados SSL válidos para nuestros dominios.

Para ello añadimos a nuestro fichero docker-compose.yml el siguiente contenido:


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
 letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: nextcloud-letsencrypt
    depends_on:
      - proxy
    networks:
      - nextcloud_network
    volumes:
      - ./proxy/certs:/etc/nginx/certs:rw
      - ./proxy/vhost.d:/etc/nginx/vhost.d:rw
      - ./proxy/html:/usr/share/nginx/html:rw
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: unless-stopped

Como podemos observar, definimos un container con el nombre "nextcloud-letsencrypt" al que le decimos que depende de nuestro container proxy. Gracias al "label" que vimos en la definición del container proxy sabe a qué contenedor tiene que crearle los certificados SSL.

Definir la base de datos MariaDB


Ahora vamos a definir el container que hará la función de base de datos para nuestra instalación de Nextcloud. Para ello hemos elegido MariaDB (un clon de MySQL). Debemos añadir lo siguiente a nuestro fichero docker-compose.yml:


db:
    image: mariadb
    container_name: nextcloud-mariadb
    networks:
      - nextcloud_network
    volumes:
      - db:/var/lib/mysql
      - /etc/localtime:/etc/localtime:ro
    environment:
      - MYSQL_ROOT_PASSWORD=contraseña_root_bbdd
      - MYSQL_PASSWORD=contraseña_usuario_nextcloud
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
    restart: unless-stopped

Como podemos observar, vamos a crear un contenedor de nombre "nextcloud-mariadb" y debemos tener presente que tenemos que definir unas variables de entorno que contendrán dos contraseñas:
MYSQL_ROOT_PASSWORD: Es la contraseña que tendrá el usuario root de nuestro motor de base de datos, en realidad no la vamos a usar nunca ya que crearemos un usuario específico para la base de datos de Nextcloud, eso sí, conviene que sea una contraseña segura.
MYSQL_PASSWORD: Es la contraseña que tendrá nuestro usuario "nextcloud" que tendrá acceso de administrador a la base de datos "nextcloud" y es la contraseña que usaremos posteriormente para configurar nuestro servidor de Nextcloud. También es muy importante que sea una contraseña segura.

Algo importante con respecto a ambas contraseñas: ¡¡No pongáis caracteres extraños!! Es decir, usad sólo mayúsculas, minúsculas y letras, pero no símbolos porque por alguna razón a docker-compose no le sienta bien y te volverás loco intentando configurarlo como me pasó a mí.

Definir el servidor de Nextcloud

Ahora vamos a definir el contenedor que hará de servidor de aplicaciones para nuestro Nextcloud. Es decir, este será el contenedor que responderá a las peticiones de los clientes que vendrán directamente de nuestro contenedor proxy, por tanto, este servidor no tendrá acceso directo a Internet, sólo a través del proxy. Veamos qué tenemos que añadir a nuestro fichero docker-compose.yml:


 app:
    image: nextcloud:latest
    container_name: nextcloud-app
    networks:
      - nextcloud_network
    depends_on:
      - db
      - proxy
      - letsencrypt
    volumes:
      - nextcloud:/var/www/html
      - ./app/config:/var/www/html/config
      - ./app/custom_apps:/var/www/html/custom_apps
      - ./app/data:/var/www/html/data
      - ./app/themes:/var/www/html/themes
      - /etc/localtime:/etc/localtime:ro
    environment:
      - VIRTUAL_HOST=nuestro.dominio.com
      - LETSENCRYPT_HOST=nuestro.dominio.com
      - LETSENCRYPT_EMAIL=nuestroemail
    restart: unless-stopped

Según podemos ver arriba vamos a crear un container llamado "nextcloud-app" que depende de los otros tres que hemos definido (db, proxy y letsencrypt), y vamos a definir una serie de volúmenes y variables de entorno que merece la pena que nos detengamos a verlos poco a poco.
Comenzamos por la variables de entorno:
VIRTUAL_HOST: Aquí tendremos que decirle el dominio que está apuntando a la IP de nuestro servidor. Mediante esta variable nuestro servidor proxy sabe a qué contenedor redirigirle la petición. Si estamos montando esta infraestructura en nuestra casa, lo normal es que tengamos una IP dinámica, lo que no es impedimento para conseguir un dominio apuntando a nuestra IP. Si queréis saber cómo hacerlo dejadlo en los comentarios y lo explico.
LETSENCRYPT_HOST y LETSENCRYPT_EMAIL: Es otra vez nuestro dominio que apunta a la IP de nuestro servidor y nuestro email para que LetsEncrypt pueda certificar nuestro dominio.
De los volúmenes que tenemos que definir quiero pararme en este:


./app/data:/var/www/html/data

Ya que a la izquierda de los ":" estamos definiendo la ruta donde se albergarán los datos que subamos a Nextcloud. Es decir, esta ruta debe apuntar al disco donde queramos que estén nuestros datos. Si queremos mantener la ruta "app/data" para tenerlo todo junto, siempre podemos usar un "mount bind" para que esa ruta esté apuntando en realidad a otro disco, por ejemplo:


1
$ sudo mount --bind /mi/disco/duro/nextcloud/ /home/usuario_no_root/nextcloud/app/data/

Como vemos, estamos montando la ruta "/mi/disco/duro/nextcloud/" en la ruta "/home/usuario_no_root/nextcloud/app/data/" y así lo tendremos todo centralizado en el directorio nextcloud de nuestro HOME, aunque en realidad los datos estarán en el otro disco.
Como digo, también podemos poner este mismo directorio en el fichero docker-compose.yml:


- /mi/disco/duro/nextcloud:/var/www/html/data

Cualquiera de las dos opciones son válidas.

Y por último, debemos completar nuestro fichero docker-compose.yml con lo siguiente para especificar los volúmenes y la red que vamos a usar:


volumes:
  nextcloud:
  db:

networks:
  nextcloud_network:

Resumen

Con todo lo expuesto arriba, nuestro fichero docker-compose.yml quedaría así:


version: '3'

services:

 proxy:
    image: jwilder/nginx-proxy:alpine
    labels:
      - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"
    container_name: nextcloud-proxy
    networks:
      - nextcloud_network
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./proxy/conf.d:/etc/nginx/conf.d:rw
      - ./proxy/vhost.d:/etc/nginx/vhost.d:rw
      - ./proxy/html:/usr/share/nginx/html:rw
      - ./proxy/certs:/etc/nginx/certs:ro
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./proxy/uploadsize.conf:/etc/nginx/conf.d/uploadsize.conf:ro
    restart: unless-stopped

 letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: nextcloud-letsencrypt
    depends_on:
      - proxy
    networks:
      - nextcloud_network
    volumes:
      - ./proxy/certs:/etc/nginx/certs:rw
      - ./proxy/vhost.d:/etc/nginx/vhost.d:rw
      - ./proxy/html:/usr/share/nginx/html:rw
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: unless-stopped

 db:
    image: mariadb
    container_name: nextcloud-mariadb
    networks:
      - nextcloud_network
    volumes:
      - db:/var/lib/mysql
      - /etc/localtime:/etc/localtime:ro
    environment:
      - MYSQL_ROOT_PASSWORD=contraseña_root_bbdd
      - MYSQL_PASSWORD=contraseña_usuario_nextcloud
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
    restart: unless-stopped

 app:
    image: nextcloud:latest
    container_name: nextcloud-app
    networks:
      - nextcloud_network
    depends_on:
      - db
      - proxy
      - letsencrypt
    volumes:
      - nextcloud:/var/www/html
      - ./app/config:/var/www/html/config
      - ./app/custom_apps:/var/www/html/custom_apps
      - ./app/data:/var/www/html/data
      - ./app/themes:/var/www/html/themes
      - /etc/localtime:/etc/localtime:ro
    environment:
      - VIRTUAL_HOST=nuestro.dominio.com
      - LETSENCRYPT_HOST=nuestro.dominio.com
      - LETSENCRYPT_EMAIL=nuestroemail
    restart: unless-stopped

volumes:
  nextcloud:
  db:

networks:
  nextcloud_network:

Puesta en marcha


Bueno, ya lo tenemos todo preparado en los dos ficheros que hemos creado "docker-compose.yml" y "uploadsize.conf".
Antes de ponerlo en marcha, tenemos que asegurarnos de que los puertos 80 y 443 están redirigidos en nuestro router hasta la IP interna de nuestro servidor, algo que se conoce como NAT. Si no sabes cómo hacerlo tendrás que buscar en Google el nombre de tu router seguido de "port forwarding" o "NAT".

Y por fin, nos situamos en el directorio donde hemos puesto nuestro fichero docker-compose.yml y ejecutamos la siguiente orden:


$ docker-compose up -d

Tendremos que dejar al servidor unos minutos para que le dé tiempo a generar los certificados SSL. Pasados unos minutos, accedemos a nuestra URL: https://nuestro.dominio.com

Y veremos algo parecido a esto:


Tenemos que elegir un usuario administrador y una contraseña para él. ¡¡NO PONER "admin" COMO NOMBRE DE USUARIO!! El problema de poner "admin" es que si dejamos nuestro servidor abierto a Internet recibiremos ataques intentando conseguir nuestra contraseña de admin y el usuario que probarán será "admin", "administrator" e incluso "administrador", por tanto, elegid otro nombre distinto y una contraseña segura.

Luego tenemos que elegir la opción de "Storage & database" (puede que salga en Español) y nos saldrá la configuración de la siguiente ventana cuando le demos a la opción "MySQL/MariaDB":


En "Database user" (usuario de la base de datos) y "Database name" (nombre de la base de datos)  tenemos que poner "nextcloud".
En "Database password" (Contraseña de la base de datos) tenemos que poner la contraseña que hemos definido en nuestro fichero "docker-compose.yml" en la variable MYSQL_PASSWORD.
En donde pone "localhost" lo cambiamos por "db" que es el nombre que le hemos dado al servidor de la base de datos.

Por último le damos a "Finish setup" (Finalizar configuración) y ya tenemos nuestro servidor de Nextcloud funcionando.

Lo ideal ahora es logarnos con nuestro usuario administrador y en la parte superior derecha hacer click en el círculo con la primera letra del nombre de nuestro usuario "admin" para desplegar el menú y luego la opción de "Usuarios" para crear los usuarios que necesitemos, dejando al usuario administrador sólo para tareas administrativas.

Una vez tengamos nuestros usuarios creados ya podemos bajarnos cualquier cliente de Nextcloud para los dispositivos que tengamos desde https://nextcloud.com/install/ en el apartado donde pone "Sync your data" donde podemos elegir los clientes para los diferentes sistemas operativos (Windows, Linux, macOS, Android y iOS).

Y esto es todo, recordad que si necesitáis saber cómo redirigir un dominio a una IP dinámica (como la de vuestra casa) me lo digáis en los comentarios para hacer un tutorial sobre ello.

¡Hasta la próxima!


Documentación

https://docs.nextcloud.com/server/14/admin_manual/
https://blog.ssdnodes.com/blog/installing-dropbox-alternative-nextcloud-with-docker/
https://github.com/nextcloud/docker/issues/371
https://github.com/jwilder/nginx-proxy
https://letsencrypt.org/docs/faq/


martes, 16 de agosto de 2016

Montar una VPN en tu servidor usando un container de Docker

Hola de nuevo,

hoy vamos a aprender a montar una VPN en nuestro servidor para poder usarla desde nuestros móviles, nuestros portátiles, etc. Lo primero que tenemos que saber es qué es una VPN y para qué sirve, así que vamos a ello: VPN viene de las siglas en inglés de "Virtual private network", red privada virtual en español y básicamente es una red privada que se extiende a través de una red pública, como internet. Quizá con un ejemplo gráfico se entienda mejor:

By Ludovic.ferre (talk · contribs) - Own work, GFDL, https://commons.wikimedia.org/w/index.php?curid=10101288

Imaginemos que tengo un empresa con varias sedes físicas separadas. Hace muchos años para conectar dichas sedes en una única red se usaban líneas dedicadas punto-a-punto, se conectaban físicamente las sedes con "un cable" que las unía físicamente. Como os podéis imaginar esto es muy muy caro y sólo estaba al alcance de empresas muy fuertes, como por ejemplo los bancos.
Una VPN viene a solucionar mediante software este problema, creando un enlace entre las sedes que las une entre ellas a través de internet, y por tanto las sedes sólo necesitan una conexión a internet que es mucho más barata que la conexión punto-a-punto. Como nuestros datos privados viajarán por Internet que es una red insegura per se, lo que hacemos es encriptar los datos de tal manera que sólo nosotros podamos entenderlos. Cualquier nodo de internet que vea pasar nuestros datos VPN sólo verá una ristra de bits sin sentido. Con esto conseguimos que nuestras sedes estén todas en la misma red y puedan compartir recursos de una forma fiable y barata.

Y entonces te preguntarás... ¿para qué quiero yo una VPN? Pues puedes ser que tengas una empresa con varias sedes y ya has dado con la solución ;-) .... o puede ser que simplemente estés un día en un Mc Donald's, un Burguer King, un centro comercial, una cafetería, un hotel, etc y te quieras conectar con tu móvil, tu portátil, tu tablet o lo que sea a la conexión Wifi del lugar. Si haces esto y NO usas una VPN lo que puedes conseguir es que te roben tus datos personales que viajan por una red insegura como es una Wifi pública. Quizá pienses que tú no tienes nada en el ordenador o en el móvil que quieras proteger, bueno, yo creo que sí lo tienes. Te pueden robar contraseñas (o sesiones) de servicios como Google, Facebook, etc También te pueden robar datos sensibles bancarios si te conectas a tu banco a través de internet, te pueden robar fotos, vídeos, etc que tengas alojadas en la nube.Pueden saber las webs que visitas, los videos que ves, las imágenes que estás viendo ahora mismo por intenet. Pueden suplantar tu identidad para publicar cosas en tu nombre o hacerse pasar por ti. En fin, creo que está claro que es una muy mala idea usar una Wifi pública sin la protección adecuada.

Pues bien, para evitar todos estos inconvenientes podemos usar una VPN que te conecte virtualmente con otro lugar para que cuando navegues a través de la Wifi Pública tus datos viajen encriptados hasta ese otro lugar y nadie en dicha Wifi te pueda robar nada. Es que como si estuvieras usando internet desde ese otro lugar. Para hacer esto puedes usar un servidor que tengas contratado en internet, un ordenador que tengas en casa, etc.

Vista la justificación de usar una VPN para el común de los mortales, veamos lo que necesitamos para llevar a cabo esta tarea:

- Un servidor conectado a internet, en este tutorial usaré un servidor con Ubuntu 16.04 LTS alojado en OVH.
- Un dispositivo móvil que haga de cliente de la VPN como puede ser un móvil con Android, con iOS, etc.
- Tiempo y ganas.

Para este tutorial voy a montar la VPN mediante Docker, y vamos a ver por encima qué es Docker y porque lo podemos usar para esto. De la Wikipedia: "Docker es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de Virtualización a nivel de sistema operativo en Linux" ¡¡¡En cristiano Doc!!! Bien, Docker nos servirá en este proyecto para montar una VPN encapsulando todo un servidor VPN en un contenedor. Básicamente es como si virtualizáramos un servidor de VPN dentro de nuestro servidor. Los que conozcan la virtualización sabrán de sus ventajas, pero en este caso la ventaja es que no tenemos que tocar la configuración de nuestro servidor, ni modificar la configuración de la red, ni pelearnos con librerías, etc. Si actualizamos, cambiamos a otro sabor de Linux cambiamos de servidor, etc nuestro contenedor Docker funcionará igualmente en otro servidor.

Para instalar Docker en Ubuntu, lo mejor es que sigáis las instrucciones de la propia página de Docker, aunque aquí voy a resumir los pasos que yo seguí. Por supuesto, todo esto lo haremos desde una terminal de Linux con permisos de root.

Lo primero, actualizar nuestro sistema:

1
2
# apt-get update
# apt-get dist-upgrade

Lo siguiente es añadir la clave de firma del repositorio de Docker a nuestro sistema:


1
# apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D

Lo siguiente será añadir el repositorio de Docker. Para ello editamos el fichero con nuestro editor favorito, en mi caso con el vi:


1
# vi /etc/apt/sources.list.d/docker.list

Y añadimos el siguiente contenido al archivo ( en mi caso para Ubuntu 16.04 LTS):


deb https://apt.dockerproject.org/repo ubuntu-xenial main

Por último instalamos Docker desde los repositorios:


1
2
# apt-get update
# apt-get install docker-engine

Y por último arrancamos el servicio de Docker y ejecutamos el contenedor de ejemplo:


1
2
# service docker start
# docker run hello-world

Y si todo va bien nos debería aparecer algo así en la consola:


# docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 # docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker Hub account:
 https://hub.docker.com

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/

Desafortunadamente, en mi caso la cosa no fue bien, me daba un error:


docker: failed to register layer: devmapper

El problema en mi caso estaba en el kernel, ya que los servidores dedicados de OVH arrancan por defecto con un kernel desde la red, y claro, el kernel que te ponen los de OVH era un 3.15 que no viene con devicemapper (una funcionalidad que usa Docker) compilado, y por tanto docker no funciona bien.

La solución fue entrar en el panel de control de OVH, entrar en la configuración del servidor dedicado y poner que arranque desde la red pero con el kernel 4.4:


Después de esto, reinicias el servidor y entonces Docker ya funciona correctamente.
Ahora tenemos que preparar nuestro "container" con el servidor de VPN, para ello ejecutamos lo siguiente:


# OVPN_DATA="ovpn-data"
# docker volume create --name $OVPN_DATA
# docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_genconfig -u udp://vpn.ejemplo.com:1194


Lo que hacemos al principio es establecer una variable con el nombre que queremos que tenga nuestro container Docker, así es más fácil copiar y pegar los comandos desde aquí sin cambiar nada. En nuestro caso, le hemos puesto "ovpn_data" como nombre. Luego lo que hacemos es crear un volumen con ese nombre que contendrá nuestros datos. Por último ejecutamos, ahora sí, la imagen del servidor VPN(kylemanna/openvpn) que ya está preparada en los servidores de docker y en esa imagen ejecutamos el script "ovpn_genconfig" que básicamente genera la configuración básica de servidor y la crea en /etc/openvpn que es el volumen que hemos creado previamente. En esta última orden es importante apreciar que tenemos que sustituir el nombre de dominio "vpn.ejemplo.com" por el nuestro propio que apunte a nuestro servidor, o si no tenemos un nombre, pues la IP directamente (suponiendo que sea un IP estática).

Ahora lo que vamos a hacer es generar el PKI de la autoridad de certificación. Al ejecutar el último comando nos pedirá una clave, tenemos que poner una clave muy segura ya que de ella dependerá la seguridad de nuestra VPN:


# docker run -v $OVPN_DATA:/etc/openvpn --rm kylemanna/openvpn touch /etc/openvpn/vars
# docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm -it kylemanna/openvpn ovpn_initpki

Ya tenemos nuestro servidor de VPN preparado, ahora vamos a crear un servicio en systemd para que se ejecute automáticamente el servidor VPN de docker cuando arranquemos nuestro servidor. Para ello creamos un nuevo fichero con nuestro editor favorito:


# vi /lib/systemd/system/docker-openvpn.service

Y dentro del fichero copiamos el siguiente contenido:


[Unit]
Description=Docker container for OpenVPN server
Requires=docker.socket
After=network.target docker.socket

[Service]
Environment="IMG=kylemanna/openvpn:latest"
Environment="NAME=ovpn"
User=user
Group=group
RestartSec=10
Restart=always
# Clean-up bad state if still hanging around
ExecStartPre=-/usr/bin/docker rm -f ovpn

# Attempt to pull new image for security updates
ExecStartPre=-/usr/bin/docker pull $IMG
ExecStart=/usr/bin/docker run -v ovpn-data:/etc/openvpn --rm -p 1194:1194/udp --name $NAME --cap-add=NET_ADMIN kylemanna/openvpn
ExecStop=/usr/bin/docker stop -t 2 kylemanna/openvpn

[Install]
WantedBy=multi-user.target


Lo que hemos hecho es crear un servicio que ejecute nuestro servidor docker VPN. Tendremos que cambiar las variables User y Group por nuestro usuario y grupo que los podemos obtener ejecutando "whoami" y "id -gn" respectivamente.

Ahora nos queda registrar el servicio en el sistema haciendo que lo arranque cada vez que reiniciemos la máquina, esto lo hacemos con el siguiente comando:


# systemctl enable docker-openvpn.service

Como podemos ver, estamos ejecutando nuestro servidor VPN escuchando por el puerto 1194, por tanto, si tenemos un firewall en nuestro servidor físico, tendremos que abrir dicho puerto:

# iptables -A INPUT -p udp --dport 1194 -j ACCEPT

Ahora ejecutamos dicho servicio:

# systemctl start docker-openvpn.service

Y si todo ha ido bien al ejecutar este comando:

# docker ps

Veremos que nuestro container se está ejecutando correctamente:

# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                    NAMES
4a2e1ebe211d        kylemanna/openvpn   "ovpn_run"          2 days ago          Up 2 days           0.0.0.0:1194->1194/udp   ovpn

Ahora tenemos que generar los certificados y ficheros de configuración necesarios para cada cliente que queramos que se conecte a nuestra VPN. Para ello, tendremos que sustituir NOMBRECLIENTE por el nombre que nosotros queramos, como puede ser "movil" (sin acento), "portatilasus", etc.

Con este comando creamos el certificado del cliente. Nos pedirá la contraseña de nuestra CA, la que hemos puesto antes, la ponemos sin equivocarnos. Ahí va el comando (cambiar NOMBRECLIENTE por lo que queramos):

# docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm -it kylemanna/openvpn easyrsa build-client-full NOMBREDECLIENTE nopass

Y por último creamos el fichero .opvn con toda la configuración del cliente que luego importaremos en nuestro móvil, tablet, etc:

# docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_getclient NOMBREDECLIENTE > NOMBREDECLIENTE.ovpn

El fichero que nos cree aquí (por ejemplo movil.ovpn) tenemos que copiarlo de forma segura a nuestro dispositivo cliente, por ejemplo con scp. Yo lo que hice fue copiarlo al ordenador de casa con scp y luego al móvil con el cable USB. Si transfieres este fichero de forma insegura (email, dropbox, whatsapp, etc) corres el riesgo de comprometer la seguridad de tu VPN.

Ya con este fichero .ovpn lo que haces es abrir el cliente de OpenVPN, yo en mi caso, para Android uso este:

OpenVPN for Android
https://play.google.com/store/apps/details?id=de.blinkt.openvpn

En este cliente de VPN, nada más entrar, le das al botón (+), le dices IMPORTAR y eliges el fichero .ovpn que hemos creado, y con esto ya debería conectarse sin problemas a tu servidor VPN de docker. Si esto no te funciona, porque no te muestra el fichero, hazlo desde tu gestor de archivos e intentas abrir el fichero, cuando te pregunte con qué app quieres abrirlo le dices con "OpenVPN for Android" y ya está.

Espero que os haya gustado este tutorial y que lo uséis cada vez que os conectéis a una red insegura.
Hasta pronto!!!

Documentación:
https://en.wikipedia.org/wiki/Virtual_private_network

viernes, 29 de noviembre de 2013

Cómo arreglar el error com.android.phone en Android 4.3 con Pepephone y otras OMV's

Hola de nuevo,

hace un tiempo actualicé por OTA mi Nexus 4 a Android 4.3 (Jelly Bean).
Una vez aplicada la OTA, siempre es recomendable hacer un Factory Reset para borrar todos los datos y evitar conflictos con ficheros antiguos, así que hice el Factory Reset y al reiniciar empezó a salirme una ventana de error de "com.android.phone" que no te permitía hacer nada, ya que al darle al botón de aceptar volvía a salir una nueva ventana inmediatamente.

El problema viene porque la SIM de Pepephone (y otros OMV's) contiene por defecto un montón de APN's que hace que Android 4.3 falle (ojo, con 4.4 no pasa).
Y la solución es bien sencilla, hay que borrar todos los APN's y poner el de tu compañía a mano, pero claro, con la ventana de error saliendo continuamente se hace muy dificil llegar hasta los APN's y borrarlos.
Si pones el móvil en modo avión deja de salirte el error, pero tienes el problema de que estando en modo avión no te permite entrar en los ajustes para borrar los APN's.

Publiqué la solución en HTCMania hace un tiempo en el foro de Nexus 4, pero me consta que ahora ocurre en más teléfonos que se están actualizando a 4.3 y por eso lo publico aquí también.

Los pasos a seguir para arreglar en error sin necesidad de ser root son los siguientes:

1. Instalamos la OTA
2. Factory reset (y perdemos todos los datos, fotos, vídeos, etc)
3. Primer reinicio y no para de darnos el error
4. Salimos del asistente de inicio (ya crearemos la cuenta después)
5. Ponemos modo avión (dejando el botón de power pulsado/modo avión). A partir de aquí ya no nos sale el error.
6. Activamos el Wifi y nos conectamos a nuestra red.
7. Vamos a ajustes/seguridad/origenes desconocidos y lo marcamos.
8. Bajamos el siguiente apk: http://bit.ly/2nFdTJ7 (totalmente fiable, lo he hecho yo, no requiere ningún permiso)
9. Lo instalamos, le damos a ejecutar y nos saldrá la lista de APN's (tras 6 segundos mostrando la pantalla de bienvenida)
10. Borramos TODOS los APN's y creamos el de nuestra compañía
11. Quitamos el modo avión y a disfrutar de 4.3

Espero que os sirva.
Saludos.

Incrementar la seguridad de tu servidor (Tercera parte) (Fail2ban)

Hola de nuevo,

después de la primera parte y de la segunda parte, vamos a explicar cómo incrementar la seguridad de nuestro servidor evitando que nos hagan un ataque de fuerza bruta (o de diccionario) a servicios que requieran un usuario y una contraseña.


Cuando hablamos de un ataque de fuerza bruta nos estamos refiriendo a que alguien empiece a probar usuarios y contraseñas en algún servicio que tengamos en nuestro servidor. Por ejemplo, en el servicio SSH, que nos pide usuario y contraseña, alguien podría empezar a probar contraseñas para el usuario "root", empezaría por aaaaaaaa, aaaaaaab, aaaaaaac, etc. Evidentemente, esto se realiza de forma automática mediante un script que va probando distintas contraseñas hasta que da con la nuestra.

De forma análoga tenemos el ataque de diccionario, en el que se prueban contraseñas de un diccionario de contraseñas, el cual contiene las contraseñas más habituales, por ejemplo "12345678", "qwertyuio", "god","password", etc.

Servicios que sean vulnerables a este tipo de ataques son SSH, apache, ftp, wordpress, etc. En general, cualquier servicio que nos pida un usuario y una contraseña.

Fail2ban es una herramienta que nos protege de este tipo de ataques, bloqueando la IP del cliente que nos está haciendo dicho ataque cuando llega a un número de intentos determinados que podemos configurar.

Es decir, podemos poner que como máximo una misma IP pueda equivocarse tres veces poniendo la contraseña de SSH, o la del admin del wordpress, o la de FTP, y al intentar una cuarta vez ya no podría conectar porque estaría bloqueado por el firewall de nuestro servidor.
Que se bloquee a nivel de firewall nos da dos ventajas:
- Que no puede seguir realizando el ataque
- Y que no nos consumirá tanto ancho de banda, ya que ni siquiera puede establecer la conexión para intentar introducir el usuario y la contraseña.
Fail2ban lo que hace es leer los ficheros de log de los distintos servicios para saber qué ip se ha equivocado al hacer login y bloquearla siguiendo unas reglas.


Para instalar fail2ban en Ubuntu tenemos que ejecutar el siguiente comando como root:

 Una vez instalado tenemos que hacer una copia del fichero /etc/fail2ban/jail.conf a jail.local para que si alguna vez se actualiza el paquete fail2ban no nos sobreescriba nuestra configuración:


Y luego hay que editar el fichero /etc/fail2ban/jail.local para activar los servicios que queremos monitorear, en mi caso serían vsftp (FTP), ssh y wordpress:


En la línea 6 (ignoreip) puedes poner IP's que NUNCA serán baneadas, por ejemplo la de tu trabajo (si es IP fija).
En la línea 7 (bantime) se especifica el tiempo de baneo, en mi caso puse 36000 segundos = 10 horas
En la línea 8 pones las veces como máximo que se pueden equivocar al poner la contraseña, he puesto 3 aunque luego en cada servicio se puede especificar las veces que quieres.

Y después tenemos la configuración para cada servicio que se entiende bastante fácil para qué es cada cosa, si tenéis dudas poned un comentario y respondo.

 Para que funcione bien hay que modificar la configuración de ssh para que en el log guarde las IP's y no los nombres de las máquinas que se contectan, para ello añadimos esta línea al final del fichero /etc/ssh/sshd_config:

 
Para que wordpress cree el fichero de log hay que instalar este plugin:
 
http://wordpress.org/plugins/wp-fail2ban/
 
El zip del plugin viene con el fichero wordpress.conf que hay que copiar en la ruta /etc/fail2ban/filter.d
 
Y luego ya podemos reinciar el ssh, el fail2ban y el wordpress:
 
 
A partir de ese momento, fail2ban empezará a banear las IP's.
Este es un ejemplo de IP's baneadas (ficticias):
 
 
 En mi servidor cada día banea unas 10 IP's, sobre todo en el servicio ssh, sobre todo de paises como Tailandia, China, etc.
Espero que os sirva, y si hay dudas, ya sabéis... un comentario ;-)

 

lunes, 28 de octubre de 2013

Incrementar la seguridad de tu servidor (Segunda parte)

Hola de nuevo,

después de la primera parte en la que hablamos de cómo conseguir que root no pudiera entrar en nuestro servidor por SSH, vamos con la segunda parte en la que aprenderemos a configurar el firewall que viene integrado en el kernel de linux, hablamos de iptables.

Por defecto una instalación de Linux es bastante segura, pero aún así siempre es mejor configurar el firewall para que sólo tengamos abiertos los puertos que queremos, aunque haya programas escuchando en más puertos.

Esto se hace entrando por SSH, luego obteniendo permisos de root y ejecutando el siguiente script que explicaré paso a paso:



De la línea 5 a la 8 estamos diciendo nuestra política por defecto, en concreto decimos que los paquetes entrantes (INPUT) y que pasen por nuestra máquina en dirección a otra (FORWARD) sean rechazados (DROP), y que los paquetes salientes de nuestra máquina (OUTPUT) sean aceptados (ACCEPT)

De la línea 13 a la 15 lo que hacemos es borrar cualquier regla que pudiera estar definida con anterioridad con la opción -F.

En la línea 18 estamos diciendo que cualquier paquete entrante que venga relacionado con una conexión previamente establecida sea aceptado.

En la línea 19 estamos aceptando cualquier paquete que vaya destinado a la interfaz local para que los programas locales se puedan comunicar entre si.

En la línea 22 estamos aceptando los paquetes ICMP de tipo ECHO (8), es decir, estamos aceptando paquetes que nos envíe el programa PING que sirve para ver si nuestro servidor está funcionando. Si no hacemos esto, OVH pensará que nuestro servidor ha sufrido un problema y nos abrirán un ticket de reparación automático. Además, siempre es mejor que nuestro servidor responda a los PING. En la línea 23 estamos configurando que nuestros paquetes de respuesta al PING de tipo ECHO REPLY (tipo 0) puedan salir (OUTPUT) de nuestro servidor, esto no haría falta ya que permitimos por defecto cualquier paquete saliente, pero por si acaso algún día cambiamos nuestra política por defecto no está de más incluirlo.

En la línea 24 estamos aceptando paquetes que vayan al puerto de SSH, el puerto 22 por defecto.

En la línea 28 estamos aceptado paquetes destinados al puerto 80 (HTTP) , suponiendo que nuestro servidor vaya a actuar como servidor web, en caso contrario, es mejor quitar esta línea.

De la línea 32 a la 34 estamos aceptando paquetes para el servicio FTP, puertos 21 (FTP) y 20 (FTP-DATA), así como los puertos del 40110 al 40210 cuando sea una conexión pasiva, estos últimos puertos debemos configurarlos en nuestro servidor de FTP.  Si nuestro servidor no va a actuar como servidor FTP es mejor quitar estas tres líneas.

Una vez hayamos ejecutado este script ya estariamos protegidos mediante el firewall, sin embargo, si apagáramos y encendiéramos el servidor todas las reglas se perderían, para evitar esto tenemos muchas maneras de hacerlo, la que yo hice fue la siguiente:

Crear un script en "/etc/network/if-post-down.d/iptablessave" que guarde las reglas al apagar la máquina:




Y creamos un script que cargue las reglas previamente guardadas en "/etc/network/if-pre-up.d/iptablesload"



Y con esto ya tendríamos el firewall de nuestro servidor finalizado.

Tenéis más información sobre todo esto aquí. Y también tenéis la documentación oficial de iptables aquí.

En la siguiente entrega veremos cómo seguir configurando nuestro servidor para conseguir un poco más de seguridad.
Saludos y hasta pronto.

domingo, 27 de octubre de 2013

Incrementar la seguridad de tu servidor (Primera parte)

Hola de nuevo queridos lectores, últimamente he estado algo ausente y me disculpo por ello, 6 meses sin escribir es demasiado, mea culpa :-(

Hoy os quería hablar de cómo incrementar la seguridad de un servidor dedicado ya que recientemente alquilé un Kemsirve 2G y nunca está de más hacer que el servidor sea lo más seguro posible.

Lo primero aclarar una máxima en cuanto a seguridad: la seguridad total no existe, así, subrayado para que lo tengamos todos claro. Es imposible conseguir que un servidor sea 100% seguro, siempre habrá algo que se nos escape, algún bug no documentado, algún mecanismo que permita a un cracker (que no hacker) experimentado entrar si dispone de los recursos y el tiempo necesario para hacerlo.

Aclarado este punto, vamos a intentar ponerle lo más dificil posible a nuestro cracker el acceder a nuestro servidor. Cuando digo "acceder" me refiero a que la persona atacante acabe teniendo un intérprete de comandos con nivel de "root" (administrador) o con un nivel inferior pero que le permita ejecutar ciertas acciones.

En este "tutorial" me baso en un servidor dedicado ejecutando Ubuntu Server 13.04. La mayoría de cosas servirán para otras versiones del mismo SO y también para otras distribuciones de Linux como Debian, Mint, etc.

Lo primero que debemos hacer para empezar a tener un servidor seguro es elegir bien la contraseña de root, y con "elegir bien" no me refiero a que si tu hijo se llama Juan Garcia pongas de contraseña "Ju4nG4rc1a", esta contraseña es malísima porque ya todos nos sabemos lo de cambiar letras por números que se parezcan. No, cuando digo contraseñas seguras me refiero a contraseñas del estilo de las que te generan programas como KeePass, por ejemplo esta: W5X{3uGVHwICZ9gxrEl7.

Lo siguiente que hay que hacer es actualizar tu sistema operativo, ya sabemos cómo (apt-get update && apt-get upgrade) ejecutándolo con permisos de root.

Algunas distribuciones de Linux, al instalarlas, te obligan a crear un usuario que mediante "sudo" puede ejecutar programas con permisos de root, este es el caso de Ubuntu Server. Sin embargo, la distribución de Ubuntu Server que te instala OVH no hace esto, sino que te da acceso como root por ssh. Esto es malo por dos motivos: Porque te obliga a entrar como root aunque sea para realizar tareas que no requieran permisos de root, y también es malo porque puedes recibir ataques para intentar encontrar tu contraseña de root entrando por SSH.

Por tanto, lo primero que haremos será NO permitir la entrada del usaurio root por SSH.  Para ello lo primero que tenemos que hacer es crearnos un usuario distinto a root para entrar en nuestro servidor, por ejemplo vamos a crear el usuario de nombre "asterix" con este comando:




Bastará con dejar los datos que nos vengan por defecto.

Luego comprobamos que efectivamente podemos acceder por SSH con nuestro nuevo usuario (asterix en el ejemplo) . También comprobaremos que una vez logados con nuestro usuario podemos hacer un "su -" y pasar a ser root poniendo la contraseña de éste.
Una vez hecho esto es el momento de no permitir que root entre por SSH, ya que siempre lo haremos con nuestro usuario (asterix o el nombre que le hayáis puesto) y una vez dentro haremos "su -" para ejecutar tareas administrativas. Para ello editamos el fichero "/etc/ssh/sshd_config" y añadimos esta línea al final:



Y luego hacemos un:



Ahora probamos a entrar por SSH con nuestro usuario y luego lo intentamos con root, esto último no debería dejarnos, incluso aunque hayamos puesto bien nuestra contraseña de root.

Con esto evitamos ataques de fuerza bruta al puerto SSH ya que la mayoría de estos ataques lo intentan con el usuario root, y eso ahora será imposible, incluso aunque supieran nuestra contraseña de root.
En el caso de mi servidor, nada más instalarlo, recibía ataques diarios durante horas de intentos de entrar por SSH como root, con este truco evitamos que puedan entrar de este modo.

En próximas entregas veremos cómo configurar más parámetros de nuestro servidor para hacerlo (un poco) más seguro.

Hasta pronto, un saludo.

martes, 16 de abril de 2013

Display option en una grid de Dynamics AX (Axapta) y un sólo registro

Imaginemos un formulario de Dynamics AX (Axapta) con una tabla principal en la que mostramos cierta información en modo lectura, por ejemplo registros de ventas:


Para que de un rápido vistazo el usuario pueda ver los registros que están en estado "Cancelado" podemos hacer que éstos aparezcan en rojo, sobrecargando el método "displayOption" del DataSource:

Y el resultado sería este:


Como podemos ver, aparece en rojo el que está cancelado y el resto en blanco o en gris.... hasta aquí todo bien.... ¿pero qué pasa si hay sólo un registro?
Pues efectivamente pasa que no sabemos qué color tiene, porque se resalta en azul por ser el registro activo:


¿Cómo podemos arreglar esto? Pues la solución es bastante fácil, sólo hay que poner el siguiento código en el executeQuery del dataSource:

Y al haber sólo un registro quedaría así:


Lo que estamos haciendo en ese código, es desactivar el resaltado del registro activo si hay un registro, y activarlo cuando hay más de uno. 

De esta manera, teniendo un sólo registro en la tabla, ya sea porque sólo haya un registro en la base de datos o ya sea porque hemos filtrado en el grid, podemos saber en qué estado está ese registro de un golpe de vista, viendo el color que tiene.

¡¡Hasta la próxima!!