[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Безопасность" / Оглавление документа

Реализация Сканера Злонамеренного Кода на Уровне Сокетов в Ядре Linux

Все сетевые соединения в системе Linux основаны на сокетах. Их-то мы и рассмотрим в этом разделе. Сокеты в целом являются реализациями протоколов, таких как IP, TCP, UDP и ICMP, 3-го и 4-го уровней по ISO-OSI. Для проверки потоков данных UDP и TCP должны контролироваться. Другие протоколы, например SPX/IPX, при желании также могут быть задействованы.

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

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

Наш механизм сканирования, реализованный в настоящее время, вызывается отправкой запроса к ADF для получения типа доступа READ, для цели IPC (Inter-Process Communication), в функциях чтения TCP и UDP, задающих идентификатор сокета, длину и позицию памяти текущего потокового сегмента, а также тип протокола в параметре атрибута.

Если был обнаружен злонамеренный код и, соотвественно, было принято решение "not_granted", то оригинальное возвращаемое значение, длина сегмента, сменяется на код ошибки "malware-detected".

После проверки сегмента данных состояние сканера сохраняется в атрибуте защиты объектов IPC-типа модуля ACI, включая необходимое количество уже прочитанных данных для отступа в алгоритме сканирования, флаг scan-result и размер последнего полученного сегмента.

Как описывалось ранее, при обнаружении злонамеренного кода, в коде принятия решения о допуске, могут иметь место различные действия, в зависимости от типа запрашиваемого процесса. Тогда как TCP-соединение блокируется ядром и закрывается вызывающим процессом, то предпринятие действий в отношении UDP-потока более проблематично, из-за неопределённости идентификатора отправителя.

Для TCP используется ACI-атрибут ms-sock-trusted-tcp, который может иметь три значения:

"not_trusted":

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

"active":

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

"full":

процесс имеет обычный не ограниченный доступ к данным

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

Воздействие сканирования на уровне сокетов на сетевую производительность всё-ещё не измерено, но оно определяется, главным образом, алгоритмом сканирования и и количеством выполненных циклов. Основной запрос решения на стандартном Pentium PC, работающем с 10 Mbit Ethernet, как показывают наши тесты для других компонентов RSBAC, не заметен.

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

Партнёры:

Хостинг: