irihorn95 Posted February 20, 2014 Posted February 20, 2014 Здравствуйте. Наблюдается такая ситуация 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 Если он и правда жрет столько, хотелось бы убить процесс полностью. Подскажите что сделать? Вставить ник Quote
agr Posted February 20, 2014 Posted February 20, 2014 Повесьте фильтр на интерфейс 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 Вставить ник Quote
irihorn95 Posted February 20, 2014 Author Posted February 20, 2014 agr Значит, среди абонентов появился олень. Благодарю)) Может завербуем его на работу)) Вставить ник Quote
NikBSDOpen Posted February 20, 2014 Posted February 20, 2014 Да вряд ли среди абонентов. Рассылка от jun приходила больше месяца назад с рекомендациями. Все столкнулись собственно с высокой загрузкой CPU, связанной с ntp, хоть фильтры для RE и стояли. Вариант то как исправить выдавать или сами? Если что http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10613&smlogin=true Вставить ник Quote
agr Posted February 20, 2014 Posted February 20, 2014 irihorn95 как уже сказали вряд ли среди абонентов. Явление это массовое во всем инете. NikBSDOpen если фильтр для RE не помогает, значит он неправильно настроен. Вставить ник Quote
NikBSDOpen Posted February 20, 2014 Posted February 20, 2014 если фильтр для 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; } Уменьшил, пороговые значения, поменял конструкт. Вставить ник Quote
agr Posted February 20, 2014 Posted February 20, 2014 NikBSDOpen ну так у вас не фильтр стоит, а полисер. Суть атаки в том, что атакующий посылает на NTP сервер команду monlist, сам запрос очень короткий - не больше 250 байт, а вот в ответ сервер уже может посылать несколько десятков килобайт. Ваши 5Мбит для пакетов 250 байт - это около 2500 пакетов в секунду. Если ответ сервера на monlist например 10Кбайт, то с таким рейтом это уже 200Мбит/с. Вставить ник Quote
msdt Posted February 20, 2014 Posted February 20, 2014 Я на своих J6350 просто закрыл NTP для всех ip-адресов, кроме тех, с которыми они синхронизизируются. Несколько десятков мегабит исходящего трафика и высокая загрузка RE сразу исчезли. Вставить ник Quote
irihorn95 Posted February 20, 2014 Author Posted February 20, 2014 msdt, Я вот жду пока до "наших" "дойдет" это)) Вставить ник Quote
st_re Posted February 20, 2014 Posted February 20, 2014 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 софта) Вставить ник Quote
agr Posted February 20, 2014 Posted February 20, 2014 Если быть точным, то ответ больше запроса в 204 раза... Я эту ссылку выше и приводил:) Если быть еще точнее, то ответ может быть в больше в 204 раза. Размер ответа зависит от того со сколькими разными машинами успел пообщаться NTP сервер до того. Вставить ник Quote
st_re Posted February 20, 2014 Posted February 20, 2014 Если быть еще точнее, то ответ может быть в больше в 204 раза. Размер ответа зависит от того со сколькими разными машинами успел пообщаться NTP сервер до того. ну после начала операции, оно быстро выходит на нужное количество для нужного соотношения, даже если до начала список был девственно чист :) Я у себя видел проблемных машин и считал объемы.. 204 почти точно выходило. В общем зарезал (ну после стука по голове причастным, естественно) UDP с или на 123 порт вне обычных для NTP размеров пакетов. Еще часть запросов летит с портов ниже 1024 (но не 123, а, к примеру 53, т.е с 53 на 123, ответ естественно улетает на чей то открытый в их фаерволе dns) а также 7777 8888 8000 и еще некоторых стандартных для разных служб. На самом деле хорошо что у топикстартера ЦПУ воткнуло, он хоть обратил внимание на проблему. Средней руки тазик с линуксом-фрей отвалит пару-тройку сотен мегабит такого мусора и не поперхнется. Разве что абуза свалится провайдеру или же на трафик попадет. Вставить ник Quote
Negator Posted February 20, 2014 Posted February 20, 2014 Кстати по RFC и запросы и ответы должны быть по 123 порту. Но никто этому не следует. Вставить ник Quote
Lynx10 Posted February 21, 2014 Posted February 21, 2014 Я просто закрыл NTP для всех ip-адресов, кроме тех, с которыми они синхронизизируются. Несколько десятков мегабит исходящего трафика и высокая загрузка RE сразу исчезли. +1 Вставить ник Quote
st_re Posted February 21, 2014 Posted February 21, 2014 Кстати по RFC и запросы и ответы должны быть по 123 порту. Но никто этому не следует. Клиенты (та же винда) массово спрашивает с >1024. да и есть общение не тол ко сервер-сервер, но и например ntpdc (т.е. вовсе не синхронизация времени, а сервисные запросы, каковыми в общем в нынешней проблеме и пользуются) не от рута. оно в принципе не сможет спросить от 123 порта. Кстати тут qwerty.ru сделало каку.. они, похоже не въехав в детали проблемы завернули 123 порт на свою железку... Все бы ничего, но их железка врет время на 5 МИНУТ! Уроды. Вставить ник Quote
NikBSDOpen Posted February 21, 2014 Posted February 21, 2014 (edited) ну так у вас не фильтр стоит, а полисер. Суть атаки в том, что атакующий посылает на 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 February 21, 2014 by NikBSDOpen Вставить ник Quote
ivb1232 Posted February 21, 2014 Posted February 21, 2014 У нас трафик от NTP DDOS атак на абонентов измерялся гигабитами. Пришлось разрешить UDP123 <--> UDP123, остальное на 123 запретить. Ситуация нормализовалась. Вставить ник Quote
grifin.ru Posted February 21, 2014 Posted February 21, 2014 У нас трафик от NTP DDOS атак на абонентов измерялся гигабитами. Пришлось разрешить UDP123 <--> UDP123, остальное на 123 запретить. Ситуация нормализовалась. А как узнать который час тем, кто за НАТом ?! Вставить ник Quote
oneem Posted February 26, 2014 Posted February 26, 2014 Привет, помогите новичку в среде 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 пропадает инет, и все. Доступ бывает. Что не правильно сделал подскажите пожалуйста.Спасибо! Вставить ник Quote
pfexec Posted February 26, 2014 Posted February 26, 2014 Что не правильно сделал подскажите пожалуйста.Спасибо!Здраствуйте, а позовите пожалуйста одмина. Он Вам поможет! .) Вставить ник Quote
myst Posted February 26, 2014 Posted February 26, 2014 Меня вот больше волнует вопрос как защитить клиентов ЗА джуном. Клиенты самые разные, NTP сервера не известны. Вставить ник Quote
darkagent Posted February 27, 2014 Posted February 27, 2014 Меня вот больше волнует вопрос как защитить клиентов ЗА джуном. Клиенты самые разные, 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 все достаточно шустро рисуется. Вставить ник Quote
myst Posted February 27, 2014 Posted February 27, 2014 (edited) Ну вот на SRX я к сожалению не нашел как сделать подобное. Edited February 27, 2014 by myst Вставить ник Quote
oneem Posted February 27, 2014 Posted February 27, 2014 Что не правильно сделал подскажите пожалуйста.Спасибо!Здраствуйте, а позовите пожалуйста одмина. Он Вам поможет! .) Мне кричать или рыпаться чтоб он пришел ?)) Вставить ник Quote
oneem Posted March 3, 2014 Posted March 3, 2014 Ни кто не поможет ? 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 на какой та форум... ХЕЛП Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.