ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Архивные статьи в категории ‘Networks’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

10 декабря прошел очередной (уже 11-ый) пиринговый форум MSK-IX и я снова был одним из участников данного форума.

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

Чтобы я хотел отметить так это «BGP: к лучшему протоколу и практикам. Неформальная рабочая группа.» в которой я поучаствовал.

В рамках беседы обсуждалась проблема с которой многие уже сталкивались, а именно bgp route leaks. Проблема которая периодически возникает по вине новичков. Тех кто настраивает BGP впервые и зачастую не читая какой либо документации, а лишь какую либо статью на просторах тырнета. Так же снова обсуждался проект MANRS (Mutually Agreed Norms for Routing Security) и звучали призывы присоединиться к данному проекту.


 

Mutually Agreed Norms for Routing Security (MANRS)

Mutually Agreed Norms for Routing Security (MANRS)

Данный проект преследует цели объединения IT сферы в соблюдении простых правил:

  • Filtering: Предотвращение распространения неправильной маршрутной информации
  • Anti-spoofing: Предотвращение трафика с подложными IP-адресами
  • Coordination: Содержание контактной и иной информации в up-to-date
  • Global Validation: Улучшение информационного обмена и координации между сетевыми операторами в глобальном масштабе

Соблюдение провайдерами и их пользователями данных правил позволит сократить многие проблемы, как то DDoS или BGP route leaks.

Автор проекта Андрей Робачевский уверен в том, что чем больше организаций поучаствуют в данном проекте, подпишутся под MANRS Document и будут соблюдать его тем больше новичков обратят на него внимание. Я не совсем согласен с ним в той части, что это обратит внимание новичков на эти пункты, т.к. скорее всего они даже не увидят данного документа и уж тем более не выполнят озвученные в нем пункты, а если даже увидят, то вряд ли прочтут (документацию то они не читают, к ОГРОМНОМУ сожалению конечно), но я абсолютно согласен с ним в той части, что необходимо хотя бы пытаться что-то с этим делать. Делать надо уже давно и делать уже сейчас, т.к. потом может стать уже слишком поздно и наши маршрутизаторы и каналы будут забиты только DDoS трафиком.

Потому я решил снова написать об этом проекте и просить вас, читателей данной статьи, обратить внимание на соответствие ваших сетей простым правилам данного проекта и если у вас есть «пробелы», то устранить их на вашей сети. Глядишь кол-во ботов и DDoS атак сократиться.


 

Александр Азимов из Qrator Labs (создатели QRATOR RADAR MONITOR о котором я так же писал в прошлый раз) предложил внести правки в прокол BGP — проект «A Simple BGP«.

Вкратце озвучу суть предлагаемых изменений. Они состоят в том, чтобы попытаться вовсе искоренить проблему BGP route leak. Проблему которая возникает из-за новичков, которые при настройке BGP сессии указывают лишь IP-адрес BGP соседа и его ASку и имеют несколько BGP сессий.  Да, да, да — такие есть и их много:

newcomers

Предлагается добавить понятие «роль» в настройки BGP сессии и передавать её в OPEN сообщении, а так же автоматической фильтрации по маркерам основываясь на установленной, в конфигурации, роли.

role.marker

bgp.role

Соответственно если «роли» не совпадут, то BGP соединение не установится и у вас будет повод обратить внимание вашего клиента на НЕ верную конфигурацию на его стороне, а так же если новичок совсем не сделает никак BGP фильтров, то ПО сделает это автоматически и за него.

Считаю что предложение очень здравое и это действительно помогло бы в борьбе (с озвученной выше) с проблемой.

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

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading...Loading...
Отправить на почту Отправить на почту
Вместо вступления: Давненько не писал, все руки как то не доходили. 2015 год заканчивается, надо бы обновить блог :) Напишу те статьи что помню и давно хотел написать.

Итак в данной статье пойдет речь о оч.хор. фишке у Juniper, а именно возможность выполнить анонс сети по BGP от другой AS без поднятия BGP сессии с этой AS.

Зачем это может понадобиться ?

Например:

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

Для понимания того что нам необходимо — читаем мануал «Understanding Aggregate Routes»:

routing-options {
    aggregate {
      (defaults | route) {
      (active | passive);
      as-path    ;
      community [ community-ids ];
      discard;
      (brief | full);
      (metric | metric2 | metric3 | metric4) metric ;
      (preference | preference2 | color | color2) preference ;
      tag string;
      }
   }
}

Вот это то что нам нужно.

В кач-ве примера возьмем следующие данные:

  • основная AS: AS100
  • вторая AS: AS200
  • префикс AS200: 1.1.1.0/24

Правим конфигурацию:

[edit]
root@mx80.domain.ru# set routing-options aggregate route 1.1.1.0/24 as-path path 200 origin igp aggregator 100 2.2.2.2

Не забываем поправить BGP фильтры для анонса данной сети своим апстримам и пирам. Затем коммитим конфиг и у вас он в таблице роутинга появится как:

root@mx80.domain.ru> show route terse 1.1.1.0/24

inet.0: 568282 destinations, 569718 routes (567644 active, 0 holddown, 638 hidden)
+ = Active Route, - = Last Active, * = Both

A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 1.1.1.0/24    A 130                        Reject

А ваши пиры получат вот такой BGP маршрут:

root@external.domain.ru> show route terse 1.1.1.0/24

inet.0: 576181 destinations, 3792790 routes (575034 active, 35 holddown, 93700 hidden)
+ = Active Route, - = Last Active, * = Both

A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 1.1.1.0/24    B 170                                        100 200 I

Т.е. префикс 1.1.1.0/24 принадлежит AS200 и доступен по as-path AS100 -> AS200, но при этом, как мы знаем, BGP сессии между AS100 и AS200 не существует.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading...Loading...
Отправить на почту Отправить на почту

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

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

Специалисты по информационной безопасности из корпорации Google обнаружили несколько критических уязвимостей в протоколе Network Time Protocol (NTP). Именно с его помощью в начале 2014 г.была проведенасамая мощная DDoS-атака в истории интернета.

«Новые уязвимости позволяют атакующему сформировать специальный пакет и, отправив его на целевую систему, вызвать переполнение буфера и далее выполнить в системе произвольный вредоносный код с привилегиями NTPD (фонового процесса, осуществляющего обмен данными по протоколу NTP)», — говорится в сообщении.

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

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

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

Источник: http://www.cnews.ru/top/2014/12/22/beschislennoe_kolichestvo_serverov_mozhet_byt_atakovano_hakeramidiletantami_591140

Overview

The NTP Project ntpd version 4.2.7 and pervious versions allow attackers to overflow several buffers in a way that may allow malicious code to be executed. ntp-keygen prior to version 4.2.7p230 also uses a non-cryptographic random number generator when generating symmetric keys. These vulnerabilities affect ntpd acting as a server or client.

Description

The Network Time Protocol (NTP) provides networked systems with a way to synchronize time for various services and applications. The reference implementation produced by the NTP Project (ntp.org) contains several vulnerabilities.CWE-332: Insufficient Entropy in PRNG — CVE-2014-9293

If no authentication key is defined in the ntp.conf file, a cryptographically-weak default key is generated.

CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) — CVE-2014-9294

ntp-keygen before 4.2.7p230 uses a non-cryptographic random number generator with a weak seed to generate symmetric keys.

CWE-121: Stack Buffer Overflow — CVE-2014-9295

A remote unauthenticated attacker may craft special packets that trigger buffer overflows in the ntpd functionscrypto_recv() (when using autokey authentication), ctl_putdata(), and configure(). The resulting buffer overflows may be exploited to allow arbitrary malicious code to be executed with the privilege of the ntpd process.

CWE-389: Error Conditions, Return Values, Status Codes — CVE-2014-9296

A section of code in ntpd handling a rare error is missing a return statement, therefore processing did not stop when the error was encountered. This situation may be exploitable by an attacker.

The NTP Project provides more information about these issues in their security advisory.

The NTP Project implementation is widely used in operating system distributions and network products. These vulnerabilities affect ntpd acting as a server or client. CERT/CC is not aware of any public exploit of these vulnerabilities at this time.

The CVSS score below is based on the buffer overflow vulnerabilities (CVE-2014-9295).

Impact

The buffer overflow vulnerabilities in ntpd may allow a remote unauthenticated attacker to execute arbitrary malicious code with the privilege level of the ntpd process. The weak default key and non-cryptographic random number generator in ntp-keygen may allow an attacker to gain information regarding the integrity checking and authentication encryption schemes.

Solution

Apply an updateThese issues have been addressed in ntp-4.2.8. The update may be downloaded from ntp.org.
Restrict status queriesAs noted in the announcement for ntp-4.2.8:

The vulnerabilities listed below can be significantly mitigated by
following the BCP of putting

restrict default … noquery

in the ntp.conf file.  With the exception of:

receive(): missing return on error
References: Sec 2670 / CVE-2014-9296 / VU#852879

below (which is a limited-risk vulnerability), none of the recent
vulnerabilities listed below can be exploited if the source IP is
restricted from sending a ‘query’-class packet by your ntp.conf file.

 

Источник: http://www.kb.cert.org/vuls/id/852879

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading...Loading...
Отправить на почту Отправить на почту

4 декабря прошел очередной (уже 10-ый) пиринговый форум MSK-IX.

Я был одним из участников данного форума, уже не впервый раз. Как и на других форумах MSK-IX были и интересные доклады и не очень.

Но и в этот раз не обошлось без тем о безопасности сетей и о DDoS. Что меня побудило на написание данной статьи ? Сейчас расскажу.

На данном форуме уже 3 доклада было посвящено данной проблеме, т.е. рост этой проблемы очевиден и чем дальше тем хуже. Я хочу обратить внимание на данную проблему не только тех кто присутствовал на данном мероприятии, но и остальных наших подписчиков.

Все мы сталкивались с проблемой DDoS`а, но далеко не все понимают, что она существует благодаря нам самим. Почему ?

Потому что не все, далеко не все, админы следуют, казалось бы простым, правилам и тем самым они, сами того не понимая, являются соучастниками DDoS атак, т.к. не делают ничего чтобы препятствовать им. Число Amplification атак растет как на дрожжах. Почему ? Да потому что реализация такой атаки проста. Они и далее будет расти, если ВЫ, уважаемый читатель, по прежнему будете бездействовать и рано или поздно это бездействие вернется к вам, как бумеранг.

Доклады (PDF версии докладов, а так же видео доступны тут):

Хорошие манеры или манифест устойчивой маршрутизации

(Докладчик: Андрей Робачевский Internet Society)

DDoS атаки: динамика за 2014 год

(Докладчик: Алексей Семеняка Qrator Labs)

Отражение DDoS-атак: защита CDN-трафика с CloudFlare

(Докладчик: Мартин Леви Cloudflare)

 

Давайте пройдемся по этим докладам и посмотрим какова ситуация по данной проблеме на текущий день.

Проект MANRS (Mutually Agreed Norms for Routing Security)

Простые правила:

  • Фильтрация BGP: Предотвращение распространения неправильной маршрутизационной информации
  • Анти-спуфинг: Предотвращение трафика с подложными IP-адресами
  • Содержание контактой и иной иформации в up-to-date: Улучшение информационного обмена и координации между сетевыми операторами в глобальном масштабе

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

Хуже чем что ? Читаем далее.

Посмотрите на рост кол-ва атак:

ddos_1

А вот как вам такая картинка:

ddos_2

Россия даже Китай обогнала по кол-ву ботов…. а теперь задумайтесь насколько велика разница по кол-ву народа в Китае и в России.

Вам не обидно за державу ? Мне обидно.

Теперь посмотрим на такой график:

ddos_3

Кол-во атак, из-за криво настроенной службы NTP, впереди планеты всей…. Хотя настройка службы NTP занимает не более 5 минут.

Смотрим во что все это выливается:

ddos_4

ddos_5

ddos_6

ddos_7

А теперь спросите себя: А вы хотите оказаться жертвой атаки в 400 Гбит/с ? Думаю что ответ будет «НЕТ!».

Ну и следующий вопрос, который стоит задать себе: А что лично Я сделал для того чтобы это остановить ?

Если ответ будет «ничего», то СРОЧНО приступите к тому, чтобы остановить ЭТО в подконтрольных вам сетях.

Для этого много не надо, как минимум:

  1. вы не должны выпускать НЕ свои IP-адреса из своей сети
  2. ваши DNS сервера не должны позволять рекурсию
  3. ваши NTP сервера должны быть настроены и не пропускать MONLIST
  4. ваша SNMP служба не имеет дефолтовых community public и private, а так же отвечат на запросы от НЕ ваших хостов
  5. если у вас есть BGP клиенты, то убедитесь что у вас есть BGP фильтры на анонсы от ваших клиентов и что они пропускают только префиксы вашего клиента

Что надо делать:

  1. На вашем Border`е (пограничный маршрутизатор вашей сети) зафильтровать все пакеты, где SRC IP не является IP-адресом из ваших подсетей.
  2. Настроить ваш DNS сервер, чтобы он выполнял рекурсивняе запросы только для IP-адресов из ваших подсетей.
  3. Настроить NTP службу.
  4. Настроить SNMP службу.
  5. Установить фильтры на анонсы подсетей ваших BGP клиентов.

Запрет рекурсии DNS  для bind и разрешение только вашим клиентам

acl "allow-recursion" {
        127.0.0.1;
        10.0.0.0/8;
        172.16.0.0/12;
        192.168.0.0/16;
        XXX.XXX.XXX.XXX/YY;
        ...
};
options {
        ...
        allow-recursion{ allow-recursion; };
        allow-query-cache{ allow-recursion; };
        ...
};

Либо полностью отключить возможность рекурсии, если этот DNS сервер используется только для резолва ваших доменов:

options {
        ... 
       recursion no;
       allow-query-cache{ none; };
       ...
}; 

Настройки для NTP службы

# by default act only as a basic NTP client
restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap
# allow NTP messages from the loopback address, useful for debugging
restrict 127.0.0.1
restrict -6 ::1
# server(s) we time sync to
server 192.0.2.1
server 2001:db8::1
server time.example.net 

Вот ещё вариант конфига для NTP:

disable monitor
enable auth
# server(s) we time sync to
server 192.36.143.151
restrict 192.36.143.151 noquery notrap
server 195.66.241.10
restrict 195.66.241.10 noquery notrap
server 192.87.106.2
restrict 192.87.106.2 noquery notrap
server 145.238.203.14
restrict 145.238.203.14 noquery notrap

driftfile /var/db/ntp.drift

restrict 127.0.0.1
restrict XXX.XXX.XXX.XXX mask 255.255.YYY.ZZZ nomodify notrap
restrict default ignore

Где XXX.XXX.XXX.XXX это ваша IP-подсеть, а 255.255.YYY.ZZZ её маска.

Настройка SNMP службы

rocommunity MYCOMPANY-RO 127.0.0.1
rocommunity MYCOMPANY-RO XXX.XXX.XXX.XXX
rwcommunity MYCOMPANY-RW 127.0.0.1
rocommunity MYCOMPANY-RO XXX.XXX.XXX.XXX

Где XXX.XXX.XXX.XXX это доверенный хост в вашей сети. Так же вы можете просто запретить фаирволом обращение на порт UDP 161 для всех кроме ваших доверенных хостов.

Так же не стоит забывать о ваших пользователях,если они у вас есть, которые так же имеют реальные IP-адреса и которые в большинстве случаев вообще не понимают «как это работает», а значит они так же могут являться источниками для осуществления DDoS`а.

Вы можете проверить, подвержены ли вы уязвимостям и смогут ли вас использовать для осуществления DDoS атаки, используя команды:

DNS Amplifiers

# dig @ВАШ-IP-АДРЕС +edns=0 +ignore +noadflag com ANY

NTP Amplifiers

# ntpdc -nc monlist ВАШ-IP-АДРЕС

SNMP Amplifiers

# snmpbulkget -v2c -c public ВАШ-IP-АДРЕС 1.3

«Инструменты«, помимо ваших рук, которые вы можете использовать для поиска IP-адресов из вашей AS которые могут быть использованы в кач-ве усилителей атаки:

Посетите данные ресурсы, посмотрите что они покажут вам по вашим IP подсетям. Если результат не будет нулевым, то обязательно устраните все проблемы. Если вы этого не сделаете, то кто-то обязательно пострадает от DDoS`а, а вы можете стать следующим.

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

В противном случае данное ЗЛО будет только расти и приумножаться.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5,00 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

Ссылка на новость: http://uinc.ru/news/sn22174.html

Попытки решить проблемы с нехваткой IPv4 адресов поставили Всемирную Сеть перед новой значительной проблемой — переполнением глобальной таблицы BGP-маршрутов. В настоящее время глобальная таблица маршрутов BGP на некоторых системах преодолела отметку в 512 тысяч записей, что начало приводить к разнообразным локальным проблемам со связностью. Ожидается, что своего пика проблема достигнет на следующей неделе, когда с переполнением столкнётся большинство провайдеров. Суть проблемы в том, что в процессе оптимизации пространства IPv4-адресов, провайдерам стали выделяться небольшие подсети, что привело к росту размера глобальной таблицы маршрутов BGP. При этом во многих устаревших, но ещё находящихся в эксплуатации, маршрутизаторах Cisco и некоторых других производителей для BGP-таблицы глобальных маршрутов IPv4 по умолчанию установлено ограничение в 512K элементов, что обусловлено размером TCAM-памяти, в которой размещается таблица маршрутов. Например, проблеме подвержены серии Cisco 7600, Cisco ASR 9000 с картами Trident, Cisco ASR 1000 с 4GB ОЗУ, Cisco Catalyst 6500. В зависимости от используемого маршрутизатора переполнение таблицы может привести к разным эффектам, от краха маршрутизатора до выпадания маршрутов и других проблем со связностью. В основном пострадают операторы связи, вынужденные использовать устаревшее оборудование. Крупные провайдеры уже перешли на современные модели маршрутизаторов, которые избавлены от упомянутых ограничений. Проблема также не повлияет на стабильность глобальной системы маршрутизации и будет ограничена только локальными проблемами со связностью у операторов, использующих устаревшие маршрутизаторы. Проблема уже привела к простою в работе таких компаний, как eBay, Comcast, Time-Warner, LastPass, Liquid Web. Так как TCAM-память разделена для таблиц IPv4 и IPv6, одним из решений является выделение дополнительной памяти для таблицы IPv4 за счёт урезания размера таблицы IPv6, но данная манипуляция («mls cef maximum-routes ip 1000») требует перезагрузки маршрутизатора. В настоящее время размер таблицы для IPv6 составляет менее 20 тысяч записей. 

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading...Loading...
Отправить на почту Отправить на почту