Секция 5 из 5 - Предыдущая - Следующая
Все секции - 1 - 2 - 3 - 4 - 5

From: Mikael Mylnikov mylnikov@tchercom.ru> 2:5020/400	  Чет 28 Дек 00 15:54

> Встали вопросы зашифровать инфу на сервере. Лазил, лазил по инету,
> наковырял разного, есть вопросы, ответить некому :)

> Вопросы.
>
> 1. Пару раз читал упоминания о том, что недавно в PGP обнаружен типа
>    черный ход, через ктр очень легко получить зашифрованную информацию.
>    Нельзя ли	подробностей ?
>К PGPDisk-у это относится ?

Уже закрыли. Бери версию 7.0

> 2. Есть ещё такой ScramDisk -  http://www.scramdisk.clara.net/. Якобы
>    лучше PGPDisk-a ... Бесплатный, исходники прилагаются ...
>    Что и чем лучше -

Скрам бесплатный и гораздо меньше по размерам (плюс разные вкусности на
любителя). PGP гораздо корректнее отрабатывает виртуальный драйв. Например,
на PGP диске ты можешь создать том Скрама, а наоборот - фигушки.

> PGPDisk или ScramDisk ?  И, если я  пральна понял - ScramDisk только под
> Вин98 ? под NT не ? В смысле, разместить криптоконтейнер в NTFS нельзя ?

Льзя, но за деньги. Версия под NT платная.

> 3. Известно ли что-нибудь о методах взлома зашифрованной PGPDisk-ом
> информации ? Вообще, существуют ли такие методы ? Ну, кроме перебора,
> есесна. А то начальство требует защиты уровня "взломать невозможно" :)))

Оба удовлетворяют этому требованию (если добавить - на практике). Атака
может вестись только на пароль пользователя, либо программная закладка...


> 4.  Какая последняя версия PGPDiska ? Где  где можно купить и сколько
>     стоит ? Помимо варианта покупать целиком PGP Desktop Security 7.0 ...
>     Его, кстати,  я нашел вот тут :
> (From FAQ Creator: К сожалению ftp не позволяет анонимного входа)
> ftp.rsc.donpac.ru/Users/Warez/PGP7/PGP_Desktop_Security_7.

Их много.

> Есть ли грабли в использовании ворованного cедьмого ?

Совесть замучает.

> или лучше скачать фриварный PGPDisk6.02i ?

Врать не буду, что-то с фриварным не то. Плодит зачем-то кучу одинаковых
устройств в менеджере (да и под NT вроде не работает).

>Чем лучше шифpовать диск<
--------------------------
From: Vladislav Myasnyankin		  2:5080/101.8	  Сре 21 Фев 01 21:03

bans> Что можете сказать по поводу BestEncrypt 6.06 from Jetico?
bans> Имеет ли смысл ему доверять?
Виндовому - не знаю. А просмотр исходников линуксового явных дыр не выявил.
У меня уже с полгода работает, даже одному юзеру шифрованный домашний
каталог сделал.


>Разница в NTWSv4 и NTSv4<
--------------------------
From: Roman Zhuk <zhukrs@int.spb.ru>	  2:5030/518.50   Пят 06 Апр 01 11:17
From: Ilia Kuliev			  2:5020/1423.6   Сре 11 Апр 01 19:33


RZ>>>>>>> NT 4.0 Server со стоящим поверх RRAS умеет OSPF. А заодно до кучи умеет
RZ>>>>>>> всякой туфты - типа генерить Source Quench и т.д. Только это почему-то
RZ>>>>>>> вяло декларируется. Кстати, у NTS и NTW протокольные стеки TCP/IP разные.
RZ>>>>>>> Особенно заметна разница в управлении потоком.
>>>>>> Как это может быть, когда для NTS и NTW идут одни и те же сервиспаки? Уж
>>>>>> апдейт стека TCP/IP там всяко дoлжен быть.
>>>>>>
>>>>>> Можно конечно предположить, что паки состоят как бы из двух частей - для
>>>>>> сервера и для WS, но слабо верится...

>>>>> Посмотри, как у того и другого работает алгоритм медленного старта (в TCP),
>>>>> и таймаут повторной пересылки. Легко отслеживается через размер очереди на
>>>>> приемном интерфейсе маршрутизатора, если тот быстрее передающего интерфейса
>>>>> (типа LAN-to-WAN), а также через мониторинг сегмента между рутером и NT.

>>>> На кой хрен этот Source Quench нужен ( что это такое я знаю ) ?
>>>> На него же все давно забили....

>>> Поставь в сеть с NTWS маршрутизатор с одним LAN-интерфейсом, а другим сильно
>>> медленным, где-нибудь 9600б/с или ниже(только не надо говорить, что таких
>>> каналов не бывает, я знаю реально действующие на 1200б/с). И померяй
>>> скорость от NTWS через маршрутизатор. NTWS мгновенно забивает очередь
>>> рутера, тот дропает пакеты, и НТя впадает в ступор в ожидании ASK
>>> (растягивая тайм-аут повторной пересылки чуть ли не на минуту). Единственный
>>> способ вовремя заткнуть слишком говорливую Station,  - это послать ей ICMP
>>> Type 4. После этого скорость через рутер реально возрастает в 1,5-2 раза и
>>> приближается к теоретической скорости самого тормозного интерфейса. С NT
>>> Server такого не происходит, т.к. у нее более плавный медленный старт, и
>>> более грамотный алгоритм тайм-аута повторной пересылки. К сожалению, у M$
>>> нет других, более приличных способов управления потоком в TCP при работе
>>> стека NTWS (маздай - он и есть маздай). Вот только заказчикам это не
>>> объяснишь :((

>> Эта... плавный и медленный старт - в смысле, TCP ? Тогда что же получается, в
>> NTWS оно не имплементировано? У них же стек протоколов один в один, как это
>> может быть?

> Речь идет об алгоритме начального роста нагрузочного окна до размеров
> приемного в сеансе TCP, а также экспоненциальном торможении тайм-аута
> повторной пересылки.
> Я не занимался анализом исходников протокольного стека под НТ. Все
> вышесказанное получено на основе мониторинга сегмента и отслеживания
> состояния очереди на передающем (медленном) интерфейсе маршрутизатора. Наши
> проблемы начались с того, что заказчики стали жаловаться на медленную работу
> наших приложений (использующих сеансы TCP) под NTWS. При работе с NTS таких
> проблем не возникало. На NTWS замедление по ср. с теоретической скоростью
> примерно в полтора-два раза. Вообще в такой ситуации помогает принудительное
> уменьшение параметра TCPWindowSize в реестре. Но тогда скорость на LANе
> падает даже не в разы, а на порядки.
> В конце концов наши программеры переписали стек под НТ заново, но он
> работает только с нашими приложениями, а нативным остается только лапу
> сосать. Кстати, Source Quench в таких случаях тоже не панацея. Он хорошо
> работает только при односторонней передаче, а на встречных потоках скорость
> проседает процентов на 20, независимо от дуплекса. Впрочем, возможно, это
> просто кривая реализация ICMP Type 4 в RRAS. На цисках, каюсь, не проверял.
> Да и где взять циску, имеющую 1200-9600 на WANе, с версией IOS до 12 (дальше
> они от поддержки Source Quench отказались)? RFC 1812 указывает, что Source
> Quench - это плохо, и заботу об управлении потоком должны брать на себя сами
> приложения. Но как тогда бороться с кривым протокольным стеком - непонятно.


угу. Я понял, в общем. Гляньте вот эту статью на CITforum:

http://www.citforum.ru/internet/tifamily/optimize01.shtml
http://www.citforum.ru/internet/tifamily/optimize02.shtml

Она немножко заумная, но интересная. Оригинал - Максим Кульгин, "СЕТИ" #11/99
Там речь идет о тонкой настройке параметров стека TCP/IP в WinNT. Скорее
всего, "сервер" и "рабочая станция" как раз в них и различаются. А если я
ничего нового не сообщил - звиняйте...

Секция 5 из 5 - Предыдущая - Следующая

© faqs.org.ru