Ботнет из Linux-устройств организует DDoS-атаки с потоком трафика 150 Гбит/с и выше

    image

    Ботнет из Linux-устройств разросся настолько, что может генерировать атаки с потоком более 150 Гбит/с, что многократно превышает запас прочности инфраструктуры среднестатистической компании. О начале подобных DDoS-атак сообщили исследователи из Akamai Technologies.

    Сетевой червь, более известный как XOR DDoS, при помощи которого и был собран ботнет, выявили еще в сентябре 2014 года. В январе этого года пользователь Хабра Patr1ot07 опубликовал статью, в которой рассказал о том, как работает зловред.

    Инфицирование начинается с попытки брут-форса SSH, используя логин root. В случае успеха злоумышленники получают доступ к скомпрометированной машине, а затем устанавливают троян, как правило, с помощью шелл-скрипта. Скрипт содержит такие процедуры, как main, check, compiler, uncompress, setup, generate, upload, checkbuild и т.д. и переменные __host_32__, __host_64__, __kernel__, __remote__,, и т.д. Процедура main расшифровывает и выбирает C&C сервер, основываясь на архитектуре системы.


    Исследователи из Akamai Technologies утверждают, что последние DDoS-атаки ботнета имели «мощность» от нескольких, до 150 Гбит/с, а нападению подвергаются до двадцати целей в сутки. Пока основной удар принимает на себя азиатский регион — более 90% целей ботнета XOR DDoS находится именно там. Атакуют, в основном, компании работающие в сфере онлайн-игр, а также образовательные учреждения.

    XOR DDoS является одним из нескольких сетевых червей, которые нацелены конкретно на Linux-системы. Деятельность группы, управляющей зловредом, отражает общую тенденцию по инфицированию оборудования и использования этих мощностей для проведения, в первую очередь, DDoS-атак. Наиболее уязвимыми являются плохо или вовсе не настроенные должным образом системы, а так же «заброшенное», но подключенное к сети оборудование. Исходя из статистики последних двух лет, последнее в особенности касается маршрутизаторов.

    На форумах в сети пишут, что малварь проживает в /lib/libgcc4.so, а в /etc/crontab прописано ее перманентное сохранение с трехминутным таймингом на проверку ( */3 * * * * root /etc/cron.hourly/udev.sh ). Даже если crontab будет вычищен, но XOR DDoS продолжит работать, запись о нем будет восстановлена в полночь пятницы. Полностью с постом об этом можно ознакомиться тут.

    «Десять лет назад Linux позиционировался как безопасная альтернатива Windows, которая в то время серьезно страдала от атак, львиная доля которых приходилась именно на это семейство ОС. Из-за этого Linux все чаще и чаще применялся и применяется для повышения уровня информационной безопасности, но поскольку сфера применения этой системы расширилась, расширились и возможности киберпреступников. Сейчас злоумышленники активно развивают тактику и инструментарий для атак на Linux-системы, поэтому системные администраторы и специалисты по безопасности должны ужесточать свою политику на местах», — прокомментировали в Akamai Technologies.

    В комментариях крайне приветствуется обмен опытом и комментарии от сис.админов и специалистов по информационной безопасности. Возможно, это убережет кого-то от инфицирования.
    ua-hosting.company
    607,00
    Хостинг-провайдер: серверы в NL / US до 100 Гбит/с
    Поделиться публикацией

    Похожие публикации

    Комментарии 62

      +14
      >> Инфицирование начинается с попытки брут-форса SSH, используя логин root.
      Как минимум тут уже написан ответ. А дальше уже зависит от уровня паранойи и продвинутости «сисадмина». Отключения входа по паролю, ограничения по IP, knock-knock, мониторинг адресов с которых идет брутфорс (хотябы fail2ban)… Ну это первое что в голову пришло.
      Но самое главное — отключение входа по ssh для root.
        –8
        Вот отключение логина для root для меня непонятная мера. Правильно — рандомный пароль(т.е. не словарный) достаточной длины. Подобрать его брутфорсом — импоссибле.

        Следовательно попытка логина злоумышленником с использованием этого пароля может произойти только если пароль скомпрометирован. Не вижу, как от этого сценария спасёт запрет логина рутом: юзернейм наверняка утечёт вместе с паролем.
          +3
          В таком случае для меня так же непонятно зачем логиниться на сервер сразу под рутом? Подобрать пароль для рута при том, что логин по ssh под root запрещен, так же импоссибле, как и вход под рутом вообще — скомпрометирован пароль или нет. Может быть Вам так удобнее, мне удобнее так. Я считаю, если пароль есть, то его можно подобрать (пусть даже за 100 миллионов лет :) ), если вход запрещен, то… В любом случае это ИМХО
            +2
            Пару логин + пароль при такой логике тоже можно подобрать, пусть за 100 млн лет.

            Если вам кажется, что дополнительные n символов логина делают возможность подбора логпасса достаточно невероятной, то нужно просто использовать пароль на n символов длиннее (если таки разрешена парольная аутентификация). Делать из логина секрет несколько бессмысленно, он by design решает выполняет другую роль.

            При этом я категорически протестую против работы под рутом. Я только хочу заметить, что отключение рут логина не повышает безопасность, если остаётся sudo -i.
              –3
              Ну в случае пользователя с именем не root сложность брута увеличивается в разы, ибо прежде чем брутить пароль надо убедиться, что пользователь в системе есть.
                +6
                Подбор пары логин (m символов) + пароль (n символов) ничем не отличается от подбора пароля m + n символов. Об этом хотел сказать Self_Perfection
                  0
                  По идее логин хранится в системе как есть, и пароль хешированным, следовательно логин на 15 символов и пароль на 6 проверится системой быстрее чем логин на 6 и пароль на 15. На доли секунды, но быстрее. Или я не прав (что вполне возможно, понятия не имею как на самом деле линукс хранит учётки)?
                    0
                    Эта разница во времени пренебрежимо мала.

                    Зато существенно, что у многих дистрибутивов по-умолчанию pam настроен отвечать о неправильном пароле с задержкой. Где-нибудь 0.3с.
              –4
              Если пароль есть, то его можно, например, украсть. И запрет входа рутом от этого защищает.
            +11
            Но самое главное — отключение входа по ssh для root.


            Нет, не надо отключать вход для рута. Не надо! Это совершенно дурацкая, распиаренная идея.
            Запретить парольный доступ как для рута, так и для остальных пользователей — надо. Отключать доступ вообще не то, что избыточно, а откровенно вредно, так как Вы либо:
            1) Вынуждены использовать сложный (с точки зрения кода) и дырявый sudo.
            2) Вынуждены использовать su, давая возможность использовать локальные эксплойты, так вынуждены иметь рута с паролем.

            Самая оптимальная с точки зрения безопасности стратегия:
            0) Прописываем руту ключи.
            1) Отключаем парольный доступ по ssh для всех, в том числе рута.
            2) Блокируем руту парольный доступ вообще: passwd -l root.
            3) Удаляем\снимаем права на запуск с sudo.
            4) Ставим fail2ban или sshguard для систем с ipv6.

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

            Речь идет исключительно про сервер, на котором Вы решаете только админские задачи.
            Если Вы работаете на линукс-хосте, а не только его админите, то дополнительный пользователь конечно нужен, работать с правами админа везде противопоказано, но отключать удаленный доступ руту полностью при этом не надо.
              –11
              Нечего работать под рутом. Зачем все делать под ним? Кто вас этому научил? Windows?
              Работайте под обычным пользователем. Нужно запустить сервис — ну используйте sudo.
              Запуская все подряд под рутом — вы можете половину файлов в системе заблокировать. Например логи почистить зашел — запустил бэкап, а потом обычный процесс из-под cron не может их удалить…
              Попробуйте запустить из-под root, например, инстанс RabbitMQ (не как сервис) — он вам понаставит права на свои же файлы, а потом не запустится больше…
                +4
                Прочтите последний абзац того, на что Вы отвечаете, пожалуйста.
                  –7
                  Я прочитал с первого раза, спасибо. Админские задачи. А какие например, что вам постоянно нужен именно root?

                  Например, у меня открыто около 15 терминалов постоянно и я все время переключаюсь между ними. Если случайно я выполню команду не в том окне — я не хотел бы чтоб это было из-под root. Наверное я один такой криворукий, но это просто еще один пример.
                  Если я знаю что команда должна быть выполнена с повышенными правами — я использую sudo, у него есть кэш и каждый раз вводить пароль не надо.
                  У меня уже привычка использовать разных юзеров для разных приложений, поэтому для меня немного странными выглядят желания работать из-под root все время.
                    +8
                    Я слабо представляю админские задачи, для которых рут не нужен. Все сервисы работают из-под рута или из-под своих пользователей, которые не имеют действительного шелла. Любая правка их конфигов, любая работа с их логами происходит из-под рута.

                    У меня нет проблем с вводом неправильных данных не туда. У меня настроено приглашение коммандной строки и заголовки окон в screen c подстветкой имени хоста, и печатаю я, глядя на экран, а не на клавиатуру. Поэтому окнами не промахиваюсь. А особо длинные комманды или скопипастнутые я печатаю сначала вставив #.

                    sudo на сервере — отвратная практика в виду немаленькой истории уязвимостей этого sudo. Опять же ссылка на яркий пример в моем первом комменте.
                      –8
                      Ну ок, вы крутой админ, вам можно, убедили. Я буду продолжать как и раньше, мне так спокойнее. А Чак Норрис продолжает заходить как chuck@norris.
                –6
                Мне все-таки хотелось бы услышать аргументы людей, которые минусуют — то есть не согласны?
                Наверное, вы считаете что все правила, которые разработало сообщество Linux — это не для вас, ваши-то уж сервера не сломает никто и на них всегда все правильно и безопасно. Я не навязываю вам это — на то оно и открытое ПО, можно делать что угодно.
                Но почему вы советуете это делать всем? Все пользователи и администраторы могут ошибаться и для их защиты и были разработаны правила и рекомендации. В том числе и временное (!) повышение прав через sudo. Я не вижу чем опаснее указанная ошибка в sudo по сравнению с запуском всего из-под root.
                Сейчас все больше серверов переводят на Linux, все больше новых пользователей у сообщества, в том числе перешедших с Windows и не очень привыкших к урезанию прав — и таким образом вы советуете им продолжать в том же духе? И что мы получим в итоге?
                Делайте сами как вам угодно, но не учите других.
                  +4
                  Но почему вы советуете это делать всем? Все пользователи и администраторы могут ошибаться и для их защиты и были разработаны правила и рекомендации. В том числе и временное (!) повышение прав через sudo. Я не вижу чем опаснее указанная ошибка в sudo по сравнению с запуском всего из-под root.


                  Я отвечу кратко, раз вы никак не усвоите текст первого моего коммента в этой теме:
                  Работать под рутом != админить (выполнять административные задачи) под рутом. Работать под рутом нельзя, правила сообщества говорят совершенно правильно. Работать — это серфить инет, писать код, компилировать код, рисовать, создавать музыку и т.п.
                  Админить под рутом — необходимость, иначе к 99% команд надо приписывать sudo, который просто своим наличием делаем Ваш сервер более уязвимым к локальным эксплойтам.

                  Так что возвращаю Вам Ваш совет. Прежде, чем пытаться кого-то учить — стоит самому разобраться в теме и понять причинно-следственные связи того, чему пытаетесь учить, а не повторять бездумно «мне так сказали! Рут — это плохо, п'нятненько?»
                    –2
                    Я не призываю отключать рута совсем. И 'работать под рутом' — я совершенно не имел в виду что вы у себя на лаптопе под ним браузер запускаете, это все понятно.
                    Но, например, объясните мне в чем я неправ вот в такой гипотетической ситуации:
                    * я скачиваю какой-то пакет из интернета, что-то в нем запускаю (у себя локально, не под рутом)
                    * внезапно этот пакет оказывается слегка вредоносным (причина не важна — но, допустим, источник, который раньше был доверенным — оказался скомпрометирован и код был изменен).
                    * этот пакет идет и вытаскивает все мои ключи из ~/.ssh — они же для чтения текущему пользователю доступны?
                    * с этими ключами он каким-то образом пытается подключиться к некому серверу и оказывается что они у него прописаны для root.
                    В итоге он имеет сразу все права.

                    Напротив — если ключи прописаны у некоего юзера loginuser — то, даже если к нему удастся подключиться, то для повышения привилегий нужно будет выполнить тот же нелюбимый вами sudo, а для него уже нужен пароль. Это дополнительный уровень и пароль вместе с ключами утянуть не так просто.
                    Ну есть в sudo уязвимости, но они, в общем-то, везде есть. А идея была задумана именно для повышения привилегий только когда это необходимо.
                    Почему вы не согласны с этой моделью? Только потому что вам удобно?
                      +3
                      этот пакет идет и вытаскивает все мои ключи из ~/.ssh — они же для чтения текущему пользователю доступны?
                      Если вы храните ключи в .ssh без passphrase — то ССЗБ. Иначе надо знать ещё и пароль для расшифровки приватного ключа.
                        0
                        Спасибо, это единственный разумный ответ, на который я не могу возразить никак. :)
                        +2
                        > объясните мне в чем я неправ вот в такой гипотетической ситуации:
                        > * я скачиваю какой-то пакет из интернета, что-то в нем запускаю (у себя локально, не под рутом)

                        Я перечислю только очевидные ошибки:
                        • «в чём я неправ» необходимо выделять запятыми;
                        • списки в комментариях лучше оформлять тэгами;
                        • запускать рандомные пакеты из Интернета не следует.
                          –2
                          Пожалуйста, давайте не будем превращать все в троллинг. Мне правда хочется все обсудить серьезно. Тэги мне скоро уже нельзя будет использовать, видимо, а запятые — ну что ж делать, виноват.
                          А про рандомные пакеты — мне кажется уже не раз обсуждалось что каждый устанавливамый пакет никто не просматривает сам. История с Bumblebee это доказала без меня.
                          Единственный аргумент который я слышу — «мне удобнее работать под рутом и заходить под ним». Мне хочется выяснить есть ли еще какие-то, чтобы говорить о безопасности, раз уж пошла об этом тема.
                            +1
                            Единственный аргумент который я слышу — «мне удобнее работать под рутом и заходить под ним».


                            Срочно к ЛОРу! Единственное, когда можно предположить, что я говорил про удобство — это тогда, когда говорил, что использовать sudo для административных задач бессмысленно, так как 99% команд идет с sudo, который в это случае никак ничему не помогает.
                            Вместо удобства мы тут вообще за безопасность рассуждаем. Которую setuidная и достаточно сложная программа на сервере, очевидно, снижает.
                              +1
                              > А про рандомные пакеты — мне кажется уже не раз обсуждалось
                              > что каждый устанавливамый пакет никто не просматривает сам.

                              Поэтому их нельзя устанавливать из недоверенного источника, точка.
                              Стандартные репозитории вашего дистрибутива считаются доверенными. Пакеты там отсматриваются ментейнерами-профессионалами. Оттуда устанавливать — можно, из других источников — не следует.

                              Абсолютному большинству троянов (спамерам, шифровальщикам, DDoS-ботам...) root даже не нужен. Используя подобный «метод защиты», вы трогательно заботитесь о своем собственном сервере, но совершенно наплевательски относитесь к другим участникам Сети, которые могут (и будут) страдать из-за вас.

                              Кроме того, если пакет установлен от пользователя с sudo и содержит троян, получить рута на этой машине для трояна — дело техники и пары часов. Так что ваш «метод защиты» ещё и недостаточен.

                              > История с Bumblebee это доказала без меня.

                              Это аргумент из серии «арбузы опасны для здоровья и должны быть запрещены — у меня дядя купил арбуз и отравился».

                              Вы боитесь не того, что опасно, а того, что страшно. Спорадические эпик фейлы могут быть везде, они случаются раз в 10 лет и о них потом слагают легенды, и их вы боитесь. А вот user mode-трояны случаются каждый день, но о них вы не беспокоитесь.

                              От проблем в пакетах из дистрибутива всё равно защититься невозможно. Вы не сможете обновить ядро или libc из user mode, вам придётся запустить инсталлятор из-под root. Если там будет пробел между / и usr — вы пострадаете. Но этот пробел может оказаться там с мизерной вероятностью, которой вы можете пренебречь. А вот вероятностью, что в скачиваемом чёрт знает откуда пакете будет троян, пренебрегать нельзя.
                            0
                            * с этими ключами он каким-то образом пытается подключиться к некому серверу и оказывается что они у него прописаны для root.
                            В итоге он имеет сразу все права.

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


                            Ключ, как уже сказали, обязателен к запароливанию. Так что либо зловреду воровоство ключа никак не поможет, либо они снифает еще и ввод и ему все равно, что снифать Ваш пароль от sudo или мой пароль от ключа. Поэтому тут оба подхода на равных. Но при моем подходе на одну достаточно дырявую программу с setuid битом меньше. Вы же знаете, чем плохи бинарники с setuid?

                            Ну есть в sudo уязвимости, но они, в общем-то, везде есть.


                            Но не на всех есть setuid до рута.
                          +1
                          Мне кажется не надо смешивать две разные ситуации.
                          1) Живешь и работаешь на юникс-машине.
                          2) Ходишь на _удаленный_ _сервер_ поадминить его, как правило с домашней винды.

                          В первом случае противопоказано жить под рутом, те самые правила сообщества линкус, блаблабла, во втором случае наоборот — нет смысла ходить не под рутом, так как всегда идешь сделать что-то рутово-админское,
                          0
                          Отключают вход руту в основном потому, что это системный аккаунт, а не персональный. Админов обычно больше одного и для целей аудита они должны входить в систему под отдельными именованными аккаунтами. Точно так же и с sudo: разобраться в логах «кто что сломал» гораздо проще, чем если все входят под рутом.
                            0
                            Да, я это тоже уже упомянул. Единственное, что в моей практике обычная ситуация как раз тогда, когда админов не больше одного. А когда больше, я обычно главный и отвечаю за остальных. Поэтому себе оставляю рута, а остальным ставлю sudo, сделав его доступным на чтение\запуск (у уровне прав в ФС, а не конфигов sudo) только тем, кому нужно.
                          +4
                          Только ключи. Всё остальное и не удобно и не нужно, если используются ключи.
                            –3
                            У меня есть клиенты, хозяева серверов, которые иногда заходят на них через Putty. Им не очень хочется заморачиваться с конвертацией ключей для Putty и они предпочитают ходить по паролю.
                            Долго объяснять почему я отключаю root не приходится — просто демонстрация security.log или audit.log — и они соглашаются что так спокойнее и можно и порт поменять заодно.
                              +1
                              То есть используете страх не очень хорошо разбирающихся в теме людей? Nice try. Как будто то, что из логов исчезнут сообщения как-то спасёт от реального взлома. Можете повесить ssh на ipv6 адрес, вообще без пароля, ни одного брутфорса не будет или просто логи вытереть — эффект тот же.

                              Ну и, вообще-то, ключи надо генерировать на той машине, где они будут использоваться и потом пересылать открытый ключ на целевой сервер. И в putty есть специальная кнопочка, которую надо нажать один раз за всё время использования.
                                0
                                Ну и, вообще-то, ключи надо генерировать на той машине, где они будут использоваться и потом пересылать открытый ключ на целевой сервер. И в putty есть специальная кнопочка, которую надо нажать один раз за всё время использования.

                                Где угодно можно ключи генерить, главное на хост доставить и в нужное место положить.
                                0
                                Что за бред? О какой конвертации ключей идет речь? Чтобы настроить Putty для авторизации по ключам требуется одна минута вместе с генерацией ключей, прописыванием кодовой фразы и добавлением публичного ключа. Причем это сделать нужно ОДИН раз. Далее каких-либо неудобств для пользователя не возникнет.
                                +1
                                Ключи удобны, пока не придется зайти с телефона, ключ которого не прописан в authorized_keys и не возращается коммандой, прописанной в AuthorizedKeysCommand. А пароли в контейнере (типа keepass) вполне можно иметь и на телефоне. Аналогичная, кстати, проблема с использованием аппаратных токенов (типа yubikey).

                                Я лично предпочитаю оставлять нормальные пароли по 16-20 символов + fail2ban. А обычно хожу по ключу, ибо удобнее.
                                  0
                                  KeePass умеет хранить и ключи.
                                    0
                                    Предпочитаю иметь отдельные ключи для разных машин (и телефонов). Проще делать отзыв, если что.
                                    Но fallback до пароля предпочитаю иметь. Но, на вкус и цвет, все фломастеры разные…
                              +6
                              (простой пользователь rpi/rpi2) Первое, что делаю при настройке линуксов — настраиваю вход по ключу и отключаю вход по паролю.
                                +7
                                Столкнулся с похожим когда-то, с тех пор даже «минутные» генерю через pwgen.
                                  +2
                                  С месяц назад получил заказ на фрилансе посмотреть почему сервак время от времени перестает фунциклировать (приложения не отвечают).
                                  Зашел по SSH (root конечно же), нашел загаженый сервер со светящими наружу всеми возможными портами. В /home/username нашел по две копии папок /etc и /var, в процессах куча процессов /tmp/_mysql и еще чего-то похожего…
                                  Немного покопался, погуглил, понял что сервак, скорее всего, активный член как минимум одного ботнета. У сервера было 32gb памяти и 32 ядра, которые временами все загружались до упора этими странными процессами. Ясно что обычному gunicorn и джанге там времени отводилось не очень много.
                                  Решил что моих знаний не хватит чтобы все выгрести. Заказчику сообщил, что бобик болен и лучше пристрелить — проще сервак снести и заново поставить новый.
                                  На что он мне ответил, что его клиент, хозяин сервера, оплатил его на год и не хочет терять деньги. В основном работает — и ладно.
                                  Денег за работу я не взял.
                                    0
                                    А переналить наживую не)?
                                      0
                                      забыли уточнить, что «поставить новый» имелось в виду фортматнуть жесткий диск?
                                        0
                                        Да, новая чистая свежая операционка и чистый диск.
                                        Это был bare-metal сервер, не виртуальный. Я предлагал обратиться к хостеру и пересоздать сервер чтобы на него поставить все приложения заново руками, но почему-то этот вариант не захотели делать.
                                      +5
                                      Такое ощущение, что изначально статью писали маркетологи мелкомягких, с целью поднагадить GNU/Linux системам. Якобы они теперь небезопасны и представляют угрозу =)
                                      Я уж подумал, действительно какой троян нашёлся. А в итоге, всё сводится к банальному подбору пароля ssh.
                                      Тут конечно, если есть доступ к root — делай что хочешь.
                                        +6
                                        Не ощутил. Статья о том, что ботнеты на базе Linux могут разрастить до огромных размеров, что админы не утруждают себя ставить нормальные пароль от root или использовать сертификаты, что админы ленятся мониторить состояние сервера.
                                          +3
                                          Тот момент, когда человек правильно понимает, что пытался донести автор :). Именно. Вопрос не в холиваре Win VS Linux, а в том, что ботнеты то растут.
                                            +2
                                            Все просто: Наняли человека с фриланса, поставили и забыли. В следующий раз о сервере вспомнят, когда что-то произойдет.
                                          +4
                                          Сейчас злоумышленники активно развивают тактику и инструментарий для атак на Linux-системы

                                          Инфицирование начинается с попытки брут-форса SSH, используя логин root

                                          О даааа, активно развивают! Инструмент по брутфорсу, который был уже N десятков лет назад!
                                            +4
                                            Я бы на их месте и не напрягался ни с чем сложным, если бутфорс работает. Самые эффективные решения чаще всего и самые простые. Вот когда 99,99% сис. админов анально огородят все это дело, то тогда уже будет следующий виток развития.
                                              +1
                                              Лично мне будет очень интересно посмотреть как это они «такими» вещами огородят все «это» дело… И впрямь, следующий виток развития.
                                                +3
                                                Вроде бы пропустили одну букву «Б», а смысл все равно не сильно поменялся.
                                                  +2
                                                  Нет, не пропустил.
                                                0
                                                Брутфорс это ещё не всё, есть куча, даже тьма оборудования, настройки которого оставлены по умолчанию. Т.е. там даже прежде чем использовать брутфорс идёт словарный подбор. Так что проблема почти всегда в людях. Те очень очень редкие и крайне дорогие атаки с эксплойтами для уязвимостей нулевого дня для построения ботнетов никто применять не будет.
                                                * сообщение так же и для ragequit
                                                +1
                                                Нужно просто отключать парольный доступ к root.
                                                Для этого в sshd_config нужно просто указать:
                                                PermitRootLogin without-password
                                                

                                                А дальше уже по желанию.
                                                Хотите — положите ключик в root и логиньтесь под ним, не хотите — не кладите.
                                                В любом случае, root уже защищен.
                                                Осталось подумать над безопасностью остальных юзеров.

                                                поскольку сфера применения этой системы расширилась, расширились и возможности киберпреступников.
                                                Интересно, в какую сторону они расширились.
                                                Получить доступ, указав правильный логн и пароль, можно было всегда.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    Навешивают зищиты на ssh, вводят ограничения по IP в основном те кто мало понимает как вообще всё это работает и где реально слабые места в системе

                                                    В чем же несостоятельность этого решения?
                                                      +2
                                                      Из полей неудобно стучаться. VPN не торт, т.к. он для «таких» людей. А ssh сертификаты в голове не вмещаются, она только для 8+ символов пароля и не более.
                                                        0
                                                        Я про ограничения по IP
                                                          +2
                                                          «Из полей неудобно стучаться.» — люди которые зарабатывают в интернете, в 21 веке часто любят путешествовать, а не сидеть в свой берлоге с крутым статическим айпи. И вообще ограничение по айпи — это хороший способ выстрелить себе в ногу ибо ничто не вечно.
                                                            0
                                                            Аналогично люди не любят запоминать сложные пароль, им лень обновлять ПО и ОСь, они не хотят вдаваться в подробности IT безопасности — к сожалению панацеи от взлома еще не придумали и приходится чем то жертвовать.
                                                      +2
                                                      Статья породила интересное обсуждение.
                                                      Обсуждение показало, что способы защиты доступа являются чем-то религиозным, когда у каждого свое непололебимое мнение.
                                                      Вплоть до «Тут всем надо делать так, тут вот так, а это мне не нравится, поэтому никому так делать не надо».
                                                      Лучший способ что-то проверить — попробовать на практике.
                                                      К сожалению (точнее, к счастью) в дикой природе не так часто ломают так, чтоб сломали.
                                                      Наверное поэтому так много мнений — жизнь не показывает, какое мнение более рабочее.
                                                        0
                                                        Ломают, но не всегда становится известно как и все эти случаи не попадают в общую публичную статистику.
                                                        Все основываются на своем пусть и многолетнем опыте, что конечно совсем нерелевантно. Вот признаюсь, у меня рут не запрещен и совсем короткие и простые пароли от рута, но не словарные — пароль типа «67aha» живет уже больше 10 лет и ничего. Но это конечно не значит что так и надо делать.
                                                        Все что известно — можно сбрутить словарный пароль от рута. С этим все согласны. И это таки случается. Новички непуганные будут всегда — только на них одних можно еще долго строить ботнеты.
                                                        Хороший пароль от рута, вход по ключу, fail2ban — любое из этих средств даже по отдельности практически гарантия от взлома. port!=22 — не гарантия, но реально помогает жить спокойно и без fail2ban — скорее его интересная замена. Что из этого выбрать для своей религии — мне кажется неважно, чисто субъективно и по удобству для каждого индивидуума.
                                                          +1
                                                          У меня как-то рута с паролем вида ho8mxd сбрутили, с тех пор ставлю пароли подлиннее :)

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

                                                      Самое читаемое