dxdt.ru: занимательный интернет-журнал

Одним из достаточно безопасных способов передачи файлов данных между разными информационными системами является использование “файлообменной” машины (обычно – виртуальной машины, выделенной для этой цели). То есть, экспортирующая система силами скрипта-робота выкладывает файлы данных на обменную машину, а импортирующая система – забирает свежие файлы, зайдя на файлообменную машину силами собственного скрипта-робота – см. схему.

И тут ни одна из систем, обменивающихся файлами, не обращается к другой системе напрямую, ни одной из систем не требуется доступ к ресурсам другой системы. Более того, файлообменная машина играет регулирующую и фильтрующую роль: никакой сервис, работающий на этой машине, не должен куда-то подключаться “наружу”, куда-то – это к системам, между которыми и передаются данные.

Поэтому получается добротная, обозримая и понятная точка обмена файлами. Такая архитектура позволяет даже сеть передачи данных выделить под задачу – то есть, файлообменные машины находятся в обособленном сегменте (логическом, виртуальном или “физическом” – как угодно), при этом контроль сетевого доступа дополнительно осуществляется вне файлобменной машины. Можно даже сделать доступ через какой-нибудь физически изолированный канал (не сеть): например, прямое соединение оптоволокном.

Основная цель подобной схемы в том, чтобы максимально логически изолировать разные информационные системы, сохранив возможность передачи данных. И такая схема изоляции систем в чём-то очень хороша, а в чём-то – не так хороша, но положительные стороны перевешивают при сравнении со многими другими вариантами организации передачи данных.

Рассмотрим практические особенности схемы с выделенной файлообменной машиной.

Итак, пусть одна информационная система экспортирует файлы, а вторая – импортирует. Для экспорта нужно обеспечить “исходящий” сетевой доступ к файлообменной машине: естественно, “исходящий” – тут не обязательно работает на уровне “диода данных”. Конечно, в идеале можно сделать аппаратный однонаправленный интерфейс, в котором физически не предусмотрено передачи любых данных в обратную сторону. Но в большинстве практических случаев это излишне, прежде всего потому, что теряется возможность аутентификации одной из логических сторон, то есть приложений (каждую физическую сторону – аутентифицировать может система построения канала). Поэтому в данном обзоре не будем совсем строить сложности, а ограничимся организацией выкладки файлов при помощи SSH-доступа. То есть, сервис (скрипт) на экспортирующей системе (“Система А” на схеме) периодически подключается по SSH к файлообменной машине и выгружает туда файлы (заметьте, вовсе не обязательно выгружать через scp – это, опять же, прочие детали, но немного про них будет в конце записки). Это не “диод данных”, но файлообменная машина, с логической точки зрения, оказывается “однонаправленной” системой: подключиться туда можно только по инициативе передающей стороны, и никакие файлы данных при этом на скачиваются (но загружаются).

Естественно, установление SSH-соединения требует не только уровня подключения с управлением сессией (TCP, в данном случае), но и двунаправленного взаимодействия с сервером на уровне SSH: сервер должен ответить, прислать ключи и так далее. Так что однонаправленным соединение оказывается только на самом высоком логическом уровне. Тем не менее, SSH-сервер, обычно, является типовым элементом и уже есть в операционной системе (например, через него ходят администраторы), поэтому тут не добавляется ничего принципиально нового, а вот имеющееся – можно и урезать (см. ниже).

Атакующая сторона, если она взломала файлообменную машину, не может, штатно, куда-то подключиться с этой машины, но может, например, подменить присылаемые файлы. Более продвинутая атака состоит в воздействии на SSH-сервер: технически, действуя умело и изящно, можно “перепрыгнуть” в обратную сторону – от SSH-сервера на подключающийся клиент. Но это уже будет высший пилотаж, даже для хорошо подготовленного пентестера.

Заметьте, что так как инициатива подключения находится на стороне сервера передающей системы, то, после вторжения на файлообменную машину, не получится как-то гарантированно навязать нужные данные этой передающей системе – придётся дождаться подключения. Это важный момент, который исключает сразу много классов уязвимостей. Например, перемещение данных между логическими HTTP-соединениями: если бы с файлообменной машины можно было куда-то штатно подключиться по HTTP, то в это “куда-то” можно было бы в любой момент отправить “полезную нагрузку”, взломав, таким образом, следующий хоп. Когда подобные исходящие запросы заведомо блокируются, придётся ждать подключений (того же SSH). Всякое ожидание увеличивает шансы обнаружения вторжения – это очень важный момент, про который постоянно забывают. (Естественно, захват контроля над файлообменной машиной позволяет попробовать найти что-то в “ближайшей сети” и т.д. Именно поэтому такая машина и должна быть изолирована на сетевом уровне.)

Посмотрим теперь на ситуацию со стороны другой информационной системы, которая принимает файлы (“Система Б”). Сервис (скрипт) в этой системе, как мы договорились, тоже имеет возможность SSH-подключения к файлообменной машине: подключаясь, этот сервис забирает новые файлы, которые выгружены со стороны экспортирующей системы. Если атакующая сторона захватила импортирующую систему, то какие есть возможности в отношении экспортирующей? Получается, что такой атакующий может зайти на файлообменную машину тем же аккаунтом, который использовал штатный сервис. Как минимум, автоматом получаем возможность читать экспортируемые файлы. Как максимум – можно поднять привилегии. Можно-то – можно, но не факт, что так просто.

Почему-то часто считают, что SSH-доступ всегда эквивалентен локальному шелл-доступу к основной системе. Но это не так. Понятно, что, – по нынешним-то временам, – путь от локального аккаунта до суперпользователя не так долог, как хотелось бы (возможно, теоретически, это не так под чем-нибудь вроде хорошо настроенной FreeBSD, но речь про практическую ситуацию). Однако, никто ведь не сказал, что и SSH-сервер, и шелл, предназначенные исключительно для реализации обмена файлами, нельзя изолировать локально, выкинув всё лишнее, и не только под FreeBSD. Нет, вовсе не обязательно использовать тот же сервер и тот же шелл, которые нужны DevOps для управления. Напротив – подключаемся, заходим, а там изолированная директория и, вместо полноценного шелла, только урезанный набор из ls, mkdir, cat, (s)cp и mv (rename), предположим. То есть, для атакующего – опять дополнительные шаги и локальные хопы (loopback какой-нибудь использовать и пр.), а каждый хоп, не забывайте, тоже повышает шансы обнаружения вторжения.

При этом SSH-авторизация обеспечивает защиту доступа к файлообменной машине (когда работает, конечно, что уж там). Но в описываемой схеме, да просто так, – даже захватив одну из информационных систем, которые файлообменную машину используют, – перейти в другую информационную систему нельзя. Точка обмена файлами оказывается своего рода тупиком: нужно ломать и её тоже, а возможности сильно ограничены.

Сравним теперь нашу схему с вариантом, когда файлообменной машины нет, а экспортирующая информационная система (“Система А”) загружает данные непосредственно в импортирующую (“Система Б”), через специальный высокоуровневый прикладной интерфейс (API), поднятый именно с этой целью. Это может быть rsync, но может быть и HTTP-сервер. Тогда, если принимающая система скомпрометирована, то получается, что экспортирующая система уже прямо подключается к контролируемому атакующей стороной серверу. В случае файлообменной машины это не так: там требовалось сперва захватить саму файлообменную машину. Но, естественно, остаётся необходимость ожидать момента подключения.

Ещё хуже, если используется HTTP-сервер, общий с другими задачами импортирующей системы. Этот HTTP-сервер может быть атакован и захвачен в рамках выполнения им других задач, но при этом атакующий получает плацдарм для прямой атаки на другую внутреннюю информационную систему (“Система А”), подключающуюся периодически для выгрузки файлов данных. Но для этой второй системы HTTP-сервер оказывается доверенным, так как задействован во внутреннем процессе. А на стороне принимающей системы – этот же сервер раздаёт, предположим, веб-страницы всем желающим.

А если атакующий захватил передающую систему, то, при условии прямого подключения, он может сразу атаковать и принимающую. Более того, тут уже подготовлен тот или иной доступ – скажем, SSH или даже TLS с двухсторонней аутентификацией. При этом отсутствие логического промежуточного узла, файлообменной машины, не позволяет эффективно разделить информационные системы на логическом же уровне протокола сетевого взаимодействия – доступ уже должен быть прямым (естественно, промежуточные сетевые узлы тут могут быть всё равно, но это теперь совсем другой аспект). Более того, прямое соединение систем навязывает всякие прочие “архитектурные решения”, в которых системы станут смешиваться и, по ошибке администратора, из одной – окажется легко перепрыгнуть в другую, без учёта направления.

Адрес записки: https://dxdt.ru/2026/01/16/16420/