L'idée fausse selon laquelle un réseau commuté Ethernet == un réseau sécurisé. Ce n'est pas le cas.

Outre l'omniprésence d'outils d'empoisonnement d'arp tels que 'Cain & Abel' et leurs semblables, le fait que la table CAM s'arrête de temps en temps (par défaut, la table CAM n'est pas disponible). 5 minutes sur un commutateur Cisco ) et donc inonder le trafic unicast comme un hub se traduit par une fuite de paquets et donc une fuite potentielle d'informations.

Vous pouvez modifier la valeur du délai d'attente sur les commutateurs gérés pour compenser le degré d'inondation que vous souhaitez autoriser, mais étant donné que cela fait partie du fonctionnement de la commutation Ethernet, vous ne pouvez pas l'atténuer complètement.

Mythe : Doubler les bps d'une liaison double le débit utile.

Comme beaucoup de mythes, celui-ci peut peut être vrai dans certaines circonstances limitées, mais il ne tient pas compte de la latence de la liaison et des limites de performance des systèmes finaux et des protocoles.

L'augmentation du nombre de bps réduit le temps nécessaire à un système pour acheminer les données sur la liaison, mais ne permet pas aux données de se déplacer plus rapidement sur la liaison. Le temps nécessaire au début du premier bit pour arriver à l'autre extrémité est le même qu'avant, mais le délai jusqu'à l'arrivée du dernier bit est réduit.

J'ai quelques mythes liés aux réseaux privés (10.x.x.x, 192.168.x.x, etc.).

Mythe 1 : Les IP privées ne peuvent jamais apparaître sur le réseau public. Par conséquent, il est impossible qu'une IP privée qui n'est pas la vôtre apparaisse, par exemple, dans un listing traceroute ou dans les en-têtes SMTP "Received by".

Mythe 2 : Il n'est pas possible pour un serveur DNS tourné vers l'internet de distribuer des adresses IP de réseaux privés.

Ces deux mythes découlent de la même idée fausse : que les IP privées sont vraiment privées et qu'elles ne se mélangent jamais avec les IP publiques. Je crois que la spécification dit seulement que les IP privées ne doivent jamais être mélangées avec les IP publiques. Acheminé sur le réseau public. Autrement dit, si vous essayez de trouver la route vers une IP privée aléatoire (en supposant qu'elle ne se trouve pas sur votre propre réseau), vous n'arriverez à rien.

Mais cela n'empêche pas les IP privées d'apparaître dans la sortie ou le résultat d'une requête. Les serveurs de courrier interne, par exemple, n'ont pas d'adresse IP publique, alors quelle autre adresse IP que la leur peut figurer dans l'en-tête Received-By ?

De même, un grand réseau institutionnel peut utiliser différents réseaux privés parmi ses nombreux LAN. Les paquets qui traversent leur réseau capteront les IP privées des routeurs, même si le paquet finit par revenir sur le réseau public. Ainsi, un traceroute peut inclure l'IP privée d'un routeur dans sa sortie.

Mythe 3 : Les adresses de réseau privé n'étant pas routables, deux réseaux locaux qui partagent le même espace d'adressage de réseau privé peuvent être connectés via un pont (tel qu'un VPN) sans aucun problème.

Cela ne fonctionnera pas - du moins pas selon mon expérience. Disons que votre travail utilise le réseau 192.168.1.x et que vous utilisez le même à la maison (comme c'est le cas pour les routeurs grand public). Vous établissez une connexion VPN de votre PC à domicile vers votre lieu de travail. À un moment donné, vous voulez envoyer un travail d'impression à une imprimante au travail dont l'adresse IP est 192.168.1.10. Votre ordinateur personnel consulte sa table de routage pour savoir où envoyer ce paquet. Quel réseau local doit le recevoir : votre réseau local domestique ou votre réseau local professionnel ? Réponse : je ne sais pas. Peut-être celui-ci, peut-être celui-là. Un L'un d'entre eux l'obtiendra, mais cela dépend probablement de votre système d'exploitation et de votre logiciel VPN pour distinguer lequel est prioritaire. Si c'est comme le logiciel VPN avec lequel j'ai eu de l'expérience, votre réseau local domestique l'obtiendra et s'il n'y a pas d'appareil à 192.168.1.10, le paquet sera finalement abandonné.

Solution : lorsque vous utilisez un VPN, assurez-vous que les deux réseaux locaux utilisent des espaces réseau différents.

Et que dire de l'idée fausse selon laquelle il suffit de diviser la bande passante d'une liaison (en bits/sec) par 8 pour modéliser avec précision le nombre d'octets qu'elle fera transiter. Je mise toujours sur 75% (maximum) de huit dixièmes de la vitesse de la liaison (c'est-à-dire que pour une liaison de 10 GBps, je mise sur 600 MBps maximum).

OK, voici quelque chose que je viens de découvrir et qui m'avait échappé auparavant, pour chaque paquet que vous envoyez, il apparaît que l'overhead moyen est de 38 octets, ceci incluant l'en-tête IP et TCP (bien sûr, cette valeur suppose que tous les champs de l'en-tête TCP sont utilisés au maximum, que la taille de l'en-tête IP est une valeur commune, c'est-à-dire sans valeurs DSCP, etc, etc.), donc pour transférer disons 2 Mo (avec des tailles de paquets de 64 Ko augmentant le nombre de paquets par seconde [plus de paquets par seconde = moins d'overhead]), il faut compter 1,2 Ko d'overhead, ce qui n'est pas beaucoup mais équivaut à 6,78 Mo pour chaque 10 Go transférés, et 607,8 Mo pour chaque 1 To transférés.

Je me sens mieux maintenant :D