Asterisk + fail2ban

Интеграция fail2ban и cisco log

# cat /etc/fail2ban/jail.d/cisco-change-config.conf

enabled  = true
maxretry = 1
bantime  = 30
filter   = cisco-change-config
logpath  = /var/log/cisco.log
action   = cisco-backup-config

# cat /etc/fail2ban/filter.d/cisco-change-config.conf

failregex = <HOST>.*Configured from.*

# cat /etc/fail2ban/action.d/cisco-backup-config.conf

actionban = /usr/bin/sshpass -p cisco /usr/bin/scp <ip>:running-config /srv/tftp/<ip>-running-config
            cd /srv/tftp/
            /usr/bin/git add *
            /usr/bin/git --no-optional-locks status | grep 'modified\|deleted\|new file' | /usr/bin/git commit -a -F -

Отправка логов syslog на удаленный сервер

Теперь идем на добавленные в syslog-ng сервера и настраиваем там отправку логов на наш сервер. Сделать это очень просто. Открываем файл конфигурации rsyslog. В CentOS он живет по адресу /etc/rsyslog.conf и добавляем туда строку:

*.* @10.1.3.22

10.1.3.22 — ip адрес syslog-ng сервера. Перезапустите rsyslog:

# service rsyslog restart

и проверяйте логи на сервере syslog-ng в указанной папке. Правило *.* отправит все логи в указанное направление. Это не всегда нужно, можно отредактировать правила. Для этого надо ознакомиться с документацией по syslog. Там нет ничего сложного, мне не хочется на этом сейчас подробно останавливаться. В интернете есть примеры. Приведу пару своих.

*.*;local5.none @10.1.3.22

В данном случае у меня по local5.notice идет лог самбы по доступу к сетевой шаре. Мне не нужно собирать эту информацию и я ее отключил. Вот еще пример:

*.info @10.1.3.22

С этого сервера сыпалось много лишней информации уровня debug. Я ограничил отправляемые сообщения уровнем info. И так далее.

Настройкаизоляторовдля

Теперьнамнеобходимосоздатьописаниятакназываемых»изоляторов»дляте»привязать»нашифильтрыкобъяснитьвкакихфайлахэтистрокиискатьичтопотомделать

Дляэтогооткройтефайл

1. УбедитесьчтонетилиневключенодругихправилсвязанныхсДляэтогодостаточносделатьпоискпофайлупоимени»»безкавычекиубедитьсячтоеслитакиеправилаестьдлякаждогоизнихсвойствоустановленов
2. ВслучаеесливерсияменьшейлибоВынехотитеиспользоватьлогииспользованиелоговкрайнерекомендуетсятоВамдостаточнобудетсоздатьтолькоодноправилоВпротивномслучаеВампонадобитсясоздатьправила

Правило№

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

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

Правило№

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

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

Monitoring Status

You can monitor the status of your configured outbound registrations via the CLI and the Asterisk Manager Interface. From the CLI, you can issue the command  to list all outbound registrations. Here is an example of what you might see:

On this particular Asterisk instance, there are two outbound registrations configured. The headers at the top explain what is in each column. The «Status» can be one of the following values:

• Unregistered: Asterisk is currently not registered. This is most commonly seen when the registration has not yet been established. This can also be seen when the registration has been forcibly unregistered or if the registration times out.
• Registered: Asterisk has successfully registered.
• Rejected: Asterisk attempted to register but a failure occurred. See the above section for more information on failures that may occur.
• Stopped: The outbound registration has been removed from configuration, and Asterisk is attempting to unregister.

In addition, you can see the details of a particular registration by issuing the  command. If I issue , I see the following:

This provides the same status line as before and also provides the configured values for the outbound registration.

AMI provides the  command that provides the same information as the CLI commands. Here is an example of executing the command in an AMI session:

The command sends  events for each configured outbound registration. Most information is the same as the CLI displays, but there is one additional piece of data displayed: NextReg. This is the number of seconds until Asterisk will send a new REGISTER request to the registrar. In this particular scenario, that number is 0 because the two outbound registrations have reached their maximum number of retries.

Asterisk: Авторизация у провайдера по IP – адресу

Некоторые категории SIP провайдеров предоставляют авторизацию на своем софтсвиче по IP – адресу. Это означает, что только лишь получив запрос с выделенного IP – адреса, провайдер позволит Вам совершать и принимать звонки. О том, как настроить авторизацию у провайдера без регистрации по IP – адресу на Asterisk при помощи FreePBX 13 расскажем в статье.

Что мы имеем

Итак, предположим, провайдер связи предоставляет нам 1 SIP номер с авторизацией по IP. Адрес софтсвича будет 33.33.44.45. Помимо этого, провайдера выделяет нам подсеть 11.22.33.44/30. В это сети:

1. 11.22.33.47 — широковещательный адрес
2. 11.22.33.46 — адрес шлюза по умолчанию
3. 11.22.33.45 — адрес, который провайдер выделяет нам для настройки на нашем Asterisk
4. 11.22.33.44 — IP адрес сети

На нашем Asterisk уже существует текущее сетевое подключение через единственный NIC (Network Interface Card, сетевая карта). Для установки дополнительного IP, нам нужно будет добавить дополнительную сетевую карту, либо добавить виртуальный интерфейс (например, eth0:0). В нашем случае, в лаборатории, наш Asterisk развернут на виртуальной машине VmWare, поэтому, мы просто добавим виртуальный vNIC.

После добавления интерфейса, мы назначим ему IP – адрес 11.22.33.45 и создадим маршрут, в котором укажем отправлять весь трафик в сторону софтсвича 33.33.44.45 через новый интерфейс (eth1). Итак, переходим к настройке.

Настройка в консоли

Первым делом подключимся к консоли (CLI) нашего сервера IP – АТС. После добавления нового интерфейса, переходим к его настройке. Вводим команду:

Нажимаем «o» для редактирования и указываем следующие параметры:

Нажимаем «:x!» и сохраняем изменения. После этого перезагружаем сетевую службу командой:

Отлично. Оба сетевых интерфейса поднялись и работают. Теперь давайте настроим маршрут для отправки трафика в сторону софтсвича через интерфейс eth1. Для этого, откройте для редактирования файл маршрута следующей командой:

В файл добавляем следующую строчку:

Делаем рестарт сетевой службы командой service network restart и проверяем маршруты:

Отлично, у нас появился нужный нам маршрут. Проверить его так же можно сделав трассировку, командой traceroute 33.33.44.45

Настройка транка в FreePBX

После того, как мы настроили маршруты и интерфейсы в операционной системе CentOS, переходим к настройке транка в графическом интерфейса FreePBX. Для этого, перейдем в раздел настроек Connectivity → Trunks и нажмем + Add Trunk, добавив SIP – транк. Заполняем любое значение в поле Trunk Name вкладки General и переходим к вкладке SIP Settings → Outgoing. Здесь, в поле Trunk Name укажите out, а в разделе PEER Details следующие параметры:

Нажимаем Submitи Apply Config. На этом все, остается только настроить маршрутизацию вызовов и можно звонить

Возможные проблемы

Если при звонке на номер вы слышите короткие гудки, а в логах и дебаге Вы видите следующее сообщение:

То перейдите в раздел настроек Settings → Asterisk SIP Settings, выберите вкладку Chan SIP Settings и убедитесь, что параметр Bind Port указан как 5060.

Снова Asterisk или надоели господа из оккупированных палестинских территорий

установив Asterisk 10 столкнулся с проблемой — в логи сыпятся сообщения о том, что некий девайс пытался зарегистрироваться с моим внешним IP. Отбросив море какашек в форумах — «типа сам дурак» и «чо гугл отменили?», а так же «iptables настроить не можешь ?», пылесосенье интернета дало результаты.

Естественно правило fail2ban сработает только блокировкой внешнего IP Asterisk. Здесь на форуме предлагали лекарство правкой исходника, но оно не работает на 1.8. Открыв исходник chan_sip.c, можно увидеть в нескольких местах строчки: Код:ast_log(LOG_NOTICE, «Sending fake auth rejection for device %s\n», get_header(req, «From»));

Поиском по форуму digium, нашлось решение. Заменил в исходнике вышеуказанные строчки на вот такую конструкцию:Код:ast_log(LOG_NOTICE, «Sending fake auth rejection for device %s (%s)\n», get_header(req, «From»), ast_sockaddr_stringify(addr));

Правило в /etc/fail2ban/filter.d/asterisk.conf:  Код: NOTICE.* .*: Sending fake auth rejection for device.* \(<HOST>:.*\)

Теперь палестинцы успешно отправляются в бан. Возможно есть ошибка в решении вопроса, поправьте пожалуйста.

От себя добавлю что механика изменений оч проста, достаточно в местах в chan_sip.c исправить логирование и вот вам счастье

Обратите внимание когда будете править, что в ряде мест не «Sending fake auth rejection for device», а «Failed to authenticate device». У меня получалось что-то вроде :

if (res == AUTH_FAKE_AUTH) {

ast_log(LOG_NOTICE, «Sending fake auth rejection for device %s (%s)\n», sip_get_header(req, «From»), ast_sockaddr_stringify(addr));

transmit_fake_auth_response(p, SIP_SUBSCRIBE, req, XMIT_UNRELIABLE);

} else {

ast_log(LOG_NOTICE, «Failed to authenticate device %s for SUBSCRIBE (%s)\n», sip_get_header(req, «From»), ast_sockaddr_stringify(addr));

transmit_response_reliable(p, «403 Forbidden», req);

}

Далее три шага: запускаем еще раз make, копируем chan_sip.so в папочку с модулями и перегружаем астериск. Радостно наблюдаем растущий список fail2ban.

конечно везде рекомендуемое решение не помешает:

iptables -A INPUT -p udp —dport 5060 -m recent —update —seconds 2 —hitcount 60 —name SIP \

-j LOG —log-prefix «SIP flood detected: «

У этого решения есть недостаток, некоторые устройства заносятся в флуд, например Panasonic Sip-Dect.  Я хочу конкретно знать, что за гадина и откуда лезет. 

You have no rights to post comments

Настройка правил фильтрации

Теперь нам необходимо создать фильтр, который будет извлекать из общего потока сообщений астериска потенциально опасные события (неверный логин/пароль, попытка входа с неразрешенного IP адреса, и т.д. и т.п.). При этом нам необходимо не только обнаруживать такие потенциально опасные события, но и вычленять оттуда IP адрес, с которого было выполнено действие. То есть мы не просто ищем определенные строки в файлах событий астериска, а настраиваем правила фильтрации.
Правила фильтрации можно прописать в файле /etc/fail2ban/filter.d/asterisk.conf. Вот образец содержимого этого файла:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#



# Read common prefixes. If any customizations available -- read them from
# common.local
#before = common.conf




#_daemon = asterisk

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P\S+)
# Values:  TEXT
#

# Asterisk 1.8 uses Host:Port format which is reflected here

failregex = NOTICE.* .*: Registration from '.*' failed for ':.*' - Wrong password
            NOTICE.* .*: Registration from '.*' failed for ':.*' - No matching peer found
            NOTICE.* .*: Registration from '.*' failed for ':.*' - Username/auth name mismatch
            NOTICE.* .*: Registration from '.*' failed for ':.*' - Device does not match ACL
            NOTICE.* .*: Registration from '.*' failed for ':.*' - Not a local domain
            NOTICE.* .*: Registration from '.*' failed for ':.*' - Peer is not supposed to register
            NOTICE.* .*: Registration from '.*' failed for ':.*' - ACL error (permit/deny)
            NOTICE.* .*: Registration from '.*' failed for '' - Wrong password
            NOTICE.* .*: Registration from '.*' failed for '' - No matching peer found
            NOTICE.* .*: Registration from '.*' failed for '' - Username/auth name mismatch
            NOTICE.* .*: Registration from '.*' failed for '' - Device does not match ACL
            NOTICE.* .*: Registration from '.*' failed for '' - Not a local domain
            NOTICE.* .*: Registration from '.*' failed for '' - Peer is not supposed to register
            NOTICE.* .*: Registration from '.*' failed for '' - ACL error (permit/deny)
            NOTICE.* .*: Registration from '\".*\".*' failed for ':.*' - No matching peer found
            NOTICE.* .*: Registration from '\".*\".*' failed for ':.*' - Wrong password
            NOTICE.* .*: No registration for peer '.*' \(from \)
            NOTICE.* .*: Host  failed MD5 authentication for '.*' (.*)
            NOTICE.* .*: Failed to authenticate user .*@.*
            NOTICE.*  failed to authenticate as '.*'$
            NOTICE.* .*: Sending fake auth rejection for device .*\<sip:.*\@\>;tag=.*
            NOTICE.* .*:  tried  to authenticate with nonexistent user '.*'
            VERBOSE.*SIP/-.*Received incoming SIP connection from unknown peer

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

В asterisk версии 1.4 и более ранних используются строки типа “… failed for ‘<HOST>’ …”, а в asterisk 1.8 и выше – строки “… failed for ‘<HOST>:.*’ …”, поскольку начиная с версии asterisk 1.8 в логах появилась информация о номере порта, которой нет в asterisk 1.4. Приведенный выше вариант учитывает как старые, так и новые версии asterisk, так что Вам нет необходимости в нем что-либо менять.

Для asterisk версии 10 и выше, если Вы включили ведение логов security, не забудьте прописать правила фильтрации для этих логов!

Правила фильтрации можно прописать в файле /etc/fail2ban/filter.d/asterisk-security.conf. Вот образец содержимого этого файла:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#



# Read common prefixes. If any customizations available -- read them from
# common.local
#before = common.conf




#_daemon = asterisk

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P\S+)
# Values:  TEXT
#

failregex = SECURITY.* SecurityEvent="FailedACL".*RemoteAddress=".+?/.+?//.+?".*
            SECURITY.* SecurityEvent="InvalidAccountID".*RemoteAddress=".+?/.+?//.+?".*
            SECURITY.* SecurityEvent="ChallengeResponseFailed".*RemoteAddress=".+?/.+?//.+?".*
            SECURITY.* SecurityEvent="InvalidPassword".*RemoteAddress=".+?/.+?//.+?".*

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Дополнительные материалы

Аsterisk failregex от Владимира Блинова

# less filter.d/asterisk.conf

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf



# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>\S+)
# Values:  TEXT
#
failregex = NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Wrong password
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - No matching peer found
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - No matching peer found
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Username/auth name mismatch
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Device does not match ACL
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Peer is not supposed to register
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - ACL error (permit/deny)
            NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Device does not match ACL
            NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>:.*' - No matching peer found
            NOTICE.* .*: Registration from '\".*\".*' failed for '<HOST>:.*' - Wrong password
            NOTICE.* <HOST> failed to authenticate as '.*'$
            NOTICE.* .*: No registration for peer '.*' \(from <HOST>\)
            NOTICE.* .*: Host <HOST> failed MD5 authentication for '.*' (.*)
            NOTICE.* .*: Failed to authenticate user .*@<HOST>.*
            NOTICE.* .*: <HOST> failed to authenticate as '.*'
            NOTICE.* .*: <HOST> tried  to authenticate with nonexistent user '.*'
            VERBOSE.*SIP/<HOST>-.*Received incoming SIP connection from unknown peer
        NOTICE.* .*: Sending fake auth rejection for device.* \(<HOST>:.*\)
        NOTICE.* .*: Sending fake auth rejection for device .*\<sip:.*\@.*\>;tag=.* \(<HOST>:.*\)
        NOTICE.* .*: Failed to authenticate device .*\<sip:.*\@.*\>;tag=.* \(<HOST>:.*\)
            NOTICE.* .*: Sending fake auth rejection for device.* \(<HOST>:.*\)
            NOTICE.* .*: Sending fake auth rejection for device .*\;tag=.* \(<HOST>:.*\)


# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Аsterisk failregex от Стрельникова Романа

failregex = SECURITY.* SecurityEvent="FailedACL".*RemoteAddress=".+?/.+?/<HOST>/.+?".*
            SECURITY.* SecurityEvent="InvalidAccountID".*RemoteAddress=".+?/.+?/<HOST>/.+?".*
            SECURITY.* SecurityEvent="ChallengeResponseFailed".*RemoteAddress=".+?/.+?/<HOST>/.+?".*
            SECURITY.* SecurityEvent="InvalidPassword".*RemoteAddress=".+?/.+?/<HOST>/.+?".*

Asterisk cannot find the specified extension

If you are seeing a message like the following on your CLI when you place an incoming call:

then it means that Asterisk was not able to direct the incoming call to an appropriate extension in the dialplan. In the case above, I dialled «456789» on the phone that corresponds with endpoint 201. Endpoint 201 is configured with  and the «default» context in my dialplan does not have an extension «456789».

The NOTICE message can be helpful in this case, since it tells what endpoint the call is from, what extension it is looking for, and in what context it is searching. Here are some helpful tips to be sure that calls are being directed where you expect:

• Be sure that the endpoint has the expected context configured. Be sure to check spelling.
• Be sure that the extension being dialled exists in the dialplan. From the Asterisk CLI, run  to see the extensions for a particular context. If the extension you are dialing is not listed, then Asterisk does not know about the extension.
  • Ensure that if you have modified  recently that you have saved your changes and issued a  from the Asterisk CLI.
  • Ensure that the extension being dialled has a 1 priority.
  • Ensure the the extension being dialled is in the expected dialplan context.

ARGH! NAT!

NAT is objectively terrible. Before having a look at this section, have a look at this page to be sure that you understand the options available to help combat the problems NAT can cause.

NAT can adversely affect all areas of SIP calls, but we’ll focus for now on how they can negatively affect the ability to allow for incoming calls to be set up. The most common issues are the following:

• Asterisk routes responses to incoming SIP requests to the wrong location.
• Asterisk gives the far end an unroutable private address to send SIP traffic to during the call.

Asterisk sends traffic to unroutable address

The endpoint option that controls how Asterisk routes responses is . By default, this option is enabled and causes Asterisk to send responses to the address and port from which the request was received. This default behavior works well when Asterisk is on a different side of a NAT from the device that is calling in. Since Asterisk presumably cannot route responses to the device itself, Asterisk instead routes the response back to where it received the request from.

Asterisk gives unroutable address to device

By default, Asterisk will place its own IP address into Contact headers when responding to SIP requests. This can be a problem if the Asterisk server is not routable from the remote device. The , , and  transport options can assist in preventing this. By setting these options, Asterisk can detect an address as being a «local» address and replace them with «external» addresses instead.

Проверкаработы

ГлавноевпроцессепроверкииметьподрукойдругойкомпьютерилилокальныйдоступксерверучтобывслучаекогдазаблокируетВашадресВысмоглиподключитьсяиудалитьэтублокировку

НеобходимообязательнопроверитьработусвязкипосколькудажееслиВывсенастроилиилископировалиправильновозможномножествокомбинацийсобытийврезультатекоторыхнастренныеВамиблокировкиработатьнебудут

Последовательностьдействийдляпроверкиработысвязки

УбедитесьчтоуВаснастроензапускипристартекомпьютера
ЕслиВынастроилиправиладлянастоятельнорекомендуемпроверитьработукаждогоизнихпоотдельностиДляэтогоотключитеодноизправилнапример
перезагрузитекомпьютерипроверьтечтослужбыизапущены
одноизправилвключеноадругоевыключеноПриэтомдлявыключенногоправилапоявитсясообщениеадлявключенногосообщениевида

ЗапуститеклиентобязательнонессамогосервераасдругогокомпьютераиуказавневерныеданныедляавторизацииадресдляподключениядолженбытьадресомсерверапопробуйтеавторизоватьсяразаилиболееколичествоавторизацийпослекоторыхадресблокируетсязадаетсявпараметредлякаждогоправилаотдельноВкачестветестовогоклиентаможноиспользоватьпрограммукотораяработаетизкоманднойстроки
ЕслиВызапустиликлиентастогожекомпьютераскоторогоподключалиськсерверуиеслибылинастроеныправильнотонаданныймоментВашадресзаблокированиВынеможетеподключитьсяксерверусэтогокомпьютерапроверьтеэтоПодключитеськсдругогокомпьютераилилокальноипродолжайтевыполнениекоманд
Запуститекомандувидадлявключенногоправилаиубедитесьчтоадресскоторогоподключалсяклиентнаходитсявспискезаблокированных
Теперьпоаналогиисдействиямиизпунктаразблокируйтевтороеправилонапримеризаблокируйтепервое
ВыполнитедействияспунктапопункттольковместоперезагрузкикомпьютерачтотожеможносделатьдостаточноперезагрузитьслужбуПослеэтогосразуразблокируетсяадрескомпьютеранакоторомВызапускаликлиентиегоможнобудетинужнокаквпунктезапуститьещераздляпроверкиработывторогоправилаОбратитевниманиечтоможетинеразблокироватьточнееразблокироватьисновазаблокироватьвэтомслучаеВамлучшесделатьпаузусекундпослечегоещеразперезагрузитьсервис
ПослетогокакВыпроверилиработуобоихправилпоотдельностинезабудьтеобязательновключитьихобадляидляпараметрПослеэтогоразумеетсянезабудьтеперезагрузитьсервис
ИпоследнийпунктеслиВывыполнилипредыдущиепунктыдостаточнобыстровтечениенесколькихминуттоможетоказатьсячтопослевключенияобоихправилипоследующейперезагрузкиуВассновазаблокируетсяадресскоторогоВызапускаликлиентаБудьтевнимательны

Temporary and Permanent Failures

Whenever Asterisk sends an outbound registration and receives some sort of failure response from the registrar, Asterisk makes a determination about whether a response can be seen as a permanent or temporary failure. The following responses are always seen as temporary failures:

• No Response
• 408 Request Timeout
• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Server Timeout
• Any 600-class response

In addition, there is an option called  that can be used to determine if authentication-related rejections from a registrar are treated as permanent or temporary failures. By default, this option is enabled, but disabling the setting means the following two responses are also treated as temporary failures:

• 401 Unauthorized
• 407 Proxy Authentication Required

What is meant by temporary and permanent failures? When a temporary failure occurs, Asterisk may re-attempt registering if a  is configured in the outbound registration. The  is the number of seconds Asterisk will wait before attempting to send another REGISTER request to the registrar. By default, outbound registrations have a  of 60 seconds. Another configuration option, , determines how many times Asterisk will attempt to re-attempt registration before permanently giving up. By default,  is set to 10.

Permanent failures result in Asterisk immediately ceasing to re-attempt the outbound registration. All responses that were not previously listed as temporary failures are considered to be permanent failures. There is one exception when it comes to permanent failures. The  can be set such that if Asterisk receives a 403 Forbidden response from a registrar, Asterisk can wait the number of seconds indicated and re-attempt registration. Retries that are attempted in this manner count towards the same  value as temporary failure retries.

Let’s modify our outbound registration to set these options to custom values:

pjsip.conf

type = registration
server_uri = sip:registrar@example.com
client_uri = sip:client@example.com
contact_user = inbound-calls
outbound_auth = provider_auth
auth_rejection_permanent = no
retry_interval = 30
forbidden_retry_interval = 300
max_retries = 20

In general, this configuration is more lenient than the default. We will retry registration more times, we will retry after authentication requests and forbidden responses, and we will retry more often.

Настройка ведения логов asterisk

В первую очередь имеет смысл настроить ведение логов asterisk, чтобы информация сразу же начала собираться в нужном нам формате и виде. Для этого в каталоге конфигурации asterisk (по умолчанию это /etc/asterisk) найдите файл logger.conf и внесите в него следующие изменения: раскомментируйте (уберите точку с запятой в начале строки):

Это нужно для того, чтобы asterisk писал в логи дату в правильном формате:
год-месяц-день часы:минуты:секунды

Начиная с 10-й версии asterisk, Вы можете включить Asterisk Security Framework. Для этого в файле logger.conf найдите и раскомментируйте (или добавьте) строку:

В этой строке с левой стороны от стрелки указано имя файла, в котором будут сохраняться события, а с правой стороны – уровни (типы событий), которые будут сохраняться. В данном примере события, относящиеся к уровню security (и только они), будут сохраняться в файл с именем security в папке логов asterisk.
Разумеется, после внесения изменений необходимо, чтобы asterisk перечитал конфигурацию. Для этого можно либо перезагрузить сервис астериска, либо только конфигурацию логов (logger reload из asterisk CLI).

После этого в папке логов asterisk (по умолчанию /var/log/asterisk) появится файл с именем security. Не забудьте настроить ротацию логов для этого файла (так же, как и для остальных логов asterisk)!

Интеграция fail2ban и snort

# cat /etc/fail2ban/jail.d/snort_jail.conf

enabled     = true
bantime     = 300
filter      = snort_filter
maxretry    = 1
logpath     = /var/log/auth.log
#action      = mail-admin
#action      = iptables-allports-forward
#action      = cisco-acl

# cat /etc/fail2ban/filter.d/snort_filter.conf

failregex = .*snort.*Priority: 1.*} <HOST>.*
#        .*snort.*Priority: 2.*} <HOST>.*

Уведомление по email

# cat /etc/fail2ban/action.d/mail-admin.conf

actionban = printf %%b "Hi,\n
            Ban this <ip>
            Regards,\n
            Fail2Ban"|mail -s " Ban <name> <ip>" <dest>

actionunban = printf %%b "Hi,\n
            Unban this <ip>
            Regards,\n
            Fail2Ban"|mail -s " Unban <name> <ip>" <dest>



name = mail-admin

dest = student

Блокировка через iptables

# cp /etc/fail2ban/action.d/iptables-allports.conf /etc/fail2ban/action.d/iptables-allports-forward.conf

# cat /etc/fail2ban/action.d/iptables-allports-forward.conf

...
before = iptables-common-forward.conf
...

# cp /etc/fail2ban/action.d/iptables-common.conf /etc/fail2ban/action.d/iptables-common-forward.conf

# cat /etc/fail2ban/action.d/iptables-common-forward.conf

...
chain = FORWARD 
...

Блокировка через cisco acl

# cat /root/cisco-acl-deny.sh

#!/bin/sh

fail2ban-client status snort | grep Banned | cut -d':' -f2 | tr -s ' ' | tr " " "\n" |
while read ip
do
        test -z "$ip" && continue
        echo " deny ip host $ip any"
done

# cat /root/cisco-acl-permit.txt

 permit tcp any host 192.168.X.10 eq 80
 permit tcp any host 192.168.X.10 eq 22
 permit icmp any 192.168.0.0 0.0.255.255
 permit ip any host 172.16.1.X
 permit udp any any
 permit tcp any any established
 deny   ip any any # log
end

# cat /root/cisco-change-firewall.sh

#!/bin/sh

cat > /root/firewall.acl <<EOF
no ip access-list extended ACL_FIREWALL
ip access-list extended ACL_FIREWALL
EOF

/root/cisco-acl-deny.sh >> /root/firewall.acl

cat /root/cisco-acl-permit.txt >> /root/firewall.acl

/usr/bin/rcp /root/firewall.acl router:running-config

# cat /etc/fail2ban/action.d/cisco-acl.conf

actionban = /root/cisco-change-firewall.sh

actionunban = /root/cisco-change-firewall.sh
# if atack from DNS)
#actionunban = echo /root/cisco-change-firewall.sh | at now + 1 min

Что такое fail2ban и зачем он нужен для asterisk?

О том, что такое fail2ban, Вы можете прочитать в разделе безопасность Linux. Рассмотрим, зачем fail2ban нужен для защиты asterisk.

Как Вам известно, asterisk является приложением (сервером) для IP-телефонии. То есть позволяет подключившимся к нему клиентам звонить друг другу и во внешний мир, используя (помимо всего прочего) линии телефонной связи. При этом возникают следующие риски:

1. клиенты идентифицируются по логину/паролю, а также (как правило) по IP адресу. При этом существует возможность подобрать пароль (раньше или позже, в зависимости от его сложности, но в любом случае это возможно), причем крайне часто ограничения по IP адресам далеко не такие жесткие, как хотелось бы (в идеале для каждого клиента должен быть свой уникальный IP адрес)
2. входящие звонки из интернета (например, с других серверов asterisk). С этими подключениями все сложнее, поскольку asterisk (в базовой конфигурации) не предусматривает отображение IP адресов, с которых производится подключение.

Программа fail2ban в связке с брандмауэром (например, iptables) и правильно настроенным asterisk (отображающим в логах полную информацию, в том числе IP адреса клиентов и других серверов) позволяет эффективно заблокировать попытки подключения и подбора пароля.

Перед началом настройки Вам необходимо установить iptables и fail2ban. Кроме того, iptables должен быть уже настроен (и разрешать подключения к asterisk) до начала настройки fail2ban! Прочитать, как настроить iptables можно здесь: настройка iptables для работы asterisk. Вы также можете установить fail2ban до установки самого asterisk, и в этом случае (по крайней мере, теоретически) в процессе установки последние версии asterisk обнаруживают установленный fail2ban и настраивают его автоматически. Однако:

1. Не всегда вопрос безопасности IP-телефонии рассматривается до установки asterisk. То есть скорее всего, Вы захотите установить fail2ban на систему с уже установленным (и настроенным) астериском.
2. Не во всех случаях автоматическое конфигурирование срабатывает вообще, не говоря уже о том, чтобы оно сработало правильно (и начало блокировать все атаки на asterisk).