Этого следовало ожидать, начиная с того самого момента, когда учёные научились загружать цифровую информацию внутрь макромолекул дезоксирибонуклеиновой кислоты.
Впервые исследователям удалось заразить вирусом компьютер, анализировавший ДНК, в которую был внесён вредоносный программный код. Похоже, что всех нас ждёт увлекательное биопанковское будущее, где взломать можно абсолютно всё, включая основное хранилище генетической информации любого биологического организма.
Команда учёных из Университета Вашингтона не планировали попасть в новостные колонки научных порталов. Но похоже, что это было неизбежно. Их волновал вопрос безопасности процесса транскрипции и анализа ДНК, ведь эта непростая задача базируется на программном обеспечении с открытым доступом к исходному коду.
Причём пользуются этим софтом сотни лабораторий по всему миру. Если злоумышленникам удастся загрузить вредоносный код в систему, весьма дорогостоящие анализы, мягко говоря, накроются медным тазом.
Разумеется, исследователи могли продемонстрировать уязвимость системы при помощи более традиционных способов. Например, использовать инструменты удалённого доступа через Интернет.
Но учёные решили зайти в своём эксперименте немного дальше. В качестве носителя вредоносного кода было решено использовать ДНК, исходный материал, с которым системе анализатора приходится иметь дело каждый день.
«Нашей основной задачей стала попытка избежать ситуаций, когда преступник будет стучать в нашу дверь, а мы будем совершенно к этому не готовы», — рассуждает профессор Тадайоши Коно, который много лет занимается исследованиями в области безопасности встроенной и нишевой электроники, в том числе и дорогостоящих научных приборов.
Программное обеспечение научного оборудования устроено таким образом, что преобразовывает получаемые из ДНК данные в бинарные данные. Поток бит хранится в буфере фиксированного размера, предполагающем разумную максимальную длину чтения.
Это открывает перед злоумышленниками базовую уязвимость переполнения буфера данных, при которой программное обеспечение выполняет подсунутый вредоносный код. Пускай в эксперименте и не использовался «компьютерный вирус» в его классическом понимании, но выполненный код был очень близок к тому. Ведь с его помощью учёным удалось получить доступ к управлению компьютером.
Исследователи очень надеются, что у них получится донести до научного сообщества эту важную информацию. Ведь если дорогостоящее исследовательское оборудование настолько уязвимо, что взломать его можно даже на уровне ДНК, многие исследования могут оказаться под угрозой срыва.
А это не сулит человечеству ничего хорошего. Результаты своего эксперимента учёные представят широкой публике на конференции USENIX Security, которая пройдёт на следующей неделе в городе Ванкувере. Взято с hi-news.ru
Google традиционно поделилась данными о распределении версий Android. Релиз флагманских смартфонов в августе и выход обновлений увеличил долю Nougat. Лидером по-прежнему остаётся Marshmallow — на «зефир» приходится треть рынка зелёного робота. Как сообщают представители ресурса 9to5google, ситуация с долями Android в этом месяце изменилась мало.
Последнее место разделяют Gingerbread и Ice Cream Sandwich с 0,7 процента каждая. Jelly Bean работает на 7,6 процента устройств, KitKat держит 16-процентную долю.
Результат Android Lollipop — 29,2 процента, Marshmallow укрепил позиции и начал месяц с 32,3 процента. 12,3 процента пользователей радуются Android 7.0 на своём устройстве, а новейшую Android 7.1 получили всего 1,2 процента. Рост Nougat за месяц — 2 процента. Взято с androidinsider.ru
При написании первой статьи мною не преследовалась цель сделать какое-либо открытие, а просто хотелось поделиться практическим опытом внедрения. На мой взгляд, описанная конфигурация является более простой, по сравнению с отраженной в презентации от вендора с применением Destination Class Usage (DCU). Но именно последнее натолкнуло на мысль оценить возможность применения DCU и SCU в системах фильтрации трафика, т. к. имею хорошее представление и практический опыт работы с DCU, где он применялся для зоновой тарификации трафика VPN-сервисов.
В последнее время многие пишут и обсуждают способы защиты от DDoS-атак, пытаются создать и внедрить новые стандарты, томно ожидая их превращения из Draft в полноценный Internet Standart, а потом еще больше ожидая вендорских имплентаций. Мне кажется, что в оперативном плане более оправданным является применение существующих решений производителей, хотя и развитие рабочих предложений тоже необходимо.
В любой операторской сети с реализованными сервисами защиты от DDoS, как правило, существует несколько ступеней очистки трафика, что вполне логично. Принять несколько сотен Gbps или Mpps «грязного» трафика и очистить его исключительно только с помощью TMS (Threat Management System) — неоправданно дорого. Обычно, первой ступеней очистки, особенно важной при атаках с большой volumetric, является Pre-firewall filter, задача которого уменьшить полосу «мусорного» трафика до значения, которое может легко «переварить» операторская сеть и TMS. Существует два основных варианта реализации данного фильтра — на пограничных маршрутизаторах собственной сети и в сетях аплинков. Если рассматривать вариант с реализацией внутри собственной сети, то это, обычно, stateful firewall filters, работающие на input/output на интерфейсах, или внедренный внутри сети FlowSpec. В сетях аплинков, как правило — FlowSpec, работающий по внутренней сигнализации, и по сигнализации, принимаемой с клиентских сетей. Если в первом варианте существует возможность более тонкой фильтрации, ограничив определенный destination IP, протокол, порт, флаг, размер пакета полисером, то во втором варианте предусмотрен только жесткий discard, мало чем отличающейся от blackhole, если атака имеет характеристики работающего сервиса.
SCU и DCU, по мануалам Juniper, предназначены для accounting-трафика по сопоставлению с определенным policy с match по определенным критериям. Т.е., если кратко, можно считать трафик по описанным в специфичный класс конкретным префиксам, BGP-community, target-community, etc. Firewall filter позволяет делать match по source-class и destination-class. Данные опции позволяют создать firewall filter с возможностью тонкой фильтрации по source AS, или если выразить простым языком, осуществлять геофильтрацию трафика с помощью Pre-firewall filter.
Пример практической реализации фильтрации TCP Syn-flood представлен на схеме. Конфигурация и ее описание даны ниже.Данные о flow «чистого» и «грязного» трафика с помощью протокола IPFIX (в данной статье его работа рассматриваться не будет) снимаются с line cards маршрутизатора с определенной дискретностью (sampling) и передаются на Flow Collector, где обрабатываются и отображаются в системе мониторинга Flow Monitor. Это один из способов реализации мониторинга входящего flow, в разных операторских сетях он реализован по разному. Одним из важных параметров, отображаемый в IPFIX является SrcAS. Кто сталкивался с огромными по объему атаками в сотни Gbps и наблюдал за автономными системами происхождения «грязного» трафика, обратил внимание, что при определенных видах атак распределение источников того же флуда далеко неоднородно. Т.е. существует какое-то число топовых ASN с превалирующим значением. Подобная картина отчетливо прослеживалась во время прошлогодних DDoS-атак с применением знаменитого ботнета Mirai.
Предлагаемый способ позволяет существенно ограничить уровень «грязного» трафика именно с ASNs, входящих в ТОР. Давайте поэтапно рассмотрим функцинал на примере конфигурационного файла.
1. Создаем policy scu_ddos в котором делаем матч по протоколу bgp и по as-path source-as. Перечисленным атрибутам присваиваем source-class ddos.
set policy-options policy-statement scu_ddos term 1 from protocol bgp
set policy-options policy-statement scu_ddos term 1 from as-path source-as
set policy-options policy-statement scu_ddos term 1 then source-class ddos
2. В as-path source-as в виде регулярного выражения добавляем origin-as для топовых ASNs.
set policy-options as-path source-as «.* 65000|65002»
В нашем примере на рисунке они обозначены красным цветом, и с них, в приведенном примере, поступает 80Gbps TCP syn-flood.
3. Применяем созданный policy на экспорт к forwarding-table. Если на экспорт уже есть примененные policy, то scu_ddos желательно поставить первым, используя команду insert в соответствующем конфигурационном блоке.
set routing-options forwarding-table export scu_ddos
4. Создаем policer lim100m.
set firewall policer lim100m filter-specific
set firewall policer lim100m shared-bandwidth-policer
set firewall policer lim100m if-exceeding bandwidth-limit 100m
set firewall policer lim100m if-exceeding burst-size-limit 1m
set firewall policer lim100m then discard
5. Создаем firewall filter scu_ddos_limit, в котором осуществляем match по source-class ddos, ограничиваемому протоколу и флагу, считаем и ограничиваем полисером в 100 Mbps весь трафик соответствующий данным критериям.
set firewall filter scu_ddos_limit term1 from source-class ddos
set firewall filter scu_ddos_limit term1 from protocol tcp
set firewall filter scu_ddos_limit term1 from tcp-flags syn
set firewall filter scu_ddos_limit term1 then policer lim100m
set firewall filter scu_ddos_limit term1 then count scu_ddos_count
set firewall filter scu_ddos_limit term2 then accept
6. На интерфейсах включения аплинков включаем accounting и применяем на input созданный фильтр scu_ddos_limit.
set interfaces ae1 unit 0 family inet accounting source-class-usage input
set interfaces ae1 unit 0 family inet filter input scu_ddos_limit
7. Проверяем срабатывание счетчиков и полисера на интерфейсе.
run show firewall filter scu_ddos_limit-ae1.0-i | match «lim100m-ae1.0-i|scu_ddos_count-ae1.0-i»
scu_ddos_count-ae1.0-i 90763066484 1745338287
lim100m-ae1.0-i 343023655 9801281
Таким образом, мы можем нивелировать значительную часть syn-флуда (в примере на рисунке из суммарной полосы в 100 Gbps до 20 Gbps), тем самым предотвратить перегрузку собственных сетевых ресурсов и устройств очистки трафика.
При правильно подобранном значении полисера дропы пакетов проявляются только во время атаки. Необходимо понимать, что в момент атак полисером также будет дропаться и часть легитимного TCP syn-трафика с ограничиваемых автономных систем, что существенно не повлияет на уже установившиеся соединения.
Apple улучшила защиту приложения «Фотографии». В iOS 11 инженеры Apple разработали новый механизм работы с хранилищем фотографий — «только для записи» (write-only). Эта опция позволит наделять приложения правами только на запись информации вместо полного доступа.
Это не самое значительное нововведение, но оно показывает, что Apple постепенно закрывает личную информацию пользователей.
Сейчас, если приложению нужно сохранить фотографию, ему необходим полный доступ к хранилищу, что означает доступ ко всем изображениям и данным, которые с ними связаны.
Новый принцип можно сравнить со специальным отделением над банковской ячейкой, через которое Вы вносите дополнительные деньги, но саму ячейку при этом открывать не нужно.
Пользователи не должны забывать, что эта функция хороша в том случае, если разработчик приложения, которое устанавливается на телефон, считает её необходимой. Именно поэтому Apple рекомендует внимательно выбирать дополнительные приложения, которые загружаются на устройство.
В новой iOS 11 расширяются возможности управления самим пользователем. В отличие от iOS 10, в которой можно выбрать только из двух опций — разрешать приложению доступ к личным фотографиям или нет, в новой операционной системе пользователь сам определит, хочет ли предоставить полный доступ или только возможность записывать информацию.
Пользователи мечтают, что в будущем будут настраивать свои девайсы полностью по личному усмотрению благодаря новым параметрам безопасности.
Пока таких возможностей у нас нет, но тренды показывают, что они могут появиться в будущих версиях iOS. Взято с macdigger.ru
Нам нравятся производители, которые оперативно и регулярно выпускают обновления для своих устройств. Так уж вышло, что никто не делает это лучше, чем недавно вернувшаяся на рынок смартфонов Nokia.
Августовское обновление безопасности для Nokia 5 и Nokia 6 вышло спустя несколько часов после того, как его опубликовала Google.
HMD Global можно похвалить как минимум за то, что компания держит данное слово. Было заявлено, что обновления будут выходить насколько возможно быстро, и для большинства производителей компания выпускает обновления невозможно быстро.
В это сложно поверить, но июльское обновление Android для Nokia 5 и Nokia 6 вышло до того, как его смогла выпустить компания Google. Августовское обновление выпустили почти одновременно с Google. Ни один другой производитель ранее не демонстрировал такие скорости.
Стоит отметить, что обновление не вышло для Nokia 3, но всего две недели назад этот смартфон получил июльское обновление.
Кроме того, нам известно, что компания усердно работает над Android 7.1.1 для этого смартфона, и вполне возможно, что совсем скоро Nokia 3 получит новую версию вместе с августовским обновлением.
Кроме молниеносных обновлений, HMD Global пообещала поддерживать свои устройства как минимум 1,5 года и выпустить Android 8.0 на всю линейку смартфонов. Взято с androidinsider.ru
Можно не доверять размытым фотографиях, но флагман показал Evleaks. Эван Бласс, известный в IT-журналистике под псевдонимом Evleaks, добыл изображение iPhone 8 за месяц по презентации. Так король выглядит в защитном бампере:
Согласно Блассу:
Название не включает Edition — это просто iPhone 8.
Apple все-таки вписала блок с сенсорами в дисплей — на манер Essential Phone, смартфона создателя Android.
Пришлось пожертвовать частью статус-бара (предполагалось, его скроют черным цветом, чтобы спрятать камеры и датчики).
За последние три года Evleaks опубликовал рендеры и фотографии Moto X4, Lumia 930, 950/950 XL, LG G6 и Galaxy Note 8 за месяцы до премьер. И не ошибся ни разу. Взято с macdigger.ru
