Différences

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

--- doc:formations:hebergement:serveur:proteger [2022/07/26 16:11] – [portsentry: intercepter les tentatives de scan de ports] 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 127: / Ligne 129: @@
 Vous trouverez bien d'autres options [[https://doc.ubuntu-fr.org/sudoers|ici]].
 ===== 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).
-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é):
-<code>
-[ssh]
-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 statistiques, 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>
@@ Ligne 206: / Ligne 144: @@
   ss -tunlp|grep portsentry  # pour montrer les ports surveillés par portsentry
-Par défaut cet outil ne fait que logguer des événements dans le journal ''/var/log/syslog'', qui peut etre lui meme surveillé par ''failtoban''. Plus efficace, on peut directement reconfigurer ''portsentry'' et les ports surveillés, par exemple pour bannir le client lui-même. 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.
+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.
 __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.
@@ Ligne 237: / 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 ====