Jump to content
Калькуляторы

DDoS Juniper

Здравствуйте. Наблюдается такая ситуация 100 мб аплоада на Juniper mx5. Постоянно такой. вывод команды

rizvan@border> show system processes summary

last pid: 24135; load averages: 2.05, 2.06, 2.07 up 350+18:26:48 10:09:33

140 processes: 6 running, 106 sleeping, 28 waiting

 

Mem: 698M Active, 124M Inact, 223M Wired, 98M Cache, 112M Buf, 844M Free

Swap: 2915M Total, 2915M Free

 

 

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND

1313 root 1 132 0 2832K 2680K RUN 176.3H 76.71% ntpd

80643 root 1 136 15 92052K 86132K RUN 1004.8 3.03% sampled

1225 root 10 105 0 14552K 6656K RUN 228.8H 0.98% clksyncd

 

Если я правильно понимаю, то NTP жрет 76 %?

а если я пытаюсь его отключить выдает такое

@border# delete system ntp

warning: statement not found

Если он и правда жрет столько, хотелось бы убить процесс полностью. Подскажите что сделать?

Share this post


Link to post
Share on other sites

Повесьте фильтр на интерфейс loopback и все будет ОК.

 

Сейчас в Интернетах идет эпидемия DDoS'ов эксплуатирующих уязвимости NTP. Ваш juniper не цель, а средство в этом случае.

Пара ссылок:

http://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks - материал по теме

http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html - готовые решения для защиты разных OS

Share this post


Link to post
Share on other sites

agr

Значит, среди абонентов появился олень. Благодарю)) Может завербуем его на работу))

Share this post


Link to post
Share on other sites

Да вряд ли среди абонентов. Рассылка от jun приходила больше месяца назад с рекомендациями. Все столкнулись собственно с высокой загрузкой CPU, связанной с ntp, хоть фильтры для RE и стояли. Вариант то как исправить выдавать или сами?

 

Если что http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10613&smlogin=true

Share this post


Link to post
Share on other sites

irihorn95

как уже сказали вряд ли среди абонентов. Явление это массовое во всем инете.

 

NikBSDOpen

если фильтр для RE не помогает, значит он неправильно настроен.

Share this post


Link to post
Share on other sites

если фильтр для RE не помогает, значит он неправильно настроен.

 

Да все правильно он был настроен, просто пороговое значение слишком высокое было. До часа "xyz" все было в норме.

Ну и у клиентов тоже пришлось быстро пилить.

 

filter NTP {

term NTP {

from {

source-prefix-list {

NTP;

}

destination-prefix-list {

INT;

}

protocol udp;

port ntp;

}

then {

policer 5M;

count ntp;

accept;

}

 

Уменьшил, пороговые значения, поменял конструкт.

Share this post


Link to post
Share on other sites

NikBSDOpen

ну так у вас не фильтр стоит, а полисер. Суть атаки в том, что атакующий посылает на NTP сервер команду monlist, сам запрос очень короткий - не больше 250 байт, а вот в ответ сервер уже может посылать несколько десятков килобайт.

Ваши 5Мбит для пакетов 250 байт - это около 2500 пакетов в секунду. Если ответ сервера на monlist например 10Кбайт, то с таким рейтом это уже 200Мбит/с.

Share this post


Link to post
Share on other sites

Я на своих J6350 просто закрыл NTP для всех ip-адресов, кроме тех, с которыми они синхронизизируются. Несколько десятков мегабит исходящего трафика и высокая загрузка RE сразу исчезли.

Share this post


Link to post
Share on other sites

NikBSDOpen

ну так у вас не фильтр стоит, а полисер. Суть атаки в том, что атакующий посылает на NTP сервер команду monlist, сам запрос очень короткий - не больше 250 байт, а вот в ответ сервер уже может посылать несколько десятков килобайт.

Ваши 5Мбит для пакетов 250 байт - это около 2500 пакетов в секунду. Если ответ сервера на monlist например 10Кбайт, то с таким рейтом это уже 200Мбит/с.

 

Если быть точным, то ответ больше запроса в 204 раза...

 

И тут http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack ребятам залили 400 гигабит с таких вот жупиперов (в том числе, проблем есть во многих версиях NTP софта)

Share this post


Link to post
Share on other sites

Если быть точным, то ответ больше запроса в 204 раза...

Я эту ссылку выше и приводил:) Если быть еще точнее, то ответ может быть в больше в 204 раза. Размер ответа зависит от того со сколькими разными машинами успел пообщаться NTP сервер до того.

Share this post


Link to post
Share on other sites

Если быть еще точнее, то ответ может быть в больше в 204 раза. Размер ответа зависит от того со сколькими разными машинами успел пообщаться NTP сервер до того.

 

ну после начала операции, оно быстро выходит на нужное количество для нужного соотношения, даже если до начала список был девственно чист :) Я у себя видел проблемных машин и считал объемы.. 204 почти точно выходило. В общем зарезал (ну после стука по голове причастным, естественно) UDP с или на 123 порт вне обычных для NTP размеров пакетов. Еще часть запросов летит с портов ниже 1024 (но не 123, а, к примеру 53, т.е с 53 на 123, ответ естественно улетает на чей то открытый в их фаерволе dns) а также 7777 8888 8000 и еще некоторых стандартных для разных служб.

 

На самом деле хорошо что у топикстартера ЦПУ воткнуло, он хоть обратил внимание на проблему. Средней руки тазик с линуксом-фрей отвалит пару-тройку сотен мегабит такого мусора и не поперхнется. Разве что абуза свалится провайдеру или же на трафик попадет.

Share this post


Link to post
Share on other sites

Кстати по RFC и запросы и ответы должны быть по 123 порту. Но никто этому не следует.

Share this post


Link to post
Share on other sites

Я просто закрыл NTP для всех ip-адресов, кроме тех, с которыми они синхронизизируются. Несколько десятков мегабит исходящего трафика и высокая загрузка RE сразу исчезли.

+1

Share this post


Link to post
Share on other sites

Кстати по RFC и запросы и ответы должны быть по 123 порту. Но никто этому не следует.

 

Клиенты (та же винда) массово спрашивает с >1024. да и есть общение не тол ко сервер-сервер, но и например ntpdc (т.е. вовсе не синхронизация времени, а сервисные запросы, каковыми в общем в нынешней проблеме и пользуются) не от рута. оно в принципе не сможет спросить от 123 порта.

 

Кстати тут qwerty.ru сделало каку.. они, похоже не въехав в детали проблемы завернули 123 порт на свою железку... Все бы ничего, но их железка врет время на 5 МИНУТ! Уроды.

Share this post


Link to post
Share on other sites

ну так у вас не фильтр стоит, а полисер. Суть атаки в том, что атакующий посылает на NTP сервер команду monlist, сам запрос очень короткий - не больше 250 байт, а вот в ответ сервер уже может посылать несколько десятков килобайт.

Ваши 5Мбит для пакетов 250 байт - это около 2500 пакетов в секунду. Если ответ сервера на monlist например 10Кбайт, то с таким рейтом это уже 200Мбит/с.

 

Ну так я же отписал выше, что все ограничил, а так же ссылку на http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10613&smlogin=true и изменил "конструкт" для ntp.

 

А полисер на 5М был изначально, до того, как всплыла текущая проблема, которая была известна, т.к. в рассылке пробегала достаточно давно, но была проигнорирована из за среднего риска угрозы, до первых скачков нагрузки по CPU в мониторинге. Естественно, на тот момент возросла нагрузка на CPU, но xntpd не положило.

 

Просто времени прошло достаточно много от начала масовой эксплуатации уязвимости. Удивительно то, что кто то еще до сих пор, не ограничил(заблокировал) ntp.

Edited by NikBSDOpen

Share this post


Link to post
Share on other sites

У нас трафик от NTP DDOS атак на абонентов измерялся гигабитами.

Пришлось разрешить UDP123 <--> UDP123, остальное на 123 запретить.

Ситуация нормализовалась.

Share this post


Link to post
Share on other sites

У нас трафик от NTP DDOS атак на абонентов измерялся гигабитами.

Пришлось разрешить UDP123 <--> UDP123, остальное на 123 запретить.

Ситуация нормализовалась.

А как узнать который час тем, кто за НАТом ?!

Share this post


Link to post
Share on other sites

Привет, помогите новичку в среде JunOS

 

Атака была по NTP.

 

Прописал фильтры

 

set firewall family inet filter CoPP term First_Fragment from first-fragment

set firewall family inet filter CoPP term First_Fragment then count First_Fragment

set firewall family inet filter CoPP term First_Fragment then discard

set firewall family inet filter CoPP term Fragment from is-fragment

set firewall family inet filter CoPP term Fragment then count Fragment

set firewall family inet filter CoPP term Fragment then discard

set firewall family inet filter CoPP term MGMT_Global_setup from protocol tcp

set firewall family inet filter CoPP term MGMT_Global_setup from destination-port ssh

set firewall family inet filter CoPP term MGMT_Global_setup from destination-port telnet

set firewall family inet filter CoPP term MGMT_Global_setup from destination-port 830

set firewall family inet filter CoPP term MGMT_Global_setup from tcp-initial

set firewall family inet filter CoPP term MGMT_Global_setup then policer copp-lim-1m

set firewall family inet filter CoPP term MGMT_Global_setup then count MGMT_Global_setup

set firewall family inet filter CoPP term MGMT_Global from protocol tcp

set firewall family inet filter CoPP term MGMT_Global from destination-port ssh

set firewall family inet filter CoPP term MGMT_Global from destination-port telnet

set firewall family inet filter CoPP term MGMT_Global from destination-port 830

set firewall family inet filter CoPP term MGMT_Global from tcp-established

set firewall family inet filter CoPP term MGMT_Global then policer copp-lim-1m

set firewall family inet filter CoPP term MGMT_Global then count MGMT_Global

set firewall family inet filter CoPP term SNMP from source-prefix-list FTP_Clients

set firewall family inet filter CoPP term SNMP from protocol udp

set firewall family inet filter CoPP term SNMP from port snmp

set firewall family inet filter CoPP term SNMP then policer copp-lim-1m

set firewall family inet filter CoPP term SNMP then count SNMP

set firewall family inet filter CoPP term SNMP then accept

set firewall family inet filter CoPP term NTP from source-prefix-list NTP

set firewall family inet filter CoPP term NTP from protocol udp

set firewall family inet filter CoPP term NTP from port ntp

set firewall family inet filter CoPP term NTP then policer copp-lim-1m

set firewall family inet filter CoPP term NTP then count NTP

set firewall family inet filter CoPP term NTP then accept

set firewall family inet filter CoPP term NTP_Block from protocol udp

set firewall family inet filter CoPP term NTP_Block from port ntp

set firewall family inet filter CoPP term NTP_Block then count NTP_Block

set firewall family inet filter CoPP term NTP_Block then discard

set firewall family inet filter CoPP term FTP from source-prefix-list FTP_Clients

set firewall family inet filter CoPP term FTP from protocol tcp

set firewall family inet filter CoPP term FTP from port ftp

set firewall family inet filter CoPP term FTP from port ftp-data

set firewall family inet filter CoPP term FTP from port 1024-65535

set firewall family inet filter CoPP term FTP then policer copp-lim-10m

set firewall family inet filter CoPP term FTP then count FTP

set firewall family inet filter CoPP term FTP then accept

set firewall family inet filter CoPP term FTP_Discard from protocol tcp

set firewall family inet filter CoPP term FTP_Discard from port ftp

set firewall family inet filter CoPP term FTP_Discard from port ftp-data

set firewall family inet filter CoPP term FTP_Discard from port 1024-65535

set firewall family inet filter CoPP term FTP_Discard then count FTP_Discard

set firewall family inet filter CoPP term FTP_Discard then discard

set firewall family inet filter CoPP term SNMP_Discard from protocol udp

set firewall family inet filter CoPP term SNMP_Discard from port snmp

set firewall family inet filter CoPP term SNMP_Discard then count SNMP_Discard

set firewall family inet filter CoPP term SNMP_Discard then discard

set firewall family inet filter CoPP term LAST then accept

 

далее ввожу защиту set system ddos-protection protocols ntp aggregate bandwidth 1000 burst 128

 

И создаю lo0.0, применяю фильтры set interfaces lo0.0 family inet filter CoPP

 

policer создал.

 

Когда вяжу фильтры на lo0.0 пропадает инет, и все. Доступ бывает.

 

Что не правильно сделал подскажите пожалуйста.Спасибо!

Share this post


Link to post
Share on other sites
Что не правильно сделал подскажите пожалуйста.Спасибо!
Здраствуйте, а позовите пожалуйста одмина. Он Вам поможет! .)

Share this post


Link to post
Share on other sites

Меня вот больше волнует вопрос как защитить клиентов ЗА джуном.

Клиенты самые разные, NTP сервера не известны.

Share this post


Link to post
Share on other sites

Меня вот больше волнует вопрос как защитить клиентов ЗА джуном.

Клиенты самые разные, NTP сервера не известны.

там правило простое: если 4й байт в ntp заголовке = 2A, дропаем пакет.

 

на cisco asr вырезал через FPM:

Match: start l3-start offset 11 size 1 regex "\x2A"

Match: field UDP dest-port eq 123

- полисю навешивал на аплинки по инпуту.

 

как это реализовать на джуне - хз, не доводилось с ним толком работать, а на cisco asr или sce все достаточно шустро рисуется.

Share this post


Link to post
Share on other sites

Ну вот на SRX я к сожалению не нашел как сделать подобное.

Edited by myst

Share this post


Link to post
Share on other sites
Что не правильно сделал подскажите пожалуйста.Спасибо!
Здраствуйте, а позовите пожалуйста одмина. Он Вам поможет! .)

 

Мне кричать или рыпаться чтоб он пришел ?))

Share this post


Link to post
Share on other sites

Ни кто не поможет ?

 

13:04:17.058946 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.058978 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.058987 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.058996 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.059005 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.059014 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.059051 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

13:04:17.059088 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

13:04:17.059110 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

13:04:17.059131 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

13:04:17.059152 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

13:04:17.059173 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

13:04:17.239206 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.239263 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

13:04:17.247097 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.247138 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

13:04:17.249100 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.249123 In IP 192.184.12.171.80 > 185.11.60.93.123: NTPv2, Reserved, length 8

13:04:17.249148 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

13:04:17.249181 Out IP truncated-ip - 6 bytes missing! 185.11.60.93 > 192.184.12.171: [|icmp]

 

Запросы стали идти на ICMP на какой та форум... ХЕЛП

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this