Brownian motion

around the essentials…

 

Archive for the Категорія ‘Адміністрування’

Gmail, IMAP та «мітки» кирилицею

Gmail дає змогу чіпляти до листа різні мітки, які з точки зору протоколів витягування пошти (POP3 та IMAP4) є скриньками. В принципі, інтерфейс Gmail також їх показує як скриньки з листами.

Іноді у різних рецептах (згодувати spamassassin’у теку «Спам» із гуглопошти, наприклад) окремим пунктом програми передбачено витягування вмісту такої скриньки (за допомогою fetchmail, скажімо).

Рішення просте:

poll imap.gmail.com protocol IMAP
   user "nouser@gmail.com" is localuser here
   password 'superpassword',
   folder "[Gmail]/Spam",
   # folder 'from Smith',
   # fetchlimit 1, keep,
   ssl

Але проблема виникає тоді, коли мітки українською (не латинкою, взагалі кажучи). І ніде, чомусь, я рішення не знайшов, саме тому це й пишу.

Справа в тому, що кодування назв скриньок має бути у «модифікованому UTF-7»; це зазначено у RFC 3501 (5.1.3. Mailbox International Naming Convention).

При цьому «службові» скриньки зазначаються як «[Gmail]/Скринька»:

poll imap.gmail.com protocol IMAP
   user "nouser@gmail.com" is localuser here
   password 'superpassword',
   folder "[Gmail]/&BCEEPwQwBDw-",         # «Спам» — обов’язково "[Gmail]/"
   # folder '&BDIEVgQ0- &BCEEMARIBDoEMA-', # «від Сашка» —  *без* "[Gmail]/"
   # fetchlimit 1, keep,
   ssl
(No Ratings Yet)

Трохи роботи .)

Щойно дописав підтримку IPv6 для свого конфігуратора (Django/Python) шейпера (HTB/Linux).

«Воно жахливе, але працює чудово»™ .)

(No Ratings Yet)

Gnuplot — малюємо час на отримання результату від Informix’а

Є Asterisk, через який дзвонить купа клієнтів. Є задача — отримати від сервера Informix (не питайте, бо не знаю) кількість секунд, які певний клієнт може наговорити, дзвонячи на певний номер телефону. Тобто, для спрощення, на сервер іде запит [номерА, номерБ], сервер віддає число (>=0).

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

Хочеться це все якось бачити. Для цього у той скрипт, який бере дані з Informix’а, додаємо двійко рядків, щоб писати журнал, у приблизно такому вигляді:

# час, «номер клієнта», куди дзвонив, залишок секунд, час на отримання
# звісно, всі номери <номерБ> різні:
"2012-04-05 17:29:34.455199","01",<номерБ>",0,"0:00:00.078631"
"2012-04-05 17:46:47.482675","02",<номерБ>",0,"0:00:00.895389"
"2012-04-05 17:48:19.594244","02",<номерБ>",0,"0:00:00.029423"
"2012-04-05 17:53:18.827345","02",<номерБ>",0,"0:00:00.033318"
"2012-04-05 18:02:59.955417","02",<номерБ>",0,"0:00:00.042353"
"2012-04-05 18:05:10.750765","02",<номерБ>",0,"0:00:00.031215"
"2012-04-05 18:05:53.240702","02",<номерБ>",0,"0:00:00.029587"
"2012-04-05 18:06:47.190297","03",<номерБ>",0,"0:00:00.063169"
"2012-04-05 18:56:49.293827","02",<номерБ>",0,"0:00:01.110830"
"2012-04-05 19:03:51.475956","02",<номерБ>",0,"0:00:00.032815"
"2012-04-05 19:42:59.389716","02",<номерБ>",0,"0:00:00.034776"

Так, зараз на всі запити сервер віддає нуль, не зважайте .)

Зверніть також увагу, що у журнал падає, насправді, не 01, 02, 03 тощо, а номер телефону, з якого йшла спроба дзвонити, — але я ховаю номер телефону, ховатиму його й на графіку, і у скрипті нижче для цього буде вжито певних заходів (тобто, це робитиму не я, а awk). Тобто, замість номеру телефону awk підставлятиме «номер клієнта».

На графіку хочемо бачити щось таке (по координаті X буде час):

  • червоними хрестиками — час відгуку;
  • синіми колами — час від попереднього дзвінка;
  • для відгуків > 0.5 секунди біля хрестика писатимемо клієнта;
  • і ще якісь усереднення.

Я нижче поясню, чому це не надто ілюстративно для даної задачі, і що варто було б зробити натомість, але — нижче.

Щоб малювати час від попереднього запиту нам мало цих даних — до кожного рядка треба також додати це значення.

Отже, цей скрипт тягне журнал з іншого сервера, прибирає лапки, додає до кожного рядка різницю між часом запису цього рядка (перше поле у журналі) і часом запису попереднього, замість номерів телефонів клієнтів пише абстрактний «номер клієнта» (кожному наступному номеру телефону — який ще не траплявся — дає наступний порядковий номер) і записує «скрипт» для Gnuplot’а.

Читати далі »»

(No Ratings Yet)

tcpdump: відсіювання HTTP GET

Уявимо себе адміністратором сервера, що перебуває під атакою–відплатою за EX.ua (одразу зауважу, що я не є таким адміністратором, у мене просто гарна уява).

У першу чергу, нам було би цікаво, що саме летить на нас, що саме «валить» наш сайт «із ніг».

Щоб довідатися, є різні способи — скажімо, дивитися журнал веб-сервера, дивитися трафік на сервері утилітою tcpdump чи подібною; можна на проміжному комутаторі відгалужувати трафік і дивитися його tcpdump’ом десь на іншому комп’ютері… Але, так чи інакше, завжди цікаво знайти найбільш універсальний інструмент.

На мій погляд, найбільш універсальним інструментом є саме tcpdump.

Одразу зауважу, що ми можемо «попрохати» tcpdump писати трафік у файл, кожні N секунд закривати файл і починати новий, а на щойно закритому виконувати певну дію (запускати скрипт) — таким чином ми можемо не лише збирати, а й у режимі «майже реального» часу аналізувати інформацію і виконувати певні дії. Це все вміє сам tcpdump, ми маємо лише все продумати і написати скрипти .)

Наприклад, може бути зручним використання утиліти fail2ban; але цей скрипт працює на одному ядрі і на гарно навантаженому сервері (яким, імовірно, є кожен сервер під атакою) почувається невпевнено. Але ми можемо суттєво полегшити йому життя, якщо не змушуватимемо читати журнал веб-сервера, а «згодовуватимемо» вже добре проаналізовану інформацію. Наприклад, із зібраної tcpdump’ом інформації відбирати адреси, з яких надходить більше X [кіло]запитів за одиницю часу.

Отже, tcpdump виглядить («має вигляд» — «виглядить», а не «виглядає»!) досить зручним інструментом. Тож спробуємо з його допомогою ловити лише HTTP GET пакети.

А тепер зазирнемо у нутрощі пакетів »

(1 votes, average: 5 out of 5)

«Малювалка» трафіку на Пітоні

Свою малювалку трафіку (читай тут) я трохи «заребрендерив» — тепер це SPy Bulk Grapher, або ж SPyBG!-) — і виклав git-сховище на github’і: SPyBG.

Сталося це тому (я ж бо ніколи про це якось і не думав), що виникло бажання дописати деякі можливості, а це буде зручніше робити з нормальним керуванням кодом, з розгалуженнями тощо — а думка зробити сховище публічним (не на bitbucket.org, скажімо) вже й не дискутувалася :О)

(No Ratings Yet)

Making RtConfig (IRRToolSet) in Ubuntu

Having used IRRToolSet in elder Ubuntu releases (elder compilers, libraries etc), i finally decided to compile it under 9.10 (yes, previously made RtConfig works under 9.10 too, «but anyway»).

But something goes wrong, with several files — illegal conversion and «bad» syntax and the like.

So, if you’ll run into the same problems, hope this patch will help.

Apply patch as usually (in the directory where IRRToolSet-4.8.5 is unpacked):

$ patch -p0 --dry-run < IRRToolSet-4.8.5-ubu-patch.diff

If everything is OK, remove --dry-run switch and run again.

(No Ratings Yet)

Django-based HTB shaper configurator

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:

» Читати далі… »

(2 votes, average: 5 out of 5)

Шейпер як ефективний файрвол

Шейпер із використанням хеш-таблиць може досить ефективно захищати клієнта від атак; ось дивіться.

Зараз наш конфігуратор шейпера генерує, скажімо, такий скрипт для певного клієнта (фрагмент):

#
# 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 — купа якихось пакетів, багато, весь канал клієнта забитий. (Так, адреса реальна, була реальна атака,-)

Все, що нам треба, — вписати потрібний фільтр у потрібну комірку хеш-таблиці:

» Читати далі — скрипт і коментарі… »

(No Ratings Yet)

Конфігуратор HTB шейпера

*subj* :-)

Давно було зрозуміло, що без нормального конфігуратора керувати нормальним шейпером «важкувато», але… все ускладнювала одна обставина — я не програміст (тм).

Чим мене не влаштовують наявні інструменти?

По-перше, всі знайдені вирішують трохи інші задачі, простіші; зокрема, я так і не знайшов конфігуратора для «свого шейпера» — шейпера на мості (bridge/linux), з використанням хеш-таблиць. Для великої кількості клієнтів, для великої кількості IP адрес.

Отже, мені треба було написати щось своє.

Я собі спростив задачу:

  1. Хай його всі сварять — я використовуватиму django.
  2. Поєднувати в одній схемі «службові» («кістякові») та «клієнтські» класи здалося заважким — вирішив зробити інакше: для генерування «кістяка» шейпера використовуватиметься окремий скрипт, а для конфігурування (генерування відповідного скрипта) клієнтських класів зроблю собі GUI.

Мій шейпер (тм,-) використовує хеш-таблиці; ці таблиці створює вищезгаданий «окремий скрипт», а заповнюються вони вже скриптами, які генеруються автоматично, засобами django, через специфічні представлення даних.

Отже, «схема» містить такі сутності:

» Читати далі — скрипт і коментарі… »

(No Ratings Yet)

HTB/8021q: Це була моя помилка

Щодо проблеми із 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» (або ж додати ще один фільтр — якщо це справді необхідно).

(No Ratings Yet)

Проблема з HTB шейпером 802.1Q трафіка на linux bridge

Увага: жодних проблем з vlan у класифікатора немає, то була моя помилка.

Експериментував і на трапив на таку проблему: не спрацьовує u32 classifier для «міченого» трафіка на лінукс-комутаторі.

Детальніше:

Полігон для тестування:

Маємо три лінукси. На одному з них (SW) робимо двопортовий комутатор, на інших (BoxA та BoxB) чіпляємо адреси 172.17.2.10/24 та 172.17.2.11/24, наприклад.

Спершу перевіряємо, що на кросовому шнурку BoxA може пінгати BoxB і навпаки.

» Читати далі — скрипт і коментарі… »

(No Ratings Yet)

Scapy для полегшення життя :-)

Така історія.

Шукав якось генератор OSPF Hello пакетів для бомбардування «лабораторного макета». Трохи помучився із packEth (я ловив/ліпив/перевіряв пакети, він огинався і зависав) і закинув цю ідею — взяв дві циски на двох кінцях каналу (пакетів мало, але регулярно і чесні, мені цього було достатньо).

Вже кинувши цю ідею, погуглив і надибав Scapy.

Це дивовижний інструмент :-)

Подивіться кілька статей:

Отже, двійко рецептів. Генерування OSPF Hello пакетів та Графік часу відгуків на ping.

» Читати далі — скрипт і коментарі… »

(No Ratings Yet)

Останні публікації

Most Rated

Highest Rated

Теґи

Архіви