SYN-flooding на мой веб-сервак. Предотвратить. Nginx?
alexander
Трафик стал сильно хаваться. Это был syn-flooding на мой веб-сервак.
При этом dmesg выдал картинко:
[30942.485594] possible SYN flooding on port 80. Sending cookies.
[30951.969322] TCPv6: Possible SYN flooding on port 80. Sending cookies.
[30960.029739] TCPv6: Possible SYN flooding on port 80. Sending cookies.
[30966.058466] TCPv6: Possible SYN flooding on port 80. Sending cookies.
[31003.499854] possible SYN flooding on port 80. Sending cookies.
Я тут добавил директивы limit для сервака, а потом вдруг возникла идея
nginx. Почитал как его хвалят. Если он такой хороший, то что его не
используют многие для своих нужд, например debian.org? :( Есть ли смысл
ставить nginx? Поможет ли он уменьшить syn-flooding и вообще нагрузку
на сервер?
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100426235...@mai1.mine.nu
Denis Feklushkin
alexander <alex...@mai1.mine.nu> wrote:
> Привет.
> Трафик стал сильно хаваться. Это был syn-flooding на мой веб-сервак.
> При этом dmesg выдал картинко:
>
> [30942.485594] possible SYN flooding on port 80. Sending cookies.
> [30951.969322] TCPv6: Possible SYN flooding on port 80. Sending cookies.
> [30960.029739] TCPv6: Possible SYN flooding on port 80. Sending cookies.
> [30966.058466] TCPv6: Possible SYN flooding on port 80. Sending cookies.
> [31003.499854] possible SYN flooding on port 80. Sending cookies.
>
> Я тут добавил директивы limit для сервака, а потом вдруг возникла идея
> nginx.
По-моему, не тот уровень. Флудить ведь не перестанут, и tcp-соекуты так и будут открываться, и в dmesg этот же текст будет писаться дальше
> Почитал как его хвалят. Если он такой хороший, то что его не
> используют многие для своих нужд, например debian.org? :( Есть ли смысл
> ставить nginx? Поможет ли он уменьшить syn-flooding и вообще нагрузку
> на сервер?
>
>
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100426230...@db.h-----g.com
alexander
Denis Feklushkin <denis.fe...@gmail.com> wrote:
> On Mon, 26 Apr 2010 23:59:00 +1100
> alexander <alex...@mai1.mine.nu> wrote:
>
> > Привет.
> > Трафик стал сильно хаваться. Это был syn-flooding на мой веб-сервак.
> > При этом dmesg выдал картинко:
> >
> > [30942.485594] possible SYN flooding on port 80. Sending cookies.
> > [30951.969322] TCPv6: Possible SYN flooding on port 80. Sending
> > cookies. [30960.029739] TCPv6: Possible SYN flooding on port 80.
> > Sending cookies. [30966.058466] TCPv6: Possible SYN flooding on
> > port 80. Sending cookies. [31003.499854] possible SYN flooding on
> > port 80. Sending cookies.
> >
> > Я тут добавил директивы limit для сервака, а потом вдруг возникла
> > идея nginx.
>
> По-моему, не тот уровень. Флудить ведь не перестанут, и tcp-соекуты
> так и будут открываться, и в dmesg этот же текст будет писаться дальше
>
> > Почитал как его хвалят. Если он такой хороший, то что его не
> > используют многие для своих нужд, например debian.org? :( Есть ли
> > смысл ставить nginx? Поможет ли он уменьшить syn-flooding и вообще
> > нагрузку на сервер?
> >
> >
>
>
ясн. ;) да я тут про nginx тут прочитал, во чо пишут гады:
"В этом примере все запросы попадающие в location / будут проксироваться
на сервер 1.2.3.4 порт 8080. Это может быть как apache, так и любой
другой http-сервер.
Однако тут есть несколько тонкостей, связанных с тем, что приложение
будет считать, что, во-первых, все запросы приходят к нему с одного
IP-адреса (что может быть расценено, например, как попытка DDoS-атаки
или подбора пароля), а во-вторых, считать, что оно запущено на хосте
1.2.3.4 и порту 8080 (соответственно, генерировать неправильные
редиректы и абсолютные ссылки). Чтобы избежать этих проблем без
необходимости переписывания приложения, мне кажется удобной следующая
конфигурация: Nginx слушает внешний интерфейс на порту 80."
Вот я и подумал что nginx еще может определять DDoS атаки ;) хыхы
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100427022...@mai1.mine.nu
Игорь Чумак
> Привет.
> Трафик стал сильно хаваться. Это был syn-flooding на мой веб-сервак.
> При этом dmesg выдал картинко:
>
> [30942.485594] possible SYN flooding on port 80. Sending cookies.
> [30951.969322] TCPv6: Possible SYN flooding on port 80. Sending cookies.
> [30960.029739] TCPv6: Possible SYN flooding on port 80. Sending cookies.
> [30966.058466] TCPv6: Possible SYN flooding on port 80. Sending cookies.
> [31003.499854] possible SYN flooding on port 80. Sending cookies.
>
> Я тут добавил директивы limit для сервака, а потом вдруг возникла идея
> nginx. Почитал как его хвалят. Если он такой хороший, то что его не
> используют многие для своих нужд, например debian.org? :( Есть ли смысл
> ставить nginx? Поможет ли он уменьшить syn-flooding и вообще нагрузку
> на сервер?
>
>
>
На порт сервиса, который нужно повалить, отсылается syn-пакет. TCP-стек
, в уверенности, что это начало нового соединения, выделяет в памяти
место, отсылает в ответ ask и ждет какое-то время стабилизации
соединения. То есть обработка каждого syn-пакета требует некоторых
ресурсов. Навалить много syn-пакетов - ресурсов в системе может не
хватить. Навалить syn-пакетов с разных адресов - не поможет ничто.
Поэтому от synflood защиты на уровне приложения нет. Надо крутить
параметры ядра (google в помощь,
http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks)
Нагрузку на сервер nginx может уменьшить. Например, некоторый запрос
обрабатывается апачем (который требует N ресурсов) за n секунд.
Результат отдается клиенту за m секунд. Если m>>n (например, канал у
клиента плохой; пусть m=n*3) . Тогда для обработки этого запроса+отдача
клиенту требуется N*n*3 ресурсов. Если между толстым апачем и клиентом
есть тонкий прокси (nginx), требующий P ресурсов - тогда на 1 запрос
потребуется N*n+P*m ресурсов. Выгодно это или нет - надо смотреть.. Если
нет запросов, которые дооолго выполняются - nginx может и не помочь
(теоретически).
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
alexander
ясна. ;) спасиб
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100427023...@mai1.mine.nu
Ivan Borzenkov
> Если нет запросов, которые дооолго выполняются - nginx может и не помочь
> (теоретически).
Такой ситуации не будет, из-за того что размер апача во много раз больше nginx
и скорость передачи до прокси намного быстрее чем до пользователя.
Так как все на порядки отличается, то получается что всегда.
---
Иван Борзенков <ivan...@list.ru>
Victor Wagner
> > alexander пишет:
> > Если нет запросов, которые дооолго выполняются - nginx может и не помочь
> > (теоретически).
>
> Такой ситуации не будет, из-за того что размер апача во много раз
> больше nginx
Ну насчет "Много больше" это еще вопрос. У меня RSS апачей (apache2 из
lenny, правда пересобранный с более другой OpenSSL) от 2,5 до 5,5Мб.
mpm - worker.
> и скорость передачи до прокси намного быстрее чем до пользователя.
И далеко не всегда критична именно скорость передачи. В очень многих
ситуациях получится что затраты времени на генерацию страницы больше,
чем на передачу.
> Так как все на порядки отличается, то получается что всегда.
Далеко не все на порядки различается.
То есть в типичном для современного web-а случае - когда все страницы на
сайте генерируются динамически, и интерпретатор того языка, на которым
они генерирются, встроен в apache (mod_php, mod_perl, mod_python) - да.
А если НЕ ВСТРАИВАТЬ языков программирования в Apache и генерировать
страницы не по факту их запроса пользователем, а по факту изменения
данных из которых они генерируются, получится что nginx как бы и не
нужен. Тем более что поддержки cgi в нем нету. А это как раз тот
случай, когда cgi эффективнее fcgi - потому что когда cgi не
запрашивают, оно ресурсов и не жрет. Совсем.
Кстати если уж использовать в качестве фронденда nginx, то не факт что в
качестве бэкэнда нужен апач. Может быть nginx-овский fastcgi всю
динамику, которую надо, обеспечит.
> ---
> Иван Борзенков <ivan...@list.ru>
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20100426184...@wagner.pp.ru