caxapa.ru :: Интересно, а есть аппаратные firewall, которые прямо в разрыв сетевого кабеля втыкаются?

Evgeny_CD, Архитектор (27.06.2009 15:44, просмотров: 31873)

Интересно, а есть аппаратные firewall, которые прямо в разрыв сетевого кабеля втыкаются? Чтобы от наиболее страшных атак с точки зрения ОСи защиться. Тот же sync flood. Короткими пакетами по 100 мбит сети любой современный писюк гасится на ура. Ибо этих пакетов в 100 мбит Ethernet может быть под 100к/сек, что явно перегрузит программный стек. А так постепенно определяем статистику левых адресов (с которых странные пакеты прут постоянно), и ставим на них бан прямо в коробочке. Пакеты из сети выкачиваются, коммутатор не засоряется, и если у них адрес совпадает с таблицей бана - умирают прямо в коробочке. Алгоритмы умеренной сложности, стоимость FPGA, подходящей под это дело, баксов 50-70.

Ответить

- Я тут неспешно думаю над проектом одного специфического маршрутизатора, который будет с приходящего линка 100М раздавать инет по портам свича. Маршрутизатор будет, конечно, L3. Правда, он будет не полноценно 100RX+100TX, а Rst7(141 знак., 01.07.2009 16:38)
  - Хм... Надеюсь, *NIX в качестве среды исполнения основного кода Вы уже откинули? Evgeny_CD(140 знак., 04.07.2009 13:59)
    - Неа. Core I7 - это дорого и круто. Бинарный поиск по таблицам правил рулит :) 10к правил - это всего-то примерно 13 сравнений ;) - Rst7(04.07.2009 14:12)
      - Согласен. После того, как я сформулировал свою идею, я сам начал активно курить все свои книги по теории алгоритмов, раздел поиск :) Но ту не не все так просто. Рассмотрим реалистичную задачу - для 100к пакетов в секунду принятие решения по таблице 10к Evgeny_CD(1562 знак., 04.07.2009 14:53)
        
        Может в таком случае =AlexD=(297 знак., 04.07.2009 19:20)
        
        Задача поиска по массиву там наиважнейшая. От нее все скорости зависят. Если ориентироваться на то, что правило "резидентно" висит в плисине, то получится плохо масшабируемая система: чуть больше правил - и "не лезет". А так все красиво - с ростом Evgeny_CD(240 знак., 04.07.2009 19:26)
        
        Самое грамотное там - сделать аппаратную поддержку поиска на плисине + SDRAM. Т.е. есть некий блок, которому задаешь вопрос - а какие есть правила в отношении такого объекта (IP адрес, порт и т.д.). Несколько мкс - и тебе приходит ответ - вот такое Evgeny_CD(1006 знак., 04.07.2009 19:44)
        
        Вы преувеличиваете количество накладных расходов. Надо просто аккуратно написать процедуру поиска. И не использовать STL ;) - Rst7(04.07.2009 18:39)
        
        STL я вообще использую как абстрактно-теоретическое пособие по написанию программ :) - Evgeny_CD(04.07.2009 18:43)
        
        Есть еще одно решения - B-деревья, а которых в узле сходится не 2, а более листьев. Ну и работа с памятью большими блоками - по странице, как я и излагал ранее. - Evgeny_CD(04.07.2009 14:55)
- Не firewall, то тем не менее: - vmp(29.06.2009 09:04, ссылка, картинка)
  - Идеи у народа вполне здравые. Два Virtex|Stratix - это сильно. Вообще по структуре напоминает то, о чем я говорил. DSP в данном случае - это быстрая молотилка с DMA. - Evgeny_CD(04.07.2009 14:02)
- Фсе украдено до нас :) -> TCP Offload Engine. Самое интересное: Evgeny_CD(1184 знак., 27.06.2009 23:37, ссылка)
  - Судя по всему, весь вопрос тут с размере и скорости работы CAM - Contet Addressable Memory. Вот почему народу пришлось на Stratix/Virtex идти. Evgeny_CD(1425 знак., 28.06.2009 01:15)
    - А зачем считать CRC, если IP попадает в бан? Два варианта, либо это точно он, либо битый пакет. - Т.Достоевский(28.06.2009 01:45)
      - С этим согласен. Но такое упрощениние не сильно упростит всю задачу целиком. - Evgeny_CD(28.06.2009 16:49)
        
        Хотя :) Если подумать !седалищем, можно придумать алгоритм принятия решения о валидности пакета, достаточно быстрый и несложный, чтобы его впихнуть в FPGA. - Evgeny_CD(28.06.2009 21:59)
- AlphaShield ->, но его производительность не понятна. Думаю, там софтовое решение - камень с двумя Ethernet. CF какой-нибудь. - Evgeny_CD(27.06.2009 16:49, ссылка)
- Если сделать на FPGA ? - Ruslan(27.06.2009 16:43)
  - А иначе и никак. 100к пакетов/сек процом не разгрести. - Evgeny_CD(27.06.2009 16:48)
    - Тогда цыклон III. Два модуля Triple-Speed Ethernet, набортное ОЗУ, модуль управления. Ну еще мелкий софт проц. для управления. - Ruslan(27.06.2009 17:12)
      - И в какой это камень влазит? Пока хотя бы со 100 мбит разобраться бы :) Софт там тоже довольно нетривиальный (т.е. совсем в набортные блоки памяти может и не поместиться), и буферный SDRAM точно потребуется. - Evgeny_CD(27.06.2009 17:22)
        
        EP3C25. :) У меня NIOS-II + один tse + DDRAM + COM + JTAG заняло 16 тыс. ячеек. - Ruslan(27.06.2009 17:28)
        
        А в каком корпусе EP3C25 юзаете? - Evgeny_CD(27.06.2009 23:40)
        
        будем в PQFP240 - Ruslan(28.06.2009 11:04)
        
        Уважаю буржуинов за системный подход :) Из 240 лапок - 148 твои (EP3C25). Хочешь перейти на более толстый кристалл - EP3C40 - только 128 сигналов. Так в EP3C40 чего только не засунешь - но по лапам ограничение. Начнешь экономить - DDR контрллер по Evgeny_CD(963 знак., 28.06.2009 14:43)
        
        Кстати, контроллер DDRAM и TSE каждый занимает ресурсов больше чем проц. NIOS-II. Ruslan(29 знак., 27.06.2009 17:31)
        
        TSE - шо це таке? - Evgeny_CD(27.06.2009 18:33)
        
        Triple-Speed Ethernet. - Ruslan(27.06.2009 18:50, ссылка)
        
        Чет у меня сегодня сайт Альтеры не открывается. Сколько он там элементов хавает? - Evgeny_CD(27.06.2009 19:12)
        
        Есть еще OpenMAC core 10/100 MBit. Но меньше потребляет ресурсов. Ruslan(27.06.2009 19:34)
        
        Т.е. получается, что в твой EP3C25 можно упаковать еще одит TSE, и как раз место на железный суппорт всяких операций останется? Сильно! В дижикее EP3C25Q240C8N 42 бакса стоит. - Evgeny_CD(27.06.2009 19:57)
        
        Или два OpenCore 10/100 Ethernet MAC. И еще eCos :))) - Ruslan(27.06.2009 20:00)
        
        Чет как-о уж больно хорошо все в Альтеру упаковывается. Даже подозрительно. - Evgeny_CD(27.06.2009 20:08)
        
        "OpenCores 10/100 Ethernet MAC -- свободно распространяемый модуль, реализующий Ethernet MAC с интерфейсом Avalon, которому для счастья нужно только PHY". Ruslan(163 знак., 27.06.2009 20:14)
        
        :)) А еще можно свой IP модуль с DMA написать. Чтобы процессор не грузить. CPU настраивает режим работы, указываеть адреса откуда писать и читать и все. IP модуль работает независимо. - Ruslan(27.06.2009 20:12)
        
        А без DMA эти контроллеры как бы и нафиг не нужны. То-то я смотрю - открываешь IP от Cast - все честно, но ресурсов раза в два больше, чем ты описываешь. - Evgeny_CD(27.06.2009 22:16)
        
        В понедельник покажу раскладку по ресурсам своего проекта. - Ruslan(27.06.2009 22:46)
        
        Принято :) - Evgeny_CD(27.06.2009 22:51)
        
        Вот основные затраты. Остальное показать не могу :)) Ruslan(29.06.2009 07:49)
        
        Какой-то толстый процессор получился. С плавчукой что ли? - Evgeny_CD(29.06.2009 13:09)
        
        Нет. обычный такой проц. Который должен потреблять 1400-1800 LE + JTAG 300-400 LE. Еще оптимизация по скорости. Ruslan(21 знак., 29.06.2009 13:30)
        
        Хм... При штатной ~80 Мгц - хорошо вы его турбировали! Сколько кеша? - Evgeny_CD(29.06.2009 14:09)
        
        Алтера обещает до 165 MHz. :) Кеш по дефолту 4К код, 2К данные. - Ruslan(29.06.2009 14:38)
        
        Эт что, 165 DMIPS что ли? А что в жизни с таками небольшими кешами показывает? По дристонометру, например. - Evgeny_CD(29.06.2009 14:44)
        
        Нет,165 МГц рабочая частота. - Ruslan(29.06.2009 15:18)
        
        2 такта на операцию? - Evgeny_CD(29.06.2009 15:20)
        
        Вот картинки. Ruslan(240 знак., 29.06.2009 22:15, ссылка)
        
        Хм... Это я упустил. 195 MIPS Cyclone-III, пусть и от быстрого кристалла (-6) - это сильно! Пусть даже 150 будет в реале на медленном дешевом кристалле. Вау! В купе с логикой на шине данных.... - Evgeny_CD(29.06.2009 22:27)
        
        Не знаю. Знаю что у меня проц работает на чатсоте 150 МГц. А сколько DMIPS считать надо - Ruslan(29.06.2009 15:38)
- При размерах атакующей сети до 10к машин (10к IP адресов) размеры бан таблиц не так уж и велики. Все на кристалле поместится. - Evgeny_CD(27.06.2009 15:54)
  - Если полностью аппаратное решение не самоцель, масочное ПЗУ тоже, то в дешёвых роутерах для дома/миниофиса уже достаточно давно есть поддержка черных списков. Кроме того, если Вы не делаете оборудование для провайдеров, то такие задачи не актуальны. Vit(222 знак., 27.06.2009 16:49, ссылка)
    - Как я уже тут долго распинаюсь, полностью программное или полностью аппаратное решение никогда не будут эффективными. Только симбиоз. - Evgeny_CD(27.06.2009 16:55)
    - Я скорее думаю о защите для простого сервера, который выставлен в инет. Специальные тарифные планы с поддержкой защиты от DDoS атак на уровне бекбона провайдера стоят очень дорого. - Evgeny_CD(27.06.2009 16:53)
      - У моей материнки в чипсете заложен "почти аппаратный" файрволл. точно то, что дурная работа по подсчёту CRC делается там на аппаратном уровне. что ещё - можно спросить у NVidia - Vit(27.06.2009 17:52)
        
        CRC - это часть засады. Нужно иметь нехилые таблицы в памяти - типа можно ли этому пакету от этого адреса идти. Nvidia аппаратный ускоритель - хорошо, но не все. - Evgeny_CD(27.06.2009 18:41)
      - "простой" сервер на 10К машин? а насчёт DDoS проблемы могут быть по-любому, но они тем и отличаются, что бодают не с одного IP/MAC, а с туевой хучи. В принципе, с помощью DummyNet давится, но эффективно лишь при наличии белого списка. Кстати, на днях Vit(38 знак., 27.06.2009 17:36, ссылка)
        
        Хм... 10к атакующих машин - такого ботнета вроде пока еще не было. 6 вроде макс. из зарегистрированных. Сколько у меня будет "белых" юзеров, и откуда они - мне неведомо, вариант с белым списком не поможет. Еще раз. Если нас гасят пакетами по 64 байта, Evgeny_CD(203 знак., 27.06.2009 18:40)
        
        DummyNet это эмулятор плохой связи. Для IPFW устанавливается правило - все запросы с длиной менее N, пинги и подобная фигня отправляются в узкий DummyNet Pipe (или разные пайпы) - шворку с заданной убогой пропускной способностью - там просто заданная Vit(128 знак., 27.06.2009 18:58)
        
        Гы-гы, т.е. мы просто увеличиваем шансы гадов на успех :) Втт пришла к нам куча пакетов. Есть наши, и есть пакеты гадов. Пакетов гадов намного больше. Сузив полосу для всех, мы отрежем пропорциональное число пакетов. Т.е. белые пакеты тоже порежутся. - Evgeny_CD(27.06.2009 19:11)
        
        Внимательнее читайте, пожалуйста. Я не писал "для всех пакетов". Vit(809 знак., 27.06.2009 20:05)
        
        И все равно толком это проблему не решит. Ок, выкинули мы мелкие пакеты - чуть легче стало. Флудить нас теперь можно только пакетами по 256 байт и более. Но их все равно десятки тысяч в секунду. Приняли мы пакет. Evgeny_CD(237 знак., 27.06.2009 22:20)
        
        ;) Нельзя объять необъятное(С) Vit(885 знак., 27.06.2009 23:40)
        
        В общем, я согласен, что практический диапазон доступной ширины полосы на порт даже в data center лежит где-то между 100 и 1000 мбит/сек. 100Мбит/сек, судя по найденному, можно расфильтровать на современных дешевых FPGA ценой до 100$ включительно, а вот Evgeny_CD(429 знак., 28.06.2009 00:42)
        
        Я когда-то администрил Linux Router, который бутился с дискеты. Там NAT с учетом трафика по группам юзеров был верхом достижений :) Шейпингом точно не пришлось заниматься. - Evgeny_CD(27.06.2009 20:07)
        
        Именно поэтому и была поставлена фряха;) - Vit(27.06.2009 20:41, ссылка)

Средства и методы разработки