Ботнет из 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.
В комментариях крайне приветствуется обмен опытом и комментарии от сис.админов и специалистов по информационной безопасности. Возможно, это убережет кого-то от инфицирования.
Комментарии (62)
Andrii_Z
01.10.2015 15:53+6(простой пользователь rpi/rpi2) Первое, что делаю при настройке линуксов — настраиваю вход по ключу и отключаю вход по паролю.
baldr
01.10.2015 16:17+2С месяц назад получил заказ на фрилансе посмотреть почему сервак время от времени перестает фунциклировать (приложения не отвечают).
Зашел по SSH (root конечно же), нашел загаженый сервер со светящими наружу всеми возможными портами. В /home/username нашел по две копии папок /etc и /var, в процессах куча процессов /tmp/_mysql и еще чего-то похожего…
Немного покопался, погуглил, понял что сервак, скорее всего, активный член как минимум одного ботнета. У сервера было 32gb памяти и 32 ядра, которые временами все загружались до упора этими странными процессами. Ясно что обычному gunicorn и джанге там времени отводилось не очень много.
Решил что моих знаний не хватит чтобы все выгрести. Заказчику сообщил, что бобик болен и лучше пристрелить — проще сервак снести и заново поставить новый.
На что он мне ответил, что его клиент, хозяин сервера, оплатил его на год и не хочет терять деньги. В основном работает — и ладно.
Денег за работу я не взял.ink08
01.10.2015 17:13забыли уточнить, что «поставить новый» имелось в виду фортматнуть жесткий диск?
baldr
01.10.2015 17:31Да, новая чистая свежая операционка и чистый диск.
Это был bare-metal сервер, не виртуальный. Я предлагал обратиться к хостеру и пересоздать сервер чтобы на него поставить все приложения заново руками, но почему-то этот вариант не захотели делать.
ZoomLS
01.10.2015 16:37+5Такое ощущение, что изначально статью писали маркетологи мелкомягких, с целью поднагадить GNU/Linux системам. Якобы они теперь небезопасны и представляют угрозу =)
Я уж подумал, действительно какой троян нашёлся. А в итоге, всё сводится к банальному подбору пароля ssh.
Тут конечно, если есть доступ к root — делай что хочешь.Delphinum
01.10.2015 16:56+6Не ощутил. Статья о том, что ботнеты на базе Linux могут разрастить до огромных размеров, что админы не утруждают себя ставить нормальные пароль от root или использовать сертификаты, что админы ленятся мониторить состояние сервера.
ragequit
01.10.2015 16:58+3Тот момент, когда человек правильно понимает, что пытался донести автор :). Именно. Вопрос не в холиваре Win VS Linux, а в том, что ботнеты то растут.
ink08
01.10.2015 17:15+2Все просто: Наняли человека с фриланса, поставили и забыли. В следующий раз о сервере вспомнят, когда что-то произойдет.
TimsTims
01.10.2015 16:58+4Сейчас злоумышленники активно развивают тактику и инструментарий для атак на Linux-системы
Инфицирование начинается с попытки брут-форса SSH, используя логин root
О даааа, активно развивают! Инструмент по брутфорсу, который был уже N десятков лет назад!ragequit
01.10.2015 17:01+4Я бы на их месте и не напрягался ни с чем сложным, если бутфорс работает. Самые эффективные решения чаще всего и самые простые. Вот когда 99,99% сис. админов анально огородят все это дело, то тогда уже будет следующий виток развития.
GAS_85
01.10.2015 17:10+1Лично мне будет очень интересно посмотреть как это они «такими» вещами огородят все «это» дело… И впрямь, следующий виток развития.
IRainman
01.10.2015 22:18Брутфорс это ещё не всё, есть куча, даже тьма оборудования, настройки которого оставлены по умолчанию. Т.е. там даже прежде чем использовать брутфорс идёт словарный подбор. Так что проблема почти всегда в людях. Те очень очень редкие и крайне дорогие атаки с эксплойтами для уязвимостей нулевого дня для построения ботнетов никто применять не будет.
* сообщение так же и для ragequit
lexore
01.10.2015 18:02+1Нужно просто отключать парольный доступ к root.
Для этого в sshd_config нужно просто указать:
PermitRootLogin without-password
А дальше уже по желанию.
Хотите — положите ключик в root и логиньтесь под ним, не хотите — не кладите.
В любом случае, root уже защищен.
Осталось подумать над безопасностью остальных юзеров.
поскольку сфера применения этой системы расширилась, расширились и возможности киберпреступников.
Интересно, в какую сторону они расширились.
Получить доступ, указав правильный логн и пароль, можно было всегда.
Ivan_83
01.10.2015 18:14+41. Дыр в не винде всё же меньше, в принципе, хотя бы потому что гуя обычно нет совсем, и в ядре в частности.
2. Экосистема очень фрагментирована поэтому:
а) массовые дыры плохо тиражируются: народ сидит на разных версиях систем и на разном софте тоже разных версий и собранно это всё разными компиляторами с разными ключами…
б) не мало систем не х86 архитектуры
2 thunderspb:
«Отключения входа по паролю, ограничения по IP, knock-knock, мониторинг адресов с которых идет брутфорс (хотябы fail2ban)» — это всё ниочём.
Примерно как написать: отключение в винде входа по паролю, использование смарт карт, установка аудита на неудачные авторизации, лимита на попытки входа.
Никто не будет брутить не словарный пароль длинее 6-8 символов, когда на сервере стоит какойнибудь апач с пхп и вордпресом или ещё какое говно с кучей дыр.
Обычно боты быстро проверят по словарю и отваливают, им некогда возится с очередным сервером, когда ещё тысячи есть.
Отключение рута — глупость и неудобства.
С точки зрения нападающего логин это часть того что нужно подобрать, почти всегда оно или короткое или словарное, в некоторых случаях можно легко узнать или догадаться какой логин у кокретного человека.
Те нападающий подбирает логин+пароль, то что вы отключаете рута вообще ни на что не влияет, кроме содержания лог файлов.
Я уже молчу про то, что большинство ботнетов спокойно работают без прав рута, им на это плевать!
Мне обычно хватало просто не словарного пароля на 8+ символов и встроенного в OpenSSH лимитера.
В последнее время я отключил всё кроме ED25519, chacha20-poly1305 / aes256 и mac тоже какие то навороченные оставил, теперь боты отсекаются на этапе согласования, ещё до отправки логина/пароля.
Ещё большего эффекта можно добится заменив 22 на другое число.
Вход по ключу несомненно секурнее, но менее удобен когда сам ты в полях, кроме того ключ это файл и его можно потерять вместе с носителем, пароль же обычно в голове и потеря носителя делает не актуальной проблему потери пароля :)
Ключ удобен для автоматического входа и не более.
Ещё у меня есть наблюдение.
Навешивают зищиты на ssh, вводят ограничения по IP в основном те кто мало понимает как вообще всё это работает и где реально слабые места в системе. Те вот такое бездумное применение защиты: поставить все защиты о каких слышал.
Ещё такие люди любят использовать VPN для защиты ssh/rdp, типа так безопаснее, только часто пароль на VPN такой же, а сам впн — pptp/l2tp, которые по факту даже пароль толком сохранить в секрете не могут и уж точно от брута защищены ещё хуже.
Ну и на охраняемых таким образом серверах обычно тоже треш и угар: обновления или вообще не ставились или ставились неизвестно когда, зато всякого говна понаставлено что нужен Геракл для разгребания этих конюшен.
Delphinum
01.10.2015 18:22Навешивают зищиты на ssh, вводят ограничения по IP в основном те кто мало понимает как вообще всё это работает и где реально слабые места в системе
В чем же несостоятельность этого решения?Askon
01.10.2015 23:36+2Из полей неудобно стучаться. VPN не торт, т.к. он для «таких» людей. А ssh сертификаты в голове не вмещаются, она только для 8+ символов пароля и не более.
Delphinum
02.10.2015 00:21Я про ограничения по IP
ArjLover
02.10.2015 01:38+2«Из полей неудобно стучаться.» — люди которые зарабатывают в интернете, в 21 веке часто любят путешествовать, а не сидеть в свой берлоге с крутым статическим айпи. И вообще ограничение по айпи — это хороший способ выстрелить себе в ногу ибо ничто не вечно.
Delphinum
02.10.2015 14:14Аналогично люди не любят запоминать сложные пароль, им лень обновлять ПО и ОСь, они не хотят вдаваться в подробности IT безопасности — к сожалению панацеи от взлома еще не придумали и приходится чем то жертвовать.
lexore
02.10.2015 00:21+2Статья породила интересное обсуждение.
Обсуждение показало, что способы защиты доступа являются чем-то религиозным, когда у каждого свое непололебимое мнение.
Вплоть до «Тут всем надо делать так, тут вот так, а это мне не нравится, поэтому никому так делать не надо».
Лучший способ что-то проверить — попробовать на практике.
К сожалению (точнее, к счастью) в дикой природе не так часто ломают так, чтоб сломали.
Наверное поэтому так много мнений — жизнь не показывает, какое мнение более рабочее.ArjLover
02.10.2015 01:51Ломают, но не всегда становится известно как и все эти случаи не попадают в общую публичную статистику.
Все основываются на своем пусть и многолетнем опыте, что конечно совсем нерелевантно. Вот признаюсь, у меня рут не запрещен и совсем короткие и простые пароли от рута, но не словарные — пароль типа «67aha» живет уже больше 10 лет и ничего. Но это конечно не значит что так и надо делать.
Все что известно — можно сбрутить словарный пароль от рута. С этим все согласны. И это таки случается. Новички непуганные будут всегда — только на них одних можно еще долго строить ботнеты.
Хороший пароль от рута, вход по ключу, fail2ban — любое из этих средств даже по отдельности практически гарантия от взлома. port!=22 — не гарантия, но реально помогает жить спокойно и без fail2ban — скорее его интересная замена. Что из этого выбрать для своей религии — мне кажется неважно, чисто субъективно и по удобству для каждого индивидуума.drakmail
02.10.2015 11:27+1У меня как-то рута с паролем вида ho8mxd сбрутили, с тех пор ставлю пароли подлиннее :)
thunderspb
>> Инфицирование начинается с попытки брут-форса SSH, используя логин root.
Как минимум тут уже написан ответ. А дальше уже зависит от уровня паранойи и продвинутости «сисадмина». Отключения входа по паролю, ограничения по IP, knock-knock, мониторинг адресов с которых идет брутфорс (хотябы fail2ban)… Ну это первое что в голову пришло.
Но самое главное — отключение входа по ssh для root.
Self_Perfection
Вот отключение логина для root для меня непонятная мера. Правильно — рандомный пароль(т.е. не словарный) достаточной длины. Подобрать его брутфорсом — импоссибле.
Следовательно попытка логина злоумышленником с использованием этого пароля может произойти только если пароль скомпрометирован. Не вижу, как от этого сценария спасёт запрет логина рутом: юзернейм наверняка утечёт вместе с паролем.
thunderspb
В таком случае для меня так же непонятно зачем логиниться на сервер сразу под рутом? Подобрать пароль для рута при том, что логин по ssh под root запрещен, так же импоссибле, как и вход под рутом вообще — скомпрометирован пароль или нет. Может быть Вам так удобнее, мне удобнее так. Я считаю, если пароль есть, то его можно подобрать (пусть даже за 100 миллионов лет :) ), если вход запрещен, то… В любом случае это ИМХО
Self_Perfection
Пару логин + пароль при такой логике тоже можно подобрать, пусть за 100 млн лет.
Если вам кажется, что дополнительные n символов логина делают возможность подбора логпасса достаточно невероятной, то нужно просто использовать пароль на n символов длиннее (если таки разрешена парольная аутентификация). Делать из логина секрет несколько бессмысленно, он by design решает выполняет другую роль.
При этом я категорически протестую против работы под рутом. Я только хочу заметить, что отключение рут логина не повышает безопасность, если остаётся sudo -i.
thunderspb
Ну в случае пользователя с именем не root сложность брута увеличивается в разы, ибо прежде чем брутить пароль надо убедиться, что пользователь в системе есть.
Blumfontein
Подбор пары логин (m символов) + пароль (n символов) ничем не отличается от подбора пароля m + n символов. Об этом хотел сказать Self_Perfection
vlreshet
По идее логин хранится в системе как есть, и пароль хешированным, следовательно логин на 15 символов и пароль на 6 проверится системой быстрее чем логин на 6 и пароль на 15. На доли секунды, но быстрее. Или я не прав (что вполне возможно, понятия не имею как на самом деле линукс хранит учётки)?
Self_Perfection
Эта разница во времени пренебрежимо мала.
Зато существенно, что у многих дистрибутивов по-умолчанию pam настроен отвечать о неправильном пароле с задержкой. Где-нибудь 0.3с.
ComodoHacker
Если пароль есть, то его можно, например, украсть. И запрет входа рутом от этого защищает.
J_o_k_e_R
Нет, не надо отключать вход для рута. Не надо! Это совершенно дурацкая, распиаренная идея.
Запретить парольный доступ как для рута, так и для остальных пользователей — надо. Отключать доступ вообще не то, что избыточно, а откровенно вредно, так как Вы либо:
1) Вынуждены использовать сложный (с точки зрения кода) и дырявый sudo.
2) Вынуждены использовать su, давая возможность использовать локальные эксплойты, так вынуждены иметь рута с паролем.
Самая оптимальная с точки зрения безопасности стратегия:
0) Прописываем руту ключи.
1) Отключаем парольный доступ по ssh для всех, в том числе рута.
2) Блокируем руту парольный доступ вообще: passwd -l root.
3) Удаляем\снимаем права на запуск с sudo.
4) Ставим fail2ban или sshguard для систем с ipv6.
Единственное, когда в системе нужен sudo, когда на сервере есть пользователи, которым нужен ограниченный рут-доступ. Но это намного более редкая другая история.
Речь идет исключительно про сервер, на котором Вы решаете только админские задачи.
Если Вы работаете на линукс-хосте, а не только его админите, то дополнительный пользователь конечно нужен, работать с правами админа везде противопоказано, но отключать удаленный доступ руту полностью при этом не надо.
baldr
Нечего работать под рутом. Зачем все делать под ним? Кто вас этому научил? Windows?
Работайте под обычным пользователем. Нужно запустить сервис — ну используйте sudo.
Запуская все подряд под рутом — вы можете половину файлов в системе заблокировать. Например логи почистить зашел — запустил бэкап, а потом обычный процесс из-под cron не может их удалить…
Попробуйте запустить из-под root, например, инстанс RabbitMQ (не как сервис) — он вам понаставит права на свои же файлы, а потом не запустится больше…
J_o_k_e_R
Прочтите последний абзац того, на что Вы отвечаете, пожалуйста.
baldr
Я прочитал с первого раза, спасибо. Админские задачи. А какие например, что вам постоянно нужен именно root?
Например, у меня открыто около 15 терминалов постоянно и я все время переключаюсь между ними. Если случайно я выполню команду не в том окне — я не хотел бы чтоб это было из-под root. Наверное я один такой криворукий, но это просто еще один пример.
Если я знаю что команда должна быть выполнена с повышенными правами — я использую sudo, у него есть кэш и каждый раз вводить пароль не надо.
У меня уже привычка использовать разных юзеров для разных приложений, поэтому для меня немного странными выглядят желания работать из-под root все время.
J_o_k_e_R
Я слабо представляю админские задачи, для которых рут не нужен. Все сервисы работают из-под рута или из-под своих пользователей, которые не имеют действительного шелла. Любая правка их конфигов, любая работа с их логами происходит из-под рута.
У меня нет проблем с вводом неправильных данных не туда. У меня настроено приглашение коммандной строки и заголовки окон в screen c подстветкой имени хоста, и печатаю я, глядя на экран, а не на клавиатуру. Поэтому окнами не промахиваюсь. А особо длинные комманды или скопипастнутые я печатаю сначала вставив #.
sudo на сервере — отвратная практика в виду немаленькой истории уязвимостей этого sudo. Опять же ссылка на яркий пример в моем первом комменте.
baldr
Ну ок, вы крутой админ, вам можно, убедили. Я буду продолжать как и раньше, мне так спокойнее. А Чак Норрис продолжает заходить как chuck@norris.
baldr
Мне все-таки хотелось бы услышать аргументы людей, которые минусуют — то есть не согласны?
Наверное, вы считаете что все правила, которые разработало сообщество Linux — это не для вас, ваши-то уж сервера не сломает никто и на них всегда все правильно и безопасно. Я не навязываю вам это — на то оно и открытое ПО, можно делать что угодно.
Но почему вы советуете это делать всем? Все пользователи и администраторы могут ошибаться и для их защиты и были разработаны правила и рекомендации. В том числе и временное (!) повышение прав через sudo. Я не вижу чем опаснее указанная ошибка в sudo по сравнению с запуском всего из-под root.
Сейчас все больше серверов переводят на Linux, все больше новых пользователей у сообщества, в том числе перешедших с Windows и не очень привыкших к урезанию прав — и таким образом вы советуете им продолжать в том же духе? И что мы получим в итоге?
Делайте сами как вам угодно, но не учите других.
J_o_k_e_R
Я отвечу кратко, раз вы никак не усвоите текст первого моего коммента в этой теме:
Работать под рутом != админить (выполнять административные задачи) под рутом. Работать под рутом нельзя, правила сообщества говорят совершенно правильно. Работать — это серфить инет, писать код, компилировать код, рисовать, создавать музыку и т.п.
Админить под рутом — необходимость, иначе к 99% команд надо приписывать sudo, который просто своим наличием делаем Ваш сервер более уязвимым к локальным эксплойтам.
Так что возвращаю Вам Ваш совет. Прежде, чем пытаться кого-то учить — стоит самому разобраться в теме и понять причинно-следственные связи того, чему пытаетесь учить, а не повторять бездумно «мне так сказали! Рут — это плохо, п'нятненько?»
baldr
Я не призываю отключать рута совсем. И 'работать под рутом' — я совершенно не имел в виду что вы у себя на лаптопе под ним браузер запускаете, это все понятно.
Но, например, объясните мне в чем я неправ вот в такой гипотетической ситуации:
* я скачиваю какой-то пакет из интернета, что-то в нем запускаю (у себя локально, не под рутом)
* внезапно этот пакет оказывается слегка вредоносным (причина не важна — но, допустим, источник, который раньше был доверенным — оказался скомпрометирован и код был изменен).
* этот пакет идет и вытаскивает все мои ключи из ~/.ssh — они же для чтения текущему пользователю доступны?
* с этими ключами он каким-то образом пытается подключиться к некому серверу и оказывается что они у него прописаны для root.
В итоге он имеет сразу все права.
Напротив — если ключи прописаны у некоего юзера loginuser — то, даже если к нему удастся подключиться, то для повышения привилегий нужно будет выполнить тот же нелюбимый вами sudo, а для него уже нужен пароль. Это дополнительный уровень и пароль вместе с ключами утянуть не так просто.
Ну есть в sudo уязвимости, но они, в общем-то, везде есть. А идея была задумана именно для повышения привилегий только когда это необходимо.
Почему вы не согласны с этой моделью? Только потому что вам удобно?
grossws
baldr
Спасибо, это единственный разумный ответ, на который я не могу возразить никак. :)
ximaera
> объясните мне в чем я неправ вот в такой гипотетической ситуации:
> * я скачиваю какой-то пакет из интернета, что-то в нем запускаю (у себя локально, не под рутом)
Я перечислю только очевидные ошибки:
baldr
Пожалуйста, давайте не будем превращать все в троллинг. Мне правда хочется все обсудить серьезно. Тэги мне скоро уже нельзя будет использовать, видимо, а запятые — ну что ж делать, виноват.
А про рандомные пакеты — мне кажется уже не раз обсуждалось что каждый устанавливамый пакет никто не просматривает сам. История с Bumblebee это доказала без меня.
Единственный аргумент который я слышу — «мне удобнее работать под рутом и заходить под ним». Мне хочется выяснить есть ли еще какие-то, чтобы говорить о безопасности, раз уж пошла об этом тема.
J_o_k_e_R
Срочно к ЛОРу! Единственное, когда можно предположить, что я говорил про удобство — это тогда, когда говорил, что использовать sudo для административных задач бессмысленно, так как 99% команд идет с sudo, который в это случае никак ничему не помогает.
Вместо удобства мы тут вообще за безопасность рассуждаем. Которую setuidная и достаточно сложная программа на сервере, очевидно, снижает.
ximaera
> А про рандомные пакеты — мне кажется уже не раз обсуждалось
> что каждый устанавливамый пакет никто не просматривает сам.
Поэтому их нельзя устанавливать из недоверенного источника, точка.
Стандартные репозитории вашего дистрибутива считаются доверенными. Пакеты там отсматриваются ментейнерами-профессионалами. Оттуда устанавливать — можно, из других источников — не следует.
Абсолютному большинству троянов (спамерам, шифровальщикам, DDoS-ботам...) root даже не нужен. Используя подобный «метод защиты», вы трогательно заботитесь о своем собственном сервере, но совершенно наплевательски относитесь к другим участникам Сети, которые могут (и будут) страдать из-за вас.
Кроме того, если пакет установлен от пользователя с sudo и содержит троян, получить рута на этой машине для трояна — дело техники и пары часов. Так что ваш «метод защиты» ещё и недостаточен.
> История с Bumblebee это доказала без меня.
Это аргумент из серии «арбузы опасны для здоровья и должны быть запрещены — у меня дядя купил арбуз и отравился».
Вы боитесь не того, что опасно, а того, что страшно. Спорадические эпик фейлы могут быть везде, они случаются раз в 10 лет и о них потом слагают легенды, и их вы боитесь. А вот user mode-трояны случаются каждый день, но о них вы не беспокоитесь.
От проблем в пакетах из дистрибутива всё равно защититься невозможно. Вы не сможете обновить ядро или libc из user mode, вам придётся запустить инсталлятор из-под root. Если там будет пробел между / и usr — вы пострадаете. Но этот пробел может оказаться там с мизерной вероятностью, которой вы можете пренебречь. А вот вероятностью, что в скачиваемом чёрт знает откуда пакете будет троян, пренебрегать нельзя.
J_o_k_e_R
Ключ, как уже сказали, обязателен к запароливанию. Так что либо зловреду воровоство ключа никак не поможет, либо они снифает еще и ввод и ему все равно, что снифать Ваш пароль от sudo или мой пароль от ключа. Поэтому тут оба подхода на равных. Но при моем подходе на одну достаточно дырявую программу с setuid битом меньше. Вы же знаете, чем плохи бинарники с setuid?
Но не на всех есть setuid до рута.
ArjLover
Мне кажется не надо смешивать две разные ситуации.
1) Живешь и работаешь на юникс-машине.
2) Ходишь на _удаленный_ _сервер_ поадминить его, как правило с домашней винды.
В первом случае противопоказано жить под рутом, те самые правила сообщества линкус, блаблабла, во втором случае наоборот — нет смысла ходить не под рутом, так как всегда идешь сделать что-то рутово-админское,
Vayun
Отключают вход руту в основном потому, что это системный аккаунт, а не персональный. Админов обычно больше одного и для целей аудита они должны входить в систему под отдельными именованными аккаунтами. Точно так же и с sudo: разобраться в логах «кто что сломал» гораздо проще, чем если все входят под рутом.
J_o_k_e_R
Да, я это тоже уже упомянул. Единственное, что в моей практике обычная ситуация как раз тогда, когда админов не больше одного. А когда больше, я обычно главный и отвечаю за остальных. Поэтому себе оставляю рута, а остальным ставлю sudo, сделав его доступным на чтение\запуск (у уровне прав в ФС, а не конфигов sudo) только тем, кому нужно.
ivlis
Только ключи. Всё остальное и не удобно и не нужно, если используются ключи.
baldr
У меня есть клиенты, хозяева серверов, которые иногда заходят на них через Putty. Им не очень хочется заморачиваться с конвертацией ключей для Putty и они предпочитают ходить по паролю.
Долго объяснять почему я отключаю root не приходится — просто демонстрация security.log или audit.log — и они соглашаются что так спокойнее и можно и порт поменять заодно.
ivlis
То есть используете страх не очень хорошо разбирающихся в теме людей? Nice try. Как будто то, что из логов исчезнут сообщения как-то спасёт от реального взлома. Можете повесить ssh на ipv6 адрес, вообще без пароля, ни одного брутфорса не будет или просто логи вытереть — эффект тот же.
Ну и, вообще-то, ключи надо генерировать на той машине, где они будут использоваться и потом пересылать открытый ключ на целевой сервер. И в putty есть специальная кнопочка, которую надо нажать один раз за всё время использования.
mureevms
Где угодно можно ключи генерить, главное на хост доставить и в нужное место положить.
pwrlnd
Что за бред? О какой конвертации ключей идет речь? Чтобы настроить Putty для авторизации по ключам требуется одна минута вместе с генерацией ключей, прописыванием кодовой фразы и добавлением публичного ключа. Причем это сделать нужно ОДИН раз. Далее каких-либо неудобств для пользователя не возникнет.
grossws
Ключи удобны, пока не придется зайти с телефона, ключ которого не прописан в authorized_keys и не возращается коммандой, прописанной в AuthorizedKeysCommand. А пароли в контейнере (типа keepass) вполне можно иметь и на телефоне. Аналогичная, кстати, проблема с использованием аппаратных токенов (типа yubikey).
Я лично предпочитаю оставлять нормальные пароли по 16-20 символов + fail2ban. А обычно хожу по ключу, ибо удобнее.
pwrlnd
KeePass умеет хранить и ключи.
grossws
Предпочитаю иметь отдельные ключи для разных машин (и телефонов). Проще делать отзыв, если что.
Но fallback до пароля предпочитаю иметь. Но, на вкус и цвет, все фломастеры разные…