Разблокируй icmp трафик windows 7. Cisco ACL для продвинутых
Нередко пользователей раздражает медлительность в работе интернета. Особенно это относится к многочисленной армии любителей сетевых игр. Можно сократить время потенциальных задержек, отключив функцию ping.
Вам понадобится
- - ПК с установленной операционной системой Windows;
- - доступ в интернет.
Инструкция
Инструкция
Каким образом можно сконфигурировать компьютеры под управлением Windows 2000/XP/2003 на блокирование Ping пакетов? Windows 2000/XP/2003 имеет встроенный механизм безопастности IP, называемых IPSec (IP Security). IPSec это протокол разработанный для защиты индивидуальных TCP/IP пакетов при передачи их через сеть.
Однако мы не будем вдаваться в подробности функционирования и устройства IPsec, ибо помимо шифрования, IPSec может также защищать ваш сервер или рабочую станцию механизмом, похожим на файерволл.
Блокируем PING на одиночном компьютере
Для блокирования всех PING пакетов с компьютера и на него нам необходимо создать полититку IPSec, которая будет блокировать весь ICMP трафик. Для начала проверьте отвечает ли ваш компьютер на ICMP запросы:
Для настройки одиночного компьютера нам необходимо выполнить следующие шаги:
Сконфигурируем список IP Filter Lists и Filter Actions
- Откройте окно MMC (Start > Run > MMC).
- Добавьте оснастку IP Security and Policy Management.
- Выберите какой компьютер будет управляться этой политикой – в нашем случае это локальный компьтер. Нажмите Close, потом нажмитеOk.
- Правой кнопкой нажмите на IP Security Policies в левой половине консоле MMC. Выберите Manage IP Filter Lists and Filter Actions.
- Вам не нужно настраивать или создавать IP фильтр для ICMP (протокол в котором работает PING), так как такой фильтр уже существует по умолчанию – All ICMP Traffic.
Однако вы можете сконфигурировать сколь угодно сложный IP фильтр, к примеру запретить пинговать ваш компьютер со всех IP, кроме нескольких определенных. В одной из следующих статей посвященных IPSec мы подробно рассмотрим создание IP фильтров, следите за обновлениями.
- В окне Manage IP Filter Lists and Filter actions просмотрите ваши фильтры и если все в порядке нажмите на вкладку Manage Filter Actions. Теперь нам нужно добавить действие для фильтра, которое будет блокировать определенный трафик, нажмем Add.
- В первом окне приветствия нажимаем Next.
- В поле Filter Action Name вводим Block и нажимаем Next.
- В Filter Action General Options выбираем Block, после чего жмем Next.
- Вернитесь в окно Manage IP Filter Lists and Filter actions и просмотрите ваши фильтры и если все в порядке, нажмите Close. Вы можете добавить фильтры и действия для фильтров в любое время.
Следующим шагом будет конфигурирование политики IPSec и её применение.
Конфигурируем политику IPSe
- В той же MMC консоле нажмите правой кнопкой по IP Security Policies и выберите Create IP Security Policy.
- Пропустите приветствие мастера нажав Next.
- В поле IP Security Policy Name введите соответствующее случаю имя, например “Block PING”. Нажмите Next
- В окне Запросов безопасного соединения сними галочку с чекбокса Active the Default Response Rule. НажмитеNext
- Отметьте чекбокс изменить свойства и нажмите Finish.
- Нам нужно добавить IP фильтры и действия фильтров в новую политику IPSec. В окне новый политике IPSec нажмите Add
- Нажмите Next.
- В окне Tunnel Endpoint убедитесь что выбрано значение по умолчанию и нажмите Next.
Научиться настройке MikroTik можно на онлайн курсе по оборудованию этого производителя. Автор курса является сертифицированным тренером MikroTik. Подробней Вы можете прочитать в конце статьи.
Статья отвечает на вопрос насколько опасно блокировать ICMP трафик.
ICMP - яблоко раздора
Многие сетевые администраторы считают, что протокол межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) представляет собой угрозу безопасности и поэтому должен всегда блокироваться на . Это правда, что протокол имеет некоторые связанные с этим проблемы безопасности, и что часть запросов должна быть заблокирована. Но это не повод блокировать весь ICMP-трафик!
ICMP-трафик имеет много важных функций; какие то из них полезны для устранения неполадок, другие же необходимы для правильной работы сети. Ниже приведены сведения о некоторых важных составляющих ICMP протокола, о которых вы должны знать. Следует подумать над тем, как оптимальным образом пропускать их через вашу сеть.
Echo запрос и and Echo ответ
IPv4 – Echo запрос (Type8, Code0) и Echo ответ (Type0, Code0)
IPv6 – Echo запрос (Type128, Code0) and Echo ответ (Type129, Code0)
Мы все хорошо знаем, что ping, - один из первых инструментов для поиска и устранения неполадок. Да, если вы включите на своем оборудование обработку ICMP-пакетов, то это значит, что ваш хост теперь доступен для обнаружения, но разве ваш уже не слушает порт 80, и не отправляет ответы на клиентские запросы? Конечно, заблокируйте ещё и эти запросы, если вы действительно хотите, чтобы на границе сети была ваша DMZ. Но блокируя ICMP трафик внутри вашей сети, не усилите защиту, напротив получите систему с излишне сложным процессом поиска и устранения неполадок («Проверьте пожалуйста отзывается ли шлюз на сетевые запросы?», «Нет, но это меня ничуть не расстраивает, потому что мне это ничего не скажет! »).
Помните, также можете разрешить прохождение запросов в определенном направлении; например, настроить оборудование так, чтобы Echo запросы из вашей сети проходили в сеть Интернет и Echo ответы из Интернета в вашу сеть, но не наоборот.
Необходима фрагментация пакета (IPv4) / Пакет слишком большой (IPv6)
IPv4 – (Type3, Code4)
IPv6 – (Type2, Code0)
Данные компоненты протокола ICMP очень важны, так как являются важным компонентом в Path MTU Discovery (PMTUD), который является неотъемлемой частью протокола TCP. Позволяет двум хостам корректировать значение максимального размера сегмента TCP (MSS) до значения, которое будет соответствовать наименьшему MTU по пути связей между двумя адресатами. Если на пути следования пакетов будет узел с меньшим Maximum Transmission Unit, чем у отправителя или получателя, и у них не будет средств для обнаружения данной коллизии, то трафик будет незаметно отбрасывается. И вы не будете понимать что происходит с каналом связи; другими словами, «для вас наступят веселые деньки».
Don’t Fragment – ICMP не пройдет!
Передача IPv4-пакетов с установленным битом Don’t Fragment (большинство из них!) или IPv6-пакетов (помним, что в IPv6 нет фрагментации маршрутизаторами), которые слишком велики для передачи через интерфейс, приведёт к тому, что маршрутизатор отбросит пакет и сформирует ответ источнику передачи с следующими ICMP-ошибками: Требуется Фрагментация (Fragmentation Required ), либо Пакет Слишком Большой (Packet Too Big). Если ответы с этими ошибками не смогут вернуться к отправителю, то он будет интерпретировать отсутствие подтверждающих ответов о доставке пакетов ACK (Acknowledge ) от получателя в качестве перегрузки / потери и источником для повторной передачи пакетов, которые также будут отбрасываться.
Сложно выявить причину подобной проблемы и быстро устранить, процесс обмена TCP-рукопожатиями (TCP-handshake) работает нормально, поскольку в нем задействованы небольшие пакеты, но как только происходит массовая передача данных сеанс передачи зависает, так как источник передачи не получает сообщения об ошибках.
Исследование пути доставки пакетов
RFC 4821 был разработан для того, чтобы помочь участникам передачи трафика в сети обойти эту проблему, используя исследование пути распространения пакетов (Path MTU Discovery (PLPMTUD) . Стандарт позволяет обнаружить максимальный объём данных (Maximum Transmission Unit (MTU) , который может быть передан протоколом за одну итерацию, путем постепенного увеличения максимального размера полезного блока данных (Maximum Segment Size (MSS) , для того чтобы найти максимально возможную величину пакета без его фрагментации на пути следования от передатчика к приемнику. Данный функционал уменьшает зависимость от своевременного получения ответов с ошибками по протоколу межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) и доступен в большинстве сетевых стеков устройств и клиентских операционных систем. К сожалению, он не так эффективен, как непосредственное получение данных о максимальном возможном размере передаваемых пакетов. Пожалуйста, позвольте этим сообщениям протокола ICMP возвращаться к источнику передачи, хорошо?
Превышение времени передачи пакетов
IPv4 – (Type11, Code0)
IPv6 – (Type3, Code0)
Traceroute - очень полезный инструмент для устранения неполадок в сетевых соединениях между двумя хостами, подробно описывающий каждый шаг пути.
Отправляет пакет с временем жизни пакета данных для протокола IP (Time to live (TTL) равным 1 , чтобы первый маршрутизатор отправил сообщение с ошибкой (включая собственный IP-адрес) о превышении времени жизни пакета. Затем отправляет пакет с TTL 2 и так далее. Данная процедура необходима для того, чтобы обнаружить каждый узел на пути следования пакетов.
NDP and SLAAC (IPv6)
Router Solicitation (RS) (Type133, Code0)
Router Advertisement (RA) (Type134, Code0)
Neighbour Solicitation (NS) (Type135, Code0)
Neighbour Advertisement (NA) (Type136, Code0)
Redirect (Type137, Code0)
В то время как IPv4 использовал протокол разрешения адресов (ARP) для сопоставления 2 и 3 уровней сетевой модели OSI, IPv6 использует другой подход в виде протокола обнаружения соседей (NDP). NDP предоставляет множество функций, включая обнаружение маршрутизатора, обнаружение префикса, разрешение адреса и многое другое. В дополнение к NDP, Автоконфигурация (StateLess Address AutoConfiguration (SLAAC) позволяет динамически настраивать хост в сети, аналогично концепции протокола динамической настройки узла (Dynamic Host Configuration Protocol (DHCP) (хотя DHCPv6 предназначается для более тонкого управления).
Эти пять типов ICMP сообщений не должны блокироваться внутри вашей сети (не учитываем внешний периметр), чтобы протокол передачи данных IP функционировал правильно.
Нумерация типов ICMP
Протокол межсетевых управляющих сообщений (ICMP) содержит много сообщений, которые идентифицируются полем «тип».
| Тип | Наименование | Спецификация |
|---|---|---|
| 0 | Echo Reply | |
| 1 | Unassigned | |
| 2 | Unassigned | |
| 3 | Destination Unreachable | |
| 4 | Source Quench (Deprecated) | |
| 5 | Redirect | |
| 6 | Alternate Host Address (Deprecated) | |
| 7 | Unassigned | |
| 8 | Echo | |
| 9 | Router Advertisement | |
| 10 | Router Solicitation | |
| 11 | Time Exceeded | |
| 12 | Parameter Problem | |
| 13 | Timestamp | |
| 14 | Timestamp Reply | |
| 15 | Information Request (Deprecated) | |
| 16 | Information Reply (Deprecated) | |
| 17 | Address Mask Request (Deprecated) | |
| 18 | Address Mask Reply (Deprecated) | |
| 19 | Reserved (for Security) | Solo |
| 20-29 | Reserved (for Robustness Experiment) | ZSu |
| 30 | Traceroute (Deprecated) | |
| 31 | Datagram Conversion Error (Deprecated) | |
| 32 | Mobile Host Redirect (Deprecated) | David_Johnson |
| 33 | IPv6 Where-Are-You (Deprecated) | |
| 34 | IPv6 I-Am-Here (Deprecated) | |
| 35 | Mobile Registration Request (Deprecated) | |
| 36 | Mobile Registration Reply (Deprecated) | |
| 37 | Domain Name Request (Deprecated) | |
| 38 | Domain Name Reply (Deprecated) | |
| 39 | SKIP (Deprecated) | |
| 40 | Photuris | |
| 41 | ICMP messages utilized by experimental mobility protocols such as Seamoby | |
| 42 | Extended Echo Request | |
| 43 | Extended Echo Reply | |
| 44-252 | Unassigned | |
| 253 | RFC3692-style Experiment 1 | |
| 254 | RFC3692-style Experiment 2 | |
| 255 | Reserved |
Пара слов об ограничении скорости
Хотя ICMP-сообщения, подобные тем, которые описаны в статье, могут быть очень полезными, помните, что генерация всех этих сообщений занимает процессорное время на ваших маршрутизаторах и генерирует трафик. Вы действительно ожидаете, что вы получите 1000 пингов в секунду через ваш брандмауэр в обычной ситуации? Будет ли это считаться нормальным трафиком? Вероятно, нет. Ограничивайте пропускную способность сети для этих типов ICMP трафика, как вы считаете нужным; этот шаг может помочь вам в защите вашей сети.
Читать, исследовать и понимать
Учитывая, что обсуждение темы «блокировать или не блокировать» ICMP-пакетов, всегда приводит к путанице, спорам и разногласиям, предлагаю продолжить изучать эту тему самостоятельно. На этой странице привел много ссылок, считаю для более полного понимания проблематики следует потратить время на их чтение. И сделать осознанный выбор того, что лучше всего подходит для вашей сети.
MikroTik: куда нажать, чтобы заработало?
При всех своих достоинствах, есть у продукции компании MikroTik один минус – много разобщенной и далеко не всегда достоверной информации о ее настройке. Рекомендуем проверенный источник на русском языке, где все собрано, логично и структурировано – видеокурс «Настройка оборудования MikroTik ». В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект. Все материалы остаются у вас бессрочно. Начало курса можно посмотреть бесплатно, оставив заявку на странице курса. Автор курса является сертифицированным тренером MikroTik.
Брандмауэр - первая линия защиты любого сервера, и от его правильной настройки зависит, сможет ли злоумышленник продвинуться дальше в своих попытках проникновения в систему. Современные файеры предлагают множество механизмов обеспечения безопасности, используя которые ты можешь оставить «не у дел» 99% атакующих. И все это без необходимости покупки дорогостоящего оборудования и коммерческого софта.
Главная цель всех взломщиков - получение доступа к командному интерпретатору сервера для использования его возможностей в своих интересах. Наиболее часто проникновение в «святая святых» осуществляется с помощью дыр в сервисах или же через подбор пароля (брутфорс) к одному из них (например, ssh).
Сканирование портов
Чтобы выявить наличие уязвимых сервисов на машине, атакующий производит разведку с помощью сканера портов и различных систем обнаружения уязвимостей. Обычно в качестве сканера портов используется nmap, который способен осуществлять сканирование десятком различных способов и в некоторых случаях умеет выявлять версии ОС и сервисов. Вот список особенно популярных флагов nmap, которые обычно используют взломщики:
Флаги nmap, используемые при сканировании
- -sT - обычное TCP-сканирование с помощью открытия соединения на указанный порт и его завершения;
- -sS - SYN/ACK-сканирование, связь разрывается сразу после ответа на запрос открытия соединения;
- -sU - UDP-сканирование;
- -sF - сканирование пакетами с установленным флагом FIN;
- -sX - сканирование пакетами с установленными флагами FIN, PSH и URG;
- -sN - сканирование пакетами без установленных флагов.
Метод защиты от сканирования прост и известен любому системному администратору. Заключается он в простом закрытии всех сервисов, которые не должны быть видны из внешней сети. Например, если на машине работают сервисы ssh, samba и apache, а из внешнего мира должен быть виден только веб-сервер с корпоративной веб-страницей, то межсетевой экран может быть настроен так:
Начальная настройка iptables
outif="eth1"
iptables -F
iptables -i $outif -A INPUT \
-m conntrack \
--ctstate ESTABLISHED,RELATED \
-j ACCEPT
iptables -i $outif -A INPUT -p tcp \
--dport 80 -j ACCEPT
iptables -i $outif -P INPUT DROP
iptables -i $outif -P OUTPUT ACCEPT
Начальная настройка ipfw
outif="rl0"
ipfw add allow ip from any to any \
via lo0
ipfw add allow ip from me to any \
via $outif
ipfw add allow tcp from any to me \
established via $outif
ipfw add allow tcp from any 80 \
to me via $outif
ipfw add deny ip from any to any \
via $outif
Начальная настройка pf
outif="rl0"
set skip on lo0
block all
pass out on $outif from $outif \
to any keep state
pass in on $outif proto from any \
to $outif port 80
Все три набора правил делают одно и то же - разрешают прохождение любого трафика по интерфейсу обратной петли (loopback), разрешают принимать пакеты уже установленных соединений (чтобы, например, браузер мог получить ответ на запрос к удаленному серверу), разрешают обращения на 80-й порт, блокируя все остальные, и разрешают любые коннекты наружу. Обрати внимание, что если в примерах iptables и ipfw мы явно задали правила для разрешения приема пакетов уже установленных соединений (established), то в случае с pf для этого достаточно было указать «keep state» в рулесете, разрешающем любые исходящие соединения.
В общем-то, такая схема защиты сетевых сервисов от сканирования и проникновения отлично работает, но мы можем пойти дальше и настроить файер так, чтобы некоторые виды сканирования вообще не могли бы быть выполнены. Технически мы не можем сделать это в отношении обычного сканирования (флаги nmap "-sT", "-sS" и "-sU") просто потому, что в нем нет ничего криминального, однако нестандартные типы сканирования, такие как "-sN", "-sF" и "-sX", порождают пакеты, которые никак не могли быть созданы легальными приложениями.
Поэтому без тени сомнения отбрасываем подобные соединения.
Методы борьбы с экзотическими видами сканирования
# Запрет FIN-сканирования
Linux> iptables -A INPUT –p tcp \
–m tcp \
–-tcp-flags FIN,ACK FIN -j DROP
FreeBSD>
not established tcpflags fin
# Запрет X-сканирования
Linux>
--tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,PSH,ACK,URG \
–j DROP
FreeBSD> ipfw add reject tcp from any to any \
tcpflags fin, syn, rst, psh, ack, urg
# Запрет N-сканирования
Linux> iptables -A INPUT –p tcp –m tcp \
–-tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE –j DROP
FreeBSD> ipfw add reject tcp from any to any \
tcpflags !fin, !syn, !rst, !psh, !ack, !urg
В OpenBSD все эти строки можно заменить простой записью в начале
/etc/pf.conf:
scrub in all
Директива scrub активирует механизм нормализации пакетов, при котором фрагментированные пакеты воссоединяются, а пакеты с недопустимой комбинацией флагов отбрасываются. Кроме экзотических видов сканирования scrub позволяет защититься и от обмана систем обнаружения вторжений (посылка сильно фрагментированных пакетов) и некоторых видов DoS-атак.
Для защиты от SYN/ACK-сканирования, инициируемого с помощью nmap-флага "-sS", мы можем использовать метод пассивного определения ОС (OS Fingerprint), доступный в брандмауэрах pf и iptables/netfilter (начиная с версии 1.4.6). Во время проведения обычного сканирования (флаг "-sT") nmap использует стандартный интерфейс сокетов операционной системы, поэтому такой скан почти ничем не отличается от потока обычных пакетов (ниже мы рассмотрим некоторые его отличия), однако при SYN/ACK-сканировании nmap формирует пакеты самостоятельно, поэтому они имеют некоторые черты, которые выдают их источник. Метод пассивного определения ОС позволяет идентифицировать эти пакеты и отбросить их с помощью стандартных правил файервола:
OpenBSD> block in quick from any os NMAP
Linux> iptables -I INPUT -p tcp -m osf --genre NMAP \
-j DROP
Модуль osf брандмауэра iptables/netfilter использует базу «отпечатков», собранную и обновляемую разработчиками OpenBSD (/etc/pf.os), поэтому оба этих правила должны привести к одинаковым результатам. Интересно так же и то, что они позволяют эффективно противодействовать функции определения ОС утилиты nmap (флаг "-O").
Теперь мы защищены почти от всех видов сканирования, кроме стандартного и тупого "-sT". Как быть с ним? На самом деле все просто. Факт сканирования портов легко заметить, просто проанализировав логи файервола. Если за короткий промежуток времени происходило множество коннектов на различные порты - значит, нас сканировали. Осталось только переложить эту идею на правила брандмауэра. Для iptables есть отличный рецепт, который блокирует всех, кто слишком настойчиво стучится в нерабочие порты:
Борьба со сканированием с помощью iptables
# Проверка на стук в нерабочие порты (10 в час)
--seconds 3600 --hitcount 10 --rttl -j RETURN
# Вторая проверка на стук в нерабочие порты (2 в минуту)
iptables -A INPUT -m recent --rcheck \
--seconds 60 --hitcount 2 --rttl -j RETURN
# Заносим адреса стучащихся в список
iptables -A INPUT -m recent --set
# Отбрасываем пакеты всех, кто превысил лимит на
количество подключений
iptables -P INPUT -j DROP
Установив пакет xtables-addons, содержащий наработки проекта patch-omatic, мы получим доступ к модулю PSD (Port Scan Detect), реализованному по образу и подобию демона scanlogd. Все предыдущие строки могут быть легко заменены простым правилом:
# iptables -A INPUT -m psd -j DROP
К сожалению, в пакетных фильтрах ipfw и pf ничего подобного нет, но это не беда, потому как сканированию портов хорошо противодействует демон PortSentry и тот самый scanlogd.
Запрет Icmp-сообщений
Хорошей практикой также является запрет ICMP-сообщений, которые могут выдать дополнительную информацию о хосте или быть использованы для выполнения различных злонамеренных действий (например, модификации таблицы маршрутизации). Ниже приведена таблица со списком возможных типов ICMP-сообщений:
Типы ICMP-сообщений
- 0 - echo reply (echo-ответ, пинг)
- 3 - destination unreachable (адресат недосягаем)
- 4 - source quench (подавление источника, просьба посылать пакеты медленнее)
- 5 - redirect (редирект)
- 8 - echo request (echo-запрос, пинг)
- 9 - router advertisement (объявление маршрутизатора)
- 10 - router solicitation (ходатайство маршрутизатора)
- 11 - time-to-live exceeded (истечение срока жизни пакета)
- 12 - IP header bad (неправильный IPзаголовок пакета)
- 13 - timestamp request (запрос значения счетчика времени)
- 14 - timestamp reply (ответ на запрос значения счетчика времени)
- 15 - information request (запрос информации)
- 16 - information reply (ответ на запрос информации)
- 17 - address mask request (запрос маски сети)
- 18 - address mask reply (ответ на запрос маски сети)
Как видишь, ответ на некоторые ICMP-сообщения может привести к разглашению некоторой информации о хосте, в то время как другие - привести к модификации таблицы маршрутизации, поэтому их необходимо запретить.
Обычно выход во внешний мир разрешают ICMP-сообщениям 0, 3, 4, 11 и 12, в то время как на вход принимают только 3, 8 и 12. Вот как это реализуется в различных брандмауэрах:
Запрет опасных ICMP-сообщений
Linux> iptables -A INPUT -p icmp \
-icmp-type 3,8,12 -j ACCEPT
Linux> iptables -A OUTPUT -p icmp \
-icmp-type 0,3,4,11,12 -j ACCEPT
FreeBSD> ipfw add allow icmp \
from any to $outif in \
via $outif icmptype 3,8,12
FreeBSD> ipfw add allow icmp \
from $outif to any out \
via $outif icmptype 0,3,4,11,12
OpenBSD> pass in inet proto icmp \
from any to $outif \
icmp-type { 3, 8, 12 } keep state
OpenBSD> pass out inet proto icmp \
from $outif to any \
icmp-type { 0, 3, 4, 11, 12 } \
keep state
При желании ты можешь запретить весь ICMPтрафик, включая пинг-запросы, но это может повлиять на корректность работы сети.
Брутфорс
Разведав информацию об открытых портах и ОС, взломщик предпринимает попытки проникновения в систему, которые могут быть основаны на эксплуатации дыр в сервисах, либо на подборе паролей. Предотвратить возможность взлома сервисов брандмауэр нам не поможет, однако затормозить процесс перебора паролей - легко. Для этого применяются возможности по ограничению количества пакетов, пришедших на машину с одного IP-адреса. Вот как это можно сделать с помощью iptables:
Защита от брутфорса с помощью iptables
# Цепочка для проверки соединений
iptables -N brute_check
# Блокировка адреса, если за 60
секунд он инициировал более 2-х соединений
--update --seconds 60 \
--hitcount 3 -j DROP
# Если нет - разрешаем соединение и
заносим адрес в список
iptables -A brute_check -m recent \
--set -j ACCEPT
# Очищаем цепочку INPUT
iptables -F INPUT
# Отправляем в цепочку brute_check
всех, кто пытается подключиться к
22-му порту
--ctstate NEW -p tcp \
--dport 22 -j brute_check
iptables -P INPUT DROP
То же самое можно проделать и с использованием pf:
Защита от брутфорса с помощью pf
# Создаем таблицу для брутфорсеров
table
# Блокируем всех, кто в нее попадает
block in quick from
# Помещаем в таблицу bruteforcers всех, кто инициирует более двух соединений на 22-ой порт в минуту
pass in on $ext_if inet proto tcp to $outif \
port 22 flags S/SA keep state \
(max-src-conn-rate 60/2, \ overload
Брандмауэр ipfw не обладает достаточной функциональностью для эффективного противодействия брутфорсерам, поэтому его пользователи должны использовать инструменты более высокого уровня, такие как специальные модули PAM, системы обнаружения вторжений и программы вроде sshguard.
Спуфинг
Спуфинг (подмена адреса отправителя пакета) может быть использован для осуществления DoS-атак или обхода брандмауэра. В первом случае спуфинг дает огромное преимущество атакующему, так как существенно затрудняет реакцию на атаку (пакеты, приходящие с совершенно разными адресами отправителя, не так просто классифицировать и заблокировать) и затягивает процесс закрытия новых соединений (обычно поддельный адрес недостижим, поэтому закрытие соединения происходит лишь по истечению таймаута). Спуфинг, осуществляемый для обхода системы защиты, менее опасен и в большинстве случаев поддается контролю.
Достаточно часто, блокируя внешние сетевые сервисы хоста, системные администраторы оставляют их открытыми для определенного диапазона адресов (например, для подключения со своей домашней машины). Вычислив один из этих адресов, взломщик может сформировать пакет, указав этот адрес в качестве обратного, и таким образом «проскользнуть » через брандмауэр. Далее он может угадать номера последовательности TCP-пакетов и сделать так, чтобы доверяющий обратному адресу сервис выполнил нужное ему действие. Это очень трудная в реализации атака, которая, тем не менее, может быть выполнена грамотным специалистом, а если речь идет о протоколе UDP, то это под силу и кулхацкеру.
К счастью, защититься от подобных атак легко. Достаточно не открывать порты незащищенных сервисов во внешний мир, а в случае резкой необходимости использовать защитные системы самих сервисов (например, сертификаты ssh) или механизм «стука в порты» (о нем рассказано в конце статьи).
Ситуация становится более сложной, когда дело касается сетевого моста, разделяющего внутреннюю и внешнюю сети (или две локальных сети). Доверительные отношения внутри локальной сети - обычное дело. Сервисы доступны всем, никакой аутентификации, шифрования и т.д. - просто лакомый кусочек для взломщика. Находясь во внешней сети, он может узнать сетевую маску внутренней сети и сформировать пакеты с соответствующим ей обратным адресом, что приведет к получению доступа ко всем ресурсам локалки. Это действительно опасная ситуация, но ее легко предотвратить с помощью правильной настройки брандмауэра или ОС.
Для этого достаточно запретить прохождение пакетов, обратные адреса которых соответствуют используемым во внутренней сети, с внешнего интерфейса:
Linux> iptables -A INPUT -i $outif \
-s 192.168.1.0/24 -j DENY
FreeBSD> ipfw add deny ip from \
192.168.1.0/24 to any via $outif
OpenBSD> block in on $outif from \
192.168.1.0/24 to any
В качестве альтернативы или дополнительной меры защиты можно (и даже нужно) использовать специальные директивы ipfw и pf и настройки ядра Linux:
Linux> echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
FreeBSD> ipfw add deny ip from any to any not antispoof in
OpenBSD> antispoof quick for $ext_if
Эти три команды приводят к одинаковым результатам. Все пакеты, обратные адреса которых соответствуют маске сети другого интерфейса, отбрасываются.
Полезности IPTABLES
В конце статьи мы рассмотрим несколько интересных возможностей iptables/netfilter, которые могут оказаться полезными при защите сервера от проникновений. Начнем с механизма удаленного управления брандмауэром, получившего имя «стук в порты» (port knoking). Суть его заключается в том, чтобы заставить файервол выполнять определенные действия после подключения к заданному порту. Ниже приведен пример правил, открывающих порт SSH на 10 секунд после «стука» в 27520-ый порт:
iptables и port knocking
# Цепочка для проверки соединений на защищаемый порт
iptables -N knock
# Разрешаем соединение, если стук был в течение последних
10 секунд
iptables -A knock -m recent --rcheck --seconds 10 \
-j ACCEPT
# Очищаем INPUT
iptables -F INPUT
# Разрешаем все, что относится к уже установленным соединениям
iptables -A INPUT -m conntrack \
--ctstate ESTABLISHED,RELATED -j ACCEPT
# Все попытки открыть соединение с 22-м портом отправляем
на проверку в цепочку knock
-p tcp --dport 22 -j knock
# Заносим адрес стучащегося в 27520-й порт в список
iptables -A INPUT -m conntrack --ctstate NEW \
-p tcp --dport 27520 -m recent --set
# При стуке в соседние порты удаляем адрес из списка
iptables -A INPUT -m conntrack --ctstate NEW -p tcp \
-m multiport --dport 27519,27521 -m recent --remove
# Запрещаем все
iptables -P INPUT DROP
Третье с конца правило добавляет адрес стучащегося в список. Если та же машина в течение 10 секунд после стука обратится к 22-му порту, соединение будет установлено. Предпоследнее правило - защита от «перебора стука». Если злоумышленник попытается стучать последовательно во все порты с надеждой, что один из них откроет 22-й порт, сработает это правило, и его адрес будет удален из списка сразу после попадания в него.
Вторая полезность iptables распространяется в пакете xtables-addons (patch-o-matic) и носит имя TARPIT. Это действие (такое же, как ACCEPT или DENY), которое «подвешивает» соединение, не позволяя атакующей стороне его закрыть. Соединение, пакеты которого попадают в TARPIT, будет благополучно установлено, однако размер окна будет равен нулю, благодаря чему удаленная машина не сможет отправлять данные, расходуя свои ресурсы, а соединение будет закрыто только по истечению таймаута. TARPIT можно использовать в экстренных случаях для защиты от DoS:
# iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT
Или же для введения атакующего в заблуждение и борьбы против сканеров
портов (только обычное TCP-сканирование, "-sT"):
# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
# iptables -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
# iptables -A INPUT -p tcp -m tcp -j TARPIT
Эти правила создают видимость системы, в которой открыты все порты, однако при попытке подключения к любому из них (кроме 80 и 25) соединения будут «подвисать». Того же результата, но без «провисших» соединений, можно добиться с помощью действия DELUDE, которое правильно отвечает на все попытки инициации соединения, но посылает RST-пакет в ответ на все остальные пакеты. Для еще большего запутывания атакующего ты можешь использовать действие CHAOS, которое случайным образом активирует одно из двух описанных выше действий.
Выводы
Обладая достаточным количеством знаний и вдумчиво читая документацию, ты можешь создать очень крепкий бастион, к которому будет не такто просто подобраться. Современные брандмауэры, а в особенности pf и iptables, предлагают множество средств защиты от непрошенных гостей, которые ты можешь получить абсолютно безвозмездно.
Links
- sf.net/projects/sentrytools - PortSentry
- www.openwall.com/scanlogd - scanlogd
Борьба с утечкой ресурсов
При использовании действия TARPIT обязательно добавляй в конфиг следующее правило, иначе «провисшие» соединения будут съедать ресурсы при обработке подсистемой conntrack:
# iptables -t raw -I PREROUTING -p tcp --dport 25 -j NOTRACK
Итак, продолжаем разбираться с ACL. На сей раз, у нас расширенные ACL. Топологию возьмём от предыдущей статьи, надеюсь, вы её изучили досконально. Если это не так, то очень рекомендую прочесть, чтобы материалы этой статьи были более понятными.
Прежде всего начну с того, что такое расширенные ACL. Расширенные ACL позволяют помимо адреса источника указать протокол, адрес назначения и порты. А так же особые параметры определённого протокола. Лучше всего учиться на примерах, поэтому сформируем новую задачу, усложнив предыдущую. Кстати, кому-то может интересно будет после этого заняться вопросами распределения трафика по приоритетам, советую вот QoS Classification and Marking хорошую статью, правда на английском. Ну а пока, вернемся к нашей задаче:
Задача.
- Разрешить echo-запросы с узлов сети 192.168.0.0/24 на сервер.
- С сервера – запретить echo-запросы во внутреннюю сеть.
- Разрешить WEB-доступ на сервер с узла 192.168.0.11.
- Разрешить FTP доступ с узла 192.168.0.13 на сервер.
Комплексная задача. Решать её будем тоже комплексно. Прежде всего разберу синтаксис применения расширенного ACL.
Параметры расширенного ACL
<номер от 100 до 199> <действие permit, deny> <протокол> <источник> <порт> <назначение> <порт> <опции>
Номера портов указываются только у протоколов TCP / UDP, разумеется. Так же могу иметь место приставочки eq (номер порта равный указанному), gt / lt (номер порта больше/меньше указанного), neq (номер порта не равен указанному), range (диапазон портов).
Именованные ACL
Кстати, списки доступа можно не только нумеровать, но и именовать! Возможно этот способ покажется вам более удобным. В этот раз сделаем именно так. Эти команды выполняются в контексте глобального конфигурирования и синтаксис выглядит так:
Router(config)#ip access-list extended <имя>
Итак, начинаем формировать правила.
- Разрешаем пинги с сети 192.168.0.0/24
на сервер. Итак, echo
-запросы – это протокол ICMP
, в качестве адреса источника выберем нашу подсеть, адресом назначения – адрес сервера, тип сообщения – на входящем интерфейсе echo
, на выходе – echo-reply
. Router(config)#ip access-list extended INT_IN Router(config-ext-nacl)#permit icmp 192.168.0.0 0.0.0.255 host 10.0.0.100 echoОпаньки, а что это у нас с маской подсети? Да, это фишка ACL
. Так называемая WildCard
-маска. Вычисляется как обратная маска от привычной. Т.е. 255.255.255.255
– маска подсети. В нашем случае подсеть 255.255.255.0
, после вычитания остаётся как раз 0.0.0.255
.Думаю, это правило в пояснении не нуждается? Протокол icmp
, адрес источника – подсеть 192.168.0.0/24
, адрес назначения – host 10.0.0.100
, тип сообщения – echo
(запрос). Кстати, нетрудно заметить, что host 10.0.0.100
эквивалентно 10.0.0.100 0.0.0.0
.Применяем это правило на интерфейс. Router(config)#int fa0/0
Router(config-if)#ip access-group INT_IN in Ну как-то так. Теперь, если проверить пинги – легко заметить, что всё отлично работает. Тут, правда нас ждёт один сюрприз, который всплывёт чуть позже. Пока не буду раскрывать. Кто догадался – молодец! - С сервера – запрещаем все echo-запросы во внутреннюю сеть (192.168.0.0/24). Определяем новый именованный список, INT_OUT и вешаем его на интерфейс, ближайший к серверу.
Router(config)#ip access-list extended INT_OUT
Router(config-ext-nacl)#deny icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo
Router(config-ext-nacl)#exit
Router(config)#int fa0/1
Router(config-if)#ip access-group INT_OUT in
Поясняю, что мы сделали. Создали расширенный список доступа с именем INT_OUT, в нём запретили протокол icmp с типом echo с хоста 10.0.0.100 на подсеть 192.168.0.0/24 и применили на вход интерфейса fa0/1 , т.е. ближайший к серверу. Пробуем послать ping с сервера.
SERVER>ping 192.168.0.11
Pinging 192.168.0.11 with 32 bytes of data:
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.
Reply from 10.0.0.1: Destination host unreachable.
Ping statistics for 192.168.0.11:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
Ну, вроде сработало как надо. Для тех, кто не знает, как посылать пинги – кликаем на интересующем нас узле, например сервере. Переходим на вкладку Desktop (Рабочий стол), там Command Prompt (Командная строка).А теперь, обещанный прикол. Попробуйте послать ping с хоста, как в первом пункте. PC>ping 10.0.0.100
Pinging 10.0.0.100 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.Вот тебе раз. Только что же всё работало! Почему перестало? Это обещанный сюрприз. Объясняю, в чём проблема. Да, первое правило никуда не делось. Оно действительно разрешает отправку echo запроса на узел сервера. Но где разрешение на прохождение echo-ответов? Его нет! Запрос посылаем, а ответ принять не можем! Почему же всё работало раньше? Тогда у нас не было ACL на интерфейсе fa0/1 . А раз нет ACL, то всё разрешено. Придётся создавать правило на разрешение приёма icmp-ответов.
В список INT_OUT добавим
То же добавим и в список INT_IN.
Router(config-ext-nacl)#permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply
Вот теперь не придраться. Всё проходит великолепно!
- Разрешаем WEB-доступ на сервер с узла *.11.Поступаем аналогично! Тут, правда, нужно немного знать, как происходят обращения по протоколам 4-го уровня (TCP, UDP). Клиентский порт выбирается произвольным > 1024, а серверный – соответствующий службе. Для WEB – это 80 порт (протокол http).А что по поводу WEB-сервера? По умолчанию, на сервере уже установлена WEB-служба, можно посмотреть в настройках узла. Обратите внимание, чтобы стояла галочка. А подключиться к серверу можно выбрав ярлык “Веб браузер” на “Рабочем столе” любого узла. Конечно же сейчас доступа не будет. Поскольку у нас на интерфейсах маршрутизатора висят ACL-ы, и в них нет разрешающих правил для доступа. Чтож, давайте создадим.В список доступа INT_IN (который на интерфейсе fa0/0
) добавим правило: Router(config-ext-nacl)#permit tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq 80 То есть мы разрешаем протокол TCP с нашего узла (порт произвольный, > 1024) на адрес сервера, порт HTTP.
И, разумеется, обратное правило, в список INT_OUT (который на интерфейсе fa0/1 ):
Router(config-ext-nacl)#permit tcp host 10.0.0.100 eq 80 host 192.168.0.11 established
То есть разрешаем TCP с порта 80 сервера на хост *.11 , и соединение уже должно быть установлено! Можно вместо established указать так же gt 1024 , работать будет так же хорошо. Но смысл немного иной.
В комментах ответьте, что будет более безопасным?
- Разрешаем FTP-доступ с узла *.13 на сервер.Тоже абсолютно ничего сложного!Разбираем, как происходит взаимодействие по протоколу FTP. В будущем, я планирую посвятить целый цикл статей работе разных протоколов, поскольку это очень полезно при создании точных (снайперских) правил ACL. Ну а пока:Действия сервера и клиента:
+ Клиент пытается установить связь и посылает пакет (в котором находится указание, что будет вестись работа в пассивном режиме) на 21 порт сервера со своего порта X (X > 1024, свободный порт)+ Сервер посылает ответ и сообщает номер своего порта для образования канала данных Y (Y > 1024) на порт клиента X, извлечённого из заголовка TCP-пакета.+ Клиент инициирует связь для передачи данных по порту X+1 на порт сервера Y (взятого из заголовка предыдущей транзакции). Как-то так. Немного сложно звучит, но нужно только разобраться!В список INT_IN добавляем правила:
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 eq 21
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 gt 1024А в список INT_OUT добавляем правила:
permit tcp host 10.0.0.100 eq ftp host 192.168.0.13 gt 1024
permit tcp host 10.0.0.100 gt 1024 host 192.168.0.13 gt 1024Проверяем из командной строки, командой ftp 10.0.0.100 , где авторизуемся по учётным данным cisco:cisco (взято из настроек сервера), там вводим команду dir и увидим, что данные как и команды – передаются успешно.
Вот примерно и всё, что касается расширенных список доступа.
Итак, посмотрим наши правила:
Router#sh access
Extended IP access list INT_IN
permit icmp 192.168.0.0 0.0.0.255 host 10.0.0.100 echo (17 match(es))
permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply
permit tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq www (36 match(es))
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 eq ftp (40 match(es))
permit tcp host 192.168.0.13 gt 1024 host 10.0.0.100 gt 1024 (4 match(es))
Extended IP access list INT_OUT
deny icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo (4 match(es))
permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply (4 match(es))
permit tcp host 10.0.0.100 eq www host 192.168.0.11 established (3 match(es))
permit tcp host 10.0.0.100 eq ftp host 192.168.0.13 gt 1024 (16 match(es))
permit tcp host 10.0.0.100 gt 1024 host 192.168.0.13 gt 1024 (3 match(es))
Рекомендуем также
Виды смайликов и их значение
Настройка подключения в Putty и WinSCP Winscp перенос настроек
Be-on-Road – бесплатный оффлайн GPS навигатор Карты для be on road 3
Как самому изменить имя в ВК: подробная инструкция для смены
Steam client not found — что делать и как исправить сбой Что за ошибка steam client not found
Acrobat reader редактирование pdf