суббота, 1 апреля 2017 г.
Это не шутки — остались считанные сутки… до дедлайна на GSoC 2017
Внимание! Это вам не шутки, а реальная возможность заработать!
Мы совсем забыли Вам напомнить или даже вообще рассказать, что в этом году случилось знаменательное событие. ReactOS впервые в истории получит слоты на Google Summer of Code второй год подряд. Ранее нам удавалось попасть в эту программу лишь раз в пять лет. Еще одно свидетельство значимости роли проекта в глазах индустрии!
Если вы хотите принять участие в GSoC и покодить этим летом за солидные премиальные и на общественное благо, то немедленно посетите данные странички на нашем сайте:
Основная информация о GSoC 2017 | Идеи для Google Summer of Code 2017
Если после просмотра данных материалов вы решитесь претендовать на участие в рамках наших слотов, то безотлагательно пишите в наш IRC-чат и высылайте свое резюме в текстовом виде в нашу рассылку.
Помните, у вас есть меньше 72 часов на заполнение заявки и собеседование с командой нашего проекта.
Ленинградский телефонный эфир: первый советский чат
Считается, что появление в 1988 году протокола Internet Relay Chat (IRC) ознаменовало собой начало мировой чат-революции и предопределило нынешнее господство мессенджеров. Все так, если не знать, что несколькими годами ранее в СССР существовало явление, получившее в последствии название «Ленинградский телефонный эфир». За железным занавесом в северной столице советского государства, несмотря на жесткий контроль со стороны всех и вся, возникло нечто, что в последствии назовут анонимный голосовой чат в реальном времени.
Это кажется ламповой байкой, но существуют десятки свидетельств того, как ленинградцы набирая определенные телефонные номера начинали общаться в формате группового телефонного голосового чата (конференц-связи) с совершенно незнакомыми людьми. Эта возможность появилась благодаря использованию в СССР декадно-шаговых АТС (АТС-ДШ). Это была не специально разработанная возможность, а ошибка станции. Не фича, а баг так сказать. Эффект эфира состоял в том, что если позвонить на некоторые неподключенные номера, то вы получите не отбой или сигнал занятости, а соединение. С кем соединение? С тем, кто тоже позвонит на этот же номер в это время.
Исследователи отмечают, что первые упоминания ленинградского эфира относятся к 1981-82 годам. А массовым это явление стало к середине восьмидесятых годов 20-го столетия и продлилось до середины 90-х.
Если коснуться технических аспектов возникновения этого феномена, то без крепких напитков не обойтись. В конце 70-х годов инженеры-связисты обнаружили, что при определенном положении шагового искателя коммутационного блока декадно-шаговых АТС сразу несколько людей могут позвонить на определенный номер, и они услышат друг друга. Дальше показания свидетелей расходятся, а схемы и объяснения кажутся мягко говоря запутанными.
Одни специалисты утверждали, что баг возникал из-за ошибки в распайке промшитов АТСК и АТС-54, либо благодаря сообщению во внутристанционных или межстанционных кабелях из-за нарушения симметрии (муфта затекла, разнопарка и прочее) и т.д.
Другая гипотеза гласила, что появление на АТС-ДШ описанных выше багов было вполне предсказуемо. Во всех учебниках пишут, что ДШИ — это 10х10 декадно-шаговый искатель, т.е. 3-х секционный (a,b — разговорные секции, с — проверка на занятость) 10-ти декадный, в каждой декаде по 10 шагов. Но шагов 11. 11-й шаг, это аварийная установка искателя на сигнал «занято», в обычном режиме он 11-й шаг пропускает, и возвращается в исходное состояние. Так вот, 11-й шаг — это тупая параллельная линия из проводов a,b, на которой висят гудки «занято». Поскольку подключение всех движков параллельное, то сигналы там слабые. В обычном режиме, если в шаговом поле нет свободных линий, то движок завершает поиск возвратом в исходное состояние, абонент слышит сигнал занято. Но если движок, во время совершения коммутационных «подъём»-«вращение», по каким-то причинам встаёт на 11 шаг, то абонент получает сигнал занято. Если несколько движков встанут на 11-й шаг, то абоненты, подключенные к этим движкам, могут поговорить. Причин много. АТС-ДШ — это вообще железно-железная логика, но иногда дающая интересные сбои. Говорили, что на практике бывали и не такие выкрутасы. Волшебные номера для эфира объяснялись траблами в ступенях искания I,II,III-ГИ.
Если вы поняли о чем это или же у вас есть собственная гипотеза, просьба поделиться мыслями в комментариях к статье.
Как говорят бывшие сотрудники ленинградских узлов связи возникший феномен был для них неприятным моментом. По большому счету это была некая техническая неполадка, которая продолжалась достаточно долго.
Считается, что первыми ленинградский эфир начали использовать незаконные советские предприниматели, фарцовщики, как их тогда называли. Они поняли, что это идеальный способ конспирации. Звонишь из автомата на непонятный номер непонятно кому и анонимно ведешь беседу с деловым партнером. С ростом популярности ленинградского эфира от этого метода им пришлось отказаться.
Продолжительное время баг на ленинградских узлах связи оставался незамеченным, что дало возможность общаться в эфире большому количеству жителей города. На пике популярности этот анонимный голосовой чат объединял десятки тысяч молодых людей. Анонимное и бесплатное общение вызвало небывалый энтузиазм у молодежи и нервный тик у руководства телефонных станций и сотрудников КГБ. «Сарафанное радио» - лучшая реклама. Секретные номера передавались из уст в уста, что через какое-то время эволюционировало в своеобразный клуб по интересам.
«Эфирщики» — это люди, которые не могли существовать без телефона. Так как в СССР у многих граждан своих телефонов не было, звонить с работы было неудобно, поэтому молодые люди часто пользовались телефонами-автоматами. Эта штука, как некоторые, наверное, помнят, требовала двухкопеечной монеты. Звонили по автоматам много и двухкопеечных монет просто не хватало, приходилось все время выменивать. И для удобства «эфирщики» придумали многоразовую монетку: просверливалось отверстие в двухкопеечной монете, крепилась леска и это становилось таким неразменным рублем — позвонил — вынул, опять позвонил, и так хоть тысячу раз.
Благодаря популярности «телефонного эфира» в Ленинграде, в середине 80-х явление было замечено работниками как социальной, так и технической сферы. В прессе появились статьи об «эфире», был снят документальный фильм. Комсомольские работники из сектора самодеятельных объединений при Ленинградском горкоме ВЛКСМ отнеслись к пользователям «эфира» благосклонно и обещали содействие. Но для работников городской телефонной сети «телефонный эфир» представлял крайне нежелательное явление: многочисленные и длительные соединения пользователей «эфира» создавали излишнюю нагрузку, на которую телефонная сеть была не рассчитана. В результате у обычных телефонных абонентов возникали проблемы с дозвоном.
Телефонисты начали борьбу с «паразитной нагрузкой». Выявленные номера «эфира» блокировались, но сообщество находило новые, и использование «телефонного эфира» продолжалось. Тем не менее, к концу 90-х явление постепенно угасло. В качестве основных причин этого называют постепенный переход городских АТС на новые технологии, исключавшие техническую возможность «телефонного эфира», и изменения в постсоветском обществе, сопровождавшиеся появлением новых развлечений и форм общения
Что же сейчас, спросите вы? Удивительно, но ряд сообществ живы до сих пор. Несмотря на целый зоопарк всевозможных мессенджеров, еще живы люди, которым приятней теплая ламповая аура форумов и чатов. Расширить кругозор и погрузиться в атмосферу ленинградского эфира можно здесь, и здесь.
Комментарии (0)
пятница, 31 марта 2017 г.
Security Week 13: В ЦРУ нашлись фанаты Doctor Who, APT29 пускает бэкдор-трафик через Google, начинайте патчить SAP GUI
Так, давайте обо всем по порядку. Новая порция украденных из ЦРУ документов появилась на WikiLeaks. Свежий подгон назван пафосно Dark Matter, однако документы в нем уже не первой свежести, датированные 2008-2012 годам. Тем не менее, представление о методах и возможностях американской разведслужбы они дают.
Оказывается, еще девять лет назад рыцари плаща и кинжала посягнули на святое — на наши айфоны и макбуки. Уже тогда в их распоряжении был отличнейший набор инструментов для слежки за пользователями яблочной техники.
Самый свежий документ из Dark Matter – мануал к уже упомянутому Sonic Screwdriver. Это имплант к прошивке переходника Apple Thunderbolt на Ethernet, и нужен он для того, чтобы заставить макбук загрузиться с флешки, игнорируя загрузочный пароль. Процедура очень простая: воткнуть переходник в порт Thunderbolt, флешку – в USB, включить макбук. И все. Правда, на флешке у бравого джейсонборна должен быть заготовлен джентльменский набор для заражения компа всякой шпионской пакостью, описания которой WikiLeaks также любезно предоставили.
Итак, набор DarkSeaSkies состоит из трех компонентов:
● DarkMatter – EFI-драйвер, прописываемый в прошивку макбука, и устанавливающий шпионские компоненты. В случае если не может обнаружить в интернете заранее прописанный сервер управления, решает, что явка провалена, и подчищает с компьютера все следы деятельности, включая себя самого;
● SeaPea – имплант пространства ядра Mac OS X, обеспечивающий сокрытие от пользователя процессов и файлов всего набора, а также запуск других инструментов;
● NightSkies – шпионский имплант пространства пользователя Mac OS X. Умеет исполнять команды с сервера ЦРУ, отправлять на сервер запрошенные файлы с макбука и наоборот, а также запускать файлы на исполнение.
Тактика применения DarkSeaSkies – очень в духе ЦРУ. Это вам не яйцеголовые из АНБ, тут требуется работа в контакте с целью. Для заражения макбука жертвы, агент должен получить физический доступ к нему. Причем в бумагах с WikiLeaks даются рекомендации попросту передать объекту уже зараженный макбук в виде взятки или же подарка, например, на свадьбу.
Так что, коллеги, если вам ЦРУ подарило на свадьбу макбук, запишите на него хоть немножко секретных документов, чтобы не расстраивать парней. Они же старались. Секретные документы, кстати, можно скачать с WikiLeaks.
Что же касается айфонов, для них агентство приготовило версию того же NightSkies, обеспечивающего полный набор возможностей для управления устройством. Имплант срабатывает при использовании определенных приложений (браузера, почтового клиента, карт и других).
Ставится NightSkies прямо в системный софт iPhone путем его перепрошивки через iTunes. Процедура описана достаточно подробно и оставляет несколько вопросов к Apple касательно системы безопасности iOS. Правда, документы старые и версия NightSkies предназначена для антикварного iPhone 3G, но наверняка для новых аппаратов агентство тоже успело состряпать софтинку. Словом, ждем новых подгонов от Ассанжа.
APT29 пропускали трафик бэкдора через Google
Новость. Исследование. В 2015 году исследователи из Университета Беркли описали технологию domain fronting, предназначенную для сокрытия истинной конечной точки трафика. Как оказалось, группа APT29 (она же Cozy Bear) давно взяла на вооружение этот прием и успешно им пользовалась.
Смысл domain fronting – в пересылке трафика, предназначенного для сервера управления и контроля, через какой-либо легитимный сервис. В данном случае парни из APT29 посмели втемную гнать траф через Google, причем за несколько лет их подрывной деятельности об этом никто не догадался.
Как это было: троянец на машине жертвы устанавливал сервис Tor, цинично замаскированный под приложение Google, и поднимал бэкдор, работающий через порты 139, 445 и 3389. Трафик бэкдора заворачивался в TOR, затем с помощью плагина meek кодировался в HTTP для сервера отражения трафика meek, после чего вся эта матрешка запихивалась в TLS для сервера Google. Главное в этой схеме – сервер meek расположен в том же облаке, что и Google.
Сервер Google, обнаружив, что к нему прилетел HTTP-запрос для сервера, расположенного в его CDN, перенаправляет его по адресу. Сервер meek раскодирует трафик и отправляет его в сеть TOR, по которой он благополучно достигает сервера управления бэкдором.
С точки зрения администратора атакованного компьютера сервисы Google общаются с сервером Google, то есть ничего подозрительного не происходит… В итоге изящную схему Google уже нарушил, потушив сервер meek в своем облаке, однако эта технология может использовать и другие CDN, так что не расслабляемся.
Дыра в клиенте SAP
Новость. У SAP снова нашли уязвимость. В этот раз не в сервере, а в клиенте, что гораздо хуже и вот почему.
Безопасники очень любят находить уязвимости в продуктах SAP, на данный момент их известно около 3800. Компания шустро латает дыры, а админы без устали (хочется верить) накатывают обновления. Но одно дело – пропатчить сервер (их может быть в сети один-два), а вот SAP GUI часто установлен на всех машинах компании. А их в крупных организациях может быть много тысяч. Это порождает и проблемы.
В данном случае эксплуатация уязвимости требует компрометации сервера SAP, что несколько снижает риск. Однако если кибербандиты таки сумели его взломать, все машины с SAP GUI будут для них как открытая дверь – хоть везде заливай вредоносный ABAP-код, насылай троянцев, твори беспредел. Как вам, например, перспектива одновременного запуска вымогателя-шифровальщика на двух тысячах машин? Начинайте-ка раскатывать патчи.
Древности
«HH&HH-4091»
Неопасный резидентный вирус. Зашифрован. Стандартно заражает .COM-файлы при их запуске. При заражении переименовывает файл в *.A*, записывается в него, а затем переименовывает обратно. По понедельникам записывает 0 в порт A0h и B0h в порт 41h (?). Ищет на экране строку «Esik» и, если таковая обнаружена, через некоторые время переходит в графический видеорежим и выводит на экран скачущий шар. Перехватывает int 1Ch, 21h. Содержит текст: «#(-28=CIPV]HARD HIT & HEAVY HATE the HUMANS!!! [ H.H.& H.H. the H. ]».
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 69.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Комментарии (0)
Релиз CLion 2017.1: C++14, C++17, код на дизассемблере в отладчике, Catch, MSVC и многое другое
Наши планы, как обычно, немного превосходят наши возможности и ресурсы. Но в этот релиз нам удалось успеть почти все из запланированного. Если вкратце:
- Поддержка C++14 (всё кроме constexpr)
- Начальная поддержка C++17 (мы начали с самой востребованной возможности – nested namespaces)
- Возможность конвертировать тип переменной в auto
- Во время отладки программы, при отсутствии файлов с исходным кодом можно переходить на код на дизассемблере (disassembly view)
- Поддержка фреймворка для юнит-тестирования Catch
- Значительное ускорение отклика редактора при печати кода (Zero Latency Typing)
- И, наконец, экспериментальная поддержка компилятора Microsoft Visual C++!
И это еще не все! Читайте подробности ниже.
Кстати, попробовать все новые возможности можно на небольшом демо-проекте, который мы специально подготовили для этих целей.
C++14 и C++17
Уже совсем скоро стандарт C++17 будет официально принят и C++ сообщество примется активно обсуждать и строить планы на C++19/20. Поэтому в версии 2017.1 мы постарались полностью поддержать все текущие (и официально принятые) стандарты современного C++.
Сначала мы закончили с constexpr из C++11, а затем принялись за C++14, а именно поддержали следующие возможности:
- auto return type,
- generic lambdas,
- variable templates, and
- generalized lambda captures.
Поддержка в данном случае заключается в корректном парсинге и резолве соответствующих конструкций языка (как вы помните, парсер у CLion свой) и, как следствие, в корректной подсветке кода, навигации, рефакторингах, автодополнении и корректной работе анализатора кода.
Типичный пример – использование generalized lambda captures, которое раньше приводило к тому, что весь код лямбды некорректно подсвечивался как неиспользуемый. Теперь, как видите, все хорошо:
Еще один пример – это использование auto для возвращаемого типа. В предыдущих версиях CLion не мог корректно вывести тип переменной vec, а значит и предложить корректное автодополнение:
Таким образом, из непокрытых возможностей стандарта C++14 остался только constexpr. И уже начата работа в направлении C++17: поддержаны nested namespaces. Полный список поддерживаемых в CLion возможностей современных стандартов C++ можно найти по ссылке.
Make auto
С появлением современных стандартов в C++ произошло много значительных изменений. Код на современном C++ существенно отличается от кода на C++ образца 98-го или даже 2003 года. И чем активнее язык развивается, тем актуальнее встает вопрос преобразования кода “старого” в “новый”. А что как не IDE может помочь справиться с этой задачей? Рефакторинги и другие преобразования кода – это как раз то, что мы в JetBrains очень любим.
Работа в этом направлении только началась, и идей у нас много. А пока что мы добавили возможность конвертации типа переменной в auto:
Обратная замена тоже может быть реализована и даже есть в планах (CPP-8555).
PCH
Precompiled headers (PCH) – это общепринятый способ сэкономить на времени компиляции, если в проекте используются большие заголовочные файлы или просто какой-то набор таких файлов используется очень часто. Притом эти файлы меняются редко. В такой ситуации есть смысл скомпилировать их единожды и в дальнейшем просить компилятор переиспользовать имеющуюся информацию.
В такой ситуации IDE должна разобраться, какие PCH передаются при компиляции, найти их и прочитать символы из этих заголовочных файлов, которые могут понадобиться для основного кода проекта.
Теперь CLion так умеет. Относится это как к PCH, так и к заголовочным файлам, передаваемым через опцию компиляции -include. То есть соответствующие классы, функции, и т. п. из таких заголовочных файлов корректно понимаются:
Обратите внимание, что для GCC есть небольшие ограничения, связанные с техническими особенностями реализации.
Дизассемблирование в отладчике
Один из самых популярных запросов в нашем трекере – возможность показа ассемблерного кода при отладке. В версии 2017.1 мы реализовали две важные возможности, связанные с этим запросом:
- Подсветка синтаксиса кода на Ассемблере в редакторе (работает только для диалекта AT&T) для файлов с расширением .s и .asm, или любых других, сконфигурированных в Settings | Editor | File Types | Assembly Language.
- Показ кода на дизассемблере (disassembly view) во время отладки при переходе на вызов, для которого нет исходных текстов программы.
Работает disassembly view пока только для GDB. По коду на дизассемблере можно походить, чтобы лучше понять, что именно делает программа и, возможно, найти проблему, ради которой и запускался отладчик. Поставить точки останова в таком коде пока нельзя.
На будущее запланирована возможность показа кода на дизассемблере даже в том случае, когда исходные коды программы имеются (CPP-9091).
Catch
Для C++ существует огромное множество тестовых фреймворков: Google Test, CppUnit, CppTest, Boost, QtTest и другие. CLion поддерживает Google Test уже довольно давно. А в версии 2017.1 появилась поддержка Catch. Почему именно Catch?
- Catch очень легко начать использовать. Чтобы подключить Catch к своему проекту, достаточно скачать и добавить в проект один единственный заголовочный файл. Удобно, не правда ли?
- Тест-кейсы в Catch достаточно гибкие и удобные.
- Автор фреймворка Catch, Phil Nash, с осени прошлого года работает с нами в компании JetBrains в роли девелопер-адвоката C++ продуктов компании. Так что параллельно с поддержкой Catch в CLion дорабатывался и сам фреймворк. Что, конечно, существенно помогло разработке.
Основное в поддержке – специальное окно с выводом результатов тестов (test runner). Если для запуска используется специальная Run/Debug конфигурация – Catch – то вывод результатов будет осуществляться туда:
Помимо удобного представления результатов, в этом окне можно:
- перезапустить все тесты или только упавшие;
- сортировать тесты по имени или по длительности прохождения;
- посмотреть/перейти на код конкретного теста;
- посмотреть вывод каждого конкретного теста и сообщения об ошибках;
- перенести результаты текущего запуска тестов в файл;
- посмотреть предыдущие запуски тестов по истории, которая сохраняется автоматически.
Кстати, в конфигурациях работает автодополнение для тегов, которые используются в тестах. Это помогает быстрее настроить набор тестов, которые надо запускать в рамках конфигурации.
Подробнее об особенностях и преимуществах Catch и его интеграции в CLion можно почитать в нашем англоязычном блоге.
Компилятор Microsoft Visual C++
Вероятно, одна из самых интересных возможностей этой версии. По-крайней мере, для пользователей на Windows. Дело в том, что раньше CLion работал только с GCC/Clang и на Windows приходилось устанавливать MinGW, MinGW-w64 или Cygwin. А они, в свою очередь, не всегда легко и понятно конфигурируются при установке, да и имеют ряд неудобств в целом. Так что пользователи на Windows вполне резонно просили нас поддержать компилятор Microsoft Visual C++. Что мы и сделали в 2017.1, правда пока в экспериментальном режиме.
Чтобы попробовать, надо включить соответствующую опцию в Registry:
- Откройте диалог Find Action (
Shift+Ctrl+Aна Linux/Windows,⇧⌘Aна macOS) - Введите Registry
- Выберите и откройте редактор Registry
- Начните вводить clion.enable.msvc – CLion найдет подходящую опцию в списке
- Включайте и пользуйтесь MSVC!
Теперь в настройках тулчейнов у вас появится возможность выбрать компилятор Microsoft Visual C++:
Поддерживаемые версии Visual Studio – 2013, 2015, 2017 – находятся и определяются автоматически.
Тут стоит оговориться, что работает MSVC по-прежнему через CMake (в качестве генератора в котором используется NMake вместе обычных Makefiles). То есть msbuild не поддержан. CLion предоставляет настройки архитектуры, платформы и версии в Build, Execution, Deployment | CMake:
Из важных ограничений стоит еще отметить: отсутствие отладчика и отсутствие поддержки специфических расширений языка от Microsoft. В остальном, мы будем рады, если те, кто был заинтересован в поддержке компилятора Microsoft Visual C++, попробуют его и поделятся с нами своими отзывами.
Zero-latency typing
Про zero-latency typing рассказывать можно довольно долго. Но мы лучше предложим читателям ознакомится с детальным исследованием этого вопроса от нашего коллеги.
В версии 2017.1 по умолчанию включили соответствующий режим, который до этого (в течение полугода) был в тестовом режиме. Само же решение позволяет уменьшить количество перерисовок редактора, тем самым уменьшая задержку между непосредственно печатью кода и его отрисовкой на экране.
Плагины
Версия CLion 2017.1 включает в себя полезные обновления таких плагинов как Swift, Go, Settings Repository и не только.
Если говорить про Swift, то на изменения стоит обратить внимание тем, кто использует или планирует использовать CLion в качестве Swift IDE на Linux. Благодаря команде AppCode в плагине появились новые возможности:
- шаблон для создания нового Swift проекта, с предварительно заполненным файлом CMake и Package.swift;
- ошибки, предупреждения и возможные исправления от анализатора кода на основе SourceKit;
- возможность генерации типа переменной уже после ее использования.
Изменения Go плагина были направлены на приведение его в соответствие с Gogland, отдельно стоящей IDE на базе платформы IntelliJ для этого языка.
А плагин для хранения настроек IDE в репозитории, наконец, был “забандлен” в саму IDE.
И многое другое
В версии 2017.1 произошло еще немало других изменений. Так, например, Find in Path (текстовый поиск по проекту или любому выбранному скоупу) доступен в виде popup-окна с удобным предпросмотром результата:
А в окне логов от системы контроля версий (для Git и Mercurial) появилась возможность использовать регулярные выражения и выбирать учитывать ли или наоборот игнорировать регистр.
Вот здесь небольшая демонстрация новых возможностей CLion 2017.1:
Если вам стало интересно, качайте 30-дневную бесплатную пробную версию, а в разделе цен можно узнать о стоимости подписки.
Следите также за статьями и обновлениями в нашем англоязычном блоге. Мы будем рады ответить на любые ваши вопросы в комментариях.
Ваша команда JetBrains CLion
The Drive to Develop
Комментарии (0)
Не останься в дураках 1го апреля – делай backup
Сегодня, во Всемирный день резервного копирования, который как раз предшествует первому апреля, мы закончили исследование, посвященное вопросам защиты и хранения данных, и хотим поделиться с вами его результатами.
Опрос пользователей проводился по всему миру на платформе Google Survey и показал, что более 34% респондентов хотя бы один раз сталкивались с потерей своих данных. Доля тех, кто активно использует решения для резервного копирования, составляет более 70%, и ключевыми показателями для них являются безопасность, простота в использовании и объем доступного облака.
Прошлый год, по мнению ведущих экспертов в области безопасности, стал годом программ-вымогателей. Да, они появлялись и раньше, но именно в 2016 году их распространение приняло масштаб настоящей эпидемии. Согласно данным исследования Лаборатории Касперского, за минувший год возникло 62 новых семейства программ-вымогателей, а количество их новых модификаций выросло в 11 раз — с 2,9 до 32 тысяч. Число атак с их использованием утроилось, а согласно данным Федерального бюро расследований США, общий ущерб от них перевалил за 1 миллиард долларов. Электронные письма, скаченные из интернета файлы, вложения в сообщениях социальных сетей — вот неполный список методов которыми эти вредоносные программы попадают в наши компьютеры, блокируют наши данные и требую за них выкуп.
Ситуация осложняется тем, что большинство пользователей ничего не знают о программах-вымогателях, и тем более не знают о способах противодействия им. Наше исследование показало, что более 62% респондентов никогда не слышали о подобной угрозе, хотя 67% опрошенных пользователей заявили, что очень дорожат своими данными, которые как раз и являются основной целью подобных программ.
Резервное копирование, являющееся наиболее простым и эффективным средством борьбы с потерей данных, может помочь и в случае атак программ-вымогателей. Несмотря на активность киберпреступников, решения для резервного копирования активно развиваются и приобретают новые фичи. Например с 2017 года мы начали внедрять технологию Acronis Active Protection, которая выявляет подозрительную активность на компьютерах и не дает вредоносным программам уничтожить пользовательские данные, их резервные копии, а также нарушить работу нашего решения. В основе технологии лежат поведенческие эвристики, которые выявляют подозрительную активность и предотвращают атаки программ-вымогателей. Такой подход вместе с интегрированным функционалом резервного копирования позволяет восстановить неограниченное количество файлов вне зависимости от их размера.
Подводя итог, мы хотели бы дать несколько простых советов, которые помогут защитить ваши данные, вне зависимости от того, где и как они хранятся:
- Всегда создавайте резервные копии важных данных. При этом старайтесь одновременно хранить резервные копии и на локальных, и в облачным хранилищах;
- Регулярно обновляйте вашу операционную систему и программное обеспечение, чтобы оперативно устранить бреши в безопасности, через которые проникают вредоносные программы;
- Относитесь внимательнее к подозрительным письмам, ссылкам и приложениям, как отмечалось выше, именно так программы-вымогатели проникают в вашу систему;
- Обязательно устанавливайте современные антивирусы на свой компьютер и включайте его автоматическое обновление.
В заключение, мы хотели бы пожелать всем подготовиться заранее к субботним розыгрышам, сделать бэкап своих данных 31 марта и не остаться первого апреля в дураках!
Комментарии (0)
[Из песочницы] Скачиваем историю переписки со всеми пользователями ВКонтакте с помощью Python
Для работы с сайтом нужно создать приложение и авторизоваться с помощью токена. Этот процесс не представляет из себя ничего сложного и описан здесь и здесь.
Итак, токен получен. Импортируем необходимые библиотеки (time и re понадобятся нам позже), подключимся к нашему приложению и начнем работу.
import vk
import time
import re
session = vk.Session(access_token='your_token')
vkapi = vk.API(session)
Так как мы хотим получить переписку со всеми друзьями, начнем с получения списка друзей. Дальнейшая обработка полного списка друзей может оказаться довольно долгой, поэтому для тестирования можно написать id нескольких друзей вручную.
friends = vkapi('friends.get') # получение всего списка друзей для пользователя
# friends = [1111111, 2222222, 33333333] # задаем друзей вручную
Имея список друзей, можно сразу приступить к скачиванию диалогов с ними, но я хочу обрабатывать только те диалоги, в которых содержится более чем 200 сообщений, так как короткие беседы с малознакомыми людьми мне не очень интересны. Поэтому напишем функцию, которая вернет «шапки» диалогов.
def get_dialogs(user_id):
dialogs = vkapi('messages.getDialogs', user_id=user_id)
return dialogs
Такая функция возвращает «шапку» диалога с пользователем, id которого равен указанному user_id. Результат её работы выглядит приблизительно так:
[96, {'title': ' ... ', 'body': '', 'mid': 333333, 'read_state': 1, 'uid': 111111, 'date': 1490182267, 'fwd_messages': [{'date': 1490173134, 'body': 'Не, ну все это и так понятно, но нам же там жить.', 'uid': 222222}], 'out': 0}]
В полученном списке содержится количество сообщений (96) и данные последнего сообщения в диалоге. Теперь у нас есть всё необходимое, чтобы скачать нужные диалоги.
Основное неудобство состоит в том, что ВКонтакте позволяет делать максимум около трех запросов в секунду, поэтому после каждого запроса нужно какое-то время ждать. Для этого нам и нужна библиотека time. Самое маленькое время ожидания, которое мне удавалось поставить, чтобы не получить отказ через несколько операций — 0.3 секунды.
Другая сложность в том, что за один запрос можно скачать максимум 200 сообщений. С этим тоже придется бороться. Напишем функцию.
def get_history(friends, sleep_time=0.3):
all_history = []
i = 0
for friend in friends:
friend_dialog = get_dialogs(friend)
time.sleep(sleep_time)
dialog_len = friend_dialog[0]
friend_history = []
if dialog_len > 200:
resid = dialog_len
offset = 0
while resid > 0:
friend_history += vkapi('messages.getHistory',
user_id=friend,
count=200,
offset=offset)
time.sleep(sleep_time)
resid -= 200
offset += 200
if resid > 0:
print('--processing', friend, ':', resid,
'of', dialog_len, 'messages left')
all_history += friend_history
i +=1
print('processed', i, 'friends of', len(friends))
return all_history
Разберемся, что здесь происходит.
Мы проходим по списку друзей и получаем диалог с каждым из них. Рассматриваем длину диалога. Если диалог короче, чем 200 сообщений, просто переходим к следующему другу, если длиннее, то скачиваем первые 200 сообщений (аргумент count), добавляем их в историю сообщений для данного друга и рассчитываем, сколько еще сообщений осталось скачать (resid). До тех пор пока остаток больше 0, при каждой итерации увеличиваем аргумент offset, который позволяет задать отступ в количестве сообщений от конца диалога, на 200.
Из-за необходимости ожидания после каждого запроса программа работает довольно долго, поэтому я добавил вывод небольшого отчета о текущем шаге, чтобы понимать, что сейчас обрабатывается и сколько еще осталось.
N.B.: у метода messages.get есть аргумент out, с помощью которого можно попросить сервер отдавать только исходящие сообщения. Я решил не использовать его и выделить нужные мне сообщения уже после скачивания по следующим причинам: а) файл все равно придется очищать, т.к. сервер отдает каждое сообщение виде словаря, содержащего много технической информации и б) сообщения собеседников тоже могут представлять интерес для моего исследования.
Каждое скачанное сообщение является словарем и выглядит примерно вот так:
{'read_state': 1, 'date': 1354794668, 'body': 'Вот так!
Потому что тут модель вышла довольно непонятная.', 'uid': 111111, 'mid': 222222, 'from_id': 111111, 'out': 1}
Далее осталось только очистить результат и сохранить его в файл. Эта часть работы уже не относится к взаимодействию с VK API, поэтому я не буду останавливаться на ней подробно. Да и что тут рассказывать — просто выбираем нужные элементы (body) для нужного пользователя и с помощью re удаляем переносы строк, которые отмечены тегом
Полностью код программы выглядит вот так:
import vk
import time
import re
session = vk.Session(access_token='your_token')
vkapi = vk.API(session)
SELF_ID = 111111
SLEEP_TIME = 0.3
friends = vkapi('friends.get') # получение всего списка друзей для текущего пользователя
def get_dialogs(user_id):
dialogs = vkapi('messages.getDialogs', user_id=user_id)
return dialogs
def get_history(friends, sleep_time=0.3):
all_history = []
i = 0
for friend in friends:
friend_dialog = get_dialogs(friend)
time.sleep(sleep_time)
dialog_len = friend_dialog[0]
friend_history = []
if dialog_len > 200:
resid = dialog_len
offset = 0
while resid > 0:
friend_history += vkapi('messages.getHistory',
user_id=friend,
count=200,
offset=offset)
time.sleep(sleep_time)
resid -= 200
offset += 200
if resid > 0:
print('--processing', friend, ':', resid,
'of', dialog_len, 'messages left')
all_history += friend_history
i +=1
print('processed', i, 'friends of', len(friends))
return all_history
def get_messages_for_user(data, user_id):
self_messages = []
for dialog in data:
if type(dialog) == dict:
if dialog['uid'] == user_id and dialog['from_id'] == user_id:
m_text = re.sub("
", " ", dialog['body'])
self_messages.append(m_text)
print('Extracted', len(self_messages), 'messages in total')
return self_messages
def save_to_file(data, file_name='output.txt'):
with open(file_name, 'w', encoding='utf-8') as f:
print(data, file=f)
if __name__ == '__main__':
all_history = get_history(friends, SLEEP_TIME)
save_to_file(all_history, 'raw.txt')
self_messages = get_messages_for_user(all_history, SELF_ID)
save_to_file(self_messages, 'sm_corpus.txt')
На момент запуска программы у меня в ВК было 879 друзей. На их обработку потребовалось около 25 минут. Файл с необработанным результатом имел объем 74MB. После выделения текста только моих сообщений — 15MB. Всего сообщений в полученном корпусе — около 150 000, а их текст занимает 3707 страниц (в вордовском документе).
Надеюсь, моя статья окажется для кого-то полезной. Все методы, которые можно использовать для обращения к API ВК, детально описаны в разделе для разработчиков ВКонтакте.
Комментарии (0)
[Из песочницы] Сравнение OpenMP на различных платформах
Всем привет! Недавно познакомился с замечательной штукой как OpenMP, на просторах есть много
описаний тут или тут, но нет красивых графиков которые бы показывали эффективность этой технологии. В этом посте я постараюсь наглядно показать эффективность работы с OpenMP на различных платформах. Кому интересно добро пожаловать!
В современном мире существует множество различных ОС и новых мощных процессоров, позволяющих производить сложные вычисления с относительно небольшими затратами времени. Данное исследование проводилось с целью выяснить в какой среде эффективнее всего производить трудоемкие вычисления, а также способы уменьшения затрат времени на вычисления.
Для проведения исследования был выбран алгоритм — вычисления числа ПИ с помощью интегральной формулы поскольку данный алгоритм хорошо поддаётся распараллеливанию и достаточно трудоёмкий с точки зрения вычислений.
Для распараллеливания алгоритма было решено использовать технологию openMP. Данная технология позволяет эффективно писать одинаковый код для разных сред выполнения, минимизируя погрешности, которые вносятся при написании кода программистом с использованием p_threads или Windows Threads, в ОС Linux и Windows, соответственно.
Для сравнения были выбраны 3 среды выполнения:
- Windows 10
- Windows Subsystem For Linux
- Linux дистрибутив Ubuntu 16.10 LTS
Тесты были проведены на компьютере с процессором.
-
Intel Сore i7-4771
Если про первые две системы слышали многие, WSL еще малоизвестна. WSL — фича, которая появилась в Windows 10 сравнительно недавно. Ядро ubuntu 14.04 было встроено в ядро Win10. Эта система позволяет запускать linux приложения, работая в Windows, более того пользователю доступно практически полное рабочее окружение использовать которое так-же просто, как открыть проводник. Прочитать про неё можно например тут .
Теперь графики
Данные представленные на графиках усреднённые, было выполнено по 5 прогонов теста для каждой ОС. По оси ординат на графиках время в секунду, значения делений оси абсцисс приведены в таблице
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 4 | 6 | 8 | 10 | 12 | 16 | 32 | 64 | 128 | 256 | 512 | 1024 |
Выводы
- openMP — технология, которая позволит решить проблему скорости разработки многопоточного приложения, но не избавит от других проблем.
- Многопоточность — сложная и важная тема, неправильное использование несомненно приведёт к ухудшению результата работы.
- Linux VS Windows — дают практически одинаковые результаты, а значит использовать стоит ту платформу которая предоставляет нужный стек технологий и позволяет минимальными усилиями решить поставленную задачу.
Спасибо за внимание.
Комментарии (0)
Пятничный формат: сегодня все дела можно отложить на потом
Сегодня мы решили вернуться к нашему традиционному формату, когда мы разбираемся с тем, есть ли жизнь после совещания, или чем тяжела жизнь программиста-интроверта в корпорации.
Поговорим о прокрастинации.
/ Фото Surian Soosay / CC
Необходимость заранее обдумывать свои действия до того, как приступить к работе — у начинающих программистов это может вызывать определенные сложности: иногда они просто не знают с чего начать. В этом материале будем разбираться, как бороться с прокрастинацией и можно ли получать от нее пользу.
Бой с тенью
У программистов есть определенное преимущество: иногда они могут автоматизировать какие-то рутинные задачи, чем облегчают свою жизнь. Но это возможно не всегда и не отменяет того факта, что самым сложным бывает начать работать.
Так как же бороться с прокрастинацией в этом случае?
Для начала мы решили поискать варианты от коллег по профессии и несчастью на Quora и нашли несколько интересных советов. Борьбу можно начать с составления четкого плана работы. Так вы сможете структурировать свои мысли и расписать пошаговый рецепт создания программы. А за выполнение каждого шага в срок можно даже наградить себя. Можно усовершенствовать план и внести в него какие-то приятные дела, которые будут выступать вознаграждением за работу. Стимулом может быть все что угодно, хоть что-нибудь вкусное на обед или кофе.
Другой вариант — разделить работу на более мелкие задачи. Это поможет, если задач слишком много и все они слишком абстрактны. Карл Фогель (Karl Fogel) в своей книге «Создание свободного программного обеспечения: Как вести успешный открытый проект» приводил результаты интересного эксперимента. Психологи разделили испытуемых студентов на две группы: у первой группы задания задействовали абстрактное мышление, а у второй — конкретное. За выполнение заданий всем студентам должны были заплатить.
В результате студенты из второй группы прислали выполненные задания раньше срока. А вот те, кто работал с абстрактными задачами, в основном присылали все в последний момент, а некоторые и вовсе не вышли на связь. Это доказывает, что абстрактные размышления о работе могут способствовать прокрастинации, а четкий план, наоборот, стимулирует активную деятельность.
Сегодня существуют разные техники тайм-менеджмента, которые обещают помочь прокрастинаторам и основаны на разделении рабочего дня на временные отрезки. Один из таких методов называется (10+2)*5, и его суть заключается в том, что в течение часа надо делать двухминутные перерывы через каждые 10 минут. Такой прием подойдет тем, кому совсем сложно сосредотачивать внимание и кто постоянно отвлекается на проверку социальных сетей, почты и просмотр смешных картинок. Теперь это можно делать вполне «законно», но только не дольше двух минут.
Еще одна техника связана с разделением работы на более длительные отрезки времени. Называется она «Pomodoro» (от таймера в виде помидора). Автор техники предлагает ставить таймер на 25 минут. После каждого такого временного промежутка, посвященного работе, можно давать себе пятиминутный отдых. После четырех отрезков по 25 минут можно позволить себе отдохнуть уже целых 20-30 минут. Эффективность такого подхода объясняется тем, что психологически человеку не надо настраиваться на выполнение всего объема работы, нужно всего лишь сосредоточиться на 25 минут. А это уже намного легче.
Кроме того, многие прокрастинаторы любят оттягивать выполнение дел до дедлайна. А тут дедлайн они устанавливают себе сами, причем время до него отсчитывает тикающий таймер.
Разработчики отмечают, что необязательно прибегать к этой технике каждый день. Но она может пригодиться для рутинных и скучных дел. К тому же многие подстраивают ее под себя: кто-то предпочитает делить время на большие отрезки, например, на 50 минут, что, в принципе, не противоречит сути тайм-боксинга, на котором основан метод «Pomodoro».
Техника спешит на помощь
Совсем необязательно покупать специальный таймер, так как сегодня существует широкий ассортимент приложений «Pomodoro». Суть их работы почти всегда одинакова — они отсчитывают время. Но у некоторых есть интересные бонусы: например, PomoDone предлагает интеграцию с Basecamp, Todoist, Evernote и многими другими программами. Pomodoro Keeper дает возможность просмотра статистики, чтобы проанализировать, когда продуктивность была выше всего. А в Be Focused есть функция добавления списка задач прямо в приложение и привязки таймера к конкретным пунктам.
Procraster объединяет в себе и тайм-боксинг, и вознаграждения, которые можно выбрать из списка или добавить собственные варианты. Но, кроме этого, ему можно пожаловаться на причины того, почему вы пытаетесь отложить работу, а приложение предложит варианты решения вашей проблемы. Но помимо приложений-таймеров есть и более изощренные средства по борьбе с прокрастинацией.
Например, в Finish можно заносить данные о текущих задачах, которые делятся на кратко-, средне- и долгосрочные. При этом приложение постоянно напоминает обо всех этих заданиях, пока вы не отметите их, как выполненные. Конечно, существуют и специальные программы, которые не позволят вам отвлекаться на соц.сети и любые устройства. Некоторые из них умеют блокировать приложения, а некоторые ограничивают использование, например, телефона, на определенный отрезок времени.
Еще одно исследование на студентах, проведенное Корнелльским университетом, показало, что использование таких приложений положительно сказалось на их желании учиться: в группах, пользовавшихся техническими средствами, курсы MOOC от Стэнфордского университета закончили на 40% больше студентов.
Кроме того, «подопытные» из этих групп тратили на 24% больше времени на написание курсовой работы и на 27% больше времени уделяли домашней работе. Но приложения можно использовать не только для повышения своей дисциплины. Например, Avoiding Procrastination 101 представляет собой целый сборник советов, которые помогут победить прокрастинацию и замотивируют на усердную работу.
Что почитать
Читать, конечно, можно не только приложения. Существует много полезных книг, которые могут перевернуть ваше представление о том, как надо жить и работать, и научат не тратить время впустую. Например, в своей книге «Все еще тянете время? Руководство по завершению незаконченных дел» Джозеф Р. Феррари (Joseph R. Ferrari), который уже больше 30 лет занимается исследованием прокрастинации, разграничивает настоящих прокрастинаторов и просто тех, кто любит откладывать дела на потом.
Первым требуется помощь специалистов, а вторые вполне могут сами взяться за свою жизнь. Главное, определить причины такого поведения. В своей книге он дает много интересных советов, например, предлагает объединиться в офисе с самыми продуктивными коллегами и равняться на них. Кроме того, он уверен, что нужно развивать в себе пунктуальность и строго придерживаться временных рамок. Но пока прокрастинатор не достигнет самого дна и не опозорится из-за своей пагубной привычки, по мнению ученого, менять свое поведение он вряд ли захочет.
Книга «7 навыков высокоэффективных людей» бизнес-консультанта Стивена Р. Кови (Stephen R. Covey) посвящена далеко не только прокрастинации, но и в ней можно найти полезные советы по борьбе с этим недугом. Именно Кови ввел матрицу времени, которая делится на 4 части и включает «важные и срочные» дела, «важные и несрочные», «неважные и срочные» и «неважные и несрочные». Распределение собственных дел в начале недели в такой матрице, по мнению автора, может намного повысить вашу эффективность и предотвратить желание отложить некоторые дела на потом.
Пирс Стил (Piers Steel), профессор психологии, занимающийся исследованием прокрастинации в Университете Калгари, написал книгу «Уравнение прокрастинации: как перестать откладывать все на потом и начать делать», где он объясняет психологические причины, по которым люди любят откладывать все на завтра. Узнав своего врага изнутри, читатели могут научиться понимать механизмы этого явления и более эффективно справляться с ним. Почитать другие статьи автора по теме прокрастинации можно тут.
Бывший сотрудник Google, разработчик (Edmond Lau) написал книгу, которую назвал «Справочник эффективного инженера». В ней он рассказывает, как можно достичь большего, работая меньше. Например, каждый раз, когда программист берется за задачу, он должен быть уверен, что она принесет ему максимальную пользу. Тогда можно будет сказать, что он эффективно потратил свое время. Это учит по-новому оценивать время и не растрачивать силы на более мелкие и неважные задачи.
Это норма
Прокрастинация может быть не так уж плоха, как о ней говорят. Многие люди научились использовать ее во благо и больше не пытаются вступить с ней в войну. Так, философ Джон Перри (John Perry) из Стэнфордского университета считает, что откладывание на потом может сделать прокрастинатора полезным членом общества. Для этого необходимо поддерживать круговорот дел в работе.
Ведь хорошо известно, что на потом откладываются самые важные дела. Но со временем появляются другие очень важные дела, вот тут-то и можно взяться за те, что померкли перед важностью и срочностью новых. Главное правило — нельзя пытаться избавиться от всех остальных более мелких дел. Ведь когда делать будет нечего, то вместо того, чтобы подобраться к той самой главной задаче, прокрастинатор начинает бездействовать и превращается в лентяя. Такой способ, однако, подойдет не всем, так как в проектной работе дедлайны обычно очень жесткие и ждать, когда задача уступит место по важности какой-то другой времени нет.
А вот Пол Грэм уверен, что прокрастинаторы бывают двух типов: пассивные и активные. И то, что описывает Джон Перри, как раз относится к активной, или хорошей прокрастинации, когда человек может занимается другими делами и становится даже более продуктивным. Еще один плюс такой системы — освобождение от лишних дел. Иногда со временем оказывается, что поставленная задача больше не актуальна.
Кроме того, если человек все время откладывает определенные рабочие задачи, может, стоит прислушаться к этим сигналам и проанализировать ситуацию. Может, эта работа на самом деле вам не подходит? Или сам проект, над которым вы работаете, не кажется вам хорошим? Решений может быть несколько: можно сменить работу, а можно постараться делегировать какие-то обязанности. В любом случае прокрастинация хороша тем, что позволяет понять, что именно вы любите и чем вам нравится заниматься, так как именно за такие дела в первую очередь принимаются желающие потянуть резину.
Главное, не заразиться пассивной формой этой «болезни» и не стать бездельником. Хотя прокрастинаторы любят говорить, что тратят на работу меньше времени: то, что они могли сделать за неделю, они делают за пару дней и ночей. Но помимо ухудшения качества, чаще всего все оставшееся время они проводят достаточно бесполезно. В среднем человек живет 27 тысяч дней или 650 тысяч часов. Это кажется большой цифрой, пока мы не задумываемся, на что именно мы тратим эти часы.
Например, только на работу человек в среднем тратит 10 лет своей жизни. А сколько из этих лет было потрачено на прокрастинацию? Но ведь мы поддаемся ее влиянию и в бытовых вопросах. Так давайте прямо сегодня возьмем и начнем делать то, что уже давно откладывали в долгий ящик! Хотя, подождите, сегодня же пятница, наверное, лучше будет начать с понедельника…
Комментарии (0)
Технологии песочниц. Check Point SandBlast. Часть 1
Уверен, что все кто интересуется вопросами информационной безопасности, знакомы с выражениями: "Таргетированная (целевая) атака", "Уязвимость нулевого дня", "0-day" или даже Advanced Persistant Threats (ATP). Данные темы можно смело назвать главным трендом в сфере Информационной безопасности. Те же шифровальщики являются одним из подвидов перечисленных угроз. На сегодняшний день, Песочницы (SandBox) это единственные средства, которые позволяют бороться с выше упомянутыми угрозами. Большинство лидеров в сфере ИБ (CheckPoint, Fortinet, PaloAlto, FireEye, TrendMicro и т.д.) уже обзавелись решениями класса «сетевые песочницы». И если еще пару лет назад многие относились к данным решениям как к чему-то экзотическому, то сейчас большинство признают, что Песочницы становятся чуть ли не обязательными для любой защищенной сети. Однако в рунете довольно мало информации о подобных продуктах и принципах их работы. В связи с этим мы решили поделиться собственным видео курсом, где вкратце рассмотрим основные моменты. В качестве примера, мы на практике покажем возможности работы решения CheckPoint SandBlast, его особенности и отличия от других решений.
Курс состоит из трех частей. Первая часть будет посвящена обзору текущей ситуации в мире ИБ, после чего мы сделаем некоторые выводы относительно эффективности традиционных средств защиты. А чтобы не быть голословными, мы на практике рассмотрим пример процесса заражения компьютера жертвы (с помощью Kali Linux). В тексте будет довольно много картинок из презентации и если вам лень читать, то можете посмотреть видео в конце статьи. Всем заинтересовавшимся добро пожаловать под кат...
ВВЕДЕНИЕ
Первое с чего хотелось бы начать, это с небольшой статистики по Информационной безопасности.
Многие до сих пор воспринимают ИБ как нечто мифическое. Но это ошибочное мнение. Если посмотреть статистику, любезно предоставленную компаниями CheckPoint, Cisco, Garnter, то можно выделить следующие цифры для 2016 года:
И что самое интересное, ситуация с ИБ с каждый годом только ухудшается. Связано это в первую очередь с мотивацией хакеров. Их становится больше. Вопрос, почему? Для ответа на этот вопрос достаточно проанализировать рынок киберпреступности за последнее время:
При этом все труднее становится вычислить хакера, даже если это обычный школьник.
- Используя Bitcoin можно без опаски принимать платежи от своих жертв.
- Анонимные сети TOR позволяют безопасно выходить на рынок вредоносного ПО. Вы можете купить готовый вирус и начать свою вредоносную активность практически сразу.
- А учитывая успешность современных атак (например шифровальщиков) хакер начинает зарабатывать практически сразу. Средняя цена выкупа информации — 300-500 долларов.
Т.е. нужно понять, что киберприступность, это реальный рынок, где можно заработать реальные деньги. При этом профессия хакера становится проще и соответственно популярнее. Таким образом, когда речь заходит об Информационной безопасности, не стоит подходить к этой теме с вопросом "Если меня взломают, то…". Более правильным вопросом будет "Когда меня взломают, то…" потому что если не реагировать адекватно на постоянно растущие угрозы, то вас однозначно взломают. Примите этот факт и попробуйте посчитать стоимость последствий.
СРЕДСТВА ЗАЩИТЫ
Какие же средства защиты мы имеем на сегодняшний день?
Многие до сих пор используют Традиционные межсетевые экраны. Это либо stateful inspection, либо даже port based. Данный межсетевой экран совершенно не применим на периметре сети. Большинство современных атак осуществляется в рамках разрешенных сетевых подключений (tcp, http, smtp и т.д.). Классический МЭ просто не видит все эти угрозы.
Для современной сети нам требуется комплексная защита. К примеру NGFW или UTM устройства, которые по сути являются ответом на современные потребности. На самом деле, здесь у нас огромный выбор. Можно выбрать UTM решения, можно специализированные узконаправленные решения, такие как Anti-Spam, Aplication Firewall, DDoS Protector, SIEM и т.д).
Однако стоит заметить, что практически все наиболее значимые игроки ИБ со своими решениями бьются за 2-5% в проводимых тестах. В остальном все идут более менее вровень. Это можно видеть во всевозможных квадрантах Гартнера:
Однако вот какая интересная штука. По отчету того же Гартнер, 95% всех атак в прошедшем году можно было предотвратить, если бы были грамотно настроены существующие средства безопасности (вне зависимости от выбранного вендора).
Эти 95% — это так называемая атака на дурака. Берутся известные вирусы или трояны и раскидываются куда только можно. При этом есть очень интересная статистика. В новогодние и летние периоды кол-во атак значительно возрастает. Как вы думаете с чем это связано? А связано это с тем, что большое кол-во школьников и студентов отправляются на каникулы и начинают развлекаться представляя себя в роли хакера. И как было сказано выше, из-за плохой настройки существующих средств, довольно большой процент “детских” атак оказывается успешным. На этом печальная статистика не заканчивается. Большинство таких зловредов еще долгое время остаются в сети компаний, их просто не могут заметить.
В чем же причина? Как правило все упирается в непрозрачную систему управления средствами защиты. Особенно ярко это проявляется если использовать специализированные средства от разных вендоров. Отсутствие централизованной системы мониторинга и системы корреляции событий (т.е. SIEM), также негативно сказывается на времени обнаружения инцидентов ИБ. Идеальным вариант это когда средства защиты интегрируются друг с другом. В этом плане UTM устройства выигрывают у специализированных узконаправленных средств. К тому же их гораздо проще изучать и эксплуатировать, даже если это делает один человек.
ПОЧЕМУ CHECKPOINT?
И все же, почему мы решили рассмотреть именно CheckPoint? Как я уже сказал ранее, чаще всего разница в эффективности средств защиты это всего лишь несколько процентов. Мы не будем их обсуждать, хотя и в этом случае CheckPoint показывает лучшие результаты.
Одно из самых главных преимуществ CheckPoint, это система управления!
Именно качественная систему управления является залогом эффективной защиты. Система управления CheckPoint является признанным лидером на рынке ИБ уже долгое время. Это уже фактически «золотой стандарт». И совсем недавно была анонсирована новая версия — R80. Однако наш курс не об этом. Но мы обязательно обсудим это в новом курсе.
Если резюмировать все вышесказанное, то можно сделать вывод, что Сегодня одним из самых важных аспектов, при выборе средств защиты, является комплексная и в то же время легко управляемая система защиты, которая позволит даже одному человеку мониторить и анализировать все происходящее в сети. Так сказать, держать руку на пульсе.
СОВРЕМЕННЫЕ СПОСОБЫ АТАК
Теперь давайте рассмотрим современные способы атак и мифы связанные с ними:
- Вопреки расхожему мнению, заразиться можно не только на сайтах для взрослых. Ошибочное мнение, что если закрыть на прокси сервере все развлекательные сайты, то пользователи будут в безопасности. Это далеко не так. Хакеры могут заразить довольно известные сайты и тогда зловред можно будет “подхватить” даже на новостном портале, форуме или соц. сетях.
- Почта также является излюбленным инструментом хакера. Но зараженное письмо может прийти не только в виде спама. Вирус в буквальном смысле можно получить по почте от своего начальника, злоумышленнику достаточно подменить адрес либо отослать письмо с похожего домена.
- Также бытует мнение, что если вирус все же попадет на компьютер, то ничего страшного не произойдет и с ним впоследствии справится антивирус. Это в корне не верно. Современным зловредам достаточно нескольких секунд, чтобы существенно испортить вам настроение. Антивирус не успеет среагировать. Ярким примером являются шифровальщики, которые запустившись начинают шифровать ваши данные. И даже если антивирус впоследствии обнаружит эту активность, то данные уже будут зашифрованны.
Шифровальщики…. Это является ярким примером возможности атак нулевого дня. В лучшем случае вы подхватили старый шифровальщик, который вы случайно скачали с общественного сайта, который был взломан нерадивым студентом. Тогда есть возможность найти ключ в интернете, которые периодически публикуются в сети. Но есть вариант, что вы подцепили нечто новое, еще неизученное, сервера хакеров еще не были скомпрометированы и в доступе нет ключей. Шифровальщики пожалуй наиболее долго играющие зловреды из всех. В этом случае у вас нет ни малейшего шанса восстановить свои данные и Придется заплатить.
Т.е. в описанной ситуации вас не спасут классические средства защиты вроде IPS, AntiVirus, AntiBot, которые работают с известными сигнатурами. Сигнатурный анализ умрет в ближайшее время.
Сам концепт сигнатуры подразумевает, что уже была замечена успешная атака. И этой первой атакой может быть компьютер в вашей сети. В сигнатурах просто пропадает смысл. Некоторые вирусы или зараженные файлы были замечены всего один раз. При этом новый зловред создается буквально в пару кликов. Либо одной командой, как это изображено на рисунке выше.
АТАКИ НУЛЕВОГО ДНЯ
Здесь мы уже плавно переходим к таргетированным атакам, или атакам нулевого дня. Таргетированные или целенаправленные атаки это самый опасный вид атак. Часто их называет атаками нулевого дня, т.к. ранее они были неизвестны. Здесь приведена небольшая статистика:
Подобная атака нулевого дня разрабатывается под конкретную компанию и даже под конкретного человека. Подготовка к атаке может включать даже элементы социальной инженерии. Вредоносное ПО может размещаться на сайте, которому жертва доверяет. Весьма часто взломать сайт гораздо проще чем инфраструктуру жертвы. Зловред также может хитрым способом доставляться по почте. При этом хакеры очень редко повторяются. Что так же сильно усложняет их поимку.
Сам процесс атаки в целом выглядит следующим образом:
Как же бороться со злоумышленниками, если традиционные средства защиты больше не эффективны? Ответ на этот вопрос дает технология CheckPoint SandBlast, которой и будет посвящен данный мини курс.
Но обо всем по порядку и для начала мы выполним несколько лабораторных работ.
ВИДЕО КУРС ПО ПЕРВОЙ ЧАСТИ
Как было сказано выше, всю теоретическую часть данного поста можно посмотреть в видео формате:
Если вам интересно посмотреть насколько просто “взломать” компьютер жертвы, то можете ознакомиться с записями лабораторных работ.
1) В первой лабораторной работе мы опробуем следующий сценарий:
- Заразим компьютер пользователя перейдя по ссылке в письме. Для этого будет использован metasploit, с помощью которого мы проэксплуатируем уязвимость adobe flash.
- Получим удаленный доступ с помощью дистрибутива Kali Linux. Для этого используется Reverse TCP
- Изучим логи на предмет подозрительной активности (по факту мы ничего не увидим...).
- Сделаем выводы об использовании традиционных межсетевых экранов.
2) Во второй лабораторной работе мы повторим эксперимент, но только в этот раз активируем дополнительные программные блейды, чтобы посмотреть, что же происходит в момент заражения:
- Настроим на Check Point дополнительные блейды (Identity Awareness, IPS, AntiVirus, AntiBot, Threat Prevention).
- Включим режим detect.
- Повторно заразим компьютер жертвы.
- Изучим логи на предмет подозрительной активности.
- Активируем режим prevent.
- Заблокируем удаленный доступ.
На этом первая часть курса завершена. В последующих двух модулях мы на практике рассмотрим работу песочниц.
P.S. Если вы первый раз слышите о том, что такое Check Point, то рекомендуем ознакомиться с этой статьей.
P.S.S После завершения этого курса мы продолжим рассматривать процесс настройки Check Point для проведения бесплатного аудита Security CheckUP.
Комментарии (0)
[recovery mode] Necurs, один из крупнейших ботнетов мира, получил DDoS-модуль
Ботнет Necurs известен как один из крупнейших ботов мира. Его владельцы задействуют мощности своего детища для рассылки огромного количества спам-сообщений. Их объем настолько большой, что работа Necurs заметно влияет на общий размер e-mail трафика во всем мире. Вообще говоря, Necurs — не просто спамбот, это достаточно опасное malware, которое заражает уязвимые системы, подтягивая основной модуль ботнета и соответствующие модули.
Существует и работает Necurs уже несколько лет. За это время он стал объектом исследования многих специалистов по информационной безопасности. Эксперты смогли узнать, какие уязвимости системы использует атакующая часть ботнета и какой протокол используется спам модулем. Но сама платформа не статична, она меняется и совершенствуется.
Около полугода назад специалисты компании Anubisnetworks обратили внимание на то, что Necurs теперь работает не только с 80 портом, но и с другими портами, которые относятся совсем к другому протоколу передачи данных. Вот пример анализа трафика Necurs.
Изучая этот аспект, специалисты компании смогли понять, что на самом деле, ботнет активизировался для того, чтобы установить в пораженных системах модуль, обеспечивающий Necurs возможность проводить DDoS атаки.
В первом случае идет установка спам-модуля, который хорошо знаком специалистам. Здесь есть упоминание С2 адресов, которые связаны с новыми спам-кампаниями. А вот во втором случае указаны параметры неизвестного доселе модуля, который ведет обмен данными с сервером через 5222 порт.
Примерная дата «релиза» этого модуля — 23 августа 2016 года. Правда, существует вероятность того, что это была предварительная версия, замененная финальной.
Сотрудники кампании скачали модуль и провели реверс-инжиниринг для того, чтобы понять, что он собой представляет. На первый взгляд, это простой SOCKS/HTTP модуль. Но если всмотреться получше, становится понятно, что у этого модуля есть возможность работы с HTTP и UDP запросами, которые ставятся в бесконечный цикл. Соответственно, становится понятно, что этот модуль предназначен для осуществления DDoS атак.
Кстати, ботнет действительно большой — инфицированных активных элементов в этой сети насчитывается более миллиона. При таком размере это очень удобный вариант для проведения DDoS атак. Некоторые зараженные элементы сети являются ее частью уже более двух лет. Столь долго ботнет продержался благодаря осторожности его владельцев, которые с осторожностью распоряжаются полученными возможностями.
Как только модуль загружается в систему-жертву. Выполняются такие действия:
* Идет парсинг параметров и настроек;
* Собирается база данных внутренних IP адресов системы, равно, как и база внешних;
* Определяется пропускная способность сети;
* Определяется случайный порт;
* Ботнет пытается выяснить, спрятана ли основная система за NAT или нет;
* Если нет, то бот запускает сервис SOCKS/HTTP для произвольного порта, большего 1024.
После инициализации бот пробует подключиться к текущему C2 каждые 10 минут. Он делает это до тех пор, пока операторы не дают команду остановиться.
Кроме того, ботнет оснащен SOCKS/HTTP модулем, что позволяет оператормам платформы использовать скомпрометированные элементы ботнета как прокси (протоколы HTTP, SOCKSv4 и SOCKSv5). Работа с прокси ведется в двух режимах: direct proxy и proxy backconnect.
Что касается первого режима, то здесь принцип работы простой:
Но работа в таком режиме возможна, только если зараженная система не скрыта за NAT или не защищена файерволом. А таких систем буквально единицы.
Что касается режима proxy backconnect, то здесь все сложнее.
Зато работа в таком режиме возможна и в том случае, если зараженная система находится за NAT или файерволом. В этом случае можно подключаться к внутренним ресурсам сети, частью которой является зараженная система. Причем подключение ведется со стороны самой системы. Еще один способ работы с такими прокси — постоянная смена IP адресов.
DDoS модуль
Но интереснее всего не прокси, а новый DDoS модуль. Он предусматривает возможность проведения базовых атак двух типов. Несмотря на то, что здесь нет никаких ухищрений вроде методов усиления атаки, масштабы бота позволяют его операторам обойтись и без хитростей.
При получении команды операторов ботнет атакует определенную цель с использованием HTTP или UDP флуда, как и указано выше.
HTTP работает в 16 параллельных потоков запросов.
Запрос формируется следующим образом.
Что касается UDP, то здесь все несколько иначе — ботнет отправляет пакеты с радомным размером от 128 до 1024 байт.
Пока что DDoS-атак с использованием Necurs не зафиксировано. Но проведение таких атак возможно в любой момент. А ведь Necurs даже больше, чем Mirai, при помощи которого злоумышленники атаковали несколько крупных телекоммуникационных организаций в разных странах мира. Правда, некоторые специалисты считают, что DDoS-модуль в Necurs предназначен не для проведения заказных атак, а для собственных нужд операторов ботнета, например, для атаки на ресурсы конкурентов.
Комментарии (0)