Комментарии 19
Кто-то ещё сидит на таком старье?
Помнится, года 3 назад новые железки шли с уже 10.2
Помнится, года 3 назад новые железки шли с уже 10.2
-3
Уязвимы все версии, начиная с 7.6R1. По сути это баг, который был с нами годами.
+3
из:
> На данный момент уязвимость исправлена в следующих версиях
можно предположить, что эти релизы не подвержены уязвимости.
Будте любезны ссылку на оригинальную новость на сайте Juniper'а?
> На данный момент уязвимость исправлена в следующих версиях
можно предположить, что эти релизы не подвержены уязвимости.
Будте любезны ссылку на оригинальную новость на сайте Juniper'а?
0
> можно предположить, что эти релизы не подвержены уязвимости.
В конкретных перечисленных релизах эта уязвимость должна быть уже исправленна.
Будьте любезны, прочитайте текст внимательно еще раз. Я указал в самом начале, что информация доступна в PR839412.
Не думаю что это оформленно в виде «новости» на сайте Juniper'а.
В конкретных перечисленных релизах эта уязвимость должна быть уже исправленна.
Будьте любезны, прочитайте текст внимательно еще раз. Я указал в самом начале, что информация доступна в PR839412.
Не думаю что это оформленно в виде «новости» на сайте Juniper'а.
0
>Juniper опубликовал PR839412
Приведите, пожалуйста, ссылку на публикацию. Или приведите оригинал.
Потому что из новости совершенно не понятно, есть ли данная уязвимость, например, в 11.4R5, установленном год назад.
Приведите, пожалуйста, ссылку на публикацию. Или приведите оригинал.
Потому что из новости совершенно не понятно, есть ли данная уязвимость, например, в 11.4R5, установленном год назад.
0
Пожалуйста: prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR839412
Думаю, ссылка не особо полезна, т.к. те кто работают с JunOS знают как посмотреть PR, у остальных же нет логина.
Я понял ваше замечание, возможно не совсем корректно сформулировал. Список исправленных релизов я скопировал из оригинального PR.
Естественно, уязвимость исправленна в последних версиях этих релизов. К примеру, 11.4R5.7, который был обновлен 28 января 2013 последний раз.
Думаю, ссылка не особо полезна, т.к. те кто работают с JunOS знают как посмотреть PR, у остальных же нет логина.
Я понял ваше замечание, возможно не совсем корректно сформулировал. Список исправленных релизов я скопировал из оригинального PR.
Естественно, уязвимость исправленна в последних версиях этих релизов. К примеру, 11.4R5.7, который был обновлен 28 января 2013 последний раз.
+3
:) Три года назад была один в один уязвимость у Джунов. только там использовался ICMP пакет. Выходит ICMP подчинили, а TCP забыли. Ждем информации, что один UDP пакет тоже ложит железку. :)
0
prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR839412
Собственно, там все написано. Судя по всему, это уязвимость ядра FreeBSD (так что надо жать аналогичные репорты о других продуктах на базе этого ядра).
Честно говоря, причин для паники не вижу.
Если у вас RE не защищен от входящих TCP откуда ни попади, то вас можно задосить еще примерно сотней способов.
В идеале FW-фильтры, защищающие RE, и не должны принимать TCP на RE от всех подряд. BGP должен быть разрешен только от сконфигурированных пиров (одна команда), к тому же eBGP — только с TTL 1. SSH — от доверенных, и т. д.
О best-practices защиты RE см. например вот эти книжки:
www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/ (доступно официально бесплатно в виде PDF).
www.juniper.net/us/en/training/jnbooks/mx-series.html
Собственно, там все написано. Судя по всему, это уязвимость ядра FreeBSD (так что надо жать аналогичные репорты о других продуктах на базе этого ядра).
Честно говоря, причин для паники не вижу.
Если у вас RE не защищен от входящих TCP откуда ни попади, то вас можно задосить еще примерно сотней способов.
В идеале FW-фильтры, защищающие RE, и не должны принимать TCP на RE от всех подряд. BGP должен быть разрешен только от сконфигурированных пиров (одна команда), к тому же eBGP — только с TTL 1. SSH — от доверенных, и т. д.
О best-practices защиты RE см. например вот эти книжки:
www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/ (доступно официально бесплатно в виде PDF).
www.juniper.net/us/en/training/jnbooks/mx-series.html
0
С этим багом достаточно одного пакета для эксплуатации. Т.е. фильтры легко обойдутся, если атакующий знает адреса ваших BGP пиров (что достаточно легко). Насчёт TTL — есть еще и multihop, и, снова таки, один единственный пакет можно собрать каким угодно.
0
Ну, если все так плохо: и multihop, и вы max ttl выставили от души, и атакующий знает адреса пиров, то да, можно кричать «караул». Только по хорошему делать это надо несколько раньше. Спорим, что в таком сулчае у вас на сессии нету аутентификации, и положить вашу внеш пиринг можно без всяких багов просто послав вам чего-нибудь по BGP? А еще лучше — просто слать вам TCP RST со всех подряд src-портов.
0
Строить теории о том, какой может быть конфигурация чтобы быть или не быть уязвимой — можно долго. Я уверен, что найдётся не мало конфигураций, которые будут уязвимы в той или иной степени. И, к счастью, такие, которые не уязвимы.
Уязвимость есть и она критическая по своей сути. Является ли возможной ее эксплуатация — зависит от вас :)
Уязвимость есть и она критическая по своей сути. Является ли возможной ее эксплуатация — зависит от вас :)
0
Ну, я с вашего позволения, повторю свой первоначальный тезис:
Если так случилось, что конфигурация уязвима в отношении данного экспойта, то с большой вероятностью она уязвима к массе других возможных атак на тот же BGP, о которых известно давно и подробно. И наоборот: если вы раньше думали головой и все делали правильно, то от этой проблемы вы защищены — проапгрейдиться все же стоит, но скорее в плановом режиме, чем сломя голову.
А дальше каждый сам решает, разумеется.
Если так случилось, что конфигурация уязвима в отношении данного экспойта, то с большой вероятностью она уязвима к массе других возможных атак на тот же BGP, о которых известно давно и подробно. И наоборот: если вы раньше думали головой и все делали правильно, то от этой проблемы вы защищены — проапгрейдиться все же стоит, но скорее в плановом режиме, чем сломя голову.
А дальше каждый сам решает, разумеется.
0
Смотрите, речь тут не о BGP. Во-первых, уязвимость на уровне TCP стэка, т.е. потенциально ещё можно эксплуатировать до того как BGP процесс дропнет пакет из-за неправильного TTL. Т.е. не важно насколько хорошо у вас он сконфигурирован, зная адрес пира — уже можно спуфнуть пакет, который потенциально перезагрузит маршрутизатор.
Это же касается и всех других сервисов, включая SSH. Раньше, зная адрес доверенного хоста — ничего сделать было нельзя. Теперь же — можно. Security through obscurity — это плохо.
Но с SSH, конечно, сложнее. С BGP же адрес пира с большой вероятностью можно угадать глядя в trace route к вам.
Поэтому уязвимы все, у кого есть хотя бы BGP с внешним миром. Не считая всех других возможных TCP сервисов.
Это же касается и всех других сервисов, включая SSH. Раньше, зная адрес доверенного хоста — ничего сделать было нельзя. Теперь же — можно. Security through obscurity — это плохо.
Но с SSH, конечно, сложнее. С BGP же адрес пира с большой вероятностью можно угадать глядя в trace route к вам.
Поэтому уязвимы все, у кого есть хотя бы BGP с внешним миром. Не считая всех других возможных TCP сервисов.
0
Я прекрасно понимаю, о чем вы.
Но только еще раз повторюсь, что пакет, прежде чем вообще быть скоммутированным свичем, который передает трафик с плат коммутации в RE, должен пролезть через систему файрвольных фильтров внутри комплекса коммутации. В случае с eBGP это должен быть пакет только от пира, и только с TTL 1. То есть это способ защититься в том числе от этой уязвимости, и это должно быть сделано, на любом маршрутизаторе, RE которого общается с недоверенными сетями.
И если этого не сделано, то бессмысленно вообще говорить о каких-либо уязвимостях, потому что, если кто-то хочет выставить свою задницу в интернет, вопрос о том, каким именно способом его могут трахнуть, приобретает вторичное значение.
SSH с web-менеджментом, если он у вас есть, на время до апгрейда можно и вовсе отключить из интернета. Другие TCP, адресованные в RE, надо просто выкидывать у помойку не глядя. И до того, как этот косяк обнаружили, так и после.
Так что никакой страшной неопределеннсти и вот этого вот «ах, неизвестно к чему это можно привести. Вдруг нам нужно какие-нибудь еще TCP-порты слушать, а мы не знаем, какие» — ничего этого нету. Все вполне известно и определенно. И защититься в данном конкретном случае вполне можно и нужно.
А то что уязвимость и баги это плохо — ну, можно и попалакать, конечно, но мне лень, если честно. Далеко не самая страшная это проблема, в т. ч. из встречающихся в JUNOS.
Но только еще раз повторюсь, что пакет, прежде чем вообще быть скоммутированным свичем, который передает трафик с плат коммутации в RE, должен пролезть через систему файрвольных фильтров внутри комплекса коммутации. В случае с eBGP это должен быть пакет только от пира, и только с TTL 1. То есть это способ защититься в том числе от этой уязвимости, и это должно быть сделано, на любом маршрутизаторе, RE которого общается с недоверенными сетями.
И если этого не сделано, то бессмысленно вообще говорить о каких-либо уязвимостях, потому что, если кто-то хочет выставить свою задницу в интернет, вопрос о том, каким именно способом его могут трахнуть, приобретает вторичное значение.
SSH с web-менеджментом, если он у вас есть, на время до апгрейда можно и вовсе отключить из интернета. Другие TCP, адресованные в RE, надо просто выкидывать у помойку не глядя. И до того, как этот косяк обнаружили, так и после.
Так что никакой страшной неопределеннсти и вот этого вот «ах, неизвестно к чему это можно привести. Вдруг нам нужно какие-нибудь еще TCP-порты слушать, а мы не знаем, какие» — ничего этого нету. Все вполне известно и определенно. И защититься в данном конкретном случае вполне можно и нужно.
А то что уязвимость и баги это плохо — ну, можно и попалакать, конечно, но мне лень, если честно. Далеко не самая страшная это проблема, в т. ч. из встречающихся в JUNOS.
0
Так а в чем заключается защита, если не проблема собрать пакет с адресом пира и таким TTL, чтобы он стал 1, когда дойдёт до маршрутизатора?
Даже если учесть, что атаковать можно только с «доверенного» внешнего пира, то если у вас их, например, сотни — это увеличивает вектор возможной атаки. Если кто то контролирует сеть пира, то он может перезагрузить ваши пограничные маршрутизаторы.
Я не вижу где я «плачу» об неизвестных слушающих сервисах. Все как раз известно. Поэтому для меня как раз ясно, что обновление должно быть внеплановым.
Даже если учесть, что атаковать можно только с «доверенного» внешнего пира, то если у вас их, например, сотни — это увеличивает вектор возможной атаки. Если кто то контролирует сеть пира, то он может перезагрузить ваши пограничные маршрутизаторы.
Я не вижу где я «плачу» об неизвестных слушающих сервисах. Все как раз известно. Поэтому для меня как раз ясно, что обновление должно быть внеплановым.
0
Ну, то есть, поймите правильно мой спич. Задуматься об апгрейде надо, нет вопросов. Но вот прям паниковать и сломя голову менять софт, нарушив стандартные правила этого дела (как минимум чтение Release Notes плюс соотнесение номера релиза со здравым смыслом) — по-моему не стоит. Лучше проверить, чего у вас в части стандартных механизмов защиты сделано.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Критическая уязвимость во всех версиях JunOS начиная с 7.6R1