Тысяча мелочей

ЕЩЕ ОДНА ПОДСКАЗКА

Я прочитал заметку Константина Пьянзина про настройки подсказки UNIX (см. раздел "Тысяча мелочей" в мартовском номере LAN за этот год). Все правильно, за исключением того, что этот вариант не будет работать в случае применения команд rsh или su. Более надежным решением было бы:

export PS1="`whoami`@h:w>"

При этом (при неизменном окружении) вам всегда будут показаны реальное имя, хост и каталог.

БАТАЛИИ ВОКРУГ МОДЕМОВ НА 56 Кбит/с

В феврале 1997 г. ITU одобрил стандарт для модемов на 56 Кбит/с и присвоил ему обозначение V.90. Таким образом, ITU дал производителям зеленый свет на разработку модемов на 56 Кбит/с.

Отметка 33,6 Кбит/с рассматривалась поначалу как потолок для модемов. Основное техническое затруднение состояло в том, что на своем пути от модема к получателю данные подвергались двум преобразованиям - из аналогового в цифровой вид, и обратно. Так, сигнал от модема передается по телефонной линии в аналоговом виде, пока он не попадет в телефонную систему оператора связи. Затем, после прохождения через телефонную систему, цифровой сигнал преобразуется обратно в аналоговый вид для передачи по обычной телефонной линии его адресату.

Проблема в том, что при преобразованиях из аналогового в цифровой вид сигнал теряет часть информации вследствие шумов дискретизации, в результате - и то при наилучших условиях - сигнал ограничен 33,6 Кбит/с.

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

В этом случае сигнал не подвергается преобразованию из аналоговой в цифровую форму, поэтому при наилучших условиях данная модель позволяет достичь скорости в 56 Кбит/с. Передаваемые пользователем данные должны тем не менее преобразовываться из аналогового в цифровой вид, когда они достигают общедоступной телефонной сети, так что в этом направлении скорость по-прежнему ограничена 33,6 Кбит/с. Однако при работе в Web скорость загрузки обычно гораздо важней скорости доступа.

Проблема с новой моделью в том, что две предложенные технологии на 56 Кбит/с - одна, 56Kflex, была разработана Lucent Technologies и Rockwell, а другая, X2, - U.S. Robotics - не совместимы между собой. Так что если пользователи хотят иметь скорость в 56 Кбит/с, то их модем должен использовать ту же технологию, что и модем их сервис-провайдера.

Осознавая опасность такой ситуации, ITU постаралась найти выход. В феврале 1998 года эта организация отобрала технические спецификации для модемов на 56 Кбит/с и инициировала процедуру формального одобрения. По информации ITU новый стандарт V.90 должен быть принят не позднее сентября 1998 года.

С появлением стандарта V.90 производители начали предлагать обновления для своих X2- и 56Kflex-совместимых модемов с целью приведения их в соответствие с новым стандартом.

ИСПОЛЬЗОВАНИЕ МАРШРУТИЗАТОРОВ ДЛЯ ЗАЩИТЫ СЕТИ

Документ RFC 2267 описывает один из способов предотвращения компьютерных атак с использованием TCP/IP: фильтрацию пакетов с поддельными IP-адресами отправителя. Здесь мы познакомимся с RFC 2267 и предлагаемым там решением.

Опубликованный в январе этого года документ был написан Полом Фергюсоном из Cisco Systems и Дэниелом Сени из BlazeNet. Данный RFC не является стандартом Internet, скорее он предлагает способ предотвращения атак по типу "отказ в обслуживании", когда сеть или компьютер перестают отвечать на запросы.

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

RFC напоминает, что о существовании таких атак известно было относительно давно и что защита против них оставалась "постоянной заботой". По сути RFC 2267 адресован провайдерам Internet и тем администраторам сетей, кто отвечает за подключение корпоративных сетей к Internet; он призывает их тщательно фильтровать IP-трафик и передавать только те пакеты, чей IP-адрес подтверждается их таблицами маршрутизации.

Как написано в RFC, "если провайдер Internet агрегирует объявления о маршрутах для нескольких обслуживаемых им сетей, то трафик, чей источник лежит якобы за пределами этих блоков адресов, должен фильтроваться".

В результате атакующий в какой-либо из этих сетей не будет иметь возможности передать пакет с неизвестным адресом отправителя. Как указывается в RFC, эта стратегия не способна предотвратить атаки, где в качестве адреса отправителя используется действительный IP-адрес.

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

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

RFC призывает к повсеместной полной реализации такой фильтрации, так как "долгом каждого администратора является предотвращение возможности организации атаки из его сети".

Ознакомиться с RFC можно по адресу: http://ds.internic.net/rfc/rfc2267.txt.

NDS FOR NT И WINDOWS 95

Комментарий редактора. Данная заметка является откликом на статью об NDS для NT (смотри статью Ли Че "Управление смешанной сетью NetWare и Windows NT" в предыдущем номере). NDS for NT позволяет интегрировать информацию о сетевых бюджетах Windows NT в каталог NDS и обеспечивает централизованное управление смешанными сетями NetWare и Windows NT.

В статье, в частности, говорится, что для изменений, добавлений и удалений в Windows NT автору пришлось использовать административную программу NetWare, выполняющуюся на контроллере домена Windows NT (NWAdminNT). Воспользоваться же NWAdmin95, стандартную административную консоль для сетей NetWare, не удалось. В данной заметке автор рассказывает, как это затруднение можно обойти.

Я занимался установкой NDS for NT в юридическом колледже в Стенфорде. Объектами NDS for NT можно управлять с рабочей станции Windows 95, хотя эта возможность и не очевидна. Если вы используете NWAdmin95, то скопируйте файлы IWSAM.DLL и IWSAM.REG в каталог PUBLICWIN95. Затем дважды щелкнув на файле IWSAM.REG, вы можете добавить ключ в реестр Windows 95, в результате чего операционная система узнает о существовании IWSAM.DLL. Теперь вы получаете возможность администрировать объекты NDS с этого конкретного компьютера под Windows 95 с помощью NWAdmin95.

Лично я использую административную программу для Windows NT, потому что она более стабильна. Однако, насколько я могу судить, использование файла IWSAM.REG и NWAdmin95 дает те же результаты, что и работа с NWAdminNT под Windows NT. Я не ставил перед собой задачи полномасштабного тестирования NWAdmin95 - все, что я сделал, это создал несколько групп и пользователей. Однако никаких проблем при выполнении этих операций

у меня не возникло, а кроме того, все привычные функции были по-прежнему доступны и в NWAdmin95. Обычно я запускаю NWAdminNT с рабочей станции Windows 95, так что опыт работы в такой конфигурации у меня достаточно обширный, и никаких затруднений или никаких ограничений в плане функциональных возможностей я выявить не смог.

Novell проявила большой интерес к нашему опыту работы с NetWare в целом и с NDS for NT в частности. Она даже прикрепила к нам сотрудницу отдела технической поддержки, к которой мы могли обращаться напрямую. Я рассказал ей о моем решении, и она никак не могла поверить, что никаких побочных эффектов не возникло.

ИСПРАВЛЕНИЯ В LDAP

В начале этого года IETF представила новую спецификацию упрощенного протокола доступа к каталогу (Lightweight Directory Access Protocol, LDAP). Эта спецификация модифицирует LDAP-2 и определяет LDAP-3, который, как надеются разработчики, станет универсальным решением для служб каталогов.

Вследствие гетерогенной природы современных компьютерных сетей системным инженерам приходится иметь дело со множеством приложений и операционных систем. В попытке централизовать службу каталогов исследователи из мичиганского университета разработали LDAP, ведущий свое происхождение от X.500.

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

Проблема с LDAP и с его наследником LDAP-2 в том, что клиент LDAP (или каталог LDAP) может корректно взаимодействовать с каталогом LDAP, только если он уже знаком с конкретной схемой этого каталога. Другими словами, клиент должен знать, каким образом организован каталог. Это условие серьезно подрывает универсальность LDAP.

LDAP-3, определяемый в RFC 2251, решает данную проблему за счет того, что он предусматривает для клиента или каталога возможность запрашивать у каталога LDAP-3 его схему. Благодаря этому LDAP-3 может передавать информацию о своей схеме другому каталогу или клиенту.

Помимо определения схемы LDAP-3 включает также набор символов ISO 10646. Это позволяет поддерживать и символы других языков помимо английского. Наконец, LDAP-3 дает рекомендации по расширению своего протокола, так что разработчики могут без проблем создавать расширения к LDAP.

На момент написания этой заметки стандарт LDAP еще не получил формального одобрения. С RFC вы можете познакомиться по адресу: http://ds.intenic.net/rfc/rfc2251.txt.

УВАЖАЕМЫЕ ЧИТАТЕЛИ!

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