Комментарии 19
Кто-то ещё сидит на таком старье?
Помнится, года 3 назад новые железки шли с уже 10.2
Помнится, года 3 назад новые железки шли с уже 10.2
Уязвимы все версии, начиная с 7.6R1. По сути это баг, который был с нами годами.
из:
> На данный момент уязвимость исправлена в следующих версиях
можно предположить, что эти релизы не подвержены уязвимости.
Будте любезны ссылку на оригинальную новость на сайте Juniper'а?
> На данный момент уязвимость исправлена в следующих версиях
можно предположить, что эти релизы не подвержены уязвимости.
Будте любезны ссылку на оригинальную новость на сайте Juniper'а?
> можно предположить, что эти релизы не подвержены уязвимости.
В конкретных перечисленных релизах эта уязвимость должна быть уже исправленна.
Будьте любезны, прочитайте текст внимательно еще раз. Я указал в самом начале, что информация доступна в PR839412.
Не думаю что это оформленно в виде «новости» на сайте Juniper'а.
В конкретных перечисленных релизах эта уязвимость должна быть уже исправленна.
Будьте любезны, прочитайте текст внимательно еще раз. Я указал в самом начале, что информация доступна в PR839412.
Не думаю что это оформленно в виде «новости» на сайте Juniper'а.
>Juniper опубликовал PR839412
Приведите, пожалуйста, ссылку на публикацию. Или приведите оригинал.
Потому что из новости совершенно не понятно, есть ли данная уязвимость, например, в 11.4R5, установленном год назад.
Приведите, пожалуйста, ссылку на публикацию. Или приведите оригинал.
Потому что из новости совершенно не понятно, есть ли данная уязвимость, например, в 11.4R5, установленном год назад.
Пожалуйста: 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 последний раз.
:) Три года назад была один в один уязвимость у Джунов. только там использовался ICMP пакет. Выходит ICMP подчинили, а TCP забыли. Ждем информации, что один UDP пакет тоже ложит железку. :)
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
С этим багом достаточно одного пакета для эксплуатации. Т.е. фильтры легко обойдутся, если атакующий знает адреса ваших BGP пиров (что достаточно легко). Насчёт TTL — есть еще и multihop, и, снова таки, один единственный пакет можно собрать каким угодно.
Ну, если все так плохо: и multihop, и вы max ttl выставили от души, и атакующий знает адреса пиров, то да, можно кричать «караул». Только по хорошему делать это надо несколько раньше. Спорим, что в таком сулчае у вас на сессии нету аутентификации, и положить вашу внеш пиринг можно без всяких багов просто послав вам чего-нибудь по BGP? А еще лучше — просто слать вам TCP RST со всех подряд src-портов.
Строить теории о том, какой может быть конфигурация чтобы быть или не быть уязвимой — можно долго. Я уверен, что найдётся не мало конфигураций, которые будут уязвимы в той или иной степени. И, к счастью, такие, которые не уязвимы.
Уязвимость есть и она критическая по своей сути. Является ли возможной ее эксплуатация — зависит от вас :)
Уязвимость есть и она критическая по своей сути. Является ли возможной ее эксплуатация — зависит от вас :)
Ну, я с вашего позволения, повторю свой первоначальный тезис:
Если так случилось, что конфигурация уязвима в отношении данного экспойта, то с большой вероятностью она уязвима к массе других возможных атак на тот же BGP, о которых известно давно и подробно. И наоборот: если вы раньше думали головой и все делали правильно, то от этой проблемы вы защищены — проапгрейдиться все же стоит, но скорее в плановом режиме, чем сломя голову.
А дальше каждый сам решает, разумеется.
Если так случилось, что конфигурация уязвима в отношении данного экспойта, то с большой вероятностью она уязвима к массе других возможных атак на тот же BGP, о которых известно давно и подробно. И наоборот: если вы раньше думали головой и все делали правильно, то от этой проблемы вы защищены — проапгрейдиться все же стоит, но скорее в плановом режиме, чем сломя голову.
А дальше каждый сам решает, разумеется.
Смотрите, речь тут не о BGP. Во-первых, уязвимость на уровне TCP стэка, т.е. потенциально ещё можно эксплуатировать до того как BGP процесс дропнет пакет из-за неправильного TTL. Т.е. не важно насколько хорошо у вас он сконфигурирован, зная адрес пира — уже можно спуфнуть пакет, который потенциально перезагрузит маршрутизатор.
Это же касается и всех других сервисов, включая SSH. Раньше, зная адрес доверенного хоста — ничего сделать было нельзя. Теперь же — можно. Security through obscurity — это плохо.
Но с SSH, конечно, сложнее. С BGP же адрес пира с большой вероятностью можно угадать глядя в trace route к вам.
Поэтому уязвимы все, у кого есть хотя бы BGP с внешним миром. Не считая всех других возможных TCP сервисов.
Это же касается и всех других сервисов, включая SSH. Раньше, зная адрес доверенного хоста — ничего сделать было нельзя. Теперь же — можно. Security through obscurity — это плохо.
Но с SSH, конечно, сложнее. С BGP же адрес пира с большой вероятностью можно угадать глядя в trace route к вам.
Поэтому уязвимы все, у кого есть хотя бы BGP с внешним миром. Не считая всех других возможных TCP сервисов.
Я прекрасно понимаю, о чем вы.
Но только еще раз повторюсь, что пакет, прежде чем вообще быть скоммутированным свичем, который передает трафик с плат коммутации в RE, должен пролезть через систему файрвольных фильтров внутри комплекса коммутации. В случае с eBGP это должен быть пакет только от пира, и только с TTL 1. То есть это способ защититься в том числе от этой уязвимости, и это должно быть сделано, на любом маршрутизаторе, RE которого общается с недоверенными сетями.
И если этого не сделано, то бессмысленно вообще говорить о каких-либо уязвимостях, потому что, если кто-то хочет выставить свою задницу в интернет, вопрос о том, каким именно способом его могут трахнуть, приобретает вторичное значение.
SSH с web-менеджментом, если он у вас есть, на время до апгрейда можно и вовсе отключить из интернета. Другие TCP, адресованные в RE, надо просто выкидывать у помойку не глядя. И до того, как этот косяк обнаружили, так и после.
Так что никакой страшной неопределеннсти и вот этого вот «ах, неизвестно к чему это можно привести. Вдруг нам нужно какие-нибудь еще TCP-порты слушать, а мы не знаем, какие» — ничего этого нету. Все вполне известно и определенно. И защититься в данном конкретном случае вполне можно и нужно.
А то что уязвимость и баги это плохо — ну, можно и попалакать, конечно, но мне лень, если честно. Далеко не самая страшная это проблема, в т. ч. из встречающихся в JUNOS.
Но только еще раз повторюсь, что пакет, прежде чем вообще быть скоммутированным свичем, который передает трафик с плат коммутации в RE, должен пролезть через систему файрвольных фильтров внутри комплекса коммутации. В случае с eBGP это должен быть пакет только от пира, и только с TTL 1. То есть это способ защититься в том числе от этой уязвимости, и это должно быть сделано, на любом маршрутизаторе, RE которого общается с недоверенными сетями.
И если этого не сделано, то бессмысленно вообще говорить о каких-либо уязвимостях, потому что, если кто-то хочет выставить свою задницу в интернет, вопрос о том, каким именно способом его могут трахнуть, приобретает вторичное значение.
SSH с web-менеджментом, если он у вас есть, на время до апгрейда можно и вовсе отключить из интернета. Другие TCP, адресованные в RE, надо просто выкидывать у помойку не глядя. И до того, как этот косяк обнаружили, так и после.
Так что никакой страшной неопределеннсти и вот этого вот «ах, неизвестно к чему это можно привести. Вдруг нам нужно какие-нибудь еще TCP-порты слушать, а мы не знаем, какие» — ничего этого нету. Все вполне известно и определенно. И защититься в данном конкретном случае вполне можно и нужно.
А то что уязвимость и баги это плохо — ну, можно и попалакать, конечно, но мне лень, если честно. Далеко не самая страшная это проблема, в т. ч. из встречающихся в JUNOS.
Так а в чем заключается защита, если не проблема собрать пакет с адресом пира и таким TTL, чтобы он стал 1, когда дойдёт до маршрутизатора?
Даже если учесть, что атаковать можно только с «доверенного» внешнего пира, то если у вас их, например, сотни — это увеличивает вектор возможной атаки. Если кто то контролирует сеть пира, то он может перезагрузить ваши пограничные маршрутизаторы.
Я не вижу где я «плачу» об неизвестных слушающих сервисах. Все как раз известно. Поэтому для меня как раз ясно, что обновление должно быть внеплановым.
Даже если учесть, что атаковать можно только с «доверенного» внешнего пира, то если у вас их, например, сотни — это увеличивает вектор возможной атаки. Если кто то контролирует сеть пира, то он может перезагрузить ваши пограничные маршрутизаторы.
Я не вижу где я «плачу» об неизвестных слушающих сервисах. Все как раз известно. Поэтому для меня как раз ясно, что обновление должно быть внеплановым.
Ну, то есть, поймите правильно мой спич. Задуматься об апгрейде надо, нет вопросов. Но вот прям паниковать и сломя голову менять софт, нарушив стандартные правила этого дела (как минимум чтение Release Notes плюс соотнесение номера релиза со здравым смыслом) — по-моему не стоит. Лучше проверить, чего у вас в части стандартных механизмов защиты сделано.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Критическая уязвимость во всех версиях JunOS начиная с 7.6R1