Ещё один traceroute/mtr на стероидах Rust в псевдографическом исполнении.
GitHub
GitHub - lance0/ttl: Fast, modern traceroute with real-time TUI, per-hop stats, ASN/geo lookup, ECMP detection, and MPLS label…
Fast, modern traceroute with real-time TUI, per-hop stats, ASN/geo lookup, ECMP detection, and MPLS label parsing. A better mtr. - lance0/ttl
👍8
Напоминание о том, что мир был изобретён в 1970 и с тех пор ничего не поменялось, несмотря на всё построенное - всё, по-прежнему, остаётся файлом.
turso.tech
Nothing new under the sun: everything is a file
The Unix revolution was built on a key principle: everything is a file. Now, with the rise of AI Agents, LLMs have access to half a century of file-based arcana. The result? Everything is becoming a file again.
👍8👎1
Переезд всегда интересное занятие, во время которого узнаёшь много нового про свою сеть и сервисы в ней. История про переезд CA в среде с Aruba ClearPass и ситуацию тупика доверия, которую смогли решить только вручную.
Network World
The perfect certificate migration until it wasn’t: How certificates can break RADIUS trusts
RADIUS didn’t fail — certificate trust did, proving one forgotten root CA can bring modern network access to a full stop.
👍2
Что попадается в honeypot (от APNIC) и какие выводы из этого можно сделать:
- Сканирование начинается сразу
- Основная масса атак на базовые вещи, например, короткие пароли
- Наличие honeypot и анализ того что там происходит позволяет прицельно корректировать свои боевые системы
- Сканирование начинается сразу
- Основная масса атак на базовые вещи, например, короткие пароли
- Наличие honeypot и анализ того что там происходит позволяет прицельно корректировать свои боевые системы
APNIC Blog
What we learned from 63,000 attacks in 12 days on APNIC Honeynet sensors at University of Dhaka | APNIC Blog
Guest Post: After twelve days, and 63,247 attacks later, we are confident recommending some steps you can take to protect your own network.
Товарищ в понедельник пишет: "Ты видел, видел? Сразу паре десятков LIR дали адреса в RIPE NCC". Я за этим уже давно не слежу, но ситуация там такая, что эти пару десятков никакой роли не сыграли. Свою
Общую картину с адресами читаем у Geoff Huston, кто что получал, куда продавал и по какой цене в 2025 году.
/24 можно дождаться за полтора года, в растущей очереди из 800 страждущих.Общую картину с адресами читаем у Geoff Huston, кто что получал, куда продавал и по какой цене в 2025 году.
👍9
WSL - имба, переехал полностью туда с Cygwin. Но по части ИБ есть, конечно, вопросики. Даже в простом варианте, не как в статье, антивирус ловит выполнение
nmap или netcat в консоли Windows и жалуется в SOC, а то же выполнение внутри WSL не ловит. На том пока и живём.SpecterOps
One WSL BOF to Rule Them All - SpecterOps
Dan Mayer's journey to create a BOF to interact with all WSL2 versions, so he can pivot to them from heavily monitored Windows machines.
👍4👎2
Если вы попытаетесь загрузить ASR1001X на прошивке от ASR1002X, то у вас это почти получится, правда, в самом конце всё крашнется. Удачно, что оно начнёт после этого перезагружаться и при наличии консоли, вам не надо будет никого гонять к устройству, чтобы его перезагружать по вашей команде.
Однако самое сложное не это, а попасть, собственно, в режим где можно что-то делать. У Cisco для этого надо послать комбинацию с
Однако самое сложное не это, а попасть, собственно, в режим где можно что-то делать. У Cisco для этого надо послать комбинацию с
BREAK, что в эпоху эмуляции всего и вся и отсутствия непосредственного физического интерфейса от тебя до устройства превращается в приключение, по SSH такое не пролазит. В моём случае для устройства удалённого доступа к консолям это решилось [ENTER]~~b, впрочем, можно эту комбинацию и переопределить, главное не забыть, особенно в моменты когда Интернета под рукой может не оказаться.Telegram
Патчкорд
Vi рулит в ситуациях когда не остаётся вариантов, а это не такая уж и редкость. Недавнее приключение - пропадает электропитание, Juniper ребутится и возвращается в аварийном Amnesiac режиме. Повод залогиниться и разобраться, но файлы побились, включая базу…
👍4
Forwarded from Технологический Болт Генона
Поздравляю ReactOS!
30 years of ReactOS
https://reactos.org/blogs/30yrs-of-ros/
Вот ссылка на первый коммит (у меня глаз зацепился за описания API, памяти, прерываний и т.д. в txt-файлах)
> committed on Jan 23, 1996
https://github.com/reactos/reactos/commit/0f94427db073a20c24f9d85c8531fbe16490af43
На Хабре есть хаб ReactOS, там сотня постов и можно всякое интересное посмотреть в исторической перспективе
https://habr.com/ru/companies/reactos/
Например, статья про графический интерфейс, который заехал в версию 0.3.x (прикреплённая картинка со сложностью explorer.exe как раз оттуда)
> 2 дек 2014
Новая графическая оболочка рабочего стола включена в основную кодовую базу ReactOS
https://habr.com/ru/companies/reactos/articles/244811/
Русскоязычный чат - @reactos_ru
30 years of ReactOS
https://reactos.org/blogs/30yrs-of-ros/
Вот ссылка на первый коммит (у меня глаз зацепился за описания API, памяти, прерываний и т.д. в txt-файлах)
> committed on Jan 23, 1996
https://github.com/reactos/reactos/commit/0f94427db073a20c24f9d85c8531fbe16490af43
На Хабре есть хаб ReactOS, там сотня постов и можно всякое интересное посмотреть в исторической перспективе
https://habr.com/ru/companies/reactos/
Например, статья про графический интерфейс, который заехал в версию 0.3.x (прикреплённая картинка со сложностью explorer.exe как раз оттуда)
> 2 дек 2014
Новая графическая оболочка рабочего стола включена в основную кодовую базу ReactOS
https://habr.com/ru/companies/reactos/articles/244811/
Русскоязычный чат - @reactos_ru
👍3👎2
Что происходит в IRR исследование RIPE Labs. Сравнили пересечения между разными реестрами, пересечения с реальными маршрутами, всё это с привязкой к времени жизни объектов, а так же как часто объекты меняются. Никаких особенных выводов, кроме того что IRR от RIR более правдивы.
RIPE Labs
The IRR Landscape: Data Quality - the Good, the Bad, and the Outdated
In the second of our IRR landscape series, we focus squarely on data quality: how accurate, current, and usable IRR routing data really is. Using freshness, DFZ alignment and RPKI conflicts, we spotlight where third-party IRRs drift and why cleanup matters.
👍1
Про nexthop в Juniper с полным погружением и путешествием по
RIB, FIB и другим таблицам разных протоколов маршрутизации и MPLS.IoSonoUnRouter
Exploring how Junos builds next-hops
“To reach 100.64.10.0/24, next-hop is 192.168.13.2 via interface ge-0/0/1.200”. We are used to say things like that almost everyday. The concept of next-hop is trivial and extremely cle…
👍4
Зачищаю остатки в
И это типичная ситуация в больших проектах, когда изменения принимаются ситуативно. К такому приходишь почти всегда, даже тогда когда первоначально есть идеально проработанный план, а исполнителем и архитектором является всего один человек. Вопрос только в степени.
Это не решается автоматизацией, автоматизация поможет держать в одинаковом состоянии 1000 устройств, но это можно сделать и вручную, если изменения происходят не так часто. Это не решается и централизованным управлением a'la Cisco ISE или SD-Access, наличием source of truth. Как только груз накопившегося переваливает за возможность одному человеку охватить это за приемлемое время, изменения будут вноситься по факту, чтобы заработало здесь и сейчас без анализа всего предыдущего.
Чем больше людей вовлечено в этот процесс, тем система быстрее придёт к этому состоянию, потому что это не вопрос архитектуры и возможности вносить изменения, даже если всё это заложено изначально, то почти невозможно донести это понимание до каждого кто что-то меняет. С одним человеком степень этого будет меньше, но тут вопрос времени и частоты изменений тоже важен. Через год даже сам автор системы с трудом вспомнит заложенную в неё концепцию, не потратив на это достаточное время, но это надо захотеть сделать и потратить.
Добавим сюда фактор наименьшего необходимого в ИБ, когда каждому даётся ровно минимум требуемых для работы прав и линейный исполнитель может вообще не видеть конфигурацию целиком. Ведущий специалист не видеть то что делается в соседней команде и команды в целом не знать замыслов архитектуры, оставаясь только в рамках своих обязанностей. В этом случае мы буквально своими руками убиваем возможность не повторятся.
Рано или поздно, всё скатывается к мгновенным изменениям здесь и сейчас, чтобы работало, без оглядки на фундамент. Можно было бы вспомнить про Waterfall и Аgile и мир основанный на правилах "чистого кода" без запаха. Но не забываем, что даже в этом мире, нужен регулярный рефакторинг, включённый в эту концепцию. Но как и регулярный аудит, он мало помогает, фактически каждый раз приходится осознавать, считай проектировать, систему заново, что тоже в итоге приходит к ситуативным исправлениям.
Выход, заморозить систему и наслаждаться красотой построенного ничего не меняя, так мы сейчас смотрим на код первого Doom. Представьте, что все последующие версии были бы изменениями, а не новыми системами. Ещё можно жёстко ограничить вариативность, т.е. не давать внести изменения если что-то похожее уже было раньше, реализуемо, но тут у нас качество основанное на форме контроля, мы запрещаем себе помимо прочего делать улучшения вне заданных рамках, фактически заморозив систему.
Можно исключить человека, совсем, в некоторой степени это в том числе и разные графические интерфейсы того же SD-Access, когда накидываются высокоуровневые условия, реализуемые потом конфигурациями устройств, но тут уже мы имеем ситуативность в этих высокоуровневых правилах. Шаг который все хотят думать что заработает, как минимум, на него переключились маркетологи это ИИ, который сменил собой предыдущую маркетинговую штуку - автоматизацию. Делегируем и больше не смотрим что получается, своего рода страусиный подход, но вполне рабочий, думать о системе как о чёрном ящике с ИИ командной строкой. Признание того что все предыдущие методы не возымели успех.
ACL и наткнулся на такие правила:130 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 80
140 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.10 eq 443
....
290 permit tcp 192.0.2.0 0.0.0.255 198.51.100.0 0.0.0.31
....
410 permit tcp host 192.0.2.15 host 198.51.100.10 eq 443
...
470 permit object-group WEB_SERVICES 192.0.2.0 0.0.0.255 198.51.100.0 0.0.0.31
И это типичная ситуация в больших проектах, когда изменения принимаются ситуативно. К такому приходишь почти всегда, даже тогда когда первоначально есть идеально проработанный план, а исполнителем и архитектором является всего один человек. Вопрос только в степени.
Это не решается автоматизацией, автоматизация поможет держать в одинаковом состоянии 1000 устройств, но это можно сделать и вручную, если изменения происходят не так часто. Это не решается и централизованным управлением a'la Cisco ISE или SD-Access, наличием source of truth. Как только груз накопившегося переваливает за возможность одному человеку охватить это за приемлемое время, изменения будут вноситься по факту, чтобы заработало здесь и сейчас без анализа всего предыдущего.
Чем больше людей вовлечено в этот процесс, тем система быстрее придёт к этому состоянию, потому что это не вопрос архитектуры и возможности вносить изменения, даже если всё это заложено изначально, то почти невозможно донести это понимание до каждого кто что-то меняет. С одним человеком степень этого будет меньше, но тут вопрос времени и частоты изменений тоже важен. Через год даже сам автор системы с трудом вспомнит заложенную в неё концепцию, не потратив на это достаточное время, но это надо захотеть сделать и потратить.
Добавим сюда фактор наименьшего необходимого в ИБ, когда каждому даётся ровно минимум требуемых для работы прав и линейный исполнитель может вообще не видеть конфигурацию целиком. Ведущий специалист не видеть то что делается в соседней команде и команды в целом не знать замыслов архитектуры, оставаясь только в рамках своих обязанностей. В этом случае мы буквально своими руками убиваем возможность не повторятся.
Рано или поздно, всё скатывается к мгновенным изменениям здесь и сейчас, чтобы работало, без оглядки на фундамент. Можно было бы вспомнить про Waterfall и Аgile и мир основанный на правилах "чистого кода" без запаха. Но не забываем, что даже в этом мире, нужен регулярный рефакторинг, включённый в эту концепцию. Но как и регулярный аудит, он мало помогает, фактически каждый раз приходится осознавать, считай проектировать, систему заново, что тоже в итоге приходит к ситуативным исправлениям.
Выход, заморозить систему и наслаждаться красотой построенного ничего не меняя, так мы сейчас смотрим на код первого Doom. Представьте, что все последующие версии были бы изменениями, а не новыми системами. Ещё можно жёстко ограничить вариативность, т.е. не давать внести изменения если что-то похожее уже было раньше, реализуемо, но тут у нас качество основанное на форме контроля, мы запрещаем себе помимо прочего делать улучшения вне заданных рамках, фактически заморозив систему.
Можно исключить человека, совсем, в некоторой степени это в том числе и разные графические интерфейсы того же SD-Access, когда накидываются высокоуровневые условия, реализуемые потом конфигурациями устройств, но тут уже мы имеем ситуативность в этих высокоуровневых правилах. Шаг который все хотят думать что заработает, как минимум, на него переключились маркетологи это ИИ, который сменил собой предыдущую маркетинговую штуку - автоматизацию. Делегируем и больше не смотрим что получается, своего рода страусиный подход, но вполне рабочий, думать о системе как о чёрном ящике с ИИ командной строкой. Признание того что все предыдущие методы не возымели успех.
👍3
Впрочем также можно поступать и без ИИ, не обращать на строчки приведённые в самом начале никакого внимания. Так работает эволюция в природе, каждое новое изменение делается не обращая внимание на то что уже было. Главное работает и даже не плохо, реальность слева больше похожа на хаос, чем на порядок справа.
👍5