Данный пост является продолжением вот этого исследования хабраюзера Muxto о наиболее часто встречающихся словах в статьях и комментариях Хабра. Как, впрочем, заметили многие, топ-10 и даже топ-50, полученный Muxto, не изобилует собственно ИТ-терминами, их там вообще нет: «в» (107 735), «и» (106 420), «на» (103 084), «с» (93 453), «не» (91 591), «что» (88 488) и т.д.

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

Хочу познакомить хабрапользователей, касающихся прямо или косвенно вопросов защиты информации, с практически не упоминавшимся на Хабре замечательным методическим ресурсом: “NIST Special Publications 800 Series”.

NIST – National Institute of Standards and Technology – американский национальный институт стандартизации, аналог отечественного ГосСтандарта. В его составе функционирует компетентный и имеющий серьезный вес в США центр по компьютерной безопасности – CSRC, объединяющий специалистов федеральных служб, университетов, крупнейших ИТ-компаний США. Центр публикует с начала 1990-х годов Стандарты (FIPS) и более детальные разъяснения/рекомендации (Special Publications) в области информационной безопасности. Рекомендациям (Special Publications), созданным CSRC, присваивается код 800. О них я и предлагаю поговорить подробнее.

Весьма интересный пост, опубликованный недавно на Хабре, и особенно комментарии к нему подтолкнули меня к описанию, пожалуй, единственной симметричной схемы, действительно обеспечивающей страховку от кражи базы паролей с сервера – схемы Лэмпорта («Lamport hash chain»). Алгоритм на самом деле чрезвычайно прост и предложен автором (L.Lamport) еще в 1981 году. Более того, схема в большинстве учебников уже упоминается как «устаревшая», т.к. целью ее разработки была в первую очередь защита от перехвата пароля на этапе передачи, а появившиеся позднее схемы семейства «challenge-handshake» (CHAP, CRAM) решают эту задачу гораздо более эффективно. А вот о втором интересном свойстве схемы Лэмпорта уже потихоньку забыли – она не требует конфиденциальности аутентификационных данных пользователей, хранимых на серверной стороне (свойство, обычно присущее только асимметричным схемам с сертификатам клиентов). Посмотрим, как можно достичь этого свойства с помощью одной только криптостойкой хеш-функции.

Однажды после очередной беседы в нашей компании о том, какой антивирус лучше всего справляется с обнаружением новых разновидностей вирусов, у меня появилось желание провести некое изучение по этому вопросу самостоятельно. Не спорю, вопрос не новый, и множество независимых групп проводит свои экспертизы (например, отличная подборка подобных рейтингов сведена на форуме группы Anti-Malware.ru, а также советую взглянуть на последнюю, в смысле самую свежую, картинку VirusBulletin). Однако, сильное желание состояло именно в том, чтобы провести такой анализ своими силами, тем более что на просторах Интернета существует практически готовый источник информации по этому вопросу – замечательный сервис VirusTotal.

Как это было сделано и что из этого вышло —

Разнообразие температур, наблюдающееся этой зимой, напомнило мне о проекте MyCli.me Хабраюзера aib, собирающего прогнозы погоды сразу с нескольких гидрометеорологических сайтов и позволяющего путем усреднения «в голове» повысить их точность.

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

Но мне хотелось более продолжительной и «взвешенной» оценки.

Доброго дня, коллеги!
Позволю вынести на общее обсуждение идею, которую я обдумываю уже достаточно давно.

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

Входными данными, как мне кажется, должны являться:

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

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

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

Поднявшаяся в этом топике дискуссия о криптостойкости многократного применения хеша над паролем (проскальзывавшая, кстати, и в других форумах), подтолкнула меня к этому немного математическому топику. Суть проблемы возникает из идеи многократной (1.000 и более раз) обработки пароля перед хранением каким-либо криптостойким алгоритмом (чаще всего хеш-функцией) с целью получить медленный алгоритм проверки, тем самым эффективно противостоящий brute force-у в случае перехвата или кражи злоумышленником этого значения. Как совершенно верно отметили хабрапользователи Scratch (автор первой статьи), mrThe и IlyaPodkopaev, идея не нова и ею пользуются разработчики оборудования Cisco, архиватора RAR и многие другие. Но, поскольку хеширование – операция сжимающая множество значений, возникает вполне закономерный вопрос – а не навредим ли мы стойкости системы? Попытка дать ответ на этот вопрос –

Последний год время от время в моей голове всплывает вопрос, на который я до сих пор не нашел ответа: «Как реализовать депонирование факта владения некоей электронной информацией ?». То есть постановка задачи выглядит следующим образом «пользователь системы X передает копию некоторой цифровой информации Y, которой он владеет, депонирующей стороне D с тем, чтобы в дальнейшем он имел возможность подтвердить любому третьему лицу факт того, что он владел Y в момент времени депонирования T». Цель: в основном авторское право, возможно препринты некоторых научных исследований, в принципе любая информация в оцифрованном виде (причем даже без раскрытия ее сути для D — достаточно подать собственно на депонирование криптостойкую хеш-сумму от нее).

Хотелось бы предупредить владельцев PIX/ASA (пока не грянул гром) о достаточно обширной уязвимости (DoS):
www.cisco.com/warp/public/707/cisco-sa-20090408-asa.shtml
(в той части, которая называется «Crafted TCP Packet DoS Vulnerability»).

Уязвимость вполне реальна и воспроизводима любым script-kiddie, что не может не печалить. Cкрипт, приведенный на milw0rm-е, валит (в невменяемое состояние) почти любую PIX/ASA буквально через 5-7 минут.
Подвержены влиянию открытые в интернет TCP-порты следующих служб:
— SSL VPNs
— ASDM Administrative Access
— Telnet Access
— SSH Access
— cTCP for Remote Access VPNs
— Virtual Telnet
— Virtual HTTP
— TLS Proxy for Encrypted Voice Inspection
— Cut-Through Proxy for Network Access
— TCP Intercept

Вчера fixed-версии софта стали доступны через официальный CCO, до этого с момента опубликования Security Advisory они были доступны только через PSIRT.

В дополнение (и подтверждение) двум недавним топикам, посвященным манипуляциям над цифрами и графиками хотелось бы привести еще парочку примеров, обнаруженных мною в ежегодном отчете по информационной безопасности «IBM Internet Security Systems X-Force® 2008 Trend & Risk Report».

Примерно год назад я озаботился журналированием всех действий наших администраторов (а их у нас 5 человек) на Cisco-девайсах.
Как известно, реализуется это на маршрутизаторах с помощью aaa accounting exec, а на PIX/ASA-х с помощью aaa accounting command, причем в обоих случаях только через протокол TACACS+.

Поиск бесплатного TACACS-сервера под Windows (!) не увенчался успехом, в результате чего была написана утилита, которую я и хочу представить Cisco-водам: tacomacc.narod.ru
Подробности настройки сервера и устройств на взаимодействие с ним приведены там же на страничке. Опыт эксплуатации — 1 год на сети из 120 разношерстных устройств (от 1750 до 5350 + PIX-ы/ASA-ы).

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

Сразу упомяну альтернативные пути:
«родные» исходники от Cisco: ods.com.ua/win/rus/net-tech/c_ios/tacacs.html
и клоны от них: en.wikipedia.org/wiki/TACACS

Регулярно сталкиваюсь с проблемой вспомнить, в какой последовательности
идет обработка пакета в Cisco, соответственно также регулярно ищу сей документ.

Может быть будет полезен кому-то кроме меня:

Пакет Inside−to−Outside

1. if IPSec then check input access list
2. decryption − for CET (Cisco EncryptionTechnology) or IPSec
3. check input access list
4. check input rate limits
5. input accounting
6. policy routing
7. routing
8. redirect to web cache
9. NAT inside to outside (local to global translation)
10. crypto (check map and mark for encryption)
11. check output access list
12. inspect (Context−based Access Control (CBAC))
13. TCP intercept
14. encryption
15. queueing

Пакет Outside−to−Inside

1. if IPSec then check input access list
2. decryption − for CET or IPSec
3. check input access list
4. check input rate limits
5. input accounting
6. NAT outside to inside (global to local translation)
7. policy routing
8. routing
9. redirect to web cache
10. crypto (check map and mark for encryption)
11. check output access list
12. inspect CBAC
13. TCP intercept
14. encryption
15. queueing

Извлечено из Cisco Document ID: 6209

Двое моих знакомых, задавших в течение недели вопросы примерно одинаковые по сути (примерно в духе: «А я слышал, что MD5/SHA-1 уже взломан, почему мы до сих пор их используем ?»), подтолкнули меня к написанию этой заметки, хотя основные события, описываемые ниже, произошли уже более 3 лет назад.