The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  вход/выход  слежка  RSS
"'Зависание' регистрации SIP-фонов через iptables"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Информационная безопасность (Linux iptables, ipchains / Linux)
Изначальное сообщение [ Отслеживать ]

"'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от jimmhockins email(ok) on 04-Июл-16, 16:12 
Имеется:
ОС - CentOS 7 (SELinux - отключено, firewalld - отключено)
На нем поднят и настроен Asterisk 1.8. Пока только на внутреннюю связь, т.е. звонки ходят в локалке. Сетевой интерфейс 1 с локальным адресом.
Развернут домен (на другом сервере), Астериск находится в нем.
В качестве "звонилок" используется Zoiper как в виде приложений для Win(на рабочих станциях), так и в виде приложений Android (на телефонах).
Соответственно настроен iptables под SIP и SSH.
Происходит следующее:
Уходя вечером выключается комп с установленным Zoiper, а мобильный гасит его сам при выходе из зоны WiFi. Утром включается комп, запускается Zoiper на компе и параллельно при подключении к WiFi на мобильном. Оба сообщают о тайм-ауте регистрации и звонки соответственно не ходят. Консоль Астериска показывает что пиры не зарегистрированы. Делаю: service iptables stop - телефоны тут же регистрируются, звонки начинают ходить.
Далее: service iptables start - все в порядке, телефоны в системе, звонки ходят. и так до очередного отключения Zoiper'ов на срок более 15 мин( периодически выхожу покурить и мобильный выходит из зоны вайфая, по возвращении и переподключении вайфая телефон нормально регистрируется, большее время не пробовал).
Вопрос - куда копать. правила файервола прилагаю.

Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
2        2   290 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:50000:65000
3      260 84282 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
4        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
5        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW
6        3   156 ACCEPT     tcp  --  ens32  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25356
7        0     0 ACCEPT     udp  --  ens32  *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
8        0     0 ACCEPT     udp  --  ens32  *       0.0.0.0/0            0.0.0.0/0            udp dpt:123
9     2322  226K undef_in   all  --  *      *       0.0.0.0/0            0.0.0.0/0
10       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060
11       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5061
12       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:10000:20000
13       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:4569
14       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:5038
15       0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060 STRING match  "friendly-scanner" ALGO name bm TO 65535
16       0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060 STRING match  "sip-scan" ALGO name bm TO 65535
17       0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060 STRING match  "sundayddr" ALGO name bm TO 65535
18       0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060 STRING match  "iWar" ALGO name bm TO 65535
19       0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060 STRING match  "sipsak" ALGO name bm TO 65535
20       0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060 STRING match  "sipvicious" ALGO name bm TO 65535
21       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x06/0x02 TCPMSS clamp to PMTU
2        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
3        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
4        0     0 undef_fw   all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
2      212 83836 ACCEPT     all  --  *      ens32   0.0.0.0/0            0.0.0.0/0
3        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
4        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW
5        0     0 undef_out  all  --  *      *       0.0.0.0/0            0.0.0.0/0
6        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25
7        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25

Chain undef_fw (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 6 prefix "-- FW -- DROP "
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain undef_in (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1     2322  226K LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 6 prefix "-- IN -- DROP "
2     2322  226K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain undef_out (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 6 prefix "-- OUT -- DROP "
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Заранее спасибо

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по ответам | RSS]

1. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от keir (ok) on 04-Июл-16, 21:09 
Все же черным по белому.
Все, что после правила 9 - бесполезно, а значит 10, 11, 12 не работают, хотя и нужны для sip.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от jimmhockins email(ok) on 05-Июл-16, 11:02 
> Все же черным по белому.
> Все, что после правила 9 - бесполезно, а значит 10, 11, 12
> не работают, хотя и нужны для sip.

Спасибо. Помогло. Я это правило вообще не приметил...
Впредь буду внимательнее :)

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от keir (ok) on 05-Июл-16, 11:04 
> Спасибо. Помогло. Я это правило вообще не приметил...
> Впредь буду внимательнее :)

Правило 9 должно быть последним в таблице. В данном случае его цель залогировать неразрешенное обращение и дропнуть пакет. Посмотрите в логи (syslog) - там должна появляться информация о сброшенных пакетах.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от jimmhockins email(ok) on 05-Июл-16, 11:09 
>> Спасибо. Помогло. Я это правило вообще не приметил...
>> Впредь буду внимательнее :)
> Правило 9 должно быть последним в таблице. В данном случае его цель
> залогировать неразрешенное обращение и дропнуть пакет. Посмотрите в логи (syslog) -
> там должна появляться информация о сброшенных пакетах.

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от AS email(??) on 07-Июл-16, 14:52 
>>> Спасибо. Помогло. Я это правило вообще не приметил...
>>> Впредь буду внимательнее :)
>> Правило 9 должно быть последним в таблице. В данном случае его цель
>> залогировать неразрешенное обращение и дропнуть пакет. Посмотрите в логи (syslog) -
>> там должна появляться информация о сброшенных пакетах.
>  да, спасибо. уже переместил и проверил логи. пришлось сымитировать, потому что
> "атак"
> пока нет))) жду решения по выбору сип-оператора и тогда уже буду наружу
> выпускать.

если наружу - рекомендую посмотреть еще и на http://linux.mixed-spb.ru/asterisk/fail2ban_setup.php
без него реально ж*па

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от jimmhockins email(ok) on 07-Июл-16, 16:38 
>[оверквотинг удален]
>>>> Впредь буду внимательнее :)
>>> Правило 9 должно быть последним в таблице. В данном случае его цель
>>> залогировать неразрешенное обращение и дропнуть пакет. Посмотрите в логи (syslog) -
>>> там должна появляться информация о сброшенных пакетах.
>>  да, спасибо. уже переместил и проверил логи. пришлось сымитировать, потому что
>> "атак"
>> пока нет))) жду решения по выбору сип-оператора и тогда уже буду наружу
>> выпускать.
> если наружу - рекомендую посмотреть еще и на http://linux.mixed-spb.ru/asterisk/fail2ban_setup.php
> без него реально ж*па

как раз доковыриваю пока время есть.. про китайцев звонящих на кубу наслышан :)

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от AS email(??) on 07-Июл-16, 20:41 
> как раз доковыриваю пока время есть.. про китайцев звонящих на кубу наслышан
> :)

ну и уж еще тогда http://ari.asterisk.org/
я вон интеграционную щину попинать -
там потом из всяких скриптов можно очень просто делать,
чтоб Астер тебе проговаривал, что не так curl -X POST .... и всего
делов-то параметры туда передать....

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от keir (ok) on 08-Июл-16, 14:41 
По поводу выпуска наружу:
fail2ban и прочее это конечно хорошо, но этой борьбы с последствиями сканов и переборов можно избежать - для оператора 5060 вывешивается наружу только для операторского ip, а для внешних клиентов используется альтернативный порт. Хоть 50600. На других портах астериск никто не ищет.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от jimmhockins email(ok) on 08-Июл-16, 15:14 
> По поводу выпуска наружу:
> fail2ban и прочее это конечно хорошо, но этой борьбы с последствиями сканов
> и переборов можно избежать - для оператора 5060 вывешивается наружу только
> для операторского ip, а для внешних клиентов используется альтернативный порт. Хоть
> 50600. На других портах астериск никто не ищет.

ну я собственно так и хотел сделать - пробросить за нат 5060 для SIP-IP only(с конкретными айпи операторов их будет 2).. но.. порт стопицот тыщ триста сорок затертый я то могу выделить и пробросить для входящих пиров. поможет ли это от портсканнеров? т.е. есть ли смысл вообще с этим заморачиваться если мало-мальски опытный админ просто отсканит весь диапазон и найдет открытый на вход порт for all?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "'Зависание' регистрации SIP-фонов через iptables"  +/
Сообщение от keir (ok) on 08-Июл-16, 15:57 
> ну я собственно так и хотел сделать - пробросить за нат 5060
> для SIP-IP only(с конкретными айпи операторов их будет 2).. но.. порт
> стопицот тыщ триста сорок затертый я то могу выделить и пробросить
> для входящих пиров. поможет ли это от портсканнеров? т.е. есть ли
> смысл вообще с этим заморачиваться если мало-мальски опытный админ просто отсканит
> весь диапазон и найдет открытый на вход порт for all?

Основная цель смены порта - защитить сервис от автоматических сканеров, а они как раз ходят по стандартным портам, пытаются подобрать известные уязвимости/перебрать пароли и лишний раз расходуют ресурсы сервера.
Ясное дело, что если сервер станет целью человека, то смена порта не сильно спасет.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру