Примеры использования RAW-фильтрации в брандмауэре?

Привет. У меня проблема с RAW-правилом. В MikroTik я пробросил порт 5060 по протоколу UDP и добавил правило в RAW, чтобы сбрасывать все соединения на этом порту с черного списка. Но это правило не работает, и пользователи пытаются подключаться через этот порт к моей PhoneStation. Что я делаю не так?

@Koman: ты уверен, что действительно нужно ставить in-interface-list? Достаточно просто использовать src-address-list=blacklist.

Спасибо, MKX. Итак, вот что я предлагаю…  
Тактика 1: Отбрасывать всё в raw prerouting для портов, которые, как известно, не используются ни для исходящего, ни для входящего трафика от роутера или пользователей за роутером, или для сервисов за роутером (in-interface WAN). Это снизит нагрузку на процессор по сравнению с фильтрацией на уровне фильтра. (например, 21, 23, 8291 и т.д.)  

Тактика 2: Оставить всё в raw, но при этом просто заносить исходный адрес для стандартных портов, которые хакеры обычно пытаются сканировать (in-interface=wan) (21, 22, 23, 53 и так далее). Создать список. Всё ещё в raw, затем блокировать все с исходных адресов из этого списка на 5 дней или около того.  

Какой риск или минус такого подхода… Мне нравится твоя логика, которая подходит для Тактики 2 — злодеи будут проверять не только стандартные порты, но может быть и гораздо больше, и разные группы. А этот метод блокирует все их попытки.  

Вот стартовый список портов, которые я не использую, и которые могут эффективно помочь выявлять плохих парней и банить их на 5 дней:  
0, 11, 20, 21, 22, 23, 79, 113, 119, 135, 139, 194, 389, 445, 500, 1002, 1025, 1026, 1027, 1028, 1029, 1030, 1720, 5000  

Я не ожидаю нежелательного входящего трафика на портах 25, 53, 80, 110, 143 или 443, но, наверное, для них стоит делать правила в firewall filter, чтобы не блокировать легитимный ответный трафик во входящий WAN.  

Согласен? Тогда будет выглядеть примерно так (прямо перед последним правилом drop all input):  

/ip firewall filter  
add action=add-src-to-address-list address-list=DropPortProbes address-list-timeout=5d chain=input comment=CaptureInputProbes_tcp disabled=yes dst-port=25,53,80,443 in-interface-list=WAN protocol=tcp  
add action=add-src-to-address-list address-list=DropPortProbes address-list-timeout=5d chain=input comment=CaptureInputProbes_udp disabled=yes dst-port=25,53,80,443 in-interface-list=WAN protocol=udp  

/ip firewall raw (PREROUTING)  
add action=add-src-to-address-list address-list=DropPortProbes address-list-timeout=5d chain=prerouting comment=CaptureUnusedPorts_TCP disabled=yes dst-port=0,11,20,21,22,23,79,113,119,135,139,194,389 in-interface-list=WAN protocol=tcp  
add action=add-src-to-address-list address-list=DropPortProbes address-list-timeout=5d chain=prerouting comment=CaptureUnusedPorts_TCP2 disabled=yes dst-port=445,500,1002,1025,1026,1027,1028,1029,1030,1720,5000 in-interface-list=WAN protocol=tcp  
add action=add-src-to-address-list address-list=DropPortProbes address-list-timeout=5d chain=prerouting comment=CaptureUnusedPortsUDP disabled=yes dst-port=0,11,20,21,22,23,79,113,119,135,139,194,389 in-interface-list=WAN protocol=udp  
add action=add-src-to-address-list address-list=DropPortProbes address-list-timeout=5d chain=prerouting comment=CaptureUnusedPorts_UDP2 disabled=yes dst-port=445,500,1002,1025,1026,1027,1028,1029,1030,1720,5000 in-interface-list=WAN protocol=udp  
add action=drop chain=prerouting disabled=yes in-interface-list=WAN src-address-list=DropPortProbes  

Как видишь, у меня нет правил фильтрации для захвата FORWARD-проб на 25, 53, 80, 443 и т.д. Может, добавить и их в эту схему?

Значит вы говорите, что нужно ставить то же самое правило в FORWARD, что и в INPUT. Но при этом отмечаете правило drop… ЗАЧЕМ? Если оставшиеся пакеты попадают в адресный список, то ни один не дойдёт до последнего drop-правила (которое теперь избыточно)???

/ip firewall filter  
{input chain}  
– разрешить админ-доступ с LAN  
– разрешить DNS с LAN  
– добавить весь остальной трафик в адресный список с именем stopProbes (timeout 6 часов)  
– сбрасывать весь остальной трафик (это правило теперь не нужно, так как до него пакеты не доходят)???

{forward chain}  
– разрешить трафик LAN → WAN  
– разрешить dst-nat трафик → connection-nat-state=dstnat  
– добавить весь остальной трафик в адресный список с именем stopProbes (timeout 6 часов)  
– сбрасывать весь остальной трафик (это правило теперь не нужно, так как до него пакеты не доходят)???

/ip firewall raw prerouting chain  
– сбрасывать пакеты с source-address-list=stopProbes

Хорошо, MKX, просто хочу уточнить, ты говоришь, что вместо того, чтобы добавлять дополнительную информацию по безопасности в правило NAT, не нужно делать общее правило для DSTNAT в фильтре, а лучше быть конкретным?

Допустим, у меня есть два потока переадресации портов (всего 4, tcp и udp):

add action=dst-nat chain=dstnat comment=CompanyA_TCP dst-port=xx,yy,zz in-interface-list=WAN log=yes protocol=tcp src-address-list=TechniciansA to-addresses=192.168.u.u  
add action=dst-nat chain=dstnat comment=CompanyA_UDP dst-port=xx,yy,zz in-interface-list=WAN log=yes protocol=udp src-address-list=TechniciansA to-addresses=192.168.u.u  

и

add action=dst-nat chain=dstnat comment=CompanyB_TCP dst-port=ttttt in-interface-list=WAN log=yes protocol=tcp src-address-list=TechniciansB to-addresses=192.168.v.v  
add action=dst-nat chain=dstnat comment=CompanyB_UDP dst-port=tttt in-interface-list=WAN log=yes protocol=udp src-address-list=TechniciansB to-addresses=192.168.v.v  

Ты предлагаешь следующие изменения… Разумеется, надо оставить NAT маршруты:

add action=dst-nat chain=dstnat comment=CompanyA_TCP dst-port=xx,yy,zz in-interface-list=WAN log=yes protocol=tcp to-addresses=192.168.u.u  
add action=dst-nat chain=dstnat comment=CompanyA_UDP dst-port=xx,yy,zz in-interface-list=WAN log=yes protocol=udp to-addresses=192.168.u.u  

и

add action=dst-nat chain=dstnat comment=CompanyB_TCP dst-port=ttttt in-interface-list=WAN log=yes protocol=tcp to-addresses=192.168.v.v  
add action=dst-nat chain=dstnat comment=CompanyB_UDP dst-port=tttt in-interface-list=WAN log=yes protocol=udp to-addresses=192.168.v.v  

а более специфичные правила фильтрации создавать отдельно, при этом порты и протоколы в фильтр не нужны:

add action=accept chain=forward comment="CompanyA DST FILTER" connection-nat-state=dstnat in-interface-list=WAN src-address-list=CompanyA  

add action=accept chain=forward comment="CompanyB DST FILTER" connection-nat-state=dstnat in-interface-list=WAN src-address-list=CompanyB

Но сейчас мы точно дублируем правило NAT в фаерволе IP? Это кажется странным. Я старался избегать дублирования, где возможно, ха-ха. Ладно, короткий ответ — ставим исходный адрес и в правила NAT, и в фильтр, да? Но надо спросить... что роутер читает первым — правило NAT или правило фильтра?  
Случай 1: если сначала идет правило NAT, тогда нам не нужно заморачиваться с точностью в фильтре, если мы укажем исходный адрес в NAT. Тогда фильтр может быть менее конкретным, и порты или протокол нас не волнуют... (где AuthorizedPortFowarders — это все IP компании (a+b)). Логика такая: когда пакет доходит до правила NAT, оно говорит: «Окей, исходный адрес Компании А к порту xx tcp на локальный IP .yy — подходит, двигаемся дальше...» Есть правило фаервола, разрешающее этот трафик? Да, совпадение есть. Значит, когда пакет доходит до фаервола, он говорит: да, это пакет назначения с WAN, и он из списка разрешённых. Все подходит, пропускаем... (и при этом Компания B не сможет добраться до портов Компании A).  
Случай 2: если сначала применяется правило фильтрации, тогда да, нужно всё подробно расписать В ФИЛЬТРЕ. Не уверен, что тогда можно как-то сократить правило NAT. Например, add chain=dstnat action=dst-nat in-interface=wan source-address-list=AuthorizedPortFowarders — это не сработает, потому что правило фаервола пропустит трафик, но публично-приватный перевод сделан не будет и так далее...  
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++­++  
После изучения диаграмм потоков пакетов, я колебался между первой и второй, какую выбрать. Похоже, что перед prerouting есть выбор фаервола! И ещё один после Bridge Forward, поэтому не совсем понятно, потому что фаервол может быть (filter, nat, mangle, raw, например). Диаграмма 4 немного помогает, ведь там подразумевается, что маршрутизация происходит до форвардинга, и я думаю, что речь идёт о фильтре в цепочке forward! Однако диаграмма 5 ещё яснее показывает цепочки потоков: последний шаг prerouting, как ты заметил, это dstnat, а фильтр forward почти самый последний шаг в цепочке forward. Поэтому мне кажется, я могу спокойно использовать add chain=forward action=accept in-interface=wan connection-state=dst source-address-list=AuthorizedPortFowarders.