Сетевик Джонни // Network Admin
رفتن به کانال در Telegram
Я Сетевик Джонни, моя цель в телеграме рассказать все о сетях в доступной форме! Сотрудничество: @stein_media
نمایش بیشتر5 768
مشترکین
-224 ساعت
+27 روز
-3130 روز
آرشیو پست ها
Не двигайтесь: вы в ИИ-кадре
Этот бот создает фото для соцсетей в футуристичном стиле. Его можно поставить на аватарку, особенно если идете на t-sync conf. Конференция от «Т-Технологий» для опытных инженеров впервые пройдет в Москве 7 февраля.
Попробовать бота можно здесь. А узнать больше о t-sync conf и зарегистрироваться — здесь
😢 Насколько утечки 🔼 бустят эффективность фишинга
Речь пойдёт о целевых атаках, не буду говорить о массовых фишинговых письмах, на подобии наследства с Африки, ибо не эффективно, лидов нет. А вот когда у тебя на руках персональные данные сотрудников и правильно воспользовавшись можно превратить обычный спам в целевую атаку:
❗️ Допустим, в сеть утекли заказы из некоторого сервиса еды. Из них злоумышленник может узнать:
· корпоративный адрес сотрудника, который заказывает еду в офис, его имя и фамилию;
· когда происходит заказ — например, до обеда в пятницу;
· что заказывают — пиццу, бургеры, вок и т. д.;
· телефон того, кто встречает курьера;
· сколько было заказов, какая регулярность
После чего желательно в пятницу утром высылается письмо на адрес жерты:
Добрый день, Афанасий Валерьянович! Спасибо, что являетесь клиентом нашей пиццерии. Мы благодарны вам и дарим купон на скидку 20%. Работает только сегодня, автоматически применится при заказе по ссылке: <фишинговая ссылка> С уважением, пиццерия Мама Вонс.Эффективность фишинга с применением персональных данных повышается в разы, в 51% случаев сотрудники открывают, и 40% из этого числа взаимодействует с сервисом, так что, будьте аккуратней и информируйте сотрудников. #Phishing #Dataleaks | 🙁 @iscode
Коллеги, продолжаем серию практикумов от Codeby Academy🔥
Встречаемся в понедельник и проводим настоящее OSINT-расследование с Катей Тьюринг.
🟧 Регистрация в боте: https://osint-workshop.codeby.school/
Что будет:
🟧 Реальное OSINT-расследование с экспертом
🟧 Поиск скрытых связей, бенефициаров бизнеса и теневых "решал"
🟧 Работа с открытыми источниками без шаблонов
🟧 Построение гипотез и их проверка в процессе
🟧 Верификация данных и аналитические решения
Вы увидите работу опытного OSINT-аналитика в прямом эфире — с логикой, находкой, и решениями.
Почему важно быть онлайн: можно задавать вопросы и по ходу увидеть процесс, понять как формируется аналитическое мышление.
🟧 2 февраля , 19:00 МСК
🟧 Онлайн, бесплатно
🟧 Регистрация: https://osint-workshop.codeby.school
Вопросы по участию:
@CodebyAcademyBot
Repost from CURATOR | DDoS‑защита, CDN, AntiBot, WAF
💥 DDoS в 2025 году: более высокая интенсивность и огромные ботнеты
Опубликовали наш годовой отчет «DDoS, боты и BGP-инциденты в 2025 году: статистика и тренды».
Ключевые факты о DDoS-атаках:
🔹 Основные цели атак — «Финтех», «Электронная коммерция», «ИТ и Телеком», а также «Медиа». На эти четыре сегмента пришлось почти 75% всех DDoS-атак за год.
🔹 На уровне микросегментов чаще всего атаковали платежные системы, рестораны и доставку еды, медиа, банки и онлайн-образование — вместе они собрали около половины всех инцидентов.
🔹 В декабре зафиксировали самые интенсивные L3-L4 DDoS-атаки 2025 года: 3,06 и 3,51 Тбит/с в пике, примерно втрое выше рекорда 2024 года. Обе атаки были направлены на сегмент онлайн-букмекеров.
🔹 Растут не только максимумы, но и «масса»: медианная интенсивность UDP flood (преобладающий вектор) выросла на 🔺57%, то есть даже рядовые атаки стали ощутимо более разрушительными.
🔹 Самый крупный DDoS-ботнет — 5,76 млн IP-адресов. Про него подробно писали здесь.
🔹 Самая длительная атака продолжалась почти 5 суток, но в целом атаки стали короче: средняя длительность снизилась почти вдвое по сравнению с прошлым годом.
👉 Больше подробностей — в полной версии отчета на сайте CURATOR.
🥷 4 YouTube-канала для системного администратора
По просьбе одного из подписчиков, а точнее Alexander S выложить YT авторов по нашему направлению, что-ж, тема отличная, не знаю почему раньше этим не занялся, так как в любой связанной с айтишкой профессии, в системном администрировании специалисту требуется постоянное обучение, без которого нельзя развить необходимые навыки и наработать опыт.
1. Andrey Sozykin — на канале доступны видеолекции, подготовленные автором на основе этих курсов. Информация подается в краткой форме без затрудняющих восприятие деталей. Автор подробно разбирает следующие темы: компьютерные сети, защищенные сетевые протоколы, SQL, Python и нейросети.
2. Вера Дроздова — роликов немного, но они оформлены в виде лекций и хорошо продуманы. Объясняются следующие темы: введение в компьютерные сети, сети ЭВМ и телекоммуникации, беспроводные технологии и компьютерные сети, сетевые технологии – все как в универе.
3. tutoriaLinux — автор профессиональный системный администратор, веб-разработчик, безопасник и архитектор датацентров с более чем десятилетним опытом. Обсуждаются следующие темы: получение первой работы, команды Linux, SRE, GIT, сети, VPN, оболочки и масса прочего. Также здесь можно найти интересные интервью.[EN]
4. ExtremeCode — и замыкающий автор в нашем списке это ExtremeCode, первые три автора это скучная техническая часть, а этот автор поможет скрасить вечера или послеобеденные будни в офисе)
админ вернулся с попойки, лайк посту поставьте братва и посты чаще начнут выходить 🌟
🥷 4 YouTube-канала для системного администратора
По просьбе одного из подписчиков, а точнее Alexander S выложить YT авторов по нашему направлению, что-ж, тема отличная, не знаю почему раньше этим не занялся, так как в любой связанной с айтишкой профессии, в системном администрировании специалисту требуется постоянное обучение, без которого нельзя развить необходимые навыки и наработать опыт.
1. Andrey Sozykin — на канале доступны видеолекции, подготовленные автором на основе этих курсов. Информация подается в краткой форме без затрудняющих восприятие деталей. Автор подробно разбирает следующие темы: компьютерные сети, защищенные сетевые протоколы, SQL, Python и нейросети.
2. Вера Дроздова — роликов немного, но они оформлены в виде лекций и хорошо продуманы. Объясняются следующие темы: введение в компьютерные сети, сети ЭВМ и телекоммуникации, беспроводные технологии и компьютерные сети, сетевые технологии – все как в универе.
3. tutoriaLinux — автор профессиональный системный администратор, веб-разработчик, безопасник и архитектор датацентров с более чем десятилетним опытом. Обсуждаются следующие темы: получение первой работы, команды Linux, SRE, GIT, сети, VPN, оболочки и масса прочего. Также здесь можно найти интересные интервью.[EN]
4. ExtremeCode — и замыкающий автор в нашем списке это ExtremeCode, первые три автора это скучная техническая часть, а этот автор поможет скрасить вечера или послеобеденные будни в офисе)
2026 станет годом гибридных атак: цифровые взломы → физический ущерб
Бизнес входит в 2026 год с новым типом угроз:
атака начинается в почте → заканчивается пустым складом.
Кибергруппировки уже координируют действия с физическими преступниками:
письмо → взлом → подмена документов → отключение камер → перехват груза.
Такие атаки не ловятся антивирусом.
Их ловят выстроенные процессы, обучение и зрелость информационной безопасности компании.
Если хочешь войти в 2026 осознанно, а не вслепую — здесь ты узнаешь, что действительно происходит в мире угроз: Мир Цифры | Туманов
👉 Подписывайтесь, чтобы быть на шаг впереди
Реклама.
О рекламодателе.
+4
От отключения хостером до полной стабильности
Как CURATOR защитил 3DNews и ServerNews от DDoS и ускорил доставку контента
Атака почти 3000 Мбит/с — и хостер 3DNews «падает» меньше чем за полчаса, просто отключив сеть.
Для медиа это катастрофа: простой, потеря трафика и удар по репутации.
Команда CURATOR подключилась в самый критичный момент и быстро вернула сайт к жизни. Подробнее о том, как это было сделано - в карточках.
Этот и другие реальные кейсы, а также экспертная информация в области кибербезопасности — в канале CURATOR.
•
aiohttp по умолчанию работает через getaddrinfo(), но может быть настроен на использование aiodns (асинхронный DNS через libcares), где возможно встроенное кэширование.
• dnspython — отдельный DNS-клиент, выполняющий DNS-запросы напрямую. С версии 2.0 поддерживает явное включение кэша:
import dns.resolver
resolver = dns.resolver.Resolver()
resolver.cache = dns.resolver.Cache()
Таким образом, поведение зависит от конкретной библиотеки. Стандартный socket и большинство оберток над ним, включая requests, кэширование не реализуют и полагаются на системный резолвер.
✋ В следующей части расскажу про контейнеры и оркестрацию, ставьте 👍
#DNS #Linux | 😏 @iscode🥷 Как работает DNS в Linux. Часть 2: уровень приложений и языков программирования
glibc
Хотя официально считается, что glibc не реализует полноценный DNS-кэш (в отличие от демонов вроде systemd-resolved, dnsmasq или nscd), в её реализации резолвера есть несколько механизмов, которые действуют как очень простое и ограниченное кэширование или оптимизация запросов.
— Во-первых, используется NSS (Name Service Switch), который может быть сконфигурирован для работы с nscd, systemd-resolved или другими кэширующими компонентами. Например, с помощью следующей директивы в файле nsswitch.conf:
hosts: files resolved myhostname
Где вместо resolved также может быть и nscd. Хотя nscd — отдельный демон, он поставляется вместе с glibc в большинстве дистрибутивов и тесно интегрирован с ней.
Когда nscd запущен и настроен (часто включен по умолчанию для passwd, group, hosts), библиотеки glibc (getaddrinfo, gethostbyname) будут обращаться к нему первыми. Nscd кэширует ответы до истечения их TTL. Кэширование в этом случае происходит вне самой библиотеки glibc, но glibc использует этот кэш прозрачно для приложения.
🔍 В реализации DNS-резолвера внутри glibc (в файле resolv/res_query.c и др.) содержатся оптимизации, такие как повторное использование сокета и игнорирование TTL при повторных запросах внутри одного вызова, которые можно рассматривать в качестве некого микро-кэша в контексте одного вызова функции разрешения. Эти оптимизации не сохраняют результаты между разными вызовами getaddrinfo или между разными процессами и действуют только в рамках одного системного вызова функции.
— Модули NSS (особенно files) кэшируют данные из статических файлов. Например, nss-files (работающий в том числе с /etc/hosts) по сути "кэширует" содержимое этих файлов в памяти процесса после их первого чтения (до перезагрузки процесса или вызова, инвалидирующего кэш NSS). Это не DNS-кэширование в чистом виде, но влияет на процесс разрешения имен, в котором участвует DNS.
Java
Java поддерживает встроенный DNS-кэш с гибкими настройками времени жизни записей.
Особенности работы
Без использования Security Manager (начиная с Java 11 - это поведение по умолчанию):
- положительные ответы кэшируются на 30 секунд (максимум, даже если DNS-сервер указал больший TTL);
- отрицательные ответы (NXDOMAIN) — 10 секунд.
С использованием Security Manager:
- положительные ответы кэшируются бесконечно (риск устаревших записей);
- отрицательные ответы не кэшируются.
Управление
Настройки указываются в свойствах JVM. TTL в секундах для успешных запросов:
networkaddress.cache.ttl=60
TTL для неудачных запросов (NXDOMAIN):
networkaddress.cache.negative.ttl=10
Варианты значений:
0 — отключить кэширование;
-1 — кэшировать бессрочно (только для положительных ответов).
Способы настройки
1. Аргументы JVM:
java -Dnetworkaddress.cache.ttl=60 -jar app.jar
2. В коде (глобально для JVM):
Security.setProperty("networkaddress.cache.ttl", "60");
Go
Go использует две модели резолвинга:
- через cgo — вызывает системный getaddrinfo() (включая NSS). Работает через системные настройки (/etc/nsswitch.conf, /etc/resolv.conf);
- Pure Go resolver — реализует собственный DNS клиент, минуя системные библиотеки.
Выбор резолвера:
GODEBUG=netdns=go # встроенный резолвер с кэшем
GODEBUG=netdns=cgo # через системный getaddrinfo()
При использовании Pure Go резолвера Go реализует in-memory DNS-кэш внутри процесса. Этот кэш хранит успешные (A, AAAA, CNAME) и отрицательные (NXDOMAIN) ответы, соблюдая их TTL. Кэш имеет фиксированный размер (реализует эвристику LRU), хранится в памяти процесса и разделяется между горутинами внутри этого процесса, но не разделяется между разными процессами или экземплярами приложений.
Python
По умолчанию модуль socket и большинство стандартных библиотек (включая requests, urllib3) используют системный вызов getaddrinfo() и не имеют встроенного кэша DNS.
• requests → использует urllib3, который делегирует разрешение DNS системной библиотеке (socket.getaddrinfo()), без кэширования.🥷 Джонни вещает: 8 популярных сетевых протоколов с наглядным объяснением
Сетевые протоколы работают на разных уровнях модели OSI, это важно знать.
🌜 Эта многоуровневая архитектура обеспечивает стандартизированное взаимодействие между различными программными и аппаратными компонентами в сети.
1. 𝗧𝗖𝗣/𝗜𝗣 — базовый метод передачи информации между устройствами в Интернете. В то время как IP отвечает за адресацию и маршрутизацию пакетов данных, TCP заботится о сборке данных в пакеты, а также о надежной доставке.
2. 𝗛𝗧𝗧𝗣 — играет решающую роль при доступе к веб-сайтам. Он отвечает за получение и доставку веб-контента с серверов конечным пользователям.
3. 𝗛𝗧𝗧𝗣𝗦 — усовершенствованная версия HTTP, HTTPS объединяет протоколы безопасности (а именно TLS) для шифрования данных, обеспечивая безопасный и конфиденциальный обмен между браузерами и веб-сайтами.
4. 𝗙𝗧𝗣 — Как следует из названия, FTP используется для передачи файлов (загрузки и скачивания) между компьютерами в сети.
5. 𝗨𝗗𝗣 — более оптимизированный аналог TCP, UDP передает данные без накладных расходов на установление соединения, что приводит к более быстрой передаче, но без гарантии, что данные будут доставлены или будут в порядке.
6. 𝗦𝗠𝗧𝗣 — движущая сила обмена электронной почтой, которая управляет форматированием, маршрутизацией и доставкой писем между почтовыми серверами.
7. 𝗦𝗦𝗛 — криптографический сетевой протокол, который обеспечивает безопасную передачу данных по незащищенной сети.
- Он обеспечивает безопасный канал, гарантируя, что хакеры не смогут интерпретировать информацию путем подслушивания 📠
#Protocol #cheatsheet | 😊 @iscode
Repost from STEIN: ИБ, OSINT
🥸 Личный VPN: юзер ликует, VLESS смеётся, а РКН плачет. v.2
Представьте: ваш VPN становится невидимкой для РКН, маскируясь под обычный трафик от народного мессенджера Max. Никаких блокировок, никаких подозрений.
— В этой статье вы узнаете, как настроить такой «стелс» за 10 минут через удобный 3x-UI интерфейс с учётом последних потуг от регулятора (лазейка есть, и способ в разы дешевле чем Double VPN + gRPC + SelfSNI + бубны + домены с закосом под трафик от сайта и прочая х)
⤷ teletype.in/@secur_researcher/vpn_tutorial
#VPN #xHTTP #VLESS | 😈 @secur_researcher
⚡ Как данные передаются через Интернет? Какое это имеет отношение к модели OSI? Как TCP/IP вписывается в это?
🚠 Семь уровней модели OSI:
1. Физический уровень
2. Канальный уровень
3. Сетевой уровень
4. Транспортный уровень
5. Сеансовый уровень
6. Уровень представления
7. Прикладной уровень
#Network #OSI
🥷 Как работает DNS в Linux. Часть 2: где именно кэшируется DNS в Linux
Ядро
Ядро Linux может опосредованно “кэшировать” DNS-трафик через подсистему
netfilter/conntrack, если используется stateful-фильтрация. Несмотря на то, что UDP — протокол без установления соединения, ядро отслеживает состояние пакетов, относящихся к одному блоку запрос-ответ (например, запрос от [src_ip:src_port] к [8.8.8.8:53] и ожидаемый ответ от [8.8.8.8:53] к [src_ip:src_port]) и временно хранит информацию — по умолчанию около 30 секунд. Это необходимо для NAT и правил вроде iptables -m conntrack --ctstate ESTABLISHED,RELATED.
Проверить текущие записи можно командой:
conntrack -L -p udp --dport 53
В списке отобразятся активные DNS-сессии, которые считаются допустимыми до истечения таймаута. Повторные DNS-запросы к тем же адресам в пределах срока жизни этих записей могут быть обработаны в рамках существующей записи состояния. Это не полноценное кэширование DNS-ответов, но conntrack может влиять на поведение сетевого уровня, особенно при диагностике проблем с NAT или firewall.
Для удаления записей из таблицы отслеживания соединений можно воспользоваться командой:
conntrack -D -p udp --dport 53
Системный уровень
1. systemd-resolved
Современные дистрибутивы с systemd часто используют systemd-resolved в качестве основного DNS-клиента, который:
- имеет собственный кэш DNS-запросов, включая положительные и (опционально) отрицательные ответы;
- поддерживает split DNS (разные DNS-серверы для разных доменов), конфигурируется через systemd-networkd или NetworkManager;
- поддерживает DNS-over-TLS (DoT), включая fallback-серверы и DNSSEC;
- предоставляет API по D-Bus (org.freedesktop.resolve1), позволяет получать статус, менять настройки и управлять кэшем через resolvectl.
2. nscd (Name Service Cache Daemon)
Если запущен nscd, он кэширует результаты NSS-вызовов, включая DNS. Его настройки находятся в /etc/nscd.conf
enable-cache hosts yes
positive-time-to-live hosts 600
negative-time-to-live hosts 20
‼️ Важный момент: nscd устарел и не рекомендуется к использованию в новых системах. В Debian-based дистрибутивах чаще всего его заменяет systemd-resolved, но в RHEL-based дистрибутивах он ещё встречается.
3. Популярные локальные кэширующие резолверы
dnsmasq — популярный выбор для локального кэширования(настройка кэша):
cache-size=1000 (cache-size управляет размером кэша. По умолчанию он небольшой (150), и для заметного эффекта его увеличивают до 1000–5000)
neg-ttl=60
unbound — более мощный DNS-рекурсор.
Управление кэшем гибкое:
Размер кэша задаётся параметром msg-cache-size (отвечает за ответы) и rrset-cache-size (за записи ресурсов):
msg-cache-size: 50m
rrset-cache-size: 100m
TTL кэшированных ответов можно ограничить директивами cache-min-ttl и cache-max-ttl
cache-min-ttl: 30 # минимальный TTL для любых ответов
cache-max-ttl: 86400 # максимальный TTL (24 часа)
bind - распространенный DNS-сервер с поддержкой рекурсивного разрешения и кэширования. Управление кэшем и его мониторинг осуществляется через команду rndc (Remote Name Daemon Control).
В конфигурационном файле named.conf можно задавать TTL для кэша и контролировать поведение:
options {
max-cache-ttl 86400; // максимальное время жизни кэша (в секундах)
max-ncache-ttl 3600; // максимальное время жизни негативных ответов (NXDOMAIN)
};
✋ В следующей части расскажу про уровни приложений и языков программирования, ставьте 👍
#DNS #Linux | 😏 @iscode👀 Наглядно показываем принцип работы и область применения восьми самых популярных сетевых протоколов
⚙️ Публикации краткого формата:
1. Насколько утечки 🔼 бустят эффективность фишинга
2. Удаляем файлы с Linux правильно
3. 10 полезных команд в Linux для сетей LAN и WI-FI
4. NAT в сетях
5. Пишем более читаемый текст в терминале Linux
6. Реверс сокс-прокси
7. Утечка DNS
8. Шпаргалка по OpenSSL
9. Основы DNS: работа DNS-request'a
10. Основы DNS: иерархия
11. Записи DNS и их типы
12. 12 заблуждений сетевого администратора
13. Настройка Git сервера с нуля
14. Десятка лучших консольных команд
15. DNS-хостинг для начинающих, многообразие ресурсных записей (ч.1)
16. DNS-хостинг для начинающих, многообразие ресурсных записей (ч.2)
17. DNS-хостинг для начинающих, многообразие ресурсных записей (ч.3)
18. DNS-хостинг для начинающих, многообразие ресурсных записей (ч.4)
19. 10 опасных команд Linux, которые вы никогда не должны запускать
20. Функционал SSH: проброс портов
21. Откуда этот конфиг? [Debian/Ubuntu]
22. Функционал SSH: ключ сервера SSH
23. Функционал SSH: вложенные туннели
24. Функционал SSH: динамический проброс портов
25. Функционал SSH: управление ключами SSH
26. HTTP: Uniform Resource Locator — или просто URL
27. Протокол HTTP: принцип работы и методы
28. Протокол HTTP: коды состояния ответов и ошибки
29. Распространенные ошибки веб-сервера Nginx (1 ч.)
30. Консольная утилита для визуализации результата любых shell команд
31. Как провести стресс-тестирование вашей системы Linux
32. Распространенные ошибки веб-сервера Nginx (2 часть)
33. Функционал SSH: проброс X-сервера
34. Функционал SSH: проброс stdin/out
35. Функционал SSH: туннелирование
36. Руководство по настройке и использованию rsync
37. Тонкая настройка SSH для безопасности серверов
38. Функционал SSH: алиасы в SSH
39. А ваша система мониторинга орёт, когда меняется маршрутизация? (ч.1)
40. А ваша система мониторинга орёт, когда меняется маршрутизация? (ч.2)
41. А ваша система мониторинга орёт, когда меняется маршрутизация? (ч.3)
42. По следам одного взлома: когда 'a' не равно 'а' (ч.1)
43. По следам одного взлома: когда 'a' не равно 'а' (ч.2)
44. По следам одного взлома: когда 'a' не равно 'а' (ч.3)
45. Проблема ботов и идея защиты, или о том как я использую zip-бомбы для защиты своего сервера
46. Проблема ботов и идея защиты, или о том как я использую zip-бомбы для защиты своего сервера(ч.2)
47. Дыра в щите Cloudflare: как атака на Jabber.ru вскрыла проблему, о которой молчат c 2023 (ч.1)
48. Технический ликбез: CAA, RFC 8657 и как это должно нас спасать
49. Слон в посудной лавке: при чём тут Cloudflare?
50. Как работает DNS в Linux. Часть 1: от getaddrinfo до resolv.conf
51. Как работает DNS в Linux. Часть 1: NSS
52. Как работает DNS в Linux. Часть 1: Библиотеки
53. Как работает DNS в Linux. Часть 1: обработка resolv.conf и что делает res_query()
54. Как работает DNS в Linux. Часть 1: порядок реализации запросов и приоритеты
55. Как работает DNS в Linux. Часть 1: порядок реализации запросов и приоритеты (ч.2)
56. Как работает DNS в Linux. Часть 1: краткое резюме и ключевые моменты
57. Как работает DNS в Linux. Часть 2: все уровни DNS-кэширования
🖥 Подборки обучающих материалов:
1. Подборка обучающих материалов по компьютерных сетях
2. Cisco Systems — подборка обучающих материалов
3. Сетевое администрирование: подборка бесплатных курсов
4. Большая подборка вопросов с собеседований: Системного администратора Linux/Devops
5. Репозиторий 101 Linux Commands eBook
🔍 Доклады и видеоматериалы:
1. Мониторинг и Kubernetes
2. Автомасштабирование и управление ресурсами в Kubernetes
3. Деление IP сети на подсети при помощи маски легко и быстро
4. portknocking на mikrotik
5. Mikrotik на VPS
6. Установка и настройка Sysmon
7. Изменение Windows 10 из Proffesional в Enterprise 2021 LTSC
8. Расследование одного взлома: SSH туннель
🔹🔹🔹🔹🔹🔹🔹🔹🔹
Оказался(ась) на этом канале впервые и потерялся? — можешь звать меня Джонни, я буду твоим проводником.
Этот Telegram-канал — солянка для сетевых инженеров и сисадминов. Здесь мы не ищем тайны, а чиним сети, настраиваем серверы и пишем скрипты, чтобы работалось лучше. Мы соберём пазл из BGP, OSPF, Ansible и Kubernetes, чтобы ты видел картину целиком, а не только красные дашборды.
🕹 Хочешь, чтобы твои сети аптаймились, а скрипты работали с первого раза? Тогда проваливайся глубже в канал и начинай читать. Добро пожаловать!
🔍 Протоколы сетевого управления и стандарты:
1. OSPF — протокол динамической маршрутизации
2. NDP — протокол управления сетевыми узлами IPv6
3. BGP — протокол маршрутизации
4. RIP — протокол маршрутизации
5. FTP — протокол передачи файлов
6. SONET — стандарт передачи данных по оптоволоконным сетям
7. RDP — протокол удаленного рабочего стола
8. RPC — протокол удаленного вызова процедур
9. SMB — протокол общего доступа к файлам
10. SIP — протокол инициации сеанса
11. QUIC — протокол универсальной управляемой передачи
12. NTP — протокол сетевой синхронизации времени
13. LLDP — протокол обнаружения топологии сети
14. SNMP — инструмент для управления сетями
15. DNS — система преобразования доменных имен
🔍 Статьи и методики по использованию:
1. Примеры атак XSS и способов их ослабления
2. Что такое триада КЦД: шпаргалка для начинающих специалистов в сфере кибербезопасности
3. Микросервисная архитектура на примере Python и gRPC
4. Компьютерные сети от А до Я: стек протоколов TCP/IP
5. Основы методологии DevOps
6. «Я тебя по IP вычислю»: как хакеры рассекречивают звенья цепи Tor
7. TCPDump — инструмент для анализа сетевого трафика
8. Wireshark — Анализ сетевого трафика
9. VMWare: создание виртуальных машин
10. Утилиты на PowerShell для системных администраторов
11. Как я искал нормальный RDP-клиент и нашел целых три
12. DNSSEC — набор расширений для обеспечения безопасности DNS
13. Будни техпода. Ошибки при подключении по RDP
14. Будни техпода. Как разместить Telegram-бота на виртуальном сервере
15. Будни техпода. Подготовка сервера с Linux для работы по RDP
16. Будни техпода. Разворачиваем сайт из конструктора на VDS за 130 рублей
17. Будни техпода. Как перенести данные с одного виртуального хостинга на другой
18. Как я сделал самый быстрый в мире файловый сервер
19. HDD, SSD или NVMe: что выбрать для виртуального сервера
20. Nmap — инструмент для сканирования хостов
21. Две скрытые кайфовые фичи Windows Admin Center: как найти, настроить и использовать
22. Устройство TCP: Реализация SYN-flood атаки
23. Tcpdump на разных уровнях: анализ и перехват трафика
24. Тачку на прокачку: тюнинг Wireshark
25. Настройка Git сервера с нуля
26. 10 типичных ошибок при использовании k8s
27. Внутреннее устройство Kubernetes-кластера простым языком
28. Сказ о том, как два сервера изменили судьбу сетевой команды
🔹🔹🔹🔹🔹🔹🔹🔹🔹
Оказался(ась) на этом канале впервые и не знаешь с чего начать? — можешь звать меня Джонни, я буду твоим проводником
Этот Telegram-канал — солянка для сетевых инженеров и сисадминов. Здесь мы не ищем тайны, а чиним сети, настраиваем серверы и пишем скрипты, чтобы работалось лучше. Мы соберём пазл из BGP, OSPF, Ansible и Kubernetes, чтобы ты видел картину целиком, а не только красные дашборды.
🕹 Хочешь, чтобы твои сети аптаймились, а скрипты работали с первого раза? Тогда проваливайся глубже в канал и начинай читать. Добро пожаловать!
Статьи и методики по использованию:
1. Примеры атак XSS и способов их ослабления
2. Что такое триада КЦД: шпаргалка для начинающих специалистов в сфере кибербезопасности
3. Микросервисная архитектура на примере Python и gRPC
4. Компьютерные сети от А до Я: стек протоколов TCP/IP
5. Основы методологии DevOps
6. «Я тебя по IP вычислю»: как хакеры рассекречивают звенья цепи Tor
7. TCPDump — инструмент для анализа сетевого трафика
8. OSPF — протокол динамической маршрутизации
9. NDP — протокол управления сетевыми узлами IPv6
10. BGP — протокол маршрутизации
11. RIP — протокол маршрутизации
12. DNSSEC — набор расширений для обеспечения безопасности DNS
13. SONET — стандарт передачи данных по оптоволоконным сетям
14. FTP — протокол передачи файлов
15. RDP — протокол удаленного рабочего стола
16. RPC — протокол удаленного вызова процедур
Публикации краткого формата:
Подборки обучающих материалов:
1. Подборка обучающих материалов по компьютерных сетях
2. Cisco Systems — подборка обучающих материалов
3.
4.
5.
6.
7.
8.
