тут такое дело, что если делать security, то надо начинать уже с разметки дисков, угу. я понимаю, что ты об этом уже читал, но я повторю: секурность не делается как ad-hoc, она должна быть запланирована изначально.
Если б читал - не спрашивал бы.
а вообще — я не понимаю, зачем ты с собой возишь что-либо кроме совершенно стандартных пустых ОС. у тебя что, ssh отвалился? берём самый дешёвый ноут, ставим на него пингвинус, больше не делаем ничего. всё. если что-то надо — коннектимся с домом по ssh, делаем всё дома, рассоединяемся, никаких следов не осталось.
У себя так и сделаю. И вообще, оно так и надо, только я раздолбай. Был. Но народ упорно требует с меня статью, и отбояриться вряд-ли получится.

(Reply to this) (Parent) (Thread)

статью — это запросто. вот:

«вы все дураки и дебилы, поэтому вам нет никакого смысла заниматься хуйнёй. всё равно вы или пароль на листочке запишете и на стену приклеите, или ключи проебёте. идите нахуй.»

(Reply to this) (Parent) (Thread)

Не канает, к сожалению. Ибо не дураки и не дебилы, ключи не проебут.

(Reply to this) (Parent) (Thread)

да канает, канает. ибо дураки, и хотят вместо нормального обучения и нанятия специалиста волшебную кнопку «заебись». естественно, при таком подходе будет дыра на дыре (большая часть из которых — в головах пользователей, не обученых «думать секурно») и всенепременно проебут. не ключ — так ещё что-нибудь.

а для просто поиграться в security достаточно почитать ман по tcplay, например. ну, или просто что-нибудь из выдачи гугеля по кнопке «мне повезёт».

(Reply to this) (Parent) (Thread)

вместо нормального обучения
Они б с удовольствием, да денег нет, и что самое поганое, я тоже не могу с определенного момента, в ГОРФ даже 1 евро отправить, не говоря о том, чтоб где-то договориться о решениях корпоративного уровня для полутора анархистов из районов, приравненных к крайнему Северу. Они ж не пропиарившийся на весь Рунет Paperdaemon даже. На Paperdaemon'а-то денег дать отказываются, а уж им хрен кто поможет, только если я по собственной инициативе и то, ограничиваясь постами в блоге.

(Reply to this) (Parent) (Thread)

ну вот тут беда в том, что нет ничего хуже, чем дилетант, пытающийся заниматься «секурностью». увы. накосячит просто везде.

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

(Reply to this) (Parent) (Thread)

Вариант хороший очень даже, но проблема в том, что у некоторых до сей поры вторые пни (серьезно, вот такой вот пиздец) и виртуалка там будет как на корове седло. Но в других случаях да, просто и без особого бубна.

(Reply to this) (Parent) (Thread)

так там и шифрование всё тормознёт так, что можно задумчиво курить. ну, если действительно хочется именно шифрования, а не симулякр.

(Reply to this) (Parent)

этой своей репликой я намекаю на то, что потом прямо и говорю, да. «вы все дураки и дебилы, не занимайтесь хуйнёй». это надо ежедневно повторять. потому что «шифрованые диски» не спасают от дырявой головы. а головы дырявые однозначно, потому что даже опытный параноик периодически лажает. а уж люди, которые в принципе не приучены думать в стиле security — налажают однозначно. так что пусть расслабляются и получают удовольствие.

(Reply to this) (Parent) (Thread)

Ладно, я так понял, что конкретики не услышу, прошу прощения в таком случае.

(Reply to this) (Parent) (Thread)

— мужики, а как мне автомобиль сделать?
— ну, почитай про двигатели внутреннего сгорания, про шасси, про…
— я так понял, что конкретики не услышу?

я тебе сказал, куда смотреть. всё остальное делается по конкретному ТЗ, с учётом специфики клиента. и сюда входит не только софт. а тот, кто пишет статьи типа «установите это, запустите то, ура» — это некомпетентный тупорылый мудак.

(Reply to this) (Parent) (Thread)

Статья, это хорошо, если ее напишу я (ибо сам в процессе приобрету новые знания, что для меня, конечно, самое основное).
Понятно, что я не собираюсь прям-таки мегарешение городить, прям-таки годное для мегаадской корпорации. Вообще надо приписку сделать в своем FAQ, соответствующую. Это ты правильно подсказал.
И куда копать ты тоже весьма дельно задал пинок в нужном направлении.

В одном из предыдущих комментов я, наверное, коряво сформулировал. А надо было вот как. Если логи можно и нужно перенести в отдельный раздел, то /etc хочется (конфиги же, pap-secrets, например и прочее палево), но нельзя.
Никогда не выносите в отдельный раздел директории /bin, /sbin, /etc, /dev. Файлы находящиеся в них могут потребоваться при старте системы. Ярким примером являются программа init и ее конфигурационный файл /etc/inittab.
Вот посему я и спросил про правильное разделение диска на разделы.

(Reply to this) (Parent) (Thread)

>И куда копать ты тоже весьма дельно задал пинок в нужном направлении.
а больше мне говорить особо и нечего. дальше тебе просто читать и пробовать, потому что ты лучше знаешь, что именно хочешь получить. давать гримуар с заклинаниями смысла нет: толку в заклинаниях, если их не понимаешь? а для понимания тебе всё равно придётся читать ровно то же самое, что и без гримуара. зато в конце концов или заебёшься и бросишь, или таки будешь делать с нормальным пониманием, что и зачем. я предпочитаю вместо рыбы показать, где учат делать удочки.

>Вот посему я и спросил про правильное разделение диска на разделы.
опять же зависит от того, как у тебя система устроена. на самом деле многое, например, можно положить в initrd. ну, не всё, так смысла нет, но достаточно для того, чтобы система минимально взлетела и смогла запустить тот же tcplay, а потом просто перемонтировать разделы на шифрованые контейнеры.

ведь не обязательно же ВСЮ инициализацию делать сразу и навсегда, это ж не винда. подтянул минимальное, запустил что надо, подмонтировал новое в нужные места (тот же /etc, например, просто тупо замаунтил из шифрованого контейнера поверх старого /etc, да и всё) — и пустил уже полноценную инициализацию.

так что по большому счёту не так уж и важно, как там изначально диски побили, всё можно в процессе загрузки переиграть. читай про создание кастомных initrd, например.

(Reply to this) (Parent) (Thread)

давать гримуар с заклинаниями смысла нет
Да! Именно что!
на самом деле многое, например, можно положить в initrd. [...] читай про создание кастомных initrd
Уфф! Аж жопа с души свалилась! Я вчера в процессе чтения и думания подходил к такой мысли - запихать в initrd тот же tcplay, расшифровать что надо и запустить нормальную инициализацию. Но потом подумал, что может я куда-то не туда думаю :) Оказывается все-таки туда думал. Радует, что я дебил, но не совсем!

(Reply to this) (Parent) (Thread)

учти только, что придётся, скорее всего, или нежно нужные .so-хи пихать (и обучать их брать откуда надо), или статическую сборку делать.

а в общем-то, initrd как раз для того и придуман, чтобы наложить туда всякого хлама, без которого система не взлетает, но который прочитать из «нормальных» мест можно только после того, как система взлетела. так что всё ты правильно подозревать начал.

(Reply to this) (Parent) (Thread)

Слушай, а чем бы нагенерить хороший ключевой файл для шифрования? В виндовом truecrypt'е был встроенный генератор (по правде говоря не очень меня устраивающий, ибо генерил ключевые файлы ровно 64 байта), в tcplay и того нет, а псевдослучайными данными из /dev/urandom пользоваться не рекомендуется.

(Reply to this) (Parent) (Thread)

>а псевдослучайными данными из /dev/urandom пользоваться не рекомендуется
не читай, пожалуйста, больше такое говно в интернетах.

запомните все: /dev/urandom — ваш друг! а если какой-то дегенерат говорит вам, что «не надо использовать /dev/urandom» — этого дегенерата можно смело бить в ебало, он чисто случайно проскочил сети естественного отбора.

(Reply to this) (Parent) (Thread)

Скорее всего прочитал одного видимо дебила, потом в мануале на tcplay
-w, --weak-keys
Use urandom(4) for key material instead of a strong entropy
source. This is in general a really bad idea and should only be
used for testing.
и, наверное, сделал неправильный вывод. Если так, то все-таки надо иногда есть, а то мозги тормозят.

(Reply to this) (Parent) (Thread)

не, тут штука в том, что «не используйте /dev/urandom» — это очень известное заблуждение. в определённых кругах бить молотком по голове за эти слова и повторять «используй /dev/urandom, сука!» — sort of running joke.

проблема в том, что «дев/урандом хуеватый» пришло из ман-страницы к нему. вторая же проблема в том, что это было написано для криптогиков. а то, что по понятиям криптогиков «хуевато», в обычном мире называется «нихуя себе пиздец ояебу крипто».

тем не менее, миф о хуеватости /dev/urandom закрепился, и теперь его цитируют все, кому не лень.

то, что ты процитировал, кстати — тоже для криптогиков написано. отчего-то предполагается, что ты в крипто съел как минимум таксу и полностью понимаешь, о чём речь. криптогики — они такие: пишут вроде бы для нормальных людей, но постоянно забывают, что такое «нормальный человек».

(Reply to this) (Parent) (Thread)

криптогики — они такие: пишут вроде бы для нормальных людей, но постоянно забывают, что такое «нормальный человек
Т.е. использование /dev/urandom для генерации ключевых файлов возможно? Даже если атакующий будет например "крупным бизнесменом из 90-х", а флешка уже разбита вначале физической атаки, и даже терморектальный криптоанализ не поможет? Тут и вопрос в том, что атакующий может быть криптогиком или нанять таких специалистов (на практике не встречалось, но я ж стремлюсь мыслить максимально параноидально).

(Reply to this) (Parent) (Thread)

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

/dev/urandom черпает энтропию из тех же источников, что и /dev/random. разница между ними в том, что /dev/random при исчерпании пула энтропии тупо зависает и ждёт, пока в пул ещё накапает.

а /dev/urandom использует энтропийный пул для запуска криптостойкого PRNG, из которого потом и выдаёт результаты. чисто теоретически если используется не очень хороший PRNG, то на основе сгенерированной последовательности можно восстановить seed.

на практике же это настолько ресурсоёмко, что можно на сей факт внимания не обращать. тем более, что /dev/urandom периодически ресидит PRNG новой энтропией, и вообще подмешивает всякое. но с точки зрения криптографа — любой алгоритм PRNG можно отреверсить, поэтому их использование априори МЕНЕЕ надёжно, чем кармически чистые источники энтропии. однако если это «менее» колеблется от (числа совершенно отфонарные, но «где-то рядом»), скажем, необходимости иметь 2^20 байт для предсказания следующего до 2^42, то на практике это совершенно похуй.

(Reply to this) (Parent)

мелкозамечание: человека, который с криптографией в районе нуля, лучше лишний раз напугать, чем пояснять, что и когда можно делать. всё равно не поймёт, пока в теме не начнёт разбираться. а когда начнёт, то ему это уже и не надо писать.

так вот: поэтому криптогики предпочитают писать пострашнее, и всё, что отходит от идеала на три микрона, называть как минимум «не очень надёжным». на практике это означает, что если видишь надпись про ненадёжность — то ВЕРЬ ЕЙ. ВЕРЬ. плохого тебе не хотят. а лучше обратись к ближайшему, кто чуть-чуть подкован в крипто, опиши свою ситуацию и спроси, что делать. ну, как тут, да. %-)

я не криптогик, конечно, но немного в теме понимаю, потому говорю тебе: в твоём случае /dev/urandom вполне. всё равно никто не будет заниматься длительным цифровым криптоанализом, а при необходимости сразу перейдут на терморектальный. так что ок.

(Reply to this) (Parent) (Thread)

лучше лишний раз напугать, чем пояснять, что и когда можно делать.
Факт!

А я просто с прошлых работ помню генераторы ключей в банк-клиентах, там как в трукрипте и старом pgp, надо было алгоритм выбирать, потом водить случайные символы,махать и клацать мышью.

(Reply to this) (Parent) (Thread)

это потому, что в винде, тащемта, нет встроеных сборщиков энтропии. поэтому приходилось просить её явно нагенерить.

в ведре пинусов же ядро энтропию собирает изо всяких мест. из времён реакций дивайсов, всяких сетевых байтов, байтов с винтов, с клавиатуры, с мыши, с белкиного хуя и вообще откуда только получается. а потом эти энтропийные пулы используются в /dev/random и /dev/urandom.

(Reply to this) (Parent) (Thread)

Ясно, благодарю.

(Reply to this) (Parent)

разве что вот не стоит использовать /dev/urandom во всяких live-дистрибутивах. они информацию для сидирования /dev/urandom по понятным причинам нигде сохранить не могут, и времени на сбор энтропии из других источников у них мало.

а с рабочей системы, особенно если она не свежезапущеная, а уже активно поюзалась — вполне нормально.

(Reply to this) (Parent) (Thread)

Ну может быть и свежепоставленная, этак 10 раз перезагружавшаяся, а может и 20. Я вообще, например, пока изучал initrd и его устройство раз 6 схватил ядрен перепуг и еще раз 15 примерно перезагружался нормально.

(Reply to this) (Parent) (Thread)

ну, оно за это время уже насобирало говна, всё ок. /dev/urandom бережно сохраняется при шатдауне и потом сохранённая срань используется для начального сидинга при загрузке — пока ядро очередной мешок говна не насобирает.

(Reply to this) (Parent)

да, напоминай мне периодически, что шутки про криптографию не понимает вообще никто. те, кто не понимает в криптографии — не понимают, где шутка и когда смеяться, а криптографы над ними плачут от стыда и горя.

(Reply to this) (Parent) (Thread)

Хорошо!

(Reply to this) (Parent)

p.s. вот почему как хирургия — так никто не горит желанием сам себя резать. а как безопасность — так это у нас каждый первый хирург, йопт.

(Reply to this) (Parent)