Vu que je n'arrivais pas à dormir à cause du chatton avant hier soir (http://khalahan.hd.free.fr/photos(...) pour ceux que ca interessent :p), j'ai cogité sur un outil qui pourrait être pratique pour sécuriser encore plus un ordinateur.
Le but est d'ouvrir un port (pour un serveur FTP par exemple) seulement quand une personne en a besoin, à l'aide d'un code composé de par exemple 3 nombres allant de 1 à 65535 (ce qui correspond à des numéros de ports).
Cette méthode s'applique uniquement pour des serveurs non publics, réservés à une liste de personnes définie, qui connaitrait la combinaison.
Prenons un exemple concret :
Le firewall, par défaut, bloque le port 21 sur lequel tourne le serveur FTP, ce qui empêche toute tentative de piratage, liée à une faille quelconque ou aux technique de "brut force" (essai de mots de passe au hasard).
M. X, avec son ip 100.200.100.200 (au hasard) veut se connecter sur le serveur FTP de MrLinux qui a l'ip 200.100.200.100 (idem). Le port 21 étant fermé, il va avoir besoin de faire le code secret qui est de 3245, 4871 et 56 (au hasard aussi).
M. X devra donc faire une tentative de connexion TCP (ou n'importe quoi d'autre que l'on décide, un ping, un paquet UDP, etc) sur le port 3245 puis 4871 puis 56.
Le serveur va ensuite ouvrir le port 21, uniquement pour cette IP.
Sous Linux, la configuration du firewall "iptables" permet de différencier une demande nouvelle connexion d'une connexion déjà établie. Cette particularité d'un bon firewall nous permet par exemple d'autoriser pendant 5mn une nouvelle connexion sur le port 21 venant de l'ip de M. X. Au bout des 5mn, M. X ne pourra plus se connecter au port 21 sans refaire la combinaison, mais pourra cependant continuer sa session FTP en cours sans aucun problème. De cette façon, le port 21 est de nouveau complêtement fermé.
C'est utile dans le cas ou M. X, qui est sur le même réseau, et qui a donc la même IP n'aura pas besoin de faire la combinaison car le port est déjà ouvert ... Les délais peuvent être très réduit pour être encore plus "sécure".
Il y 2 façons de mettre cela en oeuvre sur le serveur :
- soit le port correspondant au premier code, à savoir 3245 dans cette exemple est déjà ouvert et lorsque que M. X se connecte dessus cela ouvre le port suivant (4871) ce qui ouvre ensuite le dernier port (56) pour enfin ouvrir le port 21 pour l'ip de M. X.
Cette technique a le désavantage de laisser des ports ouverts, et peut être contournée en scannant les ports ouverts un par un, ce qui nécessiterait une protection en plus pour éviter les scans de ports intempsetifs.
- soit tous les ports sont fermés (paquets rejetés), et le programme s'occupe de regarder le fichier de log (la configuration d'iptables pour loguer les ip + ports est très facile). Si le programme detecte que l'IP de M. X essaie de se connecter successivement sur les 3 ports correspondant aux combinaisons, le port 21 est ouvert aux nouvelles connexions pour cette IP pour x minutes (ou x secondes).
Cette solution est beaucoup plus sécurisée, mais nécessite de loguer toutes les tentatives d'accès.
Une autre option pour que ca soit encore plus sécurisé serait de faire varier la combinaison de ports, pour rendre plus sécurisé l'accès, et en particulier pour la 1ère implémentation qui laisse des ports ouverts.
Les ports peuvent varier selon les variables suivantes :
- jour de la semaine
- jour du mois
- mois
- année (2 ou 4 chiffres)
- ip du serveur (4 nombres différents)
- ip du client (idem)
- heure
- minutes
Par exemple :
1er code = Heure * 4
2eme code = Année_4_chiffres * 10
3eme code = 4eme nombre de l'ip du client (200) * 13 + 5
Qu'en pensez-vous ? connaissez-vous des programmes qui font des choses similaires ?
Journal Port fermé, mais accessible
29
mai
2004
# Groar^Wmiaou !
Posté par Ramso . Évalué à 4.
[^] # Re: Groar^Wmiaou !
Posté par khalahan . Évalué à 2.
D'ailleurs, est-ce que c'est parce qu'elle est toute petite qu'elle a autant de punch ou ca va rester ? :p
ps : c hors sujet, mais bon, vous avez qu'à lire en dessous, c'est plus technique :)
[^] # Re: Groar^Wmiaou !
Posté par CopainJack (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Groar^Wmiaou !
Posté par degeu raoul ⭐ (Mastodon) . Évalué à 1.
Il est sympa mais chiant aussi.
Par contre, la tienne a l'air vraiment tres jeune ? c'est peut etre pour ca qu'elle fait autant le cirque.
[^] # Re: Groar^Wmiaou !
Posté par Zorro (site web personnel) . Évalué à 1.
[^] # Re: Groar^Wmiaou !
Posté par icyfemur . Évalué à 2.
[^] # Re: Groar^Wmiaou !
Posté par Prosper . Évalué à 2.
http://pschit.net/ccc/(...)
[^] # Re: Groar^Wmiaou !
Posté par LeMagicien Garcimore . Évalué à 1.
Le nombre de journées perdues à matter ta webcam pour voir les chatons...
C'était à quelle époque ? je crois que j'étais en stage mais je me souviens plus.
Et ils sont où maintenant les chatons ?
# Pas mal !
Posté par Sleem . Évalué à 1.
J'ignore si un projet allant dans ce sens existe déjà, mais le concept de "firewall dynamique" (car c'est bien de cela qu'il s'agit) me plaît bien !
Côté sécurisation, on obtiendrait des serveurs polymorphes, capable de s'adapter aux requêtes qui lui sont adressés, car en effet, on peut même élargir l'idée pour que ce ne soit plus uniquement dans une logique d'authentification et de restriction d'accès. Je veux dire par là que la possibilité de n'autoriser l'accès ftp que si la personne a contacté le serveur web dans les 5 dernières minutes me paraît interressante, et semble, à mon humble avis, ouvrir de vastes possibilités en matière de configuration réseau, gestion serveurs et sécurisation...
Maintenant il faut voir si un projet allant dans ce sens existe déjà (cela m'étonnerait), et sinon s'y mettre. Concrètement, ça ne devrait pas être trop compliqué vu la puissance d'iptables et la possibilité de faire des scripts et de logger... Je verrais bien un script Perl pour gérer ça, dont on peut fixer le comportement via un fichier xml par exemple (si condition alors modification iptables), qui récupère les évènements dans les logs générés par iptables, et qui exécute des scripts iptables en conséquence.
[^] # Re: Pas mal !
Posté par L. R. . Évalué à 5.
Le principe est on ne peut plus simple. On ouvre une connexion SSH au firewall et on tombe dans un shell spécial (qui dit simplement qu'on est logué et de pas fermer la fenêtre tant qu'on a pas fini de bosser, mais avec un timeout correct il se fermera tout seul quand on aura fini de faire du trafic).
Dans /etc/authpf/users//authpf.rules on place les règles de l'utilisateur et elles se chargeront dans le fichier maître à l'endroit désiré (qui est marqué par "anchor authpf").
Je l'utilise par exemple personnellement sur mon réseau Wireless. Ca me permet par exemple d'autoriser des amis de passage à aller sur Internet mais pas sur mon réseau, des choses du genre. Oupla une petite connexion SSH et tout va bien.
Je trouve ce principe plus intéressant que le "code par ports", dans le sens où il ne pourrait s'implanter que dans des connexions à des serveurs firewallés, et pas sur des routes comme on peut le faire avec authpf. De plus, le "code par ports" nécessite une implantation d'un tel standard dans les protocoles existant, ce qui pourrait s'avérer être lourd à faire.
Enfin, quiconque écoute la ligne trouvera la combinaison en question. je verrai plutôt un système à mi-chemin entre authpf et ton idée avec quelque chose en SSL, par exemple en HTTPS, où tu post une combinaison à un certain script perl qui s'occuperait de mettre à jour iptables. Après suffirait de recharger la requête de post de temps en temps pour éviter le déchargement des règles et tout serait OK.
Voilà voilà :)
[^] # Re: Pas mal !
Posté par khalahan . Évalué à 3.
http://www.openbsd-france.org/documentations/OpenBSD-authpf.html(...)
La solution HTTPS serait plus sécurisée en effet et éviterait les écoutes de lignes. Un simple serveur Apache + un script pour la mise en place, ou une simple démon qui attend sur un port précis une combinaison (en SSL tant qu'à faire).
La 2ème solution que je propose (tous les ports sont fermés (paquets rejetés), et le programme s'occupe de regarder le fichier de log) a l'avantage d'avoir tous les ports fermés sur la machine. Mais surtout, est-ce que ca ressemble pas trop à une "bidouille" d'analyser les logs comme ca ?
[^] # Re: Pas mal !
Posté par drac . Évalué à 1.
J'avais trouvé ça dans la doc de tldp.org sur les passerelles avec authentification:
http://tldp.org/HOWTO/Authentication-Gateway-HOWTO/services.html(...)
# Solutions plus simples :
Posté par Olivier (site web personnel) . É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
[^] # Re: Solutions plus simples :
Posté par khalahan . Évalué à 1.
Sinon, la 1ère solution avec 2 démons a l'air intéressante. Cependant, si l'on veut l'utiliser avec apache, apache ne devra pas être root (1 des threads est root, les autres sont identifiés comme "www-data" sur ma machine). J'entend parler de temps en temps de chrootage, et si j'ai bien compris ce que c'était ca résoudrait ce problème ?
[^] # Re: Solutions plus simples :
Posté par Olivier (site web personnel) . Évalué à 2.
J'ai Apache2 (2.0.47) sur la machine, et 6 process. Aucun ne sont root. C'est la configuration de base d'une Mdk 9.2. Tu dois avoir un problème de configuration de ton Apache.
J'entend parler de temps en temps de chrootage, et si j'ai bien compris ce que c'était ca résoudrait ce problème ?
Le chroot permet de faire fonctionner un programme/démon dans un "faux /" réduit à son plus strict minimum, et ne contenant pas de commandes systèmes. C'est un bon principe de sécurisation, mais il n'est pas absolu. il existe des techniques pour sortir des chroot, et retomber dans le "vrai /" : http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-04.htm(...) , partie "La prison"
Bref, le chroot c'est bien, mais ce n'est pas uen protection absolue. C'est juste une protection supplémentaire.
[^] # Re: Solutions plus simples :
Posté par khalahan . Évalué à 1.
J'ai vérifié la config d'Apache, et rien ne m'a paru anormal (apache 1.3.29.0.2-4). Je v googler un peu voir si c normal.
# Deja implementé: Port knocking
Posté par daggett . Évalué à 8.
"Port knocking is a method of establishing a connection to a networked computer that has no open ports . Before a connection is established, ports are opened using a port knock sequence, which is a series of connection attempts to closed ports."
# C'est quoi l'interet?
Posté par Tutur . Évalué à 3.
Personnelement, je prefere l'habituel login/password avec quelques régles simple: 2 tentatives ratés, 1 minutes avant de pouvoir se connecter. Tentatives raté suivantes 1 heures avant de pouvoir se connecter. Voir des password dynamique; je sais que ça existe, mais je sais pas comment ça fonctionnent.
Si tu veux cacher le service derriére le port, le plus simple et de modifier un tcp-wrapper (xinetd) pour qu'il demande un login/pass.
[^] # Re: C'est quoi l'interet?
Posté par ckyl . Évalué à 2.
Tu peux éviter ce genre de problème mais je suis pas très friand de ce genre de solution perso.
# Même pasmal
Posté par Gonéri Le Bouder (Mastodon) . Évalué à 0.
http://pasmal.casino770.com(...)
# NoCat ;-))
Posté par saorge . Évalué à 1.
Bon, alors, déjà, la petite boule de poil est super mignonne ;-)
Et au hasard de mes pérégrinations sur le Web, j'ai trouvé cela : http://www.campus.ecp.fr/~petrus/linux_nocat.php(...)
Apparemment, c'est un firewall dynamique, mais bon, je ne connais pas plus son fonctionnement (lecture en diagonale).
Et puis, le nom est trop marrant au vu du journal ;-)
[^] # Re: NoCat ;-))
Posté par khalahan . Évalué à 1.
Ca marche avec identification en https, pour autoriser l'accès au web. Un popup qui reste ouvert sert à renouveler le login/mot de passe toutes les 450 secondes (d'après le screen).
Maintenant armé de toutes ces solutions le choix sera plus facile :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.