Азбука безопасности Ubuntu
«Мои первые 5 минут на сервере» Брайана Кеннеди — отличное введение, как быстро обезопасить сервер от большинства атак. У нас есть несколько исправлений для этой инструкции, чтобы дополнить ею наше полное руководство. Также хочется подробнее объяснить некоторые вещи для более юных инженеров.
Каждое утро я проверяю почтовые уведомления logwatch и получаю основательное удовольствие, наблюдая несколько сотен (иногда тысяч) безуспешных попыток получить доступ. (Многие довольно прозаичны — попытки авторизоваться как
root с паролем 1234 снова и снова). Приведённая здесь общая методика подходит для серверов Debian/Ubuntu, которые лично мы предпочитаем всем остальным. Они обычно служат только хостами для контейнеров Docker, но принципы те же. На больших масштабах лучше использовать полностью автоматические установки с инструментами вроде Ansible или Shipyard, но иногда вы просто поднимаете единственный сервер или подбираете задачи для Ansible — для таких ситуаций предназначена инструкция.
Примечание: Эта справка создана как базовая азбука. Её следует расширить и дополнить в соответствие с вашими потребностями.
В первую очередь
У нас ещё даже нет пароля для рута. Хотелось бы выбрать что-нибудь случайное и сложное. Используем генератор менеджера паролей с настройками максимальной сложности. Менеджер паролей сохраняет пароль и шифрует его, доступ к нему возможен только по длинному мастер-паролю. Здесь предусмотрена пара избыточных мер защиты (длинный, сложный случайный пароль + защита пароля шифрованием и другим длинным паролем). Используете вы парольный менеджер или другие инструменты, сохраняйте пароль в безопасности, применяя какую-нибудь форму шифрования. Вам понадобится только этот рутовый пароль в случае потери пароля sudo.
# passwd*Примечание: На HN и Reddit развернулась интересная дискуссия о рутовых паролях. Её стоит почитать.
Теперь следует обновить репозитории и накатить последние патчи. Далее будет отдельный раздел по автоматизации установки обновлений безопасности.
apt-get update
apt-get upgradeДобавляем пользователя
Вам никогда не следует заходить на сервер как рут. Мы следуем тем же правилам при создании пользователей, которые установил Брайан Кеннеди, но вы можете использовать собственные. У нашей маленькой команды не было проблем с использованием единственного пользователя для авторизации, но в больших командах лучше создать разных пользователей с разными уровнями привилегий, где только избранные получают привилегии sudo.
useradd deploy
mkdir /home/deploy
mkdir /home/deploy/.ssh
chmod 700 /home/deploy/.sshУстанавливаем предчтительную оболочку для пользователя deploy, мы используем bash:
usermod -s /bin/bash deployПомните:
chmod 700 означает, что владелец аккаунта обладает правами на чтение, запись и запуск программ. Мы всё ещё находимся с правами рута, но через минуту мы запустим команду chown рекурсивно на этой папке для пользователя deploy и группы deploy. Только этот пользователь должен иметь право работать с папкой .ssh.Аутентификация по ключу ssh
Мы стараемся не использовать пароли для входа на сервер. Насчёт этого было много споров после того как вышла инструкция Брайана, но я тоже склонен согласиться с такой позицией. Вот несколько замечаний на этот счёт:
- Ключи ssh лучше паролей только потому, что они содержат и требуют больше информации.
- Пароли можно подобрать брутфорсом. Гадать по публичному ключу по существу невозможно, так что их можно считать полностью безопасными.
- Что насчёт кражи компьютера? Да, там ваши секретные ключи, но отозвать ssh-key легко, достаточно просто удалить открытый ключ из authorized_keys. Вам следует также защитить секретный ключ безопасной и длинной парольной фразой. См. следующий пункт.
- Всё это работает ТОЛЬКО ПРИ УСЛОВИИ БЕЗОПАСНОЙ И ДЛИННОЙ ПАРОЛЬНОЙ ФРАЗЫ, ЗАЩИЩАЮЩЕЙ КЛЮЧ. Повторяем второй раз, потому что это критически важно.
Итак, оставим в прошлом аутентификацию по паролю. Скопируйте содержимое id_rsa.pub1 со своей локальной машины на серверы в файл authorized_keys.
vim /home/deploy/.ssh/authorized_keysУстановим правильные привилегии, руководствуясь принципом безопасности Linux, известным как принцип минимальных привилегий:
chmod 400 /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy -Rchmod 400 устанавливает разрешения, так что файл может прочитать только владелец. Другая команда chown делает пользователя deploy и группу deploy владельцами (рекурсивно) их домашней директории. Мы упоминали об этом ранее, когда устанавливали разрешения на чтение, запись и исполнение для владельца этой директории.Вернёмся к этому чуть позже, когда правильно протестируем нашего пользователя deploy и sudo для отключения авторизации рута и установки авторизации только по ключу ssh.
Тестирование пользователя deploy и установка sudo
Мы собираемся проверить, как происходит авторизация пользователя deploy, в то же время сохраняя открытым соединение по ssh для рута на всякий случай. Если всё работает нормально, мы используем наше открытое подключение рута, чтобы установить пароль для deploy. Поскольку мы отключаем авторизацию по паролю, то этот пароль будет использован при применении sudo. Снова мы запускаем парольный менеджер для генерации сложного и случайного пароля, сохраняем его в зашифрованном виде и сообщаем коллегам (синхронизация зашифрованного файла с паролем).
passwd deployУстановка sudo простая. Открываем файл sudo:
visudoДобавляем группу
%sudo под рутовым пользователем, как показано ниже. Убедитесь, что все остальные пользователи и группы отбиты комментариями с символом # (у пользователей нет префиксов, а группы начинаются с %). На большинстве свежих установок там ничего нет, но на всякий случай.root ALL=(ALL) ALL
%sudo ALL=(ALL:ALL) ALLТеперь добавим пользователя
deploy в группу sudo.usermod -a -G sudo deployЭто предоставит пользователю deploy доступ к sudo после введения пароля, который мы только что создали.
Замечание к исправлению: спасибо пользователю ackackacksyn на Reddit за верное замечение, что не следует добавлять пользователей напрямую в список sudo.
Активируем вход по ключу ssh
Конфигурация ssh для этой машины хранится здесь:
vim /etc/ssh/sshd_configВы захотите добавить туда несколько строк. Мне кажется, они довольно понятны сами по себе. Это IP-адрес, который вы используете для подключения. У нас в компании используется VPN-конфигурация с OpenVPN и криптографической аутентификацией, так что для подключения к серверу нужно также пройти аутентификацию и быть подключённым к VPN.
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy@(your-VPN-or-static-IP)Активируйте все эти правила, перезапустив службы ssh. Вероятно, придётся переподключиться (делайте это через пользователя deploy!).
service ssh restartУстановка файрвола
Обычно здесь два лагеря. Одни используют IPtables напрямую, а другие применяют удобный интерфейс под названием
ufw, который представляет собой слой над IPtables для упрощения процесса настройки. Более простой вариант обычно предпочтительнее с точки зрения безопасности. ufw от DigitalOcean действительно неплох и помогает в основных вещах.ufw установлен по умолчанию на Ubuntu, а на Debian достаточно запустить команду apt-get install ufw.По умолчанию
ufw должен отказывать во всех входящих подключениях и разрешать все исходящие, однако, он не будет запущен (потому что иначе как бы вы подключились?). Мы пройдёмся и явно разрешим соединения, которые считаются нормальными.Во-первых, следует убедиться в поддержке IPv6. Откройте конфигурационный файл.
vim /etc/default/ufwУстановите IPv6 в значение
yes.IPV6=yesДля остальных портов, которые мы собираемся открыть, можно просто использовать инструмент
ufw из командной строки, что очень удобно.sudo ufw allow from {your-ip} to any port 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw disable
sudo ufw enableПервое — это избыточная мера, которая гарантирует, что только соединения с нашего IP-адреса могут соединяться по SSH (стандартный порт SSH)2. Вторая и третья команда открывают трафик http и https.
Примечание: Спасибо chrisfosterelli за замечание, что если вы собираетесь установить первое правило (а вам следует это сделать), то убедитесь, что у вас статичный IP-адрес или безопасный VPN, к которому вы подключаетесь. Динамический IP-адрес оставит вас без доступа к серверу когда-нибудь в будущем.
Автоматические обновления безопасности
Мне они нравятся. Они не идеальны, но это лучше, чем пропустить патчи после их выхода.
apt-get install unattended-upgrades
vim /etc/apt/apt.conf.d/10periodicОбновите этот файл следующим образом:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";Я в целом согласен с Брайаном, что лучше отключить обычные обновления, а оставить только обновления безопасности. Идея в том, что будет не очень хорошо, если приложение внезапно перестанет работать из-за обновления какого-то пакета с зависимостями, в то время как обновления безопасности очень редко создают проблемы с зависимостями на уровне приложения.
vim /etc/apt/apt.conf.d/50unattended-upgradesОтредактируйте файл следующим образом:
Unattended-Upgrade::Allowed-Origins {
"Ubuntu lucid-security";
//"Ubuntu lucid-updates";
};Всё готово.
Fail2ban
fail2ban — отличный пакет, который проактивно блокирует подозрительную активность, как только она обнаружена. В их вики сказано, что fail2ban сканирует файлы логов (например,
/var/log/apache/error_log) и банит IP-адреса, которые проявляют подозрительные признаки — слишком много попыток ввода неправильного пароля, поиск эксплоитов и проч… Сразу после установки Fail2Ban оснащён фильтрами для различных сервисов (apache, courier, ssh и др.).apt-get install fail2banДвухфакторная аутентификация
Двухфакторная аутентификация обязательна, если мы проектируем систему, которая соответствует нормам безопасности. Теоретически, если вы активируете двухфакторную аутентификацию поверх всех остальных защитных мер, то тогда для получения доступа к серверу (через вскрытие уязвимостей в приложениях), нападающим придётся также иметь:
- Доступ к вашему сертификату и ключу для доступа к VPN.
- Доступ к вашему компьютеру, чтобы получить секретный ключ.
- Доступ к вашей парольной фразе для секретного ключа.
- Доступ к вашему телефону для двухфакторной аутентификации.
Это немало барьеров (четыре), которые придётся преодолеть. Даже если они получат рутовый доступ через sudo, им придётся найти пароль deploy, который защищён шифрованием AES (пятый барьер).
Устанавливаем пакет.
apt-get install libpam-google-authenticatorДля установки запускаем команду и следуем инструкциям:
su deploy
google-authenticatorДвухфакторная аутентификация устанавливается очень легко и добавляет хороший дополнительный уровень безопасности.
Logwatch
Этот инструмент скорее для удовольствия и мониторинга постфактум. Logwatch отслеживает логи и в соответствии с настройками высылает по почте ежедневную красиво структурированную сводку. Это довольно занимательные данные, и вы удивитесь, как много попыток доступа к серверу происходит каждый день. Я установил его только для того, чтобы продемонстрировать коллегам, насколько важно иметь хорошую безопасность.
У DigitalOcean есть отличное описание установки и настройки Logwatch, но если мы хотим уложиться в 10 минут, то просто установим его и сделаем задание cron для ежедневного запуска и отправки письма по электронной почте.
apt-get install logwatchДобавляем задание cron.
vim /etc/cron.daily/00logwatchДобавьте следующую строку в файл cron:
/usr/sbin/logwatch --output mail --mailto you@example.com --detail highВсё готово
Ну вот. После завершения всего вышеперечисленного вашей основной заботой и точкой сбоя станет ваше приложение и сервисы. Это совершенно другая область.
Мы пытаемся максимально формализовать и описать наши лучшие практики и процессы, если хотите узнать больше, изучите наш репозиторий. Всё в открытом доступе, и мы продолжаем пополнять его.
1 Убедитесь, что указан именно `.pub`. Это кажется очень простым, но я встречал двух товарищей (оба *не* работают в нашей компании — они бы быстро прекратили здесь работать) за свою карьеру, которые прислали мне свои секретные ключи (`id_rsa` без расширения .pub), когда я попросил прислать открытый ключ. Вернуться к статье
2 Мнения расходятся, назначать ли для соединений SSH стандартный или нестандартный порт. См. здесь и здесь аргументы обеих сторон. Вернуться к статье
Комментарии (54)
amarao
17.06.2016 11:45+10Когда человек говорит, что получает удовольствие от чтения logwatch, я понимаю, что это «root-администратор на своём калькуляторе». В нормальном продакшене поток логов так велик, что разглядывание попыток «китайских ботов» невозможно — поток сообщений превышает способности человека к чтению.
А главное — зачем? Если система настроена адекватно (авторизация только по ключам), то попытки ботов подобрать пароль создают только небольшой паразитный трафик, не более.
grossws
17.06.2016 14:42В нормальном продакшене поток логов так велик, что разглядывание попыток «китайских ботов» невозможно — поток сообщений превышает способности человека к чтению.
Даже для одного сервера на ip из известных подсетей (типа hetzner'а, например) поток может составлять сотни-тысячи попыток входа в час пока не успокоится и не вызывать желания читать это барахло кроме как fail2ban'ом ,)
Merlyel
18.06.2016 20:01Logwatch хорошо настраивается. Убрать оповещения об авторизации (пусть это действительно читает fail2ban или еще что-то подобное) и смотреть только то, что действительно нужно
setevoy4
20.06.2016 07:17Справедливости ради — речь об уведомлении от Logwatch, а не просмотре самих логов. В свою очередь настройки Logwatch позволяют достаточно комфортно настроить размер и информативность таких сообщений.
Но категорически не вижу смысла в нём при 10+ серверах.Тут уж ELK и тому подобные решения.
И ответ на ваш вопрос:
> А главное — зачем?
В посте:
> Я установил его только для того, чтобы продемонстрировать коллегам, насколько важно иметь хорошую безопасность.
savostin
17.06.2016 11:47Меня сейчас, конечно, опустят, но может кто-то внятно объяснить почему
Вам никогда не следует заходить на сервер как рут
Лично я не вижу никаких удобств в этом правиле, одни неудобства — постоянно вводить sudo на каждый чих. Если принять, что я не пью, не употребляю и никогда не делаю
авторизация строго по ключу, sshd на нестандартном порту, в iptables открыт только для моего ip, то какие «неприятности» меня могут ждать? Что-то за 10 лет * 5 машин ну ни разу ничего такого (тьфу-тьфу-тьфу). Я почти уверен, что многие делают sudo bash сразу же после логина, если не ставят это в .bashrc, особенно те, кто занимается администрированием этой машины, а не кодингом в ~/rm -rf /
mrobespierre
17.06.2016 12:54-2Очень хочется вас плюсануть, жаль не могу. Никто не сможет внятно объяснить, т.к. это правило — полный бред. К слову, Fail2ban для ssh и 400 на ключи никак не повышают безопасность сервера. Подобные статьи пишут люди, которые очень смутно представляют себе атаку на сервер.
savostin
17.06.2016 12:57+1Ну, не скажите. 400 при сильно кривых соседях по home могут помочь, да и, если мне не изменяет память, ssh по-другому не даст работать, т.е. проверяет права на файл. А вот запрет на логин рутом встречается в 99% руководств по настройке ssh.
a1ien_n3t
17.06.2016 13:42Я вот тоже невижу никаких преимуществ. Даже наоборот вред. Например я логуинусь по ключу под рутом. Приватный ключ лежит в токене в не извлекаемом виде + распечатан и спрятан в сейф. И больше нигде этого приватного ключа нету.
И мне тут предлогают еще заводить учетку с паролем и двать возможность делать sudo. Зачем если лучше залогинется сразу под рутом. И уже из под рута переключатся если нужно на пользователя. И у пользователя вобще отключть возможность логина по паролю.
Все это естественно справедливо для серверов. И одельный логин сдела для запуска приложений которые не должны работать под рутом.VecH
17.06.2016 14:31В каком токене это хранится, ruToken для этого подойдет или есть что то более вариативное?
Еще задумался про Google Authentificator но желательно Hardware с возможностью пользоваться не только сервисами гугла, а еще Майл.Ру и т.д.?
Приложение в телефоне можно случайно удалить, потерять телефон. Оставлять его в сейфе не хороший вариант (ведь надо звонить и пользоваться другими его удобствами, держать для этого отдельный телефон в сейфе можно, только есть ли смысл, аккумулятор все заряжать придется часто, да и время синхронизировать
dmitrmax
19.06.2016 00:08-1> Приватный ключ лежит в токене в не извлекаемом виде + распечатан и спрятан в сейф.
Спешу вас разочаровать, но если вам удалось распечатать приватный ключ, то ни о какой неизвлекаемости с токена не может идти и речи.a1ien_n3t
19.06.2016 00:11+1А то, что ключ можно сгенерировать на компьютере, а потом записать на токен, после чего удалить, вы не рассматривали?
dmitrmax
19.06.2016 05:07-1Рассматривал. Такие токены знаю. Но обычно (за всю Одессу не скажу) это означает только одно: неизвлекаемость там такая же, как и защита документов PDF. То есть если программа (драйвер) уважает «флажки» в профиле ключа, то она вам не даст ключ проэкспортировать. А если написать такую, которая эти флажки будет вертеть на одном месте — то только в путь. Чтобы вам было ещё больше понятнее, то просто подумайте на тему того, как выполняется шифрование — если его не делает токен, то это означает, что хост всё равно его скачивает.
Настоящие неизвлекаемые ключи генирируются прямо на токене и никогда не покидают его. Токен при этом аппаратно производит все операции с закрытым ключем: шифрование (ассиметричное), электронная подпись, некоторые даже хэши считают. Такие токены сильно дороже и реже продаются. Потому что параноиков мало и спрос на них никакущий.grossws
19.06.2016 05:44Многие токены допускают загрузку ключа снаружи, но он не становится от этого извлекаемыми. И операции шифрования и подписи производятся только на токене, а APDU для извлечения ключа просто возвращают ошибку, так что софт на хосте не может получить ключ, если на javacard нет бэкдора в апплете.
dmitrmax
20.06.2016 20:59Не исключаю таких реализаций. А можно конкретные модели назвать, с которыми вы сталкивались?
grossws
20.06.2016 23:45Yubikey (Neo), Рутокен ЭЦП, eToken Pro (Java) как минимум. Обычно смарткарты и не подразумевают возможность извлечения ключевого материала, если они сертифицированы по разумным стандартам. А те, что делались с прицелом на FIPS — тем более.
moveax3
17.06.2016 14:12+7sudo имеет смысл, когда пользователей-администраторов больше одного, тогда при заходе на сервер, даже если у них прописано sudo bash, в логах можно будет посмотреть, кто из них именно под sudo накосепорил. Если администратор один, то это по моему только лишний слой, так же как и использование ufw поверх iptables.
a1ien_n3t
17.06.2016 16:29Если логинется по ключаем под рутом, то тоже можно логировать кто это был.
У каждого админа свой ключ.
Frankenstine
19.06.2016 14:34Если админов несколько и они отвечают каждый за свой «фронт работ», то sudo позволяет разграничить их полномочия так, чтобы они не могли накосячить в «чужой области». Сделать это, если все они логинятся под рутом, просто не возможно принципиально.
iqiaqqivik
17.06.2016 14:31+4Если у вас 20 терминалов открыто, то можно случайно стать заложником “Ой, не то окно, прости, боевой сервер, это было не тебе”. `sudo` на каждый чих — просто еще один барьер, который помешает случайности что-то испортить.
rawsik
17.06.2016 14:37-2барьер не судо,
технически, — правильно вывешенный хостнейм сервера, который однозначно его идентифицирует
организационно, — понимать ответственность.
на автомате можно вбить с судо что угодно.
есть хоть кто-то, с большим и интенсивным опытом работы с серверами, кто хоть раз случайно не вводил команды не в ту консоль? ( как минимум ребут )
поэтому IMO есть понятие деструктивные и недеструктивные команды, надо понимать чем они различаются, и перед вводом первых несколько раз проверить что действительно они нужны и там ли они выполняться.
ganjar
18.06.2016 22:18Для себя сделал следующее — 3 рабочих стола. На первом разработка (код, браузер), на втором локальный/дев сервер, на третьем — продакшн.
Переключаясь на третий стол, я четко знаю с чем работаю и «случайных комманд» там просто быть не может.
acmnu
19.06.2016 15:30+1Да есть. Любой админ с опытом, прекрасно понимает эту ситуацию. За день я открываю консоль на сервер, в среднем 152 раза (я серьёзно, я считал). У меня 100+ хостов, и под 1000 хостов у клиентов, которых мы обслуживаем. В таком потоке легко лажануть. И reboot, известный также как «куищще» это мелочь по сравнению с тем, что может произойти.
Методы придумываются разные: разукрашка терминалов (имеется ввиду выставление фона). Файрволл от самого же себя (прежде чем идти клиенту, я должен зайти на вебинтерфейс и открыть доступ, указав какого черта мне там понадобилось) и все равно, особенно при массовых операция возникают факапы.
Однажды в большой и серьёзной компании за одну держурную ночь произошло сразу два факапа: один склонировал OEBS не туда (перепутал один из тестов с dev инсталяцией), а другой перепутал клиентов (одна буква отличия вроде). Моя смена была следущая и я, как старший наслушался всего (предыдущий старший смены тоже оставался и разгребал). Однажды админ с менеджером перепутали инсталяции (глаз к утру замылился) и «закрыли период» в компании в которой работают десятки тысяч человек. Это значит, что выставились счета, просчитались налоговые деклорации, на кучу принтеров уехало куча бумаги, а самом главному пришел финансовый отчет за квартал. Это был эпичный факап, который разгребала сотня людей: очень сложно провернуть фарш назад и объяснить контрагентам, отделам, налоговой, что та фигня, что пришла к ним утром это ошибка, а реальность будет только на следущей неделе.
Все это наводит любого админа на мысль, что паранои мало не бывает. В первую очередь по отношению к самому себе. Поэтому чем больше мне надо шагов сделать до reboot, тем лучше. И даже после этого я попытаюсь выдохнуть, еще раз прочитать задачу и как минимум сказать ip a (хостнейм совсем не показатель тут). И только после этого сказать в консоль «куищще».
Sudo или su (в Aix и Solaris su выполняет роль sudo) не панацея, но его отсутствие говорит о довольно слабом жизненом и аминском опыте.
baalmor
17.06.2016 14:41Это еще один слой безопасности. Вы можете его убрать или использовать по вашему усмотрению, но это, определенно, риск. На практике, у одного из моих клиентов угнали ключи с его персональной машины. Не будь это ключи к руту, у нас было бы еще время на реагирование. Но с рут доступом атакующий просто спокойно все слил.
И да, опережая возможные сомнения: разграничение прав на сервере для обычных пользователей, в том числе и на чтение — тоже еще один уровень безопасности.savostin
17.06.2016 14:43Так ключ запаролить
можнонужно. Тот же уровень безопасности, имхо.baalmor
17.06.2016 14:55Разумеется, кто же спорит то?
Это как подушки на которые придется падать в случае чьей-то или своей ошибки.
Запаролил ключик — молодец, взломщик задолбается брутфорсить.
Убрал root доступ — молодец, упорный взломщик дважды задолбается ища пути повышения привилегий.
Больше слоев — крепче спишь, меньше цена ошибки, но больше тратишь время на рутинные действия типа ввода паролей или sudo.acmnu
19.06.2016 15:39В openssh есть ssh-agent. Если его обернуть selinux или apparmor, то можно добиться определенного усиления защиты не потеряв в удобстве.
rawsik
17.06.2016 14:43основное преимущество, и задача sudo, как отмечали, это когда администраторов и людей которые имеют доступ больше чем один,
где-то в интерпрасах могут вообще запрещать логиниться под рутом, если это не крайне необходимо.
перевешивание ssh на другой порт это конечно мера, но если позволяет инфраструктура, то у серверов несколько подключенных сетей и отвечают они за разные задачи, есть public network — через которую обслуживаем клиента, есть mgmt network — внутри которой организуется доступ по ssh. при необходимости другие.
относительно доставки ключей на сервера, если их больше 10, 100 и тп, выкладывать ключи пользователей это та ещё задача, поэтому используется централизованный сервер с которого это производится, в идеале привязка к централизованной учётке, чтобы было в итоге,
сотрудник уволился — из одного места удалили, сотрудник изменил ключ — из одного места поменяли.
AlexGluck
17.06.2016 16:09+1Судо критично необходимо если админов больше 1. А перевешивание на другой порт помогает от китайских ботов, хотя я уже даже на домашнем роутере перестал перевешивать порт. Трафик от ботов не такой чтобы с этим гемороится. А так считаю что опытный админ закрывает вход под рутом и прописывает судо баш в башрс, просто потому что это въедается в голову из компаний где больше 1 админа. Закрывать доступ по айпи это супер если у тебя единственная точка входа со статическим айпи, к которой ты подключаешься с помощью сертификатов. И вводить пароли по факту не надо и удобно и безопасно. А чтобы не боятся потерять ключи хранить их надо только в 1 месте на зашифрованном диске(и распечатка в сейфе).
acmnu
19.06.2016 15:41Опытный админ никогда не будет делать NOPASSWD на рута.
AlexGluck
20.06.2016 12:04А про nopasswd никто не говорил. Вместо пароля используется ssh ключ http://blog.towo.eu/authenticating-sudo-with-the-ssh-agent/
acmnu
20.06.2016 13:01Ааа. Вот о чем речь. Я такое не стал делать, поскольку рушится ещё один барьер на пути проникновения. Хотя, конечно, это лучше, чем nopasswd.
sashkin
17.06.2016 15:57+6Если вы с чем-то не сталкивались, это не значит, что это придумали ради усложнения жизни админам. Как мне помнится это стало хорошим тоном после того, как появились атаки на машины в которых хакер получал доступ на сервер копроментируя какого-то пользователя и заливал в доступную скомпрометированному пользователю папку скрипт/бинарник. В то время многие админы сидели как root и в PATH у них для удобства запуска самописанных скриптов был путь ".". В таких случаях хакер мог загрузить на сервер в папку скомпрометированного пользователя файлик с именем типа ls или cd, чем самым тут же перекрывал системные команды админу, либо он мог прикинуться одним из ничего не понимающих пользователей (например хостинга) и попросить админа проверить чего его скрипт helloworld не запускается на сервере. В результате админ сидящий под root сам того не зная выстреливал себе в ногу выполняя зловред со своими правами. Именно с тех пор считается, что сидеть на серверах под root и добавлять "." в PATH очень дурной тон. В домашних песочницах – пожалуйста.
alexkunin
17.06.2016 18:42+2Кроме таких сложностей, как атака с подменой экзешника в PATH, на клавиатуру может прыгнуть кошка, разлиться чай или усесться девушка своей шикарной попой (которую и наказать-то не получится). Ко мне однажды в гости дядя пришел, и со словами «ух-ты, компьютерная мышка!» просто поклацал кнопкой и подвигал мышем, не глядя на монитор. Он удалил несколько уникальных (мною написанных, не помню с чем) файлов с компа. Это была полуось, подтверждение на удаление было выключено, и файлы восстановить так и не вышло (кажется, ФС была HFS+).
А если бы это была рутовая консоль сервера, то хаотичные движения и клики мышью могут выполнить кусок текста на экране под рутом.
fivehouse
17.06.2016 14:31+2Ну и мои 5 копеек. Включайте IPV6 только тогда, когда вы (и ваше сетевое оборудование) полностью сможете удержать этот протокол под контролем. Да, надо будет немного подучиться. Обилие софтовых шлюзов (и разнообразие реализованных способов) IPV4-IPV6 разбросанных вендорами по многим системам по своему усмотрению делают общение с IPV6 во внутренних сетях с выходом в интернет не таким прозрачным.
andkln
20.06.2016 07:16+3А потом останется только поставить за пару минут WordPress или Joomla и чуть-чуть подождать до момента, когда сервер начнёт рассылать спам, подбирать пароли к чужим серверам, хостить дорвей и северокорейский прокси. Потому что в 2016-м основной вектор атаки на веб-сервера — это веб-сайты на популярных CMS, о трудностях защиты которых можно рассказать не одну прекрасную драму.
GreyCat
Какой-то список вредных советов эры эдак конца 90-х. Заставить всех ходить под одним пользователем (и расшарим пароль от него (!) на всех). Whitelist в iptables и sshd доступа по ssh по IP. Разложить ssh-ключи вручную. Умилительно "читать logwatch" каждый день (заняться больше нечем?). И обязательно "длинная и сложная пассфраза".
К счастью, пассаж про "кражу сервера", которая якобы каким-то образом компрометирует приватные ключи ssh и, самое главное, их после этого нужно их "отозвать" (на украденном сервере, что ли?) — это просто ляп перевода, там в оригинале "stolen machine".
ikirin
Я совсем не разбираюсь в теме администрирования сервером, хотелось бы понять, как говориться best practics.
Хотелось бы услышать аргументированный ответ почему подход в статье из прошлого вера и какие сейчас применяются методы.
GreyCat
Да я, собственно, примеры привел.
Заведение одного пользователя на всех — странная практика — я такое видел только в коллективах конца 90-х типа "разработчики сидят на Windows 98", им выдали загадочный и очень редкий "сервер", с которыми никто обращаться не умеет, лучше на него вообще не дышать, единственный что-то знающий человек ("гуру-админ") приходит раз в неделю. Все остальные дружно учат PHP2 или 3 и пытаются делать какие-то сайты. По современным реалиям я не вижу никаких аргументов в пользу того, чтобы не заводить отдельного пользователя на каждого человека: и управление этим всем куда более вменяемое, и аудит безопасности проще и прозрачнее — куда проще понять, кто, что и когда делал.
Фильтрация по IP — опять же, в большинстве случаев бред из эры середины-конца 90-х, когда действительно были какие-то фиксированные IP по организациям и люди сидели и работали строго с работы. По современным понятиям куда администраторам лучше иметь доступ к серверам из любой точки мира (с wifi из кафе), и если что-то случается — иметь возможность зайти и принять меры.
Да если уж на то пошло — в целом любые разговоры о сетях — будь то "зафильтрую по IP", "органичу по VLANу" и т.д. — упираются в то, что бесполезно тупо следовать таким "советам" из "статей" — вопрос об архитектуре сети компании в целом, зонировании, организации каких-то слоев управления, менеджмента сетей, VPNов и т.д. Это весьма комплексный вопрос и крайне наивно думать, что "зафильтрую по IP" что-то решит. В лучшем случае — не решит, в худшем — создаст (зачастую еще хорошо припятанные и оттого больнее бьющие) грабли тем, кому с этим придется работать потом.
Опять же — прописывать вручную фильтр по IP одновременно и в iptables, и в sshd — отнюдь не мера безопасности, а очередная глупость, которая аукнется тогда, когда в следующий раз IP поменяется и очередной админ, которому это "досталось в наследство" сообразит поменять его в первом месте и забудет про второе. Как только одно и то же надо прописывать в нескольких местах — это первый и значительный признак того, что нужно откладывать все эти ручные разборки и нужна уже хоть какая-то автоматизация и configuration management.
Я могу долго продолжать, но надо ли?
dmitrmax
Лучше опишите свои первые пять минут на сервере.
GreyCat
Я не хожу туда вручную и тем более не подхожу к этому с пиететом типа "первые N минут".
В одном (большом) проекте у нас все сервера ставятся, загружаясь в специальной сети по PXE, затем запускается unattended инсталлятор Debian. Настройки сильно зависят от роли конкретной машины и совершенно не похожи на то, как настраивается типичный веб-фронтэнд: подавляющее большинство машин этого проекта вообще не смотрят мордой в интернет, не использует iptables, не настраивает sudo/пользователей/раскладывает ключи (потому что все приходит централизованно через LDAP) и т.п. До загрузки сервера по PXE есть еще предварительный этап, когда надо перенастроить свичи (в основном VLANы) и соединиться с BMC, заказав загрузку из сети. После инсталляции на машину приходит агент configuration management, донастраивая и доустанавливая все по заданному плану.
В нескольких проектах поменьше, хостящихся на типичных облачных провайдерах (Amazon, DO, RS, ...), используется артиллерия поскромнее: просто задание CM на ~70 строчек, который настраивает все, как мне нравится: создает пользователей, раскладывает ключи и т.д. Учитывая, что инсталляции новой ноды на таких провайдерах занимает эдак минуту, плюс еще минуты 3 на то, чтобы отработал этот скрипт CM, в подавляющем большинстве случаев никто вообще не заморачивается тем, чтобы отлаживать какие-то изменения конфигурации — тупо убивают существующую нод(у|ы) и заказывают их создание заново.
dmitrmax
Не сервера кражу, а компьютера, с которого осуществляется доступ на сервер. Ведь на компе хранится приватный ключ.