Ce sont de bonnes idées, mais il y a plus simple quand même :
- Un demon serveur (apache, perl, etc...) qui écoute sur un port particulier, et qui attend des codes d'authentifications, basés sur une date/heure par exemple comme tu l'as dis. Cela demande une bonne synchro sur les serveurs de temps (NTP) du serveur et du client, mais c'est faisable. Le demon ouvre alors à la demande le port du serveur, via un commande Iptables. Afin de ne pas faire tourner le démon (qui attend les requêtes) avec les droits root (ce n'est pas sécurisé tout cela...), on peut le faire dialoguer en loopback avec un autre démon, root celui-ci, qui est inaccessible depuis Internet. Et seul ce demon aura les droits root pour modifier Netfilter/iptables. Si nécéssaire, une socket Unix peut être utilisée pour cette connexion interne, ce qui limite encore plus les risques sur le 2nd demon root.
- Si on peut accepter que le client attende un peu pour sa connexion, on peut envisager ceci :
- Le client qui veut se faire ouvrir le port 21 du serveur envoie un email sur une adresse convenue (yahoo, google, free, etc...)
- Regulièrement, le serveur interroge le compte email, via pop ou imap. Dès qu'il lit cette demande de connexion, il ouvre le port adéquate, et renvoie un mail au client pour lui dire que le port est ouvert pour une durée de xx minutes
Bien entendu, pour plus de sécurité le mail peut-être codé:
- utilisation de clef publique/privée pour chiffre le corps du mail
- inscription dans le mail de l'adresse IP du client (pour ne pas se basé sur l'adresse IP source du mail, qui peut être trafiquée)
- utilisation d'un code de validité, basé sur une date/heure, un code aléatoire, etc...
# Solutions plus simples :
Posté par Olivier (site web personnel) . En réponse au journal Port fermé, mais accessible. Évalué à 3.
- Un demon serveur (apache, perl, etc...) qui écoute sur un port particulier, et qui attend des codes d'authentifications, basés sur une date/heure par exemple comme tu l'as dis. Cela demande une bonne synchro sur les serveurs de temps (NTP) du serveur et du client, mais c'est faisable. Le demon ouvre alors à la demande le port du serveur, via un commande Iptables. Afin de ne pas faire tourner le démon (qui attend les requêtes) avec les droits root (ce n'est pas sécurisé tout cela...), on peut le faire dialoguer en loopback avec un autre démon, root celui-ci, qui est inaccessible depuis Internet. Et seul ce demon aura les droits root pour modifier Netfilter/iptables. Si nécéssaire, une socket Unix peut être utilisée pour cette connexion interne, ce qui limite encore plus les risques sur le 2nd demon root.
- Si on peut accepter que le client attende un peu pour sa connexion, on peut envisager ceci :
- Le client qui veut se faire ouvrir le port 21 du serveur envoie un email sur une adresse convenue (yahoo, google, free, etc...)
- Regulièrement, le serveur interroge le compte email, via pop ou imap. Dès qu'il lit cette demande de connexion, il ouvre le port adéquate, et renvoie un mail au client pour lui dire que le port est ouvert pour une durée de xx minutes
Bien entendu, pour plus de sécurité le mail peut-être codé:
- utilisation de clef publique/privée pour chiffre le corps du mail
- inscription dans le mail de l'adresse IP du client (pour ne pas se basé sur l'adresse IP source du mail, qui peut être trafiquée)
- utilisation d'un code de validité, basé sur une date/heure, un code aléatoire, etc...
Olivier