Комментарии 25
61% Linux‑хостов не имели установленного пароля для загрузчика операционной системы GRUB
Вопрос специалистам, а как в корпоративной среде отсутствие пароля на загрузчик реально влияет на безопасность? Типа коллега может загрузиться на твоём рабочем месте и взломать твою учётную запись, получив доступ к доступным для неё данным?
Правда интересна точка зрения профессионалов.)))
Может загрузится и чего-нибудь добавить. Чисто теоретически (т.е. вся защита на том что свои так не сделают)
Можно вставить флешку и загрузиться с неё, а дальше - всё что угодно (если диск не зашифрован).
А то и вообще загрузиться по сети.
По-хорошему, даже биос должен быть запаролен, особенно на корпоративных компьютерах. Чтобы без пароля можно было компьютер только включить и выключить, ну или разобрать.
Все в конечном итоге сводится к шифрованию диска. Загрузить какую-то ОС и забрать все данные с диска совсем несложно если диск не зашифрован.
Шифруя диск мы практически лишаем себя возможности восстанавливать на нём информацию в случае сбоя.
По моему мнению, в корпоративной среде вероятность злонамеренной загрузки коллеги с твоего рабочего места не стоит того, чтобы сознательно создавать ситуацию, когда восстановление данных будет невозможно. Требование о шифрации разделов и пароль на загрузку - загон безопасников, приносящий больше вреда, чем пользы.
Достаточно не давать ключи от кабинета кому попало.)))
Это не от коллеги защита. Это защита от потерянного/украденного ноута и доступа к данным кем угодно.
А уникальные невосстановимые данные на ноуте не стоит держать. Ни на личном ни на корпоративном. Все чему больше суток должно бекапиться на сервера. Потерять все за последний день неприятно, но не смертельно.
Для ноутбука за пределами конторы - небольшой частный случай - шифрация и пароль на загрузчик оправданы на 200%. Но не думаю, что под "61% линукс хостами" в статье имелись ввиду ноутбуки.
а вот тут вы ошибаетесь )
в некоторых местах бывает так, что двое рядом сидящих вместе пошли перекусить или на перекур, а вот уже в трех метрах от их мест сидят совершенно незнакомые люди, которые понятия не имеют где чей там компьютер, и кто вон тот молодой человек в костюме (или в футболке), который увлеченно клацает по клавиатуре: новый сотрудник, стажер, или он там всегда сидел, за монитором.
Уже не их отдел, не касается.
Да, с таким офисом не знаком. Но все равно кажется, что это тоже какой-то частный случай.))) И, конечно, здесь нужны будут и шифрация разделов, и пароль на загрузчик. Вот только не понятно, что делать, если что-нибудь украдут из системного блока, раз такие дела. А разъемы клавиатуры и мыши, похоже эпоксидной смолой надо заливать.)))
Для безопасного доступа с рабочего устройства к удаленным системам на macOS и Linux используется протокол SSH. Наиболее безопасной в рамках этого протокола считается аутентификация по специально сгенерированному ключу. Однако на каждом четвертом устройстве аутентификация по ключу отключена, а вместо нее разрешен вход по SSH с аутентификацией по паролю.
Ну если настроен fail2ban и правильный пароль, то не вижу проблемы в доступе с паролем.
А собственно сейчас, держать наружу открытый ssh без fail2ban - уже практически муветон.
Даже имея аутентификацию только по ключу - это не спасает от постоянных попыток войти под рутом с кучей дефолтовых паролей. Чуть чуть полегче, если порт не стандартный, но тоже не спасает от постоянной долбежки с IP со всего мира.
Человек физиологически не способен запомнить достаточно нормальных паролей.
Поэтому никаких паролей для доступа по сети. Где можно используем ключики, где нельзя 2fa, где совсем-совсем нельзя пароль из локальной хранилки паролей.
Пароли можно только для локального доступа к конкретному устройству. Вторым фактором выступает само устройство.
В статье все правильно написали в этом месте. Любой ssh с доступом по паролю из интернета - это дыра и надо срочно закрывать.
А весь мусорный софт вроде fail2ban снесите с серверов. ssh достаточно безопасен сам по себе, костыли не нужны.
Всё это хорошо вписывается в правило аскетизма: если вам нужно только считать, то пользуйтесь калькулятором, а не компьютером. Так и по аналогии: никакого ненужного работающего софта. А сам софт должен очень строго фильтровать свой ввод, минимально по нуждам и строго не более. Всё должно быть урезано по самое мама не могу, за исключением когда что-то вдруг понадобилось.
Я и сейчас с трудом понимаю что значит "нужно настроить файрволл и закрыть порты" - а выключить ненужный софт слушающий нужные ему порты не судьба? Я понимаю, когда функциональность нужна. Но тогда и фильтровать входящих должен сам софт, а не отдельный всемогущий запрещатель Файрволл.
Да, уязвимости существуют, но, имхо, это проблема и дело самого софта, а не стороннего (файрволл, антивирус и т.д.)
Аутентификация с долгоживущими секретами - что по паролю, что по ключу - не является надёжной, хоть и входит по умолчанию в опенсорсные решения. Вендоры уже давно на этом кормятся, предлагая более удачные решения https://www.ssh.com/ssh-zero-trust-access-key-and-secrets-management.
Ключевое слово кормятся.
Этим решения и удачны.
OpenSource это для энтузиастов и админов локалхостов. Решения уровня энтерпрайз - за деньги. Чудес нет.
Вариант с ключами подходит, когда количество хостов и пользователей можно пересчитать по пальцам одной руки. При этом они должны быть хорошо обучены регламентам безопасности. Дальше контроль, ротация и отзывы скомпроментированных ключей становятся неконтролируемыми и все это превращается в профанацию. Попытка самостоятельно навернуть какие-то инструменты сверху обойдётся дороже, чем купить готовое.
Это всё от непонимания.
Нет такой системы, куда должны ходить толпы пользователей, ОСОБЕННО в энтерпрайзе: там есть один департамент, в нем один отдел, и в нем буквально 2-3 человека которые ИМЕЮТ ПРАВО заходить на эту конкретную систему в продакшен и что-то там делать.
Все остальные такого права иметь в принципе не должны, включая начальников.
Иначе потом получается такой головняк, когда приходится вызванивать "специалиста по системе ХХХХ" и обеспечивать ему транспорт, чтобы привезли, подождали пока починит и вернули обратно.
Вы точно работали в энтерпрайзе?
Типичный отдел разработки 10-20 человек. Вместе с линейными руководителями и прочими людьми которые знают что такое ssh и иногда им пользуются.
Таких отделов 5-10 штук в подразделении. Итого под 100 человек уже.
И вот они все ходят куда-то по ssh. С учетом микросервисов это точно более 100 разных серверов. Вероятнее под тысячу.
Итого вам надо управлять сотней ключей на тысяче разных хостов. Люди приходят, уходят, технику теряют, да и просто ключи ротировать неплохо бы. Может купите хорошую систему для этого? Соседнему подразделению тоже надо.
Такую систему можно написать, в общем что от нее надо понятно. Но обычно купить дешевле.
PS: sudo на тысяче хостов можно и не давать всем. Там гранулярность полезна. А вот просто сходить посмотреть под обычным юзером надо иногда всем на все хосты. Ой, sudo тоже надо управлять. Чтобы в 4 ночи когда вашему сеньору чинящему аварию из-за которой бизнес теряет миллионы в час оно срочно понадобилось на сервере соседей он его получил максимум за 5 минут.
Может все таки купите систему для управления всем этим? Там за углом ваши безопасники стоят с требованием отзыва ключей тоже за 5 минут максимум. В любое время дня и ночи. Увольнения и компрометации ключей бывают разные.
У вас отдел разработки напрямую выкладывает свои творения на "боевые" сервера?
Понятно потом, почему сеньору приходится в 4 утра чинить поломанную из-за предновогоднего обновления систему, а бизнесу терять миллионы )
Вот зачем ему, судя по вашим словам, программисту по должности, нужно sudo?
Он еще и серверами занимается, в нагрузку? Бардак.
Это не программная проблема, это проблема в организации работы в вашей компании.
И начинать нужно не с покупки очередной вундерпрограммы, а с совещания наверху, и выяснения кто виноват и что с ним делать.
Через CD это напрямую? Тогда конечно да.
Кто кроме разработки знает что надо выложить вот эти семь микросервисов чтобы кнопка была перекрашена в соответствии с ТЗ? Кто кроме разработки поймет что что-то пошло не так? Кто кроме разработки посмотрит на падения тестов и скажет что ерунда катим? Кто кроме разработки сможет посмотреть на флеймграф или поймать гонку? Кто кроме разработки пойдет читать логи с корками и хипдампами? И вообще поймет что они сейчас нужны.
Причины баги вы установили как-то очень легко и быстро. Допустим вы правы. Тогда все хорошо. Такие баги не требуют отладки в 4 ночи. Дежурный девопс/админ жмет кнопку откатить релиз и все.
А вот если релизов не было полгода, а бага была внесена 12 лет назад появляются проблемы.
Это довольно типичный паттерн разработки и эксплуатации софта. Софт нынче сложный. А тайм то маркет требуют поменьше. Вот и приходится иногда чинить налету.
Разработка выкатывает релиз - пусть сырой, но релиз. С инструкцией по установке и по откату. Протестировав его на тестовой системе.
Технари накатывают релиз по инструкции, если что-то идет не так, хоть что-то, не по скрипту - откатывают обратно немедленно, и докладывают руководству.
А руководство обьясняет разработке, что разрабатывать надо тщательнее, и тестировать надо тщательнее, потому что отказ системы стоит столько, что проще нанять другую команду.
Или купить этим тестовое оборудование, пусть сами там установят, нагрузят, и снимают свои флеймграфы сколько хотят.
А потом выкатят релиз с инструкциями.
Какая модель угроз здесь описана? Какие хосты имеются ввиду, а интернет или в корпоративной сети? Очень много вопросов. Понятное дело, что пароль можно подобрать, он может утечь и тому подобное. Для этого есть средства управления секретами, 2FA, парольные политики и средства мониторинга, типа SIEM. В Энтерпрайзе только так.
Опять же бэкапы ни кто не отменял.
По данным BI.ZONE, две трети хостов у российских компаний уязвимы для кибератак из‑за неправильных настроек