Aujourd'hui, je voudrais vous dire quelques mots sur le pare-feu Windows ou, comme on l'appelle dans le système d'exploitation russifié, le pare-feu. En général, c'est une très bonne chose, mais en particulier ... Il s'avère que par défaut cela fonctionne dans un mode plutôt intéressant. Comme le dit le proverbe: "Et les garçons ne savent pas." Alors, nous commençons à comprendre ce qui est quoi.
introduction
Tout d'abord, je vais expliquer l'essence du problème que je résolvais. J'ai dû vérifier comment la prochaine carte fonctionne correctement avec notre service All Hardware. Mais pas celui que j'ai vérifié dans l' un des articles précédents , mais plus sophistiqué, avec le FPGA Xilinx.
Qu'est-ce que le service All Hardware. C'est le site que l'utilisateur visite, se connecte et reçoit une liste des différentes cartes physiquement situées sur le serveur. Pourquoi fait-il ceci? Travailler avec la planche sans l'acheter. Par exemple, voyez si cela fonctionne pour lui, ou entraînez-vous simplement à travailler avec un contrôleur spécifique. Les tableaux sont fournis par les fabricants et le service leur permet une session à durée limitée. L'utilisateur sélectionne une carte dans la liste et obtient trois choses: l'adresse IP, le numéro de port et la vidéo de la caméra qui regarde cette disposition. En fait, vous pouvez toujours y transférer des ports via SSH, mais je ne suis pas un expert en eux. De ma part - exactement l'adresse, le port et la vidéo.
De plus, l'utilisateur de l'environnement de développement, qui est sur sa machine locale, doit sélectionner un débogueur distant (pour la plupart des environnements, c'est le bon vieux GDB, pour Keil c'est plus pervers, mais si vous êtes intéressé - vous pouvez faire un article séparé à ce sujet, cela ne s'applique pas au pare-feu). L'adresse IP et le port émis y sont dirigés, après quoi vous pouvez démarrer une session de débogage à distance, en vous concentrant sur ce qui se passe avec la carte par l'image de la caméra et par les ports transmis via SSH.
Ainsi, n'importe qui peut ressentir le travail avec différentes cartes de développement sans les acheter. En même temps, comme dans le cas de Redd, l'environnement de développement et les codes sources sont situés sur la machine locale. Seul le code binaire va au serveur. Mais après l'expiration de la session, l'automatisation efface la ROM, de sorte que le prochain utilisateur ne pourra pas lire le code.
Alors, revenons au sujet de l'article. Quel est le côté du pare-feu ici? C'est simple. J'ai dû travailler avec un FPGA Xilinx. Et leur environnement de développement est officiellement WebTalk. Je ne voulais pas qu'elle signale mes actions "là où elles devraient être", donc l'environnement se trouvait sur une machine non connectée au réseau. Même si elle le voulait vraiment, ses mains sont courtes. Il n'y a pas de canal physique et c'est tout! Mais le concept du service All Hardware est qu'il doit y avoir un réseau. Pour tester, la voiture a dû être temporairement connectée au fil (en fait, l'absence de réseau est plus une habitude, il n'y a toujours rien d'intéressant sur cette voiture). Que faire? Marchez sur la gorge de votre paranoïa? Eh bien, moi non! J'ai décidé de limiter l'environnement de développement à la liste des adresses autorisées afin qu'il ne puisse fonctionner qu'avec localhost et le serveur All Hardware. Je ne sais pas ce qui va se passer ensuiteet maintenant le serveur All Hardware a la même adresse IP. C'est juste que de nouveaux ports sont émis de session en session. Donc, l'objectif est clair, passons à la mise en œuvre.
Quel pare-feu dois-je prendre?
Sur Windows XP et Windows 7, j'ai utilisé Outpost Firewall. C'est une évolution nationale. Très fiable et confortable. Je me suis même acheté une licence à vie pour trois voitures en rupture de stock. Une fois, ce pare-feu m'a aidé à identifier un cheval de Troie qu'aucun antivirus n'a vu. Lorsque j'ai pu prendre le fichier avec le corps du virus, je l'ai transmis à plusieurs antivirus fournis sur le LiveCD. Personne n'a rien remarqué de suspect. Et mon pare-feu était juste dans un mode paranoïaque, d'où j'ai appris l'activité suspecte du programme.
Tout allait bien jusqu'à ce que le fabricant de ce pare-feu s'arrête dans des circonstances étranges. Après cela, je suis devenu très triste. Je suis tellement triste que mon ordinateur portable principal ait toujours un 7 avec Outpost, car je n'ai pas cherché de remplaçant. Mais l'IDE Xilinx veut le top dix! À la perfection! Il est donc temps d'apprendre à travailler avec le pare-feu intégré à ce système d'exploitation!
Nous savons tous que lorsqu'un programme tente d'accéder au réseau, ce pare-feu standard nous demande s'il doit ou non lui permettre de fonctionner avec le réseau. Nous pouvons interdire immédiatement, ou nous pouvons décocher la case d'autorisation après, il existe de nombreux guides à ce sujet sur le réseau. Ces cases à cocher sont:
Tout le monde sait ça. Mais quelle est la valeur de cette connaissance? J'oublierai mes réflexions qui m'ont accablé en lisant la masse du même type d'articles "comment interdire à une application de se mettre en ligne", qui ne disent pas comment ne pas l'interdire, mais seulement la restreindre. Je préfère montrer mes conclusions en utilisant un exemple spécialement conçu pour cela. Écrivons deux applications console les plus simples.
Serveur
La première application prétendra être un serveur. Il prend les paquets UDP qui contiennent des chaînes et les affiche à l'écran. Afin que nous puissions parler de la même chose, voici son code source C ++:
#include <iostream>
#include <winsock2.h>
#include <ws2tcpip.h>
// Need to link with Ws2_32.lib
#pragma comment (lib, "Ws2_32.lib")
#define DEFAULT_BUFLEN 16
int main(int argc, char** argv)
{
if (argc != 2)
{
printf("usage: ServerTest.exe port");
return -1;
}
WSADATA wsaData;
WSAStartup(MAKEWORD(2, 2), &wsaData);
// The socket address to be passed to bind
sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = INADDR_ANY;
addr.sin_port = htons((u_short)strtoul (argv[1],0,0));
SOCKET sock = socket(AF_INET, SOCK_DGRAM, 0/*IPPROTO_UDP*/);
bind(sock, (struct sockaddr*) &addr, sizeof(addr));
while (true)
{
struct sockaddr from;
int len = sizeof(from);
char buf[DEFAULT_BUFLEN];
memset(buf, 0, DEFAULT_BUFLEN);
recvfrom(sock, buf, DEFAULT_BUFLEN-1, 0, &from, &len);
printf(buf);
}
return 0;
}
Nous lançons ce programme, en passant le numéro de port (disons 1234) comme argument et recevons de manière prévisible une requête du pare-feu:
laissez-lui l'activité du réseau ... Laissez-le patienter, et nous écrirons la partie client comme un autre EXE.
Client
Laissez notre client envoyer les lignes tournantes au serveur. Voici son texte:
#include <iostream>
#include <winsock2.h>
#include <ws2tcpip.h>
#include "Windows.h"
// Need to link with Ws2_32.lib
#pragma comment (lib, "Ws2_32.lib")
#define DEFAULT_BUFLEN 16
int main(int argc, char** argv)
{
if (argc != 3)
{
printf("usage: ClientTest.exe address port");
return -1;
}
WSADATA wsaData;
WSAStartup(MAKEWORD(2, 2), &wsaData);
struct sockaddr_in server, client = { AF_INET,INADDR_ANY,INADDR_ANY };
memset(&server, 0, sizeof(server));
server.sin_family = AF_INET;
server.sin_port = htons((u_short)strtoul (argv[2],0,0));
InetPton(AF_INET, argv[1], &server.sin_addr.s_addr);
SOCKET sock = socket(PF_INET, SOCK_DGRAM, 0);
bind(sock, (sockaddr*)& client, sizeof(client));
for (int i=0;;i++)
{
static const char* sticks[] = { "\\\r","|\r","/\r","-\r" };
sendto(sock, sticks[i%4], strlen(sticks[i%4])+1, 0, (sockaddr*)& server, sizeof(server));
Sleep(250);
}
}
Nous commençons par spécifier l'adresse du serveur et le port que le serveur avait (je l'ai 192.168.1.95 et 1234), après quoi un autre légèrement différent commence à fonctionner dans la fenêtre du serveur que je voulais, mais toujours un bâton:
Mais ce qui m'inquiète ce n'est pas que le symbole "\ R" ne ramène pas le chariot au début de la ligne, mais le fait que le client est un processus distinct ... Lancé à partir d'un fichier complètement séparé! .. Et le pare-feu ne m'a pas demandé l'autorisation d'activité du réseau. Au lieu de cela, il l'a résolu lui-même, sans même m'informer que le programme irait quelque part. Comment?
Un peu de théorie sur les modes de fonctionnement du pare-feu
Nous arrivons ici à l'essence de l'article.
, Windows- , . , , - ( ), , , !
En fait, voici le paramètre de pare-feu correspondant: Tout ce
qui n'est pas interdit est autorisé. Une application peut se voir explicitement refuser une activité. C'est à cela que sont consacrés un très grand nombre d'articles sur Internet ... Mais le cheval de Troie montera imperceptiblement sur notre voiture, on ne devinera même pas qu'il doit être saisi dans des applications interdites. Encore une fois, cela ne résout pas mon problème présenté dans l'introduction de l'article. Je dois laisser l'accès à ces adresses que j'ai autorisées et refuser toutes les autres.
Pour ce faire, vous devez basculer le pare-feu en mode «tout ce qui n'est pas autorisé» pour les connexions sortantes. Je ne sais toujours pas comment entrer l'élément de menu correspondant ... Ouais, je l'ai trouvé ...
Et là, nous sélectionnons d'abord l'onglet correspondant au profil actif (dans ma photo c'était «Profil général», puis basculons la liste de sélection «Connexions sortantes» de «Autoriser (par défaut)» à «Bloquer».
Voilà, pouvons-nous bien dormir? Hélas? Si c'était aussi simple que ça, je suis sûr que Microsoft choisirait immédiatement le mode "Bloquer" pour tout le monde. C'est dommage, mais tout ne fait que commencer.
Un peu sur le masochisme appliqué
Alors. Disons que vous avez activé le mode de blocage pour les sorties ... Tout est mort en même temps, y compris les navigateurs. En général, personne ne se soucie à aucun moment de ramener le choix à l'ancienne position et de revenir à la version d'origine. Mais voyons ce que le nouveau régime nous donne en général. Nous obtenons une liste de règles. Et pour ces règles, vous pouvez définir une condition d'autorisation inconditionnelle, ou vous pouvez définir une liste de ports ouverts et une liste d'adresses ouvertes pour l'application. Les adresses peuvent être définies en tant que groupe. Voici la fenêtre des paramètres du port:
Voici la fenêtre des paramètres d'adresse:
De plus, personne ne se soucie d'ouvrir le port pour aucun programme, limitant la liste d'adresses valides pour cela. Autrement dit, nous ne disons pas "programme tel ou tel pour permettre l'accès à tel ou tel port", mais "tous les programmes fonctionnant via le port tel ou tel, permettent le travail, limitant les adresses au groupe suivant".
Tout est super sauf une chose. Si la liste des règles pour les connexions entrantes est générée par le système, vous devez tout ajouter vous-même pour les connexions sortantes. Comme je l'ai dit, mon navigateur est mort - j'ai dû l'ajouter moi-même aux boîtes d'envoi autorisées. Je ne décrirai pas comment les adresses sont configurées, ce n'est pas l'article. Les articles sur la définition de règles (dans le but de bloquer, cependant) sont un centime une douzaine. En général, j'ai généralement trouvé une règle appropriée pour les appels entrants, copié le nom du fichier à partir de là, puis - créé une règle pour les appels sortants, pointant vers le même fichier. Eh bien, et a permis l'activité à ce programme.
Lorsque j'ai eu un problème de connexion à un VPN au bureau, j'ai recherché une liste de règles prêtes à l'emploi et j'ai trouvé ceci (je savais à l'avance que notre connexion VPN était établie en utilisant le protocole L2TP):
La règle a été créée pour nous, mais pas activée. Je suis entré dans ses propriétés, je l'ai activé, après quoi une boule verte avec une coche est apparue à gauche dans la liste, et la connexion VPN au bureau a fonctionné.
Mais d'une manière ou d'une autre, mais en général, travailler avec un tel pare-feu sent le masochisme. Il faut avoir une volonté de fer pour ne pas crier: "Et tout cela est fatigué" et ne pas revenir à l'ancien mode de travail. J'ai presque atteint cet état (heureusement, les expériences avec Xilinx for All Hardware sont déjà terminées), mais une de mes connaissances m'a suggéré une belle solution.
Module complémentaire sur le pare-feu standard
Il s'avère qu'il existe un programme de contrôle du pare-feu Windows officiellement gratuit.
Il ne fait rien par lui-même, il gère simplement le pare-feu intégré à Windows, fournissant des interfaces très conviviales. Vous n'avez plus besoin de parcourir un tas de menus pour personnaliser quelque chose. Tous les paramètres sont regroupés de manière pratique et compacte sur plusieurs onglets. Je ne décrirai pas toutes les fonctions de ce programme. Le but de l'article n'est pas de le décrire, mais simplement de marquer son existence. De plus, tout le monde peut trouver des articles spécialisés, connaissant le nom de Windows Firewall Control.
Et maintenant, au démarrage de la partie client de l'exemple ci-dessus, j'ai finalement reçu un message:
je peux lui accorder l'accès, après quoi une règle sera automatiquement créée, je peux refuser l'accès, je peux bloquer l'application une fois.
Par souci d'intérêt, j'ai trouvé une règle créée automatiquement dans la liste des pare-feu standard et j'ai limité la liste des adresses disponibles pour celle-ci:
En général, la vie avec cette application est devenue beaucoup plus facile même en utilisant le pare-feu Windows standard. Tant mieux que cette machine Windows 10 est restée en ligne, pas aussi sans défense qu'auparavant.
Conclusion
Le pare-feu Windows standard fonctionne par défaut dans un mode tel que tout programme peut commencer à envoyer des données, dont l'utilisateur ne sera même pas informé. Personne ne cache cela, mais tout le monde ne le sait pas. Vous pouvez, bien sûr, installer un pare-feu tiers, mais il suffit amplement de basculer le pare-feu Windows standard en mode "tout interdit qui n'est pas autorisé". Malheureusement, il s'avère être un enfer de soutenir les performances du réseau avec des moyens réguliers. Mais un programme tiers et officiellement gratuit de contrôle du pare-feu Windows supprime cet inconvénient.
Que vous utilisiez un ensemble du pare-feu classique et de ce programme, ou que vous obteniez un pare-feu tiers, la question est ouverte. Mais le fait que l'utilisation du pare-feu standard en mode par défaut soit quelque peu effrayant, à mon avis, ne fait aucun doute.