Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    uPnP и файрвол... что с этим делать?

    uPnP и файрвол... что с этим делать?

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    uPnP и файрвол... что с этим делать?, RouterOS
     
    nsayer
    Guest
    #1
    0
    08.12.2011 20:04:00
    У меня включён uPnP, чтобы внутренние хосты могли запрашивать входящие соединения. Также у меня есть такие правила:

    0 X chain=forward action=accept protocol=icmp  
    1 X chain=forward action=accept connection-state=established in-interface=ether1-gateway  
    2 X chain=forward action=accept connection-state=related in-interface=ether1-gateway  
    3 X chain=forward action=reject reject-with=icmp-network-unreachable in-interface=ether1-gateway  

    Обратите внимание, что они отключены. Если их включить, входящие соединения перестают работать. В принципе, меня это не сильно удивляет.

    Что я на самом деле хочу узнать — это лучшие практики для такого случая. Мне говорили, что неразумно полностью полагаться на NAT, чтобы защищать внутренние хосты. Но в то же время, если внутренние хосты через uPnP запрашивают перенос портов для входящих соединений, то фаервол должен это пропустить.

    Но разве это не то же самое, что просто использовать NAT в роли фаервола? Если бы существовало некое волшебное правило типа «chain=forward action=accept allowed-by=uPnP», которое вставлять между правилами 2 и 3, то что тогда этот фаервол по сути делал бы?
     
     
     
    SeaburyNorton
    Guest
    #2
    0
    31.12.2011 23:57:00
    bump Кто из других гуру согласен или не согласен с этим методом (выше)?
     
     
     
    Djelibeybi
    Guest
    #3
    0
    01.01.2012 21:03:00
    Ну, цепочка Forward предназначена для маршрутизируемых пакетов. Ты используешь NAT для устройств UPnP, так что они обрабатываются в цепочке NAT. Честно говоря, не уверен, что цепочка Forward вообще что-то делает в этой ситуации.
     
     
     
    nsayer
    Guest
    #4
    0
    02.01.2012 00:08:00
    В этом случае это явно используется, о чём говорит тот факт, что мне пришлось добавить правило, позволяющее пропускать весь входящий трафик в мою локальную сеть.
     
     
     
    Djelibeybi
    Guest
    #5
    0
    03.01.2012 00:22:00
    У меня нет правил переадресации, и UPnP отлично работает только с автоматически добавленными правилами dst-nat.
     
     
     
    nsayer
    Guest
    #6
    0
    03.01.2012 00:29:00
    Итак, у вас есть правило null forward, которое пропускает весь трафик. Попробуйте добавить правило в цепочку forward, которое будет сбрасывать весь трафик, и посмотрите, что произойдет.
     
     
     
    SeaburyNorton
    Guest
    #7
    0
    08.03.2012 17:14:00
    Можно ли сказать (или подтвердить у Mikrotik), что правило upnp nat не требует наличия правила фильтрации в фаерволе, которое его пропускает? Например, если у вас есть правило в фильтре фаервола, отбивающее все пакеты из цепочки forward с интернет-интерфейса, то правило upnp nat всё равно их примет?
     
     
     
    bahbka
    Guest
    #8
    0
    02.02.2013 13:42:00
    Устройства в одной и той же broadcast-домене на WAN-интерфейсе могут получить доступ к вашей приватной LAN, добавив маршрут типа <YOUR_LAN_NETWORK> через <YOUR_WAN_IP>, пока вы не запретите такой форвардинг. Это серьёзная проблема безопасности. Рекомендую добавить правило drop/reject для форварда. Конечно, нужны некоторые правила «принять», по крайней мере для установленных соединений. Не знаю, как заставить работать UPnP-форвардинг в этой ситуации без добавления правил accept для конкретных портов.
     
     
     
    nsayer
    Guest
    #9
    0
    02.02.2013 15:52:00
    Разве блокировка исходной маршрутизации не приведёт к тому же результату?
     
     
     
    bahbka
    Guest
    #10
    0
    02.02.2013 17:09:00
    Хмм, ты прав! Спасибо за совет.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры