общий хостинг
6 статей с этим тегом
Несанкционированный доступ к некоторым веб-серверам ConoHa WING (GMO Internet) (426 аккаунтов): затронуты данные в областях веб-серверов клиентов, что делать владельцам сайтов уже сегодня
20 сентября 2026 года GMO Internet, Inc. объявила, что на некоторых хостинг-серверах (веб-серверах) её сервиса аренды хостинга ConoHa WING третья сторона получила несанкционированный доступ к областям веб-серверов некоторых клиентов и установила вредоносную программу. Затронуты 426 аккаунтов, а речь идёт о «данных, хранящихся в областях веб-серверов клиентов». Доступ и установка начались 3 сентября; компания обнаружила их 16 сентября, а 18 сентября установила причину и масштаб и удалила программы. Компания говорит, что установила причину, но не раскрыла её. По её словам, данные участников, договоров и платежей хранятся в отдельной среде и не утекли. В уведомлении не сказано, были ли похищены данные в областях веб-серверов. Затронутым клиентам писали индивидуально на зарегистрированный адрес электронной почты; те, с кем не связались, не затронуты. По состоянию на 15 октября последующего уведомления не было. Мнение этого сайта: сначала проверьте, пришло ли вам индивидуальное письмо, и если пришло, следуйте его инструкциям. Затем считайте учётные данные, хранящиеся в вашей области веб-сервера (пароль к базе данных в wp-config.php, ключи API в .env и т. д.), прочитанными посторонними и смените их, а также проверьте файлы, администраторов и запланированные задания, добавленные после 3 сентября.
Как проверить, не взломан ли ваш сайт или сервер: пошаговые проверки для виртуального хостинга, WordPress и VPS и что делать в первую очередь, если вы что-то нашли
Проверка сайта на вторжение — это внешние признаки и следы внутри. Признаки: отчёт «Security issues» (Проблемы безопасности) в Search Console, пометка «This site may be hacked» (Этот сайт может быть взломан) в поиске, уведомление от хостинга, незнакомые администраторы, перенаправления только на мобильных или только из поиска. Следы: администраторы, изменённые файлы ядра (wp core verify-checksums), история входов, authorized_keys, cron, прослушиваемые порты, недавно изменённые файлы. Позиция этого сайта: если вы ничего не нашли, это не доказывает, что всё чисто. Если нашли, сохраните улики до очистки, смените все учётные данные с чистого устройства, восстановитесь из резервной копии, сделанной до вторжения, или пересоберите сервер, закройте точку входа и только потом запрашивайте проверку.
Если взломали вашего хостинг-провайдера: что делать клиентам
Взлом на стороне провайдера нельзя заблокировать настройками клиента, поэтому защита смещается от предотвращения к ограничению того, что можно потерять. Результаты расследования от 10 сентября установили самое важное: несанкционированный доступ к системе управления продажами происходил в период с апреля 2023 по март 2026 года, число затронутых аккаунтов хостинга выросло с 583 до 951, а часть начальных паролей не была хеширована. Позиция сайта: считайте всё на виртуальном хостинге доступным для чтения, выносите секреты, учётные данные и резервные копии за пределы провайдера и сегодня же смените начальный пароль, если всё ещё им пользуетесь.
Оставили файл с секретом в публичной директории? Проверьте свой webroot
Всё, что в вашем webroot, любой может скачать по URL. Забытый JSON с токеном/учётными данными, .env или резервная копия означают мгновенную утечку — и если он пришёл из общего шаблона, тот же файл лежит на каждом сайте. Исправление: кладите в публичную директорию только то, чем можно публично делиться, держите секреты вне webroot с правами 600, а найдя один — проверьте каждый сайт и хост.
Случай, когда .env в Laravel был доступен публично: ошибка размещения на шаред-хостинге и как её исправить
Причина: всё приложение сидело под веб-корнем; видимым должен быть только public/. Исправление в три шага — временная блокировка через .htaccess, смена ключей, реструктуризация — затем профилактика процессом.
Как держать .env вне публичного веба на общем хостинге
Основное исправление: тело приложения вне docroot, наружу только public/. Сначала закройте доступ через .htaccess, сделайте это постоянным реструктуризацией, затем самопроверка. Взгляд этого сайта: это не оплошность одного человека, а опасная раскладка, ставшая стандартом во всей отрасли, — чините процессом, а не бдительностью. bootstrap-redirect лучше симлинка.