LINUX.ORG.RU
решено Форум — Security  

Сервер DDOSят

 ,


1

4

Приветствую всех. Все началось с этого Debian stable плохая отдача файлов
Саппорт сказал, что веб-серв подвергся dos атаке. Вчера целый день ip в бан кидали по этому методу: http://dd0s.blogspot.com/2009/10/ddos-tcpdump.html
На сервере стоит csf+ldf.

Действительно ли это ddos? Единственная проблема - это невозможность выкачать файлы, и заметно страдает загрузка изображений. А в целом веб-сервер работает норм. Если ddos, то как бороться?

ps aux | grep apache | wc -l
39
cat /proc/net/ip_conntrack | wc -l 284 
-na | grep ":80\ " | grep syn
-na | grep ":80\ " | grep SYN | wc -l
19
netstat -na | grep ":80\ " | grep SYN | sort  -u | more
tcp        0      0 91.121.208.132:80       175.209.146.204:33293   SYN_RECV   
tcp        0      1 91.121.208.132:39213    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39214    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39215    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39216    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39217    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39218    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39219    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39220    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39221    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39222    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39223    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39225    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39226    173.194.78.141:80       SYN_SENT   
tcp        0      1 91.121.208.132:39227    173.194.78.141:80       SYN_SENT


netstat -na | grep ":80\ " | wc -l
90

← OpenSuSe не позволяет изменять файлы на ntfs (права?)
Нужен совет по безопасному дублированию сообщений syslog →

для графики и файлов лучше nginx и желательно на отдельном домене, это еще выгодно и тем, что снижает потери от ограничений HTTP протокола (не более 2-х соединений на один хост). А лучше вообще на CDN куда-нибудь положить.

для DDOS как-то слабовато все равно. От адекватного DDOS нужны железки за $150k, типа Arbor. Можно у тех же qrator взять фильтрацию за 17000 в месяц, за границей дешевле, баксов от 300.

что Google Analytics говорит или какая-нибудь внешняя система сбора данных? или не установлено?

BaBL ★★★★★
()
Ответ на: комментарий от kombrig

Ну где-то 50-70к, используется для обработки запросов, посылаемых с мобильных девайсов.

Stafox
() автор топика
Ответ на: комментарий от BaBL

для графики и файлов лучше nginx и желательно на отдельном домене


Стоит принять Ваши слова, думаю так и следует сделать.
В общем, побаловался ещё немного с iptables. Потом правда в один момент, серв перестал на пинги отвечать. Пришло письмо от сапорта, что в связи с этим будут проведены работы. Пять мин в дауне, и все. Все прекратилось. Все грузится, число процессов апатча - 30. На будущее, займемся настройкой nginx.

Stafox
() автор топика
Ответ на: комментарий от kombrig

Может nginx фронтэндом к индейцу прикрутить?

Подпишусь. Если на сайте много статики - то использование nginx'а оправдано.

Плюс, нгинкс возьмет проблему медленных клиентов на себя. Не знаю как сейчас, а в 2007-2008 году было популярно послать на сайт 200-300 клиентов со скоростью канала несколько байт в секунду.

Deleted
()
Ответ на: комментарий от BaBL

это еще выгодно и тем, что снижает потери от ограничений HTTP протокола (не более 2-х соединений на один хост)

откуда такая инфа об ограничениях?

Skolotovich ★★★
()
Ответ на: комментарий от BaBL

8.1.4 последний абзац.

во первых, это «Практические соображения» т.е. чтото вроде рекомендаций, во вторых это относиться к persistent connections, в третьих все это говориться в контексте клиента, а не сервера

Skolotovich ★★★
()
Ответ на: комментарий от Skolotovich

8.1.4 последний абзац.

во первых, это «Практические соображения» т.е. чтото вроде рекомендаций, во вторых это относиться к persistent connections, в третьих все это говориться в контексте клиента, а не сервера

Именно так. ИЕ и ФФ будут долго тянуть тебе графику, если у тебя все на одном домене торчит. А если ты так мучаешь клиентов при возможности это обойти - мои соболезнования, это прямая недополученная прибыль.

BaBL ★★★★★
()
Ответ на: комментарий от BaBL

Именно так. ИЕ и ФФ будут долго тянуть тебе графику, если у тебя все на одном домене торчит.

а причем «тянуть граффику» к keep-alive?

не ну можно конечно все тянуть с сервера и через «постоянное соединение», только зачем?

http://ru.wikipedia.org/wiki/Постоянное_HTTP-соединение почитай для просветления

Skolotovich ★★★
()
Ответ на: комментарий от Skolotovich

а причем «тянуть граффику» к keep-alive?

не ну можно конечно все тянуть с сервера и через «постоянное соединение», только зачем?

Если вы пытаетесь тут самоутвердиться - вынужден вас разочаровать. Читайте про дефолтное поведение HTTP 1.1.

BaBL ★★★★★
()
Ответ на: комментарий от BaBL

Если вы пытаетесь тут самоутвердиться - вынужден вас разочаровать.

да не, просто бесит когда с умным видом несут ахинею

Читайте про дефолтное поведение HTTP 1.1.

и все таки, причем здесь рекомендации к реализации keep-alive соединения в хттп клиенте к ддосу и хттп серверу?

Skolotovich ★★★
()
Ответ на: комментарий от Skolotovich

и все таки, причем здесь рекомендации к реализации keep-alive соединения в хттп клиенте к ддосу и хттп серверу?

Сбоку пришлось, заодно. Это по контексту все поняли.

keep-alive тут никто не реализовывает, он в 1.1 по дефолту является предустановленным => имеет место быть.

BaBL ★★★★★
()

90 коннектов - фигня. Надо ставить nginx и настраивать там лимиты.

Если можете выпилить апач целиком - выпиливайте. Если не можете, тогда nginx на статику + проксирование апача для скриптов. А у самого апача количество чайлдов до 5-10 подрезать, смотря сколько ядер.

С апачем это должно было когда-нибудь случиться. Take it easy.

Vit ★★★★★
()
Ответ на: комментарий от BaBL

keep-alive тут никто не реализовывает, он в 1.1 по дефолту является предустановленным => имеет место быть.

таки да, по умолчанию, если не сказано обратного, тут признаю свою неправоту

вот только, какое это имеет отношение к серверу и ддосу, если там описаны рекомендации к реализации хттп клиента?

Skolotovich ★★★
()
Ответ на: комментарий от Skolotovich

вот только, какое это имеет отношение к серверу и ддосу, если там описаны рекомендации к реализации хттп клиента?

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

Бороться с DDOS на уровне одной машины - бесполезно. Это только в рамках шалостей школоты. Заказной DDOS может парализовать целый ДЦ, iptables не спасет.

BaBL ★★★★★
()
Ответ на: комментарий от BaBL

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

от забивания канала таки как раз может спасти шейпер, а вот от варианта с открыванием большого количества соединений защититься трудновато

вот с выкладыванием статики на другой домен можно наступить на кроссдомайн, например в случае с флешом, так что тоже не панацея

Бороться с DDOS на уровне одной машины - бесполезно. Это только в рамках шалостей школоты. Заказной DDOS может парализовать целый ДЦ, iptables не спасет.

в большинстве случаев да, бесполезно

и со слов знакомого хостера щас чаше устраивают атаки на днс, нежели на сам сайт

Skolotovich ★★★
()
Последнее исправление: Skolotovich (всего исправлений: 1)

проанализируй access.log на предмет того, что вызывает интерес коннектящейся публики. Если не хочешь париться с nginx, а лучше его все-таки поставить, то смотри в сторону mod_pagespeed.

По поводу SYN, то сам ложил сайтик на апаче с помощью своего ноута и 3Мб/с коннекта.

Так что nginx и с песней.

insider ★★★
()

Товарищ, а тебя не смущает что «много» соединений с 173.194.78.141 это беганье гугл-бота?)) А то тебе уже на 200 сотни коннектов тут nginx уже втюхивают. Например этот сайт без всяких ваших nginx-ов фронтэндовских обходится и ничО. Если так syn флуда опасаешься, можно попробовать вроде этого 


IPTABLES="$(which iptables)"

# SYN flood
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Политики
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT

# Одновременные соединения
$IPTABLES -A INPUT -i eth0 -p tcp -m multiport --dports 80 -m connlimit --connlimit-above 30 -j REJECT

# Разрешенные порты
$IPTABLES -A INPUT -i eth0 -p tcp -m multiport --dports 80 -m limit --limit 30/s --limit-burst 10 -j ACCEPT
И да, iptables в студию.

oskar0609 ★
()

netstat -na | grep ":80\ " | wc -l
90

что любопытно,

tcp 0 1 91.121.208.132:39214 173.194.78.141:80 SYN_SENT

это исходящие соединения с сервера, причем на google

так то ничего криминального не видно.

а в чем DDoS проявляется? 90 соединений на апач это явно не оно.
ботнеты от 5К хостов начинаются.

нужны логи аномальные логи апача
статистика аномальной нагрузки на сервер - какие из ресурсов исчерпались?

neomag
()

tcp 0 1 91.121.208.132:39213 173.194.78.141:80 SYN_SENT И так много раз одно и тоже. Вас что «долбит» один IP?

black_13 ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← OpenSuSe не позволяет изменять файлы на ntfs (права?)
Security
Нужен совет по безопасному дублированию сообщений syslog →