12 medidas para un sistema Linux Apache MySQL PHP LÁMPARA la raíz del servidor Web seguro

La frecuencia de la piratería se ha incrementado dramáticamente en los últimos meses. Sobre todo una gran cantidad de datos a ser recogidos por hacks en los servidores web. Incluso el Sony PSN truco se aprovechó de una vulnerabilidad no corregida en el servidor web Apache. Así que aquí estoy planteando medidas que el servidor puede poseer un poco más seguro contra los ataques desde el exterior. Por supuesto, esto también no ofrece protección del 100%, pero es mejor hacer a los chicos malos del juego un poco más difícil. Algunas de las medidas requieren sólo una instalación y mantenimiento mínimos. Otros necesitan una gran cantidad de tiempo y conocimientos de PHP para la captura. Usted siempre debe prestar atención a la relación costo-beneficio en la selección de las medidas de seguridad. No tiene sentido para proteger un sitio pequeño, privado, al igual que el Banco de Reserva Federal. Sin embargo, son pocos los cambios específicos en el sistema ya tiene un gran significa más seguridad. Y eso se debe tratar incluso antes de que sea demasiado tarde ....

Todos los consejos y Codesnips se refieren a una caja de Debian actual.

Primero El servidor de seguridad - prohibir Una vez que todo

La mayoría de distribuciones de Linux en sus instalaciones por defecto abrir ningún puerto en el exterior que no son absolutamente necesarios. Esta situación puede cambiar rápidamente, sin embargo, incluso cuando el servidor
jugando y probando cosas. De pronto, incluso el servidor de medios está a la escucha en Internet o en la base de datos
acepta las conexiones de Internet. Por lo tanto, no está mal disciplinarse a sí mismos y poner en un servidor de seguridad muy restrictivas que básicamente prohíbe Una vez que todas las conexiones desde el exterior y sólo permite que la (auto) los compuestos seleccionados. Afortunadamente, esto se hace rápidamente con iptables. De esta manera ya no se puede proporcionar servicios para hacer accesible a todo el mundo que no tienen negocios allí. Lamentablemente, usted paga un poco de consuelo - el servidor de seguridad debe ajustarse cada vez que desea ofrecer nuevos servicios. Sin embargo, el esfuerzo es pequeño y grande de los beneficios.

 # / Bin / bash

 # Eliminar las tablas existentes
 iptables-F

 # Prohibir todas las conexiones entrantes
 iptables-P INPUT DROP
 iptables-P FORWARD DROP

 # Permitir todas las llamadas
 iptables-P OUTPUT ACCEPT

 # Permitir SSH
 iptables-A INPUT-j ACCEPT-p tcp - dport 22 

 # Permitir HTTP
 iptables-A INPUT-j ACCEPT-p tcp - dport 80 

 # Más información de servicio (UDP) permiten, por ejemplo, servidor de juegos
 iptables-A INPUT-j ACCEPT-p tcp - dport 4534 

 # Permitir todo, desde localhost.  (Para permitir el acceso sin trabas a la del propio servidor, sus servicios,
 # Por ejemplo, PHP en la base de datos local
 iptables-A INPUT-s 127.0.0.1-j ACCEPT

 # Ya conexiones establecidas serán aceptadas en cada puerto
 # (Se requiere para algunos demonios)
 iptables-A INPUT-m Estado - state ESTABLISHED, RELATED-j ACCEPT

Esta espina dorsal poco podemos simplemente seguir ampliando y añadir sus propios servicios. Cuando se trabaja en el servidor de seguridad, siempre debe tomar medidas para el caso de que se bloquea a ti mismo. Especialmente para los servidores remotos a los que no tienen acceso físico, es muy molesto perder por un firewall no descarta su propio acceso. Para evitar este problema fuera del camino, usted puede dejar el trabajo para empezar en el firewall temporalmente sólo una tarea de cron que restablece el servidor de seguridad cada pocos minutos, o se reinicia el servidor. ¿Son las normas más probado y me encantó, el cronjob serán desactivados y las nuevas reglas permanentemente activo.

Para averiguar qué servicios están a la vuelta de escuchar a su propio servidor, puede utilizar netstat:

 # Para sockets TCP:
 netstat-LPN | grep tcp

 # Lo mismo ocurre con UDP:
 netstat-LPN | grep udp

Para probar si el servidor de seguridad que realmente funciona, puede escanear un puerto de su propio servidor desde otro equipo. Todo salió y debe dar lugar solamente a los puertos que están abiertos incluso:

 # Para TCP:
 nmap-p1-65 535 meinserver.de

 # Para UDP:
 nmap-sU-p1-65 535 meinserver.de

Segundo SSH prohibición de inicios de sesión

En su servidor de raíz propia que tiene acceso total a SSH. Esto es muy útil, como se puede desde cualquier cliente de SSH para los tiempos de servidor sólo para trabajar en él. La desventaja de esto es que el curso puede alguien que por desgracia es de alguna manera hecho cargo de sus propias contraseñas. Es mucho más seguro permitir las conexiones SSH sólo con un archivo de clave válido. Por lo tanto, la clave pública del cliente al servidor y copiar los inicios de sesión interactivos están desactivados mediante la introducción de una contraseña.

 # En el cliente, cree una clave pública
 # Si se especifica la hora de generar una contraseña, es necesario
 # Volver luego y la contraseña del archivo de clave.  De otra manera
 # Sólo se necesita la clave.

 ssh-keygen-t rsa

 # Copiar la clave generada en el servidor

 ssh-copy-id-i ~ /. ssh / id_rsa.pub root@meinserver.de

 # Ahora ajuste sshd_config en el servidor / etc / ssh /
 .
 .
 PasswordAuthentication no
 .
 .

 # A continuación, empezar de nuevo RearBBpos
 / Etc / init.d / ssh restart

Incluso en este caso hay que tomar precauciones para no excluidos, incluso si algo no funciona.
La clave pública en una memoria USB con la contraseña correspondiente en la cabeza hace que sea mucho más difícil para los chicos malos para conseguir una concha.

Tercera SSH fuerza bruta prevenir denyhosts

Si el consejo no es práctico 2 y no renunciar a la comodidad de la contraseña de base de los inicios de sesión desea, puede lo menos evitar que los tipos de contraseñas automatizado de los atacantes en el servidor. Muchos de los robots en Internet durante todo el día tratando de hacer nada más que a servidores SSH y probar en sus diferentes contraseñas. Con una contraseña razonablemente segura que no es un gran problema, pero hay una sensación mejor, ni siquiera si eso es posible. Además, también protege a sus usuarios, si hay sobre las cuentas del servidor y el usuario. Aquí, usted no puede confiar en que los usuarios utilicen contraseñas seguras. denyhosts constantemente revisadas y los inicios de sesión SSH en el usuario bloquea durante un tiempo que han ingresado su contraseña incorrectamente repetida. La IP de los usuarios de forma temporal van en / etc / hosts.deny, de modo que ya no tienen acceso a es posible. Esta fuerza bruta SSH a una tarea muy larga y no muy prometedora.

 apt-get install denyhosts

 Denyhosts Número funciona bien después de la instalación.  Puede ser
 # En la melodía archivo / etc / denyhosts.conf bien

Cuarto Listas negras utilizadas para bloquear IPs conocidas de problemas

En varias listas negras de Internet se mantienen, lo que la lista de un gran número de servidores criminales / picada / spam / fraudulento. Estas listas de IP pueden ser introducidos directamente en el servidor de seguridad, de modo que a partir de estas máquinas no se sabe que puede confiar en absolutamente ninguna relación es posible a su propio servidor. Así que usted puede reducir la cantidad de spam en su propio servidor de manera espectacular y uno u otro script kiddie cierre patronal, debido a que su representante rusa de repente deja de funcionar. ¿Cómo hacer que yo he sido en otro artículo en el blog describe el ejemplo de la lista negra de Infiltrated.net.

Quinto No utilice FTP para trabajar en el servidor

FTP es una reliquia de tiempos mejores, cuando Internet era una pequeña aldea todavía confiaba. Muchos administradores de sitios web sigue siendo el uso de FTP para transferir archivos al servidor o para trabajar en su propio sitio web. Por desgracia, esto es muy incierto, ya que FTP transmite todos los datos sin garantía. Las contraseñas y los datos se pueden leer sin ningún problema en cada salto entre servidores y clientes. Mucho más seguro para ir con sshfs. Le permite montar un directorio a través de ssh en el sistema del servidor remoto de archivos local. A continuación, puede trabajar en el servidor como si estuviera en el equipo local. Todo el acceso a archivos en el servidor son completamente transparentes, por lo que se puede abrir con el programa de gráficos local para editar una imagen en el servidor directamente, y luego guardar. Más confort y seguridad sin mucho esfuerzo.

 # Instalar sshfs
 apt-get install sshfs

 # Crear punto de montaje en el sistema de archivos local
 mkdir / media / miservidor

 # Server para el soporte de sistema de archivos local
 sshfs www-data@mein-server.de :/ var / www / media / miservidor

 # Ahora es el directorio / var / www en mi servidor local en / media / miservidor disponibles

Sexto Instalar actualizaciones

Un sistema seguro super no servirá de nada si el propio sistema es defectuoso y una vulnerabilidad conocida puede ser explotada. En la mayoría de los casos, estas vulnerabilidades cerró rápidamente, pero a menudo olvidada de administrador actualizaciones periódicas del sistema para hacer. Ya sea que usted debe activar las actualizaciones automáticas en servidores Linux o no es un tema polémico. Algunos nunca lo haría, porque, naturalmente, con un montón de mala suerte puede ser que los cambios que el sistema inutilizable. Esto me sucedió en más de 10 años de trabajo en sistemas Debian, pero nunca me aprecian los beneficios de las actualizaciones oportunas y regulares, mucho mayor que el riesgo resultante.

 # Esta línea en el archivo / etc / crontab, actualiza el reloj del sistema todos los días a las 6 am
 0 6 *** root apt-get update && apt-get-y de actualización

Estos método rápido y sucio trabajado para mí hasta ahora siempre es bueno. Hace poco leí que en el repositorio de Debian y el paquete de actualizaciones desatendidas existe que resuelve el problema, probablemente, más elegante, pero no lo he probado.

Incluso con estas actualizaciones del sistema vollautomtischen no es totalmente descolgado. Si una actualización del kernel se ha entregado, tiene que arrancar el sistema una vez más a mano, de lo contrario los cambios no estarán activos.

Si usamos terceros código PHP en el servidor, como un CMS de código abierto o un foro, es, por supuesto, es absolutamente necesario y el código de este con las nuevas versiones hasta la fecha. Dado que Debian no actualiza sus cambios a las aplicaciones de las normas que regulan esta mano de obra se necesita. La mejor manera de leer sus listas de correo con los productos correspondientes a fin de estar siempre al día.

Séptimo PHP open_basedir con encarcelar a

Hacks basado en el hecho de que una vulnerabilidad en el código PHP se utiliza para acceder a los archivos en el acceso al sistema de archivos que no pertenecen al sitio, pero el sistema en sí mismo es por lo que debe encerrar a PHP para que se lea sólo en los directorios especialmente designados y escribir permitido. Para ello, el php.ini la opción de configuración open_basedir. PHP tiene la opción de colocar el acceso sólo se permite a los directorios de allí. Archivos tales como / / etc passwd están fuera de su alcance. Hostet a múltiples sitios web en un servidor se debe establecer open_basedir en cada configuración del host virtual en cada lado.

 # Php.ini global a través de:
 # / Etc/php5/apache2/php.ini
 open_basedir = / var / www / tmp :/ /

 # Por sitio en la configuración del host virtual:
 php_value open_basedir / var / www / site / :/ tmp /

Es importante considerar si todos los sitios se han añadido a las secuencias de comandos por lo general necesitan tener acceso, de lo contrario puede ser que son las funciones de movilidad reducida y legítimo de la aplicación PHP.

Octavo Cree sus propios sitios web para los usuarios de MySQL

Utilice su propia PHP-MySQL aplicación, a pesar de todo debe crear para el usuario de MySQL Apllikation propia y en ningún caso utilizar las peticiones fundamentales de usuario de MySQL. También debe restringir los derechos de los usuarios hasta el momento de que las operaciones en realidad sólo se les permite, lo que requiere el script PHP. CREATE TABLE y DROP TABLE son tan comunes en las inyecciones de SQL y se utiliza en la mayoría de las aplicaciones PHP no sea necesario. Hostet a múltiples sitios con múltiples bases de datos en un servidor, usted debe crear sus propias bases de datos para todos los usuarios. Así, después de un ataque con éxito, un atacante sólo tiene acceso a la base de datos y no directamente en absoluto. Si usted no desea probar la línea de comandos para administrar las cuentas de usuario de MySQL, el usuario de gestión funciona también bastante fácil con phpMyAdmin en la pestaña "derechos".

Noveno PHP mensajes de error frente a

Mensajes de error de PHP que un atacante puede revelar mucho acerca de su propio servidor: una estructura de directorios, las estructuras de base de datos, errores de configuración, etc También buscan que el usuario muy poco profesional. Por esta razón, debe estar en un servidor web en vivo, siempre apague, ya que sólo vamos a seguir viendo en los registros.

 # Php.ini global a través de:
 # / Etc/php5/apache2/php.ini
 display_errors = Off

 # Por sitio en la configuración del host virtual:
 display_errors Off php_flag

 # Mensajes de error leerlo de todos modos:
 cat / var/log/apache2/error.log | grep php

10a Objetivo para el límite de inyección SQL con ModSecurity

Inyecciones de código SQL es el método más frecuente de ataque en los servidores web. Acceder directamente a través de la aplicación web y se encuentra con un navegador para llevarlas a cabo. Aquí se transmiten por las variables de usuario creadas consultas SQL enviadas a los privilegios del usuario de base de datos la totalidad de su base de datos en borrará leer o editarlos. Una verdadera protección real contra la inyección de SQL, sólo existe si el código de PHP ha sido escrito el lugar en relación a estos ataques. Cada variable de entrada del usuario, lo que podría entrar en una consulta SQL, debe ser probado y se escapó. PHP ofrece la real_mysql_escape_string function ().

Si usted no está seguro si el código es limpio, puede mod_security para Apache ayudar a evitar una gran cantidad de estos ataques de todos modos. revisión constante de todas las solicitudes de mod_security en el servidor Web y responde a las pre-patrón que muchos ataques de inyección SQL se pueden bloquear. Por desgracia, sólo funciona bien con el esfuerzo mod_security manual. A menudo, después de unos bloques de nueva instalación mod_security también es necesario (regular) las funciones de su código PHP, por lo que uno no tiene otra opción, ya que la aplicación completa de probar de nuevo la instalación. Sólo entonces puede uno saber si mod_security ni siquiera puede ser que desee bloquear funciones. Si es así, entonces la lista de filtros para ajustarse a desaparecer de modo que el falso positivo.

La configuración de mod_security es algo complicado y está más allá del alcance de este artículo, pero hay un montón de buenos tutoriales en el mod_security Internet.

11 Identificación de verificación - Apache aún no sabe quién es
Esto realmente no es método eficaz en contra de un hachazo, que hace que los scripts automatizados que buscan versiones de servidor, pero más pesado un poco. Generalmente los puntos de Apache a páginas con mensajes de error (por ejemplo, 404 Not Found) su firma del servidor.

 Apache/2.2.16 (Unix) Server en www.daniel-ritter.de el puerto 80

Se elimina cualquier potencial agresor recibirá por lo menos una vez antes sobre el servidor Web eigesetzten y el nivel de versión. El servidor de la firma se apaga rápidamente:

 # / Etc/apache2/conf.d/security
 ServerSignature Off

12 No utilice deshabilitar módulos de apache

Por defecto, Apache ha cargado algunos módulos que casi nunca son necesarias. En Debian se pueden encontrar los módulos cargados
como un enlace simbólico en / etc/apache2/mods-enabled.

Se puede quitar casi siempre:

mod_cgi

Se utiliza para ejecutar scripts CGI. Esta técnica se remonta a los albores de la web y fue el antepasado de los modernos lenguajes de scripting para permitir sitios web dinámicos. mod_cgi es innecesario para el 99% de los sitios de PHP y con una defectuosa configuración de Apache es un potencial agujero de seguridad

 a2dismod cgi

mod_status

Permite a los navegadores para leer la información sobre el estado de los apaches. Casi nunca se usa para los sitios "normales", proporciona información sobre el estado de los atacantes, pero Apache.

 estado de a2dismod

mod_autoindex

mod_autoindex asegura que los directorios se pueden enumerar en el servidor web, si no hay una página de índice válido en el directorio adecuado. Si esta funcionalidad no se desea, debe deshabilitar, ya que los árboles de directorios completas en el servidor web puede ser visible desde el exterior.

 a2dismod AUTOINDEX