На главную -> MyLDP -> Тематический каталог -> Безопасность работы с системой Linux

---

OPSEC для пользователей, разработчиков и администраторов Linux

Оригинал: Layer 8 Linux Security: OPSEC for Linux Common Users, Developers and Systems Administrators
Автор: Лайза Кэхольд (Lisa Kachold)
Дата: июль 2009 г.
Перевод: Сергей Супрунов
Дата перевода: 09 августа 2009 г.

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

Давайте рассмотрим применимость одной стандартной методики повышения безопасности в случае использования Linux как рабочего инструмента: OPSEC.

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

"Если я могу определить диспозицию врага и в то же время скрыть собственную, тогда я могу сконцентрировать свои силы, а он должен будет разделить свои." - Сунь Цзы

Хотя мы можем и не осознавать это, поскольку своим мышлением глубоко вросли в "матрицу безопасности Linux", повсюду полно международных, национальных и местных "врагов", которые почтут за счастье "сорвать" стек TCP/IP в Linux, маниакально ухмыляясь. Если не верите мне, то чем вы можете обосновать свою позицию? Вы когда-нибудь тестировали или применяли методики оценок OPSEC (OPSEC Assessment, OA) хотя бы к чему-то из следующего списка?

OPSEC как методология была разработана во время Вьетнамской войны, когда адмирал Улисс Шарп, главнокомандующий Тихоокеанским флотом США, учредил подразделение "Фиолетовый Дракон" после того как пришёл к выводу, что обычных мер контрразведки и обеспечения безопасности самих по себе недостаточно. Был разработан и применён подход "думай как волк", то есть рассматривай свою организацию с точки зрения противника. В процессе разработки и передачи этой команде корректирующих действий был введён термин "Безопасность операций".

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

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

Модель OSI является семиуровневой абстрактной моделью, описывающей архитектуру взаимодействия объединённых в сеть компьютеров. Эти уровни располагаются один над другим, предоставляя возможность выделить на каждом из них определённые функции. Верхний, 7-й, уровень - это прикладной уровень (Application Layer, уровень приложений), описывающий методы и протоколы программных приложений.

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

Поскольку при обсуждении тем, связанных с работой сетей, обычно упоминается нумерация уровней OSI, то на проблему, возникшую по вине пользователя, могут ссылаться как на проблему 8-го уровня, подобно таким устоявшимся акронимам как PEBKAC (Permanent Error Between Keyboard And Chair, неустранимая ошибка между клавиатурой и креслом) и "Ошибка ID-Ten-T" [записанный как ID10T, термин визуально напоминает слово "идиот" - прим.перев.]

Мы можем считать, что ключи SSH (или их слабость) сами по себе не являются слишком большой проблемой безопасности. Однако прибавьте к этому пользователей с правами root, "реальные", полностью маршрутизируемые IP-адреса (работающие без NAT), отсутствие iptables или другого файрволла, отсутствие системы управления паролями или политики безопасности, а также любопытного пользователя с антиобщественными наклонностями, недовольного низкой зарплатой и вооружённого Ettercap-ом, и что - может, это всё-таки проблема?

Процесс оценки OPSEC включает в себя следующие шаги:

1. Определение критической информации

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

"Подождите!", - скажете вы. "Я всего лишь парень с ноутбуком!". Вы часто посещаете интернет-кафе? Вы пользуетесь общедоступными сетями? Вы позволяете другим подсматривать ваш логин в банковских данных через ваше плечо? Если так, OPSEC как раз для вас.

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

2. Выявление потенциальных противников

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

Если у вас не было момента, чтобы взглянуть на ваши лог-файлы и увидеть все попытки получить доступ через SSH или ftp, или "приземлиться" с серьёзными намерениями в интернет-кафе, анализируя беспроводной трафик, или поизучать вывод tcpdump, чтобы увидеть, что происходит в университетской сети, - сейчас самое время начать. Это не только китайцы и русские (утилиты типа netcat, nmap MetaSploit легко можно настроить, чтобы подделать эти адреса). Проснитесь и побродите по разным конференциям, а потом со всей строгостью задайте себе вопрос: кого следует считать конкурентами и преступниками. Это обязательный шаг в методике OPSEC. В 1990-х на северо-западном побережье Тихого океана противоборствующие системные администраторы Linux регулярно атаковали веб-серверы друг друга.

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

3. Выявление потенциальных уязвимостей

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

Если вы не выполняли поиск в Интернете, чтобы убедиться, что ваша версия Firefox не подвержена известным эксплоитам, вы не выполнили этот шаг. Если вы не знаете текущие уязвимости ваших версий OpenSSH, Apache, Java или кучи других бинарников, установленных в вашей Ubuntu или Fedora, у вас нет основы для разумного использования Linux.

Хотя я не настаиваю, чтобы каждый посещал DefCon [ежегодная "хакерская" конференция - прим.перев.], чтение её публичного веб-сайта сможет убедить вас в важности OPSEC. А ещё лучше - запишите себе BackTrack4 LiveCD и запустите несколько из предоставляемых им инструментов на своих системах.

Есть два основных способа представить сетевую модель Linux с помощью стека OSI - "нисходящий" (см. модель OSI) и "восходящий":

Большинство проблем соответствуют восьмому уровню!

4. Оценка риска

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

Протестировав SSH из внешней сети, или просканировав ваш кластер приложений J2EE с помощью IBM WatchFire AppScan, или подвергнув свой Apache 1.33/LDAP фаззингу [fuzzing, fuzz-тестирование - метод тестирования, когда приложению отправляются случайные "вредоносные" запросы с целью выявления уязвимостей - прим.перев.] из общедоступной (не использующей VLAN) публичной сети, или взломав свой собственный WEP-ключ за пять минут, вы чётко увидите, что вы, по сути, ничем не владеете, не можете гарантировать какую-либо устойчивость, и как только ваша система подвергается вторжению, ситуация кардинально меняется.

Например, это может быть момент, когда владелец iPhone или Blackberry понимает, что этот телефон, видимо, делает больше, чем планировалось, и удивляется политике включения непроверенных, непросканированных вложений в формате pdf, установленной на уровне 8/9, но без OPSEC этот момент всегда настаёт слишком поздно. Телефоны могут взаимодействовать практически со всем, имеют IP-адреса, но обычно игнорируются!

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

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

5. Определение мер противодействия

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

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

6. Оценка эффективности

Проанализируйте и оцените эффективность полученных решений, внесите соответствующие корректировки.

Эти решения могут быть весьма просты - "обёртка" (wrapper) для SSH, обновление OpenVPN (что на самом деле осуществляется элементарно), отключение выполнения скриптов в настройках браузера, отказ от использования браузера из-под учётной записи root на рабочем сервере. Они могут включать в себя единожды настроенный сервер с IPTABLES, или являться комплексным решением, таким как коммутатор приложений 7-го уровня (что для небольшой конторы, занимающейся разработкой, может оказаться дешевле, чем полная ревизия кода с целью обеспечения совместимости с PCI [PCI DSS, Payment Card Industry Data Security Standard - стандарт безопасности данных индустрии платежных карт - прим.перев.] или повторная разработка). Например, при фаззинге сервера Tomcat встроенная IDS (Intrusion Detection System, система обнаружения вторжений) или архитектурные изменения в mod_security или mod_proxy защитят от многомесячных DoS-атак.

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

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

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

Если (или когда) вы обнаружите что-то опасное на 9-м уровне (уровне управления), задокументируйте это и передайте вверх по инстанции, чтобы снять с себя ответственность. Апатия и позиция типа "отчёты о безопасности непопулярны" или "все до сих пор игнорируют это, а я что - умнее всех?", являются совершенно разрушительной практикой. При необходимости используйте справочники; безопасность - это общее дело.

Самой опасной политикой уровня 8/9 является "отгораживание" от проблем безопасности. Несколько ярких примеров такого "страусиного" поведения:

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

Полное отсутствие уязвимостей абсолютно недостижимо. Если вы работаете в вычислительном центре, который функционирует как будто полная безопасность обеспечивается и без OPSEC, или ловите себя на мысли, что здесь нет никаких рисков, это серьёзный "звоночек". Единственный реалистический подход - 100%-ная информированность. Как правило, те, кто понимает, что именно нужно защищать, имеет большие шансы защитить важную информацию, в отличие от тех, кто не представляет себе её ценность.

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

Вы можете просто получить список данных от CERT (Computer Emergency Response Team, Центр реагирования на компьютерные инциденты), связанный с вашими технологиями, будь то Cisco IOS для вашего межсетевого экрана Pix или система OpenWRT.

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

Сосредоточьтесь на том, что можно защитить, а не на том, что выявлено.

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

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

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

"А как быть с отделом обеспечения качества?" - спросите вы. "Мы являемся таким отделом и у нас нет времени на пристальные исследования". Достаточно просто прогнать ваше приложение через Wikto/Nikto или другой сканер уязвимостей.

Устанавливаете шикарную CMS на php/MySQL или другой разделяемый портал? Используете SVN? Так может этим вы просто открыли прекрасный шифрованный туннель прямо к своей системе. Наверняка вы это не узнаете, пока не выполните тестирование! Вы проверяли свою версию SugarCRM перед сборкой? Вы искали известные эксплоиты для этого инструмента с открытым кодом, прежде чем применять его?

Регулярная оценка даст вам гарантию лучшей защиты.

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

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

Об авторе

Лайза Кэхольд отвечает за безопасность и администрирование Linux-систем, является веб-мастером, обладателем сертификата CCNA (Cisco Certified Network Associate) и программистом с более чем 20-летним опытом работы в Unix/Linux. Лайза - бывший преподаватель в FreeGeek.org, представитель DesertCodeCamp, пользователь Wikipedia и заядлый участник LinuxChix. Она организовала и продвигает образовательную программу Linux Security в Phoenix Linux Users Group HackFEST Series Labs, каждую вторую субботу месяца посвящает фонду помощи слепым детям в Фениксе, штат Аризона. В 1990-х годах, после 6 полных лет администрирования новостей на UseNet, ею был зарегистрирован сайт Obnosis.com. Её самой большой гордостью является то, что она сидела на стуле самого Линуса Торвальдса во время интервью с представителями OSDL в Орегоне, в 2002 году.

---

---