irihorn95 Опубликовано 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 Если он и правда жрет столько, хотелось бы убить процесс полностью. Подскажите что сделать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
irihorn95 Опубликовано 20 февраля, 2014 · Жалоба agr Значит, среди абонентов появился олень. Благодарю)) Может завербуем его на работу)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikBSDOpen Опубликовано 20 февраля, 2014 · Жалоба Да вряд ли среди абонентов. Рассылка от jun приходила больше месяца назад с рекомендациями. Все столкнулись собственно с высокой загрузкой CPU, связанной с ntp, хоть фильтры для RE и стояли. Вариант то как исправить выдавать или сами? Если что http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10613&smlogin=true Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 20 февраля, 2014 · Жалоба irihorn95 как уже сказали вряд ли среди абонентов. Явление это массовое во всем инете. NikBSDOpen если фильтр для RE не помогает, значит он неправильно настроен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikBSDOpen Опубликовано 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; } Уменьшил, пороговые значения, поменял конструкт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 20 февраля, 2014 · Жалоба NikBSDOpen ну так у вас не фильтр стоит, а полисер. Суть атаки в том, что атакующий посылает на NTP сервер команду monlist, сам запрос очень короткий - не больше 250 байт, а вот в ответ сервер уже может посылать несколько десятков килобайт. Ваши 5Мбит для пакетов 250 байт - это около 2500 пакетов в секунду. Если ответ сервера на monlist например 10Кбайт, то с таким рейтом это уже 200Мбит/с. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
msdt Опубликовано 20 февраля, 2014 · Жалоба Я на своих J6350 просто закрыл NTP для всех ip-адресов, кроме тех, с которыми они синхронизизируются. Несколько десятков мегабит исходящего трафика и высокая загрузка RE сразу исчезли. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
irihorn95 Опубликовано 20 февраля, 2014 · Жалоба msdt, Я вот жду пока до "наших" "дойдет" это)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 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 софта) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 20 февраля, 2014 · Жалоба Если быть точным, то ответ больше запроса в 204 раза... Я эту ссылку выше и приводил:) Если быть еще точнее, то ответ может быть в больше в 204 раза. Размер ответа зависит от того со сколькими разными машинами успел пообщаться NTP сервер до того. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 20 февраля, 2014 · Жалоба Если быть еще точнее, то ответ может быть в больше в 204 раза. Размер ответа зависит от того со сколькими разными машинами успел пообщаться NTP сервер до того. ну после начала операции, оно быстро выходит на нужное количество для нужного соотношения, даже если до начала список был девственно чист :) Я у себя видел проблемных машин и считал объемы.. 204 почти точно выходило. В общем зарезал (ну после стука по голове причастным, естественно) UDP с или на 123 порт вне обычных для NTP размеров пакетов. Еще часть запросов летит с портов ниже 1024 (но не 123, а, к примеру 53, т.е с 53 на 123, ответ естественно улетает на чей то открытый в их фаерволе dns) а также 7777 8888 8000 и еще некоторых стандартных для разных служб. На самом деле хорошо что у топикстартера ЦПУ воткнуло, он хоть обратил внимание на проблему. Средней руки тазик с линуксом-фрей отвалит пару-тройку сотен мегабит такого мусора и не поперхнется. Разве что абуза свалится провайдеру или же на трафик попадет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 20 февраля, 2014 · Жалоба Кстати по RFC и запросы и ответы должны быть по 123 порту. Но никто этому не следует. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 21 февраля, 2014 · Жалоба Я просто закрыл NTP для всех ip-адресов, кроме тех, с которыми они синхронизизируются. Несколько десятков мегабит исходящего трафика и высокая загрузка RE сразу исчезли. +1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 21 февраля, 2014 · Жалоба Кстати по RFC и запросы и ответы должны быть по 123 порту. Но никто этому не следует. Клиенты (та же винда) массово спрашивает с >1024. да и есть общение не тол ко сервер-сервер, но и например ntpdc (т.е. вовсе не синхронизация времени, а сервисные запросы, каковыми в общем в нынешней проблеме и пользуются) не от рута. оно в принципе не сможет спросить от 123 порта. Кстати тут qwerty.ru сделало каку.. они, похоже не въехав в детали проблемы завернули 123 порт на свою железку... Все бы ничего, но их железка врет время на 5 МИНУТ! Уроды. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikBSDOpen Опубликовано 21 февраля, 2014 (изменено) · Жалоба ну так у вас не фильтр стоит, а полисер. Суть атаки в том, что атакующий посылает на 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. Изменено 21 февраля, 2014 пользователем NikBSDOpen Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ivb1232 Опубликовано 21 февраля, 2014 · Жалоба У нас трафик от NTP DDOS атак на абонентов измерялся гигабитами. Пришлось разрешить UDP123 <--> UDP123, остальное на 123 запретить. Ситуация нормализовалась. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
grifin.ru Опубликовано 21 февраля, 2014 · Жалоба У нас трафик от NTP DDOS атак на абонентов измерялся гигабитами. Пришлось разрешить UDP123 <--> UDP123, остальное на 123 запретить. Ситуация нормализовалась. А как узнать который час тем, кто за НАТом ?! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
oneem Опубликовано 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 пропадает инет, и все. Доступ бывает. Что не правильно сделал подскажите пожалуйста.Спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 26 февраля, 2014 · Жалоба Что не правильно сделал подскажите пожалуйста.Спасибо!Здраствуйте, а позовите пожалуйста одмина. Он Вам поможет! .) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 26 февраля, 2014 · Жалоба Меня вот больше волнует вопрос как защитить клиентов ЗА джуном. Клиенты самые разные, NTP сервера не известны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 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 все достаточно шустро рисуется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 27 февраля, 2014 (изменено) · Жалоба Ну вот на SRX я к сожалению не нашел как сделать подобное. Изменено 27 февраля, 2014 пользователем myst Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
oneem Опубликовано 27 февраля, 2014 · Жалоба Что не правильно сделал подскажите пожалуйста.Спасибо!Здраствуйте, а позовите пожалуйста одмина. Он Вам поможет! .) Мне кричать или рыпаться чтоб он пришел ?)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
oneem Опубликовано 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 на какой та форум... ХЕЛП Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...