База на знаења

Nosotros nos tomamos la seguridad muy seriamente por lo que elaboramos una lista comprensible de las medidas de seguridad a tomar para un servidor VPS. Para obterner alguna o todas de las siguientes medidas de seguridad aplicadas a su servidor VPS, contacte a nuestro equipo de soporte. Por favor especifique cuáles de los siguientes pasos desea que apliquemos. Tipicamente hacemos los pasos 1-6 automáticamente y 7-9 sobre solicitud específica. Este artículo no pretende ilustrar cada paso en detalle, pero si cubrir las medidas en alto nivel para que ud. pueda comprender que implican y cómo pueden ayudar, asi como tambien que cosas debe tener en cuenta al aplicar estas medidas. Si ud. prefiere realizar alguna de estas medidas por ud. mismo en lugar de solicitar nuestra asistencia, y necesita algunos consejos, sólo dejenos saber. 1. Actualizar Apache/PHP, openssh, openssl, mysql etc. Nada nuevo aquí, pero nosotros nos aseguraremos de que su vps esté corriendo las últimas versiones seguras de los componentes de software más comunes. �ste es el primer paso para prevenir que su servidor sea crakeado por herramientas comunes y exploits conocidos. Usualmente no hay lados oscuros en esta medida, pero si ud. tiene requerimientos especiales para aplicaciones particulares, y necesita una versión de software específica para algunos de estos componentes, algunas actualizaciones deben ser realizadas con precacución. 2. Instalación de Firewall. Podemos instalar R-fx Networks APF firewall y varias otras herramientas relacionadas como bfd, sim y pmon. Estas herramientas van a prevenir accesos no autorizados a su servidor y prevenir ataques de fuerza bruta. APF (Advanced Policy Firewall) http://www.rfxnetworks.com/apf.php BFD (Brute Force Detection) http://www.rfxnetworks.com/bfd.php SIM (System Integrity Monitor) http://www.rfxnetworks.com/sim.php PRM (Process Resource Monitor) http://www.rfxnetworks.com/prm.php LES (Linux Environment Security) http://www.rfxnetworks.com/les.php NSIV (Network Socket Inode Validation) http://www.rfxnetworks.com/nsiv.php SPRI (System Priority) Installation http://www.rfxnetworks.com/spri.php Por favor tenga en cuenta que no existen balas de plata, y esta medida no prevendrá vulnerabilidades de algunos servicios que ud. corra. También debera tener en mente que ud. tiene un firewall instalado y deberá abrir puertos adicionales si ud. añade nuevos servicios. 3. Instalación de Rkhunter. Aunque no es un mecanismo preventivo, esto puede ser muy útil para detectar alguna falla en su capa de defensa. Es una tarea programada (cron) que escanea su sistema en busca de rootkits, exploits, troyanos y puertas traseras (backdoors). http://www.rootkit.nl/projects/rootkit_hunter.html Esta configuración no tiene lados oscuros, pero puede generar falsas alarmas de tiempo en tiempo. 4. Instalación de Mod_Security. Mod security es efectivamente un firewall para aplicaciones basadas en web y puede ayudar a prevenir ataques en programas que de otra manera serían vulnerables. Esto puede ser ajustado finamente, pero limitará a sus clientes mas avanzados (se puede rectificar facilmente) http://www.modsecurity.org Si desea saber que bloquea exactamente mod_security, observe el siguiente artículo: http://soporte.wizhosting.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=132&nav=0 5. Asegurando /tmp. Muchos ataques y expoits usa /tmp para trabajar o propagarse a si mismos. Pero convirtiendo /tmp en una partición a parte y montandola como no ejecutable y no escalable en privilegios (noexec y nosuid), esta medida prevendrá que muchisimos de estos exploits causen daño. El lado oscuro potencial de esta medida es hacer el /tmp muy pequeño para algunas aplicaciones especificas como backups o transferencias de cuentas. 6. Desactivando acceso no-root a binarios inseguros. Muchos exploits usan ejecutables muy conocidos instalados en su sistema como parte de su caja de herramientas. Permitiendo el acceso sólo a usuarios con privilegios a estos archivos, ud. puede prevenir que muchos ataques tengan éxito. Ud. puede encontrar muy util limitar el acceso a algunos binarios como "wget", uha herramienta muy potente y comoda para los usuarios, pero tambien para los crackers. 7. Desactivando acceso SSH cómo root. (opcional) Conectar a SSH como root es malo porque un ataque de fuerza bruta puede usar el usuario conocido ("root") y concentrarse especificamente en la contraseña y sus variantes. Utilizando un usuario único (no alguno tipico como admin), puede reducir ampliamente la chance de sistemas de crack con fuerza bruta. Algunas personas necesitan shh como root como forma de acceder por ftps a todo el sistema. Hay algunas vueltas para solucionar esto, como crear otro usuario con uid 0. Debe tener esto en cuenta a la hora de contactar soporte, brindandonos el usuario y la clave del usuario no-root para acceder por ssh a su servidor. 8. Cambiar el puerto SSH. (opcional) Una capa adicional de seguridad es cambiar el puerto por default de ssh a otro puerto. Aunque esta es una tecnica de seguridad por oscuridad, esto puede dejarlo completamente a salvo de muchos scripts infantiles. De la misma forma que en el paso anterior, debe informarnos el puerto necesario para conectar por ssh cuando solicite soporte. 9. PHP suEXEC. (opcional) cuando PHP corre como un Módulo de Apache, se ejecuta con el usuario/grupo del servidor web que es comunmente "nobody" o "apache". php suEXEC modifica esto ejecutando scripts como CGI. Esto significa que los scripts son ejecutados como el usuario que lo creó. Si el usuario "juan" sube un script PHP, ud. verá como que "juan" esta corriendo el script cuando observe los procesos del sistema. Esto provee una capa adicional de seguridad ya que los scripts no aceptan permisos superiores a 777 (read/write/execute a nivel de user/group/world). el lado oscuro de esta medida es que algunas veces puede haber problemas si se añaden directivas de php en archivos .htaccess. Debe remover todas las directivas de php en archivos .htaccess que tenga, y moverlas a un archivo php.ini dentro del directorio donde corre el archivo .php. También se puede perder un poco de performance (asi como tambien observar un nivel más alto de carga del servidor) como resultado de todos los scripts php corren como cgi separados, en vez de como parte de un modulo de apache.