Hace unos días, en otro post contestando a Aj, comenté que iba a hablar sobre el tema. Intentaré ser lo más objetivo posible y lo que aquí os diga, tomadlo únicamente como una opinión personal, fruto del uso de estas soluciones durante un tiempo, para acabar dejándolas de lado.

Quizás alguno piensa que el título o «titular» es un poco alarmista, pero os aseguro que igual me quedo corto viendo lo que se ve por ahí.

La cuestión es simple, imaginad un sitio web que tiene unas necesidades de expansión grandes y decide contratar un servidor dedicado. Dentro de los planes de alojamiento habituales, esta es la opción más potente y cara dicho sea de paso, una máquina enterita para ti, con toda su capacidad y también, con sus problemas…

Por debajo de esta opción, está el llamado «servidor virtual» donde te aseguran (es muy fácil decirlo) un mínimo de memoria RAM o CPU de la máquina que compartes (también acceso por ssh como root, etc, etc).

En una escala inferior, (la más común) se encuentra el típico alojamiento compartido, donde puedes llegar a convivir en el mismo servidor con otros cientos de webs, pero que tampoco necesariamente tiene que funcionar mal si está bien controlado.

Hasta aquí, creo que todos entienden más o menos las diferencias, ahora pasemos a hablar del porqué de mi afirmación de «servidores en peligro».

En este caso, tengo que pasarle la mayor parte de la responsabilidad a los proveedores de alojamiento, no voy a acusarles de publicidad engañosa pero para ser políticamente correcto (que no lo suelo ser -;), lo dejaré en un «es un cuasi-engaño«.

El cliente, leyendo frases como esta, piensa que es como el nirvana aplicado a la web;

«Podrá usted mantener su sistema actualizado y siempre a punto de un modo totalmente gráfico y sin necesidad de aprender complicados comandos de administración remota».

Y UNA MIERDA !! con perdón xD. Si alguno se piensa que con una solución tipo Plesk, cPanel, etc, va a administrar un servidor web que dios le pille confesado -;).

Algunos casos de las «bondades» de Plesk que podéis leer, este que os pongo es de una búsqueda rápida en Google.

Plesk utiliza el estandar en seguridad adoptado por los servidores UNIX (security model). Este modelo ha sido probado en cientos de miles de servidores UNIX de todo el muno y ha demos- trado su altisimo nivel de seguridad. Al mismo tiempo, Plesk ha sido desarrollado para preservar la flexibilidad de los administadores de sistemas UNIX que necesitan un total control sobre sus servidores..

No he visto a un Plesk activar y controlar la caché de MySQL, compilar Apache con un módulo determinado, parchear un Kernel o hacer rular DenyHosts, esto va por lo de «total control«…

Aquí algo de información sobre cPanel que es parecido a Plesk en la gestión y uso de las opciones con las que cuenta.

Vamos a ver, con un software como los que he citado (que hay más), tu puedes; crear cuentas de correo, administrar cuotas de disco, crear usuarios FTP, añadir dominios, reiniciar servicios, hacer backups, instalar algo de software, etc, etc. (Ver Demos al final del post).

Por supuesto nada que no se pueda realizar desde un línea de comandos Unix GNU/Linux. La ventaja del uso de alguna de estas soluciones es que accedes a través de una interfaz web donde, a golpe de ratón y de un modo muy sencillo, controlas varios aspectos del servidor web.

¿Qué es lo que no se dice? lo que no se dice es que puedes administrar PARTES de un servidor web con cPanel o Plesk, pero es imprescindible que además lo hagas del modo «tradicional», linea de comandos ssh y teclear comandos y más comandos.

Aunque también os digo que simplemente ejecutando regularmente apt-get, los riesgos, aún faltando otras muchas cosas por hacer, serían mucho menores (siempre, repito, sabiendo lo que se hace que apt-get es una pasada pero puedes «pasarte-;).

Imagino que es más comercial no decir nada sobre el asunto y poner la consabida cláusula del tipo;

«En el momento de la entrega del servidor, la máquina queda bajo su entera y total responsabilidad».

Menuda frase…

Creo que sería más adecuado algo así como;

«Le avisamos que aunque usted puede administrar muchos aspectos del servidor web, es necesario realizar otras tareas de mantenimiento tales como actualizar el sistema base así como el resto de servicios regularmente».

Cosa que por otro lado, les devengaría más beneficios en concepto de mantenimiento así como una percepción de mayor servicio por parte del cliente.

No quiero demonizar a sistemas como cPanel o Plesk, pero si puedo decir que es un lío a veces saber que cosas dependen del propio sistema y que controlan los citados paneles, por momentos puede ser un verdadero infierno a veces entrar por ssh e intentar relanzar un servicio de un modo «tradicional» y ver como «casca» todo al depender de uno de estos añadidos.

Pero a ver como se come en un server con Plesk que el password por defecto del admin de MySQL es el del admin del Plesk…Eso hay que sufrirlo -;).

Pero el debate no es ese, particularmente y como «ex» usuario de Plesk, os diré que aunque cueste, es mucho más limpio para el sistema y su administración hacerlo todo a «callo», vale que es difícil y un frontend (yo me quedaría caso de usarlo con webmin por citar uno) facilita las cosas pero no es la solución definitiva.

Fijaros como será, que llevo mucho tiempo estudiando por mi cuenta y tragándome unos tochos de libros que para que os voy a contar y todavía a día de hoy me atasco con algun tema, gracias sobre todo a la ayuda de un buen amigo, he comenzado a entender como se administra un servidor web, usando en los que mantengo actualmente Debian GNU/Linux.

Además, estos servidores normalmente se entregan con un montón de servicios corriendo que no son necesarios, algunos potencialmente peligrosos para el sistema.

Tampoco (que creo que no cuesta tanto), ocultan las versiones del FTP, DNS, Apache o MySQL de turno, con lo que el cliente, confiado en que con su Plesk o cPanel ya es suficiente, va dejando obsoletas las aplicaciones instaladas y por desconocimiento, no sabe tampoco que con un escaneo mediante nmap muy simple, todos los puertos en uso así como las versiones de los mismos quedarán expuestos.

Un ejemplo de como puede ser el tema;

PORT STATE SERVICE VERSION
21/tcp open ftp ProFTPD 1.3.0
22/tcp open ssh OpenSSH 4.2 (protocol 2.0)
23/tcp open telnet
25/tcp open smtp qmail smtpd
53/tcp open domain
80/tcp open http Apache httpd 2.0.54 ((Fedora))
106/tcp open pop3pw poppassd
110/tcp open pop3
143/tcp open imap Courier Imapd (released 2004)
443/tcp open ssl/http Apache httpd 2.0.54 ((Fedora))
465/tcp open ssl/smtp qmail smtpd
993/tcp open ssl/imap Courier Imapd (released 2004)
995/tcp open ssl/pop3
1720/tcp filtered H.323/Q.931
3306/tcp open mysql MySQL 4.1.14
8443/tcp open ssl/http Apache httpd 2.0.46 ((Red Hat) mod_ssl/2.0.46 OpenSSL/0.9.7a)

Fijaos que cantidad de información, este servidor está montado hace poco tiempo, dentro de 2 meses, las versiones serán las mismas y habrán salido los correspondientes parches y el sistema será un coladero…

Si os fijáis, en el puerto 8443 corre Plesk, sólo con editar el httpd.conf del plesk (fichero de configuración de Apache) y añadir «ServerTokens Prod» no saldría la versión de Apache, tampoco la del OpenSSL ni la versión del sistema operativo.

En este ejemplo no se revela la versión de PHP pero editando php.ini donde pone el valor «expose_php = On» pasándolo a «Off», problema resuelto caso que con lo anterior no sea suficiente para PHP que lo suele ser salvo en alguna cabecera.

Me vale lo mismo para el propio Apache que está corriendo en el puerto 80 «Apache httpd 2.0.54 ((Fedora))», el apache del Plesk «tiene otra opinión» y dice que es un sistema Red Hat, pero ya sabemos por donde van los tiros.

La versión de ProFTPD se puede ocultar muy fácilmente así como hacer que MySQL sólo escuche conexiones entrantes de la propia máquina, también el DNS, editando el named.conf la versión de BIND queda oculta, etc, etc.

Para ocultar la versión de OpenSSH hay que hacerlo con una opción a la hora de compilarlo, como veis, hay mucha, demasiada información para un posible atacante y vaya, que esté corriendo Telnet (prácticamente en desuso por la seguridad del cifrado de SSH) es un riesgo de los buenos. (Ojo que este server no es de los que están «realmente mal» -;).

Además de no estar un firewall activo, se puede ver el estado de los puertos «open» y por mucho que Iptables esté en el sistema, si no se le meten las consabidas reglas, es como si lo tenéis apagado.

Un cracker o atacante puntual, lo primero que haría sería ver los servicios activos, puertos abiertos, versiones de S.O, etc, etc, en el objetivo para luego, atacar con exploits, herramientas de fuerza bruta y otras muchas técnicas que darían para otro post y de los largos -;).

Esto es sólo un ejemplo a voleo, pero puede que a algunos que estáis pensando contratar un servidor dedicado, os de alguna pista.

Resumiendo, un panel gráfico como cPanel o Plesk, cito estos dos por ser los de mayor implantación, os servirá para muchas tareas del día a día con el servidor, pero de ahí a que lo administren realmente hay un mundo.

Hay gente que sabe la de dios más que yo de estos temas, como de casi todo sobre lo que suelo hablar en el blog, tomaos estos consejos como la opinión de uno que hace unos años creyó que un Plesk iba a ser su mejor compañero de viaje…

Sobra decir que contrastéis y busquéis otras opiniones, ya que la mía por muy objetiva que pretenda yo que sea, no deja de ser una más, con los aciertos y errores que se me puedan atribuir.

Hace un tiempo comenté en esta entrada las bondades de SSH para administrar un servidor (dedicado o virtual), desde GNU/Linux, también en Mac OS X donde tenéis una línea de comandos Unix o en Windows con Putty.

Para acabar, os recomiendo que si valoráis vuestros datos, trabajo y proyecto web como sin duda lo hacéis, toméis uno de estos dos caminos caso de no saber de estos temas, o bien aprender y probar localmente en vuestros equipos antes de aplicarlo al server en producción, o dejarlo en manos de profesionales que sabrán que hacer.

Demo de cPanel | Demo de Plesk.

Saludos y que ustedes lo administren bien !

Dabo.

[tags] Apache, servidor, ssh, Plesk, cPanel, Unix, Webmin, Putty, web, hosting, alojamiento, sysadmin [/tags]