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

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

Специалисты обнаружили несколько новых уязвимостей в популярном протоколе 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

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

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)
Загрузка...
Отправить на почту Отправить на почту

Всем трям !

После очередного взлома Asterisk`а клиента нашего клиента (простите за тавтологию :)) и отправки через него SIP вызовов на дорогие направления и данного топика на форуме мы снова между собой заговорили про давнюю идею…

Идея, которая сидит не только в наших головах, до которой пока ни у кого толком руки так не дошли…

Идея проста: для email есть тот же Spamcop, а для VoIP ? Хм… да ничего нету… И вот этот пробел хорошо бы устранить.

Что необходимо ?

Online сервис, в последствии распределенный сервис, который будет содержать список фродовых номеров и/или направлений и предоставлять возможность обращаться к нему за этим данными, например перед тем как разрешить совершение вызова.

Что это даст ?

Ну как минимум: клиенту это может сэкономить его деньги, а нам это даст сохранение клиента, своих нервов и попыток доказать клиенту, что его система все же совершала вызовы на дорогие направления.

Ведь наверняка и у вас было когда клиент говорил «это не мое !» и потом «тогда я отключаюсь от вас».

Так было принято решение: brain -> hands -> service 🙂

Встречайте пилотную версию нового проекта subnets.ru -> frod.subnets.ru

Надо же с чего то начинать.

Вот вкратце как предполагается  использовать и уже сейчас можно использовать:

Asterisk dialplan

DNS + ENUMLOOKUP

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

[tests]
exten => test,1,Set(DIAL=${ENUMLOOKUP(${EXTEN},,,,frod.subnets.ru.)})
exten => test,n,NoOp(${DIAL})
exten => test,n,GotoIf($["${DIAL}" = ""]?dial:frod)
exten => test,n(dial),NoOp(Dial(SIP/prov/${EXTEN},60,ti))
exten => test,n,Hangup
exten => test,n(frod),NoOp(Frod detected, skip dial)
exten => test,n,Hangup

В CLI Asterisk будет:

-- Executing [test@tests:1] Set("SIP/6003-000002b2", "DIAL=810972592132872@127.0.0.1") in new stack
-- Executing [test@tests:2] NoOp("SIP/6003-000002b2", "810972592132872@127.0.0.1") in new stack
-- Executing [test@tests:3] GotoIf("SIP/6003-000002b2", "0?dial:frod") in new stack
-- Goto (tests,test,6)
-- Executing [test@tests:6] NoOp("SIP/6003-000002b2", "Frod detected, skip dial") in new stack
-- Executing [test@tests:7] Hangup("SIP/6003-000002b2", "") in new stack

API Для тех кому нужно будет большее чем DNS запрос, будет доступно API:

Консоль

# nslookup 7781046406664700.frod.subnets.ru
Server: 91.217.137.1
Address: 91.217.137.1#53

Name: 7781046406664700.frod.subnets.ru
Address: 216.121.95.194

Вышеописанное уже есть на данный момент, а далее… далее очень много вопросов. Вопросов таких как:

  • получение данных извне
  • обработка данных (добавление номера в список, кол-во времени хранения и т.п.)
  •  удаление номера из базы извне

Это конечно не полный список вопросов, которые нужно решить и которые будут решаться. Если у вас есть данные о фродовых вызовах с ваших серверов/железа и вы готовы ими поделиться с остальными, то отправка этих данных нам приветствуется 🙂 Если у вас есть мысли, идеи, то они так же приветствуются. Можно написать тут в комментах, можно отправить на virus [СОБАЧКА-ГАВ-ГАВ] subnets.ru Пока нет логики обработки данных, то пока данные из базы будут представляться as-is.

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

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

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

Ссылка на новость: 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 тысяч записей. 

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

Heartbleed OpenSSL Security Bug

Несколько дней назад обнаружили уязвимость в протоколе SSL.

CVE-2014-0160

Description

The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.

http://www.nixp.ru/news/12427.html

Уязвимость CVE-2014-0160, о которой стало официально известно 7 апреля, затрагивает последние релизы OpenSSL: стабильную 1.0.1 и бету 1.0.2-beta, которые, в частности, используются в актуальных версиях дистрибутивов GNU/Linux и других UNIX-подобных систем (например, Ubuntu 12.04 и 13.10, Fedora 18, CentOS 6.5, FreeBSD 8.4). Проблема в обработке памяти в расширении TLS heartbeat приводит к возможности получить данные, хранимые в OpenSSL, что несет серьезную угрозу конфиденциальности информации, передаваемой по зашифрованному каналу.

Проблему обнаружил Нил Мехта (Neel Mehta) из Google. Исправление уже доступно пользователям OpenSSL 1.0.1 в релизе 1.0.1g, а для бета-версии 1.0.2-beta будет представлено в 1.0.2-beta2. Всем пользователям OpenSSL 1.0.1 рекомендуется срочно обновиться до актуальной версии. Поставщики крупных Linux-дистрибутивов и других систем, использующих OpenSSL, уже выпустили соответствующие обновления.

KB у Juniper: [JSA10623] 2014-04 Out of Cycle Security Bulletin: Multiple products affected by OpenSSL «Heartbleed» issue (CVE-2014-0160)

Проверить ваш HTTS сервис на наличие данной уязвимости можно с помощью online тулз:

 

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