Как остановить попытки регистрации на Asterisk
Основной вопрос:
Мои журналы Asterisk завалены такими сообщениями:
[2012-05-29 15:53:49] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:50] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:55] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:55] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:57] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device <sip:[email protected]>;tag=cb23fe53
[2012-05-29 15:53:57] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device <sip:[email protected]>;tag=cb23fe53
[2012-05-29 15:54:02] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:54:03] NOTICE[5578] chan_sip.c: Registration from '<sip:[email protected]>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 21:20:36] NOTICE[5578] chan_sip.c: Registration from '"55435217"<sip:[email protected]>' failed for '65.218.221.180' - No matching peer found
[2012-05-29 21:20:36] NOTICE[5578] chan_sip.c: Registration from '"1731687005"<sip:[email protected]>' failed for '65.218.221.180' - No matching peer found
[2012-05-30 01:18:58] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=dEBcOzUysX
[2012-05-30 01:18:58] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=9zUari4Mve
[2012-05-30 01:19:00] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=sOYgI1ItQn
[2012-05-30 01:19:02] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=2EGLTzZSEi
[2012-05-30 01:19:04] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=j0JfZoPcur
[2012-05-30 01:19:06] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=Ra0DFDKggt
[2012-05-30 01:19:08] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=rR7q7aTHEz
[2012-05-30 01:19:10] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=VHUMtOpIvU
[2012-05-30 01:19:12] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:[email protected]>;tag=JxZUzBnPMW
Я использую Asterisk для автоматизированной телефонной системы. Единственное, что он делает, это принимает входящие звонки и выполняет скрипт Perl. Нет исходящих звонков, нет входящих звонков на фактический телефон, нет телефонов, зарегистрированных в Asterisk.
Кажется, должен быть простой способ заблокировать все попытки неавторизованной регистрации, но я долго боролся с этим. Похоже, что должен быть более эффективный способ не допустить, чтобы эти попытки зашли достаточно далеко, чтобы добраться до моих журналов Asterisk. Некоторые настройки, которые я мог бы включить / выключить, которые вообще не допускают попыток регистрации или чего-то еще. Есть какой-либо способ сделать это?
Кроме того, правильно ли я полагаю, что сообщения "Регистрация от..." - это, скорее всего, люди, пытающиеся получить доступ к моему серверу Asterisk (возможно, для совершения звонков в моей учетной записи)? И в чем разница между этими сообщениями и сообщениями "Отправка поддельного отказа..."?
Дальнейшие детали:
Я знаю, что строки "Регистрация от..." являются злоумышленниками, пытающимися получить доступ к моему серверу Asterisk. При установленном Fail2Ban эти IP-адреса блокируются после 5 попыток (по какой-то причине одна получала 6 попыток, но без).
Но я понятия не имею, что означают сообщения "Отправка поддельного отказа от аутентификации..." или как остановить эти потенциальные попытки вторжения. Насколько я могу судить, они никогда не были успешными (не видели каких-либо странных обвинений на моих счетах или что-нибудь).
Вот что я сделал:
- Настройте правила аппаратного брандмауэра, как показано ниже. Вот,
xx.xx.xx.xxэто IP-адрес сервера,yy.yy.yy.yyэто IP-адрес нашего объекта, иaa.aa.aa.aa,bb.bb.bb.bb, а такжеcc.cc.cc.ccIP-адреса, которые использует наш провайдер VoIP. Теоретически, порты 10000-20000 должны быть доступны только для этих трех IP-адресов.+-------+-----------------------------+----------+-----------+--------+-----------------------------+------------------+ | Order | Source Ip | Protocol | Direction | Action | Destination Ip | Destination Port | +-------+-----------------------------+----------+-----------+--------+-----------------------------+------------------+ | 1 | cc.cc.cc.cc/255.255.255.255 | udp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 10000-20000 | | 2 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 80 | | 3 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 2749 | | 4 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 443 | | 5 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 53 | | 6 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 1981 | | 7 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 1991 | | 8 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 2001 | | 9 | yy.yy.yy.yy/255.255.255.255 | udp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 137-138 | | 10 | yy.yy.yy.yy/255.255.255.255 | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 139 | | 11 | yy.yy.yy.yy/255.255.255.255 | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 445 | | 14 | aa.aa.aa.aa/255.255.255.255 | udp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 10000-20000 | | 17 | bb.bb.bb.bb/255.255.255.255 | udp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 10000-20000 | | 18 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 1971 | | 19 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 2739 | | 20 | any | tcp | inbound | permit | xx.xx.xx.xx/255.255.255.255 | 1023-1050 | | 21 | any | all | inbound | deny | any on server | 1-65535 | +-------+-----------------------------+----------+-----------+--------+-----------------------------+------------------+ - Настройте Fail2Ban. Это своего рода работа, но она реагирует, а не проактивна, и, кажется, не блокирует все (например, сообщения "Отправка поддельного отказа...").
- Установите правила в sip.conf, чтобы запретить все, кроме моего VoIP-провайдера. Вот мой sip.conf с почти всеми закомментированными строками (для экономии места). Внизу обратите внимание на мою попытку отказать всем, кроме моего провайдера VoIP:
[general] context=default allowguest=no allowoverlap=no bindport=5060 bindaddr=0.0.0.0 srvlookup=yes
disallow=all allow=g726 allow=ulaw allow=alaw allow=g726aal2 allow=adpcm allow=slin allow=lpc10 allow=speex allow=g726
insecure=invite
alwaysauthreject=yes
;registertimeout=20 registerattempts=0 register => user:pass:[email protected]:5060/700
[mysipprovider] type=peer username=user fromuser=user secret=pass host=sip.mysipprovider.com fromdomain=sip.mysipprovider.com nat=no ;canreinvite=yes qualify=yes context=inbound-mysipprovider disallow=all allow=ulaw allow=alaw allow=gsm insecure=port,invite
deny=0.0.0.0/0.0.0.0 permit=aa.aa.aa.aa/255.255.255.255 permit=bb.bb.bb.bb/255.255.255.255 permit=cc.cc.cc.cc/255.255.255.255
4 ответа
Как долго действуют эти правила брандмауэра? Если вы только что настроили их недавно, и в зависимости от того, как вы их настроили, правила могут применяться только к новым попыткам подключения, но любые установленные подключения все равно будут разрешены. Следовательно, попытки регистрации через уже установленное соединение все еще будут разрешены.
Вы не предоставляете достаточно информации о типе брандмауэра, который используете, но посмотрите, сможете ли вы найти список установленных соединений на порту 5060 и вручную отбросить их. Последующие новые попытки подключения теперь должны быть заблокированы в соответствии с правилами брандмауэра.
Я также вижу, что вы установили bindaddr=0.0.0.0 в вашем конфигурационном файле Asterisk, который заставляет Asterisk прослушивать все доступные интерфейсы. Сколько IP-адресов у этого сервера? Если у него более 1 IP-адреса, вам нужно указать их все в правилах брандмауэра, так как в настоящее время вы только перечисляете xx.xx.xx.xx в качестве IP-адреса назначения для блокировки входящего трафика через порт 5060.
Короче говоря вы блокируете не тот порт. Регистрация SIP происходит через порт 5060 (TCP или UDP). Порты 10000+ предназначены для фактического трафика канала RTP, а не для настройки вызова. Настройте брандмауэр так, чтобы блокировать входящие 5060 и 5061, и вы должны перестать видеть сообщения. Пока вы занимаетесь этим, вы также можете подумать, хотите ли вы, чтобы ваша система прослушивала регистрации SIP на всех интерфейсах. Помните - скорее всего, вы подключаетесь к своему провайдеру, а не наоборот.
В этой ситуации я бы установил определенное правило запрета в качестве первого на вашем брандмауэре - блокирование трафика через порт 5060 на ваш блок Asterisk. Если регистрация по-прежнему разрешена, тогда вам придется более внимательно изучить конфигурацию брандмауэра и определить, почему он не работает.
Конечно - это должно быть остановлено вашим правилом запрета на ловушку, которое вы используете в настоящее время, но оно явно не в состоянии его поймать.
Надеюсь это поможет.
По-видимому, регистрация может проходить через порты 5060/5061. Даже если вы укажете
Порт =5061
или же
bindport=5061
или же
bindaddr=0.0.0.0:5061
Звездочка по-прежнему принимает регистрацию через порт 5060, и все по-прежнему работает.