Как стать автором
Обновить

Комментарии 55

Какой-то список вредных советов эры эдак конца 90-х. Заставить всех ходить под одним пользователем (и расшарим пароль от него (!) на всех). Whitelist в iptables и sshd доступа по ssh по IP. Разложить ssh-ключи вручную. Умилительно "читать logwatch" каждый день (заняться больше нечем?). И обязательно "длинная и сложная пассфраза".


К счастью, пассаж про "кражу сервера", которая якобы каким-то образом компрометирует приватные ключи ssh и, самое главное, их после этого нужно их "отозвать" (на украденном сервере, что ли?) — это просто ляп перевода, там в оригинале "stolen machine".

Я совсем не разбираюсь в теме администрирования сервером, хотелось бы понять, как говориться best practics.
Какой-то список вредных советов эры эдак конца 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, в подавляющем большинстве случаев никто вообще не заморачивается тем, чтобы отлаживать какие-то изменения конфигурации — тупо убивают существующую нод(у|ы) и заказывают их создание заново.

Не сервера кражу, а компьютера, с которого осуществляется доступ на сервер. Ведь на компе хранится приватный ключ.
Когда человек говорит, что получает удовольствие от чтения logwatch, я понимаю, что это «root-администратор на своём калькуляторе». В нормальном продакшене поток логов так велик, что разглядывание попыток «китайских ботов» невозможно — поток сообщений превышает способности человека к чтению.

А главное — зачем? Если система настроена адекватно (авторизация только по ключам), то попытки ботов подобрать пароль создают только небольшой паразитный трафик, не более.
В нормальном продакшене поток логов так велик, что разглядывание попыток «китайских ботов» невозможно — поток сообщений превышает способности человека к чтению.


Даже для одного сервера на ip из известных подсетей (типа hetzner'а, например) поток может составлять сотни-тысячи попыток входа в час пока не успокоится и не вызывать желания читать это барахло кроме как fail2ban'ом ,)
Logwatch хорошо настраивается. Убрать оповещения об авторизации (пусть это действительно читает fail2ban или еще что-то подобное) и смотреть только то, что действительно нужно
Справедливости ради — речь об уведомлении от Logwatch, а не просмотре самих логов. В свою очередь настройки Logwatch позволяют достаточно комфортно настроить размер и информативность таких сообщений.
Но категорически не вижу смысла в нём при 10+ серверах.Тут уж ELK и тому подобные решения.

И ответ на ваш вопрос:
> А главное — зачем?
В посте:
> Я установил его только для того, чтобы продемонстрировать коллегам, насколько важно иметь хорошую безопасность.
Меня сейчас, конечно, опустят, но может кто-то внятно объяснить почему
Вам никогда не следует заходить на сервер как рут
Лично я не вижу никаких удобств в этом правиле, одни неудобства — постоянно вводить sudo на каждый чих. Если принять, что я не пью, не употребляю и никогда не делаю
rm -rf /
авторизация строго по ключу, sshd на нестандартном порту, в iptables открыт только для моего ip, то какие «неприятности» меня могут ждать? Что-то за 10 лет * 5 машин ну ни разу ничего такого (тьфу-тьфу-тьфу). Я почти уверен, что многие делают sudo bash сразу же после логина, если не ставят это в .bashrc, особенно те, кто занимается администрированием этой машины, а не кодингом в ~/
Очень хочется вас плюсануть, жаль не могу. Никто не сможет внятно объяснить, т.к. это правило — полный бред. К слову, Fail2ban для ssh и 400 на ключи никак не повышают безопасность сервера. Подобные статьи пишут люди, которые очень смутно представляют себе атаку на сервер.
Ну, не скажите. 400 при сильно кривых соседях по home могут помочь, да и, если мне не изменяет память, ssh по-другому не даст работать, т.е. проверяет права на файл. А вот запрет на логин рутом встречается в 99% руководств по настройке ssh.

openssh и при 0600 тоже позволит работать

Я вот тоже невижу никаких преимуществ. Даже наоборот вред. Например я логуинусь по ключу под рутом. Приватный ключ лежит в токене в не извлекаемом виде + распечатан и спрятан в сейф. И больше нигде этого приватного ключа нету.
И мне тут предлогают еще заводить учетку с паролем и двать возможность делать sudo. Зачем если лучше залогинется сразу под рутом. И уже из под рута переключатся если нужно на пользователя. И у пользователя вобще отключть возможность логина по паролю.
Все это естественно справедливо для серверов. И одельный логин сдела для запуска приложений которые не должны работать под рутом.
В каком токене это хранится, ruToken для этого подойдет или есть что то более вариативное?

Еще задумался про Google Authentificator но желательно Hardware с возможностью пользоваться не только сервисами гугла, а еще Майл.Ру и т.д.?
Приложение в телефоне можно случайно удалить, потерять телефон. Оставлять его в сейфе не хороший вариант (ведь надо звонить и пользоваться другими его удобствами, держать для этого отдельный телефон в сейфе можно, только есть ли смысл, аккумулятор все заряжать придется часто, да и время синхронизировать
Мне очень понравился yubico. Там многи чего есть и потержка pgp и piv и разные способы OTP. И все в одном девайсе.
> Приватный ключ лежит в токене в не извлекаемом виде + распечатан и спрятан в сейф.

Спешу вас разочаровать, но если вам удалось распечатать приватный ключ, то ни о какой неизвлекаемости с токена не может идти и речи.
А то, что ключ можно сгенерировать на компьютере, а потом записать на токен, после чего удалить, вы не рассматривали?
Рассматривал. Такие токены знаю. Но обычно (за всю Одессу не скажу) это означает только одно: неизвлекаемость там такая же, как и защита документов PDF. То есть если программа (драйвер) уважает «флажки» в профиле ключа, то она вам не даст ключ проэкспортировать. А если написать такую, которая эти флажки будет вертеть на одном месте — то только в путь. Чтобы вам было ещё больше понятнее, то просто подумайте на тему того, как выполняется шифрование — если его не делает токен, то это означает, что хост всё равно его скачивает.

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

Многие токены допускают загрузку ключа снаружи, но он не становится от этого извлекаемыми. И операции шифрования и подписи производятся только на токене, а APDU для извлечения ключа просто возвращают ошибку, так что софт на хосте не может получить ключ, если на javacard нет бэкдора в апплете.

Не исключаю таких реализаций. А можно конкретные модели назвать, с которыми вы сталкивались?
Я уже приводил тут в коментарии выше.

Yubikey (Neo), Рутокен ЭЦП, eToken Pro (Java) как минимум. Обычно смарткарты и не подразумевают возможность извлечения ключевого материала, если они сертифицированы по разумным стандартам. А те, что делались с прицелом на FIPS — тем более.

НЛО прилетело и опубликовало эту надпись здесь
Вот это уже хороший довод! Спасибо.

Недостаточного одного sudo, ведь ж есть sudo -i

Если логинется по ключаем под рутом, то тоже можно логировать кто это был.
У каждого админа свой ключ.
Если админов несколько и они отвечают каждый за свой «фронт работ», то sudo позволяет разграничить их полномочия так, чтобы они не могли накосячить в «чужой области». Сделать это, если все они логинятся под рутом, просто не возможно принципиально.
Если у вас 20 терминалов открыто, то можно случайно стать заложником “Ой, не то окно, прости, боевой сервер, это было не тебе”. `sudo` на каждый чих — просто еще один барьер, который помешает случайности что-то испортить.
барьер не судо,
технически, — правильно вывешенный хостнейм сервера, который однозначно его идентифицирует
организационно, — понимать ответственность.
на автомате можно вбить с судо что угодно.

есть хоть кто-то, с большим и интенсивным опытом работы с серверами, кто хоть раз случайно не вводил команды не в ту консоль? ( как минимум ребут )

поэтому IMO есть понятие деструктивные и недеструктивные команды, надо понимать чем они различаются, и перед вводом первых несколько раз проверить что действительно они нужны и там ли они выполняться.
Для себя сделал следующее — 3 рабочих стола. На первом разработка (код, браузер), на втором локальный/дев сервер, на третьем — продакшн.
Переключаясь на третий стол, я четко знаю с чем работаю и «случайных комманд» там просто быть не может.
Да есть. Любой админ с опытом, прекрасно понимает эту ситуацию. За день я открываю консоль на сервер, в среднем 152 раза (я серьёзно, я считал). У меня 100+ хостов, и под 1000 хостов у клиентов, которых мы обслуживаем. В таком потоке легко лажануть. И reboot, известный также как «куищще» это мелочь по сравнению с тем, что может произойти.

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

Однажды в большой и серьёзной компании за одну держурную ночь произошло сразу два факапа: один склонировал OEBS не туда (перепутал один из тестов с dev инсталяцией), а другой перепутал клиентов (одна буква отличия вроде). Моя смена была следущая и я, как старший наслушался всего (предыдущий старший смены тоже оставался и разгребал). Однажды админ с менеджером перепутали инсталяции (глаз к утру замылился) и «закрыли период» в компании в которой работают десятки тысяч человек. Это значит, что выставились счета, просчитались налоговые деклорации, на кучу принтеров уехало куча бумаги, а самом главному пришел финансовый отчет за квартал. Это был эпичный факап, который разгребала сотня людей: очень сложно провернуть фарш назад и объяснить контрагентам, отделам, налоговой, что та фигня, что пришла к ним утром это ошибка, а реальность будет только на следущей неделе.

Все это наводит любого админа на мысль, что паранои мало не бывает. В первую очередь по отношению к самому себе. Поэтому чем больше мне надо шагов сделать до reboot, тем лучше. И даже после этого я попытаюсь выдохнуть, еще раз прочитать задачу и как минимум сказать ip a (хостнейм совсем не показатель тут). И только после этого сказать в консоль «куищще».

Sudo или su (в Aix и Solaris su выполняет роль sudo) не панацея, но его отсутствие говорит о довольно слабом жизненом и аминском опыте.
Это еще один слой безопасности. Вы можете его убрать или использовать по вашему усмотрению, но это, определенно, риск. На практике, у одного из моих клиентов угнали ключи с его персональной машины. Не будь это ключи к руту, у нас было бы еще время на реагирование. Но с рут доступом атакующий просто спокойно все слил.
И да, опережая возможные сомнения: разграничение прав на сервере для обычных пользователей, в том числе и на чтение — тоже еще один уровень безопасности.
Разумеется, кто же спорит то?
Это как подушки на которые придется падать в случае чьей-то или своей ошибки.
Запаролил ключик — молодец, взломщик задолбается брутфорсить.
Убрал root доступ — молодец, упорный взломщик дважды задолбается ища пути повышения привилегий.
Больше слоев — крепче спишь, меньше цена ошибки, но больше тратишь время на рутинные действия типа ввода паролей или sudo.
В openssh есть ssh-agent. Если его обернуть selinux или apparmor, то можно добиться определенного усиления защиты не потеряв в удобстве.
основное преимущество, и задача sudo, как отмечали, это когда администраторов и людей которые имеют доступ больше чем один,
где-то в интерпрасах могут вообще запрещать логиниться под рутом, если это не крайне необходимо.

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

относительно доставки ключей на сервера, если их больше 10, 100 и тп, выкладывать ключи пользователей это та ещё задача, поэтому используется централизованный сервер с которого это производится, в идеале привязка к централизованной учётке, чтобы было в итоге,
сотрудник уволился — из одного места удалили, сотрудник изменил ключ — из одного места поменяли.

Другой вариант — хранить ключи в ldap. Тогда можно сделать централизованные учётки через sssd и централизованное получение ключей через AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys в sshd_config.

Или в EMCSSH.
Судо критично необходимо если админов больше 1. А перевешивание на другой порт помогает от китайских ботов, хотя я уже даже на домашнем роутере перестал перевешивать порт. Трафик от ботов не такой чтобы с этим гемороится. А так считаю что опытный админ закрывает вход под рутом и прописывает судо баш в башрс, просто потому что это въедается в голову из компаний где больше 1 админа. Закрывать доступ по айпи это супер если у тебя единственная точка входа со статическим айпи, к которой ты подключаешься с помощью сертификатов. И вводить пароли по факту не надо и удобно и безопасно. А чтобы не боятся потерять ключи хранить их надо только в 1 месте на зашифрованном диске(и распечатка в сейфе).
Опытный админ никогда не будет делать NOPASSWD на рута.
А про nopasswd никто не говорил. Вместо пароля используется ssh ключ http://blog.towo.eu/authenticating-sudo-with-the-ssh-agent/
Ааа. Вот о чем речь. Я такое не стал делать, поскольку рушится ещё один барьер на пути проникновения. Хотя, конечно, это лучше, чем nopasswd.
Ключи лучше пароля, и барьеры никакие не рушатся. Отдельный ключ для судо, отдельный для ссш. и на каждую площадку свои ключи.
И оба ключа в одном хранилище ssh-agent? Пароли на ключах хоть есть?
Если вы с чем-то не сталкивались, это не значит, что это придумали ради усложнения жизни админам. Как мне помнится это стало хорошим тоном после того, как появились атаки на машины в которых хакер получал доступ на сервер копроментируя какого-то пользователя и заливал в доступную скомпрометированному пользователю папку скрипт/бинарник. В то время многие админы сидели как root и в PATH у них для удобства запуска самописанных скриптов был путь ".". В таких случаях хакер мог загрузить на сервер в папку скомпрометированного пользователя файлик с именем типа ls или cd, чем самым тут же перекрывал системные команды админу, либо он мог прикинуться одним из ничего не понимающих пользователей (например хостинга) и попросить админа проверить чего его скрипт helloworld не запускается на сервере. В результате админ сидящий под root сам того не зная выстреливал себе в ногу выполняя зловред со своими правами. Именно с тех пор считается, что сидеть на серверах под root и добавлять "." в PATH очень дурной тон. В домашних песочницах – пожалуйста.
опечатка: копроментируя > компрометируя ;)
ну не сильно-то и опечатка :)
НЛО прилетело и опубликовало эту надпись здесь
1)Заходим по ssh под неадмином
2)sudo bash
НЛО прилетело и опубликовало эту надпись здесь
Ну и мои 5 копеек. Включайте IPV6 только тогда, когда вы (и ваше сетевое оборудование) полностью сможете удержать этот протокол под контролем. Да, надо будет немного подучиться. Обилие софтовых шлюзов (и разнообразие реализованных способов) IPV4-IPV6 разбросанных вендорами по многим системам по своему усмотрению делают общение с IPV6 во внутренних сетях с выходом в интернет не таким прозрачным.
А потом останется только поставить за пару минут WordPress или Joomla и чуть-чуть подождать до момента, когда сервер начнёт рассылать спам, подбирать пароли к чужим серверам, хостить дорвей и северокорейский прокси. Потому что в 2016-м основной вектор атаки на веб-сервера — это веб-сайты на популярных CMS, о трудностях защиты которых можно рассказать не одну прекрасную драму.
Это не подход истинного админа. Натоящий админ ленив и никогда не вводит руками то, что нужно вводить всякий раз, получая новый сервер.
Поэтому, «первые 5 минут на сервере» можно опустить до «первые 0 секунд на сервере» и приложить листинг сценария ansible, который будет использовать только рутовый пароль (с которым севрер обычно и выдаётся).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.