Перейти к содержимому
Калькуляторы

Wheely

Пользователи
  • Публикации

    22
  • Зарегистрирован

  • Посещение

1 подписчик

О Wheely

  • Звание
    Абитуриент
  1. Будем рады увидеть в открытом доступе :)
  2. Аномалия

    egrep -i established /proc/net/ip_conntrack
  3. PS склонился к идее от rage, поскольку slowloris/slowread & sockstress используют методику понижения размера окна до нуля в определенный момент tcp сессии, я просто посредством u32 заблокировал пакеты с winsize 0. Будем тестировать. ну я бы просто рейты на такие пакеты поставил. потому что так можно и tcp сломать :) Не люблю я рейты, честно. Если ситуация не такая, что без них вообще никак - никогда не использую. Ибо счетчики рейтов берут информацию с clocksource, а это даже в состоянии покоя будет отжирать честь процессора. Особенно это касается таймеров в ipset. Каким образом я сломаю тцп подобным образом? SYN пакеты с initial winsize 0 никогда не посылаются, а ack с нулевым окном - собственно и есть нарушение логики tcp сессий.
  4. Айписет стоит давно, да. Фейл2бан и подобные высокоуровневые надстройки фтопку, ибо прокси молотит довольно внушительные объемы трафика. Если в айпитейблах какой-нибудь connlimit лишний сразу задерет нагрузку процентов на 40, то какая речь о файл2бан. PS склонился к идее от rage, поскольку slowloris/slowread & sockstress используют методику понижения размера окна до нуля в определенный момент tcp сессии, я просто посредством u32 заблокировал пакеты с winsize 0. Будем тестировать.
  5. Я понимаю, а где это тогда реализовать? На каком сервере? Я смотрел в сторону DNS. стоит bind. Но как?! На роутере своем. Ессно, команда для ната будет другая, если у вас не софтроутер, а железка.
  6. A kind of, но довольно специфичный. Либо мне забили коннекты быстрее, чем нжинкс закрывал старые, либо... ну, я на scapy делал 3-way handshake и потом выставлял окно в 0. несколько сотен тысяч итераций делают жертве плохо. winsize 0 можно легко заблочить, а вот когда тебе валят куча вполне легитимных запросов, никаким образом не поддающихся сигнатурной фильтрации с разных айпишников - тут нужно покумекать. Идея склоняется к тому, чтобы максимально агрессивно выхеривать залипшие тсп-коннекты, не навредя при этом нормальному tcp обмену трафиком.
  7. Некстхоп там зачем? Если должникам выдается ип из пула 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
  8. A kind of, но довольно специфичный. Либо мне забили коннекты быстрее, чем нжинкс закрывал старые, либо... Прочитал эту статью: http://blog.tsunanet.net/2011/03/out-of-socket-memory.html В системе нет сообщений о том, что Out of socket memory. Только о том, что too many orphans. Крутить max_orphans я не стал, ибо сомневаюсь, что в этом есть большой смысл. В то же время я кое-как пробился в консоль сервера и мог оперировать там, в то время, как на порт веб-сервера вообще было не подключиться, поэтому я склюняюсь к тому, что проблема именно в настройках в nginx.
  9. Доброго времени суток. Имеется защищенный веб-сервер на базе 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 стека? Спасибо за внимание.
  10. Спасибо за отличную новость, Павел! Собираемся закупать несколько карточек на пробу. Учитывая не заоблачную цену, думаю, будет разумное приобретение.
  11. Нельзя пренебречь. Для сетевушек разные маршруты? На всех сетевухах висят айпишники из одной подсети или из разных (с необходимостью создания n числа "дефолтных" маршрутов для каждой сетевухи)?
  12. iptables hashlimit. но это всё равно форма стейтов. Работают эти стейты действительно ОЧЕНЬ быстро и оверхедят сравнительно мало по отношению к классике state - коннтреку.
  13. Здравствуйте. Очень с трудом мы подняли интерфейс 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 сделан. Подскажите, пожалуйста!
  14. Да, вы были правы. На другом сервере все ОК. Спасибо.
  15. Здравствуйте. Имеется 2 тазика на Debian Wheezy, между которыми поднят GRE туннель, а точнее первый тазик отдает один из своих внешних IP второму тазику. Через определенное время gre сессия отваливается и этот отдаваемый адрес ниоткуда недоступен, на трассе последним узлом является основной ип тазика-донора. При пинге со второго тазика первый тазик на ip внутри gre туннеля сессия возобновляется и трафик опять начинает ходить (на 10-20 минут, потом снова). Что за мистика? Весь гугл искурил, нашел пару таких же вопросов но без ответов...