Comments / Profile of velizarx / Habr

Вадим @velizarx

User

Profile Publications 3Comments 16Bookmarks 11

Введение в сетевую часть облачной инфраструктуры

velizarx Aug 25 2020 at 21:03

Спасибо за статью, крайне мало подобного материала про OpenStack на хабре, к сожалению не самая популярная тема.

Look

Введение в сетевую часть облачной инфраструктуры

velizarx Aug 25 2020 at 21:02

В Селетеле у нас сеть вся с включенным Jumbo frame из-за чего MTU нормальный (хотя пришлось в одном месте подложить патчиком в OpenStack). Адреса в ВМ настраиваются статикой даже без DHCP потому что образы которые доступны в панели управления собраны с cloud-init, который так же умеет читать metadata и настраивать все что надо. Это позволяет чуть-чуть экономить на ресурсах и количестве таблиц маршрутизации (ака netns). И, да, в конфиге nova есть опция cpu_mode=host-passthrough чтобы клиенты могли собирать свой код используя специфичные фичи проца. Ограничение только в том что все равно там не все, список «проброшенных» фич ограничивается qemu.

Look

Тонкая настройка OpenStack под высокой нагрузкой

velizarx Oct 25 2018 at 11:59

Опечатка в

ovs_vsctrl_timeout = 30

лишня r. Упоминание этого таймаута подсказывает, что вы используете openvswitch агент в режиме вызова shell-команд ovs-vsctl. Рекомендую попробовать native режим (ovsdb_interface = native) при котором neutron становится менеджером для OVS. Работает значительно быстрее, особенно это заметно при синхронизации OF правил после перезапуска агента. В режиме native есть одна немаловажная настройка таймаута: of_request_timeout на которую стоит обратить внимание.

Также есть несколько вопросов к вам:

BGP плагин для neutron пришлось как-то дорабатывать?
L2 сегмент физической сети у вас уходит дальше одной стойки? Приходится ли тянуть VLAN от сетевых нод до bare-metal роутера?
В первой части статьи вы говорите о том что отказались от NAT совсем (как кажется по тексту), но дальше в разделе про FWaaS вы упоминаете про виртуальные роутеры? Не совсем понял, как виртуальные роутеры работают с FWaaS но без NAT. Поясните, пожалйста этот момент.
Используются ли у вас гибриднае сети когда нужно подключить в виртуальную (overlay) сеть bare-metal устройство/сервер? Если да, то как реализуется такая схема? Или вы используете VLAN сети для такого через provider:network_type=vlan?

Look

История одной DDOS атаки на роутер и методы защиты Juniper routing engine

velizarx Oct 29 2014 at 12:32

Вероятно, не совсем правильно понял ваш вопрос, но посмотрите на term discard-TTL_1-unknown в фильтре discard-all. Все firewall filter в Juniper переносят нагрузку на PFE.

Look

Интеграция RPKI в BGP на маршрутизаторах Juniper

velizarx Feb 11 2014 at 23:56

Да Вы правы, не поможет, не то написал. Имел ввиду IP hijacking (притягивание трафика). Соглашусь с Вами, uRPF в сети провайдера с асинхронным трафиком — миф.

Look

Интеграция RPKI в BGP на маршрутизаторах Juniper

velizarx Feb 11 2014 at 17:59

Надо начинать с малого, когда-нибудь RPKI искоренит DDOS атаки с IP Spoofing'ом. Хочу верить, что я внес свою лепту в процесс внедрения этой полезной технологии. Подпишите и свои маршруты ROA www.ripe.net/lir-services/resource-management/certification/resource-certification-roa-management ;)

Look

Защита от DDOS атак средствами BGP

velizarx Feb 11 2014 at 17:24

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

Look

Защита от DDOS атак средствами BGP

velizarx Feb 11 2014 at 17:19

Да, к сожалению есть только рекомендации по составлению community.

Спасибо, не знал про привязку community к static маршрутам. По привычке использовал cisco-way. На самом деле я еще обычно выставляю no-install для static маршрута, чтобы пакеты до этого хоста внутри моей AS не дропались на маршрутизаторе. Это очень полезная функция Juniper, которой к сожалению нет в Cisco.

Look

Защита от DDOS атак средствами BGP

velizarx Feb 11 2014 at 16:13

Да, Вы отчасти правы, но в статье говорится про атаки с которыми не удается справится иными средствами и из-за которых может страдать вся сеть. Если недоступна вся сеть, то лучше «пожертвовать» одним сервером и разгрузить канал, а потом искать цель атаки (если это сервер с клиентами, например) и заниматься анализом атаки. Кроме того существует возможность более продвинутого blackhole, например, если контент Вашего сервера для России, то в момент атаки можно установить Blackhole только на зарубежный пиринг. Это позволит снизить уровень атаки (по статистике 80% трафика DDOS льется из-за границы) и оставить сервер доступным для Российского сегмента. Многие Российские провайдеры предоставляют расширенные community, которые позволяют такое делать. Существует также метод «сливного туннеля», который позволяет не ограничивая доступ к серверу фильтровать трафик, о нем Вы можете почитать в rfc3882.

Look

Защита от DDOS атак средствами BGP

velizarx Feb 11 2014 at 14:11

Время установки префикса в такой (рекурсивный) Blackhole как правило 1-3 минуты, пока все провайдеры примут community. Blackhole у первого провайдера срабатывает через ~5-10 секунд, то есть трафик в Вашу AS уже перестанет попадать.

Look

История одной DDOS атаки на роутер и методы защиты Juniper routing engine

velizarx Sep 16 2013 at 17:19

Да фильтр выглядит так:

user@MX-80> show configuration firewall family inet filter PROTECT-UPLINK 
apply-flags omit;
/* allow packets from BGP neighbors to BGP address */
term discard-to-bgp-ip {
    from {
        source-address {
            0.0.0.0/0;
        }
        source-prefix-list {
            BGP-neighbors-v4 except;
        }
        destination-prefix-list {
            BGP-locals-v4;
        }
    }
    then {
        count discard-to-bgp-ip;
        discard;
    }
}
/* Block private networks */
term rfc1918 {
    from {
        source-prefix-list {
            rfc1918;
        }
    }
    then {
        count discard-rfc1918;
        discard;
    }
}
/* Block packet from own networks */
term discard-from-locals-ip {
    from {
        source-prefix-list {
            INTERNAL-locals-v4;
        }
    }
    then {
        count discard-to-locals-ip;
        discard;
    }
}
/* allow other */
term allow-other {
    then accept;
}

префикс листы:

prefix-list BGP-locals-v4 {
    apply-path "protocols bgp group <*> neighbor <*.*> local-address <*.*>";
}
prefix-list BGP-neighbors-v4 {
    apply-path "protocols bgp group <*> neighbor <*.*>";
}
prefix-list rfc1918 {
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
}
prefix-list INTERNAL-locals-v4 {
    apply-path "interfaces xe-0/0/1 unit <*> family inet address <*>";
}

В моем случае интерфейс xe-0/0/1 смотрит во внутрь AS, то есть на нем все собственные сети.

Look

История одной DDOS атаки на роутер и методы защиты Juniper routing engine

velizarx Jul 20 2013 at 14:06

Например так:
1) написать префикс лист для мультикаст адресов OSPF:

prefix-list OSPF {
    224.0.0.5/32;
    224.0.0.6/32;
}

2) сам фильтер:

filter accept-ospf {
    apply-flags omit;
    term accept-ospf {
        from {
            source-prefix-list {
                LOCALS-v4
            }
            destination-prefix-list {
                LOCALS-v4
                ospf;
            }
            protocol ospf;
        }
        then {
            count accept-ospf;
            accept;
        }
    }
}

Look

История одной DDOS атаки на роутер и методы защиты Juniper routing engine

velizarx Jul 18 2013 at 23:35

В настоящий момент такой цели нет, да и сгенерировать больше 1.5Mpps довольно сложно, надо ставить FreeBSD и крутить netmap. Обычный linux утилизирует все 8 ядер на 100%. Вероятно, после очередного крупного DDOS, я опубликую следующие испытания.

Look

История одной DDOS атаки на роутер и методы защиты Juniper routing engine

velizarx Jul 17 2013 at 10:04

Проблема в том, что ограничение доверенных хостов BGP легко обходится подменой ip если у провайдера не включен uPRF (как раз у нас такая ситуация), а все остальные фильтры ssh, snmp и так не лезут в tcp flag.

Про правило с ICMP не знал, проверил на практике без фильтра, действительно количество pps не влияет на нагрузку RE:

не подскажите где в оф. доке можно об этом почитать? Единственное что удалось найти это Enabling ICMP Flood Protection, но у меня на стенде эта защита была выключена.

Look

История одной DDOS атаки на роутер и методы защиты Juniper routing engine

velizarx Jul 16 2013 at 19:34

Да обработка мусора — это основная проблема, дело не в RST, в момент атаки на порт BGP процесс rpd занят обработкой мусора и грузит CPU, а после падения сессий и попытки их восстановить еще добавляется нагрузка на обработку fullview и роутер самостоятельно очнуться не может. Но фильтры переносят всю нагрузку на PFE и rpd работает только с нормальным трафиком. В момент проведения первого теста, я был удивлен насколько мало надо трафика чтобы положить роутер, порог ~400Kpps, что совсем не много.

Look

История одной DDOS атаки на роутер и методы защиты Juniper routing engine

velizarx Jul 16 2013 at 16:54

Да, была такая мысль, протестировал буквально вчера, наглядный результат: habrastorage.org/storage2/fb8/578/ea4/fb8578ea472d4a83f841dfea5f6d6871.png

как видно все осело на PFE. Первая волна SYN, вторая как раз ACK.

Look