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

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

Блоги и СМИ жужжат о том, что завтра официально стартует LHC – Большой Адронный Коллайдер. И, типа, Землю ждёт большая и очень чОрная дыра. Между тем, дата запуска столь сложного устройства – довольно условный момент. Это ж вам не воздушный шарик полетел. Можно было назначить такой датой некоторое уже случившееся событие на LHC (установка детекторов, инженерные тесты и т.п.). Выбрали 10 сентября и некоторый “первый пучок”.

А вот на энергии, с которыми связывают страшилки и конец Света – на них ускоритель выйдет не вовсе не 10 сентября, а в лучшем (худшем?) случае через несколько недель. Да и то лишь в том маловероятном случае, если завтрашние мероприятия пройдут успешно. Понятно, что от хитрого физико-технического изделия можно ожидать подвоха: что-нибудь сломается.

С другой стороны, конечно, можно считать, что на “первом пуске” кто-то “нажмёт не на тот рычаг” и тут оно “как жахнет!”. Обычно так происходит в кинофильмах. Но в реальности, вряд ли всё так же просто, как в кино. Так что нужно сдвинуть срок Конца.

А вообще, про LHC нужно читать в проекте на “Элементах”, который ведёт Игорь Иванов. Или в блоге Игоря.

(Фото: interactions.org)

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

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

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

(Германская подводная лодка времён Второй Мировой)

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

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

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

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

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

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

Продолжение – в третьей части.

(Часть 1)

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

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

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

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

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

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

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

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

Якобы так, как показано на картинке ниже, будет выглядеть новая мишень для штатовского флота. Мишень имитирует двухступенчатые противокорабельные крылатые ракеты 3M54 “Клаб” (ОКБ “Новатор”; это те самые ракеты с дозвуковой маршевой ступенью и сверхзвуковой атакующей). Видимо эта же мишень пригодится для имитации других ракет, которые не слишком быстро конструируют на основе “Клаб”. Контракт в $97 млн на изготовление мишеней достался Alliant Techsystems. Собственно, картинка:

(источник картинки)

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

В понедельник – пять избранных записок в блоге dxdt.ru:

• “Касперские” и распределённые вычисления;
• Ложные цели, полезные приманки;
• Су-30МКИ в Штатах, на учениях;
• Чего боятся Штаты, часть 1;
• На суше и на море: элементы ПРО.

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

Оказывается, в терминологии продуктов “Лаборатории Касперского” то, что “срок действия ключа истекает” – это угроза безопасности (прямо так и пишут). В общем, угрожают. Кошмар. (И немедленно перешёл на конкурирующий продукт.)

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

Так, если говорить об осуществляющих собственно перехват решениях, то будут созданы и развёрнуты (или уже развёрнуты): 1) наземные комплексы, в том числе обязательно мобильные, что важно; 2) разнообразные воздушные системы, в том числе осуществляющие непрерывное патрулирование (большие самолёты строить умеют давно, осталось научиться делать их чуть более экономичными); 3) морские элементы ПРО (можно вспомнить проведённый в этом году перехват штатами собственного сверхсекретного спутника, вышедшего из строя); интересно, что появятся и системы подводного базирования, хоть это и может на первый взгляд показаться странным. Морская часть системы – ключевая, потому как большая часть поверхности Земли – это водная поверхность.

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