Depuis quelques années (10/15, mince ça passe vite), j’héberge mes services à la maison au frais dans le garage sur un serveur physique, des VMs et depuis peu des instances cloud. Moi, ma petite famille et un cercle d’amis en sont les seuls utilisateurs. Un peu comme beaucoup de monde ici sans doute.
Un soir, j’installe Grafana/Prometheus pour me former et constate les scans en continu des bots sur tout ce qui est exposé. Bon, je ne suis pas un jeunot, je m’en doutais, mais quand même, ça se bouscule pas mal…
N’étant pas à l’abri de louper une mise à jour de temps en temps, ça ne me plaît pas beaucoup et je cherche comment améliorer tout ça, et voici comment…
Les pistes
Jour 1 : la solution VPN ! C’est cool, ça protège des virus selon le VPN du Nord ou OpenOffice en son temps. Ah non, la ministre pensait que c’était un pare-feu… (cf lien 5)
Et oui, c’est bien, mais il faut gérer les authentifications, installer les clients, croiser le regard de ses proches (« Mais pourquoi 😢 »). La nuit passe, il faut trouver autre chose.
Jour 2 : le bastion ssh, les proxies socks. C’est marrant, tout terrain et ça fonctionne. Mais bon on va garder ça pour soi au travail. Ce serait un remake en pire du jour un… Next !
Jour 3 : port-knocking ! On toque à la porte d’un serveur avec la bonne séquence udp ou tcp et il ouvre des règles de pare-feu. C’est propre, il y a des clients disponibles sur quasiment tous les appareils. C’est presque idéal, mais ça reste quand même technique, très, trop…
Jour 4 : 😰 pas grand-chose de neuf.
Jour 5 : je me rappelle mes quelques mois à développer un premier projet opensource 🤔. Si ça n’existe pas, on le code et on le partage ! C’était le bon temps ! Go, on se retrousse les manches.
On code !
Mois 1 : maquette sous django, base de données mariadb et installation conteneurisée. Ça fait le boulot, mais ce n’est pas superléger. J’ai l’impression d’enfoncer un clou avec une masse.
Mois 2 : ça fait le boulot et c’est quand même bien pratique. Mes instances nextcloud et bitwarden par exemple sont accessibles via des liens « tiers » que je donne à mes proches. Quand ils vont dessus, leurs ip clientes sont lues et le pare-feu les autorise directement. Ils sont redirigés quelques secondes après et utilisent tout ce qu’ils connaissent normalement sans nouveau passage par MySafeIP.
C’est aussi la première fois que j'ai si peu d’état d’âme à avoir des données personnelles en ligne.
Les bots eux se cassent les dents, je jubile 😏.
Mois 3 : le partager en l’état ? Il faudrait faire plus léger. Découverte de Fastapi, bootstrap. On ressort clavier/souris. Fastapi est bluffant dans un autre registre que Django 🤩. Le potentiel est là et la documentation est pléthorique pour un projet aussi jeune. C’est très, très motivant et j’ai quelques idées pour la suite :).
MySafeIP en bref
Après cette longue introduction, mais qui résume bien le besoin et les contraintes de ce genre d'outil, voici en bref ce qu'est MySafeIP.
MySafeIp est une application opensource (Apache-2.0) servant de tiers de confiance pour tenir à jour dynamiquement des IPs de confiance :
- soit déclarées manuellement après authentification ;
- soit automatiquement via des liens à la manière d’un raccourcisseur d’url mais dont la redirection permet la lecture de l’IP cliente et son autorisation.
L’ensemble est basé sur les framework Fastapi (backend) et Bootstrap/jinja (UI). L’interface d’administration web est compatible pc/smartphone.
Ça s’installe facilement :
L’installation est conteneurisée côté serveur et un petit module python est disponible pour assurer la récupération des IPs côté pare-feu. Je fournis aussi le script permettant de régler à minima iptables en se basant sur ipset 🥳.
En bref, cela s’installe en 5 minutes via docker-compose (oui, c’est un peu vendeur, disons 15 minutes en comptant le client 😜) et ajoute un filtrage fin en entrée de tous vos services sans effaroucher pour autant vos utilisateurs.
Côté authentification, login/mot de passe et deux facteurs (TOTP) pour l’administration web, Tokens pour le module client (gérables depuis l’application).
Vous pouvez enfin autoriser ou non l’enregistrement d’utilisateurs qui voudraient s’en servir pour leurs propres services. Il est, de plus, disponible en français et anglais.
Vous savez presque tout, j’espère qu’il vous rendra autant service qu’à moi.
Je le considère en version Alpha le temps de m’atteler à la réorganisation des routes et l’ajout des tests unitaires. Il fonctionne cependant « out of the box » et vous donnera déjà un bon aperçu de son utilité.
Et, avant que vous ne vous précipitiez sur les captures d’écran : très mais alors très bonne année à tout le monde !
Quelques captures d’écran :
L’accueil :
La déclaration d’ip :
Un exemple de lien instantané :
Je suis vivement intéressé par vos retours !
Aller plus loin
- Le dépôt du projet (455 clics)
- Le dépôt docker-compose (122 clics)
- Le dépôt du client (125 clics)
- Pour me suivre sur fosstodon: (98 clics)
- Le pare feu openoffice existe (234 clics)
# IP dynamique ?
Posté par Mimoza . Évalué à 4.
Projet sympa ! Bravo pour le boulot.
Je me demandais par contre comment tu gère (si tu le gère) les connexion via smartphone. Les opérateurs ayant la facheuse tendance de partager les IP entre plusieurs utilisateurs et de changer l’adresse IP de manière dynamique.
Même sans parler de smartphone, quelqu’un en déplacement doit repasser par tes liens sécuriser pour pouvoir accéder a ce qu’il souhaite j’imagine.
[^] # Re: IP dynamique ?
Posté par gUI (Mastodon) . Évalué à 5. Dernière modification le 12 janvier 2023 à 08:09.
Est-ce que ce serait via les "instant links" : où que tu sois, si tu as le lien, tu as accès ?
C'est surtout qu'on est carrément derrière un NAT, avec un IP locale non routable.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: IP dynamique ?
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 1.
Normalement, l'IP vue sera bien l'ip publique et non la locale ;)
[^] # Re: IP dynamique ?
Posté par gUI (Mastodon) . Évalué à 4.
Évidemment, mais c'est pas l'IP de ton téléphone.
Là par exemple chez SFR si je vais sur monip.org,je vois 92.88.170.121 (qui est une IP publique), mais si je demande à mon téléphone son IP, il me dit 100.91.12.5 (qui est une IP privée).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: IP dynamique ?
Posté par fenril . Évalué à 0.
Je vais sans doute dire une connerie (qui a dit ENCORE ?) mais 100.x.y.z n'est pas une adresse privée telle que définie par la rfc1918.
Mais peut-être as-tu voulu écrire 10.91.12.5?
[^] # Re: IP dynamique ?
Posté par Frédéric Blanc . Évalué à 2.
Le bloc d'IP 100.64.0.0/10 (adresses de 100.64.0.0 à 100.127.255.255) est un bloc d'IP privées réservé par la RFC 6598 pour que les opérateurs puissent faire du "Carrier Grade Network Address Translation", et ainsi ne pas risquer de télescopage avec les IP privées définies par la RFC 1918.
Les adresses de ce bloc ne peuvent pas circuler sur la partie publique d'Internet, elles doivent être NATées en sortie et c'est pour cela que gUI voit que son téléphone s'est fait attribuer l'IP 100.91.12.5 par SFR, là où monip.org lui annonce qu'il utilise l'IP publique 92.88.170.121.
[^] # Re: IP dynamique ?
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 3.
Hello,
Oui, via les liens instantanées c'est le plus rapide pour mettre à jour son IP.
# Intéressant
Posté par Lenbootil . Évalué à 4.
C'est une approche un peu différente de ce que j'ai l'habitude de voir. Et rien que pour ça, ça mérite d'être creusé.
Il ne faut pas oublier que la sécurité, c'est comme un oignon : c'est construit en plusieurs couches superposées. Et plus il y en a, mieux c'est. :)
La première des restrictions IP devrait donc être géographique. Sans vouloir verser dans le cliché, à moins d'avoir des amis chinois ou russes, inutile de laisser passer les adresses IP de ces pays. Du coup, ce serait peut-être intéressant de rajouter un module basé sur xtables geoip, par exemple.
D'où la sécurité par couches superposées. ;)
Pas pour moi. Les conteneurs, c'est devenu la solution de facilité, qui masque le problème de la gestion des dépendances. Pour beaucoup, c'est facile, donc on ne fait même plus gaffe à ce qu'on installe. Résultat, l'admin n'est plus vraiment maître de ce qui tourne sur ses bécanes, ce que je trouve un peu embêtant quand, justement, on parle de garder la main sur ses données…
Bref, si tu pouvais proposer une méthode d'utilisation sans docker, ça serait cool. :)
[^] # Re: Intéressant
Posté par aiolos . Évalué à 5. Dernière modification le 12 janvier 2023 à 09:56.
Le Dockerfile donne la recette pour construire le conteneur, tu devrais pouvoir le refaire à la main en local ; le fichier doker-compose.yml te donner les configs pour faire tourner l'appli…
Bref, en fait, puisque tout est disponible, l'admin
n'estplus vraimenttoujours maître de ce qui tourne sur ses bécanes…[^] # Re: Intéressant
Posté par Lenbootil . Évalué à 1.
Oui, j'ai vu. Merci pour le lien, cela dit.
Je disais juste qu'une ou deux lignes d'information dans le README, ça pourrait aussi être une bonne idée.
[^] # Re: Intéressant
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 2.
Oui, bien vu. Une installation classique ne serait vraiment pas un problème.
[^] # Re: Intéressant
Posté par gUI (Mastodon) . Évalué à 10.
Pitié, non.
J'ai été sur mon ADSL résidentiel chez OVH qui venait de racheter des blocs d'IP anciennement Russe. Plusieurs années après je continuais à être emmerdé par des sites (y compris gouvernementaux !) qui me refusaient l'accès.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Intéressant
Posté par Lenbootil . Évalué à 3.
Ah oui, pas de bol. Et pas cool, non plus.
Mais…
1/ Le contexte est important. Le filtrage geoip me semble pertinent en utilisation à titre personnel, pour un cercle de proches, beaucoup moins pour un site commercial ou gouvernemental. Il y a quand même un gros paquet de différences entre une instance nextcloud auto-hébergée et les sites de la DGFIP…
2/ Là, on touche aux problèmes des bases d'adresses IP, et de la fréquence de leur mise à jour. Et comme elles sont, de surcroît, de moins en moins librement accessibles, ça ne risque pas de s'arranger, malheureusement.
[^] # Re: Intéressant
Posté par Psychofox (Mastodon) . Évalué à 7.
Oui et non.
Alors oui ça filtre bien une grosse partie du traffic. Mais maintenant la plupart des réseaux de bots utilisent des appareils connectés du monde entier, donc tu as des attaques venant de partout, y compris de ton propre pays. Par ailleurs, la geolocalisation des ips n'a souvent rien à voir avec la localisation exacte. Mon opérateur mobile que j'utilise en Espagne me donne un numéro espagnol. Mais la range d'ip vient de leurs serveurs en Roumanie. Du coup dans plein de boutique en lignes que je visite on me propose par défaut le Leu roumain comme monnaie. C'est con.
Et aussi, tu va bloquer ton cousin qui a décidé d'aller vivre quelques années en Chine.
Moi tout ce que je self host, j'y accède depuis un VPN. Par contre c'est pas hyper pratique d'enseigner à un tiers comment se connecter à un VPN et t'as pas forcément envie qu'il se connecte à tout ton réseau local, donc tu vas devoir les faire accéder à un VPN séparé n'ayant accès qu'à des VLANS dédiés aux seuls resources que tu veux leur donner accès. Et tu ne veux pas non plus qu'ils accèdent au net via ton VPN, car ça te soumets à des risques si tonton Firmin oublie de se déconnecter de ton VPN et va visiter son forum pédophile favori.
[^] # Re: Intéressant
Posté par Lenbootil . Évalué à 3.
Visiblement, j'ai abordé un sujet polémique. Et pas un vendredi, en plus. Oups.
Mais bon, même je comprends les problèmes que gUI et toi exposez, là, on parle juste d'un pare-feu perso pour une dizaine de proches.
Ben oui, ça filtre une grosse partie du trafic. C'est toujours ça de moins à gérer.
Et le cousin en Chine, ben il aura droit à son exception. Et ça n'empêchera pas de continuer à bloquer les adresses nigériannes, vietnamiennes, péruviennes, luxembourgeoises…
Admettons qu'en temps normal, je bloque les adresses IP espagnoles. Et tant qu'aucun de mes utilisateurs ne s'en plaint, j'ose croire que c'est bien comme ça. Par contre, quand j'ai prévu de me déplacer en Espagne, je débloque juste avant, et je rebloque en rentrant, et j'ai limité la surface d'attaque le reste du temps. Où est le problème ?
Et puis, certes, ce n'est pas parfait, mais il est bien évidemment hors de question de ne se reposer que sur un seul outil de sécurité. Le bot nmap, par exemple, il doit aussi être bloqué par d'autres règles ou mécanismes, qu'il soit français ou non. Mais comme ces mécanismes sont potentiellement un peu plus gourmands, autant faire un tri au préalable, non ?
[^] # Re: Intéressant
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 4. Dernière modification le 12 janvier 2023 à 13:14.
En fait, je suis parti du principe de base que par défaut tout est interdit ;)
[^] # Re: Intéressant
Posté par Astaoth . Évalué à 9.
Absolument pas. En entreprise, le gros des bots qu'on se tapent viennent des USA, une restriction géographique ne servira à rien ici. Par contre, quand on utilise Tor par exemple, on ne controle pas son noeud de sorti, on peut se retrouver n'importe où dans le monde.
On peut vouloir bloquer les flux Tor (même si c'est une mauvaise idée je trouve), mais dans ce cas la liste des noeuds sortant est dispo publiquement.
Si on veut bloquer tout les flux qui viennent d'un pays, ne faudrait-il pas également bloquer les flux VPN (qui permettent donc de contourner ces restrictions) ? Mais dans ce cas, quid des utilisateurs qui vivent derrière des VPN ou proxy cloud ?
La restriction géographique est vraiment très cliché, très facile à contourner, à trop de risques de surblocage, et fourni donc un faux sentiment de sécurité.
Emacs le fait depuis 30 ans.
[^] # Re: Intéressant
Posté par gUI (Mastodon) . Évalué à 10. Dernière modification le 12 janvier 2023 à 17:20.
J'avais jamais regardé… je prends les 2500 dernières IP bannies par mon
fail2ban, et je fais passergeoiplookupdessus (premier outil trouvé, si vous avez mieux je peux réessayer)Validé !
EDIT : encore mieux ! je prenais la liste des IP brute des logs, sans passer un
uniqdessus. Une fois trié, je n'ai plus que 624 IP différentes, et le classement est encore plus inattendu :Russie + Chine c'est moins de 10% des IPs rejetées…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Intéressant
Posté par jyes . Évalué à 6. Dernière modification le 13 janvier 2023 à 08:45.
C’est parce-que leur attaque par dictionnaire est plus efficace et qu’elles réussissent à se connecter avant d’être arrêtées par fail2ban ! Débranche tous tes serveurs !
[^] # Re: Intéressant
Posté par Astaoth . Évalué à 6.
Et parmi ca, le gros des IP américaines, c'est des scanners de type Shodan ou Censys. T'as des initiatives comme greynoise qui existent pour référencer les ip ayant ce type de trafic un peu gris.
Bon à côté, je te concède par contre que pour le moment, l'immense majorité des bots qui font des attaques de SQLi ou path traversal un peu bateau ont des IP chinoises. Mais si demain tout le monde géobloque les ip chinoises, ca deviendra des IP francaise de chez OVH ou d'un VPN, ca ne changera pas grand chose.
Emacs le fait depuis 30 ans.
# Pas mal !
Posté par Marcel4567 . Évalué à 2.
Projet intéressant en effet.
J’utilise d’autre techniques, plus archaïque mais ça marche bien, ca a beaucoup réduit les scan de scripts kiddies :
- Pour SSH: port-knocking ICMP. Pas besoin de client, et ça reste simple. Avec un SSH tar pit en plus (endlessh), ça leur fera les pieds !
- Pour les sites web public: je reste avec du purement static (genre Jekyll), pas de PHP ou autre, ça limite la surface d’attaque à Nginx.
- Pour les sites privés: authentification client par certificat SSL. Ça demande de gérer des certificats et de les installer dans les navigateurs des gens de ta famille, mais c’est diablement efficace. Si pas de certificat, la connection SSL monte pas.
Le filtrage par IP ça peut poser problème pour les gens en 4G/5G. L’IP publique est partagée avec d’autre personnes et elle peut changer d’un site à l’autre. J’ai souvent ce problème avec des captchas qui tourne en boucle vu que mon IP publique n’est pas stable.
# docker
Posté par barmic 🦦 . Évalué à 2.
Je suis pas encore allé voir, mais comment tu manipule ton firewall depuis un conteneur ?
Dans une idée un peu similaire mais bien moins aboutie (j'étais seul utilisateur), j'avais fais en sorte de pouvoir pousser un fichier chiffré et signé contenant mon ip. Le serveur poll se fichier en vérifiait la conformité et autorisé la liste d'IP en question.
Tu ne parle pas de timeout, tu garde les IP autorisées combien de temps ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: docker
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 2.
Il y a une partie serveur qui peut être installé sur la machine exposée ou ailleurs (voir même un service en ligne partagé entre plusieurs). Et un module client python pour récupérer la liste des IPs à autoriser. Il y a un exemple de script fourni pour récupérer les IPs à intervalle régulier dans un ipset. Mais chacun peut coupler le client avec la solution firewall de son choix. Idéalement, j'aimerai gérer les échanges par websocket à l'avenir pour avoir quelque chose de plus dynamique.
Pour le timeout, oui c'est maquetté mais pas proposé (je voulais partager rapidement pour écouter les remarques). En gros, il y aura un timeout configurable par défaut pour ce qui est lien instantanée et une programmation possible (début/fin) via le menu "Ip de confiance".
# Qui gardera le gardien ?
Posté par Pierre Tramal (site web personnel) . Évalué à 5. Dernière modification le 12 janvier 2023 à 14:19.
Il doit y avoir quelque chose qui m'échappe, mais comment protèges tu le serveur qui reçoit les requêtes des liens partagés avec les utilisateurs ?
Et deuxième chose je ne vois pas la différence entre ta solution ou héberger le service Web que tu veux "cacher" sous une URL secrète difficile à deviner (comme celles générées par ton soft) partagée avec les tiers de confiance.
[^] # Re: Qui gardera le gardien ?
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 4.
Le "gardien" est effectivement exposé mais il n'est pas "sensible" car il ne possède pas de données.
Perso, mon serveur MySafeIP fonctionne sur une instance cloud (free tier Oracle) et mes machines chez moi viennent l'interroger toutes les 10 secondes. Si un jour cette vm tombe, l'infra chez moi reste isolée (ports fermés par défaut).
Même avec une seule machine cela reste intéressant: Tu n'autorises par défaut chez toi que le port dédié au serveur MySafeIP (un port "exotique" 8079 disons).
Ainsi toutes tes autres pages accessibles en 80/443 sont fermées par défaut et ne subissent pas les attaques des bots. Si il y a un jour une faille concernant l'authentification de mon serveur nextcloud par exemple, la page d'authentification n'est pas accessible sans passage par MySafeIP.
Elle ne devient accessible en 80/443 (grace au client mysafeip et à iptables) qu'après la déclaration de l'ip sur MySafeIP manuellement après authentification ou dynamiquement en utilisant un lien instantanée.
Je ne sais pas si je suis clair, il faut vraiment que je fasse une démo en vidéo ;)
[^] # Re: Qui gardera le gardien ?
Posté par Micromy (site web personnel) . Évalué à 3.
C'est très bien, c'est pragmatique. Avec ce genre d'outils ça peut faciliter le passage à l'auto-hébergement, et l'auto-hébergement, c'est mieux. Merci pour la dépêche.
[^] # Re: Qui gardera le gardien ?
Posté par Pierre Tramal (site web personnel) . Évalué à 1.
Il contient quand même assez de données pour aller modifier les règles de pare feu de la destination, non ?
[^] # Re: Qui gardera le gardien ?
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 3.
Le serveur MySafeIP ne pilote pas le client. Il possède juste la liste des IPs à autoriser. Le client récupère ces IPs via le module qui gère l’authentification et le GET des IPs. Elles peuvent être alors ajoutées en sources autorisées du parefeu par le script fournit ou tout autre moyen.
Je propose ipset pour la gestion du groupe d’ip mais libre à chacun d’adapter à sa manière/parefeu ;)
[^] # Re: Qui gardera le gardien ?
Posté par stopspam . Évalué à 2.
Je me suis posé exactement les mêmes questions. Je ne vois pas ce qu'apporte la solution mais si ça sert à d'autres alors…
# Réflexions en vrac.
Posté par frafra . Évalué à 1.
Bravo pour ce projet, le sujet est intéressant et je n'ai rien posté depuis une éternité.
D'abord il est possible de restreindre les IP sources à certains pays. Il y a par exemple ipdeny. Un court script pour le transformer au format voulu fera l'affaire.
Coté alternatives il existe teleport qui fait à la fois bastion ssh mais aussi web, bdd et k8s avec du 2FA et l'enregistrement de sessions.
Enfin, j'aime assez l'idée de mettre tout derrière un vpn. Un seul port udp en écoute et pour Wireguard une bonne intégration sur Android où on peut même choisir les applis qui passent par le vpn. Il y a des gestionnaires de configurations web si besoin de gérer des clients.
En espérant avoir alimenté vos reflexions.
[^] # Re: Réflexions en vrac.
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 1.
Je suis d'accord avec toi mais un peu comme certains commentaires plus haut je ne fais pas confiance à un pays en particulier. Le principe est de dire qu'aucun réseau n'est de confiance.
Le but est aussi de pouvoir donner un accès rapide sans configuration particulière à communiquer. C'est ce qui est possible avec les liens instantanés. Aucune configuration, juste un lien à donner :)
# Pk ne pas utiliser des certificats
Posté par Ronki . Évalué à 1.
Hello, je trouve ton concept intéressant. Cependant, en plus de bannir les ip chelous, pourquoi tu n’utilises pas un certificat côté client?
Je ne connais pas ton setup mais si tu as un reverse proxy, mets dessus une validation de certificat client. Sur chacun des postes utilisateurs tu l’installes et là plus personne à part ton cercle proche pourra y accéder
[^] # Re: Pk ne pas utiliser des certificats
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 1.
En fait, le but est de pouvoir coller à n'importe quel setup pour faciliter le filtrage niveau réseau (niveau 3). C'est un complément aux mesures qui viennent après en authentification (niveau 7).
MySafeIP peut aussi bien être utilisé en amont d'un reverse proxy, d'un VPN ou encore d'un serveur ssh par exemple.
Utiliser des certificats est intéressant/important mais cela n'agit au même niveau.
[^] # Re: Pk ne pas utiliser des certificats
Posté par aiolos . Évalué à 2.
Les certificats clients agissent en niveau 3 également, couche Transport, comme l'indique le nom du protocole les utilisant Transport Layer Security (TLS) ; l'authentification peut être transférée aux couches plus hautes, notamment la couche application, mais ce n'est pas une obligation.
[^] # Re: Pk ne pas utiliser des certificats
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 1.
Bon je vais chipoter un peu mais TLS est un peu plus haut dans les couches (niveau 5) quand iptables/netfilter est bien niveau 3.
[^] # Re: Pk ne pas utiliser des certificats
Posté par aiolos . Évalué à 2. Dernière modification le 27 janvier 2023 à 22:45.
Alors, effectivement, dans le modèle OSI, TLS se place en couche 5, présentation, au dessus de TCP qui appartient à la couche Transport. Mais souvent, quand on parle de TLS, on se place dans le modèle internet (TCP/IP) ; dans ce dernier, TLS appartient à la couche transport (d'où le nom), qui est en couche 3.
Mais bon, on est d'accord, onquand même en train de couper des cheveux en 4 et TLS est bien au dessus de netfilter, dans les deux modèles ;)
[^] # Re: Pk ne pas utiliser des certificats
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 1.
Effectivement ;)
# Utiliser le fait que HTTPS est peu visé?
Posté par lym . Évalué à 1.
Je n'ai pour ma part pas d'hébergement 24/7 pour les proches, mais j'ai longtemps eu un simple serveur SSH accessible de l'extérieur pour mes propres besoins: Clairement, regarder les logs faisait peur… Fail2ban permettant de calmer l'affaire bien au delà des options intégrées au serveur.
Le port knock, avec une séquence bien choisie pouvant au pire se faire avec une simple commande ping (dispo sur toute machine, ma philo étant de pouvoir au besoin me connecter de toute machine de confiance sans outil spécifique avec juste ma tête de disponible, ce qui exclu donc également l'usage de clef ssh pour en rester aux user/pass), j'ai aussi utilisé… avant de passer IPV6: knockd ne le supporte pas!
Depuis, j'ai de la domotique avec un accès externe HTTPS (merci certbot/letsencrypt).
Depuis, j'avoue être assez surpris vs SSH: On voit certes passer des connections, mais juste les robots d'indexation lâchant l'affaire sur la page de connexion et/ou après lecture du robots.txt.
HTTPS semble donc au final assez peu attaqué comparé à SSH qui est un aimant à robots de bruteforce.
=> J'ouvre désormais au besoin le SSH via un bouton de l'interface domotique/HTTPS, accessible comme le reste après login et qui appelle un script ouvrant le port 22 pour 30s, laissant le temps d'établir une connexion si besoin d'administration distante/accès à mon LAN via tunnel/proxy socks.
Simple et pour le moment jamais mis en défaut.
# IPv6 ?
Posté par Élafru . Évalué à 2.
Je ne vois dans les captures d'écran et dans le README que des adresses en IPv4… Ce programme développé en 2022 aurait-il fait l'impasse sur l'IPv6 ?
[^] # Re: IPv6 ?
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 1.
Release early, release often :) J’ai répondu à un besoin initial et partagé sans à priori sur l’intérêt de la communauté. Toutes les briques sont cependant compatibles mais je n’ai pas testé c’est vrai. L’adaptation si ce n’est pas compatible devrait être assez accessible.
# Il y a bien plus simple
Posté par pasBill pasGates . Évalué à 1. Dernière modification le 31 janvier 2023 à 20:08.
Et si tu installais et configurais IPSEC
Tu mets un certificat sur les clients auxquels tu fais confiance, tu configures IPSEC sur tes serveurs pour faire confiance aux certificats.
Et … c'est tout. Une machine qui ne parle pas IPSEC, qui n'a pas le bon certificat, ne touchera aucun des ports, elle se fera éjecter dès la couche IP. Plus besoin de gérer des listes de confiance d'addresses IP, tu peux utiliser n'importe quelle addresse. Faut juste potentiellement gèrer du NAT traversal.
Bon il reste toujours le risque d'une faille dans la couche IP évidemment, rien n'est jamais totalement sûr, mais cela limite énormement la surface d'attaque.
[^] # Re: Il y a bien plus simple
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 1.
Un exemple tout simple: je peux partager un lien instantané avec ma mère de 82 ans qui pourra accéder sans soucis aux photos que je lui partage. Avec Ipsec, je dois faire 300km espérer ne pas avoir de souci avec son téléphone puis rentrer. Passer ensuite 30 minutes au téléphone pour la guider même si elle se débrouille très bien à distance et finir par tout envoyer par mail. Je ne suis pas certain d’y gagner 😉
Dans d’autres contextes je suis d’accord, un vpn est là bonne solution. Tout dépend des cas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.