Предисловие
Давным-давно в начале 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 — . Но далее в статье речь не об этом.
Никогда бы не подумал, что в 2019 году возможно подобное «развлечение». Подобие же заключается в легкости поиска чужих доступных ресурсов для всех любопытствующих. Далее речь пойдет не о популярном в последние 2 года тренде — поиске открытых для доступа баз данных MongoDB или Elasticsearch — а о несколько более приземленном сервисе.
Далее весь порядок действий, их этическую норму предлагаю не оценивать, отмечаю, что настоящий пост не призыв к действиям, которые возможно отнести к некоторым статьям Уголовного кодекса РФ или подобным нормам из законодательств других государств.
Network File System (NFS)
— протокол сетевого доступа к файловым системам, позволяет подключать (монтировать) удалённые файловые системы через сеть, обеспечивает пользователям доступ к файлам, позволяет работать с этими файлами точно так же, как и с локальными.
Большинство представленных на рынке Network-attached storage (NAS), конечно же, поддерживают NFS, и предоставляют доступ к локальным ресурсам равно как и на любом сервере с операционной системой, в которой возможно развернуть службу NFS.
Настройки доступа к ресурсам сервера с какой-нибудь ОС Ubuntu и IP-адресом 192.168.1.1 содержатся в файле /etc/exports и представляют собой записи вида:
- /data/place1 192.168.1.0/255.255.255.0(rw,no_subtree_check,nohide,async) 192.168.101.0/255.255.255.0(rw,no_subtree_check,nohide,async)
- data/place2 192.168.1.0/255.255.255.0(rw,no_subtree_check,nohide,async) 192.168.101.0/255.255.255.0(rw,no_subtree_check,nohide,async)
В данном случае доступ по NFS к серверу и его ресурсу /data/place1 возможен для клиентов с IP-адресами из сетей 192.168.1.0/255.255.255.0, 192.168.101.0/255.255.255.0.
Смонтировать удаленный ресурс в локальную директорию, например, /home/user/example, если клиент в разрешенной подсети, и установлен клиент для NFS, возможно через команду(Ubuntu):
mount -t nfs 192.168.1.1:/data/place1 /home/user/example
В случае, если вместо IP-адресов указано * или (everyone) — то, зачастую, любой клиент может смонтировать удаленный ресурс себе в систему.
Пользователю (например, под Ubuntu) достаточно набрать в терминале: showmount -e ip-target и получить информацию о доступных ресурсах на сервере (server’s export list).
Например:
showmount -e 81.24.ХХХ.ХХХ
Export list for 81.24.ХХХ.ХХХ:
/home/admin 192.168.52.1/24
Таким образом формируется следующий сценарий: детектировать сервера с работающей службой NFS, определить доступные ресурсы на серверах, консолидировать результат в единую форму вывода, и дальше действовать по ситуации.
Что может быть на ресурсах — очевидно, что угодно:
- личные файлы пользователей Интернет, например, в случаях «открытых» NAS устройств;
- директории с файлами целых предприятий, баз данных, архивы баз данных;
- часто директории с адресами /home/* (иногда с ключами в .ssh и доступные на запись);
- директории с файлами систем видеонаблюдения;
- прочее…
Получение IP-адресов
В отношении обнаружения серверов со службой NFS в глобальном Интернете возможны 2 способа: самостоятельно, используя различные инструменты, и готовые сторонние результаты сканирования, базы данных и сервисы. Фактически всё сводится к получению списка IP-адресов. В локальной сети, полагаю, вариант очевиден — действовать самостоятельно.
Свидетельством функционирования сервиса NFS могут выступать открытые TCP-порты 111, 2049.
Для самостоятельного получения списка IP-адресов серверов достаточно просканировать диапазон адресов или целиком подсети на наличие указанных открытых портов. Для этого подойдет любой инструмент: nmap, masscan и так далее.
Например, командой masscan -p111,2049 200.26.1XX.0/24 —rate=10000 будет за несколько секунд сканирована сеть 200.26.1XX.0/24 на предмет открытых портов 111, 2049:
Scanning 256 hosts [2 ports/host]
Discovered open port 2049/tcp on 200.26.1XX.28
Discovered open port 111/tcp on 200.26.1XX.15
Discovered open port 111/tcp on 200.26.1XX.20
Discovered open port 111/tcp on 200.26.1XX.28
Дальше к каждому из обнаруженных IP-адресов возможно применить команду:
showmount --no-headers -e 200.26.1XX.28
Результат:
/usr/common *
Очевидно, что самому сканировать миллионы IP-адресов пространства Интернет возможно, но это не самый быстрый путь и тогда решением подзадачи может выступить замечательный сервис , есть конечно и другие, но этот с очень удобным и . Углубляться в описание возможностей сервиса не является целью статьи. Кратко — сервис предоставляет расширенный поиск по устройствам, подключенным к сети Интернет. Критериями поиска могут выступать сетевые идентификаторы и другие метаданные: серийные номера сертификатов и тому подобное. В Shodan много возможностей целевого поиска, но отдельного поиска по NFS я не нашел, как, например, есть по критерию product с указанием названия продукта: mongodb, elastic или apache. Поэтому через Web NFS возможно искать по следующим запросам: nfs, tcp 2049, tcp 111, и так далее, как угодно.
Или установить клиент Shodan(CLI), инициализировать свой API KEY к сервису и из командной строки вызвать поиск, например:
- shodan search —fields ip_str,port Portmap:2049
- shodan search —fields ip_str,port —separator, nfs
Результат:
139.196.154.23,111,
198.27.116.37,111,
95.211.192.96,111,
80.23.66.122,111,
210.116.82.97,111,
192.198.82.3,111,
165.227.67.242,111,
116.12.48.9,111,
85.34.250.102,111,
182.75.249.197,111,
192.151.212.175,111,
119.216.107.127,111,
217.59.68.2,111,
178.159.12.97,111,
…
Итак, как получить списки IP-адресов устройств с действующей службой NFS – понятно.
Получение информации о доступных ресурсах службы NFS на конкретных серверах.
Для решения этой задачи массово есть множество путей: написать bash-скрипты, организовать хитрый pipeline из цепочки команд с вызовом showmount и другие варианты — кому что нравится.
Я же в своих изысканиях решил эту задачу на Python, причем двумя разными способами. Первый — с подключением посредством ssh к своему личному серверу на Ubuntu с NFS-клиентом и последующим вызовом на нем команды showmount с искомым пулом IP-адресов. Второй вариант решения — на чистом Python.
Предполагаю, что может возникнуть вопрос: почему так сложно, почему на Python?
Потому что, как и в предыдущей своей статье на Хабр, я буду использовать инструмент Lampyre, к которому 26 февраля опубликовали , позволяющий писать на Python свои модули к платформе.
Lampyre
Кратко про Lampyre — программная платформа для OSINT и анализа данных с «толстым» клиентом под Windows, аналог известного и популярного инструмента для тех же целей — Maltego. Как и в Maltego, в Lampyre «из коробки» предоставляется набор запросов к различным сервисам. Запросы концептуально являются аналогами трансформаций из более известного продукта. Если чего-то не хватает, теперь возможно написать свои запросы. Запросы, поставляемые с Lampyre, исполняются на инфраструктуре платформы, написанные самостоятельно — на машине. То есть у пользователя должен быть установлен Python и все необходимые библиотеки, используемые в коде.
Я решил протестировать возможности API. Ключевой момент — в Lampyre уже есть несколько «requests» к Shodan, тем более что иметь свой API KEY от сервиса пользователю не надо. Таким образом, одним запросом можно получить списки IP-адресов с поднятым NFS сервисом, а вторым запросом, написанный мной модуль будет проверять доступные ресурсы и визуализировать результат с характеристиками ресурсов на том же графе.
Причем тут Корея
В ходе поиска из Shodan и тестирования модуля стало интересно посмотреть обстановку с качеством и количеством результатов сканирования сервисом Shodan стран Азии, как обстоят дела с незащищенными ресурсами. Выбор пал на Республику Корея, думаю нет нужды говорить о том, что Южная Корея очень технологически развитая страна, и я предположил, что в ее сетях можно найти что-нибудь интересное.
Поиск по Shodan, в Query: nfs, в Country: код Республики Kорея, kr
Результат не заставил себя долго ждать (на изображении ниже только часть общей схемы).
Список хостов:
- psi.kaist.ac.kr
- hulk.kaist.ac.kr
- messi.kaist.ac.kr
- marvel.kaist.ac.kr
- kaist.ac.kr
- ai1.kaist.ac.kr
- jarvis3.kaist.ac.kr
- baraddur.kaist.ac.kr
- rho.kaist.ac.kr
- jarvis.kaist.ac.kr
Все они, как это видно и на графе, и по названиям — числятся за AS1781 —
— ведущий учебный и исследовательский университет Южной Кореи, расположенный в Тэджоне, находится на второй строчке национального рейтинга в Южной Корее. Университет стабильно входит в 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.
Почти все директории с файлами были доступны на чтение и запись. У некоторых пользователей в .ssh были доступны файлы authorized_keys с возможностью записи в них.
Я сгенерировал свой ключ, скопировал его в authorized_keys одного из пользователей и подключился к серверу по ssh на порт 2222, номер порта получил из данных от Shodan.
Пользователи, настройки сети:
Хосты в сети:
Файл /etc/exports и диски:
Файл /etc/fstab и OS:
Полагаю, что это сеть какой-то кафедры для аспирантов или студентов, а на серверах производят какие-то свои вычисления, потому как там много различных исходников на Python, что-то связанное с GPU и дистрибутив Anaconda, тому прочее. Я не стал всё изучать и стал думать, что с этим всем делать, понятно, я мог «ходить» по большей части нод(может быть придумать что-нить более экзотическое), но интереса особенного у меня это не вызывало. И надумал я следующее: раз институт научный и передовой, должны быть направления по информационной безопасности. Действительно, даже целая лаборатория: и ее руководитель
Ему я и решил написать письмо, так мол и так, дозволять всем в Интернет подключать ресурсы NFS с правами чтения и записи очень опасно, видимо вам надо что-то исправить, прикрепил скриншоты и отправил.
Письмо 1
Dear Sang Kil Cha,
I’m writing you, as at the kaist.ac.kr website you are referred to as the leading SoftSec Lab at KAIST, and I believe the following matter is of your concern.
During our research in the field of informational security, unintentionally and by chance the following servers were detected:
143.248.247.131 — psi.kaist.ac.kr
143.248.247.4 — jarvis3.kaist.ac.kr
143.248.247.169
143.248.247.223
143.248.247.235
143.248.247.251 — marvel.kaist.ac.kr
143.248.247.239 — jarvis.kaist.ac.kr
143.248.247.194 — hulk.kaist.ac.kr
143.248.2.23
All these servers have the NFS (Network File System) service up and running.
The security level of access to these servers is incredibly low.
Home directories of these servers with all their content can be accessed by anyone using the Internet.
For example, settings nfs — /etc/exports 143.248.247.251—>/home or for 143.248.247.239
showmount -e 143.248.247.239
Export list for 143.248.247.239:
/data
/home /appl
User directories of most of the servers are accessible for reading and writing, including their sub directories, which contain public and private ssh access keys.
Editing files allows adding new access keys and gaining remote ssh access to the servers and then – to some inner KAIST subnets.
Solely for testing such shallow access was obtained, no modifications were made, no data was edited, copied or deleted, no harm was done to the infrastructure.
Please see the attached files for some sort of acknowledgement and proof.
I do not have any requirements or claims but I do recommend considerably enhancing your network security level.
Вскоре мне ответили, вольный перевод: спасибо, перешлём кому положено.
Ответ 1
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:
Письмо 2
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 . 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.
Следующим шагом, посредством библиотеки Python будет осуществляться обращение к личному ssh серверу и последовательный (попытка асинхронности в коде концепта модуля присутствует) вызов команды:
timeout {timeouts} showmount --no-headers -e {ip}
Вывод результата будет разбираться посредством кода на Python в выводную структуру, таблицу: список из словарей в Python.
Ключи в словаре:
- current_day – дата запроса пользователя
- host_query — IP, в отношении которого получаем информацию
- shared_path — ресурс NFS
- status_ip — информация о возможностях доступа к ресурсу, если перечисляются IP-адреса через «,», то строка-словарь дублируется в рамках списка.
Далее, по замыслу концепта, осуществляется примитивная попытка разобрать значение ключа status_ip на предмет: IP-адрес, запись хоста, значения «*» или «everyone»
Согласно документации к и пояснениях от support Lampyre.io — каждый модуль должен возвращать данные в таблицу, одну или несколько, но таблица должна быть описана в рамках API (Task headers, table header). Фактически — это основной результат работы модуля.
Таким образом, конечный результат с учетом ключей словаря будет таблицей:
class NFSHeader(metaclass=Header):
display_name = 'Search data from NFS services'
current_day = Field('Date', ValueType.Datetime)
host_query = Field('Search ip', ValueType.String)
shared_path = Field('NFS path', ValueType.String)
ip = Field('ip address', ValueType.String)
network = Field('network address', ValueType.String)
host = Field('host', ValueType.String)
status = Field('raw record', ValueType.String)В таблицу будут записываться значения (несколько модифицированные) от разбора результата исполнения команды showmount на сервере. Названия полей класса говорят сами за себя, в колонке raw record будет храниться информация о возможностях доступа к ресурсу. Такой разбор данных о ресурсах NFS можно в некотором смысле считать и OSINT-ом, информация о возможном доступе с различных IP-адресов дает какое-то представление о собственниках ресурса или адресации внутри сети ресурса. Например, IP-адрес сервера со службой NFS расположен в Украине, а IP-адрес, разрешенный на доступ — в Германии:
А если расширить изучение данного примера, то тут же находится подтверждение связи серверов не только через NFS, но и через один сертификат на адресах: 77.120.103.9, 138.201.202.135 и домен *.aniart.com.ua:
Как передавать данные в модуль и писать в таблицу:
создается собственный класс SearchDataNFS от класса Task:
class SearchDataNFS(Task)В методе get_id возвращаем уникальный рандомный UUID:
def get_id(self):
return 'bf51fd57-3fec-4416-9d07-905935a484b4'В методе get_display_name указываем как будет называться Task, а в методе get_description, соответственно названию, описание Task:
def get_display_name(self):
return 'Explore: NFS(SSH)'
def get_description(self):
return 'Explore NFS resourses'В методе get_headers указываем какие таблицы будем использовать:
def get_headers(self):
return NFSHeaderМетод будет определять вид окна ввода входных данных. Из кода очевидно, что на вход подается список строк, который позже самостоятельно будет преобразован в IP-адреса:
def get_enter_params(self):
ep_coll = EnterParamCollection()
ep_coll.add_enter_param('ips', 'IP', ValueType.String, is_array=True,
value_sources=[Attributes.System.IPAddress],
description='IPs, networks')
return ep_collВ методе происходит основное исполнение задачи:
ips = []
for input_ip in set(map(lambda z: z.strip(), enter_params.ips)):
ips.extend(reparse_ip_hosts(input_ip))К входным параметрам осуществляется обращение через enter_params.ips. В методе reparse_ip_hosts — происходит самостоятельно реализованная валидация строк в IP-адреса.
targets = ((ip, port) for ip in ips for port in ports)
lines = thread_async_nfs_one_client(targets)
info = reparse_result_rows(lines)
fields_table = NFSHeader.get_fields()
for data_id in info:
tmp = NFSHeader.create_empty()
for field in fields_table:
if field in data_id:
tmp[fields_table[field]] = data_id[field]
result_writer.write_line(tmp, header_class=NFSHeader)В функции thread_async_nfs_one_client происходит подключение к серверу с ssh (IP-адрес, логин и пароль заданы hardcode) и исполняется showmount, так как ранее указывал, результат разбирается, потом в функции reparse_result_rows он еще раз модифицируется. Важно отметить, info — список, состоящий из словарей, в каждом словаре ключи названы как поля класса NFSHeader. То есть словарь выглядит так:
{
'current_day': datetime.datetime(2019, 3, 6, 16, 48, 17),
'host_query': '192.168.1.1',
'shared_path': '/volume1/workspace',
'ip': '192.168.10.10',
'network': '',
'host': '',
'status': '192.168.10.10'
}Важно соблюдать типы данных в словаре, они должны быть такими же, как в описании таблицы.
Далее в цикле происходит итерация по элементам списка и их запись через метод API () в конкретную таблицу NFSHeader.
Для более подробного описания необходимо ознакомиться с документацией.
В принципе, модуль уже готов для добавления в Lampyre.
Использование своего модуля в Lampyre
В связи с тем, что используется ssh и исполнение команды showmount, конечно же, необходимо иметь доступ к своему серверу по ssh. У меня для тестов такую роль выполняла виртуальная машина в Virtualbox c Ubuntu и установленным на ней NFS-клиентом.
Для работы с собственными модулями на машине пользователя необходим Python 3.6, путь к интерпретатору должен быть в системных переменных, либо указан путь до него в файле LampyreconfigappSettings.config. По умолчанию ключ pythonPath в настройках закомментирован.
Загрузка модуля в Lampyre осуществляется следующими шагами:
- В окне Scripts загрузить файл Lampyreuser_tasksontology.py (поставляется с приложением)
- В том же окне загрузить свой модуль, в данном случае nfs_via_ssh.py. Если что-то пошло не так, то должна помочь кнопка Details
- После загрузки в окне List of requests на вкладке Tasks появится раздел Local tasks (в коде модуля можно было назвать иначе), в нем название Explore:NFS(SSH):
Обновленное окно List of requests: - IP-адреса серверов с NFS, как я говорил ранее, лучше получить предварительно исполнив запрос Shodan search с параметрами Query: tcp 2049 (можно и просто указать nfs). Параметр Page or range, установленный по умолчанию в 1, означает, что вернется 1 страница ответов от сервиса Shodan, на 1 странице обычно 100 результатов(строк).
Результат исполнения Shodan: - Скопировать в буфер обмена IP-адреса из таблицы или со схемы и вставить его в окно модуля IP Explore:NFS(SSH). Запустить и ожидать результата:
Конечно необходимо учитывать и пропускную способность от своего и чужого серверов, и 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 станет активной.
Шаблон отсутствует:
Шаблон для графа по таблице составлен:
В целом такой подход к «мэпингу» значений из колонок и строк таблицы в объекты графа существует и в другом приложении — :
После визуализации графа от такого «мэпинга» становится понятно, что это не лучший вариант: видно отношение IP-адреса сервера к IP-адресам и хостам, с которых возможны доступы, и имеющиеся ресурсы NFS на сервере, но ведь к разным ресурсам возможны доступы с разных IP. Поэтому создаём другую схему (для любой таблицы можно создать множество схем).
Схема 2
Уже лучше. Всё становится на свои места — на каком сервере есть ресурсы, и с каких IP-адресов к ним возможен доступ:
Такой вариант создания шаблона схемы графа по таблице удобен лишь тогда, когда не так часто приходится работать с собственным модулем, или в случае импорта текстовых файлов (csv) в приложение. Дело в том, что созданный подобным образом «мэпинг» сохраняется лишь в рамках текущего расследования. После создания нового «расследования» модуль будет сохранен и будет исполнятся с результирующей таблицей, но схема не сохранится и её придется строить заново.
Для объединения результатов от поиска по Shodan и NFS необходимо открыть схему Shodan search, активировать кнопку add to active tab и нанести на ту же вкладку результат нашего модуля — схемы объединятся:
Объединенные схемы:
Код модулей для Lampyre , там же вторая версия модуля без использования подключения по ssh.
Вместо заключения — коллеги, регулярно проверяйте корректность настроек своих NFS и не только.
Источник: habr.com