Today I would like to tell you a few words about the Windows Firewall, or, as it is called in the Russified OS, the firewall. In general, this is a very good thing, but in particular ... It turns out that by default it works in a rather interesting mode. As the saying goes: "And the boys don't know." So, we begin to figure out what's what.
Introduction
First, I will explain the essence of the problem that I was solving. I had to check how the next board works correctly with our All Hardware service. But not the one that I checked in one of the previous articles , but more sophisticated, with the Xilinx FPGA.
What is the All Hardware service. This is the site that the user visits, logs in and receives a list of various boards physically located on the server. Why is he doing this? To work with the board without buying it. For example, see if it works for him, or just practice working with a specific controller. The boards are provided by the manufacturers, and the service provides a limited-time session with them. The user selects a board from the list and gets three things: IP address, port number and video from the camera that is looking at this layout. In fact, you can still forward ports through SSH there, but I'm not an expert in them. On my part - exactly the address, port and video.
Further, the user in the development environment, which is on his local machine, must select a remote debugger (for most environments this is the good old GDB, for Keil it is more perverse, but if you are interested, you can make a separate article about this, this does not apply to the firewall). The issued IP and port are driven in there, after which you can start a remote debugging session, focusing on what is happening with the board by the picture from the camera and by the ports forwarded through SSH.
Thus, anyone can feel the work with various development boards without buying them. At the same time, as in the case of Redd, the development environment and source codes are located on the local machine. Only binary code goes to the server. But after the expiration of the session, the automation erases the ROM, so that the next user will not be able to read the code.
So, back to the topic of the article. What is the side of the firewall here? It's simple. I had to work with a Xilinx FPGA. And their development environment is officially WebTalk. I didn’t want her to report my actions “where it should be,” so the environment was on a non-networked machine. Even if she really wanted to - her hands are short. There is no physical channel and that's it! But the concept of the All Hardware service is that there must be a network. To test, the car had to be temporarily connected to the wire (in fact, the lack of a network is more of a habit, there is still nothing interesting on that car). What to do? Step on the throat of your paranoia? Well, I do not! I decided to limit the development environment to the list of allowed addresses so that it can only work with localhost and the All Hardware server. I don't know what will happen nextand now the All Hardware server has the same IP address. It's just that new ports are issued from session to session. So, the goal is clear, let's proceed to implementation.
What firewall should I take?
On Windows XP and Windows 7, I used Outpost Firewall. This is a domestic development. Very reliable and comfortable. I even bought myself a lifetime license for three cars out of stock. Once this firewall helped me identify a Trojan that no antivirus has seen. When I was able to take the file with the virus body, I fed it to several antiviruses supplied on the LiveCD. None noticed anything suspicious. And my firewall was just in a paranoid mode, from where I learned about the suspicious activity of the program.
Everything was fine until the manufacturer of this firewall shut down under strange circumstances. After that, I became very sad. I got so sad that my main laptop still has a seven with Outpost, since I didn't look for a replacement. But the Xilinx IDE wants the top ten! Perfectly! So, it's time to learn how to work with the firewall built into this OS!
We all know that when a program tries to access the network, this standard firewall asks us whether to allow it to work with the network or not. We can prohibit immediately, or we can uncheck the permission box after, there are a lot of guides about this on the network. These checkboxes are:
Everyone knows that. But what is the value of this knowledge? I will omit my thoughts that overpowered me when reading the mass of the same type of articles "how to prohibit an application from going online", which do not tell how not to prohibit it, but only to restrict it. I'd rather show my conclusions using an example specially made for this. Let's write two simplest console applications.
Server
The first application will pretend to be a server. It takes UDP packets that contain strings and displays them on the screen. In order for us to talk about the same thing, here is its C ++ source code:
#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;
}
We launch this program, passing the port number (say, 1234) as an argument and predictably receive a request from the firewall:
Let him network activity ... Let him wait while, and we will write the client part as another EXE.
Client
Let our client send the spinning stick lines to the server. Here is its text:
#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);
}
}
We start by specifying the server address and the port that the server had (I have it 192.168.1.95 and 1234), after which a slightly different one starts to run in the server window than I wanted, but still a stick:
But what worries me is not that the symbol "\ R" does not return the carriage to the beginning of the line, but the fact that the client is a separate process ... Launched from a completely separate file! .. And the firewall did not ask me for permission to network activity. Instead, he resolved it himself, without even informing me that the program would go somewhere. How so?
A bit of theory about firewall operating modes
Here we come to the essence of the article.
, Windows- , . , , - ( ), , , !
Actually, here is the corresponding firewall setting: Anything
that is not prohibited is allowed. An application can be explicitly denied activity. This is what a huge number of articles on the Internet are devoted to ... But the Trojan will climb onto our car imperceptibly, we will not even guess what exactly it should be entered into prohibited applications. Again, this does not solve my problem presented in the introduction of the article. I need to leave access to those addresses that I allowed and deny all others.
To do this, you need to switch the firewall to the "forbidden everything that is not allowed" mode for outgoing connections. I am always confused how to enter the corresponding menu item ... Yeah, I found it ...
And there we first select the tab corresponding to the active profile (in my picture it was “General profile”, and then switch the “Outgoing connections” selection list from “Allow (default)” to “Block.”
That's it, can we sleep well? Alas? , no. If it were that simple, I'm sure Microsoft would immediately choose the "Block" mode for everyone. It's a pity, but everything is just beginning.
A little about applied masochism
So. Let's say you turned on blocking mode for outgoing messages ... Everything died right away, including browsers. In general, no one bothers at any time to return the choice to the old position and roll back to the original version. But let's see what the new regime gives us in general. We get a list of rules. And for these rules, you can set an unconditional permission condition, or you can set a list of open ports and a list of open addresses for the application. Addresses can be set as a group. Here is the port settings window:
Here is the address settings window:
Moreover, no one bothers to open the port for any programs, limiting the list of valid addresses for it. That is, we do not say "Program such and such to allow access to ports such and such", but "All programs working through port such and such, allow work, limiting the addresses to the next group."
Everything is great except for one thing. If the list of rules for incoming connections is generated by the system, then for outgoing connections you need to add everything yourself. As I said, my browser died - I had to add it to the allowed outboxes myself. I will not describe how addresses are configured, this is not the article. Articles about setting rules (for the purpose of blocking, however) are a dime a dozen. In general, I usually found a suitable rule for incoming, copied the file name from there, and then - created a rule for outgoing, pointing to the same file. Well, and allowed this program to be active.
When I had a problem with connecting to a VPN in the office, I researched a list of ready-made rules and found this (I knew in advance that our VPN connection is using the L2TP protocol):
The rule was created for us, but not activated. I went into its properties, activated it, after which a green ball with a checkmark appeared on the left in the list, and the VPN connection to the office worked.
But one way or another, but in general, working with such a firewall smacks of masochism. You need to have an iron will so as not to shout: "And this is all tired" and not to return to the old mode of work. I have almost reached this state (fortunately, experiments with Xilinx for All Hardware have already been completed), but one of my acquaintances suggested a beautiful solution to me.
Add-on over the standard firewall
It turns out there is an officially free Windows Firewall Control program.
It does nothing by itself, it just manages the firewall built into Windows, providing very user-friendly interfaces. Now you don't have to run through a bunch of menus to customize something. All settings are conveniently and compactly collected on several tabs. I will not describe all the functions of this program. The purpose of the article is not to describe it, but simply to mark its existence. Further - everyone can find specialized articles, knowing the name of Windows Firewall Control.
And now, when starting the client part from the example above, I finally received a message:
I can grant him access, after which a rule will be automatically created, I can deny access, I can block the application once.
For the sake of interest, I found an automatically created rule in the standard firewall list and limited the list of available addresses for it:
In general, with this application life has become much easier even when using the standard Windows Firewall. So much better that this Windows 10 machine stayed online, not as defenseless as it was before.
Conclusion
The standard Windows Firewall works by default in such a mode that any program can start sending data, about which the user will not even be informed. Nobody hides this, but not everyone knows about it. You can, of course, install a third-party firewall, but it is quite enough to switch the standard Windows Firewall to the "forbidden everything that is not allowed" mode. Unfortunately, it turns out to be hell to support network performance with regular means. But a third-party, officially free Windows Firewall Control program removes this inconvenience.
Whether you will use a bundle from the regular firewall and this program, or get a third-party firewall, the question is open. But the fact that using the standard firewall in the default mode is somewhat scary, in my opinion, is beyond doubt.