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

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


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

      Читать дальше →
    • [Опрос] А вот про нейронные сети, ИИ и т.д

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


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


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


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


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


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

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

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


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


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


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


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

          Люди, включайте мозг ...
        • Fail2ban 0.10: Новые возможности. Тест открыт

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

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

              Довольно много времени прошло после моей последней статьи про 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), увеличилась на два-три, а местами до пяти каталогов.
              Читать дальше →
            • Блокировка по access_log, легкий способ прострелить ногу или устранение конкурентов

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

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

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

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

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

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

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

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

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

                  Я немного изменил порядок, т.к. именно в такой последовательности я разбирался с этими ограничениями, так сказать отсортировано «исторически».
                  Читать дальше →
                • Sexy primes, «медленный питон» или как я бился о стену непонимания

                    Многие разработчики, особенно принимающие активное участие в проектировании системы, наверняка сталкивались с подобной ситуацией: приходит коллега (разраб, проектлид или продажник не суть важно) с очередной идеей-фикс: давай перепишем все на 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
                    

                    Читать дальше →
                  • Как я однажды взломал онлайн-казино

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

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

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

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

                      Завел себе аккаунт, и поехали…
                      Читать дальше →
                    • Аудит одного «медленного» приложения в одном крупном концерне

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

                        Вступление


                        Речь шла о том, что иногда в корпоративном секторе, прикрываясь надуманными нормативами или навязанными стандартами от безопасности, случаются совершенно неоправданные, а иногда и совершенно дикие реализации последних, нередко граничащих просто с невозможными условиями работы. Например 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 быстро пересмотрел бы свою позицию, если бы ему (его подразделению) коллективный счет выставить за суммарное время «простоя» (ожидания) всех сотрудников.
                        Итак аудит ...