Sat, 19 Jul 2014 17:47:30 +0400 Eugene писал(а):
Можно уже шифрованное передавать, сжатое, и т.п.
Можно много чего чисто теоретически, только схема cryptsetup на vds
в эти теоретизирования не укладывается. Конкретные предложения есть?
Это уже было конкретно.
Но, я заметил, что кто-то
On Fri, 18 Jul 2014 23:16:46 +0400
Artem Chuprina r...@ran.pp.ru wrote:
cryptsetup позволяет заинтересованным лицам с хост-машины почитать
содержимое VDS, когда та запущена.
Можно уже шифрованное передавать, сжатое, и т.п.
Иван.
--
To UNSUBSCRIBE, email to
On Sat, Jul 19, 2014 at 07:58:07PM +0700, Иван Чернов wrote:
On Fri, 18 Jul 2014 23:16:46 +0400
Artem Chuprina r...@ran.pp.ru wrote:
cryptsetup позволяет заинтересованным лицам с хост-машины почитать
содержимое VDS, когда та запущена.
Можно уже шифрованное передавать, сжатое, и т.п.
т.е. шифровать у себя, а потом огромный архив целиком гнать по сети на сервер.
ТС же заявляет, что именно от этого хочет уйти.
2014-200 04:05 Artem Chuprina r...@ran.pp.ru wrote:
dimas - debian-russian@lists.debian.org @ Sat, 19 Jul 2014 00:07:34 +0400:
d ну не знаю, через sshfs/sftp
хм, не совсем знаком с тонкостями sshfs и прочих всяких nfs. неужто нету
протоколов, где при изменении файла не надо гонять его весь целиком, а
синхронизируется только измененный кусок?
контейнер там или не контейнер - не вижу разницы. файл он и есть файл. сервер
дает к нему доступ, а чем там его
On Sat, Jul 19, 2014 at 11:31:45PM +0400, dimas wrote:
хм, не совсем знаком с тонкостями sshfs и прочих всяких nfs. неужто нету
протоколов, где при изменении файла не надо гонять его весь целиком, а
синхронизируется только измененный кусок?
Протоколы такие есть, вот только sshfs к ним не
dimas - debian-russian@lists.debian.org @ Sat, 19 Jul 2014 23:27:56 +0400:
d т.е. шифровать у себя, а потом огромный архив целиком гнать по сети на
сервер.
d ТС же заявляет, что именно от этого хочет уйти.
Вопрос стоял кто не позволяет подсмотреть? Вот, gnupg не позволяет.
Шифровать,
Здравствуйте.
Создаю бекапы с помощью rsync на удаленный сервер по ssh.
Хочется чтоб на удаленном сервере файлы лежали в зашифрованном виде.
Никак не могу придумать как это сделать.
Создавать архив, который сжать, который зашифровать, а потом передавать
на удаленный хост не получится - размер
18.07.2014 13:30, Dmitry Podkovyrkin пишет:
Здравствуйте.
Создаю бекапы с помощью rsync на удаленный сервер по ssh.
Хочется чтоб на удаленном сервере файлы лежали в зашифрованном виде.
duplicity
--
С уважением. WBR.
Алексей. Alexey.
mailto:ale...@remizov.org
18.07.2014 15:59, Alexey Remizov пишет:
18.07.2014 13:30, Dmitry Podkovyrkin пишет:
Здравствуйте.
Создаю бекапы с помощью rsync на удаленный сервер по ssh.
Хочется чтоб на удаленном сервере файлы лежали в зашифрованном виде.
duplicity
Вот спасибо. То что нужно.
--
Regards
Dmitry
да банальный cryptsetup. или еще чего на вкус и цвет
2014-199 15:30 Dmitry Podkovyrkin dmitry@rutelecom.company wrote:
На удаленном сервере создавать шифрованный архив (образ), который
монтируется как каталог в который и делать rsync? Есть такие решения?
--
To UNSUBSCRIBE, email to
dimas - debian-russian@lists.debian.org @ Fri, 18 Jul 2014 22:12:45 +0400:
d да банальный cryptsetup. или еще чего на вкус и цвет
cryptsetup позволяет заинтересованным лицам с хост-машины почитать
содержимое VDS, когда та запущена.
--
To UNSUBSCRIBE, email to
ну не знаю, через sshfs/sftp монтировать удаленную фс к себе, а потом контеёнер
открывать у себя
и это, кто не позволяет?
2014-199 23:16 Artem Chuprina r...@ran.pp.ru wrote:
dimas - debian-russian@lists.debian.org @ Fri, 18 Jul 2014 22:12:45 +0400:
d да банальный cryptsetup. или еще чего
On Sat, Jul 19, 2014 at 12:07:34AM +0400, dimas wrote:
ну не знаю, через sshfs/sftp монтировать удаленную фс к себе, а потом
контеёнер
открывать у себя
и это, кто не позволяет?
А головой подумать? :) На каждую операцию с образом fs, смонтированным
через cryptsetup, потребуется обновление
dimas - debian-russian@lists.debian.org @ Sat, 19 Jul 2014 00:07:34 +0400:
d ну не знаю, через sshfs/sftp монтировать удаленную фс к себе, а потом
контеёнер
d открывать у себя
d и это, кто не позволяет?
gnupg, например, не позволяет. Причем без извращений.
d да банальный cryptsetup.
, чтобы понять статью
Disk encryption theory в английской википедии.
Статья про Block Cipher mode of operation там тоже в общем достаточно
понятно все про CBC разъясняет.
И третье. Насколько я знаю, aes предполагает симметричное шифрование. И
таким образом шифруется весь диск. Но в самом начале
-cbc-essiv.
Первое, я не уверен, что это нужно называть алгоритмом.
Второе, я не очень понял, что есть cbc и essiv после беглого чтения
википедии. Есть желание понять, посоветуйте что почитать.
И третье. Насколько я знаю, aes предполагает симметричное шифрование. И
таким образом шифруется весь диск
On Mon, Apr 21, 2014 at 12:51:57AM +0400, Dmitrii Kashin wrote:
И третье. Насколько я знаю, aes предполагает симметричное шифрование. И
таким образом шифруется весь диск. Но в самом начале же диска должна
находиться весьма известная структура данных - таблица разделов, что
видится мне
да, если есть свап, его, наверно, стоит зашифровать с /dev/urandom в качестве
ключа. так делается по-дефолту в убунтовском установщике (про остальных не
знаю), если сделать хомяк с ecryptfs. при каждой загрузке свап шифруется
рэндомным ключом, который живет только в течение одной сессии.
dimas wrote:
да, если есть свап, его, наверно, стоит зашифровать с /dev/urandom в качестве
Нет, не стоит. Поскольку речь идёт о нетбуке, вероятно использование hibernate
(suspend-to-disk). А оно с случайным ключём для свопа не совместимо.
ключа. так делается по-дефолту в убунтовском
, читай подводные камни.
2. Какова будет плата за шифрование (нагрузка на cpu, сокращение
длительности работы от батарей).
3. Какой метод шифрования лучше выбрать. Я не параноик, главное чтоб мои
личные данные не утекли при потере нетбука, сдачи его в ремонт и т.п. И
так чтоб не сильно просаживалась
шифровать (cryptsetup,
cryptsetup LUKS синтаксис, loop-aes), их особенности, читай подводные камни.
LUKS, особенно если нет желания использовать фразу от 20 символов.
loop-aes устарел и не нужен.
2. Какова будет плата за шифрование (нагрузка на cpu, сокращение
длительности работы от батарей).
Зависит
подводные камни.
имхо лучше всего cryptsetup (прописываем нужное в crypttab) и все.
loop-aes нынче вошел в cryptsetup
2. Какова будет плата за шифрование (нагрузка на cpu, сокращение
длительности работы от батарей).
по сравнению с расходами на саму дисковую активность мизерная.
я просадок по
LUKS, особенно если нет желания использовать фразу от 20 символов.
loop-aes устарел и не нужен.
Спасибо. Сам уже склоняюсь к LUKS, т.к. понравилась идея со слотами. И
относительно легкой сменой пароля.
Зависит от дискового I/O. Я пока не замечал особого уменьшения времени
автономной работы
4. Существует ли возможность использовать разные контейнеры для
расшифровки в зависимости от парольной фразы? Например для подмены /home
фиктивными данными. Я понимаю что при не зашифрованном корне это может
быть легко обнаружено, но все же.
на своих скриптах разве что
Да, пожалуй оптимальный
- User Dmitry E. Oboukhov on 2012-04-01 23:22:57 wrote:
3. Какой метод шифрования лучше выбрать. Я не параноик, главное чтоб мои
личные данные не утекли при потере нетбука, сдачи его в ремонт и т.п. И
так чтоб не сильно просаживалась производительность.
AES256 или 512 имхо
Главный вопрос
- User Sergej Kochnev on 2012-04-02 02:11:02 wrote:
3. Какой метод шифрования лучше выбрать. Я не параноик, главное чтоб мои
личные данные не утекли при потере нетбука, сдачи его в ремонт и т.п. И
так чтоб не сильно просаживалась производительность.
aes-cbc-essiv, желательно в 64-битном
Привет
On 09/06/2010 06:36 AM, Korona Auto Ltd./ Andrey N. Prokofiev wrote:
1) Как сделать автоматическое монтирование тома при перезагрузке
системы? Где при этом хранить файл-ключа? Можно ли его хранить на
удаленном фтп сервере или есть более разумный способ?
А смысл хранить на FTP сервере?
Sergey Spiridonov пишет:
Привет
On 09/06/2010 06:36 AM, Korona Auto Ltd./ Andrey N. Prokofiev wrote:
1) Как сделать автоматическое монтирование тома при перезагрузке
системы? Где при этом хранить файл-ключа? Можно ли его хранить на
удаленном фтп сервере или есть более разумный способ?
А
On Mon, Sep 06, 2010 at 02:45:15PM +0400, Korona Auto Ltd./ Andrey N. Prokofiev
wrote:
А если ключ хранится где-то на фтп в локальной сети, то
злоумышленник утащив сервер не сможет получить доступ к тому по
причине недоступности ключа. Или есть более кошерные варианты?
Да есть. Определить
Иван Лох пишет:
Да есть. Определить какие данные являются секретными, кто за них отвечает и
куда этот человек втыкает ключ, когда ему нужно с ними работать.
За эти данные отвечает целый отдел. И чего? Дать начальнику отдела ключ
от серверной?
--
WBR, Andrey N. Prokofiev
IT department of
On Mon, Sep 06, 2010 at 03:11:49PM +0400, Korona Auto Ltd./ Andrey N. Prokofiev
wrote:
Иван Лох пишет:
Да есть. Определить какие данные являются секретными, кто за них отвечает и
куда этот человек втыкает ключ, когда ему нужно с ними работать.
За эти данные отвечает целый отдел. И чего?
Korona Auto Ltd./ Andrey N. Prokofiev пишет:
Можно ли его хранить на
удаленном фтп сервере или есть более разумный способ?
Если уж так делать, то лучше не FTP. По FTP всё идёт по сети в открытую.
--
Dmitri Samsonov
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a
Привет
On 09/06/2010 12:45 PM, Korona Auto Ltd./ Andrey N. Prokofiev wrote:
А смысл хранить на FTP сервере? Тогда уж храни на USB stick, который
нужно вставить при перезагрузке. Наверное есть смысл даже там держать
весь /boot.
Так это не секюрно. Получается получив доступ к серверу -
День добрый. Необходимо реализовать файловый сервер с шифрованием данных.
При этом планирую использовать самбу+truecrypt. При помощи truecrypt
шифруется том raid1, а самбой расшаривает для доступа пользователям. При
этом возникает два вопроса:
1) Как сделать автоматическое монтирование тома
Maxim Tyurin [EMAIL PROTECTED] wrote:
Andrey Melnikoff writes:
Maxim Tyurin [EMAIL PROTECTED] wrote:
Andrey Melnikoff writes:
То, что там можно хранить сертификаты - это я понял.. а вот что делать с
паролями из той-же мозилы - непонятно.
Firefox и thunderbird умеют работать с
Andrey Melnikoff writes:
Maxim Tyurin [EMAIL PROTECTED] wrote:
Andrey Melnikoff writes:
То, что там можно хранить сертификаты - это я понял.. а вот что делать с
паролями из той-же мозилы - непонятно.
Firefox и thunderbird умеют работать с токеном.
Я правильно понимаю - что на токене
Maxim Tyurin [EMAIL PROTECTED] wrote:
Andrey Melnikoff writes:
То, что там можно хранить сертификаты - это я понял.. а вот что делать с
паролями из той-же мозилы - непонятно.
Firefox и thunderbird умеют работать с токеном.
Я правильно понимаю - что на токене можено держать свой
Andrey Melnikoff writes:
То, что там можно хранить сертификаты - это я понял.. а вот что делать с
паролями из той-же мозилы - непонятно.
Firefox и thunderbird умеют работать с токеном.
--
With Best Regards, Maxim Tyurin
JID:[EMAIL PROTECTED]
--
To UNSUBSCRIBE,
Maxim Tyurin [EMAIL PROTECTED] wrote:
Andrey Melnikoff writes:
Maxim Tyurin [EMAIL PROTECTED] wrote:
Andrey Melnikoff writes:
Pavel Ammosov [EMAIL PROTECTED] wrote:
On Thu, Mar 13, 2008 at 09:55:06PM +0300, sergio wrote:
[]
Если нужна защита, то существует IBM 4758
2008/3/27 andrey i. mavlyanov [EMAIL PROTECTED]:
Konstantin Matyukhin пишет:
А что есть для хранения ключей/паролей ? i.e. есть кучка паролей,
логинов,
ssh ключей - их надо где-то хранить, причем более-менее секурно.
KM aptitude install revelation
Гном. Отказать.
Andrey Melnikoff writes:
Pavel Ammosov [EMAIL PROTECTED] wrote:
On Thu, Mar 13, 2008 at 09:55:06PM +0300, sergio wrote:
[]
Если нужна защита, то существует IBM 4758
(http://www.ibm.com/security/cryptocards/)
Это PCI-карта, представляющая защищённое хранилище ключей (от
физического
andrey i. mavlyanov [EMAIL PROTECTED] wrote:
Konstantin Matyukhin пишет:
А что есть для хранения ключей/паролей ? i.e. есть кучка паролей,
логинов,
ssh ключей - их надо где-то хранить, причем более-менее секурно.
KM aptitude install revelation
Гном. Отказать.
Что ж,
Maxim Tyurin [EMAIL PROTECTED] wrote:
Andrey Melnikoff writes:
Pavel Ammosov [EMAIL PROTECTED] wrote:
On Thu, Mar 13, 2008 at 09:55:06PM +0300, sergio wrote:
[]
Если нужна защита, то существует IBM 4758
(http://www.ibm.com/security/cryptocards/)
Это PCI-карта, представляющая
Andrey Melnikoff writes:
Maxim Tyurin [EMAIL PROTECTED] wrote:
Andrey Melnikoff writes:
Pavel Ammosov [EMAIL PROTECTED] wrote:
On Thu, Mar 13, 2008 at 09:55:06PM +0300, sergio wrote:
[]
Если нужна защита, то существует IBM 4758
(http://www.ibm.com/security/cryptocards/)
Konstantin Matyukhin - debian-russian@lists.debian.org @ Thu, 27 Mar 2008
22:00:23 +0300:
А что есть для хранения ключей/паролей ? i.e. есть кучка
паролей, логинов, ssh ключей - их надо где-то хранить, причем
более-менее секурно.
KM aptitude install revelation
Гном.
Pavel Ammosov [EMAIL PROTECTED] wrote:
On Thu, Mar 13, 2008 at 09:55:06PM +0300, sergio wrote:
[]
Если нужна защита, то существует IBM 4758
(http://www.ibm.com/security/cryptocards/)
Это PCI-карта, представляющая защищённое хранилище ключей (от
физического взлома, от нагрева,
Andrey Melnikoff - debian-russian@lists.debian.org @ Thu, 27 Mar 2008
00:42:16 +0300:
Если нужна защита, то существует IBM 4758
(http://www.ibm.com/security/cryptocards/)
Это PCI-карта, представляющая защищённое хранилище ключей (от
физического взлома, от нагрева, охлаждения,
А что есть для хранения ключей/паролей ? i.e. есть кучка паролей, логинов,
ssh ключей - их надо где-то хранить, причем более-менее секурно.
aptitude install revelation
--
С уважением,
Константин Матюхин
Konstantin Matyukhin - debian-russian@lists.debian.org @ Thu, 27 Mar 2008
10:32:19 -0400:
А что есть для хранения ключей/паролей ? i.e. есть кучка паролей, логинов,
ssh ключей - их надо где-то хранить, причем более-менее секурно.
KM aptitude install revelation
Гном. Отказать.
--
Konstantin Matyukhin - debian-russian@lists.debian.org @ Thu, 27 Mar 2008
А что есть для хранения ключей/паролей ? i.e. есть кучка паролей,
логинов,
ssh ключей - их надо где-то хранить, причем более-менее секурно.
passwords.txt.cpt - текстовый файл, зашифрованный ccrypt.
А что есть для хранения ключей/паролей ? i.e. есть кучка паролей,
логинов,
ssh ключей - их надо где-то хранить, причем более-менее секурно.
KM aptitude install revelation
Гном. Отказать.
Что ж, идущим в альтернативном направлении могу посоветовать MyPasswordSafe.
--
С
sergio - debian-russian@lists.debian.org @ Fri, 14 Mar 2008 03:00:50 +0300:
Еще swap не стоит забывать.
s Может это и не хорошо, но его просто нету.
Здесь показанно как размещать ключ на usb:
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedVarWithUSBKey
s опять-же надо
sergio - debian-russian@lists.debian.org @ Fri, 21 Mar 2008 17:35:29 +0300:
Ну ты уж выбери что-нибудь одно. Либо вводить ключ с помощью человека,
предварительно проверив все, что можно, либо без помощи человека, как в
DRM. Последний вариант скомпрометирован априори.
s да мне не сложно
Всем привет.
При утсановке дебиана можно сделать шифрованный раздел. или даже сделать
шифрованным root с отдельным boot для initrd.
Проблема только в том, что при загрузке надо ввести пароль.
То есть надо оказаться рядом с этим компутером да ещё и подключить к
нему клавиатуру. А
sergio wrote:
При утсановке дебиана можно сделать шифрованный раздел. или даже сделать
шифрованным root с отдельным boot для initrd.
Еще swap не стоит забывать.
Проблема только в том, что при загрузке надо ввести пароль.
Здесь показанно как размещать ключ на usb:
Nicholas wrote:
Еще swap не стоит забывать.
Может это и не хорошо, но его просто нету.
Здесь показанно как размещать ключ на usb:
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedVarWithUSBKey
опять-же надо оказаться рядом с машиной.
Тем же способом можно попробовать разместить
Все cryptofs'ы, если смонтированы, админу доступны.
доступны ли они админу если виртуальная машина занимается
шифровкой/расшифровкой образа при работе?
маунт на виртуальной машине как-то встраивается в общую ФС разве?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Tue, 11 Mar 2008
12:25:37 +0300:
Все cryptofs'ы, если смонтированы, админу доступны.
DEO доступны ли они админу если виртуальная машина занимается
DEO шифровкой/расшифровкой образа при работе? маунт на виртуальной
DEO машине как-то
вытекающими..
эмм
так я ж и говорю в этом случае есть проблема бакапа ключа бакапа.
в сейфе его хранить чтоли? да ну нафиг
Ассиметричное шифрование. Ключ с которым шифруют не позволяет
расшифровать а ключ для расшифровки ну например на флэшке у босса
Сам ключ может шифроваться паролем
имеется шифрованный (AES256, но это непринципиально - всегда можно
изменить) раздел.
монтируется руками с вводом пароля.
далее есть необходимость создания второго шифрованного раздела.
хочется тут не вводить еще раз пароли а использовать тот же.
как решение:
скрипт монтирует сперва один
Dmitry E. Oboukhov пишет:
имеется шифрованный (AES256, но это непринципиально - всегда можно
изменить) раздел.
монтируется руками с вводом пароля.
далее есть необходимость создания второго шифрованного раздела.
хочется тут не вводить еще раз пароли а использовать тот же.
как решение:
скрипт
Не совсем понятна задача. если это
раздел для бэкапов то почему-бы просто не
шифровать бэкап
(ну например с помощью fsbackup) с помощью gnupg
открытым ключем? И раздел не надо будет
шифровать
и бэкапы будут пакованные ну и можно
полные/инкрементальные со всеми
вытекающими..
эмм
Fri, 7 Mar 2008 16:16:52 +0300
Dmitry E. Oboukhov [EMAIL PROTECTED] wrote:
Не совсем понятна задача. если это
раздел для бэкапов то почему-бы просто не
шифровать бэкап
(ну например с помощью fsbackup) с помощью gnupg
открытым ключем? И раздел не надо будет
шифровать
и бэкапы
в случае если это пароль, то бакап ключа не нужен - в голове
очень надежно хранится информация :)
Очень большое заблуждение.
если со мной что-то случится то мне совершенно безразлично будет что там
и как с серверами которые я админю :)
вот уж не хватало на этот случай закладываться по _работе_
еще вопросик смежный.
есть всякие услуги вроде VDS-серверов. есть клиент который хочет держать
на таком сервере данные. за траффик он за свой не переживает
(шифроваться будет) а вот данные ему хочется обезопасить.
есть ли решения, позволяющие закрыть доступ к данным на таком сервере от
легкости доступа. (Ну, может,
существует специально обученный патч к ядру, который админа такой
возможности лишает, но в норме надо исходить из того, что вся память
работающей машины ему доступна.)
Можно производить одностороннее шифрование данных (зашифровать можно,
расшифровать в автопилоте
то что надо :)
Можно производить одностороннее шифрование данных (зашифровать можно,
расшифровать в автопилоте - нельзя), если есть уверенность, что админ не
перехватит эти данные до зашифрования.
Но общая идея формулируется кратко и исключений не имеет - если ты не
доверяешь админу, тебе
Fri, 7 Mar 2008 17:46:26 +0300
Dmitry E. Oboukhov [EMAIL PROTECTED] wrote:
DEO есть ли решения, позволяющие закрыть доступ к данным на таком
DEO сервере от администратора (хостера итп)?
DEO если создать скажем шифрованный раздел, то пока он смонтирован
DEO один фиг он будет виден админу? я
вот например sshfs есть
так там по дефолту, смонтированное юзером root не видит
интересно насколько это надежно?
sudo -u user bash
%)
а ну да
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Fri, 7 Mar 2008
17:55:01 +0300:
вот например sshfs есть
так там по дефолту, смонтированное юзером root не видит
интересно насколько это надежно?
sudo -u user bash
%)
DEO а ну да
Рут в юниксе может всё.
--
Artem Chuprina
Fri, 07 Mar 2008 18:33:04 +0300
Artem Chuprina [EMAIL PROTECTED] wrote:
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Fri, 7 Mar
2008 17:55:01 +0300:
вот например sshfs есть
так там по дефолту, смонтированное юзером root не видит
интересно насколько это надежно?
sudo -u
Alexander GQ Gerasiov - debian-russian@lists.debian.org @ Fri, 7 Mar 2008
18:41:01 +0300:
вот например sshfs есть
так там по дефолту, смонтированное юзером root не видит
интересно насколько это надежно?
sudo -u user bash
%)
DEO а ну да
Рут в юниксе может всё.
AGG
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Fri, 7 Mar 2008
17:46:26 +0300:
Но общая идея формулируется кратко и исключений не имеет - если ты
не доверяешь админу, тебе нечего делать на его сервере.
DEO ну я примерно такое резюме и вынес :)
DEO тут как всегда жадность клиента
DEO а на не собственном сервере я вообще не понимаю людей которые
DEO размещают свои данные. кучу контор знаю которые держат свои БД у
DEO хостеров. а по идее админы тех хостеров получают в сотни-тысячи
DEO раз меньшие бабки чем стоят те данные. при желании думаю купить
DEO информацию не большая
On 2008.03.07 at 16:42:25 +0300, Dmitry E. Oboukhov wrote:
в случае если это пароль, то бакап ключа не нужен - в голове
очень надежно хранится информация :)
Очень большое заблуждение.
если со мной что-то случится то мне совершенно безразлично будет что там
и как с серверами которые я
On 2008.03.07 at 17:46:26 +0300, Dmitry E. Oboukhov wrote:
а на не собственном сервере я вообще не понимаю людей которые размещают
свои данные. кучу контор знаю которые держат свои БД у хостеров.
а по идее админы тех хостеров получают в сотни-тысячи раз меньшие бабки
чем стоят те данные. при
шифрует все проходящие данные. Вопросы: кто работал с таким
оборудованием - что лучше приобретать, какие они есть (SCSI, IDE), нужны ли
драйвера или оно так работает (Debian Woody) (я так понимаю что пароль
должен передаваться извне, а не жестко зашит в сем девайсе)...
Апаратное шифрование
жестко зашит в сем девайсе)...
Апаратное шифрование ничем не может быть лучше програмного с точки зрения
надежности.
Если надо просто впечатляющее клиента решение - можно попробовать это
http://www.securit.ru/produkt/server.shtml
(сам не пробовал, может соберусь).
Кстати они
Добрый деньВот у клиента появилось желание организовать сервер под
Linux с аппаратным шифрованием всех данных. Я себе так представляю (никогда
раньше не сталкивался с такими вещами), что эта вещь ставится между винтом и
контроллером и шифрует все проходящие данные. Вопросы: кто работал с
Hi debian-russian,
Интересует такой вопрос, как зашифровать траффик между двумя
машинами в инете? Никогда с этим не работал, так что если
можно - поподробнее пожалуйста.
Или ссылочку, желательно русскоязычную.
--
Best regards,
Dmitry
On Tue, 10 Apr 2001, Dmitry V. Glushenok wrote:
From: Dmitry V. Glushenok [EMAIL PROTECTED]
Subject: шифрование траффика
X-Mailer: The Bat! (v1.51) UNREG / CD5BF9353B3B7091
Hi debian-russian,
Интересует такой вопрос, как зашифровать траффик между двумя
машинами в инете? Никогда с этим
On Tue, 10 Apr 2001, Dmitry V. Glushenok wrote:
Date: Tue, 10 Apr 2001 09:44:30 +0400
From: Dmitry V. Glushenok [EMAIL PROTECTED]
To: debian-russian@lists.debian.org
Subject: шифрование траффика
Resent-From: debian-russian@lists.debian.org
Hi debian-russian,
Интересует такой вопрос
а еще
IPSEC (freeSwan,W2k)
s/W2k/vtun/
--
Alexey Vyskubov
(at home)
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
84 matches
Mail list logo
