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

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

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

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

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

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

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

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

Безопасность веб-сайтов и окружающие эту безопасность вопросы постоянно возникают при обсуждении 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? Платная или бесплатная? Что со “стоимостью владения”? и всякие другие интересные моменты.

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

Как известно, многоязычные домены устраивают таким образом, что на клиентской стороне многоязычное имя преобразуется в допустимую к использованию в DNS “абракадабру” из ASCII-символов. Например, “бармалей.ru” кодируется в XN——80AABSUKF5A.RU. То есть, с формальной точки зрения, никакого расширения алфавита в собственно DNS не происходит, а предлагается лишь начать регистрировать “абракадабры” строго определённого вида.

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

С другой стороны, все эти мероприятия по набиванию “абракадабры” в командную строку – прямо противоречат исходным целям DNS, ради которых она создавалась. Ведь доменную систему имён придумали как раз для того, чтобы вместо численной “абракадабры” (IP-адресов) предложить пользователям-человекам удобные для запоминания, “мнемонические” адреса (компьютерам-то DNS вообще не нужна). Однако вряд ли XN——80AABSUKF5A – это удобная для запоминания строка. Так что админы оказываются вытеснены в такую область, в которой назначение DNS становится каким-то другим. Как бы даже и противоположным, ведь запомнить “XN——…” – может быть сложнее, чем IP-адрес. (Тут, конечно, ситуация выглядит ещё более забавной, если вспомнить, что админов планируют пересадить на IPv6, но это уже другая история.)

В чём причина трудностей админов? Причина простая: Интернет стал коммерческим инструментом, отсюда и новые приоритеты. В рамках “классической” DNS, скажем, вообще нет ни малейших оснований для появления новых доменов верхнего уровня общего назначения (не национальных) в дополнение к “изначальным”. Однако ж в коммерческом Интернете домены такие появляются многочисленными партиями (.NAME, .BIZ, .INFO и т.п.) – потому что они нужны маркетологам.

И, понятно, что админам никуда не деться. В своё время они, по сходным причинам, переучивались, скажем, на Windows.

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

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

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

Интернет-издание “Бизнес-центр” пишет про Top4Top и его “закрытие”:

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

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

Как говорится, до свидания, “Херня” – “Яндекс” меняет логотип на кириллический. (Если кто не помнит, то “Херня” – это старая шутка с поворотом логотипа Яndex.) Вот бы ещё до “Яндекса” наконец дошло, что пора уже корректно обрабатывать кириллические имена доменов, как это довольно давно делает Google.

Как известно, новая версия программного продукта “Лаборатории Касперского” (KIS-2009) предлагает пользователю присоединиться к сети “Kaspersky Security Network”, формально для того, чтобы отправлять в лабораторию сведения о новых вирусах. Но, судя по всему, это такой первый (или второй?) шаг на пути “преобразования” компьютеров пользователей продуктов “Касперских” в узлы распределённой вычислительной сети.

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

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

Статья про кириллические домены и “поддельный домен” РУ: “А не парагвайский ли этот домен?”

Интересно, а многие ли считают, что домен SU – умер? Почти умер?

(Напомню, в скобках, что SU – это домен Советского Союза, только переживший государство на 15 с лишним лет. Регистрация доменов .SU – до сих пор открыта, можно даже регистрировать многоязычные домены. Домены пользуются спросом, хотя, конечно, до зоны .RU, с её более чем полутора миллионами доменов, далеко.)

Так вот, жив ли домен SU?

Между прочим, нас ждёт повсеместное внедрение DNSSEC на ключевых серверах DNS в ближайшее время. И это правильно. Потому что тепершняя DNS – самое раздолье для злоумышленников: разработанная в начале 80-х система доменных имён вообще никак не защищена. Это ещё можно было понять в 80-х, когда Интернет строился на доверии сторон. Современные реалии с наличием столь незащищённой системы среди ключевых элементов Сети – не сочетаются.

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

А о том, что же такое DNSSEC – я как-нибудь напишу.