3csyslog для windows 10 x64

3csyslog для windows 10 x64

Программа 3CSyslog от известной компании 3Com является полноценным эмулятором юниксового демона syslogd для Windows-систем, предназначенного для сбора syslog-сообщений от сетевых устройств различных производителей, поддерживающих данный формат сообщений. То есть, фактически, является полноценным syslog-сервером, предоставляющим ту же функциональность, что и syslogd в операционных системах семейства Unix.

Программа имеет простейшие настройки: 1) вкладка Security Settings позволяет указать с каких адресов разрешается получение syslog-сервером сообщений (любые устройства в сети или только определенные IP-адреса); 2) вкладка Log File Destination позволяет указать месторасположение файла журнала (в который будут записываться все получаемые сообщения) и структуру файла журнала (будут ли сообщения записываться в один единый файл, или файлов журнала будет несколько и структура их будет формироваться по типам сообщений, важности или IP-адресу устройств).

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

Syslog 3.2

Что нового в Syslog 3.2:

The algorithm of version 3.1 was rather slow. It’s been optimized.

Отзывы о Syslog

» Оставьте первым свой отзыв об этом приложении.

Обзор

3CSyslog это программное обеспечение Shareware в категории (2), разработанная 3CSyslog.

Проверяли обновления 31 раз пользователями нашего клиентского приложения UpdateStar в прошлом месяце.

Последняя версия 3CSyslog в настоящее время неизвестна. Первоначально он был добавлен в нашу базу данных на 30.10.2007.

3CSyslog работает на следующих операционных системах: Windows.

3CSyslog не был оценен нашими пользователями еще.

Источник

3csyslog для windows 10 x64

Moder » 03 апр 2014, 14:40

И так, есть ресивер, на котором запущен плагин для работы с картой или шурой, статическими ключами и т.п.
Это может быть Dreambox, Optibox, Octagon, Vu+, Azbox и другие ресивера.
Нужно посмотреть корректность работы плагина, получает ли ресивер ключи, отвечает ли карта, дает ли сервер ответ, т.е. хоть как-то выяснить когда что-то не так работает как запланировано.

1. Просмотр прямо на ресивере через TELNET.
Пример на базе Dreambox500s с установленным wicardd.
Запускаем любой telnet клиент, например putty .
Вводим IP ресивера, выбираем telnet и нажимаем Open.

И смотрим онлайн лог.

Не очень удобный, но довольно простой способ.
Ниже будут и другие варианты просмотра лога работы эмулятора.
Пароли к файлам: bazahdtv

Просмотр лога ЭМУ с помощью 3CSyslog

Moder » 04 апр 2014, 16:33

2. Просмотр лога ЭМУ с помощью 3CSyslog.
Это, наверное, один из самых популярных и самый простой способ просмотра лога по UDP протоколу, рекомендую всем им пользоваться!
И так есть ресивер подключенный к сети Ethernet и в этой же сети находится компьютер на котором будем смотреть лог работы эмулятора.
Первое что должно быть настроено в ресивере, это нужно указать эмулятору (плагину) куда ему отправлять лог своей работы. В нашем случае нужно его направить на компьютер с определенным IP адресом. Т.е. мы должны знать IP адреc нашего компьютера! Его можно посмотреть через сведения о сетевом подключении, к примеру возьмем его — 192.168.1.123 , в вашем случае он будет скорее всего другой и нужно подставлять именно IP адрес вашего компьютера. Теперь вносим его в конфигурационный файл эмулятора, в зависимости какой установлен это выглядит так:

для Wicardd:
в конфигурационный файл — wicardd.conf
в секцию [global], нужно внести строку — log_udp = 192.168.1.123:514, (для старых версий было — log = 192.168.1.123)
выглядеть она будет приблизительно так:
[global]log_udp = 192.168.1.123 :514
debug = 1 #0- нет лога, 1 — минимальный, 2 и 3 расширенный и полный лог

для mgcamd:
меняем файл — mg_cfg
# 00 Off (default)
# 01 Network
# 02 console
# 03 both
L: < 01 >192.168.1.123 514

для camd3:
файл camd3.config
# Log(optional): 0 — keine Ausgaben, 1-Datei, 2 — Console, 4 — UDP(syslog), 3 — Console+Datei, 5 — UDP+Datei, 6 — UDP+Console, 7-UDP+Console+Datei; Default ist 2;
LOG=4
# Host fьr UDP-logging
LOG_HOST=192.168.1.123
# Port fьr UDP-logging(optional); Default ist 514
LOG_PORT=514

для evocamd:
файл camd_cfg
# To use UDP log
# 00 disabled
# 01 enabled
L: < 00 >192.168.1.123 514

для gbox:
файл gbox_cfg
# Trace/Debug
# xx yz ; xx=00 no konsole output
# xx yz ; xx=01 konsole output
# xx yz ; y=0 debug output (don’t use)
# xx yz ; y=1 no debug output
# xx yz ; z=0 ouput to konsole
# xx yz ; z=1 output to /var/tmp/debug.txt
# xx yz ; z=2 Output to UDP (to capture with gboxt)
Z: < 00 12 >192.168.1.123 514

Вносите изменения в файл конфигурации и делаете перезапуск эмулятора.
Теперь необходимо на компьютере запустить программу 3CSyslog, можно не делать никаких дополнительных настроек. Если все правильно сделано, то будет виден лог работы эмулятора. Если его нет возможно включен фаервол, попробуйте его отключить.
Есть также не большая програмка, с помощью которой можно проверить и саму программу — 3CSyslog.
Называется — MGCAMD_LOG_client .
Запускаете его сначала на том же компьютере и посылаете текст на IP адрес своего же компьютера, в программе логгер (3CSyslog) получите данное сообщение. Потом запускаете эту программу с другого компьютера, посылаете сообщение на свой компьютер, если сообщение доходит, то с сетью все в порядке, ищите проблему или правильность настройки в ресивере.
Пароли к архивам — bazahdtv

Re: Как посмотреть лог эмулятора Wicardd, mgcamd и др.

Moder » 05 апр 2014, 12:54

3. Подборка различного софта для снятия лога, пробуйте, может кому да и понравится.
Мне понравился — Openbox MgCamd Explorer.
Пароль на архивы — bazahdtv

Источник

Открытое решение Graylog. Cбор и анализ событий в сетях промышленных масштабов

Задача сбора и анализа всевозможных журналов с множества машин в подконтрольной системному администратору сети существует столько же, сколько компьютерные сети как таковые. За это время заметно эволюционировали (и революционно выросли в объеме) как сами собираемые данные, так и инструменты сбора

Проверенные временем программы типа rsyslog и syslog-ng по-прежнему популярны, однако сами по себе они уже не удовлетворяют всех потребностей (в первую очередь в плане анализа данных) и часто используются как компоненты более сложной инфраструктуры.

Одним из примеров подобных комплексных решений является Graylog – инструментарий централизованного сбора, хранения и анализа данных о различных событиях на серверах локальной сети.

В данной статье мы с вами рассмотрим стабильную ветку Graylog 2.x и последнюю версию из этой ветки 2.5.1.

Параллельно развивается ветка 3.x, но на данный момент она рекомендуется только для использования энтузиастами.

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

Установка

Graylog предлагает множество вариантов установки:

• пакеты для CentOS 6/7, Debian 7/8/9, Ubuntu и производных;
• скрипты развертывания с помощью Chef, Puppet, Ansible и файлы для Vagrant;
• готовые образы виртуальных окружений для Open-Stack, EC2, Docker и любых средств виртуализации, понимающих формат OVA;
• наконец, можно просто скачать архив с файлами приложения и развернуть его на любой системе согласно инструкциям.

Установка с помощью образа ВМ наиболее проста (например, для знакомства мы изначально ставили Graylog в виртуальную машину Virtuozzo Infrastructure Platform), однако не рекомендуется к реальному использованию – мощностей ВМ может и не хватить для обработки реальных данных. Поэтому в данной статье мы рассмотрим установку Graylog из пакетов RPM на машине под управлением Virtuozzo 7 – для нее вполне подойдут пакеты от CentOS.

Перед установкой самого Graylog, необходимо установить необходимые ему компоненты: Java, MongoDB и Elasticsearch. Первую можно поставить из репозиториев системы, а другие – непосредственно из репозиториев производителей:

# yum install java-1.8.0-openjdk
# yum install https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64/RPMS/mongodb-org-server-4.0.5-1.el7.x86_64.rpm
# yum install https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.5.4.rpm

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

В большинстве случаев эти сервисы MongoDB и Elasticsearch в дополнительной настройке не нуждаются, можно их сразу запустить и добавить в список сервисов, включаемых при старте системы:

# systemctl enable mongod elasticsearch
# systemctl start mongod elasticsearch

Больше мы к этим сервисам возвращаться не будем, желающих же детальнее узнать про Elasticsearch отправим к статье [1].

Для установки сервера graylog, необходимо сначала добавить репозиторий посредством установки пакета graylog-2.5-repository_latest , а затем уже поставить сам пакет graylog-server :

# rpm -Uvh https://packages.graylog2.org/repo/packages/graylog-2.5-repository_latest.rpm
# yum install graylog-server

Обратите внимание, что в рамках ветки 2.5 вы сможете обновлять пакеты graylog с помощью стандартной команды yum update , однако для перехода даже на ветку 2.6 (если такая появится) либо 3.0 надо будет подключать отдельные репозитории и следовать инструкциям по обновлению, поскольку такой переход может потребовать ручной адаптации конфигурационных файлов.

После установки пакетов необходимо внести правки в файл конфигурации /etc/graylog/server/server.conf – в варианте по умолчанию он работать не будет.

В частности, необходимо заполнить поля password_secret («соль», которая будет использоваться при шифровании паролей пользователей) и root_password_sha2 – хеш-сумма пароля для входа в веб-интерфейс под пользователем admin .

Хеш-сумму пароля необходимо вычислить с помощью sha256sum :

# echo -n «ваш_пароль» | sha256sum

А password_secret рекомендуется сгенерировать с помощью утилиты pwgen – его длина должна составлять как минимум 64 символа:

Также есть смысл настроить параметры rest_listen_uri и web_listen_uri , чтобы иметь возможность заходить в веб-интерфейс и использовать API с других машин – по умолчанию эти параметры выставлены в «127.0.0.1».

Опционально можно указать сертификат для доступа к веб-интерфейсу и API по протоколу https.

Когда все настройки завершены, можно включать и запускать сервис graylog-server :

# systemctl enable graylog-server
# systemctl start graylog-server

Спустя непродолжительное время на указанном вами в файле конфигурации адресе на порту 9000 (если вы не изменили его в конфигурации) станет доступен веб-интерфейс Graylog.

Если этого не случилось – загляните в файл /var/log/graylog-server/server.log , в котором Graylog сообщает обо всех неполадках.

Если же все прошло успешно, то можно начинать работу по настройке сбора данных с ваших серверов.

Настраиваем сбор журналов

Для первого входа в веб-интерфейс Graylog используйте пользователя admin и пароль, хеш-сумму которого вы указали в файле конфигурации. В дальнейшем в меню System можно создать новых пользователей во внутренней базе Graylog, настроить интеграцию с LDAP, Active Directory и другими внешними механизмами аутентификации.

Для начала же перейдем к непосредственным обязанностям сервиса и настроим извлечение логов rsyslog по протоколу TCP с одной из Linux-машин под управлением Virtuozzo.

Первым делом необходимо настроить сам rsyslog для передачи данных в Graylog. Делается это созданием нового файла в директории /etc/rsyslog.d со следующей строкой:

Надо также убедиться, что порт 514 на сервере Graylog доступен с этой машины. Кроме того, порт должен быть доступен самому Graylog, который работает с правами непривилегированного пользователя и по умолчанию не имеет доступа к портам диапазона от 1 до 1024. Решить эту ситуацию можно перенаправлением данных на сервере Graylog с порта 514 на непривилегированный порт, например 1514:

# iptables -t nat -A PREROUTING -p tcp —dport 514 -j REDIRECT —to 1514

После этого можно возвращаться в веб-интерфейс Graylog и переходить в меню System → Inputs , где настраиваются источники входящих данных. При создании нового источника необходимо выбрать его тип – набор доступных возможностей впечатляет (и может расширяться с помощью плагинов), нас в данный момент интересует Syslog TCP (см. рис. 1).

Рисунок 1. При добавлении источника данных, необходимо выбрать один из предопределенных типов

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

После сохранения настроек можно нажимать кнопку Launch new input для активации источника – если Graylog сможет получить данные, новый источник перейдет в состояние Running и вы увидите статистику получаемых данных (см. рис. 2).

Рисунок 2. Для каждого источника можно посмотреть статистику данных и просмотреть все сообщения

На этой же странице можно перейти к просмотру всех полученных от источника сообщений, нажав кнопку Show received messages .

Поиск и анализ данных

Кнопка показа сообщений от источника ведет на страницу поиска и фильтрации сообщений. Возможности поискового механизма очень богаты и подробно описаны в документации [2], при переходе же со страницы источника поиск уже настроен на отображение сообщений только от него.

Страница поиска отображает как собственно перечень сообщений, так и график со статистикой их получения. Результаты поиска можно сохранить, а также сделать доступными в виде отдельного элемента на одной из панелей вкладки Dashboards .

Более точно: на вкладку Dashboards можно вынести информацию об общем количестве сообщений, удовлетворяющих выбранному критерию (кликнув на кнопку Add count to dashboard ), а также график интенсивности получения сообщений во времени (кнопка Add to dashboard в правом верхнем углу соответствующей гистограммы).

В итоге на панелях Dashboards вы сможете оперативно отслеживать сразу множество интересных вам различных показателей.

Сообщения в Graylog не просто отображаются «как есть», но подвергаются дополнительному анализу – из них по возможности извлекаются имя пославшей сообщение программы, степень критичности и ряд других типичных показателей. На основе этих характеристик можно производить дополнительную фильтрацию – например, отображать только сообщения заданной программы либо только критические ошибки.

Graylog хорошо справляется с подобным разбором стандартных сообщений от того же rsyslog, а для нестандартных данных предлагает настроить свои собственные анализаторы.

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

Извлекать данные можно с помощью регулярных выражений, шаблонов Grok или простых операций со строками. Более того, можно преобразовывать извлеченные строки к определенным типам данных (например, к целым числам), чтобы их можно было сравнивать подобающим образом.

В окне создания анализатора вам предложат сразу посмотреть на результат применения вашего экстрактора к произвольной строке.

Graylog умеет самостоятельно разбирать ряд типичных сообщений – например, строк в формате переменная=значение или сообщений в формате JSON – и сохранять их элементы в поля с соответствующими названиями.

Например, если в вашем сообщении есть следующая JSON-строка:

то Graylog превратит ее в два поля, error_severity и e rror_message , со значениями critical и crash соответственно.

Потоки сообщений и нотификации

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

Для фильтрации сообщений Graylog предоставляет механизм потоков ( Streams ), создание и настройка которых доступны в одноименном пункте главного меню веб-интерфейса. Каждый поток содержит сообщения, удовлетворяющие определенному критерию – как правило, используется фильтрация по ключевым словам.

По умолчанию в Graylog уже создан один поток – All messages , – содержащий все входящие сообщения. Наличие хотя бы одного потока необходимо, поскольку именно к ним привязываются механизмы оповещения ( Alerts ) системных администраторов об интересующих их событиях. Настраиваются оповещения в меню Alerts , и для каждого из них надо определить поток анализируемых сообщений и условие срабатывания.

Типичными условиями является появление сообщений с заданным текстом либо слишком частое повторение некоторых сообщений в течение определенного промежутка времени. Для примера настроим оповещение на случай, когда сообщений просто становится слишком много. Для этого при создании Alert укажем All messages в качестве потока и Message Count Alert Condition в роли условия.

После нажатия кнопки Add alert condition зададим конкретные условия (см. рис. 3) – период времени (в минутах), количество сообщений и Grace period – время бездействия после того, как условие генерации оповещения перестало быть истинным.

Рисунок 3. При выполнении определенных условий для потока входящих сообщений можно сгенерировать соответствующее оповещение

Механизм работы данного примера следующий: если в течение минуты мы получаем более 10 сообщений, то генерируется оповещение. Если в течение следующих десяти минут число сообщений нормализуется, то инцидент с превышением числа сообщений помечается как « разрешенный » ( Resolved ), если нет – то генерируется новое оповещение. Если бы мы выставили ненулевой Grace period , то Graylog дополнительно выжидал бы указанное время после разрешения инцидента перед новым анализом.

Само оповещение о произошедшем событии можно либо отправить на электронную почту, либо послать POST-запросом на указанный вами адрес.

После этого имеет смысл протестировать наше оповещение и сгенерировать на подконтрольных машинах относительно большое количество сообщений – хотя бы десяток за минуту. На вкладке Alerts overview должен появиться новый инцидент в состоянии Unresolved (см. рис. 4).

Рисунок 4. Если условие срабатывания оповещения перестает выполняться, то соответствующий инцидент переходит в состояние

После того как поток сообщений прекратится, инцидент перейдет в состояние Resolved .

Агенты Graylog

В примере с syslog мы настроили сам сервис на отсылку журналов на сервер Graylog. Однако далеко не все сообщения от ОС и приложений можно перенаправить таким образом, ведь многие программы просто записывают свои журналы в локальные файлы и не предусматривают возможности их отсылки куда-то еще штатными средствами.

На этот случай Graylog предоставляет возможность установить на каждую подконтрольную систему своих агентов, которые займутся сбором необходимой информации и отсылкой ее на сервер.

Агент состоит из двух частей – сервиса Graylog Collector Sidecar , общающегося с сервером (получающим от него параметры для сбора данных и отправляющим обратно собранную информацию) и бэкенда, непосредственно анализирующего файлы журналов системы. На данный момент пакеты агентов не входят в репозиториий graylog и необходимо их скачивать и устанавливать вручную с репозиториев github [3].

Начнем с Sidecar . На сайте имеются пакеты collector-sidecar в форматах deb и rpm, пригодные для установки в Debian, Ubuntu, CentOS и производных (в том числе для Virtuozzo 7). Для Windows предоставляется установщик collector_sidecar_installer.exe, который может работать как в интерактивном, так и в автоматическом режиме (параметр /S ).

После установки sidecar необходимо отредактировать файл /etc/graylog/collector-sidecar/collector_sidecar.yml (для Windows – C:\Program Files\graylog\collector-sidecar\collector_sidecar.yml ) – как минимум надо указать адрес вашего сервера Graylog и тэги, по которым надо выбирать конфигурацию сбора логов (об этом – чуть ниже).

В этом же файле осуществляется включение того или иного бэкенда – достаточно найти нужный в секции backends и выставить флаг enabled в true (а выставление флага в false бэкенд отключит).

Можно также разрешить отсылку на сервер метрик машины ( send_status ), включающих в себя некоторые характеристики системы типа использования диска и выставленные для sidecar тэги, а также периодическую отсылку листинга директорий машины ( list_log_files ). С помощью такой информации в веб-интерфейсе Graylog можно будет смотреть, какие файлы журналов доступны для агентов.

Для каждого бэкенда указан путь к его конфигурационному файлу – эти файлы генерируются автоматически на основе информации от сервера Graylog, редактировать их руками не надо.

Чтобы sidecar запускался как демон, необходимо установить и включить соответствующий сервис. В Virtuozzo и дистрибутивах Linux с systemd это делается следующими командами:

# graylog-collector-sidecar -service install
# systemctl start collector-sidecar
# systemctl enable collector-sidecar

$ «C:\Program Files\graylog\collector-sidecar\graylog-collector-sidecar.exe» -service install
$ «C:\Program Files\graylog\collector-sidecar\graylog-collector-sidecar.exe» -service start

Бэкенды Filebeat и Winlogeventbeat входят непосредственно в пакет collector-sidecar, nxlog же следует ставить отдельно c официального сайта [4]. При этом после установки необходимо отключить автоматический запуск сервиса nxlog – за его запуск и останов будет отвечать sidecar , отвечающий за перезапуск процессов сбора данных при любом изменении конфигурации, получаемой от сервера.

Сбор данных от агентов

Перед регистрацией агентов в Graylog необходимо в веб-интерфейсе зарегистрировать соответствующий источник данных ( Input ), в который агенты смогут посылать информацию.

При использовании Filebeat или Winlogeventbeat можно использовать тип источника Beats , для NXlog доступен только GELF (Graylog Extended Log Format) – собственный формат Graylog, созданный «по мотивам» syslog, но не имеющий его ограничений (в первую очередь на длину сообщения).

После создания источника можно идти в секцию System → Collectors → Manage Configurations для настройки конфигурации – правил сбора данных. Здесь при создании новой конфигурации сразу нужно выбрать вкладку, соответствующую бэкенду, который вы планируете использовать.

Первым делом укажите тэги – по ним демоны sidecar на конкретных машинах определяют, какую конфигурацию им использовать, просто сопоставляя тэги конфигурации с локальными настройками.

Далее в секции Output надо определить, куда отправлять данные (как правило, это сервер Graylog; однако вы можете развернуть несколько машин с Graylog с балансировкой нагрузки между ними – в таком случае здесь надо указать адрес балансировщика). Здесь же можно настроить разбор записей и формирование полей (фактически экстрактор).

Наконец, в секции Inputs задаются данные, которые необходимо собирать – как правило, это всевозможные файлы журналов. Веб-интерфейс позволяет в удобном виде задать наиболее популярные характеристики сбора информации (пути к журналам, время отсылки и так далее) и Graylog сам сгенерирует файл конфигурации бэкенда на основе этих данных. Однако вы можете указать непосредственно содержимое файла или его часть в поле snippet – это поле добавляется в генерируемый файл без изменений.

На этом все. Теперь агенты на подконтрольных машинах смогут найти конфигурацию по указанному тэгу и начать посылать данные.

В этой статье мы рассмотрели базовые сценарии использования Graylog. Установить и начать его применять несложно. При этом за внешней простотой скрываются гибкость настройки, мощные возможности фильтрации и анализа информации, а также производительность, позволяющая ежедневно обрабатывать терабайты данных. Освоиться со всем этим богатством поможет подробная и всеобъемлющая документация [2], к которой мы и отправляем всех заинтересовавшихся возможностями открытого инструмента, превосходящего многие коммерческие аналоги.

• Яремчук С. Настраиваем стек ELK для централизованного хранения журналов. // «Системный администратор», № 1-2, 2018 г. – С. 16-22. URL: http://samag.ru/archive/article/3575 .
• Документация Graylog – http://docs.graylog.org .
• Репозиторий Graylog Sidecar – https://github.com/Graylog2/collector-sidecar/releases .
• Официальный сайт NXlog – https://nxlog.co .

Ключевые слова: syslog, graylog, журналы, security.

Источник