12 mesures pour un système Linux Apache MySQL PHP LAMP Web racine du serveur sécuriser

La fréquence de piratage a augmenté de façon spectaculaire ces derniers mois. Surtout beaucoup de données à être captés par des hacks sur les serveurs web. Même le Sony PSN bidouille a profité d'une vulnérabilité non corrigée dans le serveur Web Apache. Donc ici, je suis mesures de sensibilisation que le serveur peut posséder un peu plus sûr contre les attaques provenant de l'extérieur. Bien sûr, ce n'est pas non plus fournir une protection à 100%, mais il est préférable de faire les méchants du jeu un peu plus difficile. Certaines de ces mesures exigent seulement une installation minimale et la maintenance. D'autres ont besoin de beaucoup de temps et des connaissances en PHP à attraper. Vous devez toujours faire attention au rapport coût-bénéfice dans la sélection des mesures de sécurité. Il ne fait aucun sens pour protéger un petit site privé comme la Federal Reserve Bank. Cependant, peu de changements spécifiques dans le système possède déjà un grand signifie plus de sécurité. Et que vous devez traiter, même avant qu'il ne soit trop tard ....

Tous les trucs et Codesnips référence à une boîte actuel de Debian.

Première Le pare-feu - Une fois que tout interdire

La plupart des distributions Linux dans leurs installations par défaut d'ouvrir les ports à l'extérieur qui ne sont pas absolument nécessaire. Cette situation peut changer rapidement, cependant, même lorsque le serveur
jouant autour et à essayer des choses. Soudain, même le serveur de médias est à l'écoute sur Internet ou la base de données
accepte les connexions à partir d'Internet. Par conséquent, il n'est pas faux de se discipliner et mettre sur un pare-feu très restrictif qui interdit fondamentalement fois toutes les connexions de l'extérieur et permet seulement (auto-) composés sélectionnés. Heureusement, cela se fait rapidement avec iptables. De cette façon, on ne peut plus fournir des services à rendre accessible au monde qui n'ont pas d'affaires là-bas. Malheureusement, vous payez un peu de confort - le pare-feu doit être ajustée à chaque fois que vous souhaitez offrir de nouveaux services. Néanmoins, l'effort est faible et les avantages grande.

 # / Bin / bash

 # Supprimer les tables existantes
 iptables-F

 # Interdire toutes les connexions entrantes
 INPUT DROP iptables-P
 iptables-P FORWARD DROP

 # Autoriser tous les appels
 iptables-P OUTPUT ACCEPT

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

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

 # En outre service (UDP) de permettre, par exemple le serveur de jeu,
 iptables-A INPUT-j ACCEPT-p tcp - dport 4534 

 # Autorise tout de localhost.  (Pour permettre l'accès sans entrave au serveur lui-même, ses services,
 # Par exemple, PHP sur la base de données locale
 iptables-A INPUT-s 127.0.0.1-j ACCEPT

 # Connexions déjà établies seront acceptées dans chaque port
 # (Nécessaire pour certains démons)
 iptables-A INPUT-m état - state ESTABLISHED, RELATED-j ACCEPT

Cette épine dorsale peu que nous pouvons tout simplement continuer à élargir et d'ajouter leurs propres services. Lorsque vous travaillez sur le pare-feu, vous devez toujours prendre des dispositions pour le cas qui bloque par vous-même. Surtout pour les serveurs distants auxquels vous n'avez pas d'accès physique, il est très ennuyeux de perdre par un pare-feu n'a pas gouverner leur propre accès. Afin d'éviter ce problème de la route, vous pouvez quitter le travail pour commencer à le pare-feu temporairement juste une tâche cron qui réinitialise le pare-feu toutes les quelques minutes ou le redémarrage du serveur. Sont les règles tard testé et aimé, la tâche cron sera désactivé et les nouvelles règles restent actives en permanence.

Pour savoir quels services sont juste autour de l'écoute de votre propre serveur, vous pouvez utiliser la commande netstat:

 # Pour les sockets TCP:
 netstat-LPN | grep tcp

 # De même pour le protocole UDP:
 netstat-LPN | grep udp

Pour tester si le pare-feu fonctionne vraiment, vous pouvez scanner les ports de votre propre serveur depuis un autre ordinateur. Tout élaboré et qu'il devrait se traduire uniquement dans les ports qui sont ouverts même:

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

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

Deuxième SSH connexions interdiction

Sur son serveur propre racine que vous avez plein accès SSH. C'est assez pratique, comme vous pouvez partir de n'importe quel client SSH pour les temps de serveur juste pour y travailler. L'inconvénient de cette est que le cours peut quiconque est malheureusement quelque peu repris leurs propres mots de passe. Il est beaucoup plus sûr pour permettre les connexions SSH uniquement avec un fichier de clé valide. Par conséquent, la clé publique du client au serveur et copiés connexions interactives sont désactivés en entrant un mot de passe.

 # Sur le client, créer une clé publique
 # Si cela est spécifié lors de la génération de mot de passe, il faut
 # Fichier journal plus tard, la clé et le mot de passe.  Autrement
 # Nécessaire seulement la clé.

 ssh-keygen-t rsa

 # Copiez la clé générée par le serveur

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

 # Maintenant, ajustez sshd_config sur le serveur / etc / ssh /
 .
 .
 PasswordAuthentication no
 .
 .

 # Puis recommencez RearBBpos
 / Etc / init.d / ssh restart

Même ici, il faut prendre des précautions pour ne pas exclure, même si quelque chose ne fonctionne pas.
La clé publique sur une clé USB avec le mot de passe correspondant à votre tête, il est beaucoup plus difficile pour les méchants pour obtenir un shell.

Troisième SSH bruteforcing éviter denyhosts

Si des conseils n'est pas pratique 2 et vous n'avez pas renoncer à la commodité du mot de passe basés sur les connexions souhaitez, vous pouvez au moins éviter les taux de mot de passe automatisé des attaquants sur le serveur. Un grand nombre de robots sur Internet toute la journée à la recherche de ne rien faire de plus que de serveurs SSH et essayer dans vos mots de passe différents. Avec un mot de passe suffisamment sûr n'est pas un gros problème, mais il ya une meilleure sensation, même pas si c'est possible. En outre, il protège également ses utilisateurs, si il ya sur les comptes de serveur et l'utilisateur. Ici, vous ne pouvez pas compter sur les utilisateurs d'utiliser des mots de passe sécurisés. denyhosts constamment revus et les connexions ssh sur l'utilisateur verrouille pendant un certain temps, qui sont entrées dans leur mot de passe erroné répétée. Le IP des utilisateurs temporairement dans / etc / hosts.deny, de sorte qu'ils n'ont plus accès est possible. Cette SSH bruteforcing à une tâche très longue et pas très prometteur.

 apt-get install denyhosts

 Denyhosts # fonctionne juste après l'installation.  Il peut être
 # Dans l'air du fichier / etc / denyhosts.conf amende

4e Les listes noires utilisées pour bloquer les adresses IP des problèmes connus

Dans les listes noires Internet divers sont maintenus, ce qui liste un grand nombre de serveurs criminelles / hachée / spam / frauduleuse. Ces listes IP peuvent être saisies directement dans le pare-feu, de sorte qu'à partir de ce qu'on appelle ne pas les ordinateurs de confiance ne peut pas se connecter du tout à son propre serveur. Ainsi, vous pouvez réduire la quantité de spam sur leur propre serveur de façon spectaculaire et l'un ou l'autre script kiddie lock-out, parce que son mandataire Russie cesse soudainement de fonctionner. Comment faire que j'ai été dans un autre article de blog décrit l'exemple de la liste noire des Infiltrated.net.

5e Ne pas utiliser FTP pour travailler sur le serveur

FTP est une relique des temps meilleurs où l'Internet était un petit village encore confiance. De nombreux administrateurs de sites Web encore utiliser FTP pour transférer des fichiers vers le serveur ou pour travailler sur leur propre site web. Malheureusement, cela est très incertain, puisque FTP transmet toutes les données sans garantie. Les mots de passe et les données peuvent être lues sans aucun problème à chaque saut entre les serveurs et les clients. Beaucoup plus sûr d'aller avec sshfs. Permet de monter un répertoire via ssh sur le système sur le serveur distant de fichiers local. Vous pouvez alors travailler sur le serveur comme s'il était sur l'ordinateur local. Tous les accès aux fichiers pour les fichiers sur le serveur sont complètement transparents, de sorte que vous pouvez ouvrir avec le programme local graphique pour modifier une image directement sur le serveur, puis enregistrez. Plus de confort et de sécurité sans trop d'effort.

 # Installez sshfs
 apt-get install sshfs

 # Créer le point de montage sur le système de fichiers local
 mkdir / media / monserveur

 # Serveur pour le support du système de fichiers local
 sshfs www-data@mein-server.de :/ var / www / media / monserveur

 # Maintenant, le répertoire est / var / www sur mon serveur local sous / media / monserveur disponibles

6e Installer mises à jour

Un système super sécurisé sera pas utile si le système lui-même est imparfaite et une vulnérabilité connue peut être exploitée. Dans la plupart des cas, ces vulnérabilités fermé rapidement, mais souvent oubliée admin mises à jour régulières du système à faire. Que vous devez activer les mises à jour automatiques sur des serveurs Linux ou non est une question controversée. Certains ne ferait jamais, parce qu'il naturellement avec beaucoup de malchance peut-être que les mises à jour de rendre le système inutilisable. Ce qui m'est arrivé dans plus de 10 années de travail sur les systèmes Debian, mais jamais et je comprends les avantages de mises à jour en temps opportun et régulier, beaucoup plus élevé que le risque qui en résulte.

 # Cette ligne dans le fichier / etc / crontab, met à jour l'horloge système tous les jours à 6 heures du matin
 0 6 *** root apt-get update && apt-get-y de mise à niveau

Ces méthode rapide et sale a fonctionné pour moi jusqu'à présent toujours bonne. J'ai lu récemment que dans le référentiel Debian et le paquet unattended-upgrades existe qui résout le problème sans doute plus élégant, mais je n'ai pas été testé.

Même avec ces mises à jour système vollautomtischen il n'est pas complètement décroché. Si une mise à jour du noyau a été livré, vous devez démarrer le système encore une fois à la main, sinon les modifications ne seront pas actifs.

Si nous utilisons un tiers du code PHP sur le serveur, comme un CMS open source ou d'un forum, il est bien sûr absolument nécessaire et ce code avec les nouvelles versions à jour. Comme Debian ne pas mettre à jour ses changements à ces demandes dans les règles régissant ce travail manuel est nécessaire. La meilleure façon de lire vos listes de diffusion avec les produits correspondants dans le but d'être toujours à jour.

7e PHP open_basedir avec emprisonner

Hacks Beaucoup repose sur le fait qu'une vulnérabilité dans le code PHP est utilisé pour accéder à des fichiers dans l'accès au système de fichiers qui n'appartiennent pas au site, mais le système lui-même est pourquoi vous devez enfermer PHP afin qu'il en lecture seule dans les annuaires spécifiquement désignés et à écrire autorisé. Pour ce faire, le fichier php.ini l'option de configuration open_basedir. PHP a la possibilité de mettre l'accès n'est autorisé dans les répertoires là-bas. Les fichiers tels que / etc / passwd sont hors de portée. Hébergement des sites Web multiples sur un seul serveur, vous devez définir open_basedir dans chaque configuration d'hôte virtuel de chaque côté.

 Php.ini # global par le biais:
 # / Etc/php5/apache2/php.ini
 open_basedir = / var / www / :/ tmp /

 # Par site dans la configuration VirtualHost:
 php_value open_basedir / var / www / site / :/ tmp /

Il est important d'examiner si tous les sites ont été ajoutés aux scripts ont généralement besoin d'avoir accès, sinon il se peut que vous soyez fonctions handicapés et légitime de l'application PHP.

8e Créer vos propres sites Web pour les utilisateurs de MySQL

Utilisez votre propre PHP-MySQL application, vous devez absolument créer pour Apllikation MySQL d'utilisateur et en aucun cas utiliser les requêtes MySQL de l'utilisateur root. Vous devez également restreindre les droits de l'utilisateur jusqu'à ce que les opérations en réalité que sont autorisés, ce qui nécessite le script PHP. CREATE TABLE et DROP TABLE sont aussi communs dans les injections SQL et utilisé dans la plupart des applications PHP jamais nécessaires. Il héberge plusieurs sites Web avec plusieurs bases de données sur un serveur, vous devez créer vos propres bases de données pour tous les utilisateurs. Ainsi, après une attaque réussie, un attaquant a seulement accès à l'une des bases de données et non pas directement à tous. Wenn man nicht die Kommandozeile bemühen möchte, um die MySQL-Useraccounts zu verwalten, funktioniert das Usermanagement auch recht einfach mit PHPmyAdmin unter der Registerkarte "Rechte".

9e PHP Fehlermeldungen abschalten

PHP-Fehlermeldungen können einem Angreifer viel über den eigenen Server verraten: Verzeichnisstrukturen, Datenbankstrukturen, Konfigurationsfehler, etc. Außerdem sehen sie für den Benutzer sehr unprofessionell aus. Aus diesem Grund sollte man sie auf einem Live-Webserver grundsätzlich abschalten, da man sie ohnehin weiterhin in den Logs sehen kann.

# Global per php.ini:
# /etc/php5/apache2/php.ini
display_errors = Off

# Per Site in der VirtualHost Config:
php_flag display_errors Off

# Fehlermeldungen trotzdem lesen:
cat /var/log/apache2/error.log | grep PHP

10e Angriffsfläche für SQL-Injections einschränken mit modSecurity

SQL-injections sind die wohl am häufigsten genutzte Angriffsmethode auf Webserver. Der Zugriff erfolgt direkt über die Webapplikation und es genügt ein Browser um sie durchzuführen. Dabei werden über vom User übermittelte Variablen geschickt SQL-Abfragen eingebaut, die mit den Rechten des Datenbankbenutzers alles an der eigenen Datenbank nach belieben auslesen, löschen oder bearbeiten können. Ein wirklicher echter Schutz gegen SQL-Injections besteht nur, wenn der PHP-Code der Site im Hinblick auf diese Angriffe geschrieben wurde. Jede Variable aus Benutzereingaben, die in eine SQL-Abfrage gelangen könnte, muss geprüft und escaped werden. PHP bietet dafür die Funktion real_mysql_escape_string().

Ist man nicht sicher, ob der Code sauber ist, kann mod_security für den Apache helfen eine große Menge dieser Angriffe trotzdem abzuwehren. 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