Базовый файерволинг на базе Internet Protocol Security (IPSec) - Системное администрирование - Каталог статей - tsd.dmitrov.ru "ТЕХСОЮЗ" Дмитров Московская область
Базовый файерволинг на базе Internet Protocol Security (IPSec)
Прежде чем мы начнем разбирать вопрос базового файрволинга, хочу оговорить некоторые моменты:
Данный материал расчитан на подготовленного пользователя, который знает базовые принципы работы сети и сетевых программ.
Данный материал не является полным в контектсе названия, а будет
освещать лишь важные моменты, которые актуальны для домашнего
пользователя.
Лирическое отступление. Создание интернета можно
считать одинм из самых значимым творением за последние четверть века.
Интернет собой очень сильно изменил нашу жизнь, сделал нас более
осведомленными в происзодящем в мире, позволил очень быстро и
эффективно находить нужную информацию, сделал людей ближе друг к другу.
Интернет стал едва ли не единым каналом передачи данных (начиная от
обмена текстовыми сообщениями в telnet до пересылки правительственной
конфидециальных данных). Но вместе с тем принёс и негативные моменты –
появились хакеры. Их основная задача – использование интернета в своих
личных, корыстных целях (кража информации), или дестабилизация работы
сервисов интернета (например, DdOS-атаки, заражение машин вирусами).
Всем известно, что они представляют серьезную угрозу для владельцев
компьютеров или владельцев информации. С ростом технологий интернета,
технологии хакеров растут так же. Поэтому появилась необходимость в
защите от хакеров. В настоящее время пользователям предлагается
множество программных (антивирусы, файрволы) и аппаратных
(интеллектуальное активное сетевое оборудование. Например,
маршрутизаторы) решений. В данной статье мы рассмотрим один из
брандмауэров (файрволов), который уже интегрирован в систему Windows
2000/XP/Vista – IPSec. В настоящее время используется только 2 типа брандмауэров:
Основанный на путях к программам, которым разрешён/запрещён доступ к интернету.
Основанный на сетевых протоколах, адресах и портах, по которым разрешается доступ к интернету.
Разберём каждый из них определим их достоинства и недостатки.
Первый тип является наиболее распространённым среди пользователей. К ним относятся такие продукты как Outpost Firewall, Kerio Winroute Firewall (KWF), Windows Firewall, а также брандмауэры, которые встроены в антивирусные пакеты как Symantec Internet Security, Kaspersky Internet Security
и т.д. В чем заключается их принцип работы: вы указываете в правилах,
что такому-то приложению разрешён доступ к сети. При этом приложение
может делать в сети практически всё, что захочет и может занимать любые
порты, какие захочет. В этом заключается главная их проблема – они не
отслеживают трафик тех приложений, которые находятся в белом списке
(разрешённых). Это значит, что какое-то вредоносное ПО может
посредством стандартных API(Application Programming Interface)
функций (или через внутренний язык приложения) инициировать передачу
данных в сеть не обладая при этом разрешением выйти в сеть. Например
троянская программа может сгенерировать некотоый запрос и сформировать
его. Затем посредством внутренних функций передать его браузеру.
Браузер будет это видеть как будто сам пользователь на страничке
сгенерировал сообщение и передаст этот запрос в сеть (например, на
нестандартный порт троянского сервера). Количество таких троянских
программ сравнительно невелико, но они есть и их сбрасывать со счетов
нельзя. Конечно же, продвинутые брандмауэры позволяют настраивать
параметры протоколов, адресов и портов для создания правил, но я,
честно говоря, не видел никого, кто бы этим занимался. И их настройка
требует достаточно глубоких знаний работы сети вкупе к тому, что сами
конфигураторы весьма неудобны в работе. Однако в этом есть и свои
плюсы. Программные фаерволы не позволят неразрешенному приложению даже
отправить рядовой запрос на DNS-сервер, не говоря уже об остальном. В
достаточной степени это удобно, но ввиду недостатков, которые я описал
выше в ряде случаев эти брандмауэры могут создать брешь в системе
безопасности и обеспечить утечку информации (или её приток). Ещё одним
плюсом таких брандмауэров заключается в том, что они определяют
приложение не только по пути его размещения, но и по хэш-коду
программы. Соответственно, если программа из белого списка будет как-то
модифицирована (заражена), то изменится её размер и, соответственно,
новый хэш-код и потеряет членство в "белом" списке.
Второй тип
брандмауэров, который работает не на программном уровне (т.е. уровне
представления) а на сетевом. Таких фаерволов можно спокойно пересчитать
на пальцах: для linux-систем – ipfw для FreeBSD и netfilter/iptables для прочих linux-систем, и для Windows – IPSec(Internet Protocol Security) и Microsoft ISA Server(Internet Security and Acceleration Server). Справедливости ради, хочу отметить, что unix-реализация ipfw/iptables/netfilter
является наиболее совершенной, чем вообще любой брандмауэр под Windows.
Конкуренцию (по функционалу) здесь может составить разве что ISA Server,
который является и файрволом (к слову говоря, он относится в равной
степени к обоим типам файрволов) и прокси-сервером. Однако он обладает
слишком широкими возможностями, что Microsoft создала отдельный учебный
курс и сертификационный экзамен по этому продукту и он больше
оптимизирован под корпоративные решения с интеграцией с Active
Directory и в домашних условиях он не используется. Суть работы таких
брандмауэров заключается в том, что они не контролируют какое
приложение осуществляет доступ к сети. Т.е. любое приложение может
инициировать запрос в сеть, но его запрос должен будет пройти целый ряд
сетевых правил, которые решают судьбу пакета (т.е. передать или убить
его). Как отмечалось выше, что программные брандмауэры в большинстве
своём не следят за использованием портов приложениями. Поэтому, если
троянская программа подружилась с кем-то из "белого" списка
(посредством внутреннего языка приложения или API-функции), то она
сможет через посредника рассылать данные в любые точки интернета. С
IP-файрволами такие фокусы уже не проходят. Они строго ограничивают
трафик только по их служебному назначению и любая отправка пакета на
нестандартный удаленный порт (чем чаще всего и грешат такие троянские
программы) приложением будет пресечена на корню. В этом заключается их
главное преимущество, что они позволяют контролировать трафик на
основании нескольких критериев характера этого трафика. Например,
соответствие IP-адреса удаленного узла, его порта и протокола
транспортного уровня. Если хоть под одно из этих условий сгенерированный пакет не подпадает, то он будет тут же убит.
Например, вы не сможете создать TCP-сессию с удаленным узлом на 53-м
порту, т.к. весь TCP трафик по такому пункту назначения запрещается
(позже мы разберём, что порт 53 – порт DNS-сервера, а DNS работает с
клиентом только по UDP-транспортному протоколу). Иными словами как бы
не были хороши программные брандмауэры, но они не совершенны и имеют
свои недостатки. К тому же программные брандмауэры имеют достаточно
выскокий процент уязвимости, т.к. они используют в своей работе
стандартные API-функции (иного им не дано, увы) уязвимость в которых
отыскать куда проще, чем в остальных случаях. Например, если
сопоставить общее кол-во уязвимостей, которые были опубликованы для
Outpost Firewall и IPSec (а он как известно является открытым), то
соотношение по этому показателю будет очень огромное, т.к. IPSec
использует отличные от Outpost механизмы работы, которыми управлять
достаточно сложно. Если взять, к примеру, ISA Server, то за последние 3
года (с релизом ISA Server 2004) в нём не было найдено ни одной(!)
уязвимости в силу специфики их работы со стеком TCP/IP. Правда, здесь
хочу отметить, что IPSec и ISA по разным (которые недоступны сторонним
разработчикам) причинам очень тесно связаны с ядром ОС (которое в
Windows закрыто) и степень влияния вредоносного ПО на них снижается в
разы.
Примечание:
Хотелось бы отметить еще один факт, который относится ко всем
брандамауэрам без исключения, который сводит их полезность на «нет» -
работа под администраторской учётной записью. Дело в том, что
большинство брандмауэров имеют либо свой внутренний язык взаимодействия
с дургими приложениями или стандартные API-функции, что позволяет
другим приложениям общаться с брандмауэрам. Чем он популярней, тем
более критичным для него становится сей факт. При работе под
административной учетной записью троянской программе ничего не стоит
обратиться к брандмауэру через один из интерфейсов (например, API) и от
имени пользователя договориться о канале для себя (сымитировав
включение в "белый" список программы самим пользователем) либо вообще
прекратить его работу. В сети уже есть достаточно большое кол-во
случаев, когда троянские программы запущенные под привелегиями
администратора самовольно отключали он-лайн сканеры антивирусов и
прекращали работу брандмауэров или открывали для себя порты. Поэтому я
ещё раз хочу обратить ваше внимание на огромные риски постоянной работы
под администраторской учетной записью. Тут вам уже ничто не поможет,
поскольку административные полномочия позволяют почти всё и вы просто
потеряете контроль над системой. Поэтому, работая под администраторской
учетной записью полезность фаервола снижается очень и очень сильно.
Сразу
оговорюсь, что IPSec не является только брандмауэром и его основная
задача даже не является файрволингом. Если расшифровать термин, то
получим IPSec – Internet Protocol Security (выше было дано
определение) и IPSec был призван защищать трафик, который прохоидит
через сетевые карты. При желании трафик можно шифровать, защищать
пакеты от перехвата и их последующей переотправки и можно проверять
целостность сообщения (убедиться, что с момента отправки до получения
получателем пакет не модифицировался).
Для тех, кто знаком с
7-уровневой моделью OSI или 4-уровневой моделью TCP/IP могут понять,
что IPSec работает на самом нижнем уровне этой модели – уровень IP
(здесь и далее мы будем говорить только в рамках протокола TCP/IP
version 4). Ниже уровня IP нету ничего, что позволяет нам создавать
безопасность передачи данных не согласуя это с более высокими уровнями.
А теперь разберём некоторые термины, которые очень важны для понимания
данной статьи (Мы не будем разбирать процесс реализации модели OSI,
инкапсуляции пакетов и т.д. ).
Для начала мы введём понятие IP-адрес. Думаю, что всем это известно – уникальный адрес абонента в пределах глобальной сети/интрасети.
Порт
– вот тут остановимся поподробнее. На компьютере как правило
установлено несколько программ, которые работают с протоколом TCP/IP, а
значит, этому протоколу необходимо как-то различать конкретных
получателей (самый верхний уровень модели OSI). Скажем, у нас есть
сервер, на котором запущены службы HTTP и FTP при наличии только одного
IP-адреса. Эти две службы слушают канал и ждут, когда к ним придут
данные. А когда они придут, то по правилам его должен получить кто-то
один, кому эти данные нужны. Поэтому во всем мире договорились поделить
общий протокол TCP/IP на некие номера (как номера квартир) и на каждый
номер посадить слушающего. Так же, для унификации и стандартизации во
всем мире договорились, что общедоступные сетевые службы и приложения
будут использовать только свои номера, но не чужие. Например, во всем
мире все HTTP сервера (веб-сервера) сидят на порту под номером 80.
Поэтому при наборе адреса в адресной строке браузера нам нет
необходимости добавлять цифру 80, т.к. во всем мире договорились, что
веб-запросы отправляются только на порт 80 и эту процедуру за вас
сделает браузер. Соответственно, есть стандартная таблица соответствия
имен служб к прослушиваемых ими портам. Например:
FTP – 21
Telnet – 23
SMTP – 25
DNS – 53
DHCP - 68
HTTP – 80
POP3 – 110
NetBIOS – 139
HTTPS/SSL – 443
Номерами
портов мы уникально идентифицируем конкретную службу получатель на
удаленном компьютере, на котором этих служб можеть быть огромное
количество. Порт получателя обычно указывается через двоеточие (символ ":") сразу за адресом компьютера: 192.168.0.1:80 – данные для веб-сервера 192.168.0.1:110 – данные для POP3 сервера и т.д.
Краткое резюме:
На данном этапе мы поняли, что на одном компьютере с одним IP-адресом
может быть запущенно несколько сетевых приложений, как веб-сервер,
почтовый сервер и еще какой-нибудь. Для идентификации конкретной службы
мы ввели понятие сетевых портов при указании которого мы четко
указываем, какому сетевому сервису предназначается пакет. Важно понять,
что номер порта является простым числом, которое выполняет только одну
функцию – идентификация службы и больше ничего эта цифра не делает.
Мы
рассмотрели механизм разделения сетевых служб со стороны сервера. А
теперь рассмотрим ситуацию со стороны клиента. Самый типичный пример –
открытый браузер, в котором открыто несколько страниц (табов,
закладок). Как браузер знает в какое окно выводить информацию с сайта?
Здесь так же применяется метод разделения портов. Это значит, что
каждое клиентское окно (таб) браузера будет иметь свой уникальный номер
порта. Так же во всем мире договорились, что под клиентские приложения
выделяется определенный диапазон портов, на которых серверные службы
висеть никогда не будут. Диапазон выбран следующий: 1024-5000
(а при желании до 65535). Эти порты в Windows зарезервированы. Когда мы
открываем браузер и открываем первую страничку, то браузер обращается к
подсистеме Windows, чтобы та выделила свободный порт. Порт выбирается
произвольно, но, обычно, по порядку. Если никто из сетевых приложений
не работает, то система выделит для этого окна порт 1024. Этим
номером мы уникально идентифицируем конкретное приложение и конкретное
окно в приложении. Когда открываем другое окно (таб), то приложение
снова обращается за портом. Система выделяет первый свободный порт.
Можно предположить, что это будет порт 1025. Когда происходит обмен
данными с сервером, то мы в заголовке пакета указываем следующую
информацию:
IP адрес сервера;
Номер порта, на котором размещается требуемая служба на сервере;
IP адрес клиента (чтобы сервер знал куда обратно отправлять ответ);
Номер порта, на котором размещается служба/приложение клиента, которому нужно отдать эту информацию.
Тем
самым, когда у нас в двух окнах браузера открыты разные страницы одного
и того же сайта, у нас нету путаницы с обменом информации между одним
сервером и двумя окнами браузера. Тут важно запомнить, что сервер будет отвечать клиенту только на тот порт, с которого сервер получил запрос.
Сервер не будет гадать или наугад отправлять ответ, а отправит только
на тот порт, откуда пришел запрос. Если окно браузера с портом 1024
обменивается данными с сервером, то условный для брандмауэра маршрут
будет такой: Клиент отправляет запрос на сервер: 192.168.0.5:1024 -> 192.168.0.1:80 Клиент
сообщает серверу свой IP (192.168.0.5) и номер порта (1024), на который
следует отвечать серверу. Сервер же обработав запрос отправляет ответ: 192.168.0.1:80 -> 192.168.0.5:1024
Тем
самым клиент получив такой ответ передаст его окну приложения, которое
использует порт 1024, а не 1025 или еще какой-нибудь. Таким образом
один браузер может иметь и 10 открытых окон и отправлять одновременно
на один веб-сервер 10 индивидуальных запросов, при этом каждое окно
браузера уникально идентифицирует себя своим номером порта. Сервер
обработав каждый запрос в полном соответствии с самим запросом
сгенерирует ответные сообщения. И каждое ответное сообщение будет
отправлено именно тому окну браузера, которое сгенерировало запрос. Для
энтузиастов порекомендую приложение TCPView от Sysinternals
и понаблюдать за сетевыми приложениями. Вы увидите, что браузер
обращается к веб-серверу только к порту под номером 80 (так
договорились во всем мире). Это видно после знака двоеточия в колонке
Remote Address. И даже если у вас открыт один браузер, то в TCPView вы
увидите процессов браузера ровно столько, сколько у вас открыто
активных табов внутри браузера. Т.е. каждый таб себя уникально
идентифицирует.
Краткое резюме:
На данном этапе мы рассмотрели процесс взаимодействия клиентского
приложения и серверной службы. Мы знаем, что когда клиент генерирует
запрос на удаленный сервер, то сначала клиент обращается за уникальным
портом для себя и на этом порту клиент будет ждать ответа от сервера.
Сервер обработав запрос отправляет ответ именно на тот порт, с которого
пришел запрос. И эти правила соблюдаются всегда и в обязательном
порядке.
Изучив процесс взаимодействия клиента и сервера на
низком уровне (с указанием IP и портов) мы можем начинать изучение
взаимодействие на более высоком уровне – пользовательском. Как
известно, механизмы взаимодействия приложений в сети очень сложны и для
упрощения этого были введены некоторые сервисы и службы, которые
прозрачно для пользователя делают всю работу по преобразованию
пользовательского ввода в формат, который будет понятен более низкому и
сложному уровню. Как известно, компьютеры в сети общаются посредством
IP-адресов и портов. (если углубиться в сетевые технологии глубже, то
это утверждение будет не совсем верным, т.к. в реальности они общаются
по MAC-адресам и за процесс преобразования IP в MAC будет заниматься
протокол сетевой маршрутизации ARP. Этот вопрос выходит за рамки
текущей статьи и мы будем просто опутим этот процесс преобразования и
договоримся, что общение между узлами происходит по IP). Но в строке
браузера мы не пишем IP адрес веб-сервера, а пишем его дружественное
имя (например, freesoft.ru), которое пользователю запомнить гораздо проще, чем IP. Чтобы это имя преобразовать в IP используется технология DNS – Domain Name Service.
DNS в упрощённом варианте работает до тупости просто. Просто напротив
дружественного имени пишет его IP и всё. Когда клиент обращается к DNS
серверу за IP, то сервер производит поиск имени и когда его находит
возвращает вам IP адрес, который записан напротив этого имени. Все DNS сервера работают на 53-м порту.
Это стандарт. И любое приложение, отправляющее запрос на DNS сервер
будет отправлять его по умолчанию только на порт 53. Значит для того,
чтобы работать в сети с брузером нам нужно для каждого запроса сделать
2 вещи:
Проеобразовать имя веб-сервера в IP адрес путем запроса DNS сервера на порт 53.
Отправить запрос на веб-сервер, порт 80.
Когда
мы отправляем почту с клиента (MS Outlook, The Bat!, Mozilla
thunderbird и т.д.) на удалённый SMTP-сервер почтового сервера мы
должны проделать следующие операции:
Преобразовать имя почтового сервера (SMTP) в IP путем запроса DNS сервера на порт 53.
Отправить сообщение на SMTP сервер почтовика, порт 25.
Работая
с клиентскими приложениями функции DNS практически всегда обязательны.
Поэтому все брандмауэры пропускают трафик на 53-й порт, т.к. закрыв его
мы значительно усложняем себе жизнь и комфортность работы в сети. Процесс взаимодействия клиента с сервером DNS будет такой же, как и клиента с веб-сервером: 192.168.0.5:1065 -> 192.168.0.1:53 Клиент с произвольного порта отправляет запрос на 53-й порт сервера, а сервер ответит следующим образом: 192.168.0.1:53 -> 192.168.0.5:1065 Как мы здесь видим, то DNS сервер отвечает именно на тот порт, с которого был произведён запрос и клиент безошибочно определит кому доставить информацию.
Краткое резюме:
На данном этапе мы расмотрели взаимодействие и преобразование
пользовательской информации в более понятный компьютерный формат. Мы
поняли, что кроме явных запросов в сети существуют и неявные запросы,
такие как DNS-запросы, но которые необходимо учитывать при построении
файрвола.
А теперь займемся уже построением конкретных схем с
использованием информации, которую мы получили выше. Когда клиент
генерирует запрос, то мы знаем явно только 3 вещи:
IP-адрес назначения;
Порт назначения;
Адрес получателя.
Вы
спросите, почему здесь нету порта отправителя? Дело в том, что, как
выше отмечалось, исходящий порт для клиента выбирается динамически из
диапазона от 1024 до 5000 и этот процесс зачастую контролировать мы не
можем. Соответсвенно порт отправителя нам неизвестен.
Совет:
Хочется оговорить здесь следующий момент. Когда мы говорим о каком-то
неизвестном нам параметре (IP-адрес, порт, протокол и т.д.) мы это
неизвестное будем называть Any (в переводе с англ.яз. – Любой). Рассмотрим, из каких сервисов состоит только веб-браузинг:
Преобразование имен в IP-адреса путем отправки запроса на DNS-сервер, порт 53.
Стандартна служба HTTP. Все запросы отправляются на порт 80.
Когда мы регистрируемся или логинимся, или вводим конфиденциальную
информацию, то используется защищенный протокол HTTPS (Hyper Transport
Transfer Protocol Secured) или SSL (Secure Socket Layer). Все такие
запросы клиент отправляет только на порт 443.
Иногда на сайтах
предлагается скачать файл по FTP (File Transfer Protocol) через то же
окно браузера. Значит, на нужно знать, на каком порту работает
FTP-сервер. FTP работает на порту 21 (редко 22). По умолчанию браузер
будет отправлять запросы на FTP только на 21-й порт.
Теперь для каждого пункта составим таблицу исходного адреса/порта и адреса/порта получателя. 1.
Так как мы не знаем с какого порта мы будем взаимодействовать с
DNS-сервером (а с DNS будет взаимодействовать множество приложений и,
соответственно будет будет использоваться много исходящих портов), то
исходный порт нам неизвестен. По нашей договоренности исходящий порт
будет равен Any. Так же для поддержания универсальности мы договоримся, что локальный адрес отправителя (клиента) будем указывать как My IP Address. Дело в том, что у каждого пользователя будут свои индивидуальные адреса, которые соответствуют локальному адресу localhost(127.0.0.1). Т.е. этот универсальный адрес localhost будем называть My IP Address. Значит мы уже знаем как будет выглядеть полный адрес отправителя: My IP Address:any (это
значит, что запрос отправляет наш компьютер с произвольного порта,
который выделит нам система и его контролировать мы не в состоянии).
Адреса DNS-серверов нам неизвестны явно, они в каждом случае будут
разные. Но у них всех будет одно общее – порт 53. Значит получателя мы
запишем как: Any:53 Т.е.
конкретного адреса мы не знаем и их может быть много, но порт нам
известен. Если вы будете взаимодействовать только с одним или
несколькими известными DNS-серверами (например, с DNS-сервером
провайдера, что будет предпочтительным), то вместо адреса назначения
Any можете указать конкретный IP-адрес DNS-сервера (то же самое
относится и к дургим серверам).
Совет: Чтобы узнать адрес своего DNS-сервера (их адреса меняются очень редко) необходимо выполнить команду: Start -> Run... -> cmd В открывшемся окне набираем ipconfig /all и ищем адреса DNS-сервера (как правило их будет два).
Просто
в общем случае мы ставим Any, чтобы не быть зависимым от конкретных
сетевых настроек. Сложив обе половинки мы получим процесс запроса: From My IP Address:any -> any:53 Читается
как: с локального компьютера и с произвольного порта запрос может быть
отправлен на любой IP (Any) но только на порт 53. Еще раз повторюсь,
что все DNS-сервера сидят только на 53-м порту. Мы знаем, что DNS
(равно как и любая служба) отвечает с того же порта, на который
отправили запрос (в нашем случае 53) и на порт с которого был отправлен
запрос (его мы не знаем, т.к. он динамически выделяется). Значит DNS
должен ответить следующим образом (глазами клиента): From Any:53 -> My IP Address:any Читается
как: с любого IP в интернете и порта 53 (т.е. только от DNS сервера)
может быть отправлен на наш локальный компьютер и получить его может
любой порт. Если вы обратили внимание, то ответ является зеркальным (т.е. по сравнению с первым вариантом просто получатель и отправитель поменялись местами). Зеркалироваться ответы будут практически всегда и это нужно запонмить, т.к это очень упростит нам жизнь. Теперь подытожим цикл общения с DNS-сервером со стороны клиента: Запрос – from My IP Address:any -> any:53 Ответ – from any:53 -> My IP Address: any
2.
После того как мы разрешили имя в IP адрес, мы можем уже обращаться к
самому веб-серверу. Мы знаем, что будем отправлять запрос с локального
компьютера и неизвестного порта на любой IP (веб-серверов и веб-сайтов
в мире миллионы, поэтому упростим перечисление всех сайтов одним
параметром Any) и порт 80. From My IP Address:any -> Any:80 Читается
так же как и формулировка для DNS только порт будет не 53, а 80. Веб
сервер будет так же отвечать зеркально (получатель и отправитель
поменяются местами): From Any:80 -> My IP Address: Any Читается так же как и формулировка с DNS. Так мы можем подытожить взаимодействие локального компьютера с произвольным HTTP (веб) сервером: Запрос – from My IP Address:any -> Any:80 Ответ – Any:80 -> My IP Address: Any Следуя этой простой аналогии мы создаем правила прохода HTTPS/SSL: Запрос – from My IP Address:Any -> Any:443 Ответ – Any:443 -> My IP Address:Any И для FTP: Запрос – from My IP Address -> Any:21 Ответ – from Any:21 -> My IP Address:Any Если
вы еще не заметили, то мы с вами написали практически полноценные
правила для файрвола. Все аппаратные файрволы и программные файрволы
основанные на характере трафика (например, IPSec) создают именно такие
правила. Зная порт, на котором висит конкретная служба и, возможно,
адрес мы можем по этому принципу написать правила для взаимодействия
практически для любой сетевой службы. Например, для приёма почты по POP3: Запрос – from My IP Address -> Any:110 Ответ – from Any:110 -> My IP Address:Any Для SMTP: Запрос – from My IP Address -> Any:25 Ответ – from Any:25 -> My IP Address:Any Везде
всё будет одинаковым, за исключением номера порта службы. Сейчас я
постараюсь сделать выписку с наиболее часто используемыми сетевыми
службами в домашних условиях с указанием порта и транспортного
протокола (разбор транспортных протоколов как TCP/UDP выходит за рамки
данной статьи, вам просто нужно запомнить, какая служба на каком
транспортном протоколе работает):
FTP – 21 (TCP)
Telnet – 23 (TCP)
SMTP – 25 (TCP)
DNS – 53 (UDP)
DHCP – 68 (UDP)
HTTP – 80 (TCP)
Pop3 – 110 (TCP)
NetBIOS – 137, 138(UDP), 139(TCP)
HTTPS/SSL – 443 (TCP)
Remote Desktop/Remote Assistance 3389 (TCP)
RAdmin – 4899 (TCP)
Internet Radio – как правило 8000 (UDP).
Причечание:
Остальные приложения, как пиринговые клиенты (eMule, DC++, Torrents)
являются распределенными и требуют ручной настройки портов для своей
работы. Вы можете за этими приложениями закреплять любые порты в
диапазоне от 5000 до 65535 и потом на основе вами указанных портов
создавать правила. Подробнее проблему с пиринговыми клиентами разберём
отдельно, если это будет необходимо.
Краткое резюме:
На данном этапе мы изучили наиболее часто используемые порты сетевых
служб в интернете и основываясь на этой информации мы научились писать
самые настоящие правила для файрвола IPSec для работы с
распространёнными сетевыми службами интернета. По этой же аналогии
можно будет создавать правила и для других сетевых служб, которые не
отмечены в списке.
Настало время знакомиться с консолью IPSec,
которая есть в системе Windows 2000 и выше. Для работы с ней нам
необходимо зайти в систему под учетной записью администратора и меню
Run... (Выполнить...) запустить консоль MMC. В меню Action нужно
выбрать Add/Remove Snap-in. В раскрывшемся списке указать IP Security
Policy Management и перетащить в нашу консоль, после чего нажать Finish.
В
правом окне мы увидим уже 3 преднастроенные политики IPSec – Client
(Respond Only, Server (Request Security), Secure Server (Require
Security). Первая политика является самой простой и открытой, т.е.
трафик весь разрешён. При этом сам компьютер не инициирует соединения.
Вторая политика (Request Security) сначала пытается установить
защищённое соединение с удаленным узлом. Если ей это удается – то оно
устанавливается. Если нет – то соединение переходит в незащищённый
режим (обычный режим). Третья и наиболее жёсткая политика – Require
Security. При этом с данным компьютером можно установить защищённое
соединение (или данный компьютер с удалённым узлом). Если удаётся, то
оно устанавливается. Если нет, то компьютер не установит соединения и
будет блокировать все пакеты. В принципе, за основу можно взять любую
из них но мы создадим свою политику. Для этого нажмём в свободном месте
правой кнопкой мыши и выберем Create IP Security Policy и назовём её My
Computer Policy. Далее выбираем активировать Default Response Rule и
выбираем по умолчанию Kerberos
и соглашаемся с предупреждением. После чего мы должны увидеть следующее окно:
Вот
это окно будет для нас самым главным. Здесь мы будем видеть список всех
установленных нами правил (в граве IP Filter List), действие на правило
(Filter Action) и прочие параметры, которые нас в данный момент
интересовать не будут. Чтобы добавить новое правило, нажимаем кнопку
Add. В окне Tunnel Endpoint выставляем This rule does not specify a
tunnel. И продвигаемся дальше, выбираем для каких сетевых подключений
будет использоваться данное правило. Выберем All Network Conncections.
В следующем окне, которое будет выглядеть примерно так:
Выставляем
переключатель напротив All ICMP Traffic и нажимаем Next. После чего мы
увидим окно, которое называется Filter Action. Нетрудно догадаться, что
здесь будет выбираться действие, которое будет выполняться в случае,
если трафик подпадёт под это правило. Окно будет иметь вид:
И пока что есть 3 варианта. Это – Permit (разрешить), Request Security (запросить безопасное соединение. В случае неудачи установить обычное соединение) и Require Security (требовать безопасное соединение. В случае неудачи - разорвать соединение). ICMP – Internet Connection Management Protocol
– это особый вид трафика, который позволяет нам при помощи специальных
пакетов отслеживать проблемы прохождения пакетов и отслеживать узлы в
сети. Например, при отправке команды ping на удалённый узел система
отправляет специальный ICMP пакет. Если ICMP запретить, то вас никто не
сможет пропинговать, но и вы не сможете никому отправить пинг. К ICMP
пакетам относятся все пакеты, которые отправляются при команднах ping,
tracert, pathping и др. Чтобы в случае какой-то неисправности мы могли
бы проверить работу узла мы разрешим ICMP трафик и в качестве действия
выберем Permit. После чего нажимаем Next и Finish. Теперь мы вернулись
в главное окно нашей политики IPSec и видим, что создано правило для
ICMP пакетов. Если пакет подпадает под это правило (допустим, пингуем
машину), то он будет на основании действия на это правило разрешён.
Теперь повторяем операцию нажатием Add и кнопками Next доходим до окна IP Filter List. Здесь мы видим ещё один вид трафика – All IP Traffic.
К этому типу трафика будет относиться весь оставшийся трафик, который
будет существовать на данной машине. Выставляем переключатель напротив
этого пункта и нажимаем Next. Однако, согласно нашей стратегии мы будем запрещать весь(!) трафик,
за исключением разрешённых правилами типов трафика и который не будет
подпадать под наши правила. Для того, чтобы запретить весь трафик в
этом окне мы создадим новое действие для всего IP-трафика кнопкой Add.
В качестве названия действия выберем наиболее понятное слово – Deny (что знаить, запретить), а в поле Description напишем описание этого действия, например "Блокировать трафик»". Нажимаем Next и нам предлагаются следующие варианты: Permit (разрешить), Block (блокировать трафик) и Negotiate Security (требовать безопасность). Мы выберем здесь Block,
т.е. запрещаем трафик. После чего нажимаем Next и Finish. Мы снова
возвращаемся в окно Filter Action, где у нас появляется новое действие,
которое мы только что создали:
Выставляем переключатель напротив действия Deny
и нажимаем Next и Finish. Мы снова возвращаемся в главное окно нашей
политики, где мы наблюдаем, что у нас есть 2 правила для трафика (для
ICMP и для всего IP) и для каждого правила определено действие, которое
будет выполняться, если хоть один пакет подпадёт под одно из них. Если
сейчас активировать эту нашу политику, то кроме отправки и получения
ICMP пакетов у нас ничего работать не будет в сети. Эти два базовых
правила будут определять общее правило нашей всей политики. Общие
правила возможны следующие – "разрешить всё, кроме..." и "запретить всё, кроме..."
(так же как мы определяли базовые правила для Software Restriction
Policies). Т.к. мы весь IP трафик блокировали, то у нас получается
второе правило. Теперь настало время заполнить многоточия в общих
правилах и создать исключения для общего него.
Чтобы что-то
начало работать мы должны создать набор правил для того типа трафика,
который должен отправляться и приниматься. Выше мы уже рассматривали
как строятся эти правила и создадим первое из них – для отправки
пакетов на DNS-сервер, чтобы мы могли преобразовывать имена серверов в
их IP-адреса. Ещё раз вспомним, как этот трафик будет проходить: Запрос – from My IP Address:any -> any:53 Ответ – from any:53 -> My IP Address: any В главном окне нашей политики мы создаём новое правило кнопкой Add. Кнопками Next мы доходим до окна со списками фильтров IP Filter List, где у нас уже есть фильтры для ICMP и IP. Т.к. мы создаём новый фильтр (правило), то здесь мы нажимаем кнопку Add. В качестве имени мы введём название DNS Client и в поле Description
введём описание его (например,"преобразование имён серверов в
IP-адреса"). Теперь мы должны описать само правило конкретными
параметрами (адресами, портами и протоколами транспортного уровня). Для
этого нажимаем Add
Кнопками Next мы доходим до окна под названием IP Filter Description and Mirrored property.
Как мы отмечали выше, у нас все правила будут зеркалирова
