Pull to refresh

Comments 80

Спасибо, вечером обязательно попробую!
многие (да почти все) загрузчики позволяют войти в SINGLE USER mode. На той же мак оси снос рутового пароля занимает минуты 2.
UFO just landed and posted this here
Еще один вывод — шифруйте домашние каталоги. Благо дело сейчас эту опцию использовать просто.
UFO just landed and posted this here
Потому и было сказано «ещё один». Потому как важность защиты груба паролем — вывод из данной статьи первый и очевидный. :)
UFO just landed and posted this here
UFO just landed and posted this here
Вот-вот. Последний раз когда проделывал такую историю с grub на шифрованный раздел. А сейчас многие дистрибутивы шифруют его по умолчанию. Хотя с шифрованием тоже надо быть осторожным.
Но все равно автору спасибо на статью.
UFO just landed and posted this here
О том-то и речь: возможность совершенно не секретная, но о ней никто не задумывается. В то же время, чем это может грозить — тоже несложно догадаться.
Почему «никто»? Я традиционно стою на позиции «доступ к консоли==физический доступ». В этом случае любые телодвижения глупы. (ровно так же, любой мудак, дорвавшийся до консоли сервера может сделать Alt-SysRq-K(H) и положить все сервисы).

Если же мы начинаем изобретать полумеры в виде «доступ к консоли но не рут», то тут остаётся шаманить. Но правильное решение — обеспечение недоверенной сети для загрузки с установлением доверенных соединений по её окончании. Любые запаивания системников всё равно обходятся.
В школе очень удобно использовать удалённую загрузку для проведения тестов. Даже если ученик получит рутовый шелл на своей машине, то это абсолютно ничего ему не даст.
Зато он может попытаться скомпрометировать учетку преподавателя. Естественно, при правильных настройках оси и системы тестирования, это ему не даст, но когда вы последний раз видели грамотно настроенную сеть в школе?
Зачем в образе системы, предназначенном для удалённой загрузки, учётная запись преподавателя?
Если есть единый сервер авторизации (виндовый домен, к примеру), то на нем будет и учетка преподавателя. Если на компьютере преподавателя в локальную копию профиля в авторан накидать троянцев, то компрометация будет осуществлена. Вообще, все сильно зависит от конкретных настроек, так что гадать — дело неблагодарное.
Авторан, виндовый домен…
Тут как бы про Linux в школе и удаленный бут говорят.
Я знаю, что пример не вполне корректный для школы. Но это реальная ситуация в наших универских терминалках.
Если бы я такую конструкцию (в виндах) делал, то разумеется, профили бы персонала лежали на DFS-шаре, а не локально.
Казалось бы — каким образом этот топик относится к информационной безопасности? Так же, как и ростоянный совет «делайте пароли сложными»?
Смотрите лирическое отступление.
насколько я помню, init=/bin/bash давал не полный доступ, а рид-онли. во всяком случае, изменения не сохранялись
незабываем примаунтить корень на чтение/запись :)
/sbin/mount -wu /
Да в общем совершенный баян конечно. GRUB ничего особенного не умеет такого, просто надо ставить на него пароль, если вы не хотите, чтобы в ваш компьютер через него могли влезть. Single mode — это вообще особенность Linux, а не GRUB, кстати.
Собственно, именно это и надо делать. Именно об этом и топик.
UFO just landed and posted this here
Начнем с того, что не все загрузчики позволяют грузиться со внешних носителей, в обход ограничений BIOS. Пример — isolinux и его брат syslinux. А GRUB позволяет.
Во-вторых, я и говорю о том, что если загрузчик позволяет редактировать параметры загрузки, то эту возможность надо защищать.
В-третьих, прежде чем написать эту статью, я пол года наблюдал эту проблему в самых разных организациях. Из виденного мною за эти пол года ни один админ так и не поставил пароль на GRUB.
UFO just landed and posted this here
UFO just landed and posted this here
Тема security при наличии физического доступа к машине слегка надуманная. Потому что нет никакой security. Поэтому в GRUB и есть этот ключик про доступ root-ом: нет смысла защищаться.
Вопрос лишь в том, насколько плотный физический контакт нужен для получения доступа к данным. Одно дело — быстро загрузиться с флешки, и совсем другое — разворотить системник, которые, кстати, нередко опечатывают.
Шифруем ФС, паролируем всё открытое.
Не 100% защиты, но пару лет(а то и десяток) при больших объемах на раскодировку потратят.
За это время инфа уже станет не актуальной как минимум.
Так что смысл есть и он обоснован.
Угум. Только шифрование винта никакого отношения к запуску системы из-под рута или не из-под рута не имеет.
> Тема security при наличии физического доступа к машине слегка надуманная. Потому что нет никакой security. Поэтому в GRUB и есть этот ключик про доступ root-ом: нет смысла защищаться.

По предложениям:
Тема security при наличии физического доступа не надуманная, можно защитится и при таком доступе.
Она есть, какая я уже написал.
Смысл защищатся есть, root доступ далеко не панацея.

Угум.
Не скучно спорить без контекста? :)
Может вам и скучно.
Но я не спорил.
Я констатировал некорректность ваших утверждений, обосновав каждое свое слово.
Вижу в этом топике много людей, рассуждающих о том, что этот пост баянист и вообще описан в man. Но у меня есть вопрос к тем людям, у которых на вход в линукс (а точнее в графическую среду) стоит пароль: а Вы выполнили меры предосторожности против такой ситуации?
Особенно феерично ответ «нет» будет смотреться на фоне того, что на вход пароль должен стоять у всех, ибо иначе это не linux-way.
UFO just landed and posted this here
А я всегда считал, что при запрете внешних носителей, пароле на bios и на вход в ОС, безопасность практически 100%, можно разве что утащить винчестер, но это могут случайно обнаружить.
Физический доступ — он может быть и ограниченным клавой, мышей и монитором.
Пароль на биос и запрет внешних носителей снимается перетыканием перемычки на материнке. Нужно как минимум опечатывать корпус.
Я лично как-то (когда делал такие корпуса на склад и обнаружил, что слажал с конструкцией) цеплял CDюк засунув руку в дырку от вынутых 5.25" устройств (расклёпывать лениво было). В принципе, можно на спор сделать «сброс настроек биоса проволочкой через вентиляционные отверстия».

Но нужно ли? Физический доступ = недоверенное устройство на том уровне, на котором есть физический доступ.
И что приходим, со своей клавой, монитором и мышкой и системником. Делаем копию диска и идем домой читать.
Ребят, это конечно же весело, но давайте представим такую ситуацию:
Вы устроились на работу, специально, чтобы вынести некоторую информацию из некоторой компании. На входе вас проверяют на подозрительную ерунду типа мышек, клав и мониторов. И на выходе так же. Ничего не принести, не вынести. Корпус опечатан, запрет на загрузку с внешних носителей, пароль на биос.
Но это ерунда — у вас то есть физический доступ. Правда он ограничен. Жестоко ограничен.
А теперь представьте, что вам повезло, и кое-какой индюк не удосужился поставить пароль на grub.
А теперь представьте, что в роли этого индюка — вы. Хотите быть индюком? То-то же!

Лишняя информация о возможной уязвимости — это хорошо. Даже если это баян с вашей точки зрения.
Мышку, клаву и монитор вам дадут на работе. Их не нужно будет вносить. Да ну и что по вашему нельзя пронести на работу микросхему от флешки и загрузиться с нее? Если важный раздел с данными не зашифрован. Соответственно ваш пароль на груб не будет никого защищать.
нет :) пароль на вход стоит, но он не для ограничения доступа того, кто имеет физический доступ он стоит, а чтобы:
а) был повод лишний раз подумать «а оно мне надо» перед запуском команды из под sudo/gksu
б) ограничить удалённый доступа (sshd проброшен на vps, чтобы в любой момент мог зайти на домашний комп, например, с работы, а периодически к sshd пытаются коннектиться)
> И не стоит недооценивать школьников
М-да. Да, не стоит их недооценивать, некоторые могут и хабр читать, а некоторым, представляете, может быть обидно про себя такое читать.
Вспомнил как регулярно получал рутовский suid-ный исполняемый файл шелла через single user mode в FreeBSD.
ну там проще, /etc/ttys
# If console is marked «insecure», then init will ask for the root password
# when going to single-user mode.
console none unknown off insecure
во freebsd тоже можно в однопользовательский режим зайти без проблем, если он не отключен.
Не редко биосы позволяют выбирать устройство для загрузки (чаще всего по F8), даже если на сам вход в биос стоит пароль. Тут загрузочной флешкой можно что угодно сделать.

На Windows XP тоже есть похожая уловка (не уязвимость в прямом смысле), на которую часто попадаются пользователи. Оригинальная система (не сборка с автоустановкой) перед первым входом в систему просит ввести до пяти имён пользователей, причём пропустить этот шаг нельзя. После создания хотя бы одного пользователя встроенный администратор автоматически скрывается с экрана приветствия. Далее пользователь ставит пароль на свою учётную запись и уверен, что в систему никто кроме него не зайдёт, ведь на экране приветствия только одна учётная запись с паролем. Однако достаточно нажать Ctrl+Alt+(Del*2), как тут же вместо экрана приветствия покажется классическое окно входа в систему; вводим туда «Администратор» (на русской системе, или, соответственно, Administrator на английской), Enter и всё — права получены за считанные секунды.
> Не редко биосы позволяют выбирать устройство для загрузки (чаще всего по F8), даже если на сам вход в биос стоит пароль. Тут загрузочной флешкой можно что угодно сделать.

В случае запрета внешних носителей — нет.
А вообще, обычно в тех местах где заботятся о безопасности просто некуда вставлять флешки. И диски. А у некоторых мало того, что корпус на замке, так еще и пустые pci слоты залиты какой то дрянью.
Если есть возможность загрузиться со своего носителя, то в ХР о пароле можно забыть.
msv1_0.dll правится за 5 минут. И все пароли по боку. Причем до некоторого момента будет абсолютно незаметно.
Скорее всего эта сборка тоже самое делает. Есть еще варианты простого сброса пароля. До сих пор где-то образ валяется, как память об эникейском прошлом :) Но это заметно и используется когда легально нужно пароль сбросить.

В целом, как писали выше, защитить данные может только шифрование.
О, да это был грандиозный фэйл в безопасности WinXP.
Что интересно, первоначально в голом WinXP (без сервиспаков) этот создаваемый по умолчанию при установке системы юзер Администратор/Administrator (со всеми админскими привилегиями, но при этом с пустым паролем) мог использоваться не только для локального интерактивного входа в систему, но и для удалённого доступа.
Т.е. с любой другой машины в локальной сети можно было подключать диски этой машине (ADMIN$, C$, D$ ...), удалённо запускать/останавливать любые службы, удалённо подключаться к системному реестру и вообще делать любой Remote Code Execution ат имени юзера Администратор/Administrator с пустым паролем.

Ну т.е. просто сканируешь локальную сеть на наличие WinXP-машин с пустым паролем админа, а дальше делаешь с ними удалённо всё, что захочешь: копируешь/удаляешь данные, подсаживаешь любой троян/руткит/keylogger, устанавливаешь/удаляешь запускаешь/останавливаешь любые приложения/сервисы, имеешь удалённую командную строку и т.д. Просто рай для кул-хацкеров.

Эту ситуацию Microsoft решил исправить в SP1 для WinXP. Но вместо того, чтобы пересмотреть модель безопасности и запретить существование в системе учётных записей с пустым паролем (или хотя бы не создавать по умолчанию админского юзера с пустым паролем), они просто добавили в систему политику, по которой для юзеров с пустыми паролями запрещался удалённый доступ к системе по сети.
Проблема с кул-хацкерами, которые ломились по сети на машины с WinXP с пустым паролем админа, как бы пропала, но локальный доступ от админа с пустым паролем всё равно остался. Т.е. и локально можно было залогиниться админом с пустым паролем, или локально выполнить от админа с пустым паролем любой произвольный код (хоть через тот же runas) — любой примитивный вирус, запущенный от непривилегированного пользователя, мог получить полный админский доступ к системе.
а помните фишку с подменой стандартной заставки на cmd.exe? это тоже было чудо
да помним, конечно…
— и подмену дефолтовой заставки logon.scr на произвольный исполняемый файл (хоть cmd.exe, хоть что угодно ещё). А заставка эта запускалась по умолчанию от имени SYSTEM, если на этапе логина в систему никем не логиниться и не проявлять клавиатурно-мышиную активность 10-15 минут.
— и загрузку с флопика/CD на базе DOS + NTFSDOS с последующим патчем библиотеки виндового криптопровайдера (msv1_0.dll), о чём уже написали выше. Что позволяло потом залогиниться в систему под любым существующим юзером без ввода его пароля. Пропатчил библиотеку, вошёл в Windows под любым юзером, сделал от его имени что угодно, потом опять грузишься с флопика/CD, делаешь откат патча. В результате у всех сохраняются старые пароли, механизм проверки паролей восстанавливается, и совсем уж явных признаков несанкционированного доступа нет.
— и запуск командной консоли от имени юзера System (у которого полномочий больше, чем у обычного админа) через scheduled tasks.
Пишешь в командной строке at 10:30 cmd.exe /interactive и добавляется задание, которое в указанное время (в данном примере в 10:30) запустит cmd.exe от имени Local System. (синтаксис точно не помню, возможно ключ /interactive нужно указывать сразу после at)

Да и много прочих ляпов в безопасности Windows, которые сходу и не вспомнишь, но их было немало.
В Виндах есть смешнее уязвимость. По-умолчанию пользователь может создавать файлы в корне диска (даже не админ). Часть сервисов по причине кривых рук указывает путь к файлу сервиса без кавычек (например, c:\program files\intel system monitoring\monitor.exe). Если положить файл c:\program.exe в корень диска, то он будет запущен с правами сервиса (чаще всего system). Дальше вопрос техники.
>> пользователь может создавать файлы в корне диска
по умолчанию не может

>> Если положить файл c:\program.exe в корень диска
винда скажет что это плохо и предложит его переименовать
Может. Проверьте сами. Не знаю как в новомодных системах, а в windows XP — может. Такая дурацкая предустановка.
папки в корне они могут создавать, а файлы нет.
А может быть у вас лицензионная версия или максимально приближенная к оригинальной, поэтому все хорошо с этой точки зрения?
лицензионная версия от не лицензионной технически ничем не отличаются.
Просто на пиратки в большинстве случаев навешивается всякая ерунда вкупе с модификациями некоторых файлов и изменением реестра.
Когда на хабре говорят «всякая ерунда» (подразумевающая «что-то такое, чего я не знаю и не понимаю) я понимаю, что хабр уже не тот.

Извините, если вы, как технический специалист, не понимаете что делают обычно системы активации в пиратских версиях, что вы делаете на хабре?
Это что, стало постыдным, не знать подробностей конкретной реализации системы активации? Или вы имеете в виду что-то другое и я что-то недопонял?
вы все правильно говорите, но будем считать что мы говорим именно о не модифицированной windows xp, на %systemdrive% которой расположена ntfs.
Вы, наверное, про «сборки от ...», но тут, как говорится, сам себе злой Буратино. Чисто же пиратская копия винды ничем не отличается от лицензионной, на то она и копия :)
Напомню тезис, который мне вбивали в голову при обучении: «Любая защита данных должна начинаться с ограничения физического доступа или невозможности его использования».

А именно — Закрыть на замок\опечатать корпус, выдрать внешние носители (CD, DVD, etc), выключить в BIOS загрузку со всего, кроме HDD1 (особенно по сети и USB) и запаролить его, запаролить GRUB.

Ну и разумеется сервера с реально ценными данными должны стоять в серверной с крепкой дверью и сигнализацией.

До тех пор, пока это не сделано — не нужен даже GRUB, достаточно отцепить и унести в кармане HDD. А потом спокойно подключить его к своей машине и слить все, что нужно.

Шифрование, сложные ключи и т.д. — это хорошо. Но во-первых не спасет от уничтожения данных, во-вторых — при наличии неограниченного времени и прямых рук ломается большая часть подобных защит, особенно «кустарных».
Как показывает практика, крепкие двери и сигнализация не спасает от несанкционированного доступа со стороны государственных структур даже в государственных структурах же. Тем более неограниченное время редкая роскошь
>> пользователь может создавать файлы в корне диска
по умолчанию не может

>> Если положить файл c:\program.exe в корень диска
винда скажет что это плохо и предложит его переименовать
4.2, специально проверил на виртуалке. C:\program.exe создается без ошибок.
>рынок загрузчиков в мире *NIX

Помойму неуместный термин. Какой рынок? Кто, что и кому продаёт?
UFO just landed and posted this here
Sign up to leave a comment.

Articles