Если кто-то еще не слышал, Juniper опубликовал заявление: обнаружен код в ScreenOS версий с 6.2.0r15 по 6.2.0r18 и с 6.3.0r12 по 6.3.0r20, позволяющий обладающим соответствующей информацией лицам сделать две вещи:

1) Аутентифицироваться на устройстве по ssh
2) Слушать VPN трафик

Обнаружить проникновение может быть непросто.

Затронута только ScreenOS. SRX в порядке. Наверное.

Подробнее:
forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554
kb.juniper.net/InfoCenter/index?page=content&id=JSA10713

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

Подтвердилось существование проблемы, о которой многие догадывались.

Cisco объявили, что неназванный производитель памяти в течение пяти лет (с 2005 по 2010) поставлял им брак. Характер брака: оборудование с этой памятью может годами копить аптайм, не вызывая никаких нареканий к своей работе, но стоит перезагрузить его (по питанию или даже простым reload) — память перестает корректно работать, само устройство либо не загружается, либо загружается и периодически падает. Связано это с деградацией чипов памяти. По заявлению вендора, основные проблемы начинаются после двух лет эксплуатации.

Прежде чем в Cisco полетят тухлые помидоры, спешу предупредить: память стандартная, многие вендоры ее закупали, потому затронуто может быть великое множество единиц оборудования. Есть подтверждение об аналогичных проблемах у Juniper. Но только Cisco сознались, несмотря на неизбежный репутационный ущерб. Их финансовые потери из-за этой катастрофы составляют около 655 миллионов долларов.

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.

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

Я много думал про информационные риски, связанные как с оборудованием Huawei, так и с самой компанией Huawei. Я разговаривал с людьми, в неформальной обстановке рассказывавшими о своем опыте работы с Huawei в роли клиентов – по их словам, качество продукции, мягко говоря, не самое лучшее, но зато цена отличная. В конце концов я осознал одну пугающую истину. Главный риск информационной безопасности – не в сетевом железе, а в инженерах техподдержки вендора.

Не так давно мне довелось беседовать с разработчиком, не понимавшим, почему полностью резервированная связь между ЦОДами не может гарантировать 100% доступность сервиса.

Сейчас я расскажу, как, имея в наличии совершенно стандартное устройство на Android с поддержкой USB Host (в моем случае Nexus 7), совершенно стандартный USB Host переходник на полноразмерный разъем «мама», совершенно стандартный USB serial контроллер на чипе PL2303 (они почти все работают именно на этом чипе) и не менее стандартный цискин голубой шнурок, зайти на консоль сетевого оборудования и без всяких ограничений работать с ней. Хотя никто не мешает подключать к планшету/телефону и любое другое оборудование, работающее с командной строкой поверх RS-232.

Существуют рекомендованные, общепринятые средства сбора логов сетевого оборудования — SNMP, syslog и иже с ними. Обычно они прекрасно работают, но временами требуется нечто большее.