↑ ↓

Инструкция Защита от DDOS при помощи CloudFlare

Как защитить свой ресурс от ддос (Простой, но эффективный способ)

  1. X-Shar :)
    X-Shar
    Ответить в чате

    Администрация

    Регистрация:
    03.06.2012
    Сообщения:
    5.985
    Симпатии:
    518
    Пол:
    Мужской
    Репа:
    +1.094 / 160 / -32
    Telegram:
    Пользователь X-Shar разместил новый ресурс:

    Защита от DDOS при помощи CloudFlare - Как защитить свой ресурс от ддос (Простой, но эффективный способ)

    Узнать больше об этом ресурсе...
     
    • Мне нравится Мне нравится x 2
  2. X-Shar :)
    X-Shar
    Ответить в чате

    Администрация

    Регистрация:
    03.06.2012
    Сообщения:
    5.985
    Симпатии:
    518
    Пол:
    Мужской
    Репа:
    +1.094 / 160 / -32
    Telegram:
  3. X-Shar :)
    X-Shar
    Ответить в чате

    Администрация

    Регистрация:
    03.06.2012
    Сообщения:
    5.985
    Симпатии:
    518
    Пол:
    Мужской
    Репа:
    +1.094 / 160 / -32
    Telegram:
    Кто использует CF по этому манну, нужно ещё обязательно сделать эту настройку, ввести в консоле:
    Код:
    for i in `curl https://www.cloudflare.com/ips-v4`; do iptables -I INPUT -p tcp -s $i --dport http -j ACCEPT; done
    
    for i in `curl https://www.cloudflare.com/ips-v4`; do iptables -I INPUT -p tcp -s $i --dport https -j ACCEPT; done
    
    iptables -A INPUT -p tcp --dport http -j DROP
    
    iptables -A INPUT -p tcp --dport https -j DROP
    
    iptables-save > /etc/iptables.rules
    Это заблокирует доступ к Вашему серверу к http и https всех айпи кроме CF, это нужно в случае если атакующий узнает реальный айпишник сервера, НО помните что могут просто забить канал, поэтому сам реальный хостинг должен-быть с широким каналом, либо с защитой своей сети, как например OVH ! ;)
     
  4. Антоха Администратор
    Антоха
    Ответить в чате

    Администрация

    Регистрация:
    26.12.2012
    Сообщения:
    3.290
    Симпатии:
    11.158
    Пол:
    Мужской
    Репа:
    +11.322 / 49 / -6
    SRV-записи ведь необязательно прописывать, если не используешь джаббер сервис?
    И в этой статейке Mail.Ru почта для домена при использовании CloudFlare говорится про DKIM-подпись и добавление её в панельке клауда. Типа для того, чтобы письма не уходили в спам. Нужно, не?
    И опять же есть ли смысл вообще пользоваться smpt от яндекса к примеру, если реальный ип палится в заголовках (и кстати это не всегда).
     
  5. virt Житель форума
    virt
    Ответить в чате

    Форумчанин

    Регистрация:
    24.11.2016
    Сообщения:
    48
    Симпатии:
    6
    Пол:
    Мужской
    Репа:
    +14 / 1 / -0
    Можно добавить, но я недобовляю, вроде в спам не уходят, более того если использовать SMTP от того-же яндекса, у них вроде своя подпись какая-то, т.е. не нужно самим добовлять.
    На ксенфоротесте Ленчи как-то скрывала айпишник, я так и неопонял как, но я зато научился чистить заголовки, если свой SMTP-сервер поднять ! :)

    Вообще необходимо понимать, что на бесплатном акке можно защитится только от ддоса мощностью примерно в 10-20 Гбит, а может даже и меньше, иначе облако просто поставит заглушку и сайт будет недоступен ! :(

    Да и вообще это как дешманский вариант, лучше либо использовать в комплексе с теми провайдерами, которые фильтруют сеть, например ovh, Ростелеком и т.д.

    Либо если есть деньги воспользоваться полностью услугами антиддос хостингов, либо хостингов с уже защитой от ддос, там всё сразу будет в том-числе и защита на L7, а также помощь техподдержки в настройки защиты...

    Но это не бесплатно разумеется ! :(
     
    • Мне нравится Мне нравится x 2
  6. Антоха Администратор
    Антоха
    Ответить в чате

    Администрация

    Регистрация:
    26.12.2012
    Сообщения:
    3.290
    Симпатии:
    11.158
    Пол:
    Мужской
    Репа:
    +11.322 / 49 / -6
    Дополнительная информация. Источник damagelab.in

    По наводке Ареса, было решено рассмотреть тему сокрытости IP адреса при использовании CDN сервиса CloudFlare.
    Ни для кого не секрет, что одним из негласных преимуществ этого сервиса является еще и тот факт, что поидее реальный IP адрес веб-ресурса становиться неизвестным, что кроме самой приватности дает дополнительные преимущества типа анти ддос, невозможности пофаззить бэкенд сайта на предмет багов, (быстро) просканировать его и пр. Но все это перестает иметь значение, когда настоящий IP адрес можно все таки найти и в данном посте хотелось бы рассмотреть те случаи, при которых это возможно (и меры предосторожности во ихбежание их возникновения). Допускаю что, тут могут быть не все возможные ситуации, поэтому если у кого-то будут еще какие-то мысли, то будет интересно о них почитать в комментариях.

    Итак, основные моменты, при которых возможно получить информацию и через нее узнать реальный IP, можно разбить на следующие пункты:
    • общий кэш и другие "исторические" данные;
    • управляющие данные домена;
    • записи на dns-серверах;
    • косвенная информация о хостере;
    Оставленные данные о сайте.
    Если веб-ресурс до перехода на CloudFlare существовал до этого в "чистом" виде, то есть к нему обращались напрямую (его домен резолвился в реальный IP адрес), то вполне возможно (зависитот популярности ресурса и других некоторых факторов), что эти данные где-то сохранились. Например, существуют сервисы, которые собирают dns-историю домена, какие dns-сервера исопльзовал, какие данные эти сервера выдавали и пр., то есть можно просто посмотреть, адрес в истории (при условии, что какой-то из подобных сервисов кэшировал этот домен). Или даже можно встретить нужную инфу на устаревших каталогах рейтингов доменов, так как она устаревшая, то адрес (если он отображается) будет настоящим, но это уже дикая редкость, конечно.
    Поэтому стоит проверить возможные следы, которые были зафиксированы кем-то, если что-то найдется, то придется переходить на новый IP адрес (если вопрос приватности крайне важен, конечно).

    Управляющие данные домена.
    По большому счету это только dns-сервера, на которые делегирован домен, но это очень важный критерий, так как при переходе на cloudflare надо указывать их сервера, как превичные, но не что не мешает оставить (как бы на всякий случай) прошлые dns-сервера. А у некоторых не особо популярных регистраторов имен удаление прошлых dns - это не просто затереть прошлую инфу на новые, а отдельный процесс, то есть добавление новых не удалит старые. Надо это все иметь ввиду и удостоверяться, что при переходе остлись только dns cloudflare или на прошлых нет никаких критично важных записей, позволяющих задетектить реальный IP (об этом ниже).
    Проблема в том, что конечно при обычном резолве мы почти всегда попадем на dns cloudflare, но ничто не мешает нам напрямую запросить резолв домена у старого сервера, который может хранить старый IP (то есть реальный), или содержать еще какую-то инфу (см. ниже).

    Записи на dns-серверах.
    Даже после делегирования домена на dns cloudflare надо удостоверяться, что в импортированных записях не осталось чего-то раскрывающего реальный адрес. К таким записям можно отнести MX записи и субдомены. MX важны, так как по ним можно узнать сервер почты (у которого с наибольшей вероятностью IP будет совпадать с IP сайта), а у импортированных субдоменов (не всегда, конечно) может остаться старый IP адрес (субдомены можно получить у специальных сервисов или сбрутить самому). Выходом может служить только смена адресов субдоменов вручную и удаление MX записи или перенос почтового сервера на другой адрес.

    Косвенная информация о хостере.
    Если сайт пользуется услугами не особо крупного хостера, то узнав его, можно пройтись по доступному ему диопазону адресов, сопоставив ответы с тем, который приходит при обращении на домен (о технических деталях будет позже).
    Данные, выдающие хостера могут быть много где: в HTTP-заголовках (встрачал один раз за все время), всякие дефолтные страницы ошибок 404, 403 или 500 и пр., иногда тот, кто выдавал SSL-сертификат на домен, может быть и хостером (если сайт вообще держит 443 порт открытым), также данные о хостере могу проскочить в whois информации.
    Также стоит вспомнить, может где-то в технических топиках администрирования или обсуждения проблем работы сайта оставлялась какая-то информация, которая может помочь найти определить хостера.
    После определения хостера, детектиться его диопазон адресов, из них отбрасываются те, где закрыт 80 порт, а по оставшимся проходится скрипт, который запрашивает либо какой-то файл, уникальный для этого сата (js, css или медиа файлы), либо главную страницу, на которой смотрит в html коде кусок, который есть на главной странице сайта. Тут есть два момента - надо зарпос делать именно на 80 порт, а не на 443, если он открыт, так как 443 далеко не всегда может корректно отвечать на подобные запросы.
    Далее, если детект делается первым способом, то при получении ответа 200 или 304 или 302 (при уловии, что в HTTP-заголовке Location указан нужный нам домен) можно считать, что реальный IP найден, а во втором способе зеленым светом будет присутствие куска кода в том, который мы получили в ответе (можно не чекать на 40* и 30* ответы, так как их html-код не будет совпадать).

    Подводя итог, можно кратко выделить основные действия, которые нужно предпринять для наиболее вероятного предотвращения детекта IP адреса после перехода на cloudflare:
    1) Посмотреть кэшированные dns данные на наличие там реального IP (если есть, придется менять его);
    2) Проверить что за домен отвечают только dns cloudflare или что в остальных dns-серверах нет потенциально "опасных" записей, иначе - почистить эти сервера (или удалить их);
    3) Проверить записи уже на серверах cloudflare, и откорректировать или удалить те, которые выдают реальный IP;
    4) Проверить наличие информации о хостере (так же в веб-архивах, а не только в текущей версии сайта) или использовать хостинг-гигантов, чекать которых будет крайне долгим занятием;
     
Похожие темы:
  1. Лена Головач
    Ответов:
    2
    Просмотров:
    2.096
  2. X-Shar
    Ответов:
    6
    Просмотров:
    2.019
  3. X-Shar
    Ответов:
    7
    Просмотров:
    15.081
  4. Антоха
    Ответов:
    1
    Просмотров:
    1.118
  5. X-Shar
    Ответов:
    3
    Просмотров:
    1.862
Загрузка...

Поделиться этой страницей