- •2. Основы межсетевого обмена в сетях tcp/ip
- •2.1. Структура стека протоколов tcp/ip
- •2.2. Основные протоколы стека tcp/ip
- •2.2.1. Протоколы slip и ppp
- •2.2.2. Протокол arp. Отображение канального уровня на уровень межсетевого обмена
- •2.2.3. Протокол ip
- •2.8. Формат пакета Ipv4
- •2.2.4. IPing - новое поколение протоколов ip
- •2.2.6. User Datagram Protocol - udp
- •2.2.7. Transfer Control Protocol - tcp
- •2.3. Принципы построения ip-адресов
- •2.4. Подсети
- •2.5. Порты и сокеты
- •2.6. Основные принципы ip-маршрутизации
- •2.7. Настройка операционной системы и сетевые интерфейсы
- •2.8. Настройка сетевых интерфейсов
- •2.8.1. Настройка Ethernet-интерфейса
- •2.8.2. Настройка slip
- •2.8.3. Настройка интерфейса ppp
- •2.9. Маршрутизация, протоколы динамической маршрутизации, средства управления маршрутами
- •2.9.1. Статическая маршрутизация
- •2.9.2. Динамическая маршрутизация
- •2.9.3. Программа routed
- •2.9.4. Программа gated
- •2.10 Анализ и фильтрация tcp/ip пакетов
- •3. Информационные сервисы Internet
- •3.1. Система Доменных Имен
- •3.1.1. Принципы организации dns
- •3.1.2. Bind (Berkeley Internet Name Domain)
- •3.1.3. Регистрация доменных имен
- •3.1.4. Серверы доменных имен и механизм поиска ip-адреса
- •3.1.5. Настройка resolver
- •3.1.6. Программа named
- •3.1.6.1. Файлы настройки named
- •3.1.6.2. Запись "Start Of Authority"
- •3.1.6.3. Запись "Name Server"
- •3.1.6.4. Адресная запись "Address"
- •3.1.6.5. Запись Mail eXchanger
- •3.1.6.6. Запись назначения синонима каноническому имени "Canonical Name"
- •3.1.6.7. Записи типа "Pointer"
- •3.1.6.8. Запись типа hinfo
- •3.1.6.9. Запись определения информационных сервисов "Well Known Services"
- •3.1.6.10. Команды описания зоны
- •3.1.6.11. Файлы описания зоны
- •3.1.7. Примеры настроек программы named и описания зон
- •3.1.7.1. Небольшой поддомен в домене ru
- •3.1.7.2. Описание "прямой" и "обратной" зон для поддомена определенного на двух подсетях
- •3.1.7.3. Делегирование поддомена внутри домена
- •3.1.8. Программа nslookup
- •3.1.9. Dns и безопасность
- •3.2. Электронная почта в Internet
- •3.2.1. Принципы организации
- •3.2.2. Формат почтового сообщения (rfc-822)
- •3.2.3. Формат представления почтовых сообщений mime и его влияние на информационные технологии Internet
- •3.2.3.1. Поле версии mime (mime-Version)
- •3.2.3.2. Поле типа содержания тела почтового сообщения (Content-Type)
- •3.2.3.3. Поле типа кодирования почтового сообщения (Content-Transfer-Encoding)
- •3.2.3.4. Дополнительные необязательные поля
- •3.2.4. Протокол обмена почтой smtp (Simple Mail Transfer Protocol)
- •3.2.5. Интерфейс Eudora
- •3.2.6. Системы почтовой рассылки (программа sendmail)
- •3.2.6.1. Принцип работы программы sendmail
- •3.2.7. Настройка программы sendmail
- •3.2.7.1. Тестирование Sendmail и способы запуска
- •3.3. Эмуляция удаленного терминала. Удаленный доступ к ресурсам сети
- •3.3.1. Протокол Telnet
- •3.3.2. Интерфейс пользователя (telnet) и демон (telnetd)
- •3.3.2.1. Программа-сервер (telnetd)
- •3.3.2.2. Программа-клиент (telnet)
- •3.3.3. Организация модемных пулов, настройка оборудования. Квоты пользователей
- •3.4. Обмен файлами. Служба архивов ftp
- •3.4.1. Типы информационных ресурсов
- •3.4.2. Протокол ftp
- •3.4.3. Сервер протокола - программа ftpd
3.1.9. Dns и безопасность
В сентябре 1996 года многие компьютерные издания Москвы опубликовали материал, в котором рассматривался случай подмены доменных адресов World Wide Web сервера агенства InfoART, что привело к тому, что подписчики этого сервиса в течении некоторого времени вместо страниц этого агенста просматривали картинки "для взрослых".
Администрирование DNS осуществляла компания Demos, поэтому пресс-конферению по поводу этого случая Demos и InfoArt проводили совместно. Разъяснения провайдера главным образом свелись к тому, что в базе данных DNS самого Demos никаких изменений не проводилось, а за состояние баз данных secondary серверов Demos ответственности не несет. Почему такое заявление вполне оправдывает провайдера?
Как было указано раньше, обслуживание запросов на получение IP-адресов по доменным именам, а именно об этом идет речь в случае InfoArt, осуществляется не одним сервером доменных имен, а множеством серверов. Все secondary серверы копируют базу данных с primary сервера, но делают они это с достаточно большими интервалами, иногда не чаще одного раза в двое суток. Запрос разрешает тот сервер, который быстрее откликается на запрос клиента. Таким образом, если подправить информацию на secondary сервере о базе данных primary сервера, то можно действительно на время между копированиями описания зоны заставить пользователей смотреть совсем не то, что нужно. Таким образом, практически все провайдеры попадают в категорию неблагонадежных. Но провайдеры также могут оказаться не при чем. В принципе, любой администратор может запустить у себя на машине named и скопировать зону с primary сервера, не регистрируя ее в центре управления сетью. Это обычная практика, т.к. разрешение имен - главный тормоз при доступе к удаленной машине, и часто по timeout прерывается работа с ресурсом из-за невозможности быстрого разрешения имени. Таким образом, все администраторы сети попадают в потенциальных злоумышленников. Но на самом деле существуют еще и другие способы. Например, кэш re-solver или сервера имен. Если время хранения записи в кэше большое, то сервер или resolver не будут обращаться к удаленному серверу вообще, а будут брать записи из кэша. Вмешаться в структуру данных кэша также возможно, а это значит, что можно и увеличить время хранения записи. Если организация- подписчик пользуется для доступа в сеть proxy-сервером, а это также обычная практика, то достаточно поправить кэш этого proxy и все пользователи этой организации будут ходить туда, куда их направит поправленная запись.
Существует несколько способов ограничения этого произвола. Первый из них - это точное знание IP-адресов ресурсов. В этом случае можно проверить состояние ресурса и выявить причину ошибки. Второй сопособ, запретить копировать описание зоны кому не поподя. Современные программы named позволяют описывать IP-адреса сетей, из которых можно копировать зоны. Правда такая политика должна быть согласована с другими владельцами зоны, в противном случае зону скопируют с secondary сервера. И наиболее мягкое средство - уменьшение времени хранения записей в кэше.
Для защиты можно использовать и фильтрацию пакетов. Зоны раздаются только по 53 порту TCP, в отличии от простых запросов. Если определить правила работы по этому порту, используя межсетевой фильтр, то можно и ограничить произвол при копировании информации с сервера доменных имен. Вообще, не стоит относиться к сервиру доменных имен легкомысленно. Следует учитывать тот факт, что используя этот сервис, можно выявить структуру вашей локальной сети.