• Уменьшение отступа

    Обратная связь

    (info@ru-sfera.pw)

Защита от DDOS при помощи CloudFlare

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


X-Shar

:)
Администрация
Регистрация
03.06.2012
Сообщения
6 067
Репутация
8 173
Пользователь X-Shar разместил новый ресурс:

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

Всем привет !

Данную статью писал на ресурсе посвящённому XenForo, но там были замечания + дополню то о чём утаил забыл написать и немного переработал статью, итак:

1)Что-же такое CloudFlare (CF) и зачем нужно:


- Это бесплатный и надёжный DNS-хостинг;

- Это бесплатное кеширование сайтов и ускорение загрузки, а также снижение нагрузки на сервер;

- Это возможность опять-таки бесплатно использовать SSL на своём сайте, причём дают сертификаты от таких "грандов"...

Узнать больше об этом ресурсе...
 

X-Shar

:)
Администрация
Регистрация
03.06.2012
Сообщения
6 067
Репутация
8 173
Дополнение к статье, как реализовать рассылку не светя IP-адрес своего сервера (Полезно для форумов) ! ;)
 

X-Shar

:)
Администрация
Регистрация
03.06.2012
Сообщения
6 067
Репутация
8 173
Кто использует 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 ! ;)
 

Антоха

Уважаемый пользователь
Форумчанин
Регистрация
26.12.2012
Сообщения
2 780
Репутация
4 652
SRV-записи ведь необязательно прописывать, если не используешь джаббер сервис?
И в этой статейке говорится про DKIM-подпись и добавление её в панельке клауда. Типа для того, чтобы письма не уходили в спам. Нужно, не?
И опять же есть ли смысл вообще пользоваться smpt от яндекса к примеру, если реальный ип палится в заголовках (и кстати это не всегда).
 

virt

Просветленный
Просветленный
Регистрация
24.11.2016
Сообщения
706
Репутация
228
DKIM-подпись и добавление её в панельке клауда. Типа для того, чтобы письма не уходили в спам. Нужно, не?
Можно добавить, но я недобовляю, вроде в спам не уходят, более того если использовать SMTP от того-же яндекса, у них вроде своя подпись какая-то, т.е. не нужно самим добовлять.
и кстати это не всегда
На ксенфоротесте Ленчи как-то скрывала айпишник, я так и неопонял как, но я зато научился чистить заголовки, если свой SMTP-сервер поднять ! :)

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

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

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

Но это не бесплатно разумеется ! :(
 

Антоха

Уважаемый пользователь
Форумчанин
Регистрация
26.12.2012
Сообщения
2 780
Репутация
4 652
Дополнительная информация. Источник 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) Проверить наличие информации о хостере (так же в веб-архивах, а не только в текущей версии сайта) или использовать хостинг-гигантов, чекать которых будет крайне долгим занятием;
 
Автор темы Похожие темы Форум Ответы Дата
virt Защита от DDOS своими силами 1
Антоха Защита от DDOS своими силами 2
X-Shar Защита от DDOS своими силами 0
X-Shar Защита от DDOS своими силами 2
X-Shar Защита от DDOS своими силами 7
X-Shar Защита от DDOS своими силами 0
X-Shar Защита от DDOS своими силами 1
X-Shar Защита от DDOS своими силами 7
X-Shar Защита от DDOS своими силами 8
X-Shar Защита от DDOS своими силами 2
X-Shar Защита от DDOS своими силами 3
X-Shar Защита от DDOS своими силами 1
Верх Низ