Иногда получается, что при выполнении очередного проекта, я случайно открываю какие-то обстоятельства, которые, вроде, никто не скрывает, можно даже найти документацию, поясняющую суть… Но многие, включая меня, находятся в плену заблуждений, поэтому не ищут ту документацию, полагаясь на совершенно неверную картину мира. У меня уже намечается целый цикл из статей, в которых я просто сообщаю, что всё, оказывается, не так, как многие (включая меня) думали. Была у меня статья про DMA, была статья про производительность шины PCI Express. К этому же циклу можно отнести статью про конфигурационные ПЗУ для ПЛИС Altera.
Сегодня мне хотелось бы рассказать пару слов про работу Windows Firewall, или, как его называют в русифицированной ОС – брандмауэра. В целом, это очень хорошая штука, но в частности… Оказывается, по умолчанию он работает в достаточно интересном режиме. Как говорится: «А пацаны и не знают». Итак, начинаем разбираться, что там к чему.
Сначала поясню суть задачи, которую я решал. Мне надо было проверить, насколько корректно работает очередная плата с нашим сервисом All Hardware. Но не та, которую я проверял в одной из прошлых статей, а более навороченная, с ПЛИС Xilinx.
Что представляет собой сервис All Hardware. Это сайт, на который пользователь заходит, авторизуется и получает список различных плат, физически размещённых на сервере. Зачем он это делает? Чтобы поработать с платой, не покупая её. Например, посмотреть, подойдёт ли она ему, или просто поупражняться в работе с конкретным контроллером. Платы предоставляют производители, а сервис – даёт сеанс работы с ними, ограниченный по времени. Пользователь выбирает плату из списка и получает три вещи: IP адрес, номер порта и видео с камеры, которая смотрит на эту макетку. На самом деле, там ещё можно через SSH пробрасывать порты, но в них я – не специалист. По моей части – именно адрес, порт и видео.
Дальше пользователь в среде разработки, которая стоит на его локальной машине, должен выбрать удалённый отладчик (для большинства сред это старый добрый GDB, для Кейла – более извратный, но если интересно – про это можно сделать отдельную статью, к фаерволу это не относится). Туда вбиваются выданные IP и порт, после чего можно начинать сеанс удалённой отладки, ориентируясь о происходящем с платой по картинке с камеры и по проброшенным через SSH-портам.
Таким образом, любой желающий может пощупать работу с различными отладочными платами, не покупая их. При этом, как и в случае с Redd, среда разработки и исходные коды размещаются на локальной машине. На сервер уходит только двоичный код. Но по истечении сеанса работы, автоматика стирает ПЗУ, так что следующий пользователь считать код уже не сможет.
Итак, возвращаемся к теме статьи. Каким боком здесь фаервол? Всё просто. Мне предстояло поработать с ПЛИС Xilinx. А их среда разработки совершенно официально обладает функцией WebTalk. Мне совершенно не хотелось, чтобы она сообщала о моих действиях «куда следует», поэтому среда стояла на несетевой машине. Даже если бы очень захотела – руки у неё коротки. Нет физического канала и всё тут! Но концепция сервиса All Hardware такова, что сеть быть должна. Для проверки машину пришлось временно подключать к проводу (на самом деле, отсутствие сети — это скорее привычка, на той машине всё равно ничего интересного нет). Что делать? Наступить на горло своей паранойе? Ну уж нет! Я решил ограничить среде разработки перечень разрешённых адресов, чтобы она могла работать только с localhost и сервером All Hardware. Не знаю, что будет потом, а сейчас у сервера All Hardware IP-адрес один и тот же. Просто от сеанса к сеансу выдаются новые порты. Итак, цель ясна, приступаем к реализации.
На Windows XP и Windows 7 я пользовался Outpost Firewall. Это отечественная разработка. Очень надёжная и удобная. Я даже купил себе по акции пожизненную лицензию на три машины. Однажды этот фаервол помог мне выявить трояна, которого не видел ни один антивирус. Когда я сумел взять файл с телом вируса, я скормил его нескольким антивирусам, поставляющимся на LiveCD. Ни один не заметил ничего подозрительного. А фаервол у меня просто был в параноидальном режиме, откуда я и узнал о подозрительной активности программы.
Всё было хорошо, пока производитель этого фаервола не закрылся при странных обстоятельствах. После этого, я сильно загрустил. Настолько загрустил, что на основном моём ноутбуке до сих пор стоит семёрка с Outpost, так как я не стал искать ему замену. Но среда разработки Xilinx хочет десятку! Прекрасно! Значит, пришла пора осваивать работу с фаерволом, встроенным в эту ОС!
Все мы знаем, что когда какая-то программа пытается получить доступ к сети, этот стандартный фаервол спрашивает у нас, разрешить ей работу с сетью или нет. Мы можем запретить сразу, а можем снять галочку разрешения после, об этом в сети имеется масса руководств. Вот эти галочки:
Это знают все. Но какова ценность этих знаний? Я опущу свои мысли, которые одолевали меня при чтении массы однотипных статей «как запретить приложению выход в сеть», не рассказывающих, как его не запретить, а только ограничить. Лучше я покажу свои выводы на специально сделанном для этого примере. Напишем два простейших консольных приложения.
Первое приложение будет прикидываться сервером. Оно принимает UDP-пакеты, в которых приходят строки, и отображает их на экране. Для того чтобы мы говорили об одном и том же, вот его исходный текст на С++:
Запускаем эту программу, передав в качестве аргумента номер порта (скажем, 1234) и предсказуемо получаем запрос от фаервола:
Разрешим ему сетевую активность… Пусть он пока ждёт, а мы напишем клиентскую часть в виде другого EXE-шника.
Пусть наш клиент шлёт серверу строки с крутящейся палочкой. Вот его текст:
Запускаем, указав адрес сервера и порт, который был у сервера (у меня это 192.168.1.95 и 1234), после чего в серверном окне начинает бежать чуть иная, чем я хотел, но всё же палочка:
Но волнует меня не то, что символ “\r” не возвращает каретку в начало строки, а то, что клиент – это отдельный процесс… Запускаемый из совершенно отдельного файла!.. А фаервол не запросил у меня разрешения на его сетевую активность. Вместо этого, он разрешил её сам, даже не поставив меня в известность о том, что программа куда-то полезет. Как так?
Вот тут мы подошли к сути статьи.
Собственно, вот соответствующая настройка фаервола:
Разрешено всё, что не запрещено. Приложению можно явно запретить активность. Именно этому посвящено огромное количество статей в Интернете… Но троян заберётся на нашу машину незаметно, мы и не догадаемся, что именно его надо занести в запрещённые приложения. Опять же, это не решает моей задачи, вынесенной во введение статьи. Мне надо оставить доступ к тем адресам, которые я разрешил и запретить все остальные.
Чтобы это сделать, надо перевести фаервол в режим «запрещено всё, что не разрешено» для исходящих соединений. Я вечно путаюсь, как войти в соответствующий пункт меню… Ага, нашёл…
И там сначала выбираем вкладку, соответствующую активному профилю (на моём рисунке это был «Общий профиль», а затем переключаем список выбора «Исходящие подключения» из «Разрешить (по умолчанию)» в «Блокировать».
Всё, мы можем спать спокойно? Увы, нет. Если бы всё было так просто – уверен, компания Microsoft сразу выбирала бы режим «Блокировать» для всех. Жаль, но всё только начинается.
Итак. Допустим, вы включили режим блокировки для исходящих… Сразу умерло всё, включая браузеры. В целом, никто не мешает в любой момент вернуть выбор в старое положение и откатиться к исходному варианту. Но давайте посмотрим, что нам вообще даёт новый режим. Мы получаем список правил. И у этих правил можно задать безусловное условие разрешения, а можно задать для приложения список открытых портов и список открытых адресов. Адреса можно задавать группой. Вот окно настройки портов:
Вот окно настройки адресов:
Мало того, никто не мешает открыть порт для любых программ, ограничив список допустимых адресов ему. То есть, мы говорим не «Программе такой-то разрешить доступ к портам таким-то», а «Всем программам, работающим через порт такой-то, разрешить работу, ограничив адреса следующей группой».
Всё замечательно, кроме одного. Если список правил для входящих соединений нам формирует система, то для исходящих всё надо добавлять самому. Как я говорил, у меня умер браузер – мне пришлось добавить его в разрешённые исходящие самостоятельно. Как настраиваются адреса, я не буду описывать, статья не об этом. Статей про настройку правил (с целью блокировки, правда) – пруд пруди. В целом, обычно я находил подходящее правило для входящих, копировал имя файла оттуда, после чего – создавал правило для исходящих, указав тот же файл. Ну, и разрешал активность этой программе.
Когда у меня возникла проблема с подключением к VPN в офисе, я поисследовал список готовых правил и нашёл вот такое (я заранее знал, что у нас VPN подключение идёт по протоколу L2TP):
Правило создано за нас, но не активировано. Я зашёл в его свойства, активировал его, после чего слева в списке появился зелёный шарик с галочкой, а VPN-соединение с офисом заработало.
Но так или иначе, а в целом, работа с таким фаерволом попахивает мазохизмом. Надо иметь железную волю, чтобы не закричать: «А надоело это всё» и не вернуться к старому режиму работы. Я уже почти дошёл до этого состояния (благо опыты с Xilinx для All Hardware уже были завершены), но один мой знакомый подсказал мне красивое решение.
Оказывается, есть официально бесплатная программа Windows Firewall Control.
Она сама по себе ничего не делает, а просто управляет фаерволом, встроенным в Windows, предоставляя очень удобные интерфейсы. Теперь не надо бегать через кучу меню, чтобы что-то настроить. Все настройки удобно и компактно собраны на нескольких вкладках. Расписывать все функции этой программы я не буду. Цель статьи – не описать её, а просто отметить её существование. Дальше – все желающие смогут найти специализированные статьи, зная имя Windows Firewall Control.
И вот теперь при запуске клиентской части из примера выше, я наконец-то получил сообщение:
Я могу разрешить ему доступ, после чего будет автоматически создано правило, я могу запретить доступ, я могу заблокировать приложение однократно.
Вот я ради интереса нашёл автоматически созданное правило в штатном списке фаервола и ограничил ему список доступных адресов:
В общем, с этим приложением жизнь стала намного проще даже при использовании штатного Windows Firewall. Настолько лучше, что эта машина с Windows 10 осталась в сети, ведь она уже не так беззащитна, как была до того.
Штатный Windows Firewall по умолчанию работает в таком режиме, что любая программа может начать отсылать данные, о чём пользователь даже не будет проинформирован. Это никто не скрывает, но не все об этом знают. Можно, конечно, поставить сторонний фаервол, но вполне достаточно перевести штатный Windows Firewall в режим «запрещено всё, что не разрешено». К сожалению, при этом поддержка сетевой работоспособности штатными средствами превращается в ад. Но сторонняя официально бесплатная программа Windows Firewall Control устраняет это неудобство.
Будете ли вы пользоваться связкой из штатного фаервола и этой программы, либо достанете сторонний фаервол, вопрос открытый. Но то, что использовать штатный фаервол в режиме по умолчанию несколько боязно, по-моему, не подлежит сомнению.
Сегодня мне хотелось бы рассказать пару слов про работу Windows Firewall, или, как его называют в русифицированной ОС – брандмауэра. В целом, это очень хорошая штука, но в частности… Оказывается, по умолчанию он работает в достаточно интересном режиме. Как говорится: «А пацаны и не знают». Итак, начинаем разбираться, что там к чему.
Введение
Сначала поясню суть задачи, которую я решал. Мне надо было проверить, насколько корректно работает очередная плата с нашим сервисом All Hardware. Но не та, которую я проверял в одной из прошлых статей, а более навороченная, с ПЛИС Xilinx.
Что представляет собой сервис All Hardware. Это сайт, на который пользователь заходит, авторизуется и получает список различных плат, физически размещённых на сервере. Зачем он это делает? Чтобы поработать с платой, не покупая её. Например, посмотреть, подойдёт ли она ему, или просто поупражняться в работе с конкретным контроллером. Платы предоставляют производители, а сервис – даёт сеанс работы с ними, ограниченный по времени. Пользователь выбирает плату из списка и получает три вещи: IP адрес, номер порта и видео с камеры, которая смотрит на эту макетку. На самом деле, там ещё можно через SSH пробрасывать порты, но в них я – не специалист. По моей части – именно адрес, порт и видео.
Дальше пользователь в среде разработки, которая стоит на его локальной машине, должен выбрать удалённый отладчик (для большинства сред это старый добрый GDB, для Кейла – более извратный, но если интересно – про это можно сделать отдельную статью, к фаерволу это не относится). Туда вбиваются выданные IP и порт, после чего можно начинать сеанс удалённой отладки, ориентируясь о происходящем с платой по картинке с камеры и по проброшенным через SSH-портам.
Таким образом, любой желающий может пощупать работу с различными отладочными платами, не покупая их. При этом, как и в случае с Redd, среда разработки и исходные коды размещаются на локальной машине. На сервер уходит только двоичный код. Но по истечении сеанса работы, автоматика стирает ПЗУ, так что следующий пользователь считать код уже не сможет.
Итак, возвращаемся к теме статьи. Каким боком здесь фаервол? Всё просто. Мне предстояло поработать с ПЛИС Xilinx. А их среда разработки совершенно официально обладает функцией WebTalk. Мне совершенно не хотелось, чтобы она сообщала о моих действиях «куда следует», поэтому среда стояла на несетевой машине. Даже если бы очень захотела – руки у неё коротки. Нет физического канала и всё тут! Но концепция сервиса All Hardware такова, что сеть быть должна. Для проверки машину пришлось временно подключать к проводу (на самом деле, отсутствие сети — это скорее привычка, на той машине всё равно ничего интересного нет). Что делать? Наступить на горло своей паранойе? Ну уж нет! Я решил ограничить среде разработки перечень разрешённых адресов, чтобы она могла работать только с localhost и сервером All Hardware. Не знаю, что будет потом, а сейчас у сервера All Hardware IP-адрес один и тот же. Просто от сеанса к сеансу выдаются новые порты. Итак, цель ясна, приступаем к реализации.
Какой фаервол взять?
На Windows XP и Windows 7 я пользовался Outpost Firewall. Это отечественная разработка. Очень надёжная и удобная. Я даже купил себе по акции пожизненную лицензию на три машины. Однажды этот фаервол помог мне выявить трояна, которого не видел ни один антивирус. Когда я сумел взять файл с телом вируса, я скормил его нескольким антивирусам, поставляющимся на LiveCD. Ни один не заметил ничего подозрительного. А фаервол у меня просто был в параноидальном режиме, откуда я и узнал о подозрительной активности программы.
Всё было хорошо, пока производитель этого фаервола не закрылся при странных обстоятельствах. После этого, я сильно загрустил. Настолько загрустил, что на основном моём ноутбуке до сих пор стоит семёрка с Outpost, так как я не стал искать ему замену. Но среда разработки Xilinx хочет десятку! Прекрасно! Значит, пришла пора осваивать работу с фаерволом, встроенным в эту ОС!
Все мы знаем, что когда какая-то программа пытается получить доступ к сети, этот стандартный фаервол спрашивает у нас, разрешить ей работу с сетью или нет. Мы можем запретить сразу, а можем снять галочку разрешения после, об этом в сети имеется масса руководств. Вот эти галочки:
Это знают все. Но какова ценность этих знаний? Я опущу свои мысли, которые одолевали меня при чтении массы однотипных статей «как запретить приложению выход в сеть», не рассказывающих, как его не запретить, а только ограничить. Лучше я покажу свои выводы на специально сделанном для этого примере. Напишем два простейших консольных приложения.
Сервер
Первое приложение будет прикидываться сервером. Оно принимает UDP-пакеты, в которых приходят строки, и отображает их на экране. Для того чтобы мы говорили об одном и том же, вот его исходный текст на С++:
#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;
}
Запускаем эту программу, передав в качестве аргумента номер порта (скажем, 1234) и предсказуемо получаем запрос от фаервола:
Разрешим ему сетевую активность… Пусть он пока ждёт, а мы напишем клиентскую часть в виде другого EXE-шника.
Клиент
Пусть наш клиент шлёт серверу строки с крутящейся палочкой. Вот его текст:
#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);
}
}
Запускаем, указав адрес сервера и порт, который был у сервера (у меня это 192.168.1.95 и 1234), после чего в серверном окне начинает бежать чуть иная, чем я хотел, но всё же палочка:
Но волнует меня не то, что символ “\r” не возвращает каретку в начало строки, а то, что клиент – это отдельный процесс… Запускаемый из совершенно отдельного файла!.. А фаервол не запросил у меня разрешения на его сетевую активность. Вместо этого, он разрешил её сам, даже не поставив меня в известность о том, что программа куда-то полезет. Как так?
Немного теории о режимах работы фаервола
Вот тут мы подошли к сути статьи.
По умолчанию, Windows-фаервол разрешает все исходящие соединения, если они не запрещены явно. То есть, к нам не смогут подключиться извне, но если какая-то программа проникла на нашу машину (или мы поставили её добровольно), она вполне может отсылать, что угодно, и никто ей по умолчанию это не запретит!
Собственно, вот соответствующая настройка фаервола:
Разрешено всё, что не запрещено. Приложению можно явно запретить активность. Именно этому посвящено огромное количество статей в Интернете… Но троян заберётся на нашу машину незаметно, мы и не догадаемся, что именно его надо занести в запрещённые приложения. Опять же, это не решает моей задачи, вынесенной во введение статьи. Мне надо оставить доступ к тем адресам, которые я разрешил и запретить все остальные.
Чтобы это сделать, надо перевести фаервол в режим «запрещено всё, что не разрешено» для исходящих соединений. Я вечно путаюсь, как войти в соответствующий пункт меню… Ага, нашёл…
И там сначала выбираем вкладку, соответствующую активному профилю (на моём рисунке это был «Общий профиль», а затем переключаем список выбора «Исходящие подключения» из «Разрешить (по умолчанию)» в «Блокировать».
Всё, мы можем спать спокойно? Увы, нет. Если бы всё было так просто – уверен, компания Microsoft сразу выбирала бы режим «Блокировать» для всех. Жаль, но всё только начинается.
Немного о прикладном мазохизме
Итак. Допустим, вы включили режим блокировки для исходящих… Сразу умерло всё, включая браузеры. В целом, никто не мешает в любой момент вернуть выбор в старое положение и откатиться к исходному варианту. Но давайте посмотрим, что нам вообще даёт новый режим. Мы получаем список правил. И у этих правил можно задать безусловное условие разрешения, а можно задать для приложения список открытых портов и список открытых адресов. Адреса можно задавать группой. Вот окно настройки портов:
Вот окно настройки адресов:
Мало того, никто не мешает открыть порт для любых программ, ограничив список допустимых адресов ему. То есть, мы говорим не «Программе такой-то разрешить доступ к портам таким-то», а «Всем программам, работающим через порт такой-то, разрешить работу, ограничив адреса следующей группой».
Всё замечательно, кроме одного. Если список правил для входящих соединений нам формирует система, то для исходящих всё надо добавлять самому. Как я говорил, у меня умер браузер – мне пришлось добавить его в разрешённые исходящие самостоятельно. Как настраиваются адреса, я не буду описывать, статья не об этом. Статей про настройку правил (с целью блокировки, правда) – пруд пруди. В целом, обычно я находил подходящее правило для входящих, копировал имя файла оттуда, после чего – создавал правило для исходящих, указав тот же файл. Ну, и разрешал активность этой программе.
Когда у меня возникла проблема с подключением к VPN в офисе, я поисследовал список готовых правил и нашёл вот такое (я заранее знал, что у нас VPN подключение идёт по протоколу L2TP):
Правило создано за нас, но не активировано. Я зашёл в его свойства, активировал его, после чего слева в списке появился зелёный шарик с галочкой, а VPN-соединение с офисом заработало.
Но так или иначе, а в целом, работа с таким фаерволом попахивает мазохизмом. Надо иметь железную волю, чтобы не закричать: «А надоело это всё» и не вернуться к старому режиму работы. Я уже почти дошёл до этого состояния (благо опыты с Xilinx для All Hardware уже были завершены), но один мой знакомый подсказал мне красивое решение.
Надстройка над штатным фаерволом
Оказывается, есть официально бесплатная программа Windows Firewall Control.
Она сама по себе ничего не делает, а просто управляет фаерволом, встроенным в Windows, предоставляя очень удобные интерфейсы. Теперь не надо бегать через кучу меню, чтобы что-то настроить. Все настройки удобно и компактно собраны на нескольких вкладках. Расписывать все функции этой программы я не буду. Цель статьи – не описать её, а просто отметить её существование. Дальше – все желающие смогут найти специализированные статьи, зная имя Windows Firewall Control.
И вот теперь при запуске клиентской части из примера выше, я наконец-то получил сообщение:
Я могу разрешить ему доступ, после чего будет автоматически создано правило, я могу запретить доступ, я могу заблокировать приложение однократно.
Вот я ради интереса нашёл автоматически созданное правило в штатном списке фаервола и ограничил ему список доступных адресов:
В общем, с этим приложением жизнь стала намного проще даже при использовании штатного Windows Firewall. Настолько лучше, что эта машина с Windows 10 осталась в сети, ведь она уже не так беззащитна, как была до того.
Заключение
Штатный Windows Firewall по умолчанию работает в таком режиме, что любая программа может начать отсылать данные, о чём пользователь даже не будет проинформирован. Это никто не скрывает, но не все об этом знают. Можно, конечно, поставить сторонний фаервол, но вполне достаточно перевести штатный Windows Firewall в режим «запрещено всё, что не разрешено». К сожалению, при этом поддержка сетевой работоспособности штатными средствами превращается в ад. Но сторонняя официально бесплатная программа Windows Firewall Control устраняет это неудобство.
Будете ли вы пользоваться связкой из штатного фаервола и этой программы, либо достанете сторонний фаервол, вопрос открытый. Но то, что использовать штатный фаервол в режиме по умолчанию несколько боязно, по-моему, не подлежит сомнению.
lair
Да нет, вполне подлежит. Мне вот не боязно.