Blog Меня бесит, когда сайт банят, а лезут чинить креатив. Личный разбор инфры под whitepage

[nixonnixonnixon]

​

Расскажу как коллегам, без справочного тона. За годы сборки инфраструктуры под whitepage я заметил одну вещь, которая меня до сих пор раздражает: сайт ловит отказ на ревью — и человек первым делом бежит менять креатив, переписывать оффер, перезаливать аккаунт. А причина-то под капотом. Я сам так обжигался в начале: крутишь-вертишь связку, а сайт всё равно «пахнет» — свежий домен из чёрного списка, Flexible SSL с редирект-петлёй, голый origin, который Censys находит за пять минут, и CSP с unsafe-inline, на которую любой вменяемый аудитор смотрит и сразу понимает: защита нарисована для галочки.


На мой взгляд, девять из десяти «непонятных» отказов — это не магия модерации, а банальная гигиена инфраструктуры. И хорошая новость: это чинится руками и проверяется заранее. Ниже — мой разбор по слоям: домен, DNS, Cloudflare, SSL и заголовки. Не про то, как лить. Про то, как собрать технически чистый сайт, который проходит ручную проверку и не палится сканерам.

Слой 1. Домен: я проверяю до оплаты, а не после бана​

Самая обидная ошибка, которую я видел (и пару раз сам совершал) — купить дроп с «красивой историей» и не проверить, что эту историю уже успели испортить. Тут важно понять одну вещь: блокировка в Google Safe Browsing или листинг в Spamhaus DBL наследуются вместе с доменом. То есть ты буквально платишь деньги за чужой бан и потом удивляешься, почему «новый» сайт сразу краснеет.


По моему опыту, минимальный прогон до покупки занимает минут десять и спасает кучу нервов:

• Google Safe Browsing Transparency Report — официальный публичный сервис, прямо показывает, числится ли домен небезопасным.
• VirusTotal — агрегатор примерно 70+ AV- и URL-блэклистов, удобно одним заходом.
• Spamhaus DBL плюс mxtoolbox.com/blacklists.aspx — DNS-блэклисты доменов и сводка по RBL.
• Wayback Machine — смотрю глазами, что физически крутилось на домене раньше. Иногда там такое, что сразу закрываешь вкладку.

Про TLD у меня личное мнение​

Возраст домена сам по себе не официальный критерий площадок — это надо честно держать в голове, никто публично порогов не публикует. Но вот что я наблюдаю стабильно: «дешёвые» зоны вроде .xyz, .top, .click, .work, .cyou исторически чаще светятся в спам-статистике Spamhaus. Это не запрет, но усиленный скрининг ты себе обеспечишь сам. .com, .net и национальные ccTLD под своё ГЕО (.ru, .kz, .com.tr) читаются нейтральнее. Я для себя вывел простое правило: бери TLD под географию проекта, а не географию под красивый TLD.


И ещё момент, на котором многие ленятся. Свежезарегистрированный домен я всегда прогреваю до запуска — индексация в Search Console, нормальный sitemap.xml, robots.txt, базовая выдача. Whois-приватность при этом — абсолютно нормальная штука, и это не про «анонимность». На ручной проверке гораздо важнее, чтобы домен бился с брендом в контенте, чем чтобы в whois было пусто или нет.

Слой 2. NS и DNS: место, где всё ломается сразу и больно​

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

1. DNSSEC плюс новый DNS-провайдер без переподписи. Если на домене активен DNSSEC, а ты переключил NS на провайдера, который зону не переподписал, домен начинает отдавать NXDOMAIN вообще всем резолверам. Сайт мёртв, пока не уберёшь DS-запись. Поэтому я всегда отключаю DNSSEC до смены NS и жду, пока DS уйдёт из TLD-зоны. Это самая жёсткая из «тихих» ошибок — ничего не предупреждает, просто всё гаснет.
2. Миграция без экспорта зоны. Переключил NS, забыл перенести MX/TXT/SPF/DKIM — и почта домена легла. Сначала поднимаю все записи на новом DNS, и только потом трогаю NS.

Мой рабочий порядок миграции, по которому я иду каждый раз:

• за сутки понижаю TTL записей до 300 с;
• снимаю полный экспорт зоны (BIND-файл или CSV у провайдера);
• поднимаю все записи на новом DNS до переключения;
• корректно снимаю DNSSEC и жду истечения DS;
• проверяю не «propagation checker'ом», а напрямую: dig NS domain @1.1.1.1, повторяю на 8.8.8.8 и 9.9.9.9, плюс dig +trace.

Отдельно про ожидания. Делегирование на уровне реестра обновляется быстро, но кэш резолверов держится до TTL родительской зоны — для NS это обычно сутки. Я это просто закладываю в график и не дёргаюсь, когда «у меня уже видно, а у заказчика ещё нет». Это нормально.

Слой 3. Cloudflare: оранжевое облако или не считается​

Как это настроить и проверить в Cloudflare
DNS → Records: у основной A-записи переключатель Proxy status должен гореть оранжевым облаком (Proxied), а не серым (DNS only) — так реальный IP сервера скрыт за Cloudflare, и прямой коннект к origin закрыт. SSL/TLS → Overview: режим Full (Strict) — сквозное валидное шифрование между посетителем, Cloudflare и origin. Серое облако = твой IP виден всем по DNS; оранжевое = трафик проксируется и origin спрятан.

Cloudflare для меня решает сразу две задачи — прячет origin IP и снимает SSL на edge. Но (и это важно) только если облако оранжевое, то есть proxied. Серый «DNS only» на основной A-записи означает, что твой реальный IP спокойно уходит в публичные базы — Censys, Shodan, SecurityTrails хранят историю DNS годами. И весь смысл проксирования при этом просто испаряется. Я проверяю цвет облака на боевой записи в первую очередь, потому что это самая обидная утечка из возможных.

Режим SSL/TLS — моя любимая боль​

• Flexible (браузер↔CF по HTTPS, CF↔origin по HTTP) — на мой взгляд, главное зло в дашборде. Источник бесконечных редиректов, ломает HSTS, по сути MITM до origin. Я его не использую и другим не советую.
• Full — шифрование до origin, но с любым сертом, включая самоподписанный. Уже терпимо, но не идеал.
• Full (Strict) — до origin по HTTPS с валидным сертом или Cloudflare Origin Certificate. Вот это мой рабочий дефолт, без вариантов.

Origin Certificate, кстати, выдаётся бесплатно, живёт долго (по опыту — годами) и валиден только при заходе через CF edge. То есть он сам по себе закрывает прямой доступ к origin валидным сертом — приятный побочный эффект.


Дальше по дашборду я прохожусь по чек-листу:

• Always Use HTTPS = On (301 c http на https прямо на edge);
• Automatic HTTPS Rewrites — лечит mixed content в HTML, бесплатно и без боли;
• минимальная версия TLS = 1.2, TLS 1.3 в приоритете;
• кэш: статику жму агрессивно, HTML — с коротким Edge TTL и purge на деплое.

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


А самое главное про скрытие origin: фаервол на сервере должен принимать 80/443 только с диапазонов Cloudflare. Список официальный — cloudflare.com/ips-v4 и ips-v6. Руками я его не вшиваю принципиально, обновляю по cron. Вшитый руками список однажды протухнет, и ты узнаешь об этом в самый неподходящий момент.

Слой 4. Валидный SSL/TLS: тут всё решает автоматика​

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


Что я держу в голове по этому слою:

• Бесплатные CA: Let's Encrypt и ZeroSSL (90 дней), Buypass с более длинным сроком. Выпуск — через ACME (certbot, acme.sh, lego, встроенный в Caddy).
• Срок публично доверенных сертов уже ограничен 398 днями, и в CA/B Forum принят план дальнейшего сокращения. Для меня вывод однозначный: ручное продление как практика мертво, живёт только ACME. Кто ещё продлевает руками — вы играете в лотерею.
• Слежу за SAN/CN. Классика жанра: серт на example.com, а сайт открывают по www. — и привет, варнинг.
• За Cloudflare в режиме Full (Strict) самоподписанный серт на origin даёт 525/526. Лечится Origin Cert или Let's Encrypt.
• Проверяю на SSL Labs (ssllabs.com/ssltest), целюсь в A/A+: TLS 1.2+, AEAD-шифры (AES-GCM, ChaCha20), без TLS 1.0/1.1.

Слой 5. Security-headers: где «зелёная галочка» выдаёт халтуру​

Реальный отчёт securityheaders.com: оценка A+ и зелёные HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Так выглядит правильно настроенный набор заголовков.


Сканеры вроде securityheaders.com и Mozilla Observatory — это то, на что смотрят и аудиторы, и внимательные модераторы. Мой базовый must-have, который я ставлю по умолчанию:

Заголовок	Безопасный дефолт
Strict-Transport-Security	max-age=63072000; includeSubDomains (preload — только после теста)
Content-Security-Policy	default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
X-Content-Type-Options	nosniff
Referrer-Policy	strict-origin-when-cross-origin
Permissions-Policy	geolocation=(), microphone=(), camera=()
X-Frame-Options	SAMEORIGIN (legacy, дублируется frame-ancestors)

А вот что я выкидываю как мёртвое: X-XSS-Protection, Public-Key-Pins (HPKP), Expect-CT — всё это давно deprecated. Если вижу их в чьём-то конфиге, сразу понимаю, что конфиг копировали из статьи десятилетней давности.

Две ловушки, на которых горят чаще всего​

• CSP с unsafe-inline 'unsafe-eval'. Меня это бесит отдельно: такая политика ставит сканеру зелёную галочку, но реальной защиты не даёт ни на грамм. И опытный аудитор это видит сразу — для него это красный флаг «делали для отчётности». Правильный путь, по которому я хожу сам: сначала Content-Security-Policy-Report-Only с endpoint'ом для отчётов, потом итерации, и только потом боевой режим. И не забудьте внести в whitelist реально используемую аналитику (GA, GTM, Pixel) — иначе сломаете собственный трекинг и будете долго гадать, куда делись конверсии.
• HSTS preload на новом домене. Включается одной галочкой за секунду, а снимается долго и больно. Я начинаю с короткого max-age (300–3600) и увеличиваю по мере уверенности. Спешка тут не окупается вообще никак.

Сами заголовки удобно ставить на уровне сервера (nginx/Caddy) и/или через Cloudflare Transform Rules → Modify Response Header. Я обычно комбинирую.

Что я держу в голове как итог​

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

1. Домен чист по Safe Browsing + VirusTotal + Spamhaus DBL.
2. NS мигрированы с экспортом зоны и снятым DNSSEC, проверены через dig.
3. Cloudflare proxied, Full (Strict), Always Use HTTPS, origin закрыт фаерволом на IP CF.
4. SSL валиден, A/A+ на SSL Labs, автопродление через ACME.
5. Security-headers реальные, не unsafe-inline, проверены на securityheaders.com.

И поверх всего — принцип, который для меня давно стал законом: «1 аккаунт — 1 вайт — 1 домен — 1 платёжка». Отдельная зона, отдельный CF-аккаунт или хотя бы отдельный токен, отдельный VPS/IP, свои GA/Pixel ID. По моему опыту, связки палятся не на хитрых механиках, а на мелочах: один email восстановления, один общий IP, один и тот же favicon-хэш на десяток проектов — и всё это корреллируется между собой при первой же жалобе. Изоляция скучная, но именно она спасает остальные активы, когда один уходит в бан.

---

Разборы, кейсы и апдейты по технике whitepage веду в своём канале — @MysticWizardsCashCartel

 

[Отройте гостувой]

Ну если речь про фб, можно пройти модерацию, на домен которого не существует. А зарегистрировать после. Вайтом сделать белую страницу. Не влияет не на что.