Export de données Influx via VPN

Bonjour,

Afin de sécuriser l’envoi des données vers ma base de données Influx, j’utilise le plugin InfluxDB. Est-ce qu’il est possible de le configurer pour qu’il utilise le plugin OpenVPN (aussi installé) afin de sécuriser l’ensemble des envois de données ?

Merci

Bonjour,

Le plugin se connecte en http ou https selon ce que vous configurez;
d’ailleurs si vous utilisez https tout est déjà encrypté et c’est superflu de vouloir en plus encapsuler tout cela dans un vpn, tout ca pour transporter des infos de monitoring probablement pas super confidentielle, vous n’envoyer pas vos coordonnées personnelles dans influx donc vraiment overkill

Donc si vous voulez sécuriser l’envoi, passez sur un flux https.

De plus, le plugin openVPN sert à connecter votre jeedom au serveurs VPN de jeedom lorsque vous avez leur service dns, il n’a pas vocation à gérer d’autres vpn à la demande des autres plugins.

Et où se trouve votre base influx?

  • sur votre réseau? du coup faire un vpn sur un lan…
  • sur internet? du coup vous allez devoir setup un serveur vpn quelque part?

bref, je ne comprend vraiment pas la question.

Si vous voulez vraiment configurer un vpn pour joindre votre base influx, ca sera à vous de configurer cela manuellement sur votre système et faire un sorte que les routes soient correctes, le plugin aura juste besoin d’une ip à laquelle se connecter, à vous de router cette ip là où il faut

Ma base influx se trouve sur l’un de mes serveurs cloud, la box Jeedom est sur un réseau que je ne maitrise pas.

J’ai déjà configuré le flux pour qu’il soit en https.

Je ne suis pas contre l’idée de configurer mon propre VPN, mais si ça ne sert à rien, autant éviter de me fatiguer pour rien.

De fait, je ne suis pas un expert en sécurité informatique. Ma question est due à un conseil qu’on m’a donné.

On m’a dit que faire en sorte que la base de données Influx soit accessible depuis internet constituait une faille de sécurité majeure. La limiter à des accès via VPN serait une bonne réduction de risque déjà.

Il faut que je creuse la question. De ce que je comprends de votre réponse, je pourrais faire pointer le plugin InfluxDB vers un point d’entrée dans le VPN, qui lui redirigerait vers la base Influx. Mais j’ai l’impression que ça laisserait le trajet Jeedom → VPN « moins sécurisé ».

Je pensais à l’origine faire un VPN point à point entre la box Jeedom et la machine qui host Influx.

Je vais affiner ma recherche sur les sujets HTTPS et VPN.

ok je comprend maintenant, donc c’est pas tellement pour protéger les données que vous envoyez mais pour limiter la « fenêtre d’attaque » sur le serveur en limitant les clients qui peuvent s’y connecter.
En théorie cela a tout son sens mais il faut mettre en balance le risque et la complexité.

Concernant le risque, je n’aurais pas classifier cela en « majeure » perso, plusieurs points permettent de mitiger le risque:

  • vous n’êtes pas forcément une cible de choix, le monde se fiche un peu de vos données dans inlfux sans vouloir vous offenser :wink:
  • de nouveau, les données ne sont pas critiques à priori, si quelqu’un y accède il va avoir quoi comme info? température et taux d’humidité? charge cpu etc…
  • si vous gardez votre serveur inlfux à jour et que vous avez des contre-mesures (fail2ban, etc) vous limitez sérieusement les risques aussi => si seul de l’https est exposé que toute tentative se retrouve bannie et que derrière il n’y a pas de faille sur influx, votre job est fait pour vous protéger
  • vous pourriez éventuellement rajouter un firewall coté serveur et faire de l’ip whitelisting, ca ajoute une petite couche.

du coup pas sur que ca nécessite d’en faire plus mais c’est vous qui allez devoir maintenir ce vpn donc à vous de faire la balance.

c’est ca l’idée, mais donc c’est sur la box jeedom ou sur le lan qui doit être configuré « le point d’entrée »
donc non le trajet jeedom → vpn ne sera pas moins sécurisée puisque uniquement locale (et toujours en https)

Si tu es professionnel et que tu exposes les données de tes clients sur Internet c’est effectivement un défaut de sécurité majeur dans les classifications d’audit de sécu (c’est mal :wink: ). Cela dit il convient de mitiger le sujet, notamment si les données n’ont pas de valeur permettant d’exploiter des failles sur les sites, qu’elle sont encryptées ou qu’elles permettent de rebondir sur des systèmes annexes. en général, il faut passer par la case pen test pour voir le degré de pénétrabilité.

si ces data sont personnelles et qu’elles ne contiennent pas de données de type personnelles, ni de données de rebond potentielles, tu peux juste t’inquiéter de publier un service sur internet sans le sécuriser, surtout s’il est installé sur un serveur où se trouvent des données perso sur d’autres sujets. il serait au moins judicieux de :

  • sécuriser la communication de ta machine sur adresse (https + ssh) via un domaine
  • ajouter quelques règles de filtrage (genre iptables) sur le sujet
  • mettre en place du fail2ban pour blacklister et un détecteur de rootkit (minimum vital)
    et si tu as un peu de budget :
  • ajouter un vm firewall+vpn en coupure (l’idéal mais une instance cloud de plus) ou souscrire au service

Je travaille avec des données pro, j’ai déjà fait la partie 1

sécuriser la communication de ta machine sur adresse (https + ssh) via un domaine

Je ne suis pas certain de quoi mettre pour la partie 2

ajouter quelques règles de filtrage (genre iptables) sur le sujet

c’est pour une éventuelle white / black list ?

La partie 3 ne me parle pas du tout, je vais regarder aussi

mettre en place du fail2ban pour blacklister et un détecteur de rootkit (minimum vital)

La partie 4 c’est celle que j’envisageais

ajouter un vm firewall+vpn en coupure (l’idéal mais une instance cloud de plus) ou souscrire au service

Je ne comprends pas la partie « souscrire au service ».

Merci beaucoup pour les conseils

sur les règles de filtrage, oui l’idée est de whitelister et blacklister des plages mais aussi des plages de ports et le type de protocole autorisé en udp/tcp. tu peux également ajouter des règles sortantes pour éviter les rebonds vers les machines du réseau local en smb, ssh, ftp, etc… et compléter via fail2ban qui peut faire un travail d’analyse des flux assez basique mais déjà efficace pour détecter par exemple les robots qui tentent de se connecter à plusieurs reprise en brute force.

tout ça reste quoi qu’il en soit très basique et sans possibilité de détection en mode intelligent et sachant lutter contre les attaques sophistiquées. Pour ça il faut un firewall en coupure avec de l’examen des paquets jusqu’au niveau 7 (applicatif). ça existe soit en boîtier, soit en appliance, soit en vm, soit en service dans le cloud. les firewalls de niveau 3 proposent la fonction vpn intégrée, qui sera de plus protégée efficacement contre les intrusions.

enfin, par souscription de service, je pensais à des services cloud de sécurité type zscaler.