Pull to refresh

Comments 36

Ну раз здесь такие темы обсуждаются... Расскажите пример атаки на ssh на 22 порту с разрешенным root у которого стоит биологически-псевдослучайный 24 значный пароль. Можно такое?

Можно. И можно жить без ремня в машине, и без антивируса, и без бэкапов — до первой аварии, утечки или rootkit'а. Тут вопрос не в теоретической надёжности длинного пароля, а в снижении вероятностей на всех уровнях.

А все же, пример будет? Мне тоже интересно было бы посмотреть.

Погугли CVE sshd, там тебе и уязвимости, и примеры, и с датами, и с proof of concept. Ну или можешь просто открыть начало статьи, представь, там ссылка на исследование, которое меня и сподвигло всё это выложить.

SSH с длинным паролем это не броня, это просто один вход.
А теперь представь, что у дома кроме двери есть ещё подвал, чердак, вентиляция и сосед с доступом к счётчику.

Речь про regreSSHion? Там же вроде надо практически брутфорс устроить.

ты на правильном пути, помимо него правда ещё много репортов о безопасности в openssh... но ну кому они нужны

Я не берусь говорить за всех, но по-моему опыту, практически всегда сервера ломают методами соц.инженерии (чаще всего письма) и/или через взломанные телеграммы и вацапы, где по рабочим вопросам в сообщениях пересылают как пароли, так и адреса серверов.

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

И от какого конкретно CVE защищает смена порта?

У меня когда возникает острая необходимость VPS развернуть, я ставлю туда Debian, на него INCUS, под INCUS поднимаю OpenWRT и отдаю ему WAN интерфейс.

И больше никаких плясок с бубном, готовый конфиг OpenWRT залить - вопрос пары минут.

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

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

Замечательная статья! Возьму за практику копировать-вставлять команды из статьи при развёртке новых серверов. Будем поднимать статистику! :D

Возьму за практику копировать-вставлять команды из статьи

Как раз статья и говорит о том, что надо перестать так делать и начать д у м а т ь.

Менять порт ssh на нестандартный это профанации, а не защита.

Нужно ограничивать фаерволом доступ к порту ssh по белому списку ip адресов.

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

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

VPN - это сеть. Что конкретно вы предлагаете покупать?

не душись. У плебеев простых смертных понятие прокси и впн к несчастью равнозначное. скорее всего он имел ввиду либо готовую ссылку под http(s) прокси, либо какую то собственную vps с точно белым айпишником

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

ну или просто отдавать провайдеру, чтобы он тебе не менял айпишник....

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

Порт кнокинг в 2к25 уже запретили? 3 рула в айпитейбле сконфигать прям великая работа.

Менять порт ssh на нестандартный это профанации, а не защита.

Хуже от этого не станет, а в связке с tarpit и fail2ban отбивает ботов и осложняет первичное сканирование.

ограничивать фаерволом доступ к порту ssh по белому списку ip адресов

Это не работает если вы не сидите на одном месте.

Для этих целей придумали впн. Ну и port knocking в конце концов.

Для этих целей придумали впн.

А доступ к VPN надо ограничивать по белому списку ip?... По той или иной причине VPN у меня ломался, а вот SSH ни разу. Понятно что есть сервера доступ к которым возможен только через VPN или только из локалки или вообще блокируется физически, но мне кажется такой подход должен быть оправдан.

port knocking

да, но в стандартном putty например не завезли knocking. Я согласен с замечанием в соседней ветке что даже на стандартном порту и с паролем вместо сертификата ssh достаточно защищен, но накручивать защиту поверх можно бесконечно. Те же белые списки можно просто совместить с limit-burst чтобы иметь возможность входа когда сервер брутят, а можно накрутить динамический firewall с репутацией ip.

В чем проблема постучать на нужные порты из cmd, а потом подключаться?

Я тут недавно читал отзывы на гостишку на букинге, так там в списке минусов было: Someone entered into our room without knocking while we were inside. Звучит, как предьява подобного уровня (:

В чем проблема постучать на нужные порты из cmd, а потом подключаться?

Через netcat который надо поставить? Или через telnet который надо включить? Готовый скрипт может лежать в облаке или на флешке, а даже если не лежит - можно написать, чуть дольше, чуть сложнее, в принципе я не вижу проблем как и смысла особого. Если уж человек готов тратить время на ручное простукивание из cmd при каждом подключении - может стоит глянуть в сторону 2fa сперва?

Nmap или похожий порсканнер на менеджмент машину уже не ставят? Или каким образом проверяют открытость портов при косяках, когда у тебя сотня другая вмок? (: заново каждый раз качают? Скрипт для подключения, которому подается хостнейм, написать - 2 минуты

Некоторые Путти билды имеют порт кнокинг нативно. Русская версия так точно. Просто в пример.

Каждый извращается, как хочет по факту. Нормальные люди делают вайтлист онли. Физически прекрасно подключается из гипервизора/ипми и прочего (да хоть через квм или kvm-over-ip сосноль). Мне для инфры нужны субнет внешек L3 отдела в вайтлисте и для фэилсейфа - домашний IP на критичных вещах. Для остального есть гипервизор.

Для любителей повыпускать порты наружу существуют ngfw - софос, пало альто, форти и прочие. Хоть сам собирай.

Для еще остального никто не мешает использовать fail2ban или любую другую альтернативу. Я себе писал когда-то и под иптейблс (на роутерах не было нативного решения) и под микрот фаер кастомное решение с прогрессивным баном в зависимости от портов. Трешхолд в Н попыток - бан на 5 минут (образно). Трешхолд в М попыток - бан на час. Еще попытки, пока в бане - пермач. При понимании работы цепочек фаера, бурстов, кол-ва пакетов и т.п. пишется за пару часов. Работает, как часы.

Нормальные люди делают вайтлист онли.

Нормальные люди сервер в розетку не включают чтобы его не взломали.

Трешхолд в М попыток - бан на час

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

Каждый извращается, как хочет по факту.

С учетом mitm набор портов для knocking должен меняться динамически и вот мы уже запускаем ide чтобы сделать свой putty. Я так и не понял зачем извращаться если можно не извращаться? Допустим на стандартном порту раздражает сканирование от ботов в логах.

Кстати что делать если один из вышестоящих брандмауэров срезает вашу попытку постучать? Хотя с такой же вероятностью он может срезать и ssh с vpn. Речь если что про гостиницы и случаи пусконаладочных на объектах.

А потом несколько дисконнектов на мобильном интернете

Часто менеджите свои сервера из Зимбабве, а не как нормальные: трастовая рабочая станция на работе или RDSка на той же работе. Подключение к ней через тунель по RDP/<любому протоколу на выбор>, а дальше использование ее как джамп ноду для подключения куда либо? (:

Как минимум в офисе есть рабы, которые подёргают твою тачку в любой момент, если там что-то ни алё

если один из вышестоящих брандмауэров

А если в ДЦ электричество пропадёт? А если сервак потеряет IP конфигурацию? А если кто-то не тот ребутнет, а конфиг фаера не сохранили? А если-если-если :)

Допустим на стандартном порту раздражает сканирование

Как будто на кастомных ситуация иная, если нет нормального IPS-а перед серваком? Логи с Пало Альты выдрать? :D Хоть обменяйся портами, один хрен по сигнатурам их ищут.

ну вот так вот, стараешся, пишешь дисклеймеры, а их игнорируют, что статья для только что взятой vps c ubuntu-сервером, как самая попсовая и распространённая...
В такой системе apt отсутствовать не может физически. Если у вас его нет — у вас не Ubuntu, не VPS, и не с коробки :)

Давайте вспомним, что сейчас 2025 год и основной дистрибутив Ubuntu 24.04.

1. Перестанем калечить системный sshd_config и начнем класть свою конфигурацию, в предназначенную для этого sshd_config.d директорию.
2. Изучим и начнем использовать nftables.
3. Начнем генерировать ключи в формате ed25519 вместо rsa.

А дальше погрузимся в изучение "как глубока кроличья нора".

1. Крепко задумаемся о включенном "по умолчанию" IPv6. Будем мы его отключать на уровне ядра и героически побеждать ругань некоторого ПО на его отсутствие. Например Nginx. Или все же аккуратно будем его настраивать на уровне сетевых интерфейсов и nftables.
2. По умолчанию Ubuntu использует ssh.socket. А что будет при срочном обновлении openssh (из-за критического CVE), если вы его перевели в ssh.service?
В документации рекомендовано:
mkdir -p /etc/systemd/system-generators/
ln -s /dev/null /etc/systemd/system-generators/sshd-socket-generator
systemctl daemon-reload
systemctl disable --now ssh.socket
systemctl enable --now ssh.service

3. И чтоб нагнать жути, следим за Changelog. И задумываемся поставить openssh из nobel-proposed.

Спасибо, очень годное дополнение по всем пунктам. Некоторые моменты сознательно упростил под целевую аудиторию, но да — часть из этого точно стоит поправить или хотя бы упомянуть в теле статьи. Учту, внесу. Благодарю.

5 лет несколько серверов у меня стояли с включенным ssh не 22 порту (а еще 23, 24 ...) и мордой в сеть (но с выключеным рутом). И одинаковой парой логин/пасс (по сути это просто клонированные девайсы были).

Непрерывно кто нибудь пытался их брутить а я ждал - когда же, когда же кто нибудь вломится на сервер и убедится что он просто стримит видео с вебкамеры в сеть, и оно публично доступно, может бота какого своего установит. Но к сожалению - этого так и не случилось. Перебирали медленно, всего по несколько тысяч попыток в день, дойти до 9 символьного пароля угадав еще и логин - при такой скорости и за тысячу лет не выйдет. В основном пары логин/пасс - были от каких то девайсов (ну типо seasonik339/default).

В итоге мне надоело вводит пароль и я сделал ssh ключ, разрещив вход только с ним.

Но вообще - как будто ssh если поменять логин и пасс - уже достаточно надежный, регулярно проверяемый и обновляемый инструмент.

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

Sign up to leave a comment.

Articles