Заблокировать скачивание с samba

Даже если samba отличает как-то, в чём я сомневаюсь, открытие файла с диска от копирования этого же файла - никто не запрещает в таком случае сделать dd.

В рамках допуска твоей гипотезы, что открытие файла в программе отличается от копирования - поведение в случае dd будет равнозначно открытию файла в программе.

Использование dd не доступно. Подразумевается, что Пользователь подключен smb клиентом.

При чем тут dd? Самба (как сервис, как демон) — прослойка между файловой системой и сетью, через которую к самбе ломится юзер.

Человек спрашивает: можно ли так наконфижить самбу?

Нет нельзя. С точки зрения файловых операций и inotify всё будет одинаково.

Единственное отличие - если файл большой, допустим pdf или видео файл и в программе нет докачки / кэширования - будут 3 операции

fopen
fread
fclose

В случае открытия в программе просмотра, читающей порциями по мере прокрутки, будет:

fopen
fread - много небольших порций чтения
fread - много небольших порций чтения
fread - много небольших порций чтения
fread
fread
fclose

Если файл небольшой или программа в любом случае дочитывает в память - будет так же 3 операции.

В случае копирования будет

fopen
fread одной операцией до конца
fclose

Подразумевается, что Пользователь подключен smb клиентом.

Если ты говоришь про какое-то ПО, т.е. программу, которая сама подключает через библиотеку к samba - это одно.

А если ты говоришь, что сетевой ресурс смонтирован на Linux или подключен как диск в Windows - то никто не запрещает использовать dd

dd if=/mnt/samba/file.pdf of=~/file.pdf

При чем тут dd? Самба (как сервис, как демон) — прослойка между файловой системой и сетью, через которую к самбе ломится юзер.

И что?

Я говорю о том, что самба, как прослойка, может иметь возможность отслеживать разницу между тем, кто по сетке к файлу ломится самба-клиентом к этой самой самбе, а кто напрямую файловой системой шабуршит ))

кто по сетке к файлу ломится самба-клиентом, а кто напрямую файловой ситемой шабуршит

И в чём по твоему будет отличие с точки зрения samba?

Если ты знаешь путь до файла на сетевом ресурсе и открываешь его сразу в программе или вызываешь копирование файла командой cp / copy / dd / rsync / cat в файл у себя локально - будет 3 операции

fopen full_path
fread full_path
fclose full_path

full_path - полный путь до файла на сетевом ресурсе samba.

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

Других отличий не будет.

Программа работает не напрямую с samba, а точно так же через драйвер cifs / smb, как будет работать и файловый менеджер и с точки зрения samba тут разницы нет.

Включи логирование в samba и посмотри как открывается файл в программе и как при копировании.

И вообще, даже если ты как-то закроешь доступ на копирование, но открываться в программе файл должен.

То кто пользователю запретит сделать «File -> Save As» и сохранить локально к себе?

https://0x0.st/P9Cw.png

Оно тебя боится ))

С т.з. сервера это будет чтение данных в обоих случаях.
В CIFS предусмотрены отдельные запросы только для server-side копирования/перемещения (для оптимизации, когда исходник и копия на одном сервере, но клиент не обязан их использовать).

Т.о. отслеживания копирования тебе нужно вести не на сервере, а на клиенте. Например сделать так, чтобы клиент, имеющий доступ к файловому серверу был VM, работающей на твоих же серверах, с доступом только через RDP/VNC и т.п. Это не исключит полностью утечку данных, но заметно осложнит ее.

Клиенты Windows. Потенциальное решение. Используя powershell включить отслеживание событий аудита файловой системы и отслеживать журнал аудита. Точка изучения Включаем аудит доступа к папкам и файлам в Windows

Ну и что ты там будешь отслеживать, все события записи на локальную ФС клиента? А потом пытаться их как-то связать с данными на файловом сервере? Ну-ну :))
Если все клиентские устройства, имеющие доступ к файловому серверу, физически находятся в «защищаемом» периметре, то какая разница скопирован туда файл или нет?

Сформулируй более конкретно, от какой угрозы ты защищаешься.

Стоп стоп стоп, ты поставил вопрос, как на самба отследить.

Т.е. ты хочешь серверное решение, без перенастройки клиентов.

Отследить целенаправленное копирование файлов, а не открытие файла приложением с сетевого диска

Штирлиц открыл приложением файл с сетевого диска и нажал ctrl+s.

Да, серверное. Но мои собственные изыскание привели меня к тем же суждениям, что изложены вдоль комментариев в этой теме.

Единственный способ, который не даст пользователю за ПК скопировать или сохранить файл - использование kiosk mode в DE и приложение, которое открывает файл на просмотр и в котором отключены функции меню для сохранения файла.

И для безопасности - ещё функция печати на физический принтер или печати на виртуальный принтер PDF.

Seamless Terminal Server

не получится копирование/сохранение на локальный комп.

Нужно, чтобы ещё локальные принтеры клиента RDP или иного терминального сервера не пробрасывались в терминальную сессию.

Иначе распечатать файл в проброшенный PDF принтер возможно или проброшенный физический принтер.

Это ты уже говорил

Это легче, поэтому не упомянул

Проблему XY вижу я.

Тебе аудит надо на самой самбе включить ну или настроить аудит доступа smbd к файлам на уровне подсистемы аудита линукс (второй вариант если самба форкает процесс для каждого юзера с его ID).

Активировал сервис аудит Файловой системы. Добавил контроль на «C:\install». Создал файл «Лист Microsoft Excel.xlsx» Вырезал, Вставил:

4663	03/21/2026 09:58:09	admin1	C:\install	ReadData (or ListDirectory)
4663	03/21/2026 09:58:09	admin1	C:\install	ReadAttributes
4663	03/21/2026 09:58:09	admin1	C:\install	ReadData (or ListDirectory)
4663	03/21/2026 09:58:09	admin1	C:\install	ReadAttributes
4663	03/21/2026 09:58:09	admin1	C:\install\Лист Microsoft Excel.xlsx	DELETE
4663	03/21/2026 09:58:09	admin1	C:\install\Лист Microsoft Excel.xlsx	ReadAttributes
4663	03/21/2026 09:58:09	admin1	C:\install\Лист Microsoft Excel.xlsx	READ_CONTROL
4663	03/21/2026 09:58:09	admin1	C:\install\Лист Microsoft Excel.xlsx	DELETE
4663	03/21/2026 09:58:09	admin1	C:\install\Лист Microsoft Excel.xlsx	ReadAttributes
4663	03/21/2026 09:58:09	admin1	C:\install	ReadData (or ListDirectory)
4663	03/21/2026 09:58:08	admin1	C:\install\Лист Microsoft Excel.xlsx	READ_CONTROL
4663	03/21/2026 09:58:08	admin1	C:\install\Лист Microsoft Excel.xlsx	READ_CONTROL
4663	03/21/2026 09:58:08	admin1	C:\install	READ_CONTROL
4663	03/21/2026 09:58:08	admin1	C:\install	READ_CONTROL
4663	03/21/2026 09:58:08	admin1	C:\install	READ_CONTROL

И что ты хочешь эти сказать? :)
Злоумышленник может например просто zip-архивировать документ с файлового сервера. В итоге у тебя будет в лучшем случае запись в security log на файл с другим именем (и другим sha256).

Если тебе нужно просто отслеживать, не хранят ли пользователи копии важных документов с файлового сервера на своих рабочих станциях, то можно реализовать некий краулер по ФС (на стороне клиентов), который будет сравнивать хеши всех файлов с заранее известным списком.