protéger domoticz depuis acces internet

[el_gringo]

Bonjour,
J'ai constaté des attaques par force brute en SSH depuis internet.

J'ai donc installé fail2ban et je vois que ça protège assez bien l'accès SSH et j'aimerais savoir comment protéger les autres ports ?
Comment peut on protéger le port 80 ?

Avez-vous modifier les paramètres suivants :
sudo nano /etc/fail2ban/jail.local
si oui, comment ?
merci,

[lost]

J'ai donc installé fail2ban et je vois que ça protège assez bien l'accès SSH et j'aimerais savoir comment protéger les autres ports ?
Comment peut on protéger le port 80 ?

Déjà, ne pas laisser sortir le port 80 (ou 8080 par défaut)qui est du http en clair: N'importe qui sur ta branche de réseau (ou un wifi non chiffré) peut capturer tes identifiants/mot de passe.

Il faut mettre le https en route (voir wiki pour créer un certificat autosigné, à minima, à faire accepter de son LAN en exception des navigateurs que l'on utilisera à distance).

Ensuite, fail2ban reposant sur une analyse des logs, il faudra pour lui faire barrer une IP responsable de trop d'échecs sur un temps donné modifier le script de démarrage de Domoticz pour envoyer ses logs dans un fichier externe, identifier la chaîne de caractère qui résulte d'un login en echec et ajouter une règle adaptée dans la config de fail2ban et redémarrer le service pour prise en compte.

Mais normalement Domoticz renvoie déjà à minima vers une page "trou du cul de l'internet" au bout d'un certain nb d'échecs même si barrer niveau firewall est plus efficace.

Pour ma part, je trouve que le https est très peu attaqué. Les IP qui accèdent à la page login par ce biais, avec un coup de whois, sont majoritairement des robots d'indexation du web qui lâchent l'affaire immédiatement.

Jamais vu une tentative de brute-force, contrairement à SSH ou c'est rapidement plusieurs par minute (et souvent, une IP est barrée et une autre, contrôlée sans doute par le même robot de brute-force, reprends dans la minute avec la suite visible des noms d'utilisateurs essayés, faisant de fail2ban un outils pas forcément efficace dans la cadre de qqun qui a à disposition un grand nombre d'IP de machines vérolées qu'il peut faire tourner pour relayer ses attaques).

=> Mets déjà en route https (port 443 par défaut) et ne laisse plus le http (un véritable appeau!) sortir avant d'envisager une suite éventuelle.

[adv]

J'ai constaté des attaques par force brute en SSH depuis internet.

Salut,

Woops, tu laisses le port 22 ouvert ?

Laisser le 443 pour Domoticz OK, mais 22 ça me semble un peu risqué, si besoin de te connecter au terminal à distance je m'orienterai plutôt sur une solution style openVPN à ta place.

Enfin c'est que mon avis, c'est vrai qu'avec Fail2Ban tu te couvres un peu.

Fais des backups de la base on sait jamais

A+

[marc_bzh]

Pour le SSH il faut déja activer l'authentification par clé et par la suite tu désactive la connexion par mot de passe

[el_gringo]

Bonjour à tous et merci pour vos réponses,

En fait, le port 443 est déjà actif sur Domoticz, donc au lieu d'utiliser le port 8080, on peut ouvrir le port 443, fermer le port 8080 et un avertissement indique un risque pour ce site mais une fois validé, l'accès à distance fonctionne dans un navigateur.

Un certificat autosigné enlève simplement l'avertissement mais si je suis seul à utiliser cet outil, à quoi bon s’embêter à créer un certificat ?
Cela renforce t-il la sécurité ?

Merci pour vos explications, ils sont d'une grande aide pour comprendre les tentatives d'intrusion des robots.
Fail2ban est en effet une protection contre les attaques.
Je l'utilise pour SSH mais j'ai bien compris maintenant que le mieux était d'ouvrir le port 22 uniquement quand j'en ai besoin.
Je le ferme et l'ouvre si besoin en passant par ma box internet.

[lost]

Fail2ban est en effet une protection contre les attaques.
Je l'utilise pour SSH mais j'ai bien compris maintenant que le mieux était d'ouvrir le port 22 uniquement quand j'en ai besoin.
Je le ferme et l'ouvre si besoin en passant par ma box internet.

Le problème étant qu'il faut, idéalement, pouvoir le faire de dehors quand on en a besoin. J'espère que tu n'as pas ouvert l'administration distante de la box pour ce faire, ce serait vraiment troquer la peste pour le choléra!

Sur une machine dont on maîtrise la configuration (pas le cas d'une box), il y a la possibilité d'ouvrir un port à la demande. Cela s'appelle le port knocking: Dans sa version la plus simple, c'est une séquence de connexions TCP ou UDP sur des numéros de ports déterminés qui ouvrira le port de son choix, juste pour l'IP demandeuse qui aura fait la bonne séquence.

Il est possible de se choisir une suite facile à retenir, genre 1234 5678 9876, qui va provoquer l'ouverture du 22.

Côté box, on veille à avoir 1234 5678 9876 et 22 ouverts (+443 pour le HTTPS, non concerné par cette manip) vers son PI. Sur le PI on active le firewall (genre UFW, en mode "default deny" et ne laissant passer par défaut que le 443 "ufw allow from any to any port 443"), installe un démon type knockd et on le paramètre. Ici cela donnerait un truc du genre (fichier /etc/knockd.conf):

Code : Tout sélectionner

[options]
	logfile = /tmp/knockd.log

[openCloseSSH]
	sequence      = 1234,5678,9876
        seq_timeout   = 15
#	tcpflags      = syn,ack
        start_command = ufw allow from %IP% to any port 22
	cmd_timeout   = 30
        stop_command  = ufw delete allow from %IP% to any port 22

Sur réception par le PI de la bonne séquence (envoyé par un client knock), on ouvre le port 22 pour 30s. Cela donne 30s pour se connecter derrière en ssh (une fois la connection établie, le firewall peut refermer le port, le conntrack est là pour la conserver tant qu'elle reste établie).

Attention, si on veut utiliser le http de son LAN, à avoir une règle pour lui seul, genre ""ufw allow from 192.168.1.0/24 to any port 8080". En mode "default deny", tout ce qui n'est pas explicitement autorisé à entrer reste dehors!

Pour ma part, je préfère un combo knockd (+fail2ban, qui se retrouve alors en seconde ligne de défense au cas ou qqun sniffe ma séquence sur un réseau ouvert même si peu probable) et ssh restant par mot de passe: Se balader avec sa clef ssh est contraignant (une clef USB à avoir sur soi avec sa clef publique) si on veut pouvoir au besoin se connecter de machines pas à soi/avec leur ssh non configuré avec sa clef.

Je retiens mieux une séquence de ports qu'une clef ssh et installer la partie client ne requiert aucun droit particulier (choisir des ports > 1024 pour la séquence de knock, afin de ne pas avoir de pb de droits à l'utilisation côté client).

[el_gringo]

Je ne vois pas trop où est le danger d'administrer sa box à distance.
J'ai un mot de passe fort.
Mon ip publique n'est pas fixe.
L'accès en https est une connexion chiffrée.

Par contre, c'est vrai que je n'ai pas d'historique des tentatives de connexions à celle-ci (contrairement à SSH).

Fail2ban et port knocking ne sont pas infaillibles mais cela permet de sécuriser l'accès distant à SSH.

En tout cas, le port knocking est très intéressant, je te remercie pour ces infos et tes conseils, je vais expérimenter cette méthode.
On en apprend tous les jours, c'est super.

[ccyril91]

De nos jours les simples authentifications login/mot de passe ne sont plus du tout sécurisées pour des services exposés sur internet. Fail2ban est INDISPENSABLE. Et de faire des tests périodiques pour savoir s'il détecte bien.
Une authentification SSH avec un bi-clé est beaucoup plus sécurisée (merci la cryptographie), et au passage plus simple car on utilise des logiciels tels que Keepass qui facilitent la vie.

Le fait d'avoir une @ip publique dynamique ne change rien au problème, ce sont des robots qui passent sur les blocs d'adresse entiers.

Le fait de se connecter en HTTPS plutôt qu'en HTTP ne couvre que le risque d'interception de mot de passe dans le cas par exemple où tu te connecte via un wifi vérolé. En aucun cas cela te protège des attaques par force brute ou via une éventuelle faille de sécurité dans Domoticz (ce qui arrive même aux meilleurs)

Après tout dépend ce que tu as à pirater chez toi ... , de tes compétences en informatique, et de ton degré de paranoia.