Защита Linux-сервера. Что сделать в первую очередь


    Habib M’henni / Wikimedia Commons, CC BY-SA

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

    Содержание



    Нерутовый юзер


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

    Поэтому нужно завести другого юзера, а для рута отключить удалённое администрирование по SSH.

    Новый пользователь заводится командой useradd:

    useradd [options] <username>

    Затем для него добавляется пароль командой passwd:

    passwd <username>

    Наконец, этого пользователя нужно добавить в группу, которая имеет право выполнять команды с повышением привилегий sudo. В зависимости от дитрибутива Linux, это могут быть разные группы. Например, в CentOS и Red Hat юзера добавляют в группу wheel:

    usermod -aG wheel <username>

    В Ubuntu он добавляется в группу sudo:

    usermod -aG sudo <username>

    Ключи вместо паролей SSH


    Брутфорс или утечка паролей — стандартный вектор атаки, так что аутентификацию по паролям в SSH (Secure Shell) лучше отключить, а вместо неё использовать аутентификацию по ключам.

    Есть разные программы для реализации протокола SSH, такие как lsh и Dropbear, но самой популярной является OpenSSH. Установка клиента OpenSSH на Ubuntu:

    sudo apt install openssh-client

    Установка на сервере:

    sudo apt install openssh-server

    Запуск демона SSH (sshd) на сервере под Ubuntu:

    sudo systemctl start sshd

    Автоматический запуск демона при каждой загрузке:

    sudo systemctl enable sshd

    Нужно заметить, что серверная часть OpenSSH включает в себя клиентскую. То есть через openssh-server можно подключаться к другим серверам. Более того, со своей клиентской машины вы можете запустить SSH-туннель с удалённого сервера на сторонний хост, и тогда сторонний хост будет считать удалённый сервер источником запросов. Очень удобная функция для маскировки своей системы. Подробнее см. статью «Практические советы, примеры и туннели SSH».

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

    Итак, для своего нового юзера сначала нужно сгенерировать ключи SSH на компьютере, с которого вы будете заходить на сервер:

    ssh-keygen -t rsa

    Публичный ключ хранится в файле .pub и выглядит как строка случайных символов, которые начинаются с ssh-rsa.

    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ3GIJzTX7J6zsCrywcjAM/7Kq3O9ZIvDw2OFOSXAFVqilSFNkHlefm1iMtPeqsIBp2t9cbGUf55xNDULz/bD/4BCV43yZ5lh0cUYuXALg9NI29ui7PEGReXjSpNwUD6ceN/78YOK41KAcecq+SS0bJ4b4amKZIJG3JWm49NWvoo0hdM71sblF956IXY3cRLcTjPlQ84mChKL1X7+D645c7O4Z1N3KtL7l5nVKSG81ejkeZsGFzJFNqvr5DuHdDL5FAudW23me3BDmrM9ifUmt1a00mWci/1qUlaVFft085yvVq7KZbF2OP2NQACUkwfwh+iSTP username@hostname

    Затем из-под рута создать на сервере директорию SSH в домашнем каталоге пользователя и добавить публичный ключ SSH в файл authorized_keys, используя текстовый редактор вроде Vim:

    mkdir -p /home/user_name/.ssh && touch /home/user_name/.ssh/authorized_keys

    vim /home/user_name/.ssh/authorized_keys

    Наконец, установить корректные разрешения для файла:

    chmod 700 /home/user_name/.ssh && chmod 600 /home/user_name/.ssh/authorized_keys

    и изменить владение на этого юзера:

    chown -R username:username /home/username/.ssh

    На стороне клиента нужно указать местоположение секретного ключа для аутентификации:

    ssh-add DIR_PATH/keylocation

    Теперь можно залогиниться на сервер под именем юзера по этому ключу:

    ssh [username]@hostname

    После авторизации можно использовать команду scp для копирования файлов, утилиту sshfs для удалённого примонтирования файловой системы или директорий.

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

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

    На CentOS/Red Hat находим строку PermitRootLogin yes в конфигурационном файле /etc/ssh/sshd_config и изменяем её:

    PermitRootLogin no

    На Ubuntu добавляем строку PermitRootLogin no в конфигурационный файл 10-my-sshd-settings.conf:

    sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

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

    На CentOS/Red Hat находим строку PasswordAuthentication yes в конфигурационном файле /etc/ssh/sshd_config и изменяем её следующим образом:

    PasswordAuthentication no

    На Ubuntu добавляем строку PasswordAuthentication no в файл 10-my-sshd-settings.conf:

    sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

    Инструкцию по подключению двухфакторной аутентификации по SSH см. здесь.

    Файрвол


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

    Перед установкой файрвола нужно убедиться, что SSH внесён в список исключений и не будет блокироваться. Иначе после запуска файрвола мы не сможем подключиться к серверу.

    С дистрибутивом Ubuntu идёт Uncomplicated Firewall (ufw), а с CentOS/Red Hat — firewalld.

    Разрешение SSH в файрволе на Ubuntu:

    sudo ufw allow ssh

    На CentOS/Red Hat используем команду firewall-cmd:

    sudo firewall-cmd --zone=public --add-service=ssh --permanent

    После этой процедуры можно запустить файрвол.

    На CentOS/Red Hat запускаем сервис systemd для firewalld:

    sudo systemctl start firewalld
    sudo systemctl enable firewalld

    На Ubuntu используем такую команду:

    sudo ufw enable

    Fail2Ban


    Сервис Fail2Ban анализирует логи на сервере и подсчитывает количество попыток доступа с каждого IP-адреса. В настройках указаны правила, сколько попыток доступа разрешено за определённый интервал — после чего данный IP-адрес блокируется на заданный отрезок времени. Например, разрешаем 5 неудачных попыток аутентификации по SSH в промежуток 2 часа, после чего блокируем данный IP-адрес на 12 часов.

    Установка Fail2Ban на CentOS и Red Hat:

    sudo yum install fail2ban

    Установка на Ubuntu и Debian:

    sudo apt install fail2ban

    Запуск:

    systemctl start fail2ban
    systemctl enable fail2ban

    В программе два конфигурационных файла: /etc/fail2ban/fail2ban.conf и /etc/fail2ban/jail.conf. Ограничения для бана указываются во втором файле.

    Джейл для SSH включён по умолчанию с дефолтными настройками (5 попыток, интервал 10 минут, бан на 10 минут).

    [DEFAULT]
    ignorecommand =
    bantime = 10m
    findtime = 10m
    maxretry = 5

    Кроме SSH, Fail2Ban может защищать и другие сервисы на веб-сервере nginx или Apache.

    Автоматические обновления безопасности


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

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

    На CentOS/Red Hat нужно установить приложение dnf-automatic и включить таймер:

    sudo dnf upgrade
    sudo dnf install dnf-automatic -y
    sudo systemctl enable --now dnf-automatic.timer

    Проверка таймера:

    sudo systemctl status dnf-automatic.timer

    Смена портов по умолчанию


    SSH был разработан в 1995 году для замены telnet (порт 23) и ftp (порт 21), поэтому автор программы Тату Илтонен выбрал порт 22 по умолчанию, и его утвердили в IANA.

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

    Смена стандартных портов — обфускация — в несколько раз сокращает объём мусорного трафика, размер логов и нагрузку на сервер, а также сокращает поверхность атаки. Хотя некоторые критикуют такой метод «защиты через неясность» (security through obscurity). Причина в том, что эта техника противопоставляется фундаментальной архитектурной защите. Поэтому, например, Национальный институт стандартов и технологий США в «Руководстве по безопасности сервера» указывает необходимость открытой серверной архитектуры: «Безопасность системы не должна полагаться на скрытность реализации её компонентов», — сказано в документе.

    Теоретически, смена портов по умолчанию противоречит практике открытой архитектуры. Но на практике объём вредоносного трафика действительно сокращается, так что это простая и эффективная мера.

    Номер порта можно настроить, изменив директиву Port 22 в файле конфигурации /etc/ssh/sshd_config. Он также указывается параметром -p <port> в sshd. Клиент SSH и программы sftp тоже поддерживают параметр -p <port>.

    Параметр -p <port> можно использовать для указания номера порта при подключении с помощью команды ssh в Linux. В sftp и scp используется параметр -P <port> (заглавная P). Указание из командной строки переопределяет любое значение в файлах конфигурации.

    Если серверов много, почти все эти действия по защите Linux-сервера можно автоматизировать в скрипте. Но если сервер только один, то лучше вручную контролировать процесс.



    На правах рекламы


    Закажи и сразу работай! Создание VDS любой конфигурации и с любой операционной системой в течение минуты. Максимальная конфигурация позволит оторваться на полную — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Эпичненько :)

    VDSina.ru хостинг серверов
    Серверы в Москве и Амстердаме

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

      –18
      «Файрвол», «Fail2Ban» — вы уж к одному знаменателю приведите. Или «Файрвол», для вас, уже русское слово, а «Fail2Ban» — ещё нет?
        +14
        Да.
        Одно из них общее слово, второе — имя собственное
          +1

          Fail2Ban это не фаервол.

          +19
          Извечный вопрос: зачем отключать root и сидеть из под пользователя с правом повышения до root, если всё равно используются ключи доступа?
          Отключение рута это сомнительная тема применяемая в экзотических кейсах, когда есть несколько равноправных администраторов на один сервер с разными учётками и нужно отслеживать кто что делает.
            0

            Добавление ещё одного администратора не сломает схему администрирования. Удобно, и ничего не стоит. Нужно просто заблокировать root.

              +3

              Хотя бы чтобы самому случайно не накосячить случайно. С точки зрения безопасности по дефолту получается два фактора: ключ и пароль пользователя для sudo. И даже три, если и ключ зашифрован

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

                  Ну не такое уж небольшое, если для sudo пароль нужен и к его вібору серьёзно отнеслись. Вроде как в Linux, например, не было простого способа получить пароль, кроме как серьёзного брутфорса. В Windows был — точно помню пароль делился на две части и каждую можно было брутфорсить отдельно :)

                    +1
                    Ну да пароль для sudo, только брутфорсить. Можно еще мониторить историю команд, на предмет случайного ввода пароля в командной строке :) или поискать скрипты, где он указан явно. А если пароль на sudo суперсложный, значит его где-то хранят. Как-бы не рядом с ключом ;-)
                      +2

                      сороктысячобезьян не такой уж сверхсложный )

                        0
                        Если намеренно добавить орфографические ошибки, подбор будет куда сложнее, потому что по словарю не ловится. Ну и про apg и другие подобные утилиты не стоит забывать: они дают, как мне кажется, очень неплохие результаты как по сложности, так и по запоминаемости. Впрочем, если приходится администрировать много сервером, то пароли всё равно надо где-то хранить и тогда есть смысл просто подумать о таком месте хранения, утечка из которого будет наименее вероятной.
                  0
                  ключ обязательно должен быть зашифрован и лежать в безопасном хранилище
                  –8
                  Тоже всегда напрягала необходимость возиться с правами. Linux — ОС для админов. И у машины должен быть один админ. Если нужно разграничить права доступа — есть Docker, виртуалки, доступ через Веб-интерфейс и подобные технологии. А если доступ к командной строке имеет кто-то, не внушающий доверия, то здесь что-то не то. ИМХО.
                    +8
                    Linux — ОС для админов
                    Есть мнение, что разрабатывали программисты для программистов.

                    Если нужно разграничить права доступа — есть Docker, виртуалки, доступ через Веб-интерфейс и подобные технологии.
                    Для разграничения прав доступа применяется дискреционная или мандатная система разграничения прав доступа. Виртуализация, контейнеризация это немного про другое.
                      –4
                      Для разграничения прав доступа применяется дискреционная или мандатная система разграничения прав доступа. Виртуализация, контейнеризация это немного про другое.

                      Вот понимания этого мне всегда не хватало. Наверное потому, что всегда самостоятельно возился со своими серверами. И именно поэтому контейнеризация как бальзам на душу, поскольку позволяет многое выбросить из головы и начинать с чистого листа с правами root.
                      +3
                      Один админ? Т.е. кто-то всё настроил и нужно дёргать его по любому вопросу, когда надо что-то доконфигурировать?
                        0

                        А когда он уволился/умер сервер выкидывать

                          +8
                          Сервера выкидывать нельзя. Ими может завладеть другой админ. По старинной традиции серверы сжигают вместе с телом покойного админа.
                      0
                      затем что надо делать всё одинаково везде.
                      0
                      Согласен с Вами. В голову приходит только аудит или если в sudo есть ограничения по командам.
                        +3
                        Зачем создавать ключи RSA, если задаем пароль в 40 символов + Fail2Ban с баном на 1-3 часа. Подбор невозможен. Да еще можно определить диапазон адресов, с которых возможен логин.
                        Смена порта — сканером легко определить список открытых портов. Тогда, какой смысл в этом действии?
                        В общем как то про безопасность все как то спорно все.
                          +1

                          "задаем пароль в 40 символов"


                          А вводить его как? Нужен ssh клиент с менеджером паролей. Тогда как с ключом работать умеют все.

                            –2
                            Да, стоит ssh клиент с мастер паролем. Длинный пароль хранится зашифрованным в ssh клиенте. Но ведь и ключ RSA хранится в хранилище. Разница в чем?
                              +3
                              Пока вы единственный администратор единственного сервера с единственным ssh клиентом — разницы нет. А так есть ;). Ключи удобнее.
                              +1

                              Менеджер паролей с настройкой сценариев вполне подойдет.
                              KeePass тот же: вызывает ssh-клиента по клику в парольнице и заполняет все поля сам. Только предварительно нужно сценарий настроить в конкретной записи.
                              И вот у меня вопрос: а как безопаснее, хранить ключ на диске или хранить пароль длинный в зашифрованном виде в менеджере паролей?
                              КМК похитить ключ с диска проще, чем похитить файл парольницы и как то его расшифровать.
                              Или нет?

                                +2
                                На приватный ключ тоже можно поставить пароль.
                                По сути получается примерно одинаково.
                                Разница только в том, что публичный ключ он как раз-таки «публичный».
                                Его можно отдавать кому угодно.
                                Если стоит задача предоставить удаленный доступ, то администратору сервера нужно только взять ваш публичный ключ и прописать его в authorized_keys нужного пользователя. А современных реалиях это чаще делается автоматически, например при создании виртуальных машин или аренде выделенных серверов.
                                Гораздо проще скриптом (системой конфигурирования) раскидывать публичный ключ, чем обеспечивать безопасность даже временных паролей.
                                Более того, невозможно проконтролировать хороший (длинный) ли пароль сделал себе пользователь или нет. Это хорошо, если пароль в 40 символов. Но он может оказаться и 123456. А ключи они уже достаточно длинные.
                                  +1
                                  К тому же KeePass есть плагин, который реализует интерфейс Pageant-а. А с ним под виндой умеет работать уже практически всё. Сам Putty, Far, FileZilla…
                                    0
                                    А с ним под виндой умеет работать уже практически всё.

                                    Но проброс в WSL это отдельные танцы с бубном ))
                                    0
                                    безопаснее — yubikey/Nitrokey или trusted platform module
                                  +2
                                  Ну это если вы готовы пароль в 40 символов вводить каждый раз.
                                  А если нет — то ключи удобнее. Как минимум раскидывать публичный ключ по серверам безопаснее при автоматизации, чем управлять паролями.

                                  Смена порта — от тупых ботов, чтобы уменьшить спам в syslog, про безопасность речи не идет.
                                    0
                                    Ну не знаю — пароль задал, в менеджер паролей добавил, в ssh клиент добавил и запомнил (под мастер-паролем) и все работает. Ни чего помнить особо не нужно. Возможно, я сильно ошибаюсь. Буду благодарен за разрушение моей стройной системы безопасности длинных паролей для ssh.
                                      0

                                      Как вы просите админов других серверов создавать вам аккаунт на их серверах с доступом по ssh? Что делаете, чтобы иметь доступ к одному аккаунту с нескольких девайсов, рабочего и домашнего, например?

                                        +2

                                        Ключ в клиенте сохраняется точно также. Но помимо всего прочего ключ можно безопасно передавать и хранить стандартными способами. А ещё иногда к ssh приходится подключаться не ssh-клиентом, а через тоннель, например в закрытую сеть. Тогда отдельно заходим по ssh на торчащий наружу комп, а потом внутри приватной сети ходим по ключам на локальные сервера.
                                        Просто с ключами — более стандартный и заведомо безопасный подход. С сорокасимвольными паролями — выглядит как велосипед. Пароль задумывался под ручной ввод, и менеджеры паролей — это своеобразный костыль. Ключи задумывались под автоматическое использование из коробки, и их для такой цели использовать правильнее.

                                          +2
                                          Если говорить о безопасности, думаю, самый сильный аргумент против пароля, это то, что злоумышленник может получить и использовать Ваш пароль в дальнейшем, если Вы были невнимательны при MITM-атаке (или при попытке авторизоваться на чужом сервере). В отличие от пароля, в подобных ситуациях злоумышленник не сможет получить Ваш приватный ключ и, например, не сможет выполнить произвольные команды на Вашем сервере.
                                        +2
                                        Ключ нужно создать один раз, менять при компрометации. При логине на ПК делается eval $(ssh-agent -s); ssh-add, вводится один раз пароль от ключа и после этого доступен беспарольный SSH на любой узел, где прописан публичный ключ.
                                        Но я не понимаю, в свою очередь, зачем предлагается fail2ban, если аутентификация по паролю отключается.
                                          0

                                          Сканером да, но много "инструментов" которые сканят заданный список портов. И вот тут измененный порт даст возможность уменьшить вероятность взлома через стандартный порт.

                                            +2
                                            Опять же, если серверов >1, и администраторов >1, то управление этим хозяйством здорово усложняется. А при целенаправленной атаке хакер, не обнаружив ответа на 22 порту, заплачет и убежит ;)
                                              0
                                              Никто и не говорил про целенаправленную атаку.
                                              Речь шла про масс-скан в котором обычно сканят определенный список портов.
                                              Вот в таком случае перенос дефолтного порта — это неплохая идея.
                                                0
                                                Опять же, если вход по паролю отключен — какой вред с этого скана? Ну прийдут китайцы, начнут подбирать пароль (которого нет) от root (который заблокирован).
                                                  0

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

                                                    0
                                                    если найдут


                                                    s/если/когда/

                                                    Ну, и смотря сколько той нагрузки.
                                                    0
                                                    Вам ответили ниже.
                                                    А если это дохлая ВПСка с минимумом ресурсов? Расходовать их на китайцев? Уж лучше я порт изменю.
                                              0
                                              А зачем «пароль в 40 символов + Fail2Ban», если можно просто использовать ключи? Подбор невозможен.
                                              Сам Fail2Ban в настройке то ещё удовольствие, не говоря уже о дополнительной нагрузке на систему.
                                              +1
                                              Ещё есть всякие белые списки, Port Knocking и прочие VPN'ы для защиты ssh и других критичных мест. Кроме инструкции по созданию ключей для ssh, уж очень банально.
                                                +1

                                                Белые списки — да, безопаснее, но не гибко. Что если будет какая-то проблема с сетевой инфраструктурой в конторе, из которой велось управление серверами?
                                                Port Knocking — это тоже не про безопасность (Security Through Obscurity), как и перенос ssh на нестандартный номер порта, а скорее про уменьшение нагрузки на сеть от атакующих ботов.

                                                +8
                                                Использовать в статье типа «гайд для новичка» редактор vim — это сильно…
                                                  –1
                                                  нормально, пусть сразу прокачиваются) для ленивых есть винда
                                                    +1

                                                    Для ленивых(новичков) есть mcedit

                                                  +4
                                                  Какие ужасные и вредные некоторые советы
                                                  Нерутовый юзер
                                                  Начали хорошо. Но зачем ему давать привилегии sudo? Нужен пример? Пожалуйста: через уязвимости злоумышленник получил возможность удалённого выполнения кода от нашего нерутового пользователя. Хорошо, если он просто начал запускать свой скрипт, хотя хорошего в этом мало. Но он может пойти дальше и устроить локальный брутфорс пароля нерутового пользователя. Если у него получится его раздобыть, то дальше у него полностью развязываются руки.

                                                  Ключи вместо паролей SSH
                                                  Дельное предложение. Только лучше использовать более продвинутый вариант с ключом на основе эллиптических кривых
                                                  ssh-keygen -t ed25519 -C "<comment>"


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

                                                  Автоматические обновления безопасности
                                                  Вообще это правильно называется автоматическая установка обновлений. И не всегда эти обновления связаны с безопасностью и не всегда обновления не приносят новых уязвимостей. Некоторые обновления могут приводить к перезапуску того или иного сервиса, а ещё могут вызывать конфликты с другими приложениями. С этим надо быть осторожней.

                                                  Смена портов по умолчанию
                                                  Помогает от тупых ботов, но есть продвинутые, которые, находя открытый порт, начинают проверять его на те или иные ответы. Поэтому лучше использовать более продвинутые методы защиты.
                                                    +1
                                                    Какие есть варианты по последнему пункту?
                                                      0

                                                      Авторизация по ключам + port knocking, и вы уже отгородились от большинства атак.

                                                        0
                                                        Никакие. Зачем трогать порты? Еще бы почитать рекомендацию, по смене портов 80/443 у nginx — чтобы боты не ходили…
                                                        Хотите закрыть доступ? Ставьте fail2ban или ограничивайте доступ по IP. Возьмите себе простую VPS для постоянного IP. Поставьте openvpn и используйте.
                                                          +1

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

                                                            0
                                                            В каком смысле?
                                                            Вот (https://github.com/angristan/openvpn-install) автоматизированный скрипт, чтобы поднять openvpn на сервере. Давайте по пунктам, какие опасности могут быть?
                                                              +1
                                                              автоматизированный скрипт

                                                              Универсальное != безопасное. ИМХО.
                                                                0
                                                                Что именно не безопасно? Давайте по пунктам.
                                                                Скрипт автоматизирует установку пакета, и генерацию конфига — который вы сами также бы сделали (или хуже).

                                                                Тогда давайте говорить, что универсальный nginx != безопасно. Надо свой велосипед веб-сервер писать.
                                                                  0
                                                                  Что именно не безопасно? Давайте по пунктам.
                                                                  1 Совсем не обязательно вести атаку на целевой сервис и заниматься его компроментацией. Можно пойти с другой стороны и устроить DOS стороннего сервиса. Что у OpenVPN защитой от атак на отказ в обслуживании?
                                                                  2 Не стоит думать, что OpenVPN безгрешен и не содержит уязвимостей.
                                                                  3 Есть другой неприятный момент. Он не частый, но бывали случаи и люди на нём накалывались: некоторые провайдеры непонятно по какой такой блажи блокируют этот тоннель. Поэтому есть мануалы, как закосить под HTTPS, работая по OpenVPN.

                                                                  Ещё надо иметь в виду, что некоторые провайдеры последней мили блокируют в своих сетях практически весь трафик UPD (сталкивался неоднократно). В настройках скрипта по умолчанию как раз идёт UDP. Но это не замечание, а просто личный опыт.
                                                                0

                                                                Любые могут быть при запуске башскрипта на 1500 строк с рутовыми правами. Если вы можете этот скрипт проверить на безопасность, то вы и, скорее всего, руками можете безопасно openvpn поднять. А если не можете...

                                                                  0
                                                                  Ну ок, тогда весь софт пишите самостоятельно. Ведь почти любая программа требует повышения привилегий при установке.
                                                                  Или вы полностью просмотрели код linux/nginx/sshd/etc и уверены, что там все безопасно?
                                                                    0

                                                                    Я доверяю авторам и используемым распространителям такого софта типа Canonical, но вот на творчество french software engineering student я бы критическую для компании инфраструктуру завязывать не стал.

                                                                      0
                                                                      АААааа...! вы вообще о чем?
                                                                      Что критическое для компании? Я предложил использовать openvpn для доступа по ssh, если нет постоянного IP. А IP VPN прописать в белый список, кто может стучаться к порту.
                                                                      Где проблема с безопасностью? Или вы думаете, что «french software engineering student» что-то внес в свой openvpn скрипт, что может перехватить зашифрованные данные между вашим ПК и сервером? Даже если на VPN есть вредоносный код, то он максимум что может, это стучать на открытый для этого IP порт и все. логин/пароль/ключ/… надо все равно где-то найти…

                                                                      «Я доверяю авторам и используемым распространителям такого софта типа Canonical»… Пару лет назад уже было, что зайти под рутом, можно зажав какие-то клавиши… Дыры и вредонос может быть везде. Точно ли пакет собран из тех исходников, что вам показывают — вы не знаете, и никогда не узнаете.
                                                                        0
                                                                        Где проблема с безопасностью?

                                                                        Она же одним интерфейсом будет смотреть в защищенный периметр, нет? Или я вашу идею как-то не так понял?

                                                                          0
                                                                          Так проблема с безопасностью в чем? ;)
                                                                          Наличие VPN какие дополнительные риски открывает?
                                                                            0

                                                                            Сервер, настроенный непонятным скриптом, получает доступ в реальную приватную сеть. Или не получает?

                                                                              +1
                                                                              А если скрипт понятный?
                                                                                0

                                                                                Тогда можно настроить и без скрипта :)

                                                                        +2
                                                                        Мне кажется, я понял, что имеет ввиду VolCh Не надо с непонятных репов тянуть скрипты без их понимания, а потом еще и использовать для прода. Доверия распространителям софта больше. Что не отметает фактов, что и там не будет все гладко иногда.
                                                                          0

                                                                          А разве тянуть без понимания это необходимо? Можно стянуть и изучить, возможно, это лучше, чем сразу пилить свой собственный велосипед.

                                                                            0
                                                                            Безусловно нет. Вопрос в доверии к ресурсам и времени на изучение. Свой велосипед — худший вариант.
                                                            0
                                                            Пара вопросов.

                                                            Про нерутового юзера не очень понял. sudo без ограничений — согласен, плохо. Вы об этом?
                                                            Атака скорее будет на повышение привилегий, чем на локальный брут, который по идее по логам детектится. Ну и если делать с норм политикой пароля, брут будет дооолгий. А если совсем убезопаситься, то можно второй фактор сделать, аля yubikey.

                                                            Можно подробнее про автообновление? Я в том плане, что Ваш комментарий скорее про администрирование, чем безопасность. Новые уязвимости в патчах — горькая правда жизни, но всяко лучше оставления известных дыр.

                                                            ИМХО, порты нет особого смысла менять, безопасность через незнание.
                                                              0
                                                              Поясните, пожалуйста, чем плохо sudo без ограничений и без пароля для администратора сервера?
                                                                0

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


                                                                использовать или нет — решать вам, на моих серверах в основном sudo без пароля.

                                                                  0
                                                                  Если учетная запись админа скомпрометирована на сервере, то просто отсылаем его пароль на сервер злоумышленника. Даже не пароль, а приватный ключ, так как в нормальной конфигурации, доступ к учетной записи возможен только по ключу. Остается только дикий вариант с открытым терминалом, оставленным в кафе, пока админ пошел отлить.
                                                                    0
                                                                    Если учетная запись админа скомпрометирована на сервере, то просто отсылаем его пароль на сервер злоумышленника.

                                                                    получить пароль — не такая уж тривиальная задача.


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

                                                                    а в чём принципиальная разница между «злоумышленник получил приватный ключ админа» и «злоумышленник сел за незаблокированный ноут админ»?
                                                                    и там, и там у злоумышленника есть доступ в шелл с правами того админа.
                                                                    sudo -i запросит пароль, получить который ещё надо суметь.

                                                                      0
                                                                      Если я могу выполнить произвольную команду от имени пользователя, то получить пароль можно очень легко.

                                                                      alias sudo='sudo -A /tmp/askpass'


                                                                      Далее, пароль наверняка не qwerty01, а посложнее. Значит, каждый раз пользователь его вводить не будет. sudo будет кэшировать введенный пароль и запрашивать снова только после определенного таймаута. По умолчанию это 5 минут.

                                                                      Тогда сам пароль и не очень нужен. Просто подождем повышения привилегий и воспользуемся.
                                                                      export PS1="\$(sudo -n whoami 2>/dev/null)$PS1"


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

                                                                      Если же вы никогда не используете пароли, то можете образ своего сервера хоть в интернет выкладывать. Злоумышленники ничего полезного для взлома получить оттуда не смогут.
                                                                0
                                                                Пара вопросов.
                                                                Более чем исчерпывающе ответили тут
                                                                От души благодарен за такой развёрнутый и понятный ответ.

                                                                Теперь вам расскажу более жуткую страшилку. Привилегированные доступы к системе сильно не нужны. Иногда совсем. Что мы обычно имеем на рабочем сервере? Процесс или несколько целевых процессов работающих в сеансе некого пользователя (не могу подобрать подходящего слова, буду благодарен, если поправите мою мысль более точно). Получая доступ к этому пространству, получаете доступ ко всем переменным, объявленных в нём (команда printenv). А что у нас там? Там обычно параметры подключения к базе данных, хранилищам, сторонним сервисам и многое к чему.
                                                                Дальше не хочется фантазировать.
                                                                0
                                                                Вообще это правильно называется автоматическая установка обновлений. И не всегда эти обновления связаны с безопасностью


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

                                                                ведь эти обновления надо тестировать в рамках общего flow в компании.
                                                                +2
                                                                Зря про ssh-copy-id не упомянули.
                                                                  0
                                                                    –1
                                                                    Вместо тысячи слов: github.com/topics/cis-benchmark
                                                                      +2
                                                                      Вроде как есть исследования, что смена порта как и смена пользователя практически ничего не дает. Только усложняет работу.
                                                                      Как и супер-длинный пароль.
                                                                      А когда работа усложняется, пользователи ее упрощают(пишут пароль на бумажку, к примеру).
                                                                      Класический пример убунту, где рут заблочен по умолчанию и есть пользователь с теми же по факту правами. Ну он просто называется ubuntu. Ага, ботнеты не вкурсе.

                                                                      Ключи ок, все остальное — в топку.

                                                                      Fail2ban надо понимать, как и firewall. На практике нормально работает только whitelist firewall с современными ботами. В эпоху ботнетов с сотнятми тысяч адресов fail2ban только им помогает.
                                                                        +1

                                                                        "Ключи ок, все остальное — в топку."


                                                                        Угу. Самый надёжный пароль — отсутствие пароля. Невозможно подобрать, не нужно менять. ;)

                                                                        0
                                                                        Стандартный порт менять бесполезно. Раньше помогало, теперь уже неактуально.

                                                                        fail2ban — тоже ни к чему, взломщикам он не помешает, а хозяевам сервера создаст неудобства. По логам видно, что ботнеты специально не заходят с одного и того же IP в течение нескольких месяцев. Блокируй его или не блокируй — ничего это не даст.

                                                                        Я считаю, что у пользователей вообще не должно быть паролей, никаких.

                                                                        passwd -l %username%


                                                                        Вход только по ключам. sudo без пароля.

                                                                        Странно, что никто не предложил selinux включить. А это как раз та штука, которая позволит предотвратить взлом через торчащий наружу сервис.
                                                                          0
                                                                          Я думаю, что не стали рассказывать, тк его и отлаживать приходится и тд. Не отменяя факта, что это одно из самых эффективных средств сдерживания атакующего, когда он уже на серваке.
                                                                            0
                                                                            Я освоил policycoreutils-python, после чего жизнь с selnux-ом стала простой и беззаботной.

                                                                            Сначала setenforce 0.

                                                                            Потом все ставишь, запускаешь.

                                                                            Недельку поработал.

                                                                            sudo cat /var/log/audit/audit.log | audit2allow -M myselinux
                                                                            sudo semodule -i myselinux.pp
                                                                            setenforce 1

                                                                            Все.
                                                                              0
                                                                              Я Вас полностью поддерживаю, просто почему-то не все хотят даже это делать. Вот не знаю, почему.
                                                                              Кстати sudo без пароля я бы сделал при условии наличия пасса на ключе. Тогда и утеря ключа не так критична.
                                                                                0

                                                                                А наличие пасса на клиентском ключе разве можно проконтролировать на сервере?

                                                                                  0
                                                                                  Нет, получается только административная мера.
                                                                                  0
                                                                                  Пароль на sudo ни от чего не защищает, кроме, пожалуй, совершенно дикой ситуации, когда админ открыл терминал и, не залочив, пошел пить чай.
                                                                                    0
                                                                                    Вроде выше писали. Ну слили ключ, а как привилегированные команды исполнять?
                                                                                      0
                                                                                      Например, так

                                                                                      alias sudo='sudo -A /tmp/askpass'

                                                                                      Но способов на самом деле много.
                                                                                        +1
                                                                                        Можно. Просто все эти лишние движения могут привлечь внимание. sudo с паролем же не универсальное средство защиты, а одна из ступеней защиты. Особенно хорошо, если можно делать сильно ограниченное sudo на пару комманд, сверившись с gtfobins.github.io
                                                                                  +1
                                                                                  SELinux шикарен и бесподобен, его долго разрабатывали, обкатывали и внедряли. Это делали люди, в криворукости и говнокодинге которые замечены не были.
                                                                                  Позволяет дела много интересных вещей (несколько пользователей root с разными возможностями). Только утилитой audit2allow надо пользоваться с осторожностью, и внимательно изучать политику, которую она выдаёт. Там иногда бывают просто феерические права доступа.
                                                                                    0

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

                                                                                0
                                                                                fail2ban — тоже ни к чему, взломщикам он не помешает, а хозяевам сервера создаст неудобства

                                                                                Какие неудобства имеются в виду? Я вижу разве что выяснение отношений «кто ввёл неправильный пароль эн раз подряд из нашего офиса» при более одного админа сервера.
                                                                                  0
                                                                                  Если fail2ban блокирует не только 22 порт- недовольных становится значительно больше ;)
                                                                                    0
                                                                                    По умолчанию, если не ошибаюсь, fail2ban мониторит исключительно ssh, всё остальное требует ручной настройки.
                                                                                0
                                                                                На DO есть возможность задать команды, которые будут выполнены при создании сервера сразу, в том числе сразу добавить ключи, включить фаервол и сменить порт. И ничего руками после создания виртуалки делать не надо. Также, я на время первоначальной настройки открываю доступ только с одного ай-пи адреса.
                                                                                  0
                                                                                  Доступ с ограниченного количества адресов и есть практически единственный действующий вариант.
                                                                                  Заведите себе мини-сервачок с включенным по максимум security, port knocking, fail2ban и уже с него заходите на все остальное.
                                                                                  Параноики заводят два таких.

                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                Самое читаемое