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

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

С наступающим! Давным-давно я избавился от OpenVPN и сейчас активно продолжаю использовать WireGuard. Даже порой связываю продакшен сервера wg тоннелями в разных регионах, где нет возможности это сделать из коробки. Стабильно, быстро, бесплатно.

Всё было хорошо, пока я не повзрослел и не познал джаззз установил себе Windows. Ну и естественно запихал туда официальный гуёвый клиент от wg. А что могло пойти не так? А всё!

Клиент в рандомный момент показывал средний палец и работал через хуй копыто.

Приходилось его выгружать, перезапускать службы, иногда передергивать софтверно сетевую карту, чтобы не ребутить машину. Ну такое себе удовольствие… Мне блять/блядь работать надо, а я тут утехами занимаюсь.

Так я ебался с полгода, но в этот понедельник меня это окончательно заебало! Пошел искать альтернативы, конкретно гуишного клиента. Потому что сама технология wg меня устраивает, не устраивают эти постоянные глюки.

И да, я много гуглил про эти проблемы, они имеются и фиксятся именно, так как я их и фиксил, перезагрузками, службами и другими костылями.

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

Называется эта штука TunnlTo. Работает в коллаборации с WireSock. По бенчмаркам обгоняет даже официальный WG клиент. На странице проекта там все подробно описано, можешь самостоятельно ознакомиться.

Чо понравилось:

1. Не глючит, шустрый, не виснет
2. Поддержка импорта тоннелей из официального wg клиента
3. При загрузки ОС можно автоматом подключать/не подключать VPN
4. Разделение приложений, кто идет через VPN, а кто нет
5. Ну и конечно другие фичи, какие хз, мне 4х хватает

В общем мне пока нравится. Заточено под винду, но у маководов и линукс-гиков и так всё хорошо, мой личный пруф.

💻 Страница проекта на github

Неделька выдалась продуктивная и очень нервная, в плане работы, в плане домашней рутины, в плане партнерских интеграций. Надо уже новых коллег к нам приводить, а я всё фигнёй какой-то занимаюсь. Исправлюсь! На выходные сделаем небольшую паузу, буду готовить контент план, чтобы уж совсем из пальца темы не высасывать. Да и ты отдохнешь.

Ну а тебе и твоим близким желаю хороших предстоящих выходных, берегите себя ребят. Увидимся!

tags: #utils #windows #networks
—
💩 @bashdays

Доброе утро! Все выходные разгребал бухгалтерию, да готовил рекламную кампанию на завтра. Даже баг мимолётом поправил у клиента. После подключения ddos-guard, мониторинг сильно засопливил. Ну тут очевидно, docker контейнеры с экспортерами снимают показатели по домену, а домен-то теперь за ddos-guard, пришлось прокинуть hosts файл и ходить напрямую за метриками.

Ладно. Сегодня на повестке дня: Зачем добавлять ./ перед исполняемым файлом или скриптом.

Когда я только начал изучение linux, я столкнулся с проблемой, что не могу выполнить bash скрипт. Вроде и атрибут +x указан, но после запуска получал идинахуй:

script.sh: command not found

Интернета тогда не было, максимум на что я мог рассчитывать это Фидонет. Но он мне не понадобился, методом тыка я самостоятельно смог решить задачу с запуском. Наверное знания MSDOS как-то натолкнули поставить перед скриптом символы ./

Но почему так? Это же не логично! Нет, всё логично. Это сделано для безопасности и от кривых рук. Например:

Работаешь ты под рутом, заходишь в домашнюю папку какого-нибудь пользователя, делаешь ls и хуяк, нет у тебя больше сервера. А что произошло?

А произошло то, что в папке пользователя лежал бинарник под названием ls. Который содержал руткит, он то и выполнился. Хотя ты ожидал что выполнится нативная утилита ls.

Вот поэтому если запускать какую-то дичь или скрипт БЕЗ ./ то оболочка будет искать эту дичь/скрипт в указанных каталогах. Которые определены в PATH. Соответственно если домашний каталог пользователя не определен в PATH, то и возникает ошибка command not found.

А вот когда указываешь ./script.sh ты говоришь оболочке - Эй бля! Игнорируй PATH и запускай мне эту пепяку! Да, вот прям отсюда!

Аналогично можно запускать указывая полный путь к программе/скрипту:

cd ~
./script.sh

# или

/home/user/script.sh

Здесь так же PATH будет игнорироваться. Но вопрос остается: Как это может быть мерой безопасности, если эта мера обходится банальным ./ ?

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

Как вариант, можешь добавить точку в PATH и тогда можешь запускать скрипты без ./ например:

export PATH=$PATH:.
script.sh

Добавляем текущий каталог в PATH. Теперь script.sh выполнится, без указания этого хитрого ./ Но так делать не рекомендуется, наступишь на грабли или даже на граблища!

Так, теперь про cron. Если хочешь чтобы твои скрипты гарантировано запускались в cron, всегда указывай полные пути до программ/утилит. Так как cron может смотреть в какой-то свой PATH или вообще через sh запускаться. Встречал/встречаю я такие случаи. Поэтому рекомендуется писать скрипты в таком духе:

CAT=$(which cat)
$CAT script.sh

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

Вот так. Хорошей тебе рабочей недели. Вечерком после интеграции закину еще чтива. На связи!


tags: #bash #linux
—
💩 @bashdays

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

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

Короче под капотом Debian 12 или Windows Server 2016 (14393.6709) Длительность онлайн сессии 15 минут.

С докой по сервакам, можешь ознакомиться здесь, там с картинками и всеми подробностями.

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

Ради интереса проверил лицензию winrar, на момент закралась мысль - а что если... Но нет, всего лишь пробная версия на 40 дней. Ну да ладно.

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

Выжимка из доки:

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

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

tags: #services
—
💩 @bashdays