У меня есть вторичная сеть от моего маршрутизатора ER605, она используется для изоляции подключенного устройства, Raspberry Pi. Я использую ее для карантина и сканирования входящих файлов из сомнительных источников (например, компьютеров моих родственников, постоянно зараженных вредоносным ПО). Мне нужно иметь возможность доступа к Pi и выгрузки отсканированных файлов в мою основную сеть. Я планирую использовать VNC для доступа и размещать файлы ok'd непосредственно на моем QNAP NAS через общий доступ SMB.
Правило ACL 5 блокирует связь из карантинной сети в мою основную сеть. Чтобы получить VNC для моего карантинного pi из моей основной сети, я изначально добавил правило 4, которого было недостаточно (онлайн-чтение подсказывало, что мне нужен ACL для ответных сообщений), поэтому я добавил версию правила 3, которая ссылалась на службу VNC, и это все равно не сработало. По прихоти я попробовал создать определение службы VNC_duplex, которое меняет местами порты источника и назначения, и изменить правило № 3 со службы VNC на VNC duplex, и вуаля VNC заработал!
Я очень рад, что это работает, но я не уверен, почему и безопасно ли это. Правильно ли я понимаю, что правило ACL 3 позволяет вредоносному скрипту отправлять сообщение с любого порта на raspberry pi на порт 5900 на любом устройстве в моей основной сети? Каков семантический способ понимания этого, и можно ли сделать это более безопасным?
Моя сеть и VLAN:
Я также настроил несколько диапазонов IP-адресов, чтобы описать области моей сети, которые я хочу сегментировать/предоставить к ним доступ:
Мои типы услуг (последние четыре введены мной самостоятельно):
И наконец мой ACL:
решение1
онлайн-чтение подсказало, что мне нужен ACL для ответных сообщений), поэтому я добавил версию правила 3, которая ссылалась на службу VNC, и это все равно не сработало. По прихоти я попробовал создать определение службы VNC_duplex, которое меняет местами порты источника и назначения, и изменить правило № 3 с службы VNC на VNC duplex, и вуаля VNC заработал!
Когда Pi отправляет ответы на ваш компьютер,Пи является источником.
«Возвратные» пакеты не только имеют IP-адрес Pi в качестве «исходного IP-адреса», но и соответствующий номер порта.на стороне Пикак «исходный порт».
Connection: 192.168.0.PC:54321 <--> 192.168.2.10:5900
Packets from PC: src = 192.168.0.PC:54321, dst = 192.168.2.10:5900
Packets from Pi: src = 192.168.2.10:5900, dst = 192.168.0.PC:54321
Все исходные шаблоны служб в вашем брандмауэре определены только для направления «вперед»; например, шаблон «VNC» соответствует порту 5900 в качестве порта назначения, что, как объяснялось, соответствует только пакетам, в которых в качестве пункта назначения указан сервер VNC, но не «обратным» пакетам.
Правильно ли я понимаю, что правило ACL 3 позволяет вредоносному скрипту отправлять сообщение с любого порта Raspberry Pi на порт 5900 на любом устройстве в моей основной сети?
Нет. Он позволяет сделать обратное — он позволяет скрипту отправлять сообщения.из порта 5900на малиновом пив любой портв вашей основной сети. («Источник» в «Порт источника = 5900»на самом деле означает(источник пакетов.)
Так как исходный порт соединенияможетбыть выбрана произвольно (при желании), это означает, что первичная сеть широко открыта для всех, ктознаето существовании этого исключения; все, что им нужно сделать, это попросить ОС привязать соединение к локальному порту 5900. (Но с другой стороны, поскольку исходный порт обычно выбирается случайным образом, а диапазон начинается далеко за пределами 5900, любой, ктоне делает(Знающий об этом исключении вряд ли обнаружит его случайно.)
Каков семантический способ понимания этого?
«Источник» на самом деле означает источник отдельного человека.пакет, а не всего соединения. (На самом деле порт можно было бы считать частью адреса пакета «транспортного уровня», и действительно, в нескольких других не-IP протоколах он был буквально частью адреса.)
Каждый порт связан с определенной конечной точкой, точно так же, как каждый IP-адрес связан с определенной конечной точкой — если вы устанавливаете соединение с Pi, вы не ожидаете, что «возвратный» пакет от Pi по-прежнему будет показывать IP-адрес Pi в качестве «пункта назначения», и то же самое относится к номерам портов.
и можно ли сделать его более безопасным?
Обычный подход заключается в том, чтобы полностью избегать таких рефлексивных ACL и использоватьс сохранением состояниябрандмауэр. Большинство маршрутизаторов способны отслеживать активные соединения («состояния» или «потоки») – они своего родапридетсяделают это, если они реализуют типичный 1:многие NAT, а фильтр брандмауэра может иметь специальное правило, которое разрешает любой пакет, соответствующий «установленному» соединению (как в iptables/nftables), или разрешает такие пакеты неявно (как в pf).
Похоже, ER603 получил поддержку ACL с отслеживанием состоянияв прошивке 2.1(Хотя, похоже, люди говорят, что это не работает.)
Если выдолжениспользовать ACL без сохранения состояния, тогда альтернативный подход заключается в том, чтобы разрешить только «возвратные» пакеты, которые имеютФлаг TCP "ACK"набор. Начальный пакет TCP-соединенияникогдаимеет этот флаг, в то время как все остальные пакеты имеют его; достаточно иметь одно правило, которое разрешает пакеты TCP ACK на любом порту.
Естественно, этот подход работает только для TCP — с UDP без отслеживания состояния вы ничего не сможете сделать, разве что надеяться, что никто не обнаружит дыру, которую создает ваш рефлексивный ACL.
У вас также должно быть еще одно правило, которое разрешает «возвратные» пакеты ICMP (например, эхо-ответ и различные сообщения об «ошибках» ICMP –как минимумНеобходимо разрешить ошибку «Требуется фрагментация», но желательно также разрешить и другие ошибки, такие как «Недоступно»).