🖥 Самый ранний вариант DOS атаки - SYN Flood.

• Рассмотрим эпизод из карьеры знаменитого хакера Кевина Митника, который пытался получить несанкционированный доступ к машине своего давнего оппонента Цутому Симомуры. Для этого он хакнул машинку в лабораторной сети и постарался представиться логин-сервером, с которого был доверенный логин на искомый терминал.

• Проблема в том, что если спуфить подключение, представляясь чужой машиной, нужно как-то вывести настоящую машину из обращения, чтобы она не смогла ничего сказать. Для этого Митник использовал генерацию большого количества SYN-пакетов со взломанной машинки, отправил их с указанием чужого валидного, но не используемого спуфленного IP-адреса из этой локалки.

• Server.login честно принял все пакеты в очередь полуоткрытых соединений, забил очередь до потолка и отослал все SYN-ACK несуществующей машине. Так что, когда Митник успешно спуфил соединение, представляясь логин-сервером, тот не мог ничего сказать терминалу, который слал SYN-ACK пакет, так как логин-сервер был уже плотно занят. В итоге Митник установил TCP-соединение, получил shell, посадил туда бэкдор, закрыл соединение и отправил reset на логин-сервер. Вся атака, если верить логам, длилась 16 секунд.

• Атака Митника - это правильный пример SYN Flood - одного из самых старых, по крайней мере, описанных в летописной истории, вариантов DoS-атаки. Тогда это была ещё не распределённая атака, а Denial of Service с одной машины. Но после этого появился подробный разбор этой ситуации с логами и прочим в mailing-листах: сначала вышла книжка Cимомуры, потом - Митника. Таким образом, люди, которые интересуются интернетом и технологиями, узнали, что так, оказывается, было можно.

Продолжение: ⬇️

👨‍💻 Краткий справочник по «всем-всем» командам Linux.

• Вероятно, что вы уже видели этот "краткий" справочник на хабре. Он был опубликован еще в 2022 году, но постоянно дополнялся автором и актуализировался.

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

➡️ https://habr.com/ru/post/683638

#Linux

📶 IPv6...

• IPv6 больше четверти века обещает избавить интернет от тесноты IPv4-адресов. Его называли будущим сети и грозили цифровым апокалипсисом IPv4… Но на дворе уже 2026 год, а IPv4 всё ещё живее всех живых. Почему за 30 лет мы так и не перешли на IPv6?

• В начале 90-х стало ясно, что 4,3 млрд адресов IPv4 - это очень мало для растущего интернета. Спустя несколько лет инженерная рабочая группа IETF начала разрабатывать новый протокол IPv6, который она представила в качестве долгосрочного решения проблемы ограниченного адресного пространства. Его базовая спецификация - RFC 1883 - была опубликована в декабре 1995 года. А после, в 1998 году, была обновлена до RFC 2460.

• Новый протокол IPv6 получил адреса длиной 128 бит (против 32 бит у IPv4) - то есть примерно 340 ундециллионов адресов. Про дефицит адресов в этом случае можно забыть навсегда.

• Казалось, что светлое будущее у интернета будет только благодаря IPv6. Поэтому в конце 90-х появились первые реализации нового протокола в ОС (в Linux — в 1996 году, в Windows — с 2000 года).

• Многие ожидали, что переход на IPv6 произойдёт чуть ли не в середине нулевых, ещё до наступления спрогнозированного адресного коллапса IPv4. Однако реальность скорректировала планы, потому что инженеры придумали, как оттянуть "конец" IPv4.

• До появления IPv6 индустрия внедрила бесклассовую адресацию (CIDR), переменную длину маски (VLSM) и, главное, NAT (Network Address Translation). Всё это делалось ради того, чтобы IPv4 жил.

• Благодаря NAT десятки устройств смогли скрываться за одним публичным IPv4-адресом, и миру этого хватило на годы вперёд. Появились даже приватные подсети (10.0.0.0/8, 192.168.0.0/16 и др.) для устройств, которые не требуют глобальных адресов (это про умные кофеварки и пылесосы).
"Эликсиры молодости" для IPv4 настолько хорошо сработали, что переход на IPv6 обесценился. Между тем свободные IPv4-адреса формально закончились.

• В 2011 году IANA (координирует распределение уникальных идентификаторов в интернете) выдала последние крупные блоки региональным регистраторам, а к 2020 году исчерпались и региональные пулы. Например, Европа объявила об опустевшем фонде IPv4 осенью 2019 года.
Но интернет не рухнул. Провайдеры ещё раз сжали IPv4-адреса в NAT, и появились CGNAT (Carrier-Grade NAT) на уровне операторов связи.

• Но что с IPv6? Его официально "запускали" несколько раз. World IPv6 Day в июне 2011 года позволил тысячам сайтов целые сутки тестировать работу по IPv6. Годом позже, 6 июня 2012 года, состоялся World IPv6 Launch — провайдеры и компании торжественно объявили о постоянном включении IPv6. Казалось, вот он, переломный момент, но прошёл 2012-й, 2013-й… начался 2026-й, а картина практически не изменилась.

• Главная проблема нового протокола кроется в его дизайне. IPv6 не совместим с IPv4 - это фактически отдельная сеть. Устройство или сайт с IPv6 не сможет напрямую "общаться" с узлом, у которого только IPv4.

• В итоге любая компания, решившая "прикрутить" IPv6, сталкивается с тем, что полностью отключить IPv4 не получится. Приходится поддерживать обе адресации, удваивая часть инфраструктуры.

• Получается довольно мрачная картина. Однако это не значит, что IPv6 он был ошибкой или совсем никому не нужен. Наоборот, IPv6 - это будущее, которое наступает постепенно.

• Большие игроки (Google и Amazon) давно работают по IPv6, им это по силам и выгодно, так как масштабы большие. Мобильные операторы, особенно в Азии и Европе, за последние годы резко подняли долю IPv6, ведь смартфонам не нужен статический IPv4. А новые проекты и стартапы уже стараются закладывать поддержку IPv6 "с нуля".

• Но массового отключения IPv4 в ближайшее время ждать не стоит (особенно в России). Эксперты полагают, что как минимум до конца десятилетия IPv4 будет сосуществовать с IPv6, а возможно, и ещё дольше.

• Пока нам всем приходится жить на двух протоколах сразу, лавируя между старым и новым. Кто знает, может, через десять лет мы оглянемся и удивимся, как долго жили в эпоху IPv4.

#Разное

• 19 марта была осуществлена целенаправленная и эффективная атака на цепочку поставок через Trivy, инструмент для сканирования уязвимостей с открытым исходным кодом, который используют разработчики и DevOps-команды по всему миру. Хакерам из TeamPCP удалось внедрить вредоносное ПО в официальные рабочие процессы GitHub Actions и образы Docker, относящиеся к Trivy.

• В результате каждый автоматизированный скан конвейера запускал вредоносное ПО, осуществляющее кражу ключей SSH, облачных токенов доступа, криптовалютных кошельков и других ценных данных из пораженных систем. Учитывая критический характер инцидента, ему был присвоен идентификатор CVE-2026-33634 с почти максимальным баллом: CVSS4B 9.4.

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

• 23 марта была обнаружена аналогичная компрометация в другом инструменте безопасности приложений: GitHub Action для Checkmarx KICS, а также Checkmarx AST. Три часа спустя вредоносный код был удален и здесь. Также TeamPCP смогли скомпрометировать расширения Open VSX, поддерживаемые Checkmarx: cx-dev-assist 1.7.0 и ast-results.

• 24 марта был скомпрометирован популярный проект, использующий сканирование кода от Trivy - универсальная библиотека для вызова ИИ-систем LiteLLM (многофункционального шлюза, который используется в множестве ИИ-агентов). Злоумышленники опубликовали в PyPI вредоносные версии LiteLLM - 1.82.7 и 1.82.8. Версия 1.82.8 распространяла малварь через .pth - файл, и вредоносный код выполнялся при каждом запуске Python-интерпретатора. В настоящее время вредоносные версии уже удалены, и последней "чистой" версией является 1.82.6.

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

• Если вам интересна данная тема, то по ссылке ниже можно найти технический анализ и подробный разбор этой атаки.

➡Компрометация репозитория;
➡Технический анализ;
➡OpenVSX-версия зловреда;
➡Жертвы;
➡Заключение.

➡️ https://securelist.ru/litellm-supply-chain-attack

#Security

• Хорошая книга, хоть и на английском, которая посвящена анализу пакетов в Wireshark - самом популярном в мире сетевом анализаторе.

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

➡️ Скачать можно с GitHub.

• В качестве дополнения:

➡Лабораторные работы для получения практического опыта работы с Wireshark;
➡Бесплатный курс: Компьютерные сети 2025;
➡Руководство: Анализ трафика сети посредством Wireshark;
➡Полный список фильтров Wireshark;
➡Статья: Wireshark. Лайфхаки на каждый день;
➡Статья: Практические приёмы работы в Wireshark;
➡Mindmap: Wireshark;
➡Не забывайте по наш репозиторий, в котором собрана подборка материала для изучения сетей (от курсов и книг, до шпаргалок и сообществ): https://github.com/SE-adm/Awesome-network

#Wireshark #Сети

🎉 Результаты розыгрыша:

🏆 Победители:
1. Vova (@Dastrilla)
2. venstom24 (@defraq99)
3. Darkrull (@Darkrull)
4. Nikita (@niktorinf)
5. Марат (@strong_690)

✔️Проверить результаты

⚡️ Электричество — не игрушка.

• В блоге программиста Алекса Йорка есть забавная история, которая произошла с ним несколько лет назад. Он писал программу для распаковки GZIP-файлов и столкнулся с неожиданной ошибкой, указывающей на повреждение архива. Это было странно - ранее ничего подобного не случалось, но теперь ошибка появлялась каждые несколько минут и не исчезала даже после перезагрузки компьютера.

• Алекс начал искать и устранять возможные причины неполадки одну за другой. Сперва он решил, что проблема возникала из-за состояния гонки, но GZIP-компрессор не был многопоточным. Затем исключил варианты с ошибкой кодирования и повреждением данных. Однако ошибки возникали без всякой логики: то появлялись, то исчезали.

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

• Позже к программным сбоям добавились проблемы с операционной системой, а приложения стали загружаться невероятно долго - но только если ноутбук был подключен к сети. И тогда программист предположил, что проблема должна быть связана с перепадами напряжения и электропроводкой в квартире - и точно, розетка, к которой он подключал устройство, не имела заземления. Алекс вызвал электрика, который установил новую розетку. После этого проблемы исчезли, а программа заработала без сбоев.

➡️ https://alexyorke.github.io/gzip

#Оффтоп #Разное

• Доброе утро...🫠

#Понедельник