Обеспечение безопасности входа на сервер

Благодаря растущему обилию полезных приложений для самостоятельного размещения, таких как WordPress, и доступному росту поставщиков облачного хостинга, запуск собственного сервера становится все более привлекательным для более широкой аудитории. Но для правильной защиты этих серверов требуются достаточно широкие знания системного администрирования Linux; эта задача не всегда подходит для новичков.

Когда вы зарегистрируетесь в типичной учетной записи облачного хостинга, вы получите электронное письмо с корневой учетной записью, паролем и IP-адресом, а также инструкции для входа через SSH через порт 22. Но важно предпринять несколько дополнительных шагов, помимо базовых. настройки доступа. Этот первый пароль пользователя root на самом деле является лишь отправной точкой для безопасности. Есть еще много чего сделать.

В этом руководстве будет представлен обзор общих поэтапных подходов для защиты вашего типичного сервера Linux.

Подходы к безопасности сервера

Для целей данного руководства я использую новую каплю Ubuntu 14.04 из Digital Ocean с конфигурацией LAMP; Если вы хотите следовать той же конфигурации, примеры шагов конфигурации объясняются здесь .

Как только вы сопоставите выбранное доменное имя, вы готовы начать. Я использую http://secure.lookahead.io для моего примера.

Вы можете войти на свой сервер с помощью SSH: ssh [email protected] . Сервер должен потребовать, чтобы вы изменили свой пароль во время первой попытки входа в систему:

Теперь остальное зависит от вас. Вот несколько общих подходов к улучшению безопасности входа на сервер:

1. Обновите компоненты вашей системы

Во-первых, важно регулярно обновлять компоненты вашей системы Linux. Как правило, когда вы входите в систему, Ubuntu сообщит вам, сколько пакетов у вас есть, которые нужно обновить. Команды для обновления ваших пакетов:

Недавняя уязвимость в Shellshock, обнаруженная в Bash, является прекрасным примером необходимости регулярно обновлять системные файлы.

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

При желании вы можете активировать автоматические обновления:

2. Измените ваш порт SSH по умолчанию

Выход из SSH-доступа через порт 22 позволяет хакерам быстрее и проще ориентироваться на ваши серверы. Давайте изменим порт SSH по умолчанию на что-то более неясное.

Отредактируйте файл конфигурации SSH:

Изменить на другой номер порта, например:

Перезапустите SSH:

Затем выйдите из системы и попробуйте войти снова. Вы должны увидеть это сообщение об ошибке:

На этот раз используйте следующую команду SSH, изменив порт на 33322: ssh -p 33322 [email protected] . Вы должны быть в состоянии успешно войти в систему.

3. Активируйте брандмауэр

Использование брандмауэра может помочь заблокировать доступ к оставленным без необходимости открытым портам и закрыть векторы атак; это может также помочь с регистрацией попыток вторжения.

Если вы используете облачные сервисы Amazon AWS, для брандмауэра есть хороший веб-интерфейс, называемый группами безопасности. Консоль для групп безопасности AWS позволяет легко отключить доступ ко всем портам, кроме вашего нового выбранного порта SSH и порта 80 для просмотра веб-страниц; Вы можете увидеть наглядный пример этого здесь :

Если вы хотите реализовать брандмауэры на основе Linux, вы можете изучить ufw и iptables . Хотя это выходит за рамки этого руководства, я приведу краткий пример использования ufw , «несложного брандмауэра».

Сначала мы ufw а затем разрешим доступ к нашему SSH-порту 33322, а также ко всему http-трафику на порту 80. Затем мы запретим доступ на стандартном SSH-порту 22.

Будьте внимательны при настройке ufw , так как вы можете заблокировать себя из существующего сеанса консоли и всего сервера.

Если вы хотите пойти глубже, стук портов обеспечивает способ более полно скрыть ваш порт доступа SSH. Джастин Эллингвуд (Justin Ellingwood) предлагает подробное руководство для опытных пользователей: как использовать порт-стук, чтобы скрыть SSH-демона от злоумышленников .

4. Измените свое имя пользователя root

Теперь давайте удалим пользователя root (или ubuntu в некоторых системах) и настроим имя администратора.

Мы добавим пользователя с именем «hal». Замените «hal» предпочитаемым именем пользователя в примерах ниже:

Добавьте нового пользователя в группу sudo для администраторов:

Добавьте нового пользователя в группу sudoers. Отредактируйте файл sudoers:

Добавьте эту строку в файл sudoers в разделе привилегий пользователя:

Отредактируйте файл конфигурации SSH еще раз:

Удалите учетную запись root или ubuntu из поля AllowUsers . Вам также может понадобиться добавить эту строку, если ее нет в вашем файле конфигурации:

Убедитесь, что PermitRootLogin выключен:

Перезапустите сервис:

Выйдите из системы и попробуйте войти снова как root. Вы не должны быть в состоянии. Затем попробуйте войти как Hal: ssh -p 33322 [email protected] . Это должно работать просто отлично.

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

5. Активируйте двухфакторную аутентификацию Google

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

Для этого примера мы будем использовать Google Authenticator. Обязательно загрузите Google Authenticator из магазина приложений iTunes или магазина Play .

Затем с консоли сервера установите пакет Google Authenticator:

Затем мы отредактируем Pluggable Authentication Module (PAM) для SSH, чтобы потребовать двухфакторную аутентификацию от Google:

Добавьте следующую строку вверху:

Затем вернитесь к редактированию файла конфигурации SSH еще раз:

Измените ChallengeResponseAuthentication на yes:

Сохраните изменения и активируйте аутентификатор:

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

Используя приложение Google Authenticator на своем телефоне, выберите значок редактирования пера в правом верхнем углу и добавьте новую запись с помощью кнопки внизу. Вы можете отсканировать QR-код вашей камерой или ввести секретный ключ. После завершения Google Authenticator будет готов предоставить вам коды для вашего следующего входа в систему.

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

Перезапустите службу SSH снова и выйдите из системы:

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

Добавление двухфакторной аутентификации добавляет сильный уровень вторичной безопасности на ваш сервер. Тем не менее, мы можем сделать больше.

6. Переключитесь на использование ключей SSH для входа

Целесообразно отключить логин на основе пароля вашего сервера в пользу ключей безопасности; ключи гораздо более устойчивы к атакам. Пароли короткие и подвержены атакам по словарю; ключи длиннее и по большей части могут быть скомпрометированы только суперкомпьютерами правительственного агентства.

Чтобы создать свой ключ SSH, следуйте этим инструкциям. Перейдите в домашний каталог для вашего нового пользователя:

1	cd /home/hal

Создайте каталог SSH и установите разрешения:

1 2	mkdir .ssh chmod 700 .ssh

Создайте новую пару ключей. Когда появится запрос, вам решать, добавлять ли пароль к ключу:

1 2	cd .ssh ssh-keygen -b 1024 -f id_hal -t dsa

Добавьте открытый ключ в файл author_keys:

1	cat ~/.ssh/id_hal.pub > ~/.ssh/authorized_keys

Установите разрешения для файла ключей:

1	chmod 600 ~/.ssh/*

Переместите закрытый ключ во временную папку для загрузки на локальный компьютер:

1 2	cp ~/.ssh/* /tmp chmod 644 /tmp/*

Загрузите новый закрытый ключ на свой компьютер, используя свою учетную запись Ubuntu. На вашем компьютере используйте терминал:

1	scp -P 33322 -i ~/.ssh/id_hal [email protected]:/tmp/* ~/.ssh

Установить разрешения и проверить:

1 2 3

cd ~/.ssh chmod 400 id_hal ssh -p 33322 -i ~/.ssh/id_hal [email protected]

Если вы столкнетесь с какими-либо ошибками, попробуйте просмотреть журнал на сервере AWS при попытке войти в систему:

1	tail -f /var/log/auth.log

Удалите временные файлы ключей из каталога сервера tmp:

1	rm -rf /tmp/*

Отредактируйте файл конфигурации SSH еще раз:

1	sudo nano /etc/ssh/sshd_config

Отключить аутентификацию по паролю:

1	PasswordAuthentication no

Перезапустите службу SSH снова:

1	sudo service ssh restart

Теперь никто не сможет войти на ваш сервер без вашего закрытого ключа. Чтобы войти на свой сервер, используйте следующую команду:

1	ssh -p 33322 -i ~/.ssh/id_hal [email protected]

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

Обратите внимание, что двухфакторная аутентификация Google Authenticator обходится при использовании безопасности ключа SSH.

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

7. Управление безопасностью вашего приложения

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

Но более распространенным примером является недавняя уязвимость плагина WordPress с помощью Slider Revolution . Тема, которую я установил, на самом деле включала этот плагин, поэтому мне пришлось обновить тему, чтобы исправить ошибку.

Сложно отследить уязвимости приложений. Это может сделать возвращение к управляемому хостингу снова привлекательным; не сдавайся! Будьте осторожны с приложениями, которые вы устанавливаете, оставайтесь в списках рассылки для ваших поставщиков кода и регулярно обновляйте все.

Будьте активны и делайте все возможное, чтобы защитить свои приложения. Например, посмотрите, как я описываю добавление защиты пользователей Apache к установке популярного веб-приложения PHPMyAdmin , которое используется для упрощения доступа к базе данных MySQL и ее администрирования. Поскольку доступ к PHPMyAdmin нужен только администраторам, а последствия его взлома высоки, добавление дополнительного уровня защиты паролем вполне подходит для этого конкретного приложения.

Безопасность — это огромная проблема и большая область для борьбы. Надеюсь, вы нашли этот урок полезным. Пожалуйста, не стесняйтесь оставлять свои идеи, исправления, вопросы и комментарии ниже. Я был бы особенно заинтересован в альтернативных и расширенных подходах. Вы также можете связаться со мной в Twitter @reifman или написать мне напрямую.