 'Зависание' регистрации SIP-фонов через iptables,  jimmhockins, 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 Заранее спасибо
|
- 'Зависание' регистрации SIP-фонов через iptables, keir, 21:09 , 04-Июл-16 (1)
Все же черным по белому.
Все, что после правила 9 - бесполезно, а значит 10, 11, 12 не работают, хотя и нужны для sip.
- 'Зависание' регистрации SIP-фонов через iptables, jimmhockins, 11:02 , 05-Июл-16 (2)
> Все же черным по белому.
> Все, что после правила 9 - бесполезно, а значит 10, 11, 12
> не работают, хотя и нужны для sip.Спасибо. Помогло. Я это правило вообще не приметил...
Впредь буду внимательнее :)
- 'Зависание' регистрации SIP-фонов через iptables, keir, 11:04 , 05-Июл-16 (3)
> Спасибо. Помогло. Я это правило вообще не приметил...
> Впредь буду внимательнее :) Правило 9 должно быть последним в таблице. В данном случае его цель залогировать неразрешенное обращение и дропнуть пакет. Посмотрите в логи (syslog) - там должна появляться информация о сброшенных пакетах.
- 'Зависание' регистрации SIP-фонов через iptables, jimmhockins, 11:09 , 05-Июл-16 (4)
>> Спасибо. Помогло. Я это правило вообще не приметил...
>> Впредь буду внимательнее :)
> Правило 9 должно быть последним в таблице. В данном случае его цель
> залогировать неразрешенное обращение и дропнуть пакет. Посмотрите в логи (syslog) -
> там должна появляться информация о сброшенных пакетах. да, спасибо. уже переместил и проверил логи. пришлось сымитировать, потому что "атак"
пока нет))) жду решения по выбору сип-оператора и тогда уже буду наружу выпускать.
- 'Зависание' регистрации SIP-фонов через iptables, AS, 14:52 , 07-Июл-16 (5)
>>> Спасибо. Помогло. Я это правило вообще не приметил...
>>> Впредь буду внимательнее :)
>> Правило 9 должно быть последним в таблице. В данном случае его цель
>> залогировать неразрешенное обращение и дропнуть пакет. Посмотрите в логи (syslog) -
>> там должна появляться информация о сброшенных пакетах.
> да, спасибо. уже переместил и проверил логи. пришлось сымитировать, потому что
> "атак"
> пока нет))) жду решения по выбору сип-оператора и тогда уже буду наружу
> выпускать.если наружу - рекомендую посмотреть еще и на http://linux.mixed-spb.ru/asterisk/fail2ban_setup.php
без него реально ж*па
- 'Зависание' регистрации SIP-фонов через iptables, jimmhockins, 16:38 , 07-Июл-16 (6)
>[оверквотинг удален]
>>>> Впредь буду внимательнее :)
>>> Правило 9 должно быть последним в таблице. В данном случае его цель
>>> залогировать неразрешенное обращение и дропнуть пакет. Посмотрите в логи (syslog) -
>>> там должна появляться информация о сброшенных пакетах.
>> да, спасибо. уже переместил и проверил логи. пришлось сымитировать, потому что
>> "атак"
>> пока нет))) жду решения по выбору сип-оператора и тогда уже буду наружу
>> выпускать.
> если наружу - рекомендую посмотреть еще и на http://linux.mixed-spb.ru/asterisk/fail2ban_setup.php
> без него реально ж*па как раз доковыриваю пока время есть.. про китайцев звонящих на кубу наслышан :)
- 'Зависание' регистрации SIP-фонов через iptables, AS, 20:41 , 07-Июл-16 (7)
> как раз доковыриваю пока время есть.. про китайцев звонящих на кубу наслышан
> :) ну и уж еще тогда http://ari.asterisk.org/
я вон интеграционную щину попинать -
там потом из всяких скриптов можно очень просто делать,
чтоб Астер тебе проговаривал, что не так curl -X POST .... и всего
делов-то параметры туда передать....
- 'Зависание' регистрации SIP-фонов через iptables, keir, 14:41 , 08-Июл-16 (8)
По поводу выпуска наружу:
fail2ban и прочее это конечно хорошо, но этой борьбы с последствиями сканов и переборов можно избежать - для оператора 5060 вывешивается наружу только для операторского ip, а для внешних клиентов используется альтернативный порт. Хоть 50600. На других портах астериск никто не ищет.
- 'Зависание' регистрации SIP-фонов через iptables, jimmhockins, 15:14 , 08-Июл-16 (9)
> По поводу выпуска наружу:
> fail2ban и прочее это конечно хорошо, но этой борьбы с последствиями сканов
> и переборов можно избежать - для оператора 5060 вывешивается наружу только
> для операторского ip, а для внешних клиентов используется альтернативный порт. Хоть
> 50600. На других портах астериск никто не ищет.ну я собственно так и хотел сделать - пробросить за нат 5060 для SIP-IP only(с конкретными айпи операторов их будет 2).. но.. порт стопицот тыщ триста сорок затертый я то могу выделить и пробросить для входящих пиров. поможет ли это от портсканнеров? т.е. есть ли смысл вообще с этим заморачиваться если мало-мальски опытный админ просто отсканит весь диапазон и найдет открытый на вход порт for all?
- 'Зависание' регистрации SIP-фонов через iptables, keir, 15:57 , 08-Июл-16 (10)
> ну я собственно так и хотел сделать - пробросить за нат 5060
> для SIP-IP only(с конкретными айпи операторов их будет 2).. но.. порт
> стопицот тыщ триста сорок затертый я то могу выделить и пробросить
> для входящих пиров. поможет ли это от портсканнеров? т.е. есть ли
> смысл вообще с этим заморачиваться если мало-мальски опытный админ просто отсканит
> весь диапазон и найдет открытый на вход порт for all?Основная цель смены порта - защитить сервис от автоматических сканеров, а они как раз ходят по стандартным портам, пытаются подобрать известные уязвимости/перебрать пароли и лишний раз расходуют ресурсы сервера.
Ясное дело, что если сервер станет целью человека, то смена порта не сильно спасет.
|
Версия для распечатки
