Новости информационной безопасности

Громкий пожарный сигнал вывел из строя жесткие диски в шведском центре обработки данных Digiplex. Наиболее заметным последствием стал сбой всех операций Nasdaq по Северной Европе. Digiplex является одним из крупнейших центров обработки данных в своем районе: сотни его серверов размещены в здании площадью 20 000 кв.м в Вясби, недалеко от Стокгольма.

Как сообщает издание Bleeping Computer, инцидент произошел 18 апреля 2018 года рано утром и был вызван инертным газом. В подобных системах пожаротушения газ высвобождается из специальных баллонов в случае возгорания. Неправильная настройка приводит к резкому непреднамеренному высвобождению газа из баллона с оглушительным звуком, который может повлечь за собой сбой в работе жестких дисков.

На видео Брендана Грегга (Brendan Gregg) из Sun Fishworks наглядно показано, почему даже простое повышение голоса может привести к сбою в работе жестких дисков:

Итоги аварии

В результате пострадала примерно треть серверов, расположенных в Швеции, Дании, Исландии, Финляндии, Норвегии и Прибалтике. Все финансовые операции таких банков, как FIM Bank и OP Bank Group, были заблокированы с 08:00 до 14:00 — к этому времени уже удалось развернуть необходимые бэкапы.

Компания Digiplex заявила, что Nasdaq арендует у них пространство в центре обработки данных, но использует при этом свое собственное оборудование. Представители биржи добавили, что прямо сейчас в Швеции недостаточно серверов для замены уничтоженных, и им приходится импортировать новое оборудование.

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

Источник: BleepingComputer

Olga Dergach

Наши тесты для вас:
— Тест на знание сленга веб-разработчиков.
— Что вы знаете о работе мозга?
— А вы точно программист?

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

Чтобы вывести из строя HDD, нужно направить на него звук на частоте, которая резонирует с частотой HDD. Программа hdd-killer отлично демонстрирует, как это происходит на практике. Если звук достаточно громкий, то вскоре система отключит устройство с ошибкой ввода-вывода, а сам жёсткий диск может получить необратимые повреждения.

Иногда подобные случае происходят непреднамеренно. Например, в сентябре 2016 года румынский дата-центр ING Bank приостановил работу на 10 часов после пожарных учений. Десятки жёстких дисков вышли из строя из-за громкого звука инертного газа, выпускаемого из баллонов под большим давлением. Звук был очень мощным (более 130 децибелл), а ведь известно, что даже кричать на жёсткие диски нельзя — это увеличивает задержку доступа к HDD.

Примерно то же самое случилось 18 апреля 2018 года в шведском дата-центре Digiplex, который обслуживает биржевые операции. Из-за инцидента даже пришлось прервать торги на бирже Nasdaq Nordiq в Северной Европе, пишет Bleeping Computer.

Как и два года назад в Румынии, всё началось с пожарной сигнализации — и громкого звука инертного газа, выпускаемого из баллонов под большим давлением. Чувствительные накопители не выдержали этого звука — и вскоре примерно треть всех серверов в дата-центре прекратила функционировать. Как сообщается, на этих серверах работали торговые системы биржи Nasdaq Nordic, а также финских банков FIM Bank и OP Bank Group.

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

Из-за инцидента биржа Nasdaq Nordic не смогла открыться в положенное время в 8:00 по местному времени, когда в этом районе начинают работать все фондовые биржи. Пострадали трейдеры из Швеции, Финляндии, Дании, Исландии, а также трёх прибалтийских стран. По каким-то причинам Nasdaq в Норвегии открылась и работала, сообщает издание.

Частично восстановить системы и перезапустить торги на Nasdaq Nordic в ограниченном объёме удалось только в 15:00 того же дня, хотя по правилам биржи она обязана восстанавливать систему из резервной копии в течение двух часов. Представители Nasdaq сообщили финским СМИ, что система резервного копирования будет использоваться до понедельника, пока они не заменят пострадавшее оборудование в дата-центре и не проверят, что в резервных копиях сохранились действительные копии всех рабочих систем от всех банков-участников торгов.

Представитель Digiplex сказал, что Nasdaq арендует только место в дата-центре, но использует своё собственное оборудование. Руководство Nasdaq объяснило, что во всей Швеции не нашлось в тот момент достаточного количества серверов, чтобы заменить вышедшие из строя. Пришлось импортировать новые серверы из-за границы. Этим объясняется задержка с восстановлением системы из резервных копий: «Самолёты только что пришли», — сказал Лаури Розендаль (Lauri Rosendahl), исполнительный директор биржи Nasdaq Nordiq, в комментарии финской газете Helsingin Sanomat на следующий день после инцидента. Пока не установят новое оборудование, биржевые сервисы работают не в полной мере. В частности, торги доступны не для всех трейдеров, пишет Helsingin Sanomat.

Digiplex — один из крупнейших центров обработки данных в Северной Европе, с тысячами серверов в здании площадью 20 000 м². Он располагается в районе Уппландс Весбю недалеко от Стокгольма. Любопытно, что в течение двух дней после фатальной пожарной тревоги так и не ясно, была она вызвана реальным возгоранием или оказалась ложной. От этого зависит, кто будет выплачивать компенсацию пострадавшим и по какой статье.

RSA — это и правда тусовка менеджеров, и не важно с чьей стороны — поставщика решений по безопасности или же компании-клиента. О киберзащите там говорят «на высоком уровне», общими словами, подчас туманно и расплывчато. В целом можно понять, почему технарей от формулировок типа «инклюзивность диверсификации при построении новой парадигмы инфобезопасности» так бомбит. Но в попытках поделить около-ИБ-сообщество на «наших» и «ваших» ничего хорошего нет. Во-первых, делителей и так в нашей жизни слишком много. Во-вторых, индустрия информационных технологий (если вспомнить тот же скандал вокруг Фейсбука) столкнулась с проблемами, которые технического решения, к сожалению, не имеют. Попробуем показать на примерах.

Да ладно? Нет, подход «чтобы что-то получилось, надо много и упорно работать» — он вообще правильный, но услышать его именно на RSA Conference было как-то неожиданно. Еще два года назад практически те же люди бодро жужжали про невероятные преимущества IoT и бездонные провалы в безопасности, к которым уже почти прикручен то ли машин лернинг, то ли блокчейн, то ли некстген, и что совсем скоро все будет хорошо. А тут вот оно как вышло. Предположу, что источник такого ветра перемен — в настроениях корпоративных клиентов, которые устали слушать про очередную страшную АПТ в отсутствие какого-то вменяемого плана противодействия. Пора бы уже поговорить про решения, причем это пожелание относится и к технарям, обычно ищущим только проблемы. Хотя бы и в самой инфраструктуре конференции: на четвертый день RSA Conference кто-то обнаружил базу фирменного мобильного приложения на серверах подрядчика в открытом доступе.

At this time, the following feeds are supported:

Getting Started

pip install -r requirements.txt

Feeds
An example configuration is provided in config_example.json with settings to get started. This file contains a JSON object containing the required settings for each feed / processor / exporter. An description of a feeds settings are shown below:

...
    "feeds": {
...
        "MalShare": {
            "ENABLED" : true,
            "API_KEY" : "00000000000000000000000000000000000000000000000000000000000",
            "EXPORTERS" :  ["DetailsPrinter", "JSONLog"],
            "PROCESSORS" :  ["YaraScan", "DNSResolver"]
        },

...

Processors
Processors are used to enrich/standardize the collected. For example, data from VirusTotal contains yara results for each file collected, whereas MalShare does not. By adding, YaraScan to the PROCESSORS key, you can scan the files to also include this data.
An example modules settings are below:

...
    "processors": {
    ...
        "YaraScan": {
            "ENABLED" : false,
            "RULES_PATH": "/yara_rules/Malware.yara"
        },
        ...

• ASNLookup
• DNSResolver
• FileType
• RDNS
• YaraScan

     ...
     "exporters": {
        ...
        "JSONLog": {
            "ENABLED" : true,
            "PRETTY" : true,
            "LOG_PATH": "./temp/"
        },
        ...

• DetailsPrinter
• GenericWebStorage
• JSONLog
• LocalFileStorage

python malpipe.py

Create Python Module
MalPipe modules are defined as Python classes. Following is an example Module header

class ModuleName(Processor):
    def __init__(self):
        md = ProcessorDescription(
            module_name="ModuleName",
            description="Description",
            authors=["Author Name"],
            version="VersionNumber"
        )
        Processor.__init__(self, md)
        self.types = ['ipaddresses']
        self.parse_settings()

 from malpipe.config import CONFIG
            ...
            self.yara_rule_path = CONFIG['processors'][self.get_module_name()]['RULES_PATH']

Add Settings
After creation of the module, settings need to be added to are config.json under the processors, feeds , or exporters key. If the new module is a processor or exporter, it will also need to be added to the associated feeds. An example is shown below:

     ...
    "processors": {
     ...    
        "SuperNewModule": {
            "ENABLED" : true,
            "DOCOOLSTUFF": true
        },
     ...
    "feeds": {
        ...
        "0DayMalwareFeed": { 
            "ENABLED" : true,
            "EXPORTERS" :  ["DetailsPrinter", "JSONLog"],
            "PROCESSORS" :  ["SuperNewModule"]
        }
        ...

Authors