mount.cifs и хранение пароля
Evgeniy Vidyakov
mount.cifs //server/share /mnt/server -o iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
Не нравится, что пароли в открытом текстовом виде. Возможно ли при монтировании получать их из какого-нибудь "закрытого" зашифрованного источника?
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/495A7CF39A777442B6BE...@servermail2.solvex.local
Nicholas
> Хранение бэкапов организовано на Widows сервере. Шара монтируется скриптом строчкой на подобии:
> mount.cifs
А разве нельзя под win ssh сервер поставить и по sshfs монтировать
(используя сертификаты) ?
--
Sincerely,
Nicholas
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/irjpki$f5a$1...@dough.gmane.org
Evgeniy Vidyakov
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/495A7CF39A777442B6BE...@servermail2.solvex.local
alexander barakin
> Хранение бэкапов организовано на Widows сервере. Шара монтируется скриптом строчкой на подобии:
> mount.cifs //server/share /mnt/server -o iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
> Не нравится, что пароли в открытом текстовом виде. Возможно ли при монтировании получать их из какого-нибудь "закрытого" зашифрованного источника?
$ man -P 'less -rp "credentials="' mount.cifs
не угадал?
--
wbr, alexander barakin aka sash-kan.
Dmitry A. Zhiglov
Stanislav Maslovski
> Хранение бэкапов организовано на Widows сервере. Шара монтируется скриптом строчкой на подобии:
> mount.cifs //server/share /mnt/server -o iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
> Не нравится, что пароли в открытом текстовом виде. Возможно ли при монтировании получать их из какого-нибудь "закрытого" зашифрованного источника?
Чтобы зашифрованный пароль расшифровать, потребуется другой пароль
или ключ, и т.д. Поэтому, я бы подошел к проблеме с другой стороны:
создал бы учетку на windows-сервере с минимальными правами, скажем,
только на запись файлов в каталог бакапов. В этом случае ущерб от
утери пароля минимизируется.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011052805...@kaiba.homelan
Stanislav Maslovski
> On Wed, May 25, 2011 at 03:04:22PM +0000, Evgeniy Vidyakov wrote:
> > Хранение бэкапов организовано на Widows сервере. Шара монтируется скриптом строчкой на подобии:
> > mount.cifs //server/share /mnt/server -o iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
> > Не нравится, что пароли в открытом текстовом виде. Возможно ли при монтировании получать их из какого-нибудь "закрытого" зашифрованного источника?
>
> Чтобы зашифрованный пароль расшифровать, потребуется другой пароль
> или ключ, и т.д. Поэтому, я бы подошел к проблеме с другой стороны:
> создал бы учетку на windows-сервере с минимальными правами, скажем,
> только на запись файлов в каталог бакапов. В этом случае ущерб от
> утери пароля минимизируется.
В догонку: имелось ввиду, что минизируется ущерб _виндовс системе_.
Понятно, что если на линуксе получили рута, то уже поздняк метаться.
Igor Chumak
> On Wed, May 25, 2011 at 03:04:22PM +0000, Evgeniy Vidyakov wrote:
>> Хранение бэкапов организовано на Widows сервере. Шара монтируется скриптом строчкой на подобии:
>> mount.cifs //server/share /mnt/server -o iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
>> Не нравится, что пароли в открытом текстовом виде. Возможно ли при монтировании получать их из какого-нибудь "закрытого" зашифрованного источника?
> Чтобы зашифрованный пароль расшифровать, потребуется другой пароль
> или ключ, и т.д.
авторизации на windows-сервере, насколько я знаю, используется хеш?
mount.cifs так не умеет - разработчики samba считают, что
credentials=/root/.smbpass - достаточно хорошо ;)
Возможно, существуют патчи, реализующие авторизацию по хешу, но я не нашел.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
alexander barakin
> 28.05.2011 08:41, Stanislav Maslovski пишет:
>>
>> On Wed, May 25, 2011 at 03:04:22PM +0000, Evgeniy Vidyakov wrote:
>>>
>>> Хранение бэкапов организовано на Widows сервере. Шара монтируется
>>> скриптом строчкой на подобии:
>>> mount.cifs //server/share /mnt/server -o
>>> iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
>>> Не нравится, что пароли в открытом текстовом виде. Возможно ли при
>>> монтировании получать их из какого-нибудь "закрытого" зашифрованного
>>> источника?
>>
>> Чтобы зашифрованный пароль расшифровать, потребуется другой пароль
>> или ключ, и т.д.
>
> Это понятно. А нет ли возможности хранить не пароль, а его хеш, ведь при
> авторизации на windows-сервере, насколько я знаю, используется хеш?
если для авторизации достаточно наличия хэша, то чем же хранение этого
хэша будет отличаться от хранения пароля (с точки зрения
безопасности)?
Igor Chumak
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
alexander barakin
> 30.05.2011 11:02, alexander barakin пишет:
>>
>> 2011/5/30 Igor Chumak<ichum...@gmail.com>:
>>>
>>> 28.05.2011 08:41, Stanislav Maslovski пишет:
>>>>
>>>> On Wed, May 25, 2011 at 03:04:22PM +0000, Evgeniy Vidyakov wrote:
>>>>>
>>>>> Хранение бэкапов организовано на Widows сервере. Шара монтируется
>>>>> скриптом строчкой на подобии:
>>>>> mount.cifs //server/share /mnt/server -o
>>>>> iocharset=utf8,credentials=/root/.smbpass,dom=DOMAIN.LOCAL
>>>>> Не нравится, что пароли в открытом текстовом виде. Возможно ли при
>>>>> монтировании получать их из какого-нибудь "закрытого" зашифрованного
>>>>> источника?
>>>>
>>>> Чтобы зашифрованный пароль расшифровать, потребуется другой пароль
>>>> или ключ, и т.д.
>>>
>>> Это понятно. А нет ли возможности хранить не пароль, а его хеш, ведь при
>>> авторизации на windows-сервере, насколько я знаю, используется хеш?
>>
>> если для авторизации достаточно наличия хэша, то чем же хранение этого
>> хэша будет отличаться от хранения пароля (с точки зрения
>> безопасности)?
>>
> Пароль по хешу восстановить тяжело.
ну так зачем восстанавливать, если и так (допустим) можно авторизоваться?
Igor Chumak
net use в windows требует ПАРОЛЬ
Так что для _стандартных_ способов авторизации знание хеша бесполезно.
Со стороны samba-сервера с авторизацией по LDAP, в каталоге хранятся
некие sambaLMPassword и sambaNTPassword - подозреваю, что клиенту этого
тоже должно быть достаточно.
И если верить http://en.wikipedia.org/wiki/NTLM, для авторизации таки
достаточно хеша.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
alexander barakin
ок. хоть как-то, но авторизоваться с помощью хэша, допустим, можно.
перечитываем первое письмо в треде:
> Возможно ли при монтировании получать их из какого-нибудь "закрытого" зашифрованного источника?
и понимаем, что хранение хэша вместо пароля никаким образом не
является ответом на этот вопрос.
даже если научить mount.cifs пользоваться хэшем, а не паролем, вся
разница будет лишь в содержимом сохраняемой информации. но сама
информация (пароль или его хэш) так и будет храниться в открытом виде.
Alexander Galanin
Igor Chumak <ichum...@gmail.com> wrote:
> Со стороны samba-сервера с авторизацией по LDAP, в каталоге хранятся
> некие sambaLMPassword и sambaNTPassword - подозреваю, что клиенту этого
> тоже должно быть достаточно.
> И если верить http://en.wikipedia.org/wiki/NTLM, для авторизации таки
> достаточно хеша.
Надо читать чуть внимательнее. По сети передаётся только хеш, на сервере
также проверяется только хеш, но для генерации ответа от клиента нужен
пароль.
--
Alexander Galanin
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011053012552...@galanin.nnov.ru
Igor Chumak
> On Mon, 30 May 2011 11:42:45 +0300
> Igor Chumak<ichum...@gmail.com> wrote:
>
>> Со стороны samba-сервера с авторизацией по LDAP, в каталоге хранятся
>> некие sambaLMPassword и sambaNTPassword - подозреваю, что клиенту этого
>> тоже должно быть достаточно.
>> И если верить http://en.wikipedia.org/wiki/NTLM, для авторизации таки
>> достаточно хеша.
> Надо читать чуть внимательнее. По сети передаётся только хеш, на сервере
> также проверяется только хеш, но для генерации ответа от клиента нужен
> пароль.
>
Посыпаю голову пеплом
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Igor Chumak
что фантазии насчет хеша остаются фантазиями. ;)
Тогда можно сделать например так:
1. патчить mount.cifs на предмет того, что пароль в файле указанном в
credentials , зашифрован неким ключом
2. сделать тулзовину make_credentials, которая будет шифровать этим
самым ключом поле с паролем.
Наиболее правильно, ИМХО, было правильно генерировать ключ случайным
образом на этапе компиляции samba - тогда ключ окажется идентичным и в
mount.cifs и в make_credentials. Удалить исходники после установки - и
можно считать, что хранилище паролей достаточно надежно.
Естествено, надо позаботиться о том, чтобы ключ дизассемблировать было
неудобно ;).
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Konstantin Matyukhin
чтобы в момент загрузки
его использовать. Т.о. задача сводится к предыдущей. За что боролись?
--
С уважением,
Константин Матюхин
Igor Chumak
> Если шифровать credentials с ключом, то этот ключ надо где-то хранить,
> чтобы в момент загрузки
> его использовать. Т.о. задача сводится к предыдущей. За что боролись?
>
непосредственно в исполняемом файле mount.cifs.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Konstantin Matyukhin
> Вот я и предлагаю: ключ генерировать на этапе компиляции samba, хранить
> непосредственно в исполняемом файле mount.cifs.
будут одинаковые ключи?
Andrey Rahmatullin
> Наиболее правильно, ИМХО, было правильно генерировать ключ случайным
> образом на этапе компиляции samba - тогда ключ окажется идентичным и
> в mount.cifs и в make_credentials. Удалить исходники после установки
> - и можно считать, что хранилище паролей достаточно надежно.
>
> Естествено, надо позаботиться о том, чтобы ключ дизассемблировать
> было неудобно ;).
--
WBR, wRAR
Andrey Rahmatullin
> > Вот я и предлагаю: ключ генерировать на этапе компиляции samba, хранить
> > непосредственно в исполняемом файле mount.cifs.
> Т.е. у всех пользователей debian, включая предполагаемого злоумышленника,
> будут одинаковые ключи?
--
WBR, wRAR
Andrey Rahmatullin
> 2011/5/30 Andrey Rahmatullin <wr...@wrar.name>:
> > Разве речь про Debian?
> Где я?!
По кр.мере в Debian не требуется "Удалить исходники после установки".
--
WBR, wRAR
Konstantin Matyukhin
--
С уважением,
Константин Матюхин
Andrey Rahmatullin
> Угу. Безопасность не должна основываться на секретном алгоритме, я в курсе.
> Предложите решение покрасивше ;)
Если требуется не хранить ключевой материал в системе и нельзя вводить его
интерактивно, я могу предложить лишь аппаратный ключ.
--
WBR, wRAR
Igor Chumak
Предложите решение покрасивше ;)
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Konstantin Matyukhin
> По кр.мере в Debian не требуется "Удалить исходники после установки".
Собиратели, они обычно в других дистрибутивах живут, да вы это и так знаете.
Konstantin Matyukhin
> Предложите решение покрасивше ;)
Не давайте root-доступ абы кому.
Konstantin Matyukhin
> В опции configure добавить чего-то вроде --with-secret_key. Опция не
> включена - у всех пользователей debian не будет _никаких_ ключей.
> Кому надо - соберет для себя с этой опцией.
Или напишет патч.
Andrey Rahmatullin
> > По кр.мере в Debian не требуется "Удалить исходники после установки".
> Так они в debian и до установки не требуются.
> Собиратели, они обычно в других дистрибутивах живут, да вы это и так знаете.
--
WBR, wRAR
Igor Chumak
> 2011/5/30 Igor Chumak<ichum...@gmail.com>:
>> Вот я и предлагаю: ключ генерировать на этапе компиляции samba, хранить
>> непосредственно в исполняемом файле mount.cifs.
> Т.е. у всех пользователей debian, включая предполагаемого злоумышленника,
> будут одинаковые ключи?
>
В опции configure добавить чего-то вроде --with-secret_key. Опция не
включена - у всех пользователей debian не будет _никаких_ ключей.
Кому надо - соберет для себя с этой опцией.
Да, _мне_ это не надо, это я рассуждаю на тему "как организовать
безопасное хранилище паролей для mount.cifs".
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Igor Chumak
В debian/rules добавить
# сгенерировать ключ
dd if=/dev/urandom bs=1k count=1 |sha512sum >secret.key
# и удалить после сборки
rm -f secret.key
В этом нет нарушений Debian Policy? ;)
А вариант с аппаратным ключом тоже не идеален.
Если ключ отдаст пароль без авторизации - кто мешает утянуть этот самый
пароль кому угодно, имеющему доступ к ключу?
Если требуется вводить пароль - тогда проще вызывать mount.cifs вручную ;)
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrey Rahmatullin
> >>>Разве речь про Debian?
> >>Где я?!
> >По кр.мере в Debian не требуется "Удалить исходники после установки".
> Собс-но , исходники удалять необязательно
> В debian/rules добавить
>
> # сгенерировать ключ
> dd if=/dev/urandom bs=1k count=1 |sha512sum >secret.key
>
> # и удалить после сборки
> rm -f secret.key
>
> В этом нет нарушений Debian Policy? ;)
> А вариант с аппаратным ключом тоже не идеален.
> Если ключ отдаст пароль без авторизации - кто мешает утянуть этот
> самый пароль кому угодно, имеющему доступ к ключу?
> Если требуется вводить пароль - тогда проще вызывать mount.cifs вручную ;)
В таком случае вам нужен аппаратный ключ, отдающий не пароль, а респонс по
переданному челленджу (мы ведь челлендж-респонс протокол обсуждаем?)
--
WBR, wRAR
Igor Chumak
-куть
>> А вариант с аппаратным ключом тоже не идеален.
>> Если ключ отдаст пароль без авторизации - кто мешает утянуть этот
>> самый пароль кому угодно, имеющему доступ к ключу?
>> Если требуется вводить пароль - тогда проще вызывать mount.cifs вручную ;)
> В таком случае вам нужен аппаратный ключ, отдающий не пароль, а респонс по
> переданному челленджу (мы ведь челлендж-респонс протокол обсуждаем?)
>
Началось все с организации безопасного хранилища паролей для mount.cifs.
В котором получение root доступа не означает получение пароля.
Причем из хранилища надо получить не подтверждение того, что "я знаю
пароль" (челлендж-респонс протокол это обеспечит) , а именно пароль. В
виде текста. Или же хранилище паролей (аппаратный ключ) должно уметь NTLM?
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Konstantin Matyukhin
> Началось все с организации безопасного хранилища паролей для mount.cifs. В
> котором получение root доступа не означает получение пароля.
Igor Chumak
> 2011/5/30 Igor Chumak<ichum...@gmail.com>:
>> Началось все с организации безопасного хранилища паролей для mount.cifs. В
>> котором получение root доступа не означает получение пароля.
> Т.е. вы ищете способ как вылечить коленку человеку, которому голову отрезало?
>
Отрезание головы одного человека не должно приводить к отрезанию ног у
всех его знакомых из вконтакта ;)
Т.е. компроментация узла с cifs клиентом не должна приводить к
компроментации узла с cifs сервером.
Вот выдал виндовый админ линуксовом админу логин-пароль для доступа.
Какие права имеет эта учетная запись? Линуксовый админ этого не знает. А
вдруг администратора (вин-админы это любят)? А вдруг через полгода
случайно (или не очень случайно) эта учетная запись получит права
администратора? Так что проблема с cleartext-паролями вполне реальная.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Konstantin Matyukhin
> Вот выдал виндовый админ линуксовом админу логин-пароль для доступа. Какие
> права имеет эта учетная запись? Линуксовый админ этого не знает. А вдруг
> администратора (вин-админы это любят)? А вдруг через полгода случайно (или
> не очень случайно) эта учетная запись получит права администратора? Так что
> проблема с cleartext-паролями вполне реальная.
Andrey Rahmatullin
> Причем из хранилища надо получить не подтверждение того, что "я знаю
> пароль" (челлендж-респонс протокол это обеспечит) , а именно пароль.
> В виде текста. Или же хранилище паролей (аппаратный ключ) должно
> уметь NTLM?
требуемому алгоритму.
--
WBR, wRAR
alexander barakin
а что может помешать воспользоваться этим аппаратным ключом злоумышленнику?
Artem Chuprina
> > переданному челленджу (мы ведь челлендж-респонс протокол обсуждаем?)
>
> а что может помешать воспользоваться этим аппаратным ключом злоумышленнику?
Воспользоваться, пока он вставлен - ничего. Не получится прикопать
credentials для последующего использования в более удобный момент.
--
Все учтено могучим ураганом...
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/874o4cumlt.wl%r...@ran.pp.ru
alexander barakin
>> > В таком случае вам нужен аппаратный ключ, отдающий не пароль, а респонс по
>> > переданному челленджу (мы ведь челлендж-респонс протокол обсуждаем?)
>>
>> а что может помешать воспользоваться этим аппаратным ключом злоумышленнику?
>
> Воспользоваться, пока он вставлен - ничего. Не получится прикопать
> credentials для последующего использования в более удобный момент.
разве это как-то принципиально отличается, например, от ношения
файлика credentials на флэшке?
Alexander Galanin
alexander barakin <alex.b...@gmail.com> wrote:
> >> а что может помешать воспользоваться этим аппаратным ключом злоумышленнику?
> >
> > Воспользоваться, пока он вставлен - ничего. Не получится прикопать
> > credentials для последующего использования в более удобный момент.
>
> разве это как-то принципиально отличается, например, от ношения
> файлика credentials на флэшке?
Содержимое credentials не будет болтаться в памяти компьютера.
--
Alexander Galanin
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011053021551...@galanin.nnov.ru
alexander barakin
> On Mon, 30 May 2011 21:34:51 +0400
> alexander barakin <alex.b...@gmail.com> wrote:
>
>> >> а что может помешать воспользоваться этим аппаратным ключом злоумышленнику?
>> >
>> > Воспользоваться, пока он вставлен - ничего. Не получится прикопать
>> > credentials для последующего использования в более удобный момент.
>>
>> разве это как-то принципиально отличается, например, от ношения
>> файлика credentials на флэшке?
>
> Содержимое credentials не будет болтаться в памяти компьютера.
а долго это содержимое может проболтаться в памяти после закрытия файла?
есть истории успеха по обнаружению таких «хвостов»?
Dmitry A. Zhiglov
<vidy...@solvex.travel> написал:
> В настоящий момент рассматриваю варианты без установки дополнительных сервисов и служб на win сервере.
Не доводилось пользоваться этой шарманкой... пошукал по инету...
А если ввести дебиан машину в АД и воспользоваться libpam-mount для
монтирования ресурса?
Alexander Galanin
alexander barakin <alex.b...@gmail.com> wrote:
> 2011/5/30 Alexander Galanin <a...@galanin.nnov.ru>:
> > On Mon, 30 May 2011 21:34:51 +0400
> > alexander barakin <alex.b...@gmail.com> wrote:
> >
> >> >> а что может помешать воспользоваться этим аппаратным ключом злоумышленнику?
> >> >
> >> > Воспользоваться, пока он вставлен - ничего. Не получится прикопать
> >> > credentials для последующего использования в более удобный момент.
> >>
> >> разве это как-то принципиально отличается, например, от ношения
> >> файлика credentials на флэшке?
> >
> > Содержимое credentials не будет болтаться в памяти компьютера.
>
> а долго это содержимое может проболтаться в памяти после закрытия файла?
> есть истории успеха по обнаружению таких «хвостов»?
При использовании «железки», пароль вообще ни на секунду в память не
попадёт, в том и разница.
Замечание, конечно, занудно-параноидальное, но вполне в духе всего
обсуждения, как мне кажется :)
--
Alexander Galanin
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011053023321...@galanin.nnov.ru
Stanislav Maslovski
>
> -куть
> >>А вариант с аппаратным ключом тоже не идеален.
> >>Если ключ отдаст пароль без авторизации - кто мешает утянуть этот
> >>самый пароль кому угодно, имеющему доступ к ключу?
> >>Если требуется вводить пароль - тогда проще вызывать mount.cifs вручную ;)
> >В таком случае вам нужен аппаратный ключ, отдающий не пароль, а респонс по
> >переданному челленджу (мы ведь челлендж-респонс протокол обсуждаем?)
> >
> Началось все с организации безопасного хранилища паролей для
> mount.cifs. В котором получение root доступа не означает получение
> пароля.
^^^^^^^^^
Как легко сообразить, это в принципе невозможно сделать, если пароль
дешифруется тем же железом, к которому у злоумышленника есть рутовый
доступ.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011053020...@kaiba.homelan
Stanislav Maslovski
> >On Mon, May 30, 2011 at 12:59:52PM +0300, Igor Chumak wrote:
> >>Наиболее правильно, ИМХО, было правильно генерировать ключ случайным
> >>образом на этапе компиляции samba - тогда ключ окажется идентичным и
> >>в mount.cifs и в make_credentials. Удалить исходники после установки
> >>- и можно считать, что хранилище паролей достаточно надежно.
> >>
> >>Естествено, надо позаботиться о том, чтобы ключ дизассемблировать
> >>было неудобно ;).
> >Ужасно.
> >
> Угу. Безопасность не должна основываться на секретном алгоритме, я в курсе.
> Предложите решение покрасивше ;)
Правильное решение с точки зрения безопасности в данной задаче - это
вместо предоставления доступа линукс-машине к ресурсам
виндовс-сервера, предоставить доступ виндовс-серверу к ресурсам
линукс-машины. Например, подложить виндовому шедулеру скрипт, который
по (s)ftp в определенное время будет забирать готовый файл бэкапа с
линукс-машины.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011053020...@kaiba.homelan
Artem Chuprina
> >> > переданному челленджу (мы ведь челлендж-респонс протокол обсуждаем?)
> >>
> >> а что может помешать воспользоваться этим аппаратным ключом злоумышленнику?
> >
> > Воспользоваться, пока он вставлен - ничего. Не получится прикопать
> > credentials для последующего использования в более удобный момент.
>
> разве это как-то принципиально отличается, например, от ношения
> файлика credentials на флэшке?
Да. В случае флешки прикопать ничто не мешает.
RTFM: Шнайер, "Прикладная криптография"
--
Молодой, дикорастущий организм...
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/8739jvvs7v.wl%r...@ran.pp.ru
Stanislav Maslovski
> On Mon, May 30, 2011 at 02:13:23PM +0300, Igor Chumak wrote:
> > 30.05.2011 13:50, Andrey Rahmatullin пишет:
> > >On Mon, May 30, 2011 at 12:59:52PM +0300, Igor Chumak wrote:
> > >>Наиболее правильно, ИМХО, было правильно генерировать ключ случайным
> > >>образом на этапе компиляции samba - тогда ключ окажется идентичным и
> > >>в mount.cifs и в make_credentials. Удалить исходники после установки
> > >>- и можно считать, что хранилище паролей достаточно надежно.
> > >>
> > >>Естествено, надо позаботиться о том, чтобы ключ дизассемблировать
> > >>было неудобно ;).
> > >Ужасно.
> > >
> > Угу. Безопасность не должна основываться на секретном алгоритме, я в курсе.
> > Предложите решение покрасивше ;)
>
> Правильное решение с точки зрения безопасности в данной задаче - это
> вместо предоставления доступа линукс-машине к ресурсам
> виндовс-сервера, предоставить доступ виндовс-серверу к ресурсам
> линукс-машины. Например, подложить виндовому шедулеру скрипт, который
> по (s)ftp в определенное время будет забирать готовый файл бэкапа с
> линукс-машины.
В добавление: сгодится даже анонимный ftp (или tftp) с
ограничением доступа к линукс-машине просто по IP, если бэкапы
выкладывать зашифрованными открытым ключём (предполагается, что
секретный ключ и доступ к виндовс-серверу есть у лица, ответственного
за восстановление из бэкапа).
Igor Chumak
-cut
>> Правильное решение с точки зрения безопасности в данной задаче - это
>> вместо предоставления доступа линукс-машине к ресурсам
>> виндовс-сервера, предоставить доступ виндовс-серверу к ресурсам
>> линукс-машины. Например, подложить виндовому шедулеру скрипт, который
>> по (s)ftp в определенное время будет забирать готовый файл бэкапа с
>> линукс-машины.
> В добавление: сгодится даже анонимный ftp (или tftp) с
> ограничением доступа к линукс-машине просто по IP, если бэкапы
> выкладывать зашифрованными открытым ключём (предполагается, что
> секретный ключ и доступ к виндовс-серверу есть у лица, ответственного
> за восстановление из бэкапа).
>
bakula ;)
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrey Rahmatullin
> >> >> а что может помешать воспользоваться этим аппаратным ключом злоумышленнику?
> >> > Воспользоваться, пока он вставлен - ничего. Не получится прикопать
> >> > credentials для последующего использования в более удобный момент.
> >> разве это как-то принципиально отличается, например, от ношения
> >> файлика credentials на флэшке?
> > Содержимое credentials не будет болтаться в памяти компьютера.
> а долго это содержимое может проболтаться в памяти после закрытия файла?
> есть истории успеха по обнаружению таких «хвостов»?
--
WBR, wRAR