Что такое nfs сервер
Как побывать в корейском университете с помощью Network File System
Предисловие
Давным-давно в начале 2000-х многие развлекались тем, что регулярно «сканировали» сети своего провайдера, а иногда и более далекие цели на предмет обнаружения Windows машин и ресурсов на них (SMB), доступных на чтение (запись). Процесс поиска был примитивен: задавался диапазон IP-адресов или маска сети и посредством различных инструментов — LANguard Network Scanner, xIntruder и подобных — сканировались адреса и находились сервера. Зачастую на обнаруженных машинах оказывались доступными на чтение, реже на запись, различные сетевые ресурсы (диски, принтеры, директории). Через анонимную сессию посредством IPC$ и пользователя «Guest» удавалось перечислять ресурсы на машине, иногда находились члены «Administrators» без паролей, а иногда, после более «активного» воздействия в отношении обнаруженных машин, удавалось найти сервера с ОС Windows NT 4.0 или Windows 2000 Server. Если удача соблаговолила обнаружить машины с распространенной тогда Windows 98, то становилось проще — в те времена в указанной ОС содержалось множество разных уязвимостей, в том числе в реализации работы с SMB, брутфорс для получения доступа к ресурсу осуществлялся за считанные минуты даже на dial-up соединениях. Для желающих окунуться в старину здесь подробно написано про «доступ» к Windows 9x — Hacking Exposed: Network Security Secrets & Solutions. Chapter 4: Hacking Windows 95/98 and Me. Но далее в статье речь не об этом.
Никогда бы не подумал, что в 2019 году возможно подобное «развлечение». Подобие же заключается в легкости поиска чужих доступных ресурсов для всех любопытствующих. Далее речь пойдет не о популярном в последние 2 года тренде — поиске открытых для доступа баз данных MongoDB или Elasticsearch — а о несколько более приземленном сервисе.
Далее весь порядок действий, их этическую норму предлагаю не оценивать, отмечаю, что настоящий пост не призыв к действиям, которые возможно отнести к некоторым статьям Уголовного кодекса РФ или подобным нормам из законодательств других государств.
Network File System (NFS)
Network File System (NFS) — протокол сетевого доступа к файловым системам, позволяет подключать (монтировать) удалённые файловые системы через сеть, обеспечивает пользователям доступ к файлам, позволяет работать с этими файлами точно так же, как и с локальными.
Большинство представленных на рынке Network-attached storage (NAS), конечно же, поддерживают NFS, и предоставляют доступ к локальным ресурсам равно как и на любом сервере с операционной системой, в которой возможно развернуть службу NFS.
Настройки доступа к ресурсам сервера с какой-нибудь ОС Ubuntu и IP-адресом 192.168.1.1 содержатся в файле /etc/exports и представляют собой записи вида:
В данном случае доступ по NFS к серверу и его ресурсу /data/place1 возможен для клиентов с IP-адресами из сетей 192.168.1.0/255.255.255.0, 192.168.101.0/255.255.255.0.
В случае, если вместо IP-адресов указано * или (everyone) — то, зачастую, любой клиент может смонтировать удаленный ресурс себе в систему.
Таким образом формируется следующий сценарий: детектировать сервера с работающей службой NFS, определить доступные ресурсы на серверах, консолидировать результат в единую форму вывода, и дальше действовать по ситуации.
Что может быть на ресурсах — очевидно, что угодно:
Получение IP-адресов
В отношении обнаружения серверов со службой NFS в глобальном Интернете возможны 2 способа: самостоятельно, используя различные инструменты, и готовые сторонние результаты сканирования, базы данных и сервисы. Фактически всё сводится к получению списка IP-адресов. В локальной сети, полагаю, вариант очевиден — действовать самостоятельно.
Свидетельством функционирования сервиса NFS могут выступать открытые TCP-порты 111, 2049.
Для самостоятельного получения списка IP-адресов серверов достаточно просканировать диапазон адресов или целиком подсети на наличие указанных открытых портов. Для этого подойдет любой инструмент: nmap, masscan и так далее.
Или установить клиент Shodan(CLI), инициализировать свой API KEY к сервису и из командной строки вызвать поиск, например:
Итак, как получить списки IP-адресов устройств с действующей службой NFS – понятно.
Получение информации о доступных ресурсах службы NFS на конкретных серверах.
Для решения этой задачи массово есть множество путей: написать bash-скрипты, организовать хитрый pipeline из цепочки команд с вызовом showmount и другие варианты — кому что нравится.
Я же в своих изысканиях решил эту задачу на Python, причем двумя разными способами. Первый — с подключением посредством ssh к своему личному серверу на Ubuntu с NFS-клиентом и последующим вызовом на нем команды showmount с искомым пулом IP-адресов. Второй вариант решения — на чистом Python.
Предполагаю, что может возникнуть вопрос: почему так сложно, почему на Python?
Потому что, как и в предыдущей своей статье на Хабр, я буду использовать инструмент Lampyre, к которому 26 февраля опубликовали API, позволяющий писать на Python свои модули к платформе.
Кратко про Lampyre — программная платформа для OSINT и анализа данных с «толстым» клиентом под Windows, аналог известного и популярного инструмента для тех же целей — Maltego. Как и в Maltego, в Lampyre «из коробки» предоставляется набор запросов к различным сервисам. Запросы концептуально являются аналогами трансформаций из более известного продукта. Если чего-то не хватает, теперь возможно написать свои запросы. Запросы, поставляемые с Lampyre, исполняются на инфраструктуре платформы, написанные самостоятельно — на машине. То есть у пользователя должен быть установлен Python и все необходимые библиотеки, используемые в коде.
Я решил протестировать возможности API. Ключевой момент — в Lampyre уже есть несколько «requests» к Shodan, тем более что иметь свой API KEY от сервиса пользователю не надо. Таким образом, одним запросом можно получить списки IP-адресов с поднятым NFS сервисом, а вторым запросом, написанный мной модуль будет проверять доступные ресурсы и визуализировать результат с характеристиками ресурсов на том же графе.
Причем тут Корея
В ходе поиска из Shodan и тестирования модуля стало интересно посмотреть обстановку с качеством и количеством результатов сканирования сервисом Shodan стран Азии, как обстоят дела с незащищенными ресурсами. Выбор пал на Республику Корея, думаю нет нужды говорить о том, что Южная Корея очень технологически развитая страна, и я предположил, что в ее сетях можно найти что-нибудь интересное.
Поиск по Shodan, в Query: nfs, в Country: код Республики Kорея, kr
Результат не заставил себя долго ждать (на изображении ниже только часть общей схемы).
Все они, как это видно и на графе, и по названиям — числятся за AS1781 — Korea Advanced Institute of Science and Technology
Корейский институт передовых технологий — ведущий учебный и исследовательский университет Южной Кореи, расположенный в Тэджоне, находится на второй строчке национального рейтинга в Южной Корее. Университет стабильно входит в 5% топовых учебных заведений Южной Кореи.
Указанные IP-адреса используем как входные аргументы к написанному модулю «Explore: NFS(SSH)» и в результате:
Я быстро составил такую схему отображения результатов таблицы в граф (о схемах и принципах построения графов дальше по тексту статьи).
Результат объединения со схемой Shodan
При анализе вершин и связей графа становится очевидно на каких адресах расположен ресурс /home, доступный всем (*).
Для лучшего визуального восприятия изменим свойства объектов графа и другие настройки схемы:
Конечно же, я по очереди смонтировал часть ресурсов на один из своих серверов и стал изучать. Везде оказывалось почти одно и тоже — директории пользователей: asm, hoo, hyshin, jay, jiwon, jkhee110, jokangjin, kmh603, ksm782, lee, linus, lost+found, marvel_guest, pie, qwe, scloud, seokmin, sgim, thrlek, yoosj, ysha, zinnia7.
Я сгенерировал свой ключ, скопировал его в authorized_keys одного из пользователей и подключился к серверу по ssh на порт 2222, номер порта получил из данных от Shodan.
Пользователи, настройки сети:
Файл /etc/exports и диски:
Файл /etc/fstab и OS:
Полагаю, что это сеть какой-то кафедры для аспирантов или студентов, а на серверах производят какие-то свои вычисления, потому как там много различных исходников на Python, что-то связанное с GPU и дистрибутив Anaconda, тому прочее. Я не стал всё изучать и стал думать, что с этим всем делать, понятно, я мог «ходить» по большей части нод(может быть придумать что-нить более экзотическое), но интереса особенного у меня это не вызывало. И надумал я следующее: раз институт научный и передовой, должны быть направления по информационной безопасности. Действительно, даже целая лаборатория: Software Security Lab и ее руководитель Sang Kil Cha
Ему я и решил написать письмо, так мол и так, дозволять всем в Интернет подключать ресурсы NFS с правами чтения и записи очень опасно, видимо вам надо что-то исправить, прикрепил скриншоты и отправил.
Вскоре мне ответили, вольный перевод: спасибо, перешлём кому положено.
Thanks for letting me know! I will forward this email to someone in charge of our network and security. Best, Sang Kil
Перед публикацией настоящей статьи я решил проверить, посмотреть что изменилось:
Действительно, доступ к ресурсам разрешили только от машин во внутренней сети, но как быть с сервером 143.248.247.251. Согласно записям в таблице к ресурсам хоста в настройках NFS так и осталось *. Я набросал еще один вариант «мэпинга» таблицы в граф:
В чем изменения «мэпинга»: объекты NFS теперь «склеиваются» при 2 одинаковых атрибутах — IP и NFS path. Объект Status создается лишь тогда, когда в атрибуте Value, в который попадает содержимое колонки raw record, содержится значение «*»
И граф по таблице предстает в новом виде:
Теперь, кстати, стала отчетлива видна адресация внутренней сети, причём на сервере 143.248.247.251 также возможно редактирование содержания пользовательских директорий, файлов; в принципе — возможности остались те же самые, что и ранее.
И вот я пишу второе письмо мистеру Sang Kil Cha, с подобным первому содержанием, отмечая, что часть событий будут изложены в статье на популярном ресурсе habr.com:
Dear Sang Kil Cha, good day to you.
I decided to take a look if anything changed after my e-mail to you and indeed, the access settings have been changed. But apparently the security engineers left out the 143.248.247.251 ip address and its settings stayed the same. Please secure this ip as well so that no strangers could access it.
I’m writing an article on the subject of Information Security and I’ll be posting it at https://habr.com. This is a very popular website in Russia. The article will include a few passages on the matter of low quality of NFS access settings with a few examples of the case with your servers. I will send you the link to my article when it’s posted.
Как использовать API Lampyre и написать свой модуль
От модуля будет требоваться принимать на вход список из IP-адресов или список из подсетей в виде 192.168.0/24 — на данном этапе, необходимо будет самостоятельно в коде осуществлять валидацию корректности входных данных на причастность строк к IP-адресам, в случае подсети — преобразовать в список IP.
Далее, по замыслу концепта, осуществляется примитивная попытка разобрать значение ключа status_ip на предмет: IP-адрес, запись хоста, значения «*» или «everyone»
Согласно документации к API и пояснениях от support Lampyre.io — каждый модуль должен возвращать данные в таблицу, одну или несколько, но таблица должна быть описана в рамках API (Task headers, table header). Фактически — это основной результат работы модуля.
Таким образом, конечный результат с учетом ключей словаря будет таблицей:
В таблицу будут записываться значения (несколько модифицированные) от разбора результата исполнения команды showmount на сервере. Названия полей класса говорят сами за себя, в колонке raw record будет храниться информация о возможностях доступа к ресурсу. Такой разбор данных о ресурсах NFS можно в некотором смысле считать и OSINT-ом, информация о возможном доступе с различных IP-адресов дает какое-то представление о собственниках ресурса или адресации внутри сети ресурса. Например, IP-адрес сервера со службой NFS расположен в Украине, а IP-адрес, разрешенный на доступ — в Германии:
А если расширить изучение данного примера, то тут же находится подтверждение связи серверов не только через NFS, но и через один сертификат на адресах: 77.120.103.9, 138.201.202.135 и домен *.aniart.com.ua:
Как передавать данные в модуль и писать в таблицу:
создается собственный класс SearchDataNFS от класса Task:
В методе get_id возвращаем уникальный рандомный UUID:
В методе get_headers указываем какие таблицы будем использовать:
Метод get_enter_params будет определять вид окна ввода входных данных. Из кода очевидно, что на вход подается список строк, который позже самостоятельно будет преобразован в IP-адреса:
В методе execute происходит основное исполнение задачи:
К входным параметрам осуществляется обращение через enter_params.ips. В методе reparse_ip_hosts — происходит самостоятельно реализованная валидация строк в IP-адреса.
В функции thread_async_nfs_one_client происходит подключение к серверу с ssh (IP-адрес, логин и пароль заданы hardcode) и исполняется showmount, так как ранее указывал, результат разбирается, потом в функции reparse_result_rows он еще раз модифицируется. Важно отметить, info — список, состоящий из словарей, в каждом словаре ключи названы как поля класса NFSHeader. То есть словарь выглядит так:
Важно соблюдать типы данных в словаре, они должны быть такими же, как в описании таблицы.
Далее в цикле происходит итерация по элементам списка и их запись через метод API (result_writer.write_line) в конкретную таблицу NFSHeader.
Для более подробного описания необходимо ознакомиться с документацией.
В принципе, модуль уже готов для добавления в Lampyre.
Использование своего модуля в Lampyre
В связи с тем, что используется ssh и исполнение команды showmount, конечно же, необходимо иметь доступ к своему серверу по ssh. У меня для тестов такую роль выполняла виртуальная машина в Virtualbox c Ubuntu и установленным на ней NFS-клиентом.
Загрузка модуля в Lampyre осуществляется следующими шагами:
Обновленное окно List of requests:
Конечно необходимо учитывать и пропускную способность от своего и чужого серверов, и timeout, заданные жестко в коде модуля.
Результат получен в виде таблицы, но можно продолжить и совместить результат таблицы с графом результатов от исполнения Shodan search. Это будет несколько сложно для восприятия сначала.
Визуализация таблицы с результатом
Приступим. Есть таблица с набором колонок со значениями от исполнения модуля пользователя. Но если обратить внимание на кнопку Sсhema окна Requests – она неактивна. Потому как не задано отображение таблицы в граф и его необходимо задать.
Схема 1 (не самая лучшая)
При открытой таблице от результата модуля внизу в правом углу есть элемент интерфейса «Add creation template», нажав на который появляется окно «Creation template». В нём-то и можно задавать отображение строк таблицы в объекты графа, подробно описывать процесс в рамках статьи не буду, по ссылке на канале платформы в Youtube показано как такое осуществить, в рамках статьи я ограничусь изображениями того что должно получиться:
Важно отметить, объекты IP, Domain — имеются в Lampyre, а объекты NFS и Network – я создал. У каждого объекта есть атрибуты, в которые пользователь «мэпит» колонки таблицы. Причем, у объекта может быть несколько атрибутов, часть из которых — по которым вершины должны «склеиться» на графе — ключевые, другие — для вывода названия вершин-объектов графа, это могут одни и те же атрибуты или совсем другие. Например, для объекта NFS – созданы 2 атрибута, NFS path и Status, ключевой атрибут — NFS path. Объекту можно назначить свою иконку — кликнув на изображение объекта справа. По завершении «мэпинга» колонок в атрибуты объектов можно строить схему — упомянутая выше кнопка Schema станет активной.
Шаблон отсутствует:
Шаблон для графа по таблице составлен:
В целом такой подход к «мэпингу» значений из колонок и строк таблицы в объекты графа существует и в другом приложении — i2 (IBM i2 Analyst’s Notebook):
После визуализации графа от такого «мэпинга» становится понятно, что это не лучший вариант: видно отношение IP-адреса сервера к IP-адресам и хостам, с которых возможны доступы, и имеющиеся ресурсы NFS на сервере, но ведь к разным ресурсам возможны доступы с разных IP. Поэтому создаём другую схему (для любой таблицы можно создать множество схем).
Схема 2
Уже лучше. Всё становится на свои места — на каком сервере есть ресурсы, и с каких IP-адресов к ним возможен доступ:
Такой вариант создания шаблона схемы графа по таблице удобен лишь тогда, когда не так часто приходится работать с собственным модулем, или в случае импорта текстовых файлов (csv) в приложение. Дело в том, что созданный подобным образом «мэпинг» сохраняется лишь в рамках текущего расследования. После создания нового «расследования» модуль будет сохранен и будет исполнятся с результирующей таблицей, но схема не сохранится и её придется строить заново.
Для объединения результатов от поиска по Shodan и NFS необходимо открыть схему Shodan search, активировать кнопку add to active tab и нанести на ту же вкладку результат нашего модуля — схемы объединятся:
Код модулей для Lampyre доступен, там же вторая версия модуля без использования подключения по ssh.
Вместо заключения — коллеги, регулярно проверяйте корректность настроек своих NFS и не только.
Установка
Для установки и сервера, и клиента необходимы одни и те же пакеты nfs-kernel-server и nfs-common
Настройка сервера
и добавляем в конец файла строки вида (строк может быть произвольное количество):
/data –путь к папке, для которой раздается доступ;
192.168.1.1 –IP-адрес, которому раздается доступ к папке(можно указать всю сеть, тогда запись примет вид 192.168.1.0/24)
(rw,no_root_squash,sync) –набор опций, опции могут быть:
rw –чтение запись(может принимать значение ro-только чтение);
no_root_squash –по умолчанию пользователь root на клиентской машине не будет иметь доступа к разделяемой директории сервера. Этой опцией мы снимаем это ограничение. В целях безопасности этого лучше не делать;
noaccess – запрещает доступ к указанной директории. Может быть полезной, если перед этим вы задали доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям.
Необходимо добавить описание опций.
all_squash– подразумевает, что все подключения будут выполнятся от анонимного пользователя
subtree_check (no_subtree_check)- в некоторых случаях приходится экспортировать не весь раздел, а лишь его часть. При этом сервер NFS должен выполнять дополнительную проверку обращений клиентов, чтобы убедиться в том, что они предпринимают попытку доступа лишь к файлам, находящимся в соответствующих подкаталогах. Такой контроль поддерева (subtree checks) несколько замедляет взаимодействие с клиентами, но если отказаться от него, могут возникнуть проблемы с безопасностью системы. Отменить контроль поддерева можно с помощью опции no_subtree_check. Опция subtree_check, включающая такой контроль, предполагается по умолчанию. Контроль поддерева можно не выполнять в том случае, если экспортируемый каталог совпадает с разделом диска;
anonuid=1000– привязывает анонимного пользователя к «местному» пользователю;
anongid=1000– привязывает анонимного пользователя к группе «местного» пользователя.
В последствии после внесения изменений в файл /etc/exports не обязательно перезапускать сервер, достаточно выполнить:
Настройка клиента
Для монтирования сетевой папки необходимо создать папку на локальном компьютере:
Монтирование вручную
Для монтирования папки вручную необходимо выполнить в терминале команду:
Монтирование с записью в fstab
Для большего удобства можно добавить запись с сетевой папкой в fstab. Целесообразно создать точку монтирования сетевой папки в /media, потому что каталоги, созданные там, будут отображаться в Nautilus в левой колонке, монтировать их можно будет одним кликом.
В файл /etc/fstab добавляем подобную запись:
опция «noauto» запрещает автоматическое монтирование сетевого диска при старте системы.
Проблемы
Использование на ноутбуке
При монтировании удаленных папок NFS посредством fstab, в ситуации, когда сеть с сервером будет не доступна, ноутбук невозможно выключить или отправить в спящий режим. Для использования удаленных папок NFS на ноутбуке лучше воспользоваться монтированием при помощи autofs
Монтирование с помощью autofs
Данный способ монтирования позволяет автоматически монтировать папку после обращения к ней в наутилусе (к примеру, через закладки) или в терминале:
и автоматически отмонтировать при отсутствии активности.
Установка
Для реализации данного способа необходимо доустановить пакет autofs :
Настройка
Для настройки autofs в файле /etc/auto.master необходимо добавить строку
Здесь –timeout=60 указывает отмонтировать раздел при отсутствии активности на нём более чем 60 секунд. Создаем в корне файловой системы папку /nfs :
В файле /etc/auto.nfs добавляем строку
-rw,soft,intr,rsize=8192,wsize=8192 – параметры монтирования;
server – папка, которая будет создаваться в каталоге /nfs при монтировании удаленных папок;
192.168.1.2:/path_to_share– IP-адрес и общая папка сервера.
Перезапускаем службу autofs :
Проблемы
Недоступность удаленного сервера
Если сеть с сервером NFS недоступна, возможна большая задержка (по умолчанию 3 минуты) при открытии nautilus, в закладках которого находится примонтированная удаленная папка NFS.
Для решения этой проблемы необходимо уменьшить время ожидания монтирования autofs, для этого в файле /etc/default/autofs необходимо раскомментировать или добавить следующие строки:
#время ожидания ответа от mount
#время ожидания при неудачной попытке монтирования
После этого autofs будет пытаться примонтировать удаленную папку только 10 секунд.
Использование
Проблемы
Проблемы с гибернацией или выключением
После настройки автомонтирования сетевых папок NFS могут обнаружится некотрые проблемы с выключением или гибернацией системы. Чаще всего это проявляется как прерывающаяся гибернация (компьютер начинает уходить в гибернацию, гаснет экран, после чего экран опять загорается и работа продолжается, так же в этих случаях возможны проблемы с выключением и перезагрузкой системы. При последующих попытках отправить компьютер в гибернацию на черном экране вверрху можно наблюдать строку типа:
Для диагностирования смотрим лог dmesg, возможный вывод:
Пакет, являющийся причиной зависания указан в начале строки, следующей после сообщения об ошибке.
Причина №1: пакет NFS
Причиной данной проблемы является скрипт прерывания работы NetworkManager, необходимо запретить его выполнение переименовав его: