Прошу прощение, если чем-то обидел. Не могу судить объективно о вашем сервере, может он реально у вас спрятан во внутренней сети, и shh-доступа к нему снаружи нет. Тогда действительно можно сильно не переживать за обновления, говнотрафик на 22 порт и дополнительную защиту.
А на версию вашего OpenSSH указал лишь по причине отсутствия возможности проверить описанные команды на старых пакетах, ограничившись последней реализацией из репозитория Ubuntu 18.04 LTS.
unabl4, как сисадмин могу сказать, что идеально, когда НА ПРОДЕ количество учётных записей разработчиков равно НУЛЮ.
Каждый должен заниматься своим делом: разработчики — разрабатывать, админы — админить.
А по мне так статья не особо полезная. Автор не концентрирует внимание на каком-то одном аспекте безопасности, а прыгает с темы на тему, толком не раскрыв ни одну из них.
Раздел «Изоляция процессов в контейнерах» можно вообще выкинуть (или перенести в отдельную тему и там развёрнуто раскрыть), тут он совершенно ни о чем. Совет упаковать базу данных в контейнер, я бы вообще отнёс к вредным, никогда бы не стал так делать.
В разделе «Сканирование портов» рассказывается только о сканировании изнутри, и ни слова нет про сканирование снаружи.
В разделе «Проверяем наличие опасных значений пользовательского ID» очень скудно описывается команда sudo. Все обозначенные автором проверки сводятся к нулю, если предварительно не проверить конфиг самого sudo.
На схеме видно, что после обмена публичными ключами два узла могут безопасно общаться между собой через небезопасный Интернет.
Кроме того, аутентификация пользователя может производиться при помощи этой самой пары ключей.
«При помощи этой самой пары ключей» ТОЛЬКО АУТЕНТИФИКАЦИЯ и производится.
А безопасное общение узлов происходит за счёт симметричного шифрования с использованием сеансового ключа, который в свою очередь генерируется еще до аутентификации при помощи алгоритма Диффи-Хеллмана.
Спасибо, очень ценное замечание! Действительно, если на один IP установлено несколько сертификатов (SNI), то необходимо указывать опцию -servername для конкретизации домена. В противном случае сервер отправляет сертификат для дефолтного домена.
Подправил.
(legioner, к сожалению, моя карма не достаточно высокая, чтоб плюсануть вам)
Как правило, бесплатные сертификаты Let's Encrypt ставятся на низкобюджетные сайты, где день-два простоя ничего не решают. Сомневаюсь, что владельцы таких сайтов будут тратить силы и деньги на обеспечение безопасности и мониторинг.
При первой же возможности будет исправлено.
ghostinushanka, было бы неплохо, если кроме троллинга вы бы немного про недочёты или ошибки В СТАТЬЕ обмолвились.
Как вы считаете, можно ли ставить в упрёк использование мной опций, которых не было в пакете 5-летней давности?
Пару грамм есть в п.4
;)
А на версию вашего OpenSSH указал лишь по причине отсутствия возможности проверить описанные команды на старых пакетах, ограничившись последней реализацией из репозитория Ubuntu 18.04 LTS.
5 лет не обновлять пакет — наверное, это круто в плане безопасности!
Каждый должен заниматься своим делом: разработчики — разрабатывать, админы — админить.
Раздел «Изоляция процессов в контейнерах» можно вообще выкинуть (или перенести в отдельную тему и там развёрнуто раскрыть), тут он совершенно ни о чем. Совет упаковать базу данных в контейнер, я бы вообще отнёс к вредным, никогда бы не стал так делать.
В разделе «Сканирование портов» рассказывается только о сканировании изнутри, и ни слова нет про сканирование снаружи.
В разделе «Проверяем наличие опасных значений пользовательского ID» очень скудно описывается команда sudo. Все обозначенные автором проверки сводятся к нулю, если предварительно не проверить конфиг самого sudo.
«При помощи этой самой пары ключей» ТОЛЬКО АУТЕНТИФИКАЦИЯ и производится.
А безопасное общение узлов происходит за счёт симметричного шифрования с использованием сеансового ключа, который в свою очередь генерируется еще до аутентификации при помощи алгоритма Диффи-Хеллмана.
Подправил.
(legioner, к сожалению, моя карма не достаточно высокая, чтоб плюсануть вам)