Рубрика «syslog»

В этой статье я хотел поднять не стандартную для меня тему о сетевом маршрутизаторе VyOS. Впервые я познакомился с этим проектом благодаря Нилу Андерсону (Neil Anderson) который составил гайд как у себя дома развернуть мини-лабораторию с NetApp симулятором и VyOS.
VyOS OpenSource Router - 1

Ключевые проекты

VyOS это opensource проект на базе Debian Linux, который родился как форк от проекта Vyatta Core Edition of the Vyatta Routing software. Как и любой роутер VyOS оперирует на третьем уровне OSI и маршрутизирует North-South трафик. VyOS включает в себя следующие ключевые проекты:

  • Debian 8, ядро 4.19
  • FRRouting (в версии 1.1 и более древних использовался Quagga)
  • ISC-DHCP
  • Keepalived
  • StrongSwan
  • OpenVPN
  • PowerDNS
  • Wireguard
  • OpenNHRP
  • Accel-ppp
  • xL2tpd
  • Squid
  • mDNS-repeater
  • IGMP-Proxy
  • iPerf
  • более детальный список в Release notes

Читать полностью »

Как определить объем ваших логов? - 1

Добрый день!

Сегодня мы рассмотрим распространённый вопрос, с которым сталкиваются все, кто обрабатывает логи или собирается это делать и сейчас приценивается к различным решениям по обработке и хранению. Какой же объем логов в день/неделю/месяц мы будем получать из различных систем и какие ресурсы по хранению мы должны задействовать?
Однозначно точно сказать довольно сложно, но мы попробуем помочь вам примерно разобраться с предполагаемыми объемами, основываясь на нашем опыте.
Читать полностью »

В нашей компании имеется распределенная сеть продаж. Связь офиса с магазином обеспечивает маршрутизатор, на котором настроен VPN до центра. И вот, с определенного момента, эта связь стала крайне некачественной, из-за шквала пакетов по 53-му DNS порту. Связь хоть и улучшилась после введения блокирующих правил файрволла, но атаки не прекратились.

Я обратился к провайдеру, с просьбой решить проблему на его стороне. На что получил ответ вынесенный в заголовок: «Ну вы же понимаете, интернет — это грязное место». И тогда я решил бороться с этим явлением самостоятельно.

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

В результате почти двух месяцев работы, в систему поступило почти 200 миллионов записей. Большая часть (98%) — это атаки типа DNS amplification, которые не раз обсуждались на хабре [1], [2], [3]. Причем атаки начинаются не сразу, а по прошествии некоторого времени, достаточного для попадания нового публичного адреса в базу сканирующих интернет ботов. В оставшейся части событий выделяется большой сегмент атак на 23-й порт. Как я выяснил — это китайские DVR системы Hikvision, разбросанные по всему миру и сканирующих весь интернет на предмет telnet подключений. На трети из них, кстати, как раз заводские логин и пароль. А все остальное — это уже рукотворные переборы портов, попытки залогиниться, опросить по snmp и прочее.
Читать полностью »

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

Плохое и кошмарное

systemd-escape

Тот факт, что существует systemd-escape, сам по себе явно указывает на нечто ужасно неправильное. Если вы никогда не видели или не использовали эту команду в деле, считайте, что вам повезло.
Читать полностью »

image

изображение с сайта oxygen-icons.org

Задача

Передавать лог-файлы на центральный сервер. При недоступности сервера не терять сообщения, а накапливать и передавать при его появлении в сети. Корректно передавать многострочные сообщения.

Дополнительно:

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

Условия: в инфраструктуре используются только Linux-сервера.

Читать полностью »

Мониторинг системных вызовов Linux - 1

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

  1. Сколько уникальных исходящих TCP-соединений установили ваши серверы за последний час?
  2. Какие процессы и пользователи инициировали установку этих соединений?

Если вы в состоянии ответить на оба вопроса, отлично — дальше можете не читать. А если ответа нет, то получить эту информацию поможет go-audit.

Читать полностью »

OPSEC LEA (Log Export API) – интерфейс, позволяющий получать логи с сервера управления (Checkpoint SmartCenter).
В основе OPSEC LEA лежит клиент-серверная архитектура. В качестве сервера выступает Checkpoint SmartCenter, который слушает входящие соединения на порт 18184 ТСР (по-умолчанию). Клиент OPSEC LEA подключается к Серверу на вышеуказанный порт и получает логи.
Fw1-loggrabber – программное обеспечение, поддерживающее OPSEC LEA, и предназначенное для получения логов с серверов управления (Checkpoint SmartCenter – далее SC). Fw1-loggrabber может выводить полученные логи на экран, перенаправлять в файл или в syslog.
Существуют версии данного ПО как под Linux, так и под Windows (под windows не поддерживается вывод в syslog).
Дано:

  • Сервер управления Checkpoint. Версия ПО Checkpoint – R77.30 (sc.local);
  • Сервер с CentOS 6.6 (loggraber.local);
  • Syslog сервер (syslog.local).

Задача:

получить логи c SC и передать их по протоколу syslog на внешний syslog сервер.
Читать полностью »

Неотъемлемой частью сетевого мониторинга является сбор логов с контролируемых серверов и прочих железок. Ведь сколько бы мы ни создали отдельных элементов данных и триггеров к ним, в какой-то момент возникнет ситуация, что что-то важное мы упустили из виду и не контролируем. Итог: «У нас ничего не работает», а система мониторинга говорит, что все хорошо.

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

Как это сделать на серверах или компьютерах, где установлен заббикс-агент, многие знают — есть встроенные элементы данных log[], logrt[].

Но как быть, когда нужно собирать логи с сетевого оборудования, на которое никак не водрузить Zabbix-agent’а? Вообще-то можно, конечно, настроить syslog-сервер на том же ПК, на которой есть заббикс-агент, а дальше при помощи log[] переносить эти данные в заббикс. Вот только элементы данных и триггеры по нему будут прикреплены к узлу сети с заббикс-агентом, что интуитивно малопонятно. А можно ли прикрепить эти данные непосредственно к сетевому устройству? Можно.

Для этого нам понадобится zabbix_sender, Zabbix API и rsyslog на машине с заббикс-сервером или заббикс-прокси. В качестве бонуса также получим быстрый контекстный переход в журнал syslog-сообщений с карты сети.
Как будет выглядеть результат? Ну, примерно вот так:
Контекстный вызов:
Удобный мониторинг Syslog сообщений c сетевых железок в Zabbix - 1

Читать полностью »

Админская загадка: На сервере произошло три oom kill'а, а мониторинг сказал только про два. Почему?

Конфигурация

Для мониторинга всего у нас настроена связка ganglia-shinken-logstash-elasticsearch-kibana. Полное описание довольно обширно, так что ограничусь только частью, имеющей отношение к проблеме.

В logstash присылаются логи со всех серверов. Он их складывает в elasticsearch. В конфиге logstash'а настроена реакция на всякие странные сообщения, которые свидетельствуют о проблемах. Если сообщение появляется, присылается event мониторингу (shinken), который разными методами начинает беспокоить админов.

Помимо syslog'ов, которые шлют сообщения от большинства приложений, у нас настроена ещё и отправка netconsole от всех ядер. Сама технология проста до невозможности — ядро помимо dmesg'а посылает сообщения в виде UDP-датаграмм на указанный IP и mac-адрес. MAC-адрес нужен потому, что netconsole очень низкоуровневая и заниматься разгадыванием «как из IP сделать MAC» (то есть ARP) не собирается. Благодаря низкоуровневости сообщения проходят даже в ситуациях полного катаклизма. Например, если программный коммутатор перестал работать (и сеть недоступна), сообщения всё равно будут посылаться. Более того, они будут посылаться, даже если в iptables сказано -j drop_vsyo_nafig. И, самое главное и ценное, эти сообщения успешно будут отправлены, если дисковая подсистема полностью не работает. То есть для post-mortem исследований «что именно случилось с зависшим сервером» — самое оно.

Очевидным кандидатом в «плохие» сообщения является сообщение от oom-killer'а.

[517935.914380] ntpd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[517935.914730] Call Trace:
[517935.914807]  [<ffffffff816e14ce>] dump_header+0x83/0xbb
[517935.914877]  [<ffffffff816e155b>] oom_kill_process.part.6+0x55/0x2cf
...
с финальным торжествующим: 
[517935.951044] Out of memory: Kill process 4550 (apache2) score 247 or sacrifice child
[517935.951203] Killed process 4550 (apache2) total-vm:2610268kB, anon-rss:2012696kB, file-rss:3928kB

Итак, возвращаемся к загадке. Идёт пусконаладка, предпродакшен, как, вдруг, апач (точнее, wsgi-приложение) насасывается данных до неприличия, и его прибивают со словами «go be fat somewhere else». Админам приходит сообщение. Казалось бы всё хорошо (ну, в админском смысле «хорошо»). Но…

Случилось три oom'а, сообщения пришли о двух. Мониторинг в порядке, netconsole в порядке. Загадка? Проблемы? Симптомы таинственной неведомой фигни? Звать придворного шамана с бубном?
Читать полностью »

Если вы работали с syslog'ом, то знаете, что у него есть приложение logger, необходимое для логгирования каких-то действий от обычных пользователей. И если многие программы умеют работать с syslog'ом самостоятельно, то логгировать все действия пользователей — это не всегда простая задача.

Тем не менее, есть как минимум два способа это сделать с использованием bash.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js