Pouvez-vous cacher l'existence d'un serveur sur Internet?

Serait-il possible d'apparaître comme si un serveur n'existait pas? Est-il possible de faire croire à toutes les demandes que le nom d'hôte ne peut être résolu que si une phrase spécifique est fournie dans la demande? Existe-t-il des preuves de l'existence de serveurs qui ne pourraient pas être cachés par le propriétaire du serveur? Y aurait-il une sécurité pratique supplémentaire?

55
Vous pouvez créer un serveur Web totalement fermé jusqu'à ce qu'une chaîne secrète soit envoyée à un port spécifique. Cependant, les gens seraient toujours en mesure de savoir qu’il y avait quelque chose là-bas. Vous pouvez vous rapprocher de la configuration d’un serveur Web sombre.
ajouté l'auteur O'Niel, source
vous ne contrôlez pas le nom d’hôte en particulier, donc pas dans cette partie, mais l’idée générale de ce que vous demandez est possible avec un logiciel/matériel personnalisé. vous devez faire attention à ne pas "prendre des erreurs" comme la plupart des choses que tout le monde veut faire par défaut.
ajouté l'auteur dandavis, source
Est-ce que le fait d'avoir un serveur sur un réseau de transport de données avec un serveur local faisant face à la zone démilitarisée satisferait votre réponse? Techniquement, il existe un serveur qui sera exposé à un moment donné, mais il n'exposera pas le serveur de données réel s'il ne peut pas s'y connecter directement. C'est en fait une configuration vraiment commune. Le serveur d'applications Web IE est confronté à la zone DMZ et le serveur SQL ne l'est pas. Typiquement avec les transports dictés par un pare-feu.
ajouté l'auteur Bacon Brad, source

7 Réponses

Vous pouvez configurer votre serveur pour qu'il supprime normalement tous les paquets entrants et n'ouvre un port qu'après avoir reçu/détecté un ensemble de paquets spécifiant une séquence spécifique de ports (appelé port de cognement). J'utilise cette technique avec mon serveur; vous ne pouvez pas voir normalement le serveur car il supprime tous les paquets entrants. Une fois que les paquets qui frappent le port atteignent le serveur, celui-ci accepte les paquets de l'adresse de "frappe" mais continue de les laisser tomber à partir d'autres adresses.

La sécurité est meilleure avec cette méthode car les analyses IP et les tentatives de brutes ne vous poseront aucun problème. Pour pirater un serveur, il doit y avoir une reconnaissance, pour savoir quels services sont en cours d’exécution, quel type d’OS vous avez, etc. En refusant cette information à un attaquant, il sera plus difficile pour lui de lancer son attaque pour votre appareil. La faiblesse de cette défense est que si un attaquant peut voir les paquets de frappe entrants, il peut également ouvrir ce port.

79
ajouté
Mais il devrait être possible d'avoir un seul port UDP en écoute, où vous devez envoyer un seul paquet UDP contenant l'heure actuelle, signé avec votre clé privée. - le serveur n'ouvre une connexion TCP que si la signature est vérifiée et que l'heure n'a pas été antérieure à 3 secondes. - puisque le serveur ne répondra pas du tout au paquet, il n’existe toujours pas tant que vous n’avez pas envoyé le "knock signé"
ajouté l'auteur Tim Jansen, source
Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacé pour discuter .
ajouté l'auteur Rory Alsop, source

Serait-il possible d’apparaître comme si un serveur n’existait pas ... sauf si une phrase spécifique était fournie dans la demande?

Je suppose que vous parlez de HTTP (c'est-à-dire "web") et d'une requête HTTP ici bien que vous ne spécifiiez pas le type de requête que vous voulez réellement dire. Dans le cas d'une requête HTTP, une telle dissimulation n'est pas possible car HTTP est un protocole d'application au-dessus de TCP. Cela signifie que le client doit d'abord établir une connexion TCP qui implique une réponse du serveur avant même que le client envoie les données de l'application (c'est-à-dire la requête HTTP). Ainsi, l'existence du serveur HTTP est révélée indépendamment de la requête.

Cela peut être différent avec d'autres protocoles. Par exemple, DNS (résolution des noms d’hôte en adresse IP) est généralement traité dans UDP, qui est sans connexion contrairement à TCP. Cela signifie que la demande avec la charge utile est le premier paquet envoyé par le client. Ainsi, un serveur pourrait être créé avec UDP qui ne répond que si la demande DNS est destinée à un domaine spécifique et supprime toute autre demande. De cette façon, le serveur ne révélerait son existence que si la demande appropriée était envoyée. Des choses similaires pourraient être faites avec SIP (téléphonie sur Internet), ce qui se fait généralement également sur UDP.

Est-il possible que toutes les demandes croient que le nom d'hôte ne peut pas être résolu ...?

La résolution d'un nom d'hôte en une adresse IP est effectuée avant même d'envoyer la demande au serveur sur cette adresse IP. Généralement, le serveur lui-même n'est même pas impliqué dans ce processus de résolution DNS. Cela signifie que même avec des protocoles sans connexion, le client ne reçoit pas les informations indiquant que le nom ne peut pas être résolu si la requête était erronée. Tout ce que le client obtiendra est l'information que la cible ne répond pas, ce qui peut être interprété comme si aucun serveur n'est configuré sur cette adresse IP ou s'il est en panne, protégé par un pare-feu ou tout simplement en perdant des paquets inattendus.

16
ajouté
Si vous utilisez TCP Fast Open, les clients peuvent alors commencer à envoyer le premier paquet de données (avec l'en-tête GET) en même temps que la liaison TCP dans le premier paquet. Si vous avez besoin de chiffrer, TLS False Start + TLS 1.3 peut vous permettre d’envoyer des paquets chiffrés avec les protocoles TCP et TLS. En théorie, il devrait être possible de faire en sorte que le premier paquet contienne toujours la chaîne de frappe dans les en-têtes HTTP.
ajouté l'auteur Jay Corbett, source
il devrait être possible de configurer le client et le serveur pour que le serveur conserve les tickets de cookies/de reprise valides plus longtemps qu'ils ne le font par défaut, voire n'expire jamais les cookies/tickets. Avec une petite modification de la pile réseau du client, il devrait également être possible de laisser au client la clé de serveur Fast Open afin que le client puisse générer son propre cookie.
ajouté l'auteur Jay Corbett, source
@LieRyan: TCP Fast Open sert uniquement à se reconnecter car il doit utiliser un "cookie" provenant d'une connexion précédente. TLS 0-RTT similaire ne fonctionne que lors de la reprise d'une session. Cela signifie que le serveur doit toujours répondre au trafic TCP et TLS normal pour que la condition préalable à l'utilisation de Fast Open et de 0-RTT TLS puisse être remplie. Et cela signifie que le serveur ne peut pas être caché de cette façon avec TCP et TLS.
ajouté l'auteur Steffen Ullrich, source
@LieRyan: bien sûr, si vous avez la possibilité de changer la pile réseau à la fois sur le client et sur le serveur, vous pouvez faire presque n'importe quoi, comme démarrer chaque connexion avec un port frappant. Mais je ne pense pas que cela compte quand même comme "cache ... sauf si une phrase spécifique a été fournie dans la requête" car c'est bien plus qu'une phrase spéciale dans la requête - c'est une pile réseau modifiée à la fois sur le client et sur le serveur. au lieu.
ajouté l'auteur Steffen Ullrich, source

Serait-il possible d’apparaître comme si un serveur n’existait pas?

Oui, bien que ce ne soit pas trivial. Cela dépend du comportement de votre fournisseur de services Internet lorsqu'un serveur n'existe pas. Certains FAI configurent leurs routeurs pour qu'ils abandonnent les paquets lorsque l'adresse IP qu'un paquet tente d'atteindre n'existe pas, d'autres renvoient un message de rejet des paquets à l'expéditeur. En outre, certains routeurs ont un comportement adaptatif et modifient leur comportement s’ils pensent qu’il peut être attaqué. Certains fournisseurs de services Internet peuvent établir une discrimination en fonction de l'origine des paquets de détection (par exemple, les paquets provenant de pays/fournisseurs de services Internet hébergeant souvent des clients malveillants peuvent être traités de manière plus hostile que ceux utilisant de bonnes pratiques de réseau).

Si vous configurez votre serveur pour qu'il supprime simplement tous les paquets non reconnus, cela peut en fait être une preuve de l'existence du serveur si votre fournisseur de services Internet envoie normalement un message de rejet. Si le routeur de votre fournisseur de services Internet modifie de manière adaptative son comportement au cours d'une période d'attaque active et que votre serveur ne suit pas ce qu'il est en train de faire, il est possible que cela devienne réellement une preuve du serveur. En outre, votre fournisseur de services Internet peut avoir son propre fournisseur de services de base, lequel peut avoir son propre ensemble de comportements.

Est-il possible que toutes les demandes estiment que le nom d'hôte n'a pas pu être résolu

Oui, n'inscrivez pas vos noms d'hôtes dans le système DNS public. Les noms d'hôte dans le système DNS public sont intentionnellement des enregistrements publics. S'il est enregistré dans le DNS public, n'importe qui peut interroger les enregistrements DNS pour rechercher l'adresse IP associée au nom d'hôte. Vous pouvez cependant définir des noms d’hôte uniquement reconnus par vos machines (c’est-à-dire utiliser le fichier hosts) ou exécuter votre propre serveur DNS privé.

Existe-t-il des preuves de l'existence d'un serveur qui ne pourrait pas être masqué par le propriétaire du serveur?

Toute adresse IP publiquement routable possède un enregistrement de propriété publique qui peut être interrogé à l'aide de l'outil whois pour savoir qui est votre fournisseur de services Internet. Votre fournisseur de services Internet (ou un adversaire qui utilise ou travaille avec votre fournisseur de services Internet) peut surveiller tous les paquets transitant par son réseau et voir ces paquets entrants sans paquet sortant antérieur comme preuve d'un serveur.

Y aurait-il une sécurité pratique supplémentaire?

Si vous avez des pratiques de sécurité médiocres au départ, le fait d'être invisible peut effectivement détourner de nombreux robots simples et des attaquants non avertis. Des attaquants plus sophistiqués peuvent trouver des moyens de contourner l'invisibilité. Si vous avez de bonnes pratiques de sécurité, en utilisant une authentification et un cryptage forts, le fait d'être caché n'a pas beaucoup d'importance en termes de sécurité.

Le meilleur endroit pour cacher une feuille est probablement de le cacher dans un arbre/une forêt. Si vous exécutez un serveur connu publiquement et que vous chiffrez tout le trafic sur le serveur (HTTPS uniquement), les personnes extérieures ne peuvent guère faire la différence entre le trafic sur le site avant et le trafic sur le site caché. La seule chose à considérer est que TLS divulgue le nom d'hôte de destination dans l'en-tête SNI. Tant que vous falsifiez votre en-tête SNI ou si vous utilisez le nom d'hôte du serveur avant, votre serveur masqué reste masqué.

4
ajouté

J'utilise fwknop (" F ire W à tous les KN ock OP ") aux ports furtifs:

Avec fwknop déployé, toute personne utilisant nmap pour rechercher SSHD ne peut même pas   Dire qu'il écoute - cela ne fait aucune différence s'ils veulent courir   un pirate de mot de passe contre SSHD ou même s'ils ont un exploit de 0 jour.

Cela fonctionne même pour furtif < code> ssh ports derrière nat .

If you want to restrict access to a single ip you can achieve the same effect by running iptables with a default deny policy (iptables -P INPUT DROP) & adding allow rules for specific src ip addresses:

iptables -A INPUT -i eth0 -p tcp -s 1.2.3.4 --dport 80 -j ACCEPT

3
ajouté
  • première question: un peu mais pas vraiment. Vous pouvez rejeter tous les paquets entrants mais ceux que vous aimez mais les connexions réussies sont «visibles» (voir troisième point)
  • deuxième question: pas question. La résolution DNS ne gère pas la chaîne de requête de la demande, vous ne pouvez donc pas l'utiliser comme filtre
  • troisième question: oui, le trafic en provenance et à destination du serveur ne peut pas être masqué par les routeurs et/ou les mandataires entre la source et la destination, de sorte que l'existence de ce serveur est connue et ne peut pas être masquée (si vous n'êtes pas sur un darknet)
  • quatrième question: peut-être qu’il peut être utilisé en tant que couche supplémentaire, mais les idées et les mesures conventionnelles doivent tout de même être en place
2
ajouté

Il existe un autre moyen de masquer un serveur à Internet, à savoir l’utilisation d’un site TOR Hidden. Ces serveurs sont conçus uniquement pour être disponibles via le réseau TOR, et uniquement adressables avec une adresse TOR .onion.

Dans le passé, ces types de serveurs cachés étaient utilisés pour diverses raisons, telles que les sites anti-censure, le courrier électronique anonyme et, dans certains cas (comme The Silk Road), des sites cachés sont utilisés pour vendre/acheter des articles illégaux.

If you are interested, look here: https://www.torproject.org/docs/tor-hidden-service.html.en

2
ajouté
Les services cachés ne cachent pas son existence, en fait, ils feraient exactement le contraire et le confirmeraient via des serveurs d'annuaire. Il voudrait cacher son emplacement.
ajouté l'auteur Paul, source

Comme d'autres l'ont souligné, cette technique s'appelle le "port knock".

Moxie Marlinspike has created a tool called "knockknock" which does precisely this.

Je crois que l'explication sur le fonctionnement de l'outil est assez bonne pour comprendre le concept. Citant de sa page:

      
  • Les serveurs exécutent l'application "knockknock-daemon" de l'application python et les clients ouvrent des ports sur ces serveurs en exécutant l'application "knockknock" de python
  •   
  • Le "démon knockknock" renferme simplement kern.log. Il ne se lie pas à des sockets, ne charge pas libpcap et n’inspecte chaque paquet, ni n’envoie quoi que ce soit sur.   le réseau du tout.

  •   
  • Lorsque vous souhaitez ouvrir un port à partir d'un client, vous exécutez 'knockknock', qui envoie un seul paquet SYN au serveur. Le paquet IP et TCP   les en-têtes sont codés pour représenter une demande chiffrée sécurisée par IND-CCA   d'ouvrir un port spécifié à partir de l'adresse IP source.

  •   
  • Les champs de ce paquet sont enregistrés dans kern.log et traités par 'knockknock-daemon', qui les valide.
  •   
  • Vous vous connectez du client au port maintenant ouvert sur le serveur.
  •   
  • Le port se ferme derrière vous et n'autorise aucune nouvelle connexion.
  •   
1
ajouté