SecretSanta

Крутяк, спасибо за объяснение. Короче говоря, я остановился на данный момент на включенном peer-isolation и следующих правилах на In направлении: permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80 permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 23 permit udp 192.168.1.0/24 192.168.1.1/32 port eq 53 deny ip 192.168.1.0/24 192.168.1.1/32 Напоминаю, что изначальной целью была изоляция хостов в локалке друг от друга и от роутера за исключением одного хоста (192.168.1.2) с сохранением доступа к интернету. P.S. Всем спасибо за помощь.

То есть, если я хочу изолировать всех от всех локалке с возможностью в будущем разрешить отдельный траффик между отдельными хостами, единственный вариант - тех, кто должен быть изолирован несмотря ни на что, пихать в одну подсеть и включать peer-isolation; тех, кто должен иметь возможность обмениваться чем-то, в другую подсеть без peer-isolation (то есть с "полным" доступом к друг другу). Или есть еще какие-то варианты? Невозможность изоляции внутри L2-сегмента без peer-isolation - это архитектурная фишка самого стека или особенность реализации в Keenetic'ах? Я поперепутал опять направления... Теперь все понятно :) Я добавлял это правило, чтобы изолировать хосты друг от друга и роутер от хостов. Но раз хосты все равно не изолировать (только что проверил, действительно не работает), то в нем смысла нет, конечно. Роутер от хостов, как вы и сказали, можно в In.

У меня все клиенты подключены по Wi-Fi (прошу прощения, если из первого поста это не было понятно). По проводу никто не подключен. Мне не нужно запрещать ТОЛЬКО доступ к интерфейсу, а нужно изолировать всех клиентов друг от друга и от роутера (кроме от 192.168.1.2 к web-интерфейсу). Именно поэтому я пишу это правило в Out. Использовать peer-isolation я не могу, потому что эта опция приоритетнее любого разрешающего правила файерволла (как подсказали выше). Скорее всего, мне понадобится позже между отдельными хостами в локалке разрешить траффик на отдельных портах. Суть моего предыдущего комментария была в том, что написанное в доках и в комменте KorDen (второй абзац) не соответствует дейсвительности (или я неправильно интерпретирую, что имеется в виду) - если разрешить входящий траффик (первое правило In), то исходящий в рамках установленного соединения должен идти нормально и не подпадать уже под правила файерволла (под правило Out), но это не так. Об этом говорит то, что я не могу зайти в интерфейс и что происходит мгновенный разрыв telnet-соединения после привязки правила из Out к интерфейсу (хотя это установленная tcp-сессия). Если правила Out выглядят так: permit tcp 192.168.1.1/32 port eq 80 192.168.1.2/32 deny ip 192.168.1.0/24 192.168.1.0/24 то все ОК. Как я уже сказал выше, все подключено по Wi-Fi. Все происходит в рамках одной подсети 192.168.1.0/24.

Хорошо, допустим, я хочу изолировать всех от всех в локалке (хосты друг от друга, хосты от роутера, роутер от хостов... ну вы поняли) за одним исключением - один хост с ip 192.168.1.2 должен иметь доступ к web-морде на роутере с ip 192.168.1.1. Пишу следующие правила: 1. In: permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80 deny ip 192.168.1.0/24 192.168.1.1/32 2. Out: deny ip 192.168.1.0/24 192.168.1.0/24 И я не могу зайти в web-интерфейс с 192.168.1.2. Более того, как только я привязываю второе правило (acl) к интерфейсу, тут же теряется telnet-соединение. То есть либо я что-то делаю неправильно (чего я не исключаю), либо никакого правила вида "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" нет, либо это правило перезаписывается правилом из списка out.

1. Это понятно, я не об этом спрашивал. Давайте переформулирую: какова логика в выборе направления (In, Out или оба?), для которого пишутся правила для файерволла, если роутер не является ни source ip (если source ip, то Out), ни destination ip (если destination ip, то In)? Например, от одного хоста в локалке к другому (ни один из них не является роутером). 2. Ваш ответ навел меня на другой вопрос: допустим, я (192.168.1.2) хочу открыть web-интерфейс (192.168.1.1:80). Для установления сессии мне достаточно разрешить Source IP - 192.168.1.2, Destination IP - 192.168.1.1, Destination port - 80 (In)? Или надо еще разрешить Source IP - 192.168.1.1, Source port - 80, Destination IP - 192.168.1.2 (Out)? Или вы это и имели в виду (что достаточно первого (In) правила)? P.S. Извините за, возможно, тупые вопросы.

Да, это в инструкции к CLI написано. Проглядел в первый раз. У меня тогда еще вопрос вдогонку по работе файерволла: 1. Допустим я делаю DNS-запрос на роутер - это подподает под направление In; 2. DNS-ответ от роутера подподает под направление Out; 3. Что если на 192.168.1.2 поднят web-сервер, и я делаю запрос к нему с 192.168.1.3? По логике в моей бошке это должно подподать под In и Out (так как пакеты идут до роутера, а потом от него). Например, я пытался заблочить в качестве эксперимента такой путь только в In правилах, и это не сработало. Значит ли это, что в таких случаях (когда пакеты идут через роутер, а не инициированы им или он является пунктом назначение - как в п. 1 и п. 2) мы выбираем направление (In или Out) по конечному узлу (то бишь это будет Out, так как последнее направление - от роутера к 192.168.1.2)? Или мы пишем правила и в In, и в Out?

Появилась необходимость изолировать WiFi-клиентов друг от друга и запретить доступ к WEB-интерфейсу роутера. Я врубил peer-isolation и protected security level в CLI. Все работает: клиенты перестали пинговаться, WEB-интерфейс не видят. Теперь, допустим, мне надо: 1. Теперь мне надо разрешить доступ к WEB-интерфейсу с одного IP. Я добавил правило в файерволл и теперь я получаю в качестве ответа 403 Forbidden (вместо таймаута - это без добавленного правила). Отсюда первый вопрос: protected security level помимо запрета на уровне файерволла еще и добавляет запрет на уровне веб-сервера или я что-то неправильно делаю? Правило: Source IP - 192.168.1.2, Destination IP - 192.168.1.1, Destination port - 80. 2. При включенной изоляции, допустим, я хочу разрешить взаимодействие между двумя IP-адресами. Для проверки добавил правила, разрешающие пинговать друг дружку, но не работает. Отсюда второй вопрос: peer-isolation или правила файерволла приоритетнее? Я читал, что у файерволла. Правило 1: Source IP - 192.168.1.2, Destination IP - 192.168.1.3, Protocol - ICMP, Правило 2: Source IP - 192.168.1.3, Destination IP - 192.168.1.2, Protocol - ICMP. P.S. Правила делал через WEB-интерфейс, не CLI. Есть ли разница?

Я не совсем понял, что вы имете в виду под этими двумя примерами. Если то, что провайдеры (а-ля Билайн) и USB-модемы крутят какие-то ресурсы с доменными именами, привязанными к адресам из частных диапозонов - однозначно надо делать команду (опцию), позволяющую определнные доменные имена добавлять в исключения (чтобы они нормально резолвились). Если имелось в виду что-то другое, то прошу прощения - я не настоящий тракторист . Если это действительно проблема, можно тогда определять локальные подсети для роутера (для которых роутер является шлюзом) и запрещать резолвить адреса только из них (ну и локалхост, собственно). Можно сделать еще проще и переложить это дело на пользователя - пусть сам вводит диапазон, для которого должна работать защита от DNS Rebinding. Ну и вы абсолютно правы, что по умолчанию врубать это все не стоит.

1. А что вы используете в качестве DNS-сервера на роутере? Что-то самописное или какой-то из относительно стандартных пакет типа dnsmasq, bind9, unbound? Вполне возможно, что там это уже реализовано в том или иной мере. Например, в dnsmasq есть ключ stop-dns-rebind. На тот случай, если пользователь имеет на локалхосте или в локалке какой-то сервис с настроенным доменным именем, можно их добавить в исключения соответветственно ключами rebind-localhost-ok и rebind-domain-ok=[<domain>]|[[/<domain>/[<domain>/]. 2. Вообще говоря от любого upstream сервера надо ответы с адресами из приватных диапазонов отбрасывать. Отдельные DNS-сервера могут иметь подобную защиту (например, вроде OpenDNS), может и провайдеры отдельные промышяют чем-то подобным, но я б не стал на это надеяться. 3. И 127.0.0.0/8, и приватные диапазоны из RFC1918, да. Насчет реализации тут вам решать: можно, конечно, из всех этих диапазонов отбрасывать; можно посмотреть какой диапазон использует пользователь в локалке у себя и исключать только его. Я бы, наверно, захардкодил все диапазоны приватные на всякий случай. Это и проще. P. S. Я не специалист по сетям или ИБ, просто интересующийся так сказать. Я, конечно, понимаю как это должно работать (вроде бы... ), но если вы все-таки возьметесь это реализовывать, крайне рекомендую ознакомиться со статьей из моего предыдущего ответа, там действительно очень хорошо все описано и объяснено.

Есть такая атака - DNS Rebinding. Она позволяет залезть внутрь периметра файервола. Если кратко, то суть в следующем: атакующий владеет доменом attack.com и DNS-сервером, обслуживающим этом домен. Когда вы заходите на этот сайт (DNS-сервер резолвит attack.com как, допустим, 5.5.5.5), вы скачиваете некий javascript. Предварительно атакующий ставит очень короткий TTL для этой А-записи. За это время он успевает поменять эту А-запись с 5.5.5.5 на, например, 127.0.0.1 или какой-нибудь адрес в LAN. Соответственно, когда TTL истекает, браузер повторно делает запрос на резолвинг attack.com и вместо 5.5.5.5 получает 127.0.0.1. А теперь самое интересное: если у вас на локалхосте или локалке крутится какой-нибудь веб-сервер или сервис с API, для работы с которыми не нужно авторизовываться, атакующий может делать к ним запросы и потом полученные данные пересылать себе посредством того самого javascript. Есть хорошая статья с диаграммами, где это более понятно и подробно описано в т.ч. с примерами. Атака не самая простая и дешевая, да и чисто технически это не проблема роутера или прошивки, а скорее веб-сервисов, не требующих авторизации, и вы здесь не причем. Но учитываю распространение всяких в том числе IoT-устройств, которые перестают поддерживаться очень быстро, где нельзя самому прикрутить какие-нибудь креденшиалсы или проверку заголовка Host и которые, располагаясь в локалке или локалхосте, могут способствовать сливу всяких чувствительных данных, может есть смысл с вашей сторону добавить опцию, позволяющую отбрасывать ответы от апстрим серверов, возвращающих адреса из частных диапозонов.

Можно ли стандартными средствами (может с помощью CLI) запретить DNS на роутере резолвить адреса из локальной сети и localhost или придется возиться с установкой сторонних DNS типа dnsmasq? Интерес связан с предотвращением атаки DNS Rebinding. Вообще неплохо было бы добавить такую возможность в интерфейс (хотя бы в виде какой-нибудь галочки).