Назад | Перейти на главную страницу

Уловки безопасности в командной строке

Командная строка и сценарии опасны. Сделайте небольшую опечатку с помощью rm -rf, и вы попадете в мир боли. При запуске скрипта импорта путайте prod со стадией в имени базы данных, и вы попадаете в зависимость (если они находятся на одном сервере, что нехорошо, но случается). То же самое, если вы слишком поздно заметили, что имя сервера, на котором вы сбрасываете, не то, что вы думали после запуска некоторых команд. Вы должны уважать Hole Hawg.

У меня есть несколько небольших ритуалов перед запуском рискованных команд - например, тройная проверка сервера, на котором я работаю. Вот интересная статья о безопасности rm.

Какие маленькие ритуалы, инструменты и уловки помогут вам в безопасности в командной строке? И я имею в виду объективные вещи, такие как «сначала запустите ls foo *, посмотрите на вывод, а затем замените ls на rm -rf, чтобы избежать запуска rm -rf foo * или чего-то подобного», а не «убедитесь, что вы знаете, что команда сделает ".

unix command-line-interface

Один, который хорошо работает, - это использование разных цветов фона в вашей оболочке для серверов prod / staging / test.

Прежде чем начать, составьте план выхода из ситуации.

Заархивируйте файл / каталог вместо того, чтобы сразу удалять его
установите маршрутизатор (cisco) на перезагрузку через 'x' минут и не пишите сразу
убедитесь, что интерфейс, который вы меняете, не тот, на котором вы вошли в систему. Это может быть интерфейс маршрутизатора, к которому вы подключены по telnet, или порт Ethernet, к которому подключен VNC.
никогда не входите как "root"
сделайте резервную копию. проверьте, что это хорошо. сделай еще один.
спросите кого-нибудь, кому вы доверяете: «Я собираюсь сделать здесь что-нибудь глупое?»

Это относится к Windows Powershell.

В качестве политики мы добавляем следующий профиль машины profile.ps1 на каждый сервер. Это гарантирует, что верно следующее:

Окна консоли администратора PowerShell имеют темно-красный цвет фона
Администратор добавлен в заголовок
Сообщение «Предупреждение: Powershell работает от имени администратора». пишется при запуске
Строка заголовка имеет префикс «Администратор:».
Стандартные утилиты (например, корпоративные сценарии оболочки, vim и infozip) находятся в пути.

$currentPrincipal = New-Object Security.Principal.WindowsPrincipal( [Security.Principal.WindowsIdentity]::GetCurrent() )
& {
    if ($currentPrincipal.IsInRole( [Security.Principal.WindowsBuiltInRole]::Administrator ))
    {
        (get-host).UI.RawUI.Backgroundcolor="DarkRed"
        clear-host
        write-host "Warning: PowerShell is running as an Administrator.`n"
    }

    $utilities = $null
    if( [IntPtr]::size * 8 -eq 64 )
    {
        $host.UI.RawUI.WindowTitle = "Windows PowerShell (x64)" 
        $utilities = "${env:programfiles(x86)}\Utilities"
    }
    else
    {
        $host.UI.RawUI.WindowTitle = "Windows PowerShell (x86)"
        $utilities = "${env:programfiles}\Utilities"
    }
    if( (Test-Path $utilities) -and !($env:path -match $utilities.Replace("\","\\")) )
    {
        $env:path = "$utilities;${env:path}"
    }
}

function Prompt
{
    if ($currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
    {
        if( !$host.UI.RawUI.WindowTitle.StartsWith( "Administrator: " ) )
        { $Host.UI.RawUI.WindowTitle = "Administrator: " + $host.UI.RawUI.WindowTitle }
    }
    'PS' + $(if ($nestedpromptlevel -ge 1) { '>>' }) + '> '
}

У меня есть простые решения для некоторых из них.

У меня выработалась врожденная привычка делать следующее (планируя работать как root):

Сначала войдите в систему как обычный пользователь, затем используя sudo su - root переключиться на root. Я делаю это как мысленную подготовку, как напоминание мне о том, что я мысленно вошел в очень опасную зону и что я должен всегда быть начеку и настороже. Как это ни смешно звучит, только этот небольшой ритуал избавил меня от множества горя, просто усилив это Я не могу быть беззаботным.
Каждая команда набрана, но клавиша [Return] никогда нажал. Никогда.
Нет команды Когда-либо выполнен без понимания именно что оно делает. Если вы делаете это, не зная, что это делает, вы играете Русская рулетка с вашей системой.
Перед при нажатии клавиши [Return] команда, введенная в CLI, внимательно просматривается на глаз. Если есть какие-либо сомнения, любой намек на потенциальную проблему, он снова исследуется. Если это колебание сохраняется, команда остается в строке, и я нажимаю Alt-F2 на другую консоль для просмотра страниц руководства и т. Д. В графическом сеансе я запускаю браузер и выполняю поиск.
Ни один обычный пользователь никогда не передается sudo в моих системах, не так как Я BOFHНо потому что без подготовки и обучения это все равно, что дать заряженное ружье обезьяне. Поначалу это забавно и весело, пока обезьяна не смотрит в бочку и не сжимает ...

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

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

или указываю полный путь к файлу

rm /usr/some/directory/targetfile

который является PITA, но ... лучше перестраховаться, чем сожалеть.

Я могу согласиться со всеми приведенными выше ответами, но я должен подчеркнуть этот очень, очень важный совет:

Знайте, когда следует избегать одновременного выполнения нескольких задач.

Там есть несколько важные вещи необходимо знать перед изменением сервера:

Убедитесь, что я на правильном сервере
Помните, ** сколько людей будут затронуты этим действием * (если вы сделаете ошибку или нет)
Прежде чем нажимать клавишу ввода, обратите внимание на возможность отменить
Спросите себя, есть ли у этой команды потенциал отключение вашей сессии (правило fw, плохое выключение и т. д.). Убедитесь, что у вас есть резерв, чтобы вернуться (особенно, если вы находитесь вне офиса)

Я удостоверяюсь, что имя хоста системы, в которой я нахожусь, указано в приглашении bash (или другой оболочки). Если я chrooted, я удостоверяюсь, что это тоже каким-то образом попадет туда.

Однажды я устанавливал систему Gentoo из другого живого дистрибутива Linux и случайно запустил довольно деструктивную команду (не могу вспомнить, что это было за ATM - какой-то вариант rm) в неправильной оболочке, что приведет к удалению множества вещей в живой системе, а не из chroot. С тех пор я всегда делал

export PS1="(chroot) $PS1"

всякий раз, когда я работал в chroot.

Это может показаться нелогичным и менее "ardkore", но лучший совет по безопасности командной строки, который у меня есть: Если альтернативный режим GUI доступен и практичен, то ИСПОЛЬЗУЙТЕ ЭТО.

Зачем? Довольно просто. GUI-режим обычно имеет встроенную сетку безопасности в виде «предупреждения - вы собираетесь замолчать freeblefrop, вы уверены, что хотите это сделать?» Даже если нет, это замедляет вас, оставляя больше времени для размышлений. Это позволяет вам более легко перепроверить параметры, прежде чем переходить к ним, вы можете делать снимки экрана до и после состояний, это защищает вас от опечаток; все хорошее, полезное и полезное.

Как вы думаете, в классическом случае ужасного "rm -rf" проще случайно запустить его из графического интерфейса или интерфейса командной строки?

В конце концов, нет ничего постыдного в использовании графического интерфейса пользователя. Это не обязательно предотвратит крупные бедствия; в графическом интерфейсе так же возможно быть счастливым триггером, как и в интерфейсе командной строки; но если он однажды спасет вас, то доказал свою ценность.

Правило 1 - делайте резервные копии

Правило 2 - НИКОГДА добавьте обертки "молли гвардии" к стандартным командам, создайте свою собственную версию, конечно, но не забирайте имя, это просто укусит вас, когда вы будете в системе, которую вы не настраивали.

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

Если вы еще этого не сделали, используйте псевдоним от rm до rm -i

Вместо псевдонима rm на rm -i, не лучше ли использовать псевдоним, чтобы сказать remove или saferemove (и использовать их в качестве предпочтительного инструмента удаления). Затем, когда вы используете коробку, на которой не было этой настройки, повреждений не будет.

Используйте здравый смысл и не запускайте непонятные команды. Это хороший совет. Если вы чувствуете, что хотите мучить себя, записывая абсолютный путь всего, что вы передаете в rm, или запускаете что-либо через sudo, не стесняйтесь. Тогда я бы предпочел su -c. По крайней мере, он не кэширует пароль. Мне было бы неудобно, если бы обычному пользователю было разрешено запускать что-то с правами root без проверки пароля.

Есть несколько вещей, которые вы можете добавить в свой ~ / .bashrc, чтобы сделать вещи немного более безопасными, например:

alias srm='rm -i'

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

Но, в конце концов, вы можете и всегда будете ошибаться. На днях у меня был несуществующий скрипт configure, который уничтожил всю мою папку / usr / bin, нарушив несколько вещей. Да, простая установка любого типа программного обеспечения с ошибкой может привести к поломке вашей системы. Вы НИКОГДА не в безопасности, что бы вы ни делали. Я имею в виду САМОЕ важное:

Регулярно делайте резервные копии.

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

Настоятельно рекомендуется иметь псевдоним, если вы когда-нибудь будете использовать mysql CLI.

Если вы используете bash, попробуйте следующее:

TMOUT=600

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

Да, я знаю, что вам следует использовать sudo для выполнения команд root - это просто дополнительная подстраховка на случай, если вы однажды решите сыграть в нее рискованно.

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

Таким образом, у вас по-прежнему будет доступ к машине и вы сможете завершить основной сеанс.

Большинство приведенных выше комментариев относятся к rm, но я проделал некоторые глупости и с другими командами ...

ifconfig для отключения сети - ой, это требует физического присутствия для исправления.

Что касается скриптов, я обычно работаю в двух окнах. Первый я использую для написания сценария, второй - для проверки каждой строки по мере ее написания. Работая медленно и осторожно, я могу убедиться, что каждая строка работает так, как я ожидал, когда я пишу код, заботясь о сохранении тех же переменных и т. Д.

Лично я не считаю, что дополнительные подсказки для таких вещей, как rm -i, действительно помогают. Я совершаю большинство своих ошибок, когда v. Устаю, в стрессе и т. Д., А это те моменты, когда я просто выхожу из себя и все равно игнорирую подсказку. Возможно, плохая практика.

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

Это и добавление эха к любым командам изменения файла, особенно если вы хотите убедиться, что у вас есть правильное совпадение глобуса или регулярного выражения.

Убедитесь, что вы никогда не запускаете команды, которые найдете в сети, если вы полностью не понимаете, что они делают.

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

Если вы используете несколько вариантов операционной системы, очень осознавать различия в синтаксисе; то, что достаточно безопасно для одного варианта unix, чрезвычайно опасно для другого.

Пример: killall

Linux / FreeBSD / OSX - убивает все процессы, соответствующие переданному параметру. например: «killall apache» убивает все apache, оставляя все остальные процессы в покое.

Солярис - убивает все процессы. Нет, правда. Из страница руководства: killall используется функцией shutdown (1M) для уничтожения всех активных процессов, не связанных напрямую с процедурой завершения работы.

пользователь root:
Не пользуйтесь root, если вам не нужно.
Если поставщик говорит, что он должен работать как root, сообщите им, что вы являетесь клиентом и хотите запустить его как не root.
Сколько программных пакетов на полке хотят получить root «просто потому, что это проще»?

привычка:
никогда не используйте '*' с командой remove, не взглянув на нее три раза. Лучше выработать привычку использовать ls -l TargetPattern, затем используйте 'rm! $'. Самая большая угроза - не там, где вы думаете. я почти введите hostname так часто, как ls!

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

найти проблемы:
использование полного пути помогает, но в тех случаях, когда это невозможно, cd в более безопасное место и ТАКЖЕ используйте '&&', чтобы убедиться, что 'cd' завершится успешно, прежде чем вы выполните поиск, удаление, tar, разворачивание и т. д .:
пример: cd /filesystema && tar cf - | ( cd /filesystemb && tar vxf -)
использование '&&' может предотвратить извлечение tar-файла поверх самого себя в этом случае (хотя в этом случае 'rsync' было бы лучше)

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

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

Но затем я использую функции редактирования истории команд оболочки, чтобы получить предыдущую команду, и модифицировать только те части, которые нужно изменить.

Совершенно не помогает вводить каждую из этих команд независимо ...

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

... потому что я случайно набрал пробел в последней строке и удалил все файлы. Я всегда извлекал предыдущую строку и просто удалял «эхо».

Для сложных регулярных выражений, особенно команд поиска, помещают эхо вперед и записывают их в файл. Затем вы можете убедиться, что вы действительно удаляете / перемещаете / и т. Д. Именно то, что вы думаете, прежде чем запускать файл с «исходным кодом».

Это также удобно для добавления вручную тех крайних случаев, которые регулярное выражение не улавливает.

Отличный способ заставить вас задуматься о том, что вы делаете, - это добавить что-то вроде этого в корневой каталог bashrc (cshrc, что угодно):

unset PATH

Таким образом, вы должны использовать / bin / rm вместо просто «rm». Эти лишние символы могут заставить вас задуматься.

Я избегаю * glob как собственный аргумент, когда это возможно. Даже если я действительно имею в виду «удалить все в этом каталоге», я стараюсь быть более конкретным, т.е. rm *.php. Это превентивный контроль повреждений на случай, если я случайно запустил ту же команду из истории в другом каталоге.

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

Используйте bash и установите PS1 = '\ u @ \ h: \ w>'. Это расширяется до username @ hostname: / full / working / directory / path> Как упоминалось в других ответах, вы можете использовать ожидание для настройки среды при каждом входе в систему, если вы не можете обновить файлы .profile или .bash_profile. Смена цвета фона - лучший ответ :-)

В случае чего-то вроде:

ls * .php
эхо rm * .php
rm * .php

Вы можете использовать оператор подстановки, например:
$ ls * .php
<список каталогов>

$ ^ ls ^ echo rm (это заменяет ls в предыдущей команде на echo rm, оставляя остальную часть командной строки такой же)

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

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

Хорошая идея - сначала запустить команду с echo, но она все же подвержена опечаткам.

Попробуйте использовать его с расширением, например! $.

echo foo*
rm -rf !$

! $ Расширяется до последнего слова последней команды, поэтому он эквивалентен

echo foo*
rm -rf foo*

Также есть! *, Который расширяется до всех аргументов последней команды.

В самом деле, вы могли бы сделать это так, если хотите

echo rm -rf foo*
!*

(Если вы используете ksh, а не bash, вы можете набрать Esc + точка, чтобы вместо этого вставить последнее слово.)

Вместо того

rm foo*

использовать

rm -i foo*

Это практично с горсткой файлов, но не, скажем, с целым архивом. Вот почему алиасинг rm будет у вас на пути.

О да. Этот старый трюк с отправкой кому-либо файла с именем "-rf" через IRC, чтобы он оказался в их ~ каталоге. Один маленький «rm -rf» позже (вместо «rm - -rf»), и последовало много смеха, когда они усвоили суровый урок о том, что IRC нельзя запускать от имени root.

Вместо того, чтобы использовать rm -rf <dir> положить -rf в конце вот так: rm <dir> -rf. Думайте об этом как о снятии предохранителя после того, как вы прицелились и перед выстрелом. Таким образом вы будете защищены, если у вас проскользнет клавиша ввода при вводе имени каталога (или использовании завершения табуляции) и если у вас есть каталоги с аналогичными именами.