Где вы оставляете следы, когда подключаетесь по SSH к серверу на базе Linux? Собрал краткую подборку основных ваших артефактов в Debian. Будет актуальна во всех дистрибутивах на её основе. Для других могут отличаться только частности в виде имён и путей к логам, но общий смысл будет тот же.

На всякий случай сразу предупреждаю, что если логи отправляются во внешнее хранилище, то вы там наследили сразу в момент подключения. Поэтому важно иметь своё внешнее по отношению ко всем серверам хранилище системных логов.

1️⃣ Подключение по SSH фиксируется в /var/log/auth.log. С ним всё просто - это текстовый лог. Сразу посмотреть удачные подключения можно так:
# grep 'Accepted' /var/log/auth.log
Лога может не быть, либо логи могут параллельно храниться в journald. Смотреть так:
# journalctl -u ssh -r

2️⃣ Информация о подключении будет записана в бинарный лог /var/log/wtmp. Смотреть в консоли командой last. Увидите информацию о дате логина, пользователе, его IP адресе. Там же дополнительно хранится информация о загрузках и выключениях сервера, в том числе кем они были инициированы. Могу сразу для расширенной информации посоветовать ключи: last -Faiwx.

3️⃣ Информация о последнем логине пользователя хранится в бинарном файле /var/log/lastlog. Смотреть одноимённой консольной командой lastlog. Увидите список всех системных пользователей и дату их последнего подключения вместе с IP адресом.

4️⃣ Пока вы не отключились, информация о вашей активной сессии вместе с остальными сессиями хранится в бинарном файле /var/run/utmp. Смотреть информацию оттуда можно командой who.

5️⃣ Если во время подключения были неудачные попытки с неправильным логином и паролем, то эта информация будет сохранена в бинарном файле /var/log/btmp. Смотреть командой lastb.

6️⃣ Если что-то делали в консоли, то информация об этом сохранится в текстовом файле ~/.bash_history. Если не хотите, чтобы это происходило, после логина измените место хранения истории через переопределение переменной. Выполните в консоли:
# export HISTFILE=/dev/null
В рамках сессии история будет сохраняться и отображаться по команде history, но в файл записана не будет.

Для скрытия информации о подключении можно банально обнулить указанные выше логи и бинарные файлы. О вас не останется информации, но станет понятно, что кто-то подключался. Я, кстати, с подобным сталкивался. Когда только устроился в одну компанию. Через несколько дней после начала работы, когда стал проверять все серваки и разбираться в инфраструктуре, заметил на одном из серверов очищенную историю и прочие следы. Остаётся только гадать, что там делал бывший админ.

Просто взять и удалить информацию о себе из бинарных файлов не очень просто. Как один из вариантов - взять готовый скрипт, который на основе IP адреса вычистит информацию в том числе из бинарных логов. У меня на Debian 12 он не завёлся. Всё время ругался на UTMP block size. Мучал уже родной ChatGPT с chatgpt.com на эту тему, не смог помочь. Много всего предложил, но ничего не помогло. В конце предложил по-другому очистить файл: удалить и заново создать. Забил.

Для того, чтобы от подобных очисток защититься, достаточно на любом Linux сервере запустить syslog сервер или systemd-journal-remote. И вы всегда будете знать, кто и когда к вам подключается. Для логов службы sshd не нужно ни много ресурсов, ни места на диске. Нет нужды разворачивать какое-то специальное хранилище для логов, если у вас в нём нет нужды. Я отдельно для syslog сервера поднимал виртуалку 1CPU/512M/10G.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#terminal #security

Продолжу начатую недавно тему про заметание следов своей деятельности в системе на базе Linux. Пишу не для того, чтобы вы заметали за собой следы, а чтобы понимали, как от этого защищаться. Сегодня речь пойдёт про управление датами создания и изменения файлов.

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

Напомню, что у файла есть несколько меток времени:

▪️Birth (crtime) - время создания айноды файла, то есть самого файла.
▪️Access (atime) - время последнего доступа к файлу.
▪️Modify (mtime) - время последнего изменения содержимого файла.
▪️Change (ctime) - время последнего изменения метаданных файла в файловой системе.

Посмотреть указанные метки можно командой stat:

# stat testfile

Поменять значения atime и mtime крайне просто. Можно взять банальную утилиту touch:

# touch -m -a -t 202501010000 testfile
# stat testfile
Access: 2025-01-01 00:00:00.000000000 +0300
Modify: 2025-01-01 00:00:00.000000000 +0300

То же самое можно сделать напрямую в файловой системе через debugfs:

# debugfs -w -R 'set_inode_field /var/www/testfile crtime 202501010000' /dev/sda1
# debugfs -w -R 'set_inode_field /var/www/testfile atime 202501010000' /dev/sda1
# debugfs -w -R 'set_inode_field /var/www/testfile mtime 202501010000' /dev/sda1
# debugfs -w -R 'set_inode_field /var/www/testfile ctime 202501010000' /dev/sda1
# echo 2 > /proc/sys/vm/drop_caches
# stat /var/www/testfile
Access: 2025-01-01 03:00:00.881765992 +0300
Modify: 2025-01-01 03:00:00.881765992 +0300
Change: 2025-01-01 03:00:00.881765992 +0300
Birth: 2025-01-01 03:00:00.881765992 +0300

В конце для проверки надо обязательно сбросить кэш, иначе изменений не увидите. Важно понимать, что для изменения atime и mtime достаточно обычных прав доступа к файлу. То есть любой червь, который залез через исходники сайта, может у него менять эти параметры. А вот для изменения crtime уже нужны права root, так как надо лезть в файловую систему.

Помимо прочих средств защиты, конкретно в данной ситуации с файлами может помочь аудит доступа с помощью auditd.

# apt install auditd
# auditctl -w /var/www/testfile -p rwa -k testfile_rule

◽️rwa - чтение (r), запись (w), изменение атрибута (a)
◽️testfile_rule - название правила аудита

Смотрим список правил:

# auditctl -l
-w /var/www/testfile -p rwa -k testfile_rule

После изменения файла смотрим записи аудита:

# aureport -f -i | grep /var/www/testfile
# ausearch -i -k testfile_rule

Лог аудита хранится в директории /var/log/audit. Поддерживается работа через syslog, так что при желании этот лог выносится на внешний сервер, как я уже рассказывал в предыдущих заметках. Подобный аудит больше актуален для конфигурационных файлов служб, в том числе системных, а не исходников сайтов. Я просто показал пример.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #terminal

Я в консоли Linux настройки IP адресов уже давно привык смотреть так:

# ip a

На выходе получается что-то похожее на ifconfig, только с другим форматированием. Ifconfig давно уже не ставлю и не использую. Все ключи позабыл. Смысла в ней уже нет с повсеместным распространением утилиты ip.

На прошлой неделе смотрел одного блогера и мельком увидел, как он смотрит IP адреса сервера:

# ip -br a
lo         UNKNOWN    127.0.0.1/8 ::1/128 
eth0        UP        172.18.107.235/20 fe80::215:5dff:fe0d:7101/64 
eth1        UP        192.168.101.2/24 fe80::215:5dff:fe0d:7105/64 
docker0      DOWN       172.17.0.1/16 
br-e901d734a0f3 DOWN       172.18.0.1/16 

Конкретизируем только IPv4:

# ip -br -4 a
lo         UNKNOWN   127.0.0.1/8 
eth0        UP       172.18.107.235/20 
eth1        UP        192.168.101.2/24 
docker0      DOWN      172.17.0.1/16 
br-e901d734a0f3 DOWN      172.18.0.1/16

Очень удобно. Я не знал и нигде не видел этот ключ. Сразу себе записал и постарался запомнить. Так реально удобнее смотреть. Сразу все адреса на виду, не надо глазами искать конкретный адрес в куче других строк.

Для просмотра линков и mac адресов ключ тоже применим:

# ip -br l
# ip -br n

Для справки ещё одну команду добавлю, которую тоже постоянно выполняю. Просмотр маршрутов:

# ip r

Вообще, использование ip упростило вопросы просмотра и управления сетевыми настройками, так что довольно легко и добровольно на неё переключился в своё время. Где-то наверное со времён Centos 7.

Интересно, кто-то ещё ставит специально ifconfig и использует? Её вроде выпилили из базовых наборов системных утилит.

#linux #terminal

Для тех, кому в консоли достаточно обычного bash, могу порекомендовать ресурс, с помощью которого можно быстро настроить себе prompt. Для тех, кто не знает, что это такое, поясню. Promt – это информация, которая отображается в командной строке перед полем с вводом своей команды. Его называют приглашением командной строки.

Стандартный promt чаще всего user@host-name:current-directory# . С помощью сайта bash-prompt-generator.org можете легко его изменить, просто собрав как в конструкторе те элементы, что вам нужны. И тут же на сайте видно, как будет выглядеть приглашение командной строки.

Из того, что обычно добавляют, отмечу следующие вещи:

- отображение IP адреса сервера
- подсветка промта разными цветами на разных серверах
- подсветка промта красным цветом при работе от root
- вывод времени

Немного поигрался в конструкторе и собрал следующий промт:

[username@hostname.com|192.168.1.100] 20:32:03 (~/bin)$ █

PROMPT_COMMAND='PS1_CMD1=$(ip route get 1.1.1.1 | awk -F"src " '"'"'NR == 1{ split($2, a," ");print a[1]}'"'"')'; PS1='[\[\e[38;5;196m\]\u\[\e[0m\]@\H|${PS1_CMD1}] \t (\[\e[4m\]\w\[\e[0m\])\$ '

Теперь эту команду надо добавить в ~/.bashrc и применить изменения:

# source ~/.bashrc

В данном случае мы настроили promt у конкретного пользователя. Я цвет имени пользователя сделал красным, потому что это root. Для остальных пользователей promt можно вообще не менять, либо задать индивидуальный. Общие же настройки для всех пользователей живут в системном файле /etc/bash.bashrc.

Если у вас какой-то прикольный и необычный promt, поделитесь, пожалуйста, информацией.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#terminal #bash

Когда-то давно писал про одну полезную консольную команду, которой иногда пользуюсь. Она принудительно и моментально отправляет сервер с Linux в перезагрузку. Эффект аналогичен нажатию на кнопку reset:

# echo b > /proc/sysrq-trigger

Разница с консольными командами reboot или shutdown как минимум в том, что они обычные бинарники на диске.

# type reboot
reboot is /usr/sbin/reboot

# type shutdown
shutdown is /usr/sbin/shutdown

Хотя на самом деле это уже давно не бинарники, а только ссылки на /bin/systemctl, но это не отменяет того, что последний тем не менее исполняемый файл. Он должен существовать, а во время выполнения пошуршать диском. У него куча ссылок на таргеты и службы systemd.

Если с диском какие-то проблемы, либо он загружен так, что ни на что не отвечает, штатный reboot не состоится, либо будет долго исполняться. К тому же reboot пытается корректно отключить примонтированные диски. Очевидно, что если с одним из них проблемы, то тоже будет всё тупить и подвисать.

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

Недавно, кстати, в статье видел использование команды с принудительной перезагрузкой. Там автор наживую накатил на VPS поверх работающей системы RouterOS. Соответственно, текущую файловую систему он уничтожил, никакой бинарник запустить невозможно. А само ядро ОС всё ещё живёт в памяти и работает. Вот ему и можно отправить напрямую команду на перезагрузку.

Эта команда является частью так называемых Linux Magic System Request Key Hacks (sysrq). Магические сочетания клавиш, которые отправляют команды напрямую в ядро. Они реально привязаны к сочетаниям клавиш, выполняемых с управляющего терминала и подключенной клавиатуры. ALT + SysRq + <command key>. Клавиша SysRq часто совмещена с PrtSc. Уже не помню, когда последний раз сидел за экраном реального сервера, если это не мои домашние тестовые компы. Обычно везде хоть какой-то IPMI есть.

Ядро должно поддерживать эти команды. Обычно в популярных дистрибутивах это так:

# cat /proc/sys/kernel/sysrq

◽️ 0 - sysrq отключен
◽️ 1 - sysrq полностью включен
◽️ >1 - включены отдельные функции

На Debian или Centos, с которыми я больше всего работал, перезагрузка всегда срабатывала.

Команд, которые можно отправить ядру, довольно много. Я лично использую только b для перезагрузки. Остальные не помню и никогда не использовал. А про reboot помню. Видел рекомендации, что перед перезагрузкой попробовать какие-то другие команды, типа тех, что отмонтируют диски, завершат процессы и т.д. Обычно если ты жёстко ресетишь сервер, то пробовать что-то не имеет большого смысла, потому что уже висим.

Если всё же интересно, то весь список команд можно запросить у ядра:

# echo h > /proc/sysrq-trigger | less /var/log/kern.log

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #terminal

Каждый практикующий линуксоид хотя бы раз в жизни сталкивался с OOM Killer, который просто приходит и грохает какое-нибудь приложение. Чаще всего от этого страдают СУБД, так как они обычно самые жирные по потреблению памяти.

Небольшая инструкция на тему того, что делать, если на сервере кончается память и к вам приходит OOM Killer.

1️⃣ Первым делом я бы проверил системные логи на тему работы OOM Killer. Если у вас включены текстовые логи syslog, то сделать это проще всего так:

# grep -i Killed /var/log/syslog

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

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

2️⃣ Запускаем батю-скрипт на bash, который построит красивую табличку по приоритетным целям для OOM Killer:



printf 'PID\tOOM Score\tOOM Adj\tCommand\n'
while read -r pid comm; do [ -f /proc/$pid/oom_score ] && [ $(cat /proc/$pid/oom_score) != 0 ] && printf '%d\t%d\t\t%d\t%s\n' "$pid" "$(cat /proc/$pid/oom_score)" "$(cat /proc/$pid/oom_score_adj)" "$comm"; done < <(ps -e -o pid= -o comm=) | sort -k 2nr

Этот скрипт гуляет по комментариям и статьям. Я как-то заморочился и вроде бы нашёл автора, но не уверен, что это именно он. Однострочник только выглядит страшно. Если его записать с форматированием, то там простая структура. Её удобно взять за основу для формирования любых табличек с использованием ps и различных метрик. Может заморочусь и сделаю подборку из прикладных вещей, типа потребления памяти, сетевых соединений и т.д.

3️⃣ Теперь мы знаем, кого прибивает наш киллер, и видим в табличке OOM Score и OOM Adjustment. Чем выше первое значение, тем больше шансов, что процесс будет прибит. Если стоит 0, то не будет прибит никогда. Кто-то может подумать, что хорошо бы сделать нужному процессу Score 0, но это плохая идея. Если процесс течёт по памяти, то тупо виртуалка зависнет. Обычно так не делают. Второе значение - поправочный коэффициент для управления Score. Чем ниже этот коэффициент, в том числе с минусовыми значениями, тем меньше шансов, что OOM Killer убьёт нужный процесс.

Система этих очков и коэффициентов замороченная. Большого смысла в ней разбираться нет. Главное выставить приоритеты так, чтобы нужный вам процесс имел приоритет на убийство ниже остальных.

4️⃣ Прежде чем менять коэффициенты, идём в свои приложения и настраиваем в них потребление памяти, чтобы она на сервере не кончалась. Настраиваем мониторинг, если его нет. Чаще всего этого будет достаточно и трогать параметры OOM Killer не придётся.

5️⃣ Если используемые вами приложения не имеют своих настроек по потреблению памяти, то настроить их и поведение OOM Killer можно с помощью Systemd. У меня была отдельная заметка по этой теме. Там ничего сложного.

6️⃣ Когда всё настроили и хотите посмотреть, как себя поведёт система, если вдруг памяти не останется, то займите её всю чем-нибудь. Например, утилитой stress. Или просто в консоли запустите:

# python3 -c 'a="a"*1073741824; input()'

Заняли 1GB памяти. Подберите своё значение, чтобы памяти не осталось (2147483648 - 2GB, 3221225472 - 3GB и т.д.). После этого можно воспользоваться магической командой, про одну из которых я недавно писал:

# echo f > /proc/sysrq-trigger

Она принудительно вызывает OOM Killer. Пример, конечно, так себе, потому что OOM Killer скорее всего грохнет запущенную команду (хотя в моих тестах первым умер systemd). Чтобы этого избежать, надо дать ей низкий Score:

# echo -16 > /proc/$(pgrep python3)/oom_adj

Ещё раз вызываем киллера и смотрим, кого он прибьёт:

# echo f > /proc/sysrq-trigger
# grep -i Killed /var/log/syslog

У меня systemd умер первым.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#terminal #linux