лог пасс что это такое
Как читать логи сервера и что это такое?
Логи – это инструмент, при помощи которого можно отслеживать рабочий процесс сервера или сайта. Поэтому знать, как читать логи это полезное умение для выявления сбоев в работе ПО, быстрого и результативного реагирования на другие проблемы (выявление злонамеренных действий), эффективного анализа рабочий процесс, противодействия DDoS-атакам.
Содержание:
Что такое логи и зачем они нужны
Логи (log) – это специальные текстовые файлы, в которых в хронологическом порядке фиксируется информация обо всех действиях программы или пользователей. Проще говоря, это журнал регистрации всех событий происходивших в системе:
Логи доступа указывают на уязвимые места сайта (в случае взлома), помогают собирать статистику посещаемости, узнавать откуда проводились запросы и какие ресурсы ссылаются на этот сайт, оценивать популярность страниц. По файлам ошибок проще найти источник проблемы и оперативно устранить баги и сбои. Журналы сервера (server logs) облегчают контроль рабочего процесса серверной машины.
В файлах логов записывается и отслеживается история работы всего программного комплекса. Поэтому специалисты рекомендуют периодически просматривать их, даже если никаких подозрительных моментов не произошло. И тем более немедленно обратиться к ним, если резко возросло количество ошибок, посыпался спам или заметно увеличилась нагрузка на сервер.
Типы логов и где их найти
Месторасположение логов зависит от используемого ПО, настроек, прописанного админом пути. Чаще всего server logs сохраняются в var/log/. Однако, не все сервисы помещают файлы регистрации в эту директорию. В любом случае, можно уточнить такую информацию у веб-хостера.
У дистрибутивов Linux CentOS или Fedora логи серверной машины лежат в /var/log/. Там можно найти:
Лог ошибок MySQL ($hostname.err) хранится в /var/lib/mysql/. Для Debian или Ubuntu местоположение логов аналогично, за исключением log file ошибок MySQL: /mysql/error.log. А также – логи веб сервера Apache сохраняются по пути /var/log/apache2.
У ОС Windows дружной метод структурирования log-файлов. События делятся на несколько уровней:
Их можно отсортировать или отфильтровать и выбрать необходимое. 
Запуск и отключение логов осуществляется с административной панели. Как правило, доступ через раздел «журнал» или «логи». При этом стоит учитывать, что файлы не сохраняются годами. Поэтому, при необходимости посмотреть log, это нужно сделать своевременно.
Какая информация хранится в логах и как ее интерпретировать?
Для большинства пользователей содержимое log-файлов это бессмысленный набор символов. Как читать логи, чтобы понять, что в них зашифровано?
Строка access.log сервера содержит:
Как правило, такой информации достаточно, чтобы проанализировать ситуацию и сделать нужные выводы. Например, заблокировать бота, который создал чрезмерную нагрузку на сайт.
Файл ошибок (error.log) регистрирует моменты, когда что-то пошло не так. Из них можно узнать:
Конечно, даже после расшифровки, данных логов еще нужно проанализировать. Для этого существует различное ПО, которое помогает отрабатывать данные из логов – Weblog Expert, WebAlyzer, Analog, Webtrends, Awstats, SpyLOG Flexolyzer и другие платные и бесплатные программы.
НАС ВЫБРАЛИ БОЛЕЕ 1000 КЛИЕНТОВ!
Нам доверяют свои проекты более 50 человек каждый день!
Лог: что это, зачем нужен и где его найти?
Зачем нужны лог файлы?
В некоторых ситуациях каждому пользователю ПК или сервера требуется проверить логи. Рассмотрим зачем именно нужны лог файлы.
1. Логи могут понадобится, если нужно узнать статистику по сайту. Например, логи сайтов отображают следующую информацию:
а) статистику посещаемости
б) точки входа и выхода с сайта
в) поисковые запросы, по которым приходят посетители, и наиболее популярные страницы сайта
г) поисковики, страны и браузеры посетителей
д) уровень конверсии и страницы сайта, которые никто не посещает
е) сайты, которые ссылаются на этот ресурс.
2. В случае вирусов или Дддос атаки на сайт, логи помогут быстрее выяснить причину и соответственно помочь устранить ее.
3. Для восстановления доступов испольузются логи авторизации, которые собирают данные о попытках входа.
4. В случае ошибок в работе определенного ПО, устройства или ОС, когда необходимо определить источник проблемы.
Логи (server logs) помогают контролировать работу серверной машины и в случае возникновения ошибок быстро их находить и устранять. Логи используются практически везде, где ведется запись и прослеживание истории программного процесса. В первую очередь это необходимо в целях безопасности. Для того, чтобы найти и проанализировать логи, используют специально предназначенное для этого ПО. Некоторые логи могут обладать очень большим размером, поэтому время от времени их нужно очищать. Лог файл показывает события и его непосредственный источник. Причиной события может быть:
Какие есть виды логов?
На практике видов логов может быть несколько. Рассмотрим каждый из них.
Как найти логи?
Место, где находятся логи зависит от используемого ПО, заданных настроек и пути, который заведомо установил администратор сервера.
Если вам нужно найти лог файлы сервера или хостинга, вы можете обратится и получить подробную консультацию у вашего хостинг-провайдера, где размещается ваш сайт.
Названия файлов: журнал ошибок – error.log; журнал доступов – log; основной журнал – syslog; журнал загрузки системы – dmesg.
В ОС Windows свой способ структуризации логов, в котором выделяют уровни событий: подробности; сведения; предупреждение; ошибка; критический. Пользователь может сортировать и фильтровать записи, в зависимости от того, что именно ему нужно.
Что делать с логами?
Лог файлы могут понадобится во многих ситуациях при работе с сайтов, ПК или сервером. Но обратите внимания, что логи не хранятся вечно, поэтому если появилась необходимость проверить их, то следует это делать своевременно. Например, часто хостинг-провайдеры хранят логи до 14 дней, а далее они удаляются и записываются новые. Поэтому если ваш сайт взломали более нескольких недель назад, то установить причину по логам не получится, если логи уже удалены.
Даже беглый анализ логов может помочь выяснить причины чрезмерной нагрузки на сайт, поэтому если вам нужна помощь, чтобы разобраться с логами и исправить возникшие ошибки работы сервера, обращайтесь в техническую поддержку ГиперХост.
Включение и выключение записей логов на сервере происходит в панели управления. В большинстве случаев эта функция доступна в разделе панели Журнал или Логи. Более детально об этом вы можете уточнить непосредственно у вашего хостера.
Как мы работаем с логами (сбор, хранение, анализ при помощи Graylog)
Всем привет! В этой статье мы хотим поделиться нашим опытом использования полезной платформы Graylog, которая ежедневно помогает собирать, надежно хранить и анализировать логи с десятков серверов, окутанных заботой нашей поддержки 🙂
Это первая часть статьи, в которой мы собрали в одном месте информацию, которая поможет установить и настроить Graylog, плюс, расскажем почему мы остановились имено на этой платформе.
Вторая часть, которая появится совсем скоро, будет содержать примеры использования и их реализацию.
Какую задачу мы решали?
Можно долго рассуждать о важности серверных логов и привести много примеров ситуаций, в которых они жизненно необходимы, но так как речь пойдет именно о сторонней системе и ее особенностях, то выделим ряд важных моментов:
Удобно, когда все логи хранятся в одном месте.
Круто, когда есть отчеты и возможность автоматически их проанализировать.
Полезно, когда логи можно посмотреть даже при “упавшем” сервере или после того как злоумышленник “прибрался” за собой.
Бесценно, когда о возникшей ошибке в логах будет оповещение.
Сформулировали задачу так:
“Подобрать бесплатное open source решение для сбора и анализа логов, не перегруженное функционалом, производительное, простое в установке и использовании.”
Почему Graylog?
Это не единственная и, возможно, далеко не самая лучшая платформа, но она широко распространена, прошла проверку временем и все еще поддерживается разработчиками.
Но, начать мы решили с анализа “конкурентов”.
Альтернативы
Splunk
Классный, модный, современный Splunk соответствует подавляющему большинству потребностей и скорее всего, может даже больше.
Но есть три момента, которые не понравились:
В нужной конфигурации решение платное.
Это закрытое решение.
Компания, без объяснений причин покинула рынок РФ.
Но, если вас это не смущает, немного полезной информации по платформе:
С этим “претендентом” не получилось, идем дальше.
Например, тут и тут его часто сравнивают с ELK, который и рассмотрим.
Что же пошло не так?
Некоторые фишки все же платные, например, уведомления и контроль доступа (однако, после некоторых событий часть данного функционала стала бесплатной).
Систему сложно настроить, “из коробки” она работать не будет.
Еще нужно упомянуть Open Distro, которая развивается на базе ELK, но полностью бесплатная, что не отменяет ресурсоемкость и сложность в настройке.
Немного полезной информации:
Инструкция по установке и настройке (eng).
Остановились на Graylog
Это open source решение.
Бесплатная версия имеет все необходимое.
Функционал небольшой, что удобно, ничего лишнего (для наших задач).
“Из коробки” решение уже работает, нужны минимальные настройки.
По сравнению с ELK ресурсоемкость значительно ниже.
Далее, мы предлагаем лонгрид по настройке и установке Graylog.
Установка и базовые настройки Graylog
В примере используем CentOS 8.
Prerequisites
Обновления обязательны, также установим пакеты для удобства работы, top-ы, etc.
смотрим где лежат сертификаты (пока самоподписанные)
кладём crt и key файлы в /etc/cockpit/ws-certs.d/
Firewall
(настройки будут индивидуальными для вашей сети, все команды даны для примера)
Кокпит должен быть доступен только админам, снаружи ему делать нечего. Создадим зону для интранета и добавим нужные адреса подсетей:
После добавления/удаления перезагрузим сервис:
Проконтролируем, что все правила верные:
SELinux
(настраиваем, а не отключаем его. )
Устанавливаем пакеты, если ещё не установлены, разрешаем апачу подключения:
Проверяем порты 9000, 9200, 27017:
Elastic Search
Импортируем ключ репозитория, добавляем конфигурационный файл репозитория, устанавливаем (вместо vim можно использовать nano, mcedit или любой другой редактор по вашему выбору):
Чтобы Elasticsearch работал с Graylog, необходимо установим имя кластера “graylog”:
Запускается довольно долго, в зависимости от конфигурации сервера или виртуальной машины. Проверяем:
Файлы Elasticsearch расположены здесь:
MongoDB
Добавляем конфигурационный файл репозитория:
Файлы MongoDB расположены здесь:
Graylog
Ссылки на оригинальную документацию:
Graylog не запускается самостоятельно (об этом есть сообщение в процессе установки).
Сначала настраиваем, потом пробуем запускать.
Генерируем хеш пароля:
Параметры эластика только для первого запуска, дальше конфигурация будет производиться уже из веб-интерфейса грейлога:
Также полезно будет настроить Email transport:
Download files → В секции GeoLite2 City → Get Permalinks (1, 2)
В Services → Manage License Keys (3)
Нажимаем «Generate new license key» создастся новый License Key. На email придёт уведомление о создании ключа.
Лицензия активируется в течение 5 минут.
Подставляем в ссылки, полученные на первом шаге ключ, полученный на втором шаге, загружаем файл с базой и файл контрольной суммы:
Проверяем целостность архива:
Установка GeoLite2 Database выполнена.
Немного ждём, затем смотрим логи запуска:
Возникают из-за того что установлена версия Enterprise, но нет соответствующей лицензии.
Заходим браузером, проверяем что веб-интерфейс доступен, можем залогиниться в веб-интерфейс:
Нас встречает мини-учебник по настройке:
NGINX
Создаём конфиг nginx, размещаем файлы сертификатов в /etc/nginx/ssl (у нас будут в одном файле сертификат + ключ):
Если получили ошибку:
То это из-за SELinux. Исправляем:
Немного реконфигурим Graylog:
Теперь Graylog слушает только на локалхосте, если открывали порт 9000, то необходимости в нём больше нет:
Размер БД
Установим размер индекса, так как виртуальный сервер имеет ограниченный объём диска.
System → Indices → Default index set → Edit
В Index Rotation Configuration:
В Index Retention Configuration:
Итого общий размер индексов будет не более 32GiB
Подведем итоги
Если вы дочитали и все еще с нами, то на этом закончим первую часть, где мы разобрали чем нам приглянулся Graylog и как можно его установить / настроить.
Надеемся, что наш опыт будет вам полезен.
Вопросы в комментариях приветствуются 🙂
Во второй части мы расскажем, как используя Graylog можно собирать системные логи и логи веб-сервера.
Дата-центр ITSOFT — размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.
Собираем, парсим и отдаём логи с помощью Logstash
Так уж сложилось, что по долгу работы мне приходится много времени уделять логам. Это и участие в выработке правил и политик сбора/хранения/использования логов, это и разбор разных инцидентов и обнаружение аномалий. За сутки наши программы, сервисы и серверы генерируют ОЧЕНЬ большое количество логов. И потребность копания в логах растёт постоянно.
Мне довелось поработать с коммерческими лог-менеджмент продуктами типа ArcSight, RSA Envision, Q1 Labs. У этих продуктов есть как плюсы, так и минусы. Но в статье речь пойдёт не о них.
Речь будет о Logstash.
Что же такое Logstash? Зачем он нужен? Что он умеет?
Logstash — это орудие для сбора, фильтрации и нормализации логов. Оно является бесплатным и open source приложением. Тип лицензии Apache 2.0.
Первой моё знакомство с LS (Logstash) произошло более года назад, и с того времени я очень плотно на него подсел. Мне нравится его идея и возможности. Для меня Logstash — это подобие мясорубки. Неважно что заходит в неё, но после не сложных манипуляций, на выходе всегда красиво и понятно оформленная информация.
Формат конфигурационного файла Logstash’а прост и понятен. Он состоит из трёх частей:
Входных, фильтрующих и выходных (или выходящих?) блоков может быть любое количество. Всё зависит от ваших потребностей и возможностей железа.
Пустые строки и строки начинающиеся с # — Logstash игнорирует. Так что комментирование конфигурационных файлов не вызовет никаких проблем.
1. INPUT
Пример конфигурации, для работы с локальными лог-файлами:
Построчное описание настроек:
тип/описание лога. При использовании нескольких входных блоков, удобно их разделять для последующих действий в filter или output.
указывается путь к лог-файлам, которые подлежат обработке. Путь должен быть абсолютным (/path/to/logs/), а не относительным (../../some/other/path/).
исключает из обработки файлы с соответствующими расширениями.
ждёт появления новых сообщений в конце файла. При обработки уже имеющихся логов, можно выставить «beginning», тогда обработка логов будет происходить построчно с начала файлов.
как часто (в секундах) проверять файлы на изменения. При больших значения, уменьшится частота системных вызовов, но так же увеличится время чтения новых строк.
время (в секундах) через которое будет обновлён список обрабатываемых файлов указанных в path.
Пример конфигурации, для работы с логами удалённых сервисов:
Построчное описание настроек:
тип/описание лога.
время (в секундах), по истечении которого не активное tcp соединение будет закрыто. Значение -1 — соединение всегда будет открыто.
в этом случае Logstash становится сервером, и начинает слушать на 192.168.3.12:3337. При установке mode => «client» Logstash будет присоединятся к удалённому ip:port для забора логов.
2. FILTER
В данном блоке настраиваются основные манипуляции с логами. Это может быть и разбивка по key=value, и удаление ненужных параметров, и замена имеющихся значений, и использование geoip или DNS запросов для ип-адресов или названий хостов.
На первый взгляд применение фильтров может показаться сложным и нелогичным, но это не совсем так.
Пример конфигурационного файла для основной нормализации логов:
Построчное описание настроек:
тип/описание лога. Здесь надо указать тот тип (type), который прописан в блоке input для которого будет происходить обработка.
путь к каталогу, содержащим шаблоны обработки логов. Все файлы находящиеся в указанной папке будут загружены Logstash, так что лишние файлы там не желательны.
указывается шаблон разборки логов. Шаблон можно использовать либо в конфигурационном файле, либо из файла шаблонов. Что бы не путаться, я для каждого формата логов создаю отдельный шаблонный файл.
С помощью grok фильтра можно структурировать большую часть логов — syslog, apache, nginx, mysql итд, записанных в определённом формате.
Logstash имеет более 120 шаблонов готовых регулярных выражений (regex). Так что написание фильтров для обработки большинства логов не должно вызвать особого страха или недопонимания.
Формат шаблонов относительно простой — NAME PATTERN, то есть построчно указывается имя шаблона и ему соответствующее регулярное выражение. Пример:
Можно использовать любой ранее созданный шаблон:
Шаблоны можно так же и комбинировать:
Допустим формат логов у нас следующий:
55.3.244.1 GET /index.html 15824 0.043
Среди готовых шаблонов, к счастью уже имеются некоторые регулярные выражения и не надо придумывать колёсное транспортное средство, приводимое в движение мускульной силой человека через ножные педали или через ручные рычаги (это я про велосипед если что).
С данным примером лога достаточно pattern записать в виде «%
После обработки наша строка будет выглядеть следующим образом:
client: 55.3.244.1
method: GET
request: /index.html
bytes: 15824
duration: 0.043
Со списком готовых grok-шаблонов можно познакомиться здесь.
Пример конфигурационного файла для изменения/удаления записей из логов:
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
удаление всех данных имеющих название поля client. Возможно указание нескольких названий полей.
переименование название поля HOSTORIP в client_ip.
замена всех «/» на «_» в поле messages.
добавление нового поля «sample1» со значением «from %
Пример конфигурационого файла:
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
временная метка события. Важная настройка для дальнейшей возможности сортировки или выборки логов. Если в логах время указано в unix timestamp (squid), то следует использовать match => [ «timestamp», «UNIX» ]
Пример конфигурационного файла для обработки логов в формате key=value:
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
использовать символы «=» и «:» для разделения ключа-значения.
название поля в котором искать ‘ключ=значение’. По умолчанию разбивка будет происходить для всей строки лога.
использовать символы «\t?&» для разделения ключей. \t — знак табулятора
Пример конфигурационного файла для «склеивания» многострочных логов (например Java stack trace):
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
при соответствии шаблону «pattern» строка принадлежит предыдущей (previous) строке.
3. OUTPUT
Пример конфигурационного файла для вывода логов в standard output:
указывается формат исходящего сообщения. Допустимо использование переменных после grok-фильтрации.
Пример конфигурационого файла для записи логов в файл:
интервал записи исходящих сообщений. Значение 0 будет записывать каждое сообщение.
файл исходящих сообщений будет сжат Gzip.
путь и название файла куда будут сохраняться исходящие сообщения. Можно использовать переменные. В данном примере, для каждого уникального IP адреса будет создана своя папка и сообщения будут записываться в файл соответствующий переменной %
формат исходящего сообщения.
Пример конфигурационного файла для записи логов в базу Elasticsearch:
название кластера указанного в cluster.name в настроечном файле Elasticsearch.
указывает какую базу Elasticsearch использовать внутреннюю или стороннюю.
транспортный port Elasticsearch.
IP адрес Elasticsearch
название индекса куда будут записываться логи.
Данный плагин можно использовать для алертов. Минус в том, что любые изменения уведомлений (в принципе как и любых других настроек) требуют перезапуск logstash программы, но разработчик говорит, что возможно в будущем этого не придётся делать.
Пример конфигурационого файла:
если у вас хватило сил дочитать до этих строк, значит вы можете сами определить смысл этих 3х настроек 🙂
тема письма уведомления. Можно использовать переменные. Например %
способ отсылки письма. Возможен один вариант из двух — smtp или sendmail.
стандартные настройки почтовых параметров.
«response errors» — название алерта (записывается в переменную %
4. Итого
Создаём файл habr.conf:
В новом терминальном окне пишем:
echo «Logs are cool!» | nc localhost 11111
Смотрим результат в окне где запущен Logstash. Если там появилось секретное послание, значит всё работает.