Трохи роботи .)
Щойно дописав підтримку IPv6 для свого конфігуратора (Django/Python) шейпера (HTB/Linux).
«Воно жахливе, але працює чудово»™ .)
Щойно дописав підтримку IPv6 для свого конфігуратора (Django/Python) шейпера (HTB/Linux).
«Воно жахливе, але працює чудово»™ .)
Викладене нижче перевірялося для 2.6.26 та 2.6.32. Обережно, у 2.6.31, ніби, є нюанси.
Зауважу, що я не дивився у cls_u32.c
тощо — і можу капітально помилятися .)
Отже, спершу трохи про «логіку фільтрування»:
tc filter ... protocol <proto> u32 match u<length> <value> <mask> at <offset>
— ми маємо на увазі зміщення «від позиції НУЛЬ», ядро має на увазі «від початку IP пакета».
Тепер — «демонстративний» (але цілком робочий) скрипт, яким можна фільтрувати влани 22 і 310 у різні класи (мова, як завжди, про linux bridge із сконфігурованим шейпером; при цьому крізь цей комутатор бігають 802.1q tagged пакети):
I’ve decided to make it available after some nice people asked for this.
Now i have no time and, let’s say, health to make it better, so please don’t complain :-)
I guess it maybe would be better to make it available somewhere at code.google.com — i would like to work on this code later, surely.
Anyway. Now — as it now is. With incomplete README:
Шейпер із використанням хеш-таблиць може досить ефективно захищати клієнта від атак; ось дивіться.
Зараз наш конфігуратор шейпера генерує, скажімо, такий скрипт для певного клієнта (фрагмент):
# # Contract I-1082, # connection 606 (0x25e). # # input: /sbin/tc class add dev clients0 classid 1:25e parent 1:fe10 htb rate 96kbit ceil 128kbit quantum 1500 burst 7500 cburst 12500 prio 50 /sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5c match ip dst X.X.133.92 flowid 1:25e /sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5d match ip dst X.X.133.93 flowid 1:25e /sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5e match ip dst X.X.133.94 flowid 1:25e /sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5f match ip dst X.X.133.95 flowid 1:25e
Припустимо, з адреси 173.204.53.138 іде атака на X.X.133.94 — купа якихось пакетів, багато, весь канал клієнта забитий. (Так, адреса реальна, була реальна атака,-)
Все, що нам треба, — вписати потрібний фільтр у потрібну комірку хеш-таблиці:
*subj* :-)
Давно було зрозуміло, що без нормального конфігуратора керувати нормальним шейпером «важкувато», але… все ускладнювала одна обставина — я не програміст (тм).
Чим мене не влаштовують наявні інструменти?
По-перше, всі знайдені вирішують трохи інші задачі, простіші; зокрема, я так і не знайшов конфігуратора для «свого шейпера» — шейпера на мості (bridge/linux), з використанням хеш-таблиць. Для великої кількості клієнтів, для великої кількості IP адрес.
Отже, мені треба було написати щось своє.
Я собі спростив задачу:
Мій шейпер (тм,-) використовує хеш-таблиці; ці таблиці створює вищезгаданий «окремий скрипт», а заповнюються вони вже скриптами, які генеруються автоматично, засобами django, через специфічні представлення даних.
Отже, «схема» містить такі сутності:
Щодо проблеми із HTB шейпером 802.1Q трафіка на linux bridge — це була моя помилка :-)
Я спитав у community@lists.altlinux.org, мене напоумив Sergey Vlasov — дуже дякую!-)
Як сказав Сергій, «передача пакетов в модуль bridge выполняется раньше, чем обработка модулем 8021q». Через це класифікатор просто відкидає пакет як невідповідний фільтру — бо у фільтрі сказано «protocol ip», а ми маємо «protocol 802.1q». Схоже, що достатньо вказати «protocol 802.1q» — після цього адреси (зміщення ві дпочатку пакета IP) «відраховуються» правильно.
Це дає можливість на комутаторах будувати «агрегаційні» шейпери, які оброблятимуть у клієнтських класах пакети клєнтів незалежно від «напрямку» (від належності до певної віртуальної мережі). Причому міграція зі «звичайного» шейпера на комутаторі потребуватиме мінімальних зусиль — треба буде замінити у конфігураторі шаблон «protocol ip» на «protocol 802.1q» (або ж додати ще один фільтр — якщо це справді необхідно).
Увага: жодних проблем з vlan у класифікатора немає, то була моя помилка.
Експериментував і на трапив на таку проблему: не спрацьовує u32 classifier для «міченого» трафіка на лінукс-комутаторі.
Детальніше:
Маємо три лінукси. На одному з них (SW) робимо двопортовий комутатор, на інших (BoxA та BoxB) чіпляємо адреси 172.17.2.10/24 та 172.17.2.11/24, наприклад.
Спершу перевіряємо, що на кросовому шнурку BoxA може пінгати BoxB і навпаки.
Я виклав — дооформив і допереклав (писав її одразу англійською) — свою «колишню» статтю про використання пітонівського модуля SPARK для компіляції «малих мов» і генерування коду на прикладі сканування, парсигу і синтаксичного аналізу простого файла конфігурації шейпера HTB та генерування коду (скрипта shell).
Поклав її як статичну сторінку — тут.