Anti-DDoS: Конфигурирование LightHTTPD

Anti-DDoS: Конфигурирование LightHTTPD

В этой теме я хотел бы рассказать о том, как сконфигурировать сервер Lighthttpd для оптимальной производительности.
Уже из самого названия продукта видно, что этот сервер "лёгкий" - он заточен под максимальную скорость работы.
А знание конфигурации позволит оптимально настроить сервер под Ваши нужды и нагрузки.

Далее я напишу о директивах конфигурации сервера, которые прямым образом влияют на производительность.

Сужаем канал

Директива connection.kbytes-per-second позволяет ограничить скорость соединения с сервером. Это позволит дольше использовать ресурсы канала во время DDoS-атаки.
Следующий код ограничит скорость до 1 мбит/с:

Code:

connection.kbytes-per-second = 1024

По умолчанию директива равна 0, т.е. ограничения отсутствуют.
Кроме того, можно ограничить скорость соединения для определённого хоста (к примеру, если идёт http-ddos на один из сайтов на сервере):

Code:

    $HTTP["host"] == "victim.com" {
      server.kbytes-per-second = 32
    }

Помимо этого, существует плагин mod_speed.c, который позволяет регулировать скорость прямо в скриптах. Пример на php:

PHP:

 <?php
 header("X-LIGHTTPD-KBytes-per-second: 50");
 echo('Content with speed, limited to 50 kbit/s');
 ?>


Ограничиваем запросы

Для того, чтобы сессии соединения сбрасывались как можно быстрее и количество запросов в эту сессию было как можно меньше, надо регулировать keep-alive директивы. Вот значения по умолчанию:

Code:

  server.max-keep-alive-requests = 16
  server.max-keep-alive-idle = 5
  server.max-read-idle = 60
  server.max-write-idle = 360

Вы можете уменьшать их с увеличением нагрузки (например, во время DDoS-атаки), вплоть до обнуления. Первые две директивы - это соответственно максимальное количество запросов во время сессии и длительность сессии (в секундах)

Регулируем дескрипторы

Для каждой открытой, скажем, php страницы на сайте создаётся файловый дескриптор.
Если идёт атака, то файловых дескрипторов создаётся очень много, и если их количество превысит установленый лимит, сервер перестанет отвечать на запросы.
Поэтому при больших нагрузках рекомендуется увеличивать значение директивы server.max-fds. По умолчанию оно равно 1024.
Данная директива работает лишь в случае, когда lighthppd запущен под root.

Code:

server.max-fds = 4096

Количество соединений

Директива server.max-connections служит для определения максимального количества соединений сервера.
По умолчанию она равна 1024, как и server.max-fds, но рекомендуется устанавливать для неё значение, равное 1/2 или 1/3 от значения server.max-fds, поскольку не все файловые дескрипторы отвечают соединениям - многие используются для fastcgi или файлов.


Всё

Больше информации можно найти на lighttpd.net.
Удачи в Анти-ДДоСе!

(c) BECHED aka Root-access, 2009,http://ahacc.ru/forum/showthread.php?t=35#

 

Добавлю ещё пару фраз.

Баним IP-адреса

Если атака ведётся с какого-то диапазона IP-адресов или с нескольких IP-адресов, логично забанить эти адреса. Для этого воспользуемся условной конструкцией, глобальными переменными и регулярным выражением:

Code:

  $HTTP["host"] == "victim.com" {
    $HTTP["remoteip"] = "^(123\.123\.123\.[0-255])$" {
     url.access-deny = ( "" )
    }
  }

Ещё ограничиваем трафик

Вот ещё некоторые меры, которые могут помочь для экономии трафика: бан ботов по user-agent и анти-хотлинкинг.
User-Agent банится так:

Code:

  $HTTP["useragent"] =~ "libwww-perl" {
    url.access-deny = ( "" )
  }

Это конечно можно сделать и в robots.txt, но ведь бот может и не проверять этот файл, так что на уровне сервера это надёжнее.
Хотлинкинг же запрещается следующим образом:

Code:

  $HTTP["referer"] !~ "^($|http://vitim\.com)" {
    url.access-deny = (".bmp", ".jpg", ".jpeg", ".png",".ico" )
  }

Таким образом, мы запретили выкладывать на других хостах картинки с нашего сервера. Это бывает весьма полезно, когда картинок много и их постоянно воруют. Того же эффекта можно достичь при помощи .htaccess. Кстати бывали и прецеденты, когда DDoS-атака проводилась с помощью очень частого показа картинок с сервера (канал забивался).

 

Такое при ддосе встречается очень-очень редко,обычно когда идет прогрузка ехе определенного DDOS-бота,то чаще всего идут от разных айпи!

А если например идет DNS!(в Black Energy Ddos bot-самый распространенный ддос-бот в паблике есть возможность атаки на DNS сервера)
Что можно применить?

 

Конечно не часто, но всё бывает, особенно, если сервак слабый, и его можно уложить даже несколькими ботами с хорошим каналом.

Насчёт DNS - собственно, это уже другая история.
Приведённые в данной теме меры помогут против самого распространённого вида атак - http-ddos'а.

Стоит почитать про fail2ban - этот пакет помогает при разных видах атак, в том числе и DNS DDoS'е, кроме того, предотвращает брутфорс, в общем очень полезная штука.

 

Ещё добавление

Распределяем нагрузки

LightHTTPD позволяет производить LoadBalancing (то есть, распределение нагрузки) между разными fastcgi-серверами.
К примеру, у Вас есть сайт, написанный на PHP, и Вы хотите разгрузить его.
Есть фронтэнд с LightHTTPD и 2 бэкэнда с FastCGI на 1000 порту. IP-адрес первого бэкнда - 192.168.1.10, а второго - 192.168.1.11.
Пишем в lighttpd.conf:

Code:

fastcgi.server = ( ".php" => 
  (
    ( "host" => "192.168.1.10",
      "port" => 1000
    ),
    ( "host" => "192.168.1.11",
      "port" => 1000 
    )
   )
  )

Как это работает? Когда появляется новое подключение, то есть пользователь запрашивает php-страницу, LightHTTPD просматривает список fastcgi-серверов, который заранее отсортирован по количеству подключений, и выбирает тот, у которого нагрузка меньше всего. Новое подключение идёт к этому серверу.
После чего, список снова отсортировывается.

Таким образом, можно значительно снизить нагрузку на основной сервер.

 

Использую LightHTTPD для flv streaming. Ограничую отдачу по подключению, тоесть - connection.kbytes-per-second = 128. Сейчас в связи с переходом на mp4 появилась необходимость в начале подключения выдавать 2 Мбита а через 5 секунд обратно возвращать на 1 Мб.
Можно ли это сделать с помощью Light?

 

Средствами конфигурации LightHTTPD динамически менять эту конфигурацию нельзя...
Возможно Вы найдёте решение в http-заголовках.
Но тогда придется обновлять страницу, т.е. сначала отправляется:

PHP:

 <?php
 header("X-LIGHTTPD-KBytes-per-second: 2048");
 ?>


А затем (по прошествии 5 секунд):

PHP:

 <?php
 header("X-LIGHTTPD-KBytes-per-second: 1024");
 ?>


Можно ли так решить конкретно Ваш вопрос, я с ходу сказать не могу...

 

Не. При стриминге (точнее перемотка видео ролика) страничка не обновляется а просто с флешплеера посылается запрос на Лайти с той секундой откуда нужно стартовать видеоролику. ОТ тут то и нужно чтоб при старте он выдал несколько Мбит а потом уже можно и 1 Мбит.
Я просто когда-то где-то встречал про «connection.burst» для Light. Но не разобрался потому что надобности тогда не было и инфу не сохранил. Да и не помню может это дополнительный модуль.
Но всерано спасибо за ответ.


Можно ли так решить конкретно Ваш вопрос, я с ходу сказать не могу...[/QUOTE]

 

[/QUOTE]


А, ну так вот же этот патч: http://www.debian.co.il/2009/09/lighttpd-burst-aka-faststart-patch/

 

Да это я видел. Это первое что выдает гугл по данному запросу. Но к сожалению мой Light под виду и это тут не поможет…

 

Не знаю живая ли эта ветка форума, но попробую написать:
Сервер, на котором висит один единственный сайт, должен выдавать контент по 81, 82 и 83 порту. На подключения к серверу к разному порту будет свое ограничение скорости (connection.kbytes-per-second).
Более того контент будет выдаваться через mod_secdownload (если это возможно) или mod_secdownload на один порт а остальные на прямую с папки.
Подскажите пожалуйста как должен выглядеть этот конфиг.