трънки и блогинки

Кръчмарско-мрежова несигурност

Написано на: 16.12.2004 · 7 коментара

Причина за тази разработка са зачестилите случаи на несъответствия между събрани пари за ядене и пиене в кръчма и сметката, която се представя накрая. Явлението може да се дължи на „надписване“, на криво разбран опит за икономия или съчетание от двете.

Цел на текста е да се опита да изложи проблема и да се опита да даде предложение за решението му. За тази цел първо ще се опитам да дам изчистен модел на ситуацията, за да помогна да се откроят някои от спецификите ѝ.

Първо малко история. При считания за остарял клиент-сървър модел в местата за биропиене (известен като самообслужване), имаме заявка и непосрествен отговор на нея по модела известен като FIFO (First In First Out). Негов очевиден недостатък е скоростта, с която нараства опашката (queue) и невъзможността за мултитаскинг и неефективно използване на целия ресурс на сървъра (лафкаджията, бармана и т.н.т.) от един клиент, но за сметка на това простотата на модела не дава възможност за злоупотреби.

Днес използвания модел с келнер, въвежда абстрактен приложен интерфейс (API) за заявките към сървъра. Осмисляйки това трябва да признаем, че използването на думата „сервитьор“ е неточно с оглед клиент-сървър модела, защото той играе роля само на транспортна среда и в действителност нищо не сервира. Ползите от този допълнителен слой са безспорни: избягва се създаването на калабалък (DDoS); дава се възможност за ефикасно използване на възможностите за времеделене и ако транспортната среда се отличава с добра проводимост може да се покрие по-голям обем от клиенти. Този модел, обаче, води със себе си и нови възможности за грешки и злоупотреби.

На първо време са му присъщи всички недостатъци на несигурната транспортна среда и недобри транспортни протоколи:

  • Възможност за прихващане на информацията, която тече по него. Примерно, да видим дали някой вегетарианец, не е размислил или кой каква и коя подред водка пие.
  • Възможност за промяна, добавяне или изтриване на заявка. Примерно може да се добави нарочно или по погрешка заявка за една бира, отговорът на която заявка да бъде унищожен или отклонен.
  • Възможна грешка на информацията в хедърите. Това дава възможност една „Леденика“ да се таксува за „Старопрамен“ и само теоретично обратното.

Ситуацията става съвсем сериозна, когато вземем предвид, че общата сума (дължината на отговора) идва за всички заявки на клиенти от определена мрежа (маса). Отделните клиенти от тази мрежа не знаят какво са заявявали другите, не всички клиенти са налице, когато окончателния отговор пристигне, няма яснота колко и кои са били клиентите, не се знае кой колко е оставял и други ужаси.

Не е въобще за учудване, че при така изложените обстоятелства, с толкова възможни уязвимости са се навъдили доста зли кракери, които експлоатират системата от двете ѝ страни.

Когато се опитах да търся отговор на този проблем първия ми опит за решение бе със средствата на криптографията с някаква аналогия с SSL и TLS. Почнах скромно с хешове и асиметрични шифри, после се оказа, че има нужда и от симетрични шифри, след това възникнаха някакъв вид сертификати и започна да се заражда PKI… Крайното решение бе непосилно сложно, но за сметка на това неработещо.

На този етап аз се отказах от опити да оправям порочна система с надграждането ѝ и реших да променя някои от нещата в нея, които са неправилни според мен. Основна част от решението се състои в пачването на транспортната среда и нагаждането ѝ да изпълнява изключително транспортни функции. Целта е да се елиминира тефтеря на келнера като единствен и при това ауторитативен източник за отправените и получени заявки. Предложението ми е да се въведат съответен на хората брой гейтове (отделни сметки) в мрежата от хора, които да извършват и своеобразен NAT (манджа към клиент преобразувания) и тези гейтове да пазят таблица на отправените и получени заявки. Броят на хора зад един гейт предполагам ще е разумно да не надвишава пет човека, за да не препълним оперативната памет на някоя пияна тиква.

Това решение не е по никакъв начин отговор на всички проблеми, но пък дава някакъв начален тласък в решаването им, който се надявам да събуди други изтерзани за по-добри идеи.

Категория: глупости · проекти

7 коментара ↓

  • Хубаво ми е, когато хората коментират. Чета внимателно всеки коментар и отговарям, когато имам какво да кажа.

  • дафчо на 17.12.2004г. в 01:26ч.

    Ха-ха-ха! Браво Пейо! Осветли ме доста по мрежовите въпроси. Продължавай в същия дух ;-)

  • Андрей на 17.12.2004г. в 06:50ч.

    Пейо, свалям шапка на германците, но те отдавна са си решили този проблем. Ние не сме, защото българските келнери и келнерки ги мързи та ги боли и искат да събират само пари накуп. В Германия, дори и 10 човека да са били на масата, всеки си отива при келнера и си плаща това, което той си е изпил(изял) и си заминава. Така не стават шашми пък се използва предимството да има келнер. Няма такива неща, като оставяне на пари на масата при тръгване, така, че после да се плати накуп. Е случва се да има някой път издънки, но хората ги е малко страх да не ги гепи сервитьора (сервитьорката), че лъжат какво са взели и си плащат всичко точно. Да не говорим, че дори така им е по-изгодно на обслужващият персонал, защото прибират бакшиш от всеки, който при всички положения е повече отколкото ако получат бакшиш от 1-2лева при положение, че сметката е да кажем 50лв. Ама не си знаят интересите тук….

  • дафчо на 17.12.2004г. в 13:31ч.

    А като помислих днес следобед, лежейки на работния ми стол, дано на някой кръчмоадмин, не му дойде на акъла да шейпва трафика с приоритети и другите там мизерии…

  • Ivan на 17.12.2004г. в 15:03ч.

    Ако ще си говорим сериозно, едно просто, и бих казал, елегантно решение на проблема е сметкаджийски тефтер с индиговo копие на всеки лист от него. Келнера записва поръчката и оставя копието на масата. etc. etc.
    Нещо като чекова книжка.
    Не знам какъв е мрежовия аналог на тази ситуация.

  • пейо на 18.12.2004г. в 10:06ч.

    @ Дафчо
    Ми че те го приотизират определено. Бира с картофи, за някой прошляк като нас, пристигат често по-бавно от шиш с гюбек, поднесен за някой дето си имал фирма.

    @ Андрей
    Знайм ний. „Цузамен ордер гетрент“ си е базов немски, но въпроса е как да хакнем сегашната сигуация.

    @ Иван
    То и сега се оставя разпечатка от всяка поръчка с донасянето ѝ, но това не помага като има над 7 човека, защото не може да се следи кой какво е поръчал и какво има в разпечатката.

  • Дойчин на 21.06.2005г. в 17:37ч.

    Чудесен труд! Браво

    Тук е описан само т.нар клиент-dedicate сървър модел, където за дадена заявка един барман обслужва един клиент, подходящ за големи и сложни заявки и малко клиенти. Бих добавил, 4е според мен най-добрият модел в тази ситуация е клиент-сървър с multithreaded сървър, където когато си поръчаш манджата, овер-барман започва да вика различните компоненти на заявката (2 кюфтета, варени картофи, лютеница, 1 бира), и за всеки компенент се хваща свободна лелка от кухнята. Ако свободни лелки не достигат в кухнята притичват бързо няколко. Ако свободните лелки са в повече, последните се оттеглят за да не създават калабълък. Лелките хвърлят на шублера компонентите, а овер-бармана аранжира в подноса. Сега си представете че има не един, а няколко овер-бармани :) cool нали.
    Всяка аналогия с Oracle е случайна :)

  • Георги на 02.11.2010г. в 11:01ч.

    Много интересен материал. Пейстнах го в Първа българска виртуална кръчма (www.kry4ma.com), с позоваване на източника, разбира се :)
    http://kry4ma.com/index.php/topic,1692.msg5694.html#new

    Поздрави и наздраве!