Чи можна запобігти SCP, поки все ще дозволяють SSH доступ?

Використовуючи сервери Solaris та Linux та OpenSSH, чи можна запобігти користувачам копіювати файли за допомогою "scp", одночасно дозволяючи доступу до оболонки з "ssh"?

Я розумію, що доступ до файлу 'ssh $ server "cat file"' набагато складніше запобігти, але мені потрібно довідатися про зупинку "scp" для початківців.

Якщо цього не зробити, чи є спосіб надійно зареєструвати весь доступ SCP на стороні сервера syslog?

У той час як ви можете редагувати свої зображення, /etc/ssh/sshd_configщоб виглядати приблизно так:

ForceCommand           /bin/sh
PermitOpen             0.0.0.0
AllowTcpForwarding     no
PermitTunnel           no
# Subsystem sftp       /usr/lib/openssh/sftp-server
PermitUserEnvironment  no

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

AllowUsers             root
PermitRootLogin        forced-commands-only

PermitUserEnvironment  no

AllowTcpForwarding     no
PermitTunnel           no

# Subsystem sftp       /usr/lib/openssh/sftp-server
Subsystem smb-reload   /usr/bin/smbcontrol smbd reload-config
Subsystem status       /opt/local/bin/status.sh

ssh root@example -s smb-reload

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

Як зазначали інші, ви не можете заблокувати scp (ну, ви могли:, rm /usr/bin/scpале це насправді нікуди не потрапляє).

Найкраще, що ви можете зробити, це змінити оболонку користувачів на оболонку з обмеженими можливостями (rbash) і лише потім виконувати певні команди.

Пам'ятайте, якщо вони можуть читати файли, вони можуть скопіювати / вставити їх з екрана. Бінарні файли? xxd / uuencode / mmencode - це усе обійти.

Я б також запропонував використовувати облік процесів, щоб допомогти вам відстежувати активність.

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

Тепер розумний механізм лісозаготівлі був би непоганим Можливо, аудит нарешті працює в Linux. Можливо, Solaris нарешті додав якийсь механізм, або dtrace можна було б використовувати безпечно. Доцільно бажати, щоб ОС реєструвалась кожного разу, коли доступ до файлу. Звичайно, різниці між "читанням" і "копіюванням" немає. Але це може задовольнити аудитора і надати значну безпеку системі. Ваші журнали можуть бути настільки галасливими, що дані марні, або навіть, що ви змушені тримати смішно короткий слід аудиту. (наприклад, ви не можете реєструвати кожне прочитане () - і одна програма, яка робить щось дивовижне, може зробити журнал кожного відкритого () катастрофою).

Залежно від того, для чого потрібен SSH, ви можете досягти цієї мети (для нетривіальних) файлів, використовуючи IPTables для припинення сеансів, якщо розмір пакета більший, ніж, скажімо, 1400 байт. Це означає, що інтерактивний ssh ​​здебільшого спрацює, але як тільки щось спробує надіслати 1500-байтний пакет - схожий scp повинен мати файл, більший ніж 1499 байт, припускаючи стандартний MTU 1500, він припинить з'єднання.

Це також запобіжить нападу, який ви згадуєте.

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

У найпростішому випадку команда зробити це може виглядати приблизно так

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff -j DROP

Ми можемо покращити цю роботу, комбінуючи перевірки довжини пакету з ipt_recent, так що ви дозволяєте обмеженій кількості пакетів перевищувати 1400 байтів у встановлені часові рамки (скажімо, 8 пакетів за 5 секунд) - це дозволить пакетам до 12 к прослизати через, але може надати вам інтерактивність, яка вам знадобиться для редагування файлів тощо. Ви, звичайно, можете налаштувати кількість пакетів.

Це може виглядати приблизно так

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --set 
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --update --seconds 5 --hitcount 8 \
         -j REJECT --reject-with tcp-reset

Наведені вище приклади правил захищають лише від завантаження scp, таких як scp myfile.data remote.host:~. Для додаткового захисту, наприклад scp remote.host:~/myfile.data /local/path, повторіть наведені вище правила, але замініть --dportна --sport.

Хитрий хакер може обійти ці обмеження, встановивши MTU менше 1400 на своїй машині (або примушуючи mtu чи подібне). Крім того, хоча ви не можете обмежити це певними користувачами, ви можете обмежити його IP, змінивши рядки iptables відповідно до !!

Ура, Девід Гоу

Ваша найкраща ставка - не блокувати scp, а використовувати файлову систему з ACL, щоб запобігти доступу до читання. Можливо, ви можете зробити щось із SELinux, щоб запобігти читанню певних програм із певних файлів.

Ні, scpі sshпрацювати на тих же портах і використовувати той самий протокол. Якщо ви відкриєте sshсеанс, ви навіть можете поділитися своїм зв’язком з наступними scp-дзвінками, використовуючи такі параметри, як ControlMaster.

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

Існує спосіб використовувати "scponly" як оболонку, щоб відключити інтерактивний ssh ​​і дозволити scp, але я не знаю нічого існуючого, що працює в зворотному порядку.

Можливо, ви зможете дослідити злом оболонки scponly, щоб досягти зворотного.

Це неможливо насправді після невеликого гуглення.

Перегляньте цю дискусію: http://www.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

Для чого комерційний продукт CryptoAuditor стверджує, що він може контролювати передачу файлів через SSH, використовуючи MITM підключення та використовуючи глибоку перевірку пакетів . Очевидно, що жодне рішення не є безпечним від копіювання + вставки, uuencode / декодування, FISH тощо. Приємно, що воно прозоре (окрім ймовірних помилок сертифікату); не існує програмного забезпечення агента для встановлення на будь-якому кінці з'єднання SSH, і немає порталу / проксі для налаштування.

Я не користувався продуктом, тому YMMV.

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

Тож я замість цього сфокусуюся на вашій альтернативній реєстрації:

Існує програма під назвою "скрипт", яка включена практично в кожен дистрибутив, і яку слід легко встановити на ті, де її немає. Це реєстратор сеансу, який записує всі вхідні та вихідні дані з оболонки, необов'язково з даними про час, щоб вони могли відтворюватися і виглядати так, як ви спостерігали через плече користувача, коли вони це робили. (95% у будь-якому випадку, вона час від часу болтирує результат, коли бере участь ncurses, але не дуже часто.)

Сторінка "man" містить вказівки щодо встановлення її як оболонки для входу в систему. Переконайтеся, що журнали кудись переходять, що користувач не може просто видалити їх (атрибут файлової системи, що додається (встановлений через chattr), може бути корисним для цього. Як і ACL або ініціювати сценарії)

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

Я вважаю, що ви можете видалити на сервері openssh-клієнтів (або еквівалент).

Я думаю, що клієнт scp викликає scp на сервері під час копіювання даних, тому якщо ви позбудетесь від scp на сервері, то вам слід добре.

$ scp bla server:/tmp/
...
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.utf8
debug1: Sending env LANG = en_US.utf8
debug1: Sending env XMODIFIERS = @im=ibus
debug1: Sending env LANGUAGE = en_US.utf8
debug1: Sending command: scp -v -t /tmp/
bash: scp: command not found
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
lost connection