Совместное исследование DDoS-Guard и FirstVDS

Раньше считалось, что DDoS-атаки направлены на «крупную рыбу» — корпорации, госкомпании, банки. Но реальность 2026 года говорит о другом: жертвой злоумышленников может стать кто угодно.

За три года число атак выросло с 2,2 до 2,5 млн. Их распределённость увеличилась на 480%. DDoS-атаки стали массовым, доступным и, что самое опасное, автоматизированным инструментом. 

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

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

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

Ранее в своих статьях я рассказывал, как подключать модули EBYTE LoRa к Raspberry Pi и Repka Pi (ссылки в конце этой статьи). Но такие микрокомпьютеры потребляют довольно много электроэнергии и не «проживут» долго на аккумуляторе. 

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

В этой статье на примере метеостанции я расскажу о том, как создавать узлы сбора данных LoRa на базе микроконтроллера ESP32-S3, установленного в модуле Heltec Automation HTIT‑WB32LAF V3. Микроконтроллер может переходить в состояние глубокого сна, когда работают только часы реального времени и память RTC, а вся периферия отключается. В результате узел сбора данных может работать очень долго, питаясь от аккумулятора.

Десятилетиями странные результаты экспериментов намекали: стерильное нейтрино существует. Оно разом объясняло бы сразу несколько загадок. Новые эксперименты эту надежду похоронили — и физики остались наедине с аномалиями, которые по-прежнему нечем объяснить. 

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

Зато судьбы учёных они меняют легко.

В конце 1990-х годов, когда физики неожиданно обнаружили, что нейтрино обладают массой, Тьерри Лассерр оставил космологию, чтобы полностью посвятить себя изучению элементарных частиц. «Это было так захватывающе, что я просто не смог устоять», — сказал Лассерр, ныне физик в Институте ядерной физики Общества Макса Планка в Гейдельберге, Германия. А Марк Росс-Лонерган собирался стать метеорологом, пока в 2010 году случайно не столкнулся с физикой частиц и не изменил своё решение. Лассерр, Росс-Лонерган и тысячи других учёных посвятили карьеру исследованию этой почти инертной частицы.

Больше десяти лет казалось, что их работа вот-вот приведёт к прорыву. Эксперименты сообщали о странных явлениях, в которых нейтрино появлялись и исчезали. Эти результаты, наряду с загадочной массой нейтрино, указывали на одно потенциальное объяснение: «стерильный» тип нейтрино определённой массы, по-видимому, скрывался за кулисами, оставаясь необнаруженным. 

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

В статье соберем полностью локальную RAG-систему на Go, PostgreSQL и Ollama без облачных API и сторонних сервисов. Разберем весь путь — от индексации документов до получения ответа LLM на основе найденного контекста.

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

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

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

Из этой статьи вы узнаете, как появились устройства LoRa и почему они могут принимать сигналы ниже уровня шума. Вы узнаете, как работать с модулями LoRa, подключенными к микрокомпьютеру Raspberry Pi, научитесь конфигурировать эти модули с учетом ограничений законодательства, а также передавать с их помощью сообщения на километры. В завершение статьи я расскажу, как сделать простую погодную станцию, измеряющую температуру, давление и влажность. Данные будут передаваться через LoRa и отображаться на OLED-мониторах, подключенных к передатчику и приёмнику.

Это вторая часть статьи про Linux Incident Response — разбор live response на работающем Linux-хосте с подозрением на компрометацию.

Если вы не читали первую часть, лучше начать с неё: в ней разобрали принципы расследования, изоляцию хоста, trusted toolkit, фиксацию исходного состояния, сетевые соединения и процессы. Без этого контекста часть команд и логика дальнейшего анализа будут менее понятны.

Первая часть здесь.

В этой части процесс идет далее — к менее изменчивым артефактам. Рассмотрим механизмы закрепления и следы на диске: systemd-сервисы и timers, cron, автозапуск, пользователи, группы, пакеты, логи, kernel-артефакты. В финале расскажем о построении таймлайна, оформлении IOC и действия с системой после завершения расследования.

Пару лет назад я уже публиковал статью о реагировании на инциденты в Linux-системах. Она по-прежнему может быть полезна как практическая шпаргалка, но с тех пор изменился и мой опыт, и требования к таким материалам. В этом цикле статей  я хочу разобрать Linux live response более системно. 

Большинство материалов по Linux IR сводятся к спискам команд: посмотреть процессы, сеть, пользователей, cron, логи. Проблема в том, что сами по себе команды мало что дают, если нет порядка их применения, ограничения live response, смысл полученного вывода и вообще — методологии, базиса работы. 

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

Добро пожаловать под кат. 

Способен ли маленький нетбук принести хоть какую-либо пользу в 2026 году?

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

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

После нагрузочного тестирования k6 формирует отчет с десятками метрик. Но сам по себе этот отчёт ещё не говорит, где находится проблема и действительно ли приложение стало работать хуже. Одни и те же значения могут указывать на разные причины: медленную базу данных, особенности работы Kubernetes, проблемы сети или обычный шум тестового стенда.

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

Сегодня мы закончим ковырять порт тайловых миров на F#. Правда, в прошлый раз мы исчерпали запас того, что вообще можно было «портировать», поэтому переключим внимание на совершенно новые фичи. Все они касаются UI (в узком смысле), ну или, говоря терминами игровой индустрии, HUD (Heads-Up Display).

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

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

Переход к микросервисной архитектуре неизбежно поднимает вопрос эффективности межсервисного взаимодействия. В PHP традиционный стек на базе PHP-FPM и REST API создает дополнительные накладные расходы: каждый запрос обрабатывается в отдельном процессе, что требует повторной инициализации контейнера зависимостей, загрузки конфигурации и всего контекста приложения. В результате увеличивается latency и снижается пропускная способность сервиса.

В этой статье мы шаг за шагом разработаем высокопроизводительный микросервис на Symfony 7, используя RoadRunner в качестве постоянного приложения-сервера, gRPC для межсервисного взаимодействия и Protocol Buffers для сериализации данных. По итогам вы получите полностью рабочий сервис и поймете, как построить производительную альтернативу классическому стеку PHP-FPM + REST.

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

Разберёмся, как ОУ устроены и почему они стали универсальным строительным блоком аналоговой техники. Пройдём путь от ламповых конструкций до копеечных микросхем, соберём несколько схем на недорогом LM358 с однополярным питанием — и в финале сделаем своими руками простейший электрокардиограф и снимем настоящую кардиограмму.

PrimeTek, бывшая PrimeFaces, запустила PrimeUI — новую лицензионную модель для экосистемы PrimeNG, PrimeReact и PrimeVue. Это подаётся как унификация бренда, но по сути компания собирает свои ключевые продукты под одной коммерческой оболочкой. Раньше они существовали как набор отдельных библиотек, которые монетизировались через дополнительные продукты и сервисы. Теперь вся экосистема превращается в единый лицензируемый актив.

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

Несмотря на все усилия Бурбаки, Коши и Вейерштрасса, подлинно формальные доказательства всегда оставались предметом теории, а не практики. Некоторые математики теперь надеются, что компьютеры смогут это изменить.

Начиная с 1960-х годов исследователи разрабатывают компьютерные программы, называемые системами интерактивного доказательства. Используя такую систему, математик записывает каждую строку доказательства (включая каждое определение) на языке, понятном компьютеру, а затем система проверяет логику. Если хотя бы один шаг не вытекает из предыдущего — если не доказана каждая мелочь вплоть до того, что 1 + 1 = 2, — программа не примет доказательство.

Сейчас учёные надеются формализовать всю математику с помощью системы интерактивного доказательства под названием Lean. Уже создана библиотека, содержащая более 120 000 определений, и проверено четверть миллиона теорем. Несколько математиков поддерживают эту базу данных, обновляя её и проверяя новые данные. (Некоторые из них занимаются этой работой полный рабочий день.) Они уже получили более 10 миллионов долларов финансирования, в основном от миллиардера-финансиста Алекса Герко.

Astro — фреймворк для сайтов, который минимизирует поставку JavaScript на клиент, обеспечивая высокую производительность. 22 июня вышла седьмая версия, в которой разработчики серьёзно прокачали скорость. Компилятор .astro переписали на Rust, туда же перенесли обработку Markdown и MDX, а движок рендеринга заменили на систему с очередями. Вкупе с Vite 8 и новым бандлером Rolldown сборки ускорились на 15–61% по внутренним бенчмаркам. А поскольку самая быстрая сборка — та, которую не нужно запускать вовсе, в Astro 7 также стабилизировали кэширование маршрутов и добавили экспериментальных CDN-провайдеров кэша для Netlify, Vercel и Cloudflare.

В Astro 7 добавили продвинутый роутинг: появляется точка входа src/fetch.ts, дающая полный контроль над конвейером обработки запросов в Astro. Для разработки с участием ИИ Astro теперь умеет определять coding agents, запускать dev-сервер в фоне и выводить структурированные JSON-логи, когда агентам нужен машиночитаемый ответ.

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

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

В прошлой главе мы начали разбирать порт тайловых миров на F#, где познакомились с некоторыми малоизвестными возможностями Godot. В этот раз наш прицел сместится с технологических особенностей RenderingServer на обычную бытовуху (бизнес-логика + высокоуровневое рисование).

При этом следует понимать, что код разбираемого проекта предшествовал написанию текста и послужил первопричиной выбора тех тем, что попали в цикл. Поэтому нас ждёт очень много очень простого кода с примечаниями вида «это стало возможно благодаря <штуковине, что мы разбирали в цикле>». Конечно-же, я добавил некоторое количество экзотики, но сегодня наша задача — закончить с рисованием чего-либо (если не считать мини-карты, она вместе с GUI попала в последнюю главу) и собрать все заготовки в подобие игры.

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

Когда Демиан Гус 12 марта прошлого года последовал за Карин Рихтер в её кабинет, первым ему бросился в глаза бюст. Бюст лысого пожилого джентльмена со стоическим лицом стоял на высоком постаменте в углу комнаты. Гус не увидел и следа того тревожного, одинокого человека, который занимал его мысли более года.

Таким Георга Кантора видела история. Интеллектуальный гигант: непоколебимый, волевой, полный решимости совершить математическую революцию, несмотря на громкие возражения своих коллег.

Именно здесь, в университете Галле в Германии, Кантор 150 лет назад начал свою революцию. Здесь, в 1874 году, он опубликовал одну из важнейших работ в 4000-летней истории математики. Эта работа кристаллизовала концепцию, долгое время считавшуюся математической угрозой, которую следует избегать любой ценой: бесконечность. Она заставила математиков пересмотреть некоторые из их самых давних предположений и потрясла математику до основания. И она дала начало новой области исследований, которая привела к переосмыслению всей науки.

В современных веб-приложениях хранение файлов часто отдают специализированным объектным хранилищам, таким как S3. Это удобно, масштабируемо и надежно. Однако здесь возникает классическая проблема проектирования: как обеспечить безопасный доступ к файлам, когда архитектура требует, чтобы хранилище было приватным, а бизнес-логика прав доступа — централизованной? Оставлять S3-бакет публичным — плохая практика, а проксировать каждый запрос на скачивание через бэкенд-сервис — значит, превратить его в «бутылочное горлышко», которое неизбежно захлебнется при росте трафика.

В этой статье я познакомлю вас с реализацией бэкенд-сервиса, который решает эту проблему элегантно: S3 отвечает за хранение и отправку данных, а мое приложение — за проверку прав и генерацию одноразовых, короткоживущих ключей доступа (Pre-signed URL). Я разберу архитектуру решения, покажу, как настроить безопасное разграничение доступа между публичными и приватными объектами, а также продемонстрирую механизм, который позволяет клиентам скачивать файлы напрямую из хранилища, минуя сервер приложения.

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

Разработчики часто сталкиваются с проблемой: сайт успешно протестировали на мастере, выкатили на прод, провели контрольное тестирование — вроде всё хорошо. Сайт работает пару месяцев — и вдруг приходит задача от SEO «увеличить скорость загрузки сайта» или «исправить просевшее количество баллов в PageSpeed». Причём ничего принципиально нового не добавляли, просто наполняли контентом.

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