Откуда есть пошёл насущный вопрос

С ростом объёма неструктурированных данных организации вопрос управления её информационными ресурсами (в частности, распределения прав доступа) перестаёт быть простым и становится проблемой, а за определёнными пределами – перерастает в настоящий кошмар. Кое-кто наверняка помнит, что на одноимённом уровне сложности происходило с монстрами в Doom: они плодились бесконтрольно, и вопрос для 99% игроков был не в том, сможете ли вы выжить, а в том, как долго продержитесь. Примерно то же самое начинает происходить и с данными: со временем их объём не только не снижается – он растёт, причём независимо от штата организации. Количество сотрудников может даже уменьшиться, но… Папка с сочетанием «2002 год» в названии? Она нам нужна. Марья Ивановна уволилась три года назад? Не трогайте её профиль, там ценные документы. А ещё мы вот тут создадим папочку. И тут. И вот здесь тоже очень нужно…

Увеличение штата специализированных подразделений – дело само по себе затратное – не выход: прибегать к такому решению постоянно (хотя бы догоняя скорость роста данных) не получится даже при всём желании. А ведь у таких подразделений есть множество других задач, зачастую более важных и также требующих огромного времени.



Что же делать? Очевидно, нужно качественное иное решение вопроса, и цель его – куда-то переместить нагрузку, создаваемую при управлении данными. Идеально, если ресурсы для обработки такой нагрузки будут расти пропорционально её увеличению. А если помечтать – чтобы росли автоматически, без меня. Эх. … Так. Но постойте… Ведь у нас уже есть вся база для создания такой почти самобалансирующей системы!

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

О чем статья

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

С этой точки зрения, очень интересным будет ресурс Kaggle[1], который превращает исследование данных в спорт. Там проводят соревнования по анализу данных. Некоторые соревнования — с обучающими материалами и предназначены для начинающих. Вот именно обучению анализу данных, на примере решения одной из обучающих задач, и будет посвящён цикл статей. Первая статья будет о подготовке данных и использованию СУБД для этой цели. Собственно, о том, как и с чего начать. Предполагается что читатель понимает SQL.

Утилита mimikatz, позволяющая извлекать учётные данные Windows из LSA в открытом виде, существует с 2012 года, однако помимо хорошо освещённого функционала восстановления паролей из памяти работающей ОС у неё есть ещё одна довольно интересная возможность. Далее я приведу пошаговую инструкцию, как при помощи нехитрых действий извлечь учётные данные из файла hiberfil.sys.

Подготовка

Для осуществления задуманного нам понадобятся следующие утилиты:

• Debugging Tools for Windows;
• Windows Memory toolkit free edition;
• И, собственно, сам mimikatz.

Во второй половине 2014 года мы уже неоднократно упоминали про целевые атаки на крупные финансовые учреждения как новую ступень мошенничества. Ведь теперь денежные средства похищают не у «мелких юрлиц», а у крупных финансовых компаний, в которых, казалось бы безопасность должна быть на высшем уровне и сложность совершения преступления приближается к «Hell». Однако, учитывая не стихающий поток подобных преступлений, а также особую актуальность на фоне текущего финансового состояния страны, мы решили обновить пост и добавить новых подробностей касательно группы Anunak, которая использует одноименного трояна, также известного как Carbanak. Название Carbanak происходит от склейки двух слов Anunak+Carberp.

Краткий экскурс

После задержаний членов группы Carberp в России, некоторые участники остались без работы, однако, полученный за долгие годы работы опыт позволил им занять новую нишу. Один из участников быстро понял, что можно украсть тысячу раз по $2 000 и заработать 2 миллиона долларов, а можно украсть всего лишь один раз и сразу всю сумму.

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

Основной костяк преступной группы составляют граждане России и Украины, однако есть лица, оказывающие им поддержку из Белоруссии.

Если сайт взломан, мало удалить с него вирус и загруженный PHP Shell. Нужно еще найти причину, по которой произошел взлом, иначе через день-два на сайте снова будет под бодрую музыку развеваться красивый турецкий иностранный флаг. Чаще всего причина — украденный пароль от FTP, устаревшая версия CMS или плагина к ней, но как найти, что именно было использовано для проникновения?

Имея некоторый опыт в этой сфере (в среднем наша техподдержка занимается поиском причины взлома сайта раз в неделю), мы систематизировали накопившуюся информацию.

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

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

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?