Чи може адміністратор сервера бачити, що я копіюю через SCP?


31

Скажіть, я підключаюся до сервера через SCP і копіюю деякі файли з віддаленого сервера на свій домашній комп'ютер. Чи можуть адміністратори сервера сказати, що я щось скопіював, побачити, що було скопійовано, чи знати, хто це скопіював?


2
використання sftp. Це може бути зафіксовано, але це не чітко видно як назву процесу scp.
Jakuje

2
Мабуть, лише питання про зміну рівня журналу на сервері? Не перевірив.
jcaron

14
Я б завжди припускав, що все пильно стежать і реєструються, якщо ви не контролюєте суворість.
axk

3
Серверні адміністратори можуть бачити все, що ви робите на своєму сервері; це якось мається на увазі під терміном "адміністратор". Питання лише в тому, чи дійсно вони звертають увагу чи турботу.
Ajedi32

Відповіді:


31

Питання ServerFault майже ідентичне цьому. Сподіваємось, ви перевірили, перш ніж розміщувати своє запитання, але ваше трохи інше, тому я відповім тут.

Коротка відповідь полягає в тому, що якщо БУДЬ-ЯКОЙ має доступ і дозволи до кінцевої точки (система, з якої ви перебуваєте scpабо scpз якою), вони можуть бачити, що відбувається. Якщо вони не мають доступу до жодної кінцевої точки, вони, ймовірно, не матимуть доступу до або зможуть розшифрувати те, що ви робите (крім потенційного знання програми за номерами протоколів).

Відповідь, в кінцевому рахунку, дуже залежить від вашої інфраструктури. Швидше за все, до тих пір, поки в компанії не буде інтенсивного моніторингу і SCP не вважається загрозою (що викине червоні прапори), ваш трафік буде проходити непомітно. Особливо це стосується менших компаній.

Як @SimonRichter згадувалося : якщо хто - то може виконати команду на вашій системі (т. Е адміни або інші), вони можуть перевірити список процесів і побачити командний рядок scp -args /filepath/. Однак це вимагає, щоб вони або реєстрували всю активність процесу, або перевіряли її під час передачі. Крім того, якщо ви робите це з власної системи на роботі до іншої системи (скажімо, вдома чи в іншому місці), вони не обов'язково матимуть таку видимість.

Крім того, як зазначає @ alex.forencich: Також можна реєструвати всі системні виклики (включаючи відкриті та читання викликів файлів), тому навіть якщо ваша програма копіювання (scp, sftp тощо) нічого не записує та не протікає (аргументи командного рядка ), все ж можна з’ясувати, які файли читали чи писали. Дивіться систему аудиту linux. -


Можна також реєструвати всі системні виклики (включаючи відкриті та читання викликів файлів), тому навіть якщо ваша програма копіювання (scp, sftp тощо) нічого не записує та не протікає (аргументи командного рядка), це все-таки можна зрозуміти які файли були прочитані чи записані. Дивіться систему аудиту linux.
alex.forencich

Дякую @ alex.forencich, я додаю ваш коментар до відповіді!
Абраксас

33

Не тільки адміністратор.

Для тестування я просто скопіював /binіз свого сервера тимчасовий каталог свого ноутбука. psна сервері показує

$ ps 24096
  PID TTY      STAT   TIME COMMAND
24096 ?        Ss     0:00 scp -r -f /bin

Ця інформація загальнодоступна для всіх користувачів.


6
Для ядра> = 3.2, (повторне) встановлення /procз опцією hidepid=2вимикає це ..
heemayl

"Ця інформація загальнодоступна для всіх користувачів." Так, справді? Усі користувачі можуть бачити, що роблять всі інші користувачі? Я не пробував цього, але це здається мені малоймовірним. Навіть у Windows ви можете бачити лише власні процеси (якщо ви не адміністратор і не натискаєте спеціальну кнопку адміністратора).
Гонки легкості з Монікою

@PreferenceBean, так, але це налаштування за замовчуванням. Залежно від того, як адміністратор встановив налаштування umask , домашні каталоги інших людей можуть бути читаними також за замовчуванням.
Саймон Ріхтер

Подання такої інформації про іншого користувача, як це, звучить як дуже тупий за замовчуванням.
CodesInChaos

@CodesInChaos - це давнє рішення, прийняте на той час, коли людям доводилося спільно ділитися комп'ютером, тому найкраще, якщо ви могли легко сказати, хто бовтає процесор і чому, щоб ви могли поговорити з ними. У ці дні ніхто взагалі не заважає, тому що дуже мало людей насправді входять у загальні комп'ютери.
Саймон Ріхтер

12

scpпрацює за допомогою коду, який працює на сервері ( sshdі scpсам). Цей теоретичний код теоретично повністю знаходиться в управлінні адміністратором сервера, і версія scpзапущеної на сервері для запису файлу підключення до вас є окремою від версії, scpзапущеної на вашій машині для видачі запиту.

Адміністратор сервера може, лише для прикладу, замінити scpна сервері версію, яка реєструє всі запити, а не як веб-сервер може писати журнали. Тоді вони могли побачити з цих журналів саме те, що ви скопіювали.

Чи є у них досвід та мотивація насправді зробити це менш визначено, але якщо вони хочуть, то в принципі нічого не може зупинити їх.

Я думаю, що ці питання є супутниками вашого: https://security.stackexchange.com/questions/14782/is-there-an-easy-way-to-see-a-log-of-scp-activity-on-a -server-ala-var-log-secu , https://askubuntu.com/questions/659896/where-would-you-find-scp-logs

Хоча я не знаю всіх подробиць, здається, що прямо з коробки немаєscp і sshd не має можливості ввійти в те, що ви просите. Тому, можливо, потрібно більше, ніж проста конфігурація, але ви не можете відійти від того, що адміністратори керують сервером.


10

Все, що проходить незашифровано через пам'ять комп'ютера, може прочитати або змінити достатньо привілейований користувач на цій машині.

Назви запущених процесів та командний рядок, що використовується для їх запуску, доступні будь-якому користувачеві, який увійшов у систему в Linux. (Це не так у Windows для допитливих людей.) Тому адміністратор чи хтось, хто трапляється, може бачити, які файли ви скопіювали. Крім того, цілком можливо, що адміністратор налаштував якийсь журнал доступу до файлів або замінив / змістив scpпрограму на одному кінці, щоб зробити додатковий журнал.

scpпросто захищає вас від мережевих нюхань. Очевидно, що обидва кінці повинні знати розшифровані дані, тому є можливість складного адміністратора на будь-якій з кінцевих точок витягнути дані з scpпам'яті. Для цього відкриті й інші рішення, навіть ті, що не включають командні рядки: обидва кінці sftpзнають, що відбувається, тому за допомогою перевірки пам’яті можна визначити, що sftpмислення / передача.


6

Основне правило полягає в тому, що людина з кореневим доступом може знати все (якщо йому можуть завадити перевірити). Напевно, єдине, що не має обмежень - це файлова система, зашифрована сертифікатами.

під час акта scpвідкриває процес на віддаленій стороні, який може побачити будь-хто лише за допомогою виклику ps. Якщо вам вдасться приховати командний рядок, який відображається у списку процесів, тоді lsof(список відкритих файлів) можна показати, які файли торкаються. Це так просто, я фактично це роблю, щоб спостерігати, наскільки я починаю якийсь процес копіювання, якщо я запустив процес на терміналі, я не можу переглянути на даний момент (де виводиться список файлів).

після акту швидке сканування за допомогою findможе знайти новіші файли (якщо часові позначки не зберігалися під час копіювання). Якщо ви можете отримати доступ до файлів або доторкнутися будь-яким способом через sshсеанс, ви .bash_historyпоказуєте, що ви робили (але ви можете видалити це, якщо хочете).

Якщо безпека мала бути дуже суворою, ви завжди можете встановити додатковий моніторинг: ви можете прослуховувати всі модифікації файлів за допомогою простого демона, а також реєструвати все про транзакції файлової системи, локальні та віддалені, не має значення. Не було б сюрпризом, щоб записати всі створені користувачем процеси . Якщо робиться резервне копіювання, файли можуть зберігатися десь після їх видалення.


Коли ви писали file, ви мали на увазі find?
CVn

1

Адміністратори сервера можуть відстежувати будь-який трафік, який прямує на сервер або з нього, так що вони могли б легко відслідковувати трафік SCP, якщо хотіли, і бачити, що ви скопіювали файли та файли, які ви скопіювали.


"що ви скопіювали файли" сильно відрізняється від "того, що я копіюю", як зазначено в ОП.
CVn

вони також можуть це бачити
Мішель Джонсон,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.