Siguiendo con el post anterior de bloqueo de IPs usando el cortafuegos integrado en el núcleo de Linux, llegamos a la necesidad de por ejemplo bloquear a cierto país. Hay negocios, o páginas web, que han recibido quizás ataques automáticos desde IPs que residen en Rusia, Rumanía o China. Si cerramos dicha entrada al servidor nos evitaríamos muchos problemas.
Tengamos en cuenta que si nuestro servidor trabaja con servidores que residen en estos países, podremos encontrarnos con conexiones que no se hacen, no dan respuesta al conectar, denegación de conexión.. Es complicado si nos olvidamos de que hemos bloqueado, por ejemplo, a Rusia. Si luego resulta que contratamos un servicio ruso, cuyos servidores residen en Rusia, estaremos contratando un servicio que no nos va a poder conectar.
Obteniendo IPs registradas por país
El primera paso es tener un listado de IPs del país en concreto que queremos bloquear. Para esto tenemos varias páginas que nos los sirven sin cargo. Por ejemplo:
Mejor coge los rangos de IPs del país que quieras bloquear usando el formato en CIDR. Es decir de la forma red/máscara, son así:
2.136.0.0/13
2.152.0.0/14
Tienes entonces que guardarte este listado de CIDRs de forma que tengas 1 CIDR por línea del fichero. Lo guardas en un fichero de texto, y se lo subes al servidor.
Metiendo el bloqueo en el firewall de Iptables
Para esto, desde un servidor GNU/Linux, bastará con ejecutar lo siguiente:
$ while read line; do sudo ufw deny from $line; done < IPsCountryCIDR.txt
Ahora hay que esperar mientras que se cargan todos los bloqueos en el cortafuegos. Tardará un buen rato porque UFW se encarga de transformar, línea a línea, al formato de Iptables.
Sólo nos quedará comprobar que está activo y con las reglas de bloqueo funcionando. Simulando una visita desde dicho país podremos comprobarlo.
Simulando visita desde cierto país
Para esto puedes usar el TorBrowser, del enrutamiento cebolla. Puedes descargártelo aquí:
https://www.torproject.org/
El navegador de la red Tor es un proyecto, que usando Firefox, hace que podamos navegar anónimamente. Esta anonimización la hace creando un camino de conexiones de varios nodos, desde nuestro PC, a la página destino. De esta manera podemos decirle al TorBrowser que queremos que el último nodo sea en un país concreto. Para esto abrimos el fichero este:
Browser/TorBrowser/Data/Tor/torrc
..y ponemos lo siguiente:
ExitNodes {es}
StrictNodes 1
El código entre llaves es el código del nodo final. Con esta configuración podemos visitar y ver esto en el navegador:
Terminando
Esto es todo, si has seguido todos los pasos, debes de haber podido bloquear el acceso a cierto país y comprobarlo con el TorBrowser.
Una de las tareas más interesantes para saber si las cosas sirven para algo en tu negocio de Internet, consiste en seguir a las visitas. Es decir, consiste en el seguimiento de la conversión, mediante lo que se llaman píxeles de conversión. Es decir, si queremos saber si un canal de entrada a tu web convierte o no, si los anuncios que ponemos en otras webs, si los enlaces de redes sociales, emails, etc.. sirven de algo. Para esto debemos de llevar un seguimiento de dicha entrada a tu web.
Quizá tienes que estudiar los registros de visitas de un proyecto que está en una nube, detrás de un CloudFront de Amazon Web Services. En este proyecto tenemos guardados los registros de las peticiones web que tenemos a los servidores. A veces es interesante revisarlos a este nivel.
Es decir, que tenemos registros de las visitas, anonimizados, por ejemplo con Google Analytics. Pero pasan muchas más cosas por debajo de Google Analytics que sólo quedan reflejados en los registros de los servidores. Así que resulta que queremos saber absolutamente cuáles han sido todos los registros. Queremos saber qué IPs son las que más nos visitan. Qué consultas al servidor son las que están provocando errores de servidor, los 500, incluso antes de que lleguen los robots que nos indexan. Qué IPs son de robots que nos están crawleando, o indexando, y un largo etcétera. Probablemente aquí veamos las IPs de los robots de Google, Bing, Yahoo que nos visitan en busca de información de la web..
Si has puesto un servidor Ubuntu/Linux lanzándole actualizaciones automáticas puede que hayas llegado a encontrarlo bloqueado. El servidor ha dejado de actualizarse y no hay manera de encontrar el problema. Cuesta mucho entrar al servidor. Un reinicio, paramos servicios, podemos hacer un par de cosas recién conectados, pero vuelve a bloquearse.. Volvemos a reiniciar para volver a entrar corriendo a ver qué pasa.. la gente corre.. ¡las mujeres y los niños primero! 😀
Esto pueden ser los síntomas de un servidor lleno. Lleno el disco duro, la memoria RAM, los i-nodos.. ha empezado a reventar por todos lados y necesitamos volverlo a la normalidad. Toca pues hacer un par de cosas..
Hoy traigo un pequeño HOWTO de cómo balancear las visitas de un sitio web entre varios servidores, eligiendo exactamente qué visitas van a qué servidores. Se trata unas pocas directrices para configurar CloudFront y así redirigir las peticiones web.
Con esto puedes controlar qué subdirectorios, o que zonas de tu aplicación web se gestionan desde qué servidores. Balancear en función de la carga se puede hacer con un ELB (Elastic Load Balancer), pero estas configuraciones a nivel de CloudFront balancean las peticiones de forma permanente. Por ejemplo:
Montar una web con lo imprescindible, ponerle el contenido y diseño, y olvidarnos de ella.. sería como comprarnos un coche y ya no preocuparnos nunca por pasarle una revisión. Sería como si nos diera igual si hay una bajada de potencia del motor, que las ruedas no estuvieran bien hinchadas. Quizá una bujía deja de dar los chispazos al 100%..
Y no sólo están los problemas de mal-funcionamiento, sino que quizá también hay algunas mejoras extras. No todo viene de casa, y puedes hacer que el coche vaya mejor. ¿Porqué no entonces dedicarle ese tiempo a nuestra web para revisar esas cosas? Es más, ¿porqué no poner a un mecánico que sepa lo que está haciendo? Está claro que nos podemos quedar tal cual, nuestro coche andará. Pero queremos que no le falte esa alegría, que responda sin pereza. Resumiendo, queremos que la maquinaria esté bien engrasada, sacando el 100% de su rendimiento. Entonces necesitaremos a un especialista que toque, pero no de oídas, sino que sepa lo que está tocando.
Una de las alternativas de almacenamiento en la nube más prometedoras es Mega. Proviene de la antigua Megaupload, de la mano de Kit Dotcom, fundador de Megaupload. Lo pusieron en marcha Kim junto a su equipo de trabajo, parece que como respuesta al cierre y confiscado de Megaupload debido a la piratería. Mega puede parecer algo novedoso, sin embargo, no es más que el mismo sistema de almacenamiento en la nube de archivos pero mucho más elaborado que el anterior. Salió al mercado hace ya cuatro años, en el 2013. Fue tanta la expectativa que hubo millones de usuarios que se registraron en muy poco tiempo hasta colapsar sus servidores. A día de hoy Kim Dotcom se ha desvinculado del proyecto, y navegando un poco puedo leer reseñas que hablan que hay alrededor de 50 millones de usuarios registrados en Mega.
Sus principales bazas en el mercado del almacenamiento en la nube han sido dos: los famosos 50 Gigas gratis, y su esfuerzo por la privacidad de los usuarios.
Ya puedes tener la estrategia de marketing mejor del mundo, la mejor campaña publicitaria, los mejores anuncios. Unas publicaciones excelentes en blogs, una gran inversión en SEM, o un SEO de contenidos inmejorable. Que si la infraestructura informática subyacente no acompaña de poco servirá. Aquí es donde entra el estar o no en la nube. Y nunca mejor dicho, poner tu aplicación web por las nubes.
¡Buenos días a todos! Voy a tratar de no perder las buenas costumbres, como esta de compartir en el blog mi granito de arena en todo esto de la informática. Hasta estos últimos días, que no he tenido la necesidad de mantener al día tantos servidores como últimamente. Estaba haciéndolo manualmente, a pelo como se suele decir, entrando en los servidores y aplicando actualizaciones, modificaciones, etc.. Todo esto es mucho tiempo así que delegar en un proveedor de hosting todo éste trabajo es una buena elección. Pero no siempre te va a valer y puede que necesites hacer configuraciones que un proveedor de hosting no te va a permitir. Administrar tu propio servidor no tiene que ser complejo.
Todo esto me ha llevado a investigar sobre paneles de control de servidores. Tenemos el gran Cpanel, Plesk, Zpanel, y un largo etcétera. Por temas laborales ya he probado algunos en los propios proveedores. Muchos funcionan de maravilla y son sencillos de gestionar. Pero no me voy a dedicar a alquilar hosts, sino que simplemente necesito mantener unos pocos servidores y no es viable comprar una solución comercial. Así que navegando y navegando al final me topé con Webmin.
Qué tiene
A grandes rasgos es una web desarrollada sobre Perl, que se instala en el puerto 10000 del servidor y se integra con el sistema operativo. Nos permite ver el estado del servidor, hacer configuraciones de red, actualizarlo, programar actualizaciones automáticas recibiendo informes a tu email. Te permite configurar usuarios, permisos, instalar bases de datos, servidor web, configurarlos. También hay módulos para instalar un servidor de correo electrónico. Puedes administrar Apache2, Mysql, Postgres, Postfix, Dovecod, etc, etc, etc.
La verdad es que te quedas mucho más tranquilo teniendo una herramienta de estas instalada en un servidor. No tienes más que entrar y de un vistazo puedes saber qué tal anda el sistema. Puedes aplicar las principales configuraciones y a correr que el tiempo es muy valioso.
Hay algunas tareas como la configuración hosts virtuales que haciéndolas a mano me he aclarado mejor. Pero deduzco que será cuestión de acostumbrarme al panel. Leo que hay extensiones de Webmin para configurar fácilmente hosts con varios dominios, permitiendo la lectura de correos a los usuarios proporcionándoles un panel de entrada al sistema.
Un detalle que me ha gustado mucho es la autenticación en dos pasos (multi-factor authentication, MFA). Con el que podemos tener por ejemplo en nuestro móvil el Google Authenticator, y tener un código de seguridad extra que se genere a cada 30 segundos, para poder entrar como en la imagen siguiente:
El theme, piel, o plantilla que podéis ver en las imágenes no es el original. Es el ‘Authentic theme’ que me ha gustado también mucho. Es totalmente sensible al dispositivo (responsive), con lo que también podemos aplicar configuraciones sobre nuestro servidor desde el móvil o tablet, cosa que se agradece en gran manera.
Aquí podemos ver lo sencillo que se hace mantener actualizado el sistema:
Aquí en la imagen se puede ver cómo configurar que todos los días se apliquen todas las actualizaciones del sistema, no sólo las de seguridad. Esto dispara cada día la instalación de todos los paquetes para actualizar y me envía un informe del resultado de la instalación a mi email. Ya os podéis hacer a la idea de que tiene muchas cosas, y lo tranquilo que me quedo con cada correo que recibo diciéndome que todo se ha actualizado correctamente.
Como buen usuario de Ubuntu, todas las pruebas y las imágenes que se ven son sobre Ubuntu. Me lo voy a anotar como indispensable en las nuevas instalaciones. Navegando y navegando por el menú lateral ya veo que no me lo voy a acabar, así que tendré que ver la documentación oficial de cada herramienta para ir más al grano en las tareas que se necesiten.
Es un proyecto alojado en Github, que por lo que veo se ve bien activo. Ahora mismo hace 4 horas que han subido una actualización, lo que denota que vamos a seguir teniendo actualizaciones frecuentemente, como todo buen proyecto Open Source.
Para el que quiera seguir investigando en esta joya de la informática, son interesantes los módulos Usermin y Virtualmin. No creo que tarde mucho en probarlos. De estos tenemos una versión gratuita y otra comercial, con las que vamos añadiendo más y más funcionalidades al panel de control.
¿Alguna sugerencia de otro programa similar para administrar servidores?
Hola de nuevo. Aquí traigo otro pequeño HOWTO para automatizar la instalación de un servidor Postresql. Como ya indico en el post anterior, estoy jugueteando con Vagrant y necesito instalar la base de datos automáticamente para no tener que estar haciéndolo cada vez. Así que ya puestos a usar Vagrant o simplemente a usar la línea de comandos podemos ejecutar estos comandos para instalar y configurar Postgresql sin sufrir mucho y comenzar a trabajar lo antes posible.
Porqué Postgresql
Un compañero de trabajo me hizo una vez la pregunta, ¿porqué Postgresql?
Es un gigante de las bases de datos relacionales. Robusta como ella misma, soporta clustering, integridad referencial.. una cantidad ingente de características. En sus últimas versiones no tiene nada que envidiar al resto de bases de datos. Y mucho la catalogan como la mejor base de datos relacional Open Source. Además de que tenemos el pgAdmin que funciona a las mil maravillas.
https://es.wikipedia.org/wiki/PostgreSQL
Hay cantidad de información por Internet, ya que desde 1982 leo que está dando guerra, así que te puedes hacer una idea de si es o no una buena elección. Cada cual que mire cuáles son sus requisitos pues no es objetivo de este post hacer una comparativa.
Dónde está el script
Sin más preámbulos el script de instalación es el siguiente:
postgres_conf_file=»/etc/postgresql/9.3/main/postgresql.conf» postgres_pg_hba_file=»/etc/postgresql/9.3/main/pg_hba.conf» main() { apt-get -y install postgresql sudo -u postgres psql<<EOI password postgres postgres postgres q EOI sed -i «s/#listen_addresses = ‘localhost’/listen_addresses = ‘*’/g» ${postgres_conf_file} cat <<EOI > ${postgres_pg_hba_file} local all all md5 host all all 127.0.0.1/32 md5 host all all 10.0.2.2/32 md5 host all all ::1/128 md5 EOI service postgresql restart } main exit 0
A fecha en que escribo, este código se puede incluir en un Schell Script que por ejemplo podemos llamar instalarPostgresql.sh, darle permiso de ejecución y lanzarlo. Funciona con la versión que se instala actualmente en un servidor de producción con Ubuntu Server 14.04 que es la 9.3 de Postgresql si no me falla la memoria.
Simplemente instala el servidor, se conecta con el cliente psql para cambiar la contraseña del administrador postgres, escucha en todas las interfaces de red y permite conectar por red a 127.0.0.1 y a 10.0.2.2 que es la IP que se ve desde dentro de una máquina virtualizada con Vagrant.
LibreOffice es una suite ofimática, es decir, para trabajos relacionados con la oficina como pueden ser documentos de texto, hojas de cálculo, presentaciones, incluso tiene para bases de datos. Toda una joya de la informática les traigo hoy con éste programa. Ya lo he mencionado anteriormente en otro post pero no por ello deja de tener mucha importancia.
La competencia
Pues bien, comparando con otras soluciones de pago como pueden ser Microsoft Office o los Google Docs que tenemos gratis disponibles en dispositivos Android. Tenemos ahora que LibreOffice va siendo cada vez más una gran solución que casi no tiene nada que envidiar al resto.
Vengo leyendo desde hace un tiempo que tienen planeado la edición de documentos online. Es decir, se instalará LibreOffice en un servidor desde el que se servirán los archivos. ¿Os suena?, al estilo que los documentos de Drive o el Office Online de Microsoft.
Entre las nuevas mejoras trae una interfaz renovada, que desde se separó el desarrollo del estancado OpenOffice, han ido queriendo diferenciarse cada vez más y más. También informan en su web que tenemos mejoras sustanciales en el funcionamiento de las hojas de cálculo, filtros, mayor velocidad, etc.
Todo apunta a una serie de características de la versión 4 que se han ido mejorando cada vez más y ahora espero que estemos en un punto de inflexión en donde se apunte más a la nube, al trabajo en red con ficheros de LibreOffice.
Otro punto importante son las mejoras de las aplicaciones para móviles. Son conscientes que los dispositivos móviles y tablets van a tener una importante presencia. Pero no van a descartar a los ordenadores, porque una buena pantalla junto con ratón y teclado no dejarán de ser más productivos a la larga para las tareas ofimáticas.
Para administrar un servidor dedicado o virtual Linux necesitamos herramientas para controlar el uso de memoria, cpu o almacenamiento. Hay una herramienta en modo consola o de terminal con la que podemos entrar y ver su estado sin necesitar de un entorno gráfico.
Estamos entonces pensando que el servidor que hemos contratado es demasiado pequeño y vayamos a contratar uno más grande. Pero antes merece la pena no entrar en más gastos y optimizarlo. Porque tal vez tengamos mucha más máquina que lo que estamos pensando, sólo era necesario optimizar.
Instalación de htop
$ sudo apt-get install htop
Una vez instalado ejecutamos htop si todo ha ido bien y ya tenemos un informe muy interesante. Ahora sabremos si estamos al borde del colapso, si el servidor de base de datos está consumiendo demasiado, etcétera. O si simplemente le sobra memoria y algo raro le está pasando.
Frentes de ataque para optimizar un servidor
Se supone que con un servidor pequeño, de 1 procesador y 1 Giga de RAM, se deben de poder servir alrededor de 10 000 vistas de página diarias. Es mucho ¿cierto? Pues sí, no estoy exagerando, la experiencia nos dice que las configuraciones por defecto de Apache, MariaDB y PHP tal vez no se acomoden bien y el servidor vaya lento, muestre páginas en blanco, se caiga el servicio.
Para cada programa o servicio se necesita su configuración así que sin contemplar la posibilidad de ampliar el servidor físicamente podemos optimizarlo viendo lo siguiente.
Configuraciones de Apache2
En un Ubuntu Server podemos encontrar sus configuraciones en /etc/apache2/apache2.conf Una de las cosas que merece la pena activar es la caché, aumenta considerablemente su rendimiento.
Si tenemos, como en éste caso una única máquina con todo en el mismo servidor (Apache2, MariaDB y PHP5). La memoria caché APC es una buena opción y se activa muy fácilmente con PHP5 si la tenemos disponible ya en Apache2.
Configuraciones de MariaDB
He escogido ésta base de datos porque trae muchas mejoras con respecto a MySQL y podemos instalar cualquier CMS compatible con MYSQL. Aparte de que es totalmente gratis.
Cuidado con la versión que instalemos, elegir mejor una estable para producción.
Las configuraciones de MariaDB las podemos optimizar en /etc/mysql/my.cnf
Es interesante instalarnos localmente MySQL y ver los fichers my-small.cnf, my-medium.cnf, my-large.cnf y my-huge.cnf para configurar los límites de nuestra MariaDB. Cuidado porque un servidor small se supone que sólo tiene 64 MB de RAM, uno de 1 GB de RAM es un servidor grande aunque no nos lo parezca, ya uno de 4 GB de RAM es enorme (huge).
Configuraciones de PHP
Tenemos en /etc/php5.6/apache2/php.ini las configuraciones que se usan para correr los scripts de PHP desde Apache.
Puede ser interesante optimizar la configuración de la linea de comandos de PHP con el fichero /etc/php5.6/cli/php.ini Éste fichero es el que se usa cuando ejecutas php desde línea de comandos. Puede ser necesario configurarlo para usar phpunit, comandos de consola de frameworks PHP, etc.
La caché de ejecución de scripts o el tiempo máximo de ejecución de un script pueden ser valores clave que provoquen que tus webs se queden en blanco. Algunos valores a los que suelo darle más son:
Si delegas la ejecución de PHP en el servicio FPM/Fastcgi sería lo mejor. Para esto hay que instalar el módulo fpm de PHP. Y el módulo de Apache para que delegue la ejecución de scripts PHP a este servicio llamado php-fpm. En este caso, tendrás las mismas configuraciones que cito antes pero en otro fichero que carga desde /etc/php5.6/fpm/php.ini, /etc/php7.2/fpm/php.ini según la versión de PHP que tengas instalada.
Cuando se instala el FPM/Fastcgi lo que conseguimos es que tanto Apache2 como PHP se ejecuten concurrentemente, pudiendo servir más páginas en paralelo.
Está la swap creada y activada?
Por último puede ser que la memoria de intercambio no esté creada. En muchos servidores virtuales simplemente tenemos la partición del sistema de ficheros principal. Damos por sentado que cuando se nos ha dado el servidor ya tenemos swap. Entonces si realmente no la tenemos no podemos usarla y si llenamos toda la memoria RAM ya tenemos colapsado el servidor porque no tiene realmente swap.
Podemos verlo usando:
$ free -m
Por ejemplo en un servidor con 1 GB de RAM y 512 GB de memoria de intercambio swap podemos tener lo siguiente:
Si no nos sale algo parecido ya tenemos otra cosa que optimizar.
Apache Benchmark
Es interesante llevar al límite a nuestro servidor usando ésta herramienta, podemos simular fácilmente varios visitantes simultáneos hasta llegar a saturar el servidor y sabremos así cuánto aguanta y si ya es suficiente.
De nuevo si tenemos Linux como máquina local es muy sencillo instalarlo sólo con poner:
$ sudo apt-get install apache2-utils
Por ejemplo si quiero ejecutar 100 peticiones de 10 visitantes simultáneamente a mi máquina local escribimos:
$ ab -n 100 -c 10 http://localhost/
En mi caso, me sale los siguientes resultados que son bien interesantes. Junto con htop podemos ver en tiempo real qué ha pasado con nuestro servidor.
This is ApacheBench, Version 2.3 <$Revision: 1528965 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient)…..done Server Software: Apache/2.4.7 Server Hostname: localhost Server Port: 80 Document Path: / Document Length: 5306 bytes Concurrency Level: 10 Time taken for tests: 2.751 seconds Complete requests: 100 Failed requests: 0 Total transferred: 560500 bytes HTML transferred: 530600 bytes Requests per second: 36.35 [#/sec] (mean) Time per request: 275.072 [ms] (mean) Time per request: 27.507 [ms] (mean, across all concurrent requests) Transfer rate: 198.99 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 0 Processing: 21 274 659.4 58 2242 Waiting: 21 271 653.4 56 2225 Total: 21 274 659.4 58 2242 Percentage of the requests served within a certain time (ms) 50% 58 66% 65 75% 75 80% 79 90% 2241 95% 2242 98% 2242 99% 2242 100% 2242 (longest request)
Puede ser un poco bruto pero ya puestos a llevar al extremo a nuestro servidor no está de sobra probarlo. Si el servidor aguanta el test entonces eso es buena señal. Si de repente ya no tenemos las webs visibles. Jeje, pues a optimizar.
Hay personas que dedican todo su trabajo a optimizar cada uno de éstos programas. Espero que comprenda que no puedo resumirlos en un sólo post así que aquí lo dejo y me remito a la documentación oficial.
