Безопасность маршрутизаторов Cisco

Маршрутизатор — это «первая линия обороны» нашей корпоративной сети непосредственно соприкасающаяся с Internet. Они часто применяются в качестве ключевых элементов в системах защиты сетей (например, firewall для фильтрации пакетов и ограничения прохождения определенного IP -трафика). Наиболее широко распространенным сейчас является оборудование фирмы Cisco Systems, которое благодаря различной реализации своей «фирменной» операционной системы Cisco IOS может приобретать свойства, необходимые администраторам.

А как его (маршрутизатор Cisco) защитить?

Список команд

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

Используйте Чтобы
enable secret Задать пароль для привилегированного доступа.
service password-encryption Обеспечить минимальную защиту для паролей в конфигурации.
no service tcp-small-servers
no service udp-small-servers
Избегать использования простых сервисов для DoS и других атак.
no service finger Избегать распространения информации о пользователях.
no cdp runningno cdp enable Избегать распространения информации об этом маршрутизаторе на соседние устройства.
ntp disable Предотвратить атаки на сервис NTP.
no ip directed-broadcast Помешать атакующим использовать маршрутизатор для smurf атак.
transport input Указать какие протоколы могут быть использованы удаленными пользователями чтобы войти через VTY или получить доступ к его TTY портам.
ip access-class Указать с каких IP адресов пользователи могут подключаться к TTYs или VTYs. Зарезервировать один VTY для доступа с рабочей станции администратора.
exec-timeout Не занимать VTY бесконечно долго бездействующей сессией.
service tcp-keepalives-in Обнаруживать и удалять «зависшие» сесии, освобождая используемые VTY.
logging buffered buffer-size Сохранять логируемые данные в буфере оперативной памяти маршрутизатора. В последних версиях IOS этот размер может идти совместно с параметром urgency threshold.
ip access-group list in Отбрасывать пакеты с поддельным IP адресом. Отбрасывать входящиеICMP redirects.
ip verify unicast rpf Отбрасывать IP пакеты в с поддельным адресом источника в случае симметричной маршрутизации на маршуризаторах поддерживающих CISCO Express Forwarding (CEF). Данная проверка известна как reverse path forwarding (RPF).
no ip source-route Отбрасывать IP пакеты, в которых включена опция source routing. Таким образом злоумышленник не получит обратно ответ на посланный пакет, если он использовал поддельный IP адрес.
access-list number action criteria log
access-list number action criteria log-input
Включить логирование пакетов удовлетворяющих определенному условию из access-list. Используйте log-input если это возможно в версии вашего IOS.
scheduler-intervalscheduler allocate Защититься от флуда и позволить работать важным процессам.
ip route 0.0.0.0 0.0.0.0 null 0 255 Быстро удалять пакеты посланные на несуществующие адреса.
distribute-list list in Фильтровать получаемую информацию о маршрутах чтобы предовратить использование неверных маршрутов.
snmp-server community something-inobvious ro listsnmp-server community something-inobvious rw list Включить SNMP версии 1, настроить аутентификацию и разрешить доступ только с некорых IP адресов. Используйте SNMP версии 1 только, если версия 2 недоступна. Следите за наличием снифферов в сети. Включите SNMP только если он нужен в вашей сети. Не настраивайте доступ на запись, если он вам не нужен.
snmp-server party…
authentication md5 secret …
Сконфигурировать аутентификацию посредством MD5 для SNMP версии 2. Включайте SNMP только, если он нужен в вашей сети.
ip http authentication method Производить аутентификацию соединений по HTTP (если вы включили HTTP сервер на вашем маршрутизаторе).
ip http access-class list Дальнейшее управление доступом к HTTP серверу, разрешая его только с некоторых хостов (если вы включили HTTP сервер на вашем маршрутизаторе).
banner login Установить предупреждающее сообщение для показа всем пользователям, кто пытается залогиниться на маршрутизатор.

Заметки по увеличению безопасности маршрутизатора Cisco

Cпособы повышения защищенности маршрутизаторов CISCO

Пароли

Пароли (и другие секреты, например SNMP последовательности) обеспечивают защиту от НСД маршрутизатора. Наилучший путь для работы с базой данных паролей — хранить их на аутентификационных серверах типа RADIUS или TACACS+. Однако в большинстве случаев на каждом маршрутизаторе остаются пароли для привилегированного доступа и другие пароли.

enable secret
Данная команда используется для установки паролей, которые предоставляют привилегированный доступ администратору в IOS. Данный пароль должен быть всегда установлен. Нельзя устанавливать enable password , т.к. данная команда использует слабую криптографию.

service password-encryption
Данная команда позволяет зашифровать пароли, CHAP секреты и другие данные, находящиеся в конфигурационном файле.

 

Контроль доступа

Доступ к маршрутизатору предполагает возможность переконфигурирования его, в том числе и несанкционированному. Поэтому проблема защиты от НСД при доступе имеет большое значение.

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

Основной способ доступа 
Существует достаточное количество способов для подключения к маршрутизатору. CISCO IOS в зависимости от конфигурации поддерживает соединения посредством telnet, rlogin, SSH, LAT, MOP, X.29, V.120. Локальные асинхронные терминалы и модемы используют стандартные линии — TTY. Удаленные сетевые соединения (независимые от протоколов) используют виртуальные TTY (VTY). Для защиты необходимо на все линии доступа установить пароли, для VTY возможна команда no password для защиты.

По умолчанию удаленный пользователь может установить соединение с TTY через сеть, так называемый «reverse Telnet», что позволяет данному пользователю работать с модемом или терминалом, подсоединенным к данному TTY. Для защиты необходимо работать с командой transport input none , которая запрещает принимать соединения из сети. Если есть возможность , то необходимо разнести dial-in и dial-out модемы и запретить использование reverse Telnet для линий, которые используются в dial-in.

Управляющий VTY
Любые VTY должны быть сконфигурированы для того, чтобы принимать соединения только по протоколам, которые нужны. Это можно сделать с помощью команды — transport input. Например, по VTY ожидается прием только сессии telnet, для этого используем команду transport input telnet. Для поддержки telnet и SSH необходимо ввести команду transprot input telnet ssh. Также можно ограничить доступ с определенных адресов с помощью ip access-class.

В СISCO IOS используется ограниченное количество VTY (обычно пять). Когда все VTY используются, больше никто подсоединиться не может. В этом и есть возможность использования DoS атаки. Способ защиты — ограничить доступ с помощью ip access-class. Например, для одного VTY используется общий доступ, а для четырех — только с одной рабочей станции.

Также можно использовать команду exec-timeout для ограничения времени атаки.

Можно использовать команду для TCP keepalive входящих соединений service tcp-keepalive-in для защиты от атак на хосты.

Желательно отключить возможность использования отличных от IP протоколов для доступа к VTY.

Предупреждающий баннер
Для предупреждения возможности несанкционированного доступа к системе целесообразно использовать ограничивающие (предупреждающие) заголовки. Данные заголовки можно сконфигурировать с помощью banner login.

 

Плохо сконфигурированные сервисы управления

Многие пользователи управляют маршрутизаторами с помощью специальных протоколов, например, HTTP или SNMP.

SNMP

Данный протокол широко используется для мониторинга и управления маршрутизаторами. К сожалению, версия 1 данного протокола использует очень слабую схему аутентификации, базирующуюся на «community string», при которой пароль может передаваться в открытом виде. Поэтому необходимо использовать версию 2 , которая работает с алгоритмом MD5 и не передает пароль по каналам связи.

Если все-таки необходимо использовать версию 1, то необходимо быть внимательным при выборе community string (нельзя использовать public или private). Необходимо избегать использования одних и тех же community string для различных устройств. Если возможно, то установить для periodic SNMP ver 1 polling в read-only community string.

Для версии 1 необходимо использовать ACL на команде snmp-server community для ограничения доступа на станции управления. Нельзя использовать команду snmp-server community в окружении, где используется версия 2 (переключает в версию 1).

Для версии 2 необходимо сконфигурировать защиту с помощью команд authentication и md5 в конфигурации snmp-server party. Если возможно, то лучше использовать различные секреты MD5 для каждого маршрутизатора.

HTTP
Для облегчения конфигурирования маршрутизатора есть возможность «поднять» на нем HTTP сервер. Пароль передается в открытом виде.

Для защиты необходимо ограничить перечень IP-адресов путем ip http access-class. Также можно использовать аутентификацию с использованием команд ip http authentication.

 

Управление и доступ через Интернет (или другие незащищенные сети)

Многие пользователи управляют своими маршрутизаторами удаленно, и часто через Интернет. Все схемы удаленного управления подвержены атакам, например, Packet Sniffers. Злоумышленники очень часто взламывают машины ISP или другие компьютеры в Сети и устанавливают программы-сниферы, которые мониторят весь трафик, пытаясь заполучить парольную фразу (если используется telnet, HTTP, snmp v.1). Защита — использование технологии S\Key, Kerberos, RADIUS, TACACS+. Для выявления сниферов можно использовать: http://www.l0pht.com/antisniff

 

Логировние

Способы ведения логов в CISCO

  • AAA logging — ведение записей о пользователях , которые подключаются.
  • SNMP trap logging — посылка данных об изменениях в системном статусе.
  • system logging — записывает огромное множество событий: logging console logging ip-address, logging trap logging monitor, termonal monitor logging buffered

Сохранение информации 
По умолчанию логируемая информация отсылается только на асинхронный консольный порт.

Почти все маршрутизаторы сохраняют информацию logging в local RAM buffer, имеющий конечный размер ( show memory, logging buffered buffer-size).

Также можно сохранять данные на syslog сервер, logging server ip-address, logging trap urgency.

Если маршрутизатор имеет real-time clock или запущен NTP, то можно записать лог с time-stamp — service timestamps log datetime msecs.

Запись нарушений списков доступа
Если используются списки доступа для ограничения трафика, есть возможность записи их нарушений. Команды — в старых версиях — log, в новых — log-input.

 

Защита IP-маршрутизации

Anti-spoofing
Множество сетевых атак проводятся с подмененными IP-адресами источника атаки, что снижает риск для атакующего быть замеченным.

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

Защита с помощью ACL
К сожалению, нет общих примеров по конфигурации ACL, каждый раз поход различный. Однако основа одна: отбросить пакет, который пришел с интерфейса, с которого данный адрес прийти не может. Например, система имеет два интерфейса, один из них смотрит в сеть Интернет, а другой в сеть Интранет. Все пакеты, принятые из сети Интернет с адресами источника внутренней сети (адреса Интранет), будут отброшены. Если CPU позволяет, то anti-spoofing должен быть включен на каждом интерфейсе.

Пример:

Anti-spoofing with RPF checks
Практически во всех CISCO IOS , которые поддерживают CISCO Express Forwarding (CEF), существует возможность «заставить» маршрутизатор проверять source address каждого пакета. Это будет работать только в случае, если маршрутизация симметричная. Если сеть будет построена так, что путь трафика от хоста А до хоста В будет проходить другим путем, чем трафик от B до A, проверка всегда будет давать неверный результат, и связь между хостами будет невозможна. Данная асимметричная маршрутизация обычно используется на Internet core. Данная проверка известна как reverse path forwarding (RPF) и включается с помощью команды ip verify unicast rpf.

Controlling Directed Broadcasts
Для атаки типа «smurf» обычно используется IP directed broadcasts.

IP directed broadcast — это пакет, который посылается на адрес broadcast подсети, к которой посылающая машина напрямую не подключена. Directed broadcast маршрутизируется через сеть как обыкновенный пакет unicast пока не достигнет подсети назначения, где и будет конвертирована в link-layer broadcast. Согласно архитектуре протокола IP только последний маршрутизатор в цепочке, тот который напрямую подсоединен к подсети-назначения, может идентифицировать directed broadcast.

При атаке типа «smurf» атакующий посылает пакеты ICMP echo requests, используя сфальсифицированный адрес источника, и все хосты подсети отвечают на подмененный адрес источника.

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

На интерфейсе маршрутизатора CISCO для защиты можно использовать команду no ip directed-broadcast, при этом необходимо сконфигурировать no ip directed-broadcast на каждом интерфейсе каждого маршрутизатора, который может быть подсоединен к подсети назначения.

http://users.quadrunner.com/chuegen/smurf.cgi

Path Integrity
Много атак проводятся с помощью обмана маршрутизации. Если злоумышленник контролирует маршрутизацию, он может переслать трафик куда угодно, подменить адрес источника и т.п.

IP Source Routing
Протокол IP поддерживает опцию source routing, которая позволяет отправителю IP-пакета контролировать путь пакета до получателя. Ранние реализации IP отрабатывали пакеты source-routed неправильно, что могло в результате посылки на нее пакета с опцией source routing привести в зависанию машины.

Маршрутизаторы CISCO с установкой no ip source-route не будут пересылать пакеты IP, в которые будет включена опция source routing.

ICMP Redirects
Сообщение ICMP redirect «заставляет» конечное СВТ использовать указанный маршрутизатор для достижения определенной точки в сети. В нормально функционирующей сети маршрутизатор посылает пакеты redirects только хостам, расположенным в локальной подсети, ни один конечный узел не посылает данные пакеты, и ни один такой пакет не проходит больше одного сетевого hop. Однако атакующий может обойти эти правила . Хорошая идея -отфильтровать входящие ICMP redirects на входящем интерфейсе любого маршрутизатора, находящегося на границе между административными доменами.

Необходимо отметить, что данное фильтрование защищает от атак redirect , которые начинаются удаленными злоумышленниками.

Routing Protocol Filtering and Authentication
Если используется динамическая маршрутизация, которая использует аутентификацию, то ее необходимо использовать. Это позволяет избежать проблемы подмены данных маршрутизации.

В части ISP или других больших сетях целесообразно использовать фильтрацию протоколов маршрутизации с использованием команды distribute-list in. Например, если вы используете динамическую маршрутизацию для связи с пользовательской «stub» сетью, вам не нужно принимать данные об обновлении маршрута с данной сети.

 

Защита от флуда

Множество атак типа «Отказ в обслуживании» (DoS) основаны на пересылке бесполезных пакетов. Данные действия занимают полосу пропускания, снижают время ответа хостов и могут привести к перезагрузке маршрутизаторов.

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

Транзитный флуд
Существует возможность использования CISCO’s quality of service (QoS) для защиты хостов от данных атак. Можно использовать — weighted fair queueing (WFQ). WFQ устанавливается по умолчанию для низкоскоростных линий во многих версия ОС. Также можно использовать committed access rate (CAR), generalized traffic shaping (GTS) и custom queuing.

Если планируется использовать QoS для контроля трафика, очень важно понимать, как это работает. Например, WFQ более эффективен против floods, чем против SYN floods, потому что обычный ping flood для WFQ является одиночным трафиком, а для SYN flood каждый пакет является отдельным потоком.

CISCO обеспечивает два различных способа уменьшить опасность от атаки типа SYN flooding. Способ «TCP Intercept» используется в маршрутизаторах модели 4000 или выше. Например, CISCO IOS Firewall Feature Set включает различные способы защиты от SYN flood.

Самозащита маршрутизатора
Прежде всего необходимо защитить сам маршрутизатор от атак и после этого необходимо защищать хосты, стоящие после него. Switching Modes and CISCO Express Forwarding

Режим — CEF switching mode, являющийся доступным в версиях ПО 11.1CC, 11.1CT, 11.2GS, и 12.0. Позволяет быстрее переключать трафик, чем обычная маршрутизация.

Хотя многие атаки типа DoS пересылают все пакеты на один или несколько хостов, много атак типа SYN flooding используют изменяющийся адрес источника. Хост, который атакуют, отвечает на SYN flood пакеты, создавая трафик с различными адресами destinations. При этом рекомендуется использовать CEF.

Scheduler Configuration
Когда маршрутизатор CISCO находится в режиме fast-switching большого количества пакетов, есть возможность его «загрузить» только работой на ответ , другая работа не будет проводиться. Данный эффект может быть снижен путем использования команды scheduler interval. Типичная конфигурация использует команду scheduler interval 500, которая показывает , что задача будет выполняться каждые 500 milliseconds.

Новые платформы фирмы CISCO используют команду scheduler allocate вместо команды scheduler interval.

 

Возможно ненужные сервисы

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

TCP and UDP «Small Services»
По умолчанию CISCO, начиная с версии 11.3, поднимает «small services»: echo, chargen и discard. Данные сервисы , особенно их UDP версии, могут использоваться для DoS атаки на маршрутизатор.

Например, атакующий может послать DNS пакеты с подмененным адресом источника DNS сервера и портом (53). Если данные пакеты будут направлены на порт CISCO’s UDP echo port, то маршрутизатор будет посылать DNS пакеты на сервер с вопросом. Ни один ACL не будет это отслеживать.

Для отключения необходимо использовать команду no service tcp-small-servers и no service udp-small-servers.

Finger
Маршрутизатор CISCO обеспечивает сервис «finger», который позволяет уточнить, кто подключен из пользователей. Отключается командой no service finger.

NTP
Network Time Protocol (NTP) не является опасным сервисом, но любые не нужные сервисы потенциально опасны. Для отключения используйте команду no ntp enable.

CDP
CISCO Discovery Protocol (CDP) используется для обмена данными между устройствами CISCO. Отключение производится командой no cdp running. CDP может быть поднят на каком-то из интерфейсов, отключение — по команде no cdp enable.

 

Cisco IPSec over ADSL

Задача: две точки подключенные к ADSL, на одной установлена Cisco 26xx, на другой Zyxel ZyWALL, надо было их связать в одну сеть.

Решил я это сделать по средствам VPN IPSec, но столкнулся с проблемами. Дело в том, что Cisco смотрит в сторону провайдера через спутниковый канал, а ADSL нужен только для того чтобы связать две точки. Вот в этом то и заключалась проблема, решение и описание проблемы я раскрою чуть ниже в конфигурации.

Конфигурация:

Конфигурация IPSEC типовая

Интерфейс в сторону локальной сети

Интерфейс в сторону спутникового модема

Интерфейс DSL

Бриджовый интерфейс для ATM0/3/0, IPSEC туннель вешается именно на него

По идее ACL располагаются в конфигурации чуть ниже маршрутов, но так будет удобней

ACL 102 задает политику обмена пакетами, в нем надо указать из какой сети в какую пакеты будут ходить в IPSEC туннеле, короче указываем обе LAN сетки обоих точек, source должна быть та которая терминируется на Cisco, а destination LAN сетка которая терминируется на ZyWall.

А сейчас начнется самое интересное 🙂

У нас есть default маршрут в сторону спутникового канала

А так же маршрут, который говорит что наш IPSEC peer находится за сетью СТК

Вроде все настроено, но пакеты не ходят, туннель не инициируется даже по первой фазе IKE.

Оказывается, чтоб туннель заработал надо создать фэйковый маршрут который говорит что сетка второго офиса находится за шлюзом ADSL

Добавляем:

Оказывается, чтобы туннель поднялся надо пустить трафик который соответствует политике прохождения трафика, короче пустить пинг из локалки первого офиса в локалку второго (ACL 102).

Прозрачное проксирование с помощью netfilter, iproute2, ipchains и squid

Этот раздел написал Рэм Нарул (Ram Narula), из «Internet for Education» (Таиланд).

Прозрачное проксирование — это обычное перенаправление серверу squid трафика, отправляемого на порт 80 (web).

Существует 3 общеизвестных способа такого перенаправления:

Шлюз.
Вы можете настроить шлюз таким образом, что он будет перенапрвлять все пакеты, адресованные на порт 80, сереверу squid

НО

Это увеличит нагрузку на шлюз. Кроме того, некоторые коммерческие роутеры не поддерживают такую возможность.

Layer 4 switch
Свичи выполняют такое перенаправление без особых проблем.

НО

Стоимость этого оборудования очень высока и может быть сопоставима с ценой связки «обычный роутер» + «Linux-сервер»

Использовать кэш-сервер в качестве шлюза.
Вы можете отправить ВЕСЬ трафик через кэш-сервер.

НО

Это довольно рисковано, поскольку squid довольно значительно нагружает CPU, что может привести к снижению производительности сети. Кроме того, squid может «рухнуть» и тогда никто из сети не сможет выйти в Интернет.

Мы предлагаем 4-й вариант:
Linux+NetFilter.
Эта методика предполагает установку меток на пакеты, с портом назначения равным числу 80, и дальнейшая маршрутизация помеченных пакетов, с помощью iproute2, на squid.

|—————-|
| Реализация |
|—————-|

Используемые адреса
10.0.0.1 naret (NetFilter)
10.0.0.2 silom (Squid)
10.0.0.3 donmuang (Router, соединенный с Интернет)
10.0.0.4 kaosarn (некий сервер в сети)
10.0.0.5 RAS
10.0.0.0/24 main network
10.0.0.0/19 total network

|—————|
|Структура сети |
|—————|

Internet
|
donmuang
|
————hub/switch———-
| | | |
naret silom kaosarn RAS etc.

Прежде всего — весь трафик должен идти через naret, для этого на всех компьютерах пропишем его в качестве шлюза по-умолчанию. Исключение составляет silom, для которого шлюз по-умолчанию — donmuang (в противном случае web-трафик зациклится).
(на всех компьютерах в моей сети был прописан шлюз по-умолчанию — 10.0.0.1, который ранее принадлежал donmuang, поэтому я изменил IP-адрес у donmuang на 10.0.0.3, а серверу naret присвоил адрес 10.0.0.1)

Silom
——
-настройка squid и ipchains

Настройте прокси-сервер squid на silom. Убедитесь, что он поддерживает прозрачное проксирование. Обычно прокси-серверу, для приема запросов от пользователей, назначают порт 3128, поэтому весь трафик, отправляемый на порт 80 будет перенаправлен на порт 3128. С помощью ipchains это делают следующие правила:
silom# ipchains -N allow1
silom# ipchains -A allow1 -p TCP -s 10.0.0.0/19 -d 0/0 80 -j REDIRECT 3128
silom# ipchains -I input -j allow1

iptables:
silom# iptables -t nat -A PREROUTING -i eth0 -p tcp —dport 80 -j REDIRECT —to-port 3128

За информацией по настройке сервера squid, обращайтесь на http://squid.nlanr.net/.
Убедитесь, что на этом сервере разрешен форвардинг, и заданный по умолчанию шлюз для него — donmuang (НЕ naret!).

Naret
——
-настройка iptables и iproute2
-запрет ICMP-сообщений о перенаправлении (если необходимо)

Пометить пакеты, с портом назначения 80, числовой меткой 2.

naret# iptables -A PREROUTING -i eth0 -t mangle -p tcp —dport 80 \
-j MARK —set-mark 2

Настроить маршрутизацию так, чтобы помеченные пакеты отправлялись на silom

naret# echo 202 www.out >> /etc/iproute2/rt_tables
naret# ip rule add fwmark 2 table www.out
naret# ip route add default via 10.0.0.2 dev eth0 table www.out
naret# ip route flush cache

Если donmuang и naret находятся в одной подсети, то naret не должен выдавать ICMP-сообщения о перенаправлении. Запрет можно наложить так:
naret# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

На этом настройку можно считать завершенной. Проверим конфигурацию

Для naret:

naret# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp — anywhere anywhere tcp dpt:www MARK set 0x2

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

naret# ip rule ls
0: from all lookup local
32765: from all fwmark 2 lookup www.out
32766: from all lookup main
32767: from all lookup default

naret# ip route list table www.out
default via 203.114.224.8 dev eth0

naret# ip route
10.0.0.1 dev eth0 scope link
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 10.0.0.3 dev eth0

|——-|
|-КОНЕЦ-|
|——-|

15.5.1. Схема движения пакетов после настройки.

|——————————————|
| Схема движения пакетов |
|——————————————|

ИНТЕРНЕТ
/\
||
\/
———————donmuang————————
/\ /\ ||
|| || ||
|| \/ ||
naret silom ||
*destination port 80 ================>(cache) ||
/\ || ||
|| \/ \/
\\===================================kaosarn, RAS, и пр.

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

Для web/http трафика:

kaosarn http request->naret->silom->donmuang->internet
http replies from Internet->donmuang->silom->kaosarn

Для прочего трафика:
kaosarn outgoing data->naret->donmuang->internet
incoming data from Internet->donmuang->kaosarn

http://docstore.mik.ua/manuals/ru/LARTC/x2540.html

Решение проблемы с Path MTU Discovery путем настройки MTU/MSS

Общеизвестно, что скорость передачи данных возрастает с увеличением размера пакета. Это вполне естественно, ведь для каждого пакета в потоке принимается решение о выборе маршрута. К примеру, файл, размером в 1 мегабайт, будет передан быстрее, если он будет разбит на 700 пакетов (при максимальном размере пакета), а не на 4000.

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

Процесс поиска такого размера называется ‘Path MTU Discovery’ (Поиск Максимального Размера Пакета для выбранного Пути), где MTU означает ‘Maximum Transfer Unit’ (Максимальный Размер Блока передачи данных).

Когда на маршрутизатор поступает пакет, который не может быть передан по выбранному маршруту целиком (без фрагментации) И у него установлен флаг «Don’t Fragment» (Не фрагментировать), то в ответ отправляется ICMP-сообщение о том, что пакет был сброшен из-за невозможности «протолкнуть» его по выбранному маршруту. Компьютер, выполнивший посылку, начинает последовательно уменьшать размер пакетов до тех пор, пока они не смогут быть переданы по выбранному маршруту.

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

В результате таких действий процесс поиска оптимального размера пакета работает все хуже и хуже, а на некоторых маршрутизаторах вообще не работает, что в свою очередь порождает сеансы TCP/IP с весьма странным поведением, которые «умирают» спустя некоторое время.

Хотя у меня нет никаких доказательств, но я знаю по крайней мере два сайта, с которыми наблюдается подобная проблема и перед обоими стоит Alteon Acedirectors — возможно кто-то имеет более богатый опыт и сможет подсказать как и почему это происходит.

15.6.1. Решение

Если вы столкнетесь с подобной проблемой, то можно посоветовать отключить ‘Path MTU Discovery’ и установить MTU вручную. Koos van den Hout пишет:

У меня возникла следующая проблема: для арендованного мною канала, работающего через ppp, на скорости 33.6К, я установил величину MTU/MRU, равную 296. Это дает мне достаточно приемлемое время отклика.

Со моей стороны установлен роутер (с маскарадингом), работающий под управлением Linux.

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

После этого возникла масса проблем с авторизацией в irc. В процессе длительных поисков я установил, что само соединение проходит и даже показывается системой как ‘connected’, но я не получал motd от irc (motd — от англ. Message of The Day, которое демонстрируется после успешной авторизации, прим. перев.). Кроме того, помятуя о проблеме, связанной с MTU, я определил, что проблема исчезала только в том случае, когда MTU устанавливался равным 296. А так как серверы irc блокируют весь трафик, который напрямую не связан с их работой, то в числе блокируемых оказался и ICMP.

Мне удалось убедить администратора WEB-сервера в истинных причинах возникновения проблем, но администратор IRC-сервера отказался устранять их.

Таким образом, передо мной встала необходимость уменьшить MTU для внешнего трафика и оставить нормальное значение для локального.

Решение:

(10.0.0.1 — шлюз по-умолчанию, внутренний адрес маршрутизатора с маскарадингом)
Вообще, можно запретить ‘PMTU Discovery’ путем настройки специфических маршрутов. Например, если проблемы наблюдаются только с определенной подсетью, то это должно помочь:

Как уже говорилось выше, Path MTU Discovery не работает в Интернет должным образом. Если вам известны факты существования сегментов в вашей сети, где размер MTU ограничен, то вы уже не можете полагаться на безотказную работу Path MTU Discovery.

Однако, помимо MTU, есть еще один способ ограничения размера пакета — это, так называемый MSS (Maximum Segment Size — Максимальный Размер Сегмента). MSS — это поле в заголовке TCP-пакета SYN.

С недавних пор, ядра Linux и некоторые драйверы PPPoE, стали поддерживать такую особенность, как ‘clamp the MSS’ (ограничение размера MSS).

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

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

Чтобы иметь возможность манипулировать размером сегмента, у вас должны быть установлены iptables, не ниже 1.2.1a и ядро Linux, не ниже 2.4.3. Основная команда iptables:

Она рассчитает правильный MSS для вашего соединения. Если вы достаточно уверены в себе и в своих знаниях, можете попробовать нечто подобное:

Это правило устанавливает MSS равным 128. Очень полезно, если вы наблюдаете разрывы при передаче голосовых данных, когда поток небольших пакетов VoIP прерывается «огромными» http-пакетами.

OSPF+Zebra

Пожалуйста, дайте мне знать — насколько верна следующая информация, а так же присылайте ваши предложения, комментарии. Zebra — большой программный пакет динамической маршрутизации, который разработали Кунихиро Ишигуро (Kunihiro Ishiguro), Тошиаки Такеда (Toshiaki Takada) и Ясахиро Охара (Yasuhiro Ohara). С помощью Zebra вы легко и быстро сможете настроить OSPF, но на практике, при настройке протокола под весьма специфические потребности, вы столкнетесь со значительным числом параметров. Ниже приводятся некоторые из характеристик протокола OSPF:

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

Быстрая сходимость
Алгоритм поиска кратчайшего пути (SPF) обеспечивает быструю сходимость, а отсюда и более быстрый, в сравнении с протоколом RIP, выбор маршрута.

Эффективное использование пропускной способности
Использование групповых сообщений, вместо широковещательных, предотвращает «затопление» информацией о маршрутах посторонних узлов сети, которые могут быть не заинтересованы в получении этих сведений, что значительно снижает нагрузку на каналы связи. Кроме того, Внутренние Маршрутизаторы (т.е. те, которые не имеют интерфейсов за пределами своей области) не обладают информацией о маршрутах в других областях, за счет чего так же достигается уменьшение трафика маршрутизации. Роутеры, имеющие несколько интерфейсов в более чем одной области, называются Пограничными Маршрутизаторами (Area Border Routers), они поддерживают отдельные топологические базы данных для каждой из областей, с которыми соединены.

Ресурсоемкость
Протокол OSPF основан на алгоритме Shortest Path First, предложенном Е.В.Дейкстрой (E.W.Dijkstra), который требует больших вычислительных затрат, нежели иные алгоритмы маршрутизации. Но в действительности он не так уж и плох, поскольку кратчайший маршрут рассчитывается только в пределах одной области, причем для сетей малого и среднего размеров — это вообще не проблема, так что вы не будете даже обращать внимания на это обстоятельство.

Состояние маршрута
OSPF представляет собой протокол состояния маршрута. В качестве метрик используются — пропускная способность, надежность и стоимость.

Открытость и наличие программного обеспечения под GPL.
OSPF — это открытый протокол, а Zebra выпускается под GPL, что дает дополнительные преимущества перед проприетарными протоколами и программными продуктами.

Предварительные условия

Ядро Linux:
Собранное с CONFIG_NETLINK_DEV и CONFIG_IP_MULTICAST (я не вполне уверен, возможно требуется еще что-то)

Iproute
Zebra
Пакет может входить в состав вашего дистрибутива. Если нет, обращайтесь на http://www.zebra.org/.

Конфигурирование

Рассмотрим конфигурирование Zebra на примере сети:

Пусть вас не пугает эта схема — дело в том, что большую часть работы Zebra выполнит самостоятельно и вам не потребуется вручную «поднимать» все маршруты. Самое главное, что вы должны уяснить из этой схемы — это топология сети. И особое внимание обратите на область 0 (area 0), как самую важную часть. Для начала сконфигурируем zebra под свои потребности (поправим файл zebra.conf):

В дистрибутиве Debian, кроме того необходимо подредактировать файл /etc/zebra/daemons, чтобы обеспечить запуск демонов во время загрузки системы.

Затем нужно внести соответствующие изменения в ospfd.conf (для случая IPv4) или в ospf6d.conf (для случая IPv6). Мой ospfd.conf выглядит так:

Здесь размещены инструкции, описывающие топологию сети.Запуск Zebra

Теперь запустим Zebra. Сделать это можно вручную — дав прямую команду zebra -d, либо с помощью сценария начальной загрузки — /etc/init.d/zebra start. После запуска, в журнале ospfd.log, появятся строки, примерно с таким содержанием:

Не обращайте внимания на строки «…SMUX_CLOSE…», поскольку они относятся к SNMP и не представляют интереса для нас. Из приведенного листинга видно, что 192.168.0.1 — это Выделенный Маршрутизатор (Designated Router), а 192.168.0.2 —Резервный Выделенный Маршрутизатор (Backup Designated Router).

И zebra, и ospfd допускают возможность интерактивного взаимодействия с ними через telnet:

Попробуем посмотреть список установленных маршрутов, залогировавшись в zebra:

или напрямую, с помощью iproute:

Отсюда видно, что zebra добавила ряд маршрутов, которых в таблице раньше не было. Новые маршруты появляются спустя несколько секунд после того, как были запущены zebra и ospfd. Теперь вы можете попробовать ping-ануть некоторые из узлов сети.Zebra выставляет маршруты автоматически, все что от вас требуется — прописать маршрутизаторы в конфигурационный файл и этого будет достаточно!

Для захвата и анализа OSPF-пакетов можно воспользоваться командой:

где число 89 — это номер протокола OSPF, а 9 — это номер октета в ip-заголовке, где хранится номер протокола.

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