Wheely

Будем рады увидеть в открытом доступе :)

egrep -i established /proc/net/ip_conntrack

PS склонился к идее от rage, поскольку slowloris/slowread & sockstress используют методику понижения размера окна до нуля в определенный момент tcp сессии, я просто посредством u32 заблокировал пакеты с winsize 0. Будем тестировать. ну я бы просто рейты на такие пакеты поставил. потому что так можно и tcp сломать :) Не люблю я рейты, честно. Если ситуация не такая, что без них вообще никак - никогда не использую. Ибо счетчики рейтов берут информацию с clocksource, а это даже в состоянии покоя будет отжирать честь процессора. Особенно это касается таймеров в ipset. Каким образом я сломаю тцп подобным образом? SYN пакеты с initial winsize 0 никогда не посылаются, а ack с нулевым окном - собственно и есть нарушение логики tcp сессий.

Айписет стоит давно, да. Фейл2бан и подобные высокоуровневые надстройки фтопку, ибо прокси молотит довольно внушительные объемы трафика. Если в айпитейблах какой-нибудь connlimit лишний сразу задерет нагрузку процентов на 40, то какая речь о файл2бан. PS склонился к идее от rage, поскольку slowloris/slowread & sockstress используют методику понижения размера окна до нуля в определенный момент tcp сессии, я просто посредством u32 заблокировал пакеты с winsize 0. Будем тестировать.

Я понимаю, а где это тогда реализовать? На каком сервере? Я смотрел в сторону DNS. стоит bind. Но как?! На роутере своем. Ессно, команда для ната будет другая, если у вас не софтроутер, а железка.

A kind of, но довольно специфичный. Либо мне забили коннекты быстрее, чем нжинкс закрывал старые, либо... ну, я на scapy делал 3-way handshake и потом выставлял окно в 0. несколько сотен тысяч итераций делают жертве плохо. winsize 0 можно легко заблочить, а вот когда тебе валят куча вполне легитимных запросов, никаким образом не поддающихся сигнатурной фильтрации с разных айпишников - тут нужно покумекать. Идея склоняется к тому, чтобы максимально агрессивно выхеривать залипшие тсп-коннекты, не навредя при этом нормальному tcp обмену трафиком.

Некстхоп там зачем? Если должникам выдается ип из пула 172.17.0.0/16, тогда iptables -t nat -A PREROUTING -s 172.17.0.0/16 -p tcp -j DNAT --to-destination 10.10.10.10:80 Где 10.10.10.10 - айпишник сервака со страничкой index.html. В конфиге веб-сервера - реврайт отовсюду на index.html, либо ErrorDocument 404 /index.html

A kind of, но довольно специфичный. Либо мне забили коннекты быстрее, чем нжинкс закрывал старые, либо... Прочитал эту статью: http://blog.tsunanet.net/2011/03/out-of-socket-memory.html В системе нет сообщений о том, что Out of socket memory. Только о том, что too many orphans. Крутить max_orphans я не стал, ибо сомневаюсь, что в этом есть большой смысл. В то же время я кое-как пробился в консоль сервера и мог оперировать там, в то время, как на порт веб-сервера вообще было не подключиться, поэтому я склюняюсь к тому, что проблема именно в настройках в nginx.

Доброго времени суток. Имеется защищенный веб-сервер на базе nginx, который на днях заддосили банальным методом. В access логах нжинкса ничего нет, но я видел кучу подключений (120000+) на 80 порт, которые уже установились. (Значит подмены IP не было, ибо проходил three way handshake) В логах системы куча сообщений вида TCP: Too many orphaned sockets и в момент атаки нжинкс съедал весь процессор. Немного продумав схему атаки, я сделал вывод, что атакующий ботнет подключался к порту nginx, но ничего дальше не слал. В настройках нжинкс keepalive_timeout установлен в 5 секунд, то есть банальный телнет на порт - и соединение закроется через 5 секунд неактивности. Меня удивило то, что веб сервером не отдается ошибка 408 в таком случае. В настройках системы max_orphans установлен в 8192 и orphan_retries установлен в 0. Позже я в nginx'e установил accept_mutex off в секции events {}, а также уменьшил fin_timeout до 5 в настройках системы. Системой обнаружения атак данная атака не детектировалась вследствии того, что весь трафик де-факто нормален (нечего блочить), ибо все запросы легитимны, просто их очень много. Соответственно прошу совета, как лучше защититься от подобного вида атак. Ratelimit на dst_port не предлагайте, плз :) Пока что надумал впихнуть haproxy с агрессивными настройками по отношению к таймаутам коннектов, но мне кажется, что это костыль, ибо задачу, должно быть, можно решить другими настройками системы. Почему nginx съедал весь процессор, несмотря на то, что сокеты по идее требовательны к памяти, а не процу (1 сокет забирает 64 кб unswappable памяти, AFAIK)? По ошибке TCP: Too many orphaned sockets в гугле очень мало инфы, и все советы, которые даются в данном случае, уже были приняты. Что крутить: nginx или настройки tcp стека? Спасибо за внимание.

Спасибо за отличную новость, Павел! Собираемся закупать несколько карточек на пробу. Учитывая не заоблачную цену, думаю, будет разумное приобретение.

Нельзя пренебречь. Для сетевушек разные маршруты? На всех сетевухах висят айпишники из одной подсети или из разных (с необходимостью создания n числа "дефолтных" маршрутов для каждой сетевухи)?

iptables hashlimit. но это всё равно форма стейтов. Работают эти стейты действительно ОЧЕНЬ быстро и оверхедят сравнительно мало по отношению к классике state - коннтреку.

Здравствуйте. Очень с трудом мы подняли интерфейс mgt на Juniper NetScreen 5200, тоже упорно не хотел подниматься. Следующие интерфейсы eth.. не поднимаются вообще. ns5200-> get route IPv4 Dest-Routes for <untrust-vr> (0 entries) -------------------------------------------------------------------------------------- H: Host C: Connected S: Static A: Auto-Exported I: Imported R: RIP/RIPng P: Permanent D: Auto-Discovered N: NHRP iB: IBGP eB: EBGP O: OSPF/OSPFv3 E1: OSPF external type 1 E2: OSPF/OSPFv3 external type 2 trailing B: backup route IPv4 Dest-Routes for <trust-vr> (6 entries) -------------------------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr Vsys -------------------------------------------------------------------------------------- * 28 0.0.0.0/0 eth2/1 *.*.218.1 S 20 1 Root * 29 0.0.0.0/0 mgt *.*.231.1 S 20 1 Root * 24 *.*.218.129/32 eth2/1 0.0.0.0 H 0 0 Root * 23 *.*.218.0/24 eth2/1 0.0.0.0 C 0 0 Root * 20 *.*.231.0/24 mgt 0.0.0.0 C 0 0 Root * 21 *.*.231.90/32 mgt 0.0.0.0 H 0 0 Root ns5200-> get interface A - Active, I - Inactive, U - Up, D - Down, R - Ready Interfaces in vsys Root: Name IP Address Zone MAC VLAN State VSD Vsys mgt *.*.231.90/24 MGT 0010.dbb8.5e00 - U - Root ha1 0.0.0.0/0 HA 0010.dbb8.5e05 - D - Root ha2 0.0.0.0/0 HA 0010.dbb8.5e06 - D - Root eth2/1 *.*.218.129/24 Trust 0010.dbb8.5e07 - U - Root eth2/2 0.0.0.0/0 Trust 0010.dbb8.5e08 - D - Root vlan1 0.0.0.0/0 VLAN 0010.dbb8.5e0f 1 D - Root null 0.0.0.0/0 Null N/A - U - Root До mgt интерфейса пинг ходит (и обратно), с eth2/1 ничего не ходит в оба направления. set policy from trust to untrust any any any permit сделан. Подскажите, пожалуйста!

Да, вы были правы. На другом сервере все ОК. Спасибо.

Здравствуйте. Имеется 2 тазика на Debian Wheezy, между которыми поднят GRE туннель, а точнее первый тазик отдает один из своих внешних IP второму тазику. Через определенное время gre сессия отваливается и этот отдаваемый адрес ниоткуда недоступен, на трассе последним узлом является основной ип тазика-донора. При пинге со второго тазика первый тазик на ip внутри gre туннеля сессия возобновляется и трафик опять начинает ходить (на 10-20 минут, потом снова). Что за мистика? Весь гугл искурил, нашел пару таких же вопросов но без ответов...

Да, после этого у вас будет недоступен стейт. Я сделал лично у себя вот как: -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack -A PREROUTING -p udp -m udp -j CT --notrack -A PREROUTING -p icmp -m icmp --icmp-type any -j CT --notrack И затем: -A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

1) hashsize conntrack'a можно сменить двумя путями - на лету и постоянно. на лету: echo $hashsize > /sys/module/nf_conntrack/parameters/hashsize постоянно: создать любой файл с расширением .conf в папке /etc/modprobe.d/ с содержимым options nf_conntrack hashsize=$hashsize, после чего перезагрузить модуль или ребутнуть сервер. 2) conntrack_buckets по умолчанию равен conntrack_max. так что особой нужды крутить первый параметр нет, гораздо юзабельнее покрутить второй и первый автоматически станет ему равным. ну а теперь несколько рекомендаций собственно по увеличению производительности nat-сервера. - NAT = conntrack, conntrack = зло. но раз уже от этого зла никуда не деться, то нужно его минимизировать: в -j NOTRACK *все*, что не будет натиться. - conntrack_max = conntrack_hashsize = 983040, как для начала. - net.netfilter.nf_conntrack_tcp_loose = 0 - очередей карты выставьте сколько у вас ядер процессора, например 4 ядра - 4 очереди и должно быть, на примере драйверов от intel: RSS=4,4 - irq развесьте вручную по ядрам одного процессора, не двух а одного, поскольку карту прибивают к единому процессору. если система мультипроцессорная, желательно вывести для NIC отдельный проц, а на второй закинуть остальные задачи (taskset, default_affinity) - tx/rx queue выставьте на максимум, txqueuelen = tx queue - оптимизируйте правила iptables, все что вам не особо нужно лучше удалить, и оставшуюся часть оптимизировать, если вам это сложно я могу в этом помочь.

Картина прояснилась, согласно документации к драйверу ixgbe при использовании ntuple (а он у меня используется) RPS loses it's sence. Т.е не работает. Попутно хотелось бы задать вопрос про ntuple, не работает правило: Как видим, несмотря на попадание под правило дропа трафика снимаемого с tcpdump, он все равно проходит. Почему так? И правило drop в ntuple не действует на большие пакеты (>1492 bytes), только на маленькие. ЧЯНТД? MTU на сервере с которого шлют пакеты 1500. На приемнике 9000. Смена MTU и там и там не помогает, драйвер сетевой карты последний (пробовал со старыми, тоже проходит). Почему фильтр сетевой карты не действует в этом случае? Если что, я шлю фрагментированные пакеты.

Возможно ли увеличение "предела памяти"? На сервере, я думаю, её хватит. А вообще сегодня планируем обновляться до 3.14-0.bpo.1-amd64 в связи с необходимостью тестирования новой опции, не работающей под 3.2.0-4-amd64. Как все сделаем, отпишем результаты (касательно балансирования нагрузки RPS и проблем с приложениями).

Приложения - nginx, fpm, mysql. RFS включен.

Мне хотелось бы добавить еще пару строк. Сервер используется как ддос-фильтр. (Пока не используется, планируется использоваться). Задача - поступающий трафик по линку 10 гигабит/сек очищать и очищенный слать уже дальше некстхопам по линку в 1 гигабит, чистить нужно много, ддосят часто, поэтому применяется такое решение. В течении длительного времени курения этого и иных (в т.ч. англоязычных) форумов было выкручено все что только можно, начиная от экспериментов с CONFIG_HZ (остановился на дефолтном 250) до тюнинга дисковой подсистемы. В данный момент сервер справляется с ддосом <1 Mpps нормально, пакеты эти плохие и дальше их пропускать не стоит. Однако как я уже отметил была замечена проблема с повышенным потреблением ЦПУ приложениями и еще одно: на один из 4-х выделенных для сетевой карты ядер наблюдается повышенная загрузка. Виню RPS, грузит не обязательно первое ядро в списке, но на одно из 4-х приходится 40% работы, скажем, а на остальные - по 20. # SMP echo "f" > /proc/irq/default_smp_affinity # eth1 echo "e" > /proc/irq/68/smp_affinity echo "e" > /proc/irq/66/smp_affinity echo "e" > /proc/irq/67/smp_affinity # eth0 echo "10" > /proc/irq/73/smp_affinity echo "10" > /proc/irq/69/smp_affinity echo "20" > /proc/irq/70/smp_affinity echo "40" > /proc/irq/71/smp_affinity echo "80" > /proc/irq/72/smp_affinity # RPS # eth0 echo "20" > /sys/class/net/eth0/queues/rx-0/rps_cpus echo "40" > /sys/class/net/eth0/queues/rx-1/rps_cpus echo "80" > /sys/class/net/eth0/queues/rx-2/rps_cpus echo "10" > /sys/class/net/eth0/queues/rx-3/rps_cpus # eth1 echo "e" > /sys/class/net/eth1/queues/rx-0/rps_cpus # XPS # eth0 echo "20" > /sys/class/net/eth0/queues/tx-0/xps_cpus echo "40" > /sys/class/net/eth0/queues/tx-1/xps_cpus echo "80" > /sys/class/net/eth0/queues/tx-2/xps_cpus echo "10" > /sys/class/net/eth0/queues/tx-3/xps_cpus # eth1 echo "e" > /sys/class/net/eth1/queues/tx-0/xps_cpus # RFS # eth0 echo "8192" > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt echo "8192" > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt echo "8192" > /sys/class/net/eth0/queues/rx-2/rps_flow_cnt echo "8192" > /sys/class/net/eth0/queues/rx-3/rps_flow_cnt # eth1 echo "32768" > /sys/class/net/eth1/queues/rx-0/rps_flow_cnt Такое "кривое" распределение RPS (и XPS) не случайно, при указании rx-X/rps_cpus == /proc/irq/[номер IRQ, соответствующий этой очереди]/smp_affinity наблюдается бОльшая загрузка ЦП, чем так как сейчас. Намного большая.

Здравствуйте. Имею сервер на платформе 3.2.0-4-amd64 и с двумя карточками и линками, 82599 как основная и 82574 как дополнительная. Прерывания раскиданы по ядрам, RPS/RFS/XPS включен. Количество очередей у 82599 равно количеству ядер специально отведенного для этой карточки процессора, т.е. 4. TX/RX queue == txqueuelen == 4096 До отвода карточке отдельного процессора и перевешивания всех остальных процессов на другой процессор (taskset + default_smp_affinity) наблюдалась вообще ужасная картина - при трафике ~700 Kpps процессор жрали не прерывания, а именно мои процессы, которые, к сожалению, никуда деть нельзя. При прибивании карты к dedicated CPU ситуация улучшилась (например, имел процесс, который в покое потребляет 10% ЦПУ, когда я ничего не разделял при 700 Kpps он потреблял 40%, после разделения стал потреблять 20%). Собственно хотелось узнать, как можно минимизировать данный побочный эффект? Он наблюдается как и 82599 так и с 82574, но в случае с 82574 также и появляется зажирание ЦП прерываниями (~2-3%). Стоит отметить, что в сервере процессора два, значит 82574 и приложения сидят на первом процессоре, а 82599 на втором и кроме нее там ничего нет. Коннтрак включен, без него к сожалению никак. options ixgbe InterruptThrottleRate=16000,16000 RSS=4,4 options nf_conntrack hashsize=1966080 net.nf_conntrack_max = 1966080 драйвера сетевых последние. Спасибо за внимание к моему вопросу.