Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 190
Сам считаю, что перевешивание порта с целью безопасности не имеет смысла, ведь на любом порту все равно придется ставить адекватную защиту вроде iptables -m recent, sshguard, fail2ban или что-то еще. А если эти средства одинаково хорошо защищают на любых портах, то для чего лишний раз нарушать стандарты и нормы? Упорядочение серверных служб, администрирование с использованием универсальных решений — вот удел хорошего системного администратора. В идеале, новый сисадмин на его месте должен максимально быстро «овладеть» сервером, не копаясь в алиасах и не используя лишний раз nmap, чтобы хотя бы залогиниться.
На днях довелось поучаствовать в дискуссии на эту тему, но ряд вопросов так и остался открыт. Оказывается, не все так очевидно, и системные администраторы очень часто перевешивают ssh на другой порт. Почему?
На днях довелось поучаствовать в дискуссии на эту тему, но ряд вопросов так и остался открыт. Оказывается, не все так очевидно, и системные администраторы очень часто перевешивают ssh на другой порт. Почему?
присоединяюсь. Никогда не меняю стандартный порт SSH. Это все равно как голову в песок. Запрещаем руту логин, разворачиваем аутентификацию по ключам. Для серверов, торчащих SSH-ем наружу применяем вышеуказанные примочки, либо универсальный SNORT (любую другую IPS по вкусу).
SNORT — всего лишь инструмент, он не может ошибаться. Ошибается админ, который его настраивает. Не нравится снорт (не можете настроить?) — покупайте железную IPS, серьезные производители (tipping point, mcafee, ibm, etc.) гарантируют отсутствие ложных срабатываний. Не устаю повторять про правило треугольника «дешево — быстро — хорошо».
«SNORT ошибается» и «Ошибка в коде SNORT» — не одно и то же. Баги никто не отменял, на то они и баги.
>анализ логов 1 раз в минуту
А при чем тут анализ логов? Снорт работает с сетевым трафиком «на лету», вы его с чем-то другим путаете, наверное с наколенными скриптами для iptables+apache.
>злоумышленник уже может быть в системе
А вот от этого вас перевешивание порта точно никак не спасет, в отличие от правильно настроенной IPS. До перевешенного порта доберется чуть более опытный взломщик, и ему уже никто не помешает подбирать пасс. В случае с IPS это не так.
>анализ логов 1 раз в минуту
А при чем тут анализ логов? Снорт работает с сетевым трафиком «на лету», вы его с чем-то другим путаете, наверное с наколенными скриптами для iptables+apache.
>злоумышленник уже может быть в системе
А вот от этого вас перевешивание порта точно никак не спасет, в отличие от правильно настроенной IPS. До перевешенного порта доберется чуть более опытный взломщик, и ему уже никто не помешает подбирать пасс. В случае с IPS это не так.
> Никогда не меняю стандартный порт SSH. Это все равно как голову в песок.
Полностью согласен, смысла в этом не много, достаточно лишь вбить в гугл это, и все встанет на свои места.
А по поводу зашиты методом «голову в песок», очень много натерпелся, у меня сейчас коллеги очень своеобразно понимают слово защита информации, у них стратегическая база Oracle не видит никаких других ресурсов(«база у нас секретная, и собаки вокруг должны бегать» (С) :)
при этом блин базу видят все :))) тоже своеобразное отношение к секурити в частности и жизни в целом…
При этом мне как кодеру который привык ранить всю логику в базе это просто страшно. Что я этим хотел сказать, не нужно решать проблему внесением путаницы, это не помешает злоумышленику и может очень сильно помешать работе ни в чем неповинных программистов.
Полностью согласен, смысла в этом не много, достаточно лишь вбить в гугл это, и все встанет на свои места.
А по поводу зашиты методом «голову в песок», очень много натерпелся, у меня сейчас коллеги очень своеобразно понимают слово защита информации, у них стратегическая база Oracle не видит никаких других ресурсов(«база у нас секретная, и собаки вокруг должны бегать» (С) :)
при этом блин базу видят все :))) тоже своеобразное отношение к секурити в частности и жизни в целом…
При этом мне как кодеру который привык ранить всю логику в базе это просто страшно. Что я этим хотел сказать, не нужно решать проблему внесением путаницы, это не помешает злоумышленику и может очень сильно помешать работе ни в чем неповинных программистов.
А когда они все торчат наружу через один NAT?
Это частный случай, совершенно другая ситуация.
Очевидно, что для маршрутизации этого, придется пробрасывать различные порты на внутрисетевые адреса.
Но тут уж лучше vpn, чтобы избежать карусели с пробросом.
Очевидно, что для маршрутизации этого, придется пробрасывать различные порты на внутрисетевые адреса.
Но тут уж лучше vpn, чтобы избежать карусели с пробросом.
это совсем другое дело, но и тут, когда выделаете ПАТ, трансляцию яб не менял.
Выработайте единую политику — в этой конторе весь ssh висит на 9999 порту… и все…
или sss*2, где sss последная байт ip адреса xxx.yyy.zzz.sss =)) мозг развивает :D
или sss*2, где sss последная байт ip адреса xxx.yyy.zzz.sss =)) мозг развивает :D
Не так. Существует куча решений, в которых, при смене стандартного ssh-порта, придется этот порт указывать. И причем не всегда очевидным способом. Посмотрите, как различны способы указания, например для rsync, scp, mercurial… Я уже напоролся. Ну его нафиг. Все равно, если вас захотят побрутфорсить — первым делом просканят порты.
Снимаю перед Вами шляпу. :)
Я не боюсь делать шаги в сторону. Сам люблю линуху, уже 2 года не вылажу из нее. Но к сожалению, не обладаю бессмертием, поэтому для себя решил, что свое время предпочту потратить на что мне нравится, а при острой необходимости — нанять такого профессионала, как вы.
Не совсем об администрировании, и ssh на не стандартном порту, но очень точно отражает то, что я хочу Вам сказать. Цитата из Спольски:
У вас, как у программиста, благодаря копеечным ценам на память и удвоению скорости процессоров каждые два года, есть выбор. Можете потратить шесть месяцев, переписывая внутренние циклы на ассемблере, или потратить шесть месяцев играя барабанщиком в рок-н-рольной группе, и в обоих случаях ваша программа будет работать быстрее. У программистов на ассемблере нет фанаток.
local.joelonsoftware.com/wiki/Письмо_о_стратегии_VI
Я не боюсь делать шаги в сторону. Сам люблю линуху, уже 2 года не вылажу из нее. Но к сожалению, не обладаю бессмертием, поэтому для себя решил, что свое время предпочту потратить на что мне нравится, а при острой необходимости — нанять такого профессионала, как вы.
Не совсем об администрировании, и ssh на не стандартном порту, но очень точно отражает то, что я хочу Вам сказать. Цитата из Спольски:
У вас, как у программиста, благодаря копеечным ценам на память и удвоению скорости процессоров каждые два года, есть выбор. Можете потратить шесть месяцев, переписывая внутренние циклы на ассемблере, или потратить шесть месяцев играя барабанщиком в рок-н-рольной группе, и в обоих случаях ваша программа будет работать быстрее. У программистов на ассемблере нет фанаток.
local.joelonsoftware.com/wiki/Письмо_о_стратегии_VI
Я действительно не понимаю, почему человек, четко и ясно понимающий свои действия, боится сделать шаг в сторону от «типовых» и «стандартных» рекомендаций в явно нестандартных ситуациях.Перевес порта — не творческое решение, это обезьянничество за другими. «Меня брутфорсят!» — «Смени порт!».
Если бы этого делать было нельзя, соответствующей опции в конфиге просто не было бы.
Я не боюсь перевешивать порт, и понимаю, что нередко перевес порта необходим. Просто мне известен преркасный, простой и изящный способ отлова простых атак, при котором так же не зе засоряются логи, но ssh остается на своем месте.
Кто-то не умеет настраивать файрволл, поэтому меняет порт, кому-то плевать на стандарт, согласен с Shark, что ничего в этом страшного нет.
Еще раз убедился, что тема холиварная, методы бывают разными, пусть каждый админит как умеет.
от специализированной атаки нацеленной на ваш конкретный хост перевешивание не спасет, но от тупых ботов помогает 100%, как только перевешивал на другой порт — долбеж прекращался…
Когда Вы перевешивали порт, Вам были известны другие способы защиты? Почему выбор пал на этот способ?
я тоже перевешивал. Знаю и другие способы. Этот сильно проще.
Как показали испытания fail2ban сильно грузит ВПСку.
А перевешивание — это просто и эффективно.
Если вы знаете, что на таком-то повороте всегда стоит злой мент, который до всех докапытвается на ровном месте, то вы смените маршрут или будете упорно ругаться с ним каждый день?
Как показали испытания fail2ban сильно грузит ВПСку.
А перевешивание — это просто и эффективно.
Если вы знаете, что на таком-то повороте всегда стоит злой мент, который до всех докапытвается на ровном месте, то вы смените маршрут или будете упорно ругаться с ним каждый день?
Fail2ban это не все решения. Как насчет iptables?
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j TARPIT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
В этой истории я мент, легко и просто ловлю нарушителей на шоссе, потому, что должен быть на шоссе, и не прячусь на проселочной дороге.
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j TARPIT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
Если вы знаете, что на таком-то повороте всегда стоит злой мент, который до всех докапытвается на ровном месте, то вы смените маршрут или будете упорно ругаться с ним каждый день?
В этой истории я мент, легко и просто ловлю нарушителей на шоссе, потому, что должен быть на шоссе, и не прячусь на проселочной дороге.
а цепочка TARPIT — это стандартная в iptables? Или там надо еще сто строк в фаервол добавить, чтобы система работала?
Используйте DROP или REJECT, как угодно.
Для TARPIT нужен модуль xt_TARPIT.
Для TARPIT нужен модуль xt_TARPIT.
А он есть? в VPS с этим сложности :)
Используйте DROP или REJECT, как угодно.
У многих брутфорсеров стоит таймаут ожидания SYN/ACK.
А вот при TARPIT они зависают гарантировано =)
А вот при TARPIT они зависают гарантировано =)
Если у вас есть две настройки, одна из которых приводит к зависанию сканера, так почему не нагадить в компот злобному крякеру?Согласен, кроме того, метод с TARPIT менее ресурсоемок, так как заставляет атакующего прерывать посылку SYN в ожидании передачи данных.
А это не злобный крякер. Это раздолбай, который повесил себе на ссш пароль 123456, после чего хитрые китайские крякеры его быстро ломанули, забросили к нему ssh-scan, и уже от него сканят вас. А он и не знает.
Ну, после такого ответа придётся узнать и может быть полечиться…
После заворота входящих подключений в тарпит — сильно сомневаюсь. Одно время я внимательно просматривал отчеты об атаках типа ssh-scan на свои ресурсы, и в ответ запускал nmap. Очень часто находились открытые сервисы VNC, RDP, MySQL, иногда даже без пароля или с тупым паролем вроде qwerty или 12345. В таких случаях я заходил и смотрел что это за сервер. Во всех случаях это были не злобные крякеры, а просто серваки без вменяемого админа. Я оставлял им сообщения — мол, примите меры. Вот после этого они проникались и принимали меры, а потом еще и благодарили меня.
спасибо, с DROP будет понятно. Модуля xt_TARPIT у меня в стандартной поставке нет, и доку я в инете не нашёл — вообще непонятно что это, откуда и с чем его едят.
Попробую ваш совет с -m recent.
Попробую ваш совет с -m recent.
Потому, как боты. И если у меня стоит слабенький VPS и вдруг ни с того ни с сего на него начинается брут-форс по подбору пароля, то даже если атака будет отбита, то это создаёт заметную нагрузку на сервер. АДолбёжка идёт практически непрерывно — похоже какие-то ботнеты сканируют сеть (а может не всю сеть а только VPS'ы провайдеров) в поисках дырок в надежде, что юзер купил VPS, поставил пароль «root» и успокоился. А как правильно заметили в комментарии выше — после переноса порта тупые брут-форсы исчезают, как класс.
Как насчет такого способа? Нагрузка мизерная.
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j TARPIT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j TARPIT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
Не у всех VPS есть необходимые модули ядра. Например, CONTRACK в большинстве случаем или отсутствует или работает криво.
VPS на OpenVZ? Хм, да, это может стать преградой.
Как быть? Нельзя же защищаться одним только перевешиванием, одно сканирование и порт для брутфорса определен.
Как быть? Нельзя же защищаться одним только перевешиванием, одно сканирование и порт для брутфорса определен.
Не знаю как у вас, а у меня были километровые логи на 21 и 22 порту сгенеренные тупыми автоботами, после перевешивания логи стали нормальными. Это так же как у нас на всех сайтах периодически пытаются найти директории phpmyadmin и т.п. Ну и нафига мне километры вирусованных ip созданные fail2ban, когда лучше я его использую для защиты от направленных атак на уникальных портах.
Сейчас долбежка идет вобще по всем IP, логи с арендованного сервера и с домашнего реального ip. Из-за этого менял порты
когда перевешивал — знал, не все доступно на стареньком ядре, не все позволяет дохленький проц и малое количество памяти. Пока мне достаточно таймаутов и перевешенного порта чтобы лог не распухал. и да блокировать по ip мне не помогало, запросы шли из разных сетей и не повторялись в приемлемом интервале времени. Кроме того я не хочу чтобы меня забанило когда я буду ломиться без ключей вспоминая/перебирая пароль…
Способ с -m recent Вас забанит максимум на 20 секунд, прописывать адреса он не просит, ловит и банит их сам. Не слышали раньше?
Я упоминаю о recent уже почти в каждом комментарии, и это не просто так. Это решение отличается универсальностью, эффективностью и наименьшей ресурсоемкостью (портнокинг менее универсален).
Хорошо настроенный файрволл избавляет от необходимости что-то выдумывать с переносом порта.
Я упоминаю о recent уже почти в каждом комментарии, и это не просто так. Это решение отличается универсальностью, эффективностью и наименьшей ресурсоемкостью (портнокинг менее универсален).
Хорошо настроенный файрволл избавляет от необходимости что-то выдумывать с переносом порта.
я не хочу автобана, это не решение проблемы, т.к. нынче моден распределенный брутфорс, кроме того я не хочу чтоды глупая железка забанила по ошибке меня, и промедление будет смерти подобно…
В вопросе — ни слова про безопасность и защиту.
Имеет смысл перевешивать ssh для того, чтобы очистить логи.
Имеет смысл перевешивать ssh для того, чтобы очистить логи.
Перевешивать 22ой порт имеет смысл чтобы отбиться от тупых brute-force'ов, не смотря на то, что SSH и без того имеет отличный тайминг на такие случаи. У меня бывало по 10mb логов в день с Auth failed, а то что от port scanner'а таким способом не спрятаться — это очевидно. Просто зачем лишний раз светиться?
от тупых брутфорсеров лично я закрываю снортом. Банит по ip на 24 часа после нескольких неудачных попыток и всё, никакого мусора в логах.
У меня бывало по 10mb логов в день с Auth failed
По 10Mb набегает, если сервер совсем никак не защищен.
Почему бы не использовать от тупого брутфорса такие правила:
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j TARPIT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
Разрешает одну попытку с одного адреса в течение двадцати секунд, иначе — TARPIT. С этим в логах вижу небольшой список хостов и всего одну попытку с каждого из них. И безопасность обеспечивает не ложную, и стандартов не нарушает, оставляя SSH на 22 порту.
iptables и snort хорошие решения, но это решения за пределами самого ssh, в моём случае хватает перевешивания. Тем более что на загруженных серверах, с большим количеством постоянных соединений уже даже загрузка модуля iptables даёт небольшой latency.
Идеально когда стоит одна железка на входе и контроллирует это.
Идеально когда стоит одна железка на входе и контроллирует это.
в важных, сложных и нагруженных системах необходимо применять полноценную hardware-based IPS. Ну и порты, кроме рабочих портов приложения, никакие наружу выставлять нельзя, тем более SSH. Для управления снаружи организовываем VPN. В идеале удаленный доступ админа должен инициировать/согласовывать живой человек — дежурный инженер в дата-центре.
я в качестве эксперимента на ВПСке вообще не включал айпитэйблс. Я внимательно проверил все службы наружу, поотключал что не нужно, регулярно всё обновляю, ссш на нестандартный порт.
Пока что всё нормально.
Пока что всё нормально.
Только как защиту от дурака, наверное.
ну лично мне перевес помог от постоянного брутфорса. логи пестрили файледными логинами, пеервесил на другой порт стало тихо. помогает от недохакеров :)
в каждой организации свой «дефолтный» порт.
Это соображение совершенно справедливо.
Однако многие дурни всё же не пользуются сканерами портов, а ограничиваются анализом порта 22.
Однако многие дурни всё же не пользуются сканерами портов, а ограничиваются анализом порта 22.
Сделайте. Только вероятность увидеть заголовок ответа 1/65000. Либо придётся сделать примерно 65000/2 попыток.
Бывает, что firewall`ом рулить обязан другой человек. Поэтому проще решить задачу не прибегая к «внешним» средствам.
Бывает, что firewall`ом рулить обязан другой человек. Поэтому проще решить задачу не прибегая к «внешним» средствам.
Как защита от дурака — почему нет? Зачем показывать дураку железобетонную дверь, когда можно сказать «ничего нет, нет ничего»?
Как защита от дурака — почему нет?
Заметил, что все называют это защитой от дурака. Не потому ли, что и сама защита дурацкая? Ведь любой, у кого что-то есть в голове, сразу ее обойдет.
Почему нельзя сразу на 22-й порт поставить адекватную защиту, и не устраивать карусель портов?
почему бы не сделать и то и другое?
Для меня это лишь еще одна ступень в защите. Почему бы не перестраховаться и не поставить адекватную защиту на нестандартный порт? И почему карусель? У меня например на работе закрыты нестандартные порты наружу, решаю эту проблему простым редиректом
$ipt -t nat -A PREROUTING -p tcp -s $dist_ip --dport 22 -j REDIRECT --to-port 26
$ipt -t nat -A PREROUTING -p tcp -s $dist_ip --dport 22 -j REDIRECT --to-port 26
Почему бы не перестраховаться и не поставить адекватную защиту на нестандартный порт?Вы не уверены в средствах защиты, которые используете? iptables/fail2ban/sshguard представляют собой средства несравнимо более надежные, нежели какое-то перевешивание порта, причем с их использованием не приходится затрачивать лишнее время на поиск порта, согласование его с другими системными администраторами и прочие неудобства.
«Карусель» потому, что это самое подходящее слово для случая, когда службы занимают нестандартные, неоговоренные порты.
$ipt -t nat -A PREROUTING -p tcp -s $dist_ip --dport 22 -j REDIRECT --to-port 26Что здесь в роли $dist_ip, внешний адрес /32?
На счет удобства использования специальных программных средств. Часто нет времени, а у многих и желания на их изучение. Тем более если не стоит какая то конкретная задача для которой это необходимо. Поэтому многие используют старый провереный способ — перевесил и забыл.
Гнать такого сисадмина взашей, который вместо нормальной защиты просто перевешивает порт :)
Это безусловно, а если не сисадмин? Тут 2 варианта или самому зарываться в документацию или платить деньги. Ну и третий собственно — просто перевесить :)
Но наверняка, кроме перевешивания портов, у такого внимательного сисадмина (задокументировал, обосновал — вау! все бы так…) и пароли не слабые или ключи, возможно, и другие средства защиты. И перевесили порт не из-за незнания, а чтобы ещё круче было. А я говорю именно о таких:
Часто нет времени, а у многих и желания на их изучение.
Абсолютно с вами согласен. Поэтому если человек ещё мало знает, но с энтузиазмом к дальнейшему обучению — ему можно простить многое. А если он перевесил порт и говорит что больше защиты не надо, потому что никто не знает, что SSH на другом порту и совсем не горит желанием изучать внутренности и пр., то именно такого «специалиста» сразу гнать надо. Сам столкнулся с подобной некомпетентностью у нас в университете, где админов набирают из студентов (так положено), а выбирают по знакомству/случаю. Работать в среде этих людей очень тяжело (мне даже не разрешили поднять Active Directory и нормальный файловый сервер для доступа к информации, а сетка достаточно большая и жутко неудобно если надо изменить что-то на всех компах сразу). Не в силах повлиять на ситуацию свалил оттуда сам :) А что говорить о той инфраструктуре, которой заведует подобный человек? Отсюда и берутся стереотипы о компьютерщиках, которые никому не хотят помогать, о глюкавых компьютерах, которые каждый день вываливаются в БСоД и прочих фантастических прелестях.
Согласен, многие пользуются перевешиванием по причине незнания хороших и эффективных средств защиты.
по моему, это вообще не защита…
nmap -sV 1.2.3.4
Порт в настройках shhd не менял. На интерфейсе, смотрящем во «внутреннюю» сеть каких-то ограничений нет, на «внешнем» по умолчанию SYN'ы на 22й порт запрещены. Временный доступ на коннект извне дает knockd, заметив верную комбинации «стуков».
Поддерживаю портнокинг — очень надежная защита, особенно при централизованной атаке ботнета, когда fail2ban и прочие не справляются.
Причем полные параноики могут выставить кучу одноразовых комбинаций стуков.
Для тех кто не знает: эти стуки — по пакету на нужные порты с нужными tcp флагами, в нужном порядке.
Для тех кто не знает: эти стуки — по пакету на нужные порты с нужными tcp флагами, в нужном порядке.
вообще ufw limit 22 проще и быстей, чем перевешивание порта…
Я на своем VDS поменял порт, просто потому что раньше невозможно было читать логи.
Кстати, переопределить порт для конкретного сервера можно в .ssh/config, так что ни запоминать его самому, ни править скрипты, которые как-то используют SSH не нужно.
Кроме того, раньше заморачивался на тему смены banner'а, так что при коннекте телнетом в приглашении отображается не OpenSSH.., а, скажем, binkd/0.92. Но сейчас что-то лень :)
Кстати, переопределить порт для конкретного сервера можно в .ssh/config, так что ни запоминать его самому, ни править скрипты, которые как-то используют SSH не нужно.
Кроме того, раньше заморачивался на тему смены banner'а, так что при коннекте телнетом в приглашении отображается не OpenSSH.., а, скажем, binkd/0.92. Но сейчас что-то лень :)
Защита должна быть комплексной, если у вас не так то
Считаю приемлемым перенос порта, но опять же если вы не используете другие методы защиты :)
хорошо если порт будет выше 1024 а ещё лучше выше 10 000. а ещё лучше…
Практика показывает, что в основном боты перебирают хосты с открытым 22 портом. дальше уже подбор.
Также практика показывает, что идёт сканирование первых 200-300 сотен портов.
так почему бы сразу от них не избавится путём переноса порта? пусть думают, что у меня нет общедоступного ssh, а от школоты что будет сканить чем-то похожим на xPider (кажется так софтина называлась :))) ) помогут другие
Считаю приемлемым перенос порта, но опять же если вы не используете другие методы защиты :)
хорошо если порт будет выше 1024 а ещё лучше выше 10 000. а ещё лучше…
Практика показывает, что в основном боты перебирают хосты с открытым 22 портом. дальше уже подбор.
Также практика показывает, что идёт сканирование первых 200-300 сотен портов.
так почему бы сразу от них не избавится путём переноса порта? пусть думают, что у меня нет общедоступного ssh, а от школоты что будет сканить чем-то похожим на xPider (кажется так софтина называлась :))) ) помогут другие
Больше всего раздражает, что эта школота грузит сервак. Толку-то от этих сканов? Ключ в 4К хрен взломаешь, а даже если взломаешь — логин-то всё равно не рутовый. Но грузят, гады, сервак и замусоривают логи. Вот и приходится портноккинг включать.
даже если взломаешь — логин-то всё равно не рутовый.А есть ли разница между разрешенным рутовым логином по ssh и нерутовым логином по ssh пользователю, у которого есть право sudo?
Иногда это «ну логин же нерутовый» всего лишь самообман.
Пользователя, у которого есть право sudo, ещё пароль можно заставить ввести. Рутовый. По умолчанию, кстати, такая настройка и включена.
Пользователя, у которого есть право sudo, ещё пароль можно заставить ввести. Рутовый.Не рутовый, а свой. Который может быть уже подобран брутфорсом по ssh.
Пароли для SSH — прошлый век. Авторизация по закрытому ключу намного надёжней. И даже если у вас украдут ключ, каким либо образом залогинятся на сервер, ему ещё нужно будет вскрыть пароль. И какова вероятность того, что за всё это время хороший сисадмин, читающий хоть раз в день логи, не заметит вторжения и не примет меры?
э… пользовотелья у которого sudo настроено на права рута вводит только свой пароль, а не рутовый. в этом и есть суть sudo
При наличии логина с ненулевой командной строкой, рутовый доступ — дело техники, особенно если ядро несвежее. Самая короткая дорожка здесь — дырка в сайте, например на php, который умеет shell_exec.
Те, кто настраивают php, так чтобы не рут мог выполнять shell_exec от имени рута — сами виноваты. Уязвимость системы определяется уязвимостью самой слабой её части, так что надеяться, что какой-либо один элемент системы защитит от взлома и пренебрегать остальными — глупо и безрассудно.
Изменение порта не является защитой
По моему, такого уж явного смысла в этом нет. Да, от дураков можно закрыться, но от более менее опытного все равно не спасет (тем более, что дурак может и почитать инструкцию, таких наверняка полно в интернете). По любому даже на нестандартном номере порта нужно будет настраивать дополнительную защиту.
А также использование нестандартного порта может иметь свои последствия — например можно попасть на порт другого сервиса или не сработает программа, использующая ssh.
А также использование нестандартного порта может иметь свои последствия — например можно попасть на порт другого сервиса или не сработает программа, использующая ssh.
Можно отключить pam в openssh и оставить авторизацию по ключам.
Тогда смысл брутофорса логин/пароль станет не эффективным вообще, так как openssh ничего не будет знать об интерактивной авторизации «логин/пароль» и со-но будет отвергать любые попытки интерактивной авторизации.
Тогда смысл брутофорса логин/пароль станет не эффективным вообще, так как openssh ничего не будет знать об интерактивной авторизации «логин/пароль» и со-но будет отвергать любые попытки интерактивной авторизации.
Тут есть один нюанс. Все отвержения — дополнительная нагрузка на процессор, лишние записи в логах и пр.
1. Парсить логи никто не отменял.
grep 'sshd[^ ]*' /var/log/messages | egrep -v «Invalid user»
2. При отключенном pam, нагрузка должна быть минимальной, так как в этом случае не используется системная pam авторизация.
3. Ставим fail2ban, раскоменчиваем некоторые правила и пользуемся. Он умеет интерактивно следить за движняками некоторых сервисов в логах и блочить по кол-ву попыток на определённое время, которое тоже в конфе задаётся.
grep 'sshd[^ ]*' /var/log/messages | egrep -v «Invalid user»
2. При отключенном pam, нагрузка должна быть минимальной, так как в этом случае не используется системная pam авторизация.
3. Ставим fail2ban, раскоменчиваем некоторые правила и пользуемся. Он умеет интерактивно следить за движняками некоторых сервисов в логах и блочить по кол-ву попыток на определённое время, которое тоже в конфе задаётся.
Переписал порт, только для того чтобы логи не росли, при подборе…
Перевесил, все стало тихо =)
Перевесил, все стало тихо =)
да, при размещении в интернете компа с открытым 22-м портом примерно через сутки китайские ботнеты круглосуточно стали подбирать логин/пароль, после смены порта на highport вообще в логах за пару месяцев не встречал попыток подбора и вообще коннектов с левых адресов
Да. Я перевешиваю именно по этой причине. Еще подберут, чего доброго.
Когда Вы перевешивали порт, Вам были известны другие способы защиты? Почему выбор пал на этот способ?
Уважаемый, вам уже несколько раз объяснили, что перевешивание порта — это защита не ssh, а логов.
Чтобы было их удобно читать.
Чтобы можно было разглядеть, что-либо более серьезное.
Слишком много информации в логах — тоже плохо.
Чтобы было их удобно читать.
Чтобы можно было разглядеть, что-либо более серьезное.
Слишком много информации в логах — тоже плохо.
смена порта делается не для безопасности а для удобства — меньше логи, меньше трафик, меньше нагрузка.
если на машине не поднят https, бывает, пересаживаю sshd на 443 — это дополнительно дает возможность логиниться и пробрасывать туннели из «чужих» мест, находясь за squid-ом, в котором connect разрешен только на «безопасные» порты
Абсолютно бесполезное действие. Даже вредное в контексте того, что порт можно забыть и нужно объяснять людям, как попасть на сервер.
Порт все равно просканить — минутное дело. И брутфорсить без разницы, 22 или 22222 порт.
Порт все равно просканить — минутное дело. И брутфорсить без разницы, 22 или 22222 порт.
Очень толсто^W смешно.
Вообще-то, я как раз администрированием серверов и занимаюсь. А в комменте своем мягко намекнул на две вещи:
1) Нужна защита, а не ее иллюзия. Вот iptables\fail2ban\snort — защита, а перевешивание портов — иллюзия. Это примерно как защищаться от взлома квартиры перевешиванием номеров на дверях.
2) Сервер далеко не один (и даже не один десяток, не редко) и разводить зоопарк портов — это очень плохо. (да, я знаю про .ssh/config, ключи и алиасы bash. Но я не всегда в сети с 1 компьютера и думаю я такой не один. Плюс, есть сервисы и софт, которым ssh\scp\sftp нужны для работы и не все умеют легко и корректно менять порты.).
Вообще-то, я как раз администрированием серверов и занимаюсь. А в комменте своем мягко намекнул на две вещи:
1) Нужна защита, а не ее иллюзия. Вот iptables\fail2ban\snort — защита, а перевешивание портов — иллюзия. Это примерно как защищаться от взлома квартиры перевешиванием номеров на дверях.
2) Сервер далеко не один (и даже не один десяток, не редко) и разводить зоопарк портов — это очень плохо. (да, я знаю про .ssh/config, ключи и алиасы bash. Но я не всегда в сети с 1 компьютера и думаю я такой не один. Плюс, есть сервисы и софт, которым ssh\scp\sftp нужны для работы и не все умеют легко и корректно менять порты.).
Профессионал способен обеспечить безопасность сервиса на любом порту, а применение неуниверсальных средств, таких как перевешивание порта, говорит не в пользу профессионала.
Это почему это профессионал не может использовать неуниверсальные средства?
Может, но это говорит не в его пользу. Очень часто без этого нельзя, особенно дело касается самописных скриптов, тут сам Бог велит оформить решение по своему усмотрению. Но профессионал явно не будет полагаться на надежность перевешивания порта, «Авось не заметят».
Выбор универсального решения, наиболее удобного для остальных людей, соответствие нормам, содержание всего на своих местах, упорядоченность конфигурации — вот признаки профессионализма.
Выбор универсального решения, наиболее удобного для остальных людей, соответствие нормам, содержание всего на своих местах, упорядоченность конфигурации — вот признаки профессионализма.
А кто сказал, что профессионал надеется на «Авось не заметят» ???Я пишу, что профессионал ЯВНО НЕ БУДЕТ полагаться на «Авось не заметят».
И кто вам сказал, что профессионал должен делать что-то наиболее удобным для остальных людей, если эти остальные люди делятся на «атакующих» и «непричастных»?
Что я должен ответить, «Илья сказал»? Таково мое понимание профессионализма.
Порт все равно просканить — минутное дело. И брутфорсить без разницы, 22 или 22222 порт.Это всё верно только в том случае, если каждая брутфорс-атака на ваши серверы была изначально нацелена именно на ваш IP-адрес, чтобы найти именно на нём SSH и подбирать пароли. Тогда злоумышленику действительно не сильно важно, какой порт найти: 22 или 22222.
Но в реальном мире обычно происходит так, что атака изначально не направлена именно на ваш IP. Злоумышленики (бот-неты, кул-хацкеры, крякеры, скрипт-киддис) в подавляющем большинстве случаев просто сканируют произвольный диапазон IP-адресов в надежде найти именно на 22 порту SSH-сервис, чтобы потом начать его брутфорсить. Т.е. злоумышленики в реальной жизни гораздо(!) чаще сканируют 22 порт для диапазона IP, нежени диапазон портов для одного конкретного вашего сервера.
И цель смены SSH-порта это не защита от брутфорса паролей, а именно уклонение от веерного тупого сканирования на 22 порт описанных выше злоумышлеников (коих в инете тысячи). В итоге хоть и не гарантируем защиту, но за то не получаем лишнюю нагрузку и лишние записи в логах, и всё это без особых напрягов.
И для указанных целей это действительно хорошо работает и даёт результат. Так почему бы и нет?
Давайте представим, что все SSH-брутфорс-атаки в интернете можно разделить на две группы:
1) Атаки случайных бот-нетов и крякеров, которые просто тупо и нецеленаправленно периодически сканируют диапазоны адресов в поисках сервиса именно на 22 порту (ибо стандарт для SSH).
2) Атаки которые чётко спланированы и изначально направлены именно на ваши серверы (например, по заказу конкурентов).
И по статистике атак первого типа гораздо-гораздо больше, чем вторых.
Перевод SSH на нестандартный порт ограждает сервер от случайных атак первого типа, но разумеется не спасает от нацеленных атак второго типа. И все админы прекрасно понимают это. Но некоторые и не хотят тотально защититься, а хотят просто оградить свой сервер от огромного процента таких вот случайных атак первого типа. И для этих целей перенос SSH на другой порт — это простой и при этом достаточный (в рамках поставленных целей) способ.
Резюме: Если цель не полная защита, а просто уменьшение (на много порядков) числа брутфорс-атак на SSH, то перенос на другой порт — это простая и действенная мера.
1) Атаки случайных бот-нетов и крякеров, которые просто тупо и нецеленаправленно периодически сканируют диапазоны адресов в поисках сервиса именно на 22 порту (ибо стандарт для SSH).
2) Атаки которые чётко спланированы и изначально направлены именно на ваши серверы (например, по заказу конкурентов).
И по статистике атак первого типа гораздо-гораздо больше, чем вторых.
Перевод SSH на нестандартный порт ограждает сервер от случайных атак первого типа, но разумеется не спасает от нацеленных атак второго типа. И все админы прекрасно понимают это. Но некоторые и не хотят тотально защититься, а хотят просто оградить свой сервер от огромного процента таких вот случайных атак первого типа. И для этих целей перенос SSH на другой порт — это простой и при этом достаточный (в рамках поставленных целей) способ.
Резюме: Если цель не полная защита, а просто уменьшение (на много порядков) числа брутфорс-атак на SSH, то перенос на другой порт — это простая и действенная мера.
Но некоторые и не хотят тотально защититься, а хотят просто оградить свой сервер от огромного процента таких вот случайных атак первого типа.В результате, от нацеленного брутфорса они все равно оказываются незащищенными.
Резюме: Если цель не полная защита, а просто уменьшение (на много порядков) числа брутфорс-атак на SSH, то перенос на другой порт — это простая и действенная мера.Согласен. Но в продакшн такое бы не пускал.
Что «нет»? Вы про какой-то конкретный сервер, который точно защищен? Мы с mvgolubev не упоминали ничего о других средствах, его вывод касается только переноса порта.Нет. От этого типа атак сервер защищается немного другими механизмами.Но некоторые и не хотят тотально защититься, а хотят просто оградить свой сервер от огромного процента таких вот случайных атак первого типа.В результате, от нацеленного брутфорса они все равно оказываются незащищенными.
Очевидно же, что перемещение ssh на другой порт не спасает от нацеленного брутфорса.
Если сразу использовать «правильные меры защиты SSH от брутфорса» на дефолтовом 22 порту, то они будут более ресурсоёмкими, т.к. сотни тупых скриптов брутфорса именно 22 порта создают лишний шум и лишнюю нагрузку.
А если сначала отсечь этих «атакующих первого типа» путём изменения SSH-порта, а уже потом ставить на SSH «правильную защиту от брутфорса», то такая защита будет уже менее ресурсоёмкой, т.к. всякая тупая шваль по SSH-порту уже толпами не ломится.
По-моему сейчас речь идёт уже об этом.
А если сначала отсечь этих «атакующих первого типа» путём изменения SSH-порта, а уже потом ставить на SSH «правильную защиту от брутфорса», то такая защита будет уже менее ресурсоёмкой, т.к. всякая тупая шваль по SSH-порту уже толпами не ломится.
По-моему сейчас речь идёт уже об этом.
почему-то обсуждение идет в ключе «перевешивание порта» vs «все остальные методы защиты». Другой порт — это один из пунктов комплексной защиты, скорее полезный, чем вредный, в ряде (не всегда) случаев.
на всех серверах своих юзаю 8-10значные пароли из букв(разный регистр) и цифр. Вроде особо не парюсь по поводу паролей. Хотя на коалокейшне был вынужден сменить порт — там много разного народа тусуется… С изменённым портом вероятность того, что при массовом сканировании найдут куда порт был перемещён — очень мала.
Вот что я думаю. Если порт перевешен, а мы видим долбежку в 22 порт — можем сразу банить такого гражданина, без мудрствований и многих записей в логи.
У меня на некоторых сайтах так сделано — видим, что кто-то начинает стучаться по админским урлам (или тестировать инъекции разные) — баним сразу.
У меня на некоторых сайтах так сделано — видим, что кто-то начинает стучаться по админским урлам (или тестировать инъекции разные) — баним сразу.
хм… никогда не перевешивал, он просто закрыт на публичных интерфейсах.
если нужен SSH — OpenVpn в руки, подключился и изнутри коннекться на стандартный порт.
если нужен SSH — OpenVpn в руки, подключился и изнутри коннекться на стандартный порт.
Дал бог людям докер в 2013 и было это хорошо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оправданно ли размещение SSH на порту, отличном от 22?