12 medidas para un sistema Linux Apache MySQL PHP LAMP 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
 # Archivo de registro más adelante, la clave y la contraseña.  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, para que de esta se sabe que no los equipos de confianza no se puede conectar en absoluto 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 se olvida admin 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. Alojamiento de varios sitios web en un servidor debe configurar 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. Alberga varios sitios web con bases de datos múltiples 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 una de las bases 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. mod_security überprüft ständig alle Requests an den Webserver und reagiert auf vorgefertigte Muster mit denen viele SQL-Injection-Angriffe abgewehrt werden können. Leider funktioniert auch mod_security nur gut mit manuellem Aufwand. Oft blockt mod_security nach einer frischen Installation auch gewünschte (normale) Funktionen des eigenen PHP-Codes, so dass einem nichts anderes übrig bleibt, als die komplette Applikation nach der Installation einmal durchzutesten. Nur so findet man heraus, ob mod_security nicht eventuell auch gewünscht Funktionen blockt. Ist das der Fall, muss die Filterliste angepasst werden, so dass die false-positives verschwinden.

Die Konfiguration von mod_security ist etwas komplizierter und würde den Umfang dieses Artikels sprengen, es gibt aber massenweise gute Tutorials zu mod_security im Internet.

11 Ausweiskontrolle - Der Apache sagt nicht mehr, wer er ist
Dies ist keine wirklich wirkungsvolle Methode gegen einen Hack, sie macht es automatisierten Skripten, die nach Server-Versionen suchen aber etwas schwerer. Normalerweise zeigt der Apache auf Seiten mit Fehlermeldungen (zB 404 Not Found) seine Serversignatur.

Apache/2.2.16 (Debian) Server at www.daniel-ritter.de Port 80

So erhalten potentielle Angreifer zumindest schon einmal Informationen über den eigesetzten Webserver und den Versionsstand. Die Serversignatur ist schnell ausgeschaltet:

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

12 Nicht benutze Apache-Module deaktivieren

Per default hat der Apache einige Module geladen, die fast nie benötigt werden. Unter Debian findet man die geladenen Module
als Softlinks in /etc/apache2/mods-enabled.

Fast immer entfernt werden können:

mod_cgi

Dient dem ausführen von CGI-Skripten. Diese Technik stammt noch aus den Urzeiten des Web und war der Vorvater der modernen Skriptsprachen um dynamische Webseiten zu ermöglichen. mod_cgi ist auf 99% der PHP-Websites unnötig und bei einer fehlerhaften Apache-Config eine potentielle Sicherheitslücke

a2dismod cgi

mod_status

Ermöglicht es Browsern Statusinformationen über den Apache auszulesen. Es wird so gut wie nie für "normale" Sites genutzt, bietet Angreifern aber Statusinformationen über den Apache.

a2dismod status

mod_autoindex

mod_autoindex sorgt dafür, dass Verzeichnisse auf dem Webserver aufgelistet werden können, wenn es keine gültige Index-Seite in dem entsprechenden Verzeichnis gibt. Falls diese Funktionalität nicht erwünscht ist, sollte man sie abschalten, da durch sie ganze Verzeichnisbäume auf dem Webserver nach aussen sichtbar werden können.

a2dismod autoindex