Pouvez-vous masquer l'existence d'un serveur sur Internet?
Serait-il possible d'apparaître comme s'il n'existait pas de serveur? Est-il possible que toutes les demandes croient que le nom d'hôte n'a pas pu être résolu à moins qu'une phrase spécifique n'ait été fournie dans la demande? Existe-t-il des preuves d'une existence de serveurs qui ne pourrait pas être cachée par le propriétaire du serveur? Y aurait-il une sécurité supplémentaire pratique?
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/vu un ensemble de paquets qui spécifient une séquence spécifique de ports (c'est ce qu'on appelle le port knocking). J'utilise cette technique avec mon serveur; vous ne pouvez normalement pas voir le serveur car il supprime tous les paquets entrants. Une fois que les paquets de frappe de port atteignent le serveur, le serveur accepte alors les paquets provenant de l'adresse de "frappe" mais continue de supprimer les paquets provenant d'autres adresses.
La sécurité est meilleure avec cette méthode car les analyses IP et les tentatives de brutes ne vous poseront pas beaucoup de problèmes. Pour pirater un serveur, il doit y avoir une reconnaissance, pour savoir quels services sont en cours d'exécution, quel type de système d'exploitation vous avez, etc. En refusant cette information à un attaquant, il lui est plus difficile de créer 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.
Serait-il possible d'apparaître comme s'il n'existait pas de serveur ... à moins qu'une expression spécifique n'ait été 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écifiez pas le type de requête que vous voulez réellement dire. En cas de requête HTTP, un tel masquage 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 que le client envoie même les données d'application (c'est-à-dire la requête HTTP) et donc l'existence du HTTP serveur est révélé indépendamment de la demande.
Cela peut être différent avec d'autres protocoles. Par exemple, DNS (résolution des noms d'hôtes en adresse IP) est généralement géré 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 concerne un domaine spécifique et abandonne 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) qui se fait généralement aussi sur UDP.
Est-il possible que toutes les demandes croient que le nom d'hôte n'a pas pu être résolu ...?
La résolution d'un nom d'hôte à une adresse IP est effectuée avant même d'envoyer la demande au serveur sur cette adresse IP et 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 n'obtient pas les informations selon lesquelles le nom ne peut pas être résolu si la demande était incorrecte. Tout au plus le client obtiendra-t-il les informations que la cible ne répond pas, ce qui pourrait être interprété comme qu'aucun serveur n'est configuré sur cette adresse IP ou que le serveur est en panne, protégé par un pare-feu ou simplement en laissant tomber des paquets inattendus.
Serait-il possible d'apparaître comme s'il n'existait pas de serveur?
Oui, bien que ce ne soit pas anodin. Cela dépend du comportement de votre FAI lorsqu'un serveur n'existe pas. Certains FAI configurent leurs routeurs pour supprimer les paquets lorsque l'adresse IP qu'un paquet essaie d'atteindre n'existe pas, d'autres renvoient un message de rejet de paquets à l'expéditeur. De plus, certains routeurs ont un comportement adaptatif et modifient leur comportement s'il pense qu'il peut être attaqué. Certains FAI peuvent discriminer en fonction de la provenance des paquets de sondage (par exemple, les paquets provenant de pays/FAI qui hébergent souvent des clients malveillants peuvent être traités plus hostiles que ceux ayant de bonnes pratiques de réseau).
Si vous configurez votre serveur pour supprimer simplement tous les paquets non reconnus, cela peut en fait prouver l'existence du serveur si votre FAI envoie normalement un message de rejet. Si le routeur de votre FAI change de manière adaptative son comportement pendant une période d'attaque active et que votre serveur ne suit pas ce que fait le FAI, cela peut en fait devenir une preuve du serveur. En outre, votre FAI peut avoir son propre FAI de liaison, qui peut avoir son propre ensemble de comportements.
Est-il possible que toutes les demandes croient que le nom d'hôte n'a pas pu être résolu
Oui, n'enregistrez simplement pas vos noms d'hôtes dans le système DNS public. Les noms d'hôtes dans le système DNS public sont des enregistrements publics intentionnels. S'il est enregistré dans le DNS public, n'importe qui peut interroger les enregistrements DNS pour rechercher l'adresse IP liée au nom d'hôte. Vous pouvez cependant définir des noms d'hôtes qui ne sont reconnus que par vos machines (c'est-à-dire utiliser le fichier hosts) ou exécuter votre propre serveur DNS privé.
Existe-t-il des preuves d'une existence de serveurs qui ne pourrait pas être cachée par le propriétaire du serveur?
Toute adresse IP publiquement routable a 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 FAI (ou un adversaire qui compromet ou travaille avec votre FAI) peut surveiller tous les paquets passant par leur réseau et il peut voir ces paquets entrants sans un paquet sortant antérieur comme preuve d'un serveur.
Y aurait-il une sécurité supplémentaire pratique?
Si vous avez de mauvaises pratiques de sécurité en premier lieu, alors être invisible peut effectivement repousser de nombreux bots simples et des attaquants peu sophistiqués. 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, être caché n'a pas beaucoup d'importance en termes de sécurité.
Le meilleur endroit pour cacher une feuille est probablement de la cacher dans un arbre/une forêt. Si vous exécutez un serveur connu du public et que vous cryptez tout le trafic vers le serveur (HTTPS uniquement), il n'y a pas grand-chose que les étrangers puissent faire pour distinguer le trafic vers le site frontal et le trafic vers le site caché. La seule chose que vous devez considérer est que TLS fuit le nom d'hôte de destination dans l'en-tête SNI. Tant que vous usurpez votre en-tête SNI ou si vous utilisez le nom d'hôte du serveur frontal, votre serveur caché reste caché.
J'utilise fwknop (" [~ # ~] f [~ # ~] ire [~ # ~] w [~ # ~] tous [~ # ~] kn [~ # ~] ock [~ # ~] op [~ # ~] erator ") vers les ports furtifs:
Avec fwknop déployé, quiconque utilise nmap pour rechercher SSHD ne peut même pas dire qu'il écoute - cela ne fait aucune différence s'ils veulent exécuter un cracker de mot de passe contre SSHD ou même s'ils ont un exploit de 0 jour.
Cela fonctionne même pour furtivité ssh ports derrière nat .
Si vous souhaitez restreindre l'accès à un seul ip, vous pouvez obtenir le même effet en exécutant iptables avec une stratégie de refus par défaut (iptables -P INPUT DROP) et l'ajout de règles d'autorisation pour des adresses IP spécifiques src:
iptables -A INPUT -i eth0 -p tcp -s 1.2.3.4 --dport 80 -j ACCEPT
- première question: un peu mais pas vraiment. Vous pouvez rejeter tous les paquets entrants, mais ceux que vous aimez, mais la connexion réussie 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 requête, vous ne pouvez donc pas l'utiliser comme filtre
- troisième question: oui, le trafic depuis et vers le serveur ne peut pas être caché aux routeurs et/ou aux proxys entre la source et la destination, donc l'existence de ce serveur est connue et ne peut pas être cachée (si vous n'êtes pas sur un darknet)
- quatrième question: peut-être qu'il peut être utilisé comme une couche supplémentaire, mais la sagesse et les mesures conventionnelles doivent être en place de toute façon
Il y a une autre façon d'avoir un serveur caché d'Internet, et c'est l'utilisation d'un site TOR Hidden. Ces serveurs sont conçus uniquement pour être disponibles via le réseau TOR et ne peuvent être adressés qu'avec une adresse TOR .onion.
Dans le passé, ce type de serveurs cachés a été utilisé pour diverses raisons, comme des sites anti-censure, des e-mails anonymes et, dans certains cas (comme The Silk Road), des sites cachés sont utilisés pour vendre/acheter des articles illégaux.
Si vous êtes intéressé, regardez ici: https://www.torproject.org/docs/tor-hidden-service.html.en
Comme d'autres l'ont souligné, cette technique est appelée "port knocking".
Moxie Marlinspike a créé un outil appelé "knockknock" qui fait précisément cela.
Je pense 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 python 'knockknock-daemon', et les clients ouvrent les ports sur ces serveurs en exécutant l'application python 'knockknock'
'knockknock-daemon' donne simplement kern.log. Il ne se lie à aucun socket, ne charge pas libpcap et inspecte chaque paquet, ou n'envoie rien sur le réseau.
Lorsque vous souhaitez ouvrir un port à partir d'un client, vous exécutez "knockknock", qui envoie un seul paquet SYN au serveur. L'IP du paquet et les en-têtes TCP sont codés pour représenter une demande chiffrée sécurisée IND-CCA pour 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.