Comments 55
Какой-то список вредных советов эры эдак конца 90-х. Заставить всех ходить под одним пользователем (и расшарим пароль от него (!) на всех). Whitelist в iptables и sshd доступа по ssh по IP. Разложить ssh-ключи вручную. Умилительно "читать logwatch" каждый день (заняться больше нечем?). И обязательно "длинная и сложная пассфраза".
К счастью, пассаж про "кражу сервера", которая якобы каким-то образом компрометирует приватные ключи ssh и, самое главное, их после этого нужно их "отозвать" (на украденном сервере, что ли?) — это просто ляп перевода, там в оригинале "stolen machine".
Какой-то список вредных советов эры эдак конца 90-х
Хотелось бы услышать аргументированный ответ почему подход в статье из прошлого вера и какие сейчас применяются методы.
Да я, собственно, примеры привел.
Заведение одного пользователя на всех — странная практика — я такое видел только в коллективах конца 90-х типа "разработчики сидят на Windows 98", им выдали загадочный и очень редкий "сервер", с которыми никто обращаться не умеет, лучше на него вообще не дышать, единственный что-то знающий человек ("гуру-админ") приходит раз в неделю. Все остальные дружно учат PHP2 или 3 и пытаются делать какие-то сайты. По современным реалиям я не вижу никаких аргументов в пользу того, чтобы не заводить отдельного пользователя на каждого человека: и управление этим всем куда более вменяемое, и аудит безопасности проще и прозрачнее — куда проще понять, кто, что и когда делал.
Фильтрация по IP — опять же, в большинстве случаев бред из эры середины-конца 90-х, когда действительно были какие-то фиксированные IP по организациям и люди сидели и работали строго с работы. По современным понятиям куда администраторам лучше иметь доступ к серверам из любой точки мира (с wifi из кафе), и если что-то случается — иметь возможность зайти и принять меры.
Да если уж на то пошло — в целом любые разговоры о сетях — будь то "зафильтрую по IP", "органичу по VLANу" и т.д. — упираются в то, что бесполезно тупо следовать таким "советам" из "статей" — вопрос об архитектуре сети компании в целом, зонировании, организации каких-то слоев управления, менеджмента сетей, VPNов и т.д. Это весьма комплексный вопрос и крайне наивно думать, что "зафильтрую по IP" что-то решит. В лучшем случае — не решит, в худшем — создаст (зачастую еще хорошо припятанные и оттого больнее бьющие) грабли тем, кому с этим придется работать потом.
Опять же — прописывать вручную фильтр по IP одновременно и в iptables, и в sshd — отнюдь не мера безопасности, а очередная глупость, которая аукнется тогда, когда в следующий раз IP поменяется и очередной админ, которому это "досталось в наследство" сообразит поменять его в первом месте и забудет про второе. Как только одно и то же надо прописывать в нескольких местах — это первый и значительный признак того, что нужно откладывать все эти ручные разборки и нужна уже хоть какая-то автоматизация и configuration management.
Я могу долго продолжать, но надо ли?
Я не хожу туда вручную и тем более не подхожу к этому с пиететом типа "первые N минут".
В одном (большом) проекте у нас все сервера ставятся, загружаясь в специальной сети по PXE, затем запускается unattended инсталлятор Debian. Настройки сильно зависят от роли конкретной машины и совершенно не похожи на то, как настраивается типичный веб-фронтэнд: подавляющее большинство машин этого проекта вообще не смотрят мордой в интернет, не использует iptables, не настраивает sudo/пользователей/раскладывает ключи (потому что все приходит централизованно через LDAP) и т.п. До загрузки сервера по PXE есть еще предварительный этап, когда надо перенастроить свичи (в основном VLANы) и соединиться с BMC, заказав загрузку из сети. После инсталляции на машину приходит агент configuration management, донастраивая и доустанавливая все по заданному плану.
В нескольких проектах поменьше, хостящихся на типичных облачных провайдерах (Amazon, DO, RS, ...), используется артиллерия поскромнее: просто задание CM на ~70 строчек, который настраивает все, как мне нравится: создает пользователей, раскладывает ключи и т.д. Учитывая, что инсталляции новой ноды на таких провайдерах занимает эдак минуту, плюс еще минуты 3 на то, чтобы отработал этот скрипт CM, в подавляющем большинстве случаев никто вообще не заморачивается тем, чтобы отлаживать какие-то изменения конфигурации — тупо убивают существующую нод(у|ы) и заказывают их создание заново.
А главное — зачем? Если система настроена адекватно (авторизация только по ключам), то попытки ботов подобрать пароль создают только небольшой паразитный трафик, не более.
В нормальном продакшене поток логов так велик, что разглядывание попыток «китайских ботов» невозможно — поток сообщений превышает способности человека к чтению.
Даже для одного сервера на ip из известных подсетей (типа hetzner'а, например) поток может составлять сотни-тысячи попыток входа в час пока не успокоится и не вызывать желания читать это барахло кроме как fail2ban'ом ,)
Но категорически не вижу смысла в нём при 10+ серверах.Тут уж ELK и тому подобные решения.
И ответ на ваш вопрос:
> А главное — зачем?
В посте:
> Я установил его только для того, чтобы продемонстрировать коллегам, насколько важно иметь хорошую безопасность.
Вам никогда не следует заходить на сервер как рутЛично я не вижу никаких удобств в этом правиле, одни неудобства — постоянно вводить sudo на каждый чих. Если принять, что я не пью, не употребляю и никогда не делаю
rm -rf /
И мне тут предлогают еще заводить учетку с паролем и двать возможность делать sudo. Зачем если лучше залогинется сразу под рутом. И уже из под рута переключатся если нужно на пользователя. И у пользователя вобще отключть возможность логина по паролю.
Все это естественно справедливо для серверов. И одельный логин сдела для запуска приложений которые не должны работать под рутом.
Еще задумался про Google Authentificator но желательно Hardware с возможностью пользоваться не только сервисами гугла, а еще Майл.Ру и т.д.?
Приложение в телефоне можно случайно удалить, потерять телефон. Оставлять его в сейфе не хороший вариант (ведь надо звонить и пользоваться другими его удобствами, держать для этого отдельный телефон в сейфе можно, только есть ли смысл, аккумулятор все заряжать придется часто, да и время синхронизировать
Спешу вас разочаровать, но если вам удалось распечатать приватный ключ, то ни о какой неизвлекаемости с токена не может идти и речи.
Настоящие неизвлекаемые ключи генирируются прямо на токене и никогда не покидают его. Токен при этом аппаратно производит все операции с закрытым ключем: шифрование (ассиметричное), электронная подпись, некоторые даже хэши считают. Такие токены сильно дороже и реже продаются. Потому что параноиков мало и спрос на них никакущий.
Многие токены допускают загрузку ключа снаружи, но он не становится от этого извлекаемыми. И операции шифрования и подписи производятся только на токене, а APDU для извлечения ключа просто возвращают ошибку, так что софт на хосте не может получить ключ, если на javacard нет бэкдора в апплете.
Yubikey (Neo), Рутокен ЭЦП, eToken Pro (Java) как минимум. Обычно смарткарты и не подразумевают возможность извлечения ключевого материала, если они сертифицированы по разумным стандартам. А те, что делались с прицелом на FIPS — тем более.
технически, — правильно вывешенный хостнейм сервера, который однозначно его идентифицирует
организационно, — понимать ответственность.
на автомате можно вбить с судо что угодно.
есть хоть кто-то, с большим и интенсивным опытом работы с серверами, кто хоть раз случайно не вводил команды не в ту консоль? ( как минимум ребут )
поэтому IMO есть понятие деструктивные и недеструктивные команды, надо понимать чем они различаются, и перед вводом первых несколько раз проверить что действительно они нужны и там ли они выполняться.
Переключаясь на третий стол, я четко знаю с чем работаю и «случайных комманд» там просто быть не может.
Методы придумываются разные: разукрашка терминалов (имеется ввиду выставление фона). Файрволл от самого же себя (прежде чем идти клиенту, я должен зайти на вебинтерфейс и открыть доступ, указав какого черта мне там понадобилось) и все равно, особенно при массовых операция возникают факапы.
Однажды в большой и серьёзной компании за одну держурную ночь произошло сразу два факапа: один склонировал OEBS не туда (перепутал один из тестов с dev инсталяцией), а другой перепутал клиентов (одна буква отличия вроде). Моя смена была следущая и я, как старший наслушался всего (предыдущий старший смены тоже оставался и разгребал). Однажды админ с менеджером перепутали инсталяции (глаз к утру замылился) и «закрыли период» в компании в которой работают десятки тысяч человек. Это значит, что выставились счета, просчитались налоговые деклорации, на кучу принтеров уехало куча бумаги, а самом главному пришел финансовый отчет за квартал. Это был эпичный факап, который разгребала сотня людей: очень сложно провернуть фарш назад и объяснить контрагентам, отделам, налоговой, что та фигня, что пришла к ним утром это ошибка, а реальность будет только на следущей неделе.
Все это наводит любого админа на мысль, что паранои мало не бывает. В первую очередь по отношению к самому себе. Поэтому чем больше мне надо шагов сделать до reboot, тем лучше. И даже после этого я попытаюсь выдохнуть, еще раз прочитать задачу и как минимум сказать ip a (хостнейм совсем не показатель тут). И только после этого сказать в консоль «куищще».
Sudo или su (в Aix и Solaris su выполняет роль sudo) не панацея, но его отсутствие говорит о довольно слабом жизненом и аминском опыте.
И да, опережая возможные сомнения: разграничение прав на сервере для обычных пользователей, в том числе и на чтение — тоже еще один уровень безопасности.
Это как подушки на которые придется падать в случае чьей-то или своей ошибки.
Запаролил ключик — молодец, взломщик задолбается брутфорсить.
Убрал root доступ — молодец, упорный взломщик дважды задолбается ища пути повышения привилегий.
Больше слоев — крепче спишь, меньше цена ошибки, но больше тратишь время на рутинные действия типа ввода паролей или sudo.
где-то в интерпрасах могут вообще запрещать логиниться под рутом, если это не крайне необходимо.
перевешивание ssh на другой порт это конечно мера, но если позволяет инфраструктура, то у серверов несколько подключенных сетей и отвечают они за разные задачи, есть public network — через которую обслуживаем клиента, есть mgmt network — внутри которой организуется доступ по ssh. при необходимости другие.
относительно доставки ключей на сервера, если их больше 10, 100 и тп, выкладывать ключи пользователей это та ещё задача, поэтому используется централизованный сервер с которого это производится, в идеале привязка к централизованной учётке, чтобы было в итоге,
сотрудник уволился — из одного места удалили, сотрудник изменил ключ — из одного места поменяли.
Другой вариант — хранить ключи в ldap. Тогда можно сделать централизованные учётки через sssd и централизованное получение ключей через AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys в sshd_config.
2)sudo bash
Поэтому, «первые 5 минут на сервере» можно опустить до «первые 0 секунд на сервере» и приложить листинг сценария ansible, который будет использовать только рутовый пароль (с которым севрер обычно и выдаётся).
Первые 10 минут на сервере