Я тут чет плотно подсел на игрушку Metroid, вроде обычная бродилка, но прям какая-то атмосферная. Прохожу сейчас по вечерам Zero Mission на GBA, ну как прохожу, брожу по карте и в дырки тыкаюсь. Хоть немного отвлекает от рутины.

Давай по теме. Ща будет интересно. Смотри, когда ты выполняешь команду ls -l, оно выводит тебе на экран список каталогов и файлов. Все это цветное и красивое. Но если сделать так:

ls -l | cat

То по итогу получим просто список каталогов и файлов, без навешанных стилей и красок. Серое и унылое. Куда делись управляющие символы (последовательности), которые всё это раскрашивают?

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

Все предельно просто. В утилитах содержится проверка своего стандартного вывода (stdout), которая не использует некоторые управляющие символы, если stdout не связан с терминалом.

И это вполне логично. Если бы эти управляющие символы передавались следующей команде, в моем случае в cat. То cat бы получил на вход помимо данных, кучу мусора, типа такого:

\e[31mBashdays\e[0m

Теперь полезем в кишки, чтобы лучше понять происходящее.

Запускаем strace:

strace -o output.txt -yf ls -l --color=auto | cat

Тут я указал утилите ls опцию color с аргументом auto. В большинстве случаев из коробки идет alias в котором уже прописана эта опция. Но так, как мы запускаем ls через strace, то существующие алиасы не будут использоваться. Вот лишь по этому и запихиваем все это в одну строку.

-y = отслеживать открытие файлов.
-f = отслеживать все процессы и форки.
-o = пишем выхлоп strace в файл.

Открываем файл output.txt и смотрим в него пустым взглядом. Но лучше грепаем вызов ioctl:

grep -i "ioctl" output.txt

Получаем несколько строк, в которых видим ошибку:

-1 ENOTTY (Inappropriate ioctl for device)

Это говорит о том, что процесс попытался выполнить операцию ввода-вывода (I/O), которая не поддерживается устройством. Канал просто не поддерживает эту возможность.

Ну и напоследок сделаем инъекцию. В этом посте можешь еще один пример с инъекцией глянуть. Запускаем:

strace -o /dev/null -fe inject=ioctl:retval=0 ls -l --color=auto | cat -v

Суть такая, если возникает ошибка, то ничего не делаем, а продолжаем работу. Эмулируем ситуацию, когда ioctl вернул статус успеха, а не -1 ENOTTY.

Опция retval=значение, это своего рода фильтр, в моем контексте он будет трассировать только системные вызовы ioctl у которых статус = не успех.

Запустили. Команда отработала, на экране видим список каталогов и файлов с управляющими символами (последовательностями).

drwxr-xr-x ^[[0m^[[01;34m1^[[0m
-rwxr-xr-x ^[[01;32mbash^[[0m
drwxr-xr-x ^[[01;34mbin^[[0m
drwxr-xr-x ^[[01;34mnginx^[[0m

Что и следовало доказать. Ну а если просто хочется протестировать управляющие символы без всяких strace, можно воспользоваться аргументом always и ключом -v для cat.

ls --color=always | cat -v

-v, --show-nonprinting

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

tags: #linux #debug #bash
—
💩 @bashdays

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

Ну и тут одно событие как-то вскользь прошло и связано оно с нативным файловым менеджером «FAR» который теперь можно без лишнего геморроя поставить на новые линуксы прям из официального репозитория.

Да, когда я начинал свой путь в айти, FAR был как правая рука для окошечников. Все активно призывали пересесть на total commander, но сколько я не делал попыток, так и не смог себя пересилить. Ну люблю я все эти консольные штуки и минимализм.

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

А вот когда я начал знакомство с linux, то второе, что я запустил (после vi), это был как раз midnight commander. Ну и все. FAR и mc стали маст-хэв штуками. Вот даже сейчас сидя на винде у меня вкорячен FAR и я даже раза два в месяц им пользуюсь.

Мой роадмеп был такой - Norton commander → Dos navigator → FAR → Midnight commander.

Короче в новых убунтах ставится так:

sudo apt install far2l

Кому подойдет FAR? Все просто, тому, кому не нравится midnight commander.

Я попробовал ради прикола воткнуть его на 23ю убунту (в wsl), взлетело, выглядит как FAR, даже alt+f1 работает для выбора дисков. Ну и по ssh запускается, в смысле подключаешься к серверу по ssh и запускаешь там FAR, работает.

Не знаю, но я уже точно ни на что не променяю Midnight commander. Даже в винде его использую. Мы связаны одной цепью.

А какой у тебя был путь с файловыми менеджерами? Чем нынче пользуешь?

tags: #рабочиебудни #utils #linux
—
💩 @bashdays

Привет и с пятницей господа и дамы! Отсматривал сегодня очередные домашние Bash задания своих студентов ну и собрал для вас самые распространенные велосипеды, которые в 99% повторяются.

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

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

Поехали!

cat bashdays.txt | cut -f 2 -d ';'

В текстовом файле bashdays.txt у меня забита строка: hello;world. Далее команда cat читает этот файл и перенаправляет данные на утилиту cut с помощью pipe «|». А cut уже режет строку по символу «;» и отдает мне второй элемент. То есть на выходе я получу: «world».

Но. Утилита cut сама умеет читать файлы. Проще говоря так:

cut -f 2 -d ';' bashdays.txt

Сюда можно приплести и grep, с которым обычно делают так:

cat bashdays.txt | grep "world"

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

grep "world" bashdays.txt

Ну и к примеру еще такое встречается часто:

cat bashdays.txt | tr 'a-z' 'A-Z'

Суть одна, cat передает данные в tr, а дальше они конвертятся в верхний регистр и выводятся на экран. По хорошему это было бы так:

tr 'a-z' 'A-Z' < bashdays.txt

Но опять же для кого по-хорошему? Мне привычнее вариант с cat, хз, переучиваться я уж точно не буду.

А еще из любимого, это циклы, ща покажу:

for s in $(ls)  
do  
    echo "$s"  
done

Это цикл, который перебирает файлы. Тут вообще зачем-то используется вызов внешней утилиты ls, хотя она тут вообще не упёрлась. Да и если такое использовать в скриптах, вылезут баги.

Например, создай такой файл:

touch "*"

И заново запусти этот цикл. ООйой… заметил прикол? Вывод продублировал все имена файлов. Вот тебе и баг, а потом сиди полдня, думай, что же оно не работает.

Этот костыль можно и перекостылисть, указав утилите ls параметр -Q. Тогда утилита ls тепло обнимет кавычками все имена файлов. Но это лишние кавычки, потом их чо? Снова обрезать?

Правильнее было бы так:

for s in ./*; do echo "$s"; done

Не вызывается никакая внешняя утилита, да и безопаснее в разы, в плане наличия багов если у файла будет какое-то корявое имя.

Перлов конечно много встречается, но это прям основные. Если что-то еще экстренно вспомню, закину в комментарии. Ну либо ты закидывай, мы всегда рады твоей активности!

Обещал на выходные тебя не беспокоить, но видимо не получится. Так, что увидимся совсем скоро. Хороших тебе предстоящих выходных и береги себя!

tags: #bash #кодревью
—
💩 @bashdays

Привет, тут на днях в нашем чатике пролетала софтина которая делает этакий ханипот на 22 порту. И все кто ломится по ssh просто вязнут в этом болоте.

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

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

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

Как с этим бороться? Ничего не бэкапить в папки проекта, удалять промежуточные файлы если что-то переносил, настраивать политики nginx чтобы 403 отдавал и т.п.

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

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

Давай настроем такой ханипот на примере nginx

Добавляем в nginx конфиги:

location ~* "^/(new|old|bkup|tmp|temp|upload|ftp|sql|file|www|drupal|joomla|wordpress|x|user|admin|a|b|r|rezerv|arch|arx|111|archive|auth|backup|clients|com|dat|dump|engine|files|home|html|index|master|media|my|mysql|old|site|sql|website|wordpress)\.tar.gz$" {
    access_log /var/log/nginx/honeypot.log;
    default_type application/zip;
    root /var/www/bashdayz/files/backup;
    rewrite ^(.*)$ /backup break;
    max_ranges 0;
    limit_rate 4k;
    limit_conn addr 1;
}

# а это в секцию http
limit_conn_zone $binary_remote_addr zone=addr:10m;

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

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

dd if=/dev/zero of=/var/www/bashdayz/files/backup bs=1G count=1

Вот и всё. Теперь если кто-то попытается вытянуть у тебя бэкап к примеру mysql.tar.gz, то будет страдать. Идея думаю тебе понятна, вокруг нее можно городить вообще сумасшедшие схемы. Но опять же это всего лишь концепт, из которого можно сделать что-то большое и нужное.

Я одно время применял этот способ в случае, когда коллеги просят выдать бэкап базы. Обычно я даю прямую ссылку на скачивание. Но бывают ситуации, когда разработчики ведут себя как зажравшиеся ЧСВешные мудаки. И на такой случай у меня для них была специальная ссылка для скачивания бэкапа.

Ничего особенного, но с сюрпризом, бэкап никогда не скачается. Тащить 10 гигабайт со скоростью dial-up ну такое себе. А когда те начинали орать как свинья из avp, мой ответ был простой - проблема на твоей стороне. У меня видишь все работает и показываю скриншот с нормальной скоростью.

Но таким быть фу, заподлостроением пусть школьники занимаются. Мы с вами взрослые и ответственные ребята. Правда? )

Ладно, рад всех видеть. Всем хорошей рабочей недели!

tags: #nginx #networks
—
💩 @bashdays

Привет. Разгребал тут мамонтовский сервер и нашел исходник с таким артом.

Думаешь это всего лишь картинка из архивов старого фидошника? Нифига, это Acme EyeDrops. Visual Programming in Perl.

В арте зашит вполне рабочий perl код. Если сохранить эту картинку в файл и затем выполнить его через интерпретатор, ты получишь секретное сообщение.

perl ./pokazisiski.pl

Сам код этого арта, сгенерирован с помощью модуля Acme::EyeDrops. Кстати на странице модуля много примеров с такими картинками (верблюды, морды, заборы, снежинки), каждая выполняет какое-то своё действие + есть примеры генераторов.

А вот эта команда, превратит файл обратно в исходник. То есть выведет исходный код вместо того, чтобы его выполнить.

perl -MO=Deparse ./pokazisiski.pl

Опять же не знаю, что ты будешь делать с этой информацией. Говорят что perl давно мёртв, но в современных скриптах и решениях люди любят его применять. ХЗ почему, наверное потому что perl есть везде. Хотя сейчас глянул, последний релиз был 2024-01-20, версия 5.39.7 (devel), капец, оно живое.

Первое и последнее, что я делал на perl, это был вывод «Hello World», на этом моё знакомство с ним закончилось. Даже на СИ порог вхождения мне легче показался, хотя по СИ у меня была книга, а по perl только какие-то огрызки из фидонета.

Ладно. Побежали дальше мир спасать от криворучек. Увидимся!

А ты применяешь perl в современном мире? Если да, поделись пожалуйста в комментариях, как и где. Очень интересно.

tags: #linux
—
💩 @bashdays

Привет. Немного терминальной развлекухи :

curl ascii.live/parrot  
curl ascii.live/forrest  
curl ascii.live/can-you-hear-me
curl parrot.live

А тут и тут можешь посмотреть исходники этих проектов. Там еще много подобных curl запросов можно понаделать с котиками, пончиками, бэтменами. А еще можно поставить себе на сервер и устраивать консольные вечеринки.

tags: #linux
—
💩 @bashdays

Привет. Странный факт - всю неделю с нетерпением ждешь выходных, а когда дождался, щелчок пальцами и снова наступил понедельник. А когда отдыхать-то? В рабочие дни разгребаешь рабочую рутину, в выходные разгребаешь домашнюю рутину.

Вот такой вот замкнутый круг получается. С другой стороны ты всегда находишься при деле, в потоке. Меньше времени остается на нытье и на самокопание. А это уже большой плюс. Окей, поныли и хватит, летсгоу!

Ты тёртый калач и всяко знаешь про специальные переменные со знаком $. Держу пари, знаешь только про базовые и часто используемые, типа $? и $1.

Сегодня рассмотрим еще парочку $@ и $*. Эти специальные переменные по сути выполняют одну и туже задачу: выводят список всех аргументов переданных скрипту. Но естественно есть различия в их использовании.

Голову не грей, теория всегда душная, сейчас на примерах рассмотрим и всё у тебя в голове сложится как надо.

Начнем с $@, накидываем скрипт:

echo "Изучаем \$@"
for arg in $@; do
    echo "Аргумент: $arg"
done

Запускаем так:

./script.sh 1 2 '3 with spaces'

На экран выводится:

Изучаем $@
Аргумент: 1
Аргумент: 2
Аргумент: 3
Аргумент: with
Аргумент: spaces

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

А теперь немного переделаем скрипт (добавим кавычки) и запустим с теме же аргументами:

echo "Изучаем \$@ с кавычками"
for arg in "$@"; do
    echo "Аргумент: $arg"
done

В этот раз на экран выведется такое:

Изучаем $@ с кавычками
Аргумент: 1
Аргумент: 2
Аргумент: 3 with spaces

Вот! Тут мы получили уже более ожидаемый результат. Массив: {$1, $2, $3}

Теперь про $*

echo "Изучаем \$*"
for arg in $*; do
    echo "Аргументы: $arg"
done

После запуска с такими же аргументами:

Изучаем $*
Аргументы: 1
Аргументы: 2
Аргументы: 3
Аргументы: with
Аргументы: spaces

Получаем то же самое, что и с $@ без кавычек. Шило на мыло. А вот если заключить $* в кавычки:

echo "Изучаем \$*"
for arg in "$*"; do
    echo "Аргументы: $arg"
done

На экране мы получим:

Изучаем $*
Аргументы: 1 2 3 with spaces

Вот и отличие. Оно небольшое, оно практически ненужное. Но в этом и кроются детали. Все аргументы объединились в одну строку, отделенным символом пробела, заданным в IFS (пробел по умолчанию).

Если это не знать, то легко можно наступить на грабли.

Вот пример как заменить IFS разделитель (пробел на запятую):

echo "Изучаем \$*"
IFS=","
for arg in "$*"; do
    echo "Аргументы: $arg"
done

Вывод будет таким:

Изучаем $*
Аргументы: 1,2,3 with spaces

Как «эффект бабочки», забыл поставить кавычки, сломал в будущем логику. Поставил кавычки, сломал другую логику. Куда не ткни, вечно какие-то костыли.

Я конечно сомневаюсь, что ты пользуешься таким высокоуровневым программированием (я не пользуюсь), но порой бывает натыкаешься на чужие скрипты с подобной логикой. И тогда важно не попасть в просак.

А что такое просак, хорошо объясняется в фильме «Жмурки».

Ладно, не смею тебя больше отвлекать. Увидимся. Хорошего понедельника!

tags: #bash #linux
—
💩 @bashdays

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

Однажды обратился клиент, которому злые лоси вынесли инфраструктуру. И когда мы полезли разбирать инцидент, на серверах отсутствовали логи, их просто не было. Их не удалили, их отключили. Тогда еще никто не парился со всякими ELK, да и может таких решений и не существовало вовсе.

В общем тут мои глаза и раскрылись, а зачем отключают логи? Правильно, чтобы что-то скрыть. Вектор атаки простой - заимел рута, отключил логи, зачистил то что было и делай свои грязные делишки.

И мне стало интересно, а как это провернуть? А если появился интерес, надо тыкать палкой.

Сейчас будем решать эту задачу. Как именно, понятия не имею. Будем экспериментировать.

Отключаем логирование

Цель - папка var/log всегда должна быть пустая и чтобы Linux машина не встала раком. Дополнительно обуздаем journald и history от bash.

Первое, что я проверил, удалил все и запретил вообще любую запись в var/log через chmod 000, но после перезагрузки сервера, всё вернулось на свои места. Права на папку стали 755. Однако…

Теперь попробуем установить на папку специальный атрибут:

sudo chattr +i /var/log

Перезагружаемся. Хе! Сработало. В папке пустота! На этом можно двигать задачу в done.

После установки этого атрибута, у тебя начнет сыпать ошибками apt, но пакеты оно будет ставить, так что имей это ввиду. Это фиксится добавлением строчки Dir::Log "/путь"; в apt.conf.d.

НО, не все так просто. Если ввести:

jorunalctl -f

Мы снова видим логи. Но теперь уже на экране. А раз они на экране, значит они где-то лежат и на диске. Давай искать.

Зачищаем этот системный журнал:

sudo journalctl --rotate && sudo journalctl --vacuum-time=1s

Ага, на экране видим путь, то что оно зачистило, это /run/log/journal/.

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

Открываем файл /etc/systemd/journald.conf и добавляем:

Storage=none

Перезагружаем службу и удаляем остатки:

sudo systemctl restart systemd-journald
rm -R /run/log/journal/*

Теперь если ввести:

jorunalctl -f

Получим такое сообщение: No journal files were found. Прекрасно!

Так, если в системе установлен rsyslog или подобное, то дизейблим и его:

systemctl stop rsyslog
systemctl disable rsyslog

Основное сделали. Осталось логирование в .bash_history. Зачищаем и накидываем атрибут на запрет записи:

cat /dev/null > ~/.bash_history
sudo chattr +i ~/.bash_history
history -c && history -w``

Либо добавляем в .bashrc строчку: HISTSIZE=0, с ней будет нативнее и без костылей с атрибутом.

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

Вообще все эти способы очень грубые и топорные. Было бы намного изящнее сделать решение, которое удаляет из логов только то, что нужно удалить. Логирование работает в штатном режиме, но критичные данные в логи не попадают.

Всех обнимаю, хорошего дня!

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

tags: #bash #linux
—
💩 @bashdays

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

Эту задачу мне удалось решить за несколько минут, не имея бэкапов я восстановил ему этот удаленный файл. Как раз способом из этого поста.

Если кратко, я глянул в логи /var/log/cron, взял рандомную таску которая выполнялась ранее и вбил:

grep -a -C 500 -F 'console import:reports' /dev/sda1

Соответственно console import:reports это часть таски, которая когда-то выполнялась. Команда отработала и нашла мне удаленный cron файл. Копипаста и все рады. Но тут опять же повезло, что данные не перезаписались на диске.

В любом случае можно было бы восстановить по хронологии из файла /var/log/cron, но уже с геморроем. Либо грепнуть CRON в syslog и journald.

На будущее сделал клиенту алиас:

alias crontab="crontab -i"

Этакая защита от дурака и толстых пальцев. Теперь если перепутать «e» и «r», то оно выругается и запросит подтверждение:

crontab: really delete root's crontab? (y/n)

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

Бэкап крона:

@daily crontab -l > $HOME/.crontab

Восстановить:

crontab < $HOME/.crontab

А вообще часто советуют использовать systemd timers вместо cron или systemd-cron, мол они гибче и безопаснее. Ну хз хз, каждый привык выбирать свои игрушки.

Всех с пятницей, хороших предстоящих выходных. Увидимся!

tags: #bash #linux
—
💩 @bashdays