Différences

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

--- doc:formations:hebergement:serveur:proteger [2022/06/14 13:36] – [Sudo, utilisateurs privilégiés et sudoers] jeremie
+++ doc:formations:hebergement:serveur:proteger [2024/02/19 18:56] (Version actuelle) – [Via le nouveau ufw] jeremie
@@ Ligne 2: / Ligne 2: @@
 ====== 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!
@@ 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:
@@ 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.
@@ Ligne 113: / Ligne 115: @@
 Mais il existe un autre moyen intermédiaire et très utile pour autoriser l'exécution d'une commande privilégiée par un utilisateur normal. Pour cela on passe par le fichier ''/etc/sudoers'', à éditer avec la commande ''visudo''.
-Par exemple, si vous souhaitez qu'un utilisateur ''www-uploader'' puisse relancer le serveur postgresql, et seulement cette action, vous pouvez créer un shell ''/usr/local/bin/postgre_restart.sh'' qui contient ceci:
+Par exemple, si vous souhaitez qu'un utilisateur ''www-uploader'' puisse relancer le serveur postgresql et sans devoir saisir de mot de passe (typiquement pour un déploiement automatisé), vous pouvez créer un shell ''/usr/local/bin/postgre_restart.sh'' qui contient ceci:
 <code>
@@ Ligne 120: / Ligne 122: @@
 </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=(ALL) 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
-===== 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.
+Vous trouverez bien d'autres options [[https://doc.ubuntu-fr.org/sudoers|ici]].
-==== protéger SSH ====
+===== fail2ban en défense contre les accès "brute force" =====
-Pour SSH spécifiquement, on recommande systématiquement l'installation de ''apt install fail2ban''.
+Pour SSH au moins, 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).
+Il y a une [[doc:formations:hebergement:serveur:proteger:fail2ban|page dédiée]] à cet outil.
-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''.
-:!: 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é):
+===== portsentry: intercepter les tentatives de scan de ports ======
-<code>
-[ssh]
+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.
-enabled  = true
+  apt install portsentry
-port     = 12345
+  ss -tunlp|grep portsentry  # pour montrer les ports surveillés par portsentry
-filter   = sshd
-logpath  = /var/log/auth.log
-maxretry = 6
-</code>
+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.
-==== 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 =====
@@ Ligne 224: / 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.
+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 ====