Comments 98
Вот она квинтэссенция:
много людей не понимают что они вводят а просто пользуются Ctrl+C Ctrl+V
@moderator по ссылке на рег.ру рефералка, это нормально?
Fixed. @guselnikovэто нарушение правил. Пожалуйста, больше не нарушайте.
VPS на REG.ru необходимо поменять еще и в файле
/etc/ssh/sshd_config.d/50-cloud-init.conf
На мастерхост тоже.
Есть примета:
Удалённая настройка файрвола - к долгой дороге.
Но на самом деле есть простой лайфхак:
прежде чем фиксировать новую конфигурацию в конфигах - сделай так:
shutdown +10 -r
...
у тебя есть 10 минут на эксперименты с файрволом
...
shutdown -c
И только потом сохранять....
Можно гораздо проще: iptables-apply.
iptables-apply will try to apply a new rulesfile (as output by iptables-save, read by iptables-restore) or run a command to configure iptables and then prompt the user whether the changes are okay. If the new iptables rules cut the existing connection, the user will not be able to answer affirmatively. In this case, the script rolls back to the previous working iptables rules after the timeout expires.
Полезная команда, спасибо! Думаю на всякий случай перед применением лучше ещё открытие новой ssh сессии проверять :)
Но не настолько универсальная )
Это еще со времен админства FreeBSD, там кстати намного проще и понятнее файрвол сделан, и то можно было накосячить.
Я сначала ставлю в крон каждые 5-10 мин скрипт очистики файера и установки accept для моего адреса в инпуте и только потом приступаю к настройке.
У хостеров есть кнопка ребута vps в панели управления. Достаточно не фиксировать изменения в постоянную конфигурацию, а сначала проверять их без сохранения.
На самом деле у каждого хостера должен быть сервис, который ходит по ресурсам клиентов через внешку и сканирует их на наличие большого количества открытых портов, CVE уязвимостей и прочего. После чего отправляет владельцу отчёт и ссылки на wiki, как это можно исправить.
Большую часть проблем можно будет исправить таким способом.
Вот тут человечка уже приняли за то, что он посканировал там у себя на работе всяких клиентов а одним из них оказался оборонный завод :-)
Человечек, насколько помню, не просто сканировал сеть, а ещё и пароли подбирал к найденным сервисам и эксплоиты разные пытался использовать. По крайней мере, та программа, которой он якобы пользовался, именно так работает.
А как на ваш взгляд выглядит поиск уязвимостей? Ну хотя бы проверить 10 самых распространенных паролей
Поиск уязвимостей, как минимум, требует согласия владельца. Иначе в таком варианте он ничем не отличается от попытки взлома.
Вот, допустим, вошли вы в магазин и начали пытаться открывать витрины - вдруг не заперто - и пробовать к ним универсальные ключи - дыра в безопасности же. На вас точно так же заявят куда надо.
Напомнило: я когда-то получил на контактный адрес нашего домена письмо в стиле "наш firewall зафиксировал пакет с айпишника какого-то, это один из ваших IP-адресов, срочно найдите, кто из ваших пользователей его отправил, и передайте контакты этого клиента ФСБ, противном случае я сам напишу докладную ФСБ, и данные затребуют уже они". Ну и копия письма сразу направлена была на info@fsb.ru, вроде того. На отправленный в ответ вопрос, почему пакет (один пакет!) нельзя послать с одного IP-адреса на другой IP-адрес (ну правда, закон-то об этом ничего не говорит) в пределах сети интернет человек ответил, что он является системным администратором в одной из серьезных госкомпаний, и у них принято рассматривать такого рода пакеты как признак атаки. Приказом, так сказать, по компании, а не вот эти ваши RFC.
Грамотность он не отличался, зато энергии было хоть отбавляй. Если его руководство было примерно так же грамотно, то они, конечно, могли и премию получать за количество отбитых атак. Ну и конечно, писать докладные на руководство, что "вот такое количество уведомлений разослали, и вот по такому количеству дел ФСБ проводит проверки".
Так вот тогда это было смешно. Теперь, понимаю так, сравнимо грамотный подход позволяет ещё и принимать до выяснения белых хакеров, а дальше - как кривая вывезет? Причем, на самом деле, В таких историях интересно всё: и доказательств как бы нет (есть только распечатки каких-то циферок на каких-то бумажках), и судьи абсолютно не знают тему, исследователи не знают тему, но есть общее ощущение что О-О-О-о-о-о, это очень серьёзно, надо примерно наказать, да и начальство похвалит. Такими темпами, трафик наружу компании можно выпускать только по очень ограниченному списку портов получателя (80, и хватит, да, товарищ директор?). А если не поможет то только по списку IP, правда?
Ну так это может быть частью сервиса прописанного в договоре.
Сделать специальную кнопку "составить отчет по безопасности" с отображением прогресса и прочего, не пускать наружу пока проверка не пройдена (для особо упорных добавить красную кнопку "да я хочу стать частью ботнета"). Куда проще?
Но это должна быть отдельная платная услуга по желанию.
Нефиг по моим ресурсам шариться.
Я прячу все за обратный прокси, и блочу по спискам, или белым или чёрным, от сервиса зависит, или задачи, например по geoip, для РФ открыт доступ на 443 порт а остальным нет. Для 80 порта открыт доступ для Европы и США для запросов LE. С geoip есть конечно сложности бывает что сеть не присутствует в листах, тогда добавляется вручную.
Использовать ctrl+c ctrl+v, не понимая, что скопировали - ну это же просто скучно
У меня белый IP, поставил себе на микротике fail2ban правилами firewall, срабатывает на сканирование самых популярных портов, список бана километровый за сутки набирается.
Все сервисы убрать за vpn и никаких проблем. (Это, конечно, не так, но цену взлома поднимет достаточно для защиты от массовой атаки)
И иметь проблемы доступа потому как vpn`ы блочат :(
у меня более грустна история была. еще до всех этих плясок с блокировками, в теплые ламповые времена. МСК-СПБ, 2 офиса. между ними gre-тунель, все счастливы. офис МСК переезжает. и... туннель на новом месте не поднимается вообще. оказалось, что в новом маршруте появился новый бэкбон, который все эти ваши туннели не любил так, что кушать не мог. т.е. тупо резал GRE без объяснения причин
И опять ни слова про то что надо просто поставить вход по ключику. Это гарантирует полную безопасность.
Приличные сервисы сразу делают машинки со входом по ключам и предлагают прямо перед создание показать свой публичный ключ. Верю что когда-нибудь все сервисы будут такими. Возможность дефолтного входа по паролю будет спрятана кликов за 5. Для тех кому непонятно зачем очень надо.
Это не гарантирует что не будет зияющей дыры по какому то другому протоколу с паролем password.
Вообще - вспоминаю вот свой недавний случай, необходимость экстренного переключения на резервного провайдера, туннели к виртуалке не коннектятся. Вспоминаю что там фильтр по IP кто может поднимать этот туннель...и кто может подключатся через Winbox(SSH вообще жестко урезан). Вообще пришлось через виртуальную консоль у провайдера добавлять правило. Было сильное желание вообще рубануть фильтры :( (если что - Winbox в подключение по ключу - не умеет а в данном случае это основное средство управления)
Можно сценарий с брутфорсом ключа?
А это может быть проблема не с SSH, на сервере же может быть и что то кроме ssh, что либо не должно светится за пределы localhost но светится(БД или там redis какой) либо просто кривая авторизация и панель светится всем.
Да, ключи SSH нужны но это - недостаточно.
В контексте статьи - уж лучше Outline/Amnezia с их подходом "вы НАМ доверяете? дайте доступ на сервер - мы сами нормально настроим" чем статьи которым совсем бездумно следуют. Другое дело - тут упирается в доверия уже к авторам той же Outline/Amnezia, что они не сделают чего не надо и что сами достаточно компетентны. Да, проблема с тем как учится тем кто хочется учится но пока не может нормально...
Речь конкретно про SSH. Для SSH ключ и запрет входа по паролю защищает от брутфорса, потому что 4096 битный ключ просто не забрутфорсишь физически.
И это важнее, чем смена порта, потому что перебрать 65 тысяч портов реально, если хотеть.
Смена порта и fail2ban уменьшат количество мусора в логах и ещё немного поднимут безопасность, но ключ это основная мера дающая 99% защиты. А в статье упомянута лишь косметическая вспомогательная мера.
Для других сервисов другие правила безопасности. Если на хосте есть условный php скрипт с system($_GET["command"]), то SSH может вообще не быть, а дырка будет.
Другая поверхность атаки. Даже если ключ без пароля, чтобы его утащить, нужно поломать машину админа. У которой может не быть ни ssh, ни внешнего ip. Это не невозможно, но риски ниже.
Безопасность 5 лет тоже лучше, чем небезопасность уже сегодня.
Главный пойнт в том, что в статье представляется как основная мера безопасности смена порта. А это вспомогательная мера. Основная мера это использование ключа.
Можно сценарий с брутфорсом 16-символьного рандомно сгенерированного пароля с цифрами, регистром и спец. символами?
Можно сценарий использования подобных паролей? Как вы их храните, как набираете.. Что предпринимаете, если пароль нужно сменить. Допустим, у вас не 1 сервер, а целых 2, или даже 3.
Как вы их храните, как набираете..
KeePass, который сам уже под ключом на токене.
Что предпринимаете, если пароль нужно сменить.
Эм... passwd?
Допустим, у вас не 1 сервер, а целых 2, или даже 3.
Хоть 3, хоть 33 - разницы никакой. Вот когда 333 - тогда уже надо думать.
KeePass
Это работает прозрачно с ssh/scp/sshfs/скриптами автоматизации на python/mc/dolphin/git/100500 других приложений, использующих ssh?
Чем отличается скармливание скриптам ключа от скармливания тем же скриптам пароля в открытом виде?
Прозрачно.
Благодаря магии ssh (или ssh-agent) всё работает прозрачно.
Эта прозрачность никак не влияет на конечную безопасность, которая в обоих случаях сводится к тому, есть ли у злоумышленника доступ к машине, на которой используется ключ либо пароль. Никакой магии нет.
Впрочем, это всё равно это попытка увести обсуждение от изначального вопроса, в котором речи об автоматизации не шло. Для автоматизации ключи просто удобнее, и всё.
Ключи просто удобнее. Они работают из коробки, нет необходимости в сторонних подпорках.
Для автоматизации - да, удобнее. Для ручного доступа - ну такое. Мне с кипассом куда удобнее. Разницы в безопасности практически нет. С одного вектора ключи могут быть незначительно безопаснее, с другого так же незначительно пароль в кипассе - от обстоятельств зависит.
ssh-agent существует
Ну попробуйте мне убедительно доказать, что ssh-agent удобнее для не-стационарных вариантов использования.
Он хранит ваш ключик в специально предназначенном для этого месте. Он прокидывает ключик дальше на следующий сервер. Он просто стандартен и всё знают как с ним работать.
Вы строите какое-то костыльное решение вместо отраслевого стандарта.
Я строю удобное мне решение для моих целей, и отвергаю попытки убедить меня в том, что оно менее безопасно "отраслевого стандарта", что, вообще говоря, чушь собачья. Отраслевой стандарт это только в крупных стационарных инфраструктурах.
Безопасность вещь сложная В вашем случае, возможно, оно и не хуже использования ключей. Ключи (публичные ) всегда лучше хотя бы тем, что их можно передавать по любым каналам связи. А приватные не нужно передавать никогда
Безопасность вещь сложная В вашем случае, возможно, оно и не хуже использования ключей.
Собственно, это то, что я хотел сказать изначально - голову надо прикладывать сообразно ситуации, а не бездумно опираться на некоторые общие практики, заведомо шельмуя всё, что от них отличается. Бездумное следование общим практикам ничем не отличается от ритуалов.
Ключи (публичные ) всегда лучше хотя бы тем, что их можно передавать по любым каналам связи.
Это замечательно, но это не про аутентификацию. Публичный ключ сам по себе никакой магией не способен позволить однозначно аутентифицировать пользователя, ровно потому, что он публичный, и всё всё равно упирается в закрытый ключ, либо пароль. Ключи больше про различные методы хендшейков по большому то счёту.
Передача пароля через ssh в общем и целом достаточно безопасна, чтобы не проводить существенных различий между использованием пароля и аутентификации по ключам.
Использование ключа на SSH никак не гарантирует полную безопасность хоста. Также есть риск не попасть в систему, потому что даже 256 бит в голове держать невозможно, не говоря уж о 4096. А вот 10-12 клавиатурно набираемых букв-цифр-спецсимволов или даже 12-16 только букв нижнего регистра вполне реально удержать в голове.
fail2ban и/или port-knocking вполне способны сильно улучшить защищённость хоста. А вот смена порта из статьи -- совсм никак не поможет.
На последок хотелось бы сказать самые простые и примитивные вещи [...]
Не думаю, что люди, которые копипастят гайды, способны просто взять и последовать вашим рекомендациям. К тому же они не бесспорные. Вместо всего этого я бы рекомендовал неопытным админам, которым просто нужна виртуалка для VPN:
не трогать дефолтные настройки sshd и фаервола, они совершенно нормальны из коробки,
если по какой-то причине ваш хостер настроил авторизацию по паролям, поставить на рутовую учётку хороший пароль из 30+ случайных символов.
А чего только на рутовую? Некоторые установочные скрипты, ну или например yay предполагают запуск от пользователя, но потом требуют повышения прав, чтобы закончить работу. Таким образом хочешь - не хочешь, а приходится себя в sudoers добавлять. И мне почему-то кажется, что у многих пользовательская учетка в sudoers без ограничений прописана.
>На последок хотелось бы сказать самые простые и примитивные вещи: меняйте порт ssh на любой другой, настраивайте файрволл и желательно ставьте на input drop. Отключите авторизацию по паролю
И чем эти рекомендации отличаются от ctrl+c ctrl+v? Зачем это надо делать? Что конкретно даст смена порта, настройка фаервола и отключение авторизации по паролю?
Смена порта не дает вообще ничего. 64 тысячи вариантов перебираются бесплатно. Можно не морочиться.
Фаерволл по дефолту имеет нормальные настройки. Тоже можно не морочиться.
64 тысячи вариантов, конечно, легко перебираются, но это если осуществляется атака конкретно на Ваш хост. Если же Ваш IP выпал случайно в результате "стрельбы по площадям", то нестандартный порт серьезно уменьшает вероятность взлома - заморачиваться с перебором портов на случайном IP взломщику менее рентабельно, чем с той же затратой ресурсов перебрать еще несколько десятков тысяч случайных IP.
Он вообще не уменьшает ничего. 64 тысячи вариантов это настолько мало что такое не надо учитывать. Безопасность строится на других порядках вариантов перебора.
Это не один взломщик. В мире более чем достаточно ботнетов, чтобы непрерывно сканировать все порты всех существующих IPv4-адресов.
Какая разница, один он или 9000? Есть топ портов для взлома, их сканят больше, чем остальные. Большинство сканящих ботов - тупые скрипты китайского/негритянского/снгшного школоло. Потом найденое по десять баксов мешок продают на хацкерских сайтах. Черной шляпе проще купить готовые отфильтрованные хосты за копеечку, чем палить дорогущий ботнет на тупом сканировании...
Если поднять ssh на 22 порту, и на 47399 - на 22 будет гиг логов в месяц, на рандомном - пару десятков записей. Я лично это проверял. Собственно, перенесенный порт позволит нашему хосту не оказаться в тех же списках для брута дедов.
Фаерволл по дефолту
настроек не имеет, кхе
Дефолтный пароль на ssh? Даже самые упоротые хостеры делают рандомный пароль. Этого пароля более чем достаточно что бы боты с пингом <1мс долбились до тепловой смерти вселенной.
Дыры обычно оставляют вполне понимающие люди, просто случайно забыли, например сделал себе сокс5 сервер без пароля, думал что на него можно будет зайти только через впн, но из за мелкой ошибки в конфигах он стал открыт наружу, через полчаса его уже весь интернет юзает с такой интенсивностью что ты не можешь сам через ssh зайти на сервер и потушить.
Насчёт вопроса - по-моему, если включить conntrack, то он проанализирует и пометит новые соединения, а уже существующие он не поймёт. И в итоге мы сами себя забаним.
Но, судя по большинству ответов, я что-то не так понимаю?
ESTABLISHED, RELATED -j ACCEPT
Существующие соединения - примет. Следующее правило не сработает.
ESTABLISHED — соединение установлено, пришел уже не первый пакет в рамках этого сеанса, это значит что все соединения что уже установлены будут разрешены (ACCEPT) и дальше по цепочке правил не идут.
Сами себя, безусловно, забаним, но не прямо сейчас
А, я, кажется, понял, почему вам не понятно.
Фаервол не занимается отслеживанием соединений, conntrack работает до него и независимо от него. Так что фаерволу всё равно, в какой момент времени применять новые правила.
Замах был на рубль, "я увидел в рекомендациях дурацкую статью". Читатель уж думает, сейчас ему напишут хорошую. А внутри ему открывают глаза на сканирование портов и ключи в репозиториях. Ну офигеть какая новость. А потом и вовсе выясняется, что всё затевалось ради реферальной ссылки.
И сама статья, и - особенно - вывод её хомячками в топ - это какой-то позор.
Основная мера защиты это использование ключа на SSH, которое вообще не упомянуто в статье. А эта мера в целом достаточная и основная.
А потом уже fail2ban и смена порта, если хочется иметь более чистые логи и ещё снизить риски.
А самое примечательное то, что в 2025 у любого нормального хостера виртуалки автоматически настраиваются на вход по ключу и в sshd_config вообще лучше не лезть, если не знаешь, что делаешь. Лучше почитать по разные виды ключей и их защиту паролем.
И про другие сервисы. Потому что на нормальном хостере и актуальном дистрибутиве сломают скорее всего не через ssh (если юзер руками не включил вход по паролю), а через cms или ещё что-то.
Использование ключа на SSH для хорошей безопасности хоста не является ни достаточным ни необходимым. Также есть риск не попасть в систему, потому что даже 256 бит в голове держать невозможно, не говоря уж о 4096. А вот 10-12 клавиатурно набираемых букв-цифр-спецсимволов или даже 12-16 только букв нижнего регистра вполне реально удержать в голове.
fail2ban и/или port-knocking вполне способны сильно улучшить защищённость хоста. А вот смена порта из статьи -- совсм никак не поможет.
Давайте я вернуть в тред.
Ключи являются необходимым и достаточным способом защиты сервера. Не софта на сервере (особенно смотрящего в сеть) не ноута админа, не самого админа. А именно сервера.
Ключи кроме это являются самым удобных из всех безопасных способов защиты ssh.
Все остальное для защиты сервера не нужно и является лишним. А все лишнее стоит сносить с серверов, нечего болото разводить.
не всегда это делается в файле
/etc/ssh/sshd_config
Не на рег, но тоже встречал такую подставу. Не понимаю зачем они это делают
меняйте порт ssh на любой другой
Это помогает, но временно.
Типовая история:
Новый порт.
Через пару дней в логах начинают появляться записи, что кто-то трогает за этот порт.
Через еще несколько дней уже попытки доступа, f2b по паре-тройке адресов в день начинает банить.
Через полгода-год начинается брут-шторм, когда попытки коннекта идут по несколько сотен в день. При этом, поскольку доступ только по ключу, происходит сразу характерный отбив попытки. Но они продолжают лезть с логином/паролем, мамкины какеры блин.
Переходим на п.1.
Новый порт.
Через пару дней в логах начинают появляться записи
Через пару? Я никогда не ставлю RDP на дефолтном порту в интернет - и всё равно боты начинают ломиться практически моментально.
Может быть кто-то специально следит за адресом вашего сервера? Просто физически невозможно постоянно рилтайм проверять все адреса на всех портах.
Кстати, можете попробовать сделать ханипот на дефолтном порту и сразу банить если его кто-то потрогает. Тут даже никакой доп. софт не нужен, просто в iptables логировать с уникальной строкой и по ней рулес в f2b.
Хостер таймвеб. Не помню чтобы настраивал f2b. Стало интересно, пошел проверять.
Status for the jail: sshd
|‑ Filter
| |‑ Currently failed: 3
| |‑ Total failed: 120 243
|‑ Currently banned: 125
|‑ Total banned: 4725
7 месяцев аптайма. Bantime - 1d. Делаем вывод, что за сутки примерно с сотни ip адресов по 6 попыток происходит.
120 243 попыток за 7 месяцев. Это же ни о чем, с такой скоростью подобрать пароль даже со словарем... Ну хз.
Но больше того, доступ по паролю то отключен...
Какая бездарная трата ресурсов.
Обращать внимание на каждую попытку трогания порта - всё равно что считать дождевые капли.
Бесполезно и ничуть не защитит от промокания.
Можно запретить вход под рутом, и сделать отдельного юзера для входа. Как после этого брутфорсить не зная юзера?
Как после этого брутфорсить не зная юзера?
точно так же, только одновременно с подбором логина. user, admin, что ещё было в том туториале по которому сервер настраивали?
а разве не все так делают? )
Ну, правда там тоже есть admin, user, qwe, webadmin, и еще несколько распространенных.
Мало кто назовется gfgseffgg22...
Теперь будут проверять ;)
Сисадмин желал подобрать себе стойкий пароль для централизованной авторизации через radius-сервер. Он обратился за советом к Инь Фу Во.
– Как вы думаете, Учитель, пароль «史達林格勒戰役» стойкий?
Нет, – ответил мастер Инь, – это словарный пароль.
– Но такого слова нет в словарях...
– "Словарный" означает, что это сочетание символов есть в wordlists, то есть "словарях" для перебора, которые подключаются к программам криптоанализа. Эти словари составляются из всех сочетаний символов, которые когда-либо встречались в Сети.
– А пароль «Pft,bcm» подойдёт?
– Вряд ли. Он тоже словарный.
– Но как же? Это же...
– Введи это сочетание в Гугле – и сам увидишь.
Сисадмин защёлкал клавишами.
– О, да. Вы правы, Учитель.
Через некоторое время Сисадмин воскликнул:
– Учитель, я подобрал хороший пароль, которого не может быть в словарях.
Инь Фу Во кивнул.
– Я ввёл его в Гугле, – продолжал Сисадмин, – и убедился, что в Сети такого сочетания нет.
– Теперь есть.
У меня на одном из серверов только рут и вход только по ключу с определенным набором алгоритмов. Удачи в брутфорсе =)
На последок хотелось бы сказать самые простые и примитивные вещи: меняйте порт ssh на любой другой, настраивайте файрволл и желательно ставьте на input drop
А существуют какие-то сторонние файрволы?
Виндовый для своих сервисов ничего не спрашивает (понятно, почему), зато популярный 3proxy зарубил (тоже молча). А я бы вот хотел, чтобы файрвол меня спросил при первой попытке подключения и о том, и о другом, и я бы разрешил 3proxy и запретил всю телеметрию.
Port-knocking решит проблему тех кому ключи по какой-то причине не подходят.
Это можно сделать и на циске и на микроте и на Линуксе конечно.
По поводу того, как правильно и безопасно настраивать свой впс, написал один товарищ прям очень хорошо и подробно. Насколько я знаю, кидать ссылки на чужие гитхабы пока что не запрещено ни правилами, ни законом, поэтому делюсь ссылочкой на человека
https://github.com/EmptyLibra
То о чем многие молчат, или может не знают…