Информационная безопасность

         

ЭТО ДОЛЖЕН ЗНАТЬ КАЖДЫЙ или кому можно передавать свои секреты


С. В. Вихорев ОАО "Элвис-Плюс",
В. М. Трушин ООО "Дельный совет"

"Connect!Мир связи", №2-3, 2001

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

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

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

Каждая организация имеет свои секреты. Как правило такую информацию называют конфиденциальной (или коммерческой тайной - это близко, но не одно и то же). Собственник информации самостоятельно может отнести определенного рода информацию [1] к категории конфиденциальной[2], за исключением той информации, которая не может быть отнесена к этой категории по закону [3]или иному правовому акту[4].

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

В одних случаях этот обмен является обязательным и определен нормами законодательства, в других случаях - волеизъявлением собственника конфиденциальных сведений. Однако, в любом случае государство берет на себя правовую охрану интересов собственника в соблюдении конфиденциальности, в том числе и защиту от незаконного воздействия на него различных должностных лиц, при условии осуществления им легальной деятельности и выполнения определенных законодательством процедур обеспечения конфиденциальности. Так, к примеру, собственник информации принимает меры по защите ее конфиденциальности законными способами, а сама информация неизвестна третьим лицам и к ней нет свободного доступа на законном основании [5].В этом случае нарушение прав на соблюдение конфиденциальности влечет дисциплинарную, административную, гражданско-правовую и уголовную ответственность по законодательству Российской Федерации.


В каких же случаях законодательство не оставляет альтернативы и предписывает производить (добровольно или принудительно) обмен конфиденциальными сведениями?

Обмен конфиденциальной информацией по закону

Надо сказать, что в определенных случаях закон обязывает представлять информацию независимо от ее конфиденциальности. Но учитывая, что такие действия нарушают в какой-то степени наши конституционные права, то такие обстоятельства должны быть обязательно определены Законом[6], не подзаконными актами, а именно законом. Желания всех и вся получить информацию - понятны, но не всегда согласуются с законом. Порядок обязательного представления информации, отнесенной к конфиденциальной информации устанавливается законодательством. Итак, посмотрим кому и какую конфиденциальную информацию мы должны [7]передавать.

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

судебные органы[8]; органы прокуратуры[9]; органы, осуществляющие оперативно-розыскную деятельность[10]; органы следствия и дознания;

2. В случае предоставления в обязательном порядке информации органам и организациям, ответственным за формирование и использование государственных информационных ресурсов в соответствии с утвержденными Правительством Российской Федерации Перечнями[11]. К таким органам, например, можно отнести:

органы статистики органы (фонды) пенсионного страхования органы (фонды) медицинского страхования органы налоговой службы организации-депозитарии ценных бумаг органы Архивной Службы России и пр.

Конкретный перечень представляемой в обязательном порядке информации с адресами ее представления прилагается к уставу каждого юридического лица (положению о нем). А должностные лица регистрационных органов, виновные в том, что не обеспечили регистрируемых юридических лиц таким перечнем, привлекаются к дисциплинарной ответственности вплоть до снятия с должности[12].



3. По обращениям депутатов Совета Федерации и депутата Государственной Думы Федерального Собрания Российской Федерации по вопросам, связанным с их депутатской деятельностью безотлагательно предоставляется необходимая информация и документация независимо от степени их секретности в соответствии с федеральным законодательством о государственной тайне[13]. Однако, обратим Ваше внимание, что законодатель предусмотрел предоставление именно информации, составляющей государственную тайну (что подчеркнуто ссылкой на Федеральный Закон о "О государственной тайне", это справедливо, так как именно государство является собственником этой категории информации и вправе устанавливать правила доступа к ней[14]), а обязательность предоставления сведений конфиденциального характера - не определяется (это прерогатива собственника конфиденциальной информации[15]). Это дает право предоставлять такую информацию депутатам на общих основаниях и с соблюдением требований, определяемых собственником информации.

4. В случае обязательной внешней аудиторской проверки с целью установления достоверности бухгалтерской (финансовой) отчетности и соответствия совершенных финансовых и хозяйственных операций нормативным актам Российской Федерации, проводимой по поручению государственных органов, органов дознания, следователя, прокурора, суда и арбитражного суда в соответствии с процессуальным законодательством Российской Федерации[16].



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

Судебные органы:

Конституционный Суд Российской Федерации Верховный Суд Российской Федерации Высший Арбитражный Суд Российской Федерации верховные суды республик краевые и областные суды, суды городов федерального значения суды автономной области и автономных округов, районные суды военные и специализированные суды общей юрисдикции федеральные арбитражные суды округов арбитражные суды субъектов Российской Федерации мировые судьи субъектов РФ общей юрисдикции

Органы прокуратуры:

Генеральная прокуратура Российской Федерации прокуратуры субъектов Российской Федерации военные и другие специализированные прокуратуры прокуратуры городов и районов территориальные, военные и иные специализированные прокуратуры

Органы, осуществляющие оперативно-розыскную деятельность:

Министерства внутренних дел Российской Федерации ФСБ России Федеральной налоговой полиции России Федеральной службы государственной охраны Пограничной службы Российской Федерации Таможенного комитета Российской Федерации Службы внешней разведки Российской Федерации Министерства юстиции Российской Федерации

Органы следствия и дознания:

органы ФСБ России органы МВД России органы прокуратуры России

<


Обмен конфиденциальной информацией по волеизъявлению собственника

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

1. Добровольная передача конфиденциальной информации в состав государственных информационных ресурсов по правилам, установленным для включения документов в соответствующие информационные системы[17].

2. Добровольная передача конфиденциальной информации на основе условий договора[18] (мены, дарения, купли-продажи, совместной деятельности и пр.) или в порядке универсального правопреемства[19] (по завещанию, в связи с реорганизацией юридического лица и пр.).

3. Передача конфиденциальной информации учредителям, участникам хозяйственных товариществ и обществ, контрагентам, партнерам, субподрядчикам, арендаторам, сотрудникам для выполнения служебных обязанностей по трудовому договору или контракту или зарубежному партнеру с использованием средства международного информационного обмена[20].

4. Передача конфиденциальной информации при использовании услуг оператора связи (телефонных, телеграфных, телетайпных, факсимильных, телематических, и др.) по транспортированию информационных потоков, по сетям электрической и почтовой связи.

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

Какую информацию обязаны предоставлять

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


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

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

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

Необходимо помнить, что закрепленное в законе право истребовать какие-либо материалы не означает безусловность их предоставления. Уголовно-процессуальное законодательство не предусматривает обязанность безусловно предоставить истребуемые материалы, а соответственно и нет ответственности за отказ в предоставлении истребуемых материалов, за исключением отдельных случаев. В принципе, законодательство не исключает необходимости соблюдения специальной процедуры (порядка) при предоставлении истребуемой информации. Федеральным законом определено, что собственник документов, массива документов, информационных систем или уполномоченные им лица устанавливают порядок предоставления пользователю информации с указанием места, времени, ответственных должностных лиц, а также необходимых процедур и обеспечивают условия доступа пользователей к информации[23].

Вообще-то говоря, установлено, что и для органов прокуратуры, внутренних дел, налоговой полиции, ФСБ России конфиденциальность определенной информации (банковская и коммерческая тайна) не является препятствием для получения сведений и документов о финансово-экономической деятельности, вкладах и операциях по счетам физических и юридических лиц, причастных к совершению тяжких преступлений и преступлений, совершенных преступными группами[24]. Основанием для предоставления банковскими и коммерческими структурами таких документов является мотивированное требование (запрос) прокурора, следователя, руководителя органа дознания по возбужденному уголовному делу[25]. Органы милиции, при наличии данных о правонарушениях в финансовой, хозяйственной, предпринимательской и торговой деятельности могут изымать необходимые документы на материальные ценности, денежные средства, кредитные и финансовые операции[26]



Органы ФСБ России имеют право безвозмездно получать от государственных органов, предприятий, учреждений и организаций независимо от форм собственности информацию, необходимую для выполнения возложенных на них обязанностей, за исключением случаев, когда федеральными законами установлен специальный порядок получения информации[27].

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

Налоговая служба Российской Федерации имеет право производить проверки денежных документов, регистров бухгалтерского учета, отчетов, планов, смет, деклараций и иных документов, связанных с исчислением и уплатой налогов и других платежей в бюджет[30]. Кроме того она может контролировать своевременность предоставления плательщиками бухгалтерских отчетов, балансов, налоговых расчетов, отчетов и других документов, связанных с исчислением и уплатой платежей в бюджет, а также проверять достоверность этих документов в части правильности определения прибыли, дохода, иных объектов обложения и исчисления налогов и платежей в бюджет[31]. При необходимости эти документы могут быть и изъяты на основании мотивированного постановления должностного лица налоговой инспекции. Предоставление же сведений, составляющих коммерческую тайну по запросам налоговой полиции и налоговой службы производится только по возбужденному уголовному делу[32] или по материалам проверки, проводимой в порядке обязательности рассмотрения заявлений и сообщений о преступлении[33].

По требованию суда, прокуратуры, органов следствия, арбитражного суда, нотариус может дать необходимую справку о совершенных нотариальных действиях[34], содержащих конфиденциальную информацию доверителя.



Особое место в процессе обмена информацией вообще и конфиденциальной в частности занимают взаимоотношения со средствами массовой информации. Законодательно закреплено, что поиск, получение, производство и распространение массовой информации не подлежит ограничениям, за исключением случаев, предусмотренных законодательством о средствах массовой информации[35]. Как один из таких случаев, законодатель называет недопустимость использования средств массовой информации для разглашения сведений, составляющих государственную или иную специально охраняемую законом тайну[36]. Поэтому, несмотря на то, что любая редакция имеет право в устной и письменной форме запрашивать информацию о деятельности государственных органов и организаций, общественных объединений и их должностных лиц, а руководители этих органов обязаны предоставлять такую информацию[37], они вправе и отказать редакции в ее получении, если запрашиваемая информация содержит какую-либо тайну[38],. В этом случае журналист может получить доступ только к документам и материалам без фрагментов, содержащих такие сведения[39].
Знание этих документов может пригодиться

Гражданский Кодекс Российской Федерации, часть I, 1994 г. Гражданский Кодекс Российской Федерации, часть II, 1995 г. Уголовный Кодекс Российской Федерации, 1996 г., Уголовно-Процессуальный Кодекс РСФСР

Федеральные Конституционные законы:

"О судебной системе Российской Федерации", № 1-ФКЗ, 1996 г. "О конституционном суде РФ", №1-ФКЗ, 1994 г.

Федеральные законы:

"О банках и банковской деятельности", № 17-ФЗ, 1996 г. "Об информации, информатизации и защите информации", № 24-ФЗ, 95г. "Об участии в международном информационном обмене", № 85-ФЗ, 1995 "О связи", № 15-ФЗ, 1995 г. "О прокуратуре Российской Федерации", №168-ФЗ, 1995 г. "Об органах федеральной службы безопасности РФ", № 40-ФЗ, 1995 г. "Об оперативно-розыскной деятельности", № 144-ФЗ, 1995 г. "Об органах федеральной службы безопасности РФ", № 40-ФЗ, 1995 г. "О статусе депутата СФ и статусе депутата ГД ФС РФ", № 3-ФЗ, 1994 г. "О федеральных органах налоговой полиции", № 5238-1, 1993 г. "О милиции", № 1026-1, 1991 г. "О средствах массовой информации", № 2224-1, 1991 г. Основы законодательства РФ о нотариате, № 4460-1, 1993 г.,

Указы Президента Российской Федерации:

"О государственной налоговой службе", № 340, 1991 г. "Об аудиторской деятельности в РФ", № 2263, 1993 г. "Об осуществлении комплексных мер по своевременному и полному внесению в бюджет налогов и других обязательных платежей", 1994 г. "О неотложных мерах по защите населения от бандитизма и иных проявлений организованной преступности", № 1226, 1994 г. "Об утверждении перечня сведений конфиденциального характера", № 188, 1997 г . Постановление Правительства РФ 1991 г. № 35 "О перечне сведений, которые не могут составлять коммерческую тайну" Постановление ФКЦБ, 1997 г., № 36 " Об утверждении Положения о депозитарной деятельности в Российской Федерации"

Письма Госналогслужбы России:

1997 г., № ИЛ-6-24/344 1994 г. № ВГ-6-18-322 1994 г., № ВГ-6-18/322, 1994 г., № ВГ-6-18/404 Комиссия по аудиторской деятельности при Президенте РФ, 1996 г., протокол № 6, "Правила (стандарт) аудиторской деятельности" Комментарии к УК РФ, Москва, 1996, изд. "ИНФРА М-НОРМА"

<


Обязанности по соблюдению конфиденциальности

Должны ли государственные органы соблюдать конфиденциальность чужих сведений? Ответ на этот вопрос безусловный - не только должны, но и обязаны. Все органы и организации государственной власти, наделенные контролирующими правами и получающие конфиденциальную информацию (в обязательном порядке или по желанию собственника) от сторонних организаций обязаны, в соответствии с действующим законодательством, выполнять требования по ее защите[40] и несут ответственность[41] (в том числе и материальную[42]) за несоблюдение режима конфиденциальности, установленного собственником информации. Собственнику же информации законом дано право контролировать выполнение этих требований и запрещать или приостанавливать обработку информации в случае их невыполнения[43]. Кроме общих норм, аналогичные положения имеются в законодательных актах Российской Федерации, определяющих права и компетенцию различных органов власти. В этих случаях собственнику конфиденциальной информации не требуется дополнительных договоренностей по соблюдению конфиденциальности - они определены законом.

Так, Конституционный Суд Российской Федерации (как впрочем и любой другой суд) назначает закрытое заседание в случаях, когда это необходимо для сохранения охраняемой законом тайны, обеспечения безопасности граждан, защиты общественной нравственности.[44]

Органы прокуратуры действуют гласно в той мере, в какой это не противоречит требованиям законодательства Российской Федерации об охране прав и свобод граждан, а также законодательства Российской Федерации о государственной и иной специально охраняемой законом тайне[45].

Органам, осуществляющим оперативно-розыскную деятельность на основании судебного решения [46](факт заведения дела оперативного учета не является основанием для действий по ограничению прав и свобод, нарушению законных интересов гражданина[47]) запрещается разглашать сведения, которые затрагивают неприкосновенность частной жизни, личную и семейную тайну, честь и доброе имя граждан которые стали известными в процессе проведения оперативно-розыскных мероприятий, без согласия граждан, за исключением случаев, предусмотренных федеральными законами[48].



Федеральные налоговые органы обязаны сохранять государственную, служебную, коммерческую тайну, тайну сведений о вкладах физических лиц и другую информацию, полученную ими при исполнении служебных обязанностей[49]. Полученная ими в ходе служебной деятельности информация используется исключительно в служебных целях и разглашению не подлежит[50]. Руководство налоговых органов особо подчеркивает, что сами налоговые органы не являются собственниками запрашиваемой информации, не могут распоряжаться ею по своему усмотрению и обязаны обеспечить сохранность и конфиденциальность сведений налогоплательщиков[51]. Конфиденциальная информация без согласия собственника этой информации может быть передана только в судебные и правоохранительные органы и в строго установленном порядке - по официальным мотивированным письменным запросам в связи с возбужденным уголовным делом[52].

Соблюдение режима конфиденциальности является законными интересами собственника информации, а в этом случае органы милиции не имеют права разглашать ставшие им известными такие сведения.[53]

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

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

Только суд, в особых случаях, может освободить нотариуса от обязанности сохранения тайны[56].

Все российские операторы связи обязаны обеспечивать соблюдение тайны связи[57]. Вместе с тем, при осуществлении международного информационного обмена, государство гарантирует защиту любой конфиденциальной информации, принадлежащей физическим и юридическим лицам, только в том случае, если они имеют лицензию на такую работу и используют сертифицированные средства международного информационного обмена[58] и средства их защиты[59].



Письменная информация аудитора является конфиденциальным документом. Сведения, содержащиеся в нем, не подлежат разглашению аудиторской фирмой, ее сотрудниками либо аудитором, работающим самостоятельно, за исключением случаев, прямо предусмотренных федеральными законами Российской Федерации. Собственник информации вправе по своему усмотрению распоряжаться сведениями, полученными в ходе аудиторской проверки[60].

Организации осуществляющие депозитарную деятельность (депозитарии) должны обеспечить целостность переданных им данных, в том числе в случае чрезвычайных ситуаций, разграничение прав доступа и обеспечения конфиденциальности информации, не допускающие возможности ее использования в собственных интересах и третьими лицами в ущерб интересам клиентов[61]. Должна быть обеспечена конфиденциальность не только информации о счетах депо клиентов и производимых по ним операциям, он и любых других сведений о клиентах[62].
потому что у Вас документов нет..."

Почтальон Печкин

Действующие лица:

Мистер Х - добропорядочный, законопослушный владелец собственной фирмы.

Господин N - честный и добросовестный налоговый инспектор

Мистер Х озабочен сохранением своих секретов. У себя на фирме он составил "Перечень сведений, составляющих конфиденциальную информацию" по которому персональные данные о сотрудниках и их имущественном положении отнесены к категории "конфиденциально" (ст. 11 Закона "Об информации, информатизации и защите информации"), установил наивысший режим защиты своей информации (ст. 21 Закона "Об информации..."), написал "Инструкцию о порядке работы с конфиденциальными сведениями" и ознакомил с ней всех сотрудников (ст. 139 ГК РФ), закупил и установил сертифицированные средства защиты информации для своей информационной сети (ст. 19 Закона "Об информации..."), пригласил специалистов из Органа по аттестации объектов информатизации (Система сертификации средств защиты информации РОСС RU.0001.01БИ00) и после проверки получил Аттестат соответствия своей корпоративной сети требованиям класса защищенности 1А (РД Гостехкомиссии России).

Господин N все свои усилия направляет на добросовестное исполнение своих служебных обязанностей по скорейшему получению и обработке налоговых деклараций. С этой целью он пригласил к себе состоятельного Мистера Х.

Место действия: рабочий кабинет налогового инспектора.

Время действия: конец финансового года.

Мистер Х: Здравствуйте господин N. Я принес Вам свою декларацию о доходах.

Господин N: Очень хорошо! Вы успели вовремя, давайте ее скорее сюда!

М-р Х: Нет, сначала я должен Вас предупредить, что это - конфиденциальная информация и Вы должны обеспечить уровень по ее защите, который я установил, как этого требует ст. 22.2 Закона "Об информации, информатизации и защите информации". Вы с этим согласны?

Г-н N: Конечно, мы умеем хранить чужие секреты! Наше руководство это прекрасно понимает и считает, что мы обязаны обеспечить сохранность и конфиденциальность сведений налогоплательщиков, о чем оно написало в своем Письме. (Демонстрирует Письмо Госналогслужбы России, от 5.05.97 г., № ИЛ-6-24/344 "О порядке предоставления сведений ограниченного распространения по запросам сторонних организаций"). Мы дадим Вам расписку, что будем соблюдать конфиденциальность.

М-р Х: Очень хорошо! Но я должен сказать, что очень тщательно храню свои секреты и поэтому установил степень защищенности при обработке этой информации на средствах вычислительной техники не ниже 1А по документам Гостехкомиссии России. Вы можете мне дать гарантии, что и Вас будут выполняться эти требования?

Г-н N: (Недоуменно) Но ведь это очень дорогая защита! Зачем Вам такая? Наши системы и без того надежно защищены!

М-р Х: Да, но я хотел бы иметь определенные гарантии.

Г-н N: Мое слово - Вам порука.

М-р Х: К сожалению, при всем моем глубоком уважении лично к Вам, я хотел бы видеть что-то более весомое, например, Аттестат соответствия требуемому уровню защиты. У Вас есть такой Аттестат?

Г-н N: Есть, но наши средства аттестованы только по классу 1В.

М-р Х: Мне этого мало и поэтому я позволю себе воспользоваться правом, предоставленным мне ст. 21.5 Закона "Об информации..." и запрещаю обработку своей налоговой декларации на Ваших средствах автоматизации до приведения их в соответствие с моими требованиями.

Г-н N: ???

М-р Х: Поймите меня правильно. Я законопослушный гражданин и готов предоставить Вам сведения из налоговой декларации, но я имею право их защитить так, как считаю нужным и не передавать эти сведения, если не уверен в их сохранности. Это моя жизнь. Поэтому, господин N, пока Ваша система не будет иметь класс защищенности 1А, я Вам ничего не дам! Но Письмо с готовностью передать Вам декларацию в любой момент, как только мне будет дана гарантия их сохранности, я Вам оставляю! Всего хорошего!

Г-н N: ???

...
<


Ответственность за разглашение конфиденциальных сведений

Конфиденциальная информация (служебная и коммерческая тайна) защищается всеми способами, предусматривающимися законодательством Российской Федерации[63]. За правонарушения при работе с информацией органы государственной власти, организации и их должностные лица несут ответственность в соответствии с законодательством Российской Федерации и субъектов Российской Федерации[64]. Руководители и служащие органов государственной власти и организаций, виновные в нарушении режима защиты информации, несут ответственность в соответствии с уголовным, гражданским законодательством и законодательством об административных правонарушениях[65].

К примеру, за противоправные действия сотрудники налоговой полиции несут установленную законом ответственность, а вред, причиненный ими подлежит возмещению в порядке, предусмотренном уголовным и гражданским законодательством[66]. Аналогичная норма предусматривается и для сотрудников милиции[67]. При нарушении органом, проводящим оперативно-розыскные мероприятия, прав и законных интересов физических и юридических лиц, вышестоящий орган, прокурор либо судья обязаны принять меры по восстановлению этих прав и возмещению причиненного вреда[68]. Любые предприятия, учреждения и организации, а также общественные объединения и граждане вправе требовать от органов ФСБ возмещения морального и материального ущерба, причиненного действиями должностных лиц этих органов при исполнении служебных обязанностей[69]. Нотариус, умышленно разгласивший ставшие известными ему конфиденциальные сведения обязан возместить причиненный ущерб по решению суда[70]. Работники связи, могут привлекаться к ответственности в порядке, установленном законодательством Российской Федерации, за нарушение тайны связи[71]. В случае разглашения конфиденциальной информации организациями-депозитариями, клиенты, права которых нарушены, вправе потребовать возмещения причиненных убытков в порядке, определенном законодательством[72].



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

Если какой-либо субъект в силу своих полномочий (налоговый инспектор, следователь, уполномоченный представитель органа власти) или по иным основаниям (служебные функциональные обязанности, договорные отношения) знает конфиденциальные сведения, но не имея согласия собственника, допустил их разглашение или использование с целью получения вознаграждения, из мести, для ухудшения положения конкурента или улучшения собственной репутации, в результате чего собственник понес крупный ущерб, то эти действия также расцениваются законом как преступление[74].

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

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

Лица, незаконными методами получившие конфиденциальную информацию, обязаны возместить причиненные убытки. Это справедливо и для работников, разгласивших такую информацию вопреки трудовому договору (контракту), контрагентов, сделавших это вопреки гражданско-правовому договору[77].

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

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



Нарушение тайны переписки имеет место в случае, когда корреспонденция становится достоянием других лиц без согласия адресата[79]. Поэтому, если кто-либо, находясь в офисе организации увидел на столе конфиденциальный документ (а это, как правило, всегда входящее или исходящее письмо - то есть корреспонденция) и умышленно прочитал его без согласия собственника (адресата), то уже это является составом преступления, которое считается оконченным с момента ознакомления с содержанием документа. Если же такую "нетактичность" допустило должностное лицо (например, работник правоохранительного органа, прибывшего с проверкой, телефонный монтер и пр.), то это может рассматриваться как отягчающее обстоятельство[80].

Использование лицом, выполняющим управленческие функции в коммерческой или иной организации, своих полномочий вопреки интересам этой организации и в целях извлечения выгод и преимуществ для себя или других лиц, либо нанесения вреда другим лицам, если это деяние повлекло причинение существенного вреда правам и законным интересам граждан или организаций является злоупотреблением полномочиями[81].

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

Возмещение убытков

Уже не раз отмечалось, что незаконное разглашение или использование конфиденциальных сведений нарушает право собственника и приносит убытки, которые подлежат возмещению[82].

Что же такое убытки применительно к рассматриваемой нами теме? Убытки - это средства, которые:

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



Особо отметим, что в состав реального ущерба входят не только фактические расходы, понесенные собственником в результате разглашения или использования нарушителем конфиденциальной информации, но и расходы, которые он должен будет произвести для восстановления нарушенного права. Эти расходы должны быть подтверждены обоснованными расчетами, доказательствами которых могут быть смета затрат на устранение недостатков, работ, услуг, а также договор, определяющий размер ответственности за нарушение обстоятельств[83]. В состав услуг по устранению нарушенных прав должны быть также включены и услуги по судебному взысканию нанесенных убытков или, проще говоря, адвокатский гонорар[84].

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

уменьшение объема производства или реализации продукции; простои и нарушения финансирования; необходимость изменения технологии; необходимость восстановления информации в случае ее утере или повреждении; необходимость организации новых каналов обмена информации и замены средств защиты информации вместо скомпрометированных; снижение качества предоставляемых услуг и многое другое.

К расходам относятся все фактические расходы, понесенные на день предъявления претензии.

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

Это не верно. В первом случае надо помнить, что действия работников должника по исполнению его обязательств считаются действиями должника (читай организации - виновной в разглашении сведений) При этом должник отвечает за эти действия[86].


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

Во втором же случае, ответчиком признается непосредственно Российская Федерация[87] в лице соответствующего финансового органа. При этом, предъявление иска непосредственно к государственному органу не может служить основанием к отказу в принятии иска или возвращению его без рассмотрения. Если иск судом удовлетворен, то взыскание ущерба производится за счет средств соответствующего бюджета, а при их отсутствии - за счет иного имущества, составляющего соответствующую казну[88].

Заключение

Уважаемые представители государственных органов управления и специальных служб! Обращаем Ваше внимание на то, что авторы статьи не ставили себе целью создать краткий справочник для недобросовестных граждан. Однако, авторы считают, что существующая законодательная база в Российской Федерации позволяет законным образом защитить права собственника конфиденциальной информации не переступая за рамки закона. Закон есть закон и он должен быть исполняем всеми без исключения. Ну а если уж что не так, то не обессудьте...

1. Указ Президента Российской Федерации 1997 г. № 188 "Об утверждении перечня сведений конфиденциального характера"

2. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст.10.5

3. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст.10.3

4. Постановление Правительства Российской Федерации 1991 г. № 35 "О перечне сведений, которые не могут составлять коммерческую тайну"

5. Гражданский Кодекс Российской Федерации, 1994 г., ст. 139

6. Гражданский Кодекс Российской Федерации, часть I, 1994, ст. 2

7. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 8.2

8. Федеральный Конституционный Закон "О судебной системе Российской Федерации", № 1-ФКЗ, 1996, ст. 4

9. Федеральный Закон "О внесении изменений в Закон Российской Федерации "О прокуратуре Российской Федерации", №168-ФЗ, 1995, ст. 11



10. Федеральный Закон "Об оперативно-розыскной деятельности", № 144-ФЗ, 1995, ст. 13

11. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 8.1

12. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 8.3

13. Федеральный Закон " О статусе депутата Совета Федерации и статусе депутата Государственной Думы Федерального Собрания Российской Федерации", № 3-ФЗ, 1994, ст. 16

14. Закон Российской Федерации "О государственной тайне", № 5485-1, 1993 г., ст. ст. 16, 17

15. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 22.1

16. Указ Президента Российской Федерации, 1993 г., № 2263, "Об аудиторской деятельности в РФ"

17. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 8.4

18. Гражданский Кодекс Российской Федерации, часть I, 1994, ст. ст. 420, 421

19. Гражданский Кодекс Российской Федерации, часть I,1994, ст. 129

20. Федеральный Закон "Об участии в международном информационном обмене", № 85-ФЗ, 1995, ст. 9.1

21. Федеральный Закон "О внесении изменений в Закон Российской Федерации "О прокуратуре Российской Федерации", №168-ФЗ, 1995, ст. 6.2

22. Уголовно-Процессуальный Кодекс РСФСР, ст. 109

23. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 22.1

24. Указ Президента Российской Федерации, 1994, № 1226 "О неотложных мерах по защите населения от бандитизма и иных проявлений организованной преступности"

25. Письмо Генеральной прокуратуры Российской Федерации от 26.09.94 г. № 7/3-1-1103-94

26. Федеральный закон "О милиции", 1991 г., № 1026-1, ст.11.25

27. Федеральный Закон "Об органах федеральной службы безопасности РФ", № 40-ФЗ, 1995, ст.13

28. Федеральный Закон "О федеральных органах налоговой полиции", 1993, № 5238-1, ст. 10



29. Указ Президента Российской Федерации, 1994 г., № ... "Об осуществлении комплексных мер по своевременному и полному внесению в бюджет налогов и других обязательных платежей"

30. Указ Президента Российской Федерации 1991 г., № 340 "О государственной налоговой службе", ст. 16

31. Указ Президента Российской Федерации 1991 г., № 340 "О государственной налоговой службе", ст. 18

32. Письмо Государственной налоговой службы Российской Федерации от 30.08.94 г. № ВГ-6-18-322

33. Уголовно-Процессуальный Кодекс РСФСР, ст. 109

34. Основы законодательства Российской Федерации о нотариате, 1993 г., № 4460-1, ст. 5

35. Закон Российской Федерации "О средствах массовой информации", № 2224-1, 1991 г., ст. 1

36. Закон Российской Федерации "О средствах массовой информации", № 2224-1, 1991 г., ст. 4

37. Закон Российской Федерации "О средствах массовой информации", № 2224-1, 1991 г., ст. 39

38. Закон Российской Федерации "О средствах массовой информации", № 2224-1, 1991 г., ст. 40

39. Закон Российской Федерации "О средствах массовой информации", № 2224-1, 1991 г., ст. 47

40. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 22.2

41. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 23.3

42. Гражданский Кодекс Российской Федерации, часть I, 1994 г., ст. 16, часть II, 1995 г., ст. ст. 1069, 1070

43. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 21.5

44. Федеральный Конституционный Закон "О конституционном суде РФ", №1-ФКЗ, 1994, ст. 55

45. Федеральный Закон "О внесении изменений в Закон Российской Федерации "О прокуратуре Российской Федерации", №168-ФЗ, 1995, ст. 4.2

46. Федеральный Закон "Об оперативно-розыскной деятельности", № 144-ФЗ, 1995, ст. 8

47. Федеральный Закон "Об оперативно-розыскной деятельности", № 144-ФЗ, 1995, ст. 10



48. Федеральный Закон "Об оперативно-розыскной деятельности", № 144-ФЗ, 1995, ст. 5

49. Федеральный Закон "О федеральных органах налоговой полиции", 1993, № 5238-1, ст. 10

50. Федеральный Закон "О федеральных органах налоговой полиции", 1993, № 5238-1, ст. 11

51. Письмо Госналогслужбы России, от 5.0597 г., № ИЛ-6-24/344 " О порядке предоставления сведений ограниченного распространения по запросам сторонних организаций"

52. Письма Госналогслужбы России и ФСНП России, 1994 г., № ВГ-6-18/322, 1994 г., № ВГ-6-18/404

53. Федеральный закон "О милиции", 1991 г., № 1026-1, ст.5

54. Гражданский Кодекс Российской Федерации, часть I, 1994 г., ст. 184.3

55. Основы законодательства Российской Федерации о нотариате, 1993 г., № 4460-1, ст. 5

56. Основы законодательства Российской Федерации о нотариате, 1993 г., № 4460-1, ст. 16

57. Федеральный Закон "О связи", 1995 г., № 15-ФЗ, ст. 32

58. Федеральный Закон "Об участии в международном информационном обмене", № 85-ФЗ, 1995, ст. 9.2

59. Федеральный Закон "Об участии в международном информационном обмене", № 85-ФЗ, 1995, ст. 17.2

60. Комиссия по аудиторской деятельности при Президенте Российской Федерации, 1996 г., протокол № 6, "Правила (стандарт) аудиторской деятельности"

61. Постановление ФКЦБ, 1997 г., № 36 " Об утверждении Положения о депозитарной деятельности в Российской Федерации", ст. 3.6

62. Постановление ФКЦБ, 1997 г., № 36 " Об утверждении Положения о депозитарной деятельности в Российской Федерации", ст. 10.1

63. Гражданский Кодекс Российской Федерации, часть I, 1994 г., ст. 139.2

64. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 23.3

65. Федеральный Закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст. 24.3

66. Федеральный Закон "О федеральных органах налоговой полиции", 1993, № 5238-1, ст. 20

67.


Федеральный закон "О милиции", 1991 г., № 1026-1, ст.40

68. Федеральный Закон "Об оперативно-розыскной деятельности", № 144-ФЗ, 1995, ст. 5

69. Федеральный Закон " Об органах федеральной службы безопасности РФ", № 40-ФЗ, 1995, ст.6

70. Основы законодательства Российской Федерации о нотариате, 1993 г., № 4460-1, ст. 17

71. Федеральный Закон "О связи", 1995 г., № 15-ФЗ, ст. 32

72. Постановление ФКЦБ, 1997 г., № 36 " Об утверждении Положения о депозитарной деятельности в Российской Федерации", ст. 10.2

73. Уголовный Кодекс Российской Федерации, 1996 г., ст. 183.1

74. Уголовный Кодекс Российской Федерации, 1997 г., ст. 138.1

75. Комментарии к УК РФ, Москва, 1996, изд. "ИНФРА М-НОРМА", ст.138, п.1

76. Уголовный Кодекс Российской Федерации, 1997 г., ст. 138.2

77. Уголовный Кодекс Российской Федерации, 1997 г., ст. 201

78. Гражданский Кодекс Российской Федерации, часть I, 1994 г., ст. 15

79. Постановление Пленума Верховного Суда Российской Федерации и Высшего Арбитражного Суда Российской Федерации от 01.07.96 г., № 6/8 "О некоторых вопросах, связанных с применением части I ГК РФ"

80. М.Ю. Радченко, "Арбитражные споры. Справочник практикующего юриста", М., 1998 г., "Новый юрист"

81. М.Ю. Радченко, "Арбитражные споры. Справочник практикующего юриста", М., 1998 г., "Новый юрист"

82. Гражданский Кодекс Российской Федерации, часть I, 1994 г., ст. 403, часть II, 1995 г. ст. ст. 1068, 1069

83. Гражданский Кодекс Российской Федерации, часть I, 1994 г., ст. 16

84. Постановление Пленума Верховного Суда Российской Федерации и Высшего Арбитражного Суда Российской Федерации от 01.07.96 г., № 6/8 "О некоторых вопросах, связанных с применением части I ГК РФ", ст. 12


Как определить источники угроз?


Сергей Вихорев, Роман Кобцев

Открытые системы No.7-8/2002

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

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

Сегодня комплексная система безопасности информации это не просто комплекс средств, а комплекс мер, направленных на предотвращение потери информации.

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

С другой стороны, не мешало бы поговорить о том, как изучать опасности. Можно, например, с криком "Ура" броситься на все грабли сразу, и затем каждую новую "шишку на лбу" "заклеивать" новыми сканерами, межсетевыми экранами и VPN. В результате, конечно, можно получить надежную, проверенную защиту, с которой ваш бизнес может спать спокойно, если, конечно, после всего этого у вас еще останутся средства на продолжение экономической деятельности.
Можно поучиться на чужих ошибках. Но, во-первых, учиться на чужих ошибках у нашего народа вообще не принято, а во-вторых, кто же про свои ошибки расскажет? Остается сначала представить все возможные варианты, а затем отобрать наиболее применимые к конкретному случаю. Здесь опять-таки альтернатива: либо использовать накопленный банк данных уже случившихся вариантов проявлений угроз (и не быть до конца уверенным, что все варианты уже проверены), либо попытаться создать методологический инструмент формирования поля возможных проявлений угроз, основанный на изучении всех влияющих факторов и позволяющий рассмотреть даже самые маловероятные варианты. Например, в США только после трагических событий 11 сентября 2001года в гражданских самолетах стали ставить бронированные двери в кабины пилотов, в то время как в СССР, такую угрозу предвидели еще на заре становления гражданской авиации.

Однако не будем лукавить и утверждать, что в природе нет методик проведения анализа рисков. Например, в нашей компании консалтинг в области информационной безопасности является серьезным направлением, и нами был самым тщательным образом изучен опыт коллег в данном вопросе. Но все имеющиеся на сегодняшний день методики (к сожалению, преимущественно иностранные) позволяют получить только лишь качественную оценку. Это, например, такие методики как Guide to BS 7799 risk assessment and risk management. - DISC, PD 3002, 1998.,Guide to BS 7799 auditing.о - DISC, PD 3004, 1998 (на основе стандартов BS 7799 и ISO/IEC 17799-00). В данных методиках оценка безопасности информации проводится по 10 ключевым контрольным точкам, которые представляют собой либо обязательные требования (требования действующего законодательства), либо считаются основными структурными элементами информационной безопасности (к примеру, обучение правилам безопасности). Эти контрольные точки применимы ко всем организациям. К ним относятся:

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



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

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

источник угрозы - фактор (уязвимость) - угроза (действие) - последствия (атака).

Сегодня угрозу безопасности информации отождествляют обычно либо с характером (видом, способом) дестабилизирующего воздействия на информацию, либо с последствиями (результатами) такого воздействия. Однако, практика свидетельствует, что о том, что такого рода сложные термины могут иметь большое количество трактовок и возможен иной подход к определению угрозы безопасности информации, базирующийся на понятии "угроза". "Угроза" -- намерение нанести физический, материальный или иной вред общественным или личным интересам, возможная опасность (С. И. Ожегов, Словарь русского языка), иначе говоря, понятие угроза жестко связано с юридической категорией "ущерб" -- фактические расходы, понесенные субъектом в результате нарушения его прав (например, разглашения или использования нарушителем конфиденциальной информации), утраты или повреждения имущества, а также расходы, которые он должен будет произвести для восстановления нарушенного права и стоимости поврежденного или утраченного имущества (ГК ФР, часть I, ст.15).


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



Рис. 1.

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

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

при обеспечении конфиденциальности информации:

хищение (копирование) информации и средств ее обработки утрата (неумышленная потеря, утечка) информации

при обеспечении целостности информации:

модификация (искажение) информации отрицание подлинности информации навязывание ложной информации

при обеспечении доступности информации:

блокирование информации уничтожение информации и средств ее обработки

Все источники угроз можно разделить на классы, обусловленные типом носителя, а классы на группы по местоположению (Рис. 2).



Уязвимости также можно разделить на классы по принадлежности к источнику уязвимостей, а классы на группы и подгруппы по проявлениям (рис. 3).



Методы реализации можно разделить на группы по способам реализации (рис. 4). При этом необходимо учитывать, что само понятие "метод", применимо только при рассмотрении реализации угроз антропогенными источниками. Для техногенных и стихийных источников, это понятие трансформируется в понятие "предпосылка".





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

Сам подход к анализу и оценке состояния безопасности информации основывается на вычислении весовых коэффициентов опасности для источников угроз и уязвимостей, сравнения этих коэффициентов с заранее заданным критерием и последовательном сокращении (исключении) полного перечня возможных источников угроз и уязвимостей до минимально актуального для конкретного объекта.



Исходными данными для проведения оценки и анализа (рис. 5) служат результаты анкетирования субъектов отношений, направленные на уяснение направленности их деятельности, предполагаемых приоритетов целей безопасности, задач, решаемых АС и условий расположения и эксплуатации объекта. Благодаря такому подходу возможно:

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

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

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



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

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

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

Сергей Вихорев (), Роман Кобцев, сотрудники ОАО "Элвис Плюс" (Москва)


Пример реализации защищенного беспроводного соединения


Рассмотрим организацию защищенного соединения для наиболее типичной, в силу своей гибкости, конфигурации: имеется локальная сеть с выделенным сервером под управлением ОС FreeBSD (ветка 5.X) и всем необходимым для беспроводных клиентских подключений оборудованием — точка доступа, коммутатор и т. д. В качестве клиентов в данном случае подразумеваем портативные компьютеры, снабженные беспроводными сетевыми адаптерами и работающие под ОС Windows XP.

Клиентам выделяется динамический IP-адрес — наиболее удобное и гибкое решение для крупных сетей, значительно упрощающее общее администрирование. Для ОС FreeBSD существуют весьма качественные реализации DHCP-серверов, выполняющие данную задачу, и мы остановимся на общепризнанном фаворите — DHCP-сервере от ICS (версия 3.0.14).

Являясь наиболее типичной, с одной стороны, с другой — данная конфигурация подразумевает не самый легконастраиваемый способ организации защищенных соединений. Это объясняется тем, что изначально сервер «не знает» IP-адрес клиента, а для организации шифрованного туннеля необходимо знание как адреса сервера (точки «А»), так и адреса клиента (точки «В»). Поэтому полностью шифрованный туннель отпадает за громоздкостью реализации, а мы остановимся на не менее надежном методе — транспортном. (Туннель же хорош в случае заблаговременно известных IP-адресов — например, если необходимо связать серверы центрального офиса и филиалов, имеющие статические IP-адреса, выделенные им интернет-провайдерами.)

Для обеспечения безопасности на транспортном уровне можно применить три подхода: использование статических политик шифрования, секретного ключа (pre-shared key) и аутентификации с открытым ключом — сертификатов X.509. Первые два случая значительно проигрывают третьему с точки зрения той же безопасности, поэтому мы остановимся на самом надежном методе, аутентификации с открытым ключом, благо как FreeBSD, так и Windows XP имеют достаточно мощные средства поддержки X.509.

Теоретически, при соблюдении должных мер безопасности, сертификат X.509 нельзя подделать (и, как следствие, подключить к серверу нежелательного клиента).
Для этого необходимо строго ограничить доступ к серверу, на котором хранится корневой сертификат, выбрать надежный пароль и т. д. — все действия администратора в этом случае хрестоматийны и не нуждаются в перечислении. Кроме того, невозможно получить сертификат X.509 и с машины-клиента, так как при экспорте сертификата закрытый ключ не экспортируется. А это именно тот компонент, который и необходимо уберечь от кражи.
Для успешной работы на начальном этапе нам необходимо пересобрать ядро операционной системы FreeBSD с поддержкой IPSec. Сделать это достаточно просто, необходимо добавить в файл конфигурации ядра строки:
OPTIONS IPSEC OPTIONS IPSEC_ESP OPTIONS IPSEC_DEBUG
Затем сконфигурировать, скомпилировать и инсталлировать новое ядро с последующей перезагрузкой. После данных манипуляций появляется поддержка IPSec.
Необходимо также несколько изменить конфигурацию межсетевого экрана, так как взаимодействие сервера с клиентом потребует доступности некоторых специфических портов, но об этом ниже.
Предполагается, что на сервере с FreeBSD уже установлен пакет OpenSSL, который необходим как для генерации ключей и сертификатов, так и для интегрирования с программой racoon, которая отвечает за обмен ключами сервера с клиентом. Таких программ, обслуживающих протокол ISAKMP, две: racoon, который мы будем использовать, и isakmpd, «демон».
На стадии подготовки ключей и сертификатов следует крайне внимательно отнестись к процедуре генерации с помощью OpenSSL, так как в подавляющем большинстве случаев «все сделано правильно, но ничего не работает» — именно на этом этапе ошибки приводят к невозможности установить связь.
Сначала необходимо сгенерировать закрытый ключ для корневого сертификата сервера. 1024-битный ключ, зашифрованный при помощи алгоритма TRIPLE-DES, запишем в файл server.key:
openssl genrsa -des3 -out server.key 1024
На этом этапе необходимо со всей ответственностью отнестись к паролю, который программа OpenSSL затребует в конце генерации закрытого ключа.


Во-первых, пароль должен быть, по возможности, не «подбираемым влет», что обеспечит надежность всех выдаваемых впоследствии сертификатов, во-вторых, его ни в коем случае нельзя забыть, так как придется генерировать заново все сертификаты. Восстановить или взломать пароль нельзя, поэтому стоит положиться исключительно на собственную память.
По сгенерированному закрытому ключу server.key создадим корневой сертификат server.crt на следующих условиях: срок действия сертификата 5 лет (1825 дней).
openssl req -new -x509 -days 1825 -key server.key -out server.crt
В процессе создания сертификата OpenSSL запросит следующие сведения:
пароль закрытого ключа
двухсимвольный код страны (US, RU, UA и т. д.)
название штата или области
название населенного пункта
название компании
название подразделения компании
имя (например имя администратора, создающего сертификат)
По окончании генерирования корневого сертификата на руках у администратора окажется необходимый инструментарий для создания сертификатов клиента и сервера, которые они будут «предъявлять» друг другу при установке защищенного соединения. Создадим ключ и сертификат для сервера:
openssl genrsa -out server-side.key 1024
Процедура создания ключа сервера схожа с созданием закрытого ключа для корневого сертификата. Далее необходимо сгенерировать запрос на сертификат server-side.csr (отвечая по ходу процедуры на стандартные вопросы):
openssl req -new -key server-side.key -out server-side.csr
В заключение генерируем сертификат со сроком действия 1 год для сервера server-side.crt, обозначив его сигнатурой закрытого ключа server.key для корневого сертификата server.crt:
openssl x509 -req -days 365 -in server-side.csr -CA server.crt -CAkey server.key -out server-side.crt
Кажущаяся громоздкость описываемых процедур на самом деле логична и хорошо документирована, тем более, что данный путь позволит обеспечить реальную безопасность беспроводного соединения (в отличие от мнимой стойкости WEP-шифрования).
Процедура создания сертификатов для клиента совершенно идентична:


openssl genrsa -out client-side.key 1024 openssl req -new -key client-side.key -out client-side.csr openssl x509 -req -days 365 -in client-side.csr -CA server.crt -CAkey server.key -out client-side.crt
Единственный дополнительный шаг на этом этапе — экспорт клиентского закрытого ключа client-side.key и сертификата client-side.crt в файл формата pl2 (client-side.pl2) для удобства импорта сертификата в ОС Windows XP.
После генерации ключей и сертификатов переместим их в каталог, например /usr/local/etc/secret.
Если на сервере установлен межсетевой экран (а он должен быть установлен), необходимо разрешить UDP-подключения на 500 порту — из файла /etc/services узнаем, что это порт isakmp:
ipfw allow udp from 192.168.1.0/24 to me dst-port 500 via fxp0 ipfw allow udp from me to any dst-port 500 via fxp0
Здесь 192.168.1.0/24 — локальная сеть организации, частью которой становится подключаемый клиент, me — IP-адрес сервера, fxp0 — сетевой интерфейс, обслуживающий локальную сеть.
Подготовительную стадию можно считать оконченной, теперь необходимо настроить ПО сервера и клиента. Как уже говорилось, в качестве программы управления ключами выбрана racoon (ныне часть пакета ipsec-tools). Программу можно установить либо в виде готового скомпилированного пакета, либо, что предпочтительнее, из портов (/usr/ports/security/racoon).
После установки требуется переименовать конфигурационный файл /usr/local/etc/racoon.conf.dist в /usr/local/etc/racoon.conf и внести в него соответствующие правки.
Закомментируем строку
path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;
так как в этом файле находятся статические секретные ключи, от которых мы сразу отказались, и вместо нее впишем свою с путем к файлам ключей и сертификатов:
path certificate "/usr/local/etc/secret" ;
Также установим избыточный уровень отладки:
log debug2;
В остальном же файл racoon.conf снабжен исчерпывающими комментариями и настраивается без особых трудностей. Стоит лишь обратить особое внимание на секции anonymous — именно они определяют поведение сервера при подключении клиентов с динамическими IP-адресами.


Запуск racoon производится со следующими параметрами:
/usr/local/sbin/racoon -f /usr/local/etc/racoon.conf -l /var/log/racoon.log
На этом настройка сервера завершена, пора приступить к «поднятию» IPSec на клиентском ноутбуке. Кстати, настройка защищенного соединения в операционных системах Windows XP/2000 выполняется весьма громоздко и сопровождается многочисленными программными помощниками.
Для начала нужно убедиться, что запущена служба IPSec Services. Затем создаем новую управляющую консоль: из командной строки дадим команду mmc. В новой консоли добавляем следующие оснастки:
Certificates (на локальном компьютере);
IP Security Policies (на локальном компьютере);
IP Security Monitor.
Для добавления сертификата и ключа необходимы некоторые файлы с сервера — client-side.pl2 и server.crt. Импортируем server.crt в контейнер Trusted Root Certification Authorities и client-side.pl2 в контейнер Personal оснастки Certificates.
В оснастке IP Security Policies создаем новую политику безопасности и называем ее, например FreeBSD. Здесь также придется пройти ряд мастеров настройки, но основной момент: важно не забыть деактивировать список фильтров по умолчанию и активировать вновь созданный — иначе опять «ничего не будет работать». В качестве точки источника и точки приемника определяем собственный IP-адрес ноутбука и фиксированный IP-адрес сервера соответственно. Также необходимо разрешить любой протокол на этом маршруте («Any»).
В заключение настройки клиента запускаем политику FreeBSD («Assign»). Если все настроено верно, это тотчас отразится в оснастке IP Security Monitor (см. скриншот). Самое время протестировать соединение — в командной строке запускаем элементарный ping. В случае правильной организации соединения появится сообщение Negotiating security и данные пинга сервера. Тому есть подтверждение и со стороны сервера, в логе racoon.log наблюдаются заветные строки:
ISAKMP-SA established 192.168.1.1[500]-192.168.1.253[500] spi:d8f9676430defba8:29ef37b543b950ea
Как видим, IPSec успешно функционирует в транспортном режиме. Конечно, было бы гораздо спокойнее и безопаснее построить полностью криптованный туннель «сервер — ноутбук», но это решение достаточно нетривиальное. Существуют и другие подходы, например организация виртуальных частных сетей с протоколами PPTP и L2TP, но специалисты по безопасности однозначно признают преимущество IPSec перед такими решениями.
В статье использована документация с сайта

Защищаем беспроводное соединение


Евгений Патий
#6/2005

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

Проблемами безопасности производители беспроводного оборудования Wi-Fi занялись давно и всерьез, ведь изначально стандарты 802.11x имели значительные недостатки в плане защищенности соединений. Если в редакции «g» уже есть подвижки в сторону улучшения стойкости ко взлому, то аппаратура с поддержкой более раннего (и более распространенного) стандарта «b» имеет нарекания в плане целостности передаваемой информации.

О какой защите инвестиций можно говорить в данном случае? Предположим, компания развернула беспроводную сеть стандарта 802.11b два года назад. А это означает, что были закуплены соответствующие точки доступа и клиентские адаптеры, причем как первые, так и вторые стоили недешево (на тот момент). Проходит немного времени, и оказывается, что беспроводная сеть передачи данных открыта для взлома, невзирая на попытки администраторов хоть как-то обезопасить сеть стандартными методами (в числе которых, напомним, 64- и 128-битное WEP-шифрование трафика, запрет широковещательной передачи идентификатора SSID, разграничение доступа, основанное на MAC-аутентификации).

Но этих методов сегодня уже недостаточно. WEP-шифрование базируется на алгоритме RC4, который ненадежен и легко поддается взлому. Да и с собственно шифрованием все далеко не однозначно — и в случае 64-, и 128-битного ключа присутствует некоторая условность. Дело в том, что эффективная длина ключа в первом составляет 40 бит, во втором — 104 бит. Недостающие до заявленных служебные 24 бит используются для дешифрования информации на принимающей стороне.

Таким образом, цифры «64» и «128» хороши лишь для маркетинговых уловок производителей и операторов, но не для реальной безопасности сети. Кроме того не будем забывать, что ключи статические — значит, их нужно периодически менять.
Если в случае беспроводной сети, состоящей из точки доступа и нескольких клиентов, это не представляет особой проблемы, то для корпоративных сетей с огромным количеством одновременно подключенных беспроводных пользователей такое решение явно не подходит. Более того, для обеспечения достаточного уровня безопасности при использовании WEP-шифрования требуется смена 64-битного ключа раз в полчаса, а 128-битного — раз в час (в реальности ключи прописывают один раз и затем их не меняют).

Запрещение трансляции SSID не способствует увеличению безопасности беспроводной сети. Такой шаг способен привести лишь к появлению потенциальных проблем у подключаемых клиентов, так как конфигурирование сети станет гораздо менее гибким. Отключение широковещательной передачи SSID создает лишь иллюзию надежности: значение этого идентификатора все равно можно подслушать — оно находится во фреймах Probe Response.

Если имеется возможность ведения списков доступа по MAC-адресам, полностью полагаться на эту меру безопасности не стоит — взломать преграду можно за считанные минуты. Суть взлома такова: при помощи специальной утилиты прослушивается радиообмен точки доступа на канале, по которому передается информация к клиенту и обратно, и в полученном трафике выделяется список «своих» клиентов. Остается лишь программно подменить аппаратный адрес своего беспроводного адаптера на один из списка валидных адресов (в подавляющем большинстве случаев это можно сделать даже стандартными средствами драйвера), — и «чужой» адаптер стал «своим».

Как видим, ситуация плачевная. Остается лишь один путь: использовать беспроводную связь только в виде «носителя», совершенно не отягощаясь заботами по настройке собственных средств безопасности. Если абстрагироваться от WEP-шифрования, списков MAC-доступа и широковещательной передачи SSID, беспроводную сеть можно сделать надежной, и даже очень надежной. Для этого требуется применить сторонние средства, наиболее популярное из которых — IPSec.

В глобальном смысле IPSec — это «каркас», часть продуктов, требующих следующей функциональности: организация защищенного соединения между точкой «А» и точкой «В».


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

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

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

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

IPSec — наиболее популярное, и пожалуй, наилучшее решение для создания виртуальных частных сетей, но имеются определенные ограничения. В случае применения IPSec в транспортном режиме не исключается возможность атак со стороны — это вызвано некоторыми ограничениями протокола ISAKMP, но сложность проведения такой атаки не сравнится со взломом беспроводной сети, защищенной средствами «из коробки».


Беспроводная "аптечка скорой помощи"


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

NetStumbler. Бесплатная утилита, позволяющая найти место доступа к беспроводной сети. NetStumbler сканирует все каналы Wi-Fi и составляет список обнаруженных шлюзов и адаптеров беспроводного доступа. Boingo Wireless Software. Бесплатная утилита, изначально предназначенная для соединения с провайдером интернета по беспроводному каналу. Может также использоваться для хранения сетевых профилей и ключей шифрования. Те, кто постоянно пользуется несколькими защищенными сетями, может сэкономить время, так как избавится от необходимости каждый раз менять ключи WEP или WPA в Wi-Fi-адаптере. JiWire AvantGo. Каталог точек доступа, который можно загрузить и пользоваться им, как справочником. Smart ID WFD-1 Wi-Fi Detector. Портативный прибор для измерения интенсивности сигнала в диапазоне Wi-Fi. Облегчает поиск "мертвых зон" в беспроводной сети; пользоваться этим устройством гораздо проще, чем тяжелым ноутбуком, у которого к тому же садятся аккумуляторы. Cantenna Wireless Network Anenna. Выглядит как металлический цилиндр, действует как остро направленная антенна. Существенно расширяет возможности подключения к беспроводной сети. В комплект входят винты для подключения Cantenna к беспроводному шлюзу или к сетевому адаптеру, кабель длиной 45 см и маленький треножник для установки на столе.



"Черные дыры"


Согласно тестам Wi-Fi Alliance, беспроводной адаптер персонального компьютера способен устанавливать соединение со шлюзом на расстоянии 40–60 футов (12–18 м) в домашних условиях и 60–80 футов (18–24 м) в офисе. Это меньше, чем радиус в 150 футов (45,7 м), теоретически предсказанный некотрыми производителями устройств Wi-Fi.

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

Что делать в этой ситуации? Найти более удачное место для шлюза или купить еще несколько антенн. Однако в любом случае, прежде чем действовать, необходимо измерить силу сигнала Wi-Fi в "мертвой зоне" — том месте, где вы хотите использовать компьютер, но не можете этого сделать. Например, может оказаться, что на одном конце большого стола сигнала практически нет, зато на другом конце прием отличный. Только не вздумайте поворачивать стол… может быть, лучше передвинуть стул?

Для измерения силы сигнала можно воспользоваться простейшими программными средствами, поставляемыми в комплекте со многими беспроводными адаптерами и некоторыми ноутбуками. Однако для серьезной работы по устранению проблем этого будет маловато. С помощью уже упоминавшейся здесь бесплатной утилиты NetStumbler можно временно превратить ноутбук или КПК c адаптером Wi-Fi в удобный анализатор беспроводных сигналов, сканирующий частоты, используемые Wi-Fi-устройствами. Программа составляет список всех обнаруженных поблизости устройств с беспроводным подключением, указывая силу сигнала каждого из них.

Впрочем, NetStumbler — несколько беспокойная программа. Она поддерживается не всеми моделями адаптеров Wi-Fi, и ее не так-то просто освоить. Альтернативой может послужить устройство наподобие Smart ID WFS-1 WiFi Detector.
Подобно NetStumbler, WFS-1 фиксирует сигналы в диапазоне 2,4 ГГц и измеряет их интенсивность. WFS- 1 представляет собой портативный датчик размером с колоду карт, с двумя светодиодами, по которым можно определить силу сигнала после нажатия на кнопку. Устройство является направленным, поэтому, в отличие от NetStumbler, распознает источники сигнала, не относящиеся к стандарту Wi-Fi, такие как микроволновые печи и радиотелефоны.

Обнаружив основные источники помех, можно поискать более удачное место для шлюза — разумеется, если удастся таковое найти. В идеале, оно должно находиться как можно ближе к "мертвой зоне". Особое внимание стоит обратить на пространственную ориентацию шлюза. Даже так называемые всенаправленные антенны на самом деле имеют "преобладающие" направления, в результате чего шлюз, повешенный на стену, может посылать сигнал главным образом в пол или потолок. При каждом перемещении шлюза или антенны необходимо перепроверять интенсивность сигнала в той точке, где он должен приниматься.

>Если перемещение или изменение пространственной ориентации шлюза и антенн не решает проблему, можно попробовать сменить антенну. К некоторым шлюзам, таким как Apple AirPort Extreme Base Station, предлагается две антенны. Некоторые компании производят антенны высокого качества, совместимые с любыми шлюзами.


Как мы с Windows искали Wi-Fi...


Понятие zero configuration — "нулевая конфигурация" — подразумевает максимально простую настройку. Но в случае со службой WindowsXP Wireless Zero Configuration (WZC) это зачастую не так.

Проблема вот в чем: время от времени при включении Windows XP не соединяется с сетью. Наиболее распространенным симптомом является недоступная (серая) кнопка Connect (Соединить) в диалоговом окне сетевых подключений. Ситуация усугубляется еще тем, что адаптер как ни в чем не бывало мигает лампочками, а в окне Device Manager (Менеджер устройств) отображается так, как будто установлен совершенно правильно.

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

На дискуссионных форумах высказывается мнение, что эта ошибка иногда — но не всегда — может быть исправлена после установки Microsoft Wireless Update Rollup Package. Этот пакет вышел еще в октябре 2003 г., и устанавливался через функцию Windows Update. Для того чтобы проверить, есть ли он на вашем компьютере, выберите команду Start?Windows Update (Пуск?Обновление Windows), выберите на левой панели режим View Installation History и поищите запись Update for Microsoft Windows XP (KB826942).

Если патч установлен, а проблема подключения осталась, попробуйте остановить и снова запустить службу Wireless Zero Configuration, отчего Windows XP переустановит драйверы сетевого адаптера.

Для того чтобы это сделать, нужно открыть консоль Services (Службы). Для этого щелкните правой кнопкой мыши на пиктограмме My Computer (Мой компьютер), расположенной на рабочем столе, и выберите команду Manage (Управление). На левой панели консоли управления откройте список Services and Applications (Службы и приложения) и выберите из него элемент Services (Службы). Просмотрите список на правой панели и дважды щелкните на элементе Wireless Zero Configuration.

Если служба не была отключена раньше, в диалоговом окне будет указан статус службы Started (Запущена), а кнопка Stop (Стоп) будет активной. Щелкните на ней, немножко подождите, пока станет активной кнопка Start (Пуск), и щелкните на ней. Если соединение восстановится, — рано радоваться: скорее всего, проблема будет повторяться, и вам придется каждый раз снова выполнять эту операцию.

Если после перезапуска службы все остается по-старому, — похоже, пора обновлять прошивку адаптера Wi-Fi ноутбука или драйверы Wi-Fi, чтобы их версия поддерживалась Windows XP. В самом худшем случае, когда WZC чаще сбоит, чем работает, отключите эту службу и используйте для настройки соединения с локальной сетью программное обеспечение, поставляемое с адаптером.



Как закрыть беспроводную "черную дыру"


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

Мост Ethernet: соединение шлюзов Ethernet-кабелем

Беспроводной мост (WDS): между шлюзами устанавливается "радиомост" с передачей радиосигналов

Внешняя антенна: к шлюзу подключается направленная антенна, котрая и доставляет сигнал в "мертвую зону"



Когда необходима защищенная сеть


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

Некоторые пользователи интернета рассматривают проникновение в незащищенные беспроводные сети как вид спорта (известный под названием wardriving — "боевое вождение"). На некоторых веб-сайтах публикуются карты открытых сетей и данные, предоставленные "игроками", проехавшими мимо на автомобиле с ноутбуком, оборудованным GPS-устройством и программным обеспечением вроде NetStumbler или Kismet

Насколько рискованно работать в незащищенной сети? Как когда. Если никогда не читать почту и не делать электронных платежей, то можно отделаться сравнительно дешево. Максимально возможная неприятность связана с использованием паролей шлюза, предлагаемых по умолчанию. Эти пароли широко известны (есть в документации и опубликованы в интернете), так что любой тинейджер, желающий самоутвердиться, может, попав в зону действия сети, зарегистрироваться в ней и ввести новые пароли, которых вы не знаете. Со всеми вытекающими последствиями… Например, если злоумышленник удалит доступ к DSL, вы потеряете доступ к интернету, а если включит WEP-шифрование, — то и к собственной локальной сети.

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

Что же делать владельцу Wi-Fi? В первую очередь, активировать систему безопасности. Самое меньшее, — изменить стандартные настройки, такие как SSID и пароли, а также защитить паролем общедоступные диски.



Перекрытие сетей


Одна и та же сеть, доблестно проработав целый день, назавтра начинает барахлить… проблема может быть в том, что ваши хорошие соседи используют плохую технологию Wi-Fi.

Любое оборудование, работающее в диапазоне 2,4ГГц (в том числе и устройства Wi-Fi), сконструировано так, чтобы создавать минимальные помехи для других устройств этого же диапазона, таких как радиотелефоны. Устройствам Wi-Fi приходится отличать полезные сигналы от радиомусора. Однако одни модели справляются с этой задачей лучше, а другие — хуже.

Например, компания Broadcom, производитель микросхем для беспроводной связи, опубликовала в прошлом году результаты тестов, согласно которым микросхемы ее конкурента, компании Atheros, создают помехи для других беспроводных устройств. Broadcom поставляет микросхемы стандарта 802.11g для шлюзов Apple, Belkin, Buffalo, Linksys и Motorola, а также для ноутбуков Dell, EMashines и Fujitsu. Технология Atheros используется в шлюзах и других устройствах D-Link и NetGear.

Причиной проблемы, на которую ссылается Broadcom, является режим Turbo, доступный для шлюзов Atheros, в котором удваивается скорость обмена данными между устройствами Atheros. Разумеется, Atheros отрицает наличие помех от ее устройств. Что же касается независимых инстанций, таких как Wi-Fi Alliance, то там данная проблема в настоящее время изучается.

Поэтому, если в соседней фирме установили оборудование на базе Atheros, и включили режим Turbo, остается только одно — решить вопрос по-хорошему, по-соседски. И наоборот, если вы используете оборудование Atheros, возможно, однажды кто-то постучится в вашу дверь…

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



Повышение безопасности Wi-Fi


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

Первая линия обороны, получившая название WEP (Wired Equivalent Privacy, защищенность кабельной сети), не прошла "проверку на прочность". Однако средства WEP-шифрования встраиваются во все устройства Wi-Fi, и лучше уж пользоваться ими, нежели вообще ничем. Тем не менее, алгоритмы шифрования WEP несовершенны. Их достаточно, чтобы остановить случайного прохожего, но настоящий злоумышленник, имея широко доступные программные средства, взломает WEP-защиту минут за 15, невзирая на загрузку сети.

Для ограничения доступа в сеть можно воспользоваться фильтрацией адресов MAC (Media Access Control, управление доступом к среде) на шлюзе. Эта служба ограничивает адреса с помощью уникального кода, встроенного в каждый адаптер Wi-Fi и Ethernet.

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

Вместо того чтобы полагаться исключительно на MAC-фильтрацию, лучше использовать ее в сочетании с шифрованием WPA (Wi-Fi Protecting Access, защищенный доступ к Wi-Fi), пришедшем на смену WEP. В WPA были исправлены основные недочеты WEP, и эта технология встроена во все устройства с сертификатом Wi-Fi, выпускаемые начиная с сентября 2003 г. Что же касается старого оборудования стандарта 802.11g, то для многих таких устройств (к сожалению, не для всех), выпущенных в период с 1999 по 2002 гг., доступны обновления встроенного ПО. Более подробные сведения об этом должны быть на сайте производителя.

Прежде чем использовать WPA в Windows XP, иногда требуется загрузить патч — в нем добавлена поддержка операционной системой WPA и еще нескольких новых технологий, необходимых для корректной работы WPA.


Этот патч поддержки WPA можно установить и на ноутбуки, поддерживающие технологию Intel Centrino. Однако, несмотря на выпуск Intel обновленных драйверов, еще не все производители интегрировали эти драйверы в версию Windows XP, устанавливаемую на их ПК. Поэтому более подробную информацию о настройке WPA на данной модели ноутбука следует искать на сайте его производителя. В этом году должен появиться новый адаптер Intel Centrino стандарта 802.11g с полной поддержкой WPA, не требующий загрузки драйверов и обновлений.

WPA предусматривает защиту сети с помощью парольной фразы (длинного пароля — от 8 до 63 символов). Парольная фраза вводится на шлюзе, на странице настройки WPA. После этого тот, кто хочет подключиться к сети, должен указать такую же фразу в параметрах своего адаптера Wi-Fi. Без парольной фразы соединение не происходит.

Для того чтобы ввести парольную фразу WPA в профиль Wireless Network Connections, дважды щелкните на пиктограмме My Network Places (Мои сетевые соединения), а затем — на надписи View Network Connections (Просмотр сетевых соединений), расположенной на левой панели. Щелкните правой кнопкой мыши на сетевом соединении Wi-Fi, выберите команду Properties (Свойства) и дважды щелкните на пиктограмме вашей сети на панели Preferred Networks (Желательные сети), расположенной в нижней части диалогового окна Properties (Свойства). Перейдите на вкладку Association (Соединение) и выберите из списка Network Authentication (Аутентификация сети) команду WPA-PSK. (При подключении к сети предприятия можно выбрать простой режим WPA.) Из списка Data Encryption (Шифрование данных) выберите команду TKIP, дважды введите парольную фразу WPA и щелкните на кнопке OK.

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


Расширение границ сети


Есть несколько способов расширить диапазон беспроводной сети за пределы досягаемости одного шлюза. Дешевле и надежнее всего будет установить несколько шлюзов Wi-Fi. Точки доступа состоят всего лишь из радиоприемника Wi-Fi, поэтому их проще настраивать, и с ними меньше проблем, однако они часто стоят дороже, чем шлюз.

Если есть возможность проложить провода в стенах или под полом, можно объединить несколько шлюзов локальной сетью Ethernet, создав своеобразный укрупненный узел связи. Можно также воспользоваться беспроводной системой распространения (Wireless Distribution System, WDS), позволяющей создать беспроводную "цепочку" из нескольких шлюзов Wi-Fi.

WDS еще называют беспроводным мостом, так как трафик каждого шлюза передается (по "мосту") другим шлюзам. Однако поскольку WDS не является стандартом, то эта технология поддерживается не всеми моделями шлюзов, и по-разному работает на устройствах различных производителей. Для использования WDS лучше всего приобрести все шлюзы одной фирмы. В частности, хорошими примерами WDS-совместимых шлюзов, полностью совместимых с Windows, являются Apple AirPort Extreme Base Station и Buffalo WBR-G54.

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

Обычно один из шлюзов беспроводной сети ("интеллектуальный") обеспечивает мостовую связь между обычной, кабельной сетью и беспроводными клиентами, играет роль межсетевого экрана, а иногда назначает IP-адреса компьютерам, подключенным к сети по протоколу DHCP (Dynamic Host Configuration Protocol, протокол динамической конфигурации хоста). Этот шлюз играет роль барьера и связующего звена между внутренней сетью и сетью Интернет.

Остальные ("немые") шлюзы выполняют единственную функцию: обеспечивают беспроводной доступ. (Активация сервера DHCP на нескольких шлюзах — верный путь к проблемам.
DHCP- сервер должен работать только на одном шлюзе, подключенном непосредственно к интернету.)

Еще один способ расширить диапазон беспроводной сети заключается в использовании адаптеров HomePlug, позволяющего передавать данные по кабелям электропроводки. Таким образом можно соединить два достаточно удаленных шлюза, если только они находятся в одном здании. Для этого сетевой кабель одного шлюза подключают адаптеру HomePlug, который включается в ближайшую электрическую розетку. В другой комнате монтируется аналогичная система, состоящая из второго адаптера HomePlug и шлюза. Если вам удастся приобрести адаптер HomePlug-Wi-Fi, то необходимость во втором шлюзе отпадет.

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


Техника безопасности в беспроводном мире


Елена Полонская,

Сети Wi-Fi — это, конечно, здорово, но не всегда надежно. Вот несколько соображений о том, зачем и как можно повысить безопасность беспроводной сети.

Типичная ситуация: устанавливаем беспроводную сеть, включаем… и через пару недель у беспроводного шлюза начинаются странные "припадки": через каких-то пять минут он разрывает соединение. Для того чтобы диагностировать проблему, устанавливаем, например, утилиту NetStumbler, и оно с радостью показывает нам аж восемь других шлюзов, использующих тот же Wi-Fi-канал, что и наш. Пытаемся сменить канал… результат нулевой. Наконец, активируем службу Wireless Zero Configuration, входящую в состав Windows XP, (оказывается, беспроводной адаптер ее по умолчанию отключил) и — ура, заработало!

В других ситуациях многие пользователи Windows XP и эксперты по сетям Wi-Fi советуют, наоборот, полностью отключить Wireless Zero Configuration — такова сумасшедшая, непредсказуемая природа беспроводных сетей: то, что срабатывает в одних случаях, бесполезно в других.

Скоростной беспроводной доступ к компьютерам и другим устройствам нельзя игнорировать, особенно в тех местностях, где другие средства связи мало развиты. Однако при этом необходимо учитывать и сопутствующие ему проблемы.

Кроме конфликтов с программным обеспечением Windows, оборудование для беспроводных сетей страдает и от других неполадок, в число которых входят "мертвые зоны", отсутствие соединения из-за ошибок Windows, суженный диапазон Wi-Fi, помехи и нарушение безопасности.



Архитектура Linux


По данным обзора Summer 2004 Evans Data Linux Developers Survey, 93% разработчиков Linux сталкивались не более чем с двумя случаями компро-метации компьютера с ОС Linux. 87% встретился только один подобный инцидент, а в практике 78% не было ситуаций, когда компьютер под управле-нием Linux сколько-нибудь серьезно пострадал от действий злоумышленников. В тех редких случаях, когда им удалось добиться успеха, основной причиной были ненадлежащим образом сконфигурированные настройки безопасности.

Однако для данной статьи важнее тот приведенный в обзоре факт, что 92% респондентов никогда не сталкивались со случаями заражения ОС Linux вирусами, троянскими и другими вредоносными программами.

То обстоятельство, что вирусы, троянские и другие вредоносные программы редко могут (если вообще могут) заразить Linux-системы, частично можно объяснить следующими причинами:

Linux имеет долгую историю использования тщательно проработанной многопользовательской архитектуры. По своей архитектуре Linux является в основном модульной системой. Функционирование Linux не зависит от RPC-механизма, а сервисы обычно по умолчанию настроены не использовать RPC-механизм. Серверы Linux идеально подходят для удаленного администрирования.

При дальнейшем чтении следует помнить о вариациях в используемых по умолчанию конфигурациях различных дистрибутивов ОС Linux, поэтому то, что верно для Red Hat Linux, может оказаться неправильным для Debian, и еще больше отличий может быть в SuSE. По большей части в том, что касается конфигураций по умолчанию, все основные дистрибутивы Linux следуют одним и тем же разумным правилам.



Архитектура Windows


Вирусы, троянские кони и другие вредоносные программы поражают настольные компьютеры с Windows по целому ряду причин, свойственных Windows и чуждых Linux:

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



Архитектура Windows и архитектура Linux


Возможно, причиной мифа о том, что Windows намного чаще подвергается атакам, чем Linux, являются вирусы, троянские кони и сетевые черви, ориентированные на электронную почту и web-навигатор. Несомненно, на настольных компьютерах инсталляций Windows больше, чем инсталляций Linux. Весьма возможно, что программное обеспечение Windows для настольных компьютеров чаще подвергается атакам, потому что Windows преобладает на настольных компьютерах. Но остается без ответа один важный вопрос. Действительно ли атаки на Windows столь успешны исключительно из-за их многочисленности, или же этот факт объясняется наличием проектных недоработок и неудачных проектных решений Windows?

Значительная часть (если не большинство) вирусов, троянских коней, сетевых червей и других вредоносных программ, заражающих компьютеры с Windows, используют для этого уязвимости в Microsoft Outlook и Internet Explorer. Поэтому можно поставить вопрос по-другому, включив в рассмотрение тот же тип программного обеспечения для Linux (наиболее часто используемые web-навигаторы, программы электронной почты, текстовые процессоры и т. д.): имеет ли Linux столько же уязвимостей в системе безопасности, сколько их имеет Windows?



Дисбаланс приложений


В дебатах о превосходстве одной операционной системы над другой часто упускается из виду, что уязвимости в системе защиты почти всегда коренятся в приложениях. Данное обстоятельство создает определенные трудности при сравнении Windows и Linux, потому что эти две системы находятся в неравном положении с точки зрения переносимости и доступности приложений.

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

С другой стороны, web-сервер Apache чаще всего ассоциируется с Linux, UNIX или другими UNIX-системами, но Apache функционирует и под управлением Windows. Поэтому, сравнивая общую безопасность Windows и Linux, можно ли считать, что брешь в Apache — это дефект только Linux? Или она негативно сказывается и на Linux, и на Windows?

Еще больше усложняет проблему то, что известно несколько случаев, когда брешь в Apache почти (или даже совсем) не опасна для Linux, но является серьезной уязвимостью в Windows. Обратная ситуация встречается крайне редко, если вообще встречается. Следует ли понижать оценку общей безопасности Windows потому, что эта система более подвержена неблагоприятному воздействию, чем Linux, при использовании программного обеспечения, которое обычно ассоциируется с Linux?

Вопрос о том, учтен ли какой-либо из этих факторов при сравнении общей безопасности Windows и Linux, ни в коем случае нельзя оставлять без внимания.



Исключение из правила


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

Объясняется это просто. Если для использования бреши необходимо попасть в комнату с компьютерами, то дело не только в том, что это трудно, но и в том, что любая попытка проникнуть в эту комнату увеличивает для злоумышленника риск быть пойманным. И именно поэтому брешь, которую может использовать только сотрудник компании, менее серьезна, чем брешь, которую может использовать любой начинающий хакер из Интернета. В первом случае риск быть пойманным намного выше, чем во втором.

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

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



Элементы показателя общей серьезности


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

Возможность использования показывает, насколько просто или сложно использовать данную уязвимость, потребуется ли высокая квалификация в программировании или эту уязвимость сможет использовать любой человек с самыми элементарными знаниями в указанной области.

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



Linux имеет долгую историю использования тщательно проработанной многопользовательской архитектуры


Linux никогда не была однопользовательской операционной системой. Поэтому в ней с самого начала заложен принцип изолирования пользователей от приложений, файлов и каталогов, воздействующих на операционную систему в целом. Каждому пользователю предоставляется пользовательский каталог, в котором хранятся все его файлы данных и файлы конфигурации, принадлежащие этому пользователю. Когда пользователь запускает какое-либо приложение (например, текстовый процессор), оно запускается с ограниченными полномочиями данного пользователя. Запущенное пользователем приложение имеет право на запись только в собственный каталог этого пользователя. Оно не может ничего записать в системный файл или даже в каталог другого пользователя, если только администратор явным образом не предоставит данному пользователю такое право.

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

Ограничения по умолчанию — свойство модульной архитектуры Linux; едва ли возможно отправить по электронной почте пользователю Linux такое сообщение, которое заразит вирусом весь компьютер. Не имеет значения, насколько неудачно сконструирован почтовый клиент или как именно он прореагирует на вирус — полномочия, установленные для клиента, позволят ему заразить или повредить только файлы своего пользователя.
Web-навигаторы, работающие в ОС Linux, не поддерживают такие небезопасные по своей природе объекты, как элементы управления ActiveX, но даже если бы они поддерживались, вредоносный элемент ActiveX смог бы запуститься только с полномочиями того пользователя, который запустил web-навигатор. И в этом случае самый большой вред, который он смог бы принести — это заразить или удалить собственные файлы пользователя.

Даже сервисы, например, web-серверы, обычно запускаются как пользователи с ограниченными полномочиями. Так, Debian GNU/Linux запускает web-сервер Apache как пользователя "www-data", принадлежащего к группе с тем же именем "www-data". Если злоумышленник на компьютере с Debian получит полный контроль над web-сервером Apache, он сможет воздействовать только на файлы, принадлежащие пользователю "www-data", то есть на web-страницы. В свою очередь, MySQL, сервер базы данных SQL-типа, часто используемый вместе с Apache, запускается с полномочиями пользователя "mysql". Даже если Apache и MySQL вместе обслуживают web-страницы, злоумышленник, получивший контроль над Apache, не будет иметь полномочий, позволяющих использовать уязвимость в Apache для получения контроля над сервером базы данных, потому что сервер базы данных "принадлежит" другому пользователю.

Кроме того, пользователи, ассоциированные с такими сервисами, как Apache, MySQL и т.д., часто устанавливаются с учетными записями, не имеющими доступа к командной строке. Поэтому, если злоумышленник сможет получить права учетной записи пользователя MySQL, он не сможет воспользоваться этой уязвимостью для того, чтобы дать произвольные команды на сервер Linux, поскольку данная учетная запись не может вызывать команды.

Напротив, ОС Windows изначально сконструирована таким образом, что всем пользователям и приложениям предоставляется административный доступ ко всем файлам на компьютере. Только постепенно Windows была переработана так, чтобы изолировать пользователей и их действия от остальной системы.Операционная система Windows Server 2003 близка к достижению этой цели, но метод, избранный Microsoft для создания барьера между пользователем и системой, все тот же: широкое использование постоянно меняющихся корректировок существующей "конструкции" вместо ее фундаментальной переработки на основе новой концепции, в которой во главу угла поставлены реализация многопользовательских возможностей и безопасность.


Linux не зависит от RPC-механизма


Как уже говорилось в разделе о Windows, аббревиатурой RPC обозначается удаленный вызов процедуры (Remote Procedure Call). RPC-механизм позволяет одной программе дать указание второй программе выполнить какое-либо действие, даже если "вторая программа" работает на другом компьютере. Первая программа при помощи RPC отправляет другой программе указание выполнить определенные расчеты и вернуть результат. Напомним, что удаленным вызовом процедуры этот механизм называется потому, что не имеет значения, функционирует ли "другая программа" на том же компьютере, на другом компьютере, стоящем в соседней комнате, или где-то в Интернете.

В большинстве дистрибутивов Linux программы инсталлируются так, что по умолчанию доступ в сеть отключен. Например, MySQL, сервер базы данных SQL-типа, обычно инсталлируется так, что он не ожидает инструкций из сети. Если создать web-сайт, установив Apache и MySQL на одном и том же компьютере, то для взаимодействия Apache и MySQL не требуется, чтобы MySQL прослушивал сеть. Напротив, SQL Server прослушивает сеть независимо от того, необходимо ли это. Если требуется, чтобы MySQL слушал сеть, эту функцию следует включить вручную, а затем в явном виде определить пользователей и компьютеры, которым разрешен доступ к MySQL.

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

В отличие от Windows Server 2003, компьютер с операционной системой Linux останется полностью работоспособным, даже если на нем заблокировать практически все RPC-сервисы, связанные с использованием сети.



Миф 1. Безопасность — вопрос количества: чем меньше инсталляций, тем безопаснее


Пожалуй, чаще всего повторяемый миф при сравнении безопасности Windows и Linux — утверждение, что с ОС Windows случается больше инцидентов, связанных с вирусами, сетевыми червями, троянскими программами и другими проблемами, только из-за того, что злоумышленники предпочитают вмешиваться в работу программного обеспечения, которое имеет наибольшую инсталляционную базу. Это рассуждение приводят в защиту ОС Windows и Windows-приложений. Windows преобладает на настольных компьютерах; именно поэтому на Windows и Windows-приложения направлено большинство атак, и именно поэтому не наблюдаются вирусы, сетевые черви и троянские кони для Linux. Нельзя отрицать, что до некоторой степени это верно, однако отнюдь не бесспорен вывод, который отсюда делается, а именно: Linux и Linux-приложения не являются более безопасными, чем Windows и Windows-приложения, просто Linux — слишком незначительная цель для того, чтобы тратить усилия на организацию атаки.

Это рассуждение легко опровергнуть, если учесть, что самым популярным программным обеспечением для web-серверов Интернета является Apache. Как следует из выполненного компанией Netcraft1 обзора web-сайтов за сентябрь 2004 г., 68% web-сайтов используют web-сервер Apache и только 21% web-сайтов используют Microsoft IIS. Если проблемы с безопасностью возникают из-за того, что злоумышленники нацеливаются на самую обширную инсталляционную базу, то должно наблюдаться больше червей, вирусов и прочих вредоносных программ, нацеленных на Apache и те операционные системы, под управлением которых он функционирует, чем на Windows и IIS. Более того, должно регистрироваться больше атак против Apache, чем против IIS, так как из приведенного выше рассуждения следует, что проблема заключается в количествах, а не в уязвимостях.

Netcraft Web Survey for September 2004 — http://news.netcraft.com/archives/2004/09/index.html

Однако в реальности наблюдается обратная картина. В течение долгого времени IIS был главной целью для сетевых червей и других атак, и эти атаки были весьма успешными.
Сетевой червь Code Red, который использовал переполнение буфера в сервисе IIS для получения контроля над web-серверами, заразил около 300 тысяч серверов, и его распространение прекратилось лишь потому, что это было предусмотрено в программном коде данного червя. Воздействие еще одного сетевого червя IISWorm оказалось ограниченным только благодаря тому, что эта программа была плохо написана, а вовсе не из-за успешной защиты IIS.

Да, известны сетевые черви для Apache, например, Slapper. (В действительности Slapper использует известную уязвимость в протоколе OpenSSL, а не в Apache). Но сетевые черви для Apache редко становятся сенсацией, поскольку их воздействие очень ограничено и они легко искореняются. На атакуемых сайтах уже были приняты меры, исключающие возможность использования ошибки в OpenSSL. Кроме того, благодаря модульной структуре Linux и UNIX было очень просто очистить и восстановить зараженные сайты. Для этого потребовалось всего несколько команд и не было необходимости в перезагрузке.

Возможно, именно поэтому в рейтинге Netcraft среди 50 web-сайтов, лидирующих по длительности непрерывной работы (промежуток времени между перезагрузками), оказалось 47, использующих Apache2. Ни на одном из этих 50 web-сайтов не использовались ни Windows, ни Microsoft IIS. Поэтому, если верно предположение, что злоумышленники атакуют наиболее распространенные программные платформы, то возникает вопрос: почему хакеры так успешно взламывают программное обеспечение и операционную систему, самые популярные среди настольных компьютеров, заражают 300 тысяч серверов IIS, но неспособны нанести подобный ущерб наиболее популярному web-серверу и его операционным системам?

Netcraft Top 50 Servers With Longest Uptime (результаты могут отличаться от приведенных, так как информация обновляется ежедневно) —

Читатели, посетившие web-сайт Netcraft, не могут не заметить, что все 50 серверов из списка лучших по длительности непрерывной работы используют какую-либо разновидность BSD, в основном BSD/OS.


Ни один из них не функционирует под управлением Windows и ни один — под управлением Linux. Самое продолжительное время непрерывной работы среди 50 лидеров составляет 1 768 дней подряд или почти 5 лет.

В результате складывается впечатление, что BSD по своей надежности превосходит все остальные операционные системы, однако информация Netcraft, хотя и непреднамеренно, вводит в заблуждение. Netcraft определяет продолжительность непрерывной работы операционных систем по данным, которые регистрируются самими операционными системами. Linux, Solaris, HP-UX и некоторые версии FreeBSD регистрируют не более 497 дней непрерывной работы, после чего счетчики обнуляются, и отсчет начинается заново. Поэтому и кажется, что все web-сайты, размещенные на компьютерах под управлением Linux, Solaris, HP-UX и, в некоторых случаях, FreeBSD, перезагружаются каждые 497 дней, даже если они функционируют годами. При составлении обзора Netcraft ни для одной из этих операционных систем не будет зарегистрировано время непрерывной работы, превышающее 497 дней, даже если они годами функционируют без перезагрузки, так что названные системы никогда не окажутся среди 50 лидеров.

Это объясняет, почему Linux, Solaris и HP-UX не могут продемонстрировать такой же впечатляющий результат по количеству последовательных дней непрерывной работы, как BSD, даже если на самом деле эти операционные системы годами функционируют без перезагрузки. Но это не объясняет, почему среди 50 лидеров нет серверов под управлением ОС Windows. Windows не обнуляет счетчик времени непрерывной работы. Очевидно, просто не существует web-сайтов под управлением ОС Windows, которые функционировали бы без перезагрузки достаточно долго, чтобы попасть в список 50 лучших.

Принимая во внимание казус с 497-дневным циклом обнуления становится неясным, как сравнить продолжительность непрерывной работы для Linux и Windows, основываясь на опубликованных данных Netcraft. Два результата — не статистика, но и они кое о чем говорят, особенно если один из них относится к web-сайту компании Microsoft.На сентябрь 2004 года средняя продолжительность непрерывной работы web-серверов под управлением ОС Windows, поддерживающих собственный web-сайт компании Microsoft (www.microsoft.com), составила примерно 59 дней. Максимальная продолжительность непрерывной работы для Windows Server 2003 на том же сайте — 111 дней, минимальная — 5 дней. Сравним эти результаты с данными для сайта www.linux.com (типовой сайт под управлением ОС Linux), у которого и средняя, и максимальная продолжительность непрерывной работы составляет 348 дней. Точное совпадение средней и максимальной величины означает, что эти серверы либо обнулили счетчик времени 348 дней назад, проработав до этого 497 дней, либо 348 дней назад они были перезагружены или впервые включены.

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


Миф 2. Открытый код опасен по определению


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

Однако факты говорят о другом. Количество предназначенных для ОС Windows эффективных вирусов, программ-шпионов, сетевых червей, троянских и других вредоносных программ огромно, а количество компьютеров, постоянно заражаемых различными комбинациями вышеперечисленного, так велико, что вряд ли поддается исчислению. Вредоносное программное обеспечение "свирепствует" настолько, что для компрометации свежеустановленной, "непропатченной" версии Windows XP после подключения компьютера к Интернету требуется в среднем 16 минут — меньше, чем время, необходимое данной ОС для загрузки и инсталляции программных коррекций, которые позволят защитить этот компьютер3.

Unpatched PC "Survival Time" Just 16 Minutes, Gregg Keizer, TechWeb News http://www.internetweek.com/breakingNews/showArticle.jhtml?articleID=29106061

Еще один пример. Web-сервер Apache имеет открытый код. Microsoft IIS — патентованный. В этом случае факты опровергают и миф о наибольшей популярности, и миф об опасности открытого кода. Web-сервер Apache — наиболее популярный web-сервер. Если бы оба эти мифа были правдой, следовало бы ожидать, что Apache и операционные системы, под управлением которых он функционирует, будут чаще подвергаться атакам, чем Microsoft Windows и IIS. На деле же все происходит с точностью до наоборот. Apache занимает почти монопольное положение в списке серверов с наибольшей продолжительностью непрерывной работы. Ни Microsoft Windows, ни Microsoft IIS нет в списке 50 серверов с самым продолжительным временем непрерывной работы. Очевидно, тот факт, что злоумышленники имеют доступ к открытому коду Apache, не дает им никакого преимущества в организации более успешных атак против Apache, чем против IIS.



Миф 3. Выводы на основании единственной характеристики


Слабость других популярных мифов о большей безопасности Windows по сравнению с Linux в том, что они основаны на единственном показателе — каком-нибудь одном аспекте измерения безопасности. Это верно для любого источника информации, будь то данные компетентного исследования или малообоснованная информация на уровне слухов.

Широко известно утверждение: "Для Linux зарегистрировано больше предупреждений об уязвимостях, чем для Windows, поэтому можно говорить о меньшей безопасности Linux по сравнению с Windows". Не менее распространено и такое: "Время между обнаружением бреши и созданием соответствующей программной коррекции в случае Linux больше, чем в случае Windows, поэтому можно говорить о меньшей безопасности Linux по сравнению с Windows".

Второе утверждение совершенно непостижимо. Невозможно объяснить, почему считается, что по такому показателю, как среднее время от момента обнаружения бреши до выпуска соответствующей программной коррекции, Microsoft превосходит какую-либо из конкурирующих операционных систем, не говоря уже о Linux. Компании Microsoft потребовалось семь месяцев (!), чтобы устранить одну из самых серьезных уязвимостей в системе защиты (Microsoft Security Bulletin MS04-007 ASN.1 Vulnerability, компания eEye Digital Security сообщила об этой задержке в информационном бюллетене AD20040210). А ведь еще имеются бреши, о которых Microsoft открыто заявляет, что они никогда не будут ликвидированы. В бюллетене Microsoft Security Bulletin MS03-010 об уязвимости Denial Of Service (отказ в обслуживании) в Windows NT говорится, что эта уязвимость никогда не будет устранена. Позднее компания Microsoft заявила, что не будут устраняться уязвимости в Internet Explorer для всех версий операционных систем, выпущенных ранее Windows XP. В статистическом смысле случай с семью месяцами между обнаружением и устранением ошибки не окажет значительного влияния на среднее время реагирования при условии, что найдется достаточно много примеров чрезвычайно быстрого реагирования, которые скомпенсируют подобные аномалии, если это действительно аномалии.
Но стоит включить в выборку только один случай "никогда" — и о статистическом среднем можно забыть навсегда.

Оставив в стороне эту неразрешимую загадку, рассмотрим, есть ли основания полагать, что Linux менее безопасна, чем Windows, потому что среднее время между обнаружением уязвимости и выпуском соответствующей программной коррекции в случае Linux больше, чем в случае Windows. Зададим себе вопрос: "Если прямо сейчас у меня случится сердечный приступ, в какое отделение скорой помощи я предпочту попасть? Туда, где среднее время между регистрацией пациента и оказанием ему помощи самое короткое? Или я предпочту отделение, где это среднее время дольше, но зато пациенты с самыми серьезными диагнозами получают помощь в первую очередь?"

Очевидно, что следует выбрать второе отделение, но вовсе не потому, что из приведенной выше информации ясно, что оно лучше первого. Этот вариант предпочтительнее, потому что он выбран по двум показателям, один из которых особенно важен для вас именно в данный момент. Можно с уверенностью утверждать: мало кто захочет попасть в больницу, о которой известно, что в ней есть шанс умереть от сердечного приступа, ожидая, пока врач закончит вправлять кому-то вывихнутый мизинец — каким бы впечатляющим ни было "среднее время реагирования на запрос о медицинской помощи". Трудность в том, что в приведенном примере недостаточно информации для принятия оптимального решения. Ничего не известно о том, как больница с наименьшим "временем реагирования" определяет, кому из больных следует уделить внимание в первую очередь. Кроме того, неплохо бы иметь информацию о показателе смертности среди больных, нуждающихся в неотложной помощи, о квалификации врачей и т. д.

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



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

Любой отдельно взятый показатель может ввести в заблуждение, поскольку неясна его значимость. Рассмотрим утверждение, что известно больше предупреждений для программного обеспечения Linux, чем для Windows. Эта статистика бессмысленна, потому что не отвечает на самые важные вопросы. Сколько брешей из зафиксированных всеми предупреждениями об уязвимостях создают реальные угрозы? Насколько серьезны эти угрозы? Насколько вероятно, что их использование причинит серьезный ущерб компьютерам? Ответы на эти вопросы имеют большое значение. Что лучше, операционная система со 100 брешами, из-за которых возможен незначительный ущерб (а то и вовсе никакого) и которыми не сможет воспользоваться никто, кроме локальных пользователей с действующими учетными записями и физическим доступом к компьютеру? Или стоит предпочесть операционную систему с единственной критической брешью, из-за которой любой хакер из Интернета может уничтожить всю информацию на сервере? Ясно, что само по себе количество предупреждений не является значимым показателем, указывающим на большую безопасность одной операционной системы по сравнению с другой.


Настройка и администрирование


Наконец, различие в подходе к настройке и администрированию серверов в Linux и в Windows, как уже отмечалось, возможно, является самым важным различием между этими двумя операционными системами.

Windows предлагает использовать знакомый интерфейс, что означает администрирование ОС Windows Server 2003 на самом сервере. Linux не полагается на локальное использование графического интерфейса и не поощряет этого отчасти потому, что функционирование графической среды на сервере — это необоснованная трата ресурсов, а отчасти потому, что от этого возрастают угрозы безопасности сервера. Так, любой сервер, предлагающий использовать графический интерфейс на компьютере сервера, предлагает также выполнять на сервере похожие операции, например, использовать web-навигатор. В результате сервер подвергается угрозам, порожденным уязвимостями в защите web-навигатора. Любой сервер, побуждающий пользователя к удаленному администрированию, защищен от подобных угроз. Если администрирование сервера Linux осуществляется удаленно, через учетную запись пользователя на рабочей станции, то брешь в web-навигаторе создает угрозу только этой удаленной рабочей станции, а не серверу. Именно поэтому брешь в защите web-навигатора потенциально опаснее для Windows Server 2003, чем для Red Hat Enterprise Server AS.



О чем эта статья?


Много копий было сломано в спорах о том, действительно ли Linux — более безопасная операционная система, чем Windows. Мы сравнили Windows и Linux по значениям следующих параметров в 40 последних программных коррекциях/уязвимостях для Microsoft Windows Server 2003 и Red Hat Enterprise Linux AS v.3:

Серьезность уязвимостей в системе безопасности, которая оценивается по следующим показателям:

возможный ущерб (насколько велик вред от использования ОС с незакрытой уязвимостью?); возможность использования (насколько легко использовать данную уязвимость?); возможная доступность (какого рода доступ требуется для использования данной уязвимости?).

Количество уязвимостей, серьезность которых определяется как Критическая.

Результаты сравнения не оказались неожиданными. Даже по субъективным и заниженным стандартам, применяемым Microsoft, по меньшей мере 38% последних программных коррекций предназначены для ликвидации брешей, которые Microsoft относит к критическим. Только 10% программных коррекций и предупреждений в Red Hat относятся к брешам, имеющим критический уровень серьезности. Приведенные результаты получены при условиях, благоприятных для Microsoft и обоснованно жестких для Red Hat, так как они основаны на критериях Microsoft, а не на используемых нами более строгих показателях безопасности. Если применить наши собственные критерии, то количество критических брешей в Windows Server 2003 возрастет до 50%.

Результаты запроса к базе данных Computer Emergency Readiness Team (CERT) подтвердили наши выводы, сделав разницу еще более значительной. Расположив полученные данные по убыванию серьезности (от более критических к менее критическим), мы обнаружили, что уровень серьезности 39 из первых 40 записей в базе данных CERT для Windows превышает пороговое значение, установленное CERT для серьезных предупреждений. Лишь три из первых 40 записей оказались выше указанного порога в результатах запроса к этой базе данных для Red Hat. Запрос к базе данных CERT для Linux показал, что только шесть из первых 40 записей находятся выше этого порогового значения.


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

Почему же тогда так много, на первый взгляд, убедительных уверений в том, что операционная система Linux в действительности менее безопасна, чем Windows? Обоснование вывода о меньшей безопасности Linux содержит вопиющие логические несоответствия. Нужно всего лишь чуть внимательнее рассмотреть этот вопрос, чтобы развенчать мифы и найти логические ошибки, лежащие в основе следующих часто повторяемых утверждений:

Windows подвергается такому количеству атак только потому, что имеет больше инсталляций, чем Linux. Следовательно, Linux была бы столь же уязвима, если бы имела столько же инсталляций. Открытый код по природе своей значительно опаснее, поскольку злоумышленникам легче найти бреши в системе безопасности. Для Linux имеется больше предупреждений об уязвимостях, чем для Windows, следовательно, Linux менее безопасна, чем Windows. В случае операционной системы Linux проходит больше времени между обнаружением бреши и выпуском соответствующей программной коррекции, чем в случае Windows.

Ошибка утверждений 3 и 4 в том, что они игнорируют наиболее важные показатели, позволяющие оценить безопасность одной операционной системы по сравнению с другой. Как будет показано в разделе "Реальные показатели безопасности и серьезности", попытки характеризовать безопасность на основании одного показателя (например, по тому, сколько времени проходит между обнаружением бреши и выходом программной коррекции) не дают значащих результатов.

В заключение дан краткий обзор существенных различий в концепциях Windows и Linux, что позволяет понять, почему операционная система Windows более уязвима к атакам как на серверах, так и на настольных компьютерах, и почему Linux является более безопасной системой.


От редакции бюллетеня Jet Info


В последнее время во всем мире растет популярность различных версий операционной системы Linux, они все чаще используются как в частном бизнесе, так и государственными структурами. Такая же тенденция наблюдается и в России. Конкуренция операционных систем обостряет противостояние между Linux-сообществом и сторонниками Windows во главе с компанией Microsoft. Стороны приводят множество аргументов в пользу "своих" систем, и далеко не всегда очевидно, какие из них — маркетинговый ход, а какие — результат беспристрастного исследования. Так что же выбрать? Какие критерии применить?

Один из решающих факторов при выборе операционной системы — насколько хорошо она обеспечивает информационную безопасность. Именно вокруг сравнения безопасности Linux и Windows давно кипят нешуточные страсти.

Первым залпом в войне Windows и Linux стал доклад компании Forrester Research, в котором было показано, что Windows безопаснее, чем Linux. Для сравнения использовались собранные за период с 1 июня 2002 г. по 31 мая 2003 г. данные об уязвимостях в защите для всех платформ Windows и всех вариантов дистрибутивов Linux от Debian, MandrakeSoft, Red Hat и Novell. Как и следовало ожидать, сообщество Linux не осталось в долгу. Сразу после публикации доклада упомянутые в нем дистрибьюторы Linux выпустили совместное заявление, в котором утверждалось, что доклад Forrester Research вводит в заблуждение, особенно потому, что в нем "все уязвимости ошибочно рассматриваются как равнозначные, независимо от риска, который возникает вследствие этих уязвимостей".

Мы предлагаем вашему вниманию независимый обзор Николаса Петрели (Nicholas Petreley), который рассмотрел доводы обеих сторон. Отчет опубликован 22 октября 2004 г. в британском Интернет-издании The Register. Перевод на русский язык выполнен с разрешения автора.

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

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

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

Кроме того, чтобы получить действительно беспристрастную картину, следовало бы сформировать стандартные "комплекты" Linux и Windows и проследить в течение определенного времени за уязвимостями этих комплектов, используя для анализа показатели, предложенные Петрели.

Но несмотря на отдельные недостатки, данный обзор — обоснованное мнение эксперта. В этом качестве он будет полезен всем, кого интересует относительная безопасность конкурирующих операционных систем — Windows и Linux.



По своей архитектуре Linux является модульной, а не монолитной системой


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

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

Ядро Linux поддерживает модульные драйверы, но в значительной мере является монолитным ядром, потому что сервисы в этом ядре взаимозависимы. Все отрицательные последствия монолитности минимизируются тем, что ядро Linux, насколько это возможно, разработано как наименьшая часть системы. Linux почти фанатично придерживается следующего принципа: "Если задача может быть выполнена вне ядра, она должна быть выполнена вне ядра". Это означает, что в Linux почти каждая полезная функция ("полезная" означает "воспринимаемая конечным пользователем") не имеет доступа к уязвимым частям системы Linux.

Напротив, ошибки в драйверах графических адаптеров являются частой причиной "синего экрана смерти" в Windows. Это происходит из-за того, что Windows интегрирует графику в ядро, где подобная ошибка может вызвать отказ системы. Не считая нескольких известных исключений (например, коммерческий драйвер графики NVidia), Linux заставляет все графические драйверы функционировать вне ядра. Ошибка в графическом драйвере может вызвать сбой в графическом приложении, но не может вызвать отказ всей системы. В случае такой ошибки достаточно просто перезапустить графическое приложение. Никакой перезагрузки компьютера не требуется.



Показатель общей серьезности и взаимосвязь между тремя факторами риска


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

Возможный ущерб — последствия от этой бреши катастрофичны.

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

Пора нажимать аварийную кнопку, не так ли? Но предположим, что аналитик добавляет еще несколько слов. Использовать эту брешь может только тот, у кого есть ключ от серверной комнаты, потому что эта данная уязвимость требует физического доступа к компьютерам. Этот единственный ключевой показатель, простите за каламбур, радикально изменяет общую серьезность угрозы, порожденной данной конкретной брешью. Крайне низкая возможная доступность переводит стрелку на шкале серьезности с "тревога!" на "под контролем".

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

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



Применение показателя общей серьезности


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

Предположим, для одной операционной системы зарегистрировано намного больше предупреждений об уязвимостях, чем для другой. Этот показатель имеет смысл только в одном случае — если для данной системы имеется также больше предупреждений об уязвимостях с высоким уровнем общей серьезности. Одно дело, если довольно часто случаются разные мелкие неприятности, не представляющие практически никакой опасности, и совсем другое — когда регулярно обнаруживаются пусть и немногочисленные, но такие бреши, которые ставят под удар всю компанию.

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



содержится информация об уязвимостях


В Таб. 1 содержится информация об уязвимостях из 40 последних программных коррекций системы защиты, выпущенных компанией Microsoft6.

Microsoft Security Bulletin, Current Downloads (результаты могут отличаться от приведенных, так как информация регулярно обновляется) — http://www.microsoft.com/technet/security/CurrentDL.aspx

Microsoft обозначила 15 из этих 40 уязвимостей как Критические. Это означает, что, согласно субъективному анализу самой Microsoft, 38% из последних обнаруженных и исправленных проблем имеют серьезность Критическая, то есть наивысшую из возможных.

Однако в применяемой Microsoft методике оценки серьезности брешей есть два спорных момента.

Microsoft часто присваивает бреши серьезность Критическая для всех операционных систем Windows, кроме Windows Server 2003, когда той же бреши присваивается более низкий статус — Важная. Причина этого различия в том, что установленные в Windows Server 2003 настройки по умолчанию отличаются от настроек по умолчанию в других версиях Windows. Microsoft следующим образом описывает различные настройки7:

Default Settings Different on Windows Server 2003 Эти настройки перечисляются на нескольких страницах в разделе "Frequently Asked Questions, What is Internet Explorer Enhanced Security Configuration?" Вот одна из таких страниц: http://www.microsoft.com/technet/security/bulletin/ms03-032.mspx

"Уровень безопасности, установленный для зоны Интернет — Высокий. Такая настройка запрещает загрузку скриптов, элементов управления ActiveX, Microsoft Java Virtual Machine (MSJVM), HTML-контента и файлов. Отключено автоматическое обнаружение сайтов интрасети. Такая настройка передает все web-сайты интрасети и все сетевые пути UNC (Universal Naming Convention), не перечисленные в явном виде в зоне локальной интрасети, в зону Интернет. Заблокированы установка по требованию (Install On Demand) и использование дополнительных компонентов web-навигатора, разработанных не компанией Microsoft. Такая настройка не позволяет web-страницам автоматически устанавливать дополнительные компоненты, а также не позволяет функционировать компонентам, разработанным не компанией Microsoft. Заблокирован мультимедиа-контент.
Такая настройка не позволяет запускать музыкальные клипы, анимационные клипы и видеоклипы".

Хотя некоторые из этих настроек по умолчанию (например, блокировка мультимедиа-контента) абсолютно логичны для сервера, почти невозможно представить, чтобы кто-либо из использующих Windows Server 2003 не изменил настройки, описанные в первом абзаце. Эти настройки делают Internet Explorer почти бесполезным для администратора сервера, желающего использовать web-навигатор для выполнения административных задач, загрузки обновлений и т. д. Понижать уровень серьезности, предполагая, что пользователи Windows Server 2003 оставят такие настройки по умолчанию без изменений — значит, в лучшем случае, заблуждаться. Если бы пользователям Windows Server 2003 предлагалось администрировать сервер удаленно, это могло бы уменьшить данную угрозу. Но Microsoft рекламирует знакомый локальный интерфейс Windows как главное преимущество Windows Server 2003. В приведенный ниже список (Таб. 1) включены бреши, уровень серьезности которых ограничен в соответствии с полномочиями пользователя. Эти случаи отмечены в таблице: в столбце "Полномочия" указано "Пользователь". Но поскольку Windows Server 2003 — это сервер, то очевидно, что большинство пользователей, непосредственно работающих на компьютере под управлением Windows Server 2003, будут администраторами. Даже если предположить, что все станут использовать оптимальные приемы работы на настольном компьютере, очевидно, что администраторы Windows Server 2003 входят в систему с полномочиями администратора. Поэтому в тех случаях, когда серьезность брешей "ограничивается" полномочиями пользователя, большую часть времени уровень серьезности фактически не уменьшается, так как пользователь будет иметь полномочия администратора. В качестве примера можно привести брешь, описанную в Microsoft Security Bulletin MS04-015. По указанной выше причине эта брешь заслуживает оценки Критическая, а не Важная. Парадоксально, но подобные бреши в Linux заслуживают понижения оценки, потому что Linux не предлагает администраторам работать в графической среде непосредственно на сервере.

Приняв во внимание все обстоятельства, следует оценить как Критические еще по меньшей мере пять уязвимостей. Это означает, что по показателям, описанным в предыдущих разделах, 50% перечисленных брешей оцениваются как Критические. Если уязвимость должна иметь оценку Критическая с учетом того, что администратор, скорее всего, изменит те настройки по умолчанию, благодаря которым Microsoft понизила уровень серьезности, то этот факт отмечается в скобках. Но при общем сравнении эти уязвимости не рассматривались как Критические. Комментарий в скобках показывает, что Microsoft преднамеренно недооценивает серьезность данной бреши на основании необоснованного допущения — настройки по умолчанию, установленные в Windows Server 2003, существенно меняют ситуацию.

Таблица 1. Программные коррекции и уязвимости Microsoft Windows Server 2003


содержится информация об уязвимостях


В Таб. 2 содержится информация об уязвимостях из 40 последних программных коррекций системы защиты, выпущенных компанией Red Hat.

Компания Red Hat не определяла уровень серьезности. Для оценки каждой уязвимости использованы показатели, описанные в данной статье, при этом учитывалось, что серверы Linux обычно администрируются с настольных систем, а не через графический интерфейс на самом сервере. Многие оценки сопровождаются краткими комментариями, которые помогут читателям понять эту оценку.

Из 40 уязвимостей только четыре оценены как Критические. Это означает, что 10% из 40 последних обновлений имеют серьезность Критическая.

Но если принять во внимание особенности программного обеспечения, к которому относятся две из четырех уязвимостей, можно утверждать, что серьезность этих двух уязвимостей не следует оценивать так высоко. Эти две уязвимости связаны с программой Ethereal. Ethereal — это одно из нескольких доступных средств контроля сетевых компонентов и прослушивания сети ("sniffer"). Программа Ethereal запускается при необходимости, а не в качестве постоянного сервиса, поэтому вероятность того, что она будет работать в момент, когда кто-то пытается воспользоваться ее уязвимостью, крайне мала. Если по этой причине понизить серьезность указанных уязвимостей до Важная, то только 5% из 40 последних предупреждений следует считать Критическими.

Уязвимости в сервисах IPSEC и Kerberos более обосновано оценены как Критические, поскольку эти сервисы функционируют на постоянной основе.

Лишь немногие уязвимости позволяют злоумышленнику действовать на уровне администратора. Однако даже в этих редких случаях, как правило, имеются факторы, уменьшающие опасность. Например, уязвимость в Samba (июль 22, 2004, RHSA-2004:259-23) можно использовать только в том случае, если кто-либо сконфигурирует inetd (через файл hosts.allow) так, что известному пользователю и компьютеру разрешается доступ к этому сервису. Если система сконфигурирована правильно, то никто, кроме авторизованного известного пользователя, не может получить доступ к программе конфигурации Samba, чтобы использовать данную уязвимость. В противном случае серьезность этой уязвимости следовало бы оценить как Критическую. Для использования других брешей, позволяющих получить административный доступ, также необходимо быть известным пользователем с действующим идентификатором. Это уменьшает угрозу и снижает серьезность, поскольку значительно увеличивается вероятность поимки злоумышленника.

Таблица 2. Программные коррекции и уязвимости Red Hat Enterprise Linux AS v.3


Реальные показатели безопасности и серьезности


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

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



Результаты запросов к базе данных CERT по уязвимостям


Американская группа Computer Emergency Readiness Team (CERT) использует свой собственный набор показателей для оценки серьезности брешей в защите. Результат выражается числом в диапазоне от 0 до 180, причем значение 180 означает самую серьезную уязвимость. Шкала является нелинейной. Иначе говоря, уязвимость с оценкой 100 не является в два раза более серьезной, чем уязвимость с оценкой 50.

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

Мы сделали запросы к базе данных CERT по ключевым словам "Microsoft", "Red Hat" и "Linux". К сожалению, средства web-поиска на сайте CERT не позволяют обеспечить в полной мере желаемую детализацию и долговечность результатов. Особенно это верно для результатов поиска по "Red Hat" и "Linux". Результаты поиска по "Linux" включают в себя несколько уязвимостей Oracle, общих для Linux, UNIX и Windows. Результат по "Red Hat" с данными о самой серьезной уязвимости даже не содержит среди подробностей указания на Red Hat как на уязвимую систему. Результаты поиска по "Microsoft" представляются вполне точными, так как и в подробностях, и в самих записях указаны бреши именно в программном обеспечении Microsoft. Вследствие этого результаты несколько искажаются не в пользу Linux и Red Hat. Тем не менее, даже если принять эти результаты, проигнорировав искажение для Linux и Red Hat, все равно получается, что большинство записей в базе данных CERT относится к Microsoft, и эти записи содержат информацию о самых серьезных брешах.

Запрос к базе данных CERT по слову "Microsoft" дал 250 результатов, причем две первые записи описывают бреши с показателем серьезности 94,5. 39 записей описывают бреши с серьезностью 40 или выше. Средняя оценка серьезности по 40 первым записям — 54,67. (Усреднение проведено по 40 записям, а не по 50 или больше, так как поиск для "Red Hat" дал только 46 записей).


Запрос к базе данных CERT по слову "Red Hat" дал 46 результатов. Первая запись описывает брешь с показателем серьезности 108,16. Только три записи (против 39 для Microsoft) содержат оценку серьезности 40 или выше. Среднее значение серьезности по первым 40 записям — 17,96.

Запрос к базе данных CERT по слову "Linux" дал 100 результатов. Первая запись описывает брешь с показателем серьезности 87,72. Только шесть записей содержат оценку серьезности 40 и выше. Среднее значение серьезности по первым 40 записям — 28,48.

Не стоило ожидать, что эти результаты совпадут с результатами нашего анализа по последним программным коррекциям. CERT использует другие критерии отбора, другой порядок дат, к тому же CERT не ограничивается только Windows Server 2003 и Red Hat Enterprise Linux AS v.3. Но результаты запросов к базе данных CERT отражают тот факт, что бреши в системе защиты Windows оказываются серьезными гораздо чаще, чем бреши в Linux, что соответствует нашим выводам.



Серверы Linux идеально подходят для удаленного администрирования


Сервер Linux можно, а часто и нужно, инсталлировать без подключенного монитора и администрировать удаленно. Очень часто такой тип инсталляции идеален для серверов, поскольку при удаленном администрировании сервер не подвергается таким угрозам, как при локальном администрировании.

Например, можно войти в систему на своем настольном компьютере в качестве обычного пользователя с ограниченными полномочиями и администрировать сервер под управлением ОС Linux через административный web-интерфейс. Даже самая критическая уязвимость в защите web-навигатора сможет воздействовать только на локальную учетную запись пользователя на его настольном компьютере, не затронув сервер.

Возможно, это одно из самых главных отличий Linux от Windows, потому что этот фактор сводит на нет многие критические уязвимости, общие для Linux и Windows, например, уязвимости web-навигаторов Mozilla и Internet Explorer.



Сравнение 40 последних программных коррекций системы защиты


В последующих разделах приведена информация о 40 самых последних программных коррекциях уязвимостей в защите ОС Windows Server 2003 (как утверждается, самой безопасной версии Windows) и Linux Red Hat Enterprise AS v.3 (как утверждается, конкурента Windows Server 2003). Данные по программным коррекциям и уязвимостям для Windows Server 2003 взяты непосредственно с web-сайта компании Microsoft, а для Red Hat Enterprise AS v.3 — с web-сайта Red Hat.

В операционной системе Windows Server 2003 были самые серьезные бреши в системе защиты. По собственной классификации Microsoft, 38% исправленных уязвимостей оценены как Критические. Если применить показатели, описанные в предыдущих разделах, это значение возрастет до 40—50%. Многие бреши, оцененные как Критические в Windows XP или других версиях, получили более низкую оценку в Windows Server 2003 только потому, что теперь по умолчанию для Internet Explorer и Outlook устанавливаются жестко ограничивающие настройки — настолько ограничивающие, что эти программы практически невозможно использовать, не изменив хотя бы некоторые из установленных по умолчанию настроек.

Совершенно иная картина получается с последними 40 уязвимостями Red Hat. Только четыре из них оценены по нашим показателям как Критические (Red Hat не указывает уровень серьезности своих предупреждений). Это означает, что 10% из 40 самых последних обновлений имеют серьезность Критическая. Фактически же эта оценка работает в поддержку Microsoft, поскольку для двух брешей можно легко доказать, что их серьезность ниже критической, что уменьшит процент критических брешей до 5%.



и уязвимости Microsoft Windows Server


Таблица 1

Таблица 1. Программные коррекции и уязвимости Microsoft Windows Server 2003

  Дата

Windows Server 2003

Описание

Способ

Путь

Доступ

Полномочия

Ущерб

Участие пользователя

Серьезность (оценка Microsoft)
Сентябрь 14, 2004 Microsoft Security Bulletin MS04-028 Переполнение буфера при обработке изображений в формате JPEG (GDI+) делает возможным запуск программного кода Специально сформированное изображение в формате JPEG Десятки приложений Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Критическая
Июль 30, 2004 Microsoft Security Bulletin MS04-025 Междоменная уязвимость в методе навигации Вредоносный web-сайт IE Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Средняя (должно быть: Критическая)
Июль 30, 2004 Microsoft Security Bulletin MS04-025 Вредоносный BMP-файл Вредоносный web-сайт IE Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Нет
Июль 30, 2004 Microsoft Security Bulletin MS04-025 Вредоносный GIF-файл Вредоносный web-сайт IE Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Критическая
Июль 13, 2004 Microsoft Security Bulletin MS04-024 Уязвимость в оболочке Windows делает возможным удаленный запуск программного кода HTML Email, посещение вредоносного web-сайта IE Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Важная (должно быть: Критическая)
Июль 13, 2004 Microsoft Security Bulletin MS04-023 Уязвимость в HTML showHelp делает возможным запуск программного кода HTML Email, посещение вредоносного web-сайта IE, Help and Support Center Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Критическая
Июль 13, 2004 Microsoft Security Bulletin MS04-023 Уязвимость в HTML-справке делает возможным запуск программного кода HTML Email, посещение вредоносного web-сайта IE, Help and Support Center Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Критическая
Июль 13, 2004 Microsoft Security Bulletin MS04-018 Накопительное обновление безопасности для Outlook Express Специально сформированный заголовок электронного письма Outlook Express 6 Удаленный (через Интернет) Пользователь Отказ в обслуживании (отказ Outlook Express) Нет Средняя
Июнь 8, 2004 Microsoft Security Bulletin MS04-017 Уязвимость в Crystal Reports Web Viewer делает возможным раскрытие информации и атаку типа "отказ в обслуживании" Специально сформированный HTTP-запрос Visual Studio .Net, IIS Удаленный (через Интернет) Сервис Удаляет файлы, Привилегированный доступ к информации, отказ в обслуживании (DoS) Нет Средняя
Июнь 8, 2004 Microsoft Security Bulletin MS04-016 Уязвимость в DirectPlay делает возможной атаку типа "отказ в обслуживании" Отправка вредоносного пакета на сервер IDirectPlay4 Удаленный (через Интернет) Сервис Отказ в обслуживании (DoS) на многопользовательском игровом сервере (Multiplayer Game Server) Нет Средняя
Май 11, 2004 Microsoft Security Bulletin MS04-015 Уязвимость в центре справки и поддержки делает возможным удаленный запуск программного кода HTML Email, посещение вредоносного web-сайта IE, Help and Support Center Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Важная (должно быть: Критическая)
Апрель 13, 2004 Microsoft Security Bulletin MS04-014 Уязвимость в Microsoft Jet Database Engine делает возможным запуск программного кода Специально сформированный запрос в Jet (SQL) Engine Jet Engine (SQL Server), IIS Удаленный (через Интернет) Сервис Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Важная
Апрель 13, 2004 Microsoft Security Bulletin MS04-013 Накопительное обновление безопасности для Outlook Express HTML Email, посещение вредоносного web-сайта MHTML Handling of Outlook Express Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Да Критическая
Апрель 13, 2004 Microsoft Security Bulletin MS04-012 Уязвимость в стандартной библиотеке RPC RPC RPC Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Критическая
Апрель 13, 2004 Microsoft Security Bulletin MS04-012 Уязвимость в сервисе RPCSS Специально сформированное сообщение RPCSS Удаленный (через Интернет) Сервис DoS (сервис RPCSS перестает отвечать на запросы) Нет Важная
Апрель 13, 2004 Microsoft Security Bulletin MS04-012 RPC поверх HTTP Специально сформированное сообщение IIS/COM Internet Services Удаленный (через Интернет) Пользователь, Сервис DoS (сервер перестает отвечать на запросы) Нет Низкая
Апрель 13, 2004 Microsoft Security Bulletin MS04-012 Идентификатор объекта Специально сформированное сообщение, требуется действующий регистрационный ИД IIS/COM Удаленный (через Интернет) Сервис, Администратор DoS (требуется перезапуск IIS) Нет Низкая
Апрель 13, 2004 Microsoft Security Bulletin MS04-011 Уязвимость в LSASS Специально сформированное сообщение LSASS Только локальный администратор Нет Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Низкая
Апрель 13, 2004 Microsoft Security Bulletin MS04-011 Уязвимость в PCT Специально сформированное TCP-сообщение PCT/SSL, приложения, использующие SSL (IIS) Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Низкая
Апрель 13, 2004 Microsoft Security Bulletin MS04-011 Уязвимость в HTML-справке делает возможным запуск программного кода HTML Email, посещение вредоносного web-сайта HTML Help Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Требуется Критическая
Апрель 13, 2004 Microsoft Security Bulletin MS04-011 Уязвимость в H.323/ICF Специально сформированное сообщение NetMeeting Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Важная
Апрель 13, 2004 Microsoft Security Bulletin MS04-011 Negotiate SSP Специально сформированное сообщение IIS Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Критическая
Апрель 13, 2004 Microsoft Security Bulletin MS04-011 Уязвимость в SSL Вредоносное сообщение IIS/SSL Удаленный (через Интернет) Нет Перезагрузка системы в результате DoS Нет Важная
Апрель 13, 2004 Microsoft Security Bulletin MS04-011 Уязвимость ASN.1 "Double Free" Специально сформированный запрос на аутентификацию ASN.1, используется многими приложениями Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Критическая
Февраль 10, 2004 Microsoft Security Bulletin MS04-007 Уязвимость в библиотеке ASN.1 может допустить запуск кода Специально сформированный запрос на аутентификацию ASN.1, используется многими приложениями Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Критическая
Февраль 10, 2004 Microsoft Security Bulletin MS04-006 Уязвимость в службе WINS (Windows Internet Name Service) может допустить запуск кода Специально сформированное сообщение, переполнение буфера WINS Удаленный (через Интернет) Администратор Отказ в обслуживании (WINS перестает отвечать на запросы), возможен полный контроль Нет Важная
Февраль 2, 2004 Microsoft Security Bulletin MS04-004 Междоменная уязвимость HTML Email, посещение вредоносного web-сайта IE Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Требуется Средняя
Февраль 2, 2004 Microsoft Security Bulletin MS04-004 Уязвимость операции перетаскивания (Drag-and-Drop) HTML Email, посещение вредоносного web-сайта IE Удаленный (через Интернет) Пользователь Загружает программы без уведомления Требуется Средняя
Февраль 2, 2004 Microsoft Security Bulletin MS04-004 Неправильная URL-канонизация HTML Email, посещение вредоносного web-сайта IE Удаленный (через Интернет) Пользователь Фальсификация web-сайта Требуется Важная
Январь 13, 2004 Microsoft Security Bulletin MS04-003 Переполнение буфера в компонентах MDAC делает возможным запуск программного кода Фальсификация локального сервера SQL Server MDAC Удаленный (через Интернет) Сервис Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Важная
Январь 13, 2004 Microsoft Security Bulletin MS04-001 Дефект фильтра H.323 сервера Internet Security and Acceleration Server 2000 делает возможным удаленный запуск программного кода Специально сформированное сообщение, переполнение буфера Microsoft Firewall Service, Microsoft Internet Security and Acceleration Server Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Критическая
Ноябрь 11, 2003 Microsoft Security Bulletin MS03-048 Междоменная уязвимость HTML Email, посещение вредоносного web-сайта IE Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Требуется Средняя (должно быть: Критическая)
Ноябрь 11, 2003 Microsoft Security Bulletin MS03-048 Уязвимость в XML-объекте HTML Email, посещение вредоносного web-сайта IE Удаленный (через Интернет) Пользователь Нарушитель может прочитать известные файлы в системе Требуется Низкая
Ноябрь 11, 2003 Microsoft Security Bulletin MS03-048 Уязвимость операции перетаскивания (Drag-and-Drop) HTML Email, посещение вредоносного web-сайта IE Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Требуется Средняя (должно быть: Критическая)
Октябрь 15, 2003 Microsoft Security Bulletin MS03-045 При переполнении буфера элементов управления "Список" и "Поле со списком" может возникнуть возможность запуска кода Использование бреши в графическом элементе управления Windows API Локальный пользователь с действующим ИД Пользователь Полный контроль, Неограниченный Нет Низкая
Октябрь 15, 2003 Microsoft Security Bulletin MS03-044 Переполнение буфера центра справки и поддержки Windows может поставить под угрозу безопасность системы HTML Email, посещение вредоносного web-сайта IE, Help and Support Center, Протокол HCP Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Требуется Критическая
Октябрь 15, 2003 Microsoft Security Bulletin MS03-043 Переполнение буфера службы Windows Messenger может допустить запуск кода Специально сформированное сообщение Служба Messenger Service, отключенная по умолчанию Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (сервер перестает отвечать на запросы) Нет Критическая
Октябрь 15, 2003 Microsoft Security Bulletin MS03-041 Уязвимость в механизме проверки кода подлинности может допустить удаленный запуск кода Вредоносный элемент управления ActiveX, используемый без разрешения при недостаточном объеме памяти ActiveX Authentication Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Требуется Критическая
Сентябрь 10, 2003 Microsoft Security Bulletin MS03-039 Переполнение буфера RPCSS может допустить запуск кода Специально сформированное сообщение RPCSS Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS Нет Критическая

Таблица 2

Таблица 2. Программные коррекции и уязвимости Red Hat Enterprise Linux AS v.3

  Дата

Red Hat Advanced Server

Описание

Метод

Путь

Доступ

Полномочия

Ущерб

Участие пользователя

Серьезность
Дата Red Hat Advanced Server Описание Метод Путь Доступ Полномочия Ущерб Участие пользователя Серьезность
Сентябрь 7, 2004 RHSA-2004:400-15 Обновленный пакет gaim позволяет устранить проблемы безопасности Отправить специально подготовленные данные в GAIM-клиент GAIM (Instant Messenger) Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Нет Важная (Gaim обычно не используется на сервере)
Сентябрь 1, 2004 RHSA-2004:323-09 Обновленный пакет lha позволяет устранить уязвимость в системе защиты Убедить пользователя использовать специально сформированную команду Хорошо сформированный LHA-архив, убеждающий пользователя использовать команду Загрузка или иной способ получения файла со сжатием lha Пользователь Полный контроль, Неограниченный Да Низкая (lha - это редко используемый устаревший формат сжатия)
Сентябрь 1, 2004 RHSA-2004:349-10 Обновленные пакеты http позволяют устранить брешь mod_ssl в системе защиты Прервать SSL-запрос в определенном состоянии Apache 2.0.50 и более ранние версии Удаленный (через Интернет) Сервис Расход ресурсов ЦП (возможно, DoS) Нет Важная
Сентябрь 1, 2004 RHSA-2004:436-07 Обновленный пакет rsync позволяет устранить проблему безопасности Отправить специально сформированную команду rsync rsync 2.6.2 и более ранние версии Удаленный (через Интернет) Сервис Позволяет читать/записывать файлы, не определенные в качестве доступных с помощью rsync Нет Важная (rsync не является общедоступным сервисом, и chroot сводит эту уязвимость на нет)
Август 31, 2004 RHSA-2004:350-12 Обновленные пакеты krb5 позволяют устранить проблемы безопасности Отправить специально сформированный запрос на аутентификацию Kerberos authentication Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (Сервер перестает отвечать на запросы) Нет Критическая
Август 26, 2004 RHSA-2004:432-08 Обновленный пакет acrobat позволяет устранить проблемы безопасности Специально сформированный закодированный файл (uuencoded) Acrobat Reader Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Да Важная (Acrobat обычно не используется на сервере)
Август 20, 2004 RHSA-2004:414-19 Обновленные пакеты qt позволяют устранить проблемы безопасности Специально сформированный файл с изображением Qt (инструментарий, используемый KDE) Удаленный (через Интернет) Пользователь Отказ Qt, возможно выполнение кода Да Важная
Август 5, 2004 RHSA-2004:378-08 Обновленные пакеты Ethereal позволяют устранить проблемы безопасности Отправить вредоносные пакеты программа контроля сети Ethereal Удаленный (через Интернет) Администратор Отказ Ethereal, возможно выполнение кода Нет Критическая
Август 4, 2004 RHSA-2004:373-13 Обновления GNOME VFS для уязвимости extfs Убедить пользователя открыть специальный URI GNOME-VFS Нет Пользователь Позволяет выполнять действия в качестве пользователя Да Низкая
Август 4, 2004 RHSA-2004:402-08 Обновленные пакеты libpng позволяют устранить проблемы безопасности Создать специально сформированный png-файл, убедить пользователя посетить web-сайт libpng Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Да Важная (web-навигатор обычно не используется на сервере)
Август 4, 2004 RHSA-2004:421-17 Обновленные пакеты mozilla позволяют устранить проблемы безопасности Несколько способов, включая вредоносный java-скрипт web-навигатор Mozilla Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Да Важная (web-навигатор обычно не используется на сервере)
Август 3, 2004 RHSA-2004:413-07 Обновленные пакеты kernel позволяют устранить уязвимости в системе защиты Доступ к большим объемам памяти Kernel Локальный пользователь с действующим ИД Нет DoS (Сервер перестает отвечать на запросы) Да Низкая
Июль 29, 2004 RHSA-2004:308-06 Обновленный пакет ipsec-средств Проверить сертификат X.509 ipsec-средства Удаленный (через Интернет) Нет Не прерывается обмен кодами при неудачной верификации Нет Важная
Июль 29, 2004 RHSA-2004:409-05 Обновленные пакеты sox позволяют устранить переполнения буферов Специально подготовленный WAV-файл sox (Sound eXchange) Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный, DoS (Сервер перестает отвечать на запросы) Да Важная
Июль 22, 2004 RHSA-2004:259-23 Обновленные пакеты samba позволяют устранить уязвимости Специально подготовленная HTTP-аутентификация Samba (сервисы Windows) Администратор Администратор Полный контроль, Неограниченный, DoS (Сервер перестает отвечать на запросы) Да Низкая (требуется предварительная аутентификация пользователя с помощью inetd/hosts.allow)
Июль 19, 2004 RHSA-2004:392-13 Обновленные пакеты php позволяют устранить проблемы безопасности Неочевидная хэш-атака PHP Удаленный (через Интернет) Сервис Позволяет выполнять программный код в качестве пользователя Apache Нет Низкая (очень трудно использовать, зависит от структуры сайта)
Июль 6, 2004 RHSA-2004:342-10 Обновленные пакеты httpd позволяют устранить проблемы безопасности Подделать удостоверяющий центр (CA) SSL, которому SSL доверяет, или использовать большой объем памяти Apache with SSL Удаленный (через Интернет) Сервис Позволяет выполнять программный код в качестве пользователя Apache; возможно, DoS Нет Средняя (из-за возможности DoS-атаки)
Июль 2, 2004 RHSA-2004:360-05 Обновленные пакеты kernel позволяют устранить проблемы безопасности Подмонтировать файловую систему NFS с уязвимого компьютера Kernel Локальный пользователь с действующим ИД, должна функционировать NFS Группа Возможно, изменяет файл, принадлежащий другой группе Нет Низкая
Июнь 18, 2004 RHSA-2004:249-07 Обновленные пакеты libpng позволяют устранить проблемы безопасности Создать специально сформированный png-файл, убедить пользователя посетить web-сайт libpng Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный, DoS (Сервер перестает отвечать на запросы) Да Важная
Июнь 17, 2004 RHSA-2004:255-10 Обновленные пакеты kernel позволяют устранить уязвимости в системе защиты Запустить такие функции, как fsave и frstor Kernel Локальный пользователь, запускающий программы, которые вызывают отказ kernel Нет Отказ в обслуживании (Сервер перестает отвечать на запросы) Да Низкая (нарушитель должен запустить программы на сервере)
Июнь 14, 2004 RHSA-2004:240-06 Обновленный пакет SquirrelMail позволяют устранить несколько уязвимостей Пользователь электронной почты может запустить специально подготовленный URL PHP, Squirrelmail Удаленный пользователь Интернета с действующим регистрационным ИД Сервис Модифицирует содержимое базы данных, функционирует как другие пользователи web-mail Нет Важная (требуется пользователь с действующей учетной записью)
Июнь 9, 2004 RHSA-2004:233-07 Обновленный пакет CVS позволяет устранить проблемы безопасности Отправить специально подготовленные инструкции в CVS CVS Удаленный пользователь Интернета с действующим регистрационным ИД Сервис Выполняет программный код с полномочиями пользователя CVS Нет Важная (требуется пользователь с действующей учетной записью)
Июнь 9, 2004 RHSA-2004:234-06 Обновленные пакеты Ethereal позволяют устранить проблемы безопасности Отправить вредоносные пакеты программа контроля сети Ethereal Удаленный (через Интернет) Администратор Полный контроль, Неограниченный, DoS (Сервер перестает отвечать на запросы) Нет Критическая
Июнь 9, 2004 RHSA-2004:236-14 Обновленные пакеты krb5 Использовать искаженные аутентификационные имена Kerberos authentication Удаленный (через Интернет) Администратор Неизвестен Нет Низкая (используемая по умолчанию конфигурация Kerberos на Red Hat не имеет этой уязвимости)
Июнь 9, 2004 RHSA-2004:242-06 Обновленный пакет squid позволяет устранить уязвимость в системе защиты Отправить чрезмерно длинный пароль Кэш и прокси Squid Локальный пользователь с действующим ИД Сервис Выполняет программный код с полномочиями пользователя Squid Нет Низкая (требуется действующая учетная запись пользователя; используемая по умолчанию конфигурация Squid не имеет этой уязвимости)
Май 26, 2004 RHSA-2004:174-09 Обновленный пакет utempter позволяет устранить уязвимость Если сервис utempter активен, позволяет написать приложение, которое использует брешь utempter Локальный или удаленный пользователь с действующим ИД Администратор Позволяет перезаписывать привилегированные файлы с symlink Нет Низкая (требуется действующая учетная запись пользователя; utempter является скрытым сервисом, который очень трудно использовать)
Май 26, 2004 RHSA-2004:219-07 Обновленные пакеты tcpdump позволяют устранить различные уязвимости Специально подготовленные ISAKMP-пакеты tcpdump Удаленный (через Интернет) Нет Вызывает аварию tcpdump Нет Низкая (tcpdump - это всего лишь утилита, которую администраторы используют для проверки TCP-трафика)
Май 21, 2004 RHSA-2004:064-11 Обновленные пакеты samba позволяют устранить уязвимость в системе защиты Случайное изменение учетной записи samba Samba (сервисы Windows) Нет Нет Может изменить пароль пользователя на такой, который легче раскрыть Да Низкая (очень маловероятный случай с маловероятными последствиями)
Май 21, 2004 RHSA-2004:120-12 Обновленные пакеты OpenSSL позволяют устранить уязвимости Отправить специально подготовленные SSL-пакеты OpenSSL Удаленный (через Интернет) Нет Может вызвать аварию OpenSSL, Отказ в осблуживании (OpenSSL перестает отвечать на запросы) Нет Важная (из-за возможности DoS-атаки)
Май 19, 2004 RHSA-2004:180-10 Обновленные пакеты libpng позволяют устранить аварию Специально подготовленное png-изображение, убедить пользователя посетить web-сайт libpng Удаленный (через Интернет) Нет Вызывает аварию приложения, использующегося для вывода изображения Да Низкая (перезапускает приложение после его аварии)
Май 19, 2004 RHSA-2004:190-14 Обновленный пакет CVS позволяет устранить проблемы безопасности Специально подготовленная CVS- команда CVS Локальный или удаленный пользователь с действующим ИД Сервис Выполняет программный код с полномочиями пользователя CVS Нет Важная (требуется пользователь с действующей учетной записью)
Май 19, 2004 RHSA-2004:192-06 Обновленный пакет rsync позволяет устранить проблемы безопасности Отправить специально подготовленную rsync-команду rsync Удаленный (через Интернет) Сервис Позволяет читать/записывать файлы, не определенные в качестве доступных с помощью rsync Нет Важная (rsync не является общедоступным сервисом, и chroot сводит эту уязвимость на нет)
Май 17, 2004 RHSA-2004:222-11 Обновленные пакеты kdelibs решают проблемы безопасности URI Специально подготовленный URI, убедить пользователя посетить web-сайт KDE Удаленный (через Интернет) Пользователь Полный контроль, Неограниченный Да Важная
Май 11, 2004 RHSA-2004:165-09 Обновленный пакет ipsec-средств позволяет устранить уязвимости в демоне ISAKMP Специально подготовленный ISAKMP-заголовок чрезвычайно большого объема ipsec-tools Удаленный (через Интернет) Нет Отказ в обслуживании (Сервер перестает отвечать на запросы) Нет Критическая
Май 11, 2004 RHSA-2004:188-14 Обновленные пакеты kernel для Red Hat Enterprise Linux 3 Update 2 Самая серьезная из исправленных ошибок - возможная эскалация полномочий при монтировании томов Netware Kernel Локальный или удаленный пользователь с действующим ИД Нет Нет Нет Низкая (скрывает исправления ошибок)
Апрель 22, 2004 RHSA-2004:183-03 Обновленные пакеты kernel позволяют устранить уязвимость в системе защиты Написать программу, чтобы получить полномочия root (администратора) Kernel Локальный пользователь с действующим ИД Администратор Полный контроль, Неограниченный Нет Важная (требуется пользователь с действующей учетной записью)
Апрель 17, 2004 RHSA-2004:153-09 Обновленные пакеты CVS позволяют устранить проблемы безопасности Подделать пути доступа, чтобы перезаписать файлы CVS Локальный или удаленный пользователь с действующим ИД Сервис Перезаписывает файлы вне каталогов CVS Нет Важная (требуется пользователь с действующей учетной записью)
Апрель 14, 2004 RHSA-2004:133-12 Обновленный пакет Squid позволяет устранить уязвимость в системе защиты Специально подготовленные URL для просмотра запрещенных web-сайтов Кэш и прокси Squid Локальный или удаленный пользователь с действующим ИД Нет Позволяет просматривать web-страницы, заблокированные с помощью Squid Нет Средняя (обычно используется для обмана Squid с целью получить доступ к запрещенным сайтам, таким как порно-сайты, но может использоваться и для доступа к блокированным страницам интрасети)
Апрель 14, 2004 RHSA-2004:160-05 Обновленные пакеты OpenOffice позволяют устранить уязвимость в системе защиты для neon Специально подготовленные строки форматов, убедить пользователя посетить web-сайт OpenOffice Удаленный (через Интернет) Пользователь Выполняет программный код Да Средняя (OpenOffice обычно не используется на сервере)



Уровень общей серьезности


С учетом описанных выше трех факторов общая серьезность угроз может изменяться от Минимальная до Катастрофическая. Рассмотреть все перестановки не представляется возможным, но несколько примеров могут оказаться полезными. Эти примеры основываются на категориях возможного ущерба в сочетании с различными категориями возможной доступности и возможности использования.

Если анонимный злоумышленник из Интернета сумеет снизить производительность компьютеров компании, то оценка последствий может варьироваться от "мелкая неприятность" до "разрушительный удар по финансам" в зависимости от того, насколько критичной является производительность системы для деятельности компании. Атака на собственную учетную запись является бессмысленной, но такая саморазрушительная деятельность может создать для ИТ-подразделения лишнюю работу по восстановлению. Потенциальная серьезность бреши, позволяющей просматривать только файлы работающего в том же здании сослуживца, минимальна, даже если эту брешь тривиально просто использовать. Уровень серьезности возрастает, когда файлы этого сослуживца содержат конфиденциальную информацию, и уменьшается, если велика вероятность поимки нарушителя. С другой стороны, если просматривать конфиденциальные файлы в сети компании может любой злоумышленник из Интернета (высокая возможная доступность), общая серьезность бреши резко возрастает. Если брешь позволяет нарушителю изменять или удалять файлы работающего в том же здании сослуживца, серьезность этой бреши тем меньше, чем регулярнее выполняется в компании резервное копирование и чем больше вероятность поимки нарушителя. Если нарушитель может изменять файлы учетной записи пользователя на удаленном компьютере, то серьезность меняется в зависимости от важности этой учетной записи и предоставляемого ею сервиса. Например, серьезность может варьироваться от незначительного искажения web-страниц до их полного удаления.



В Windows слишком широко используется RPC-механизм


Аббревиатура RPC означает "удаленный вызов процедуры" (Remote Procedure Call). RPC — это то, что происходит, когда одна программа отправляет через сеть указание другой программе выполнить какое-либо действие. Например, одна программа может использовать RPC, чтобы дать другой программе указание рассчитать среднюю стоимость чая в Китае и вернуть результат. Удаленным вызовом процедуры этот механизм называется потому, что не имеет значения, функционирует ли "другая программа" на том же компьютере, на соседнем, или где-то в Интернете.

RPC-механизмы — это потенциальная угроза безопасности, поскольку их предназначение — позволить компьютерам, находящимся где-то в сети, давать данному компьютеру указания выполнить те или иные действия. Как только обнаруживается брешь в программе, разрешающей использование RPC-механизма, у любого, кто располагает подключенным к сети компьютером, появляется возможность использовать эту брешь, чтобы заставить уязвимый компьютер выполнить какие-либо действия. К сожалению, пользователи Windows не могут заблокировать RPC-механизм, так как Windows использует его, даже если компьютер не подключен к сети. Многие сервисы Windows устроены именно так. В некоторых случаях можно блокировать RPC-порт на межсетевом экране, но Windows так широко использует RPC-механизмы в основных функциях, что подобная блокировка не всегда возможна. Удивительно, но некоторые из наиболее серьезных уязвимостей в Windows Server 2003 (см. Таб.1) — следствие брешей в самих RPC-функциях Windows, а не в приложениях, которые их используют. Самый распространенный способ использовать уязвимость, связанную с RPC-механизмом — атаковать сервис, использующий RPC, а не сам RPC-механизм.

Важно отметить, что RPC-механизмы не всегда необходимы, отчего становится еще непонятнее, почему Microsoft так широко их использует. Предположим, требуется создать web-сайт, используя два сервера. Один сервер будет работать в качестве сервера базы данных, второй — в качестве web-сервера.
В этом случае серверу базы данных необходимо использовать RPC, потому что web-сервер находится на отдельном компьютере и должен иметь возможность доступа к серверу базы данных через сетевое подключение. (Даже в этом случае следует сконфигурировать сервер базы данных так, чтобы он "слушал" только данный web-сервер, но не другие компьютеры). Если же и сервер базы данных, и web-сервер функционируют на одном компьютере, использование RPC-механизмов на сервере базы данных не только не обязательно, но и нежелательно. Web-сервер должен иметь прямой доступ к серверу базы данных, потому что они оба функционируют на одном компьютере. Ни технических, ни логических причин подключать к сети сервер базы данных нет, поскольку такое подключение создает лишнюю угрозу безопасности.

Вопрос о серверах баз данных поднят из-за того, что сетевой червь Slammer, один из самых опасных червей, когда-либо существовавших в Интернете, использовал на редкость неуместное применение RPC-подобных сетевых соединений, реализованное Microsoft. За короткое время Slammer заразил так много систем, что Интернет практически перестал функционировать.

Сетевой червь Slammer вызвал хаос, использовав две бреши в Microsoft SQL Server, который является сервером клиент-серверной базы данных SQL-типа. Одна брешь — это самая бесполезная функция Microsoft SQL Server, позволяющая одновременно запустить несколько копий сервера базы данных на одном компьютере. Почему эта функция бесполезна? Если вы незнакомы с работой серверов баз данных, представьте это себе следующим образом. В обычных условиях бессмысленно запускать несколько копий сервера базы данных на одном компьютере, потому что одна копия — это все, что нужно, даже если ее использует множество разных приложений. Потребность в одновременном запуске нескольких серверов баз данных на одном компьютере также вероятна, как потребность в одновременном запуске двух копий Windows XP на одном компьютере. Несколько копий сервера базы данных запускаются не по ошибке исключительно редко, да и то лишь в высокопроизводительных приложениях или для тестирования и разработки4.



Кажется, мы поняли, почему Microsoft решила установить по умолчанию именно этот режим функционирования SQL Server. Многие сторонние приложения используют процессор SQL Server по умолчанию. Если бы на компьютере могла функционировать только одна копия SQL Server, то Microsoft пришлось бы разработать удобные средства, позволяющие программе инсталляции обнаружить установленный и функционирующий SQL Server, а затем обеспечить удобный способ инсталляции, интеграции и администрирования особых требований сторонних приложений в своей собственной базе данных и в таблицах, функционирующих на данном сервере. Это очень элегантное решение, минимизирующее используемые ресурсы, поскольку всегда требуется только одна копия SQL Server. Но такой подход потребовал бы большой дополнительной работы со стороны Microsoft или со стороны независимых разработчиков. Намного проще реализовать решение, позволяющее сторонним приложениям не заботиться о том, инсталлирован ли SQL Server. По схеме, реализованной Microsoft, любое стороннее приложение может просто инсталлировать свою собственную копию SQL Server, не беспокоясь о том, установлен ли SQL Server на данном компьютере, какая версия SQL Server инсталлирована, как сконфигурирован существующий SQL Server. Стремясь привлечь независимых разработчиков к использованию SQL Server, Microsoft выбрала принцип наименьшего действия и разработала систему, в которой любое приложение может инсталлировать свою собственную копию SQL Server, которая не взаимодействует с другими копиями SQL Server, функционирующими на том же компьютере. Из-за этого возникла необходимость в запуске несколько копий SQL Server с задействованным RPC-механизмом, который следовало бы использовать как можно реже. Этот наименее затратный подход имел чрезвычайно пагубные последствия. Если бы Microsoft разработала SQL Server так, чтобы он функционировал как единственная копия, не подключенная по умолчанию к сети, то сетевой червь Slammer не нашел бы достаточно компьютеров с работающим SQL Server, чтобы причинить сколько-нибудь значительный ущерб.



Простой способ обеспечить одновременную работу нескольких не мешающих друг другу копий SQL Server — создать RPC-механизм, который сортирует запросы на получение данных таким образом, что, например, приложение-факс запрашивает одну копию SQL Server, а приложение-ежедневник — другую. Ситуация усложняется тем, что и средства разработки Microsoft поддерживают тот же принцип монолитности, который используется в продуктах Microsoft. Поэтому самые разные приложения — программы планирования времени, программное обеспечение для факсимильной связи, системы управления проектами — почти 200 приложений, многие из которых предназначены для настольных систем, используют неоправданно уязвимый процессор SQL Server. В результате сотни тысяч, если не миллионы, людей используют настольные приложения, зависящие от процессора SQL Server с его многочисленными разрешенными сетевыми сервисами, немалая часть которых уязвима к атакам из Интернета. Вряд ли можно придумать лучший способ устроить катастрофу.

В результате Slammer смог атаковать огромное количество компьютеров, потому что на всех процессорах SQL Server использование этих функциональных возможностей разрешено по умолчанию. Хотя SQL Server еще не интегрирован в Windows, его повсеместное использование в различных приложениях — от программного обеспечения для факсимильной связи до программ планирования времени — фактически превращает его в часть более крупной монолитной системы, что открывает возможность такой организации атаки, которая характерна для монолитной системы. К сожалению, весьма вероятно, что SQL Server будет тесно интегрирован в File System WinFS, новую перспективную файловую систему Windows, первоначально предназначавшуюся для Longhorn, операционной системы нового поколения. Горячим сторонникам идеи интеграции SQL Server в операционную систему следует помнить об истории с сетевым червем Slammer.


Возможная доступность


Данный показатель учитывает меры, которые необходимо принять для получения доступа к компьютеру с целью использовать уязвимости в системе защиты. Обычно такие меры попадают в одну из перечисленных ниже категорий. На практике реальный порядок этих категорий может меняться, но приведенный список может оказаться удобным ориентиром. Кроме того, следует заметить, что существует несколько экзотических сложных случаев, которые в приведенном списке не рассматриваются. Например, закрытая программной коррекцией брешь в Windows Server 2003 сама по себе была не очень доступна, но она позволяла злоумышленнику сделать систему незащищенной перед серьезными угрозами. То есть это было одно из звеньев в цепочке уязвимостей. Категории в списке перечислены в порядке возрастания их серьезности.

Необходим физический доступ к компьютеру, но не требуется наличия действующей учетной записи пользователя. Необходим физический доступ к компьютеру и требуется действующая учетная запись пользователя. Необходима действующая учетная запись пользователя, но не нужен физический доступ к атакуемому компьютеру. Достаточно доступа по локальной сети (из корпоративной сети компании). Необходима действующая учетная запись пользователя, но не нужен физический доступ к атакуемому компьютеру. Атакуемый компьютер доступен через Интернет с удаленного компьютера. Можно использовать брешь удаленно, через Интернет, не имея действующей учетной записи пользователя на атакуемом компьютере, но невозможно достичь бреши напрямую. Существует еще один барьер, например, маршрутизатор или межсетевой экран. Для этой категории трудно найти надлежащее место при перечислении по уровню серьезности, поскольку правильно сконфигурированный межсетевой экран может обеспечить стопро-центную защиту, но не всегда. Плохо сконфигурированный межсетевой экран может вообще не обеспечивать никакой защиты. Можно использовать брешь удаленно, через Интернет, не имея действующей учетной записи пользователя на атакуемом компьютере, но невозможно достичь бреши напрямую.
Существует еще один, более трудный для преодоления барьер. Этим барьером может быть другая программа (например, брешь существует в Microsoft SQL Server, но для ее использования необходимо внедрить элемент управления ActiveX или Javascript в web-страницу, доступную через Microsoft Internet Information Server). В некоторых случаях для получения непрямого доступа необходимо вовлечь в этот процесс пользователя. Например, придется разослать по электронной почте сообщения, которые направят пользователей на web-страницу, содержащую вредоносный элемент управления или код. Широко используется способ, когда пользователю предлагается открыть файл, вложенный в электронное письмо. Серьезность этой категории меняется в зависимости от того, насколько искусно это вовлечение замаскировано под невинное действие. Использовать брешь можно удаленно, через Интернет, не имея действующей учетной записи пользователя на атакуемом компьютере, но невозможно достичь бреши напрямую. Тем не менее, брешь используется косвенно, но автоматически. Например, брешь в операционной системе Windows используется немедленно и автоматически, как только пользователь открывает электронное письмо с помощью программы Outlook. Использовать брешь можно удаленно, через Интернет, просто отправив через сеть информацию на атакуемый компьютер. Например, уязвимость типа "отказ в обслуживании" (DoS) можно использовать просто отправив специальные сетевые пакеты на атакуемый web-сайт, что сделает этот web-сайт недоступным для других пользователей Интернета.


Возможность использования


Этот показатель учитывает технические трудности, которые необходимо преодолеть, чтобы использовать брешь в защите. Обычно эти трудности попадают в одну из перечисленных ниже категорий. Категории перечислены в порядке возрастания их серьезности (на практике реальный порядок этих категорий может меняться, но приведенный список может оказаться удобным ориентиром).

Брешь существует, но еще не обнаружена. Для использования этой бреши необходимы либо исключительная компетентность, либо счастливый случай. Для использования бреши необходимы высокая квалификация в программировании и глубокое знание операционной системы, но о существовании этой бреши известно недостаточно широко, из-за чего маловероятно, что ее используют многие нарушители. О существовании бреши известно, и для ее использования необходимы высокая квалификация в программировании и глубокое понимание того, как функционируют атакуемые программное обеспечение и операционная система. Для использования бреши необходима высокая квалификация в программировании, но уже создан вирус, троянская программа или сетевой червь, которые могут служить основой для атаки. Программисту требуется только модифицировать этот код, чтобы использовать новую брешь или сделать данный вирус более опасным. Для создания кода, использующего брешь, необходима высокая квалификация в программировании, но подходящий код уже существует, и достаточно средней квалификации в программировании, чтобы усовершенствовать или модифицировать этот код так, что он будет использовать существующую брешь или "будущие" бреши. Для использования бреши достаточно средней или начальной квалификации в программировании либо же элементарного знания компьютера. Не имеет значения, насколько трудно использовать брешь, поскольку вся работа по созданию средств для использования этой бреши уже проделана, а вредоносный код сделан общедоступным для его применения новичками. Кто угодно может использовать брешь, введя простой текст в командной строке или указав URL в web-навигаторе.



Возможный ущерб


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

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



Windows фокусируется на знакомом графическом интерфейсе для настольных компьютеров


Компания Microsoft считает знакомый интерфейс Windows главным аргументом5 в пользу перехода на Windows Server 2003. Цитата с web-сайта компании Microsoft: "Знакомый интерфейс Windows облегчает использование Windows Server 2003. Новые удобные мастера упрощают установку специальных ролей и выполнение обычных задач управления сервером..."

Top 10 Benefits of Windows Server 2003 — http://www.microsoft.com/windowsserver2003/evaluation/
whyupgrade/top10best.mspx (На русском языке: Десять веских оснований для перехода на Windows Server 2003 — http://www.microsoft.com/rus/windowsserver2003/whyupgrade/
top10best.mspx)

Пропагандируя такое использование, Microsoft предлагает администраторам работать с ОС Windows Server 2003 на самом сервере, зарегистрировавшись с полномочиями администратора. В результате администратор Windows становится наиболее уязвимым к брешам в системе защиты, поскольку использование уязвимых программ, таких как Internet Explorer, создает угрозы безопасности сервера.



Windows и Linux: что безопаснее?


Николас Петрели, Информационный бюллетень Jet Info

Развенчание мифов

Миф 1. Безопасность — вопрос количества: чем меньше инсталляций, тем безопаснее

Миф 2. Открытый код опасен по определению

Миф 3. Выводы на основании единственной характеристики

Архитектура Windows и архитектура Linux

Архитектура Windows

Архитектура Linux

Элементы показателя общей серьезности

Способы оценки показателей

Дополнительные соображения

Программные коррекции и уязвимости Microsoft Windows Server 2003

Программные коррекции и уязвимости Red Hat Enterprise Linux AS v.3

Результаты запросов к базе данных CERT по уязвимостям

Николас Петрели (Nicholas Petreley) работает в компьютерной индустрии почти двадцать лет. Он был внештатным автором, редактором, консультантом, преподавателем и программистом, работал исполнительным редактором в испытательном центре "InfoWorld" и главным редактором Интернет-издания "NC World Magazine".

В настоящее время Николас Петрели занимает должность аналитика по Linux в исследовательской компании Evans Data Corporation, работает в качестве обозревателя в журнале "ComputerWorld", а также пишет статьи и аналитические обзоры для Интернет-издания "LinuxWorld", основанного им в 1998 году.

Работы Николаса Петрели неоднократно отмечались различными наградами и призами.



Windows по своей архитектуре является монолитной, а не модульной системой


Монолитная система — это система, в которой большинство функций интегрировано в единый модуль. Противоположностью такой системе является система, в которой функции распределены по нескольким уровням, причем каждый уровень имеет ограниченный доступ к другим уровням.

Хотя часть недостатков Windows — "наследство" ее исходной однопользовательской архитектуры, другие ее недостатки — прямое следствие обдуманных проектных решений, таких как монолитная архитектура (интегрирование большинства функций в ядро операционной системы). Компания Microsoft фактически вытеснила web-навигатор Netscape, интегрировав Internet Explorer в свою операционную систему так тесно, что не использовать IE стало практически невозможно. Нравится это пользователю или нет, но Internet Explorer вызывается при использовании справочной системы Windows, Outlook и многих других приложений как Microsoft, так и независимых производителей. Конечно, коммерческие интересы Microsoft требуют, чтобы использование каких-либо иных продуктов, кроме Internet Explorer, было крайне затруднительным. Microsoft успешно превращает конкурирующие продукты в ненужные, интегрируя в свою операционную систему все больше и больше сервисов, предоставляемых такими продуктами. Но в результате этого подхода получается монстр из сложным образом взаимодействующих сервисов (то есть, по определению, монолитная система).

Взаимозависимости такого рода имеют два неприятных каскадных побочных эффекта. Во-первых, в монолитной системе каждая брешь в какой-либо одной части системы проявляется во всех сервисах и приложениях, зависящих от этой части системы. Интегрировав Internet Explorer в операционную систему, Microsoft создала систему, в которой любая брешь в Internet Explorer подвергает настольный компьютер с Windows угрозам, реализация которых может нарушить не только работу web-навигатора, но и весьма далеких от него объектов. Следовательно, одна-единственная брешь в Internet Explorer проявляется в бесчисленном множестве других приложений, многие из которых используют Internet Explorer неявным для пользователя образом, что дает этому пользователю ложное ощущение безопасности.


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

Проиллюстрировать это поможет простая аналогия. Представим себе идеально устроенную операционную систему, которая состоит из трех сфер: одна — в центре; вторая, большего размера, охватывает первую; а третья сфера охватывает две внутренние. Конечный пользователь "видит" только внешнюю сферу. Это уровень, где пользователь запускает приложения, например, текстовые процессоры. Текстовые процессоры используют необходимые функции, предоставляемые второй сферой, например, средства визуализации графических изображений или форматирования текста. Эта вторая сфера (ее специалисты обычно называют "пользовательскими процессами") не имеет прямого доступа к критичным частям системы. Чтобы выполнить свою работу, она должна запросить разрешение от самой внутренней сферы. Внутренняя сфера выполняет самые важные функции, поэтому имеет непосредственный доступ ко всем критичным частям системы. Она управляет дисками, памятью и всем остальным. Эта сфера называется "ядро" и является сердцем операционной системы.

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

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


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

Наконец, монолитная система нестабильна по своей природе. Когда в системе так много взаимосвязей, изменение одной из частей этой системы порождает множество угроз. Единственное изменение в системе может оказать (и обычно оказывает) каскадное воздействие на все сервисы и приложения, которые зависят от этой части системы. Именно поэтому пользователи Windows трепещут при мысли об установке программных коррекций и обновлений. Обновления, исправляющие одну часть Windows, часто нарушают работу других сервисов и приложений. В качестве иллюстрации можно привести следующий факт: для пакета обновлений Windows XP service pack 2 уже составлен постоянно растущий список случаев, когда его установка привела к выходу из строя сторонних приложений. Это естественное явление в монолитной системе — любое изменение в одной части механизма влияет на весь механизм и на все приложения, которые зависят от этого механизма.


Windows только недавно эволюционировала от однопользовательской модели к многопользовательской


Критики Linux любят повторять, что Linux — это "устаревшая" технология. Ирония же заключается в следующем: одна из самых больших проблем Windows в том, что именно этой операционной системе никак не удается избавиться от своей "устаревшей" однопользовательской архитектуры.

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

Операционная система Windows XP стала первой версией Windows, в которой проявились существенные результаты усилий по изолированию пользователей от системы, так что в Windows XP каждый пользователь имеет свои собственные личные файлы и ограниченные системные полномочия. Но из-за этого многие Windows-приложения, разработанные для предыдущих версий, перестали функционировать, поскольку раньше они могли получать доступ и модифицировать программы и файлы, доступ к которым теперь разрешен только администратору. Именно поэтому в Windows XP предусмотрен режим совместимости, то есть режим, который позволяет программам функционировать так, будто они работают в прежней незащищенной однопользовательской среде. Кроме того, именно по этой причине каждая новая версия Windows несет в себе угрозу отказа приложений, работавших в предыдущих версиях. Поскольку Microsoft вынуждена модифицировать Windows, чтобы она "вела себя" как многопользовательская система, новые ограничения выводят из строя приложения, которые функционировали при отсутствии этих ограничений.

Windows XP — это прогресс, но и Windows XP нельзя назвать настоящей многопользовательской системой.
Например, Windows XP поддерживает функцию, которую Microsoft называет "Fast User Switching" (быстрое переключение пользователей), она же позволяет двум и более пользователям входить в систему Windows XP на одном компьютере в одно и то же время. Однако есть загвоздка. Это возможно тогда и только тогда, когда данный компьютер не принадлежит какому-либо домену сети Windows. Причина в том, что сеть Microsoft разработана в предположении, что пользователи входят в сеть только со своего собственного компьютера. Microsoft либо не может, либо не желает внести необходимые изменения в операционную систему и "конструкцию" сети, чтобы адаптировать этот сценарий к возможностям Windows XP.

Windows Server 2003 — это следующее приближение к настоящей многопользовательской системе, но даже в Windows Server 2003 не удалось ликвидировать все бреши в системе защиты, унаследованные от однопользовательской системы. Именно поэтому в Windows Server 2003 пришлось отключить использование по умолчанию многих функций web-навигатора (например, ActiveX, написание сценариев и др.). Если бы Microsoft перестроила эти функции для работы в безопасном и изолированном режиме в настоящей многопользовательской среде, они не создавали бы серьезных угроз, перед которыми по-прежнему беззащитна Windows.