Pull to refresh

Журналирование Windows EventLog и система оповещения для администраторов

Information Security *
Некоторое количество времени(года три) назад, в попытке найти способ экспорта Windows EventLog, была найдена возможность в удобном виде осуществлять аудит различных событий происходящих на сервере.
Читать дальше →
Total votes 6: ↑5 and ↓1 +4
Views 16K
Comments 1

Как узнать какие порты на коммутаторах уже не используются

System administration *
Sandbox
Чуть больше года назад столкнулся с проблемой, знакомой, наверное, каждому админу: в одном из коммуникационных шкафов закончились почти все свободные порты. Визуально было видно, что почти к каждому порту подключён кабель, свободных осталось только один-два порта, а требовалось подключить около десяти новых девайсов.

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

Отключение неактивных портов было неприемлемо, так как то, что какой-то порт в данный момент не активен, не говорит о том, что он не использовался 10 минут назад, а пользователь просто отключил свой компьютер, и, скажем, уехал на встречу.
Читать дальше →
Total votes 60: ↑56 and ↓4 +52
Views 48K
Comments 62

Перенаправление событий Windows (Event Log) на сервер syslog Linux

System administration *
Sandbox

Вступление


Это статья предназначена для системных администраторов, которые знакомы с Linux и используют семейство этих систем в смешанной среде прекрасно осознавая что разные ОС хороши в разных задачах. Так же она будет интересна всем администраторам, даже тем, кто не знаком с линуксом, своей теоретической частью.

В ней описывается простой и надежный способ (даже скорее простая и надежная сторонняя утилита) для передачи системных событий из Event Log’ов серверов на базе Windows в Linux syslog для удобства централизованного хранения и обработки.

Реалии таковы, что в нынешней корпоративной среде самое эффективное и надежное решение основывается на смешении серверных операционных систем из-за качества и способов решаемых ими задач. Рабочие станции, и, следовательно, групповое ими управление и администрирование проще делать на Active Directory; веб сервер, прокси сервер надежнее поставить на линукс; роутером быстрее сделать что-то из Cisco. Эта объективная реальность, с которой работают администраторы многих средних компаний (особенно знакомые с линуксом, от винды так или иначе им все равно не уйти и зачастую в фирме стоят домен-контроллеры на винде и прокси-сервер и роутер на линуксе) — в мелких фирмах можно обойтись одной виндой, в крупной фирме скорее всего раздельно существует администратор линуксоид и администратор виндузятник умело отвечающие за свои сектора. Так или иначе, эта статья не теоретизирование и не исследование на эту тему, эта статья про конкретную задачу, которая практически всегда приходит в голову любому администратору работающему в таком окружении, а вступление что-то затянулось.
Читать дальше →
Total votes 40: ↑37 and ↓3 +34
Views 58K
Comments 17

NOC: Введение в Fault Management

Network technologies *


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

Существует немало систем мониторинга, которые выполняют активную проверку сети и сетевых сервисов по протоколам ICMP и SNMP. Быстрый и неправильный ответ – очевиден. Достаточно настроить волшебную систему мониторинга, и наступит полное счастье. Вся обманчивость этого заблуждения понимается со временем. Сначала выясняется, что обнаружение аварий происходит только на тех сервисах, которые поставлены на мониторинг. Хорошо, если удалось накрыть хотя бы основные сервисы. Остальные, увы, будут ставиться на мониторинг в результате горького опыта и ценой запоздалой реакции. Чуть попозже начинается мистика. Что-то явно работает не так, есть жалобы, но система мониторинга говорит, что все в порядке. В чем причина?
Читать дальше →
Total votes 28: ↑28 and ↓0 +28
Views 15K
Comments 20

Logreplica: сбор логов со всего кластера в единую точку в реальном времени

System administration *
Я продолжаю делиться полезными утилитами, которые использую в различных проектах. На этот раз речь пойдет о logreplica — простом инструменте, который позволяет организовать надежную передачу логов с разных серверов кластера на единую машину с большими дисками «в реальном времени». Это очень удобно, если вы хотите централизованно мониторить или анализировать логи со всего кластера так, как будто бы они пишутся напрямую на единственную машину.

Можно сказать, что logreplica задумывался как более удобный и надежный способ сбора логов в центральное место, нежели способ использования настроек syslog/syslog-ng.

Преимущество logreplica — в простоте конфигурирования: вы единственный раз настраиваете «маску» имен лог-файлов и задаете адреса машин-источников, и в дальнейшем логи, соответствующие маске, автоматически и «на лету» складываются на центральную машину (в том числе если на машинах-источниках появляются новые лог-файлы, неизвестные на момент старта logreplica). При добавлении новой машины на ней не нужно ничего донастраивать: достаточно включить ее имя в конфиг-файл.
Читать дальше →
Total votes 30: ↑26 and ↓4 +22
Views 6.8K
Comments 47

Приручаем Graylog2 — визуализированный и функциональный сервер лог-файлов

System administration *
При достаточно большом парке серверов, с тысячами крутящихся на них сервисов, демонов, скриптов, довольно непросто уследить за многочисленными ошибками внутри. Где-то кончилась память, где-то залип демон, где-то база данных ведет себя неадекватно. Уже не раз обсуждались серверы централизованного хранения логов, хочу рассказать еще об одном удобном и мощном инструменте — Graylog2.
Читать дальше →
Total votes 54: ↑53 and ↓1 +52
Views 65K
Comments 34

Журналы сервисов — пользователям

System administration *
image Давно меня заботила проблема, что пользователь шаред-хостинга не всегда знает, что происходит с его аккаунтом — зашёл ли кто по ftp, выполнилось ли задание cron, был ли доступ по ssh, куда делось письмо и вообще отправлялось ли. У большинства хостеров (и у нас в том числе) пользователь мог задать вопрос в службу техподдержки и ждать, когда специалист с соответствующими правами и квалификацией сделает подборку нужных логов. Бонусная проблема — нельзя вот так просто взять и одной командой посмотреть записи в логах относящиеся к пользователю. Это создаёт трудности для системного администратора.

Казалось бы простая задача с самого начала начала преподносить сюрпризы.
Читать дальше →
Total votes 24: ↑17 and ↓7 +10
Views 7.8K
Comments 54

Удобный просмотр syslog журнала межсетевого экрана D-Link DFL-860E c помощью скрипта на PHP

PHP *
Sandbox
В межсетевых экранах D-Link DFL есть несколько минусов в средстве просмотра журнала событий с помощью веб-интерфейса:
— большой поток данных переполняет отображаемый журнал событий и просмотреть логи обычно возможно только за маленький промежуток времени (несколько дней, чаще только за 1 день);
— чтобы посмотреть журнал нужно зайти в веб-панель маршрутизатора (ввести пароль и логин), выбрать статус и отображение журнала. Не имея доступа к веб-панели (не являясь админом устройства) посмотреть логи невозможно, а бывает нужно дать доступ на просмотр логов человеку, которому пароль и логин к устройству давать не нужно;
— в журнале логи разбиваются на маленькие странички, и если журнал большой перелистывать такие странички становится утомительно.

В DFL можно отправлять логи на syslog сервер, который будет писать журнал в файл, правда читать потом такой файл очень неудобно из-за его большого размера и неудобного поиска.

Для тех у кого есть возможность использовать web сервер, выполняющий скрипты на php можно просматривать журнал с помощью небольшого скрипта:

Читать дальше →
Total votes 6: ↑5 and ↓1 +4
Views 13K
Comments 0

Маленькая админская история: как поймать OOM

Webzilla corporate blog
Админская загадка: На сервере произошло три 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 в порядке. Загадка? Проблемы? Симптомы таинственной неведомой фигни? Звать придворного шамана с бубном?
forensic system administration
Total votes 54: ↑48 and ↓6 +42
Views 28K
Comments 19

Удобный мониторинг Syslog сообщений c сетевых железок в Zabbix

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

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

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

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

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


Читать дальше →
Total votes 15: ↑14 and ↓1 +13
Views 122K
Comments 23

Сбор логов межсетевого экрана Checkpoint (OPSEC LEA)

Information Security *
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 сервер.
Читать дальше →
Total votes 6: ↑6 and ↓0 +6
Views 13K
Comments 4

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

Southbridge corporate blog System administration **nix *Server Administration *
Translation


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


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

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

Читать дальше →
Total votes 26: ↑25 and ↓1 +24
Views 19K
Comments 5

Cбор логов с rsyslog, именами файлов в тегах, многострочными сообщениями и отказоустойчивостью

Configuring Linux *System administration **nix *

image


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


Задача


Передавать лог-файлы на центральный сервер:


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

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

Читать дальше →
Total votes 27: ↑27 and ↓0 +27
Views 120K
Comments 12

SystemD отстой, да здравствует SystemD

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

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


systemd-escape


Тот факт, что существует systemd-escape, сам по себе явно указывает на нечто ужасно неправильное. Если вы никогда не видели или не использовали эту команду в деле, считайте, что вам повезло.
Читать дальше →
Total votes 64: ↑61 and ↓3 +58
Views 46K
Comments 188

Грязное место провайдера: проект blondemine

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

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

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

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

Читать дальше →
Total votes 13: ↑12 and ↓1 +11
Views 5.3K
Comments 8

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

TS Solution corporate blog Information Security *System administration *Server Administration *Big Data *


Добрый день!

Сегодня мы рассмотрим распространённый вопрос, с которым сталкиваются все, кто обрабатывает логи или собирается это делать и сейчас приценивается к различным решениям по обработке и хранению. Какой же объем логов в день/неделю/месяц мы будем получать из различных систем и какие ресурсы по хранению мы должны задействовать?
Однозначно точно сказать довольно сложно, но мы попробуем помочь вам примерно разобраться с предполагаемыми объемами, основываясь на нашем опыте.
Читать дальше →
Total votes 9: ↑7 and ↓2 +5
Views 5.8K
Comments 1

VyOS OpenSource Router

Open source *IT Infrastructure *Network technologies *Software
В этой статье я хотел поднять не стандартную для меня тему о сетевом маршрутизаторе 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

Настроить корпоративную сеть с VyOS роутером
Total votes 16: ↑16 and ↓0 +16
Views 33K
Comments 37

Создание инкрементального сервера для iOS Team

Development for iOS *
image

Бесплатная книга

После пяти лет наступаний на одни и те же грабли, и полугода поисков DevOps-а, который знает что-такое Provision Profile и как от него зависит развертывание приложения, было принято решение составить пошаговую инструкцию, в картинках, о том, настраивать рабочее окружение в iOS Team с минимальными финансовыми вложениями (к примеру, когда нет проплаченных аккаунтов GitHub или Jira), а работа кипит.
Читать дальше →
Total votes 8: ↑8 and ↓0 +8
Views 2.5K
Comments 1

journald вместо syslog

Configuring Linux *System administration *Server optimization *Server Administration *DevOps *
Tutorial

Использование journald как замена syslog'у для приложений с большим числом логов.Давным-давно, когда были дебаты о том, стоит ли принимать в качестве init-системы systemd (с одной стороны удобно, с другой стороны, довольно токсичный автор...), вместе с systemd приехал и journald. В целом, он ощущался как аппендикс к systemd, и вместе с ForwardToSyslog, он мирно жил на серверах. Дефолтная конфигурация в целом устраивала, а всё нужное можно было по-старинке накрутить в syslog'е.

В одном из проектов у нас образовалась потребность в обработке большого числа логов, и мы решили попробовать journald вместо (r)syslog(d|-ng). Оказалось, что:

journald решает все наши проблемы

документации по нему подозрительно мало (особенно, в сравнении с systemd)

при том, что его поведение более-менее разумно, интуиция о том, как он работает, практически отсутствует и её надо набирать.

Read more
Total votes 54: ↑52 and ↓2 +50
Views 15K
Comments 45
1