Linux очистить все логи

Удалить все /var /log?

Можно ли удалить все в /var/log ? Или я должен только удалять файлы (рекурсивно) в /var/log , но оставить папки?

Есть ли у кого хорошая строка rm ? (Мои навыки администратора оставляют меня нервным.)

Примечание. Я использую Debian. Я не уверен, какая версия.

9 ответов

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

Вы никогда не знаете, когда вам понадобятся журналы с некоторого времени назад, поэтому лучше их архивировать (до разумного возраста, например, 3 месяца).

logrotate может сжать ваши старые файлы журналов, чтобы они не занимали много места на диске.

Если вы удалите все в /var /log, вы, скорее всего, получите массу сообщений об ошибках за очень короткое время, так как там есть папки, которые, как ожидается, будут существовать (например, exim4, apache2, apt, cups, mysql, samba и др.). Плюс: есть некоторые службы или приложения, которые не будут создавать свои файлы журналов, если они не существуют. Они ожидают по крайней мере пустого файла. Поэтому прямой ответ на ваш вопрос на самом деле — «Не делай этого . » .

Как отметил Йоши, для этого нет оснований. У меня запущены серверы debian, у которых не было одного файла журнала, удаляемого за многие годы.

Удалить все файлы:

Удалить все .gz и повернутый файл

Попробуйте запустить команду без «-delete», чтобы протестировать ее.

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

, который очищает журналы, но сохраняет файлы.

Очистка всех журналов в системе Linux без удаления файлов:

Samba ( /var/www/samba ) создает имена файлов журналов с IP-адресами, вы можете их удалить:

Вы можете использовать параметр ctime для поиска старых файлов . например:

Как bindbn объясните, сначала попробуйте найти файлы выборки и после использования опции delete: D

Я использовал простой уборщик здесь:

• Удаляет имена файлов с помощью следующих шаблонов имен файлов с паролями в /var/log
  ^.*/.+\.[[:digit:]]+(\.[[:alpha:]]+)?$ литий>
  • ^.*/.+\.old$ (без учета регистра)
• Truncate /Empty файлы с именами файлов со следующими шаблонами имен файлов в /var/log
  • ^.*/.+\.log$ (без учета регистра)

/var/log часто имеет разрешения drwxrwxr-x , поэтому он не доступен для пользователя, если только пользователь не является root или принадлежит привилегированной группе. Это означает, что новые файлы журналов не могут быть созданы не-привилегированными пользователями.

Приложения, которые ожидают входа в точку внутри /var/log , будут часто касаться файла, существовавшего где-то в /var/log во время установки (что часто встречается с повышенными привилегиями) и будет chmod и, возможно, chown в это время для разрешений, подходящих для непривилегированных пользователей, которые будут использовать приложение.

Журналы Apache, например, обычно записываются с помощью nobody , который является пользователем с максимально возможными привилегиями для Apache для выполняйте свою работу, не подвергая систему неоправданному риску. Но даже приложение с большим количеством приложений часто ожидает, что оно сможет записать в файл журнала в /var/log .

Итак, что происходит, если файл журнала и путь к файлу журнала не существуют? Это полностью зависит от приложения. Некоторые приложения будут спокойно пропускать протоколирование. Другие создадут много предупреждений. И другие просто выручат. Там нет жесткого правила; это зависит от бдительности разработчика приложения, а также от того, насколько критичен разработчик его способность регистрироваться. В лучшем случае приложение попытается либо написать, либо, возможно, создать, а затем записать в файл журнала в месте назначения в /var/log и будет не может этого сделать, потому что он запускается пользователем, который не имеет прав на запись в эту часть файловой системы.

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

Соответствующее действие — установить logrotate с соответствующими конфигурационными файлами. Обычно вращение будет связано с заданием cron. Вращение может быть основано на интервалах, или на основе размера, или и то, и другое. Также возможно настроить правила, которые не допускают поворота на основе интервалов, если файл журнала по-прежнему пуст, когда истекает интервал. Вращение может включать в себя рассылку лог-файлов, сжатие, удаление, измельчение и т. Д.

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

Источник

Очистка лог файлов под linux

Я использую виртуальную машину kvm ubuntu 10.04 для тестирования некоторых функций модуля ядра. Я пролистываю файлы /var/log для просмотра сообщений ядра об этом модуле.

Чтобы начать с чистого состояния, я удаляю файлы журналов, содержащие старые сообщения, выполнив rm -rf /var/log/* , а затем перезагрузив виртуальную машину. Однако после перезагрузки новые файлы журнала все еще содержат эти старые сообщения журнала. Удаление файлов и перезагрузка виртуальной машины занимает около 5-6 циклов, чтобы окончательно избавиться от сообщений журнала.

Почему это происходит? Есть ли более простой способ очистки файлов журнала?

3 ответа

Самый простой способ очистить старые журналы — не удалять их.

Лучший способ очистить журналы — это либо logrotate , как указал Ханан Н., либо:

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

Обычно, хотя вы не хотите очищать журналы, так как они являются отправной точкой для устранения неполадок.

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

Есть также инструменты, которые будут извлекать только новые записи из журнала. Утилита logtail из пакета logcheck одна такая утилита. Его можно запустить с файлом альтернативного смещения.

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

Похоже, что это работает нормально (в Ubuntu LTS 14.04), свернув журналы в чистый журнал, а затем удалив старые записи журнала. Он похож на метод cp /dev /null, но я думаю, что он чище. YMMV

Источник

Заметаем следы вместе с хакерами. Чистим логи и историю Bash на взломанных Linux системах

Последним этапом деятельности любого хакера является заметание следов.

Автор: DRD_, Cyber Weapons Lab

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

Для демонстрации основ заметания следов, сначала скомпрометируем цель, а затем изучим несколько методов, используемых для удаления истории Bash и очистки логов после взлома Linux систем.

Шаг 1. Скомпрометируйте цель

Первое, что нам следует сделать, — взломать цель. Используя некорректную обработку сервером команд ОС, можно применить внедрение команд, для получения оболочки. Затем нашу новую оболочку необходимо обновить до полностью интерактивной. Данная процедура значительно упростит работу. После этого мы сможем повысить наши привилегии до root, чтобы наилучшим образом использовать преимущества системы и оставаться незамеченными.

Шаг 2. Создайте легко удаляемый скрытый каталог

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

С помощью команды mkdir можно создать скрытый каталог, добавив точку к имени:

Зададим команду перечисления содержимого /dev/shm. Как видим, ничего не появилось:

Каталог появляется лишь тогда, когда мы используем переключатель -a для вывода списка всех файлов и каталогов:

Для удаления каталога после завершения работы на машине, используйте команду rmdir :

Шаг 3. Удалите историю Bash

Команды записываются в переменную среды HISTFILE, обычно это .bash_history. Воспользуемся echo для определения местоположения:

Используем команду unset для удаления переменной:

Повторив процедуру снова, видим, что ничего не появляется:

Чтобы история команд не сохранялась, также можно ее отправить в /dev/null. Для этого установите переменную:

Или сделайте то же самое с командой экспорта:

История теперь будет отправлена в /dev/null (то есть никуда):

Установите количество команд, которые будут сохраняться во время текущего сеанса, равным 0, используя переменную HISTSIZE:

В качестве альтернативы используйте команду экспорта:

Измените количество строк, разрешенных в файле истории, с помощью переменной HISTFILESIZE. Установите данное значение на 0:

Или с экспортом:

Для изменения параметров оболочки также можно использовать команду set. Чтобы отключить опцию истории, используйте следующую команду:

Снова включите ее:

Точно так же для изменения параметров оболочки можно использовать команду shopt. Чтобы отключить историю, используйте следующую команду:

Снова включите ее:

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

Данный метод работает не всегда и зависит от системы. Также можно просто очистить историю с помощью переключателя -c :

Чтобы убедиться, что изменения записаны на диск, используйте переключатель -w :

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

Также можно использовать команду kill для выхода из сеанса без сохранения истории:

Шаг4. Очистите файлы журнала

Конечно, можно просто удалить журнал с помощью команды rm :

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

Обратите внимание, функция усечения присутствует не всегда и не во всех системах.

То же самое можно сделать, отображая в файл “ничего”:

А также использовать > сам по себе для очистки файла:

Мы также можем отправить его в /dev/null:

Или использовать команду tee :

Также можно использовать команду dd, чтобы ничего не записывать в файл журнала:

Команда shred может быть использована, чтобы поверх перезаписать файл с бессмысленными двоичными данными:

Дополнительно добавив -zu, вы обрежете файл и перезапишете его нулями:

Шаг 5. Используйте специальный инструмент для наилучшего сокрытия следов

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

Затем запустите его:

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

Также можно отключить Bash и историю авторизации с помощью опции 2:

Если вам нужно срочно все очистить, просто добавьте в команду now:

Заключение

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

Источник

Как очистить журналы logs в Systemd

Журнал systemd – это собственная система журналирования systemd. Это эквивалентно системному журналу в системе инициализации. Она собирает и хранит данные журнала ядра, сообщения системного журнала, стандартный вывод и ошибки для различных системных служб.

Машина Linux с systemd записывает журналы в каталог /var/log/journal. Если вы помните структуру каталогов Linux , в /var хранятся системные журналы.

Что касается ведения журнала, то со временем она начинает расти. И если вы проверите дисковое пространство в Linux, вы увидите, что иногда это занимает несколько ГБ.

Позвольте нам показать вам, как очистить журналы systemd и освободить место на диске в вашей системе Linux.

Очистка журналов журнала systemd

Сначала проверьте пространство, занятое журналами журнала, с помощью команды du:

Вы также можете использовать команду journalctl для той же задачи:

Обе команды должны дать примерно одинаковый результат:

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

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

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

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

1. Очистить журнал журнала старше x дней

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

Вот как может выглядеть вывод:

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

2. Ограничить журналы до определенного размера

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

Это уменьшит размер журнала примерно до 100 МБ.

Вы можете указать размер в ГБ с G, МБ с М, КБ с К и т. д.

Надеюсь, вам понравится этот быстрый совет по очистке файлов журналов systemd. Если у вас есть какие-либо вопросы или предложения, пожалуйста, оставьте комментарий ниже.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник