Technologies informatiques,
Recherche et développement

Outils pour utilisateurs

Outils du site

Vous êtes ici : index » doc » formations » hebergement » serveur » proteger
Piste :
doc:formations:hebergement:serveur:proteger

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
doc:formations:hebergement:serveur:proteger [2022/06/14 13:39] – [Sudo, utilisateurs privilégiés et sudoers] jeremiedoc:formations:hebergement:serveur:proteger [2024/02/19 18:56] (Version actuelle) – [Via le nouveau ufw] jeremie
Ligne 2: Ligne 2:
  
 ====== Protéger ses serveurs ====== ====== Protéger ses serveurs ======
 +
 +Voyez aussi: [[doc:formations:hebergement:serveur:observer|observer]] votre serveur.
  
 En cas de compromission, la meilleure solution reste la réinstallation à partir de zéro. Et donc, il FAUT avoir des sauvegardes régulières, et qui marchent! En cas de compromission, la meilleure solution reste la réinstallation à partir de zéro. Et donc, il FAUT avoir des sauvegardes régulières, et qui marchent!
Ligne 92: Ligne 94:
  
  
-=== Utilisateurs "système" ===+==== Utilisateurs "système" ====
  
 Par prudence, vous pouvez commencer par désactiver un utilisateur plutôt que de le supprimer, c'est moins dangereux (voyez aussi ''ssh'' qui peut servir à restreindre les commandes utilisables par celui-ci), par exemple: Par prudence, vous pouvez commencer par désactiver un utilisateur plutôt que de le supprimer, c'est moins dangereux (voyez aussi ''ssh'' qui peut servir à restreindre les commandes utilisables par celui-ci), par exemple:
Ligne 105: Ligne 107:
  
  
-=== Sudo, utilisateurs privilégiés et sudoers ===+==== Sudo, utilisateurs privilégiés et sudoers ====
  
 Les utilisateurs qui font partie du groupe ''sudo'' peuvent lancer une commande en tant que root en préfixant leur commande par ''sudo'' (//supervisor do// ...), qui va ensuite leur demander de saisir leur mot de passe. Les utilisateurs qui font partie du groupe ''sudo'' peuvent lancer une commande en tant que root en préfixant leur commande par ''sudo'' (//supervisor do// ...), qui va ensuite leur demander de saisir leur mot de passe.
Ligne 120: Ligne 122:
 </code> </code>
  
-Ensuite, vous lui permettez d'éxécuter la commande en tant que root et sans même son mot de passe en ajoutant la ligne suivante avec `visudo`:+Ensuite, vous lui permettez d'éxécuter la commande en tant que root en ajoutant la ligne suivante avec `visudo`:
  
-  untel ALL=(root) NOPASSWD: /usr/local/bin/postgre_restart.sh+  www-uploader  ALL=(root) NOPASSWD: /usr/local/bin/postgre_restart.sh
      
 __note:__ Attention ! Si votre commande accepte des arguments issus de l'utilisateur, pensez à bien "blinder" le script afin d'éviter un abus de droits __note:__ Attention ! Si votre commande accepte des arguments issus de l'utilisateur, pensez à bien "blinder" le script afin d'éviter un abus de droits
  
 Vous trouverez bien d'autres options [[https://doc.ubuntu-fr.org/sudoers|ici]]. Vous trouverez bien d'autres options [[https://doc.ubuntu-fr.org/sudoers|ici]].
 +
 ===== fail2ban en défense contre les accès "brute force" ===== ===== fail2ban en défense contre les accès "brute force" =====
  
-Les accès "brute force" sont des tentatives répétées d'entrer sur votre serveur, en testant plusieurs logins possibles, ou en testant de nombreuses URL afin de trouver un service mal protégé et rentrer dans votre serveur illégalement.+Pour SSH au moins, on recommande systématiquement l'installation de ''apt install fail2ban'' !
  
-==== protéger SSH ====+Il y a une [[doc:formations:hebergement:serveur:proteger:fail2ban|page dédiée]] à cet outil.
  
-Pour SSH spécifiquement, on recommande systématiquement l'installation de ''apt install fail2ban''.  
  
-C'est un système qui observe vos tentatives d'accès à votre serveur et qui bannit automatiquement et temporairement les adresses IP qui tentent de rentrer abusivement. C'est très efficace et ça réduit la taille de ''/var/log/auth.log'' (ce qui le rend plus lisible donc plus efficace).+===== portsentry: intercepter les tentatives de scan de ports ======
  
-Par défaut il protège SSH sur son port 22, en analysant les abus et erreurs d'authentification dans son fichier ''/var/log/auth.log''.+Cet outil peut s'installer pour repérer et agir contre des outils d'intrusion qui "scannent" les ports habituels servant de vecteurs d'attaque sur un serveur. Presque systématiquement, un client qui essaye de nombreux ports consécutivement "pour voir si ça mord" n'est pas un client normal.
  
-:!: si l'on a changé le port du serveur SSH en 12345, il faudra le dire à fail2ban. Créez ou modifiez le fichier ''/etc/fail2ban/jail.local'' (pensez à ''service fail2ban restart'' une fois édité): +  apt install portsentry 
-<code>+  ss -tunlp|grep portsentry  # pour montrer les ports surveillés par portsentry
  
-[ssh] +Par défaut cet outil ne fait que logguer des événements dans le journal ''/var/log/syslog'', qui pourrait être traité lui-même par ''failtoban'' comme ci-dessus. Mais bien plus efficace, on peut directement configurer ''portsentry'' ainsi que les ports surveillés pour bannir le client. Voyez [[https://le-guide-du-secops.fr/2020/10/12/portsentry-un-outil-pour-contrer-et-bloquer-les-scans-de-ports/|ce tutoriel]] par exemple.
- +
-enabled  = true +
-port     = 12345 +
-filter   = sshd +
-logpath  = /var/log/auth.log +
-maxretry = 6 +
- +
-</code> +
- +
-==== Tentatives d'accès "brute force" ==== +
- +
-''fail2ban'' peut être facilement utilisé pour déclencher une action de barrage sur la base d'expressions régulières trouvées "trop souvent" dans un ou plusieurs fichiers journaux. +
- +
-Par exemple, pour protéger d'accès intempestifs sur votre serveur web nginx vous pouvez créer le fichier de détection ''/etc/fail2ban/filter.d/nginx-forbidden.conf'': +
- +
-<code> +
-[Definition] +
-failregex = ^ \[error\] \d+#\d+: .*directory index.*forbidden.*, client: <HOST>, .*$ +
-            ^ \[error\] \d+#\d+: .*Connection refused.*, client: <HOST>, .*$ +
- +
-# On cherche à collecter les adresses IP des lignes suivantes: +
-#   2022/04/16 17:49:16 [error] 16133#16133: *12898 directory index of "/home/www/dl.tecrd.com/" is forbidden, client: 185.59.221.123, server: dl.tecrd.com, request: "GET / HTTP/1.1", host: "dl.tecrd.com" +
-#   2022/04/16 17:49:14 [error] 16133#16133: *12882 connect() failed (111: Connection refused) while connecting to upstream, client: 185.59.221.123, server: visio.tecrd.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:9900/", host: "visio.tecrd.com" +
- +
-ignoreregex =  +
-</code> +
- +
-Le fichier d'action qui l'accompagne est ''/etc/fail2ban/jail.d/nginx-forbidden.conf'': +
-<code> +
-[nginx-forbidden] +
-enabled = true +
-filter = nginx-forbidden +
-port = http,https +
-logpath = /var/log/nginx/*error*.log +
-findtime = 60 +
-bantime = 2000 +
-maxretry = 4 +
-</code> +
- +
- +
-Fail2ban permet de tester en amont la validité des règles, mais aussi d'avoir des statitsiques, par exemple ici avec: +
- +
-<code> +
-fail2ban-client status nginx-forbidden +
-Status for the jail: nginx-forbidden +
-|- Filter +
-|  |- Currently failed: 0 +
-|  |- Total failed: 15 +
-|  `- File list: /var/log/nginx/test-main.error.log /var/log/nginx/bbb.tecrd.com.error.log /var/log/nginx/ccc-gen.error.log /var/log/nginx/error.log +
-`- Actions +
-   |- Currently banned: 1 +
-   |- Total banned: 2 +
-   `- Banned IP list: 176.164.85.123 +
-</code>+
  
 +__Note__ je vous conseille d'ajouter une ou plusieurs adresses IP "fiables" dans le fichier ''/etc/portsentry/portsentry.ignore.static'' qui ne seront jamais bannies avant d'activer des réactions plus agressives envers le client.
  
 ===== Firewall: restreindre l'accès a des services à des IP connues ===== ===== Firewall: restreindre l'accès a des services à des IP connues =====
Ligne 226: Ligne 175:
 Il s'agit d'un système de configuration plus récent que iptables. Il est un peu moins répandu mais il est réputé un peu plus facile à l'usage si l'on ne connait pas déjà iptables.  Probablement un bon investissement. Il s'agit d'un système de configuration plus récent que iptables. Il est un peu moins répandu mais il est réputé un peu plus facile à l'usage si l'on ne connait pas déjà iptables.  Probablement un bon investissement.
  
 +Exemple pour autoriser les clients 10.34.0.* à accéder au service web local:
 +
 +  ufw allow from 10.34.0.0/8 to 10.34.0.1 port 80
 +
 +Pour lister les règles ''ufw status numbered'' (ce qui permet de retirer une règle avec ''ufw delete N'').
 ==== Via un serveur filtrant amont ==== ==== Via un serveur filtrant amont ====
  
doc/formations/hebergement/serveur/proteger.1655213945.txt.gz · Dernière modification : 2022/06/14 13:39 de jeremie