dxdt.blog: занимательный интернет-журнал

В реальности восстание роботов только ожидается через несколько десятков лет. В Интернете всё быстрее. Здесь роботы уже играют одну из определяющих ролей в пользовательской навигации. Думаю, понятно, что речь о программах-роботах, используемых интернетовскими поисковиками: поисковые машины служат “интерфейсом к контенту” Интернета для масс рядовых пользователей, при этом в крупнейших поисковых системах собирают информацию о веб-страницах и ранжируют её не люди, но роботы. Куда робот посоветовал, туда пользователь и отправился – вот что получается.

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

Роботы-генераторы могут как собирать тексты на заданную тему “с нуля”, так и “перефразировать” готовые тексты с тех или иных сайтов (такие вот есть “роботы-рерайтеры”). И в первом, и во втором случае используются специальные словари. Тексты по качеству, с точки зрения человека, варьируются от полной бессмыслицы до более или менее читабельной чепухи. С точки зрения других роботов, не понимающих смысла, тексты выглядят очень похожими, а обычно неотличимыми от текстов, написанных человеком. Неплохой и понятный пример подобного робогенератора текстов: “Яндекс.Рефераты” (там же есть и яндексовский генератор стихов Пушкина). Другие примеры реализаций можно в изобилии найти в Google. Например, по запросам “генератор статей” и “синонимайзер текстов“.

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

Почему работают роботы? Потому что они дешевле, чем копирайтер. Работа с роботами может быть массовой, и “на круг” прибыль больше.

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

Следующий шаг восстания роботов – генерация текстов, более или менее полезных пользователю. Это ниша всевозможных автоматических “агрегаторов новостей” и так называемых “робоСМИ”. Например, робоСМИ собирают новости и статьи с разных сайтов, сортируют собранное по базе ключевых слов (по тематике), автоматически генерируют по шаблонам анонсы и публикуют получившуюся “информационную ленту”. Часто результат не сильно хуже общего уровня массовых текстов по данной тематике в Интернете (в Рунете, если хотите). Тут ведь ещё играет важную роль общее падение уровня авторских публикаций в Сети, особенно по темам, интересным более или менее широкой аудитории – а это не обязательно “сплетни про знаменитостей”, годятся и “новости из мира гаджетов”.

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

Есть и тенденция следующего уровня: для первичного “удобрения” всё равно нужны тексты, сгенерированные людьми. При этом качество и ценность этих текстов не так уж важны: переработка и массовость – компенсируют недостатки сырья. Значит в систему, для питания роботов, требуется заманить некоторое количество человеческих авторов (точнее – “авторов”). С экономической точки зрения лучше, если заманивать тоже будут роботы. То есть программа-бот рассылает по почте приглашения потенциальным авторам, даже, возможно, ведёт переписку, с целью убедить автора зарегистрироваться на “фабрике удобрений” и “вести там авторский блог”, бесплатно, конечно. Результаты блогерства скармливаются роботам и – система работает эффективнее.

Вот так. А виной всему не развитие технологий, а “кризис ответственности” в Сети. Результатом, кстати, станет какой-нибудь новый Интернет.

Известно, что разные картиночные капчи (CAPTCHA) используют в Интернете с целью отличить просто компьютер от компьютера, управляемого человеком. Например для того, чтобы какие-то действия на сайте были доступны только человеку, а не программе-боту. Сейчас капчи стали настолько “попсовым явлением”, что то и дело появляются реализации, которые программе-боту решить проще, чем человеку.

Рассмотрим пример. На сайте народного голосования “Премии Рунета” есть капча, как бы защищающая голосовалку от накрутки. Капча выглядит так (ниже – две картинки, в масштабе 1:1 и увеличенная):

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

Между тем, с помощью настроенной программы-бота капча ломается очень быстро. Основная уязвимость капчи в том, что пикселы цифр там всегда чёрные, в фоне же чёрные пикселы не встречаются. При этом цифры выводятся в известной области изображения (одной и той же, как я понимаю) простым шрифтом, без всяких искажений. Ключевой момент алгоритма решения данной капчи: делается простой перебор масок цифр 0-9 (так сказать, из библиотеки, сгенерированных на основе того же шрифта) по изображению, с обнаружением максимально совпадающих масок. Понятно, что даже не нужно делать сегментацию – значащие пикселы уже отмечены “контрастным” цветом (RGB: 0.0.0).

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

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

Update (27/10/2008): “Премия”, наконец-то, поменяла капчу на более стойкую. Исправляются, это не может не радовать.

Занимательные новости, связанные с растущей информатизацией всех отраслей человеческой деятельности. Как пишет Wall Street Journal, в большом количестве устройств, обрабатывающих банковские карточки (имеются в виду мини-терминалы для магазинов), обнаружились “жучки”, передававшие информацию о картах “налево”.

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

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

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

Довольно часто веб-разработчики спрашивают на семинарах: зачем реально нужен Unicode в качестве единственной кодировки на русскоязычном сайте, если есть удобная и привычная Windows-1251? Тем более, мотивируют своё отрицание разработчики, что Unicode увеличивает объём передаваемых данных.

Так вот есть отличный пример необходимости Unicode: многоязычные доменные имена. Предположим, что эти имена упоминаются в тексте новости на сайте. Если сайт работает не в Unicode, а в Windows-1251, то указать имя (не картинкой) просто не получится – нет там нужных символов в таблице. На мой взгляд, уже одного этого достаточно, чтобы перейти на Unicode и следовать современным веб-стандартам.

Кстати, без “внешних” относительно DNS центров доверия – в DNSSEC смысла нет. Дело вот в чём. DNSSEC подразумевает подписывание адресной информации. Подпись должна гарантировать достоверность данных. Однако, скажем, на компьютер конечного пользователя данные из DNS поступают с сервера интернет-провайдера. Ну вот, предположим, подписал провайдер эти данные какой-то подписью – и что? Это ведь не снимает вопрос доверия провайдеру: понятно, что он мог подписать какие угодно данные какой-нибудь только что сгенерированной подписью, выдав её за подпись администратора соответствующей доменной зоны (при этом и открытые ключи провайдер может подменить).

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

Вообще у провайдеров будут хитрые проблемы с DNSSEC. Скажем, DNSSEC позволяет давать “авторитативные” ответы о том, что запрошенный адрес не существует. Это перекрывает кислород тем интернет-провайдерам, которые подменяют через DNS несуществующие адреса на свои (рекламные, информационные) страницы.

Между прочим, компьютерные чипы вполне себе изучают с помощью рентгеновских лучей (и довольно давно). Тщательно просветив микросхему, можно получить представление о её топологии, обнаружить какие-нибудь “лишние” внутренние устройства. Для чего? Например, с целью выявления “закладок” в чипах, которые планируется использовать на, скажем так, ответственных участках работы.

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

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

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

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

Несколько неожиданная параллель: отчасти по сходным причинам просто нельзя использовать CMS (системы управления контентом веб-сайтов), хотя бы часть исходного кода которых “закрыта”.

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

Как известно, DNSSEC – это технология, помогающая избавиться от основных проблем с уязвимостями в современной DNS. DNSSEC позволяет подписать цифровой подписью данные по адресации в той или иной доменной зоне. В результате участники и пользователи DNS получат возможность проверять достоверность данных об адресах сайтов. То есть, ранее данные принимались “с верой на слово” и вместо реального сайта под доменом test.ru можно было относительно легко попасть на поддельный, расположенный как бы под тем же адресом. DNSSEC позволяет проверить достоверность данных по подписи и на поддельный сайт не ходить.

Хитрости состоят в том, что DNSSEC может добавить лишнего доверия системе DNS. И в тот момент, когда раскроется очередная уязвимость в реализации криптографических протоколов, проблем может оказаться гораздо больше, потому что пользователи будут больше доверять подписанным ответам. Интересно, что OpenSSL, суперсерьёзная ошибка в которой обнаружилась весной этого года, вполне себе используется в работе серверного ПО для реализации DNSSEC (не всегда, впрочем).

Вот. Есть и другой важный момент.

DNSSEC, с криптологической точки зрения, вполне стандартная система авторизации с иерархией удостоверяющих центров. По логике развития, иерархия подписей должна бы соответствовать иерархии самой DNS. То есть подписывать ключи для конкретных зон должны авторитативные серверы (есть такие серверы, служащие источником первичной информации об адресации). А корневые серверы (грубо говоря, серверы корневого домена “.” – см. “Как работает DNS“) должны выступать “верховным центром доверия”.

Но на практике корневые серверы пока ничего в рамках DNSSEC не подписывают (хотя в ближайшее время DNSSEC там, видимо, появится). И авторитативные серверы доменов верхнего уровня также весьма редко поддерживают DNSSEC. Всё это приводит к тому, что некоторые провайдеры или регистраторы, не являясь источником авторитативной информации в данном домене верхнего уровня, начинают, тем не менее, самостоятельно подписывать зоны DNS. Вроде бы – неплохо, а с другой стороны – вводит клиентов в большое заблуждение, потому что получается, что реальные возможности “удостоверяющего центра” вовсе не соответствуют взятой им на себя ответственности.

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

“Мастерхост” со своими “иными” панелями управления – кладезь “радостей” для юзабилиста. Я как-то писал уже про исключительно оригинальный способ предоставлять доступ к логам сервера, которого придерживается “Мастерхост”: десяток кликов – и несвежие логи в вашем браузере.

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

Например, в “Мастерхост” до сих пор нельзя через SSH удалить на хостинге файлы, созданные сервером из PHP. То есть если PHP-шная CMS создала какие-то файлы во время своей работы, то удалить их “очевидным образом”, через SFTP, не получается. Нужно устанавливать на хостинг какой-нибудь файл-менеджер (PHP) и чистить дисковое пространство с помощью браузера.

Управление доменами также реализовано непонятным образом: ой как не просто найти способ сменить NS-ы, скажем.

При этом большая часть функциональности “Панели управления”, насколько удалось разобраться в этой “иной логике”, собрана в некое “Древо услуг”, где есть и список доменов, привязанных (?) к хостингу. Если кликнуть на имя домена, то вместо ожидаемого интерфейса по управлению собственно доменом возникает весьма странная страница. На ней, например, есть список, заявленный как содержащий “все характеристики домена”. При этом среди “характеристик” обозначены различные CGI-параметры, возможности по установке ПО (!), путь к каталогу для HTML-файлов и тому подобные вещи. Какое отношение эти серверные настройки имеют к домену – не понятно. Из как-то связанных с DNS параметров упоминаются только синонимы домена – и всё, несмотря на заявленные “все характеристики”. Это кошмар.

С целью экономии текстовых символов, не стану уже писать о том, как продлеваются услуги “Мастерхоста” – там прослеживается тот же подход, который выливается в посещение “сайта-магазина” и многократные клики по страничкам.

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

В продолжение недавней записки про “Касперских” – такой продукт, как Nod32 Smart Security, оказался весьма неплох. Удобный интерфейс, понятная логика. При этом по уровню замедления компьютера – “Касперские” даже и близко не стояли, Nod32 ощутимо быстрее. Рекомендую переходить.

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

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

Скажем, конечному пользователю весьма важно понимать, насколько “безопасный” (тут это несколько условный термин, понятно) веб-сайт ему нужен. Потому что одно дело – корпоративный сайт крупного банка, а другое – личная веб-страничка, посвящённая разведению сазанов в домашнем аквариуме. Да, безопасность, конечно, на первом месте. Но нужно понимать, что безопасность строится на оценках рисков, и верно эти самые риски оценивать для банка и для странички про сазанов. Дело даже не в наличии уязвимостей в конкретной CMS, а в том, интересен ли сайт профессионалам-взломщикам и сколь велик будет ущерб от нарушения работы сайта.

При составлении собственного представления о безопасности использования конкретной CMS нужно учитывать её отношения с уязвимостями. Тут есть свои важные моменты. Например, то, что сайты под некоторой CMS “Имярек” “за отчётный период” не были взломаны, никоим образом не означает, что “Имярек” сколь-нибудь надёжна и безопасна. Почему? Потому что отсутствие взломов сайтов ничего нам не говорит о безопасности CMS.

Понятно, что сайты под “Имярек” могли быть просто не интересны хакерам. Понятно, что внутри CMS “Имярек” может присутствовать шикарная уязвимость, которую обнаружат завтра. А послезавтра для этой уязвимости хакерская группа напишет бота, и через два дня все сайты под “Имярек” будут взломаны в одном потоке, автоматически. То есть оценить безопасность “Имярека” на основании “полного отсутствия взломов” – невозможно. А если нельзя оценить безопасность, то нельзя и прогнозировать риски.

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

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

Есть расхожее заблуждение, что можно “вслепую” использовать уникальную “проприетарную CMS”, разработанную специально для данного сайта небольшой дизайн-студией. Мол, “секретность” и “уникальность” внутреннего устройства такой CMS обеспечивает безопасность. В реальности же разработчики подобной CMS обычно наступают на все широко известные в кругах специалистов по взлому (и по безопасности) грабли, допуская шаблонные ошибки в архитектуре продукта. Эти самые шаблонные ошибки и станут отличным фундаментом для проведения атак даже без изучения исходного кода. Мало того, секретность исходного кода вряд ли можно обеспечить на практике: при малейшей необходимости исходники утекут. Есть много путей для такой утечки: “через хостинг”, через дыры в других программных системах, после “шаблонного взлома”. Или, скажем, исходники просто распространит создатель продукта. Главное правило таково: секретность исходного кода вообще  не добавляет безопасности системе.

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

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

Часто приходится слышать, что коммерческие CMS якобы более безопасные, так как в коммерческих компаниях дорожат имиджем и строго следят за безопасностью. Это неверное обоснование. Да, ничто не мешает коммерческой компании делать безопасный продукт и нанимать специалистов-архитекторов ПО высокой квалификации. Однако на практике коммерческие компании старательно ограждают себя условиями лицензирования от ответственности и используют низкоквалифицированных программистов (а архитекторов не используют вовсе), потому что такое поведение позволяет максимизировать прибыль при обычно небольшом числе инсталляций коммерческой CMS. Бесплатные CMS также имеют свой имидж, которым дорожат лидеры групп разработчиков. И при этом нет никаких оснований считать, что те же программисты, приложившие руку к той или иной бесплатной CMS, не работают в коммерческих компаниях над платными продуктами.

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

Эта заметка – начало серии записок про выбор CMS и про безопасность CMS. Продолжение – в следующий раз. Кстати, в продолжении: нужно ли выбирать распространённую CMS? Платная или бесплатная? Что со “стоимостью владения”? и всякие другие интересные моменты.