По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Когда администратор является единственным администратором АТС, то проблем с выяснением причин кто и что сломал не возникает, так как административный аккаунт один и им пользуется только один человек.
А вот когда администраторов много, да ещё необходимо разграничивать права доступа в зависимости от выполняемых обязанностей, тогда как раз и встает вопрос о персональных аккаунтах для администраторов.
Для этого можно создавать как персональные профайлы (под единичные доступы), так и групповые (например, для сотрудников, выполняющих ограниченные функции – проверка состояния транков, создание абонентов, настройка Call Center и так далее).
Стоит заметить, что первые 19 профайлов являются системными и их менять или удалять не стоит. Для новых профайлов следует использовать номера с 20.
Выполнение в терминале или консоли GEDI
Для начала надо создать новый профайл командой:
add user-profile-by-category НОМЕР
или
add user-profile НОМЕР
В открывшемся окне выставляем параметры, которые нам необходимы.
User Profile Name – имя профайла. Служит для идентификации уровня доступа (имя пользователя или имя группы пользователей, для которых и создается данный профайл).
Shell Access? – разрешен ли данному профайлу доступ в командную строку системы
В терминале это выглядит так:
А в консоли GEDI это будет немного поудобнее, тем более, что выставление параметров можно выполнять при помощи мыши, при этом по нажатию правой кнопки показывается подсказка по значениям в конкретном поле:
На первой странице выставляются общие (групповые для функций) права на доступ. Более детальные разрешения выставляются на последующих страницах. Однако без выставления прав на группу нельзя выставить права на функцию, входящую в эту группу.
Например, нельзя разрешить настраивать абонентов или транки, не разрешив при этом группу Maintenance (G) на первой странице. Но можно разрешить доступ только к абонентам, но запретив доступ к транкам.
Чтобы не открывать все группы, можно найти необходимую функцию, посмотреть в какую группу (категорию) входит данная функция и на первой странице разрешить именно эту группу.
Разрешение r позволяет только просматривать без возможности создания или внесение изменений в настройки.
Разрешение w дополнительно позволяет ещё и создавать, изменять и удалять настройки.
Разрешение m позволяет выполнять дополнительные действия по обслуживанию (трассировки, включение/выключение абонентов или транков и так далее)
Обычно создают профайл для полного доступа администраторов (с включением всех групп (категорий) и правами доступа wm) и профайлы с ограниченным доступом для других пользователей, выполняющих некоторое задачи (например, 1-линия для создания абонентов, служба мониторинга для просмотра статусов абонентов или транков и так далее).
После установки всей настроек сохраняем настройки путем нажатия F3 в терминале или Enter (F3) в консоли GEDI.
Выполняется в web-браузере
Подключаемся к Avaya Communication Manager по IP-адресу, заходим под учетной записью dadmin (если она у нас единственная) или под учетной записью «полного» администратора (если ранее был создан такой аккаунт).
Далее Administration → Server (Maintenace) → Security → Administrator Accounts → Add Login и создаем уже сами аккаунты:
Сначала выбираем уровень доступа. В зависимости от выбранного уровня предоставляются разные права, не настраиваемые в профайле.
Вот пример предоставляемых прав для 2-х администраторов:
Для уровня «полного» администратора выбираем Privileged Administrator.
Login name – создаваемый логин, по которому будет осуществляться авторизация.
Additional groups (profile) – в выпадающем списке выбираем созданный ранее профайл.
Enter password or key – вводим пароль для входа.
Re-enter password or key – подтверждаем введенный ранее пароль.
Как правило пользователь должен сам создавать и помнить свои пароли, поэтому
Force password/key change on next login – отмечаем в Yes. Тогда при первом входе пользователю будет предложено для продолжения работы сменить пароль на новый.
Далее подтверждаем введенные данные Submit.
Для добавления доступа к Web-настройкам созданный ранее профайл надо добавить через Administration → Server (Maintenace) → Security → Web Access Mask.
Нажимаем Add, потом вводим номер нашего созданного профайла и выбираем какую маску доступа будем применять или сразу будем применять все включено/выключено.
После сохранения убеждаемся, что вновь добавленная маска применилась, выбираем её, заходим в нее нажав Change и проверяем/добавляем/удаляем необходимые настройки.
Далее заходим под созданной учетной записью и проверяем уровень доступа по доступным командам. После проверки полного доступа рекомендуется сменить пароль для учетной записи dadmin и не выдавать этот логин никому.
Дальше в логах на СМ мы можем просмотреть историю входов, введенных команд и выполненных действий по каждому логину.
Первые два типа систем (IPS - intrusion prevention system & IDS - intrusion detection system) появились в 1986 году как результат научной работы, и их базовые принципы до сих пор используются повсюду – в системах предотвращения и обнаружения, в NGIPS и NGFW – словом во всех системах, которые были упомянуты в заголовке. В статье мы расскажем, как IPS/IDS изменялись со временем, с какими проблемами сталкивались разработчики и что можно от них ожидать в будущем.
Итак, как мы уже сказали, системы обнаружения угроз и системы предотвращения угроз появились после написания научной статьи некой Дороти Деннинг, и называлась эта статья «Модель обнаружения угроз», и благодаря этой статье Стэнфордский Исследовательский Институт разработал нечто под названием Intrusion Detection Expert System/ (IDES). Вольно это можно перевести как экспертная система обнаружения угроз. Она использовала статистическое обнаружений аномалий, сигнатуры и хостовыепользовательские профили для детектирования редискового поведения у систем. Таким образом, она могла определить если такие протоколы как FTP или HTTP были использованы некорректно и даже могла определять атаки с отказом обслуживания (DoS).
2000 - 2005: Обнаружение предпочтительнее предотвращения
В ранних 2000х системы обнаружения считались хорошим тоном. А до этого межсетевые экраны были очень эффективны для ландшафта угроз безумных 90х годов. Фаерволы обрабатывали трафик относительно быстро, так как в них не было глубокой инспекции пакетов, то есть вы не знали, что это за трафик приходит к вам в сеть – фаерволы реагировали только на установленные в правилах (листах контроля доступа) порты, протоколы иили сетевые адреса. В начале 2000х появились новые атаки, такие как SQL-инъекции и прочие, и они моментально завоевали место на подиуме в арсенале взломщиков. И вот на этом этапе IDS системы и пригодились – а время систем предотвращения угроз еще не настало.
В то время некоторые организации боялись использовать IPS так как такая система потенциально могла заблокировать безвредный трафик. Как мы более подробно описывали в нашей статье про IPS и IDS, IPS ставится «в разрыв» и блокирует подозрительные соединения, полностью разрывая коннект и связь между отправляющей и принимающими сторонами. Но как вы могли понять, такое соединение могло стать подозрительным просто по причине какой-то аномалии в подключении и грубо говоря «глюке». Таким образом, IDS системы просто сообщали о такой аномалии и ничего не блокировали, чтобы сисадмин мог среагировать и проверить - правда ли это что-то плохое или же это просто доброкачественная аномалия. По этой причине в то время рынок для систем предотвращения угроз был настолько мал, что существовало всего несколько IPS вендоров. То есть идеей было что нужно пропускать любой трафик, а разберемся, мол, уже опосля – риск потери хорошего трафика был страшнее угрозы взлома.
В это время сигнатуры писались для обнаружения эксплойтов, но не уязвимостей – то есть для каждой уязвимости было 100 разных способов эксплойта. Как только злоумышленники находили уязвимость, они заставляли разработчиков IDS исходить потом и писать сотни разных сигнатур для эксплойтов – все только для того, чтобы система обнаружения отправила тревогу админу. И вендоры IDS хвастались количеством имеющихся у них сигнатрур, будто это выгодно отличало их от конкурентов – но как вы понимаете, это не было корректным критерием оценки. В общем и целом, механизмы тогда насчитывали следующее полчище методов – совпадение по паттернам, строкам, аномалиям и даже эвристический анализ.
Принятие IPS - год 2005
Когда в 2005 году системы предотвращения начали становится популярнее, большее количество вендоров стали соревноваться за место под солнцем на растущем рынке, и перестали хвастать самыми длинными сигнатурами. Опять же, по причине установки «в разрыв», клиенты боялись, что все эти сигнатуры будут замедлять сеть, так как каждое соединение должно быть пропущено через них. Таким образом, было решено сменить вектор написания сигнатур на другие – те, которые будут базироваться не на эксплойте, а на самой уязвимости. Было получено опытным путем, что если в системе более 3500 сигнатур, то это будет заметно сказываться на производительности. Сегодня производители все еще помещают в систему как новые сигнатуры, так и некую классику уязвимостей, которую злоумышленники могут использовать.
2006 – 2010: Настает время производительных IPS/IDS комбайнов
Вендоры, которые предлагали гибридные системы, быстро обошли конкурентов – они предлагали гораздо более производительные системы, вплоть до 5 Гбитсек, и могли мониторить сегментированные сети, DMZ, серверные фермы с веб-приложениями и площадь внутри периметра. К примеру, сегодня производительные IPS устройства легко дают более 40 гигабит в секунду.
В итоге, клиенты начали массово переходить на системы предотвращения вторжений и рынок начал очень быстро расти. А когда появился стандарт безопасности PCI DSS начал требовать от организаций поддержу оплаты картами установки или IDS, или МСЭ с возможностью фильтрации веб-приложений, очень много организаций купили гибридные системы. И прошло уже много лет с момента рождения технологии, так что технологию порядочно оттюнинговали и подрихтовали, так что, ложно-положительных срабатываний стало гораздо меньше. Однако, в этот же момент начала расползаться эпидемия ботнетов. И самым популярным способом стало помещение зловредных приложений на популярных сайтах, и, если какой-нибудь браузерный плагин вроде Java или Adobe Flash был с уязвимостью, при клике на соответствующий документ вредонос тихонько скачивался на компьютер. Кроме того, в 2008 году злоумышленники активно использовали перенаправляющие ссылки на вредоносные сайты, так что IDS/IPS вендоры начали также добавлять списки IP-адресов вредоносных командных центров и их веб-адресов – если эти ресурсы содержали на себе вредоносы.
2011 – 2015: Системы предотвращения вторжений следующего поколения
В эти годы был переломный момент для вендоров в сфере ИБ – так как они стали выпускать системы предотвращения угроз следующего поколеня, которые включали в себя такие фичи как контроль пользователей и приложений. Таким образом, традиционный IPS смотрит в сетевой трафик на предмет известных аттак и что-то делает с этим трафиком, в зависимости от модели развертывания, а IPS следующего поколения делает тоже самое, но кроме того он покрывает гораздо больше протоколов (вплоть до 7 уровня) для защиты от большего количества атак. Кроме того, он также позволяет гибко контролировать доступ к приложениям – то есть, например, чтобы можно было лайкать фотки в VK, но нельзя было их заливать. И более того – чтобы это могли делать только определенные группы пользователей.
Следующее дополнение к IDS/IPS системам появилось после взлома RSA (компании, которая занимается мультифакторной аутентификацией) в 2011 году – тогда новостные ресурсы назвали это APT (Advanced Persistent Threat)-атакой, то есть сложной постоянной угрозой. Позже было сказано, что это была фишинговая атака, в которой содержался документ с вредоносом внутри. Клиенты стали спрашивать ИБ вендоров, могут ли они их защитить от подобных вещей, если у вендора нет сигнатуры на данный конкретный вредонос, и ответом вендоров было предоставление такой фичи как эмуляция и песочницы – но это потребовало около 18 месяцев для большинства вендоров. Так что компании FireEye и Fidelis оказались в фазе бурного роста, так как они предоставляли такие технологии песочницы, до которых всем было очень далеко. Только подумайте, песочницы впервые за всю историю могли обнаружить до сих пор неизвестную атаку нулевого дня.
Как работает песочница: неизвестный исполняемый файл или документ сначала попадает в песочницу, где он запускается в разных операционных системах и алгоритм пытается имитировать действия пользователя – клавиши стучат, мышка елозит и кликает, время прокручивается – все в надежде на то, что вредонос вылупится и себя покажет.
Вендоры пошли чуть дальше. Если вредонос себя проявлял, то его хэш-сумма (MD5 или SHA) сохранялась для того, чтобы в будущем всегда ловить такие файлы. Соответственно, если другой клиент на такой же системе получал тот же файл – то он не пропускался в сеть и звучала тревога. Такие системы получили название Next Generation Firewall – межсетевых экранов следующего поколения.
Конечно, Гартнер использовал этот термин еще в 2003 году и предсказал, что они межсетевые экраны будут содержать внутри себя сложную IPS систему, но индустрия не принимала подобные устройства вплоть до 2013 года.
2018 – и далее: Межсетевые экраны следующего поколения
Сегодня большинство организаций используют NGFW и список их фич только растет. Так как эти МСЭ отличаются различными фичами, организациям придется выбирать в зависимости от точности поставленной задачи и их требований.
Опять же, есть за и против МСЭ следующего поколения: за – нужно купить только пару железяк вместо почти десятка. Против – это все один вендор, и его мудрость ограничена, то есть не существует лучшего вендора, который знал бы все и сразу. Таким образом очень неплохой практикой является комбинировать устройства защиты от разных производителей и разбавлять их «мудрость» между собой. Важно помнить, что любое устройство защиты всегда хорошо только настолько, насколько богаты знания и опыт, стоящие за этим устройством. Есть даже специальный термин – Threat Intelligence. Такие системы и базы знаний есть у всех больших ИБ вендоров. Более того, они есть полностью бесплатные и открытые – например, VirusTotal.
Сегодня ландшафт угроз постоянно меняется и большинство вендоров сконцентрировано на машинном обучении, чтобы алгоритмы анализа файлов всегда улучшались, а количество шума и ложных срабатываний стремилось к минимуму.
Но это бесконечная игра в кошки-мышки, и на каждый ход производителей хакеры придумают что-нибудь новое, что позже смогут нейтрализовать вендоры.
Если вы только начинаете своё знакомство с IP-АТС Asterisk и графическим интерфейсом FreePBX, может случиться так, что ваша АТС забанит вас по IP и восстановить доступ вы сможете только через консоль самого сервера или виртуальной машины. Знакомо? Тогда читай что делать в таком случае!
По умолчанию во FreePBX работает встроенная защита сервера от взлома пароля методом “грубого перебора”, известного в простонародье как брутфорс (bruteforce). Этот механизм называется fail2ban и предназначен он для того, чтобы ограничивать возможным злоумышленникам доступ к компонентам сервера.
В случае с FreePBX может случиться ситуация, когда сервер примет вас за возможного злоумышленника и ограничит вам доступ по SSH (порт по умолчанию 22). Представьте - вы только установили FreePBX, зашли в web-интерфейс начали проводить настройки, но тут вам понадобилась консоль сервера. Вы открываете putty, вводите адрес и порт сервера, затем логин, а потом пароль. Сервер отвечает, что пароль не правильный Access denied. “Неправильно ввёл, с кем не бывает” – подумаете вы и повторите попытку. Так вот если вы 5 раз неправильно введёте пароль, то на шестой увидите следующую картину при попытке подключиться к серверу:
Данная статья описывает ситуацию, которая может случиться на тестовых системах или же - на свежих системах, которые установлены недавно. Команда Мерион Нетворкс ни при каких условиях не рекомендует использовать советы из данной статьи на системах, работающих в Production режиме... Никогда.
Однако! Если у вас остался доступ к вэб интерфейсу FreePBX, то ещё не всё потеряно. Начиная с версии 13, во FreePBX появился модуль Firewall, который как раз и отвечает за работу fail2ban. Поэтому, чтобы заново открыть себе доступ к серверу, мы этот модуль не на долго отключим. Для этого прыгаем в Connectivity → Firewall и жмём Disable Firewall:
Отлично, теперь, чтобы сервер нас больше не банил мы немного подредактируем настройки fail2ban. Для этого, опять подключаемся к серверу по SSH и редактируем файл /etc/fail2ban/jail.local любым текстовым редактором, например vim:
vim /etc/fail2ban/jail.local
Найдите секцию [DEFAULT] и добавьте в опцию ignoreip адрес, с которого вы подключаетесь к серверу. Адреса можно добавлять через пробел в одну строку, можно также добавлять целые сети.
После этого не забудьте заного включить Firewall. Connectivity → Firewall и жмём Enable Firewall
Если WEB - интерфейс доступен
Если доступ к WEB - интерфейсу FreePBX доступен, то просто зайдите в него, перейдите на Admin → System Admin → Intrusion Detection. В списке забаненных IP - адресов найдите нужный и удалите его. Можно это сделав, например, указав в разрешенном списке забаненный адрес с /32 маской, или подсеть. После этого нажмите Restart. Готово.