Пока не взломали

По данным исследователей, дыру уже дёргали вживую, возможно ещё с февраля. Shared-хостинг снова напоминает коммуналку: один плохой замок — и внезапно открывается не одна дверь, а весь этаж. Технически баг сидит в логике сессий. До нормальной авторизации cpsrvd создавал pre-auth session file, а дальше через криво обработанные cookie и заголовки можно было подсунуть в эту сессию лишние свойства. В плохом сценарии — что-нибудь уровня user=root. Потом сессия перечитывается, кэшируется, и вот у нас уже не «неудачная попытка входа», а административный доступ без пароля. Красиво? Да. Противно? Тоже да...

Это не тот случай, когда сервер можно забрать прямо из интернета одним красивым запросом. Тут атакующему сначала нужен обычный пользователь на машине или код внутри контейнера. Но дальше история становится заметно веселее: из непривилегированного состояния можно попытаться доползти до root. И самое мерзкое — баг выглядит почти скромно. Речь про контролируемую запись всего 4 байт в page cache читаемого файла. Четыре байта, да. В обычной жизни это звучит как мелочь, а в ядре Linux — как «мы чуть-чуть подпилили несущую балку, ничего страшного». Технически всё крутится вокруг AF_ALG. Это такой интерфейс, через который userspace может ходить к криптографическому API ядра через сокеты...

Хотя если без самообмана, fail2ban — это защита от мусора, а не от атаки. Брутфорс, кривые попытки логина, какая-то веб-помойка — да. DDoS — нет. Проблема очень простая. Fail2ban сначала должен дождаться, пока запрос долетит до nginx, попадет в лог, распарсится, и только потом IP уйдет в бан. То есть вся эта схема работает только тогда, когда сервер еще в состоянии спокойно жить и писать логи. А при нормальном флуде ничего он уже не успевает. Если у вас канал 100 мегабит, а туда прилетает 200 мегабит UDP, то на этом кино заканчивается. Канал забит, пакеты не доходят до приложения, логов нет, fail2ban ничего не видит...

Иногда смотришь на уязвимости и думаешь — ну ладно, бывает, сложная логика, хитрый баг. А иногда читаешь CVE и просто улыбаешься. Потому что это не «хакерская магия», а обычная человеческая расслабленность. В Nginx UI нашли CVE-2026-27944. Там есть эндпоинт /api/backup, который отдает бэкап конфигурации. И всё бы ничего, но авторизацию на него почему-то решили не вешать. Но самое красивое даже не это. В ответе вместе с архивом прилетает ключ для расшифровки этого самого бэкапа. Прямо в заголовке. То есть система буквально говорит: держи конфиг, держи ключ, пользуйся на здоровье. Мы с вами понимаем, что обычно лежит в таких бэкапах...

Семейный онлайн-бизнес, небольшой сайт, внезапно начинает захлёбываться. Заходит в логи — 400 000 уникальных IP за несколько часов колотят по главной странице. Для контекста: у них обычно 2-3 тысячи посетителей в день. Первая реакция — «Может это вирусный контент? Может нас кто-то упомянул?» Проверяет реферреры — тишина. Проверяет user agents — каша из Firefox, Chrome, Safari, всё как у людей. Вот только люди так не ходят: по 50 запросов в секунду с одного IP к одной и той же странице. Админ начинает банить через fail2ban. Через час понимает, что это как вычерпывать океан ложкой — IP меняются быстрее, чем он успевает добавлять правила...

в комментариях — квинтэссенция того, почему selfhosting и публичные сервисы живут в разных вселенных. Один юзер честно объясняет: «Бро, если кто-то захочет тебя положить — он положит. У тебя домашний канал 100-500 Мбит? Ботнет может гнать 100+ Гбит. Game over». Другой добавляет: «Cloudflare free tier — это единственный способ. Спрячь origin IP за прокси, молись чтобы не слили настоящий». Но самый вкусный комментарий от чувака, который попробовал: поднял сайт дома, через неделю словил атаку. Не какую-то терабитную историю — всего 2 Гбит UDP flood. Его домашний роутер от провайдера просто выключился от перегрева, пытаясь обработать миллионы пакетов в секунду...

Наконец-то дождались разговора по существу. Давайте разберем, что реально работает при защите от DDoS на типичных VPS, где канал — это не терабиты из презентаций, а скромные 100 Мбит–1 Гбит или 10 Гбит в лучшем случае. Начнем с неприятной правды: fail2ban + iptables — это защита от мусора, а не от DDoS. Когда у вас 100 Мбит канал и начинается даже небольшой UDP-флуд на 150–200 Мбит, fail2ban вообще ничего не успеет забанить — канал уже забит, пакеты не доходят до приложения, логи не пишутся. Fail2ban...

В штатах сейчас шумно вокруг сайта, где доксили (сливали данные) агентов ICE (иммиграционная полиция). Ресурс лег под мощным DDoS-ом. Админы жалуются прессе, что атака «сложная» и идет через российские прокси-серверы, из-за чего «невозможно отследить источник». Мы с вами знаем, как это переводится: «мы сэкономили на нормальном Scrubbing-центре и нас смыло обычным ботнетом». Использование российских IP — это классика жанра для маскировки, а не доказательство «руки Кремля». Но кейс показательный:...

) Кто тут любит low-code и n8n для связки сервисов? У меня для вас плохие новости. В популярных версиях нашли связку уязвимостей, которая превращает ваш удобный автоматизатор в решето. Суть в вебхуках: CVE-2026-21858 (кривая валидация ввода) в комбинации с CVE-2026-21877 (инъекция кода). Работает классически: атакующий шлёт специально сформированный запрос на вебхук, парсер n8n давится, но исполняет код. PoC уже гуляет по сети...

Cloudflare отбил рекордную атаку мощностью 29,7 Тбит/с — это новый мировой максимум, который длился всего 69 секунд. За этим стоит ботнет AISURU, состоящий из 1–4 миллионов устройств, который запускает атаки выше 1 Тбит/с в среднем 14 раз в день. Самое неприятное: куски этого ботнета продаются as-a-service за несколько сотен-тысяч долларов, то есть любой желающий может устроить хаос национального масштаба, положив магистральные каналы и лишив доступа к интернету миллионы пользователей...

Carpet bombing: вместо классического “весь трафик на один IP” атакующие размазывают умеренную нагрузку по сотням или тысячам адресов одновременно. Твои пороги per-destination молчат, потому что на каждый отдельный хост идёт условно легитимный объём, но суммарно инфраструктура всё равно схлопывается под весом. Для телекома и банков это особенно больно, потому что классические анти-DDoS решения настроены детектить “острые пики”, а тут ковровая бомбардировка без явных выбросов. Параллельно расцвели атаки через амплификацию:...

Есть такая неприятная штука в DDoS — null-routing, или blackhole. Звучит как из киберпанка, а на деле это просто провайдер отрубает твой IP от своей сети, чтобы спасти остальных соседей по стойке. Механика простая: идёт мощный UDP или SYN-флуд прямо на IP твоего сайта, весь этот мусор забивает каналы датацентра, сервер начинает тормозить, потом вылетает 503. Если у тебя нет защиты на входе, провайдер видит, что твой адрес сжирает весь аплинк и мешает другим клиентам — и просто отправляет весь трафик к тебе в “чёрную дыру”. Технически IP остаётся в таблицах маршрутизации, но физически весь трафик уходит в никуда...