Skip to main content

DDOS атаки на маршрутизатор и методы защиты Juniper routing engine

По долгу службы мне часто приходится сталкиваться с DDOS на сервера, но некоторое время назад столкнулся с другой атакой, к которой был не готов. Атака производилась на маршрутизатор Juniper MX80 поддерживающий BGP сессии и выполняющий анонс сетей дата-центра. Целью атакующих был веб-ресурс расположенный на одном из наших серверов, но в результате атаки, без связи с внешним миром остался весь дата-центр. Подробности атаки, а также тесты и методы борьбы с такими атаками под катом. 

История атаки


Исторически сложилось, что на маршрутизаторе блокируется весь UDP трафик летящий в нашу сеть. Первая волна атаки (в 17:22) была как раз UDP трафиком, график unicast пакетов с аплинка маршрутизатора:

image
и график unicast пакетов с порта свича подключенного к роутеру:
image

демонстрируют, что весь трафик осел на фильтре маршрутизатора. Поток unicast пакетов на аплинке маршрутизатора увеличился на 400 тысяч и атака только UDP пакетами продолжалась до 17:33. Далее атакующие изменили стратегию и добавили к атаке UDP еще и атаку TCP SYN пакетами на атакуемый сервер, а также на сам маршрутизатор. Как видно по графику, маршрутизатору стало настолько плохо, что он перестал отдавать SNMP в zabbix. После волны SYN на порты маршрутизатора стали отваливаться BGP сессии с пирами (используется три аплинка с каждого получаем full view по ipv4 и по ipv6), в логах появились трагические записи:


Jun 27 17:35:07 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1200215741 snd_nxt: 1200215760 snd_wnd: 15358 rcv_nxt: 4074908977 rcv_adv: 4074925361, hold timer out 90s, hold timer remain 0s
Jun 27 17:35:33 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 244521089 snd_nxt: 244521108 snd_wnd: 16251 rcv_nxt: 3829118827 rcv_adv: 3829135211, hold timer out 90s, hold timer remain 0s
Jun 27 17:37:26 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1840501056 snd_nxt: 1840501075 snd_wnd: 16384 rcv_nxt: 1457490093 rcv_adv: 1457506477, hold timer out 90s, hold timer remain 0s

Как было выяснено позже, после атаки, волна TCP SYN увеличила нагрузку на routing engine маршрутизатора после чего упали все BGP сессии и маршрутизатор не смог самостоятельно восстановить работу. Атака на маршрутизатор длилась несколько минут, но из-за дополнительной нагрузки, маршрутизатор не мог обработать full view с трех аплинков и сессии снова рвались. Восстановить работу удалось только поочередным поднятием всех BGP сессий. Дальнейшая атака шла на сам сервер.

Испытание в условиях стенда и воспроизведение атаки


В качестве цели атаки использовался Juniper MX80 с той же версией прошивки, что и на боевом роутере. В качестве атакующего использовался сервер с 10Gb картой и установленной на нем ubuntu server + quagga. Генератором трафика выступал скрипт с вызовом утилиты hping3. Для проверки пагубного воздействия “всплесков” трафика, скрипт генерировал трафик с временными разрывами: 30 секунд атака — 2 секунды атаки нет. Также, для чистоты эксперимента, была поднята BGP сессия между маршрутизатором и сервером. В установленной на тот момент конфигурации боевого маршрутизатора, порты BGP и SSH были открыты на всех интерфейсах/адресах маршрутизатора и не фильтровались. Аналогичная конфигурация была перенесена на стендовый маршрутизатор.

Первым этапом испытаний стала атака TCP SYN на BGP (179) порт маршрутизатора. IP адрес источника совпадал с адресом пира в конфигурации маршрутизатора. IP address spoofing не исключался, так как у наших аплинков не включен uPRF. Сессия была установлена. Со стороны quagga:


BGP router identifier 9.4.8.2, local AS number 9123
RIB entries 3, using 288 bytes of memory
Peers 1, using 4560 bytes of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
9.4.8.1 4 1234 1633 2000 0 0 0 00:59:56 0

Total number of neighbors 1

Со стороны Juniper:
user@MX80> show bgp summary 
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
2 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
9.4.8.2 4567 155 201 0 111 59:14 1/2/2/0 0/0/0/0

После начала атаки (13:52) на маршрутизатор летит ~1.2 Mpps трафика:
image

или 380Mbps:
image
Нагрузка на CPU RE и CPU FE маршрутизатора возрастает:
image
После задержки (90 сек) BGP сессия падает и больше не поднимается:
Jul 4 13:54:01 MX80 rpd[1407]: bgp_hold_timeout:4035: NOTIFICATION sent to 9.4.8.2 (External AS 4567): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 9.4.8.2 (External AS 4567), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 3523671294 snd_nxt: 3523671313 snd_wnd: 114 rcv_nxt: 1556791630 rcv_adv: 1556808014, hold timer out 90s, hold timer remain 0s

Маршрутизатор занят обработкой прилетающего TCP SYN на порт BGP и не может установить сессию. На порту множество пакетов:
user@MX80> monitor traffic interface ge-1/0/0 count 20 
13:55:39.219155 In IP 9.4.8.2.2097 > 9.4.8.1.bgp: S 1443462200:1443462200(0) win 512
13:55:39.219169 In IP 9.4.8.2.27095 > 9.4.8.1.bgp: S 295677290:295677290(0) win 512
13:55:39.219177 In IP 9.4.8.2.30114 > 9.4.8.1.bgp: S 380995480:380995480(0) win 512
13:55:39.219184 In IP 9.4.8.2.57280 > 9.4.8.1.bgp: S 814209218:814209218(0) win 512
13:55:39.219192 In IP 9.4.8.2.2731 > 9.4.8.1.bgp: S 131350916:131350916(0) win 512
13:55:39.219199 In IP 9.4.8.2.2261 > 9.4.8.1.bgp: S 2145330024:2145330024(0) win 512
13:55:39.219206 In IP 9.4.8.2.z39.50 > 9.4.8.1.bgp: S 1238175350:1238175350(0) win 512
13:55:39.219213 In IP 9.4.8.2.2098 > 9.4.8.1.bgp: S 1378645261:1378645261(0) win 512
13:55:39.219220 In IP 9.4.8.2.30115 > 9.4.8.1.bgp: S 1925718835:1925718835(0) win 512
13:55:39.219227 In IP 9.4.8.2.27096 > 9.4.8.1.bgp: S 286229321:286229321(0) win 512
13:55:39.219235 In IP 9.4.8.2.2732 > 9.4.8.1.bgp: S 1469740166:1469740166(0) win 512
13:55:39.219242 In IP 9.4.8.2.57281 > 9.4.8.1.bgp: S 1179645542:1179645542(0) win 512
13:55:39.219254 In IP 9.4.8.2.2262 > 9.4.8.1.bgp: S 1507663512:1507663512(0) win 512
13:55:39.219262 In IP 9.4.8.2.914c/g > 9.4.8.1.bgp: S 1219404184:1219404184(0) win 512
13:55:39.219269 In IP 9.4.8.2.2099 > 9.4.8.1.bgp: S 577616492:577616492(0) win 512
13:55:39.219276 In IP 9.4.8.2.267 > 9.4.8.1.bgp: S 1257310851:1257310851(0) win 512
13:55:39.219283 In IP 9.4.8.2.27153 > 9.4.8.1.bgp: S 1965427542:1965427542(0) win 512
13:55:39.219291 In IP 9.4.8.2.30172 > 9.4.8.1.bgp: S 1446880235:1446880235(0) win 512
13:55:39.219297 In IP 9.4.8.2.57338 > 9.4.8.1.bgp: S 206377149:206377149(0) win 512
13:55:39.219305 In IP 9.4.8.2.2789 > 9.4.8.1.bgp: S 838483872:838483872(0) win 512

Вторым этапом испытаний стала атака TCP SYN на BGP (179) порт маршрутизатора. IP адрес источника выбирался случайно и не совпадал с адресом пира указанным в конфигурации маршрутизатора. Эта атака произвела на маршрутизатор такой же эффект. Дабы не растягивать статью однообразными выводами логов, приведу только график нагрузки:

image

По графику отчетливо видно момент начала атаки. BGP сессия также упала и не смогла восстановиться.

Концепция построения защиты RE маршрутизатора


Особенность работы оборудования Juniper заключается в разделении задач между routing engine (RE) и packet forwarding engine (PFE). PFE обрабатывает весь поток проходящего трафика осуществляя его фильтрацию и маршрутизацию по заранее сформированной схеме. RE занимается обработкой прямых обращений к маршрутизатору (traceroute, ping, ssh), обработкой пакетов для служб BGP, NTP, DNS, SNMP и формирует схемы фильтрации и маршрутизации трафика для PFE маршрутизатора. 

Основная идея защиты маршрутизатора состоит в фильтрации всего трафика предназначенного для RE. Создание фильтра позволит перенести нагрузку, создаваемую DDOS атакой, с CPU RE на CPU PFE маршрутизатора, что даст возможность RE обрабатывать только реальные пакеты и не тратить процессорное время на другой трафик. Для построения защиты необходимо определить, что фильтруем. Схема написания фильтров для IPv4 была взята из книги Douglas Hanks Jr. — Day One Book: Securing the Routing Engine on M, MX and T series. В моем случае на маршрутизаторе схема была следующей:

По протоколу IPv4
  • BGP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка bgp neighbor. Разрешаем только подключения tcp established, то есть фльтр будет отбрасывать все SYN прилетающие на этот порт, а сессия BGP будет начинаться только от нас (BGP сосед аплинка работает в пассивном режиме).
  • TACACS+ — фильтруем пакеты по source и destination ip, source ip может быть только из внутренней сети. Ограничиваем полосу пропускания в 1Mb/s.
  • SNMP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка snmp-clients в конфигурации.
  • SSH — фильтруем пакеты по destination ip, source ip может быть любой, так как есть необходимость экстренного доступа к устройству из любой сети. Ограничиваем полосу пропускания в 5Mb/s.
  • NTP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка ntp servers конфигурации. Ограничиваем полосу пропускания в 1Mb/s (в дальнейшем порог был уменьшен до 512Kb/s).
  • DNS — фильтруем пакеты по source и destination ip, source ip может быть любой из списка dns servers конфигурации. Ограничиваем полосу пропускания в 1Mb/s.
  • ICMP — фильтруем пакеты, пропускаем только на адреса принадлежащие маршрутизатору. Ограничиваем полосу пропускания в 5Mb/s (в дальнейшем порог был уменьшен до 1Mb/s).
  • TRACEROUTE — фильтруем пакеты, пропускаем только пакеты с TTL равным 1 и только на адреса принадлежащие маршрутизатору. Ограничиваем полосу пропускания в 1Mb/s.

По протоколу IPv6, в моем случае, фильтры накладывались только на BGP, NTP, ICMP, DNS и traceroute. Единственное отличие в фильтрации ICMP трафика, так как IPv6 использует ICMP в служебных целях. Остальные протоколы не использовали IPv6 адресацию. 

Написание конфигурации


Для написания фильтров в juniper существует удобный инструмент — prefix-list, который позволяет динамически составлять списки ip адресов/подсетей для подстановки в фильтры. Например, для создания списка адресов ipv4 BGP соседей указанных в конфигурации, используется следующая структура:


prefix-list BGP-neighbors-v4 {
apply-path "protocols bgp group <*> neighbor <*.*>";
}

результат составления списка:
show configuration policy-options prefix-list BGP-neighbors-v4 | display inheritance 
##
## apply-path was expanded to:
## 1.1.1.1/32;
## 2.2.2.2/32;
## 3.3.3.3/32;
##
apply-path «protocols bgp group <*> neighbor <*.*>»;

Составляем динамические списки префиксов для всех фильтров:

/* Список всех ipv4 адресов соседей BGP */
prefix-list BGP-neighbors-v4 {
apply-path "protocols bgp group <*> neighbor <*.*>";
}
/* Список всех ipv6 адресов соседей BGP */
prefix-list BGP-neighbors-v6 {
apply-path "protocols bgp group <*> neighbor <*:*>";
}
/* Список всех ipv4 серверов NTP */
prefix-list NTP-servers-v4 {
apply-path "system ntp server <*.*>";
}
/* Список всех ipv6 серверов NTP */
prefix-list NTP-servers-v6 {
apply-path "system ntp server <*:*>";
}
/* Список всех ipv4 адресов назначеных роутеру */
prefix-list LOCALS-v4 {
apply-path "interfaces <*> unit <*> family inet address <*>";
}
/* Список всех ipv6 адресов назначеных роутеру */
prefix-list LOCALS-v6 {
apply-path "interfaces <*> unit <*> family inet6 address <*>";
}
/* Список всех ipv4 адресов SNMP клиентов */
prefix-list SNMP-clients {
apply-path "snmp client-list <*> <*>";
}
prefix-list SNMP-community-clients {
apply-path "snmp community <*> clients <*>";
}
/* Список всех серверов TACACS+ */
prefix-list TACPLUS-servers {
apply-path "system tacplus-server <*>";
}
/* Список адресов роутера которые принадлежат внутренней сети */
prefix-list INTERNAL-locals {
/* В моем случае лучший вариант - ручное указание адреса */
192.168.0.1/32;
}
/* Список адресов роутера на интерфейсе управления, для доступа по SSH */
prefix-list MGMT-locals {
apply-path "interfaces fxp0 unit 0 family inet address <*>";
}
/* Приватные сети */
prefix-list rfc1918 {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
}
/* Loopback */
prefix-list localhost-v6 {
::1/128;
}
prefix-list localhost-v4 {
127.0.0.0/8;
}
/* Список всех ipv4 локальных адресов BGP */
prefix-list BGP-locals-v4 {
apply-path "protocols bgp group <*> neighbor <*.*> local-address <*.*>";
}
/* Список всех ipv6 локальных адресов BGP */
prefix-list BGP-locals-v6 {
apply-path "protocols bgp group <*> neighbor <*:*> local-address <*:*>";
}
/* Список всех ipv4 серверов DNS */
prefix-list DNS-servers-v4 {
apply-path "system name-server <*.*>";
}
/* Список всех ipv6 серверов DNS */
prefix-list DNS-servers-v6 {
apply-path "system name-server <*:*>";
}

Составляем политики для ограничения пропускной способности:


/* Ограничение в 1Mb */
policer management-1m {
apply-flags omit;
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 625k;
}
/* Все что не помещается дропаем */
then discard;
}
/* Ограничение в 5Mb */
policer management-5m {
apply-flags omit;
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 625k;
}
/* Все что не помещается дропаем */
then discard;
}
/* Ограничение в 512Kb */
policer management-512k {
apply-flags omit;
if-exceeding {
bandwidth-limit 512k;
burst-size-limit 25k;
}
/* Все что не помещается дропаем */
then discard;
}

Ниже, под «копи-паст», конфигурация фильтров конечного варианта защиты (были уменьшены пороги пропускной способности трафика NTP и ICMP, причины снижения порогов подробно описаны в разделе тестирования). Настраиваем фильтры ipv4:
IPv4 filter

Аналогичный фильтр для ipv6:
IPv6 filter

Далее необходимо применить фильтры на служебный интерфейс lo0.0. В системе JunOS этот интерфейс используется для передачи данных между PFE и RE. Конфигурация примет следующий вид:
lo0 {
unit 0 {
family inet {
filter {
input-list [ accept-bgp accept-common-services discard-all ];
}
}
family inet6 {
filter {
input-list [ accept-v6-bgp accept-v6-common-services discard-v6-all ];
}
}
}
}

Порядок указания фильтров в input-list интерфейса очень важен. Каждый пакет будет проверяться на валидность проходя по фильтрам указанным в input-list слева направо.

Тестирование фильтров


После применения фильтров, провел ряд тестов на том же стенде. После каждого теста выполнялась очистка счетчиков firewall. Нормальная (без атаки) нагрузка на роутере видна на графиках в 11:06 — 11:08. График pps за весь период тестов:
image
График CPU за весь период тестов:
image

Первым проводился тест флуда icmp c порогом трафика 5Мб/с (на графиках 10:21 — 10:24). По счетчикам фильтра и на графике видно ограничение по трафика по пропускной способности, но даже этого потока было достаточно для повышения нагрузки, поэтому порог был уменьшен до 1Мб/с. Счетчики:
Filter: lo0.0-i                                                
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 47225584 1686628
accept-ntp-lo0.0-i 152 2
accept-snmp-lo0.0-i 174681 2306
accept-ssh-lo0.0-i 38952 702
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 841 13
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 780 13
discard-udp-lo0.0-i 18743 133
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-icmp-lo0.0-i 933705892 33346639
management-5m-accept-ssh-lo0.0-i 0 0

Повторный тест флуда icmp c порогом трафика 1Мб/с (на графиках 10:24 — 10:27). Нагрузка на RE роутера упала с 19% до 10%, нагрузка на PFE до 30%. Счетчики:


Filter: lo0.0-i                                                
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 6461448 230766
accept-ntp-lo0.0-i 0 0
accept-snmp-lo0.0-i 113433 1497
accept-ssh-lo0.0-i 33780 609
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 0 0
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 360 6
discard-udp-lo0.0-i 12394 85
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 665335496 23761982
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0

Следующим был проведен тест флуда на порт BGP роутера с постороннего (не включеного в конфиг) ip адреса (на графиках 10:29 — 10:36). Как видно из счетчиков, весь флуд осел на discard-tcp фильтре RE и лишь увеличил нагрузку на PFE. Нагрузка на RE не изменилась. Счетчики:
Filter: lo0.0-i                                                
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 824 26
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 0 0
accept-snmp-lo0.0-i 560615 7401
accept-ssh-lo0.0-i 33972 585
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 1088 18
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 12250785600 306269640
discard-udp-lo0.0-i 63533 441
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0

сессия не падает:
user@MX80# run show bgp summary                
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
2 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
9.4.8.2 4567 21 22 0 76 8:49 1/2/2/0 0/0/0/0

Четвертым был проведен тест флуда (на графиках 10:41 — 10:46) UDP на порт NTP (в настройках фильтра взаимодействие по этому порту ограничивается серверами указанными в конфиге роутера). По графику, нагрузка поднимается только на PFE роутера до 28%. Счетчики:
Filter: lo0.0-i                                                
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 0 0
accept-snmp-lo0.0-i 329059 4344
accept-ssh-lo0.0-i 22000 388
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 615 10
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 0 0
discard-udp-lo0.0-i 1938171670 69219329
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0

Пятым был проведен тест флуда (на графиках 10:41 — 11:04) UDP на порт NTP с IP spoofing. Нагрузка на RE увеличилась на 12%, нагрузка на PFE увеличилась до 22%. По счетчикам видно, что флуд упирается в порог 1Мб/с, но этого достаточно для повышения нагрузки на RE. Порог трафика в итоге был уменьшен до 512Кб/с. Счетчики:
Filter: lo0.0-i                                                
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 34796804 1242743
accept-snmp-lo0.0-i 630617 8324
accept-ssh-lo0.0-i 20568 366
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 1159 19
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 0 0
discard-udp-lo0.0-i 53365 409
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-ntp-lo0.0-i 3717958468 132784231
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0

Повторный тест флуда (на графике ниже 11:29 — 11:34) UDP на порт NTP с IP spoofing, но с порогом трафика 512Кб/с. График нагрузки:
image
Счетчики:
Filter: lo0.0-i                                                
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 21066260 752363
accept-snmp-lo0.0-i 744161 9823
accept-ssh-lo0.0-i 19772 347
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 1353 22
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 0 0
discard-udp-lo0.0-i 82745 602
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-512k-accept-ntp-lo0.0-i 4197080384 149895728
management-5m-accept-ssh-lo0.0-i 0 0


Заключение


В итоге всех проведенных тестов удалось получить, устойчивую к DDOS атакам, конфигурацию фильтров трафика RE. В настоящий момент эта конфигурация уже применена на боевом роутере и проблем не выявлено. По счетчикам с боевого MX80:
Filter: lo0.0-i                                                
Counters:
Name Bytes Packets
accept-v6-bgp-lo0.0-i 31091878 176809
accept-v6-icmp-lo0.0-i 1831144 26705
accept-v6-ntp-lo0.0-i 0 0
accept-v6-traceroute-icmp-lo0.0-i 0 0
accept-v6-traceroute-tcp-lo0.0-i 48488 684
accept-v6-traceroute-udp-lo0.0-i 0 0
discard-v6-icmp-lo0.0-i 0 0
discard-v6-tcp-lo0.0-i 0 0
discard-v6-udp-lo0.0-i 0 0
discard-v6-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-v6-icmp-lo0.0-i 0 0
management-1m-accept-v6-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-v6-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-v6-traceroute-udp-lo0.0-i 0 0
management-512k-accept-v6-ntp-lo0.0-i 0 0

Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 135948400 698272
accept-dns-lo0.0-i 374 3
accept-icmp-lo0.0-i 121304849 1437305
accept-ntp-lo0.0-i 87780 1155
accept-snmp-lo0.0-i 1265470648 12094967
accept-ssh-lo0.0-i 2550011 30897
accept-tacacs-lo0.0-i 702450 11657
accept-traceroute-icmp-lo0.0-i 28824 636
accept-traceroute-tcp-lo0.0-i 75378 1361
accept-traceroute-udp-lo0.0-i 47328 1479
discard-TTL_1-unknown-lo0.0-i 27790 798
discard-icmp-lo0.0-i 26400 472
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 35680 1115
discard-tcp-lo0.0-i 73399674 1572144
discard-udp-lo0.0-i 126386306 694603
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-dns-lo0.0-i 0 0
management-1m-accept-icmp-lo0.0-i 38012 731
management-1m-accept-tacacs-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-512k-accept-ntp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0

видно какое количество “левого” трафика оседает на фильтре discard.

Буду рад ответить на все вопросы в комментариях.

Comments

Popular posts from this blog

Почему инженеры электросвязи становятся продажниками

Давно предупреждал инженеров электросвязи - если вы не развиваетесь, то рано или поздно превратитесь либо в дворника, либо в ассенизатора. О чем не предупреждал, каюсь, - так это о том, что локальный апокалипсис наступит прямо сейчас. Взять, например, сетевых инженеров  Ростелекома, которые бодро так искали, кого ещё подключить к интернету последние пару недель в Сочи и в Адлере. Скажете, инженеров заставляют работать продажниками - произвол и несправедливость? Лично я в этом совершенно не уверен. Чтобы было сразу понятно, о чем речь, готов проиллюстрировать свою мысль как работодатель. Мы ведь имеем здесь потенциальный конфликт в отношениях между работником и Ростелекомом , верно? И пока возмущенная общественность твердо стоит на стороне работника, предлагаю посмотреть чуть шире — не со стороны работодателя даже, а так, сбоку. Давайте возьмем, например, меня — типичного работодателя. Так случилось, что на меня работает некоторое количество весьма лояльных и толковых людей, ч

Как работает банк со своими корреспондентами по SWIFT

Итак, наш банк имеет открытые корреспондентские счета в США (CITIBANK N.A. NEW YORK), в Европе (VTB BANK DEUTSCHLAND AG), в России (Промсвязьбанк Москва и Собинбанк Москва). Соответственно, все расследования по платежам происходят через эти банки согласно  установленным корреспондентским отношениям с использованием соответствующих форматов SWIFT MT-195/295, MT-196/296, MT-199/299 и MT-192/292 Кроме прямых корреспондентских отношений с банками, нашим банком установлены отношения и с другими финансовыми организациями через процедуру обмена ключами, что даёт возможность использовать SWIFT-форматы МТ-195, МТ-196 и МТ-199 для проведения процедуры расследования по стандартным платежам и платежам с покрытием: - DEUTSCHE BANK TRUST COMPANY AMERICAS USA - COMMERZBANK AG Germany - CITIBANK N.A. London - CITIBANK N.A. Brussels - BANQUE DE COMMERCE ET DE PLACEMENTS S.A. Geneva - NORVIK BANKA JSC  LV - ABLV BANK AS  LV В среднем процедура расследования занимает от 3 до 14 дней (е

Как найти реального заливщика

Своего первого реального заливщика, который показал мне как можно скачать деньги в интернет с банковских счетов, я нашел случайно, когда еще трудился в Укртелекоме сменным инженером немного подрабатывая продавая трафик налево , но потом этот человек отошел от дел в связи со слишком уж скользкой ситуацией в данной сфере, и я решил поискать партнера на форумах, разместив рекламу на трёх электронных досках объявлений. Честно говоря поначалу даже был готов сразу закинуть 500 000 гривен в Гарант, но потом призадумался, а стоит ли? Ко мне начал обращаться народ обращается разных категорий 1. Дебильная школота, которая что-то любит повтирать про свою серьезность и просит закинуть 10 000 USD им на Вебмани в качестве аванса  2. Реальные мэны, которые  льют сразу большую сумму по SWIFT  без разговоров про гарантии и прочую шнягу, но после того, как им отдаёшь нал, они сразу пропадают, суть данных действий я так и не понял. зачем пропадать, если всё прошло гладко? 3. Мутные личност

М9 - точка обмена трафиком • Московский INTERNET EXCHANGE • MSK-XI

Вот так всё начиналось Изначально был всего один провайдер - Релком. Не было конкурентов - не было проблем. Рунет еще делал свои первые шаги, и все русскоязычные ресурсы были сосредоточены в одном месте. Позже Релком развалился на Релком и Демос, стали появляться другие провайдеры. Рунет тем временем подрос и... распался на множество отдельных сетей-сегментов, контролируемых разными провайдерами. Разумеется, конечные пользователи имели доступ ко всем ресурсам рунета, но прямого взаимодействия между провайдерами не было. Поэтому трафик шел с сервера одного провайдера по огромной петле через Америку, потом Германию, и только потом возвращался на сервер другого провайдера. Имела место неоправданная потеря и в скорости, и в деньгах. Пока трафик был незначительным, это мало кого волновало, но интернет бурно развивался, трафик по рунету стремительно увеличивался, и в один прекрасный день крупные провайдеры Москвы (по сути, Демос и Релком) сели друг напротив друга и решили, что им надо нал

Чем рискуют дропы и нальщики принимая заливы на свои карты

Зам.начальника управления Следственного департамента МВД Павел Сычев рассказал о криминальном бизнесе «нальщиков» - Глава Банка России Эльвира Набиуллина заявила о снижении объемов теневого оборота в конце 2013 года. Что показывает ваша статистика по выявлению незаконных операций? - В последние годы объем денежных средств, выведенных в теневой сектор, увеличивался, и криминогенная обстановка ухудшалась. Проблема находится в поле зрения президента -  в декабрьском послании Федеральному Собранию, он призвал избавить нашу финансовую систему от разного рода «отмывочных контор» и так называемых «прачечных». Оперативники уже получили ориентировку на более активное выявление этих преступлений. П о уголовным делам, расследованным МВД только в первом полугодии 2013 года, проходит 145 млрд рублей, обналиченных и незаконно выведенных заграницу. Это неуплаченные налоги, незаконный бизнес, хищения, взятки. Финансовый доход посредников от этих операций составил 8 млрд рублей. Расследовано 89

Залив на карту без предоплаты по SWIFT или SEPA

В последнее время наблюдается такая ситуация, что нальщиков и дропов на рынке много, а адекватных заливщиков , можно сказать, совсем нет. Например, один мой хороший знакомый, имеющий свой собственный офшор, работает с заливщиками на условиях партнерства, предоставляя им трафик и взамен получая 20% от поведенных транзакций на свой счет в офшорном банке. Мне он рассказал по большому секрету, как такое ему удается, а начинал он как и все с малого - продажи дебетовых карт и игре на рынке FOREX . Просто так искать Заливщиков на различных форумах, посвящённых обналу и отмыванию денег - достаточно муторное и нудное занятие, потому как после общения с десятым по счету заливщиком, начинаешь понимать, что просто так на карты и счета никто лить не будет. Однако моему другу попался один довольно интересный вариант - Заливщик предложил сделать перевод в размере 375 000 EUR по SEPA  в день предоставления готового к работе счета и активной системы Multihomed AS . Остальные предлож