Система анализа доступа к серверу телефонии

Размещено на http://www.allbest.ru/

"Система анализа доступа к серверу телефонии"

локальный сервер аутентификация телефония



Введение

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

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

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

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

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

Для реализации указанной цели необходимо решить следующий ряд задач:

анализ регистрационных данных о попытках проникновения в систему;

разработка автоматической системы анализа получения доступа к серверу телефонии по протоколу SSH;

разработка автоматической системы контроля локальных соединений с сервером телефонии;



1.SSH

Существует несколько версий протокола ssh, различающиеся используемыми алгоритмами шифрования и общими схемами работы. В настоящее время повсеместно используется протокол ssh версии два. Протокол младших версий является по современным меркам небезопасным. Вообще-то сейчас ssh является коммерческим продуктом (что само по себе противоречит требованиям безопасности - всем должен быть известен исходный код системы защиты информации, чтобы убедиться в отсутствии всяких backdoors), но тем не менее доступна свободная реализация ssh . Наилучшим документом по ssh является, по-моему, банальный man ssh.

SSH предоставляет 3 способа аутентификации клиента: по ip адресу клиента(небезопасно), по публичному ключу клиента и стандартный парольный метод. Вот как работает ssh версии 2: при запросе клиента сервер сообщает ему, какие методы аутентификации он поддерживает(это определяется в опции PreferredAuthentications sshd.conf) и клиент по очереди пытается проверить их. По умолчанию клиент вначале пытается аутентифицироваться своим адресом, затем публичным ключом и, если ничего не работало, передаёт пароль, введённый с клавиатуры(при этом пароль шифруется асимметрическим шифрованием). После прохождения аутентификации одним из методов из имеющихся у клиента и сервера пар ключей генерируется ключ симметрического шифрования, который генерируется на основании своего секретного и удалённого публичного ключей. После чего все последующие данные, передаваемые через ssh, шифруются данным ключом(обычно используется алгоритм aes с длиной ключа 128 бит). Стоит отметить, что протокол ssh версии 1 имел некоторые недочёты в шифровании передаваемого трафика и являлся по сути методом безопасной аутентификации, поэтому по современным меркам данный протокол считается небезопасным. Протокол версии 2 поддерживает более современные методы шифрования трафика, также вместе с данными посылаются контрольные суммы формата sha или md5, что исключает подмену или иную модификацию передаваемого трафика(чего не было у ssh версии 1).

1.1 Аутентификации пользователей через ssh Ниже будут приведены все три способа аутентификации и их настройка в unix системах.

1)По адресу клиента:

При данном способе аутентификации происходит следующее:

каждый клиент и сервер имеют свои пары ключей RSA, которые называются ключи хоста. При этом существует несколько методов проверки адреса клиента.

Сервер смотрит файлы $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv или /etc/ssh/shosts.equiv, если же сервер настроен на проверку ключей клиентов(а это нужно в соображениях безопасности, т.к. иначе злоумышленник может подменить ip клиента на свой), то он дополнительно проверяет /etc/ssh/ssh_known_hosts и $HOME/.ssh/known_hosts. Естественно, что файлы, расположенные в домашних каталогах сервера, действуют на пользователя, в чьём каталоге они размещены, а файлы, расположенные в /etc имеют глобальный эффект. Для начала расскажу о синтаксисе вышеперечисленных файлов:

rhosts - определяет адрес компьютера и имя пользователя, с которой данному пользователю открыт доступ(файл расположен в домашнем каталоге пользователя ).

shosts - аналогичен .rhosts, но предназначен исключительно для ssh, поэтому

использовать лучше именно данный файл. Пример .shhosts:

user1.test.ru user1

userstend.test.ru user1

null.test.ru user1

/etc/hosts.equiv - также содержит пары имя машины/имя пользователя, но имеет эффект на всех пользователей.

/etc/shosts.equiv - аналог hosts.equiv, но применяется только ssh, что также более предпочтительно. Пример файла /etc/shhosts.equiv

+ user1.test.ru user1

- server.test.ru xakep

Знак + означает разрешение пользователю работать с сервером с данного адреса,знак - запрещает подобное действие.

/etc/ssh/ssh_known_hosts и $HOME/.ssh/known_hosts - данные файлы содержат список адресов и соответствующих им публичных ключей. При запросе клиента сервер генерирует случайную строку и шифрует её публичным ключом удалённого хоста. Клиент, получив данную строку, расшифровывает её своим секретным ключом (который имеется только у него) и зашифровывает полученную строку ключом сервера. Сервер получает зашифрованное сообщение, расшифровывает своим секретным ключом и сравнивает с исходной. Если строки совпали, то клиент имеет валидный секретный ключ, что даёт ему право захода на данный сервер. Но для начала клиент должен иметь правильный адрес, которому соответствует публичный ключ на сервере в файле ssh_known_hosts. Файл состоит из 3-х полей: адрес(или адреса, разделённые запятой), публичный ключ для него одной строкой и дополнительное поле комментариев(необязательно). Пример файла known_hosts:

user1.test.ru {SOME_VERY_LONG_PUBLIC_KEY}

Адрес клиента должен быть в полном формате(name.domain), иначе могут быть проблемы. Кроме этого, в адресе можно использовать шаблоны * и ?. Публичные ключи вставляются в данный файл самим администратором из генерированных клиентом ssh(identity.pub) публичных ключей. Вообще создание ssh_known_hosts - это прерогатива администратора(root).

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

1.2 Аутентификация пользователя по его публичному ключу

Аутентификация удалённого пользователя по ключу идентична проверке ключа хоста(с посылкой случайной строки) за тем исключением, что проверяется не адрес клиентской машины, а ключ клиента и имя пользователя. Данному пользователю на сервере может соответствовать его публичный ключ, тогда клиент, имея секретный ключ сможет заходить на сервер без пароля. Механизм работы я только что описал, поэтому сразу же расскажу, каким образом аутентифицировать пользователей по ключу(предполагается, что используется клиент и сервер openssh).

Для генерации пары ключей используйте программу ssh-keygen. Для указания типа ключа необходимо указать ssh-keygen -t {RSA DSA}, например ssh-keygen -t rsa создаст пару ключей RSA длиной 1024 бита. Для указания файла, в котором следует сохранить ключи, можно использовать опцию -f(традиционно используются файлы $HOME/.ssh/id_rsa и $HOME/.ssh/id_dsa для ключей rsa и dsa соответственно), для указания длины ключа в битах используйте опцию -b:

ssh-keygen -t rsa -b 2048 -f $HOME/.ssh/id_rsa

В результате работы программа запросит ввод пароля для шифрования секретного ключа, чтобы исключить использование его при попадании к посторонним лицам, не знающим пароля(пароль желательно выбирать не короче 10-и символов). После этого будет необходимо вводить данный пароль каждый раз при использовании секретного ключа. После работы ssh-keygen создаётся пара ключей: один секретный(зашифрованный введённым паролем), а другой публичный с расширением .pub(id_rsa.pub). Публичный ключ необходимо будет скопировать в домашнюю директорию сервера $HOME/.ssh/authorized_keys. После этого сервер будет знать ключ данного пользователя и сможет аутентифицировать вас без пароля. Файл authorized_keys может содержать несколько публичных ключей, допустимых для данного пользователя: просто поместите их в данный файл по порядку. После этих операций можно входить, имея секретный ключ, на сервер, где размещён ваш публичный ключ, причём под тем пользователем, в чьём домашнем каталоге данный ключ находится. Пароля удалённого пользователя не требуется, необходимо только знать пароль расшифровки секретного ключа. Для переноса своего публичного ключа на сервер надо использовать только безопасные источники, иначе ключ могут подменить. Для переноса публичного ключа клиента служит программа ssh-copy-id.

Для начала необходимо сделать следующее:

# ssh-copy-id -i public_key_file user@machine

После соединения с севером machine и передачей имени пользователя user(необходимо указывать, если удалённое имя отличается от локального) происходит парольная аутентификация заданного пользователя(или текущего) на удалённой машине, затем происходит копирование ключа public_key_file(или $HOME/.ssh/identity.pub если имя файла не указано) на сервер в $HOME/.ssh/authorized_keys. После этого можно входить на сервер, не используя пароль пользователя. При выполнении данной операции учтите, что вы должны скопировать на удалённую машину ПУБЛИЧНЫЙ ключ.

1.3 Обычная парольная аутентификация

Тут можно отметить только одно: в любом случае вначале идёт обмен асимметрическими ключами, и хеш пароля передаётся в зашифрованном виде. Парольная аутентификация используется наиболее часто, но, честно говоря, ssh предлагает более удобные методы аутентификации, и пользоваться ими можно, если к ssh есть все заплатки. И, конечно же, протокол версии 1 необходимо отключить. Итак, начинаем настройку...

Я заметил, что большинства администраторов просто оставляют файлы конфигурации клиента и сервера по умолчанию, чтобы руки не марать. Но это неправильно: в разных системах эти файлы конфигурации различаются очень существенно, и это приводит к неразберихе и непониманию работы сервера, что создаёт дополнительную угрозу безопасности. Для этого я решил описать файлы конфигурации ssh на примерах ssh_config и sshd.conf для клиента и сервера соответственно.

Для конфигурации клиента используется файл $HOME/.ssh/config или /etc/ssh/ssh_config(для всей системы). Файл имеет следующий формат: определение адреса хоста и параметры для него. В адресе можно использовать обычные шаблоны и все имена параметров и их значения должны быть набраны в том же регистре, что и в примере(иначе параметр воспринят не будет). Вот пример ssh_config, который содержит наиболее полезные опции(на самом деле описывать некоторые параметры конфигурации ssh не имеет смысла, т.к. употребляются они очень редко):

ssh.conf:

1.Host *.test.ru

Определение хоста, в данном случае включает все хосты домена test.ru, можно использовать одиночный символ * чтобы указать параметры доступа к любому хосту.

2. ForwardX11 yes

Эта опция определяет, будет ли ssh использовать передачу данных от удалённого X сервера через свой безопасный канал. Далее будет описано, каким образом организуются безопасные туннели через ssh. Данная возможность позволяет защищать по идее небезопасные протоколы(X, pop, smtp, ftp) шифрованием ssh. По умолчанию данная опция стоит с флагом no.



3. PreferredAuthentications hostbased,publickey,keyboard-interactive

Список предпочтительных методов аутентификации через ssh версии 2. Первым стоит самый предпочтительный протокол.

4. PasswordAuthentication yes

Этот параметр определяет, будет ли производится стандартная парольная проверка.По умолчанию yes.

5. NumberOfPasswordPrompts 3

Число попыток ввода пароля перед тем, как клиент отсоединяется от сервера. По умолчанию пароль можно вводить трижды.

6. AllowUsers *@*.test.ru

DenyUsers xakep lamer

DenyGroups x*

Список допустимых пользователей для данного сервера. Можно применять два формата: список пользователей, разделённых пробелом, и список пользователей и хостов, разделённых пробелом(USER@HOST - разрешает данному пользователю доступ только с данного адреса). Можно использовать выражения * и ?. Подобное же назначение имеют опции AllowGroups, DenyUsers и DenyGroups(для групп нельзя указывать адрес клиента).

7. HostbasedAuthentication yes

Использование ssh(2 версия) аутентификации через rhosts и RSA ключи. По умолчанию no.

8. FallBackToRsh no

Будет ли клиент пытаться работать по rsh, если ssh недоступен или по каким-то причинам работает неправильно. По умолчанию no.

9. BatchMode no

Режим скрипта, когда не спрашиваются пароли с терминала. По умолчанию no.

10. CheckHostIP yes

known_hosts, что исключает подмену ip. По умолчанию yes.

11. StrictHostKeyChecking ask

Данный параметр означает, будет ли клиент доверять полученным от серверов ключам. Параметр может принимать следующие значения: yes - ключи никогда автоматически не помещаются в known_hosts, ask - ключ может быть помещён в known_hosts только после подтверждения пользователя, no - все ключи автоматически размещаются в known_hosts(небезопасно). По умолчанию ask.

12. IdentityFile $HOME/.ssh/id_rsa

IdentityFile $HOME/.ssh/id_dsa

параметры определяют секретные ключи ssh различных форматов:

rsa и dsa.

13. Port 1022

Порт, на удалённой машине используемый ssh. По умолчанию 22.

14. KeepAlive yes

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



2. Подсистема Fail2ban

Основной задачей Fail2ban является обнаружение и блокирование отдельных IP-адресов, с которых производятся попытки несанкционированного проникновения в защищаемую систему. Такие "враждебные" IP-адреса определяются по результатам наблюдения за файлами журналов - log-файлами (например, /var/log/secure, /var/log/faillog и т.д.). Если с какого-либо IP-адреса выполняется слишком много попыток зарегистрироваться в защищаемой системе или производятся какие-либо другие подозрительные действия, то хост с этим IP-адресом блокируется на некоторый интервал времени, определённый системным администратором, т.е. ни один пакет, посланный с такого заблокированного хоста, не будет принят. Такая блокировка выполняется посредством изменения правил (rules) сетевого экрана (iptables).

Описанная выше функциональная схема позволяет защищаться от так называемых "brute force" атак, т.е. от многочисленных попыток войти в систему с различными вариантами паролей. Атаки такого рода достаточно часто практикуются сетевыми взломщиками.

2.1 Загрузка Fail2ban

Существуют готовые к установке бинарные пакеты для наиболее широко распространённых дистрибутивов, таких как Debian, Ubuntu, SuSE, поэтому можно воспользоваться соответствующим менеджером пакетов для установки Fail2ban. Fail2ban написан на языке программирования Python, поэтому для работы требует установленной подсистемы интерпретации и поддержки этого языка.

Рекомендуется, но не является обязательным требованием, наличие в системе следующего программного обеспечения: сетевой экран (поддерживается iptables или shorewall), tcp-wrappers, команда обмена сообщениями электронной почты mail, система отслеживания изменений в файлах на основе inotify (поддерживается монитор Gamin).

2.2 Общая структура и схема функционирования Fail2ban

С точки зрения архитектуры Fail2ban представляет собой систему "клиент-сервер". Серверная часть - fail2ban-server - это многопоточная программа, которая прослушивает Unix-сокеты, ожидая поступления команд, и отправляет клиенту необходимую информацию. Всё это происходит в режиме реального времени. Сам сервер не обладает никакой информацией о текущем статусе файлов конфигурации, поэтому при запуске находится в состоянии "по умолчанию" , в котором не определены никакие блокировки и прочие параметры. Клиентская часть - fail2ban-client - является внешним, интерфейсным компонентом всей описываемой подсистемы. Клиент устанавливает соединение через сокет сервера и посылает через него команды для конфигурирования сервера и выполнения требуемых операций. Клиент может считывать и передавать содержимое конфигурационных файлов или просто отправить на сервер одну команду, используя для этого командную строку shell-оболочки или собственный интерактивный режим, который активизируется при помощи ключа -i.

2.3 Принципы конфигурирования подсистемы Fail2ban

Набор файлов конфигурации может иметь вид, показанный в листинге 1. Структура каталогов и конфигурационных файлов получена при помощи стандартной утилиты tree.

$ tree /etc/fail2ban/ /etc/fail2ban/ +-- action.d ¦ +-- complain.conf ¦ +-- dshield.conf ¦ +-- hostsdeny.conf ¦ +-- ipfilter.conf ¦ +-- ipfw.conf ¦ +-- iptables-allports.conf ¦ +-- iptables.conf ¦ +-- iptables-multiport.conf ¦ +-- iptables-multiport-log.conf ¦ +-- iptables-new.conf ¦ +-- mail-buffered.conf ¦ +-- mail.conf ¦ +-- mail-whois.conf ¦ +-- mail-whois-lines.conf ¦ +-- mynetwatchman.conf ¦ +-- sendmail-buffered.conf ¦ +-- sendmail.conf ¦ +-- sendmail-whois.conf ¦ +-- sendmail-whois-lines.conf ¦ L-- shorewall.conf +-- fail2ban.conf +-- filter.d ¦ +-- apache-auth.conf ¦ +-- apache-badbots.conf ¦ +-- apache-nohome.conf ¦ +-- apache-noscript.conf ¦ +-- apache-overflows.conf ¦ +-- common.conf ¦ +-- courierlogin.conf ¦ +-- couriersmtp.conf ¦ +-- cyrus-imap.conf ¦ +-- exim.conf ¦ +-- gssftpd.conf ¦ +-- lighttpd-fastcgi.conf ¦ +-- named-refused.conf ¦ +-- pam-generic.conf ¦ +-- php-url-fopen.conf ¦ +-- postfix.conf ¦ +-- proftpd.conf ¦ +-- pure-ftpd.conf ¦ +-- qmail.conf ¦ +-- sasl.conf ¦ +-- sieve.conf ¦ +-- sshd.conf ¦ +-- sshd-ddos.conf ¦ +-- vsftpd.conf ¦ +-- webmin-auth.conf ¦ +-- wuftpd.conf ¦ L-- xinetd-fail.conf L-- jail.conf

Рис.1. Конфигурационные файлы и каталоги Fail2ban

При внесении изменений в конфигурацию к показанной на рис.1 обычно добавляются файлы с расширением .local (fail2ban.local, jail.local и т.п.). Параметры настройки, содержащиеся в .local-файлах, имеют преимущество над аналогичными параметрами, записанными в .conf-файлах. На практике это означает, что сначала считывается содержимое .conf-файлов, а затем содержимое .local-файлов, поэтому значения ранее определённых параметров могут быть заменены. Таким образом, в .local-файлах можно хранить лишь те значения параметров, которые требуется скорректировать. Более того, все необходимые изменения конфигурации следует вносить в соответствующие .local-файлы, а не в файлы с расширением .conf. Это помогает поддерживать корректность общей структуры конфигурации и избежать проблем при обновлении всей подсистемы Fail2ban.

Ведение журналов самой подсистемы Fail2ban обычно определяется двумя параметрами:

· logtarget- задаёт направление потока для вывода информации о работе fail2ban. Этот параметр может иметь одно из следующих значений:STDOUT, STDERR, SYSLOGили имя файла. По умолчанию (если данный параметр не определён) присваивается имя файла/var/log/fail2banlog.

· loglevel - определяет степень подробности выводимой информации. Возможные значения:

1. ERROR (только информация об ошибках);

2. WARN (информация об ошибках и предупреждающие сообщения);

3. INFO (полная информация о работе);

4. DEBUG (вывод более подробных описаний всех действий, состояний, ошибок, необходимых для отладки подсистемы).

По умолчанию задан уровень 3 - INFO.

Ещё один параметр, определяющий функциональность Fail2ban, - это socket, который задаёт имя файла, используемого для обмена информацией между клиентом и сервером. По умолчанию этому параметру присваивается имя файла/var/run/fail2ban/fail2ban.sock.



3. Сервер телефонии Asterisk

Asterisk IP-PBX -- свободное решение компьютерной телефонии с открытым исходным кодом от компании Digium, первоначально разработанное Марком Спенсером. Приложение работает на операционных системах Linux, FreeBSD и Solaris. Имя проекта произошло от названия символа "*" (звездочка, астериск).Asterisk в комплексе с необходимым оборудованием обладает всеми возможностями классической АТС, поддерживает множество VoIP протоколов и предоставляет богатые функции управления звонками:

· голосовую почту,

· конференции,

· интерактивное голосовое меню (IVR),

· центр обработки вызовов (постановка звонков в очередь и распределение их по агентам используя различные алгоритмы),

· запись (CDR)

и прочие функции. Для создания дополнительной функциональности можно воспользоваться собственным языком Asterisk для написания плана нумерации, написав модуль на языке C, либо воспользовавшись AGI - гибким и универсальным интерфейсом для интеграции с внешними системами обработки данных. Модули, выполняющееся через AGI, могут быть написаны на любом языке программирования.

Asterisk распространяется на условиях двойной лицензии, благодаря которой одновременно с основным кодом, распространяемым по открытой лицензии GNU GPL, возможно создание закрытых модулей, содержащих лицензируемый код: например, модуль для поддержки кодека G.729.



3.1 Оборудование для Asterisk

Asterisk может работать как с аналоговыми линиями (FXO/FXS модули), так и цифровыми (ISDN BRI и PRI -- потоки Т1/E1). С помощью определённых компьютерных плат (наиболее известными производителями которых являются Digium, Sangoma, OpenVox, Rhino, AudioCodes) Asterisk можно подключить к высокопропускным линиям Т1/E1, которые позволяют работать параллельно с десятками и сотнями телефонных соединений. Полный список поддерживаемого оборудования для соединения с ТФОП определяется поддержкой оборудования в модулях ядра:

· DAHDI, акроним Digium Asterisk Hardware Device Interface (ранее назывался Zaptel)^[2], разрабатывается параллельно с Asterisk компанией Digium,

· mISDN^[3], разрабатывается Карстеном Кайлом (Karsten Keil) из команды SuSE и компанией Beronet^[4],

· CAPI

· и др.

3.2 Протоколы

Поддерживаются следующие протоколы:

· SIP,

· H.323,

· IAX2,

· MGCP,

· Skinny/SCCP,

· XMPP (Google Talk),

· UNIStim,

· Skype через коммерческий канал^[5].

Возможно транслировать текст и видеосигналы (например, использовать видеофон). Кроме того, реализована работа с другими компьютерными протоколами:

· DUNDi - протокол, также разработанный Digium,

· OSP,

· T.38, поддерживается передача факсов.

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

3.3 Программирование

Настройка и программирование производится с помощью нескольких механизмов:

· диалплан, который пишется на специальном языке. Доступна как старая версия, так и новая -- AEL, а также на языке Lua.

· AGI.

· AMI.

· Конфигурация из БД.

Расширение выполняемых функций также возможно путём написания на языке C нового модуля, что возможно благодаря подробной Doxygen-документации.

Для работы с Asterisk создано множество графических интерфейсов, я использую voiceone.

3.4 Рекомендации по безопасности в Asterisk

1.Использовать Firewall c возможностью распознавания DoS атак.

Также, если существуют риски атаки типа Denial Of Service (DoS), следует установить специальное оборудование, распознающее такой тип атак и автоматические блокирующее атакующего с уведомлением системного администратора.

2.Следует обеспечивать безопасность оборудования VoIP на физическом уровне.

Доступ к оборудованию должны иметь только ответственные за него лица.

3.Ограничение доступа к открытым портам.

Оставив только необходимые службы рекомендуется так же ограничить доступ к ним используя сетевой экран.Например, разрешить доступ к ftp или tftp серверу только для IP адресов, которым этот доступ может понадобиться и запретить для всех остальных. Доступ к web-интерфейсу IP АТС только с IP адреса компьютера администратора.

4.Огрничение доступа к командной строке.

Необходимо запретить доступ через telnet и разрешить доступ по ssh, причём необходимо использовать нестандартные порты, например 1022.

5. Использование нестандартных портов для сигнальных протоколов.

Назначить в качестве слушающего порта для SIP 5089 вместо стандартного 5060, обычно первым этапом при сканировании диапазона IP адресов в Интернете с целью выявить устройства VoIP для последующего взлома является поиск открытых сигнальных портов SIP, H.323 и т.д.

6.Ограничение регистрации пользователей.

Если клиенты могут регистрироваться на корпоративной IP АТС прямо из сети Интернет (что рекомендуется только с использованием защищенного канала VPN ), не принимать сообщения о регистрации REGISTER с любого IP адреса без необходимости. Следует ограничить список IP адресов, с которых могут регистрироваться клиенты. Настоятельно рекомендуется использовать для доступа к корпоративной сети VoIP защищенную сеть VPN.

Для Asterisk: строки «permit=« and «deny=« для пользователей в файле sip.conf

Если все же необходимо открыть регистрацию для заранее неизвестного списка IP адресов, нужно использовать параметр Set «alwaysauthreject=yes» в файле sip.conf. Это позволит избежать «утечки» информации о пользователях. Опция yes позволяет отклонять запросы об аутентификации для существующих пользователях с такой же причиной как и для несуществующих . Таким образом, атакующий не сможет определить существующих на IP АТС пользователей и вероятность получить доступ к пользователю перебором паролей существенно снижается.

7.Используйте сложные пароли из случайных чисел.

Использование простых паролей, например ; «0000», «12345» или его отсутствие, является наиболее частой причиной взлома учетных записей пользователей. Простые пароли легко угадать. Используйте программы для генерирования паролей, например Pwgen. Рекомендуется использовать пароли, содержащие не менее 12 символов включающие цифры, буквы в нижнем и верхнем регистре.

8.Рекомендуется ограничивать число одновременных вызовов для учетных записей.

Если злоумышленник сумеет получить доступ к учетной записи, количество одновременных вызовов на учетную запись будет ограничено. Тогда он меньше «назвонит» до момента когда будет обнаружен.

9.Логирование всех событий в системе.

Используйте журналы всех событий в системе, желательно, что бы логи(журналы) о событиях в системе записывались удаленно. Это связано с тем, что злоумышленник, получив доступ к устройству, в частности к IP АТС, пытается скрыть свое присутствие и свои действия путем удаления всех событий из файлов журналов. Если логи будут отправлять на удаленный сервер, это затруднит или сделает невозможным скрыть свое присутствие.

10.Ведение журналов CDR(Call Detail Record).

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

11.Использовать регистрацию только по доменному имени.

Очень полезно запретить регистрацию по ip адресу, используя вместо этого регистрацию по имени домена(например 1124@ucexpert.ru, вместо 1124@84.52.79.150). Если злоумышленник не будет знать домен в котором следует регистрироваться все попытки подобрать учетные данные будут тщетными.

12.Дополнительные методы повышения безопасности. Методы, описанные в практической части дипломной работы.



4. XMPP

Программы для мгновенного обмена сообщениями (instant messaging - IM) пользуются широкой популярностью, как среди обычных, так и деловых пользователей. Они позволяют не только обмениваться информацией в реальном времени, но и получать данные о присутствии или отсутствии собеседников (как правило, поддерживаются такие признаки присутствия, как "доступен", "отошел от компьютера", "недоступен" и т. д.). Примером одного из ранних открытых протоколов IM может служить Jabber, созданный Джереми Миллером (Jeremy Miller) в 1998 г. Изначально он не задумывался как стандартный протокол, однако, благодаря своей расширяемости и XML-основам он быстро нашел применение в качестве транспорта общего назначения в промежуточном программном обеспечении, ориентированном на обмен сообщениями (message-oriented middleware -- MoM). Развитие Jabber в итоге привело к появлению стандартизированного протокола XMPP, описанного в спецификации RFC 3920 "Extensible Messaging and Presence Protocol (XMPP)" (расширяемый протокол для обмена сообщениями и информацией о статусе присутствия), которая была разработана рабочей группой в IETF.

XMPP является отнюдь не единственным транспортным протоколом общего назначения, служащим для обмена сообщениями. Другие популярные протоколы, например XML-RPC и SOAP могут предоставить аналогичные возможности, но семантически передача сообщений будет напоминать вызовы функций. Кроме того, более новые решения, такие как ReST (передача репрезентативного состояния), позволяют получать доступ к файлам, используя URL для указания местоположений, объектов и методов.



4.1 Архитектура XMPP

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

Данная простая архитектура представлена на рис.3 (в этом примере оба клиента относятся к одному домену - discovery.nasa.guv).

Рис.2.Архитектура xmpp

Серверы могут также взаимодействовать между собой в целях кросс-доменной маршрутизации, например, для передачи сообщений из домена discovery.nasa.guv в europa.nasa.guv. Кроме того, могут существовать специальные шлюзы (gateway), служащие для преобразования сообщений, полученных по другим протоколам. На рис.4 показан пример сети XMPP, включающей шлюзы в сети SMS (сервис передачи коротких сообщений) и SMTP. Чаще всего шлюзы используются для трансляции сообщений, передаваемых по разным IM-протоколам, например XMPP и IRC (Internet Relay Chat). Благодаря своей расширяемости XMPP представляет собой идеальную инфраструктуру для интеграции различных конечных протоколов. Шлюзы XMPP позволяют завершать указанные сессии клиент-серверного обмена сообщениями, а также инициировать новые сессии связи через указанный конечный протокол и с учетом необходимых преобразований данных.

Рис.3. Развёрнутая архитектура протокола xmpp

4.2 Соединение с другим протоколом

Полезной особенностью XMPP систем являются транспорты, илишлюзы, позволяющие пользователям получать доступ к сетям, использующим другие протоколы. Это могут быть другие протоколы мгновенного обмена сообщениями, IRC или такие протоколы, как SMS и электронная почта.

В отличие от мультипротокольных клиентов, XMPP предоставляет доступ на уровне сервера, посредством коммуникации через специальные сервисы-шлюзы, выполняющиеся на удалённом компьютере.

Любой пользователь может «зарегистрироваться» на одном из этих шлюзов, предоставив информацию, необходимую для входа в сеть, и может общаться с пользователями сети так, как если бы они были пользователями сети джаббер. Это значит, что любой клиент, полностью поддерживающий XMPP, может быть использован для доступа к любой сети, для которой существуют шлюзы, без какого-либо дополнительного кода в клиенте и без необходимости клиенту иметь прямой доступ в Интернет.

Реализация шлюзов зависит от конкретного XMPP-сервера и подвержена нестабильности из-за закрытости коммерческих IM-сервисов.

Рис.4.Схема соединение xmpp с другим пртоколом.



5.Работа скрипта и вспомогательных служб

5.1 Локальная сеть

Для реализации и тестирования скрипта и вспомогательных используются сервера с предустановленной ОС Debian, на которых уже работают службы используемые в компании. Топология сети в которой установлен каждый сервер выглядит следующим образом:

Рис. 5. Топология сети предприятия

Локальная сеть: Рабочие станции, IP-телефоны, GSM и VoIP-шлюзы и другое оборудование с помощью которого работает управляющий персонал и рядовые сотрудники. Все оборудование имеет соединение с локальным сервером через сетевой коммутатор. Клиентская часть установлена на рабочих станциях, серверная часть установлена на Локальном сервере. Так же используются VoIP и GSM-шлюзы с помощью которых осуществляется связь между персоналом и клиентами.

Локальный сервер: Для локальной сети выступает в роли маршрутизатора. Доступ на сервер осуществляется с помощью любого ssh-клиента. Соединение происходит через один единственный порт 1022.

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

5.2 Принцип работы скрипта

Перед тем , как описать работу самого скрипта, очень важно показать, в какой среде мы работаем и какой дополнительный функционал мы используем вместе с основным скриптом.

Для начала , мы работаем в Debian GNU/Linux 6.0.4 (squeeze) со своим пересобранным ядром. Данная операционная система была выбрала лишь потому, что она более проста в использовании и все нужные компоненты для работы скрипта корректно работают с ней.

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

На практике это выглядит следующим образом. Разобьём скрипт на 3 части, по целям его использования:

1.Анализирование лога на предмет записи «failed keyboard interective» в /var/log/auth.log

2.Анализирование лога на предмет записи»wrong password»/var/log/asterisk/full

3.Анализирование состояние локальных пользователей сервера телефонии

Разберём каждый по отдельности.



5.3 Анализ лога ssh

Все ssh коннекты к серверу(будь то успешные или нет) фиксируются(логируются) в системном файле auth.log. Соответственно нас интересует неуспешные попытки коннекта, которые мы будем расценивать, как попытку перебора пароля.

Такая попытка в логе выглядит следующим образом:

pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=176.67.48.163

Тут видно, что пользователь , имея внешний ip адрес 176.67.48.163 попытался зайти по ssh на текущий сервер и ввёл неправильный логин и пароль. Нам интересна запись «authentication failure», так как именно её ищет наш скрипт.

"exec" => "/bin/cat /var/log/auth.log | /bin/grep sshd | /usr/bin/tail -n 30 | /bin/grep -c \"Failed keyboard-interactive/pam for\""

"email" => "Attack off SSH.\n On 30 lines on log file, {exec} contains @Failed keyboard-interactive/pam@"

В этой части видно, что мы ищем 30 последних записей на предмет искомого слова, после чего отправляется email, который будет выглядеть следующим образом:

2011-07-26 21:00:07

Attack off SSH.

On 30 lines on log file, 8 contains @Failed keyboard-interactive

Разумеется есть вероятность того, что это просто кто-то , кто имеет настоящие пароли на сервер, ошибается при вводе, поэтому эта часть скрипта носит лишь предостерегающий характер.

Тут нам пригодится программный пакет fail2ban. Согласно заранее приготовленному файлу конфигурации, а именно:

enabled = true

port = ssh

filter = sshd

action = iptables[name=SSH]

action = xmpp[name=SSH]

logpath = /var/log/auth.log

maxretry = 6

bantime = 259200

Распишем, что означает каждый параметр:

· ignoreip - это разделенный пробелами список ip-адресов, которые не могут быть блокированы fail2ban. Сюда можно занести свою локальную машину или комьютер, с которого будут проводится эксперименты над системой

· bantime - время в секунда, на которое блокируется хост.

· maxretry - максимальное число ошибочных попыток доступа к сервису, прежде чем хост будет заблокирован fail2ban.

· filter - имя соответствующего файла-фильтра в /etc/fail2ban/filter.d, без конечного.conf

· action - имя соответствующего файла-реакции на срабатывание фильтра в /etc/fail2ban/action.d

· logpath - файл логов, мониторинг которого осуществляет fail2ban, для проверки попыток атак.

· enabled - может принимать значение true или false. Включено,выключено правило.

Файл sshd.conf по принципу своейработы похож на первую часть скрипта, а именно , если в logpath = /var/log/auth.log будет 6 записей типа «Authentication failure for» и если найдёт, то отработает действие

action = iptables[name=SSH]

и будет создано правило в iptables, а именно:

$IPTABLES -A INPUT -s 176.67.48.163 -j DROP

Соответственно этот хост будет помещён в список не доверительных хостов(baned) на значение параметра bantime ,который равен 259200 секундам.

В силу работы подсистемы fail2ban, то скрипт ограничится лишь отправкой письма на почту для дальнейшего анализа системным администратором. Если попытки взлома повторятся после исключения из списка не доверительных хостов, а именно по прошествии 259200 секунд, на почту придёт ещё одно письмо и нужно будет задуматься о том, что для этого хоста прописать постоянное запрещающее правило в iptables.



Заключение

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

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

Сервер телефонии и ssh вещи неразделимые, соответственно в скрипте есть автаматизация по сбору статистики о проникновение на сервер по ssh.

Так же были проведены тесты, в которых есть вывод данных и расписано на примерах , как этот скрипт работает на тестовом сервере.



Список использованной литературы

1.Эви Немеет, Гарт Снайдер, Скотт Сибасс, Трент Р.Хейн. «UNIX

Руководство системного администратора», 3-ее изд., издательская группа BHV,

Санкт-Петербург, 2004г.

2.Платов М.В. Asterisk и Linux: миссия IP-телефония. - Журнал "Системный администратор", N6, 2005 г. - 12-19 c.

3.Фролов А.Г. Диалог-МИФИ, 2005 г. - 236 с.

4.Зиглер Роберт Л. Брандмауэры в Linux. Издательский дом «Вильямс», 2001. - 384с.

5.Э. Мэйволд. Безопасность сетей. URL: http:// www.intuit.ru /department/ security/netsec (дата обращения 14.12.2011)

6.Oskar Andreasson. Iptables Tutorial 1.2.2 URL: http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html (дата обращения 15.10.2012)

7.Меггелен Дж., Мадсен Л., Смит Дж. Asterisk: будущее телефонии, 2-е издание. - Пер. с англ. - СПб: Символ-Плюс, 2009. - 656 с.

Размещено на Allbest.ru