Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 53
progorodsamara.ru/news/view/samarec-licno-podaril-svou-beskonecnuu-flesku-dmitriu-medvedevu
"У меня не получилось": российской "бесконечной флэшки" больше не будет
Создатель проекта, который подарил флэшку Медведеву, признал, что не всегда принимал правильные решения
Самарский изобретатель, Алексей Чуркин объявил о закрытии стартапа Flashsafe. "Бесконечную флэшку" он пытался вместе со своей командой раскрутить три года, но признал, что не достиг успеха и больше не может соревноваться с облачными платформами крупных IT-гигантов. Свой стартап - флешку, которая предоставляла доступ к зашифрованным обалчным хранилищам данных - самарский предприниматель презентовал и Президенту Владимиру Путину, и председателю Правительства РФ Дмитрию Медведеву.
Момент был упущен, я признаю что сам во всем виноват, нужно было уделять больше внимания команде, быть скромнее, и не принимать не верные кадровые решения, поэтому прошу у всех прощения за свои действия, - написал Алексей Чуркин на странице своего проекта. И рассказал всю историю борьбы за рынок хранения информации.
Теперь Алексей намерен взяться за новые проекты. В течение долгого времени он жил в США, но теперь намерен стать полезным у себя на Родине.
ничего личного - но уже было
Но я не предлагаю стартап и тем более через госструктуры )
Это так, пятничное...
доступ к зашифрованным обалчным хранилищам данных
Интересные хранилища и презентованы верно.
usb-ключ был этой безлим-флэшекой
Ключ тоже алчный с подпиской?
ЗЫ, вроде у героя новости с обалчными хранилищами все сложилось, если не ошибся с тезкой, так что https://habr.com/ru/companies/oleg-bunin/articles/903552/
ничто так не выдавало бывшего freebsd-шника как пути вида /usr/local/bin
если вы зануляете хистори, то все равно спалитесь на заходе по ssh, его историю входов тоже надо занулять
О, это отдельная история, почему есть /bin, /usr/bin и /usr/local/bin, надо будет как-нибудь написать )
та уже нету истории, точнее ушло в аналы истории. если раньше был FHS, то с выходом systemd все развалилось и стандарт стал неактуальным. и не то чтобы в линуксе его сильно соблюдали и ранее
надо будет как-нибудь написать
Вот именно.
Только с поправкой - сейчас как раз на практике сталкиваюсь со случаем, когда это разделение не просто дань традиции, но и может иметь практический смысл: снова у аппаратного сервера ограничение по размеру диска (emmc), и дополнительное дисковое пространство можно примонтировать в usr, но и сохранить специфичный для данного девайса софт в /usr/local
Старинные костыли снова пригодились
Ну почему только freebsd-шника? В старом линуксе вполне себе /usr/local/* популярен был, да и сейчас я его использую (пример с домашнего нано-сервера под дебианом):
$ du -sh /usr/local/*
104K /usr/local/bin
160K /usr/local/etc
4.0K /usr/local/games
4.0K /usr/local/include
160K /usr/local/lib
0 /usr/local/man
4.0K /usr/local/sbin
3.0M /usr/local/share
3.1M /usr/local/src
А против лишней истории ещё полезно в /etc/fstab добавить
tmpfs /var/log tmpfs size=128m,rw,nodev,noexec,nosuid,auto 0 1
В старом линуксе вполне себе /usr/local/*
ух ты. чекнул на бубунте 24, и вправду живое.
А против лишней истории ещё полезно в /etc/fstab добавить
ну тут палка о 2х концах. если у вас ооо с 1.5 человеками и вы занимаетесь этим или льете логи в сием с большой компанией, ИБ и вот это все.
Да я не о том, что оно «живое» (то есть формально существует) в некоем дистрибутиве — а что я его реально использую! В /usr/local/src разворачиваю и собираю софт, которого нет в дистрибутиве (или мне нужна более свежая версия, я сижу на дебиане oldstable и иногда oldoldstable); плюс в /usr/local/[s]bin ложатся всякие специфичные для сайта скрипты.
А про палку о двух концах — вроде как предполагается, что если человек использует загрузочную флешку с монтированием в далёко и под шифром, то тут речь не идёт о логах в SIEM (не говоря уже о корпоративной ИБ).
Если в качестве транспорта используется ссш, то почему просто не использовать ссшфс?
Потому что тут разделение: чтобы получить доступ к данным нужен доступ к серверу (физический или ссш) И доступ к паролю шифрования luks. Одного недостаточно.
Использование sshfs или других видов сетевого монтирования каталогов исключает один из элементов, т.е. получив доступ к серверу получаем и доступ к данным сразу. Что в случае физически неподконтрольного сервера неприемлемо - по условию задачи информация не должна попасть не в те руки (админам сервера тоже нельзя).
Ну и ограничение по каналу связи, так то это может быть не ssh, а что-нибудь другое
Если сервер вам неподконтролен, то админы могут подменить люой бинарник, что поможет им узнать пароль от вашего крипто контейнера.
Как именно?
ISCSI пробрасывает работу на уровне блоков, пароль и шифрование находятся вне этого уровня.
С тем же успехом можно просто прочитать файл образа и вскрыть его. Или не вскрыть...
Да, вы правы. Но тогда возникает вопрос почему нельзя использовать encfs поверх sshfs? Тогда тоже все шифрование происходит на стороне клиента, сервер хранит только зашифрованные данные.
Почему нельзя - можно. Если они дружат друг с другом, почему бы и нет?
в моих условиях мне работа подмаунченого sshfs не понравилась: почему то при первом старте любила подвисать, причем на двух разных хостах. вангую потому что ssh тротлят с известными целями известно кто. при этом вопрос секукрности у меня полностью противоположный: хост доверенный, а клиент нет - т.е. на нем ключевая информация нежелательна
От старого доброго паяльника в известное всем место ничего не поможет
в качестве транспорта используется ссш
кстати не обязательно, существуют и другие способы порты пробросить, можно даже не шибко секурные
ну отформатируй флешку в fat32 и сделай sudo cryptsetup luksFormat --offset 30000 /dev/sdb
неплохо, но ненадежно:
-- флешка остается "в заложниках", т.е. вы уже никак не можете повлиять на ее уничтожение и запретить исследование
-- есть такая штука binwalk:
dd if=/dev/sdb of=to_analyze.img
binwalk to_analyze.img
-----
30000 luksHeader....
А потом ректальный криптоанализ...
Ну и размер ограничен размером флешки минус 30000, минус ОС (или придется читать ее на стационарном компьютере, оставляя логи, историю команд, и т.д.)
Ничто так не бесит, как задержка реакции интерфейса.
Это файл может тянуться со скоростью 45 кбит/сек, но реакция на кнопки должна быть мгновенной. А не как у тонкого клиента... )
По условию задачи не решает: данные на сервере доступны посторонним. Ещё и заботливо открыты для просмотра.
Ну и тормозной интерфейс бесит, это я уже говорил. Понимаю, у всех свое понятие "тормозной", но rdp бесит даже когда компьютеры в одной сети, через один свич, постоянные задержки прорисовок, это пипец какой-то.
Время отклика, критическое для восприятия - 200мс, если больше то нужно продумывать интерфейс так, чтобы это было органично и незаметно, в фоне. Графические окна к этому не относятся
вы никогда не работали с RDP профессионально и я ваше мнение не беру в расчёт. Какая-то голимая субъективщина
Who care?
Это моя задача и моё ее решение )
Нравится RDP - устанавливайте и наслаждайтесь, мне-то что?
На мой субьективный взгляд - очень тормозное поведение интерфейса, для кого-то другого - вполне приемлемо, а для вас так и вообще очень быстро.
Это каким таким образом?
Подумайте.
Вы опять спорите с теми тезисами, которые сами и придумали.
Для того чтобы сказать "мне не нравится скорость работы rdp" не требуется разбираться в тонкостях работы rdp, достаточно видеть как это работает и испытывать дискомфорт от жутких тормозов. При этом для кого-то - "даже быстро".
Ваша идея с усыпляющий газом прекрасна - вот только если чел уснул перед незаблокированным экраном - какая уже разница, какое там было техническое решение? Он уснул.
Непонятно, зачем крутить kde с диска. Потому что зачем именно kde, и во-вторых уже один раз загруженное находится в памяти и не требует его загружать снова. Ну, если это не какойто программный монстр с автоподкачкой.
Вы говорите что 30 лет в классах компьютеры настраиваете - это больше говорит о вашей работе и объясняет ваш характер, но совершенно не обьясняет, почему мне должно нравиться, как rdp работает с интерфейсом.
Вы охотно упихиваете "kde" в 128 килобит - что ж, упихайте туда же и rdp. Это будет кровь из глаз - хотя опять же, некоторым даже быстро.
Более того, я такое даже вживую видел: если слышали когда-нибудь про "модемы для витой пары" с интерфейсом rs232 на 115200, с дальностью до 10 км. Я с этим работал когда-то. Не думаю, что 128 сильно быстрее 115. Но там и удаленный диск подключать будет весело.
И самое главное - вы начинаете спорить даже не поняв о чем написано. Ещё раз: сервер не безопасен - это условие. Если у вас там находится что-то не для всех - то хоть там rdp, хоть там kde, диск уже в руках людей, которые могут изучать его побитово, подменять бинарники, внедрять кейлогеры и всячески развлекаться. Способ вашего подключения к интерфейсу тут не имеет никакой роли.
Кроме случая, когда зашифрованный диск расшифровывается не на этом сервере - и это как раз iscsi. У них только шифрованные блоки.
Но вы не разобрались, вы сразу решили что вариант студента плохой, а ваш правильный )
Вы много и обильно пишете, отвечать на каждый пункт лениво, отмечу последнее:
Вот здрасте. Как наличие в руках тонкого клиента компрометирует данные? Никак. Это просто пустая коробка. У них есть CF карта на котором мини-линукс
Вы не умеете читать, сразу спорите.
Конкретно там, на что вы поспешили спорить, речь идет о сервере. Знате, что такое сервер? Это там, где находится физически диск, или в вашем варианте - ОС с RDP.
Вот этот сервер стоит, допустим, у вас на кафедре, вы там админ, со всеми своими админсткими правами, а я не хочу чтобы вы копались в моих файлах.
Но файлы зашифрованы, и расшифровываться на ВАШЕМ сервере не будут.
А на CF-карте действительно только мини-линукс, который всё что умеет - подключать к себе удаленный диск. На нем нет никаких данных.
Где же будут расшифрованные данные? Подумайте.
Логически следует из предположения "взять сервер где-то подальше", т.е. не "настроить у себя в бункере за бронированными дверями и уехать подальше самому", а "взять", арендовав удаленно.
Также явным образом указано в одном из моих комментариев, и было угадано другими комментаторами.
Пожалуй, если формировать именно как ТЗ - это надо отдельно оговаривать.
Но на это есть дисклеймер - "сляпано тяп-ляп"
Тонкий клиент? RDP/VNC?
очень зависит от задачи. дистанционное рабочее место можно и черз ssh (+lynx даже ) организовать, но это случай скорее когда хост доверенный. тут же мы рассматриваем случай когда хост недоверенный и там все должно быть зашифровано
Конкретно чел спорит чтобы спорить, это его хобби )
Помните же что он не решил вопрос с "Лицом в пол, руки за голову!"
привязать флешку веревочкой к карману, чтобы не потерялась )
"Отойдите от компьютера!" - да, конечно...
А потом начинайте обьяснять, для чего вы сидели за пустым экраном тонкого клиента и тупили в него. Ведь там больше ничего нет, верно?
Не вижу я в авторском посте информации про доверенность хоста
ок немного притянул, но диск то там шифрованный. риторический вопрос звучит в ключе: какое место привлечет больше внимания, локальное или удаленное, с чего, так сказать, начнут
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Очумелые ручки: терабайт на флешке