Прийоми безпеки командного рядка [закрито]

Командний рядок та сценарії небезпечні. Зробіть невелику помилку з rm -rf і ви потрапили у світ боляче. Плутайте додаток зі ступенем в імені бази даних під час запуску сценарію імпорту, і ви будете звільнені (якщо вони на одному сервері, що не добре, але буває). Те саме, що надто пізно помітити, що ім'я сервера, на якому ви хлюпали, - це не те, що ви думали, що це було після розробки деяких команд. Ви повинні поважати Хол-Хола .

Перед виконанням ризикованих команд у мене є кілька невеликих ритуалів - як зробити потрійну перевірку сервера, на якому я перебуваю. Ось цікава стаття про безпеку автомобілів .

Які маленькі ритуали, інструменти та хитрощі захищають вас у командному рядку? І я маю на увазі об'єктивні речі, такі як "спочатку запустіть ls foo *", подивіться на результат цього, а потім замініть ls на rm -rf, щоб уникнути запуску rm -rf foo * або чогось подібного ", а не" переконайтеся, що ви знаєте, що команда зробить ".

Добре працює це використання різних кольорів фону на оболонці для серверів prod / staging / test.

Майте на увазі план відступу, перш ніж починати.

• Скопіюйте файл / каталог, а не видаляйте його відразу
• встановіть (cisco) маршрутизатор для перезавантаження через «х» кількість хвилин і не 'wr' відразу
• переконайтеся, що інтерфейс, який ви змінюєте, не той, на якому ви ввели систему. Це може бути інтерфейс маршрутизатора, до якого ви telnet'd, або Ethernet-порт VNC'd.
• ніколи не входити як "root"
• зробити резервну копію. перевірте, чи це добре. зробити ще один.
• запитайте когось, кому ви довіряєте: "Я збираюся тут щось зробити німим?"

У мене є низькотехнологічне рішення деяких із них.

У мене з'явилася вроджена звичка робити наступні дії (коли планують працювати як root):

• Спочатку увійдіть як звичайний користувач, потім використовуйте sudo su - rootдля переходу на root. Я роблю це як розумову підготовку, нагадуючи мені, що я подумки пройшов в дуже небезпечну зону і що я повинен бути настороженим і бути під вартою весь час. Як це не дивно, але цей маленький ритуал один врятував мене безліччю горя, просто підкріпивши, що я не можу бути недбалим .
• Кожна команда вводиться, але клавіша [Return] ніколи не натискається. Ніколи .
• Жодна команда ніколи не виконується, не розуміючи , що саме вона робить. Якщо ви робите це, не знаючи, що це робить, ви граєте в російську рулетку зі своєю системою.
• Перш ніж натиснути клавішу [Return], команда, яка вибита з CLI, ретельно перевіряється оком. Якщо є якісь вагання, будь-який натяк на потенційну проблему, вона буде переглянута знову. Якщо це коливання зберігається, команду залишають у рядку, і я alt-F2 на іншу консоль, щоб переглянути сторінку сторінки тощо. Якщо в графічному сеансі я запускаю браузер і виконую деякий пошук.
• Жоден звичайний користувач ніколи не передає sudoмої системи, не тому, що я бофф , а тому, що без підготовки та навчання, це як подарувати мавпі завантажений пістолет. Спочатку весело і весело, поки мавпа не дивиться вниз по стволі і не стискається ...

При використанні rm я завжди cdспочатку перейду до каталогу, потім використовую префікс, ./щоб переконатися, що каталог правильний, тобто

cd /usr/some/directory ; rm ./targetfile

або я вказую весь шлях до файлу

rm /usr/some/directory/targetfile

що є ПДФА, але ... краще безпечно, ніж шкода.

Цей специфічний для Windows Powershell.

В якості політики ми додаємо наступні машини machine.ps1 на кожному сервері. Це гарантує істинність наступного:

1. Вікна консолі адміністратора powerhell мають темно-червоний колір фону
2. До заголовка додано адміністратора
3. Повідомлення "Попередження: Powershell працює як адміністратор". пишеться при запуску
4. Рядок заголовка з префіксом "Адміністратор:"
5. Стандартні утиліти (наприклад, сценарії корпоративних оболонок, vim та infozip) знаходяться у шляху.

$ currentPrincipal = Новий об'єкт безпеки.Principal.WindowsPrincipal ([Security.Principal.WindowsIdentity] :: GetCurrent ())
& {
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrator))
    {
        (get-host) .UI.RawUI.Backgroundcolor = "DarkRed"
        ясний-господар
        write-host "Попередження: PowerShell працює як адміністратор.` n "
    }

    $ utilities = $ null
    якщо ([IntPtr] :: розмір * 8-екв. 64)
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x64)" 
        $ utilities = "$ {env: programfiles (x86)} \ Утиліти"
    }
    ще
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x86)"
        $ utilities = "$ {env: programfiles} \ Утиліти"
    }
    if ((Test-Path $ утиліти) -and! ($ env: path -match $ utilities.Replace ("\", "\\")))
    {
        $ env: path = "$ утиліти; $ {env: path}"
    }
}

функція підказка
{
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrator))
    {
        if (! $ host.UI.RawUI.WindowTitle.StartsWith ("Administrator:"))
        {$ Host.UI.RawUI.WindowTitle = "Адміністратор:" + $ host.UI.RawUI.WindowTitle}
    }
    'PS' + $ (якщо ($ nestedpromptlevel -ge 1) {'>>'}) + '>'
}

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

Знайте, коли уникати багатозадачності.

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

Я колись встановлював систему Gentoo з іншого дистрибутива Linux, і випадково запустив досить руйнівну команду (не можу пригадати, що це за банкомат - якийсь варіант rm) в неправильній оболонці, внаслідок чого в живій системі з'явилася купа речей видалено, а не матеріали з хротуару. Відтоді я завжди робив це

export PS1="(chroot) $PS1"

всякий раз, коли я працював у межах chroot.

Перед тим, як змінити сервер, слід пам’ятати кілька важливих речей :

• Переконайтесь, що я на правильному сервері

• Будьте в курсі **, скільки людей буде зачеплене цією дією * (якщо ви помилилися чи ні)

• Перш ніж набрати клавішу "enter", пам’ятайте про можливість скасування

• Запитайте себе, чи не має ця команда відключення вашого сеансу (fw правило, неправильне відключення тощо ...). Переконайтеся, що у вас є аварійний заїзд, який потрібно повернути (особливо якщо ви не вдома)

Якщо ви цього ще не зробили, псевдонім rm -i

Правило 1 - зробити резервні копії

Правило 2 - НІКОЛИ не додайте обгортки "molly guard" до стандартних команд, переконайтеся, що ви маєте власну версію, але не переймайте це ім'я, воно просто кусає вас, коли ви перебуваєте в системі, яку ви не створили.

Підказки-підказки, як різний колір для кореневого та (часткового) дерева каталогів, - чудові помічники, але знову ж таки переконайтеся, що ви можете працювати без них.

Це може здатися протиінтуїтивним і менш "ардкоре", але найкращий підказник безпеки командного рядка, який я маю: " Якщо альтернатива режиму GUI доступна і практична, то використовуйте ІТ .

Чому? Досить просто. У режимі GUI зазвичай є вбудована мережа безпеки у вигляді "попередження - ви збираєтеся вирвати freeblefrop, ви впевнені, що хочете це зробити?" Навіть якщо ні, це сповільнює вас, надаючи більше місця для роздумів. Це дозволяє вам двічі перевірити параметри перед тим, як скористатися ними, ви можете зробити знімок екрана до і після станів, він захищає вас від помилок; всі хороші, корисні та корисні речі.

У класичному випадку жахливого "rm -rf", чи вважаєте ви, що простіше випадково оформити його з GUI чи CLI?

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

Використовуйте здоровий глузд і не виконуйте команди, яких ви не розумієте. Це все хороша порада. Якщо вам здається, що ви боліть себе, виписуючи абсолютний шлях усього, що ви проходите в rm, або керуючи чим-небудь через sudo, не соромтеся. Тоді я вважаю за краще су -с. Принаймні, він не кешує пароль. Я не відчував би себе комфортно, коли будь-якому постійному користувачеві дозволяється керувати речами з правами root без перевірки пароля.

У вашій ~ / .bashrc можна вкласти кілька речей, щоб зробити речі трохи безпечнішими, такі як:

alias srm='rm -i'

Дозволяючи вам мати безпечну альтернативу rm, ...

Але врешті-решт, можна і завжди будеш викручуватися. Днями у мене був неіснуючий скрипт конфігурації, який порушив всю папку / usr / bin, порушивши кілька речей. Так, проста система "встановити" будь-якого типу програмного забезпечення з помилкою в ньому може зламати вашу систему. Ви ніколи не безпечні, чим би ви не займалися. Що я отримую, це НАЙБІЛЬШЕ важливе:

Тримайте регулярні резервні копії.

Замість псевдоніму rm до rm -i, чи не краще було б псевдоніму сказати видалити або saferemove (і використовувати їх як бажаний інструмент видалення). Тоді, коли ви використовуєте вікно, у якого не було встановлено цього, шкоди не завдано.

Переконайтеся, що ви ніколи не запускаєте команду, яку ви знайдете в Інтернеті, якщо ви повністю не розумієте, що вони роблять.

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

Очевидною для безпеки командного рядка з точки зору Unix / Linux є правильне використання кореневого облікового запису.
Rm -rf як root, як правило, більш небезпечний, ніж як користувач, і використання вбудованих речей, таких як sudo, а не вхід у систему як root, є життєво важливим. Гарний простий віамі, як правило, допоможе при шизофренії або декількох особистостях.

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

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

Таким чином, ви все ще маєте доступ до машини і може вбити основний сеанс.

Більшість вищезазначених коментарів стосуються rm, але я зробив деякі дурні речі і з іншими командами ...

ifconfig зняти мережу - ouch, що вимагає фізичної присутності для виправлення.

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

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

Якщо ви використовуєте bash, спробуйте це:

TMOUT=600

у вашому /root/.bashrcчи подібному. Він автоматично виходить з системи через 10 хвилин, знижуючи ймовірність того, що ви перейдете на кореневий термінал, який ви випадково залишили відкритим і наберіть щось дурне.

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

# Allow only UPDATE and DELETE statements that specify key values
alias mysql="mysql --safe-updates"`

Настійно рекомендується мати псевдонім, якщо ви коли-небудь використовуєте mysql CLI.

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

Я уникаю *глобуса як власного аргументу, коли це можливо. Навіть якщо я дійсно маю на увазі "видалити все з цього каталогу", я намагаюся бути більш конкретним, тобто. rm *.php. Це запобіжний контроль пошкоджень у випадку, якщо я випадково запустив ту саму команду з історії в іншому каталозі.

Чудовий спосіб змусити вас задуматися над тим, що ви робите, - додати щось подібне до bashrc root (cshrc, що завгодно):

unset PATH

Таким чином, вам доведеться робити / bin / rm замість просто "rm". Ці зайві символи можуть змусити вас задуматися.

Для складних регулярних виразів, особливо команди 'find' ставлять відлуння попереду і захоплюють їх у файл. Тоді ви можете перевірити, чи дійсно ви видаляєте / переміщуєте / і т. Д. Саме те, що, на вашу думку, є перед тим, як виконати файл із "source".

Це також зручно для вручну додати ті крайові корпуси, які регулярно не підбирали.

Трохи мета для деяких інших публікацій: я використовую звичайні кроки echo / ls, запропоновані спочатку, щоб переконатися, що команда вибирає набір потрібних мені файлів або іншим чином інтерпретується оболонкою за призначенням.

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

Це зовсім не допомагає вводити кожну з цих команд незалежно ...

$ ls *.bak
$ echo rm *.bak
$ rm * .bak

... тому що я випадково набрав пробіл в останньому рядку та видалив усі файли. Я завжди отримував би попередній рядок і просто видаляв би ехо.

root користувач:
Dont root, якщо не потрібно.
Якщо постачальник каже, що його потрібно запускати як root, скажіть їм, що ви є клієнтом, і що ви хочете запустити його як некореневий.
Скільки програмних пакетів, що знаходяться на полиці, хочуть викорінити "просто тому, що це простіше"?

звичка:
ніколи не використовуйте "*" з видаленням, не дивлячись на це тричі. Найкраще побудувати звичку використовувати ls -l TargetPattern , а потім використовувати "rm! $". Найбільша загроза - не бути там, де ти думаєш, що ти є. Я майже набираю "ім'я хоста" так часто, як "ls"!

милиці:
стандартний підказки допомагає багато, як і псевдоніми, такі як "псевдонім rm = 'rm -i" ", але я часто не маю повного контролю над машинами, на яких я працюю, тому я використовую сценарій обгортки очікування просто для встановлення вашого шляху , підказка та псевдоніми з '-i'

знайти проблеми:
використання повного шляху допомагає, але у випадках, коли це неможливо, перейдіть на більш безпечне місце та ТАКОЖ використовуйте "&&", щоб переконатися, що "cd" вдався до того, як ви знайдете, видаліть, tar, untar, тощо:
приклад: cd /filesystema && tar cf - | ( cd /filesystemb && tar vxf -)
використання "&&" може запобігти витягуванню файлу tar на самому собі в цьому випадку (хоча в цьому випадку "rsync" було б краще)

видаляє:
ніколи не видаляйте рекурсивно, якщо можете допомогти, особливо в сценарії. знайти та видалити за допомогою -типу f та -name 'pattern' Я все ще живу, боячись подати «нічого» xargs ... tar та untar для переміщення матеріалів (замість цього використовуйте rsync)

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

Приклад: кіллалл

Linux / FreeBSD / OSX - вбиває всі процеси, що відповідають переданому параметру. наприклад: "killall apache" вбиває всіх апачів, залишаючи всі інші процеси в спокої.

Solaris - вбиває всі процеси. Насправді ні. Зі сторінки man : killall використовується shutdown (1M) для знищення всіх активних процесів, не пов'язаних безпосередньо з процедурою відключення.

Замість

rm foo*

використання

rm -i foo*

Це практично з кількома файлами, але не, скажімо, з цілим тарболом. Ось чому згладжування rmстане на ваш шлях.

Спершу запускати команду із луною - це гарна ідея, але вона все ще схильна до помилок.

Спробуйте використовувати його з розширенням, таким як! $.

echo foo*
rm -rf !$

! $ Розширюється на останнє слово останньої команди, тому воно еквівалентно

echo foo*
rm -rf foo*

Є також! *, Який розширюється на всі аргументи до останньої команди.

Дійсно, ви могли б зробити це так, якщо хочете

echo rm -rf foo*
!*

(Якщо ви використовуєте ksh, а не bash, ви можете ввести Esc + period, щоб вставити останнє слово замість цього.)

У разі чогось подібного:

ls * .php
echo rm * .php
rm * .php

Ви можете використовувати оператор підстановки, як-от так:
$ ls * .php
<dir listing>

$ ^ ls ^ echo rm (це замінює ls у попередній команді echo rm, зберігаючи решту командного рядка однаковим)

$ ^ echo rm ^ rm (замініть echo rm просто rm, таким чином, вам не доведеться повторно вводити * .php і викидати пробіл у неправильний час)

^ = shift-6, для тих, хто з ним не знайомий.

Використовуйте bash і встановіть PS1 = '\ u @ \ h: \ w>'. Це поширюється на ім'я користувача @ ім'я хоста: / full / working / каталог / path> Як зазначено в інших відповідях, ви можете використовувати очікувати, щоб створити середовище кожного разу, коли ви не можете оновити файли .profile або .bash_profile. Зміна кольорів фону - найкраща відповідь, хоча :-)

Ага так. Цей віковий трюк надсилати комусь файл через IRC під назвою "-rf", щоб він опинився в їх ~ каталозі. Пізніше один "rm -rf" (замість "rm - -rf") і багато сміху виникли, коли вони засвоїли суворий урок про те, як IRC не працює як root.

Замість того щоб використовувати rm -rf <dir>поставити -rfв кінці приблизно так: rm <dir> -rf. Подумайте про це як про те, щоб зняти безпеку після того, як ви націлилися і перед тим, як стріляти. Таким чином ви захищені, якщо під час введення імені каталогу (або за допомогою заповнення вкладки) у вас є ковзання клавіші "введення" і у вас є аналогічні каталоги.