Mis 10 Consejos para administrar servidores y no morir en el intento
Últimamente he estado un poco desaparecido, quizá algunos ya se habrán dado cuenta de esto, la razón es que me estoy enfocando en algunas cosas nuevas de la informática.
Como es conocido durante mis años en la universidad he estado trabajando bastante en la línea de GNU/Linux y administración de servidores (de hecho es lo que más he hecho junto con desarrollo web claro), ahora bien dentro de esta «reinvención» personal he decidido entre otras cosas dejar definitivamente la lìnea de administración de servidores (no así GNU/Linux) por lo que he pensado que sería una buena idea escribir un artículo con los principales consejos en base a experiencias que he aprendido hasta el momento en lo que a administración de servidores y GNU/Linux respecta. Los siguientes consejos los he aprendido a punta de porrazos y más de alguno que me conozca recordará porque he escrito algún consejo, casi todos en base a experiencias reales. Espero que a alguno que este comenzando le puedan servir.
1.- No borres, mueve: Es común borrar datos por error que mas tarde requerimos durante el proceso de mantención de un servidor, no borres, mueve; crea un directorio temporal en /tmp/mimantención y mueve allí los datos que deseas borrar pero borra el directorio al finalizar todo. Este simple consejo puede ahorrarte trabajo extra causado por los típicos errores que uno comete.
2.- Guarda los comandos que haz utilizado en un fichero de log: Yo lo llamo workbashlog en similitud al conocido changelog. Resulta una muy buena práctica que de a poco he ido implementando; trata simplemente de documentar no sólo el proceso sino que los comandos en terminal que utilizo para realizar los procesos de administración, existen varias buenas razones para hacer esto, sin embargo, quizá la más importante sea que con el tiempo aprendes a utilizar comandos cada vez más potentes, reducidos y sin causar daños colaterales. Si eres un poco flojo puedes incluso utilizar un comando que se llama «script» para automatizar la creación del workbashlog en un fichero de los comandos que ejecutas en terminal (como lo haría bash_history pero sin necesidad de cerrar sesión)
3.- Ser paranoico es tu obligación, no una elección, pero hay un límite: Sea el tipo de servidor que sea excepto cuando no sea uno en tu red local casera, siempre y ante todo debes esperar que alguien atacará tu servidor, esta es casi una regla de oro en lo que respecta a administración de servidores. Si dejas un servidor con la posibilidad de accesar por ssh como usuario root estas perdido; si dejas un servidor sin un firewall adecuado estas perdido; si dejas un servidor apache sin módulos de seguridad estas perdido, y así hay mil ejemplo de prácticas comunes en temas de seguridad que no se necesita ser hacker para utilizar. Los ataques por fuerza bruta desde servidores zombie son cosas de todos los días, creer que tu servidor no será atacado es convertirlo en un servidor zombie por lo bajo. Asegurar tu servidor hasta los extremos no debería porque interrumpir tu trabajo ó el de otros que utilicen el servicio, la regla aquí es prohibir todo aquello que no se use o no conozcas para que se usa y creer que quien lo usa (usuario de tu servidor) puede ser tu atacante, déjalo trabajar tranquilo pero elimina la probabilidad de que destruya tu servidor.
4.- Controla el acceso físico a la máquina: Esto tiene mucho que ver con el punto anterior, pero he querido recalcarlo, ambos (acceso físico y por software) son importantes, no sacas nada teniendo un servidor totalmente protegido a nivel de software con firewall espectaculares si el acceso físico a la máquina es cosa de niños. He tomado el control de servidores en forma física (con autorización claro) en minutos, tener acceso físico a un servidor es incluso peor que no utilizar contraseña para acceder vía ssh por ejemplo.
5.- Asegura tu trasero: Es común (quizá más de lo que se pueda creer) quedar colgado mientras se realizan operaciones en el servidor. Esto se refiere a perder el control de servidor sin haber establecido ningún tipo de seguro antes de esto, frases típicas para ejemplificar este caso son: «el firewall que he creado me ha cerrado el puerto de ssh y he quedado fuera», «la actualización de software me ha instalado un nuevo kernel que ha fallado al rearrancar la máquina», «mientras actualizaba datos en mi web me han robado la contraseña de la base de datos», «han interceptado mi comunicación sin cifrar y me han robado los datos». Recuerda siempre crear un seguro antes de realizar procesos críticos , visualiza 2 o tres jugadas a futuro como la harías si jugaras ajedrez (asegurarías a la reina o al rey antes de atacar). Algo muy básico como programar un cron de autoreinicio del servidor en un período de 45 minutos más antes de comenzar a realizar una tarea que sabes te tomará al menos de ese tiempo puede salvarte frente a problemas como cierre de puertos, etc.
6.- Nada de puertas traseras: Una mala práctica recurrente en administradores de servidores es crear puertas traseras para tomar el control a posteriori en caso de cualquier cosa del servidor. No recomiendo hacer esto por razones casi obvias, las puertas traseras pueden ser usadas por cualquiera. Borra ya ese pensamiento de tu mente y haz el trabajo de manera ética y profesional. Si tienes un revólver en casa puedes matar a un ladrón con el o el ladrón puede matarte a ti.
7.- No copies y pegues comandos que no conoces que hacen: Soy un convencido que la mayor parte de los problemas que acarrea un sistema pertenecen no a fallas del mismo sino a una mala operación, comúnmente a un desconocimiento de como se ha operado. Esto último ocurre más a menudo de lo que creemos, copiar y pegar comandos sin tener una mínima idea de que realizan es la peor de las prácticas que puedes realizar en GNU/Linux. A menudo no faltan los chistosos que en algún foro o blog de GNU/Linux publican comandos donde hay cosas como «rm -rf /» ó «yes > hola.txt» ocultos entre otros comandos y usuarios llorando que su sistema a petado por causa de ellos, almenos deberías tener una idea de que hace cierto comando antes de ejecutarlo màs aùn si lo haces como usuario root.
8.- Participa de la comunidad: Levantar un servidor con todas las medidas de seguridad disponibles hasta la fecha no basta, existe un período de tiempo realmente importante entre que una falla de seguridad ha sido detectada y el parche para la misma es liberado, durante todo este tiempo si tu servidor es afectado queda expuesto. Resulta importante participar de comunidades de seguridad (o listas de seguridad de la distribución de GNU/Linux que uses) esto es porque los fallos normalmente son avisados por listas de correo mucho antes que sean reparados, y las reparaciones de los mismos son también liberados por listas de correos mucho antes de que estos sean propagados por los repositorios de seguridad. Para estar preparado debes estar informado.
9.- Establece contraseñas complejas: Estoy casi seguro que este debe ser sino por poco el consejo más repetido en temas de seguridad, sin embargo pocos lo implementan. La razón normalmente es que nadie está dispuesto a memorizar millones de claves para temas de seguridad, sin embargo, existen soluciones a este problema: por nombrar algunas aplicaciones como Keepassx entre otras te permiten manejar contraseñas complejas con una clave única de desbloqueo, averigua sobre eso e impleméntalo.
10.- Utiliza un servicio de monitorio de servidores: Hoy en día existen muchísimos servicios de monitoreo de servidores gratuitos, que básicamente te avisan por correo cuando tu servidor ha caído o cierto servicio ha dejado de funcionar. Son realmente útiles.
Este fin de semana me tocó resolver uno de esos desagradables problemillas que aveces ocurren al intentar instalar aplicaciones, específicamente mi tortura fué la instalación de eXeLearning en su última versión sobre Ubuntu 10.04 y Ubuntu 9.04. Dado que al buscar información del problema me percaté que no está resuelto completamente aún en ninguna web pensé que sería bueno documentarlo por si a alguien le ocurre lo mismo, bueno aqui voy con la historia.
Los últimos avances de la ofimática que se
A pesar de esto, la curva de aprendizaje, las complicaciones en caso de errores, y los resultados obtenidos, pueden llegar a perjudicar a un novato, mientras que los resultados obtenidos no se alejan demasiado a los que puedas obtener utilizando OpenOffice en su última versión con algunas horas de uso y algo de talento artístico. Hoy por hoy el uso de plantillas y estilos gráficos es una realidad en los sistemas de edición tradicionales y un chiste para usuarios de softwares privativos como Microsoft Office 2010 (el cual tuve la oportunidad de probar en su versión beta gracias a la licencia que regaló Microsoft meses atrás). El nacimiento de aplicaciones sociales en la red para el procesamiento de documentos en equipos de trabajo (Microsoft Office 2010 cloud, Google Docs) pone de manifiesto uno de los problemas más conocidos y comunes para el mundo LaTeX, me refiero a la posibilidad de compartir un documento y ser editado fácilmente por el receptor, en síntesis escribir un documento en forma colaborativa. Esto último es un problema intrínseco en la filosofía de trabajo que sigue LateX (WYSIWYM: lo que ves es lo que quieres decir) a diferencia de la que sigue la mayoría de los editores gráficos (WYSIWYG: lo que ves es lo que obtienes), tomar un documento y comaprtirlo con alguien sin que este veo como se ve realmente el documento final sino sólo su contenido en si es algo que desespera al común de las personas.
Hace algunos días teníamos la necesidad de armar un servidor que usaría la placa madre DP55KG de intel, la cual según especificaciones del fabricante, podría soportar desde un procesador i5-650 en adelante, con socket 1156, y un montón de otras cosas, entre ellas una de las importantes es que cuenta con una controladora raid de 6 puertos sata, más 2 puertos sata adicionales.
