Защита информации, виртуальные частные сети (VPN). Технология ViPNet.

Здравствуйте, уважаемые подписчики!

При сохранении существующих темпов роста Internet такие особенности протокола IPv4, как недостаточный объем адресного пространства и неэффективный способ распределения адресов, станут неминуемо сдерживать его развитие.
Большинство специалистов в области технологий Internet уверены в необходимости перехода на новую, шестую версию протокола IP...
 
Представляем Вам статью Игоря Алексеева: "Переход на IPv6", посвященную вопросам безболезненного перехода на новую версию протокола Internet.

Как обычно в рассылке, свежие новости из области защиты информации и IT-технологий, информационные сообщения по новым атакам и способам взлома, статистика по инцидентам, а также новости компании Инфотекс.

Новости компании Инфотекс

• Компания "Инфотекс" приняла участие в семинаре "Информационная безопасность в корпоративных сетях", организованным ассоциацией "Бизнес-защита" в Новосибирске.
• Приглашаем принять участие в семинаре, проводимом компанией Инфотекс в рамках партнерской программы с Информационной системой оптовой торговли ИСОТ: "Создание защищенных телекоммуникаций для корпораций, дистрибьюторских и партнерских сетей".

Введение
При сохранении существующих темпов роста Internet такие особенности протокола IPv4, как недостаточный объем адресного пространства и неэффективный способ распределения адресов, станут неминуемо сдерживать его развитие. Большинство специалистов в области технологий Internet уверены в необходимости перехода на новую, шестую версию протокола IP. Косвенным свидетельством этому служит постоянно увеличивающееся число организаций, компаний-разработчиков сетевого оборудования и программного обеспечения, принимающих участие в Международном форуме IPv6. Вместе с тем, многие считают, что переходный период может затянуться на длительное, практически неограниченное время, в течение которого две версии протокола IP должны мирно сосуществовать. Поэтому способ перехода должен предусматривать сохранение совместимости новых узлов и сетей с доминирующим сейчас в Сети протоколом IPv4. Логика работы и форматы данных двух протоколов существенно отличаются, поэтому их совместимость должна обеспечиваться внешними по отношению к ним механизмами.

При правильном использовании механизмов перехода процесс смены версий протокола IP может оказаться не таким уж сложным, как это представляется сейчас.

Существующие механизмы
Взаимодействие систем, работающих с разными стеками протоколов, осуществляется обычно с использованием следующих методов:

• трансляция;
• мультиплексирование;
• инкапсуляция (туннелирование).

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

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

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

В процессе инкапсуляции принимают участие три типа протоколов:

• транспортируемый протокол;
• несущий протокол;
• протокол инкапсуляции.

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

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

В смешанных сетях IPv6—IPv4 наиболее часто используется мультиплексирование, а также туннелирование. Использование этих средств позволяет системам IPv6 обмениваться информацией с другими узлами IPv6 через сети IPv4. Для того чтобы узлы, поддерживающие только протокол IPv6, могли обращаться к ресурсам в сети IPv4, необходимо наличие дополнительных систем: шлюзов прикладного или транспортного уровня, трансляторов протоколов, шлюзов SOCKS. Сейчас основные усилия разработчиков направлены на создание механизмов, позволяющих протоколу IPv6 беспрепятственно работать поверх сетей, поддерживающих только IPv4. Однако в будущем потребуются средства, обеспечивающие передачу IPv4 через сети, где используюется исключительно IPv6, так как большинство систем в Internet перейдет на этот протокол.

Итак, для того чтобы вычислительные платформы работали в сетях IPv4 так же, как в IPv6, необходима одновременная поддержка и того и другого стека. Расширенная версия интерфейса socket дает приложению возможность указать, каким адресом — IPv6 или IPv4 — оно желает воспользоваться для установления соединения. Если приложение выдает адрес IPv6, то операционная система будет создавать соединение по протоколу IPv6. Системы с двойным стеком могут принимать, отправлять и обрабатывать пакеты обоих протоколов. Соответственно, каждая из таких систем должна иметь как минимум по одному никак не связанных друг с другом адресу IPv4 и IPv6.

Поскольку шестнадцатибайтный адрес IPv6 запомнить сложнее, чем четырехбайтный IPv4, то роль службы DNS в сетях IPv6 становится еще более значимой. Стандарт DNS определяет новые типы записей о ресурсах для установления соответствия между именем системы и ее адресами в форматах IPv4 и IPv6. Какой из протоколов будет задействован для того или иного соединения, зависит от порядка записей, предоставляемых службой DNS приложению. Например, система может предоставлять только адрес IPv4, или только IPv6, или возвращать все имеющиеся в DNS адресные записи, относящиеся к запрошенному имени.

Доставка пакетов IPv6 конечным системам возможна при условии существования общей для этих систем инфраструктуры доставки. Поскольку сети, поддерживающие IPv6, составляют пока лишь малую часть всего Internet, будучи "островами" в "океане" IPv4, то для обеспечения соединений между ними широко применяется метод туннелирования. Несущим протоколом здесь является IPv4, а транспортируемым — IPv6. Пакет IPv6 помещается в поле данных пакета IPv4 и передается по обычной сети IPv4. По окончании передачи он извлекается из поля данных и обрабатывается обычным образом — т. е. либо отправляется в дальнейший путь (уже по сети IPv6), либо используется непосредственно получившей его системой. В общем случае полный маршрут пакета IPv6 может включать несколько туннелей через транзитные сети IPv4.

Поскольку туннели (как статический, вручную сконфигурированный, так и автоматически построенный) имеют интерфейсы IPv6, то у них должен быть локальный адрес для их канальной среды (link local address), который используется протоколами маршрутизации, механизмом обнаружения соседей и т. п. Спецификацией протокола IPv6 предусматривается возможность автоматической конфигурации адреса на интерфейсе путем объединения префикса маршрутизации и канального адреса интерфейса. В случае туннельного интерфейса, адрес канальной среды составляется из идентификатора интерфейса — его адреса в сети IPv4 и префикса FE00::/64 (см. Рисунок 1).

Рисунок 1. Конструирование локального адреса туннельного интерфейса для канала IPv6.

Поддержка туннелирования расширяет функциональность узлов, являющихся конечными точками туннеля, и налагает на них дополнительные требования. Принимающий узел должен распознать, что в поле данных полученного им пакета IPv4 находится пакет IPv6. Для этого анализируется поле "протокол" в заголовке пакета IPv4, значение которого в данном случае должно быть равным десятичному числу 41.

Минимальное значение максимального размера пакета, который может быть отправлен через интерфейс (Maximum Transmission Unit, MTU) для IPv6 составляет 1280 байт. Для того чтобы избежать излишней фрагментации, инкапсулирующая система должна, по возможности, использовать такое значение MTU для пакета IPv6, чтобы он помещался вместе со своим заголовком в разрешенном значении MTU для IPv4. Если размер присылаемого пакета IPv6 не позволяет разместить его целиком в поле данных пакета IPv4, инкапсулирующий узел может отправить узлу-источнику трафика IPv6 управляющее сообщение ICMPv6. При передаче трафика IPv6 через туннель в сети IPv4 протокол IPv4 играет роль канальной среды, поэтому, когда пакет проходит через туннель, счетчик транзитных узлов маршрута (hop counter) уменьшается на 1. Это делает туннель прозрачным на уровне IPv6, а для инструментов сетевой диагностики (например, traceroute) — невидимым.

При приеме пакета IPv4, несущего в поле данных пакет IPv6, система должна применить к нему стандартные методы фильтрации трафика по исходному адресу IPv4: пакет отбрасывается, если это особый адрес — для многоадресной или широковещательной рассылки, 0.0.0.0 или 127.х.х.х (loopback). Затем, отбросив инкапсулирующий заголовок IPv4, аналогичную фильтрацию необходимо выполнить для адресов IPv6. К числу особых в протоколе IPv6 относятся адреса многоадресной рассылки, неопределенные адреса (unspecified address — 0.0.0.0/32 для IPv4 и ::/128 для IPv6), адреса обратной петли, а также особые адреса IPv4, полученные отображением на IPv6. Далее пакет передается стеку IPv6 и обрабатывается им как обычный пакет IPv6. Единственное исключение состоит в том, что узел не должен осуществлять дальнейшую маршрутизацию данного пакета, если только такая возможность не разрешена конфигурацией для адреса IPv4, с которого пришел пакет, т. е. если этот узел не сконфигурирован как конечная точка туннеля, начальной точкой которого является рассматриваемый адрес IPv4.

Поскольку начальная точка туннеля, осуществляющая инкапсуляцию пакетов IPv6 в пакеты IPv4, — это узел-отправитель по отношению к пакетам IPv4, она может получить сообщение протокола ICMP об ошибке, возникшей при передаче пакета IPv4 по сети. В некоторых случаях, в зависимости от типа сообщения, появляется необходимость передачи информации об ошибке узлу-отправителю вложенного пакета IPv6. Например, если сообщение ICMPv4 сигнализирует о превышении допустимого размера пакета, то система должна вести себя в соответствии со спецификацией определения максимального для маршрута IPv4 блока данных, который может быть отправлен по данному маршруту без фрагментации (Path MTU, PMTU). Т. е. необходимо зарегистрировать значение Path MTU для IPv4 и определить, следует ли генерировать информацию ICMPv6 о превышении размера пакета. Обработка других типов сообщений ICMPv4 зависит от того, какая часть пакета, вызвавшего ошибку, содержится в сообщении ICMP. В зависимости от реализации ICMP помимо внешнего заголовка IPv4 может быть передано либо 8, либо более начальных байт поля данных пакета, к которому относится это сообщение. Если оно содержит достаточно информации для реконструкции заголовка пакета IPv6, то инкапсулирующий узел может воспользоваться этими данными для составления сообщения ICMPv6 и отправки его узлу-источнику данного пакета IPv6.

Статические и динамические туннели
В зависимости от того, как инкапсулирующий узел определяет адрес IPv4 другой стороны туннеля, туннели делятся на два типа — статические и динамические.

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

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

Для автоматического построения туннеля необходимо, чтобы IPv6-адрес получателя относился к типу IPv4-совместимых (см. Рисунок 2).

Рисунок 2. Форматы адресов IPv6: а) IPv4-совместимый, б) IPv4-отображенный адреса.

Адреса такого типа присваиваются узлам, которые готовы к автоматическому туннелированию и могут принимать пакеты IPv6. Указанные пакеты должны инкапсулироваться в пакеты IPv4 с адресом назначения IPv4, содержащимся в совместимом с IPv4 адресе IPv6. Адрес IPv6, совместимый с IPv4, уникален, если в нем содержится уникальный в глобальном масштабе адрес IPv4. Интерфейс для автоматического туннелирования не считается подключенным к реальной физической сети: в частности, он не участвует в работе механизма автоматического нахождения соседей.

Узел IPv6/IPv4 может получить свой совместимый с IPv4 адрес IPv6, с использованием любого разрешенного механизма конфигурации адресов IPv4. Полученный адрес IPv4 используется для конфигурации интерфейса узла IPv4, а затем, при дополнении префиксом ::/96, становится IPv4-совместимым адресом устройства IPv6.

При автоматическом туннелировании адрес удаленного узла на противоположном конце туннеля определяется из последних 32 бит IPv4-совместимого адреса пакета. Если IPv6-адрес назначения пакета не является IPv4-совместимым, то такой пакет не может быть отправлен с помощью механизма автоматического туннелирования. Для того чтобы пакеты можно было направлять на интерфейс автоматического туннелирования, в таблицу маршрутизации можно занести маршрут с префиксом ::/96, поскольку все пакеты с IPv4-совместимыми адресами имеют такой префикс.

Рассмотрим, например, сеть, в которой имеется несколько узлов IPv6/IPv4, не разделенных маршрутизаторами IPv4/IPv6. Узлы могут быть сконфигурированы на использование автоматического туннелирования для взаимной передачи пакетов IPv6, а также настроены на удаленный маршрутизатор IPv6/IPv4, который также способен выполнять автоматическое туннелирование. Для обеспечения работы такой системы в таблицах маршрутизации узлов должно быть две записи: одна из них направляет все пакеты с префиксом ::/96, на автоматическое туннелирование, а вторая указывает маршрут по умолчанию ::/0 на удаленный маршрутизатор IPv6/IPv4. Пакеты IPv6, адресованные узлам IPv6, отправятся через удаленный маршрутизатор по статически сконфигурированному одностороннему туннелю, в то время как ответные пакеты будут переданы удаленным маршрутизатором с помощью автоматического туннелирования (см. Рисунок 3).

Рисунок 3. Схема использования автоматических туннелей.

(Окончание статьи, в котором рассмотрен механизм соединения сетей IPv6 через IPv4 (6-to-4) и подключение к Internet по IPv6 читайте в следующем выпуске...)

Игорь АЛЕКСЕЕВ (опубликовано в журнале сетевых решений "LAN" #07-08/2001).

По Сети стремительно начал распространяться новый вирус - Goner. Другое имя червя – Pentagon.

По сообщению "Лаборатории Касперского" червь распространяется в виде аттачмента к электронному письму. Именно так он был обнаружен, что называется, в диком виде всеми антивирусными компаниями. "Лаборатория Касперского" зафиксировала "несколько" случаев заражения вирусом Goner, компания Symantec сообщает об одной тысяче заражений на конец вторника. Почтовый сервис MessageLabs сообщает о 39 тысячах зараженных писем.

Червь распространяется в письме с заголовком "Hi". В теле письма содержится текст: "How are you ? When I saw this screen saver, I immediately thought about you. I am in a harry, I promise you will love it!" ("Как дела? Когда я увидел этот скринсйвер, я сразу подумал о тебе. Я спешу. Обещаю, тебе он понравится!").

Вложенный файл поименован как Gone.src. Для активизации червя пользователь должен самостоятельно раскрыть этот аттачмент. Червь функционирует только в среде Win32.

После инсталяции в систему червь рассылает себя по всем адресам из адресной книги Microsoft Outlook. Червь также пытается рассылать себя через популярный интернет-пейджер ICQ.

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

По сведениям компании Zone Labs, с функцией удаления файлов антивирусников червь справляется плохо. Так у антивирусного ПО ZoneAlarm вирусу удалось удалить только пользовательский интерфейс и "Help", основная же программа продолжала работать.

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

Помимо попыток уничтожения файлов антивирусных программ, Goner-Pentagon также запускает скрытое приложение, осуществляющее DoS-атаку на сервер twisted.ma.us.dal.net, вновь и вновь заходя на IRC-канал #pentagonex под разными случайными именами.

Интенсивность эпидемии этого червя, как и всех ему подобных, "Лаборатория Касперского" в своем отчете и компания "Symantec" в интервью CNet оценивают одинаково: в первые часы такие вирусы обычно начинают очень активно распространяться, в следующие 2-3 дня наблюдается заметный рост количества зараженных сообщений, затем начинается спад, после чего эпидемия полностью сходит на нет.

Антивирусные компании и интернет-СМИ не устают говорить о необходимости ни в коем случае не открывать аттачменты неизвестного происхождения, а тем более с двойным или исполняемым расширением. Однако пользователи очень быстро забывают уроки предыдущих эпидемий и снова и снова ведутся на нехитрые призывы посмотреть на "очень интересный скринсейвер". Однако информация о новой эпидемии быстро распространяется и пользователи вновь становятся аккуратнее.

Вирус Goner написан на языке Visual Basic 6 и представляет собой исполняемый файл размером около 38 килобайт. Червь упакован утилитой UPX.
(источник - http://www.netoscope.ru/, опубликовано 05.12.2001)

Эпидемия вируса W32/Badtrans.B, разразившаяся в конце ноября, но уже причинившая больший ущерб, чем такие вредоносные программы, как Sircam, Nimda и Aliz, для 15 пользователей Сети обернулась просто катастрофой.

Как любой саморассылающийся вирус, W32/Badtrans.B в случае успешного заражения рассылает собственные копии по всем почтовым адресам, хранящимся в списке контактов. Обычно в строке, указывающей отправителя, значится почтовый адрес владельца зараженного ПК, однако в тех случаях, когда это в силу каких-либо причин невозможно, в строке обратного адреса указывается один из 15 адресов, прописанных в программном коде самого вируса. Критерий, по которому отбирались эти реально существующие адреса, пока остается неясным, однако для их владельцев эпидемия стала настоящим бедствием.

Каждый день 15 пользователей интернета, в числе которых несколько американцев, швед, мексиканец и житель Таиланда, получают сотни писем от владельцев зараженных компьютеров с уведомлением о том, что вирус был направлен именно с их почтового адреса. Естественно, никто из этих лиц не имеют никакого отношения к данному вирусу, а некоторые из них, как стало известно, вообще используют компьютеры на платформе Macintosh, которые в принципе не могут быть заражены W32/Badtrans.B. Тем не менее, поток писем, зачастую содержащих оскорбительные высказывания, не иссякает.

Так, Джоанна Кастилло (Joanna Castillo) - программист Техасского университета с двадцатилетним стажем - вынуждена была сменить свой почтовый ящик, которым она пользовалась в течение восьми лет, после того, как в него пришло свыше 4000 писем, относящихся к новому вирусу. При этом г-жа Кастилло относится именно к числу владельцев ПК от Apple.

Несколько пострадавших от столь своеобразной категории спама уже заявили, что в случае, если создатель злополучного вируса будет обнаружен, они намерены обратиться в суд для компенсации причиненного ущерба.
(источник - http://www.cnews.ru/, опубликовано 05.12.2001)

Вместе с диском для консоли Sega можно приобрести вирус Kriz

Ведущий разработчик антивирусного программного обеспечения компания Sophos выступила с предупреждением, адресованным владельцам игровых консолей Sega Dreamcast. Как удалось обнаружить экспертам Sophos, все диски с ролевой игрой Atelier Marie, разработанной компанией Kool Kizz и продававшейся в основном на японском рынке, заражены вирусом Kriz.

В дикой форме этот вирус был впервые обнаружен в 1999 г. и по своим разрушительным функциям схож с нашумевшим тогда же CIH/Chernobyl. Этот вирус способен поражать только Windows-системы, поэтому для консолей он не представляет опасности, однако поскольку, помимо самой игры, на дисках поставляются скринсейверы для ПК, вероятность заражения существует.

По заявлению Kool Kizz, все диски, содержащие вирус, были отозваны.
(источник - http://www.cnews.ru/, опубликовано 04.12.2001)

Один из ведущих провайдеров услуг управления сетевыми сервисами (MSP), компания MessageLabs, осуществляющая поддержку популярного сервиса проверки электронных писем на наличие вирусов SkyScan AV, опубликовала статистические данные по наиболее популярным вирусам ноября, претендующие на то, чтобы стать сенсацией.

В течение минувшего месяца сервисами MessageLabs было зафиксировано 170 510 электронных писем, зараженных вирусом W32/Badtrans.B, об эпидемии которого CNews.ru сообщал ранее. Таким образом, W32/Badtrans.B больше чем в три раза опередил по популярности нашумевший минувшим летом SirCam, которым в ноябре оказались заражены 52 179 писем. Еще одно недавнее "приобретение" интернета - вирус Nimda.E - занял в данном рейтинге только восьмое место с 1631 заражениями.

Впрочем, как заявляют эксперты MessageLabs электронная почта - далеко не единственное средство распространения вредоносных программ, поэтому реальные показатели заражений, а также популярность некоторых вирусов, в действительности могут отличаться от объявленных результатов.
(источник - http://www.cnews.ru/, опубликовано 04.11.2001)

В понедельник продавцы дистрибутивов операционной системы Linux распространили среди своих клиентов информацию о дыре, обнаруженной в самой распространенной программе FTP-сервера WU-FTPd. Степень угрозы оценена специалистами как высокая. Дыра позволяет злоумышленникам получать доступ к управлению сервером, - сообщает Security Focus.

Обнаружена она была в середине ноября аргентинской исследовательской группой Core Security Technologies, которая информировала об этом производителей Linux и open-source-ресурсы, поддерживающие и распространяющие WU-FTPd. Правительственная информационная служба компьютерной безопасности CERT предприняла попытку скоординировать одновременный выпуск производителями программного обеспечения патчей для обнаруженной дыры. Этот выпуск был запланирован на 3 декабря. Раньше этого срока продавцам и производителям не рекомендовалось оповещать общественность о баге.

Однако производитель самой распространенной версии (дистрибутива) Linux Red Hat на прошлой неделе во вторник не выдержал. Red Hat изготовил свой патч и опубликовал предупреждение. Остальные производители, не успевшие изготовить заплатку, оказались в большей уязвимости и вынуждены были доделывать патч в срочном порядке. Национальный центр защиты инфраструктуры ФБР NIPC на следующий день выпустил специальное предупреждение об опасности хакерских проникновений через обнаруженную дыру.

Производители крайне отрицательно отнеслись к поступку Red Hat. Представители Linux-сообщества, особенно специалисты по безопасности, также в массе своей не одобрили преждевременное разглашение информации о дыре.

Red Hat ночью того же дня принесла публичные извинения перед прочими производителями и продавцами. Произошедшее компания называет ошибкой. Патч был готов и ждал назначенного времени (3 декабря). Однако веб-адмистратор случайно включил его в материалы для публикации вместе с другими обновлениями.

В большинстве своем linux-сообщество нормально относится к координации выхода патчей. Аналогичные устремления Microsoft, наоборот, вызывают крайнее раздражение пользователей и специалистов по безопасности.
(источник - http://www.netoscope.ru/, опубликовано 03.12.2001)

Интернет общественность сильно обеспокоена новыми возможностями поисковой системы Google. Несколько недель назад Google запустил новый поисковый сервис, который позволяет находить не только HTML-документы, но и файлы форматов Adobe PostScript; Lotus 1-2-3 и WordPro; MacWrite; Microsoft Excel, PowerPoint, Word, Works и Write; а также .rtf. После запуска этой системы владельцы многих сайтов обнаружили, что в результатах поиска Google стали появляться документы, содержащие явно конфиденциальные данные, в частности пароли.

По мнению основателя и руководителя компании Internet Security Systems Кристофера Клауса (Christopher Klaus), проблема не нова. Еще на заре развития поисковых систем в AltaVista, например, можно было набрать "password" и получить массу всевозможных паролей. С появлением продвинутых возможностей Google ситуация качественно изменилась. Порграммы-пауки этой поисковой системы стали проникать гораздо глубже обычного веб-контента, иногда преодолевая не слишком сложные средства защиты от несанкционированного доступа.

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

Кроме этого, эксперты по безопасности опасаются, что пользование поиском среди файлов разных форматов, может повысить угрозу вирусного заражения компьютера. Например, документы Microsoft Office, открытые в "своей" программе могут заразить компьютер макровирусами. Пользуясь Google, этой опасности можно избежать, выбрав опцию просмотра документов в HTML-формате "View HTML".
(источник - http://www.cnews.ru/, опубликовано 30.11.2001)

DoS-атаки, несомненно, являются одним из наиболее распространенных инструментов хакеров. Подобным способом в разное время были выведены из строя серверы Белого Дома США, газеты New York Times, центра сетевой безопасности CERN и многих интернет-магазинов. По данным Калифорнийского университета в Сан-Диего (США), каждые пять минут в мире происходит две DoS-атаки. Однако мало кто из неспециалистов знает, что у любого пользователя Сети давно есть возможность испытать на своем компьютере или сервере все прелести "отказа в обслуживании".

такую возможность, в частности, предоставляет сайт "Виртуальный самоубийца", на страницах которого можно выбрать любой из множества алгоритмов DoS-атак и запустить его против своего компьютера или межсетевого экрана для выхода в интернет. В числе доступных для "самоубийства" средств представлены Jolt2, Smurf, Teardrop, Vapourization, WinNuke, Bonk, Nestea, Newtear, Syndrop и Targa.

Владельцы данного сайта заявляют, что с его помощью можно проверить уровень защищенности вашей системы от DoS-атак. Однако, прежде чем спешить ставить эксперименты над своим компьютером, стоит как следует подумать. Испытателей предупреждают, что "данная атака может нанести ущерб вашей машине и, возможно, повредит некоторые из файлов на системном диске. Вы можете сломать свой винчестер".

Однако в случае неудачного исхода теста владельцы "Виртуального самоубийцы" за порчу вашего компьютера ответственности нести не будут, о чем сразу же предупреждают всех посетителей сайта, а объясняться с руководством компании, если эксперимент проходил на работе, придется вам самим.
(источник - http://www.cnews.ru/, опубликовано 28.11.2001)

Компания Инфотекс приняла участие в семинаре "Информационная безопасность в корпоративных сетях", организованным ассоциацией "Бизнес-защита" в Новосибирске.

Семинар был посвящен современным технологиям обеспечения информационной безопасности корпоративных сетей организаций. На семинаре рассматривались вопросы, касающиеся межсетевых экранов, систем обнаружения атак, систем анализа защищенности, систем построения VPN и совсем недавно появившихся на рынке России систем анализа содержания (Web, e-mail). С докладами выступили специалисты Регионального Учебно-научного центра по проблемам информационной безопасности при НГТУ, ассоциации "Бизнес-Защита", представители ведущего в Сибири интегратора систем информациионной безопасности "Технической Испытательной Лаборатории" и других IT-компаний.

Интерес у участников семинара вызвал доклад специалиста компании Инфотекс Геннадия Басова "Основные подходы компании Инфотекс к вопросам концепции и организации защиты информационных сетевых ресурсов" и рассмотренные им варианты комплексных решений проблемы безопасности в Интернет на базе технологии ViPNet.

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

Приглашаем принять участие в семинаре, проводимом компанией Инфотекс в рамках партнерской программы с Информационной системой оптовой торговли ИСОТ: "Создание защищенных телекоммуникаций для корпораций, дистрибьюторских и партнерских сетей ".

Вопросы семинара:

Сетевые решения ViPNet - инструмент для повышения эффективности бизнеса.
- Информация о компании Инфотекс
- Лицензии и сертификаты, выданные компании
- Клиенты, партнеры и проекты компании
- Технология VPN компании Инфотекс

Продуктовый ряд ViPNet
- Выгоды от использования технологии ViPNet
- Стратегия продвижения решений ViPNet
- Технология ViPNet.
- Драйвер ViPNet - основа защищенной сети
- Основные модули комплекса
- Основные функции
- Основные режимы работы
- Интерфейсы и сервисы программы
- "Деловая почта" - защищенный документооборот

ГУП "Москачество" - пример внедрения технологии ViPNet.
- О компании ГУП "Москачество"
- Проблемы безопасности информационных ресурсов.
- Характеристики внедренного ViPNet-решения
- Бизнес- выгоды от внедрения ViPNet- решения

Семинар состоится 19 декабря.
О месте проведения семинара будет объявлено позднее.

Чтобы принять участие в семинаре необходимо зарегистрироваться. Форма для регистрации находится здесь.
Вопросы по семинару просьба отправлять Головкиной Ирине.

Полнофункциональные демо-версии продуктов ViPNet Desk, TermiNet, ViPNet Office, ViPNet Tunnel находятся по адресу 
http://www.infotecs.ru/demo.htm

Если у вас есть какие-нибудь пожелания или вопросы по поводу дальнейших выпусков рассылки, мы с удовольствием рассмотрим их.