Одна из основных проблем публичного сервиса  IP телефонии  работающего на базе протокола SIP является уязвимость перед DOS или того хуже DDOS атаками или попытками получить несанкционированный доступ к учетным записям пользователей. Универсального средства для отражения подобных атак не существует. Наиболее правильным является использование специализированных элементов в сети VoIP, которые называются пограничные контроллеры сессий или Session Border Controllers(SBC).

Анализ VoIP трафика и защита от DoS атак является одной из функций SBC но далеко не единственной. Пограничные контроллеры сессий анализируют содержимое сообщений не только на нижних уровнях ( реже 2, чаще 3 или 4)но и на 7 уровне модели TCP/IP и не просто анализируют содержимое, а запоминают состояние сессии и прочую информацию об источнике и адресате,  что позволяет интеллектуально выстроить защиту  сервера телефонии и принимать решения относительно тех или иных пакетов.Например, отличить простой запрос о регистрации агента пользователя(User Agent) SIP от попытки определить существует ли учетная запись или подобрать учетные данные, найти уязвимости сервера, получить прочую информацию или просто атаковать сервер множеством запросов для выведения его из строя. Можно сказать, что это файерволл работающий на 7 уровне и адаптированный специально для SIP. Такой функционал может выполняться на отдельном сервере для провайдеров с большой и сложной инфраструктурой или  являться логическим элементов(подсистемой или модулем) в встроенным в сервер телефонии(т.е. функций SBC).  На данный момент чаще встречаются  отдельные и  достаточно сложные программно- аппаратные решения.  Но такие устройства являются специализированными и доступны в основном  VOIP провайдерам или крупным предприятиям, которые готовы выложить круглую сумму за такие устройства.
В обычных IP АТС такой функционал зачастую никак не реализован. Если вы используете сервер телефонии на базе ОС Linux(например Asterisk, Freeswitch или Yate) то для защиты от атак на 3 и 4 уровне можно использовать штатный файервол Linux –iptables. В заметке будет представлено простое решение с использованием iptables, syslog и анализатора журнала файервола.
Для анализа и защиты на 7 уровне использовать утилиту написанную на языке python- Fail2Ban. Принцип защиты с помощью утилиты заключается  в извлечении информации о подозрительной активности  хостов из журналов сервера телефонии  на основе  их анализа используюя регулярные  выражения. Затем, подозрительные хосты заносятся в списки iptables как запрещенные.

В заметке представлен пример настройки iptables позволяющий защитить сервер телефонии от флуда.

Итак, шаг первый- настройка записи событий от iptables в syslog с последующей отправкой в коллектор журналов по сети для последующего анализа:

#vim  /etc/syslog.conf

Добавляем строку

kern.=debug     @192.168.50.50 # отправлять жуналы ядра уровня debug на удаленный хост

Здесь следует учесть что iptables не ведет отдельного журнал а использует для этого журнал ядра, можно лишь указать iptables как помечать сообщения iptables, а затем отправлять сообщения с этой меткой на удаленный хост, к сожалению все остальные события помеченный как debug будут отправляться на удаленный хост!

Мы используем два модуля для iptables:

• • recent – позволяющий огранчить количество пакетов от источника за заданное время.
  • hashlimit – позволяющий сгладить пики интенсивности  поступления пакетов путем ограничения числа пакетов в секунду для каждого из источников.

  Добавляем правила для iptables:

  #iptables -A INPUT -s 172.17.17.1 -d 10.10.10.1 -p udp  --dport 5060 -j ACCEPT -m comment --comment "Ignore packets from trusted host"
  #iptables -A INPUT -s 172.17.17.1 -d 10.10.10.1 -p udp  --dport 5060 -j ACCEPT -m comment --comment "Ignore packets from trusted host"
  #iptables -A INPUT -d 10.10.10.254 -p udp --dport 5060 -m recent --name banned –set
  #iptables -A INPUT -d 10.10.10.254 -p udp --dport 5060 -m recent --name banned --rcheck --seconds 20 --hitcount 255 -j LOG --log-level debug --log-prefix "sip overflowed: "
  #iptables -A INPUT -d 10.10.10.254 -p udp --dport 5060 -m recent --name banned --rcheck --seconds 20 --hitcount 255 -j DROP
  #iptables -N PPSLIMIT
  #iptables -A INPUT -d 10.10.10.254 -p udp --dport 5060 -j PPSLIMIT
  #iptables -A PPSLIMIT -d 10.10.10.254 -p udp --dport 5060 -m hashlimit --hashlimit 35/s --hashlimit-burst 35 --hashlimit-mode srcip --hashlimit-name limit -j ACCEPT
  #iptables -A PPSLIMIT -d 10.10.10.254 -p udp --dport  5060 -j LOG --log-level debug --log-prefix "pps 35 exceeded: "
  #iptables -A PPSLIMIT -d 10.10.10.254 -p udp --dport  5060 -j DROP
  

  Итак сначала мы формируем список хостов с которых пропускаем трафик любой интенсивности.
  Далее устанавливаем счетчик пакетов для каждого хоста. Адреса хостов и счетчиков хранятся в файле /proc/net/ipt_recent/
  Если Вы не указали имя листа(в примере это banned), все все хосты будут помещаться в список по умолчанию DEFAULT

  Работа со списком:
  Добавить хост в список DEFAULT (или списка с произвольным именем)

  echo xx.xx.xx.xx > /proc/net/ipt_recent/DEFAULT

  Удалить хост из списка DEFAULT (или списка с произвольным именем)

  echo -xx.xx.xx.xx > /proc/net/ipt_recent/DEFAULT 

  Очисить список DEFAULT (или списка с произвольным именем)

  echo clear > /proc/net/ipt_recent/DEFAULT

  Далее устанавливаем ограничение на количество пакетов за заданное время, в данном случае 255 пакетов за 15 секунд, если до истечения 15 секунд придет сверх 255, например 256ой- он будет отброшен пока не закончится таймаут и запись о таком  пакете заносится в журнал syslog, который в свою очередь передает её по сети коллектору для анализа.
  Далее если пакетов пришло меньше 255, передаем пакеты на проверку в следующую цепочку где проверим их  интенсивность:
  Все адреса источников заносятся в именованную таблицу(в данном случае limit), она хранится по адресу  /proc/net/ipt_hashlimit/limit. Если пакетов больше 35 за секунду, то 36 и последующие “соскользнут” дальше по цепочке  где по следующему правилу информация о пакете заносится в журнал syslog и  событие передается по сети аналогично предыдущему правилу, последующее  правило отбрасывает пакеты.
  Запись логов необходима для того что бы фиксировать информацию и  анализировать какие хосты превышают лимит и  и в каком объеме. Этим занимается сервер, на который записывается syslog от iptables. Например анализатор логов файервола формирует top-лист нарушителей и рассылает на почту уведомления об источниках и объемах превышения. Таким образом можно следить за превышениями и судить о   природе таких превышений- ошибки на оборудовании клиентов, флуд, попытки получить несанкционированный доступ и т.д.

  Дополнительно, пример настроек iptables для сервера IP телефонии(IP АТС):

  cat /etc/sysconfig/iptables
  
  # Generated by iptables-save v1.3.5 on Mon Jun 9 11:01:52 2008
  *nat
  :PREROUTING ACCEPT [1:60]
  :POSTROUTING ACCEPT [4:466]
  :OUTPUT ACCEPT [4:466]
  COMMIT
  # Completed on Mon Jun 9 11:01:52 2008
  # Generated by iptables-save v1.3.5 on Mon Jun 9 11:01:52 2008
  *mangle
  :PREROUTING ACCEPT [26:2130]
  :INPUT ACCEPT [26:2130]
  :FORWARD ACCEPT [0:0]
  :OUTPUT ACCEPT [26:3174]
  :POSTROUTING ACCEPT [26:3174]
  COMMIT
  # Completed on Mon Jun 9 11:01:52 2008
  # Generated by iptables-save v1.3.5 on Mon Jun 9 11:01:52 2008
  *filter
  :FORWARD ACCEPT [0:0]
  :INPUT DROP [0:0]
  :OUTPUT ACCEPT [0:0]
  # Accept traffic from lo
  -A INPUT -i lo -j ACCEPT
  # Accept traffic from internal interfaces
  -A INPUT ! -i eth0 -j ACCEPT
  # Accept traffic with the ACK flag set
  -A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
  # Allow incoming data that is part of a connection we established
  -A INPUT -m state --state ESTABLISHED -j ACCEPT
  # Allow data that is related to existing connections
  -A INPUT -m state --state RELATED -j ACCEPT
  # Accept responses to DNS queries
  -A INPUT -p udp -m udp --dport 1024:65535 --sport 53 -j ACCEPT
  # Accept responses to our pings
  -A INPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT
  # Accept notifications of unreachable hosts
  -A INPUT -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT
  # Accept notifications to reduce sending speed
  -A INPUT -p icmp -m icmp --icmp-type source-quench -j ACCEPT
  # Accept notifications of lost packets
  -A INPUT -p icmp -m icmp --icmp-type time-exceeded -j ACCEPT
  # Accept notifications of protocol problems
  -A INPUT -p icmp -m icmp --icmp-type parameter-problem -j ACCEPT
  # Allow connections to our SSH server
  -A INPUT -p tcp -m tcp --dport ssh -j ACCEPT
  # Allow connections to our HTTP server
  -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
  # Allow connections to our FTP server
  -A INPUT -p tcp -m tcp --dport ftp -j ACCEPT
  # Allow connections to our IDENT server
  -A INPUT -p tcp -m tcp --dport auth -j ACCEPT
  # Allow connections to our FLASHPOLICY server
  -A INPUT -p tcp -m tcp --dport 843 -j ACCEPT
  # Allow connections to SIP and IAX signalling ports
  -A INPUT -p udp -m udp -m multiport -j ACCEPT --dports 5060,4569
  # Allow connections to RTP ports
  -A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT
  # Allow connections to UDPTL ports
  -A INPUT -p udp -m udp --dport 4000:4999 -j ACCEPT
  # Allow connections to TFTP ports
  -A INPUT -p tcp -m tcp --dport 69 -j ACCEPT
  # Allow connections to TFTP ports
  -A INPUT -p udp -m udp --dport 69 -j ACCEPT
  # Allow connections to SYSLOG ports
  -A INPUT -p udp -m udp --dport 514 -j ACCEPT
  # Respond to pings
  -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
  # Protect our NFS server
  -A INPUT -p tcp -m tcp --dport 2049:2050 -j DROP
  # Protect our X11 display server
  -A INPUT -p tcp -m tcp --dport 6000:6063 -j DROP
  # Protect our X font server
  -A INPUT -p tcp -m tcp --dport 7000:7010 -j DROP
  # Protect our MySQL server
  -A INPUT -p tcp -m tcp --dport 3306 -j DROP
  # Allow connections to unprivileged ports
  -A INPUT -p tcp -m tcp --dport 1024:65535 -j ACCEPT
  COMMIT
  # Completed on Mon Jun 9 11:01:52 2008
  
  

  Похожие материалы:

  • Книга SIP Trunking (SIP транкинг)
  • Безопасность VoIP. Схемы и рекомендации по повышению безопасности.
  • BLUE.BOX- Мультидоменная(Multi-tenant) виртуальная IP АТС на базе Freeswitch
  • Резервирование Asterisk при помощи Heartbeat и Rsync
  • Вышла первая книга по перспективной телекоммуникационной платформе Freeswitch
  

  Tags: Asterisk, Freeswitch, IP PBX, IP АТС, IP-телефония, iptables, SBC, Securiry, Session Border Controller, SIP, VoIP, Yate