Комментарии 98
Изменил одну настройку fail2ban. А именно, бан на месяц тех, кто трижды ошибся. Пароль 19 символов, буквы разного регистра, плюс цифры и символы. Я в опасности?
Мы все умрем…
да
В опасности. Легко трижды опечататься и потерять доступ к серверу.
Но я хожу по rsa, а вход по паролю оставил на всякий случай, вдруг потеряю ключи.
Что до ошибок, то после первой ошибки начинаешь набирать очень внимательно.
> Но я хожу по rsa, а вход по паролю оставил на всякий случай, вдруг потеряю ключи.
Но вход по паролю вы же все равно оставили — значит остается возможность брутфорса.
f2b может быть неэффективен в случае использования большого ботнета. И, насколько помню, там были какие-то проблемы с ipv6. Возможно тут лучше еще добавить ufw limit 22/tcp или аналогично через iptables.
На случай потери всех копий зашифрованного бэкапа ключей можно загрузить сервер с livecd / rescue и поставить новый ключ.
Но вход по паролю вы же все равно оставили — значит остается возможность брутфорса.
f2b может быть неэффективен в случае использования большого ботнета. И, насколько помню, там были какие-то проблемы с ipv6. Возможно тут лучше еще добавить ufw limit 22/tcp или аналогично через iptables.
На случай потери всех копий зашифрованного бэкапа ключей можно загрузить сервер с livecd / rescue и поставить новый ключ.
Но пароль же 19 символов (на самом деле больше, конспирация), буквы разных регистров, цифры и знаки. Чтобы его сбрутить, из расчета три попытки в месяц с пары тысяч ip, времени понадобится ну очень много же.
Но все равно вероятность больше, чем при удачном бруте rsa 4096.
Плюс если пароль не уникальный и не случайный, то шансы еще повышаются.
Плюс если пароль не уникальный и не случайный, то шансы еще повышаются.
Пароль нужен только для локального входа на сервер.
По ipmi/kvm/iLo/любая консоль облачного провайдера.
Вообще по уму — смена пароля root должна делаться через автоматизированную систему управления конфигурацией.
По паролям. Ещё очень частая история — синхронизация учеток через LDAP/ActiveDirectory. В этом случае успешный Брут пароля пользователя даёт возможность беспрепятственного использования любого Корп.сервиса под его учеткой. Лучше уж по ключам ходить.
По ipmi/kvm/iLo/любая консоль облачного провайдера.
Вообще по уму — смена пароля root должна делаться через автоматизированную систему управления конфигурацией.
По паролям. Ещё очень частая история — синхронизация учеток через LDAP/ActiveDirectory. В этом случае успешный Брут пароля пользователя даёт возможность беспрепятственного использования любого Корп.сервиса под его учеткой. Лучше уж по ключам ходить.
Больше…
Я на обычные сайты ставлю пароль в 25 символов, при возможности.
А более важные, если позволяет, то в 250 :)
Правда, менеджер паролей.
Я на обычные сайты ставлю пароль в 25 символов, при возможности.
А более важные, если позволяет, то в 250 :)
Правда, менеджер паролей.
Совсем не проблема — просто зайти на него через другой сервер, или через прокси.
и запросто таким образом отсечь пулы провайдеров, которые не дают «белый» айпи (всякие мобильные интернеты).
Да, можно возразить, что пользуйтесь ВПН, но это такое себе…
Да, можно возразить, что пользуйтесь ВПН, но это такое себе…
Переборщиков паролей много, если использовать стандартный 22 порт то благодаря f2b таблица записей блокировок за месяц будет примерно 2k, если использовать нестандартный порт, то все равно будут попадать переборщики. Я бы просто закрыл порт от всех, добавив пару своих подсетей в доверенные.
Если бы все вопросы безопасности решались просто ужесточением политик…
В реальности — это всегда компромисс, и неверно определив его, вы теряете в безопасности.
1) Длинный и сложный пароль? Значит он наверняка записан где-то на бумажке или каком-нибудь сайте-блокноте. И может потеряться. А может и «подглядеться».
2) Жесткая политика банов — раз в год и палка стреляет. Например, неудобно решать проблему на сервере с телефона, значит, может быть сядете за чужой комп (доверенный, хорошего человека). Но там нет ключей и с трех попыток и сами ошибетесь.
3) Непредвиденные проблемы — у них есть гадкое свойство — они непредвиденные. Например, какой-то кривой пакет SSH в обновлении, или уязвимость в алгоритме генерации ключей, из-за которой после обновления ssh сервер перестанет опознавать ваши ключи (да, дурное решение, но программист вот не подумал и сделал). И вот вы сами входите по паролю снова и делаете 3 ошибки.
Но можно с другой стороны идти. Не от шаблона своего поведения, а от шаблона атаки. Блокировка на один час — уже достаточно, чтобы предотвратить большинство брутфорса. Есть ли разница, подберут пароль за время в триста миллиардов раз больше времени жизни вселенной или всего лишь за 50 лет? Короткая блокировка безопаснее при ложном срабатывании, но дает достаточную (50 лет) защиту от брутфорса.
И еще такой момент — если у сервера есть альтернативный доступ (например, для VPS — это консоль сервера из админки у хостера, или просто ваш аккаунт у хостера, через который можно заказать визит в ДатаЦентр вплоть до того чтоб вытащить сервер из рэка и увезти домой) — то самые параноидальные методы дадут только побочные минусы, но прочность цепи по прежнему будет равна прочности самого слабого звена.
В реальности — это всегда компромисс, и неверно определив его, вы теряете в безопасности.
1) Длинный и сложный пароль? Значит он наверняка записан где-то на бумажке или каком-нибудь сайте-блокноте. И может потеряться. А может и «подглядеться».
2) Жесткая политика банов — раз в год и палка стреляет. Например, неудобно решать проблему на сервере с телефона, значит, может быть сядете за чужой комп (доверенный, хорошего человека). Но там нет ключей и с трех попыток и сами ошибетесь.
3) Непредвиденные проблемы — у них есть гадкое свойство — они непредвиденные. Например, какой-то кривой пакет SSH в обновлении, или уязвимость в алгоритме генерации ключей, из-за которой после обновления ssh сервер перестанет опознавать ваши ключи (да, дурное решение, но программист вот не подумал и сделал). И вот вы сами входите по паролю снова и делаете 3 ошибки.
Но можно с другой стороны идти. Не от шаблона своего поведения, а от шаблона атаки. Блокировка на один час — уже достаточно, чтобы предотвратить большинство брутфорса. Есть ли разница, подберут пароль за время в триста миллиардов раз больше времени жизни вселенной или всего лишь за 50 лет? Короткая блокировка безопаснее при ложном срабатывании, но дает достаточную (50 лет) защиту от брутфорса.
И еще такой момент — если у сервера есть альтернативный доступ (например, для VPS — это консоль сервера из админки у хостера, или просто ваш аккаунт у хостера, через который можно заказать визит в ДатаЦентр вплоть до того чтоб вытащить сервер из рэка и увезти домой) — то самые параноидальные методы дадут только побочные минусы, но прочность цепи по прежнему будет равна прочности самого слабого звена.
Вы знаете как приятно вбивать пароль из 19 знаков полученный от клиента по СМС.
А там весь набор символов, где много 0 или О или I или l — меня прям гордость берет за параноиков.
А там весь набор символов, где много 0 или О или I или l — меня прям гордость берет за параноиков.
Кстати, идея кажется хорошей. ssh повесить на другой порт, а на стандартном порту повесить ловушку-имитатор. И пусть ломают.
Ловушка TARPIT на 22. А другой порт SSH открывается только после port knoking. Вход по ключам, если кто-то отправил учётные данные, то бан. Что бы ещё придумать…
Вы там у себя на серверах секретные данные Пентагона храните что ли?
Чтобы ещё придумать…
Нужно чтобы это был вход не на настоящий сервер, а просто на шлюз без bash_history, с которого уже можно соединиться с настоящим в приватной сети… по паролю. Пароль должен включать управляющие ASCII-коды, символы нотной азбуки и мертвых языков
Можно просто зарезать фаерволлом доступ ко всему, кроме нескольких публичных сервисов, а открывать админский доступ только с конкретного IP после аутентификации через https. Это и отсеивает всех желающих халявного ssh, и не приводит к потере доступа откуда угодно даже в случае нескольких ошибок при вводе пароля.
Откройте для себя "Single Packet Authorization" как первый барьер, к примеру описан тут.
Открытый SSH — это безусловное зло. При первом же DoS вам не дадут зайти на сервер.
Но есть же ключи
За пароли из случайных символов в разных регистрах пора уже помидорами кидаться начинать. Пароль это любая фраза лишенная смысла для незнакомого с этой фразой.
«40 тысяч обезьян в… сунули банан» Классика!
Cмена порта это мертвому припарка. Security through obscurity в чистом виде.
Авторизации по ключам с запретом всего остального достаточно для 99.999% серверов. Актуальный бекап kdbx со всеми ключами в облаке спасет от седых волос при смерти диска.
«40 тысяч обезьян в… сунули банан» Классика!
Cмена порта это мертвому припарка. Security through obscurity в чистом виде.
Авторизации по ключам с запретом всего остального достаточно для 99.999% серверов. Актуальный бекап kdbx со всеми ключами в облаке спасет от седых волос при смерти диска.
А еще есть модуль hashlimit для iptables — прекрасно защищает SSH от брутфорса на любом порту!
Утерянный kdbx сделает голову седой полностью
Я вам открою страшную тайну(только никому не говорите!):
Пароль или ключ — это тоже «Security through obscurity в чистом виде.»
Вот эта вот мантра «Security through obscurity — это плохо потому что плохо», идиотская, потому что любая мантра идиотская без понимания сути.
Security through obscurity — это не плохо и не хорошо. Вопрос всегда в том, насколько сложно получить сакральное знание и насколько сложно поставить воглаву угла еще более сакральное(ну и насколько это оправданно).
Пароль или ключ — это тоже «Security through obscurity в чистом виде.»
Вот эта вот мантра «Security through obscurity — это плохо потому что плохо», идиотская, потому что любая мантра идиотская без понимания сути.
Security through obscurity — это не плохо и не хорошо. Вопрос всегда в том, насколько сложно получить сакральное знание и насколько сложно поставить воглаву угла еще более сакральное(ну и насколько это оправданно).
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 это однозначно плохо.
Было приемлимо при цезаре, когда многие реально не догадывались поменять символ на рядом стоящий для расшифровки текста.
Но сейчас надежда на то что нападающий идиот только вредит защите.
Security through obscurity — это расчёт на то что атакующий идиот и не знаком с методами защиты.
«угадай число от 1 до 65535 чтоб зайти на сервер»
либо
«подбери комбинацию из 20-50 символов чтоб зайти на сервер»
Какая-то минимальная разница таки есть в задачах.
И как вам уже говорили смену порта по степени усиления защиты можно приравнять к добавлению 2-3 символов в пароль.
А Security through obscurity в 2018 это однозначно плохо.
Было приемлимо при цезаре, когда многие реально не догадывались поменять символ на рядом стоящий для расшифровки текста.
Но сейчас надежда на то что нападающий идиот только вредит защите.
Вы так и не поняли, сюда по всему, почему говорят, что смена порта не имеет смысла. Она защищает только от тупых скриптов, которые даже не пытаются найти ssh у вас на сервере, а просто бьют по 22 порту.
Найти ssh не так сложно, правда. Разве что если еще запускать несколько ssh в контейнерах и один настоящий, но можно тогда и самому запутаться.
Найти ssh не так сложно, правда. Разве что если еще запускать несколько ssh в контейнерах и один настоящий, но можно тогда и самому запутаться.
НЛО прилетело и опубликовало эту надпись здесь
Ну стукаются, и чего? Стукаются же не те, кто готов посвятить месяц-два, с 0-day эксплойтами чтобы взломать именно вас. Стукаются те, кто хочет попробовать пароль password или 123456 на рута (вдруг да сработает! срабатывает же в 1 случае из тысячи).
Если у вас хоть как-то защищен сервер хоть чуть-чуть — они вам не страшны. (а если даже так не защищен — то вас наверняка УЖЕ взломали :-) ). А уж те кто готов серьезнее ломать — они умеют nmap запускать. Номер порта — это легко проверяемый секрет из 16 бит.
Все равно что использовать крем «Дэта» от наемного убийцы. От комаров же помогает! :-)
Если у вас хоть как-то защищен сервер хоть чуть-чуть — они вам не страшны. (а если даже так не защищен — то вас наверняка УЖЕ взломали :-) ). А уж те кто готов серьезнее ломать — они умеют nmap запускать. Номер порта — это легко проверяемый секрет из 16 бит.
Все равно что использовать крем «Дэта» от наемного убийцы. От комаров же помогает! :-)
О, вечная тема. И слишком многогранная, как почти любая тема по безопасности.
Конечно, мало смысла делать тотальный hardering ssh, когда, к примеру, на хосте крутится вордпресс с плагинами из нипойми откуда (правда, опять же, если WP хорошо упрятан в контейнер, то уже не так страшно).
Лично я тоже крайне скептичен к переносу на другой порт. Хоть какой-то смысл это имеет только при одновременной настройке бана за попытки скана портов, иначе… ну ёлки, просканить порты это дело пары секунд.
Вообще, давно думаю, что концептуально все подобные атаки живы только засчет одной вещи — они дешевые (по ресурсам) для стороны атакующего. Вот если бы сделать так, что для прохождения аутентификации клиентская сторона должна выполнить набор относительно тяжелых вычислительных операций — эти атаки бы ушли сами собой. То же самое можно было бы применить к спаму. Как только такие операции будут «убивать» машины по CPU (а лучше еще и по памяти) — даже большие ботнеты не смогут создать проблем.
Да, и совсем забыл! Почему-то в качестве защиты не упомянута банальная 2FA.
TOTP с googleauth настраивается элементарно, и проломить ботнетом её нереально в принципе.
Конечно, мало смысла делать тотальный hardering ssh, когда, к примеру, на хосте крутится вордпресс с плагинами из нипойми откуда (правда, опять же, если WP хорошо упрятан в контейнер, то уже не так страшно).
Лично я тоже крайне скептичен к переносу на другой порт. Хоть какой-то смысл это имеет только при одновременной настройке бана за попытки скана портов, иначе… ну ёлки, просканить порты это дело пары секунд.
Вообще, давно думаю, что концептуально все подобные атаки живы только засчет одной вещи — они дешевые (по ресурсам) для стороны атакующего. Вот если бы сделать так, что для прохождения аутентификации клиентская сторона должна выполнить набор относительно тяжелых вычислительных операций — эти атаки бы ушли сами собой. То же самое можно было бы применить к спаму. Как только такие операции будут «убивать» машины по CPU (а лучше еще и по памяти) — даже большие ботнеты не смогут создать проблем.
Да, и совсем забыл! Почему-то в качестве защиты не упомянута банальная 2FA.
TOTP с googleauth настраивается элементарно, и проломить ботнетом её нереально в принципе.
Дык не надо мешать спамерам спамить в песочницу. Мы, после того как создали видимость для спамботов и ребят из «Индии», что их попытки удачны, теперь пасем вполне компактное стадо этих спам-товарищией. Их число не растет, они счастливы. Мы тоже :) Живем без капчи, клиенты счастливы.
Вы именно про почту сейчас? А как вы их загнали в песочницу, а обычных юзеров оставили, расскажите? =)
В целом, ханипоты да ловушки — тоже хорошая вещь, но они уже требуют некоторой осторожности и подготовки.
В целом, ханипоты да ловушки — тоже хорошая вещь, но они уже требуют некоторой осторожности и подготовки.
Нет, не про почту. Я говорил про всякие формы фидбеков/отзывов/запросов в вебе и тому подобное. Рассказать можно, но это не готовые рецепты. Это некая система, строилась годами (наш продуктовый веб-проект с 2004 года живет). Это скорей некий набор концепций (например анализ поведения на ресурсе), а уж как их реализовывать, это дело десятое. Но факт такой, что проникновение массового спама в CRM мы отсекли практически на корню.
Вот если бы сделать так, что для прохождения аутентификации клиентская сторона должна выполнить набор относительно тяжелых вычислительных операций…При коннекте посылать атакующему произведение двух больших простых чисел и не пускать, пока он не ответит одним из сомножителей. Oh, wait…
На середине статьи, мне в голову пришла бредовая мысль «а если на 22-м порту сделать проброс на другую машину, „жертву“, вот пусть ее ломают. А она нам статистику будет присылать. Потом дочитал до конца и понял, что не такая уж и бредовая мысль :)
а чем плохо отключение ssh пока не стукнешься в специальный урл?
Ничем не плохо — только нужно не просто стукнуться, а авторизоваться, тогда получится такая себе 2FA. Port knocking тоже хорошо помогает. Я себе настроил доступ с некоторых своих ip + knocking. Чтоб порт открылся нужно пингануть пакетиками определённого размера не менее n раз. После чего нужно залогиниться в течении 1 минуты.
Я как-то об этом уже писал, но повторюсь:
Есть ещё один не самый очевидный (и не для всех актуальный) момент — мне как-то не то за две, не то за три недели набрутфорсили паролей на 9 ГБ трафика. Прямо такой аккуратный длинный прямоугольник на графике bandwidth.
У многих безлимит, но на маленьких VPS нередко бывают ограничения, и когда вот так впустую съели девять ГБ из ста, мне это пришлось не по нраву. Остатка всё равно хватило с лихвой, но после этого порт поменял.
Кто-то скажет, что этот трафик всё равно бы пришёл, но я считаю, что намного вероятнее нет, чем да. На мой взгляд, перебор продолжался из-за того, что от сервера шли ответы.
Думаю, что также с подобными вещами можно бороться, давая ответы DROP вместо REJECT, но я не настолько хорош в настройке удалённых серверов, чтобы сразу сказать можно ли это сделать и как.
Есть ещё один не самый очевидный (и не для всех актуальный) момент — мне как-то не то за две, не то за три недели набрутфорсили паролей на 9 ГБ трафика. Прямо такой аккуратный длинный прямоугольник на графике bandwidth.
У многих безлимит, но на маленьких VPS нередко бывают ограничения, и когда вот так впустую съели девять ГБ из ста, мне это пришлось не по нраву. Остатка всё равно хватило с лихвой, но после этого порт поменял.
Кто-то скажет, что этот трафик всё равно бы пришёл, но я считаю, что намного вероятнее нет, чем да. На мой взгляд, перебор продолжался из-за того, что от сервера шли ответы.
Думаю, что также с подобными вещами можно бороться, давая ответы DROP вместо REJECT, но я не настолько хорош в настройке удалённых серверов, чтобы сразу сказать можно ли это сделать и как.
Сейчас у всех уважающих себя хостеров есть облачный фаервол. Уже ничего мудрить не нужно — просто запрещаете доступ по SSH для всех, кроме вашего IP.
Вариант не подходит для тех, у кого нет постоянного ip. Например человек не сидит на месте, а много путешествует, например. К тому же есть ещё ватианты, когда достаточно большое число людей сидят за NAT. Поэтому "ваш ip" — это мало кому подойдёт.
Согласен. Более красивой выглядит port knocking.
Кто много путешествует, особенно по кафешкам сидит, давно уже использует VPN. Вот его ip и считается белым.
Кто много путешествует, особенно по кафешкам сидит, давно уже использует VPN. Вот его ip и считается белым.
не понял, каким образом использование VPN соотносится с «белым IP». За IP VPN'а легко так же может оказаться сотня-другая ботов.
Это маловероятно. И часто у людей свой VPN. На виртуалке или на домашнем роутере.
С тем же успехом, можно сразу впниться до сети с конечным узлом. Делать промежуточные хопы смысла нет
Банально просто. Вы поехали в Тайланд отдохнуть, а дома у Вас отключили свет/ интернет. Может авария у провайдера — причин может быть много. А Вам срочно нужно поправить что-то на одном из серверов. И Вам прийдётся, вместо отдыха, кому то звонить, нервничать, думать даже о срочной покупке билетов на самолёт. Я просто всё это проходил однажды…
1-3 бакса в месяц обходится vps-ка с поднятым vpn и белым статичным ip. Взять 2 у разных хостеров и нервы на 100% защищены.
А потом эта VPSка попадает под бан РКНа… (такое случилось с моими VPS на Scaleway и DO)…
Ну это проблемы текущего законодательства. О которых все ноют, но молчаливо принимают.
Во вторых поэтому 2 у разных хостеров. Шансы одновременного бана очень малы.
В третьих даже если их забанят проблемой будет только пробиться к своей VPS. Управлять сервером с неё вы всё так же сможете. Ибо каналы на которых висят даже российские хостеры, как показывает практика, блокировкам не подвержены.
Во вторых поэтому 2 у разных хостеров. Шансы одновременного бана очень малы.
В третьих даже если их забанят проблемой будет только пробиться к своей VPS. Управлять сервером с неё вы всё так же сможете. Ибо каналы на которых висят даже российские хостеры, как показывает практика, блокировкам не подвержены.
А что остались админы, которые пользуются чужими VPN?
Что Вы будете делать, если "ляжет" VPN?
На этот случай я обычно держу 2 впн на своих серверах в разных странах и оба эти ip в вайтлисты.
То есть, вместо простых мероприятий в виде port knocking и смены порта ssh, Вы должны держать 2 vpn сервера в разных странах? Уверен, Вы это только сейчас придумали.
Быстро поднять другой, это дело 5 минут и 5 баксов.
Стандартный порт SSH — лишний трафик и срачь в логах. Смена порта эту проблему прекрастно решает минимальными усилиями.
Никто не будет спорить ключи, Fail2ban, двухфакторня авторизация, сложные и длинные пароли все это нужно и прекрасно работает в своем сегменте защиты. Но почему то некоторые забывают, что защищаться нужно с момента сбора информации о Вашей системе. Чем сложнее будет собрать информацию о открытых портах тем сложнее будет организовать атаку. Часто сканирование портов идет на ограниченный набор портов, использовать их как ловушку в iptables, второй пакет с этого же адреса на любой порт в течении 1 часа и блокируем на сутки или больше этот IP адрес. Модулями iptables это реализуется просто. Отслеживание сканирования идет на уровне пакетов, а не лог файлов.
Первое. В общем случае, для публичных сервисов это не работает. Там попросту не построить «белый» список, откуда можно ходить.
Второе. fail2ban такое себе решение. Меня он уже один раз из-за недоработки в нем подвёл. К тому же, если кто-то нальет трафика в сервер, то цепочки fail2ban очень сильно снизят скорость работы. Ядро только и будет, что гонять трафик по правилам файрволла. Это ограничивает применение fail2ban pet-проектами.
В третьих — что будете делать, если злоумышленники DDoS нальют в сервис?
Второе. fail2ban такое себе решение. Меня он уже один раз из-за недоработки в нем подвёл. К тому же, если кто-то нальет трафика в сервер, то цепочки fail2ban очень сильно снизят скорость работы. Ядро только и будет, что гонять трафик по правилам файрволла. Это ограничивает применение fail2ban pet-проектами.
В третьих — что будете делать, если злоумышленники DDoS нальют в сервис?
Достаточно сделать аутентификацию по ключам, отключить аутентификацию по паролю и выставить LogLevel ERROR в /etc/ssh/sshd_config, чтобы флуд перебора не шёл в логи. В итоге только для ssh уже не нужно оставлять fail2ban.
А не подскажете, бывает динамический port knocking? Просто статический плох тем, что подслушав траффик один раз становится ясно как открывать порт. Под динамическим я имею ввиду ситуацию, когда номера портов в которые надо постучаться зависят от даты, IP и много чего еще и алгоритм известен только владельцу сервера и самому серверу естественно.
Вы представляете себе уровень подготовки людей, которые могут слушать ваш трафик? Если вы серьезно с такими столкнетесь, то динамическая блокировка будет у вас наименьшей проблемой.
Да сейчас все подряд слушают траффик, если могут — то весь. Или даже при подключении по ssh через wi-fi ближайшей кафешки надо оборачиваться в vpn? Вроде ж технически не должно быть очень сложно, вот и подумалось, что решения есть. Нагуглил: cryptknock.sourceforge.net и github.com/ashemery/tariq
Скрипт на bash + cron могут решить данную проблему.
Например от дня месяца зависит номер порта по определенному алгоритму, а от дня недели размеры пакетов или еще что-нибудь.
Ну и на локальном компе, аналогичный скрипт, который делает пинги.
Например от дня месяца зависит номер порта по определенному алгоритму, а от дня недели размеры пакетов или еще что-нибудь.
#убирает старые правила и ставит новые, делает iptables-save
0 0 * * * /bin/bash ~/new-rules.sh
Ну и на локальном компе, аналогичный скрипт, который делает пинги.
Тогда лучше возьмите SPA с криптографией, вроде fwknop.
Честно говоря, не понимаю о чем тут спорить. Атаки с целью взлома (не DoS) можно разделить на две большие категории.
1. «сеть» или атака по площадям: ткнулись на стандартные порты, попробовали стандартные пароли, не получилось, побежали дальше. Неважно, какой хост будет взломан. Главный и единственный критерий — цена атаки в пересчете на один хост.
2. «крючок», или направленная атака: целевая система заранее известна, и нужно подобрать подход именно к ней. Критерии — успешность атаки на заданную систему и её цена.
Основное положение, на котором строится смена порта — что атаки первого типа встречаются гораздо чаще чем второго. Поэтому вычислительно дешевый прием, способный отклонить все или многие атаки первого типа, будет оправдан. А смена порта — исключительно дешевый прием. Единственная затрата — запомнить/записать новый номер порта.
От атак второго типа смена порта не защитит никак, но как минимум избавит от более затратные средства противодействия (типа того же fail2ban) от необходимости пережевывать большой поток запросов.
Так что в итоге смена порта ни в коем случае не является достаточной сама по себе, но вполне допустима как один из уровней защиты — для отсева массовых, но не слишком тщательных атак.
1. «сеть» или атака по площадям: ткнулись на стандартные порты, попробовали стандартные пароли, не получилось, побежали дальше. Неважно, какой хост будет взломан. Главный и единственный критерий — цена атаки в пересчете на один хост.
2. «крючок», или направленная атака: целевая система заранее известна, и нужно подобрать подход именно к ней. Критерии — успешность атаки на заданную систему и её цена.
Теоретически...
их можно совместить — построить автоматизированный анализатор уязвимостей, способный более-менее тщательно простучать целевой хост, и натравить его на весь диапазон IPv4. На практике — стоимость создания и время работы (в расчете на один хост) будут высоки, что сделает атаку непрактичной для большинства злоумышленников. Так что такие гипотетические атаки можно отнести ко второй категории.
Основное положение, на котором строится смена порта — что атаки первого типа встречаются гораздо чаще чем второго. Поэтому вычислительно дешевый прием, способный отклонить все или многие атаки первого типа, будет оправдан. А смена порта — исключительно дешевый прием. Единственная затрата — запомнить/записать новый номер порта.
Исключение
… составят крупные системы под управлением большой команды, где предсказуемость (в том числе стандартные номера портов) важна для успешной совместной работы. Но у таких команд обычно есть ресурсы на более дорогостоящие средства противодействия.
От атак второго типа смена порта не защитит никак, но как минимум избавит от более затратные средства противодействия (типа того же fail2ban) от необходимости пережевывать большой поток запросов.
Так что в итоге смена порта ни в коем случае не является достаточной сама по себе, но вполне допустима как один из уровней защиты — для отсева массовых, но не слишком тщательных атак.
Лично я ssh перевешиваю на другой порт, а всех, кто ломится на 22 сразу в баню.
Свой айпишник в белый лист, чтобы случайно себя не кикнуть.
Свой айпишник в белый лист, чтобы случайно себя не кикнуть.
НЛО прилетело и опубликовало эту надпись здесь
Очень грамотный ответ!
Дополнительно хочу добавить, что концептуально при использовании ssh-agent (что является достаточно популярным решением) парольная защита ключей ssh абсолютно бесполезна. Разбор этого производился неоднократно. Например, rabexc.org/posts/pitfalls-of-ssh-agents
Тем более, что есть куча софта, которое не умеет работать с зашифрованными ssh ключами (ansible, salt etc.).
Отдельный вопрос — это именно случайность при генерации ключевых пар, но я предполагаю, что в современных дистрибутивах даже с настройками по умолчанию все должно быть хорошо.
Дополнительно хочу добавить, что концептуально при использовании ssh-agent (что является достаточно популярным решением) парольная защита ключей ssh абсолютно бесполезна. Разбор этого производился неоднократно. Например, rabexc.org/posts/pitfalls-of-ssh-agents
Тем более, что есть куча софта, которое не умеет работать с зашифрованными ssh ключами (ansible, salt etc.).
Отдельный вопрос — это именно случайность при генерации ключевых пар, но я предполагаю, что в современных дистрибутивах даже с настройками по умолчанию все должно быть хорошо.
Я использую sslh на порту 443, за которым прячется ssh и nginx с пустым индексом и живым сертификатом от let's encrypt. Это, безусловно, тоже security by obscurity, но в логах удивительно чисто. Видимо такие комбинации мало кто пытается ломать плюс я лично никому не интересен.
А вам не пофиг что там в логах? Ну хочет кто сканить пусть сканит. При сканировании всего Интернета нагрузка на вас смешная выходит. При целевом ломании именно вас с такими мелочами быстро разберутся. При ДДОС что именно ддосить найдут. И смысл прятать ssh?
В плюсах меньше записей в логах. Ротацию вы ведь умеете настраивать? Значит это сомнительный плюс.
В минусах более сложная схема про которую надо помнить, надо администрировать и надо документировать.
В плюсах меньше записей в логах. Ротацию вы ведь умеете настраивать? Значит это сомнительный плюс.
В минусах более сложная схема про которую надо помнить, надо администрировать и надо документировать.
Однозначно нестандартный порт, как выше писалось — TARPIT, и, если позволяет бизнес-концепция, DROP пакистанов, гондурасов, кетаев и прочих нежелательных через iptables/ipset
Выше писали, что смена порта ssh неудобна для больших организаций, т.к. сложно администрировать. Так вот, в приличных организациях ssh вообще не должен быть доступен из интернета — только через сетевой интерфейс локальной сети и впн.
НЛО прилетело и опубликовало эту надпись здесь
Одно другому не мешает — изолированная внутренняя сеть отлично сочетается с аутентификацией внутренних клиентов.
Отличия есть. OpenVPN открыта в интернет на одном-двух хостах, ssh — на всех. OpenVPN нативно поддерживает полное шифрование трафика (когда атакующий без симметричного ключа не сможет даже идентифицировать сервис), ssh — нет.
Многие повторяют мантру "security through obscurity это плохо" как непреложную истину, но это всего лишь рекомендация. Заменять security на obscurity, конечно, плохо, но добавление obscurity к security повышает уровень защиты системы.
Если несложные организационные меры позволяют отсечь часть рисков (автоматизированные сканы ssh на уязвимости, атака на внутренние системы из интернета, обязательность наличия инсайдера для атаки) — то почему нет?
Кто-то продумывает 2048-битные ключи и шифрование на элиптических кривых, а кто-то меняет значение двух байт данных и думает что защитился.
Извините, конечно, но смена порта это сесурити какое-то. Даже стыдно о таких методах говорить в современном мире.
А для использующих Fail2Ban в аду есть отдельный Jail. «Чтобы избежать нагрузки на сервер от попыток брутфорса, мы повесим внутри отдельный демон который будет постоянно парсить логи регулярками и рисовать правила с баном по IP, ведь авторизация по ключу и правила в iptables это так сложно и не эффективно»
Извините, конечно, но смена порта это сесурити какое-то. Даже стыдно о таких методах говорить в современном мире.
А для использующих Fail2Ban в аду есть отдельный Jail. «Чтобы избежать нагрузки на сервер от попыток брутфорса, мы повесим внутри отдельный демон который будет постоянно парсить логи регулярками и рисовать правила с баном по IP, ведь авторизация по ключу и правила в iptables это так сложно и не эффективно»
Не очень понимаю причем тут нагрузка на сервер. Fail2ban хорош, когда невозможно или непрактично заведомо составить список «разрешенных» адресов.
Хотя, «авторизация по ключу и пусть ломятся» — тоже решение, fail2ban не ограничивается одним SSH. Ему всё равно чьи логи парсить. Т.е. если у вас смотрит в свет ПО с менее развитыми возможностями авторизации (например, держите небольшой игровой сервер — вполне частый use case, по-моему), тогда приходится выкручиваться.
Конечно, в идеальном мире всё ПО должно иметь хороший, защищенный механизм авторизации. Но в реальном мире fail2ban — это сравнительно удобный костыль. Вопрос только в том, когда его применение даёт выигрыш, а когда нет.
Хотя, «авторизация по ключу и пусть ломятся» — тоже решение, fail2ban не ограничивается одним SSH. Ему всё равно чьи логи парсить. Т.е. если у вас смотрит в свет ПО с менее развитыми возможностями авторизации (например, держите небольшой игровой сервер — вполне частый use case, по-моему), тогда приходится выкручиваться.
Конечно, в идеальном мире всё ПО должно иметь хороший, защищенный механизм авторизации. Но в реальном мире fail2ban — это сравнительно удобный костыль. Вопрос только в том, когда его применение даёт выигрыш, а когда нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
22 порт SSH переносить или нет