MeAndMyKeyboard a écrit 22 commentaires

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.

Effectivement ;)

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.

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.

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 :)

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.

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 ;)

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 ;)

Oui, bien vu. Une installation classique ne serait vraiment pas un problème.

En fait, je suis parti du principe de base que par défaut tout est interdit ;)

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".

Normalement, l'IP vue sera bien l'ip publique et non la locale ;)

Hello,

Oui, via les liens instantanées c'est le plus rapide pour mettre à jour son IP.

J'aimerai trouver le temps pour le faire mais pour l'instant ce n'est pas trop le cas. Par contre, toute initiative est la bienvenue!

Merci à vous pour cette "attention" qui est aussi sympathique qu'inattendue.
Mais j'en profite aussi et surtout pour vous remercier de la visibilité que vous offrez aux nouveaux projets (comme le mien) en leur permettant de prendre leur envol et de recueillir les avis éclairés et critiques des visiteurs de linuxfr.org

Merci beaucoup pour vos précisions, je les garde de côté pour voir si certaines questions peuvent être traitées par le logiciel dans les prochaines versions (que ce soit par l'ajout de fonctionnalités, des bonnes pratiques ou de la documentation).

En fait, le fichier du code source est setting.py.model. A l'installation, l'administrateur copie ce fichier en settings.py ce qui permet de conserver les mises à jour par git sans avoir à gérer de conflit. Si vous avez utilisé la machine virtuelle, ce détail n'est pas visible c'est vrai.

Je garde cependant la remarque ( et vos solutions) en tête et regarderai si il y a des bonnes pratiques sur ce point. Merci ;-)

Je comprend tout à fait votre remarque. Ce logiciel comme les autres solutions du même domaine (wpkg, OCS, Fusion) répond à cinq besoins principaux:
- Les grands parcs basés sur des solutions autres que Active Directory (Samba / Ldap);
- Les parcs de dimension réduites qui n'utilisent pas Active Directory, n'ont pas les ressources ou les moyens d'utiliser ces solutions;
- Les parcs Active Directory qui cherchent des solutions simples et complémentaires;
- Les administrateurs qui cherchent des solutions évolutives et adaptables à leurs besoins propres;
- Les curieux et passionnés par les solutions libres qui recherchent des alternatives aux solutions propriétaires: on est bien sur Linuxfr.org n'est-ce pas ;-) .

Merci pour votre commentaire et vous êtes donc embauché pour le plugin GLPI ;-) Plus sérieusement, j'y ai réfléchi et échangé rapidement sur ce point avec Nelly de GLPI aux solutions linux. Je pourrais m'appuyer sur le plugin webservice de GLPI pour pouvoir gérer la création et mise à jour des machines directement depuis l'outil.
Maintenant, ce n'est pas un besoin que nous avions aujourd'hui car le couple OCS / GLPI que j'utilise me satisfait dans ses fonctions de gestion de parc. Pour quelqu'un qui ne souhaiterait pas installer de serveur OCS, il est aussi possible d'utiliser uniquement l'agent fusion et son plugin GLPI associé. C'est aussi pour ça que je parle dans le premier commentaire d'une solution différente / complémentaire.
En attendant, il est enfinpossible de faire un export des données puis un import avec le plugin data injection par exemple. En bref pas de problèmes, que des solutions! On se recontacte pour démarrer les devs de ce plugin alors?

Je suis très intéressé par le besoin que vous exprimez, pourriez vous m'en dire un peu plus (ici ou par mail). Perso, dans ce cas (mais je n'ai peut être pas tout saisi) je fais un paquet d'installation des dll avec inno setup ce qui me permet de suivre facilement les versions puis je fais une condition sur ce paquet pour le logiciel initial.

Dans ce cas, les profils sont très utiles car en mettant à la fois le paquet de dll et le logiciel en ayant besoin, UpdatEngine installera d'abord les dépendances nécessaires puis le logiciel qui ne pouvait pas s'installer à la base (pas besoin de les placer dans un ordre précis, le système se débrouille seul lors de la vérification du profil). Par exemple si un logiciel A nécessite B et B nécessite le logiciel C et que ces trois logiciels sont dans le même profil (peu importe l'ordre), alors UpdatEngine installera automatiquement C puis B et enfin A.

bonjour et merci pour votre commentaire.
Sinon oui, c'est effectivement une fonction que j'ai prévu pour la prochaine version et que je souhaitais n'annoncer qu'à la sortie. Mais comme ça c'est fait ;-).

Pour résumer et compléter les infos du lien rappelé par sparklyon: En fait la raison est assez simple, je suis parti d'une page blanche afin de n'être dépendant d'aucun projet existant et implémenter les fonctionnalités que je souhaite sans aucune contrainte (par exemple, je ne souhaitais pas être "contraint" par les mécanismes existants de déploiements).

J'ai beaucoup de respect pour les deux projets que tu cites (sinon, je n'aurais pas écris l'ouvrage sur l'application OCS Inventory paru dernièrement ;-) ), mais je veux simplement faire quelque chose de différent / complémentaire apportant de réelles nouveautés tout en restant accessible. C'est d'ailleurs un point sur lequel j'ai déjà eu l'occasion de discuter avec les membres de la communauté OCS que je salue si ses membres passent par ici :)

Je souhaitais enfin développer la partie serveur et cliente dans le même langage afin d'être efficace et cohérent avec la philosophie du projet.