selinux

Из чата asterisk-support.ru вынесу свое отношение к selinux:

напишу таки свои пять копеек про selinux ко вчерашнему разговору

Андрей думает, что это мало кого беспокоит. Но так и есть. Все спокойно хранят свои данные в облаках и умают, что о них должны заботиться компании. Только небольшое количество спецов понимают, что да как, где дыряво, где не заштопано. При этом менять архитектуру/основу системы не каждому дано, по большей части люди используют только верхние готовые упрощенные интерфейсы. И зачастую такой подход работает. А уж если речь идет о дополнительной настройке (да еще и не обязательной), то тут как бы и вовсе о чем говорить?

но тема таки может быть интересной, т.к. используемая с тех пор когда мамонты еще были молодыми и не такими шерстяными система разграничения rwx для 3-х уровней не всегда достаточна. Особенно для упоротых на безопасности, для параноиков.

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

Но время покажет. Т.е. чтобы эта тема вошла в обиход, ее должны начать поддерживать и использовать как раз производители ПО. Т.е. в мануалах, заметках, how-to’сах должно быть написано, что делать чтобы повысить безопасность приложения. Чтобы ты не сам придумывал, как да что. А были уже предзаготовленные решения, которые устанавливались сразу при установке, а не надо было раскурить трубку, попить чаю, раздуплить два раза тему и потом настроить абы как. Пока этого нет.

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

Когда я вижу asterisk_t и метку типа ast_cod_lib_t – я думаю, еб№на мать, если я к этому вернусь через полгода, фиг чего я разберу, зачем я это сделал, лучше я с этим связываться вообще не буду. Когда я вижу cgcreate, cgexec, cgclassify – о, боже, как это все бросать в суп – вместе или по очереди, а посолить-поперчить? когда я пользую docker exec, docker build – ну на порядок структурированней и понятней (в общем, cli тоже надо уметь варить)

Хотя selinux тоже уже давненько присутствует, его использование пока не дает “а-а-а!.. дайте два” эффекта. Возможно, кто-то сядет и напишет тулзу, которая будет все аккуратно за тебя делать, возможно разработчики будут видеть пользу от применения при эксплуатации своего ПО и рекомендовать использовать, или что-то еще. Но пока… хз.

Теперь попробую привести примеры. Вот допустим у нас есть веб-сервис, который пускает только авторизованных пользователей. С определенных ip. По https. Но в нашем веб-сервисе есть возможность загрузить файл, который как-то затем обрабатывается, например загружаем картинку и изменяем ей размер. И мы знаем, что у этого веб-сервиса используетс ядля ресайза либа, которая для определенных gif с котиками, выполняет код. Наш пользователь может что-то у нас сделать, что мы ему не разрешали делать. Это печаль.

Или еще пример. Я написал прогу. Говорю, эй парни, у меня есть хорошая прога, agi-сервер для астериска, который все делает хорошо. Бинарник, однако, извините. Но в него добавил exploit, который на определенных линуксах запускает код. Т.е. вы сами поставили троянского коня. Это тоже печаль.

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

Если у вас более масштабное решение, т.е. кол-во пользователей исчисляется тысячами и много больше пользователей. То тут как раз и встает вопрос о том, что всем им просто так доверять тоже не стоит. Каждый из них имеет определенный уровень доступа и уже что-то может делать с вашей системой. Вы же их не забаните по ip? Отсюда, следует, чтобы все процессы и данные, к которым имеют доступ такие пользователи не делали всего того, что не следует. А значит их нужно ограничить. И у вас есть для этого средства: а) писать свои проги так, чтобы пользователи не пихали туда все, что не нужно, б) эти проги должны быть существенно ограничены системой.

Ну, и наверное стоит помнить, что это разработка АНБ. Т.е. АНБ заказали разработку какого-то демона, допустим конвертит wav в mp3, чтобы места хватило для записи всех разговоров всех американцев. Но вдруг этот конвертер еще и Сноудену будет mp3 отправлять? Ай-вай. Было бы хорошо, дать доступ к двум папкам и запретить использовать сеть вообще. ок, selinux.

Как-то так.

Advertisements
selinux

git головного мозга

Документацию, конечно, лучше хранить в текстовых файлах под контролем какой-нить DVCS.

История: пара товарищей усердно писала пару модулей, взаимодейтсвующих друг с другом. Поскольку предполагалось, что с этими модулями могут взаимодействовать и другие модули, в том числе и сторонних товарищей, то надо писать доку. Дока была написана. С использованием wordpress. Да, который устанавливается, который на php, который работает с БД. Ну, сами понимаете, что написано с использованием редактора wordpress. И все хорошо. Но однажды… тут вспоминаем Брюса Уиллиса из “Счастливого числа Слевина”, который так многозначительно говорил: “Однажды…”.

Так вот, однажды… сервер, где был wordpress, умер. И сисадмины его не восстановили. Они колдовали над своим VMware ESXi, но все тщетно. И документация умерла. Пара товарищей-то, кстати, уже не работала, а желающие использовать модули и узнать какие параметры туда передавать таки были.

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

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

git головного мозга

Mysql CDR asterisk – field only 2kb

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

Но.. хочется больше. Например, в lua диалплане я готовлю большой файл с данными по звонку, какой пользователь с какого телефонного аппарата звонил на какое-направление. Или поступил входящий номер, был ли он проверен по черному списку, прошел ли ivr, какую букву нажал в ivr, попал в очередь, сколько раз какой агент очереди вызывался. В итоге получается Json поболее 2кб.

Также есть ограничения и cdr_odbc, cdr_pgsql.

В общем, пока выход – использовать func_odbc. Или патчить астериск.

 

Mysql CDR asterisk – field only 2kb

using SHARED asterisk

Использование функции SHARED не очень удобно. Т.к. она привязана к каналам.

Например, мы делаем вызов в queue, где агентами являются Local-каналы, т.е. по отношению к текущему это будут другие каналы. По идее можно было бы узнать имя родительского канала через наследуемую переменную, но как мы будет в него сохранять данные? У нас может быть переменное количество каналов, да и они могут вызываться в queue по нескольку раз. Т.е. пакетов данных по звонкам в сабканалы может быть много.

Альтернатива – использование внешнего хранилища, например, redis. На сабканале делать redis.lpush на uniqueid, а в основном канале сделать redis.lrange по uniqueid и получить массив данных одним хопом. Единственно, необходимо на ключи redis ставить TTL, иначе они будут накапливаться в памяти.

Начало здесь: https://asterisk-support-ru.slack.com/archives/asterisk/p1462528938000253

using SHARED asterisk

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

По идее можно записи на астериске кешировать на tmpfs.

в asterisk.conf есть опции

cache_record_files = yes ; Cache recorded sound files to another
; directory during recording.
record_cache_dir = /tmp ; Specify cache directory (used in conjunction
; with cache_record_files).

если record_cache_dir вынести на tmpfs, а также часть sounds, которые часто используются, то получится что файлы всегда в памяти и на их чтение и запись будет тратится меньше времени.

Как это дело замутить с докером?

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

md5 в asterisk

Полезная команда

echo -n “1234:asterisk:abcd” | md5sum    – md5-хеш от строки без символа новой строки

Несколько конструктивных заметок

  1. Указать realm в sip.conf [general]  – необходимо зафиксировать realm, чтобы в случае необходимости сменить или поправить. По дефолту ставим realm=asterisk, realm указать в каждом пире нельзя.
  2. md5secret = md5(username:realm:secret)

Ссылки:

http://www.voip-info.org/wiki/view/Asterisk+config+sip.conf

http://www.voip-info.org/wiki/view/Asterisk+sip+md5secret

БД update

http://marc.info/?l=asterisk-users&m=121736726209773

 

Есть еще тема про домены

http://superuser.com/questions/598797/realms-in-asterisk

http://kb.smartvox.co.uk/asterisk/how-it-works/configuring-sip-domains-asterisk/

md5 в asterisk

Виртуализация и контейнеризация #webdev

Вообще, сравнивать виртуалки и контейнеры – не комильфо. Суть виртуализации была разделить и сделать машины поверх железа. Виртуализация говорит: железо – отстой. Оно ломается, а виртуальная машина нет. Но ее лучше забекапить. Целиком. Все эти системные блоки умещались в один большой мощный сервак. Там у нас 1С на винде, а еще на фряхе там почтовик и прокси, чтобы смотреть кто по порнушным сайтам ходит. Сломалось железо? Заменили. Все виртуалки целые.

А у докера другая цель, которая становится очевидной когда научишься разделять а) приложение, б) его конфигурацию и в) данные приложения. Докер говорит: ваше приложение – ничто. Его надо заставлять работать. Оно иногда умирает? Я его заставлю работать снова. Ему надо отдельные пакеты-шмакеты, ОСы и т.п? – ок. Пусть думает, что оно одно и все для него. И работает. А если умрет, я его подниму и заставлю работать. А где будет работать приложение? На железе? В виртуалке? В виртуалке, которая запущена в виртуалке? Докеру все одно: запустить контейнер, чтобы приложение работало. Бекапить приложение? Очень смешно. Образ есть? Работаем. Нет? Сбилдим, и ок. Остается только забота о конфигурациях и данных. Ну и приложения иногда писать надо, не самому же работать в докере : )
А поскольку докер позволяет отделить мух от котлет, то появляются решения для управления всем этим колхозом. Поэтому контейнеры – это возможность эффективнее использовать ресурсы, контейнерам прямая дорога в ентерпрайз.

Вы же знаете эту тему: приходите к кому-нибудь, смотрите комп,а там на Винде вирусни.. В общем, самое быстрое и радикальное – переустановить. А он: а,мать моя, у меня там Герои 3 стоят, там уже много прошел и CS и все такое, а еще фотки там слиты где-то и документы, и диплом там же, наверное, хорошо если в Users. Приложения с конфигами и данными в перемешку. Переустанавливаешь. А он: шеф, все пропало! А если бы все данные на USB-винте были, а конфиги и настройки сети на флешке? Плюс скрипт, который знает какие игрухи поставить, да приложения скачать?

Но опять же профит не в том, чтобы определиться виртуалки или контейнеры. Особенно, когда вы строите инфраструктуру для роста. А в том, чтобы использовать их совместно, научившись управляться с этим хозяйством. В целом, приложениям не надо знать на железе они работают или в виртуальных средах, они не знают есть ли в одной ОС рядом с ними БД или где-то далеко. В целом, поняв что астериски все одинаковы, а различаются только конфигурацией, вы спокойно используете один образ астериска для докера на десятках машин, просто создав нужную конфигурацию. Вы понимаете, что данные полученные от астериска – логи звонков, записи разговоров – далее не имеют отношения к астериску и вы их можете использовать, обрабатывать, сохранять не зависимо от того есть астериск или нет, есть БД или нет. Вы можете развернуть свои контейнеры на железе, сконфигурировав одним образом, вы может развернуть те же контейнеры на виртуалке в DigitalOcean, а затем переконфигурировать свой трафик туда сейчас или потом в случае аварии железа. По сути, вам уже и виртуалки бекапить не надо, т.к. в случае необходимости вы ее создаете с базовым образом ОС, закидываете докер-образ приложения, заливаете конфиги, необходимые данные – все работает. В идеале. : )

 

 

Виртуализация и контейнеризация #webdev