"Черна дупка" 192.0.2.0/24 в мрежата на Софийския Университет "Св. Климент Охридски"

Веселин Колев, Софийски Университет "Св. Климент Охридски"

Съдържание:

Какво е предназначението на "черна дупка" 192.0.2.0/24

Пример за нуждата от използване на 192.0.2.0/24

1. Увод

Софийският Университет "Св. Климент Охридски", в рамките на мероприятията по подобряване на сигурността на своето и локалното българско интернет пространство, стартира проект за "черна дупка" 192.0.2.0/24. Терминацията на трафика към тази мрежа се извършва на сървър на Университета. Префиксът се излъчва към партньорите за локална свързаност на СУ.

Специалистите от направление "Мрежи и комуникации" се ангажират с безпристрастното и надеждно терминиране на паразитния трафик, без да използват ролята си в ущърб на друг субект в интернет пространството.

2. Какво е предназначението на "черна дупка" 192.0.2.0/24

"Черната дупка" 192.0.2.0-192.0.2.255 е мрежови сегмент със специално предназначние описан в RFC3330. Той няма единен "origin" в глобалната BGP таблица. Възможно е излъчването му с origin стойност на най-различни автономни системи ("anycast"). Предишното приложение на сегмента е било за тестови цели, но напоследък той все повече се използва за мрежа, към която се насочва и терминира паразитен трафик.

По принцип не би следвало префиксът 192.0.2.0/24 да бъде приеман за обработка от BGP софтуера, използван върху граничните маршрутизатори на автономните системи (без значение дали оператор на автономната система е транзитен доставчик или краен потребител). Освен това всеки пакет насочен към хост от сегмента 192.0.2.0-192.0.2.255, би следвало да бъде отхвърлен/терминиран със съответното ICMP съобщение. Най-често тази добра практика не се разбира и не се прилага или ако се прилага, приложението в много от случаите е неадекватно.

Неприлагането на добрата практика води до изпускане на трафик за 192.0.2.0-192.0.2.255 извън автономната система на транзита или крайния потребител. Проблемът обаче не е толкова в изпускането, а в това че някой злонамерен субект може да оперира с този трафик в ущърб на услугите на изпращача (виж раздел 3). Повечето оператори на автономни системи разчитат на това, че никой техен съсед няма да им обяви в BGP сесиите префикса 192.0.2.0/24. Съществува обаче случай, при който въпреки, че няма обявяване на префикса 192.0.2.0/24 в BGP, трафик за 192.0.2.0-192.0.2.255 може да бъде изнесен извън автономната система. Най-често това се наблюдава при излъчването в BGP на префикса 0.0.0.0/0 и то при префиксния обмен между автономни системи (eBGP). Казано с други думи, дадена автономна система се обявява за първоизточник на цялото IPv4 пространство и все едно дали съседните автономни системи приемат или не BGP префикс 192.0.2.0/24 - винаги ще има транзит на трафик към 192.0.2.0-192.0.2.255 и свързаните с това рискове за услугите на крайните потребители.

Неадекватното прилагане на филтрацията за префикса 192.0.2.0/24 се състои в следното. Предполагаме, че даден доставчик не приема върху своите гранични маршрутизатори префиксите 0.0.0.0/0 и 192.0.2.0/24 с origin друга автономна система, а при опит за изпращане на пакет към 192.0.2.0-192.0.2.255 съответния граничен маршрутизатор връща подходящо ICMP съобщение за недостижимост. Повечето доставчици обаче имат вътрешна структура от маршрутизатори и техните клиенти биват включвани в мрежата към маршрутизатор, който е надолу в йерархията и който не получава пълната BGP таблица. След като той не получава пълната BGP таблица, получава префикса 0.0.0.0/0, който се излъчва навътре в автономната система от някои от граничните маршрутизатори за изцяло вътрешни цели (забележете: излъчването на 0.0.0.0/0 в рамките на една автономна система рядко е проблем - проблем е излъчването на 0.0.0.0/0 в BGP сесиите между различни автономни системи). По този начин, пакетите за 192.0.2.0-192.0.2.255 няма да бъдат терминирани върху първия след излъчвателя-клиент маршрутизатор, а ще преминат през цялата вътрешна система за маршрутизация на доставчика и процес на терминация ще има чак върху граничните маршрутизатори. Така последните ще поемат за обслужване по-голямо количество паразитен трафик, в сравнение в случая, в който той е терминиран на по-долно ниво в йерархията на маршрутизацията по дадено направление. Подобна ситуация може да създаде излишен товар върху маршрутизаторите и да влоши качеството на маршрутизация на полезния трафик (и особено интерактивния).

Как "черната дупка" се справя с насочения към нея паразитен трафик? Черната дупка приема и унищожава пакетите за адресното пространство 192.0.2.0-192.0.2.255, без да ги обслужва на приложен слой (под обслужване на приложен слой се разбира насочването на инструкциите от пакета към някаква специфична услуга: SMTP, DNS, HTTP и др). Върху процеса на терминацията влияят два фактора: (i) мястото на черната дупка в мрежовата топология и (ii) физическия капацитет на използвания за унищожаването на пакетите хардуер.

(i) Топологичният фактор се изразява в следното. За да може терминирането да бъде ефективно, от гледна точка на използваните мрежови ресурси, дупката би следвало да се намира максимално близо до източника на паразитен трафик. В противен случай ще се получи запълване на канала към Интернет на нейния оператор и/или ще се натовари излишно процеса на маршрутизация (преди всичко глобално) с транзитирането на неполезен трафик. Колкото по-далеч от източника е дупката (в метричност на брой транзитни автономни системи), толкова повече други източници на паразитен трафик ще "вижда" тя и толкова по-големи пакетни потоци ще бъдат насочвани към нея. Следователно е изключително важно дадена черна дупка за 192.0.2.0-192.0.2.255 да не бъде сама в далечна околност на интернет пространството.

(ii) Физическият капацитет на сървъра, който ще терминира паразитния трафик към 192.0.2.0-192.0.2.255, би следвало да е такъв, че за всеки унищожен пакет да се генерира ICMP съобщение (примерно "Network Unreachable" или "Host Unreachable"). Изпращането на ICMP съобщения към изпращача на унищожения пакет влияе благоприятно върху терминирането на заявки за TCP сесии и особено за терминиране на запитванията към DNS сървъри, разположени в 192.0.2.0-192.0.2.255, защото на питащият сървър за имена не му се налага да изчаква указаното в DNS протокола време, за да обяви запитването за провалено (както би станало, ако не се върне ICMP съобщение за недостижимост). Поради високия интензитет на генериране на ICMP съобщения, става ясно, че е препоръчително "черната дупка" да се реализира върху самостоятелен сървър, а не чрез правило в пакетния филтър на маршрутизатор за отхвърлянето на пакети към 192.0.2.0-192.0.2.255. Ако стека на маршрутизатора се занимава с генериране на ICMP съобщения за всеки пакет от паразитния трафик, това би влошило качеството на маршрутизацията. Дори обаче пакетите да се терминират мълчаливо, без генериране на ICMP съобщения, това също е допълнителен товар за маршрутизатора и отново ще има споменатото влошаване на качеството.

Каква е ползата от насочване на паразитния трафик за 192.0.2.0-192.0.2.255 към мрежата на Софийския Университет и кой печели от това? Ако даден субект в българското интернет пространство желае да терминира споменатия паразитен трафик при себе си, това е добре дошло и за него и за Университета, защото субекта не ангажира свои и университетски ресурси, а освен това проявява разбиране по проблемите на паразитния трафик. Възможни са обаче и случаи, в които субекта има разбиране за проблема, но по някаква причина не може да терминира при себе си паразитния трафик за 192.0.2.0-192.0.2.255. В този случай той има възможността да го изпраща за унищожаване в мрежовата инфраструктура на СУ, като така се снижава риска от злонамереното използване на трафика. Същото може да се каже и за тези, които не разбират важността за терминиране на паразитния трафик - той пак ще бъде терминиран на сигурно място. Университетът печели от това, защото обучава върху действащо решение своите младши специалисти по мрежи и комуникации, а освен това допринася за общата сигурност на услугите в българското интернет пространство, част от което е и университетската мрежа.

3. Пример за нуждата от използване на 192.0.2.0/24

Показателният пример по-долу е свързан с възможни проблеми от използването на домейни, предназначени за описание на източници на SPAM, но вече изведени от употреба. Най-често срещаният случай към момента е за домейните:

Предназначението на подобни домейни е да бъдат "черни" списъци на SPAM излъчватели (DNSBL). Те се използват от сървърския софтуер за електронна поща, с цел отхвърляне на писма, които са изпратени от адрес, който е описани в зона на DNSBL домейн. Всеки сървър за поща, който използва подобна анти-SPAM защита, има свой списък с DNSBL домейни, който най-често се съставя от администратора на сървъра.

Домейнът uceb.org и неговите поддомейни, са били използвани за DNSBL, но в момента са закрити (виж съобщението на адрес http://www.anti-abuse.org/rbl-blackholesuceborg-no-longer-online/ за повече подробности). За съжаление, огромна част от сървърския софтуер за електронна поща, все още използва този ресурс. По същия начин, поддомейна dynablock.njabl.org е с прекратена функционалност, но независимо от това все още се използва (за повече подробности виж http://njabl.org/dynablock.html).

Защо след като домейнът uceb.org е закрит, все още има заявки за извличане на записи от зоната му и тази на негови поддомейни? Причината е, че регистрацията му в регистъра на TLD ORG изтича на 21 март 2010 г. (виж whois информацията за домейна). За да го направят неоперативен, при условие, че е още активен, администриращите домейна са посочили за негови делегиращи сървъри за имена такива, с IP адреси в сегмента 192.0.2.0-192.0.2.255. Идеята е, че по този начин заявките за извличане на записи от зоната на домейна, ще попаднат в най-близката "черна дупка" до излъчилия ги и няма да натоварват излишно системата за имена в Интернет.

При dynablock.njabl.org нещата стоят малко по-различно. В този случай няма как просто да се премахне зоната на домейна. При съществуващата честота на запитванията, подобно премахване няма да донесе желания положителен ефект, защото дори dynablock.njabl.org да не съществува повече, njabl.org съществува и всички заявки за несъществуващия домейн, вследствие на йерархичното търсене в DNS, ще пристигат за обслужване върху сървърите за имена на съществуващия домейн. Това ще доведе до напълно излишен товар, който ще влоши производителността на сървърите за имена за използваемите поддомейни на njabl.org и оттам ще намали скоростта на обработка на потока електронна поща от страна на анти-SPAM филтрите (последните разчитат на информацията от споменатите поддомейни). За да не се получи подобно претоварване, операторите на зоната на dynablock.njabl.org не са я заличили, а са декларирали за нея такива сървъри за имена (делегиращи NS записи), които имат IP адреси в 192.0.2.0-192.0.2.255. По този начин заявките за извличане на записи от зоната ще стигат в най-близката "черна дупка" до клиента и няма да влияят върху производителността на обслужването на записи за други поддомейни на njabl.org. От казаното следва интуитивно, че NS записите за dynablock.njabl.org и самата зона, би трябвало да се поддържат дотогава, докато домейна njabl.org съществува. Строго погледнато, подобно твърдение не е съвсем коректно. Причината да има запитвания към dynablock.njabl.org е широкото използване на домейна в анти-SPAM софтуера, в комбинация с липсата на механизъм, по който операторите на зоната да кажат на всички използващи го, че той повече не е функционираща (не обслужва DNSBL). Разбира се, че с времето този софтуер ще се подменя, което ще води до актуализиране на конфигурациите му и зоната на домейна dynablock.njabl.org няма да се използва повече. За съжаление, подобен процес е твърде разтеглен във времето (причините за това са комплексни). Следователно трябва да бъде намерен начин за проверка на активността по използването на домейна, който да подскаже на операторите на njabl.org, кога е дошло времето за премахване на зоната dynablock.njabl.org. Един възможен начин е получаването на обратна връзка от операторите на черни дупки за 192.0.2.0-192.0.2.255 за броя заявки към dynablock.njabl.org, но чисто организационно това не е възможно. Друг начин е на определени периоди от време, NS записите за dynablock.njabl.org да се насочват към специални съвъри за имена, които не са част от черна дупка и така да се оценява глобалния трафик към този домейн. В случай, че трафикът е все още значителен, NS записите отново се насочват към хост в 192.0.2.0-192.0.2.255. Ако обаче периодичните тестове показват спадане на броя заявки към dynablock.njabl.org до стойности, които няма да влияят забележивмо върху натоварването на сървърите за имена на njabl.org, зоната и делегиращите записи могат да се заличат.

От казаното дотук привидно следва, че ако не е налична мрежа от черни дупки 192.0.2.0-192.0.2.255, проблеми могат да възникнат единствено и само от големия брой заявки към сървърите за имена на домейни, като посочените по-горе. В най-лошия случай, това би довело до непредумишлена DDoS атака на някои сървъри за имена и оттам на анти-SPAM филтрите. Наистина, такъв проблем съществува, но реалната опасност за анти-SPAM услугите идва от друго място. Нека си представим, че някой злоумишлено излъчва префикса 192.0.2.0/24 в маршрутната таблица и обслужва DNS трафика, насочен към 192.0.2.0-192.0.2.255, върху свои сървъри за имена. Тогава този някой може да саботира анти-SPAM защитата на някои сървъри за поща така, че те да започнат отхвърлянето на всички идващи писма, сякаш са изпратени от източник на SPAM и по този начин да се обезмисли услугата електронна поща! За целта е достатъчно върху споменатите сървъри за имена да бъдат изградени зони за DNSBL домейните, чиито трафик се терминира в 192.0.2.0-192.0.2.255 и в тях да бъде създаден "wildcard" A запис, сочещ към 127.0.0.X (X=1,2,...). Важно е да се отбележи какъв би бил периметърът на поражения в резултат от подобен саботаж. Саботажът би засегнал всички сървъри за електронна поща, които използват все още неактуални зони на DNSBL домейни, трафика за които се терминира в сегмента 192.0.2.0-192.0.2.255 при саботьора. При това, всичко зависи от маршрутизацията на трафика, излъчен от този сървър за имена, информацията от който потенциално уязвимите пощенските сървъри получават през библиотеката на резолвера в операционната система. Ако поразен от саботажа доставчик използва централен кеширащ сървър и трафика от него за сървърите за имена в 192.0.2.0-192.0.2.255 попадне при саботьора, уязвими ще бъдат всички пощенски сървъри, които са DNS клиенти на този сървър и използват излезли от употреба DNSBL домейни.

Как да се предпазят сървърите за имена и използващите ги анти-SPAM услуги от такъв саботаж? Разбира се, най-правилният и лесен начин е изобщо да не се използват зоните на излезли от употреба DNSBL домейни за анти-SPAM филтрация. За съжаление практиката показва, че само малка част от администраторите на сървъри за поща проявяват нужното внимание и извършват актуализация на използваните от тях DNSBL зони на домейни. Следователно единственият приложим начин е да се осигури такава маршрутизация и унищожаване на пакетите към 192.0.2.0-192.0.2.255, че саботаж като описания да бъде малко вероятен.