Releyendo el artículo sobre configurar logwatch noté un detalle importante: falta la configuración de postfix para que el mail de logwatch llegue a nuestra casilla.
En este caso voy a usar postfix conectado a una cuenta SMTP externa que envíe los emails (hice las pruebas con mailgun y sendgrid, ambas funcionaron OK).
Vamos con la configuración.
Navegando entre las ofertas de black friday de LowEndBox (muy recomendado si necesitan contratar servers baratos), encontré una muy buena oferta para ChicagoVPS, empresa de la cual tengo buenas referencias, por lo que decidí aprovecharla y contratar el server donde ahora está hosteado el sitio, para ir probando la performance. Igual aún mantengo otros sitios en Linode que, como comenté hace un tiempo, es una muy buena opción para servers de 5 USD.
Después del salto comento los desafíos que encontré al migrar el server.
Linux trae una gran herramienta para prevenir accesos no deseados: iptables. El problema con iptables es que no es tan sencilla de configurar (alguna vez me dejé sin acceso a mi propio server, jeje).
Por suerte existe uncomplicated firewall, o simplemente UFW, para que asegurar nuestro servidor sea realmente sencillo. Vamos al paso a paso:
En la entrada sobre como instalar el certificado SSL con Let's Encrypt usaba la versión del certbot del repo de ubuntu. Ahora hay una versión más reciente disponible, su instalación es simple y tiene algunas ventajas que nos van a ser útiles.
Hay un par de pasos extras a realizar, pero nada muy complejo. Vamos a verlo:
La manera más usual para conectarnos a un servidor Linux es usando ssh. Esto lo sabemos nosotros y también algún usuario malicioso. De hecho cuando recibo el email de logwatch encuentro cosas como esta:
sshd:
Authentication Failures:
root (58.218.198.151): 5245 Time(s)
root (116.31.116.28): 2060 Time(s)
root (59.45.175.67): 360 Time(s)
root (59.45.175.62): 274 Time(s)
root (221.194.47.252): 237 Time(s)
root (121.18.238.123): 226 Time(s)
root (121.18.238.119): 192 Time(s)
root (59.45.175.56): 186 Time(s)
root (221.194.44.240): 153 Time(s)
root (59.45.175.88): 141 Time(s)
root (59.45.175.66): 135 Time(s)Como ven, muchos intentos de ingresar al server, por lo que siempre es mejor agregarle una capa extra de seguridad a nuestro acceso.
Siempre es recomendable tener un sistema actualizado para evitar problemas con exploits conocidos (WannaCry, te hablo a vos!).
Una forma de hacer esto es entrar al servidor al menos un par de veces por semana y correr el update manualmente. Otra forma es usar unattended-upgrades y que las actualizaciones se hagan automáticamente.
Obviamente, yo opté por la segunda :D
Habrán visto que en su server todo es logueado (accessos por ssh, estadísticas de apache, actualizaciones, etc) pero se hace muy dificil, por no decir imposible, leer esos logs diariamente para asegurarnos que todo anda bien en nuestro sistema.
Por suerte existen herramientas como logwatch, que nos hacen un resumen de los logs del sistema y nos lo envían por email. Vamos a ver como lo dejamos configurado.
Como ya comenté en el pasado, para este sitio (y otros en el mismo server) estoy utilizando Apache para servir el PHP en el puerto 8080 y al frente un nginx como reverse proxy, que redirecciona las peticiones PHP al Apache y sirve los archivos estáticos, utilizando el prótocolo http2.
Entonces vamos a ver como configurar los vhosts en ambos servers para poder servir más de un sitio desde la misma VM.
Por lo general utilizo git para control de versión, y siempre es útil tener alguna forma de que el deploy al server se haga automáticamente una vez que los cambios son pusheados a master, en lugar de tener que conectarme al server, actualizar repo (git pull) y recién ahi ver los cambios (sobre todo si es más de un server el que hay que deployar).
Hay varias herramientas para lograr esto, desde las más completas de Integración Continua (Jenkins, Travis), hasta otras más específicas (por ejemplo Magallanes, para PHP) pero hoy me voy a enfocar en una solución no tan "empresarial" sino algo más simple, usando solamente git. Es bastante sencillo de setear y la idea es hacer un push desde nuestro entorno de desarrollo y que el contenido impacte en el server.
Siempre nos interesa (o nos debería interesar) que nuestro sitio esté disponible todo el tiempo posible. Una gran opción para monitorear la disponibilidad es Uptime Robot.
Este servicio tiene varias cosas muy buenas, que vamos a analizar en detalle hoy: es gratis hasta para 50 monitores, permite monitorear http(s), ping, un puerto específico y hasta por keyword, integración con email, slack y SMS.