🥷 Джонни вещает: откуда этот конфиг? [Debian/Ubuntu]

Цель этого поста: показать технику отладки в debian/ubuntu, связанную с "поиском первоисточника" в системном конфигурационном файле.

🖥 Тестовый пример: после долгих издевательств над tar.gz копией установленной ОС и после её восстановления и установки апдейтов мы получаем сообщение:

update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
W: initramfs-tools configuration sets RESUME=/dev/mapper/U1563304817I0-swap
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/foobar-swap)
I: Set the RESUME variable to override this.

🕹 Цель: понять, откуда это значение (U1563304817I0) пришло и как его правильно поменять. Это первый попавшийся пример, не особо интересный сам по себе, но удобный, чтобы показать практические методы работы с Linux.

Шаг номер 1: Откуда пришёл RESUME?

# cd /etc
# grep -r RESUME
initramfs-tools/conf.d/resume:RESUME=/dev/mapper/U1563304817I0-swap

Мы рекурсивно (-r) ищем упоминание этой переменной в каталоге /etc (там, где большинство конфигов). Мы находим conf.d сниппет, который явно используется пакетом initramfs-tools.

Теперь новый вопрос, а откуда этот сниппет? - есть три варианты:
1. Магический артефакт(кто-то положил и забыл ✋)
2. Конфиг из пакета
3. Конфиг, сгенерированный каким-то скриптом из системных пакетов

Теперь проверяем c помощью dpkg -S он позволяет нам поискать по базе установленных файлов и найти к какому пакету файл относится.

dpkg -S initramfs-tools/conf.d/resume
dpkg-query: no path found matching pattern *initramfs-tools/conf.d/resume*

Вот пример удачного поиска:

dpkg -S resolv.conf
manpages: /usr/share/man/man5/resolv.conf.5.gz
systemd: /lib/systemd/resolv.conf

Возвращаемся к нашей задаче: файл initramfs-tools/conf.d/resume не устанавливается в систему из пакета. Может быть он генерируется в postinst/preinst скрипте пакета? Проверяем третью версию 😡

# cd /var/lib/dpkg/info/
# grep -r initramfs-tools/conf.d/resume *
initramfs-tools-core.postrm: rm -f /etc/initramfs-tools/conf.d/resume

В каталоге /var/lib/dpkg/info/ лежат распакованные версии всех "метафайлов" пакетов (скрипты установки/удаления, описания пакетов и т.д.). Удивительно, но этот файл удаляется в postrm (при удалении) пакета initramfs-tools-core. Посмотрим содержимое его postinst… Ничего, касающегося conf.d директории.

Давайте взглянем на файлы из состава пакета initramfs-tools-core.

# dpkg -L initramfs-tools-core
...
/usr/share/initramfs-tools/hooks/resume
...

Команда dpkg -L позволяет посмотреть все файлы, которые есть в системе от указанного пакета. Я выделил интересный для изучения файл. Изучение файла показывает как эта переменная используется, но не отвечает откуда он появляется.

💳 Если пост понравился, жду от вас реакций и выпускаю на ту же тему, но уже о базе ответов debconf

#Debian #Ubuntu #dpkg

🥷 Джонни вещает: debconf

Получается, это чей-то артефакт. Чей? Перед тем, как нырять в инсталлятор, глянем ещё в одну важную инфраструктуру Debian — ответы на вопросы. Каждый раз, когда пакет задаёт вопрос, и во многих случаях, когда он вопроса не задаёт, но использует вариант по-умолчанию, и вопрос, и ответ фиксируются в специальной базе в Debian, которая называется debconf.

— Мы можем посмотреть на базу ответов (и даже выставить их до установки самого пакета — debconf-set-selections), для этого нам потребуется утилита debconf-get-selections из состава debconf-utils. К сожалению, ничего интересного не нашлось: (debconf-get-selections |grep -i resume вернул пусто).

debian-installer

У установщика есть своя база ответов на вопросы: /var/log/installer/cdebconf/questions.dat. К сожалению, там тоже нет ни слова про наш resume.
Зато рядом есть логи, в т.ч. syslog, куда пишется весь лог инсталляции. Там упоминается пакет base-installer, и на его странице мы можем видеть ссылку на сырцы.

🖥 Внутри них мы с лёгкостью находим ответ на наш вопрос:

resume="$(mapdevfs "$resume_devfs")"; then
...
if [ "$do_initrd" = yes ]; then
...
resumeconf=$IT_CONFDIR/resume
....
echo "RESUME=$resume" >> $resumeconf

mapdevfs — это утилита с понятным назначением, а интересная нам функция это get_resume_partition, которая читает /proc/swaps и выбирает там самую большую. Swap же у нас приходит от partman'а.

Ответ на наше тестовое задание: файл создаётся инсталлятором в /target'е в момент установки, т.е. мы говорим про well-known, но артефакт. В существующих в системе пакетах нет никого и ничего, чтобы меняло этот файл.

❗️ Подводя итог: dpkg и debconf — основные методы для поиска поставщиков файлов; поиск в /var/lib/dpkg/info позволяет увидеть операции над файлами на этапе установки; установщик может создавать файлы-артефакты, которые потом никем никогда не меняются (кроме пользователя), и это можно увидеть в коде установщика.

#Linux #DevOps #debconf | 🏃‍♂️ @iscode

🥷 Джонни вещает: ключ сервера SSH

Прошлый пост(click) оказался для вас hard-level, поэтому сегодня тема попроще(про пальчики вверх не забываем, я для кого стараюсь 😄)

🖥 Первый раз, когда вы заходите на сервер, SSH вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

— Если ключ сервера поменялся (например, сервер переустановили), SSH вопит от подделки ключа. Обратите внимание, если сервер не трогали, а SSH вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).

🕹 Удалить известный ключ сервера можно командой ssh-keygen -R server. При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1.

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

🔍 Заметим, если вы сервера клонируете (например, в виртуалках), то SSH-ключи сервера нужно обязательно перегенерировать. Старые ключи из know_hosts при этом лучше убрать, иначе SSH будет ругаться на duplicate key.

#SSH #host | 😊 @iscode

🥷 Джонни вещает: вложенные туннели (естественно, туннели можно перенаправлять)

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

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

ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2

Твою мать, чё у вас здесь происходит? 😄 Мы говорим SSH перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить SSH (то есть клиента SSH) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться).

💬 Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором. (ставим пальцы, и расскажу о динамическом пробросе портов)

#SSH #TCP | 😊 @iscode

🥷 Джонни вещает: динамический проброс портов

Перенаправление трафика с нескольких портов на удаленный сервер: ssh -D 3000 ssh-server. Тут мы поднимаем SOCKS-прокси на порту 3000 для всех интерфейсов в локальной системе. Теперь трафик, отправленный через прокси-сервер на SSH-сервер, можно адресовать на любой порт или конечный хост.

— По умолчанию используется протокол SOCKS5, поддерживающий TCP и UDP.

ssh -D 127.0.0.1:3000 ssh-server (поднимаем SOCKS-прокси на 127.0.0.1:3000 в локальной системе)

При работающем SOCKS-прокси можно настроить браузер на его использование для доступа к ресурсам так, как будто соединения исходят от SSH-сервера. Например, если у SSH-сервера есть доступ к другим серверам в частной сети, с помощью SOCKS-прокси можно заходить на эти серверы локально (словно вы находитесь в той же сети), и не нужно настраивать VPN.

🖥 Работу SOCKS-прокси можно проверить командой: curl -x socks5://127.0.0.1:12345 https://example.org

#SSH #Socks #Proxy | 😊 @iscode

Обычный день с СДВГ

#meme | 😊 @iscode

🥷 Джонни вещает: управление ключами SSH

Теория в "двух словах": SSH может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают.

🖥 Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).

Генерация ключа и его структура: cвой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо. Сменить пароль на ключ можно с помощью команды ssh-keygen -p.

~/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
~/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa).

🎙 Если подобный формат постов вам понравиться, сделаю и на другие темы.

#SSH | 😊 @iscode

🥷 Docker в виртуальной машине

#meme | 😊 @iscode

🥷 HTTP: Uniform Resource Locator — или просто URL

Важную роль в работе HTTP играет Uniform Resource Locator, сокращенно URL – единообразный определитель местонахождения ресурса. Именно URL используется для того, чтобы указать, к какой странице мы хотим получить доступ.

❗️ URL состоит из трех основных частей(см. приложение):

1. Название протокола, в примере на рисунке протокол HTTP.
2. Адрес сервера, на котором размещен ресурс. Можно использовать IP-адрес или доменное имя. Адрес сервера отделяется от названия протокола двоеточием и двумя слешами.
3. Адрес ресурса на сервере. Это может быть HTML-страница, изображение, видео или ресурс другого типа. В примере на рисунке адрес страницы: /posts/http.

В URL не обязательно использовать только протокол HTTP, вот примеры с другими протоколами:

https://ya.ru | ftp://example.com

URL может включать достаточно большое количество других компонентов, кроме протокола, адреса сервера и адреса ресурса. Более подробно почитать о них можно в документе RFC 1738, Uniform Resource Locators (URL).

#HTTP #URL | 😏 @iscode

😟 Как сделать и настроить собственный VPN

В этой статье я подробно расскажу как оформить сервер и поднять свой VPN на протоколе VLESS с XTLS-Reality, который выделяется на общем плане тем, что трафик шифруется и маскируется под подключение к популярным сайтам (доменам), тем самым станет тёмной лошадкой для ТСПУ.

↘️ habr.com/ru/users/stein_osint/

— Дорогие сабчики, канал разрастается, а анимированных эмодзи всё меньше, просьба к вам - проголосовать за меня.

#VPN #VLESS #Reality #РКН | 😈 @secur_researcher

🥷 Протокол HTTP: принцип работы и методы

Протокол HTTP работает в режиме запрос-ответ. Клиент, например, браузер, передает на сервер запрос к определенному ресурсу, например, Web-странице. Сервер в ответ отправляет клиенту этот ресурс или сообщение об ошибке, если ресурс передать нельзя.

- На транспортном уровне HTTP использует протокол TCP (кроме HTTP/3, в котором применяется QUIC), порт Web-сервера по-умолчанию: 80.

🕹 Запрос HTTP состоит из трех основных частей:
· Запрос
· Заголовки (не обязательно)
· Тело сообщения (не обязательно)

Пример простого запроса HTTP в текстовом режиме:
GET /posts/http HTTP/1.1
Host: johnny.ru

Начинается всё с метода HTTP, в нашем случае это - GET, он указывает, какое действие требуется выполнить с ресурсом. В примере метод GET говорит о том, что мы хотим получить (загрузить) ресурс, далее адрес ресурса /posts/http – путь к странице на Web-сервере, которую мы хотим загрузить и далее идёт версия протокола.

- Во второй строке указывается заголовок Host. Этот заголовок является обязательным в версии HTTP/1.1, в нем задается доменное имя сервера, к которому направлен запрос.

❗️ Методы HTTP: они говорят нам, какое действие с ресурсом мы хотим совершить. В примере запроса мы видели метод GET, который предназначен для получения ресурса. Кроме GET в HTTP есть и другие методы, наиболее важные из которых определены в документе RFC 9110 HTTP Semantics.

1. GET — Запрос на передачу ресурса.
2. HEAD — Запрос на передачу ресурса, но сам ресурс в ответе не передается, только заголовки.
3. POST — Передача данных на сервер для обработки указанного ресурса.
4. PUT — Размещение ресурса на сервере (если такой ресурс уже есть на сервере, то он замещается).
5. DELETE — Удаление ресурса на сервере.
6. CONNECT — Установка соединение с сервером на основе ресурса.
7. OPTIONS — Запрос поддерживаемых методов HTTP для ресурса и других параметров коммуникации.
8. TRACE — Запрос на трассировку сообщения: сервер должен включить в свой ответ исходный запрос, на который он отвечает. Это полезно, когда запрос проходит через промежуточные устройства, которые могут изменить запрос, например, добавить заголовки.

Полный список всех существующих методов HTTP находится в документе Hypertext Transfer Protocol (HTTP) Method Registry, который сопровождается организацией Internet Assigned Numbers Authority (IANA).

Жду от вас реакшена и делаю пост о кодах статусов ответов HTTP!

#HTTP #Method #Request | 😏 @iscode