По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Дело в том, что если вы не используете какие либо сетевые сервисы (такие как NFS доступ, например) на своем Linux сервере, то скорее всего portmapper вам не нужен.
А чтобы окончательно уверить вас в том, чтобы выключить службу, вот вам факт: злоумышленники юзают сервис portmapper для увеличения эффекта DDoS-атак.
А теперь о том, как проверить portmapper на вашем сервере и отключить его.
Коротко о том, что делает portmapper
Портмаппер это специальный сервис в Linux, который обеспечивает службы RPC (Remote Procedure Call), такие как NFS - служба, например. Кстати говоря, portmapper обитатет на 111 порту (TCP и UDP).
RPC (Remote Procedure Call) - так называемый удаленный вызов процедур. Если кратко, это технология, позволяющая определенному софту вызывать функции и процедуры на других сетевых машинах
Как посмотреть RPC службы
Легко. Вы можете посмотреть список активных RPC - служб с помощью команды rpcinfo. Вот так:
[root@merionet ~]# rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
У нас запущен только сам portmapper. Переходим к экзекуции.
Остановить portmapper in CentOS 7
Сервис, отвечающий за portmapper как правило называется rpcbind. Останавливаем службу и сокет, как показано ниже:
[root@merionet ~]# systemctl stop rpcbind
Warning: Stopping rpcbind.service, but it can still be activated by:
rpcbind.socket
[root@merionet ~]# systemctl stop rpcbind.socket
Полностью выключаем portmapper, даже после перезагрузки
Убедимся, что сервис тоже выключен:
[root@merionet ~]# systemctl disable rpcbind
А теперь контрольный в голову. Проверяем, что при попытке посмотреть информацию по rpc (команда )
[root@merionet ~]# rpcinfo -p
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused
Готово. Теперь, ваш сервер стал чуточку безопаснее.
Конференции помогают оперативно обсуждать важные вопросы внутри компании и эффективно решать проблемы. В данной статье пойдет речь о модуле конференций (Conference) в Elastix 4.0.
Процесс настройки
Для начала процесса настройки данного модуля необходимо пройти по следующему пути в веб-интерфейсе Elastix: PBX → Conference. Появится интерфейс менеджмента конференций:
Соответственно, при клике на “+ New Conference” произойдет создание новой конференции, а при нажатии на “Delete” – удаление уже существующей инстанции. По сути, можно создать бесконечно много конференций, но, как правило, для небольшой организации требуется всего пара-тройка подобных инстанций и то довольно редко.
Так же кнопка «Show Filter» позволяет фильтровать конференции по трем признакам: прошедшие, текущие и будущие.
Ниже на скриншоте приведу пример настроенной конференции:
Рассмотрим поля по порядку:
Conference Name – название конференц-рума
Moderator PIN – пин-код модератора (управляющего) конференцией
User PIN – пин-код пользователя (можно оставить поле пустым)
Start Time – время начала конференции
Conference Number – номер конференции для вызова (экстеншен, по своей сути)
Conference Owner – «владелец» конференции
Moderator Options – опции для модератора, такие как как оповещение о появлении в конференции и запись разговора
User Options – опции пользователя: оповещение, режим слушателя, ожидание владельца конференции
Duration – длительности конференции
Max Participants – максимальное количество участников ( к данному параметру необходимо отнестись внимательно, так как большое количество участников будут очень сильно загружать сильно, что может повлиять на общую функциональность Elastix.
Для завершения и сохранения конференции необходимо нажать на кнопку «Save». Ниже привожу пример трех созданных конференций который запланированы на будущее время (обратите внимание на надпись Filter applied: State = Future Conferences)
Как известно, в телефонии существует два основных вида перевода (или трансфера - transfer) входящих звонков, это:
Attendant Transfer/ consultative transfer - Перевод звонка, при котором оператор, получив информацию от звонящего, ставит звонок на удержание, затем инициирует второй вызов третьей стороне (абоненту, с которым хочет соединиться звонящий), уведомляет о входящем вызове и лишь после разрешения третьей стороны, соединяет с вызывающим абонентом. После этого, оператор кладет трубку и больше никак не влияет на переведенный вызов. Таким образом, оператор остается уверенным в том, что звонящий соединен с нужным абонентом. В случае, если у оператора не получается дозвониться до вызываемого абонента или он сообщает, что не может в данный момент принять звонок, оператор снимает звонящего с удержания и просит его перезвонить позднее.
Blind Transfer - Даже из названия становится понятно, что данный вид перевода является “слепым”, т.е оператор переводит звонок, не уведомляя третью сторону в входящем вызове. Не трудно догадаться, что если вызываемый абонент занят или не отвечает, то вызов попросту обрывается.
Согласитесь, ситуация крайне нежелательная, клиентам приходится заново набирать номер, общаться с оператором, объяснять, что разговора не состоялось и т.д. Теряется время, лояльность клиентов и интерес.
В IP телефонии на базе Asterisk с данной проблемой познакомились, когда начали осуществлять миграцию с аналоговых АТС. Дело в том, что аналоговые АТС по умолчанию поддерживают так называемый Transfer Recall. Данный функционал заставляет АТС перезванивать оператору, если звонок между вызывающим и вызываемым абонентами, по каким то причинам не состоялся. Оператор, в свою очередь, просил вызывающего абонента перезвонить.
Проблема с потерянными вызовами после “слепого” перевода имела место быть вплоть до Asterisk версии 1.6, когда в файл feature.conf в Attended Transfer (atxfer) не был введен дополнительный функционал atxferdropcall , со значениями yes и no
atxferdropcall = yes - Звонок не будет возобновлен после неудачного перевода
atxferdropcall = no – Звонок будет возобновлен после неудачного перевода
По умолчанию в Asterisk данная переменная имеет значение yes.
Таким образом, чтобы решить проблемы с потерянными вызовами при переводе, нужно просто изменить файл feature.conf следующим образом:
[general]
parkext => *700
parkpos => 701-720
context => parkedcalls
parkedcalltransfers = caller
transferdigittimeout => 1
xfersound = beep
xferfailsound = beeperr
atxfernoanswertimeout = 15
atxferdropcall = no
atxferloopdelay = 10
atxfercallbackretries = 2
[featuremap]
blindxfer => *
atxfer => #
Где,
atxfernoanswertimeout - Время, которое необходимо для дозвона обратно;
atxfercallbackretries - Количество попыток повторного дозвона