Технологии цифровых подписей 2 страница

Рис. 2. Структура сети с использованием продуктов RSA

Сервер RSA Authentication Manager осуществляет двухфакторную аутентификацию пользователей на основе показаний прибора SecurID. В отличие от сервера аутентификации VASCO VRM, пользователи взаимодействуют с сервером RSA ACE/Server посредством программных агентов RSA ACE/Agent. Такие агенты уже встроены в сотни современных серверов удаленного доступа, брандмауэров, маршрутизаторов, точек доступа беспроводных систем, есть также разработанные специально для широко распространенных Web-серверов (Microsoft IIS, Apache, Stronghold и SunONE), локального и удаленного доступа в ОС Windows и UNIX. Пример сети с использованием продуктов RSA приведен на рис. 2.

Кроме взаимодействия посредством агентов, RSA ACE/Server может применять протоколы аутентификации RADIUS и TACACS+. В состав RSA ACE/Server входит собственный сервер RADIUS, что позволяет иметь общую базу данных пользователей как для аутентификации по протоколу RADIUS, так и для аутентификации SecurID. При двухфакторной аутентификации требуется ввести идентификатор (имя) и пароль, состоящий из персонального идентификатора (PIN) и цифрового кода, отображаемого на дисплее SecurID в текущий момент.

Администрирование RSA Authentication Manager выполняется с графической консоли. С ее помощью назначаются идентификаторы доступа SecurID пользователям, устанавливаются правила разграничения доступа с возможностью задавать время, когда он разрешен, а также объединять пользователей в группы. RSA Authentication Manager позволяет импортировать данные из LDAP-директории, в которой централизованно хранятся данные о пользователях. На сервере ведется аудит доступа пользователей и действий администратора. Для увеличения производительности в случае аутентификации большого количества пользователей и обеспечения работоспособности сервера при выходе из строя аппаратного обеспечения RSA Authentication Manager допускает функционирование до 60 дублирующих серверов-реплик.

В состав сервера RSA Authentication Manager входят следующие компоненты:

• базы данных пользователей, идентификаторов доступа SecurID, агентов RSA ACE/Agent, аудита попыток аутентификации и действий администратора;

• процессор аутентификации;

• консоль администрирования;

• средства репликации базы данных и менеджера блокирования атак типа «replay»;

• сервер RADIUS;

• сервер TACACS+;

• утилита ускоренного администрирования Quick Admin с Web-интерфейсом.

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

Для защиты обмена служебной информацией между различными программными модулями сервера аутентификации RSA Authentication Manager, а также между сервером и агентами (RSA Authentication Agents) используется ее шифрование (с применением алгоритмов RC5 и DES).

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

RSA Authentication Manager может работать под управленим таких операционных систем:

• Microsoft Windows 2000 Server или Advanced Server;

• Microsoft Windows 2003 Server;

• HP-UX 11 на PA-RISC 2.x;

• IBM AIX 5L v.5.1 или 5.2 на PowerPC и RISC/6000;

• Solaris 8 или выше на UltraSPARC.

Интересным является устройство eToken NG-OTP компании Aladdin, представляющее собой комбинированный идентификатор доступа в формате USB со встроенным генератором OTP и ЖКИ для отображения одноразовых паролей. Помимо стандартных функций криптографического идентификатора доступа, таких как защищенное хранение секретных ключей и цифровых сертификатов пользователей, шифрования/дешифрования данных, цифровой подписи и т. п., он может генерировать одноразовые пароли для защищенного удаленного доступа мобильных пользователей к корпоративным ресурсам.

Как и в VRM компании VASCO, аутентификация в устройствах Aladdin базируется на протоколе RADIUS. Серверная часть решения встроена в систему управления средствами аутентификации TMS (Token Management System), которая служит для управления всем жизненным циклом как eToken, так и eToken NG-OTP.

Преимуществами двухфакторной аутентификации на основе eToken NG-OTP являются поддержка всех совместимых с RADIUS решений, шифрования и цифровой подписи почтовых сообщений, защиты ПК, защищенного доступа к Web и построения VPN с использованием eToken.

В качестве алгоритма криптографического преобразования входных данных для получения одноразового пароля в eToken NG-OTP применяется совместимый с OATH алгоритм, основанный на HMAC/SHA1.

В заключение отметим основные преимущества двухфакторной аутентификации с использованием OTP. К ним относятся:

• применение одноразовых паролей вместо статических (даже если злоумышленник подсмотрит пароль, он не сможет им воспользоваться, поскольку при следующей аутентификации сервер сгенерирует уже новый пароль);

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

• снижение затрат на администрирование, поскольку администратору не нужно периодически менять статические пароли на сервере;

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

• применение генераторов OTP возможно в тех случаях, когда пользователю недоступен USB-порт (либо он просто отсутствует – как в PDA, смартфонах, мобильных телефонах).

Средства защиты компьютерных систем при подключении к Интернет

Internet - огромная сеть построенная из множества совершенно независимых компьютеров, принадлежащим самым разным людям и организациям. На них хранится огромное количество интересной и самой разнообразной информации, часть из которой интересует совсем не тех людей или мешает им фактом своего существования. Это приводит к тому, что в последнее время появилось большое количество компьютерных преступников (именуемых 'хакерами'), поставивших целью своего существования взлом компьютерных систем. Так как в интернете отсутствует какой-либо централизованый контроль за действиями подобных личностей, каждому конкретному администратору каждой конкретной системы, подключенной к интернету приходится самому заботиться о безопасности (security) в своей системе.

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

Как известно, первые работоспособные unix-системы появились в середине-конце семидесятых и на сегодняшний день, благодаря своей масштабируемости и огромному количеству программ, они до сих пор остаются одними из лучших операционных систем для серверов и даже персональных компьютеров, особенно, когда дело касается локальных или глобальных сетей. К сожалению, большинство из таких систем имеют один огромный недостаток в интересующей нас области. Рут (root - главный администратор системы) имеет право делать с компьютером все, что захочет. Существование этого принципа подразумевает, что хакер, получив каким-нибудь образом права пользователя root, сможет сделать с данным компьютером (а во многих случаях - и со всей компьютерной системой, сообщающейся с данным компьютером) все что пожелает. Другие модели безопасности, имеющие несколько администраторов с ограниченными правами, на базе Unix-систем не реализуются из-за принципиальных правил построения таких систем или реализуются в ограниченном масштабе (например - многие коммерческие системы включают в себя поддержку ACL, позволяющую, в общем случае, разумно распределять права между отдельными администраторами, но все равно имеют пользователя root с неограниченными правами, что сводит все преимущества ACL к нулю). К слову, следует заметить, что в системах, не имеющих "пользователя с неограниченными правами", также имеется множество "лазеек", позволяющих эти права получить (например, классический сценарий взлома с правами backup-оператора). Однако, в Unix-системах для создания безопасности достаточно высокого уровня зачастую требуется приложить больше усилий, чем в системе с распределенными правами администраторов (разумеется, если дело не касается откровенно "клинических" случаев, вроде Windows NT, которую Microsoft пытается позиционировать как замену Unix-системам).

Другим минусом Unix-системы, с точки зрения безопасности, является один из ее плюсов - практически с любой подобной системой можно работать удаленно по сети так, как с локальным компьютером. В сочетании с принципом "рут может все" и легкостью работы с практически любыми внешними устройствами на всех уровнях (вплоть до физических) под Unix-системами, это делает подобные системы просто опасными (в первую очередь - для самих владельцев таких систем, во вторую - для их клиентов и партнеров), при отсутствии достаточно строгой системы безопасности. Данная проблема преследовала Unix-системы с самого рождения, но по настоящему остро она встала после распространения сети Internet, в которой каждый компьютер может атаковать сразу несколько злоумышленников, сидящих к тому же на другом материке.

Разумеется, наибольшую опасность для современных систем, имеющих хорошую историю борьбы с различными багами и дырами, представляет человеческий фактор. Любой человек совершает ошибки. С этим нужно мириться и стараться строить всю систему безопасности так, чтобы подобные ошибки не причиняли ей серьезного вреда. Перечень распространенных ошибок, приводящих к появлению "дыр" в системах безопасности очень широк, но наиболее часто встречаются следующие: установка и/или запуск непроверенных программ, различные попытки упростить администрирование (повторяющиеся пароли, раздача одного и того же административного аккаунта нескольким людям, установка чрезмерного количества специальных программ и сервисов, расширяющих количество вариантов администрирования (особенно удаленного) и т.д.), отсутствие хорошего контроля за деятельностью "простых" пользователей. Как видно, это именно человеческие ошибки и основной упор в защите компьютерных систем нужно делать на уменьшение вероятности их появления.

От теории перейдем к рассмотрению практических вариантов противодействия возможным попыткам взлома.

В большинстве случаев, первое что нужно сделать - это спрогнозировать направленность, источники и частоту попыток взлома. Банки, заводы, издательства, консультационные фирмы, торговые дома, фонды и биржи - все имеют высокие шансы подвергнуться атакам хакеров, желающих разбогатеть, стать известными за счет шумихи (часто подобная тенденция наблюдается среди молодежи с ее часто увеличенными комплексом неполноценности и желанием выделиться), получить доступ к интересной информации (часто - для того чтобы реализовать первый вариант) и просто навредить (такой мотив часто встречается в случае обиженных клиентов и работников фирм, происков конкурентов, заметания следов взлома и т.д.). Также существует проблемы, связаные с промышленным шпионажем и конкуренцией на фоне чрезмерно "свободного" рынка и отсутствием законодательной базы в области компьютерных преступлений (это я, конечно, про Россию). Анализ всех возможных вариантов и направлений атак дает возможность правильно расчитать направленность усилий по отдельным элементам систем безопасности и оптимально организовать доступ к защищаемой информации извне и изнутри. Разумеется, всегда следует правильно оценивать необходимые затраты по поддержанию требуемого уровня безопасности и стараться не впадать в паранойю на почве защиты от всего на свете (далее мы сможем увидеть, как подобная паранойя может даже облегчить возможный взлом).

Правильная организация локальной сети внутри компьютерной системы также является одной из ключевых областей компьютерной безопасности. Как правило, подобные сети реализуются на базе систем "каждый со всеми" (Ethernet) и гораздо реже - с применением других решений. В общем случае, локальную сеть следует рассматривать как один большой компьютер и, соответственно, считать каждую возможную "дыру" на отдельном компьютере сети, как общую для всех компьютеров этой сети. Большинство сценариев взлома построено на следующем принципе - получив доступ к одному из компьютеров, имеющему подключение к локальной сети, за счет возможностей перехвата пакетов на этой локальной сети, адресованных другим компьютерам, уменьшенным правилам фильтрации пакетов в пределах этой сети, упрощенным правилам предоставления административных сервисов между компьютерами сети, можно получить доступ и к остальным компьютерам этой локальной сети. Типичные действия, совершаемые для этого - перехват пакетов с данными авторизации (например, запуская программу типа tcpdump с фильтром на пакеты, идущие с/на 23-ий (telnet) и/или 21-ый (ftp) tcp-порты в течение достаточно долгого времени, хакер легко сможет узнать имена и пароли пользователей и, скорее всего, даже системных администраторов на компьютерах, стоящих в том же ethernet-сегменте, что и взломанный компьютер. Более сложные случаи включают в себя перехват пакетов систем типа NFS (шаринг файловых систем между хостами), YP (синхронизация данных авторизации на нескольких системах), которые часто используются в системах с большим количеством точек доступа)), анализ и использование систем доступа, основанных на "доверии" (rlogin, rsh, частные случаи использования ssh) между компьютерами локальной сети. В свете вышесказанного, при построении локальных сети компьютерной системы с доступом в Internet, следует разбивать ее на два или даже больше сегментов с фильтрацией пакетов между ними (в более "близких" к Internet сегментах, следует устанавливать компьютеры, которые непосредственно общаются с ним (www/ftp/что-то_еще-серверы), в более дальних - сервера баз данных, клиентские машины (их также желательно вынести в отедельный сегмент)). С огромной осторожностью следует относиться к применению программ типа rlogin и rsh, а при больших размерах сети - и telnet, ftp (лично я рассматриваю ssh, как хорошую замену для всех этих программ, дающую достаточный для большинства применений уровень защиты). Программные системы "раздачи" файлов или специальных данных по сети (NFS, samba, rdist, YP) также следует применять только в случаях крайней необходимости и по возможности - использовать для их траффика соединения "точка-точка" (ppp, slip, различные туннельные драйвера с шифрованием). Множество проблем с точки зрения безопасности в локальных сетях вызывает также необходимость создания бэкапов данных. Если бэкапы хранить на каждом компьютере отдельно - в случае его взлома, они могут быть утеряны (эту вероятность всегда следует оценивать как 100%). Если бэкапы хранить на других компьютерах - встают проблемы перехвата траффика с бэкапом данных авторизации и возможность "раскусить" пароли из бекапов от другой машины. Возможный выход из этой тяжелой ситуации - хранить копию бэкапов локально, а также сваливать их в шифрованном виде на один или несколько специальных бэкап-серверов, не имеющих больше никаких других сервисов и средств удаленного доступа (для уменьшения вероятности взлома этих бэкап-серверов и/или вывода их из строя до или на время взлома).

Фильтрация пакетов (файрволл) - очень мощное и удобное средство для ограничения доступа к компьютерным системам. Любое подключение компьютерной системы к сети Internet должно идти через файрволл. Он должен запрещать доступ к наименее защищенным от внешних влияний сервисам, использующих нешифрованные формы пересылки данных авторизации или вообще их неиспользующие (rlogin, rsh, telnet, NFS, YP, при необходимости - ftp, tftp, pop* и им подобные). Также запрету следует подвергать незапланированные исходящие соединения наружу (это будет хорошей защитой при использовании хакером различных sniffer-ов, "жучков" и "закладок"). При больших размерах сети - файрволлы следует также устанавливать между отдельными сегментами сети. К счастью, в большинстве современных Unix-систем имеется возможность включить на каждом компьютере свой маленький файрволл. Не следует недооценивать эту возможность - например, компьютер установленный как бэкап-сервер просто обязан иметь в запретах все виды соединений, кроме входящих соединений с данными бэкапа, а на компьютере, служащем www-сервером - можно запретить входящие и исходящие tcp-соединения, кроме http и ftp (при наличии необходимости внешнего администрирования сервера по ftp). Такой подход к конфигурированию системы может показаться несколько параноидальным, но зато дает возможность обеспечить "непотопляемость отдельных отсеков". Правда, это может дать неожиданные плоды в виде возникновения опасности осуществления сценария "уставший админ", когда администратор, желающий произвести администрирование удаленного сервера и не имея возможности сделать это с локальной консоли, зачастую просто отключает всю или большую часть правил файрволла на время администрирования (а иногда - и забывает потом их включить), что делает сеть уязвимой для атак снаружи, а также, при не совсем правильных настройках файрволла - дает ложное ощущение безопасности. Часто возникающая ошибка, при конфигурировании файрволла - запретить коннекты на практически все tcp-порты, но оставить открытыми остальные протоколы, которые могут быть использованы хакерами для взлома. Также следует внимательно относиться к вопросам надежности работы файрволла во всех возможных ситуациях. Файрволл может быть подвергнут взлому, как и любой другой компьютер. Поэтому проблема правильного конфигурирования и слежения за работой файрволла должна стоять на первом месте. Стоит поостеречься распространившейся в последнее время немного наивной веры в защищенность "аппаратных" роутеров. Как правило - все подобные устройства имеют широкий набор средств удаленного доступа, которые при малейших ошибках в настройках делают их настоящими находками для хакеров, благодаря наличию в них большого спектра специфических средств файрволла, роутинга, слежения за работой сети и туннелирования. При слишком "открытых" настройках, такое устройство станет, если не стартовой площадкой для взлома, то уж источником полезной для хакера информации - обязательно.

Одну из самых неприятных проблем в области безопасности компьютерных систем представляют из себя "баги" и "дыры" в программах и операционных системах. Они всплывают в самые неподходящие моменты и с самыми неприятными последствиями, зачастую сводя на нет старания администраторов в области безопасности. За время развития Unix-систем в них было найдено огромное количество багов и дыр, но до сих пор никто не сможет гарантировать, что не появится новых (более того - периодически обнаруживаются новые дыры, а благодаря Internet-у, подробные описания этих дыр (часто - с примерами программ) становятся известными за считанные часы). В общем случае, следует считать, что баги и дыры могут быть везде. Самые опасные из этих дыр - дыры в программах-серверах, предоставляющих сервис через Internet (ftp/www/mail-сервера и им подобные), так как их нельзя закрыть (иначе потеряется смысл самого подключения к Internet) и многие из них запускаются из под аккаунта с правами root. Дыры в ядрах систем не менее опасны, так как хотя и приводят в основном только к Denial of Service (DoS) или расширению средств "локального" взлома, тем не менее появления возможности использования подобных дыр и багов также следует опасаться (хакер может использовать, например, сценарий с подменой машин. Получив доступ к одному из компьютеров локальной сети или взломав роутер и изменяя таблицы роутинга, хакер может временно вывести из работспособного состояния выбранную машину и прописать в конфигурации взломанной машины адрес компьютера, подвергнутого DoS с целью получить доступ к сервисам, доступных только с этого компьютера). Большинство дыр в Unix-программах появляются по причине переполнения стека - пожалуй самой серьезной проблемы в области отладки программ. Программа, получающая какие-либо данные снаружи (а это делают практически все программы) и "забывающая" ограничивать или правильно контролировать размер вводимых данных может переполнить буфер данных процедуры, выделяемый обычно на стеке и вводимые данные заполняют области стека, в которых хранятся адреса возвратов из процедур, что делает возможным запуск на исполнение машинного кода, написанного хакером или передачи управления на неверные участки программы. Такая проблема связана с принципиальными ограничениями одностековой архитектуры, присущей большинству процессоров и компиляторов C, когда и данные и адреса возврата хранятся вперемешку в одном стековом сегменте. К сожалению, двухстековые системы (или c большим количеством стеков) не получили широкого распространения, а различного рода фиксы, делающие стековый сегмент недоступным для хранения исполняемого кода не дают полной гарантии отсутствия в программе подобных дыр (хакер не сможет исполнить свой собственный код, заполняя им стек, но легко сможет передать управление в нужный ему участок программы или код, лежащий в статическом сегменте данных). Конечно, использование данных дыр довольно сложно (требуется точно знать адреса возвратов, содержимое регистров и иметь полный код программы, а то и всей операционной системы, но в случае серьезно подготовленных атак хакер обычно имеет и то и другое). Такого рода дыры находили и находят практически во всех программах, поэтому максимум, что можно сделать - запускать минимум необходимых программ и полностью закрывать на файрволлах (или с помощью специальных tcp-враперов) соединения к программам, нужных только в пределах локальной сети или не прошедших достаточную проверку. В более выгодном положении оказываются программы и операционные системы со свободно распространяемыми исходными текстами - в них обычно "ковыряется" множество самых разных людей и баги обнаруживаются и фиксятся достаточно быстро. Разумеется, у свободно распространяемых исходных текстов есть и обратная сторона - среди "ковыряющихся" в них людей есть и хакеры, которые могут использовать обнаруженные баги в целях взлома. Однако, при необходимости обеспечить максимальный уровень безопасности, наличие исходных текстов и их полный анализ просто обязательны (к счастью, такие уровни безопасности требуются в очень редких случаях).

Особое место занимают "баги" и "дыры" намеренно помещенные в программы. Такие дыры могут появиться в результате использования непроверенных программ, целенаправленных действий хакеров и из-за каких-то особых мотивов авторов программ. Разумеется, использовать подобные программы не следует ни при каких обстоятельствах. Проблема заключается в том, что не всегда подобные "закладки" легко обнаружить. Для уменьшения вероятности занесения подобных программ следует придерживаться одного простого принципа. Никогда не используйте бинарные файлы, полученные из незаслуживающих доверия источников. Этот принцип включает в себя настоятельную рекомендацию запускать только скомпилированные в пределах своей организации бинарники (возможно, следует задуматься о выделении специального compiler-сервера, хорошо защищенного, чтобы не искать необходимые исходные тексты и патчи по большому количеству компьютеров и не бояться подмены на какой-нибудь из машин исходных текстов системных программ. Это также позволит убрать компилятор C/C++, исходные тексты и библиотеки с большинства Unix-машин для усложнения жизни хакерам). Периодически проверяйте контрольные суммы запускаемых файлов и скриптов. Причем делайте это программой, скомпилированой на другом компьютере и static-сборкой. В сетях с различными операционными системами появляется угроза осуществления довольно нетривиальных сценариев взлома, как например такой (этот сценарий, как все предыдущие и последующие (кроме тех, о которых сказано обратное) является вымышленым и совпадения с реально происшедшими случаями будут совершенно случайны): в сети из нескольких компьютеров под Windows 95 и Unix-сервера администратор для доступа к своему почтовому ящику использовал pop3-клиента (на сервере стоял POP-3 сервер, который проверял логин/пароль по /etc/passwd). Хакер, достаточно проинформированный о применяемых в данной организации программах, прислал по электронной почте документ формата Microsoft Word 95 с макросом-вирусом (троянским конем), который прочитал конфигурационные файлы pop3-клиента и переслал обнаруженный там пароль администратора хакеру.

Частным случаем намеренно сделаных дыр являются "отладочные" дыры. Средства отладки встраиваются во многие программы с целью облегчить их конфигурирование и отслеживание ошибочных ситуаций. Фактически, такие средства являются потенциальными дырами, при невнимательном отношении к процессу их использования. В качестве примера, приведу реальный случай, который немного коснулся и меня лично. Один из Internet-провайдеров нашего города использовал программу mpd-1.0 (Multi-link PPP по RFC-1717) под FreeBSD-2.2 для связи со своим провайдером, находящимся в другом городе. Администраторы с целью облегчить себе контроль за работой данной программы запускали ее в отладочном режиме со включенной tcp-консолью (при необходимости, можно было сделать telnet на определенный порт и управлять работой mpd), причем без всякого пароля. Закончилось это тем, что однажды утром содержимое дисков сразу нескольких компьютеров этого провайдера оказалось уничтоженным. К сожалению, администраторы не стали утруждать себя тщательными расследованием этого случая, поэтому точный способ взлома остался неизвестным, но как показали мои исследования исходных текстов - mpd в такой отладочной конфигурации позволял выполнять произвольные команды с правами рута без серьезных усилий со стороны хакера. Обязательно проверяйте и отлаживайте новое программное обеспечение на специально выделенных компьютерах с минимальным доступом извне и старайтесь сводить отладочные работы на системах, подключенных к Internet к минимуму.

Строя систему безопасности, не следует забывать о "физической" безопасности. При наличии физического доступа к компьютеру, практически любая защитная система может быть взломана за короткое время. Например, большинство Unix-систем можно загрузить в single-user mode, а при его запрете - загрузиться с другого физического носителя (дискета, лента, компакт-диск и т.д.) затем подмонтировать локальные диски компьютера и получить полный доступ к этому компьютеру (системы шифрования данных, хранимых на дисках, к сожалению, не слишком распространены и довольно дороги). Поэтому необходимо тщательно следить за охраной помещений, в которых установлены компьютеры, контролировать доступ в эти помещения, правильно подбирать и инструктировать персонал, имеющий доступ к компьютерам (классические ситуации с забытым логином на локальной консоли или обиженным сотрудником явно не способствуют повышению уровня безопасности), контролировать трассы прокладки локальных сетей и крайне внимательно относиться к любым незапланированным перезагрузкам/отключениям/потерям связи, особенно во время отсутствия персонала и тому подобное. Разумеется, уровень реализации всех этих мер напрямую зависит от необходимого уровня безопасности и стоимости защищяемой информации.

К сожалению, такое может случиться с каждым - в каталоге /usr/tmp лежит копия sh с битом SUID и владельцем root, все логи за предыдущую неделю куда-то испарились, несколько машин имеет на дисках только пару случайно уцелевших файлов, а представители конкурентов задают глупые вопросы, с трудом сдерживая улыбку. Если такое произошло - можете считать что вам даже повезло - вашу систему взломали те, кому хотелось просто показать свою "крутизну". В случае хорошо подготовленного и продуманного взлома "по заказу" вы рискуете просто ничего не узнать. Но акции подобного уровня встречаются нечасто и обычно о факте взлома узнают в тот же или на следующий рабочий день. Что же делать если система подверглась взлому? К своей искренней радости, автор данной странички с этим вопросом на практике никогда не встречался. Однако, я могу предложить несколько чисто умозрительных рекомендаций. Во-первых - не надо спешить. Если вам нужно найти истинного виновного (а его нужно найти в подавляющем большинстве случаев) и узнать в каком же месте ваша система безопасности дала сбой - самое плохое что вы сможете сделать, это взять последние бэкапы и начать все восстанавливать, уничтожая последние следы взлома и снова открывая все те же дыры. Оцените примерный срок начала взлома. Поищите заслуживающие доверия бэкапы, датированные более ранним числом. Внимательно исследуйте всю ту информацию, что имеется в наличии (логи, бэкапы, исходные тексты и т.д.) на предмет возможный подделок, жучков и дыр. Сценарий "почти идеального взлома" (до осуществления которого дело почти никогда не доходит) включает в себя занесение всевозможных жучков во все возможные места - исходные тексты программ, ядра операционной системы, статические и динамические библиотеки, SUID-ные программы и даже компиляторы и дистрибутивы операционной системы, записаные на дисках машин подвергнувшихся взлому - все это может содержать в себе код, добавленный хакером в своих личных интересах. Чем ближе взлом к "идеалу", тем меньше будет встречаться подобных вставок, так что всегда храните, как минимум - контрольные суммы для всех файлов на носителях, расположенных в обычное время как можно дальше от ваших компьютеров.

Дата добавления: 2015-06-04