С чего бы начать?.. RAW по сути своей сильно урезан по функционалу, из-за того что он идёт до Conntrack и теряет много полезных ништяков, но это не критично.
Как уже было сказано выше, Raw — обрабатывает пакеты до их попадания в Connection Tracking (Далее - Conntrack) и по сравнению с Filter Rules, Raw обработка или удаление быстрее примерно также, как и FastTrack, а это разгрузка CPU ~ в 6 раз.
Небольшое предисловие
Я не претендую на 100% достоверность, по той простой причине, что не являюсь сертифицированным специалистом Mikrotik. И не имею никаких сертификатов, дипломов. Я лишь монтажник сетей, и пишу сюда свой опыт с этими устройствами.
Для примера я взял довольно распространённую модель RB941-2ND со 100мбит-ными портами для наглядности, версия RouterOS - 6.47.9 | 32Мб RAM и 650МГц CPU SMIPS.
(Возможно это звучит как издевательство, но я действительно DDoS-ил эту конфигурацию, и оно спокойно молотило все 100Мбит нагружаясь лишь на 25%, когда при стандартных правилах Filter уходило в 100% при 60 мбит).
В чем проблема стандартных (QuickSet) правил Filter?
При стандартных параметрах маршрутизатора, мы видим что пакеты приходящие через интерфейс WAN проходят до цепочки Input. То есть маршрутизатор их обрабатывает полноценно через Routing Decision, заносит их в Conntrack с соответствующими данными, и в конце этот пакет либо встречает свою погибель в лице стандартного правила Drop, либо пройдет как новое подключение с локальным процессом, если порт роутера открыт. Либо в уйдет в Forward цепочку, если настроен проброс портов через сетевую трансляцию адресов, но это уже скорее исключение.
Посмотрите на схему цепочек RouterOS:
Она довольно упрощена, но.. Видите? Пакет проходит до цепочки Input, и также проходит через Conntrack, Mangle, NAT и Routing Decision и только потом в Filter. Это абсолютно бесполезная трата ресурсов процессора и оперативной памяти маршрутизатора. Таким образом, при довольно больших объемах бесполезного трафика, CPU уйдет в 100% или Conntrack переполнится новыми подключениями рано или поздно. Всё потому что у нашего подопытного - аппаратное обеспечение оставляет желать лучшего. (Хотя это довольно спорный момент, некоторые гигабитные маршрутизаторы уходили гулять в 100% при 200мбит трафика, что является абсурдом).
Задача:
Разгрузить маршрутизатор для работы хотя бы с локальной сетью, если из внешней сети гадят большим количеством пустого трафика. Закрыть полностью все порты управления RouterOS для WAN одним правилом и попытаться если не полностью предотвратить, то хотя бы ослабить переполнение Conntrack.
Условия:
Маршрутизатор полностью настроен через QuickSet в качестве домашней точки доступа, что может вам показаться кощунством (Простите мне просто было лень пилить всё вручную по статьям из интернета). Включен IPv4 FastTrack и прочие службы управления RouterOS. Всё эти службы видны и в локальной сети, и в интернете по IP.
Сценарий пользования: Домашний/Офисный, с динамическим/статическим адресом; По большому счету, это роли не играет, потребуется чуть-чуть поменять правила для каждого случая, но их объединяет одно - открытый доступ извне. Я конечно же предоставлю оба варианта в графическом, и в текстовом для терминала формате.
Что потребуется?
Нам потребуется Winbox или терминал SSH - выбирайте по вкусу. Знания как работает NAT, прямые руки и подключение к RouterOS, очень желательно из локальной сети, поскольку соблюсти истину "Удаленной настройки Firewall - это к дальнему выезду" ни мне, ни вам не охота, верно?
Как реализовать и куда тыкать?
Потребуется создать 3 правила NAT для TCP, UDP и ICMP подключений локальной сети, чтобы исходящий трафик машин из LAN менял свои SRC порты на наш диапазон, который мы укажем. Рекомендуется выбирать диапазон и количество портов исходя из количества клиентов, и того, сколько подключений делается в самое пиковое время, (не обязательно, но желательно). Можно взять за пример ~2 тысячи подключений с одного устройства к примеру. Предположим что в сети около 4 устройств, итого 8 тысячи портов требуется зарезервировать под нашу затею. Также необходимо учесть, что этот диапазон должен быть нестандартным, чтобы боты-сканеры не смогли определить тип операционной системы по IP, и не попали в открытые порты маршрутизатора, и чтобы NAT правила не накладывались на опубликованные порты типа 1-8000. Правильнее было бы указать допустим - 42000-50000, поскольку он изначально зарезервирован.
Недостаток такого метода: Если клиентов к роутеру подключено слишком много, то в таком случае, реализовать эту систему правил необходимо без NAT. Но должны быть заблокированы все порты служб маршрутизатора из WAN, что не является нашей задачей.
Достоинство этого метода:
> Гибкость, вы можете спокойно открывать какие-либо порты и ставить сервер, но придется допиливать RAW ограничение, чтобы не было проблем с переполнением Conntrack в NAT при DDoS.
> Маскировка цепочки Input. Она будет доступна только на определенном диапазоне портов, плюс изначально экранирована нормально закрытым Firewall. Это значит, что если бить DOS-ом по порту, на котором не висят NAT правила - максимальная разгрузка CPU в RAW при удалении пакетов.
Разумеется, от меня существует две версии. При динамическом адресе, и при статическом.
Сначала рассмотрим правила NAT при динамическом адресе.
Диапазон 12000-18000 указан как пример собственной конфигурации;
Правила в текстовом режиме для терминала:/ip firewall nat
add action=masquerade chain=srcnat comment="SRC RAW NAT TCP" out-interface-list=WAN protocol=tcp to-ports=42000-50000
add action=masquerade chain=srcnat comment="SRC RAW NAT UDP"
out-interface-list=WAN protocol=udp to-ports=42000-50000
add action=masquerade chain=srcnat comment="SRC RAW NAT ICMP"
out-interface-list=WAN protocol=icmp
Как вы можете заметить, используется Masquerade. Это сделано для совместимости с динамической выдачей адресов от провайдера (DHCP) и как более совместимый/универсальный вариант. Однако, он же является менее безопасным, поскольку в сеть провайдера могут улететь ваши локальные IP адреса при внезапном разрыве, но беспокоиться не о чем. Это явление крайне редкое.
Если у вас статический IP адрес, есть другой вариант. Он чуть безопаснее, и надежнее, поскольку при внезапном разрыве локальные адреса не улетят в публичную сеть и немного разгрузится маршрутизатор.
Правила в текстовом режиме для терминала:/ip firewall nat add action=src-nat chain=srcnat comment="SRC NAT TCP RAW" Не забудьте отредактировать "INSERTYOURIP", впишите туда свой статический адрес, чтобы правило начало работать :)
out-interface-list=WAN protocol=tcp to-addresses=INSERTYOURIP to-ports=
42000-50000
add action=src-nat chain=srcnat comment="SRC NAT UDP RAW"
out-interface-list=WAN protocol=udp to-addresses=INSERTYOURIP to-ports=
42000-50000
add action=src-nat chain=srcnat comment="SRC NAT ICMP RAW"
out-interface-list=WAN protocol=icmp to-addresses=INSERTYOURIP
Firewall RAW, великий и ужасный
Здесь нам необходимо почесать репу, сделать 5 базовых правил RAW. Оперируем мы всегда цепочкой Prerouting, и никогда Output. Это сделано для того, чтобы работали исходящие подключения от системы роутера к службам обновлений, внешним DNS.
Первое фундаментальное правило - блокировать фрагментированные пакеты со всех интерфейсов Ethernet. Такие пакеты, если приходят из интернета - ничего хорошего обычно не сулят и очень сильно нагружают как оконечные устройства нашей сети, так и сам маршрутизатор. (Ведь фрагментированный пакет надо собрать, чтобы его принять). Обзываем правило хоть как. Я из глупости назвал оный Security Rule.
Пример правила в терминале:
/ip firewall raw add action=drop chain=prerouting comment= "Security Rule: Block IP Fragment" fragment=yes
2 по 4 правило - Принимать пакеты на указанные в NAT порты, но в зависимости от скорости сети указывать ограничение количества пакетов в секунду. (Каждый 1 мбит = 2 пакета. Если сеть высоконагруженная, или есть проблемы с доступом - 1Мбит = 4 пакета). Во всех правилах далее - указываем интерфейс WAN.
Текстовый формат правила:/ip firewall raw
add action=accept chain=prerouting comment="Src NAT TCP" dst-port=12000-18000 in-interface-list=WAN limit=200,200:packet protocol=tcp
add action=accept chain=prerouting comment="Src NAT UDP" dst-port=12000-18000 in-interface-list=WAN limit=200,200:packet protocol=udp
add action=accept chain=prerouting comment="Src NAT: RAW ICMP" limit=
10,10:packet protocol=icmp
Опытным путем было установлено, что ограничения в 200 входящих пакетов в секунду для TCP/UDP протоколов по линии 100Мбит - достаточно при включенном FastTrack, поскольку при помощи этой технологии организуется беспрепятственное прохождение соединения. Каждый пакет с установленным соединением обрабатывается нулевым правилом FastTrack, и редко, единично для каждого соединения может зайти в RAW. Если такое происходит - Routing Decision и Conntrack сам решает куда отнести этот пакет, в Forward (Это Related и Established подключения) или в Input (Удаление пакета, или доступ к RouterOS) цепочки. Напоминаю, что порты на скриншота 12000-18000 указаны из примера собственной конфигурации.
ICMP принимаем как есть, ограничение ставим на 10 пакетов в секунду по стандарту.
Пятое правило - блокировать всё, что явно не разрешено с интерфейса WAN.
Достоинства данной системы правил:
Высокая производительность Drop-а пустого трафика. (Да, она может спасти от DDoS с IP Spoofing-ом, если службы ваших LAN-машин экранированы через NAT и ограничены в RAW, поскольку учтены таймеры соединений Conntrack внешних служб для защиты последнего).
Гибкость, вы спокойно можете опубликовать ваши службы.
Вы можете сделать подобие Conntrack через Address List и Mangle, если потребуется обслуживать клиентов вашей службы в первую очередь, и устроить мониторинг IP подключенных клиентов к вашим службам для диагностики.
Она не влияет на LAN подключения, поскольку все правила проработаны только для WAN.
Полностью закрывает все порты маршрутизатора извне, при верном выборе диапазона SRC портов. Это происходит поскольку пакеты не доходят до Input цепочки без соответствующего разрешающего правила, а даже если и доходят, то отлавливаются стандартным правилом Drop all from WAN. Либо принимаются, исходя из вашей конфигурации.
Таким образом мы исключаем атаки на DNS порт, порт SSH, порты FTP, Bandwitch Server, а также атаки на Winbox-порты одним правилом.
Также комплекс правил не исключает и не мешает технике ICMP Port Knocking для доступа извне.Есть возможность прикрутить систему, которая обнаруживает IP сканеры, хецкеров и удалять такие пакеты не в Input цепочке, а в Prerounting, выполняя тем самым разгрузку CPU.
Недостатки:
Ограничение количества пользовательских портов.
Возможно не совместим с VPN. (Поправьте, если это не так).
Требуется более детальная настройка портов, которые смотрят наружу. Требуется добавлять в Raw дополнительные правила с ограничениями.
