Filter to NAT

Тема в разделе "Маршрутизация", создана пользователем Ника, 21 июл 2016.

  1. Ника

    Ника Новый участник

    Здравствуйте!

    Ребят, подскажите правило!
    надо грамотно перенаправить на внутренний сервак
    В фильтре разрешаем вход на роутер (имеющий статический внешний) с внешнего IP ааа.ввв.ссс.0/19 по порту и протоколу
    далее нужно натировать на адрес внутри сети 192.168.1.10

    просто через нат работает, но как сказал Гуру Илья - это не есть наш метод

    надо вначале отфильтровать, а потом передать
     
  2. Илья Князев

    Илья Князев Администратор Команда форума

    Не... Вы не поняли. Сначала сработает dst-nat и потом фильтр в цепочке forward. В input этот трафик не попадет.
     
  3. Ника

    Ника Новый участник

    А как отправить в цепочку фильтр после нат?
    если мы разрешим chain=dstnat action=dst-nat to-addresses=192.168.1.10 protocol=udp in-interface=ether1 dst-port=5060-5070,10000-20000
    то пойдет к нам все кому не лень :)
    если укажем chain=dstnat action=dst-nat to-addresses=192.168.1.10 protocol=udp src-address=" IP ВАСИ" in-interface=ether1 dst-port=5060-5070,10000-20000
    то пакеты по придут только от IP ВАСИ, но это судя по вашим статьям не надежно
    если просто поставить chain=forward action=accept protocol=udp src-address=IP ВАСИ in-interface=ether1
    ну правило и правило, нат то все всех равно пускает
    можно поставить внизу форвард правило chain=forward action=drop in-interface=ether1

    не хочется грузить проц ошибочными правилами
    а да самое нижнее правило у меня chain=input action=drop in-interface=ether1, в принципе это дублирует блокировку форвард

    правил у меня пока не много, проц 1-2% загружен
    я работаю по принципу запретить всё, а потом разрешаю. читал, что это сейчас не очень практикуется.
    как лучше?
     
  4. Илья Князев

    Илья Князев Администратор Команда форума

    Нет конечно. Дальше пишем в файрволле правило в цепочке forward. Только с учетом того, что адрес назначения и порт назначения уже те, что задал NAT.
    Тут грубо
    /ip firewall filter
    add action=drop dst-address=192.168.1.10 dst-port=5060-5070,10000-20000 src-address-list=!allowed-sip
    не пропустит никого кроме тех, кто указан в списке allowed-sip
    Нет единого стандарта. Даже на одном роутере используются обе политики в зависимости от интерфейса.
     
  5. Ника

    Ника Новый участник

    а почему грубо? мне кажется не плохо добавили протокол, поднимаем правило наверх и вуаля, пусть сразу все гуляют
    должно работать.
     
  6. Илья Князев

    Илья Князев Администратор Команда форума

    скорее комментарий к описанию. Не стал приводить диаграммы прохождения трафика через роутер.
     
  7. Ника

    Ника Новый участник

    Илья, если указываем порты, то он просит еще и протокол обязательно, что логично.
    у меня стоит так
    0 chain=input action=drop src-address-list=BOGON in-interface=ether1

    1 chain=input action=accept in-interface=!ether1

    2 chain=forward action=accept connection-state=established

    3 chain=forward action=accept connection-state=related

    4 chain=forward action=drop protocol=udp dst-address=192.168.1.10 src-address-list=!allow-sip dst-port=4569,5060-5070,10000-20000

    если поднимаю выше то нет или звука или вообще регистрации. ну пока вроде нормально fail2ban не ругается

    ps сегодня заметил телики LG лезут в гугл на
    64.233.165.188:5228
    108.177.14.188:5228
    и хард помаргивает периодически, достала эта слежка, думаю рубануть.
     
  8. Илья Князев

    Илья Князев Администратор Команда форума

    У вас какой-то странный файрволл. Скажем так
    Код:
    /ip firewall filter 
    Разрешили на вход все что сами создали в Output
    Код:
    add chain=input connection-state=established,related action=accept 
    Разрешили ICMP
    Код:
    add chain=input protocol=icmp action=accept 
    Грохаем все что пришло с WAN. Если что-то надо разрешить ставим перед этим правилом. Все это все. И богоны тоже.
    Код:
    add chain=input in-interface=WAN action=drop
    //Теперь пошел Forward. Если у нас клиенты за NAT, что чтобы трафик снаружи попал в форвард надо или чтобы клиент из-за ната создал подключение, или было правило в dst-nat
    Тогда грохаем непонятнтые соединения.
    Код:
    add chain=forward connection-state=invalid action drop 
    И защищаемся от подмены адреса на входе. Если новый пакте идет с WAN и попал в Forward он ДОЛЖЕН был быть обработан dst-nat. Иначе drop
    Код:
    add chain=forward connection-nat-state=!dstnat connection-state=new in-interface=WAN action=drop 
    Остальное дописать по желанию.
     
  9. Ника

    Ника Новый участник

    Еще раз благодарю Вас, Илья.
    у меня списочек побольше, что то перекочевало из правил линуха
    0 chain=input action=drop src-address-list=BOGON in-interface=ether1 log=no log-prefix=""

    1 chain=input action=accept in-interface=!ether1 log=no log-prefix=""

    2 chain=forward action=accept connection-state=established log=no log-prefix=""
    думаю правило 2 и 3 можно объединить, по старинке раздельно делал
    3 chain=forward action=accept connection-state=related log=no log-prefix=""

    4 chain=forward action=drop protocol=udp dst-address=192.168.1.10 src-address-list=!allow-sip dst-port=4569,5060-5070,10000-20000 log=no log-prefix=""

    5 chain=forward action=drop connection-state=invalid log=no log-prefix=""

    6 chain=input action=accept tcp-flags=ack protocol=tcp log=no log-prefix=""

    7 chain=input action=accept connection-state=established log=no log-prefix=""
    и 7, 8 можно вместе
    8 chain=input action=accept connection-state=related log=no log-prefix=""

    9 chain=input action=accept protocol=udp src-port=53 dst-port=1024-65535 log=no log-prefix=""

    10 chain=input action=accept protocol=icmp icmp-options=0:0-255 log=no log-prefix=""

    11 chain=input action=accept protocol=icmp icmp-options=3:0-255 log=no log-prefix=""

    12 chain=input action=accept protocol=icmp icmp-options=4:0-255 log=no log-prefix=""

    13 chain=input action=accept protocol=icmp icmp-options=11:0-255 log=no log-prefix=""

    14 chain=input action=accept protocol=icmp icmp-options=12:0-255 log=no log-prefix=""

    15 chain=input action=drop in-interface=ether1 log=no log-prefix=""

    Вообще классная вещь Mikrotik, много функций.
     
  10. InfSub

    InfSub Новый участник

    Сори за некропостинг, нагуглил эту тему...

    В последнее время замечаю ночами сильный поток данных, на различные ip оканчивающиеся на 188 (aaa.bbb.ccc.188) порт всегда 5228, источник - ПК
    Кто-нибудь может прокомментировать - что это?
     
  11. порт похож на гугловский, но стоит все-таки проверить компьютер на вирусы, определить источник, если что-то подозрительное - убить )
     
  12. Мышаня

    Мышаня Участник

    5228 - порт через который работает google play (маркет). Что именно может так теребить с ПК - не понятно...
     
  13. InfSub

    InfSub Новый участник

    Про гугл плей не прокомментирую, хотя да, с мобильных устройств, через Wi-Fi, тоже есть поток данных на этот порт и эти IP
    Но и со стационарных ПК, оставленных на ночь, аналогичная ситуация, более сотни соединений с 3-5 компов. Разве что, если это гугл, может обновление Google Chrome... сложно сказать, это действительно надо мониторить сам ПК, но вирусов быть, по идее не должно, антивирусник есть (согласен, это не всегда показатель чистоты компа)
     
  14. Какой трафик генерят?
     
  15. InfSub

    InfSub Новый участник

    вчера правило врубил которое режет все обращения по данному порту, ночью отключу - заскриню
     
  16. InfSub

    InfSub Новый участник

    кстати, может кто подскажет, на сколько корректно правило, которое ловит только TCP syn запросы (не проверяя другие флаги - наличие отсутствие), у меня по данному правилу уже более 4000 адресов в бане
     
  17. InfSub

    InfSub Новый участник

    Во вложении скрин
    попыток подключиться к 5228 не вижу, но возможно они были ранее, либо их просто не было из-за того, что компы погасили, когда правило еще работало, что странно, ПК с данными IP в сети давно нет, а вот соединения висят, при том с теми же 188 адресами, только порт теперь 443 (https) и таймаут в несколько часов из-за чего видимо и висят

    Соответственно вопрос, а кто определяет таймаут соединения? и как их убивать, это хорошо их сейчас 20 штук, а так будут висеть пара сотен, к примеру
    к слову, на dhcp у меня таймаут для ip 5 минут
     

    Вложения:

    • 443.PNG
      443.PNG
      Размер файла:
      137 КБ
      Просмотров:
      5