En la actualidad hay una gran oferta de servidores para utilizar en nuestras aplicaciones. Y, tenemos la posibilidad de contratar servidores muy potentes por relativamente poco dinero. Una de las posibilidades que tenemos es contratar un VPS (Servidor Privado Virtual) En el mercado encontramos servicios administrados, en los que tendremos directamente un panel de control, un servidor instalado con ciertas características, y ya se encargan por nosotros de actualizar, instalar software y tener al día la seguridad. Estos servidores tienen configuraciones rígidas, puede que no se ajusten 100% a tus necesidades. Por otro lado, saldrán algo más caros (ya que te ahorran trabajo, el panel de control puede que sea privativo y tengas que pagar licencia) y pueden ser algo más lentos (ya que todo el software que viene instalado consume recursos).
Mi caso personal
Hace años decidí montar mi blog y algunas páginas más en un VPS. En estos tiempos son relativamente baratos y rápidos de contratar e instalar. Sale incluso mejor que tener una máquina enchufada en tu casa las 24h. Estos servidores suelen cumplir ciertas normativas de seguridad física y ambiental, contar con fuentes de alimentación de respaldo, en ocasiones discos duros en RAID y una conexión a Internet muy rápida. De todas formas, esta guía podrás utilizarla para montarte un servidor en casa si lo prefieres.
Por otro lado, tenemos una ventaja añadida y a la vez un inconveniente con respecto a la contratación de un hospedaje normal y corriente: tú tienes el control sobre el software del servidor. ¿Y eso qué quiere decir? Que si hay algún problema la culpa es tuya y solo tuya. Bueno, un problema puede tener muchas causas, puede haber un fallo de hardware, puede inundarse o incendiarse el centro de datos donde está tu servidor, pero casi siempre los problemas suelen suceder por tener cosas abiertas o mal configuradas, y me ha pasado con hostings de todo tipo.
En definitiva, hemos decidido montar nuestro servidor desde cero, así podremos instalar los servicios que queramos (recordemos, cuantas menos cosas tengamos, menos puntos de ruptura), queremos controlar al 100% nuestra infraestructura, o automatizarla si tenemos muchos servidores, y, ¿por qué no? Cuando decides instalar tu propio servidor, aprendes un montón, tanto del sistema operativo, programas que utilizas, protocolos, seguridad, scripting... y quiero compartir mi aventura con todos vosotros.
Mi lista de control
Así decidí crear una lista de control o checklist en la que marco algunas tareas básicas que debemos llevar a cabo cuando instalamos nuestro servidor desde cero. Antes de nada debo decir que esta lista no es rígida. Depende de las necesidades de cada uno de nosotros, del objetivo del servidor que vamos a montar. Si bien es cierto que hay tareas que recomiendo que se realicen siempre, en nuestro caso puede no ser necesario. Por ejemplo, establecer reglas robustas para un firewall no será necesario si ya hemos dedicado una máquina a esa función.
Antes de nada, comentar que esta lista corresponde con un servidor de propósito general: Web, lenguaje de servidor (PHP, Ruby, NodeJs...), correo, y como mucho, algunos extras. Aunque, como siempre, intentaré utilizar siempre que sea posible software libre, aunque también es cierto que hay sitios en los que, en ocasiones no podemos mandar, como sucede en el software utilizado en el centro de datos, o el hypervisor en caso de configuración de VPS.
Atención: Este checklist utiliza cookies para guardar tu configuración. Para que puedas llevar el control de tus tareas a través de esta web. En ningún momento me quedo yo con información. Las cookies no se generan hasta que no haces click en una opción.
Planificación
Instalación y configuración de servicios
Instalación del S.O. (si es un VPS ya tendremos instalada un SO)
Acceder por SSH y crear un usuario administrador (no usar root, admin, administrator...)
Actualizar el sistema (siempre hay algo que actualizar y queremos empezar con buen pie)
Instalación de servidor web y lenguajes de servidor (NodeJS, PHP, Ruby, Python...)
Base de datos: instalación (aunque podemos dejarlo solo en otra máquina)
Base de datos: configuración y optimización (como antes, tenemos que ajustar los parámetros para adaptarlos a nuestro servidor)
Servidor de correo: envío y recepción (instalación y configuración de paquetes)
Servidor de correo: usuarios (crear políticas de usuarios y dominios a los que atenderemos)
Servidor de correo: filtros de servidor
Servidor de correo: Anti Spam
Servidor de correo: Antivirus
Servidor de correo: Webmail y utilidades (autorespondedores, cambios de contraseñas, aprendizaje de SPAM...)
Opción: FTP ¿Quién quiere FTP hoy en día? Seguro que a mucha gente le resulta útil
Opción: Sistemas de archivos distribuidos. Para replicación de datos en varias máquinas o la obtención de almacenamiento más grande
Opción: Enchufar y montar discos duros adicionales
Mantenimiento y auditoría
Gestión de servicios
Cambios en DNS
Tests de intrusión externa, pruebas de penetración
Inventario de hosts
Políticas de actuación frente a mensajes de abuso
Comprobación de reputación de IP
Cruzar los dedos (y rezar para que todo funcione) - Ya podrá entrar todo el mundo en nuestro servidor
Como he dicho antes, quiero dedicar varios posts a esto, por lo que iré explicando uno a uno todos los puntos. Proponiendo software, alternativas y comentando todos aquellos detalles que he ido encontrando en mi camino. Debo aclarar que todo esto corresponde a un servidor para uso personal, o de pequeña empresa. Esta pequeña infraestructura puede complicarse con la entrada de nuevas necesidades de rendimiento y escalabilidad. Incluso una configuración que podemos configurar en una sola máquina, podríamos hacerlo dividido en varios servidores interconectados, todo dependerá de nuestros cuellos de botella y el nivel de disponibilidad del servicio.
Aclaraciones
Tener claro qué necesitamos
¿Alojaremos sólo una web? ¿Cuántas visitas tendrá? ¿La programación de la web requiere mucha CPU/RAM? En definitiva, no es lo mismo alojar un WordPress con menos de 1000 visitas al día que alojar 40 webs diferentes en nuestro servidor. Dependiendo de nuestras necesidades, podremos conformarnos con 1Gb de RAM, un sólo núcleo de CPU y unos 20Gb de disco duro, o puede que necesitemos interconectar varios servidores más potentes. Cómo los conectemos y a qué dediquemos cada uno ya es cuestión de creatividad.
Aunque tenemos que tener también presente nuestro presupuesto. No es lo mismo que entre una gran empresa que para este propósito se puede gastar unos 200€/mes que un blogger que va a empezar y no pueda gastarse más de 10€/mes. Si el blogger tiene éxito siempre podrá ir ampliando lo que tiene progresivamente, aunque le toque trabajar mucho haciendo cambios.
¿Necesitas una IP española? O al menos, europea. Esto es importante tenerlo en cuenta. Además, si vamos a ofrecer un servicio, y pensamos cobrar por él, tendremos que hacer pruebas de conexión al centro de datos de nuestro proveedor, mirar webs que estén alojadas allí y ver cómo se comportan.
Contratar VPS o montar ordenador
Todo esto lo podremos poner en práctica en un ordenador antiguo (o nuevo) en nuestra casa, en una máquina virtual en nuestro ordenador para hacer pruebas, en un VPS que contratemos... No recomendaría hacer esto en un servidor dedicado, siempre es bueno tener un plan B cuando las cosas fallen (y pueden fallar en cualquier momento). Me refiero a que si es un ordenador en nuestra casa, si todo el sistema se cuelga, o nos atacan, podemos desconectar la red en cualquier momento, o desenchufarlo, o darle al reset si hay un fallo de software irrecuperable. Si tenemos un servidor dedicado, es recomendable lanzar máquinas virtuales para lanzar nuestros servicios. Es más probable que falle una máquina virtual que el hypervisor, y tendremos algo de control. Si contratamos un servidor dedicado, en 2017, tendremos en nuestras manos una máquina muy potente (un dual core con 2Gb de RAM no nos saldría rentable, para eso, contratamos un VPS). También tenemos que informarnos muy bien de lo que se nos ofrece, muchos proveedores venden VPS como dedicados o se inventan alguna palabrería extraña.
No está de más leer los contratos de nuestro proveedor, ver qué seguridad física utiliza el centro de datos, control del clima, respaldo de energía, etc. Sobre todo si nosotros vendemos un servicio, nuestros clientes se sentirán más seguros si nuestro proveedor es de confianza. Y si nuestros clientes o usuarios dejan datos personales en nuestra web, las medidas de seguridad física, control de visitas o enjaulado de las máquinas pueden ser muy útiles (aunque físicamente nunca vayamos a comprobarlo).
Establecer política de acceso remoto
Empezamos con lo que realmente importa, ¿quién va a entrar en nuestra máquina?¿cómo va a hacerlo?¿con qué privilegios? Está claro que cuanta menos gente tenga permitido entrar mejor. Debemos determinar si nuestro acceso web es público o privado, si damos servicio de correo, si se podrán subir archivos por FTP y si tendremos usuarios por SSH, y qué nivel de seguridad necesitamos para cada servicio. ¿Nos fiamos de los que van a administrar el servidor?
Configuración de seguridad SSH
Las configuraciones por defecto de seguridad no suelen ser buenas, por lo que tendremos que mejorar mucho esto. Para ello, puedes leer este post: Consejos para endurecer un servidor SSH y hacerlo más seguro.
Eso sí, aunque vayas a montar un servidor para experimentar, asegúrate de configurarlo bien y no dejar una entra fácil, puesto que los atacantes pueden aprovechar cualquier recoveco para entrar.
Configuración básica de nuestro servidor
Aquí haremos tareas como:
- Cambiar el hostname, y poner un FQDN válido. Normalmente, si accedemos por un dominio o subdominio, el hostname debe coincidir, al menos el hostname principal, o una identificación de nuestro servidor, como por ejemplo: servidor-web-principal.midominio.com; esto puede ser importante en el futuro.
- Ajustar zona horaria del sistema
- Ajustar localización o idiomas del sistema. Locales. Esto nos quitará problemas cuando entremos por SSH.
- Sincronización horaria por NTP
- Swap, discos RAM, etc
- Configuración del comportamiento del terminal (a mí me encantan Av-pag y Re-pag al estilo Gentoo).
- Editor de texto por defecto (¿eres de vi? ¿de nano? ¿joe? ¿prefieres Emacs?)
- Cualquier otra cosa pequeña y rápida que se nos ocurra
Reglas de Firewall
Dependiendo de nuestro sistema, interfaces de red, existencia o no de una red privada o tipo de conexión con el exterior, necesitaremos establecer unas reglas básicas. Es conveniente tener sólo abiertos los puertos que necesitemos. Si se trata de un servidor web, el puerto 80 (y el 443 para HTTPS), si es un servidor de correo, 25, 110, 143, etc (dependiendo de los servicios que corremos en ese servidor).
Eso sí, dado el creciente número de servicios que podemos tener en nuestro servidor, muchos de ellos privados, puede que tengamos puertos abiertos en nuestra máquina que no nos interese que sean accedidos desde fuera: MySQL, Redis, NodeJs, monitorización, inventariado, antispam, etc. Todos esos puertos deben estar cerrados hacia el exterior.
También es conveniente, para nuestra protección un sistema que nos permita hacer listas negras y blancas de IPs con el objetivo de bloquear manual o automáticamente aquellas IPs que nos ataquen.
Puede darse el caso de tener una red privada a la que tengan acceso otros VPS dentro de la misma red (máquinas virtuales dentro del mismo host, por ejemplo). Así que debemos restringir el acceso a nuestro servidor a máquinas privadas desconocidas.
Sistema de detección de intrusos
Un sistema de detección de intrusos o IDS (Intrusion Detection System) suele interceptar el tráfico de red, analizarlo y detectar qué cosas tienen pinta de ataques. Muchos de estos ataques suelen manipular los paquetes de red de forma que el software destino de estos (nuestros servicios) tienen un comportamiento no deseado. Estos servicios pueden caerse, dejar de responder o incluso dar privilegios a personas que no tienen que tenerlos.
Este software suele funcionar junto al firewall, incluso existen sistemas automáticos que cuando detectan que un atacante está intentando hacer accesos inválidos al servidor, le dicen al firewall que bloquee la IP atacante durante un tiempo o de forma permanente. Esto se suele llamar IPS (Intrusion Prevention System).
Endurecimiento y optimizacioń de servidor web
Debemos asegurarnos de que nuestra configuración es óptima para nuestra máquina. En la medida de lo posible, no vamos a atender a más clientes de los que podemos. Por otro lado no vamos a limitar los clientes a los que atendemos de forma que nuestra máquina ande demasiado sobrada y todavía pudiéramos atender más. Debemos configurar bien el tema de los Timeouts, hay aplicaciones que tardan mucho y tenemos que subir este valor, pero me gusta dejarlo lo más pequeño posible.
Por otro lado, debemos revelar la menor cantidad de información posible de nuestro servidor. Aunque queda muy bien decir la versión que utilizamos, eso puede ser un buen punto de partida para un ataque.
Además, debemos bloquear el acceso del servidor a directorios donde no deba acceder (restringir /, /home/, /etc/ por si las moscas). Bloquear directorios .svn, .git, algún directorio de contraseñas o datos privados, archivos de configuración (aunque sean scripts PHP...). Es muy buena idea configurar módulos de seguridad para nuestro servidor web. Por ejemplo, tanto en Apache, como Nginx, tenemos ModSecurity, muy completo y rápido.
Asimismo, en el lado de los lenguajes, es muy buena idea bloquear en la medida de lo posible llamadas a ciertas funciones. En PHP, tenemos exec, eval, system, funciones relacionadas con los procesos, etc. Debemos evaluar qué uso le damos al servidor, y en qué medida controlamos lo que se ejecuta en él.
Antivirus. Estás leyendo bien, para GNU/Linux
Aunque nos encontremos en GNU/Linux, y para un usuario de a pie no tenga mucho sentido utilizar un antivirus. En el mundo de los servidores no es tan cierto. Estoy de acuerdo en que si el servidor es privado, sólo tienen permiso de entrada personas de confianza, no hemos configurado correo electrónico y no utilizamos programación de lenguajes de servidor (PHP, Ruby, NodeJS...) no tiene sentido utilizar un antivirus. Podemos ahorrar esa memoria y CPU que nos quita este software. Como en Windows, un programa antivirus puede llegar a consumir muchos recursos, muy valiosos, sobre todo si nuestro presupuesto es limitado.
Pero si utilizamos WordPress, Joomla, Drupal, o scripts en NodeJs. Todo cambia, nuestro servidor puede ejecutar código y este código puede contener muchas vulnerabilidades. Es cierto que, sobre todo en scripts conocidos, las vulnerabilidades se corrigen muy rápido, pero siempre tenemos los zero-day que pueden ser explotados y pueden echar al traste nuestro trabajo en el servidor, nuestros proyectos, hobbies o fuentes de ingresos. Lo digo porque no es la primera vez que un script permite subir un archivo, éste se ejecuta y, aunque el usuario afectado sólo sea el correspondiente en nuestro servidor web, puede hacer mucho daño, puede poner a enviar correos a todo el mundo sin control, o puede hacer que nuestro servidor sirva como fuente de spoofing a usuarios de bancos y meternos en un lío. No tengáis miedo, estos líos no suelen ser muy graves (si tomas medidas rápido), pero puedes tirarte un tiempo sin servicio, cosa que en Internet es muy mala.
Lo dicho, más vale prevenir. Si además del antivirus, intentas buscar malware en tu servidor a menudo, no está de más.
Copias de seguridad
Otra de las asignaturas pendientes del 50% de las personas. Poca gente hace copias de seguridad de sus servidores. A pesar de ser muy importante, da una pereza horrible y nos obliga a contratar más espacio de almacenamiento. Por lo que termina siendo más caro. Muchos proveedores nos ofrecen un servicio de copias de seguridad, o acceso a discos duros para ello, si tenemos la posibilidad de utilizar discos magnéticos en este mundo de SSD, nos va a salir más barato.
De todas formas, si el servidor lo vamos a utilizar a modo personal, siempre podemos realizar dichas copias en nuestro ordenador de casa, creeando un script que se lance a diario y se lo baje. Si es para nuestra empresa, podemos hacerlo en un ordenador físico de la empresa, pero no estaría de más hacerlo también en un servidor aparte (incluso mejor si dispones de un servidor en un proveedor diferente, nunca se sabe cuándo va a caer un rayo o un volcán entrar en erupción.
Lo que tenemos que tener claro es ¿de qué vamos a hacer copia de seguridad? Aquí viene mi pequeña lista:
- Archivos de configuración del servidor: elegir lo que necesitamos dentro de /etc/, de los diferentes programas y scripts que lanzamos en nuestro ordenador, de los crontab de los diferentes usuarios y los archivos de configuración de nuestras páginas web.
- Código web: muchos utilizamos git/svn/cvs para llegar el código de las webs, y puede que no sea necesario hacer una copia de seguridad diaria de esto, pero no está de más hacer una al mes, sobre todo porque seguramente a la hora de restaurar el servicio todo sea más rápido.
- Ficheros subidos en nuestras webs: Los uploads de los usuarios no deben formar parte del código de la web, por lo que debemos hacer backup por serparado de éstos.
- Base de datos.
- Usuarios de la base de datos. Son los grandes olvidados, pero cuando tienes muchas aplicaciones instaladas, y cada una tiene su usuario, restaurarlos todos es horrible.
- Correo. Los usuarios de nuestro sistema no tienen culpa de que haya pasado algo en el servidor, y deberíamos restaurarles sus correos, preferencias, información personal...
- Scripts propios. Aunque no es algo primordial, pero muchas veces estos scripts se encuentran... bueno, en realidad no sabemos dónde se encuentran, la experiencia me dice que los haces una vez, y se les pierde la pista, así que, mejor tenerlos a mano.
Dichas copias de seguridad, deberíamos hacerlas con la mayor frecuencia posible. Pero eso puede resultar contraproducente, ocuparía mucho sitio, tendría nuestro servidor todo el rato leyendo y escribiendo y todo se resentiría, por lo que podemos programar esas tareas a una periodicidad más lógica. En mi caso personal, prefiero que el código de la web y los scripts se copien una vez al mes (puede que haya casos en los que no es posible), todo lo demás prefiero copiarlo a diario, a una hora más o menos intempestiva, que no suela haber nadie en la web, ni mis usuarios estén consultando el correo ni nada, me gusta hacerlo a las 4:30 AM, aunque me visitan a esa hora, la carga que tiene el servidor en esa franja es mínima.
Como característica especial, cabe decir que la prioridad de la tarea de copia de seguridad suele ser más baja (tanto en disco como en CPU), me da igual lo que tarde (dentro de lo normal). Normalmente mis copias de seguridad terminan a las 5:30, una hora haciendo copias de todo, que no está mal. Eso sí, para ahorrar en disco y recursos, suelo hacer las copias de seguridad de manera incremental. Un día a la semana, hago una copia de seguridad completa de todo, absolutamente todos los archivos, pero los demás días, sólo copio los cambios producidos en esos archivos. Lo malo es que, imaginando que los martes hago una copia completa, si necesito restaurar un lunes, debería restaurar copias a partir del martes anterior, lo bueno es que al ocupar poco, puedo almacenar copias de al menos un par de semanas en el tiempo y puedo volver atrás.
Otro factor importante de las copias de seguridad es el cifrado. Tengamos información confidencial o no, recomiendo siempre cifrar estas copias, la CPU hoy en día es barata, la RAM también y el coste de cifrarlas no es tan grande. Pero nos dará seguridad y dormiremos más tranquilos, sobre todo si tenemos que copiar por red dichas copias de seguridad, nos las traemos a nuestro ordenador o hemos contratado un servicio de almacenaje de copias de seguridad externo. ¡Ah, se me olvidaba! Siempre que vayáis a pasar por red los archivos de copia de seguridad, calculad el hash MD5 o SHA2 del archivos en origen y destino y comparadlo, la comunicación de red no es perfecta y a veces falla. Hacer esto me ha salvado la vida alguna vez.
Monitorización y estado de salud
Es algo muy importante, saber cómo se está portando nuestro servidor en cada momento. Si tienes un servidor muy modesto pensarás: voy a gastar más recursos monitorizando que sirviendo. Aunque hoy en día existen monitores muy buenos, y que consumen pocos recursos, los hay complicadísimos y que pueden hacernos el café con leche por las mañanas.
Pero debes instalar uno, nos puede dar una idea de nuestros cuellos de botella, de cuándo debemos ampliar el servidor, o de cuándo estamos pagando de más, decirnos si nos han atacado o hemos dejado de responder. Es información demasiado importante como para dejarla estar. Nos puede ayudar a solucionar o prevenir errores, incluso ver si tenemos algún servicio roto. O lo más sencillo del mundo, nos estamos quedando sin espacio en disco.
Muchos de estos programas permiten configurar alertas ya que, estas pantallas pueden ser caleidoscópicas, dejarnos obnubilados mirándolas sabiendo que todo va bien. Pero los problemas pueden venir en cualquier momento y estos programas pueden avisarnos por e-mail, por móvil, o como queramos. También podríamos tener cierta capacidad de decisión: desactivar temporalmente servicios, bloquear temporalmente países enteros, prohibir la subida de ficheros hasta que un adminsitrador vuelva...
Perros guardianes (watchdogs)
De la mano de los monitores, están los perros guardianes. Una tecnología que lleva años entre nosotros y se utiliza en muchos ámbitos del hardware/software. El ejemplo más claro son los dispositivos empotrados que disponen de una CPU pequeña o un microcontrolador. Cualquier cosa puede ir mal, entonces tienen un dispositivo de hombre muerto (DM, Dead man, HM, hombre muerto). Tal y como pasa a los conductores de ferrocarriles que tienen que pulsar un pedal o accionar un dispositivo cada cierto tiempo indicando que siguen vivos. Los procesos de nuestro sistema pueden hacer lo mismo. Indicar que siguen en pie y funcionando. Los dispositivos empotrados tienen un circuito que automáticamente hace un reset cuando el programa que está corriendo no envía una señal en un intervalo de tiempo determinado.
Un proceso informático puede pasar por muchos estados, y puede que, aunque el proceso esté en memoria no esté funcionando bien. Lo que podemos hacer, en primera instancia es saber si el proceso está en memoria (con ps lo sacamos fácilmente), si no está en memoria pueden haberse dado muchas causas, aunque lo primero es mirar en dmesg y en los logs de ese mismo programa. Seguramente haya sido que el mismo Sistema Operativo ha creído seguro cargarse ese programa ( OOM Kill) o tal vez el programa tenga un bug, o haya realizado una operación no válida.
Pero en ocasiones, los procesos que se mueren pueden ser los procesos de base de datos, o servidor web, y eso no es bueno, por lo que deberíamos avisar al administrador, pero volver a levantarlo automáticamente para no dejar sin servicio la web. Si tenemos un sistema complejo, podríamos levantar un servidor de respaldo levantar nuestra web con funciones reducidas (menos interacción con el usuario implica algo más de seguridad).
Control de logs
Son ficheros que de lo grandes que son, no los miramos casi nunca. Lugares donde hay más paja que cosas realmente interesantes, y muchas veces están desactivados, no se tienen en cuenta, se borran sin mirar... pero es un gran error. Bien utilizados pueden ser una herramienta de lo más útil.
En estos ficheros se escribe todo lo que nos sucede. Cada usuario que entra a nuestra web, fallos en nuestros scripts, consultas de base de datos, accesos FTP, SSH, tareas cron, los e-mails que llegan a nuestro sistema, estado de ejecución de tareas, fallos de segmentación, problemas con la memoria o los discos, y mucho más.
Sólo tenemos que tener un buen sistema de gestión que detecte las cosas interesantes, y nos deje sólo con las cosas que consideramos útiles. Además, si nuestro servidor está muy transitado, estos archivos ocuparán mucho, y en ocasiones, por contrato, legislación o compromisos varios nos vemos obligados a almacenar dichos logs durante un tiempo, 2 años es típico. 2 años es mucha información y ocupa muchísimo espacio, afortunadamente los logs se pueden comprimir mucho, ya que son texto plano y en ocasiones muy repetitivo. Pero nunca viene mal tener un sistema centralizado de gestión y análisos. Hay empresas que llegan a tener clusters completos para gestionar los logs de sus ordenadores.
Gestion de información y eventos de seguridad: SIEM
De la mano de la gestión de logs, podemos tener un software que detecte cosas interesantes y tome decisiones. Este software puede estar en el mismo servidor o en otra máquina aparte, a la que periódicamente conectaremos para informar de eventos, por lo que es muy importante el cifrado en estos datos. A los SIEM, no les debe llegar información sensible de usuarios, pero sí de procesos, por lo que si no protegemos esta información puede ser un buen punto de partida para un ataque.
Auditoría interna
¿Qué están haciendo mis procesos? ¿Qué archivos modifican? Pero aún voy más lejos, hay varios usuarios que tienen acceso SSH o FTP a mis sistemas y espero que no estén haciendo lo que no deben. Está feo quitarle el acceso a los usuarios, y es buena política restringir lo más posible los permisos sobre el servidor. Pero hay veces que es inevitable. Aunque, deberíamos poder saber lo que están haciendo, si un empleado de mi sistema ha extraído una copia de seguridad de la base de datos principal, deberíamos poder preguntarle para qué la quiere, así le disuadimos de utilizarla fuera y sacar información de nuestra empresa, sabiendo que lo sabemos. Si se han borrado ciertos archivos o ha sucedido un desastre en nuestro sistema, así podríamos saber qué lo ha provocado... ¡La información es poder! Aunque consume mucho disco y CPU.
Monitorización externa
Hasta ahora tenemos una visión de lo que pasa dentro de nuestro servidor. Pero, una persona desde fuera, ¿tiene acceso a mi web? Puede que en ocasiones nuestro servicio esté saturado y tarde mucho en responder, puede haber problemas en la DNS, o que no esté disponible en diferentes partes del mundo debido a problemas de red. Tener un control de todo esto también es muy interesante y nos ayuda a conocer si estamos online y si hay puntos en los que podemos mejorar.
¿Y tu lista?
¿Echas en falta alguna tarea necesaria? ¿Hay algo que no harías nunca en tu servidor? Déjame un comentario
Foto principal: Glenn Carstens-Peters
Puzzle Bobble
Karate Blazers
Puzzle De Bloques
Magical Cat Adventure