|
Перевод статьи «Sending Apache httpd Logs to Syslog» автора Rich Bowen. Каждый раз, когда ваш сервер Apache получает запрос, он создает запись в одном или нескольких лог-файлах. Эти лог-файлы полезны для разных целей, от статистического анализа ваших посетителей до анализа атаки на ваш сервер. Во многих случаях, наличие этих логов, записанных в локальной файловой системе, по крайней мере, неудобно. Два отдельных сценария пришли мне в голову, но, возможно, у вас есть другие. С первым я, к сожалению, имел личный опыт. Когда взломщики атакуют сервер, они часто «убираются» за собой, так что вы не можете вычислить, как они проникли. Если они осторожны, это включает в себя удаление логов, так что вы не можете увидеть, какие техники они использовали. Это особенно важно, если они использовали сам веб-сервер в качестве способа проникновения, а некоторые скрипты-эксплойты просто удаляют лог-файлы для надежности. В этом случае, очень полезно иметь копию лог-файлов где-нибудь ещё. Второй сценарий, возможно, менее вероятен, но он просто интересен. Когда у вас более одного сервера, — особенно если их у вас дюжины или сотни, — довольно трудно просматривать все ваши логи, так как их очень много. В этом случае, может быть полезно комбинировать их в одном месте. В обоих случаях, посылать логи в центральный сервер syslog будет идеальным вариантом, в отличие от записи в локальной файловой системе. Ведение лога в syslog Так получилось, что мало людей знает о том, что Apache может вести лог ошибок в syslog с помощью одной директивы настройки: ErrorLog syslog:local1 Это почти все, что надо сделать. Эта строка сообщает Apache посылать лог ошибок в syslog под названием local1. Конечно, вам также надо сказать вашему серверу syslog отправлять этот лог другому серверу, вашему серверу syslog, чтобы записывать его в лог-файл. То, как именно вы можете это сделать, будет зависеть от реализации syslog. Как бы то ни было, обычный syslog в Linux использует файл под названием /etc/syslog.conf (или что-то похожее) для настройки отправки сообщений syslog. Так как лог ошибок Apache использует стандартный для syslog вид, вы можете использовать обычные настройки syslog для разделения вывода данных syslog в различные файлы. Например, если вы хотите вести лог только для критических ошибок в отдельном файле, добавьте следующую строку в файл /etc/syslog.conf: local1.crit /var/log/apache.crit Это инициирует ведение лога записей уровня crit и выше в файл /var/log/apache.crit Я обещал, что вы можете отправлять записи лога на другой сервер. Для этого пропишите такую строчку: local1.* @192.168.200.12 Вам также надо настроить удаленный сервер syslog для принятия этих записей лога. Для большинства серверов syslog, это делается добавлением параметра -r к другим параметрам запуска сервера syslog. Тем не менее, это может быть по-другому в другой реализации, так что обратитесь к документации вашего syslog сервера. Отправка логов доступа К сожалению, только логи ошибок имеют такую встроенную возможность. Но крайне полезно также иметь логи доступа в наличии на удаленном сервере, по причинам, описанным выше. Вот способ отправлять лог доступа в syslog. Однако, как и в любой другой подобной статье, я призываю вас прочитать документацию к Apache, так как эта возможность может быть встроена в будущем. На данный момент, вот что вам надо сделать. Весь процесс можно разделить на два шага. Во-первых, создайте скрипт, который будет отправлять записи в syslog: #!/usr/bin/perl
use Sys::Syslog qw( :DEFAULT setlogsock );
setlogsock('unix');
openlog('apache', 'cons', 'pid', 'local2');
while ($log = Этот скрипт, написанный на Perl, использует модуль Sys::Syslog для отправки данных серверу syslog. Убедитесь, что модуль Sys::Syslog установлен у вас, хотя, он должен быть стандартным для последних версий Perl. Поместите куда-нибудь этот скрипт и сделайте его исполняемым. Для этого примера, я подразумеваю, что вы сохранили его, как /usr/local/apache/bin/apache_syslog. Во-вторых, направьте ваш лог доступа на этот скрипт, используя pipe-синтаксис лог-файла: CustomLog |/usr/local/apache/bin/apache_syslog combined Скрипт apache_syslog будет запускаться при старте веб-сервера и обрабатывать записи лог-файла так, словно он получает их от сервера. Цикл while будет продолжаться, пока работает процесс Apache. Как вы видите в скрипте, он отправляет эти записи в syslog под названием local2, так что настройте ваш syslog сервер с помощью следующей строки в /etc/syslog.conf: local2.* @192.168.200.12 Ознакомьтесь с документацией модуля Sys::Syslog для получения более подробной информации о доступных опциях данного модуля. С этой настройкой, в случае атаки на ваш сервер или фатальной ошибки, у вас по-прежнему будет удаленная копия ваших логов для того, чтобы понять, что произошло. Примите во внимание и то, что если у вас есть несколько директив CustomLog, у вас могут и быть несколько лог-файлов. Поэтому, если вы хотите иметь локальный лог-файл вдобавок к удаленному, просто добавьте ещё одну директиву CustomLog, указывающую на локальный лог-файл: CustomLog /usr/local/apache/logs/access_log combined Предостережения Конечно, существует пара предостережений при ведении лога в syslog. Первое: если вы ведете лог с нескольких серверов в центральный сервер syslog, важным будет то, чтобы держать ваши часы синхронизированными с NTP. Если вы этого не сделаете, записи логов будут не будут поступать в правильном порядке, и это может вызвать трудности при обработке логов для получения статистической информации. В частности, некоторое программное обеспечение, производящее статистическую обработку, может неправильно сработать и прервать процесс своей работы. Второе: я упомянул, что мой сервер syslog объединяет несколько записей лога в одну строку, в случае, если они одинаковые. Например, повторяющийся запрос к одному и тому же отсутствующему файлу, получит такое отображение: Aug 31 20:18:05 192.168.200.10 last message repeated 19 times Наконец, не лишним будет упомянуть о существовании сторонних модулей для ведения логов на нескольких серверах. Самым популярным из таких модулей является mod_log_spread, который может быть более подходящим решением для очень больших (если в наличии много серверов) инсталляций. |