Разработка динамических сайтов
SEO услуги
Управление контекстной рекламой

Вход на хостинг

Имя пользователя:*

Пароль пользователя:*

IT-новости

20.04.2016 iPhone 2017 года поместят в водонепроницаемый корпус из стекла

Линейка iPhone в новом году серьезно поменяется. В этом уверен аналитический исследователь Мин Чи Ку......

подробнее

30.07.2015 Ищем уникальный контент для сайта

Ищем уникальный контент для сайта Без уникального контента Ваш сайт обречен на то, что его страницы......

подробнее

11.05.2015 Распространённые ошибки разработчиков сайтов

Не секрет, что в сети Интернет насчитывается миллионы сайтов, и каждый день появляются тысячси новых......

подробнее

Пишем систему динамической защиты ресурсов сети


Андрей Бирюков

Аудит журналов безопасности операционной системы – неотъемлемая часть работы системного администратора. Если обнаружены попытки проникновения, на них необходимо немедленно отреагировать. Автоматизируем данный процесс с помощью сценария Perl.

Что собираемся защищать

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

Однако иногда такая реакция может оказаться запоздалой, особенно это касается попыток осуществления несанкционированного входа в систему. Если какие-либо ресурсы вашей сети (например, электронная почта, веб-сервер или доступ по протоколу SSH) опубликованы в Интернете, то вам наверняка приходилось наблюдать записи в протоколах, свидетельствующие о попытке осуществления несанкционированного доступа к ресурсам сети. Конечно, это попытки взлома с помощью «грубой силы» (brute force, подбор пароля по словарю), такой способ, как правило, не приносит результата. Хотя иногда начинающие хакеры с упорством, достойным лучшего применения, «натравливают» словари на учетную запись root.

Но тут следует заметить, что зачастую наш потенциальный противник охотится вовсе не за паролем к учетной записи пользователя, а, к примеру, ему необходимо определить существует ли пользователь с таким именем на сервере или нет. Такая информация будет весьма полезна для спамеров. Ведь на очень многих почтовых серверах имя пользователя совпадает с именем почтового ящика, точнее, с той его частью, которая идет до знака @ (например, user@mydomain.ru), а база корпоративных электронных адресов стоит дороже чем база адресов с бесплатных почтовых серверов. Для того чтобы избежать подобного рода сканирования, можно просто закрыть соответствующие порты от использования снаружи. Но в большинстве современных компаний сотрудники хотят иметь доступ к своей почте из дома или находясь в командировке, поэтому вариант с запретом нам не подходит.

Из всего этого делаем вывод, что нам необходимо средство, которое могло бы обнаруживать и адекватно реагировать на попытки подбора логинов/паролей к ресурсам нашей сети.

Существует масса решений, как программных, так и аппаратных, получивших название Intrusion Detection System, IDS, системы обнаружения вторжения, которые позволяют выполнить данную задачу. Но зачастую они либо слишком громоздки в управлении, либо слишком дорого стоят.

Попробуем самостоятельно разработать простейшую IDS. В качестве инструментов будем использовать сценарии Perl под ОС Linux.

Как собираемся защищать

В качестве основы для реализации я использовал сценарий, находящийся на cpan.org [1]. Идея довольно проста: через определенные промежутки времени сканируется файл /var/log/messages. В случае обнаружения сообщений, информирующих о попытках несанкционированного доступа с определенного IP-адреса, по протоколу ssh в iptables добавляется строка, блокирующая получение пакетов с данного адреса. Список заблокированных IP-адресов автор предлагает передавать в сообщениях syslog.

Обратите внимание на то, что перед запуском сценария необходимо создать iptables chain Block и поместить текущую конфигурацию iptables в файл /etc/sysconfig/iptables. Тут следует сразу отметить, что пример сценария (см. листинг 1) ориентирован на использование в дистрибутивах Fedora/Red Hat. Для применения с другими дистрибутивами Linux необходимо будет произвести небольшие изменения.

Листинг 1. Сценарий, блокирующий атаки на ssh

 

#!/usr/bin/perl -w

use Sys::Syslog; # модуль для работы с syslog

$max=10; # максимально разрешенное число попыток

 

# файл журнала, с которым мы и работаем

$watchfile=         '/var/log/messages';

 

# путь к iptables (для разных дистрибутивов Linux он может различаться)


Предыдущая страницаОглавлениеСледующая страница
 
[001] [002] [003] [004] [005] [006] [007] [008] [009] [010] [011] [012] [013] [014] [015] [016] [017] [018] [019] [020]
[021] [022] [023] [024] [025] [026] [027] [028] [029] [030] [031] [032] [033] [034] [035] [036] [037] [038] [039] [040]
[041] [042] [043] [044] [045] [046] [047] [048] [049] [050] [051] [052] [053] [054] [055] [056] [057] [058] [059] [060]
[061] [062] [063] [064] [065] [066] [067] [068] [069] [070] [071] [072] [073] [074] [075] [076] [077] [078] [079] [080]
[081] [082] [083] [084] [085] [086] [087] [088] [089] [090] [091] [092] [093] [094] [095] [096] [097] [098] [099] [100]
[101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120]
[121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140]
[141] [142] [143] [144] [145] [146] [147]

+7 (831) 413-63-27
ООО Дельта-Технология ©2007 - 2023 год
Нижний Новгород, ул. Дальняя, 17А.
Rambler's Top100