Угроза избыточного выделения оперативной памяти
Обновлено: 07.07.2024
Памяти свойственно утекать, образовывая мощные осадочные пласты в адресном пространстве, которые уже никогда не вернутся обратно в общий пул, а потому, сколько бы виртуальной памяти у нас не было, рано или поздно она все-таки заканчивается, что особенно актуально для серверов, пилотируемых в круглосуточном режиме без ежедневных перезагрузок. И хотя разработчики периодически исправляют ошибки, реальной помощи от них ждать не приходится, и мы остаемся со своими проблемам один на один.
Большинство статей, посвященных проблемам утечек ресурсов, ориентировано главным образом на программистов, имеющих в своем распоряжении исходные коды и обширный набор различных диагностических утилит: от штатных отладчиков, входящих в комплект поставки компилятора, до специализированных анализаторов типа IBM Rational Purify, BoundsChecker или Valgrind.
Работа с исполняемыми модулями уже откомпилированных программ в лучшем случае поддерживается в очень ограниченном режиме (а зачастую не поддерживается вообще), но, как бы там ни было, даже обнаружив место утечки, устранить ее непосредственно в машинном коде может только продвинутый хакер. Сколько времени он проведет за отладчиком, неизвестно, и кто оплатит его работу, остается только гадать.
Мы же люди простые. Администраторы мелкокорпоративных, офисных или даже домашних серверов, работающих, как правило, на основе NT-based систем. Исходных текстов у нас нет, да и времени/средств на исправление чужих ошибок - тоже. Тем не менее, бороться с утечками все же приходится. Кому не случалось перегружать зависший сервер, не реагирующий даже на <Ctrl-Alt-Del>, и давить на Reset с угрозой разрушения дискового тома и потери кучи оперативных данных?
Классификация утечек и причины их возникновения
Прежде чем бороться с утечками, необходимо разобраться, что это вообще такое и почему это происходит. Куда утекает память? Риторический вопрос! Никуда она не утекает, просто неудачный термин. Правильнее говорить об «отложении» или «пластовании» ресурсов, по аналогии с осадочными слоями. Рассмотрим следующий (вполне классический) пример:
foo(char *x)
// выделяем буфер из динамической памяти (также называемой кучей)
char *p = malloc(MAX_SIZE);
// если строка не влезает в буфер, возвращаемся из функции
if (strlen(x) >= MAX_SIZE)
return ERR_STR_TOO_LONG;
// копируем строку в буфер
strcpy(p, x);
// делаем с ней что-нибудь полезное
// освобождаем выделенную память
free(p);
return OK;
>
При этом от разработчиков серверных приложений автору постоянно приходится слышать, что, мол, проблема утечек фундаментальна и что если сервер теряет не более 1 Кб памяти в секунду, это вполне нормально. Количество установленной физической памяти не играет никакой роли, и падение производительности за счет утечек практически полностью нивелируется тем фактом, что операционная система вытесняет неиспользованные страницы на диск в файл подкачки. Однако адресное пространство процесса небезгранично и на 32-битных платформах по умолчанию составляет чуть менее 2 Гб (остальные 2 Гб занимают ядро ОС, ядерные структуры данных, драйвера и т.д.).
Легко рассчитать, что если память утекает со скоростью 1 Кб в секунду, то адресное пространство будет полностью исчерпано за 25 дней, а на самом деле намного раньше, поскольку, помимо динамической памяти, в обозначенные 2 Гб входят стек, образы исполняемых файлов и библиотек, структуры данных операционной системы прикладного режима и т.д. Для рабочей станции функционировать в течение месяца без перезагрузок — слегка противоестественно, а вот для серверов это вполне нормальное состояние, но, чтобы они не грохнулись раньше времени, необходимо преодолеть утечки.
Утечки делятся на две категории: жесткие (hard) и мягкие (soft). Мягкие утечки (также называемые локальными) действуют только в течение определенного периода времени, а затем возвращают «награбленные» ресурсы в общий пул. Вот, например, некоторый сервер обрабатывает запросы пользователей в отдельном потоке и под каждый запрос выделяет определенное количество памяти, но не освобождает ее после завершения обработки запроса, однако при отключении клиента вся память освобождается одним махом. Вот это и называется локальной утечкой.
Жесткие (или глобальные) утечки не освобождаются, пока администратор не отправит сервер в shutdown или не перезагрузит ОС. Последний момент очень важен! Если приложение выделяет блоки совместно используемой памяти (shared memory), то они не освобождаются вместе с завершением выделившего их процесса и продолжают болтаться в адресном пространстве вплоть до полной перезагрузки.
Кстати, помимо утечек памяти, существует проблема утечки и прочих системных ресурсов, например файловых дескрипторов, количество которых хоть и велико, но все же конечно. Если сервер открывает файлы, забывая их закрыть, то в какой-то момент система просто рухнет, будучи не в силах открыть файл даже для своих сугубо системных нужд.
Утечка ресурсов как направленная атака
Приложение может работать годами, не вызывая никаких проблем и вдруг. администратора начинают доставать непрекращающиеся утечки. Но ведь машинный код, в отличие от фрегата, не может прохудиться от старости!
Все дело в том, что существует целый подкласс DoS-атак, вызывающих отказ в обслуживании путем генерации запросов, приводящих к утечкам памяти. Вернемся к фрагменту исходного кода, демонстрирующего утечку памяти. Допустим, что процедура foo() обрабатывает поля некоторого заголовка, причем длина строки MAX_SIZE выбрана программистом с большим запасом, так что нормальные запросы обрабатываются без каких-либо проблем. Но вот коварные хакеры находят ошибку в коде и начинают бомбардировать сервер строками невероятной длины. И хотя это не приводит к немедленному отказу, количество свободной памяти постепенно уменьшается вплоть до полного исчерпания кучи.
К сожалению, разработчики и специалисты по безопасности склонны недооценивать этот подкласс атак, поскольку ни к захвату управления, ни к утрате конфиденциальности он не приводит, а потому заплатки под известные дыры зачастую вообще не выпускаются!
Схватка с утечками в рукопашную
Залогом успешной борьбы с утечками становится заблаговременная подготовка. Прежде всего, постарайся до максимума увеличить объем виртуальной памяти. Учти, что если стартовый объем файла подкачки меньше конечного, то при достижении пороговой величины система попытается увеличить размер файла подкачки (если дискового места хватит). Причем все запросы на выделение памяти в это время будут отклоняться, и приложение вместо валидного указателя получит ноль, а вот как оно отреагирует на это, сказать сложно (пример такой ситуации совсем недавно описывалась в одной из наших статей - "История зависшего гаджета"). Часть приложений
завершит свою работу в аварийном режиме (с потерей несохраненных данных), часть поведет себя неадекватно, выдавая странные результаты. Так что лучше не мелочиться, не жертвовать дисковым пространством, а если уж выделять, то выделять! Но сколько?
Допустим, у нас есть k серверных приложений, и они порождают n процессов (их легко посчитать в диспетчере задач). Поскольку на 32-битных платформах каждый процесс владеет 4 Гб оперативной памяти, нам потребуется 4*(MAX(k, n) Гб памяти и еще пара гигабайт под системные нужды. Однако при изменении размера файла подкачки через графический интерфейс («Мой компьютер -> Свойства системы -> Дополнительно -> Параметры быстродействия -> Виртуальная память -> Изменить») мы ограничены четырехразрядным полем в мегабайтах, то есть не можем получить более 10 Гб виртуальной памяти. Для большинства нужд этого более чем достаточно, однако для серверов с многодневным аптаймом, на которых установлена куча
серверных приложений, возможно, потребуется и больший объем. Установить его поможет бесплатная утилита pagefileconfig.vbs.
Однако, независимо от количества имеющейся виртуальной памяти, каждый процесс в свое распоряжение получает чуть меньше двух гигабайт кучи, чего при интенсивных утечках хватает совсем ненадолго. А потом бац - и сервер в дауне! Иди поднимай его потом.
[Boot Loader]
Timeout=30
Default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows Server 2003" /3GB
Перезагрузка приложений
Если планируется использовать сервер в полностью автономном режиме длительное время (например, ты уезжаешь в отпуск, оставляя домашний компьютер с ftp-архивом предоставленным самому себе), то тогда потребуются намного более радикальные меры борьбы с утечками. А именно - периодический перезапуск серверных приложений командой kill.exe (входит в бесплатно распространяемый набор Microsoft Debugging Tools, Support Tools, а также в Microsoft Platform SDK), закинутой в системный планировщик (смотри описание штатной команды at).
Кстати говоря, многие серверы имеют свои собственные встроенные планировщики, позволяющие делать мягкий shutdown, при котором блокируется подключение новых клиентов и в момент, когда отваливается последний из имеющихся, сервер отправляет себя на перезагрузку.
С серверами, реализованными как системные службы, дела в некотором смысле обстоят намного лучше, поскольку всякая служба обязана (по условиям спецификации) поддерживать мягкую перезагрузку без потерь оперативных данных. Однако далеко не всякая мягкая перезагрузка возвращает «осадочную» память, к тому же источником утечек вполне может оказаться и головной процесс SERVICES.EXE, которым «крышуются» все службы.
System Process (0)
System (8)
SMSS.EXE (232)
CSRSS.EXE (260)
WINLOGON.EXE (280) NetDDE Agent
SERVICES.EXE (308)
svchost.exe (480)
DLLHOST.EXE (1048)
Smc.exe (504) Sygate Personal Firewall
ups.exe (536)
svchost.exe (568) MCI command handling window
vmware-authd.ex (1240)
Вопрос из зала: а с какой частотой следует перегружать серверные процессы, или даже операционную систему целиком, если перезагрузка этого процесса невозможна? Ответ: чтобы не привязываться к конкретному расписанию, будем периодически вызывать API-функцию VirtualQueryEx, возвращающую размер виртуальной памяти, потребляемый каждым процессом, и, как только он достигнет определенного порогового значения, выбранного нами заранее, уходить в reboot (естественно, для этого необходимо хоть немного уметь программировать).
Функция VirtualQueryEx принимает на грудь дескриптор процесса и возвращает следующие данные:
typedef struct _MEMORY_BASIC_INFORMATION // базовый адрес региона
PVOID BaseAddress;
// базовый адрес выделенного блока памяти
PVOID AllocationBase;
// «первородные» атрибуты защиты
DWORD AllocationProtect;
// размер региона в байтах
DWORD RegionSize;
// тип региона (выделен, закреплен, свободен)
DWORD State;
// текущие атрибуты защиты
DWORD Protect;
// тип страниц памяти
DWORD Type;
> MEMORY_BASIC_INFORMATION;
Вызывая ее многократно с различными базовыми адресами, мы в итоге получим полную картину адресного пространства, которая позволит нам принять решение о перезагрузке, когда свободных блоков практически не останется (тут, кстати говоря, необходимо учесть, что, даже если мы имеем 100 несмежных свободных блоков по 4 Кб, а программа просит каких-то жалких 10 Кб, запрос на выделение памяти не может быть выполнен в силу фрагментации кучи, а потому суммарный размер свободных блоков еще ни о чем не говорит).
Детали реализации мы оставим в стороне. Это совсем несложная утилита, которую легко написать менее чем за вечер, однако она необыкновенно эффективна при «разруливании» автопилотируемых серверов.
Принудительное освобождение памяти
А вот не хотим мы перезапускать ни серверное приложение, ни саму операционную систему. Не хотим и все! Что тогда? Вот тогда-то нам и пригодится весьма продвинутая методика, дающая неплохой результат, хотя и без всяких гарантий. Анализ большого количества программ, страдающих хроническими утечками памяти, показал, что указатели на блоки динамической памяти, как правило, помещаются в локальные стековые переменные, автоматически уничтожаемые компилятором при выходе из функции. Следовательно, если на данный блок динамической памяти не ссылаются ни другие блоки, ни локальные переменные, то его можно считать с высокой степенью вероятности «потерянным» и с некоторым риском освободить,
возвращая память обратно в кучу.
Подобный «сборщик мусора» представляет собой довольно сложную программу, вынужденную учитывать многие нюансы. У мыщъх'а пока что имеется pre-alpha версия, предназначенная для сугубо внутреннего использования.
Как она работает? Вместо того чтобы определять границы стека каждого из потоков, мыщъх просто сканирует адресное пространство процесса (естественно, исключая невыделенные блоки), выцеживая 32-битные значения, похожие на указатели. Похожие - это находящиеся в пределах динамических блоков памяти, полный перечень которых можно получить посредством следующих API-функций: CreateToolhelp32Snapshot\Heap32First\ Heap32ListFirst\Heap32ListNext\Heap32Next.
Занятые блоки динамической памяти, в границах которых нет ни одного указателя, считаются «осадочными» и освобождаются. А вот как они освобождаются — это уже вопрос. Можно, конечно, вызывать API-функцию VirtualFreeEx, но! Компиляторы работают с динамической памятью не напрямую, а посредством своих собственных библиотек времени исполнения (Runtime Library, или сокращенно RTL). Любая работа с динамической памятью в обход RTL-менеджера неминуемо приводит к краху приложения. Поэтому мы должны впрыснуть свой код в подопытный процесс и вызывать RTL-функцию освобождения памяти. Например, в языке Си это функция free().
Имеются, естественно, и другие трудности, но их обсуждение выходит за рамки этой статьи. Главное, что освобождение «потерянной» памяти все-таки возможно!
Заключение
Мыщъх предложил несколько достаточно эффективных методов борьбы с утечками памяти, опробованных как на домашнем сервере, так и на серверах ряда мелких предприятий. И хотя до «промышленного» внедрения этим методикам еще далеко, они работают. Мыщъх продолжает рыть землю в этом направлении, разрабатывая полностью автоматизированный «сборщик мусора», ориентированный на откомпилированные программы без исходных текстов. Желание принять участие в проекте всячески приветствуется. В общем, дорогу осилит идущий!
Полную версию статьи
читай в сентябрьском номере
Хакера!
При обработке информации на уровне ПУ возможна реализация следующих УБИ:
угрозы информации, обрабатываемой в технических средствах ПУ;
угрозы НСД в ПУ связаны с действиями нарушителей, имеющих доступ к ПУ. Кроме этого, источниками угроз НСД к информации в ПУ могут быть нарушители с различным потенциалом, а также аппаратные закладки и вредоносные программы;
угрозы преднамеренного искажения системного времени в компонентах ИСУЭ.
В ПУ возможны уязвимости в микропрограммном обеспечении, уязвимости, связанные с используемыми протоколами передачи данных, уязвимости, в связи с возможностью наличия аппаратных закладок, уязвимости связанные с недостатками организации ТЗИ от НСД, уязвимости вСЗИ.
В ПУ в соответствии с используемыми технологиями, объектами воздействия, уязвимостями возможны следующие угрозы из Банка данных угроз безопасности информации ФСТЭК России:
УБИ.006: Угроза внедрения кода или данных;
УБИ.007: Угроза воздействия на программы с высокими привилегиями;
УБИ.008: Угроза восстановления и/или повторного использования аутентификационной информации;
УБИ.012: Угроза деструктивного изменения конфигурации/среды окружения программ;
УБИ.014: Угроза длительного удержания вычислительных ресурсов пользователями;
УБИ.015: Угроза доступа к защищаемым файлам с использованием обходного пути;
УБИ.019: Угроза заражения DNS-кеша;
УБИ.022: Угроза избыточного выделения оперативной памяти;
УБИ.023: Угроза изменения компонентов информационной; (автоматизированной) системы;
УБИ.025: Угроза изменения системных и глобальных переменных;
УБИ.026: Угроза искажения XML-схемы;
УБИ.027: Угроза искажения вводимой и выводимой на периферийные устройства информации;
УБИ.028: Угроза использования альтернативных путей доступа к ресурсам
УБИ.030: Угроза использования информации дентификации/аутентификации, заданной по умолчанию;
УБИ.031: Угроза использования механизмов авторизации для повышения привилегий;
УБИ.033: Угроза использования слабостей кодирования входных данных;
УБИ.034: Угроза использования слабостей протоколов сетевого/локального обмена данными;
УБИ.035: Угроза использования слабых криптографических алгоритмов BIOS;
УБИ.036: Угроза исследования механизмов работы программы;
УБИ.037: Угроза исследования приложения через отчеты об ошибках;
УБИ.049: Угроза нарушения целостности данных кеша;
УБИ.061: Угроза некорректного задания структуры данных транзакции;
УБИ.063: Угроза некорректного использования функционала программного и аппаратного обеспечения;
УБИ.069 <5>: Угроза неправомерных действий в каналах связи;
<5> Указанная угроза может быть нейтрализована без применения СКЗИ.
УБИ.067: Угроза неправомерного ознакомления с защищаемой информацией;
УБИ.083 <6>: Угроза несанкционированного доступа к системе по беспроводным каналам;
<6> Указанная угроза может быть нейтрализована без применения СКЗИ.
УБИ.086: Угроза несанкционированного изменения аутентификационной информации;
УБИ.088: Угроза несанкционированного копирования защищаемой информации;
УБИ.089: Угроза несанкционированного редактирования реестра;
УБИ.090: Угроза несанкционированного создания учетной записи пользователя;
УБИ.091: Угроза несанкционированного удаления защищаемой информации;
УБИ.092: Угроза несанкционированного удаленного внеполосного доступа к аппаратным средствам;
УБИ.093: Угроза несанкционированного управления буфером;
УБИ.094: Угроза несанкционированного управления синхронизацией и состоянием;
УБИ.095: Угроза несанкционированного управления указателями;
УБИ.098: Угроза обнаружения открытых портов и идентификации привязанных к ним сетевых служб;
УБИ.099: Угроза обнаружения хостов;
УБИ.100: Угроза обхода некорректно настроенных механизмов аутентификации;
УБИ.102: Угроза опосредованного управления группой программ через совместно используемые данные;
УБИ.103: Угроза определения типов объектов защиты;
УБИ.104: Угроза определения топологии вычислительной сети;
УБИ.107: Угроза отключения контрольных датчиков;
УБИ.109: Угроза перебора всех настроек и параметров приложения;
УБИ.111: Угроза передачи данных по скрытым каналам;
УБИ.113: Угроза перезагрузки аппаратных и программно-аппаратных средств вычислительной техники;
УБИ.114: Угроза переполнения целочисленных переменных;
УБИ.115: Угроза перехвата вводимой и выводимой на периферийные устройства информации
УБИ.116: Угроза перехвата данных, передаваемых по вычислительной сети;
УБИ.117: Угроза перехвата привилегированного потока;
УБИ.118: Угроза перехвата привилегированного процесса;
УБИ.120: Угроза перехвата управления средой виртуализации;
УБИ.121: Угроза повреждения системного реестра;
УБИ.122: Угроза повышения привилегий;
УБИ.124: Угроза подделки записей журнала регистрации событий;
УБИ.127: Угроза подмены действия пользователя путем обмана;
УБИ.128: Угроза подмены доверенного пользователя;
УБИ.130: Угроза подмены содержимого сетевых ресурсов;
УБИ.131: Угроза подмены субъекта сетевого доступа;
УБИ.132: Угроза получения предварительной информации об объекте защиты;
УБИ.139: Угроза преодоления физической защиты;
УБИ.140: Угроза приведения системы в состояние "отказ в обслуживании";
УБИ.143: Угроза программного выведения из строя средств хранения, обработки и (или) ввода/вывода/передачи информации;
УБИ.145: Угроза пропуска проверки целостности программного обеспечения;
УБИ.148: Угроза, сбоя автоматического управления системой разграничения доступа хранилища больших данных;
УБИ.149: Угроза, сбоя обработки специальным образом измененных файлов;
УБИ.152: Угроза удаления аутентификационной информации;
УБИ.153: Угроза усиления воздействия на вычислительные ресурсы пользователей при помощи сторонних серверов;
УБИ.155: Угроза утраты вычислительных ресурсов;
УБИ.156: Угроза утраты носителей информации;
УБИ.157: Угроза физического выведения из строя средств хранения, обработки и (или) ввода/вывода/передачи информации;
УБИ.160: Угроза хищения средств хранения, обработки и (или) ввода/вывода/передачи информации;
УБИ.162: Угроза эксплуатации цифровой подписи программного кода
УБИ.163: Угроза перехвата исключения/сигнала из привилегированного блока функций;
УБИ.165: Угроза включения в проект не достоверно испытанных компонентов;
УБИ.166: Угроза внедрения системной избыточности;
УБИ.169: Угроза наличия механизмов разработчика;
УБИ.170: Угроза неправомерного шифрования информации;
УБИ.171: Угроза скрытного включения вычислительного устройства в состав бот-сети;
УБИ.177: Угроза неподтвержденного ввода данных оператором в систему, связанную с безопасностью;
УБИ.178: Угроза несанкционированного использования системных и сетевых утилит;
УБИ.179: Угроза несанкционированной модификации защищаемой информации;
УБИ.180: Угроза отказа подсистемы обеспечения температурного режима;
УБИ.181: Угроза перехвата одноразовых паролей в режиме реального времени;
УБИ.182: Угроза физического устаревания аппаратных компонентов;
УБИ.183: Угроза перехвата управления автоматизированной системой управления технологическими процессами;
УБИ.185: Угроза несанкционированного изменения параметров настройки средств защиты информации;
УБИ.187: Угроза несанкционированного воздействия на средство защиты информации;
УБИ.188: Угроза подмены программного обеспечения;
УБИ.189: Угроза маскирования действий вредоносного кода;
УБИ.191: Угроза внедрения вредоносного кода в дистрибутив программного обеспечения;
УБИ.192: Угроза использования уязвимых версий программного обеспечения;
УБИ.193: Угроза утечки информации за счет применения вредоносным программным обеспечением алгоритмов шифрования трафика;
УБИ.195: Угроза удаленного запуска вредоносного кода в обход механизмов защиты операционной системы;
УБИ.198: Угроза скрытной регистрации вредоносной программой учетных записей администраторов;
УБИ.203: Угроза утечки информации с неподключенных к сети Интернет компьютеров;
УБИ.204: Угроза несанкционированного изменения вредоносной программой значений параметров программируемых логических контроллеров
УБИ.205: Угроза нарушения работы компьютера и блокирования доступа к его данным из-за некорректной работы установленных на нем средств защиты;
УБИ.208: Угроза нецелевого использования вычислительных ресурсов средства вычислительной техники;
УБИ.209: Угроза несанкционированного доступа к защищаемой памяти ядра процессора;
УБИ.210: Угроза нарушения работы информационной системы, вызванного обновлением используемого в ней программного обеспечения;
УБИ.212: Угроза перехвата управления информационной системой;
УБИ.213: Угроза обхода многофакторной аутентификации;
УБИ.214: Угроза несвоевременного выявления и реагирования компонентами информационной (автоматизированной) системы (в том числе средствами защиты информации) на события безопасности информации;
УБИ.217: Угроза использования скомпрометированного доверенного источника обновлений программного обеспечения.
Обоснование неприменимости угроз к ПУ в связи с отсутствием технологий представлено в таблице 4.
Таблица 4. Обоснование неприменимости угроз к ПУ в связи с отсутствием технологий.
Сложные технологические процессы, применяемые для получения электроэнергии, должны быть непрерывны; это достигается путём использования автоматизированных систем управления технологическими процессами (АСУ ТП), а также за счёт слаженной работы различных служб предприятия и немалого количества персонала. Автоматизация приводит к тому, что генерирующие объекты энергосистемы могут быть уязвимыми с точки зрения информационной безопасности и оказываться целями кибератак. Постараемся провести объективный анализ мероприятий по обеспечению защиты АСУ ТП, которые реализуются на большинстве генерирующих объектов энергетики, таких как городская теплоэлектроцентраль (ТЭЦ).
Введение
Для того чтобы понять причины, по которым возникла проблематика обеспечения ИБ на теплоэлектроцентралях, следует обратиться к истории появления и эксплуатации таких объектов. Большинство ныне работающих ТЭЦ строились в советскую эпоху, и АСУ ТП реализовывались на отечественной программно-аппаратной базе. Подсистем их защиты никто не создавал, поскольку тогда безопасность обеспечивали на уровне организационно-распорядительных документов и физической изоляции АСУ ТП.
В 2000-е годы началось масштабное обновление устаревших объектов генерации. В первую очередь модернизировалось газовое оборудование, менялись устаревшие системы АСУ ТП. Однако эти процессы опять же в основном не затрагивали защиту от информационных угроз.
Появление Федерального закона №187-ФЗ от 26 июля 2017 г., предписывающего обеспечивать безопасность критической информационной инфраструктуры (КИИ), заставило субъектов энергетики пересмотреть подходы и принципы к защите подведомственных им комплексов оборудования. Нарушения работы ТЭЦ могут привести к тому, что потребители лишатся энергоресурсов, и зачастую носят межмуниципальный характер; согласно упомянутому выше закону, АСУ ТП теплоэлектроцентралей относятся к КИИ и требуют обязательной защиты.
Постановление Правительства РФ №127 и приказы ФСТЭК России №235, №239 дополняют Федеральный закон №187-ФЗ и регламентируют обеспечение информационной безопасности объектов КИИ. К сожалению, эти документы только предъявляют требования и не содержат методических указаний относительно того, как модернизировать существующие АСУ ТП в части реализации механизмов или внедрения средств защиты информации.
Процесс обеспечения защиты АСУ ТП
Перечислим работы, необходимые для обеспечения защиты АСУ ТП как объекта критической информационной инфраструктуры.
- Проведение независимого аудита систем АСУ ТП. На этом этапе выполняется анализ действующих организационных мер, политик и концепций по защите информации; документов, регламентирующих использование средств и методов защиты информации; организационной структуры обслуживающего персонала и должностных инструкций; перечня ответственных лиц и их функциональных обязанностей; действий при внештатных ситуациях; процедур восстановления работоспособности системы, учёта оборудования и программного обеспечения; механизмов отключения от рабочего контура, обмена оборудования и программного обеспечения при выводе на ремонт; регламента назначения прав доступа.
- Разработка модели угроз и модели нарушителя. В состав этого шага входят: определение перечня угроз безопасности, определение вероятности осуществления каждой из них, оценка актуальности угроз, анализ эффективности существующих и имеющихся в наличии мер и средств защиты информации, оценка возможностей физического доступа к объектам АСУ ТП, выявление возможных технических каналов утечки информации.
- Проектирование системы защиты информации.
- Внедрение средств защиты информации (ЗИ). Этот этап включает поставку технических средств ЗИ, установку и настройку средств ЗИ, предварительные испытания комплекса защиты АСУ ТП и его передачу в опытную эксплуатацию, а также передачу комплекса средств защиты информации АСУ ТП в промышленную эксплуатацию.
- Разработка организационно-распорядительных документов. Их содержание описывает отдельные меры защиты информации в АСУ, планирование мероприятий по обеспечению этой защиты, реализацию действий в нештатных (непредвиденных) ситуациях в ходе эксплуатации АСУ, информирование и обучение персонала, работающего с комплексом защиты АСУ, анализ угроз безопасности информации в АСУ и рисков от их реализации, управление (администрирование) комплекса защиты системы, выявление инцидентов (одного события или группы событий), которые могут привести к сбоям или нарушению функционирования АСУ и (или) к возникновению угроз безопасности информации, и реагирование на них, а также управление конфигурацией АСУ и её комплекса защиты, контроль (мониторинг) обеспечения уровня защищённости АСУ и борьбу с угрозами при выводе системы из эксплуатации.
Приведём наиболее распространённые меры, применяемые для защиты информации в АСУ ТП на теплоэлектроцентралях:
- АСУ ТП функционирует в изолированном контуре инфраструктуры.
- Для взаимодействия с сетью предприятия создаётся «демилитаризованная зона» (ДМЗ).
- Блокируется доступ к интерфейсам ввода-вывода.
- Ограничивается физический доступ к оборудованию.
- На рабочие места оператора АСУ ТП и администратора, дежурного смены устанавливается антивирус.
- На автоматизированные рабочие места устанавливается сканер уязвимостей (в виде агента).
- Устанавливается пароль на BIOS.
- Запрещается загрузка с альтернативных носителей.
- На базе средств операционной системы реализуется управление правами доступа пользователей.
- Права пользователей системы АСУ ТП ограничиваются встроенными средствами самой системы.
Уровень защищённости АСУ ТП теплоэлектроцентралей
Для понимания того, насколько АСУ ТП теплоэлектроцентралей защищены от информационных рисков, предлагаем рассмотреть реальные угрозы и вызовы, с которыми могут столкнуться специалисты по ИБ на таких объектах с учётом нового технологического уклада. Для этого будем использовать банк данных ФСТЭК России.
Таблица 1. Описание угроз безопасности информации, актуальных для АСУ ТП
Использую windows 10, недавно установил большое обновление Anniversary. Но проблема, которую я опишу ниже возможно не связана с ним, а началась еще до обновления.
После некоторого времени при работе с компьютером оперативная память забивается на 95%, после выключения всех запущенных приложений занятость озу падает до 85-90%. В диспетчере задач на вкладках Процессы и Подробности никаких процессов, которые бы занимали оперативку нет. Данная проблема возникает не систематически, а через раз. Иногда может пройти 2 часа, а иногда пол дня.
Чаще всего перед этим я использую следующее ПО:
phpStorm последней версии (64bit +java64), git +chrome, photoshop.
virtualbox с установленной на виртуалку ubuntu.
Также играю в различные игры.
После перезагрузки и включения этих программ они занимают от силы 40% моего общего ОЗУ.
Но, когда оперативка заполнена, даже после выключения остается занято 80%.
Попробовал очистить ее с помощью программы Memory Cleaner, не помогло.
Выключал в службах superFetch, вроде бы тоже не помогло.
Какие есть предположения в чем может быть проблема? Хотелось бы услышать комментарий по поводу того, аппаратная ли это проблема или программная и какими средствами(ПО) я могу определить, что занимает оперативную память.
Эта цепочка заблокирована. Вы можете просмотреть вопрос или оставить свой голос, если сведения окажутся полезными, но вы не можете написать ответ в этой цепочке.14 польз. нашли этот ответ полезным
К сожалению, это не помогло.
Благодарим за отзыв, он поможет улучшить наш сайт.
Благодарим за отзыв.
Вообщем ситуация сделающая, сегодня был включен стим, utorrent качал, виртуалка, php-storm+xdebux и chrome. Комп начал жутко лагать, я все-все выключил, результат на скринах ниже.
5 польз. нашли этот ответ полезным
К сожалению, это не помогло.
Благодарим за отзыв, он поможет улучшить наш сайт.
Благодарим за отзыв.
В ответ на запись пользователя AlexandrDutov от 26 августа, 2016Добрый день, Александр.
Сожалею о данной проблеме.
Этот вопрос неоднократно обсуждался.
Попробуйте применить решения из подобных тем.
Пожалуйста, сообщите мне о результатах.
Желаю удачи и хорошего дня!
Если вы считаете эту информацию полезной, прошу отметить ее как ответ
К сожалению, это не помогло.
Благодарим за отзыв, он поможет улучшить наш сайт.
Благодарим за отзыв.
У меня та же ситуация. Это связано с одним из последних обновлений виндовс. Ранее такой ситуации не наблюдалось. Все верно описано, память занята, процесса нет занимающего ее, у меня так же 16 гб и при штатном использовании все 100% занять очень сложно. Кроме фотошопа у меня ничто другое не способно занять всю память.
Лично я знаю много людей у которых наблюдаеться то же самое.
Я так понимаю что в майкрософт забили на это и ничего исправлять не собираються. Придется переходить на другую ОС, хотя бы для рабочих нужд, на виндовс становиться невозможно стабильно работать.
51 польз. нашли этот ответ полезным
К сожалению, это не помогло.
Благодарим за отзыв, он поможет улучшить наш сайт.
Благодарим за отзыв.
В ответ на запись пользователя OlehShpilka от 10 декабря, 2017Я так понимаю что в майкрософт забили на это и ничего исправлять не собираються.
Правильно поняли. Ошибки в драйверах, написанных другими компаниями, "Майкрософт" исправлять не будет. Заниматься выяснением, правильные ли драйверы поставил пользователь - тоже не будет.
8 польз. нашли этот ответ полезным
К сожалению, это не помогло.
Благодарим за отзыв, он поможет улучшить наш сайт.
Благодарим за отзыв.
В ответ на запись пользователя Igor Leyko от 10 декабря, 2017Я так понимаю что в майкрософт забили на это и ничего исправлять не собираються.
Правильно поняли. Ошибки в драйверах, написанных другими компаниями, "Майкрософт" исправлять не будет. Заниматься выяснением, правильные ли драйверы поставил пользователь - тоже не будет.
Вы сейчас о драйверах для оперативной памяти? Ведь проблема именно в ней, а конкретнее в ее использовании. Так вот, я никогда о таковых не слышал. И второе, я никаких драйверов не переустанавливал уже достаточно давно, а проблема появилась после обновления системы, и не у меня одного как я понимаю. Если у вас есть конкретный ответ на проблему, либо вы можете как либо обосновать что именно система не причем и вина в поставщике драйверов мы все (на данный момент 74 человека) будем вам крайне признательны.
И еще как вариант, может майкрософт будет так любезен в диспетчере все же показывать кем из "поставщиков"/процессов используется память.
П.С. Убунту я уже поставил, там таких проблем не наблюдается.
24 польз. нашли этот ответ полезным
К сожалению, это не помогло.
Благодарим за отзыв, он поможет улучшить наш сайт.
Благодарим за отзыв.
В ответ на запись пользователя OlehShpilka от 10 декабря, 2017Вы сейчас о драйверах для оперативной памяти?
Нет, конечно. О драйверах устройств, утечки памяти в которых и вызывают разрастание невыгружаемого пула.
То что проблема появилась после обновления системы, означает, что какой-то драйвер с новой версией работает некорректно.
Назвать драйвер телепатически я Вам, как Вы возможно понимаете и сами, не смогу, увы.
3 польз. нашли этот ответ полезным
К сожалению, это не помогло.
Благодарим за отзыв, он поможет улучшить наш сайт.
Благодарим за отзыв.
В ответ на запись пользователя Igor Leyko от 10 декабря, 2017Майкрософт ну вообще ни в чем не виновата. Ну прям святая.
Обновляет автоматически драйвера, а там трава не расти, ведь это производитель виноват. Проще всего перевести стрелки.
Но, когда сталкивались с проблемой работы Intel HD 4000 и установки драйверов на Windows 10 обращались в Intel. И Intel сообщил что драйвер рабочий, просто не сертифицирован Майкрософт.
Драйверы Windows 10 для процессоров Intel® Core™ третьего поколения с графическими решениями Intel® HD Graphics 4000 и процессоров Intel® Core™ третьего поколения с графическими решениями Intel® HD Graphics 2500 (раньше под кодовым названием Ivy Bridge) будут включать поддержу модели драйверов Windows Vista Display Driver Model (WDDM) 1.3 . Для ссылки функции WDDM 1.2 доступны на веб-сайте Microsoft. Этот драйвер Windows 10 не будет снабжен цифровой подписью , что означает, что это не было протестировано Windows Hardware Quality Labs (WHQL).
Так что же Майкрософт не протестирует драйвер ? А все потому, что наплевать!
Зачем же существует эта лаборатория WHQ ? Чтобы блокировать рабочие, по заявлению Intel, но не сертифицированные и не рекомендуемые по самомнению Майкрософт?
У сотен пользователей проблемы с драйверами, не только на старых устройствах обновленных по псевдоакции до Windows 10, но даже и на новых устройствах.
Зачем всё это?
Недавно были замечены проблемы на Nvidia GeForce 388.43 и конечно снова виноват производитель, но ведь Майкрософт WHQL как то тестирует драйверы и собирает сведения о них, перед обеспечиванием Цифровой подписью, но скорее всего нет.
Читайте также: