Привет! Меня зовут Миша, и я основатель https://defbox.io - платформы на которой можно попробовать написать детект под разные атаки и соревноваться кто лучше это делает :)

Мы успели сделать несколько лабораторных работ, о которых, я надеюсь, Вам будет интересно почитать :)

На примере SSH-bruteforce стенда я расскажу, как можно своими руками сделать лабу для тренировки написания детектов:
1. Как поднять платформу для сбора и анализа логов
2. Как поднять и подготовить заведомо уязвимый сервер
3. Как провести SSH-Bruteforce
4. Что искать в платформе из п.1 и как написать правило в эластике

Я следила за проектом Flipper Zero с самого начала, мне нравилась идея, команда, ее подходы и статьи о куче интересных деталей на Хабре.

Вот, он готов. Пришло время его купить, я захожу на сайт, а там 170 долларов... И это только первый вопрос.

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

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

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

Привет! Меня зовут Алексей Карпов, я DevOps-инженер (MLOps) отдела ML разработки в OKKO. Хочу поделиться опытом в работе с Apache Airflow в связке с Kubernetes. Расскажу, как установить Airflow в Kubernetes, настроить автоматическую синхронизацию DAG'ов с удалённым репозиторием, а также как отладить его работу. Всё это — на примере запуска простейшего DAGа. 

Есть такие ребята — SRE (с англ. Site Reliability Engineering), которые выросли из старых добрых и бородатых системных администраторов. Но они устали заниматься ежедневной рутиной и решили всё автоматизировать. Именно поэтому 50% времени SRE пишут код.

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

Короче, решил я замутить что-то своё, чтоб не хранить все свои доступы удобно (не)доступными в одном файле KeePass, а то ведь мало ли что. Просто так, из принципа. Биткойнов не держу.

Шли годы…

В настоящее время существует огромное количество всеразличного рода анонимных (скрытых) сетей, начиная с теоретически доказуемых (DC-сети, Queue-сети, Entropy-сети) и заканчивая практически используемыми (Tor, I2P, Mixminion). При таком количестве реализаций было бы очень удобно обобщить структуру всех таковых систем и привести их к общим составляющим. В результате подобных действий, мы сможем не только лучше понять то, как строятся современные анонимные сети, но и то, как их можно улучшать.

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

Docs as Сode — подход к работе с текстами, подразумевающий написание текста как кода:

• в простом текстовом редакторе или IDE;
• с использованием системы контроля версий;
• с CI / CD / Code Review.

В настоящее время Docs as Code широко применяется при работе с технической документацией, давая техническим писателям и проектным командам массу удобств и преимуществ.

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

В этой статье я расскажу о таком эксперименте (забегая вперед, удачном). Моей дочери 11 лет, она пишет сказки, стихи и рассказы. Чтобы поддержать ее увлечение, я помог ей создать литературный сайт, используя подход Docs as Code. Она успешно освоила основы Markdown и Git. Сейчас она самостоятельно публикует новые произведения и обновляет новости на своем сайте https://lib-beliakova.github.io/.

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

И уж конечно, никогда при написании a * b мы не задумываемся о том, как реализовано умножение чисел a и b в нашем языке. Какие вообще есть алгоритмы умножения? Это какая-то нетривиальная задача?

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

Я уже довольно долго собираю и настраиваю десктопы с Linux для дома и офиса, и последнее время не без удовольствия выбираю конфигурации со встроенной графикой Intel. Когда‑то я начинал с машинки, в которую поставил с Core i3–2105, (HD Graphics 3000), позднее — более новый Core i3–9000 (UHD Graphics 630), а совсем недавно мне очень недорого достался Intel NUC5PPYH, разумеется тоже с фирменным графическим контроллером Intel.

Сразу хочу сказать, что если вы не играете в коммерческие игры в Linux, то графические «встройки» Intel — это лучший выбор в плане стабильности и поддержки производителя. Видеодрайвер уже много лет есть в ядре, и он просто работает: с аппаратным ускорением из коробки, без тиринга, без дополнительных проприетарных блобов и прочей головной боли. Более того, таких драйверов минимум два: это традиционный 'intel' и более новый 'modesetting'. Графика Intel с самого начала лучше всего работала в Wayland, не будем забывать и об этом.

Поводом для этой заметки стало наблюдение: эффекты рабочего стола могут тормозить на старых «встройках» Intel при том, что в OpenGL‑приложениях может быть вполне высокий FPS и хорошая плавность. Я наблюдал разные признаки торможения в двух самых популярных рабочих окружениях (KDE Plasma 5 и Gnome 4) как в X11, так и в Wayland. Я хочу поделиться советом про то, как ситуацию можно исправить на примере дистрибутива Fedora $releasever (на момент описания это 37).