Чистка логов Апача

А как насчот времени модификации фаила? через touch?

to logos:

Цитата
grep -v "твой ip" access_log (или error_log) > tmp; mv tmp access_log

После такой 'чистки' Apache больше ничего не будет писать в access_log до своего рестарта.

To Shanker:

Цитата
А как насчот времени модификации фаила? через touch?

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

Дата последнего изменения метаданных файла (ctime). Её можно увидеть с помощью ls -lc filename). Для многих редкоизменяемых файлов ctime обычно указывает на дату их создания.

Дата последней модификации содержимого файла (mtime). Её можно увидеть с помощью ls -l filename).

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

Для того чтобы пользовательские приложения могли изменять вышеперечисленные атрибуты, ядро предоставляет несколько *utime-подобных системных вызовов (которые и используются утилитой touch). Однако, есть одно "НО". Дело в том, что эти системные вызовы позволяют изменять только mtime и atime атрибуты, а вот ctime изменяется только самим ядром. Например, если атакующий заменил какой-нибудь бинарный executable файл, а затем через touch (или подобную утилиту) "подогнал" его mtime+atime атрибуты под те же значения, которые были ранее у файла-оригинала, то факт подмены файла очень просто обнаруживается при помощи команд ls -lc  и ls -l. Простро сравните даты. Если mtime является более ранней датой чем ctime, то это наталкивает на определённые подозрения. Особенно если метаданные анализируемого файла в нормальной ситуации не должны были измениться (а в большинстве ситуаций метаданные бинарных executable файлов очень редко изменяются с момента их создания).

Короче, для полноценного и чистого исправления *time атрибутов файла необходимо обязательно изменять и ctime. Это можно сделать путём "отката" системного времени перед внесением изменений в файл (хотя это и ОЧЕНЬ КОРЯВЫЙ метод, но он и самый простой), либо путём прямого исправления файловой системы (этот метод по-сложнее, т.к. он не всегда может быть выполнен штатными средствами). Второй метод можно раскрыть следующим примером:

Допустим, у нас имеется корневая файловая система ext2 на /dev/hda2 и нам необходимо изменить ctime атрибут файла /etc/passwd. Воспользуемся штатной утилитой debugfs из пакета e2fsprogs.

bash# debugfs -w /dev/hda2
debugfs: 1.39 (29-May-2006)
debugfs: show_inode_info /etc/passwd
.......skip.....
ctime: 0x44eed0fe -- Fri Aug 25 10:29:18 2006
.......skip.....
debugfs: set_inode_field /etc/passwd ctime 20060102030405
debugfs: show_inode_info /etc/passwd
.......skip.....
ctime: 0x43b89825 -- Mon Jan 02 03:04:05 2006
.......skip.....
debugfs: quit
bash#

P.S. Здесь специально не упоминаются системы хранения и проверки контрольных сумм/хешей файлов, т.к. это выходит за рамки поднятых вопросов.

Удачи.

Я имел ввиду, что если использовать тот способ, который предложил г-н logos, то система журналирования апача нарушится (из-за того что изменяется inode number access_log файла).

А какую ошибку выдаёт если не убивать апач и пытаться манипулировать с логами ?

Цитата
ClosedGL пишет: А какую ошибку выдаёт если не убивать апач и пытаться манипулировать с логами ?

У меня не рутовкие права. Просто не даёт перезаписать файл: ошибка записи.

Тем не менее вопрос остаётся открытым: есть ли возможность модификации логов БЕЗ рестарта апача? Или это невозможно даже теоритически?

Цитата
ClosedGL пишет: Да можно конечно. хоть обычным grep'ом

А как же твои же слова:

Цитата
ClosedGL пишет: После такой 'чистки' Apache больше ничего не будет писать в access_log до своего рестарта

То ли явное противоречие толи я что-то не догоняю