Начну этот материал сразу с того, что хоть сколько-то значимого опыта использования Linux у меня никогда не было (так что все нижеописанные мои «ошибки» могут кому-то показаться смехотворными, но дочитайте до конца). Однако после многочисленных новостей об этой системе и куче мемов про сравнение безопасного Linux и «дырявой» Windows у меня сформировалась уверенность, что детище Линуса Торвальдса — это защищённая система, где пользователь контролирует каждую шестерёнку в едином механизме.
Честно говоря, эта уверенность сохранилась у меня и сейчас. Но теперь я воспринимаю данный «факт» совершенно иначе. Впрочем, чтобы не затягивать, перейду сразу к истории.
Я арендовал виртуальный сервер с предустановленной Ubuntu 24.04 и первым же делом решил обезопасить его, заменив SSH-подключение по паролю на доступ по асимметричному ключу и поменяв порт используемого мною сервиса на случайный. Дальше мои приключения можно расписывать в мемах.
Начал я с замены SSH-пароля на ключ, сгенерировал его на своём компьютере, отправил публичный образец на сервер, там отключил в конфиге /etc/ssh/sshd_config вход по паролю и перезагрузил SSH-службу на сервере. Всё прошло гладко.
Но когда я снова подключался к серверу по SSH спустя какое-то время, я забыл парольную фразу (passphrase) для приватного ключа. После трёх неудачных попыток сервер предложил войти… по паролю?! Исходный пароль сработал, я смог войти на сервер вообще без SSH-ключа.
После общения с моими виртуальными и реальными друзьями стало понятно, почему так произошло. Дело в том, что VPS-хостинги позволяют управлять параметрами входа через веб-администрирование сервера, добавлять ключи и всякое такое — если записывать соответствующие настройки в системные файлы конфигурации, то при первом же обновлении службы SSH, если пользователь машинально выберет «Обновить sshd_config» вместо «Оставить без изменений», то параметры доступа к серверу слетят. Из-за этого некоторые VPS-хостинги создают дополнительные файлы конфигурации, имеющие более высокий приоритет, чем дефолтные системные. То есть если в стандартном конфиге и в этом дополнительном конфиге есть конфликтующие правила, то применяться будет настройка из дополнительного конфига.
Такое оказалось и у меня — в системе был файл /etc/ssh/sshd_config.d/50-cloud-init.conf, содержащий только одну строчку:
PasswordAuthentication yes
Ладно, перейдём к закрытию порта, а к обсуждению этого вернёмся позже.
Когда я установил нужную мне программу (теперь в СМИ запрещено упоминать установку утилит такого рода, так что я не буду) и выбрал порт для неё, я уже знал, что подвох может быть в самом неожиданном месте, поэтому после смены SSH-порта на другой я решил заблокировать не только стандартный порт 22, но и порт той моей программы — посмотреть, будет ли она работать в таком случае. Всё это делал через файрвол ufw.
По порту 22 больше нельзя было соединиться по SSH, что радовало, но вот программа продолжила функционировать… Чтобы выяснить, почему это происходит, ушло много сил и нервов (уже изрядно израсходовавшихся на этапе проблемы с входом по паролю). Оказалось, что в конфигурационном файле моей программы есть неприметные строчки:
PostUp = iptables -I INPUT -p udp --dport 12345 -j ACCEPT
...
...
PostDown = iptables -D INPUT -p udp --dport 12345 -j ACCEPT
Первая разрешает трафик по порту при запуске сервера моей программы, а вторая запрещает при выключении. И выясняется, что указанная здесь служба iptables управляет таблицами правил, которые используются ядром Linux для фильтрации пакетов — она главнее, чем ufw. Даже не так, ufw — это интерфейс для удобного взаимодействия с правилами iptables, он просто добавляет туда настройки. Но если в iptables добавлять правила напрямую, они будут считаться системой более приоритетными.
Иными словами, моя блокировка порта 12345 через ufw не работала, поскольку, как оказалось, другой скрипт вносил правила прямо в iptables.
Прозвучит смешно, но именно так я в шутку сообщил приятелям, с которыми поделился своими историями, пока ещё не знал причин такого неожиданного для меня поведения Linux. Я думал, что строчка «PasswordAuthentication no» в системном файле конфигурации SSH запретит вход по паролю, а команда «sudo ufw deny <порт>» запретит использование порта. Но ни то ни другое не сработало. На фоне усталости (в том числе нервной) я и подумал, что вся безопасность Linux сильно преувеличена и на самом деле всё не работает так, как должно.
Помните мою аналогию в начале статьи? О том, что Linux — это большой механизм, каждую шестерёнку в котором пользователь может контролировать. Сейчас я тоже считаю, что это так, но с существенным уточнением: для того чтобы контролируемая тобой шестерёнка действительно влияла на весь механизм, нужно иметь глубокие знания о связи этой шестерёнки с другими деталями механизма — причём далеко не всегда соседними.
По запросу «Как отключить пароль SSH в Linux» ни в одной из статей на первой странице Google нет информации о том, что могут быть некие дополнительные правила, превалирующие над системными. Везде пишут только об изменении sshd_config. И ни в одной не указано, что проверить вход по SSH-ключу нужно не один раз на успех/провал, а три раза на неудачу, до полного отказа службы пустить тебя по SSH к серверу.
По поводу блокирования порта «гуглёж» более успешный — в половине статей на первой странице советуют использовать команды iptables. Но ведь в другой половине говорят о ufw, где приводят только один метод проверки внесённых тобой настроек — «ufw status (verbose)» (этот способ бесполезен, если есть конфликтные правила в самом iptables, ведь о них не узнать по данной команде).
То есть об этих проблемах, которые по случайности заметил я, можно даже не догадываться — всё будет работать, но безопасность продолжить сохранять бреши.
На самом деле, я арендовал не один сервер с Ubuntu, а два, у разных VPS-хостингов. И в каждом из них были свои настройки: какой-то добавляет правила в sshd_config.d, а какой-то нет; кто-то активирует ufw по умолчанию, а кто-то нет. И это только те подводные камни, которые мне посчастливилось распознать, и только в тех VPS-хостингах, которые я использовал.
Более того, я мог не заметить кучи других подводных камней и до сих пор не знать об их существовании, думая, что я что-то обезопасил тем или иным запретом, но на деле этот запрет может не применяться.
Мораль моих историй, как мне кажется, такова — если что-то касается безопасности, всегда нужно самому тестировать те слои защиты, которые ты создаёшь. Причём стараться делать это как злоумышленник, а не как советуют в статьях из интернета по поднятию этих самых слоёв защиты, или хотя бы почитать не менее трёх материалов о той штуке, которую делаешь.
Если ограничиваться только одной статьёй, то будешь натыкаться на мнимые методы проверки — сродни выполнения команды «ufw status verbose», выводящей правила ufw, но не показывающей возможные конфликты в iptables, которые всегда будут решаться не в пользу твоих правил ufw.
