SG
Коллеги, вопрос. Насколько плохо у астериска во внешку открывать RTP порты 10000-20000, но при этом 5060 фильтровать на уровне Iptables
мое мнение - ничего плохого нет
Size: a a a
2020 May 29
SG
Астериск не биндид на себе все эти порты, а открывает при активном разговоре
Б
Спасибо 👌 думал примерно также
AS
нет. Просто интересует, насколько уязвим астериск при открытых RTP портах во внешку, если при открытом 5060 во внешку астериск начинают активно насиловать, то что будет если открыть RTP порты? Есть ли какие-то уязвимости, баги и прочее
Если RTP без шифрования - можно украсть разговор если есть доступ к трафику
OS
у астера был баг, когда открывалась RTP-сессия, в нее можно было подмешать чужой трафик, с неопределенного ip. Но сейчас этот баг пофиксили. Астер сначала открывает окно, изучает откуда прилетает ответ, после чего блокирует ip:port и больше с других ip не принимает.
ИБ
у астера был баг, когда открывалась RTP-сессия, в нее можно было подмешать чужой трафик, с неопределенного ip. Но сейчас этот баг пофиксили. Астер сначала открывает окно, изучает откуда прилетает ответ, после чего блокирует ip:port и больше с других ip не принимает.
Да, можно было даже ДДоСить по RTP
--
Коллеги, вопрос. Насколько плохо у астериска во внешку открывать RTP порты 10000-20000, но при этом 5060 фильтровать на уровне Iptables
они же открываются только во время соединения, а в ждущем режиме не прослушиваются
--
я хотел сказать, что открывая rtp, вы открываете как раз самую уязвимую часть
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
должно открывать порты динамически и только для тех с кем установлено соединение
должно открывать порты динамически и только для тех с кем установлено соединение
Т
Доброго времени суток!
Подскажите кто нибудь сталкивался с проблемами подключения cdr_pgsql и postgresql 12.3(последний релиз)
- у меня стоит Астер 14.7.1 и с недавним обновление базы postgresql lj 12.3 модуль перестал поключаться дело в том что в новом pg изменили структуру системных табли и астериск выводит ошибку подключения к pg :
"ERROR[7835] cdr_pgsql.c: Failed to query database columns: ОШИБКА: столбец d.adsrc не существует
LINE 1: ...ECT a.attname, t.typname, a.attlen, a.attnotnull, d.adsrc, a..." - в 12.3 pgsql удален этот столбец adsrc.
Естьли вариант обновления модуля cdr_pgsql без обновления всего астера?
Подскажите кто нибудь сталкивался с проблемами подключения cdr_pgsql и postgresql 12.3(последний релиз)
- у меня стоит Астер 14.7.1 и с недавним обновление базы postgresql lj 12.3 модуль перестал поключаться дело в том что в новом pg изменили структуру системных табли и астериск выводит ошибку подключения к pg :
"ERROR[7835] cdr_pgsql.c: Failed to query database columns: ОШИБКА: столбец d.adsrc не существует
LINE 1: ...ECT a.attname, t.typname, a.attlen, a.attnotnull, d.adsrc, a..." - в 12.3 pgsql удален этот столбец adsrc.
Естьли вариант обновления модуля cdr_pgsql без обновления всего астера?
Коллеги если кто столкнется с проблемой модуля cdr_pgsql.so при поключения астериска 14.7.1 и ниже с бд postgresql 12.3 (крайний релиз)
проблема заключалась в поле adsrc таблицы pg_attrdef так как в последних релиза этот столбец был удален
старый модуль cdr_pgsql.so не мог подключиться. Скомпилировать модуль с более позднего астериска естественно не получилось.
проблема была решена костылем в коде cdr_pgsql.c на строчках 698 и 708
поле d.adsrc был заменен на a.attname as adsrc - так как поле простое текстовое и не несет дальнейшего смысла а менять кол-во столбцов в
запросе чревато фатальной ошибкой. после правки естественно компилируем и заменяем модуль cdr_pgsql.so
проблема заключалась в поле adsrc таблицы pg_attrdef так как в последних релиза этот столбец был удален
старый модуль cdr_pgsql.so не мог подключиться. Скомпилировать модуль с более позднего астериска естественно не получилось.
проблема была решена костылем в коде cdr_pgsql.c на строчках 698 и 708
поле d.adsrc был заменен на a.attname as adsrc - так как поле простое текстовое и не несет дальнейшего смысла а менять кол-во столбцов в
запросе чревато фатальной ошибкой. после правки естественно компилируем и заменяем модуль cdr_pgsql.so
Т
SL
https://voxlink.ru/kb/asterisk-configuration/ustanovka-i-nastrojka-sip-shljuza-dlja-telegram/ - очень круто!
Но 2 вопроса.
1) Нет ли информации по зависимостям для debian-like?
2) Для чего pjsip?
Но 2 вопроса.
1) Нет ли информации по зависимостям для debian-like?
2) Для чего pjsip?
EK
https://voxlink.ru/kb/asterisk-configuration/ustanovka-i-nastrojka-sip-shljuza-dlja-telegram/ - очень круто!
Но 2 вопроса.
1) Нет ли информации по зависимостям для debian-like?
2) Для чего pjsip?
Но 2 вопроса.
1) Нет ли информации по зависимостям для debian-like?
2) Для чего pjsip?
2) SIP-стек. Драйвер, который собственно и заведует сигнализацией SIP. Один из двух. Есть еще chan_sip, но pjsip новее и далее астер скорее всего уйдет на него
О каких зависимостях речь?
О каких зависимостях речь?
SL
2) SIP-стек. Драйвер, который собственно и заведует сигнализацией SIP. Один из двух. Есть еще chan_sip, но pjsip новее и далее астер скорее всего уйдет на него
О каких зависимостях речь?
О каких зависимостях речь?
Не дай Бог!
Ну, т.е. и в chan_sip оно замечательно заработает?
Зависимости в пункте 7.
Ну, т.е. и в chan_sip оно замечательно заработает?
Зависимости в пункте 7.
--
его можно вообще на отдельном хосте поставить
--
инфактум со стороны sip-сервера выглядит как обычный софтфон
EK
Не дай Бог!
Ну, т.е. и в chan_sip оно замечательно заработает?
Зависимости в пункте 7.
Ну, т.е. и в chan_sip оно замечательно заработает?
Зависимости в пункте 7.
Ну вроде где-то писали, что chan_sip будет депрекейтед. Хотя и могу врать. Сейчас не помню и может путаю с app macro. Но, имхо, к этому идет.
Насчет пункта 7 - попробуйте поставить аналогичные пакеты через apt.
Насчет пункта 7 - попробуйте поставить аналогичные пакеты через apt.
EK
сначала apt install build-essential, далее пробуем компильнуть и смотрим, на что ругается, и доставляем
SL
Ну вроде где-то писали, что chan_sip будет депрекейтед. Хотя и могу врать. Сейчас не помню и может путаю с app macro. Но, имхо, к этому идет.
Насчет пункта 7 - попробуйте поставить аналогичные пакеты через apt.
Насчет пункта 7 - попробуйте поставить аналогичные пакеты через apt.
макро уже в прошлом, они перешли на gosub
но от от chan_sip уходить никак нельзя. Иначе как жиль всяким yealink, grandstream и т.п.?
Имена пакетов, как правило, различаются, но попробую.
Я так понял, что freepbx тоже не является обязательным элементом связки?
но от от chan_sip уходить никак нельзя. Иначе как жиль всяким yealink, grandstream и т.п.?
Имена пакетов, как правило, различаются, но попробую.
Я так понял, что freepbx тоже не является обязательным элементом связки?
EK
макро уже в прошлом, они перешли на gosub
но от от chan_sip уходить никак нельзя. Иначе как жиль всяким yealink, grandstream и т.п.?
Имена пакетов, как правило, различаются, но попробую.
Я так понял, что freepbx тоже не является обязательным элементом связки?
но от от chan_sip уходить никак нельзя. Иначе как жиль всяким yealink, grandstream и т.п.?
Имена пакетов, как правило, различаются, но попробую.
Я так понял, что freepbx тоже не является обязательным элементом связки?
фрипбх - это тупо наболдажник на астер. поэтому все, что он умеет, умеет и астер. отсюда вывод - 99% вероятности, что не нужен
SL
фрипбх - это тупо наболдажник на астер. поэтому все, что он умеет, умеет и астер. отсюда вывод - 99% вероятности, что не нужен
Наболдажник ))) Шикарно!
Спасибо за информацию!
Спасибо за информацию!