Understanding STIR/SHAKEN

https://transnexus.com/whitepapers/understanding-stir-shaken/

The Federal Communications Commission (FCC) has been encouraging the telecommunications industry to develop a solution to stop robocalls and spoofed calling numbers since 2014. The industry’s response has been to develop a new technology standard called STIR [1] (Secure Telephony Identity Revisited) and SHAKEN [2] (Secure Handling of Asserted information using toKENs) which defines how telephone service providers should implement the STIR technology to ensure calling numbers are not spoofed.

Ставим sip3 trial

Что это - можно посмотреть тут
https://sip3.io/features/

По установке, есть репа с буками для ansible, которые выкатывают пакеты в докер.
https://github.com/sip3io/sip3-ansible/
Делаем clone.
Для установки нужны ansible (в центос 7 из epel) и docker (ставить с сайта), а также
yum install python-pip
pip install docker-py

Вносим нужные хосты

vi roles/sip3-salto/templates/hosts.yml.j2

Также, если порт 80 занят, правим порт для запуска

vi roles/sip3-hoof/tasks/main.yml

80 на 88

И запускаем установку.

ansible-playbook -K playbooks/trial/sip3.yml

ansible-playbook -K playbooks/trial/captain.yml

Также учитываем момент что всё будет доступно без SSL и паролей, так что это только для закрытого контура или прогонять через nginx для ssl и авторизации.

Termshark - A terminal user-interface for tshark, inspired by Wireshark.

Доступен первый выпуск Termshark, консольного интерфейса, выполненного в форме надстройки над развиваемым проектом Wireshark анализатором сетевых протоколов TShark. Код написан на языке Go и распространяется под лицензией MIT. Готовые сборки подготовлены для Linux, macOS, FreeBSD и Windows.

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

https://termshark.io/
https://github.com/gcla/termshark
https://www.opennet.ru/opennews/art.shtml?num=50556
https://github.com/gcla/termshark/releases/tag/v1.0.0

Поскольку оно на golang, можно взять уже собранный файл и просто положить например в /usr/bin (внимание, для работы требуется поставить tshark)
wget https://github.com/gcla/termshark/releases/download/v1.0.0/termshark_1.0.0_linux_x64.tar.gz
tar -zxvf termshark*
mv termshark*/termshark /usr/local/bin

При ошибке
Could not find tshark in your PATH. The tshark binary is required to run termshark.
Try installing with: yum install wireshark
требуется поставить wireshark.

termshark will not operate correctly with a tshark older than 1.10.2 (found 1.8.10)

Если ставим в центос6 - версия из того что было в epel слишком стара. Проблема в том, что даже в DAG только 1.10.0-2

Небольшое исследование про golang-github-influxdb-influxdb-datastore

Если кто сталкивался с докой
https://support.nagios.com/kb/article.php?id=802
то видел, что не найти пакет golang-github-influxdb-influxdb-datastore, исследование тэгов репы показывает что оно было в ветке 0.8, но было выпилено к выходу ветки 0.9.
Можно скачать rpm с этим пакетом (например с rpm.pbone), но он не поставится по зависимостям.
(И вкратце - ставить datastore уже не нужно)

CentOS 6: ставим AlertManager

https://prometheus.io/download/
тут качаем AlertManager, распаковываем, копируем alertmanager и amtool в /usr/local/bin/, конфиг в /etc/prometheus/alertmanager.yml
Потом тут
https://gist.github.com/JoergM/86617e89d6491b42596c
инит файл под него.
Настройку опускаем, это можно делать через правку конфига или напрямую через amtool
Копируем init файл в /etc/init.d, выставляем +x на него, добавляем пользователя prometheus
groupadd prometheus
useradd -d /var/lib/prometheus -g prometheus -M -s /sbin/nologin prometheus

Запускаем.
mkdir /var/log/prometheus/

chown prometheus /var/log/prometheus/

mkdir /var/lib/prometheus/alertmanager

chown prometheus: /var/lib/prometheus/alertmanager

Вносим правки в инит файл: нужно к -config добавить минус чтобы получилось --, удалить часть про silences, и добавить --storage.path=/var/lib/prometheus/alertmanager
Конфиг - расширение меняем на .yml

/etc/init.d/alertmanager start

По настройке есть например тут
https://prometheus.io/docs/alerting/configuration/

Чуть подробнее про особенности 2.0+ версии есть тут
https://ealebed.github.io/posts/2017/prometheus-%D0%BC%D0%B8%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F-%D0%BD%D0%B0-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8E-2.0/

Nagios+grafana

За основу можно взять статью
https://support.nagios.com/kb/article.php?id=802
Но - только взять за основу, поскольку эта статья УЖАСНА. По форме и содержанию. Главный элемент в этой доке это nagflux, который связывает метрики нагиоса и БД influxdb. Также описывается histou

Есть ряд нюансов, например если ставим в центос6 то epel там постоянно обрезают, нужно искать пакеты по архивам.
Вообще, дока крайне странная, чего стоит использование путей /usr/local/..., вместо cat >> file << EOF делается пачка echo '', неполные и нерабочие конфиги...
Также можно посмотреть эту доку
https://exchange.nagios.org/directory/Documentation/Nagios-with-InfluxDB%2C-nagflux-and-Grafana/details

Unable to negotiate with x.x.x.x.123 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

При подключении к некоторым железкам типа Cisco ASA5508 может быть ошибка при подключении
Unable to negotiate with x.x.x.x.123 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Фикс: указать опцию -oKexAlgorithms=+diffie-hellman-group1-sha1
например так
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 x.x.x.x

Можно в ~/.ssh/config добавить
Host x.x.x.x
    KexAlgorithms +diffie-hellman-group1-sha1

Semantic Versioning 2.0.0

https://semver.org/
https://semver.org/lang/ru/

Debian: ставим kamailio+rtpengine

Имеется: debian 8 (jessie), кама штатно - говно мамонта
Unpacking kamailio (4.2.0-2+deb8u5) ...
Ставим адекватную версию. Прямо с офсайта можно скачать с версии 3.3 по самую свежую 5.2
https://deb.kamailio.org (2)
Сначала добавить ключ

 wget -O- http://deb.kamailio.org/kamailiodebkey.gpg | sudo apt-key add -

а потом ставим репу, для этого выбираем нужную версию камы и в /etc/apt/sources.list.d/kamailio.list пишем нужные строки из доки выше.
Потом как обычно, apt-get update; apt-get install kamailio

nginx ldap auth

Самый простой вариант ограничения доступа - через файл с паролями, как-то так

location / {

auth_basic "Restricted Area";

auth_basic_user_file auth/htpasswd;

proxy_pass ... }

Но порой требуется интеграция с ldap. Есть несколько вариантов

1. https://github.com/nginxinc/nginx-ldap-auth - отдельный сервис, можно запустить в докере, обращение к сервису идёт по http
2. Внешние модули:
   https://github.com/kvspb/nginx-auth-ldap
   https://github.com/sto/ngx_http_auth_pam_module
3. Штатный модуль http://nginx.org/en/docs/http/ngx_http_auth_request_module.html, но общение с ldap надо реализовать самому

Плюсы и минусы каждого подхода вполне понятны. Модуль - надо собирать под ту же версию, а если оно не умеет динамическим модулем то потом собирать пакет и выкатывать нашу сборку. Нужно отслеживать процесс обновления пакетов, чтобы не поставилась другая версия (решается через опцию Requires в spec файле).

Соберём пакет по п.1, при этом обязательно актвировать модуль ngx_http_auth_request_module (включено в официальных сборках), спека в комплекте
https://github.com/nginxinc/nginx-ldap-auth/tree/master/rpm

Делаем свой docker registry

https://docs.docker.com/registry/deploying/

Само создание сводится к одной команде (требуется установленный докер)
docker run -d -p 5000:5000 --restart=always --name registry registry:2

Потом вешаем нужный тэг
docker tag ubuntu:16.04 localhost:5000/my-ubuntu
и push
docker push localhost:5000/my-ubuntu

Но с других машин при пуше будет ошибка http: server gave HTTP response to HTTPS client, нужно настраивать сертификат или создавать /etc/docker/daemon.json (см доку).

CentOS, rtpengine dkms сборка модуля

https://habr.com/ru/post/266399/

Главное требование - наличие установленных пакетов ядра:
yum install -y kernel kernel-headers kernel-devel kernel-tools kernel-debug-devel
И перезагружаемся, чтобы переключиться на эту версию. После этого, поставив ngcp-rtpengine-kernel, модуль должен загрузиться сам. Если нет - смотрим линк выше, в сторону dkms add, dkms build, dkms install

Prometheus

Prometheus - "мониторинг нового поколения".
Prometheus' main distinguishing features as compared to other monitoring systems are:

a multi-dimensional data model (timeseries defined by metric name and set of key/value dimensions)
a flexible query language to leverage this dimensionality
no dependency on distributed storage; single server nodes are autonomous
timeseries collection happens via a pull model over HTTP
pushing timeseries is supported via an intermediary gateway
targets are discovered via service discovery or static configuration
multiple modes of graphing and dashboarding support
support for hierarchical and horizontal federation

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

• Где хранить?
• Как получать?
• Как выводить?
• Как оповещать?
• Как масштабировать?

Помимо самого прометея, есть ещё
push gateway для работы с кратковременными процессами (когда сервис работает слишком мало времени, что бы Prometheus имел возможность выполнять к нему запросы для получения метрик)
exporters для сбора метрик из сторонних сервисом (и таких экспортёров – миллион, и имя им легион). В частности, большой список есть тут https://prometheus.io/docs/instrumenting/exporters/
alertmanager – менеджер уведомлений (умеет Slack, почту и т.д.)

А также..

1. дашборды (dashboards), где будем настраивать всякие красивые графики;
2. Системы сбора, обработки метрик;
3. Базы, где метрики будут храниться;

1. Grafana, 

2. StatsD, telegraf, carbon

3. graphite, influxdb, whisper, prometheus...

Мониторим nginx статистику (коды ответов итд) через prometheus, подключаем dashboard в grafana

Базовый (не Plus) nginx выдаёт крайне скупую статистику - сколько коннектов сейчас, сколько обработано. Чтобы получать больше информации, нужно или парсить access логи, или ставить модуль vts - их есть 2 вида
1) https://github.com/vozlt/nginx-module-vts
собирается динамическим модулем для nginx, причём версии nginx и модуля должны совпадать

2) https://github.com/knyar/nginx-lua-prometheus
требует lua, то есть или нужен nginx plus или openresty

Поставим первый модуль и подключим к нему экспортер vts в json
https://github.com/hnlq715/nginx-vts-exporter

UP: больше не нужно, nginx-vts научился экспортировать prometheus и json сам. Просто пишем server например на порт 9913 "как было" и всё. И там сразу

    location /metrics {
        vhost_traffic_status_display;
        vhost_traffic_status_display_format prometheus;
        vhost_traffic_status_bypass_stats on;
    }

Сборку и установку динамического модуля опустим (подробнее есть тут), только проверим что по адресу http://localhost/status есть отдача статистики модуля (а чтобы она появилась, читаем тут).
Теперь подключаем экспортер, и по адресу http://localhost:9913/metrics смотрим что появилась информация.
А теперь само подключение дашборда.
http://docs.grafana.org/reference/export_import/#importing-a-dashboard
Читаем как подключать, там достаточно просто id вставить и заполнить data source (prometheus), брать например тут
Nginx VTS Stats

Теперь переходим на http://(server):3000/dashboard/import и в Grafana.com Dashboard вставляем нужный нам id.

PS
Обращаю внимание, есть такой шлак
https://github.com/nginxinc/nginx-prometheus-exporter
Почему шлак? Потому что для чистого nginx он просто экспортирует stub_status, тот самый мизер.

ещё немного про сборку пакетов под debian

https://habr.com/ru/company/itsumma/blog/443490/#comment_19876102

А у вас была необходимость собирать пакеты «правильно и канонично»? (Под этим я имею ввиду когда пишется debian/rules а потом все собирается при помощи dpkg-buildpackage -us -uc)

Просто, если делать это для внутренних нужд, то шаблон control.in, куда подставляются нужны значения версий, posints/postrm скрипты если нужны, директория с деревом файлом + fakeroot dpkg-deb --build и готовый пакет. Вроде совсем небольно. Можно еще fpm использовать, но если нет необходимости собирать пакеты под другие дистрибутивы, то какого-то особого преимущества он имхо не даст.

А если совсем «для себя», то можно checkinstall использовать.

https://michael.stapelberg.ch/posts/2016-11-25-build-tools/
Ну и сама статья о том, что с пакетами в debian всё довольно печально даже для maintainer