Pull to refresh
122
0
Sergey G. Brester @sebres

Senior Engineer; Data Scientist; Security Auditor

[Окончание] Новогодний детектив: странный хайзенбаг в «питоньих» часах

Reading time 12 min
Views 3.8K


Здесь лежит окончание "расследования" Новогодний детектив: странный хайзенбаг в «питоньих» часах.
Изначально хотел просто обновить статью и написать соответствующий комментарий, но понял что апдейт выходит чуть не длиннее самой статьи.


Напомню краткое содержание предыдущей части: python, как впрочем и всё на нем написанное, временами прыгает в будущее, а конкретно в 2023-й год в локальной временной зоне, и по некоторым данным в 2024-й в UTC/GMT (но это не точно) и побыв там некоторое время возвращается обратно в настоящее.


Во время прыжка оно ведет себя довольно стабильно (т.е. считает нано-, микро- и миллисекунды, а то и секунды, как будто время идет как ни в чём не бывало) в 2023-м т.е. локально, при том что в результате повторных прыжков время вновь продолжается как будто по возвращению оно (время) течет в какой-то параллельной вселенной. Однако странное его "отражение" в UTC/GMT, ну то что как будто бы в 2024-м, выглядит менее стабильно, ибо для него наблюдается странные дрейфы дополнительно к смещению прыжка.


Хотя куда уж страннее.

Читать дальше →
Total votes 17: ↑15 and ↓2 +13
Comments 9

Новогодний детектив: странный хайзенбаг в «питоньих» часах

Reading time 8 min
Views 15K


Давненько я не писал на Хабр, да и тема интересная появилась, так что пора поправить это постыдное упущение.


Далее собственно детектив как оно есть, "расследование" которого ещё не окончено, можно присоединиться кстати… Пост будет обновляться, по окончанию (я надеюсь что баг таки найдётся) пост изменит название получив префикс "[SOLVED]"...
Продолжение и надеюсь окончание истории см. в этом посте.


Постучался тут человечек на GH, с ошибкой типа "Fail2ban ведет себя как-будто он временами в будущем". Первой мыслью было — что опять! ну снова кто-то во временных зонах потерялся.
Но нет, всё оказалось несколько хуже — иногда, редко, Fail2ban пишет в логи дату из 2023-го года.
И не только пишет, а по всей видимости действительно начинает считать что он где-то в 2023-м, со всеми вытекающими — снятием бана для блокированных адресов по истечению срока действия и т.д. и т.п.
Причем делает это для всех потоков, а чуть позже возвращается в 2021-й, чтобы позднее снова на короткое время прыгнуть в 2023-й и так снова и снова.

Читать дальше →
Total votes 58: ↑58 and ↓0 +58
Comments 42

Магелланова ошибка: Buffer overrun или кругосветная экспедиция средствами SQLite FTS

Reading time 3 min
Views 3.6K

Как-то обошли на Хабре недавнюю Magellan-ошибку и связанные с ней уязвимости, попробую исправить это упущение.


Немного истории


  • 1 Ноября 2018 в Chromium прилетел баг-репорт за номером 900910: "Multiple issues in SQLite via WebSQL." Об ошибке сообщает Wenxiang Qian из Tencent Blade Team.
  • 5 Ноября 2018 ошибку закрывают в ядре библиотеки SQLite (FTS3), где она собственно и живет чуть не со времен создания модуля, т.е. с ноября 2009-го года.
  • 28 Ноября 2018 оно вливается в Chromium
  • Чуть позже Tencent Blade Team публикует сообщение об ошибке, дав ей название Magellan, особенно не раскрывая при этом подробностей, и указав, что публикация готовых эксплойтов и PoC пока не планируется.
  • Через неделю в интернете полно PoC, крэшащих Chrome, Electron dev-framework и т.п. Доказательств и каких-либо других сведений, что уязвимость использовалась в злонамеренных целях по прежнему нет.
  • DRH, подтвердил подозрения на Hacker News, что уязвимость имеет место (как минимум если допускается исполнение "чужого" SQL-запроса, или SQL Injection подобного сценария).

Что может быть подвержено уязвимости?


Потенциально, все устройства и программы, использующие SQLite (с включенным FTS) или использующие или на нем базирующиеся приложения (как например Chromium). Степень насколько они могут быть затронуты и эффект возможного "поражения" зависят от того, найден ли подходящий вектор атаки.


Немного подробнее о Magellan SQLite BUG

Читать дальше →
Total votes 18: ↑18 and ↓0 +18
Comments 7

Epic fail of the month: rsync как «вектор» на утянуть данные

Reading time 3 min
Views 16K

Изначально просто хотел бросить ссылкой к некоторым комментариям для первой ветки вот этой статьи, в качестве примера, почему торчать портами наружу (почём зря) — не есть хорошо.
Ну и ответ вырос в простыню в эту статью, да и коммент увидит раз-два человека (а так возможно кому пригодится).


Речь пойдет совсем не про уязвимость в прямом смысле этого слова, а про то как по недосмотру (халатности или лени) выстрелить в ногу сразу длинной очередью.


Что собственно случилось


Команда UpGuard Cyber Risk нашла "дыру", где многия документы, в том числе и секретные, валялись (другого слова не подберу) в прямом публичном доступе.
Чтобы оценить серьёзность — среди компаний накрытых той "дырой" подразделения VW, Chrysler, Ford, Toyota, GM, Tesla и ThyssenKrupp.


Данные у всех разного типа, степени конфиденциальности и "грифа" секретности, но...


Читать дальше →
Total votes 47: ↑45 and ↓2 +43
Comments 17

Двойка вам, или аудит со взломом

Reading time 8 min
Views 24K

Как всегда без имен и названий, и так как я дополнительно связан подписью о неразглашении, еще и с немного видоизменённой историей (и опуская некоторые подробности, на публикацию которых я не получил разрешения).
Ниже следует реальная история проникновения на компьютер сотрудника… ну скажем некоторого частного банка. События, о которых повествует ваш покорный слуга, происходили в некоторой европейской стране не так что бы давно, еще до DSGVO (GDPR, RGPD) но в процессе становления оного, в преддверии так сказать.


Собственно началось всё с аудита безопасности — ..., интервью, разглядывания под лупой всего и вся, поиском и проработкой потенциальных лазеек и узких мест на пролезть (как туда, так и оттуда), ..., и собственно разбора полётов. На котором заказчик получил в итоге неутешительный для него вывод — "троечка с натяжкой".


Опустим слова, которые пришлось выслушать от краснеющих на глазах IT-безопасников, но общий лирический посыл таков — я бросаюсь голословными обвинениями, а у них — всё на замке, а ключ у CSO в кармане под сердцем.


Попытки объяснить, что система безопасности выстроенная вокруг firewall+proxy+webwasher like content-filter & antivirus, без какой-либо худо-бедно настроенной гибридной IDS (HIDS+APIDS), хонепотов и т.д. и т.п., во первых по определению не является безопасной, во вторых я же как бы показал уже несколько мест, где оно как минимум не комильфо. Попытки вернуться к конструктивному диалогу (собственно обратно к разбору) разбивались о трехэтажную стену обиды, выстроенную всем отделом.


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

Читать дальше →
Total votes 58: ↑51 and ↓7 +44
Comments 88

GNMT, epic fail или тонкости машинного перевода

Reading time 4 min
Views 8K
После прочтения статьи "Нейронный машинный перевод Google" вспомнился курсирующий последнее время в интернет очередной epic-fail машинного перевода от Google. Кому сильно не терпится сразу мотаем в низ статьи.

Ну а для начала немного теории:


GNMT есть система нейронного машинного перевода (NMT) компании Google, которая использует нейросеть (ANN) для повышения точности и скорости перевода, и в частности для создания лучших, более естественных вариантов перевода текста в Google Translate.

В случае GNMT речь идет о так называемом методе перевода на основе примеров (EBMT), т.е. ANN, лежащая в основе метода, обучается на миллионах примеров перевода, причем в отличии от других систем этот метод позволяет выполнять так называемый zero-shot перевод, т. е. переводить с одного языка на другой, не имея явные примеры для этой пары конкретных языков в процессе обучения (в обучающей выборке).

Image 1. Zero-Shot Translation
Рис. 1. Zero-Shot Translation
Читать дальше →
Total votes 35: ↑20 and ↓15 +5
Comments 56

Оптимизация кода в уме, или «Ну так же однозначно быстрее»

Reading time 4 min
Views 25K
Намедни работая над одной ошибкой в одном опенсорсном проекте, увидел как коллега (тоже работающий параллельно над той же проблемой) залил такой вот коммит [31a078bec7]:

   	/*
-	 * Select the list item based on the index. Negative operand means
-	 * end-based indexing (-2, ...), and -1 means out of range.
+	 * Decode end-offset index values.
   	 */
-	if (opnd < -1) {
-	    index = opnd+1 + objc;
-	} else {
-	    index = opnd;
-	}
+	index = opnd + (opnd <= TCL_INDEX_END)*(objc - 1 - TCL_INDEX_END);
   	pcAdjustment = 5;

Изменение само по себе правильное (теперь TCL_INDEX_END есть константное определение (-2)).

И грубо говоря в уме это разворачивается в следующее (все переменные int):

index = opnd + cmp(opnd, (-2))==>(0 | 1) * (objc - 1 - (-2));

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

Во первых, это изменение касается самой «главной» функции в этом проекте (TEBCresume), ибо она ответственна за исполнение байт-кода (JIT скомпилированных инструкций языка TCL). По этой причине эта функция еще и самая большая (порядка 6 тысяч строк + примитивы и макросы) и одна из самых сложных в кодовой базе проекта, с множественными `goto`, головоломными макросами для работы со «стеком» исполнения, свёртка/развертка NRE (nonrecursive evaluation) и т.д. и т.п.

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

Во вторых, по роду деятельности мне часто приходится оптимизировать сишный код, разглядывая его ассемблерное отражение, выжимая доли микро- а то и нано-секунд, и я часто вижу, что там очень всё совсем неоднозначно бывает. Как минимум иногда разворачивая такие вот «экономящие» условный jump конструкции обратно в if или даже if/else, я видел улучшение как и в результирующем ассемблерном коде, так и явно при конечном сравнении производительности результатов исполнения.

Собственно к чему я все это писал — хотелось на примере показать как оно бывает, ну и раз уж коснулись этой темы, собрать немного статистики. Посему пара опросов в конце статьи…
Развернуть в ассемблер ...
Total votes 51: ↑48 and ↓3 +45
Comments 55

Great developer, true engineer and real leader — RIP Shawn O. Pearce

Reading time 2 min
Views 15K

image


29 января 2018, скончался Шон Пирс, известный программист, автор, коммиттер и основатель многих проектов, в том числе Git, Jgit, libgit и Gerrit Code Review.


Умер выдающийся разработчик, настоящий инженер и отличный руководитель, оставив замечательных пацанов, жену и… всё опенсорс сообщество.


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

Читать дальше →
Total votes 57: ↑56 and ↓1 +55
Comments 9

И так сойдёт… или Дыра как средство защиты

Reading time 6 min
Views 13K


По мотивам "И так сойдёт… или как данные 14 миллионов россиян оказались у меня в руках"...


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


И чтобы расставить все точки над E, — я вовсе не пытаюсь оценить или как-то обелить "ответственные" лица, что с одной, что с другой стороны.


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


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


Например прочитав "Утащил базу весом 5 Гб… сколько времени это качалось. Вы думаете, кто-то заметил?" я лишь усмехнулся и продолжил чтение (ибо ИМХО некоторое преувеличение допускается в такого рода статьях).


Хотя автор и сам признал что он немного лгунишка апдейтом в конце статьи.


конечно же, никакой базы у меня нет, на протяжении 3-х дней я эмулировал скачивание ...

Теперь почему это очевидно/вероятно (даже не принимая другие типовые ограничения во внимание):

Читать дальше →
Total votes 44: ↑24 and ↓20 +4
Comments 43

С новым (айтишным) «годом» Вас, други

Reading time 1 min
Views 19K

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


Я не перепил, если что...

Читать дальше →
Total votes 70: ↑63 and ↓7 +56
Comments 24

[Опрос] А вот про нейронные сети, ИИ и т.д

Reading time 5 min
Views 22K

На просторах интернета часто доводилось видеть мнения, что де "нейросеть — панацея от всего и вся", т.е. например "натравите нейросеть — и все, профит" или еще брутальней "скоро создадут ИИ на базе нейронной сети, которая сможет заменить даже программистов / администраторов / аналитиков и т.д.".


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


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


Написать статью (и опрос) хотел уже довольно давно, но все как-то руки не доходили. А после очередного вопроса-предложения по е-майлу "натравите же нейронную сеть" на проблему из моей прошлой статьи "Мониторинг лог-журналов: Такой уязвимый лог...", все-таки понял — нет — надо писать.


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


Хотя вдруг это я таки нещадно отстал от жизни...

Читать дальше →
Total votes 51: ↑36 and ↓15 +21
Comments 152

Мониторинг лог-журналов: Такой уязвимый лог или как подложить свинью коллегам

Reading time 11 min
Views 20K

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


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


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


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


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

Люди, включайте мозг ...
Total votes 36: ↑36 and ↓0 +36
Comments 18

Fail2ban 0.10: Новые возможности. Тест открыт

Reading time 3 min
Views 20K

Это анонс новой версии fail2ban (пока тестовая альфа-ветка), в которой помимо многих других улучшений и вкусностей, хоть и с опозданием, все же появилась давно запланированная поддержка IPv6.
Время, будь оно не ладно — летит с бешеной скоростью.

Читать дальше →
Total votes 29: ↑27 and ↓2 +25
Comments 22

NGINX — Ускорение или Детектив для программиста «Оптимизация под Windows»

Reading time 11 min
Views 17K
Довольно много времени прошло после моей последней статьи про nginx под windows, неделя nginx закончилась. Стоит поправить это упущение.

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

После небольшого разбора и оценки в сравнении с результатами предыдущего анализа, заметил одну странность — абсолютная скорость отдачи nginx упала в среднем от 5 до 15%.

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

Покрутив логи и так и сяк, зацепился за отдачу маленькой статики — выяснилась одна закономерность: чем длиннее путь (url) — тем «медлительней» становился nginx (независимо от размера файла).

Итак после нескольких экспериментов, имеем следующие факты:
  • скорость отдачи падает прямо пропорционально увеличению длины пути до файла
  • скорость практически не зависит от длинны URL, т.е. если URL короткий, но увеличиваем длину root/alias, скорость отдачи падает также, т.е. это все-таки длинна пути, а не URL
  • ну и наконец, поиграв с путями файла, а именно его вложенности, выяснилось, что скорость отдачи падает в зависимости от количества поддиректорий, и не зависит от длины как-таковой. Т.е. файл «D:\...\ms-ms-ms-ms-ms-ms-ms-ms\test.gif» отдается много быстрее «D:\...\ms\ms\ms\ms\ms\ms\ms\ms\test.gif»

И тут пришло озарение — я вспомнил, что в этом проекте изменилась файловая структура, и вложенность до некоторой статики и динамики, отдаваемой файлом (по redirect), увеличилась на два-три, а местами до пяти каталогов.
Читать дальше →
Total votes 25: ↑25 and ↓0 +25
Comments 29

Блокировка по access_log, легкий способ прострелить ногу или устранение конкурентов

Reading time 3 min
Views 29K
Очередной пример, как легко прострелить себе ногу, на этот раз «переусердствовав» при защите сайта.
Имён как всегда не называю, однако история показательна как-таковая, т.е. в качестве примера, как не надо «защищать» свои сервера. Эх говоришь им, говоришь — а все без толку.

Пришлось тут намедни делать «аудит» одного коммерческого проекта… ну очень просили.
Упала посещаемость сайта, не совсем чтобы совсем, но довольно заметно. Смотрели логи, аналитику поисковиков и т.д. и т.п. Все вроде нормально, и кто приходит, тот даже не уходит сразу.
Но не буду ходить вокруг, да около — проанализировав логи банов по IP выяснилась одна закономерность — за короткое время в бан попадало огромное количество IP-адресов. Все поголовно по одной причине — якобы как botsearch. Отротированные логи за последний месяц тоже ужасали своими размерами и даже заглядывать туда не нужно было, и так все ясно. Т.е. случилось следующее: куча клиентов просто не могла попасть на сайт.
На вопрос «что-то меняли где-то с месяц назад?» был получен отрицательный ответ.

Не буду утомлять здесь детективным чтивом, после недолгих поисков — картина маслом. Некий прямой конкурент этого сайта поспособствовал «утечке» клиентов, или вернее и организовал эту «странную непосещаемость».
Читать дальше →
Total votes 37: ↑36 and ↓1 +35
Comments 25

NGINX — История перерождения под Windows

Reading time 6 min
Views 43K
Раз уж тут у нас «неделя» nginx, например тут или тут, то попробую и я внести свою, так сказать, лепту. Речь пойдет про nginx 4 windows, а именно про более-менее официальную сборку для этой пропритарной, некоторыми не очень любимой платформы.

Почему Windows. Все просто, в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа. И от этих требований к платформе, например в ультимативной форме озвученных клиентом, никуда не денешься.
И раз уж имеем Windows, но не хочется мучиться с IIS, apache и иже с ними, если хочется использовать любимые инструменты, а nginx однозначно к ним относится, то приходится иногда мириться даже с некоторыми ограничениями на этой платформе. Вернее приходилось…

Хотя нужно заметить, что даже с этими ограничениями, nginx даст фору практически любому веб-серверу под windows по многим факторам, в том числе по стабильности, потреблению памяти, а главное производительности.

Спешу сразу поделится хорошей новостью — больше ограничений, критичных к высокой производительности, при использовании nginx под windows практически не существует, и последнее из критичных, с высокой долей вероятности, тоже скоро отпадет. Но по порядку…

Здесь описаны известные проблемы nginx 4 windows, а именно:

  • Рабочий процесс может обслуживать не более 1024 одновременных соединений.
  • Кэш и другие модули, требующие поддержки разделяемой памяти, не работают под Windows Vista и более поздними версиями в связи с тем, что на этих версиях Windows включена рандомизация адресного пространства.
  • Хоть и возможен запуск нескольких рабочих процессов, только один из них реально работает.

Я немного изменил порядок, т.к. именно в такой последовательности я разбирался с этими ограничениями, так сказать отсортировано «исторически».
Читать дальше →
Total votes 69: ↑66 and ↓3 +63
Comments 81

Sexy primes, «медленный питон» или как я бился о стену непонимания

Reading time 10 min
Views 31K
Многие разработчики, особенно принимающие активное участие в проектировании системы, наверняка сталкивались с подобной ситуацией: приходит коллега (разраб, проектлид или продажник не суть важно) с очередной идеей-фикс: давай перепишем все на java, scala и т.д. (любимое подставить).

Вот и мне в очередной раз «спустили» такую идею в немаленьком-таком legacy проекте. Не совсем переписать, не совсем все (ну в перспективе). В общем перейти с питона (а у нас там еще и тикль модульно присутствует) на scala. Речь пока шла о разработке новых модулей и сервисов, т.е. начинать с наименее привязанных к middle-level и front-nearby API's. Как я понял в перспективе возможно совсем.

Человек — не разработчик, типа нач-проекта и немного продажник (для конкретного клиента) в одном лице.

Я не то, чтобы против. И скалу уважаю и по-своему люблю. Обычно я вообще открыт ко всему новому. Так, например, местами кроме тикля и питона у нас появляются сервисы или модули на других языках. Так, например, мы переехали с cvs на svn, а затем на git (а раньше, давно-давно, вообще MS-VSS был). Примеров на самом деле масса, объединяет их один момент — так решили или как минимум одобрили сами разработчики (коллективно ли, или была группа инициаторов — не суть важно). Да и дело в общем в аргументах за и против.

Проблема в том, что иногда для аргументированной дискуссии «Developer vs. Anybody-Else» у последнего не дотягивает уровень знаний «материи» или просто невероятно сложно донести мысль — т.е. как-бы разговор на разных языках. И хорошо если это кто-нибудь типа software architect. Хуже, если имеем «беседу» например с чистым «продажником», огласившим например внезапные «требования» заказчика.

Ну почему никто не предписывает, например, плиточнику — каким шпателем ему работать (типа с зубцами 10мм клея же больше уйдет, давайте может все же 5мм. А то что там полы-стены кривущие никого не волнует). И шуруп теоретически тоже можно «закручивать» молотком, но для этого же есть отвертка, а позже был придуман шуруповёрт. Утрирую конечно, но иногда действительно напоминает такой вот абсурд.

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

Но что-то я отвлекся. В моей конкретной истории аргументов — за scala, у человека как всегда почти никаких.
Хотя я мог бы долго говорить про вещи, типа наличие разрабов, готовые наработки, отточенную и отлаженную систему и т.д. и т.п. Но зацепился за его «Питон очень медленный». В качестве примера он в меня кинул ссылкой на Interpreting a benchmark in C, Clojure, Python, Ruby, Scala and others — Stack Overflow, которую он даже до конца не прочитал (ибо там почти прямым текстом есть — не так плохо все с питоном).

Имелось ввиду именно вот это (время указано в секундах):
  Sexy primes up to:        10k      20k      30k      100k
  ---------------------------------------------------------
  Python2.7                1.49     5.20    11.00       119     
  Scala2.9.2               0.93     1.41     2.73     20.84
  Scala2.9.2 (optimized)   0.32     0.79     1.46     12.01

Читать дальше →
Total votes 57: ↑46 and ↓11 +35
Comments 55

Как я однажды взломал онлайн-казино

Reading time 7 min
Views 126K
Вдохновившись рассказом Chikey о том, как он вновь «сломал интернет» Егор прекрати уже ломать все подряд, займись делом каким-нибудь, решил поведать об одной истории с довольно известным за рекой онлайн-казино. Имя этой «организации» не называю, т.к. процентов на 50 уверен, что или совсем не пофиксили, или сделали кривее, чем было до этого.

История очень похожа на взлом Егора, за исключением того, что это не совсем рэйс, вернее, совсем не race condition в чистом его виде. Как оно будет полностью не знаю, я больше практик, чем теоретик. Назовем его «conditional race condition» — хоть и масло масляное, но суть отражает верно.

Как-то вечером, домашние уснули, по ящику одна муть, наши опять проигрывают делать было особенно нечего, на опенсорс решил на сегодня забить, захотелось чего-нибудь сломать. А что ломать (когда Егор уже все сломал), как не банк какой-нибудь или казино (эго, необходимость иногда почувствовать себя крутым парнем, все дела в общем). Это было одно из первых онлайн-казино, которое мне тогда приглянулось в поиске.

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

Завел себе аккаунт, и поехали…
Читать дальше →
Total votes 132: ↑110 and ↓22 +88
Comments 72

Аудит одного «медленного» приложения в одном крупном концерне

Reading time 7 min
Views 14K
В общем-то хотел просто ответить на этот комментарий и в качестве примера привести неожиданные результаты одного как-то сделанного мною аудита веб-приложения, но ответ получался очень громоздкий.
Так родилась эта статья.

Вступление


Речь шла о том, что иногда в корпоративном секторе, прикрываясь надуманными нормативами или навязанными стандартами от безопасности, случаются совершенно неоправданные, а иногда и совершенно дикие реализации последних, нередко граничащих просто с невозможными условиями работы. Например CIO и иже с ним (либо нерадивые или просто ленивые исполнители), руководствуясь такими политиками, возможно переусердствовали, а часто не нашли (или не искали) лучшего решения.

В результате имеем антивирусы на серверах, со всеми вытекающими, потому что просто должен быть на каждом компьютере. Сотрудников вынужденных работать под админом (aka MakeMeAdmin), потому что создать админский аккаунт (тех-юзера), тупо для скриптов, перестартовки и дебага сервисов, ну никак не возможно (да и ладно — все-равно есть же антивирус). Политики позволяющие запустить исполняемый файл отовсюду (сеть, временный каталог и т.д.), потому что какая-то там служба обновления по другому не умеет (не страшно — снова антивирус как аргумент). И т.д. и т. п.

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

Пример: как-то бились с одним известным антивирусом (доказуемо бажным, вероятно где-то в районе аналитики и очередях real time scanning) — при очень большой загруженности сервера (32 ядра >= 50% cpu load):
  • антивирус блокирует (от нескольких миллисекунд до 30 секунд!) доступ к файлам, после их переименования — в результате многопоточный pipeline (асинхронная очередь заданий) периодически вылетает с «access denied» при доступе например к временным, только что созданным и затем переименованным файлам из другого потока, сообщившего об окончании работы. При том, что working folder вроде бы совсем исключен из real time scanning.
  • или того хуже, кладет дочерние процессы спать (suspended) и забывает их «разбудить», а поток в предке бесконечно ждет окончания работы уснувшего дитя.
И ведь отключить его в продакшн на серверах «никак не возможно» (даже временно в качестве доказательства, т.к. таким антивирусом как правило они себе одно место прикрывают).

Например, что стоит разделить ту же сеть и воткнуть тот же антивирус за NAT-ом. Или хотя бы проверить на такие болячки и заменить на другой, более надежный. Сравните эту стоимость со скажем человеко-часом * 25000 сотрудников, ежедневно минута за минутой тратящихся на тупое ожидание ответа приложения.
А в результате растет-растет число велосипедов типа «safe_rename», «real_delete» или «start_process_with_observe» вокруг проектов. Тот же CIO быстро пересмотрел бы свою позицию, если бы ему (его подразделению) коллективный счет выставить за суммарное время «простоя» (ожидания) всех сотрудников.
Итак аудит ...
Total votes 19: ↑17 and ↓2 +15
Comments 36

Fail2ban [incremental]: Лучше, быстрее, надежнее

Reading time 9 min
Views 157K
fail2ban image
Про fail2ban написано уже много, в том числе и на хабре. Эта статья немного о другом — как сделать защиту им еще надежнее и о еще пока неизвестных в широких кругах новых функциях fail2ban. Добавлю сразу — речь пойдет пока про development branch, хотя уже долго проверенный в бою.

Краткое вступление


В большинстве своем fail2ban устанавливается из дистрибутива (как правило это какая-нибудь стабильная старая версия) и настраивается по манам из интернета за несколько минут. Затем годами работает, без вмешательства админа. Нередко даже логи, за которыми вроде как следит fail2ban, не просматриваются.
Так вот, сподвигнуть на написание этого поста меня заставил случай, произошедший с одним сервером моего хорошего знакомого. Классика жанра — пришла абуза, за ней вторая и пошло поехало. Хорошо еще злоумышленник попался ленивый — логи не потер, да и повезло еще крупно, что logrotate был настроен, чтобы хранить логи месяцами.
Как дальше жить
Total votes 72: ↑71 and ↓1 +70
Comments 60
1

Information

Rating
Does not participate
Location
Hamburg, Hamburg, Германия
Date of birth
Registered
Activity