Когда настраиваешь hreflang для Казахстана, первый инстинкт — вписать KZ. Это код страны по ISO 3166-1. Код языка — из другого стандарта, ISO 639-1, и для казахского он kk. Для армянского — hy, для грузинского — ka, для таджикского — tg. Ни один не совпадает с кодом страны.

Путаница возникает потому что коды похожи: KZ и kk, AM и hy, GE и ka. Это главная ловушка при настройке hreflang, переключателя языков и передаче локали в платёжные системы.

«Казахский» или «Kazakh» в меню выглядит так же странно, как если бы в английском интерфейсе написали «Russian» вместо «Русский».

Редакционные сайты почти всегда используют полные нативные названия. tengrinews.kz — «Қазақша / Русский / English», khovar.tj — «Тоҷикӣ / Русский / English», armenpress.am — «Հայերեն» рядом с иконкой глобуса. Короткие коды (2–3 символа) оправданы только там где мало места: панели управления, мобильные меню, компактные SaaS-интерфейсы.

Казахский. Разработчик без казахского набивает в коде К вместо Қ — просто потому что Қ на русской клавиатуре нет. В переключателе появляется «Казакша» вместо «Қазақша». Выглядит как опечатка, а технически — другая строка: поиск по сайту сломается, сортировка поедет. Аббревиатура «КЗ» — по той же причине неправильная, правильно «ҚЗ».

«Қазақша» означает «по-казахски» — разговорная, привычная форма. На официальных сайтах иногда пишут «Қазақ тілі» (казахский язык), но в меню «Қазақша» короче. Сравните: «Казак» (казак, человек) и «Қазақ» (казахский народ) — второе слово просто невозможно написать русскими буквами.

Кыргызский. Здесь нет единого стандарта даже на официальных сайтах. kabar.kg пишет «Кыр», другие правительственные ресурсы — «Кырг». Оба варианта правильны. Практический совет: выбери один и держись его во всём интерфейсе. «Кырг» чуть однозначнее, если в вашем меню несколько аббревиатур на «К» (казахский, кыргызский, русский).

И «Кыргызча», и «Кыргыз тили» — оба правильны: первый разговорнее («говорить по-кыргызски»), второй официальнее («кыргызский язык»). Для переключателя «Кыргызча» привычнее.

Армянский. Это единственный язык в списке где выбор нативного названия зависит от того где живёт аудитория — потому что армянский существует в двух вариантах с разной орфографией (Wikipedia):

Разница — в одной букве: «ե» у восточного и «է» у западного. Но словарный запас тоже различается: «самолёт» по-восточному — «ինքնաթիռ», по-западному — «օդանաւ». Сайт для Армении — Հայերեն. Для армянской диаспоры — Հայերէն. ISO-код у обоих один — hy, но ISO 639-3 разделяет: hye (восточный) и hyw (западный). Аббревиатура «ՀԱՅ» — от армянского «Հայ» (армянин): «ՀԱ» без третьей буквы как слово не читается.

Таджикский. Проблема та же что у казахского, но видна сразу: Ҷ стоит в самом названии языка. Если разработчик набьёт «ТЧ» вместо «ТҶ» — ошибка прямо в переключателе. Ҷ — это не «Ч»: звук ближе к английскому «j» в jump, что-то среднее между «дж» и мягким «ж». МИД Таджикистана на mfa.tj пишет именно «Ҷ». В слове «Тоҷикӣ» есть ещё Ӣ (долгое «и»), которой тоже нет на русской раскладке.

Грузинский. Разработчики часто пытаются сократить «ქართული» до «Geo» или «GE» — просто потому что не знают как работать с нелатинским шрифтом в интерфейсе или боятся проблем с рендерингом. Грузины мгновенно это считывают: «GE» воспринимается как иностранный технический код, не как родное слово. Мхедрули — письменность 1600 лет, созданная изолированно. «გამარჯობა» — это «здравствуйте». Пишите «ქართული» полностью, даже в компактных интерфейсах.

Локаль — это связка «язык + страна». Она определяет формат чисел и дат, символ валюты, порядок сортировки. В локали используется код языка, а не страны: kk_KZ, не kz_KZ. hy_AM, не am_AM. Та же логика что с ISO 639-1.

Коды валют — отдельный стандарт, ISO 4217. Несколько нюансов:

Узбекский so'm — официальное сокращение, пишется строчными буквами с апострофом. В интерфейсах часто используют просто «сум» или «UZS» — оба варианта приняты.

Казахстан и Россия делят телефонный код +7. Если в форме регистрации страну определяют автоматически по телефонному номеру — это сломается: +7 701 может быть и Москва, и Алматы. Запрашивайте страну отдельным полем или определяйте по IP.

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

Если подключить Google Font только с кириллическим диапазоном, армянский и грузинский текст не отобразится в нужном шрифте — браузер подставит системный fallback, и страница будет выглядеть непоследовательно. Армянский Unicode-блок — U+0530–U+058F, грузинский — U+10A0–U+10FF. Noto Sans от Google покрывает оба — подключите его как запасной шрифт для этих языков.

Большинство языков СНГ используют кириллицу, но три страны перешли на латиницу после распада СССР: Узбекистан в 1993 году, Азербайджан в 1991-м. Кириллица там ещё встречается в старых документах и у старшего поколения, но новый контент — латиница. Казахстан начал переход в 2017 году, новая орфография утверждена в 2023-м. Это уже третья смена алфавита за сто лет: арабская вязь, потом Яналиф (советская латиница в 1930-х), потом кириллица, теперь снова латиница.

Узбекскому не нужен отдельный шрифт — там стандартная латиница плюс апостроф в O'zbekcha. Большинство латинских шрифтов это покрывают. Проверьте только символ ʻ (U+02BB) — он есть не везде.

Армянский и грузинский — полностью самостоятельные системы, не связанные ни с кириллицей, ни с латиницей, ни друг с другом. Армянский алфавит создан в 405 году монахом Месропом Маштоцем для перевода Библии. Грузинское мхедрули примерно того же возраста.

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

В казахском 42 буквы — 33 стандартных плюс 9 специальных: Ә, Ғ, Қ, Ң, Ө, Ұ, Ү, Һ, І. В таджикском свои 6 дополнительных: Ғ, Ҳ, Қ, Ҷ, Ӣ, Ӯ.

Қ и К при внимательном взгляде отличаются (у Қ есть хвостик снизу) — но на русской клавиатуре Қ просто нет. Человек набирает «Казакша» вместо «Қазақша» не потому что невнимателен, а потому что нужная клавиша недоступна. Или копирует из источника где уже допущена такая замена и не замечает.

Практически важны буквы в названиях языков и аббревиатурах: Қ в «Қазақша» и «ҚЗ», Ҷ и Ӣ в «Тоҷикӣ» и «ТҶ», І в казахских словах. Если вставляете текст из внешнего источника — проверяйте. Вставьте подозрительный символ на unicode.org и сразу увидите что это за точка.

Для большинства коммерческих сайтов русский безопаснее как дефолт, особенно если аудитория старше 35 или это B2B. По переписи 2021 года казахским владеют около 80% населения, русским — около 70%, и они сильно пересекаются. Для молодёжной или государственной аудитории — казахский.

Только если вы целенаправленно работаете с армянской диаспорой в Ливане, Франции или США. Для проекта, ориентированного на Армению, достаточно восточноармянского (hye). Общий код hy технически принят для обоих вариантов.

hreflang="hy" — для восточноармянского (Армения). Для западноармянской диаспоры теоретически hyw, но это нестандартный тег, и не все краулеры его обрабатывают. Проще одна версия на hy, ориентированная на Армению.

Кириллица. Официальный документооборот и большинство сайтов всё ещё на кириллице. Новая латинская орфография утверждена в 2023 году, но массового перехода пока нет. За ситуацией следит gov.kz.

Это два независимых стандарта. ISO 3166-1 кодирует политические единицы (страны), ISO 639-1 — лингвистические (языки). Армянский получил код hy от латинизированного «Hayastan» — самоназвания Армении. Грузинский — ka от «Kartuli». Где-то коды совпадают (ru/RU, uz/UZ), где-то нет (hy/AM, ka/GE, kk/KZ). Совпадение — случайность, не правило.

29 мая 2026 года, 17:04. К прокси-серверу Multify подключились два IP-адреса из Кот-д'Ивуара. За следующие 90 секунд они перебрали почти 100 URL и получили 100 отказов.

Это типичная работа сканера уязвимостей. Не целенаправленный взлом, а автоматическая разведка. Такие сканеры работают непрерывно, обходя миллионы сайтов в поисках одного: открытого файла с ключами, паролями или конфигурацией, либо известной уязвимости в CMS. Неважно на чём стоит сайт — WordPress, Drupal, Joomla или самописный движок. Сканер проверяет всё подряд по стандартному словарю.

Multify как обратный прокси принимает весь входящий трафик на себя. Сканер стучится в инфраструктуру Multify, а не напрямую к сайту клиента. Защита прокси — это и есть защита клиентских сайтов.

Вот список из реального лога:

`` /.env /.env.production /.env.local /.env.bak /wp-config.php /config/database.php /config/secrets.yml /azure-credentials.json /gcp-credentials.json /private.key /database.sql /dump.sql ``

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

Переменные окружения — файлы .env и их варианты. В них разработчики хранят ключи API, пароли к базам данных, токены платёжных систем. Один такой файл даёт атакующему полный доступ к инфраструктуре без каких-либо следов взлома. По данным GitGuardian, в 2024 году секреты в публичных репозиториях обнаруживались более 12 миллионов раз, .env в тройке самых частых. Разработчик добавляет файл в .gitignore, но на сервере после деплоя он остаётся в публичной директории, и никто не проверяет.

Конфиги CMS и фреймворков — wp-config.php (WordPress), конфиги Joomla, Drupal, файлы Laravel, Symfony, Rails. Сканер не знает, на чём написан сайт, поэтому проверяет все популярные варианты подряд.

Облачные ключи — gcp-credentials.json, azure-credentials.json, service-account.json, terraform.tfvars. Попадание означает доступ к облачному аккаунту со всеми данными и потенциальными счетами на десятки тысяч долларов.

Ключи шифрования — private.key, server.key, rails/master.key. Открытый приватный ключ позволяет расшифровать весь трафик или подделать подписи.

Логи и дампы — error.log, debug.log, database.sql, dump.sql. Логи часто содержат данные пользователей, пути к файлам, иногда пароли в открытом виде.

Конфиги инфраструктуры — nginx.conf, docker-compose.yml, web.config. Из них можно узнать внутреннюю топологию сети и найти следующую точку входа.

Уязвимости CMS — отдельная категория. Как только публикуется новый CVE, сканеры начинают проверять все сайты подряд, часто в течение нескольких часов. По данным Google Project Zero, медиана от публикации CVE до первых атак — 15 дней, но для уязвимостей с публичным PoC это время сократилось до нескольких часов. Пример, который сейчас в активной эксплуатации: CVE-2026-9082, SQL-инъекция в Drupal Core на PostgreSQL (версии 8.0 до 11.3.9). Уязвимость в том, как Drupal строит SQL-запросы через JSON:API: атакующий передаёт в параметре фильтра ключ массива с вложенным SQL, Drupal вставляет его в запрос без санитизации. Без авторизации, через обычный HTTP-запрос. Результат: выгрузка базы данных, создание admin-аккаунта, в некоторых конфигурациях выполнение произвольного кода. CVSS 9.8, критическая (для сравнения: Log4Shell, который положил половину интернета в 2021 году, получил 10.0). Патч вышел 20 мая, рабочий PoC появился на GitHub менее чем через час. 22 мая уязвимость добавили в каталог CISA Known Exploited Vulnerabilities. За первые 48 часов зафиксировано более 15 000 попыток эксплуатации на почти 6 000 сайтах в 65 странах.

Атака 29 мая была именно такой. WAF отработал по сигнатурам OWASP CRS, CrowdSec добавил оба IP в список заблокированных. Клиент об этом не узнал.

Сканер прошёлся по всем категориям сразу, за 90 секунд.

Сканер запустился с двух адресов одновременно. Современные сканеры распределяют нагрузку по нескольким IP, чтобы оставаться ниже порога простых rate-limit правил. Если защита срабатывает на «больше 10 запросов в минуту с одного IP», сканер просто делает по 5 с каждого. При этом сами IP чаще всего не имеют отношения к реальному атакующему — это арендованные VPS, взломанные серверы или ботнет-машины по всему миру. Кот-д'Ивуар здесь случайная география, а не место откуда реально работает человек.

Любопытная деталь из лога: первый запрос второго IP вернул 200 — сканер сначала проверил главную страницу, убедился что сайт живой, и только потом начал перебор. Это признак инструмента, а не случайного трафика.

WAF (Web Application Firewall) — файрвол уровня приложения. В отличие от сетевого файрвола, который смотрит на IP и порты, WAF читает содержимое HTTP-запроса: URL, заголовки, тело. Он анализирует каждый запрос до того, как тот доходит до сайта.

Основа правил — OWASP Core Rule Set (CRS), открытый набор сигнатур атак, который поддерживает некоммерческий фонд OWASP. CRS покрывает перебор файлов конфигурации, SQL-инъекции, XSS и другие распространённые векторы. Запросы к .env, .sql, .key, wp-config.php и десяткам других расширений блокируются сразу. WAF не знает, существует ли файл на сервере — он блокирует по имени запроса, и сканер получает отказ до того, как успевает что-либо узнать.

CrowdSec — открытый движок поведенческого анализа. WAF работает с каждым запросом отдельно, CrowdSec смотрит на последовательность: что именно запрашивает этот IP на протяжении последних минут.

Один запрос к .env может быть ошибкой в ссылке. Десять запросов к .env, .env.production, .env.local, .envrc за 30 секунд — это уже не пользователь. CrowdSec распознаёт этот паттерн по сценариям (поведенческим правилам) и блокирует IP. Заблокированные адреса попадают в общую базу угроз, которой пользуются тысячи серверов по всему миру. Сканер, засечённый на одном сайте, сразу становится нежелательным гостем везде.

Сканер отработал стандартный словарь за полторы минуты и ушёл ни с чем. Сайт клиента не получил ни одного вредоносного запроса.

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

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

Если сайт клиента работает на Drupal с PostgreSQL — WAF на уровне прокси блокирует характерные паттерны запросов: сложные filter-параметры к /jsonapi, запросы к /user/login?_format=json с нестандартными телами. Сканер не добирается до сайта. Но это не замена патчу: если сайт доступен напрямую в обход прокси, защиты нет.

Современные сканеры распределяют запросы по нескольким адресам, чтобы оставаться ниже порога простых rate-limit правил. CrowdSec смотрит на поведение, а не на количество запросов с одного IP, поэтому такая техника не помогает.

Нет. WAF блокирует запросы по имени пути до того как они доходят до приложения. Сканер не знает, существует ли файл на сервере — он получает отказ на уровне прокси.

Целенаправленная атака сложнее: атакующий знает цель, использует нестандартные векторы и работает медленно, чтобы не попасть в поведенческие паттерны. WAF и CrowdSec снижают поверхность атаки, но не дают стопроцентной гарантии. Для критичных сайтов нужен penetration test и мониторинг аномалий.

Нет. Геолокация IP сканера — это геолокация машины, которую используют, а не атакующего. Блокировка по стране бессмысленна: следующая атака придёт из Бразилии, Нидерландов или России.