Рубрика «syslog»
VyOS OpenSource Router
2019-01-31 в 0:58, admin, рубрики: 802.1Q, Accel-ppp, Alibaba Cloud, Amazon EC2, Ansible, BGP, BGP-peer, citrix xenserver, CloudPack, clustering, Conntrack-Sync, Debian, dell, DHCP Client, DHCP Server, DMVPN, EdgeCore, FRRouting, gateway, Google Cloud Platform, GRE, IGMP-Proxy, IP6IP6, iperf, IPIP, IPIP6, ipsec, IPSec VTI, IPSec/GRE, IPv4, IPv6, ISC-DHCP, isc-dhcp-server, junos, keepalived, kvm, l2tp, L2TPv3, L2TPv3 Router, lacp, layer 2, lldp, mDNS, mDNS-repeater, Microsoft Azure, Microsoft Hyper-V, netflow, Nutanix AHV, open source, OpenNHRP, opensource, openstack, openvpn, ospf, OSPFv3, Packet Cloud, Policy-Based Routing, powerdns, PPPoE server, PPTP, QinQ, quagga, Ravello, RHEV, rip, RIPng, saltstack, sFlow, SIT, site-to-site vpn, snmp, squid, ssh, strongswan, supermicro, syslog, tftp, TFTP Server, virtualbox, VLAN, VMWare ESXi, vpn, VPN Gateway, VPN RA, vrrp, vxlan, vyatta, vyOS, WAN load-balancing, wireguard, xL2tpd, Сетевые технологии, СофтВ этой статье я хотел поднять не стандартную для меня тему о сетевом маршрутизаторе VyOS. Впервые я познакомился с этим проектом благодаря Нилу Андерсону (Neil Anderson) который составил гайд как у себя дома развернуть мини-лабораторию с NetApp симулятором и VyOS.
Ключевые проекты
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
Как определить объем ваших логов?
2018-06-09 в 7:12, admin, рубрики: big data, Cisco, Palo Alto, splunk, syslog, wineventlog, Блог компании TS Solution, информационная безопасность, логи, Серверное администрирование, системное администрированиеДобрый день!
Сегодня мы рассмотрим распространённый вопрос, с которым сталкиваются все, кто обрабатывает логи или собирается это делать и сейчас приценивается к различным решениям по обработке и хранению. Какой же объем логов в день/неделю/месяц мы будем получать из различных систем и какие ресурсы по хранению мы должны задействовать?
Однозначно точно сказать довольно сложно, но мы попробуем помочь вам примерно разобраться с предполагаемыми объемами, основываясь на нашем опыте.
Читать полностью »
Грязное место провайдера: проект blondemine
2017-10-03 в 6:42, admin, рубрики: firewall, hacks, postgresql, syslog, Сетевые технологииВ нашей компании имеется распределенная сеть продаж. Связь офиса с магазином обеспечивает маршрутизатор, на котором настроен VPN до центра. И вот, с определенного момента, эта связь стала крайне некачественной, из-за шквала пакетов по 53-му DNS порту. Связь хоть и улучшилась после введения блокирующих правил файрволла, но атаки не прекратились.
Я обратился к провайдеру, с просьбой решить проблему на его стороне. На что получил ответ вынесенный в заголовок: «Ну вы же понимаете, интернет — это грязное место». И тогда я решил бороться с этим явлением самостоятельно.
В результате была собрана система сбора и анализа несанкционированных сетевых пакетов.
А чтобы не утомлять читателя техническими подробностями, самое интересное я расскажу сразу, а тем кто пожелает ее повторить или улучшить рекомендую дочитать до конца.
В результате почти двух месяцев работы, в систему поступило почти 200 миллионов записей. Большая часть (98%) — это атаки типа DNS amplification, которые не раз обсуждались на хабре [1], [2], [3]. Причем атаки начинаются не сразу, а по прошествии некоторого времени, достаточного для попадания нового публичного адреса в базу сканирующих интернет ботов. В оставшейся части событий выделяется большой сегмент атак на 23-й порт. Как я выяснил — это китайские DVR системы Hikvision, разбросанные по всему миру и сканирующих весь интернет на предмет telnet подключений. На трети из них, кстати, как раз заводские логин и пароль. А все остальное — это уже рукотворные переборы портов, попытки залогиниться, опросить по snmp и прочее.
Читать полностью »
SystemD отстой, да здравствует SystemD
2017-04-06 в 9:09, admin, рубрики: syslog, systemd, журнал, лог, Настройка Linux, Серверное администрирование, системное администрированиеКажется, что systemd — некое яблоко раздора в Linux-сообществе. Как будто не существует нейтральной точки зрения на systemd. Кардинально противоположные мнения предполагают, что вы должны или любить его, или желать уничтожения. Я хочу предложить некую середину. Для начала, обсудим кошмарные свойства systemd.
Плохое и кошмарное
systemd-escape
Тот факт, что существует systemd-escape, сам по себе явно указывает на нечто ужасно неправильное. Если вы никогда не видели или не использовали эту команду в деле, считайте, что вам повезло.
Читать полностью »
Cбор логов с rsyslog, именами файлов в тегах, многострочными сообщениями и отказоустойчивостью
2017-02-07 в 16:51, admin, рубрики: linux, logging, rsyslog, syslog, Настройка Linux, системное администрированиеизображение с сайта oxygen-icons.org
Задача
Передавать лог-файлы на центральный сервер. При недоступности сервера не терять сообщения, а накапливать и передавать при его появлении в сети. Корректно передавать многострочные сообщения.
Дополнительно:
- не требуется изменение конфигурации сервера при появлении новых лог-файлов, достаточно перенастройки клиента.
- можно передавать содержимое всех лог-файлов с соответствующим шаблону именем, причём на сервере их содержимое будет сохраняться раздельно в файлы с таким же именем.
Условия: в инфраструктуре используются только Linux-сервера.
Мониторинг системных вызовов Linux
2016-12-27 в 6:24, admin, рубрики: audit-go, auditd, go-audit, rsyslog, syslog, Блог компании centos-admin.ru, Серверное администрирование, системное администрирование, метки: audit-go, go-audit
Если вы инженер в организации, использующей Linux в промышленной эксплуатации, у меня к вам два небольших вопроса.
- Сколько уникальных исходящих TCP-соединений установили ваши серверы за последний час?
- Какие процессы и пользователи инициировали установку этих соединений?
Если вы в состоянии ответить на оба вопроса, отлично — дальше можете не читать. А если ответа нет, то получить эту информацию поможет go-audit.
Сбор логов межсетевого экрана Checkpoint (OPSEC LEA)
2016-04-07 в 10:35, admin, рубрики: checkpoint, opsec, syslog, информационная безопасность, логи, метки: opsec 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 сервер.
Читать полностью »
Удобный мониторинг Syslog сообщений c сетевых железок в Zabbix
2015-03-18 в 8:05, admin, рубрики: open source, rsyslog, syslog, zabbix, Блог компании Zabbix, Серверное администрирование, системное администрированиеНеотъемлемой частью сетевого мониторинга является сбор логов с контролируемых серверов и прочих железок. Ведь сколько бы мы ни создали отдельных элементов данных и триггеров к ним, в какой-то момент возникнет ситуация, что что-то важное мы упустили из виду и не контролируем. Итог: «У нас ничего не работает», а система мониторинга говорит, что все хорошо.
Поэтому первое, что хотелось сделать — собирать все логи в заббиксе, сгруппировав их по узлу сети для того, чтобы всегда можно было пробежаться по сообщениям глазами, не тратя время на доступ на оборудование.
Второе — обратить внимание и на те события, о которых и не подозреваешь.
Как это сделать на серверах или компьютерах, где установлен заббикс-агент, многие знают — есть встроенные элементы данных log[], logrt[].
Но как быть, когда нужно собирать логи с сетевого оборудования, на которое никак не водрузить Zabbix-agent’а? Вообще-то можно, конечно, настроить syslog-сервер на том же ПК, на которой есть заббикс-агент, а дальше при помощи log[] переносить эти данные в заббикс. Вот только элементы данных и триггеры по нему будут прикреплены к узлу сети с заббикс-агентом, что интуитивно малопонятно. А можно ли прикрепить эти данные непосредственно к сетевому устройству? Можно.
Для этого нам понадобится zabbix_sender, Zabbix API и rsyslog на машине с заббикс-сервером или заббикс-прокси. В качестве бонуса также получим быстрый контекстный переход в журнал syslog-сообщений с карты сети.
Как будет выглядеть результат? Ну, примерно вот так:
Контекстный вызов:
Маленькая админская история: как поймать OOM
2014-08-01 в 11:47, admin, рубрики: logstash, syslog, udp, webzilla, Блог компании Webzilla, Серверное администрирование, системное администрирование, спасибо за чтениеАдминская загадка: На сервере произошло три 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 в порядке. Загадка? Проблемы? Симптомы таинственной неведомой фигни? Звать придворного шамана с бубном?
Читать полностью »