Комментарии 98
Изменил одну настройку fail2ban. А именно, бан на месяц тех, кто трижды ошибся. Пароль 19 символов, буквы разного регистра, плюс цифры и символы. Я в опасности?
Но я хожу по rsa, а вход по паролю оставил на всякий случай, вдруг потеряю ключи.
Что до ошибок, то после первой ошибки начинаешь набирать очень внимательно.
Но вход по паролю вы же все равно оставили — значит остается возможность брутфорса.
f2b может быть неэффективен в случае использования большого ботнета. И, насколько помню, там были какие-то проблемы с ipv6. Возможно тут лучше еще добавить ufw limit 22/tcp или аналогично через iptables.
На случай потери всех копий зашифрованного бэкапа ключей можно загрузить сервер с livecd / rescue и поставить новый ключ.
Но пароль же 19 символов (на самом деле больше, конспирация), буквы разных регистров, цифры и знаки. Чтобы его сбрутить, из расчета три попытки в месяц с пары тысяч ip, времени понадобится ну очень много же.
Плюс если пароль не уникальный и не случайный, то шансы еще повышаются.
По ipmi/kvm/iLo/любая консоль облачного провайдера.
Вообще по уму — смена пароля root должна делаться через автоматизированную систему управления конфигурацией.
По паролям. Ещё очень частая история — синхронизация учеток через LDAP/ActiveDirectory. В этом случае успешный Брут пароля пользователя даёт возможность беспрепятственного использования любого Корп.сервиса под его учеткой. Лучше уж по ключам ходить.
Я на обычные сайты ставлю пароль в 25 символов, при возможности.
А более важные, если позволяет, то в 250 :)
Правда, менеджер паролей.
Да, можно возразить, что пользуйтесь ВПН, но это такое себе…
В реальности — это всегда компромисс, и неверно определив его, вы теряете в безопасности.
1) Длинный и сложный пароль? Значит он наверняка записан где-то на бумажке или каком-нибудь сайте-блокноте. И может потеряться. А может и «подглядеться».
2) Жесткая политика банов — раз в год и палка стреляет. Например, неудобно решать проблему на сервере с телефона, значит, может быть сядете за чужой комп (доверенный, хорошего человека). Но там нет ключей и с трех попыток и сами ошибетесь.
3) Непредвиденные проблемы — у них есть гадкое свойство — они непредвиденные. Например, какой-то кривой пакет SSH в обновлении, или уязвимость в алгоритме генерации ключей, из-за которой после обновления ssh сервер перестанет опознавать ваши ключи (да, дурное решение, но программист вот не подумал и сделал). И вот вы сами входите по паролю снова и делаете 3 ошибки.
Но можно с другой стороны идти. Не от шаблона своего поведения, а от шаблона атаки. Блокировка на один час — уже достаточно, чтобы предотвратить большинство брутфорса. Есть ли разница, подберут пароль за время в триста миллиардов раз больше времени жизни вселенной или всего лишь за 50 лет? Короткая блокировка безопаснее при ложном срабатывании, но дает достаточную (50 лет) защиту от брутфорса.
И еще такой момент — если у сервера есть альтернативный доступ (например, для VPS — это консоль сервера из админки у хостера, или просто ваш аккаунт у хостера, через который можно заказать визит в ДатаЦентр вплоть до того чтоб вытащить сервер из рэка и увезти домой) — то самые параноидальные методы дадут только побочные минусы, но прочность цепи по прежнему будет равна прочности самого слабого звена.
А там весь набор символов, где много 0 или О или I или l — меня прям гордость берет за параноиков.
Кстати, идея кажется хорошей. ssh повесить на другой порт, а на стандартном порту повесить ловушку-имитатор. И пусть ломают.
Вы там у себя на серверах секретные данные Пентагона храните что ли?
Чтобы ещё придумать…
Нужно чтобы это был вход не на настоящий сервер, а просто на шлюз без bash_history, с которого уже можно соединиться с настоящим в приватной сети… по паролю. Пароль должен включать управляющие ASCII-коды, символы нотной азбуки и мертвых языков
«40 тысяч обезьян в… сунули банан» Классика!
Cмена порта это мертвому припарка. Security through obscurity в чистом виде.
Авторизации по ключам с запретом всего остального достаточно для 99.999% серверов. Актуальный бекап kdbx со всеми ключами в облаке спасет от седых волос при смерти диска.
Пароль или ключ — это тоже «Security through obscurity в чистом виде.»
Вот эта вот мантра «Security through obscurity — это плохо потому что плохо», идиотская, потому что любая мантра идиотская без понимания сути.
Security through obscurity — это не плохо и не хорошо. Вопрос всегда в том, насколько сложно получить сакральное знание и насколько сложно поставить воглаву угла еще более сакральное(ну и насколько это оправданно).
А пароль/ключ/токен — это скорее о физическом владении чем-то для входа.
Поэтому, если злоумышленник узнает номер порта, что несложно, то он получает доступ к серверу
А вот защита ключами, даже если злоумышленнику извстен порт и протокол, предотвратит доступ к серверу
Очень важно это понимать и не путать.
Закрывать дверь на ключ и класть его под коврик в надежде, что никто не узнает — вот пример бытовой security through obscurity
Неправильно
что несложно
А я что написал?
Вопрос всегда в том, насколько сложно получить сакральное знание и насколько сложно поставить воглаву угла еще более сакральное
P.S.
Про не сложность определения порта — отдельный ЛОЛ. Учитывая, что:
1) Порт не отзывается никак.
2) Любая попытка сканирования блочит IP на первом же обращении к закрытому порту.
Security through obscurity — это расчёт на то что атакующий идиот и не знаком с методами защиты.
«угадай число от 1 до 65535 чтоб зайти на сервер»
либо
«подбери комбинацию из 20-50 символов чтоб зайти на сервер»
Какая-то минимальная разница таки есть в задачах.
И как вам уже говорили смену порта по степени усиления защиты можно приравнять к добавлению 2-3 символов в пароль.
А Security through obscurity в 2018 это однозначно плохо.
Было приемлимо при цезаре, когда многие реально не догадывались поменять символ на рядом стоящий для расшифровки текста.
Но сейчас надежда на то что нападающий идиот только вредит защите.
Найти ssh не так сложно, правда. Разве что если еще запускать несколько ssh в контейнерах и один настоящий, но можно тогда и самому запутаться.
Если у вас хоть как-то защищен сервер хоть чуть-чуть — они вам не страшны. (а если даже так не защищен — то вас наверняка УЖЕ взломали :-) ). А уж те кто готов серьезнее ломать — они умеют nmap запускать. Номер порта — это легко проверяемый секрет из 16 бит.
Все равно что использовать крем «Дэта» от наемного убийцы. От комаров же помогает! :-)
Конечно, мало смысла делать тотальный hardering ssh, когда, к примеру, на хосте крутится вордпресс с плагинами из нипойми откуда (правда, опять же, если WP хорошо упрятан в контейнер, то уже не так страшно).
Лично я тоже крайне скептичен к переносу на другой порт. Хоть какой-то смысл это имеет только при одновременной настройке бана за попытки скана портов, иначе… ну ёлки, просканить порты это дело пары секунд.
Вообще, давно думаю, что концептуально все подобные атаки живы только засчет одной вещи — они дешевые (по ресурсам) для стороны атакующего. Вот если бы сделать так, что для прохождения аутентификации клиентская сторона должна выполнить набор относительно тяжелых вычислительных операций — эти атаки бы ушли сами собой. То же самое можно было бы применить к спаму. Как только такие операции будут «убивать» машины по CPU (а лучше еще и по памяти) — даже большие ботнеты не смогут создать проблем.
Да, и совсем забыл! Почему-то в качестве защиты не упомянута банальная 2FA.
TOTP с googleauth настраивается элементарно, и проломить ботнетом её нереально в принципе.
В целом, ханипоты да ловушки — тоже хорошая вещь, но они уже требуют некоторой осторожности и подготовки.
Вот если бы сделать так, что для прохождения аутентификации клиентская сторона должна выполнить набор относительно тяжелых вычислительных операций…При коннекте посылать атакующему произведение двух больших простых чисел и не пускать, пока он не ответит одним из сомножителей. Oh, wait…
Ничем не плохо — только нужно не просто стукнуться, а авторизоваться, тогда получится такая себе 2FA. Port knocking тоже хорошо помогает. Я себе настроил доступ с некоторых своих ip + knocking. Чтоб порт открылся нужно пингануть пакетиками определённого размера не менее n раз. После чего нужно залогиниться в течении 1 минуты.
Есть ещё один не самый очевидный (и не для всех актуальный) момент — мне как-то не то за две, не то за три недели набрутфорсили паролей на 9 ГБ трафика. Прямо такой аккуратный длинный прямоугольник на графике bandwidth.
У многих безлимит, но на маленьких VPS нередко бывают ограничения, и когда вот так впустую съели девять ГБ из ста, мне это пришлось не по нраву. Остатка всё равно хватило с лихвой, но после этого порт поменял.
Кто-то скажет, что этот трафик всё равно бы пришёл, но я считаю, что намного вероятнее нет, чем да. На мой взгляд, перебор продолжался из-за того, что от сервера шли ответы.
Думаю, что также с подобными вещами можно бороться, давая ответы DROP вместо REJECT, но я не настолько хорош в настройке удалённых серверов, чтобы сразу сказать можно ли это сделать и как.
Вариант не подходит для тех, у кого нет постоянного ip. Например человек не сидит на месте, а много путешествует, например. К тому же есть ещё ватианты, когда достаточно большое число людей сидят за NAT. Поэтому "ваш ip" — это мало кому подойдёт.
Согласен. Более красивой выглядит port knocking.
Кто много путешествует, особенно по кафешкам сидит, давно уже использует VPN. Вот его ip и считается белым.
не понял, каким образом использование VPN соотносится с «белым IP». За IP VPN'а легко так же может оказаться сотня-другая ботов.
Во вторых поэтому 2 у разных хостеров. Шансы одновременного бана очень малы.
В третьих даже если их забанят проблемой будет только пробиться к своей VPS. Управлять сервером с неё вы всё так же сможете. Ибо каналы на которых висят даже российские хостеры, как показывает практика, блокировкам не подвержены.
Что Вы будете делать, если "ляжет" VPN?
Ну и чтоб антифрод не парил мозг на разных сервисах.
Второе. fail2ban такое себе решение. Меня он уже один раз из-за недоработки в нем подвёл. К тому же, если кто-то нальет трафика в сервер, то цепочки fail2ban очень сильно снизят скорость работы. Ядро только и будет, что гонять трафик по правилам файрволла. Это ограничивает применение fail2ban pet-проектами.
В третьих — что будете делать, если злоумышленники DDoS нальют в сервис?
Достаточно сделать аутентификацию по ключам, отключить аутентификацию по паролю и выставить LogLevel ERROR в /etc/ssh/sshd_config, чтобы флуд перебора не шёл в логи. В итоге только для ssh уже не нужно оставлять fail2ban.
Например от дня месяца зависит номер порта по определенному алгоритму, а от дня недели размеры пакетов или еще что-нибудь.
#убирает старые правила и ставит новые, делает iptables-save
0 0 * * * /bin/bash ~/new-rules.sh
Ну и на локальном компе, аналогичный скрипт, который делает пинги.
1. «сеть» или атака по площадям: ткнулись на стандартные порты, попробовали стандартные пароли, не получилось, побежали дальше. Неважно, какой хост будет взломан. Главный и единственный критерий — цена атаки в пересчете на один хост.
2. «крючок», или направленная атака: целевая система заранее известна, и нужно подобрать подход именно к ней. Критерии — успешность атаки на заданную систему и её цена.
Основное положение, на котором строится смена порта — что атаки первого типа встречаются гораздо чаще чем второго. Поэтому вычислительно дешевый прием, способный отклонить все или многие атаки первого типа, будет оправдан. А смена порта — исключительно дешевый прием. Единственная затрата — запомнить/записать новый номер порта.
От атак второго типа смена порта не защитит никак, но как минимум избавит от более затратные средства противодействия (типа того же fail2ban) от необходимости пережевывать большой поток запросов.
Так что в итоге смена порта ни в коем случае не является достаточной сама по себе, но вполне допустима как один из уровней защиты — для отсева массовых, но не слишком тщательных атак.
Свой айпишник в белый лист, чтобы случайно себя не кикнуть.
Дополнительно хочу добавить, что концептуально при использовании ssh-agent (что является достаточно популярным решением) парольная защита ключей ssh абсолютно бесполезна. Разбор этого производился неоднократно. Например, rabexc.org/posts/pitfalls-of-ssh-agents
Тем более, что есть куча софта, которое не умеет работать с зашифрованными ssh ключами (ansible, salt etc.).
Отдельный вопрос — это именно случайность при генерации ключевых пар, но я предполагаю, что в современных дистрибутивах даже с настройками по умолчанию все должно быть хорошо.
В плюсах меньше записей в логах. Ротацию вы ведь умеете настраивать? Значит это сомнительный плюс.
В минусах более сложная схема про которую надо помнить, надо администрировать и надо документировать.
Выше писали, что смена порта ssh неудобна для больших организаций, т.к. сложно администрировать. Так вот, в приличных организациях ssh вообще не должен быть доступен из интернета — только через сетевой интерфейс локальной сети и впн.
Одно другому не мешает — изолированная внутренняя сеть отлично сочетается с аутентификацией внутренних клиентов.
Отличия есть. OpenVPN открыта в интернет на одном-двух хостах, ssh — на всех. OpenVPN нативно поддерживает полное шифрование трафика (когда атакующий без симметричного ключа не сможет даже идентифицировать сервис), ssh — нет.
Многие повторяют мантру "security through obscurity это плохо" как непреложную истину, но это всего лишь рекомендация. Заменять security на obscurity, конечно, плохо, но добавление obscurity к security повышает уровень защиты системы.
Если несложные организационные меры позволяют отсечь часть рисков (автоматизированные сканы ssh на уязвимости, атака на внутренние системы из интернета, обязательность наличия инсайдера для атаки) — то почему нет?
Извините, конечно, но смена порта это сесурити какое-то. Даже стыдно о таких методах говорить в современном мире.
А для использующих Fail2Ban в аду есть отдельный Jail. «Чтобы избежать нагрузки на сервер от попыток брутфорса, мы повесим внутри отдельный демон который будет постоянно парсить логи регулярками и рисовать правила с баном по IP, ведь авторизация по ключу и правила в iptables это так сложно и не эффективно»
Хотя, «авторизация по ключу и пусть ломятся» — тоже решение, fail2ban не ограничивается одним SSH. Ему всё равно чьи логи парсить. Т.е. если у вас смотрит в свет ПО с менее развитыми возможностями авторизации (например, держите небольшой игровой сервер — вполне частый use case, по-моему), тогда приходится выкручиваться.
Конечно, в идеальном мире всё ПО должно иметь хороший, защищенный механизм авторизации. Но в реальном мире fail2ban — это сравнительно удобный костыль. Вопрос только в том, когда его применение даёт выигрыш, а когда нет.
22 порт SSH переносить или нет