Servidores

Linux, Servidores, Sistemas, Trucos

Modo rescate OVH: cómo acceder a tu servidor aunque esté caído o bloqueado.

/

Tenemos servidores de clientes en varios proveedores, uno de ellos OVH. Hace unos días uno de dichos servidores, tras una modificación en los iptables, nos echó y no dejaba conectarnos. De ninguna manera, ni tras reiniciar. Por si os ocurre, os explicamos el modo rescate de OVH (gracias, gracias, gracias OVH), a través del cual pudimos deshacer la modificación anterior y acceder de nuevo al servidor. El modo rescue-pro, rescate, carga un sistema Linux basado en Debian desde red, lo que te permite montar los discos y hacer los cambios necesarios. Igual que si tuvieras el servidor delante y iniciaras en modo recuperación de Linux. Para activar el modo rescate (inglés): Tienes que ir al área de cliente dedicado y seleccione el servidor al que quieres acceder en la columna izquierda. En la pestaña «Estado del servidor», en «Información general» > «Boot», pincha en «Editar». Después «Iniciar en modo rescue» y elige la configuración rescue-pro. Una vez elegido ese modo de inicio, hay que reiniciar el servidor. Si puedes por SSH, si no desde el panel de OVH. OVH mandará un correo con el la contraseña temporal de root. Entra por SSH, usa el usuario root y la contraseña que te han mandado. Verás que puedes acceder, pero no tienes los discos montados. Tienes que montarlos. Para saber que disco tienes puedes hacer fdisk -l. Monta los discos, por ejemplo con: mount /dev/hda2 /mnt/var Después haz los cambios que necesites. Para desactivar el modo rescate entra de nuevo en el mismo menú de OVH y después en el modo de inicio escoge «Iniciar en el disco duro». Después reinicia el servidor. Este tipo de servicios de los proveedores no tienen precio 😀  

Servidores, Sistemas, Trucos

Cómo probar un servidor Postfix desde línea de comandos

/

Así que has montado un servidor Postfix, todo parece ir bien, no da error… ¿cómo pruebo si funciona? Os indicamos cómo. Primero obviamente ver si el servicio está levantado y funcionando. En distribuciones Debian lo podrías hacer como: sudo postfix status Si todo está bien lo siguiente es conectarse por telnet para probarlo y mandar un mensaje. Si estás en el propio servidor para conectarte por telnet es: telnet localhost 25 Después para ver si el servidor está bien para el dominio podemos poner: EHLO tunombrededominio Tendrías que ver varias líneas con 250 delante. Si es así vamos a mandar un correo con las siguientes instrucciones (pulas enter después de cada línea): MAIL FROM: loquesea@tudominio.com RCPT TO: ladireccióndedestion@dominiodestino.loquesea DATA Después de este DATA viene el cuerpo del mensaje. Escribe lo que quieras. Para acabar tienes que poner una línea con un sólo punto y enter. . Eso le dice al servidor que se ha acabado el mensaje y deberías recibir algo como  “queued ….”. Es decir el mensaje se va a enviar. Puedes salir de telnet con quit (enter). Ahora ve a tu dirección de correo destino y mira si has recibido el mensaje. Mira también la carpeta spam. Si no lo has recibido busca en el log de postfix o del servidor. Recuerda que puedes ver la puntuación de spam enviando a estos servicios.

Seguridad, Servidores, Trucos

Proteger una web en Nginx contra ataques de fuerza bruta: rate limiting

/

Uno de los peligros que corren las páginas web es el ataque por fuerza bruta, y los ataque DDOS. Básicamente son muchas peticiones a la web por segundo, lo que bloquea los procesadores y “tira” la web (no se pueden procesar más peticiones y el servidor se cuelga). Evidentemente tenemos que proteger nuestra web de estos ataques. Cloudflare tiene unas protecciones mínimas para evitar estos ataques, pero en los modos gratis y Pro hemos hecho pruebas y no son muy efectivos (en modo alto, no se en modo ataque). Tenemos que pensar en Cloudflare como una capa más de seguridad, pero no algo 100% efectivo. Así que nos queda proteger el servidor, hoy os contamos cómo hacerlo con Nginx. Nginx tiene una directiva llamada limit_req_zone , que se puede usar junto con  limit_req para controlar el número de peticiones. Para comprenderlo podemos usar la analogía de un cubo de agua con agujeros. Si no tuviera agujeros y sigue llegando agua, el cubo rebosará (servidor caído). Si ponemos agujeros, podremos seguir metiendo agua sin que el servidor rebose, hasta un límite (donde ya rebosará). El agua que sale de los agujeros es la información que meteremos en los buffers. El agua que rebosa son las peticiones que no se atenderán, pero serán menos que sin agujeros. Esto nos permite controlar un poco ataques. Para configurar este parámetro hay que hacer lo siguiente: En el fichero de configuración tienes que añadir una línea como esta, configurando la zona y los límites. Juega con esos límites, sobre todo la última parte que son las peticiones por segundo. Puedes dejarlo en 10 o ponerlo en 1. Por defecto empieza en 10 y prueba. El nombre de la zona (mylimit) podemos cambiarlo también. limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s; Esta línea la puedes añadir tanto en el fichero de configuración del sitio, como en el directorio conf.d en un fichero llamado limits.conf. Después en el fichero de configuración del sitio (sites-enabled) tenemos que aplicar ese límite con limit_req donde queramos (por ejemplo un wp-admin de wordpress en este caso). server { location /wp-admin/ { limit_req zone=mylimit; } } También podemos ponerlo sólo para un tipo de ficheros: location ~ \.php$ { limit_req zone=one burst=5 nodelay;}   Con esto al reinciar Nginx (prueba la configuración primero) deberías poder hacer pruebas de muchas llamadas al servidor y no debería haber problemas. Cualquier exceso o se guardará en la cola o no se procesará, sin tirar el servidor. Más información aquí.

Diseño Web, Servidores, Sistemas, Trucos

Obtener la IP original de los clientes cuando usas Cloudflare

/

Ya hemos hablado largo y tendido sobre Cloudflare, una capa extra de seguridad y de caché para tus páginas web. Eso si, si deseas obtener, por tema de registro o para alguna aplicación web, la IP de un cliente, verás que hay un problema. Al venir todas las peticiones de los servidores de Cloudflare, no sabes la IP real de un cliente. Aquí os comentamos cómo resolverlo. En esta página de Cloudflare viene la solución para cada servidor web o proxy. Por ejemplo en Apache debemos instalar el módulo mod_cloudflare. En Nginx podemos usar otro módulo que se llama http_real_ip. Este módulo no se carga por defecto, hay que instalarlo o compilarlo con la opción –with-http_realip_module . Si ese es tu caso estás de enhorabuena. Sólo tienes que poner en tu configuración de nginx: set_real_ip_from 103.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 104.16.0.0/12; set_real_ip_from 108.162.192.0/18; set_real_ip_from 131.0.72.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 162.158.0.0/15; set_real_ip_from 172.64.0.0/13; set_real_ip_from 173.245.48.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 190.93.240.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 199.27.128.0/21; set_real_ip_from 2400:cb00::/32; set_real_ip_from 2606:4700::/32; set_real_ip_from 2803:f800::/32; set_real_ip_from 2405:b500::/32; set_real_ip_from 2405:8100::/32; set_real_ip_from 2c0f:f248::/32; set_real_ip_from 2a06:98c0::/29; # use any of the following two real_ip_header CF-Connecting-IP; #real_ip_header X-Forwarded-For; Después sólo tienes que probar la configuración de nginx y reiniciar si todo está bien. Deberías ver las IPs originales. Si no tienes es módulo en nginx, y no te apetece recompilar, puedes hacer un truco. En la configuración de nginx puedes poner algo como: location ~ \.php$ { fastcgi_param REMOTE_ADDR $http_x_real_ip; #…other rules } Esto usará ese parámetro de http_x_real_ip para coger la ip real que Cloudflare pone en las cabeceras. Pero sólo valdrá para aplicaciones que pasen por fastcgi. Por ejemplo el propio nginx no sabrá la ip real si no le ponemos un parámetro (ver las siguientes líneas). También puedes usar esta opción para redirigir según la IP real, por ejemplo con: if ($http_x_real_ip != xxxx.xxxx.xxxx.xxxx) {          return 403;         } Y, si no quieres ponerlo en nginx puedes buscar las cabeceras desde Php con: if (isset($_SERVER[“HTTP_CF_CONNECTING_IP”])) { $_SERVER[‘REMOTE_ADDR’] = $_SERVER[“HTTP_CF_CONNECTING_IP”]; } ¿Cómo comprobar que funciona? Además de en los logs (que puede ser un follón mirarlo), puedes poner un phpInfo en tu servidor (quítalo luego). Hay un apartado donde puedes ver el SERVER [“Remote Address”] y las cabeceras que pasa Cloudflare en SERVER [“http_x_real_ip”] y SERVER [“http_x_forwarded_for”]. Cuando funciona, el campo Remote Address debe ser una de las cabeceras de Cloudflare (http_x_real_ip o la otra según cual uses).  

Seguridad, Servidores, Sistemas, Trucos

Cómo proteger un servidor web para que sólo acedan las IPs de Cloudflare

/

 Ya hemos hablado de Cloudflare, el servicio web que sirve cono CDN, cahcé, firewall y mucho más. Tiene varios planes, gratis y de pago. Pero para la mayoría de las páginas web el modo gratis es suficiente. Mientras seáis conscientes de los límites de subida que establece Cloudflare. Hoy os vamos a enseñar “un truco” por el que vamos a limitar a nuestro servidor a que acepte sólo peticiones web que accedan de las IPs de Cloudflare. Esto aumentará la seguridad en nuestra web, porque eliminará cualquier petición que no proceda de Cloudflare, y las que procedan de ahí vienen filtradas por sus sistemas de seguridad. Además, también aprovechamos la caché de Cloudflare lo que hace que el rendimiento de nuestra página y la experiencia de usuario mejore. Cómo hacerlo. 1. Lo primero que debemos hacer es activar Cloudflare. Nos registramos en ese servicio, damos de alta nuestra web y nos dirá los DNS que tenemos que poner en nuestro dominio. Después tenemos que ir al proveedor de nuestro dominio y cambiar los DNS. Apunta todos los registros de DNS que tienes para copiarlos en Cloudflare. Nota: si tienes el correo con tu proveedor, puede que tengas problemas al cambiar los DNS a otro proveedor. Consulta con ellos antes. Seguramente también se puede hacer todo esto sin cambiar los DNS a Cloudflare, pero explicamos la manera más sencilla. Una vez que hayas cambiado los DNS a Cloudflare ya podemos gestionar todo desde su panel. Tenemos que activar para nuestro dominio y para www.nuestrodominio el servicio de Cloudflare. Aseguraos que en el DNS tienen la nube en naranja, no en gris. Eso significa que pasa por sus sistemas. 2. Ya tenemos el que cualquier persona de fuera que escriba nuestro dominio irá por Cloudlfare. Ahora tenemos que asegurarnos que nuestro servidor no admita peticiones de ningún otra fuente. 2.1 Por IpTables. Para eso nos vamos a nuestro servidor (suponemos que es dedicado o Cloud). Tenemos que activar en iptables el filtro para que sólo acepte las IPs de Cloudflare. Tenemos siempre un listado actualizado de las mismas aquí. Cuidado: siempre que manejes un firewall corres riesgo. Asegúrate que pruebas todo antes de activarlo y que luego tienes una manera de retroceder. Si queremos hacer esto directamente por iptables podemos hacerlo de esta manera que sugiere Cloudflare.  Sin embargo ya hemos dicho que es más fácil realizar todas estas gestiones por programas como Firehol. En Firehol abrimos el fichero firehol.conf y después de los primeros comentarios añadimos las ips de cloudflare así (una por línea). Los puntos suspensivos indican que está el resto de ips: cloudfl_ips=”103.21.244.0/22 103.22.200.0/22 ….. “ Después, en la interfaz que esté conectada al exterior ponemos: server http accept src “$cloudfl_ips” server https accept src “$cloudfl_ips” Con esto graba el fichero y asegúrate de probar la configuración antes de reiniciar el servicio. 2.2 Por configuración del servidor web (Nginx en este caso). Podemos restringir las ips de Cloudflare en el servidor web. Hoy lo mostraremos en Nginx. Para ello creamos el fichero: etc/nginx/cloudflare-allow.conf  con un contenido como este: # https://www.cloudflare.com/ips # IPv4 allow 199.27.128.0/21; allow 173.245.48.0/20; allow 103.21.244.0/22; allow 103.22.200.0/22; allow 103.31.4.0/22; allow 141.101.64.0/18; allow 108.162.192.0/18; allow 190.93.240.0/20; allow 188.114.96.0/20; allow 197.234.240.0/22; allow 198.41.128.0/17; allow 162.158.0.0/15; # IPv6 allow 2400:cb00::/32; allow 2606:4700::/32; allow 2803:f800::/32; allow 2405:b500::/32; allow 2405:8100::/32; Después, en la carpeta sites-available (o sites-enabled), editamos el fichero de configuración de tu dominio y en el apartado server ponemos: include /etc/nginx/cloudflare-allow.conf; deny all; Y reiniciamos nginx. Esto debería restringir las ips a sólo las de Cloudflare y rechazar el resto. También se puede hacer así.

Seguridad, Servidores, Sistemas

IPTables y FireHOL: configurando el firewall en un equipo Linux

/

El kernel de Linux incluye un firewall muy potente, Iptables. Este programa está instalado en la mayoría de las distribuciones. Con él se pueden crear reglas de filtrado de paquetes desde muy sencillas a extremadamente complejas. De esta manera, el administrador de un equipo Linux tiene una herramienta muy poderosa para aumentar la seguridad de su sistema. Explicaremos de manera rápida la lógica de Iptables, y sus comandos básicos. Aunque hay que decir que configurar Iptables a mano es una tarea complicada, no es trivial. Además, a todos nos ha pasado, equivocarte en un comando en un cortafuegos puede llevar a que no puedas conectarte tu mismo a la máquina (ten siempre una acceso de seguridad para emergencias). Así que, más adelante, hablaremos sobre un programa que nos ayudará a configurar nuestro firewall. Conceptos de Iptables. Los paquetes puedes entrar (input), salir (output) o pasar (forward) por tu sistema. Las reglas se pueden hacer teniendo en cuenta: Protocolo del paquete (-p=protocol) . Por ejemplo Tcp, udp, icmp.. Origen del paquete (-s=source). Puede ser una ip o un rango de ips. Interfaz de entrada (-i=input) o de salida (-o=output). Por ejemplo eth0, eth1,ppp0… Por el tipo de paquete (input, output o forward). Podemos decir que hag Nateo antes de enrutar (iptables -t nat -P PREROUTING ACCEPT) o después de enrutar (iptables -t nat -P POSTROUTING ACCEPT) o ambos. Para ver las reglas que tenemos configuradas o activas en una tabla podemos hacer: iptables -L O si queremos algo organizado por servicio: iptables -S Con estos comando también podemos filtrar por tipo (Input, output, TCP), por ejemplo: sudo iptables -S TCP sudo iptables -L INPUT Para borrar todos los contadores podemos usar: iptables -Z  (podemos especificar por tipo). Para borrar todas las reglas: iptables -F  (podemos especificar por tipo). Cuidado que borra todo. Pero como decimos, configurar Iptables a mano puede ser complejo. Así que existen varias soluciones para ayudarte con ello. Hay GUIs (interfaces gráficos) como Firestarter, o programas como FireHOL, del que hablamos hoy. FireHOL es un lenguaje y un programa para ejecutarlo que, aunque no tiene asistente gráfico, nos ayuda mucho a configurar los Iptables. Consta de un fichero de configuración en /etc/firehol/firehol.conf  desde el que se configura todo. La sintaxis de FireHOL es sencilla y se basa en la idea típica de los cortafuegos “deniega todo y luego acepta sólo lo que quieres dejar pasar“. El uso es sencillo, puedes poner reglas como server (entrante) o client (saliente). Y definir tus propios servicios como: server_emule_ports=”tcp/4662,64397,7037,23213,25286 udp/4672″ client_emule_ports=”default” Y luego aceptarlos en el interfaz adecuado: server emule accept client emule accept   Una vez guardado el fichero no se activan las reglas hasta que hagas: /etc/init.d/firehol restart PERO recomiendo (y esto es una GRAN ventaja) probar primero la configuración antes de grabarla con firehol try Esto activa las nuevas reglas durante 30 segundos hasta que escribas la palabra commit. Si no lo haces (porque algo haya fallado) restaura el cortafuegos anterior (permitiéndote cambiar la configuración. Puedes ver más información aquí: https://firehol.org/guides/firehol-welcome/ https://firehol.org/documentation/#firehol http://firehol.org/tutorial/  

Diseño Web, Servidores, Sistemas

MySQL Workbench, el interfaz gráfico de Mysql para diseñar, administrar y gestionar bases de datos.

/

Cuando quieres gestionar bases de datos en servidores, bases de datos Mysql y SQL, la herramienta más común es PhPMyAdmin, de eso no hay duda. Sin embargo, existen alternativas muy interesantes que podemos tener que considerar en ciertas ocasiones. Hoy os hablamos de una de ellas: MySQL Workbench. En nuestro caso, usamos empezamos a usar esta GUI para bases de datos, porque necesitábamos conectarnos a servidores de base de datos que estaban muy restringidos en términos de seguridad. La conexión sólo se podía hacer por clave privada por ssh, y PhpMyAdmin no permitía esto (de manera sencilla al menos). MySQL Workbench es un gran interfaz gráfico para bases de datos SQL disponible para Windows, Linux y Mac OS X. Con esta sencilla pero potente herramienta, podemos realizar modelado de datos, desarrollo SQL, administrar servidores SQL, administrar usuarios, realizar copias de seguridad, migrar, monitorizar el rendimiento y mucho más. Si eres un administrador de servidores, y llevas varios servidores de bases de datos, te recomiendo que pruebes esta herramienta, porque te va a resultar sencillo, y muy visual, gestionar esos servidores. Además una de las grandes ventajas que tiene es que, al contrario que PhpMyAdmin, lo instalas en tu equipo en tu oficina y eso se conecta directamente con los servidores de bases de datos. No tienes que instalar nada en tu servidor, no necesitas servidores web ni tienes que dejar en el servidor programas que puedan conectarse a la base de datos y puedan ser puntos débiles de seguridad.    

Internet, Servidores, Sistemas, Soporte

VPN en Windows 10. Cómo crear un servidor de VPN en Windows

/

Si no sabes lo que es una VPN, deberías aprenderlo pronto. Porque, pronto deberíamos todos tener ordenadores y móviles conectados por VPN cuando estemos en Internet. Para una conexión de VPN necesitas: Un servidor de VPN que reciba las llamadas. Esto es lo que os enseñamos a hacer hoy en Windows 10. Abrir unos puertos en el router. En este caso el 1723 hacia la IP (fija) de tu servidor de VPN. Uno o varios clientes que hagan la llamada de VPN. Esto os enseñamos a hacerlo el próximo día. En caso de no tener IP fija en tu oficina/casa (donde esté el servidor) necesitaréis un servicio de IP dinámica y configurarlo en el router para que el cliente sepa dónde está tu servidor. En este vídeo os enseñamos a crear el servidor de VPN en Windows 10 (válido con pequeñas modificaciones en cualquier Windows), y abrir los puertos en el firewall del servidor Windows. Si recibes un error al crear la conexión entrante especificada en el vídeo, mira el artículo de mañana, porque ahí os explicaremos cómo resolverlo.  

Diseño Web, Gestores de contenidos, Servidores, Sistemas, Trucos

Modificar parámetros de php.ini en GoDaddy como max_input_vars, max_execution_time

/

GoDaddy es un hosting que nos encontramos en muchos clientes, porque es muy económico. Eso si, como pasa en muchos servidores compartidos, en cuanto les pides “algo más” , normalmente con gestores de contenidos como WordPress y Prestashop, empiezan a poner problemas. Una de las primeras cosas que necesitas para añadir funcionalidades extra es modificar los parámetros de php.ini como max_execution_time, max_input_vars , memory_limit etc. En cada hosting hay que cambiar esto de manera diferente, según su configuración, y no siempre se puede. Hoy os explicamos cómo hacerlo en GoDaddy. Manera sencilla. Muchos de los parámetros como max_execution_time o memory_limit se pueden cambiar desde el menú, con una opción que está algo escondida. Para ello tienes que entrar en tu CPanel, bajar hasta la parte donde pone Select Php Version y pinchar en esa opción. Puede que ahí tengas que cambiar la versión a 5.6 o superior. Arriba a la derecha tiene que poner Switch to Php Options, si no, cambia la versión. En los Php Options verás que te deja cambiar muchos parámetros. Si el tuyo está ahí, cámbialo y dale a Save. Recuerda que siempre puedes comprobar si está cambiado en tu servidor subiendo por FTP un phpinfo.php y llamándolo desde el navegador. Método algo más complicado. No todos los parámetros están en ese menú anterior. Por ejemplo max_input_vars, necesario para cambiar las traducciones de Prestashop, no está. Entonces tienes que seguir el siguiente método. Tienes que crear un fichero .user.ini en la raíz de tu hosting. Pero yo lo intenté subir por ftp y no sirvió por la codificación. Lo mejor es hacerlo desde el File Manager de tu panel de GoDaddy. Abre el File Manager, ve a la raíz de tu sitio, dale a crear un fichero (arriba a la izquierda) con codificación utf8, y llámalo .user.ini. Ese fichero tiene que empezar por {PHP} (a algunos les funciona sin eso) y luego los comandos que quieras. Por ejemplo: {PHP} max_input_vars = 10000 Salvalo y prueba. Cuidado que a veces la caché del navegador juega malas pasadas. Vuelve a comprobarlo con un phpinfo.php. Esperamos os ayude.

Servidores, Sistemas, Trucos

Truco para nginx: probar la configuración antes de reinciar

/

El 90% de nuestros clientes usan Apache tanto en sus servidores compartidos como en los dedicados. Pero alguno usa algún otro sistema como Nginx. Hoy os dejamos un truco muy sencillo…pero vital cuando estás gestionando páginas web en Nginx. En Apache, si haces un cambio en alguno de los virtual hosts, tienes que reiniciar el servicio y esperar que todo haya salido bien. Si no falla Apache y se caen todos los servicios web que dependan de ellas. Nginx tiene una gran diferencia aquí, que me parece excelente. Permite probar primero la configuración para ver si da errores, antes de reiniciar y cargarnos todo. De hecho , si falla, nos dice aproximadamente dónde está el fallo. Como además, para alguien que viene de Apache, Nginx es muy distinto y, en ocasiones, poco intuitivo, esta solución ya nos ha salvado más de una vez. Truco: Para probar una configuración hecha en tus sites-defaul o sites-enabled, tienes que poner en la línea de comandos: nginx -t Si falla, ve a la línea que indica el error y vuelve a modificarlo. Cuando dice que ok, ya puedes reiniciar el servicio con (o su equivalente en el S.O en el que estés):   service nginx restart

Scroll al inicio