Как остановить попытки регистрации на Asterisk

Главный вопрос:

Мои журналы Asterisk завалены такими сообщениями:

[2012-05-29 15:53:49] NOTICE[5578] chan_sip.c: Registration from '<sip:912@xx.xx.xx.xx>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:50] NOTICE[5578] chan_sip.c: Registration from '<sip:912@xx.xx.xx.xx>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:55] NOTICE[5578] chan_sip.c: Registration from '<sip:100@xx.xx.xx.xx>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:53:55] NOTICE[5578] chan_sip.c: Registration from '<sip:100@xx.xx.xx.xx>' 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:100@xx.xx.xx.xx>;tag=cb23fe53
[2012-05-29 15:53:57] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device <sip:100@xx.xx.xx.xx>;tag=cb23fe53
[2012-05-29 15:54:02] NOTICE[5578] chan_sip.c: Registration from '<sip:100@xx.xx.xx.xx>' failed for '37.75.210.177' - No matching peer found
[2012-05-29 15:54:03] NOTICE[5578] chan_sip.c: Registration from '<sip:100@xx.xx.xx.xx>' 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:55435217@xx.xx.xx.xx>' 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:1731687005@xx.xx.xx.xx>' 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:unknown@188.64.49.26>;tag=dEBcOzUysX
[2012-05-30 01:18:58] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=9zUari4Mve
[2012-05-30 01:19:00] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=sOYgI1ItQn
[2012-05-30 01:19:02] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=2EGLTzZSEi
[2012-05-30 01:19:04] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=j0JfZoPcur
[2012-05-30 01:19:06] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=Ra0DFDKggt
[2012-05-30 01:19:08] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=rR7q7aTHEz
[2012-05-30 01:19:10] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;tag=VHUMtOpIvU
[2012-05-30 01:19:12] NOTICE[5578] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@188.64.49.26>;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.cc IP-адреса, которые использует наш провайдер 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:user@mysipprovider.com: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

Короче вы блокируете не тот порт. Регистрация SIP происходит через порт 5060 (TCP или UDP). Более 10000 портов будут использоваться для фактического несущего трафика RTP, а не для установки вызова. Настройте брандмауэр, чтобы блокировать входящие сообщения 5060 и 5061, и вы должны перестать видеть сообщения. Пока вы это делаете, вы также можете подумать, хотите ли вы или хотите, чтобы ваша система прослушивала регистрации SIP на всех интерфейсах. Помните - вы, скорее всего, подключаетесь к своему провайдеру, а не наоборот.

По-видимому, регистрации могут поступать на порты 5060/5061. Даже если вы укажете

порт = 5061

или

bindport = 5061

или

bindaddr = 0.0.0.0: 5061

Звездочка по-прежнему принимает регистрацию на порт 5060, и все по-прежнему работает.

Что я бы сделал в этой ситуации, так это установил конкретное правило запрета в качестве первого на вашем брандмауэре, заблокировав трафик через порт 5060 на ваш сервер Asterisk. Если регистрации по-прежнему разрешены - вам придется более внимательно изучить конфигурацию вашего брандмауэра и определить, почему он не работает.

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

Надеюсь это поможет.

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

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

Я также вижу, что вы установили bindaddr=0.0.0.0 в вашем файле конфигурации Asterisk, что заставляет Asterisk прослушивать все доступные интерфейсы. Сколько IP-адресов у этого сервера? Если у него более 1 IP-адреса, вам необходимо указать их все в правилах брандмауэра, поскольку в настоящее время вы указываете только xx.xx.xx.xx в качестве IP-адреса назначения для блокировки входящего трафика на порт 5060.