Как было предложено в этом ответе, достаточно заключить переменную в кавычки.
Причина, по которой кавычки необходимы в вашем случае, заключается в том, что без них bash применяет оператор split+glob к расширению $MYCUSTOMTAB
. Значение по умолчанию $IFS
содержит символ TAB, поэтому в echo -e $MYCUSTOMTAB "blah blah blah"
, $MYCUSTOMTAB
просто разбивается на ничто, так что получается то же самое, как если бы вы написали:
echo -e "blah blah"
(вероятно, вы не хотите -e
здесь, btw).
Вы также можете использовать printf
вместо echo
:
printf '%s\n' "$MYCUSTOMTAB"
printf '%s\n' "${MYCUSTOMTAB}blah blah"
Или, если вы хотите, чтобы printf
делал такие же \n
, \t
расширения, как echo -e
, используйте %b
вместо %s
:
printf '%b\n' "${MYCUSTOMTAB}blah blah"
Для справки читайте Почему printf лучше echo?
Я хотел прокомментировать, но получилось слишком длинно. Глядя на журнал, я вижу контекст файла subj=system_u:system_r:unconfined_service_t:s0
. Это указывает на то, что SELinux включен. Проверьте статус SELinux с помощью sestatus
или getenforce
. Если вы видите enforcing, то контекст файла сверху не тот, что я ожидал увидеть. Я бы попросил вас перейти в DIR /home/usersite
и запустить ls -Z
. Это будет хороший контекст файла ole ls plus. Вот вывод ls -Z на моем блоке разработчика:
[user@localhost]$ ls -Z ~ | grep -i Music
drwxr-xr-x. user user unconfined_u:object_r:audio_home_t:s0 Music
Сравните контекст файла с другими файлами в том же DIR. Я ожидаю увидеть контекст файла unconfined_u:object_r:httpd_sys_content_t:s0
для файлов, на которых работает ваш веб-сервер. В прошлом я перемещал файлы с применением SELinux и вызывал проблемы, потому что контекст файла не меняется при перемещении файлов, а с применением SELinux и неправильным контекстом у вас будут проблемы, которые будет обнаруживать Auditd. Чтобы изменить контекст файла, используйте chcon
как root для изменения контекста. Я работаю в основном с RHEL/CentOS, и вот ссылка , которая может помочь прояснить некоторые из ваших вопросов и узнать, как использовать chcon
для получения правильного контекста файла.
У вас есть девять записей аудита, все из которых произошли менее чем за три секунды, в воскресенье, 31 марта (в эпоху с 1554067160 по 1554067162; см. ваше местное время для тех, у когоdate -d @1554067160; date -d @1554067162
). Эти записи аудита были созданы на основе правила аудита, которое вы пометили именем «мониторить -хосты».
Все записи очень похожи, в основном отличаются значениями pid
, но также различаются значениями name
.
Процесс запущен из /opt/cpanel/ea-php70/root/usr/sbin/php-fpm
с родительским pid 9239, UID 1121 и GID 1123. Этот процесс открылся(syscall=2
на x86 _64 )"/home/usersite/public _html/index.php" (inode 576615421 )три раза, затем открыл "/home/usersite/public _html/wp -content/themes/twentythirteen/index.php" (inode 1135033766 )шесть раз. Оба этих файла находятся на устройстве 09 :01, что переводится как /dev/md1
--, предположительно у вас есть файловая система, построенная на /dev/md1
. Текущим рабочим каталогом для первых трех открытий был «/home/usersite», а рабочим каталогом для последних шести открытых был «/home/usersite/public _html». Открытые вызовы были успешными и возвращали различные дескрипторы файлов(5
или 6
).
На данный момент оба файла имели режим (набора разрешений )из 644
, как показано в mode=0100644
.
К сожалению, ни одна из этих контрольных записей не указывает (на более высоком уровне )«что» произошло или «как». Если вы подозреваете, что эти файлы index.php были повреждены злоумышленником, весьма вероятно, что они используют этот файл php -fpm (или базовую уязвимость )для доступа к файлам.
Следующая ссылка оказалась полезной для меня при анализе логов:
Также был полезен этот фрагмент Python, который я создал для преобразования шестнадцатеричных -закодированных полей, таких как proctitle:
python -c 'import binascii; print binascii.a2b_hex("636174002F6574632F7373682F737368645F636F6E666967")'
Обновлен фрагмент python для python3:
python3 -c 'import binascii; print(binascii.a2b_hex("636174002F6574632F7373682F737368645F636F6E666967"))'