🥷 Джонни вещает: проброс авторизации

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

🆘 Для понимания ситуации, пример ниже будет ссылаться на вот эту схему (click)

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.

— Компромиссным вариантом было бы иметь «другой» SSH-ключ, который бы авторизовывал [email protected] на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

⚙️ SSH предлагает возможность форварда SSH-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.

Вызов выглядит так: ssh -A [email protected] ssh [email protected]

Удалённый SSH-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали SSH-клиенту доступ к своему агенту авторизации (но не ключу!).

#SSH #Authorization | 😊 @iscode

🥷 Джонни вещает: установка и настройка Sysmon

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

— Установка системы занимает считанные секунды и может быть полностью автоматизирована.

EDR (Endpoint Detection & Response) - система обнаружения вредоносной активности на конечных точках
SIEM (Security information and event management) - система анализа в реальном времени событий безопасности

#sysmon #EDR #SIEM | 😏 @iscode

🥷 Джонни вещает: как провести стресс-тестирование вашей системы Linux

Стресс-тестирование Linux — ключевой этап подготовки серверов к реальной работе.

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

Методы стресс-тестирования Linux

1. Нагрузка через циклы

Создание бесконечных циклов нагружает процессор. Это простой способ проверить систему.

Запуск нагрузки:

for i in 1 2 3 4; do while : ; do : ; done & done

Каждый цикл запускается в фоновом режиме и увеличивает нагрузку на ЦП.

Мониторинг нагрузки:
Запускайте команду uptime каждые 30 секунд, чтобы наблюдать за изменением средней загрузки:

while true; do uptime; sleep 30; done

Остановка нагрузки:
Чтобы завершить циклы, используйте kill, указав номера заданий:

kill %1 %2 %3 %4

2. Использование утилиты stress

stress — мощный инструмент, который позволяет создавать нагрузку на различные ресурсы системы: ЦП; память; ввод/вывод

Примеры использования stress:
• Нагрузка на процессор:
stress --cpu 4

Чем больше указано ядер (--cpu), тем выше нагрузка на систему.

• Нагрузка на память:
stress --vm 2

• Нагрузка на ввод/вывод (I/O):
stress --io 4

Для анализа работы ввода/вывода используйте iotop:
sudo iotop

3. Написание скриптов для мониторинга

Для удобного отслеживания нагрузки вы можете написать скрипт. Например, для мониторинга использования памяти:

#!/bin/bash
while true
do
free
sleep 30
done

Скрипт отображает использование памяти каждые 30 секунд. Вы можете адаптировать его под свои задачи.

Проведение стресс-тестов помогает: подготовиться к реальным пиковым нагрузкам; улучшить производительность системы; найти и устранить возможные проблемы на этапе разработки.

#Stress | ✋ @iscode

🥷 Как работает DNS в Linux. Часть 1: от getaddrinfo до resolv.conf

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

Данный пост — начало серии, посвященной низкоуровневой архитектуре разрешения имен. Поговорим о том, как устроен этот процесс в Linux на уровне ядра, различных библиотек C и системных вызовов.

— Многие знают, что процесс разрешения имен в Linux — это не просто «вызов DNS», а цепочка из библиотек, конфигурационных записей и вызовов, зависящих от реализации конкретного приложения, используемых типов библиотек и системных настроек.

В этой части постараемся разобрать все по слоям и собрать некую фундаментальную базу в кратком и доступном виде.

Вершина айсберга: почти все современные приложения в Linux, от curl до systemd, используют функцию getaddrinfo() из стандартной библиотеки C (glibc или musl). Именно она выполняет основную работу по переводу доменного имени в IP-адрес (A, AAAA-записи) в зависимости от настроек и запроса.

При этом она не только выполняет DNS-запросы, но и обрабатывает другие типы данных, такие как имена сервисов, например, преобразует имя сетевого сервиса “http” в порт 80, используя /etc/services. Это делает ее универсальным инструментом для сетевых приложений.

Функция getaddrinfo() возвращает список структур addrinfo, каждая из которых содержит IP-адрес, тип сокета, протокол и другие параметры. Это позволяет приложениям выбирать наиболее подходящий адрес для подключения.

Пример использования getaddrinfo() в псевдокоде:

```
struct addrinfo hints, *res;
zero_memory(hints);
hints.ai_family = ANY_FAMILY;
hints.ai_socktype = TCP;

err = getaddrinfo("example.com", "http", hints, &res);
if (err == 0) {
for each addr in res:
use(addr)
freeaddrinfo(res);
} else {
print(gai_strerror(err));
}

```

При этом getaddrinfo() — это вершина айсберга. Для получения IP-адреса она вызывает цепочку внутренних механизмов, прописанную в конфигурационных данных системы. Один из этих механизмов — NSS (Name Service Switch), о нём мы поговорим в следующем посте.

#DNS #Linux | 😏 @iscode

🥷 Как работает DNS в Linux. Часть 1: NSS

NSS реализован на основе подгружаемых модулей — динамических библиотек, соответствующих API glibc, таких как libnss_dns.so, libnss_files.so, libnss_myhostname.so и других. Они функционируют как плагины и подгружаются библиотекой glibc во время выполнения, отвечая за конкретные методы разрешения IP-адресов. Порядок и набор источников, используемых для разрешения имен, задается в конфигурационном файле /etc/nsswitch.conf.

Пример содержания nsswitch.conf:

# /etc/nsswitch.conf

passwd: files systemd
group: files systemd
shadow: files
gshadow: files

hosts: files dns myhostname
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

Например, строка в модулях с содержанием ``hosts: files dns`` говорит, что сначала ищется соответствие в локальном файле /etc/hosts, и если модуль files возвращает результат, то последующие модули, такие как dns (делающий DNS-запрос) не будут вызваны.

Соответственно, если в nsswitch.conf строка hosts не включает упоминание модуля dns, то конфигурационный файл resolv.conf, содержащий настройки обращения к DNS-источникам, проигнорируется, и DNS-запрос не будет сформирован.

🕹 Также в NSS могут задействоваться модули mdns (для Zeroconf/Avahi), nis (в старых системах) и myhostname.

Модуль myhostname является частью systemd и используется для разрешения локального имени хоста. Он не всегда присутствует в минималистичных системах, таких как Alpine Linux.

В следующем посте расскажу о библиотеках экосистемы Linux, ожидайте, сегодня продолжение 🪳

#DNS #Linux | 😏 @iscode | YouFast VPN — сильнейший из всех

🥷 Как работает DNS в Linux. Часть 1: Библиотеки

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

1. Glibc — наиболее распространённая реализация стандартной библиотеки языка C, реализует высокоуровневые функции, такие как getaddrinfo(). Она взаимодействует с NSS (Name Service Switch) для определения источников разрешения имён (например, /etc/hosts, DNS) и использует библиотеку libresolv для выполнения DNS-запросов.

- Glibc может использовать системные вызовы, такие как sendto и recvfrom для отправки и получения DNS-запросов по UDP или TCP. Широко распространена в большинстве дистрибутивов Linux (Ubuntu, Debian, Fedora и др.)

2. Musl — альтернативная стандартная библиотека C, разработанная с упором на минимализм, производительность и совместимость со стандартами POSIX. Она используется в легковесных дистрибутивах, таких как Alpine Linux.

- Musl реализует разрешение доменных имён напрямую, без использования NSS, самостоятельно читает /etc/hosts и /etc/resolv.conf и отправляет DNS-запросы, не используя внешние библиотеки вроде libresolv. Однако musl имеет ограничения в поддержке некоторых параметров resolv.conf, таких как rotate или сложные search.

3. Libresolv.so — является частью glibc, реализующая низкоуровневую работу с DNS, выполняя такие запросы, как res_query() и res_send(), но может использоваться независимо в некоторых приложениях вроде nslookup (что позволяет выполнять DNS-запросы напрямую, минуя стандартные механизмы разрешения имен).

- Libresolv используется glibc для выполнения DNS-запросов, когда NSS указывает, что нужно обратиться к DNS. Она читает /etc/resolv.conf, формирует DNS-пакеты и отправляет их на указанные серверы по UDP или TCP.

Стоит отметить, что некоторые приложения, например, написанные на Go, могут полностью обходить glibc/musl и использовать собственные DNS-резолверы.

#DNS #Linux | 😏 @iscode | YouFast VPN — сильнейший из всех

🥷 Как работает DNS в Linux. Часть 1: обработка resolv.conf и что делает res_query()

Файл /etc/resolv.conf содержит основные настройки клиента DNS, а именно: список серверов, параметры, search-домены. Например:

nameserver 192.168.1.1
search dev.local
options timeout:2 attempts:3

— Glibc и libresolv парсят его вручную при необходимости.

Важные моменты и ограничения:

- опции вроде rotate, ndots, timeout и attempts влияют на поведение запроса;

- опция rotate используется для циклического выбора серверов из списка nameserver, но она не поддерживается в musl;

- search используется для автодополнения, например, если имя db01 не является FQDN, к нему будут по очереди подставляться домены из директивы search.

Важно отметить, что файл resolv.conf может быть динамически изменён DHCP-клиентом, NetworkManager или утилитой resolvconf, что может вызывать путаницу при решении проблем с DNS. Об этом мы поговорим в одной из следующих частей.

Касательно res_query(), это функция из libresolv, вызываемая внутренне в процессе разрешения имени. Она формирует DNS-пакет вручную и отправляет его на указанные в resolv.conf DNS-серверы. Её используют утилиты вроде nslookup, а также некоторые программы, которые обходят getaddrinfo().

Функция отправляет DNS-запросы с помощью res_send() по UDP, а при необходимости, например, при получении ответов, превышающих 512 байт, переключается на TCP.

🕹 Важно: при использовании res_query() вы не получите информацию из /etc/hosts, NSS или других источников. Это DNS-запрос в чистом виде. Поэтому dig или nslookup могут получить один результат, а, например, ping или curl — совсем другой.

1. res_query() считается устаревшей функцией, использовать ее не рекомендуется. Для более удобной и безопасной работы с DNS лучше отдать предпочтение getaddrinfo() или таким библиотекам, как c-ares или libdns.

2. c-ares — легковесная библиотека для асинхронных DNS-запросов, часто используется в высоконагруженных приложениях (например, curl и Node.js)

3. libunbound (из проекта Unbound) — более мощная библиотека с поддержкой DNSSEC и гибкой настройкой запросов.

В следующем посте расскажу о порядке реализации запросов и приоритетов, ожидайте, сегодня продолжение 🪳

#DNS #Linux | 😏 @iscode | YouFast VPN — сильнейший из всех

🥷 Как работает DNS в Linux. Часть 1: порядок реализации запросов и приоритеты

Вот типичный порядок разрешения имени в Linux при использовании glibc и NSS:

1. Приложение вызывает getaddrinfo();

2. getaddrinfo() обращается к системе NSS и следует заданному в nsswitch.conf порядку;

3. Если первым указан модуль files, имя ищется в файле /etc/hosts;

4. Если включён модуль dns, NSS вызывает libnss_dns.so, которая обращается к функциям из libresolv;

5. libresolv формирует DNS-запрос через res_query() и отправляет его с помощью res_send() на указанные в resolv.conf адреса DNS-серверов, затем получает и возвращает IP-адрес.

#DNS #Linux | 😏 @iscode | YouFast VPN — сильнейший из всех

🥷 Как работает DNS в Linux. Часть 1: порядок реализации запросов и приоритеты

Важно: если имя найдено на одном из шагов, например, в hosts, последующие источники не используются.

В минималистичных системах, таких как Alpine Linux с musl, порядок может отличаться, так как musl не использует NSS и реализует DNS-запросы напрямую, читая /etc/hosts и resolv.conf самостоятельно.

Некоторые приложения и языки (например, Go, Java, Node.js) могут использовать собственные DNS-резолверы, полностью игнорируя системные настройки.

Для примера проанализируем работу утилиты curl.

Команда:

strace -f -e trace=network curl -s download.astralinux.ru > /dev/null
Вывод strace:
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
socketpair(AF_UNIX, SOCK_STREAM, 0, [5, 6]) = 0
strace: Process 283163 attached
[pid 283163] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7
[pid 283163] connect(7, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (Нет такого файла или каталога)
[pid 283163] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7
[pid 283163] connect(7, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (Нет такого файла или каталога)
[pid 283163] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 7
[pid 283163] connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.24.31.107")}, 16) = 0
[pid 283163] sendmmsg(7, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\250\207\1\0\0\1\0\0\0\0\0\0\10download\nastralinux"..., iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=40}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\240\215\1\0\0\1\0\0\0\0\0\0\10download\nastralinux"..., iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=40}], 2, MSG_NOSIGNAL) = 2
[pid 283163] recvfrom(7, "\250\207\201\200\0\1\0\1\0\0\0\0\10download\nastralinux"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.24.31.107")}, [28->16]) = 56
[pid 283163] recvfrom(7, "\240\215\201\200\0\1\0\0\0\1\0\0\10download\nastralinux"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.24.31.107")}, [28->16]) = 114
[pid 283163] sendto(6, "\1", 1, MSG_NOSIGNAL, NULL, 0) = 1
[pid 283163] +++ exited with 0 +++
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
setsockopt(5, SOL_TCP, TCP_KEEPIDLE, [60], 4) = 0
setsockopt(5, SOL_TCP, TCP_KEEPINTVL, [60], 4) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("130.193.50.59")}, 16) = -1 EINPROGRESS (Операция выполняется в данный момент)
getsockopt(5, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
getpeername(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("130.193.50.59")}, [128->16]) = 0
getsockname(5, {sa_family=AF_INET, sin_port=htons(48488), sin_addr=inet_addr("172.24.31.241")}, [128->16]) = 0
sendto(5, "GET / HTTP/1.1\r\nHost: download.a"..., 86, MSG_NOSIGNAL, NULL, 0) = 86
recvfrom(5, "HTTP/1.1 200 OK\r\nServer: nginx/1"..., 102400, 0, NULL, NULL) = 1617

🔍 Что мы видим в этом strace?

1. Попытка использовать NSCD (Name Service Cache Daemon)

connect(..., "/var/run/nscd/socket", ...) = -1 ENOENT
- Это означает, что glibc сначала пытается использовать кеш имён из NSCD, если он запущен. В системе его нет, и запрос идёт дальше.

2. Вызов socket() и connect() к DNS-серверу

socket(AF_INET, SOCK_DGRAM|..., IPPROTO_IP) = 7
connect(7, ..., sin_addr=inet_addr("172.24.31.107")...)
- Здесь создаётся UDP-сокет для обращения к DNS-серверу, указанному в /etc/resolv.conf.

3. Вызов sendmmsg() — отправка DNS-запросов

sendmmsg(7, [ { "download.astralinux.ru" }, { "download.astralinux.ru" } ], ...)
Здесь отправляются запросы на резолв имени.

4. Ответ от DNS

recvfrom(...) = 56
recvfrom(...) = 114
Теперь IP-адрес известен.

56 - это размер DNS-ответа в байтах, содержащего А-запись (IPv4-адрес)

114 - размер дополнительных данных, например CNAME, или авторитетные серверы в случае рекурсивного запроса.

5. TCP-соединение по IP

connect(5, ..., sin_addr=inet_addr("130.193.50.59"))
Здесь уже сам curl устанавливает TCP-соединение по IP-адресу, который ему вернула getaddrinfo().

‼️ Таким образом, когда мы вызываем curl, мы не видим DNS-запросов напрямую — их делает библиотека glibc внутри вызова getaddrinfo(). Но strace позволяет увидеть косвенные признаки:

Среди вызовов будет попытка подключиться к nscd, вызов connect() к DNS-серверу, отправка UDP-пакета через sendmmsg(), а затем — стандартное TCP-соединение по IP:

connect(7, {AF_INET, 172.24.31.107:53}) = 0
sendmmsg(7, [{ "download.astralinux.ru" }]) = 2
recvfrom(7, ...) = ...
connect(5, {130.193.50.59:80}) = 0

Важно отметить, что поведение getaddrinfo() может зависеть от реализации libc. Например, в glibc результаты могут кэшироваться, что влияет на производительность и актуальность данных.

#DNS #Linux | 😏 @iscode | YouFast VPN — сильнейший из всех

🥷 Как работает DNS в Linux. Часть 1: краткое резюме и ключевые моменты

DNS-запрос в Linux — это не обязательно запрос к DNS-серверу. Цепочка обращений может включать hosts, NSS, glibc и другие источники.

NSS и nsswitch.conf определяют порядок и источники разрешения имён.

glibc использует NSS и может кэшировать результаты; musl реализует DNS-резолвинг напрямую с ограниченной поддержкой опций resolv.conf.

Resolv.conf управляет настройками резолвера, но может быть изменен динамически.

Getaddrinfo() — основной интерфейс для разрешения имен, обрабатывает как DNS, так и другие источники.

В разных языках программирования (Go, Java, Python с dns.resolver, Node.js) могут использоваться собственные механизмы DNS-запросов.

✋ В следующей части дополним картину общим представлением того, как устроено кэширование DNS записей — ключевой механизм, который напрямую влияет на производительность, надежность и поведение приложений при смене IP-адресов, ставьте 👍

#DNS #Linux | 😏 @iscode

🥷 Как работает DNS в Linux. Часть 2: все уровни DNS-кэширования

В первых частях мы разобрали, как в Linux работает процесс разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Однако если бы каждый вызов требовал нового DNS-запроса, это было бы неэффективно и сильно нагружало как систему, так и сеть. Поэтому используется кэширование.

Кэширование DNS может быть везде — в glibc, в systemd-resolved, в браузерах и даже в приложениях на Go. Кэш помогает увеличить скорость работы, но создает дополнительные сложности при отладке. Например: вы меняете DNS-запись, но сервер продолжает ходить по старому IP-адресу. Или, Dig показывает правильный адрес, а curl всё равно подключается к устаревшему.

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

1. Что такое DNS-кэш и зачем он нужен:
DNS-кэш — это не единое хранилище, а многоуровневая система механизмов кэширования на разных уровнях системы. Каждый DNS-запрос — это долгий сетевой вызов, поэтому многие компоненты стараются сохранять результаты локально.

TTL (Time To Live) — время жизни записи в кэше. Оно указывается в DNS-ответе и определяет, как долго можно использовать сохранённый IP-адрес. Задается обычно в секундах. После истечения TTL необходимо обновить данные.

🕹 Таким образом, кэширование позволяет:
- повысить скорость обработки повторных DNS запросов - снизить нагрузку на серверную и сетевую инфраструктуру - обеспечить отказоустойчивость при временной потере соединения - уменьшить задержки в работе приложений

— Но у кэширования есть и обратная сторона: устаревшие данные могут стать причиной недоступности сервисов при изменении инфраструктуры.

✋ В следующей части дополним картину темой в каких уровнях работы кэшируются DNS в Linux, ставьте 👍

#DNS #Linux | 😏 @iscode

🔹🔹🔹🔹🔹🔹🔹🔹🔹

Оказался(ась) на этом канале впервые и потерялся? — можешь звать меня Джонни, я буду твоим проводником.

Этот 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. Сказ о том, как два сервера изменили судьбу сетевой команды

🔹🔹🔹🔹🔹🔹🔹🔹🔹🔹🔹 🔹🔹🔹🔹

⚙️ Публикации краткого формата:
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 туннель

👀 Наглядно показываем принцип работы и область применения восьми самых популярных сетевых протоколов

🥷 Как работает 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

⚡ Как данные передаются через Интернет? Какое это имеет отношение к модели OSI? Как TCP/IP вписывается в это?

🚠 Семь уровней модели OSI:

1. Физический уровень
2. Канальный уровень
3. Сетевой уровень
4. Транспортный уровень
5. Сеансовый уровень
6. Уровень представления
7. Прикладной уровень

#Network #OSI

🥸 Личный VPN: юзер ликует, VLESS смеётся, а РКН плачет. v.2

Представьте: ваш VPN становится невидимкой для РКН, маскируясь под обычный трафик от народного мессенджера Max. Никаких блокировок, никаких подозрений.

— В этой статье вы узнаете, как настроить такой «стелс» за 10 минут через удобный 3x-UI интерфейс с учётом последних потуг от регулятора (лазейка есть, и способ в разы дешевле чем Double VPN + gRPC + SelfSNI + бубны + домены с закосом под трафик от сайта и прочая х)

⤷ teletype.in/@secur_researcher/vpn_tutorial

#VPN #xHTTP #VLESS | 😈 @secur_researcher