В то время как люди обычно понимают, что важно хранить журналы и управлять ими, чтобы их можно было регулярно проверять на предмет операций, анализа первопричин, целей безопасности и т. Д. Часто мы сталкиваемся с тем, что пользователи не могут понять, с чего начать при просмотре данных журналов и что они должны высматривать. Общий вопрос, который мы получаем:
«Хорошо, у меня есть куча Linux-боксов, я использую стек LAMP, на что мне следует обращать внимание в журналах».
К сожалению, это все равно, что пытаться объяснить кому-то, как починить свою машину, если у нее возникли проблемы, БЕЗ знания проблемы. Поэтому очень сложно сказать: «ну, вы должны искать в журнале X проблему Y». Мы находим гораздо лучший ответ — дать людям обзор регистрации на их платформе, как она работает, как она может быть настроена, в какие файлы и местоположения регистрируются различные типы событий и какие инструменты можно использовать для анализа данных. Так что это именно то, что мы собираемся сделать здесь. Таким образом, если вы хотите выполнить проверку безопасности или вам необходимо «устранить» некоторые ошибки, копаясь в ваших данных журнала, вы будете знать, где искать, и у вас будут подходящие инструменты для работы.
В ближайшие недели и месяцы мы рассмотрим ряд платформ и технологий, но в качестве отправной точки мы начнем с обзора ведения журналов в linux и того, что вам нужно знать, если вы используете, в частности, стек LAMP.
1. Системный журнал
Все дистрибутивы Linux (и UNIX), а также большинство маршрутизаторов, брандмауэров и сетевых устройств используют Syslog для обеспечения функциональности журналирования. Системный журнал часто называют «рабочей лошадкой разнородных сетевых журналов» …. Хорошо, может быть, не так часто … но фраза довольно хорошо подытоживает, что такое системный журнал.
Чтобы быть точным, Syslog — это фактически протокол, который позволяет машине / устройству отправлять данные журнала по сети сборщикам сообщений о событиях (серверам syslog). Протокол определяет архитектуру обмена сообщениями, какие протоколы и порты транспортного уровня должны использоваться для отправки информации, как должны создаваться сообщения, а также способ описания того, откуда поступили сообщения в вашей системе (на уровне оборудования ) и как они должны это делать. лечиться ( уровень тяжести ).
Однако термин «системный журнал» также регулярно используется для обозначения любых реализаций протокола, которые поставляются с различными операционными системами, такими как syslogd, rsyslog и syslog-ng. Все они поддерживают сбор и пересылку журналов на сервер журналов или в службу журналов . Различные реализации отличаются с точки зрения функциональности, которую они предоставляют, причем некоторые из них более мощные, чем другие. Syslogd является самой простой реализацией и поддерживает только пересылку UDP. Rsyslog и syslog-ng предоставляют некоторые дополнительные и весьма полезные функции. Например, оба поддерживают переадресацию UDP и TCP. Rsyslogпоставляется с Ubuntu и Fedora, и, исходя из собственного опыта работы с ним, его очень просто настроить. Помимо обработки журналов уровня операционной системы, он поддерживает такие общие компоненты, как MySql, PostgreSQL, Oracle и другие. Syslog-ng, поддерживаемый ребятами из Balabit , предоставляет некоторые дополнительные функции, такие как возможность классифицировать, маркировать и сопоставлять сообщения журнала в режиме реального времени. Он также может быть настроен для пересылки журналов, не относящихся к системному журналу (например, созданных вашими серверами приложений / кодом приложения) сторонним службам (таким как Logentries) или серверам сбора системного журнала. Если вы пользователь Windows и чувствуете себя немного обделенными всеми этими разговорами о syslog и linux, не отчаивайтесь, есть даже реализация syslog для Windows ( snare ) !!
Для настройки Syslog вам нужно иметь дело с соответствующим файлом ‘.conf’ для вашей версии syslog. С rsyslog это rsyslog.conf и обычно находится в /etc/rsyslog.conf. В файле конфигурации вы указываете такие вещи, как:
- формат ваших сообщений журнала.
- в какие события файла (от разных частей вашей системы) следует регистрировать события.
- в какие события файла с разными уровнями серьезности следует записывать.
- где регистрировать ваши данные — например, вы можете войти в файлы, но вы также можете войти в базы данных или переслать ваши журналы на удаленный сервер / службу регистрации.
- фильтры — т.е. удалить события, которые вы не хотите регистрировать.
Для получения дополнительной информации о настройке rsyslog.conf см. Справочную страницу rsyslog . Ребята из Monitorware также проделали хорошую работу по сбору уроков и руководств по системному журналу .
Обратите внимание: если вы играете с syslog и хотите создавать сообщения журнала тестирования, команда ‘logger’ может быть очень полезна. Команда ‘logger’ позволяет вам отправлять некоторые события журнала тестирования в системный журнал. Например:
$ logger this is a test log event
Отправит сообщение «это событие журнала тестирования» в файл «/ var / log / syslog» со стандартной конфигурацией rsyslog. ‘logger’ также может использоваться для добавления функциональности регистрации в любые написанные вами сценарии оболочки .
2. Где живут журналы Linux
Если вы находитесь в дистрибутиве Linux, большинство ваших журналов будут находиться в папке «/ var / log» или в одной из ее подпапок. Geek Stuff предоставляет список из 20 различных файлов журналов, которые находятся в каталоге «/ var / log /», которые могут представлять интерес, и дает подробную информацию о том, какие события обычно содержатся в этих журналах.
Вот краткое изложение некоторых из наиболее интересных из них, обратите внимание, что некоторые из них относятся к конкретному дистрибутиву:
- / var / log / message: глобальные системные сообщения, включая сообщения, зарегистрированные во время запуска системы
- / var / log / dmesg: информация о кольцевом буфере ядра, содержит информацию об аппаратных устройствах, которые ядро обнаруживает в процессе загрузки. Вы можете использовать команду ‘dmesg’ для вывода списка этих событий из командной строки.
- /var/log/auth.log: журналы аутентификации, включая логины пользователей и используемый механизм аутентификации.
- /var/log/daemon.log: файл журнала для всех процессов, работающих в фоновом режиме.
- /var/log/kern.log: журналы ядра, все сообщения, выводимые ядром linux.
- /var/log/cron.log: Журналы запланированных заданий cron.
- / var / log / maillog: журналы почтового сервера.
- /var/log/boot.log: сообщения, сгенерированные во время загрузки.
- / var / log / secure: журнал аутентификации
Also if you are running a LAMP stack these may be of interest:
- Apache: apache web server logs (i.e. access.log and error.log) are usually found at /varl/log/httpd or /var/log/apache2/
- Nginx: if you run nginx rather than apache, nginx logs are located at /var/log/nginx/. Nginx log events are stored in the yourapp.access.log and yourapp.error.log. The access log contains records of requests made to the web server, with any related errors being sent to the error.log. Further info on nginx logs can be found at nginx.org.
- MySQL logs: The general query log, error log and slow query log are usually of interest and are located at /var/log/mysql.log, /var/log/mysql.err and /var/log/mysql/mysql-slow.log respectively. Note the slow query log often needs to be enabled in the relevant mysql configuration file.
We’ll be covering technologies such as .NET, Java, Ruby, PHP etc. in more details in future posts, giving details on what logs are important for these technologies and what to look out for within the log data.
3. Things to look out for
“What to look out for in linux logs” was the motivation for this post. And although I’ve said above that this is a difficult question to answer without knowing the specifics I thought I’d better not dodge the question completely and at least give some examples of issues and how they can be investigated. Sandeep Kalathil gives some nice examples in his piece on the Binbert blog and so also do the guys at Linucium. I’ll cover some of these here and give a few more also:
- messages.log: is known as the “general system activity” log and is where various system applications and daemons record messages as well as messages from non-kernel boot issues, cron jobs, authentication events, and messages that go to the dmesg log end up. It is usually the first place to look when there is something up and you need to begin investigation.
- dmesg.log: As explained above, this log contains messages from the kernel that appears during the boot process, thus it is the first place to look if your system is not behaving properly and you suspect something went wrong during start up, such as a device driver issue, wifi issue or a service that fails to start correctly. For example if you suspect your wifi driver has problems, you might search the dmesg.log file for the string ‘wlan’ or ‘wifi’ like this guy. Checking my own dmesg.log (I’m running ubuntu) I see that my MongoDB instance failed to start correctly. I get the following when searching for ‘init’ in dmesg.log:
18.480052] init: mongodb main process (1273) terminated with status 100)
Copying the error code into google gets me a quick fix also – nice! Finally the guys at Ghacks also give some good tips on identifying issues, related to attaching usb devices, using the dmesg log.
- Logins/dictionary attacks: If you suspect that there is a security issue with system access you may want to go directly to the ‘auth.log’. The ‘auth.log’ records all user logins and the login mechanism used, and will capture any unauthorised access or attempted access for that matter. For those with servers that have publicly facing IPs this is a log that you should keep an eye on, in particular to monitor dictionary attacks which WILL occur regularly enough. My recent post on the Engine Yard blog shows what a successful dictionary attack looks like. It’s a good idea to create alerts around this type of activity in your logs also.
- Tracking sudo access: whenever you run the ‘sudo’ command, it logs it in the auth.log file in case you need a clear picture of who did what, and when
- kernel.log: Diagnosing problems with a new kernel installation (-e.g. distribution upgrade) or major system problems
- Apache logs: apache logs can be reviewed for issues with web requests such as broken links (check the apache error log for ‘”file not found’ or ’404′) or for security issues such as denial of service (DOS) attacks. The apache logs contain the IP address of the machine that made the request, so you can see who is trying to accessing your web application. If someone is performing as DOS attack you can, as a starting point, figure out where this is coming from and if it is a DOS or not. Some apache common error codes are discussed in this post. The full list of possible status codes can be found in the HTTP specification (RFC2616 section 10).
- MySQL logs: Database logs can be useful for investigating slow queries or DB related errors. Slow queries are essentially queries in your database that are taking too long. They can result in slow running applications and are one of the most common issues resulting in application performance problems.
I hope this helps in giving you a clearer picture of logging on linux and where to start if you need to review your logs. In part 2 of our ‘logging on linux’ series, we’ll cover a number of other topics such as tools for analaysing and managing your linux logs, log forwarding on linux and why storing logs remotely is recommended.