хороший совет - ничего не скажешь пароль к бд и сразу в крон... лучше на сокеты не ставить проверку пароля а поставить аутентификацию по пиру (системному пользователю) а внешние скрипты типа phpmyadmin вязать по порту... не знаю если в mysql есть такая возможность - давно на постгресе. но это уже как-то глубоко в оффтопик :-)
octopas ( 2013-06-07 17:43:48 +0400 )редактироватьу mysql уже фиг знает сколько присутсвует возможность ставить разных пользователей разным адресам и хорошим тоном является запрет для пользователя рут доступа извне сервера. а если злоумышленик получил доступ к РУТОВОМУ кронтабу, то вас уже ничего не спасет, поверьте. хотя четсно говоря удаление 100000 записей на системах гед это 100000 больше чем сумарное число немного не радуют. я обычно удаляю по calldate>date_sub(now(),interval 6 month)
meral ( 2013-06-08 15:17:56 +0400 )редактировать>>хороший совет - ничего не скажешь пароль к бд и сразу в крон...
А PHP скрипты веб интерфейса у вас пароли к БД спрашивают непосредственно перед исполнением?
switch ( 2013-06-08 15:50:34 +0400 )редактироватьскрипт надо не от рута запускать а из от униховского пользователя asterisk. Как это у меня - только юникс пользователи "asterisk" и "www-api" имеют доступ непосредственно к базе данных Астериска (так настроены pgident и pghba.conf). www-api - это пользователь для отдельного API контроллера (гальваническая развязка через JSON-RPC), который проксирует запросы от вебморды к базе и соответственно имеет к доступ к базе Астера. Если на сервере появились вредноносные веб скрипты то им нужно знать интерфейс между гальванической развязкой и вебмордой чтобы навредить базе Астера. Пароль в этом случае не нужен - api-контроллер коннектится к базе через сокет. Астер тоже через сокет может. если уже есть unix идентификация - зачем еще одна? без ident идентификации и с открытым паролем в /etc/crontab может быть весело... особенно если права для чтения для "other"... от рута по идее вообще в системе ничего запускаться не должно.
octopas ( 2013-06-08 18:40:02 +0400 )редактироватьна сервере телефонии имхо пофигу от какого пользователя. ибо кроме телефонии нчего нет. и если есть доступ к пользователю астриск - то уже можно всю инфу удалить.и смысл? ваши идеи какието сильно теоритические. много вы систем создали?
meral ( 2013-06-08 19:03:48 +0400 )редактироватьесли кто-то получил физический доступ к вашей системе - это уже не ваша система. Если кто-то подключился к эластику и клонам через любую учетку, то он имеет доступ ко всему. В общем можно долго и нудно зарабатывать геморрой мозга устраняя потенциальные проблемы внутренней безопасности, а можно просто никого не пускать внутрь. И потом: если сокет пускает без пароля, то нахрен вся остальная псевдозащита?
switch ( 2013-06-08 19:05:34 +0400 )редактироватьElastix в глаза не видел - только Vanilla. Делаю с нуля на ZF2 обе части + marcelog/PAGI (для AGIшной части использую только некоторые компоненты фреймворка, но оказалось весьма кстатьи - но это уже к поднятой теме безопасности не имеет отношение вроде как :) ). Далеко не на нулевом этапе. До этого долго изучал вопрос. Почему Вы думаете что все системы обязательно должны быть клонами Эластикса? Если создавать тиражируемую систему то вопрос размещения на разных серверах - не обязательно в компетенции разработчика. Как получат доступ к пользователю "asterisk" без взлома рута расскажите мне - при /sbin/nologin? Код Астера вроде небезопасными функциями не страдает насколько мне известно... Лучшая защита - изоляция объектов. Когда доступ к базе может быть от любого пользователя юникс - это не есть гуд. вот что я хотел сказать да и только. чем больше уровней защиты, тем лучше теоретически. если никого не пускать на сервер - это хорошо, но может не продлиться вечно.
octopas ( 2013-06-08 23:49:17 +0400 )редактироватьот того что вы понаделали слоев защиты в виде разделения доступа локальным пользователям к БД ничего не изменится:
- база данных mysql мало кому интересна
- пароли к SIP учеткам хранятся в открытом виде (в случае freepbx)
- никто не будет две недели ломать ваш mysql сервер чтобы слить трафик, просто возьмут следующий адрес из списка
Ну и глупо разграничивать доступ по mysql учеткам внутри одной машины в то время когда у вас в скриптах хранится в открытом виде пароль доступа к базе. Это просто бессмысленно. Если на ваш сервер попал посторонний (ssh, telnet, etc...), то грош цена вашей паранойе.
В общем случае стоимость защиты не должна превышать стоимости последствий от ее компрометации. В подавляющем большинстве случаев защита сервера телефонии сводится к стойким паролям SIP учеток и изолированию (веб интерфейса и других сервисов) от внешнего мира. Запекать каждый раз мудреную систему - нафиг надо. Есть best practics, что нужно делать чтоб вероятность взлома была минимальной.
switch ( 2013-06-09 09:25:43 +0400 )редактировать
Дело не в карме - сайт глючит.
switch ( 2013-06-08 10:32:10 +0400 )редактироватьСпасибо, будем ждать когда сделается =)
DmitryK ( 2013-06-08 11:21:12 +0400 )редактироватьнасколько я помню после удаления файлы в freepbx уже не показывает микрофончик. там просто проверка есть ли файл. или что за ярлычек вам надо удалить?
meral ( 2013-06-08 15:21:26 +0400 )редактироватьпоказывает =( и ссылается на не существующий файл
DmitryK ( 2013-06-09 01:41:05 +0400 )редактироватьобновите еластикс.
meral ( 2013-06-09 05:11:47 +0400 )редактироватьу меня стоит * + отдельно накатил фрипбх
DmitryK ( 2013-06-09 23:17:09 +0400 )редактировать