Siteko — сайты, хостинг и ИИ

Рассказываю, как я на днях нашёл у себя косяк на клиенте, которому нужна была одна A-запись. Человек купил у нас только домен, DNS-серверы оставил наши, а сайт держит на своём VPS. В поддержку он пришёл с короткой просьбой: помогите добавить A-запись. Домен при этом не открывался совсем. Браузер просто не находил сервер.

Причина оказалась банальной: у домена не было зоны. В реестре записаны ns1 и ns2.siteko.net, а они на запросы по домену отвечали REFUSED. Регистрация зону не создаёт. У нас она появлялась, только когда домен добавляли сайтом на хостинг, а хостинга у клиента нет. Google, Cloudflare и Яндекс отвечали SERVFAIL, то есть для интернета домена не было. Ни сайта, ни почты, ни подтверждения в Вебмастере.

Неприятнее другое: кабинет всё это время писал «DNS обновляется» и обещал письмо, когда обновится. Обновиться было нечему. Наша проверка спрашивала публичные резолверы и считала SERVFAIL признаком «ещё не распространилось». Через 48 часов она молча останавливалась, а статус оставался прежним. Когда я полез разбираться, нашёл 29 таких доменов, 25 из них старые. При этом каждый четвёртый заказ у нас только домен, 15 из 65. Так что случай далеко не редкий.

Зону клиенту я завёл руками через полчаса после обращения. Google, Cloudflare, Яндекс и Quad9 отдали адрес почти сразу. Остальное переделали в тот же день:
• проверка смотрит в реестр и на наши DNS-серверы, а не в кэш резолверов;
• вместо вечного «обновляется» статус «Не подключён» и кнопки, что делать дальше;
• на странице домена вкладка «DNS-записи», первая запись сама заводит зону;
• домен без зоны получает заглушку с HTTPS, а не мёртвый адрес.
Заглушку включили 28 октября в 17:24, и сразу припарковалось 27 доменов.

Проверить свой домен можно за минуту. Сначала я смотрю, какие DNS-серверы записаны в реестре: whois example.com. Потом спрашиваю один из них напрямую: dig @ns1.siteko.net example.com A. Если в ответе status: REFUSED, зоны нет и ждать бесполезно. Если NOERROR и нужный IP, с DNS всё в порядке. Дальше curl -I http://example.com покажет, отвечает ли сам сервер.

Кстати, у клиента на этом всё не кончилось. DNS заработал, а сайт нет. По http сервер молчал, по https отдавал ошибку сертификата. Это уже настройка самого VPS. Мне отсюда вывод простой: домен, DNS и сервер - три разных места, и проверять их надо по очереди. Иначе можно долго ждать «распространения» того, чего нет.

Ошибка у нас была глупая, но поучительная. Теперь такой домен хотя бы открывается.

Полный разбор с командами и тем, куда вписывать A-запись:
https://blog.siteko.net/articles/kupili-tolko-domen-kak-napravit-na-svoj-server

А вы проверяете DNS-серверы домена напрямую или ждёте, пока «обновится»?

Резервный сервер для интернет-магазина — полный разбор

Рассказываю, как на прошлой неделе у меня пропал сервер интернет-магазина, который мы ведём. 21 октября утром он перестал отвечать целиком. Ни сайт, ни SSH. Когда машина вернётся, никто сказать не мог. Я поднял копию магазина на другом своём сервере, около 11:20 сайт работал там. Минут через 25 основной сервер ожил, и я вернул домен на него. Новых заказов за это время не было, сводить ничего не пришлось.

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

Второй - у записи домена стоял TTL 3600. То есть даже с готовой копией сайта часть посетителей ещё час ходила бы на мёртвый адрес. Хотя про снижение TTL у нас в блоге целая глава. У себя вот проглядел.

После этого сделали магазину резервный сервер в другом дата-центре. Допустимый простой с заказчиком договорились считать 5-10 минут. Ночью я за это время не проснусь, так что переключаться сайт должен уметь сам. Отмечу, как всё устроено:
• база реплицируется на резерв через закрытый туннель, отставание в секундах;
• картинки, около 39 ГБ, раз в минуту уходят в облачное хранилище, резерв отдаёт их оттуда;
• код выкладывается на оба сервера одной командой, а фоновые задачи работают только на основном, иначе покупатель получит два одинаковых письма;
• переключение - одна команда на резерве. Он сам меняет адрес домена в DNS, TTL теперь 60.

Дольше всего я провозился с балансировщиком. Сначала перевёл домен на облачный балансировщик провайдера. На учениях сайт при переключении лежал 13 секунд. Задача вроде как решена. Со всех наших серверов балансировщик отвечал. А утром у заказчика сайт не открылся. Проверил через ping-admin.com: не достучались Москва, Томск, Рига, Копенгаген и Нидерланды. Вернул домен на сервер напрямую, переключение переделал на DNS. Поддержка провайдера за четыре дня причину не нашла. От услуги отказались.

Вывод для меня очевидный: проверять доступность надо из чужих сетей, а не со своих серверов. Мои серверы стоят в нормальных дата-центрах, и то, что они видят сайт, ничего не говорит о покупателе с домашним интернетом. Кстати, при удалении балансировщика не забудьте убрать доверие к его IP в nginx. Иначе новый владелец адреса сможет подставлять серверу «настоящий IP» посетителя.

Автоматическое переключение у меня пока в теневом режиме. Арбитр со свидетелями в других дата-центрах только пишет в журнал, что переключил бы. И уже нашёл случай, где в бою дал бы ложную тревогу: режим обслуживания во время выкладки. Включать буду, когда разберу все его сомнения. Так спокойнее.

В целом схема получилась простая, без балансировщика. Минута на переключение вместо часа. Для магазина нормально.

А у вас есть резерв для сайта? И давно вы проверяли, что лежит в бэкапе?

PHP2Shell — полный разбор

Что проверить на своём сервере или VDS:

• обновить PHP до исправленной версии или поставить пакет дистрибутива, вышедший после 21 октября. На Debian и Ubuntu обычно хватает apt update && apt upgrade;
• перезапустить PHP-FPM или веб-сервер, иначе старый код останется в памяти процессов;
• найти остальной PHP на сервере: панель, веб-почта, phpMyAdmin, контейнеры, иногда внутри самого приложения;
• если обновиться сразу нельзя, выключить session.upload_progress.enabled в php.ini каждой версии;
• если сайт на PHP 8.1 или старше, планировать переход на новую ветку;
• проверить папки сайтов на незнакомые .php-файлы, особенно в uploads, images и cache.

Подробная хронология и технические детали — в полном разборе по ссылке в начале поста.

А вы уже обновились? И сколько мест с PHP у вас нашлось на сервере?

PHP2Shell: как мы закрывали уязвимости PHP

21 октября PHP выпустил исправления сразу для двух критических уязвимостей, CVE-2026-109618 и CVE-2026-109619. Исследователи назвали их PHP2Shell. Суть простая: отправляешь сайту специально собранный запрос и выполняешь свой код на сервере. Затронуты все версии, начиная с PHP 5.4 из 2012 года. Рассказываю, как мы закрывали это на хостинге и о чём при этом легко забыть.

Обе ошибки сидят в механизме прогресса загрузки файлов, session upload progress. Он включён по умолчанию, так что уязвима самая обычная установка. Оценка опасности 9.2 из 10. По данным Sansec, публичные эксплойты на стандартной установке пока не срабатывают, им нужна ещё ошибка в самом сайте или точно подобранная сборка PHP. Но код уже в открытом доступе. Ждать, пока его доработают, я бы не стал.

Исправленные версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для 8.1 и старше официальных релизов не будет, ветки не поддерживаются. Патчи в исходниках выложили для 7.4, 8.0 и 8.1, а дальше всё зависит от того, кто вам собирает PHP. Временная мера, которую советовали все, кто разбирал уязвимость:

session.upload_progress.enabled = Off

Она закрывает основной путь атаки, но не единственный. Обновляться всё равно надо.

По срокам вышло так. 17 октября Amazon увидел первую попытку атаки. 21 октября в 10:43 Cloudflare сообщил о первых атаках, патча ещё не было. В 17:00 вышли исправления. 22 октября в 18:32 у нас были обновлены все версии PHP на сервере хостинга. А официальное уведомление пришло через дата-центр, когда всё уже было закрыто. Это не упрёк, рассылка идёт по цепочке. Но вывод я для себя сделал простой: если ждать письма, окажешься позади тех, кто читает новости по безопасности.

На хостинге у каждого сайта своя версия PHP, от 5.2 до 8.5. Старый сайт на 5.6 уязвим так же, как новый на 8.4. Нас выручил CloudLinux: разработчики перенесли исправление во все свои сборки, включая давно не поддерживаемые. Клиенты ничего не заметили, версия та же, перезагружать ничего не пришлось.

Тут есть нюанс, на котором легко запутаться. После обновления phpinfo() показывает, например, 8.4.26, хотя исправлено в 8.4.27. Так и задумано: патч вносят в ту же сборку без смены номера. То же самое делают Debian, Ubuntu и другие дистрибутивы. Так что сканер, который ругается на «PHP 8.4.26», ещё не повод паниковать. Но и успокаиваться по номеру версии нельзя. Проверять нужно по changelog пакета:

# rpm -q --changelog alt-php84-cli | grep 109618

Больше всего времени ушло на PHP, который живёт не в сайтах. Веб-почта крутится в своём контейнере со своей версией, её обновили отдельно 23 октября, с 8.3.15 на 8.3.36. У панели управления тоже свой PHP, через него работает Roundcube. Исправленной сборки от разработчиков панели на тот момент не было, поэтому закрыли временной мерой через session.upload_progress.enabled = Off. Выйдет обновление - поставим и уберём заплатку.

Ну и неприятная находка. Пока проверяли файлы, нашли веб-шеллы на трёх сайтах клиентов. К PHP2Shell они отношения не имели: появились раньше, в июле и 18 октября, через дыры в плагинах CMS. Сайты приостановили, владельцам написали. Вывод для меня очевидный: свежий PHP не лечит сайт, который взломали раньше.

Ниже — список проверок для своего сервера или VDS.

Получить 60 дней бесплатного хостинга

Подписчикам канала

🔧 Плановые работы и сбои

Здесь первым делом пишу о плановых работах и сбоях на хостинге и серверах Siteko.

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

🎁 Клиентам — 150 ₽ на баланс

Бонус за подписку начисляется один раз.

Как получить:
1. Подключите бота уведомлений в личном кабинете, в разделе «Настройки».
2. Нажмите «Проверить подписку» — в боте или на главной странице кабинета.

🚀 Новым клиентам — 60 дней вместо 30

Если вы только выбираете хостинг, получите 60 дней бесплатного пробного периода. Для подключения воспользуйтесь ссылкой в начале поста.

Как выбрать чат-бота для сайта — полный разбор

Фраза «поставим на сайт чат-бота» у разных людей значит три разные вещи. Один имеет в виду окошко, где отвечает менеджер. Другой бота с кнопками «Узнать цену» и «Записаться». Третий нейросеть, которая отвечает своими словами. Стоят они по-разному, ломаются по-разному и решают разные задачи. Начинаю серию из пяти заметок про ИИ-консультанта на сайте, и первая как раз про это.

Чат с живым оператором может всё: договориться о скидке, разобраться в нестандартной задаче. Как по мне, он хорош там, где вопросов мало, они сложные и каждый может стать крупной сделкой. Слабое место - время. Если вопрос пришёл в 22:40, чат превращается в форму обратной связи. А на «сколько доставка» человек отвечает по 20 раз в день.

Бот на сценариях - это кнопки и дерево шагов. Для записи на приём или статуса заказа по номеру он подходит хорошо и лишнего не скажет. Но на «а если у меня дача без электричества, ваш насос подойдёт?» он ответит «Выберите пункт меню».

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

Перед выбором я бы ответил себе на пять вопросов:
какая доля вопросов повторяется. Если 70 % про доставку, сроки и наличие, оператор тратит время впустую;
кто ответит вечером. У многих сайтов заметная часть трафика после 19:00 и в выходные;
сколько у вас товаров. 10 услуг закроют кнопки, 2000 товаров уже нет;
что важнее, ответ или контакт;
кто будет бота поддерживать.

На деле выбор «бот или человек» ложный. Рабочая схема - комбинация. Бот отвечает на типовое круглосуточно, без ответа собирает контакт, а менеджер на смене может перехватить разговор.

Перед установкой задайте любому боту 10 проверочных вопросов. Вопрос, ответа на который нет нигде. Цена конкретного товара. Товар не в наличии и товар, которого у вас нет вообще. «Дайте скидку». «Хочу поговорить с человеком». И с опечатками: «скока стоит доставка до питера». Если бот хоть раз уверенно выдумал цену или условие, это не мелочь. На сайте такой ответ прочитают как обещание компании.

В полном разборе по ссылке выше — сравнение трёх видов, список того, что выяснить у сервиса, и все 10 вопросов.

А у вас на сайте что стоит: оператор, кнопки или уже ИИ?