throughtheether

Как настроить Policy-based Routing на cisco

Модель устройства и версию прошивки (операционной системы) будьте добры уточнить.

Как настроить Policy-based Routing на cisco что бы клиент имеющий ip из сети 172.17.0.0/16 при обращении на любой сайт попадал на страничку заглушку?

Не уверен, что PBR здесь поможет. Как один из вариантов - закрыть трафик наружу при помощи ACL и отдавать на все DNS(A)-запросы какой-либо внутренний IPv4-адрес. Первое применяется на граничных маршрутизаторах, второе - на DNS-сервере.
Если есть хост, отдающий заглушку, то можно перенаправить запросы на него при помощи Destination NAT (если оборудование это поддерживает).

UPD:

Не поможете примером? Облазил всё что можно. На днсах можно как то через view. Но так же примеров нет.

Вот ссылки на примеры использование view: 1, 2. Вот ссылки на примеры реализации разрешения всех имен хостов в заданный IPv4-адрес: 1, 2.

Настройки будут выглядеть примерно так (проверить пока нет возможности):
Файл named.conf, добавить:

view internal {
   match-clients { 172.17.0.0/16; };
   zone "." IN {
    type master;
    file "db.fakeroot";
   };
};

Содержимое файла db.fakeroot:

$ORIGIN .
$TTL 1D
@    IN     SOA  @ none. ( 0 1D 1H 1W 3H );
     IN     NS   @
*    IN     A    a.b.c.d

где a.b.c.d - IPv4-адрес хоста с заглушкой. Может понадобиться добавить view для обработки запросов от других клиентов.

Я считаю, что перед тем, как покупать новые устройства, крайне желательно оптимизировать инфраструктуру с целью повышения ее надежности. Поэтому в комментарии коснусь и других тем, не только анти-DDoS решений.

Есть несколько десятков серверов в двух стойках к которым в сумме подведено около 10 Gbps

Что значит около 10 Гбит/с? Используются 10-гигабитные линки или агрегация из нескольких гигабитных? По некоторым соображениям первый вариант предпочтительнее.

Периодически «приходят» атаки в несколько гигабит или более и забиваю канал.

Интенсивность трафика вам известна откуда? Необходимо понимать, что если мусорный трафик представляет собой UDP или сегменты TCP без установления сессии, то вполне возможна такая ситуация, когда к вашему провайдеру приходит 10-20 гигабит/c адресованного вам трафика, а до вас доходит лишь его часть. Если есть возможность, запросите статистику (данные netflow) хостинг-провайдера.

Хотим сделать схему с защитой с помощью сетевого оборудования Cisco (или какого-либо другого) внутри ДЦ, чтобы не пользоваться данным внешним сервисом и не менять IP.

Касательно оборудования Cisco. Было у Cisco Systems решение Clean Pipes, предназначенное для противодействия DDoS-атакам. Состояло из двух компонент - детектора аномалий (Cisco Traffic Anomaly Detector, использовалось опционально) и собственно фильтрующего устройства (Cisco Anomaly Guard). Оба устройства имеют статус End-of-life. Далее совместно с Arbor Networks была разработана архитектура Clean Pipes 2.0, где, насколько мне известно, основную работу выполняло устройство Arbor Peakflow TMS (threat management solution). О существовании современного устройства под брендом Cisco Systems, разработанного для противодействия DDoS-атакам, мне неизвестно.

Подскажите, пожалуйста, возможно ли это и, если да, то в какую сторону копать?

Во-первых, определитесь, зачем вам это. Если мусорный трафик на клиента приводит к недоступности вашей сети (т.е. к полной утилизации линка), то это одно. В таком случае вам поможет BGP blackhole (RTBH, remotely triggered blackhole filtering), отбрасывая весь трафик до клиента. Эффективно клиентский хост будет недоступен (т.е. DoS-атака удалась, отказ в обслуживании достигнут), но мусорный трафик будет отброшен на оборудовании провайдера, не влияя на работоспособность вашей сети. На мой взгляд, иметь настроенный RTBH необходимо. Для этого можно использовать, например, программный BGP клиент, вроде exabgp или quagga.

Если вы планируете фильтровать клиентский трафик (т.е. отбрасывать мусорный и пропускать "полезный", что бы это ни значило), то RTBH не подойдет. Возможные варианты (с которыми я работал либо работу которых наблюдал) аппаратных решений - грамотно настроенный сервер под Linux/*BSD с картами Intel (дешево, гибко, множество нюансов), Juniper SRX подходящей мощности (дорого, от некоторых атак вполне защищает, но, на мой взгляд, специализированное решение предпочтительнее), Arbor Peakflow TMS (дорого, красивый интерфейс, в целом понравилась работа с ним), Периметр от МФИ-Софт (работает, но не без нюансов).

Кроме самого устройства или внешнего сервиса, как я уже упоминал, следует, на мой взгляд, удостовериться, что:
1) сеть находится под всесторонним мониторингом
2) имеется либо отдельная (management) сеть для управления, либо настройки QoS на линках, резервирующие полосу для трафика систем управления.
3) настроена защита CPU сетевых устройств (Control plane protection policy в cisco-мире)
4) отсутствуют другие узкие места (например, ECMP в том или ином виде, агрегация двух линков в 1 гигабит/c не во всех случаях дает пропускную способность в 2 гигабита/с)

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

Как сейчас распространяются вирусы?

Если говорить о распространении банковских троянов, DDoS-ботов, троянов для мошенничества с рекламой, то одна из схем примерно такова:
Сайт с живыми пользователями -> Ссылка/фрейм/попандер на эксплоит-пак -> Эксплуатация уязвимости (Flash, браузер, и т.д.) -> загрузка и исполнение шифрованного бинарника.

Хочу поделить сеть на vlan'ы, но при подключении в управляемый свитч (sw1) неуправляемого свитча (sw2) не получится распределить устройства, подключенные к этому самому sw2, по вланам. Тут ничего нельзя сделать?

Для некоторых неуправляемых коммутаторов на определенных чипсетах есть подобное решение: ссылка. Думаю, нет нужды объяснять, что это трудно поддерживается и в промышленную сеть такое пускать не стоит.

А как эффективнее всего сделать MAC-based vlan?

Считаю, что эффективнее всего этого не делать. Эта схема также представляется трудномасштабируемой и трудноподдерживаемой.

Я бы на вашем месте использовал L3-коммутаторы (или сервер на Linux/*BSD в качестве маршрутизатора) и управляемые L2-коммутаторы.

Проверьте arp-таблицы (arp -a) на машинах, вероятно, на маршрутизаторе активирована опция proxy ARP. Сравните содержание записей с реальными MAC-адресами сетевых адаптеров машин (ipconfig /all)

Насколько мне известно, экзамен CCNA недавно был обновлен. Однако прочитать книгу, думаю, будет весьма полезно.

Слышал (но не использовал) про YANG/NETCONF. Посмотрите, может, вам подойдет.

Переведите ваше устройство в режим маршрутизатора с NAT. Так, чтобы на WLAN-интерфейсе был активен dhcp-клиент (или прописан статический адрес, предоставляемый вам оператором). На LAN-интерфейсах - адреса из отдельного префикса (не пересекающегося с операторским). NAT между LAN- (внутренний интерфейс с т.з. NAT) и WLAN- (внешний интерфейс с т.з. NAT) интерфейсами.

Но в таком случае конечные устройства будут подключены к маршрутизатору по витой паре. Если необходим доступ именно по WiFi, то, на мой взгляд, без двух WiFi-трансиверов (устройств) не обойтись. Схему также придется чуть усложнить.

Проверьте настройки безопасности на роутерах (иногда это называется application layer gateway, ALG).
Проверьте правильность подключения (wan-порт роутера 2 подключен в lan-порт роутера 1).
Проверьте адресацию.

на какие сайты какие пользователи ходили и объем трафика, как общий, так и по пользователям.

Если достаточно IP-адресов сайтов и IP-адресов клиентов, то можно подумать об использовании netflow, если ваше оборудование (маршрутизатор) его поддерживает.

Топология сети какова? Какие устройства (коммутаторы, маршрутизаторы) находятся между ноутбуком и МФУ? Если в печати/traceroute указывать имя принтера (если используется), а не IPv4-адрес (я думаю, у вас именно IPv4) - каковы результаты?

Попробуйте деактивировать все "решения безопасности" на пути между устройствами (брандмауэр windows, возможные настройки маршрутизатора) и пронаблюдайте за ситуацией.

Доступным остаётся от 10 минут до трёх дней, потом надо опять повторить, перезагрузка принтера не помогает, перезагрузка ноутбука тоже (для чистоты эксперимента ноут подключался как кабелем, так и по wi-fi, так же переустанавливалась ОС).

Есть подозрение на проблему с адресацией, проверьте уникальность MAC- и IPv4-адресов на устройствах.

Использовал docopt. Для моих скромных целей хватило.

Тикните носом что ковирять ?

Например, bottle.py в качестве веб-сервера, subprocess для исполнения команд. Если хочется обойтись стандартной библиотекой, то SimpleHTTPServer/BaseHTTPServer в случае python2, http.server в случае python3.

Попробовал запрос сайта curlом сделать в резте получаю хтмл сайта провайдера и так при обращении к любому внешнему сайту.

В чем может быть проблема?

Доступ в интернет оплачен?

Что я уже сделал:
...
2. Отключил Ipv6

Что это значит? Где отключили? На каждой рабочей станции в сети?

все статистики отличные (top,iostat,ifstat,ifconfig,sar) - нигде нет пределов.

На портах коммутаторов показатели смотрели? Количество отброшенных пакетов, размеры очередей?

в чем может быть проблема или как продиагностировать?

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

И при этом выключить сервер, то флуд перерастает в Unicast-флуд и распространяется на все виртуальные интерфейсы на сервере, в некоторых случаях на весь vlan,

Если я вас правильно понял, подразумевается unknown unicast flood.

Ваш хост имеет адрес 109.XX.XX.XX.53? Какой именно трафик распространяется на весь влан - подобный указанному в дампе или, может быть, arp-запросы?

Я с libvirt не работал, но мысли касательно вашей ситуации такие. Есть некий маршрутизатор (устройство или виртуальная сущность), на котором активен IP-адрес из одного префикса ("подсети") с 109.XX.XX.XX.53. На нем есть arp-таблица, где IPv4-адресу 109.XX.XX.XX.53 соответствует некий MAC-адрес aaaa-bbbb-cccc (подразумевается использование ethernet). На (виртуальном) коммутаторе/бридже этому MAC-адресу соответствует некий виртуальный интерфейс.
Когда вы хост выключаете, возможны два варианта:
1) в таблице коммутатора исчезает запись, ставящая в соответствие MAC-адресу aaaa-bbbb-cccc некий виртуальный интерфейс. В таком случае будет наблюдаться unknown unicast flood, а именно трафик, подобный указанному на приведенном вами дампе, будет направляться во все интерфейсы коммутатора (хотя, могут быть нюансы, связанные с виртуализацией). Для решения проблемы вы можете или задать статическое соответствие MAC-адреса aaaa-bbbb-cccc нужному интерфейсу, или, если есть такая возможность, зафильтровать трафик, предназначенный для хоста с MAC-адресом aaaa-bbbb-cccc на время, пока соответствующий сервер неактивен, или фильтровать трафик на 109.XX.XX.XX.53 на вышестоящем оборудовании
2) в arp-таблице маршрутизатора исчезает запись, ставящая в соответствие IPv4-адресу 109.XX.XX.XX.53 MAC-адрес aaaa-bbbb-cccc. В таком случае маршрутизатор будет слать некоторое количество широковещательных arp-запросов. Количественные характеристики зависят от реализации, как именно это сделано в libvirt, трудно предполагать.

Что можно сделать со стороны активного оборудования, чтобы избежать подобных проблем в автоматическом режиме?

Не понимаю вашего фокуса именно на активном оборудовании. На мой взгляд, конструктивнее сначала попытаться решить проблему на уровне виртуализации. Представляется, что среда виртуализации предоставляет более удобные инструменты для автоматизации (т.е. различные скрипты и/или API). Если вышеописанное (установку статической записи в таблицу соответствия MAC-адрес <-> интерфейс коммутатора; установку фильтрующей записи в ту же таблицу, см. cisco-аналог mac address-table static MACADDRESS vlan VLANID drop; фильтрацию на основе L3-данных) не получится реализовать на сервере виртуализации, можно попытаться фильтровать трафик до 109.XX.XX.XX.53 на вышестоящем оборудовании, но сомневаюсь, что это можно будет удобно автоматизировать.

Дальнейшие советы, не зная топологию сети, давать затруднительно.

UPD:

В примере, имелось ввиду, что 109.XX.XX.XX - это IP, 53 это порт,

Извините, проглядел. Вот именно поэтому я не люблю вывод tcpdump и предпочитаю оперировать дампом в виде pcap-файлов.

Я наблюдаю две проблемы:
1) мусорный трафик на один из ваших хостов
2) флуд (умножение) этого трафика на все ваши виртуальные сервера

Касательно первой проблемы есть вопросы. Как вы используете DNS-сервер? Как фильтруется доступ к нему? Если никак, то почему? Разрешены ли рекурсивные запросы? Если да, то желательно заблокировать их обработку, кроме того случая, когда вы точно знаете, что именно делаете. Я подозреваю, в данном случае имеет место попытка атаки 94.41.XX.XX при помощи вашего сервера (dns reflection attack, точнее можно будет сказать, если вы предоставите дамп трафика в формате .pcap, tcpdump -i -s 65535 -w ). Если гипотеза окажется верна, то есть вероятность, что такой мусорный трафик прекратится через некоторое время после того, как вы выключите обработку рекурсивных запросов.
Вообще говоря, я бы на вашем месте запретил бы весь трафик, кроме трафика вашего сервиса и управленческого (ssh, snmp и т.д.) трафика при помощи списков доступа (ACL) на активном оборудовании (на ближайших к вашему оборудованию L3-устройствах, скорее всего их два)

Теперь по второй проблеме.

сетевые инженеры Дата-центра говорят, что установили настройку для влана и свичей в ДЦ "mac-address-table aging-time = 14400"

Именно это, на мой взгляд, и вносит наиболее весомый вклад в проблему. При выключении вашего сервера коммутатор ДЦ еще 4 часа будет слать вам адресованный серверу трафик. Значение 14400 выбрано, скорее всего, с целью избежать проблем рассогласованности arp-таблицы и таблицы MAC-адресов при импользовании ECMP и FHRP (довольно распространенная проблема в ДЦ-окружении). Именно такое значение по умолчанию имеет срок жизни arp-записи в устройствах cisco, если мне не изменяет память.
Одно из возможных решений - снижение срока жизни записи таблицы MAC-адресов. Это возможно, если в ДЦ вам предоставлен отдельный коммутатор или если вам предоставлен отдельный влан (частая схема в ДЦ), и при этом оборудование ДЦ поддерживает изменение срока жизни записи таблицы MAC-адресов в зависимости от влана (cisco catalyst, если не ошибаюсь, это могут, в зависимости от версии IOS).
Второй вариант - при выключении виртуального сервера автоматически создавать соответствующее правило ebtables или статическую запись в таблице MAC-адресов виртуального бриджа, запрещающее трафик до него (думаю, в той или иной степени это реализуемо). Третий вариант - удаление записи таблицы MAC-адресов коммутатора ДЦ по запросу через какой-либо API на данный момент предстает малореальным. Кроме того, можно подумать о реорганизации схемы подключения вашего сервера к оборудованию провайдера с использованием двух L3-линков. В таком случае на вас не влияют L2-настройки оборудования ДЦ (сроки жизни записей arp-таблицы, таблицы mac-адресов), и ваш маршрутизатор (виртуальный) будет отбрасывать трафик до хоста, для которого нет ARP-записи (т.е. для выключенного).

Вы писали касательно описанного мною выше варианта:

Ситуацию спасает просьба о блокировке атакуемого IP на активном оборудовании, либо можно при помощи ebtables запретить форвардинг пакетов на атакуемый ip-адрес, тогда трафик будет идти просто на основной интерфейс физического сервера, не затрагивая виртуальные сервера. Оба варианта не являются выходом поскольку требуют постоянного присутствия как сетевых инженеров в ДЦ, так и приносят проблемы на физическом сервере, потому и хотелось бы узнать возможно ли в автоматическом режиме со стороны сетевого оборудования избегать таких проблем.

Я пока не понял, к каким проблемам на физическом сервере приводит фильтрация трафика при помощи ebtables. Необходимо понимать, что либо этот трафик (вредоносный, мусорный) каким-то образом фильтрует ДЦ (для этого он сначала должен по каким-то критериям этот злонамеренный трафик выявить, и не факт что его критерии совпадут с вашими), скорее всего за дополнительные деньги (услуга anti-DDoS), либо этот трафик доходит до оборудования под вашим управлением, и тогда уже вы его фильтруете так, как сочтете необходимым.

Резюмируя, на вашем месте я бы:
1) разобрался с трафиком, приведенным в дампе, с настройками DNS-сервера
2) разрешил бы только необходимый для работы проекта трафик при помощи ACL на оборудовании ДЦ
3) настроил бы внятный мониторинг вашего сервера
Практически уверен, что после реализации пп. 1), 2) наблюдаемая проблема бы исчезла. Даже если нет - варианты я привел (изменение L2-настроек оборудования ДЦ, изменение схемы подключения)

UPD2:

Фильтровать никакой трафик нельзя потому, что это не наш трафик, а трафик в сторону клиента, который арендовал VDS. По этой же причине, кого-то блокировать нельзя для входящих пакетов,

Не понимаю, почему нельзя фильтровать клиентский трафик. Так делают практически все. Когда на сервер, арендуемый за 100 долларов в месяц, приходит 10 гигабит/c трафика и больше, как правило, трафик до него блокируется по той простой причине, что расходы на трафик превышают доходы от клиента. Кроме того, часто такой трафик угрожает самой инфраструктуре. Вы задали вопрос касательно анти-DDoS. Что это, если не фильтрация трафика?

Далее, думаю, вам стоит переделать схему аплинка, это наиболее простое и потенциально эффективное решение. Так, чтобы сервер был подключен к маршрутизатору L3-интерфейсом и затем маршрутизировал (а не бриджил) трафик до клиента. Я представляю себе, как бы это выглядело в случае с L3-коммутатором, но тут наверняка проявятся неизвестные мне нюансы реализации поддержки сети в Linux. Рекомендую схему перед применением досконально протестировать.

Наверное в специализированных академиях CISCO готовят специалистов более тщательно и знают тонкости вопросов?

Не уверен.

Наверное в таком случае качество подготовки курсанта для экзамена более высокое?

Опять же не уверен.

Как реально сдать на сертификацию CISCO без спец. обучения и образования, занимаясь только самообучением и самопрактикой?

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

И можно ли таким образом прокачаться до нормального сисадмина, поднатаскаться и сдать экзамены CCENT, CCNA, CCDA, CCNP, CCDP,

Можно.

CCIP,

Уже неактуален.

CCIE, CCDE,

Думаю, при соответствующей упертости и финансовых возможностях можно, но смысл сдавать CCIE, а тем более CCDE, не имея опыта практической работы, от меня ускользает.

CCAr

Думаю, нет.