Защита информации

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

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-враперов) соединения к программам, нужных только в пределах локальной сети или не прошедших достаточную проверку. В более выгодном положении оказываются программы и операционные системы со свободно распространяемыми исходными текстами - в них обычно "ковыряется" множество самых разных людей и баги обнаруживаются и фиксятся достаточно быстро. Разумеется, у свободно распространяемых исходных текстов есть и обратная сторона - среди "ковыряющихся" в них людей есть и хакеры, которые могут использовать обнаруженные баги в целях взлома. Однако, при необходимости обеспечить максимальный уровень безопасности, наличие исходных текстов и их полный анализ просто обязательны (к счастью, такие уровни безопасности требуются в очень редких случаях).