[Résolu] Sécurité de son serveur

sputnick · Le 18/02/2024, à 21:12

C'est l'ensemble des recommandations qui sont valables suivant les cas.

Aucune mesure ne se suffit à elle même.

Comme déjà expliqué, fail2ban réduit la surface d'attaque. Rien de magique, cela n’empêche pas une bonne gestion de mot de passe ou mieux, une clef ssh 4096 bits poussé par Ansible.

Un mot de passe généré par keepassxc de 24 caractères, est quasi incassable.

Edit:

Et il me semble que personne n'en a parlé, mais configurer iptables n'est pas un luxe.

Tu peux y définir qui fait quoi, quand, comment et sur quel port tcp et ou udp.

Dernière modification par sputnick (Le 18/02/2024, à 21:29)

jplemoine · Le 18/02/2024, à 23:42

sputnick a écrit :

Et il me semble que personne n'en a parlé, mais configurer iptables n'est pas un luxe.

En fait, j'ai proposé fail2ban + GeoIP : de mémoire, ça configure les iptables. Si oui, ça revient au même ? ou pas ?

sputnick · Le 19/02/2024, à 00:06

Ben tu peux configurer fail2ban ET iptables séparément.

Par exemple, autoriser les port 80/443 dans iptables, mais ban si il y a N requêtes HTTP en erreur 403/404/4*/5*, alors ban.

C'est 2 choses différentes.

Oui, GeoIP selon les besoins et les services.

On peut bloquer des ranges d'IP dans iptables ou dans le serveur web, nginx par exemple.

Après avoir identifiée un AS aka Autonomous System, on peut le bloquer en récupérant les ranges d'IP sur https://bgp.he.net/ avec l'ASN

Dernière modification par sputnick (Le 19/02/2024, à 01:11)

jplemoine · Le 19/02/2024, à 00:22

Ok. Merci pour les précisions.

sputnick · Le 19/02/2024, à 01:27

Les 40* et 50*, sont dues à des tentatives d'accéder de façon malveillante à des ressources 'cachées'.

Quelques exemples:

GET /phpinfo.php
GET /phpinfo
GET /.git/config
GET /.well_known/xxx
GET /.env
GET /admin/.env
GET /admin
HEAD /backup
GET /wordpress
GET /wp-login.php
GET /priv8.php
POST /scripts/WPnBr.dll
...

Dernière modification par sputnick (Le 19/02/2024, à 01:27)

bruno · Le 19/02/2024, à 09:07

L’expression surface d’attaque à un sens bien précis, rappel :

bruno a écrit :

Et cela n'a pas grand chose à voir avec ce que l'on appelle la surface d'attaque car cela ne joue pas sur l'exposition du système aux attaques.

Ne pas installer de services inutiles ou ne pas en exposer publiquement réduit la surface d'attaque.

sputnick a écrit :

Ben tu peux configurer fail2ban ET iptables séparément.

Tu veux dire nftables, iptables n'est plus l'interface de filtrage par défaut sur les distributions majeures et a tendance a être abandonnée progressivement depuis quelques années.

sputnick a écrit :

Par exemple, autoriser les port 80/443 dans iptables, mais ban si il y a N requêtes HTTP en erreur 403/404/4*/5*, alors ban.

Ainsi le malheureux utilisateur qui se trompe d'URL est insiste un peu se verra refuser l'accès au site. Et bloquer des clients sur des erreurs HTPP 500, donc des erreurs du serveur, je rigole J''espère que tu n'administres pas de serveurs web…

Quant à bloquer des plages d'IP entières voire des ASN complets, c'est vraiment que tu veux que tes services ne soient accessibles qu'à tes voisins.

matrix-bx · Le 19/02/2024, à 09:49

Je ne serai guère surpris d'apprendre que certains souffrent de douleurs cervicales chroniques.

/me out.

bruno · Le 19/02/2024, à 10:18

@matrix-bx : pas compris la blague …

--
Pour en revenir au sujet d'origine :

J'ai 2 serveurs Ubuntu à la maison :
- un qui tourne sur un ancien PC qui me sert de serveur vidéo.
- un autre sur Raspberry avec serveur Apache et Nextcloud

Le serveur vidéo ne doit probablement être accessible que localement. Il faut donc mettre le service en écoute que sur le réseau local et ne pas rediriger les flux entrants sur la box vers ce service.

La box doit uniquement rediriger les paquets entrants sur 80,4433 vers les m^mes port de ton Raspberry.

Pour le serveur Apache j'omets les indispensables mises à jour dès qu'elles paraissent (on peut automatiser avec unattended-upgrades), le point faible c'est toujours les applications web installées. Dans ton cas Nextcloud oit être mis à jour dès que possible : il n'y a pas d'automatisation mais tu peux recevoir les notifications. Les comptes utilisateurs doivent avoir des mots de passe très solide (surtout les admins) et si tu n'as pas confiance tu peux activer l’authentification à double facteur (chiant à tout point de vue).

randoo · Le 19/02/2024, à 11:11

Bonjour à tous.

Je ne pensais pas que mes questions allaient créer un débat pareil. Lol
Je vous remercie de toutes les informations que vous m'avez apporté.

J'accède à mes serveurs via SSH uniquement via le réseau local. Du coup, est ce que je peux configurer mes serveurs pour accepter uniquement les IP locales (192.168.x.x) pour les connexions SSH ? Mais je vais, par sécurité, changer les ports SSH, ...

Je vous remercie aussi pour les conseils de base pour la sécurité (mot de passe fort, Keepass, mise à jour, ...), ne vous inquiétez pas, je fais déjà attention à tout ca, je fais même de la prévention à mon petit niveau autour de moi.

Cordialement
Randoo

bruno · Le 19/02/2024, à 12:32

Oui tu peux configurer le serveur SSH pour que seules les IP locales y aient accès, avec des directives du type dans sshd_config :

ListenAddress 192.168.1.12

(en remplaçant par l'IP locale du serveur, voir la page de man pour plus d'infos.)
Mais ce n'est pas très utile si ta box ne redirige pas le trafic vers le serveur SSH et c'est encore moins utile de changer le port par défaut.

O_20_100_O · Le 19/02/2024, à 12:42

Bonjour,
Et ne pas oublier les IPv6 dans les réglages vus plus haut.

Dernière modification par O_20_100_O (Le 19/02/2024, à 12:43)

krodelabestiole · Le 19/02/2024, à 20:47

- mettre un fail2ban : sshd + recidive

un f2b sur un service qui n'est accessible qu'en local !?
vous comptez bannir les IPs locales ?

randoo a écrit :

Mais je vais, par sécurité, changer les ports SSH, ...

Nuliel a aussi démontré qu'il était inutile et plutôt contre-productif de changer de port, point de vue sécurité, justement. et il est encore plus complètement inutile et seulement contre-productif de changer le port d'un service local (il n'y aura de toute façon pas de garbage dans les logs).

vu le résultat j'aurais tendance à penser que randoo aurait pu juste copier coller les recommandations qu'on trouve en vrac sur le web, comme s'il était inutile d'adapter la sécurité au contexte et au niveau nécessaire, ou de comprendre ce qu'on fait, au risque de se bannir lui-même et seulement lui.

randoo a écrit :

Donc, on est d'accord, que la Livebox sert de pare-feu, et qu'on ne peut accéder depuis l'extérieur que sur mes 2 serveurs, et pas sur les autres appareils ?
Étant donné que je n'ai ouvert que certains ports, on ne peut pas accéder à mes serveurs via SSH par exemple depuis l'extérieur puisque je n'ai pas ouvert le port concerné ?

que sur les serveurs et sur les ports en écoute et redirigés (http(s))
ça avait pourtant l'air assez clair à l'origine (à part le part-feu sur le serveur qui ne sert effectivement à rien).
certains service UPnP peuvent ouvrir des ports automatiquement et exposer d'autres services, il faut surtout surveiller l'ensemble des appareils locaux. si tu es friand d'IoT, caméras IP, prises connectées et autres gadgets domotiques, ça peut valoir le coup créer deux sous-réseaux isolés (mieux vaut simplement éviter, ou veiller à complètement exclure les technologies propriétaires).

si tu veux mettre un f2b c'est seulement sur les services accessibles de l'extérieur : les formulaires de connexion de nextcloud ou jellyfin (les APIs utilisent des clés / token) et ce n'est pas indispensable (c'est généralement plus gênant qu'autre chose), contrairement à l'emploi de mots de passe fort.

c'est quoi exactement que tu appelles un "serveur vidéo" ? jellyfin ?

jplemoine · Le 19/02/2024, à 22:01

krodelabestiole a écrit :

- mettre un fail2ban : sshd + recidive
un f2b sur un service qui n'est accessible qu'en local !?
vous comptez bannir les IPs locales ?

Bien sûr que non. C'est moi qui ait induit en erreur : je pensais que le ssh était accessible depuis l'extérieur.
Désolé.

sputnick · Le 19/02/2024, à 22:13

bruno a écrit :

L’expression surface d’attaque à un sens bien précis, rappel :
Et cela n'a pas grand chose à voir avec ce que l'on appelle la surface d'attaque car cela ne joue pas sur l'exposition du système aux attaques.
Ne pas installer de services inutiles ou ne pas en exposer publiquement réduit la surface d'attaque.

Tu joue sur les mots. On parle de réduire les risques...

bruno a écrit :

Tu veux dire nftables, iptables n'est plus l'interface de filtrage par défaut sur les distributions majeures et a tendance a être abandonnée progressivement depuis quelques années.

Tu joue (encore) sur les mots, un firewall si tu préfère. Je note nftable, merci de l'info. J'utilise iptables depuis 20 ans et suis à l'aise avec.

bruno a écrit :

sputnick a écrit :
Par exemple, autoriser les port 80/443 dans iptables, mais ban si il y a N requêtes HTTP en erreur 403/404/4*/5*, alors ban.
Ainsi le malheureux utilisateur qui se trompe d'URL est insiste un peu se verra refuser l'accès au site. Et bloquer des clients sur des erreurs HTPP 500, donc des erreurs du serveur, je rigole J''espère que tu n'administres pas de serveurs web…

Oui, les erreurs 500 sont une erreur de ma part, mais le principe de bloquer les erreurs 40* reste. Je ne bloque effectivement pas les erreurs 50*.

bruno a écrit :

Quant à bloquer des plages d'IP entières voire des ASN complets, c'est vraiment que tu veux que tes services ne soient accessibles qu'à tes voisins.

Ça dépends de tes besoins en fonction des services. Par exemple, imagine un gitlab accessible que par certains devs utilisant des IPs particulières (juste un exemple), ben ça peut être intéressant de n'autoriser que les IPs habituelles.

Concernant nextcloud, pour être informé des mises à jour rapidement, j'utilise ce cron:

* * * * * cd /var/www/nextcoud; s=$(php8.2 occ update:check); if ! grep -q 'Everything up to date' <<< "$s"; then s-nail -s "$s" me@sputnick.fr </dev/null &>/dev/null; fi

Bien sur, je n'utilise pas

* * * * *

pour de vrai (toutes les minutes).

NicoApi73 · Le 20/02/2024, à 10:00

Bonjour,

@randoo : Ton pare-feu c'est ta box. S'il est franchi, rien n'arrêtera un attaquant. Tu pourrais mettre en place une DMZ, ce qui n'a que très peu d'intérêt dans le cadre d'un réseau privé.

Si tu veux renforcer la sécurité, en ayant déjà mis en place les bases (mots de passe ou passephrase fort, ce qui correspond à une entropie >85 bits), il faut passer par une authentification à double facteur pour ce qui concerne les attaques en ligne.

Si un de tes serveurs est compromis, pour protéger les données sensibles d'une attaque hors-ligne, il faut chiffrer (par exemple, avec veracrypt), en utilisant un mot de passe fort et une clé de chiffrage (qui ne doit pas être accessible en ligne bien entendu)

@sputnick :

sputnick a écrit :

On parle de réduire les risques...

La réduction de risques passe par l'authentification multifacteur, éventuellement associée à une limitation des essais d'authentification. (Fail2Ban ne permet pas de réduire le nombre d'essai puisqu'un attaquant utilisera plusieurs adresses IP.)

sputnick a écrit :

bruno a écrit :
Tu veux dire nftables, iptables n'est plus l'interface de filtrage par défaut sur les distributions majeures et a tendance a être abandonnée progressivement depuis quelques années.
Tu joue (encore) sur les mots, un firewall si tu préfère. Je note nftable, merci de l'info. J'utilise iptables depuis 20 ans et suis à l'aise avec.

Non, ce n'est pas un firewall. C'est une interface. Le firewall est intégré dans le noyau linux, plus précisément dans netfilter. nftables remplace iptables, ebtables et arptables.

sputnick a écrit :

bruno a écrit :
Quant à bloquer des plages d'IP entières voire des ASN complets
Ça dépends de tes besoins en fonction des services. Par exemple, imagine un gitlab accessible que par certains devs utilisant des IPs particulières (juste un exemple), ben ça peut être intéressant de n'autoriser que les IPs habituelles.

Quand on ne doit autoriser un service qu'à un nombre limité de machines, on autorise ces machines et on bloque tout le reste. Le cas échéant, il y aura toujours une faille. Par conséquent, bloquer des plages complètes (comme suggéré précédemment) est en général une mauvaise pratique.

EDIT : typo

Dernière modification par NicoApi73 (Le 20/02/2024, à 12:25)

jplemoine · Le 20/02/2024, à 10:56

NicoApi73 a écrit :

Si un de tes serveurs est compris,

Compromis ?

NicoApi73 · Le 20/02/2024, à 12:25

jplemoine a écrit :

NicoApi73 a écrit :
Si un de tes serveurs est compris,
Compromis ?

oui, merci. Typo corrigée

randoo · Le 20/02/2024, à 13:00

Encore merci pour toutes vos informations. Je voulais être sur de comprendre ce que je faisais et ne pas ouvrir la porte grande ouverte. Vous m'avez apporté beaucoup de choses, je vais faire le tri. Lol

krodelabestiole a écrit :

c'est quoi exactement que tu appelles un "serveur vidéo" ? jellyfin ?

C'est le genre là, puisque c'est Emby.

sputnick · Le 20/02/2024, à 13:55

@NicoApi73:

Quand on ne doit autoriser un service qu'à un nombre limité de machines, on autorise ces machines et on bloque tout le reste. Le cas échéant, il y aura toujours une faille. Par conséquent, bloquer des plages complètes (comme suggéré précédemment) est en général une mauvaise pratique.

C'est tout à fait un usage légit', par exemple quelqu’un qui a une seedbox sur son serveur pour ban certains range d'IP connus comme nuisibles.

Pour firewall VS interface de firewall, toi aussi tu joue sur mes mots ce qui reste à retenir c'est de créer des règles de filtrage IP.

bruno · Le 20/02/2024, à 16:04

sputnick a écrit :

bruno a écrit :
Quant à bloquer des plages d'IP entières voire des ASN complets, c'est vraiment que tu veux que tes services ne soient accessibles qu'à tes voisins.
Ça dépends de tes besoins en fonction des services. Par exemple, imagine un gitlab accessible que par certains devs utilisant des IPs particulières (juste un exemple), ben ça peut être intéressant de n'autoriser que les IPs habituelles.

Dans ce cas le filtrage par IP se fait au niveau de la configuration de GIT.
Si un service ne permet pas de filtrer par IP directement dans sa configuration on le fait avec des règles de pare-feu en bloquant tout puis en autorisant ce qui doit l'être, pas en bloquant des plages d'Ip au petit bonheur la chance…

sputnick a écrit :

Concernant nextcloud, pour être informé des mises à jour rapidement, j'utilise ce cron:
* * * * * cd /var/www/nextcoud; s=$(php8.2 occ update:check); if ! grep -q 'Everything up to date' <<< "$s"; then s-nail -s "$s" me@sputnick.fr </dev/null &>/dev/null; fi
Bien sur, je n'utilise pas
* * * * *
pour de vrai (toutes les minutes).

Ça c'est particulièrement absurde et inutile puisque nextcloud offre déjà par défaut, une tâche planifiée (ajax, webcron, cron ou timer systemd) qui vérifie cela toutes les 5 minutes. Voir dans Nextcloud, Paramètres d'administration > paramètres de base et si besoin lire
https://docs.nextcloud.com/server/lates … ation.html

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 18/02/2024, à 21:12

Re : [Résolu] Sécurité de son serveur

#27 Le 18/02/2024, à 23:42

Re : [Résolu] Sécurité de son serveur

#28 Le 19/02/2024, à 00:06

Re : [Résolu] Sécurité de son serveur

#29 Le 19/02/2024, à 00:22

Re : [Résolu] Sécurité de son serveur

#30 Le 19/02/2024, à 01:27

Re : [Résolu] Sécurité de son serveur

#31 Le 19/02/2024, à 09:07

Re : [Résolu] Sécurité de son serveur

#32 Le 19/02/2024, à 09:49

Re : [Résolu] Sécurité de son serveur

#33 Le 19/02/2024, à 10:18

Re : [Résolu] Sécurité de son serveur

#34 Le 19/02/2024, à 11:11

Re : [Résolu] Sécurité de son serveur

#35 Le 19/02/2024, à 12:32

Re : [Résolu] Sécurité de son serveur

#36 Le 19/02/2024, à 12:42

Re : [Résolu] Sécurité de son serveur

#37 Le 19/02/2024, à 20:47

Re : [Résolu] Sécurité de son serveur

#38 Le 19/02/2024, à 22:01

Re : [Résolu] Sécurité de son serveur

#39 Le 19/02/2024, à 22:13

Re : [Résolu] Sécurité de son serveur

#40 Le 20/02/2024, à 10:00

Re : [Résolu] Sécurité de son serveur

#41 Le 20/02/2024, à 10:56

Re : [Résolu] Sécurité de son serveur

#42 Le 20/02/2024, à 12:25

Re : [Résolu] Sécurité de son serveur

#43 Le 20/02/2024, à 13:00

Re : [Résolu] Sécurité de son serveur

#44 Le 20/02/2024, à 13:55

Re : [Résolu] Sécurité de son serveur

#45 Le 20/02/2024, à 16:04

Re : [Résolu] Sécurité de son serveur

Pied de page des forums