Автоматизация, мониторинг и как жить разработчику без умения вести Инстаграм?
Эта статья - не содержит ответ на вопрос. Есть его пояснение, история разработки и немного философии. Я писал статью, надеясь, что у Вас есть опыт, которым Вы сможете поделиться. В этом случае, возможно, Вы найдете время и напишите о нем в комментариях к статье.
$PSStyle для новой функции под названием PSAnsiRendering. В этой статье я покажу, как можно использовать ANSI-рендеринг для управления оформлением текста, например цветом и стилизацией шрифта, в PowerShell.
Резервное копирование? Опять?
Ага!
Разумеется, любой грамотный АйТи-шник прекрасно знаком с подоплёкой этого вопроса, однако, как оказалось, методология и даже простейшая алгоритмика иногда являются камнем преткновения.
Что странно. Что удивительно.
Давайте разбираться, что нужно сделать "До полуночи", чтобы спать спокойно "После полуночи"...
Пошаговое руководство по созданию уникальных правил автообнаружения в Zabbix на примере мониторинга учетных записей. Статья знакомит с логикой создания таких правил и содержит подробные объяснения по каждому пункту.
Deployment и DeploymentConfig — это, казалось бы, похожие объекты API для OpenShift Container Platform. Но на самом деле они предлагают разные гибкие методы управления интерфейсом пользователей. Расскажем о различиях и приведём примеры, когда какие объекты лучше использовать.
Прим. Wunder Fund: наш СТО Эмиль по совместительству является известным white-hat хакером и специалистом по информационной безопасности, и эту статью он предложил как хорошее знакомство с фаззером afl и вообще с фаззингом как таковым.
В первой части этой серии статей я рассказал о том, как организовать фаззинг Apache HTTP Server с привлечением кастомных мутаторов. Во втором материале я раскрыл вопрос создания перехватчиков ASAN, которые позволяют выявлять ошибки при использовании собственных реализаций пулов памяти.
Эта статья, третья и последняя, посвящена результатам моих исследований. Я расскажу тут об обнаруженных мной уязвимостях Apache.
Привет! Меня зовут Кирилл Цветков. Я DevOps, инженер, линуксовый админ – именно через запятую и никак иначе. В этой статье я попробую последовательно рассказать вам что такое DevOps, и примирить два конфликтующих стереотипа, которые это слово окружают.
Коробочные решения хороши тем, что позволяют переложить доработку и внедрение на поставщика ПО. И поначалу всё идёт хорошо: не тратится время на разработку, стоимость решения высокая, но адекватная.
Однако не всё так радужно: помимо лицензии приходится оплачивать поддержку, даже если для конкретного продукта она на данном этапе не нужна. В контрактах многие услуги появляются прицепом, просто потому, что они являются частью коробки. Кроме того, стоимость обновлений с каждым годом растёт, тогда как старые версии перестают поддерживаться. Запросы на доработку продукта под себя долго согласовываются, а иногда выясняется, что нужную фичу просто невозможно прикрутить в разумные сроки по разумной цене. Когда подобные вещи всплывают, у руководства неизбежно возникают вопросы вида «Что делать?», «Можно ли не платить?» и «Зачем платили, если можно было не платить?».
В посте мы рассказали, как разбирались с зависимостью от вендоров в Росбанке: с какими специфическими для финтеха трудностями столкнулись, как с ними справлялись и чего в итоге удалось достичь банку на ниве open source.
Для нас давно стала привычной быстрая смена «потребительских» технологий — появляются новые, более совершенные устройства, и предыдущее поколение, которое могло появиться всего полгода назад, уже выглядит устаревшим. В мире серверов это тоже есть, пусть и не столь явно, да и не с такой частотой. Тем интереснее выглядит маленькое открытие Кевина Хьюстона из BladesMadeSimple.com на рынке блейд-серверов.
Недавно меня спросили, не вижу ли я признаков ухода вендоров с рынка блейд-серверов? И если вижу, то что тогда они предлагают вместо блейдов? Если честно, вопрос меня удивил. Единственным намёком на какой-либо уход с этого рынка были гуляющие в последний год слухи о планах Cisco. Я уже писал об этом здесь, но захотел проверить, есть ли какие-то факты, подкрепляющие заданный мне вопрос. И меня удивило то, что я обнаружил.
Фото Todd Diemer, Unsplash.com
В PayPal мы недавно начали прощупывать почву с Kubernetes. Большинство наших рабочих нагрузок выполняется на Apache Mesos, и в рамках этой миграции нам необходимо было понять несколько аспектов производительности кластеров, работающих под управлением Kubernetes, с control plane, специфичной для PayPal. Главным среди этих аспектов является понимание масштабируемости платформы, а также определение возможностей для улучшения за счет настройки кластера.
В отличие от Apache Mesos, который может масштабироваться до 10 000 нод из коробки, масштабирование Kubernetes является нетривиальной задачей. Масштабируемость Kubernetes ограничивается не только количеством нод и подов, но и некоторыми другими аспектами, такими как количество создаваемых ресурсов, количество контейнеров в поде, общее количество сервисов и производительность при развёртывании подов (pod deployment throughput). В этой статье мы опишем некоторые проблемы, с которыми столкнулись при масштабировании, и то, как мы их решили.
Прим. Wunder Fund: наш СТО Эмиль по совместительству является известным white-hat хакером и специалистом по информационной безопасности, и эту статью он предложил как хорошее знакомство с фаззером afl и вообще с фаззингом как таковым.
В первой статье из этой серии я рассказал о том, с чего стоит начать тому, кто хочет заняться фаззингом Apache HTTP Server. Там мы обсудили разработку кастомных мутаторов в AFL++, поговорили о том, как создать собственный вариант грамматики HTTP.
Сегодня я уделю внимание написанию перехватчиков ASAN, которые позволяют «ловить» баги в кастомных пулах памяти. Здесь пойдёт речь и о том, как перехватывать системные вызовы, нацеленные на файловую систему. Это позволяет выявлять логические ошибки в исследуемом приложении.
В статье «Итоги внутренних пентестов — 2020» от Positive Technologies сообщается, что в 61% внутренних тестирований на проникновение успешно применялась атака Kerberoasting. Это мотивировало меня разобраться в атаке, а также ответить на следующие вопросы: почему Kerberoasting так часто эксплуатируется и какие практики по защите существуют и успешно применяются на текущий момент.
Перед тем как перейти к сути атаки, полезно получить общее представление о том, как именно устроена проверка подлинности Kerberos.
Проверка подлинности
В проверке подлинности Microsoft по Kerberos участвуют:
Key Distribution Center (KDC) – Центр распространения ключей Kerberos, одна из служб безопасности Windows server. Работает на контроллере домена (DC);
Клиент, который хочет пройти проверку подлинности и получить доступ к сервису;
Сервер, к сервису которого пользователь хочет получить доступ.
Исследование функций и скриптов в Mikrotik script. Рассматриваются разные способы создания и вызова функций и скриптов с передачей в них параметров. Оператор :parse и особый тип данных code.
Прим. Wunder Fund: наш СТО Эмиль по совместительству является известным white-hat хакером и специалистом по информационной безопасности, и эту статью он предложил как хорошее знакомство с фаззером afl и вообще с фаззингом как таковым.
Этот материал открывает серию из трёх статей (она продолжает материалы о фаззинге FTP-серверов и FreeRDP), посвящённых фаззинг-тестированию реализации протокола HTTP, представленной в Apache HTTP Server. Это — один из самых популярных веб-серверов и в представлении он не нуждается. Так, Apache HTTP — это один из первых HTTP-серверов, разработка которого началась в 1995 году. По состоянию на январь 2021 года под его управлением работали более чем 300000000 серверов, а значит — он использовался на 26% таких систем и занимал второе место по распространённости, немного уступая лишь Nginx (31%).
В этой статье я вкратце расскажу о том, как работает Apache, и освещу кое-какие идеи, которые помогут всем желающим лучше понять суть кастомных мутаторов, и то, как можно эффективно их применять для исследования реализаций протокола HTTP.
Совсем недавно, 25 января 2022 года вышел новый релиз Nginx - 1.21.6, в котором исправлена проблема неравномерного распределения входящих соединений между несколькими worker процессами в дефолтной конфигурации на Linux системах. Если конкретнее - use epoll, accept_mutex off, reuseport выключен.
В данной конфигурации при определенном характере нагрузки большинство входящих в Nginx соединений обрабатывается лишь одним worker процессом.
Насколько я понимаю, эта проблема существует уже более пяти лет и берет начало в версии 1.11.3 (Jul 2016), когда в Nginx по умолчанию отключили accept_mutex, а вместо него стали полагаться на флаг EPOLLEXCLUSIVE, появившийся в ядре Linux 4.5.
Стоит заметить, что проблема балансировки входящих соединений при использовании механизма epoll и флага EPOLLEXCLUSIVE более глобальна и касается не только Nginx, а любых сетевых приложений, работающих по аналогичной схеме.
В этой статье мы посмотрим на историю и причины появления данной проблемы, а также рассмотрим код ее решения в новом релизе Nginx.