Jump to content

Recommended Posts

Posted

Уважаемые коллеги!

 

Из Ситуационного центра Роскомнадзора поступила информация, что на оборудовании Juniper была обнаружена уязвимость (CVE-2018-0020) позволяющая провести атаку типа DoS. Злоумышленник при отправке неверно сформированного запроса BGP UPDATE может вызвать сбой и перезапуск процесса маршрутизации (rpd). Получение повторяющихся неверно сформированных BGP UPDATE может привести к отказу в обслуживании устройства.

 Уязвимые версии Juniper Networks Junos OS:

 14.1X53 versions prior to 14.1X53-D47;

15.1 versions prior to 15.1F6-S10, 15.1R4-S9, 15.1R6-S6, 15.1R7;

15.1X49 versions prior to 15.1X49-D130 on SRX;

15.1X53 versions prior to 15.1X53-D66 on QFX10K;

15.1X53 versions prior to 15.1X53-D58 on EX2300/EX3400;

15.1X53 versions prior to 15.1X53-D233 on QFX5200/QFX5110;

15.1X53 versions prior to 15.1X53-D471 on NFX;
 

16.1 versions prior to 16.1R3-S8, 16.1R4-S9, 16.1R5-S3, 16.1R6-S3, 16.1R7;

16.1X65 versions prior to 16.1X65-D47;

16.2 versions prior to 16.2R1-S6, 16.2R2-S5, 16.2R3;

17.1 versions prior to 17.1R2-S3, 17.1R3;

17.2 versions prior to 17.2R1-S3, 17.2R2-S1, 17.2R3;

17.2X75 versions prior to 17.2X75-D70;

Versions prior to 13.2R1 are not affected.

 

Ссылка: https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10848&actp=METADATA

Posted
45 минут назад, vvertexx сказал:

И как ты представляешь эксплуатирование этой уязвимости?

 

Ну видимо это не просто так выяснилось. Еще бы детали апдейта узнать конкретно. А то случаи бывали, например, в апдейте было овердохрена коммунити набито или ас патх овердлинный - эриксоны вылетали всем бгп процессом от такого. Видимо, можжевельник где-то там же огребает.

Posted

Ну как-то так:

set policy-options prefix-list BGP-locals-v4 apply-path "protocols bgp group <*> neighbor <*.*> local-address <*.*>"
set policy-options prefix-list BGP-neighbors-v4 apply-path "protocols bgp group <*> neighbor <*.*>"

 

set firewall filter accept-bgp interface-specific
set firewall filter accept-bgp term accept-bgp from source-prefix-list BGP-neighbors-v4
set firewall filter accept-bgp term accept-bgp from destination-prefix-list BGP-locals-v4
set firewall filter accept-bgp term accept-bgp from protocol tcp
set firewall filter accept-bgp term accept-bgp from port bgp
set firewall filter accept-bgp term accept-bgp then count accept-bgp
set firewall filter accept-bgp term accept-bgp then accept

 

Остальное зарезать и на lo0.0 повесить.

 

ЗЫ: https://radar.qrator.net/ - тут можно посмотреть, есть ли в AS какие-то Vulnerable Ports

 

3 часа назад, vvertexx сказал:

И как ты представляешь эксплуатирование этой уязвимости?

Если порт bgp не закрыт, то логи обычно содержат записи а-ля

	bgp_listen_accept: Connection attempt from unconfigured neighbor: 60.191.38.78+50099
	bgp_listen_accept: Connection attempt from unconfigured neighbor: 60.191.38.78+40330
	bgp_listen_accept: Connection attempt from unconfigured neighbor: 60.191.38.78+14279

т.е. пакет так или иначе обработался на re, видимо сабжевый пакет крошит rpd в таком случае.

Posted

Да походу тут от пиров прилететь может только разве что. А не просто из мира по портам bgp.

Да и передан такой апдейт дальше не будет. Мелкая проблема, может быть эксплуатирована только в определенном специфичном случае.

Posted
1 минуту назад, vurd сказал:

Да походу тут от пиров прилететь может только разве что. А не просто из мира по портам bgp.

Да и передан такой апдейт дальше не будет. Мелкая проблема, может быть эксплуатирована только в определенном специфичном случае.

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

WORKAROUND:

While there is no workaround, the risk associated with this issue can be mitigated by limiting BGP sessions only from trusted peers.

 

 

Posted
14 минут назад, vurd сказал:

Да походу тут от пиров прилететь может только разве что. А не просто из мира по портам bgp.

Да и передан такой апдейт дальше не будет. Мелкая проблема, может быть эксплуатирована только в определенном специфичном случае.

От кастомера с сессией вполне может прилететь - тут уж никак не защититься. Но это надо кому-то насолить сильно.

Если бы "malformed BGP UPDATE" передавался дальше в таком же побитом виде какими-нибудь бирдами или кваггами - то и из обменников могло бы прилететь, хотя этот расклад, конечно, намного менее вероятен.

Posted
2 минуты назад, Mystray сказал:

От кастомера с сессией вполне может прилететь - тут уж никак не защититься. Но это надо кому-то насолить сильно.

Если бы "malformed BGP UPDATE" передавался дальше в таком же побитом виде какими-нибудь бирдами или кваггами - то и из обменников могло бы прилететь, хотя этот расклад, конечно, намного менее вероятен.

А мне вот кажется, что как раз наиболее вероятен такой апдейт с обменника. Что они имеют в виду под malformed можно только догадываться. По сути oversized какой-нибудь это тоже malformed, хотя он корректен по полям - такие пакеты bird может и перекинуть.

Posted

Так экслуатировать-то элементарно. На MSK-IX гугл пирится приватно с кучей операторов, вот туда они и зарядят апдейты в час X

 

А сколько наших магистралов пристутсвует на куче IX потенциального противника? Там-то всю внешку и положат

Posted
1 час назад, s.lobanov сказал:

На MSK-IX гугл пирится приватно с кучей операторов, вот туда они и зарядят апдейты в час X

И зачем это кому то нужно?

Они вон долго сокрушались что иран без инета остался когда они очередной имплант в кошку им сажали.

Posted
В 17.04.2018 в 16:40, Butch3r сказал:

Кто-нибудь писал авторам письма чтоб помогли скачать софт?

Пишите в личку - постараюсь помочь.

Posted

 Не подскажете, что стоит на роутсерверах ttk,rtk и ihome ? Вчера вечером была невнятная совершенно ситуация c бгп, трафик закрутился меж трёх ног, кладя каналы в полки. Ну и брокада отребутилась, потеряв логи...

Posted
В 17.04.2018 в 10:26, s.lobanov сказал:

На MSK-IX гугл пирится приватно с кучей операторов

С тех пор, как msk-ix перестал быть виден в as-path, нужды в приватном пиринге больше нет.

Posted
13 минут назад, rdc сказал:

С тех пор, как msk-ix перестал быть виден в as-path, нужды в приватном пиринге больше нет.

нужды может и нет, но гугл на msk-ix ведёт себя именно так. хочешь пириться с нами - пирься приватно через заявку на isp.google.com

 

с теоретической точки зрения не очень понятно зачем это надо с учётом того, что контроллировать распространение префиксов можно через msk-ix комьюнити.

с практической точки зрения, комьюнити msk-ix вещь не универсальная и на других IX другие community, а приватный пиринг штука универсальная и может работать на любом IX

Posted

гугл же присутствует на RS

 

> show arp | grep google

2e:21:31:2b:6c:ca 195.208.208.232 msk-ix-gw1.google.com     xe-0/0/0.0              none

f6:b5:2f:71:58:cb 195.208.208.250 msk-ix-gw3.google.com     xe-0/0/0.0              none

 

> show route google.com    

173.194.0.0/16     *[BGP/150] 1w1d 11:39:43, MED 0, localpref 100, from 195.208.208.100

                      AS path: 15169 I, validation-state: unverified

                    > to 195.208.208.250 via xe-0/0/0.0

Posted

конкретнее?

 

я через RS вижу следующее:

8.8.4.0/24 8.8.8.0/24 8.34.208.0/21 8.34.216.0/21 8.35.192.0/21 8.35.200.0/21 23.236.48.0/20 23.251.128.0/19 35.184.0.0/13 35.192.0.0/13 35.200.0.0/14 35.204.0.0/15 35.224.0.0/14 35.228.0.0/14 35.232.0.0/14 35.236.0.0/14 35.240.0.0/14 35.244.0.0/14 64.233.160.0/19 66.102.0.0/20 66.249.64.0/19 70.32.128.0/19 70.32.131.0/24 70.32.133.0/24 70.32.145.0/24 70.32.146.0/23 70.32.151.0/24 72.14.192.0/18 74.114.24.0/21 74.125.0.0/16 104.132.0.0/23 104.132.5.0/24 104.132.7.0/24 104.132.8.0/24 104.132.11.0/24 104.132.34.0/24 104.133.2.0/23 104.154.0.0/15 104.196.0.0/14 107.167.160.0/19 107.178.192.0/18 108.59.80.0/20 108.170.192.0/18 108.177.0.0/17 108.177.20.0/23 108.177.22.0/24 130.211.0.0/16 142.250.0.0/15 146.148.0.0/17 162.216.148.0/22 162.222.176.0/21 172.102.8.0/21 172.110.32.0/21 172.217.0.0/16 172.253.0.0/16 173.194.0.0/16 173.255.112.0/20 185.150.148.0/22 192.104.160.0/23 192.158.28.0/22 192.178.0.0/15 199.192.112.0/22 199.223.232.0/21 207.223.160.0/20 208.68.108.0/22 208.81.188.0/22 209.85.128.0/17 209.107.176.0/20 216.58.192.0/19 216.73.80.0/20 216.239.32.0/19 216.252.220.0/22

Posted
6 минут назад, rdc сказал:

конкретнее?

Ну смотрите, на MSK-IX гугл анонсирует большие префиксы

 

Берём IP google.com 209.85.233.139. смотрим его на lg.msk-ix.ru, там он 209.85.128.0/17, а на lg, например, Мегафона, он виден как /24 , т.е. 209.85.233.0/24

 

Если вы хотите получить префиксы гугла как морспецифики, то нужно запириться с ними приватно на msk-ix

 

+ отдельная логика по отношению к вашим префиксаму них - если вы их отдаёте гуглы через RS или если вы их отдаёте приватно. Логика эта нигде явно не описана, но на пути хождения трафика от них к вам, оно в общем случае, влияет.

Posted

@rdc 

Суть-то даже совсем не в том что сделали конкретно Вы. Гугл делает прямые пиринги с РФ-операторами, а не с роут-сервером лишь ради того, чтобы в час X прислать специально сформированный анонс, которые отключит эти маршрутизаторы или передаст управление потенциальному противнику. В случае когда вы пиритесь через посрединка в виде RS (=ПО bird), шансов на успешность такой атаки чуть меньше (зависит от того, пройдёт ли "специальный" анонс через bird или нет)

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.