татко Крокодил

И ето го описанието на мрежата на openfest. Като цяло изглежда като проект за някой студентски курс по мрежи, няма нещо особено сложно или странно в него, описвам го основно за любопитните хора. Аз ще разкажа за жичната мрежа и топологията, Петко за wireless-а (като намери време и му писне да му мрънкам).

Като за начало, ето генералната схема, в pdf и vsd. Правих схемата на visio, понеже съм му свикнал и още не мога да му намеря еквивалент (а се оказва, че libreoffice вече го отваря).

Топологията беше следната: в “ядрото” (никаква идея защо се казва така) на втория етаж в Interpred влизат кабели до всички нужни зали. Там по принцип има switch на mtel/spnet/каквото-е-там, в който влиза връзката навън и самите зали.
Ние си сложихме там сървъра и един гигабитов switch (core-sw, cisco 3750). В него преместихме кабелите до всички нужни зали, а сървъра (който ни играеше и router) свързахме към техния switch за uplink, и към нашия switch по два порта за streaming vlan-а и за клиентите. В залите, където имахме wi-fi access point-и слагахме managed switch, така че да можем да си занесем дотам двата нужни vlan-а (management и този за потребителите), където имахме камери – също.

Имахме следните vlan-и в мрежата:
600 – management (за нашите си устройства), 10.0.0.0/16
601 – wifi, 10.1.0.0/16 и 2a01:288:4000:32::/64
602 – wired (потребителски портове по switch-овете), 10.2.0.0/16 и 2a01:288:4000:33::/64
603 – streaming (наша техника, пускаща суровите потоци с видео), 10.3.0.0/16
604 – TV (overflow-ове – телевизори и т.н.), 10.4.0.0/16

Толкова голяма мрежова маска за ipv4 при rfc1918 адреси е ок, понеже фоновия трафик от сканирания от internet-а го няма, че да бълваме broadcast трафик постоянно. Имаше проблем с друго, който ще опиша по-долу.
Имахме ipv6 само за потребителските мрежи, по мои наблюдения доста от нашата техника има проблем да си говори с тоя протокол все още, а мотото на setup-а беше “минимални рискове”.
Използвахме нормално per-vlan STP, като беше спряно за VLAN-а на wifi-то, а всички портове бяха в portfast (или какъвто-е-там-еквивалента-извън-cisco) режим. Радвам се, че не ни се наложи да борим цикли или каквото и да е, свързано с него…

Адреси се раздаваха по DHCP за ipv4 и по RA за ipv6.

За да намалим натоварването на външната връзка, със split dns заявките за ip адреса на stream.openfest.org им се отговаряше с адреса на локалния сървър, където имаше същите потоци.

Самия restreaming setup изглеждаше по следния начин:

Трите камери/streamer-и изпращаха до сървъра потоци на голям bitrate/разделителна способност – двете по-малки камери директно HDV потока по UDP, 1080p на 25mbps, setup-а от зала София – 1080p на 5mbps, H.264. На сървъра се reencode-ваха до два формата и се пращаха до големия restreamer (който имаше 10gbps порт) и до локалния сървър, от който също можеха да се гледат. За да няма смесване на този трафик с каквото и да е, всичката A/V техника си имаше отделен VLAN, който беше отфилтриран, така че да не може да влиза в него чужд трафик.

Понеже нямах много вяра и на overflow техниката (и е тривиално да се DoS-не raspberry pi) всичките телевизори бяха в собствен VLAN. На практика, имаше firewall който казваше, че трафик от потребителските мрежи може да излиза само от eth0, не можеше да ходи по нашите vlan-и (600,603,604).

Няколко думи за мрежовата ни техника:
core-sw и sof-pocket бяха две гигабитови cisco-та от netissat (любими switch-ове са ми това, работят идеално, ако се ползват правилно);
quanta беше домашният switch на Мариян, 48-портов гигабитов manageable;
reception-sw беше linksys SWR224G4, който заедно с един SRW2016 (двата от Благовест) ми изпили нервите – не му работеше web контрола, менюто, дето се виждаше по telnet не можеше да настройва VLAN-и, и накрая се оказа, че ако човек се логне, натисне ctrl-z и пусне lcli, там се появява едно доста използваемо cisco-подобно cli, от което всичко става лесно (думи не могат да опишат колко съм благодарен на тоя човек);
Няколко switch-а по залите бяха TP-Link SG-3109 (дойдоха от Unex през StorPool), и направо ми спасиха живота – малки 8-портови manageable, със сериен порт, със същото cli като lcli-то на linksys-а, направо песен за подкарване (чак ми се иска ако намеря такива на нормална цена, да купя 5-6, ще са незаменими за някои събития);
още едно 3750 (от Леков), което отиде за една от залите, понеже дойде в последния момент;
един DLink (от Благо), който замести linksys SRW2016 (пак от Благо), като unmanaged switch за стаята на екипа.

Като цяло крайни потребители се закачаха само в стаите за workshop-и и в team стаята, както и лектора в зала G1 (а трябваше и в другите, ще знаем за догодина).

Следват малко картинки, след което ще разкажа как протече работата на мрежата и какво трябва да направим догодина:

grendel (restreamer-а ни, който ни дадоха Delta.bg):
eth9 – сумарен трафик на порта, през който се stream-ваше за света;

router (eagle):
CPU;
eth0, uplink навън;
connection tracking – статистика по типове връзки;
Power – колко мощност е дърпало захранването на сървъра (не е много смислено, но е забавно);

И от два switch-а, понеже за другите не ми остана време да пусна cacti:
core-sw:
Gi1/0/1, вътрешен порт за потребителския трафик;
Gi1/0/2, streaming VLAN;
Gi1/0/3, зала Пловдив;
Gi1/0/4, зала София (джоб);
Gi1/0/6, зала Бургас;
Gi1/0/7, зала G1;
Gi1/0/8, зала G2;
Gi1/0/9, зала G3;
Gi1/0/10, зала Варна;

sof-pocket-sw:
Gi0/2, рецепция на зала София;
Gi0/3, зала София, десен access point (OFAP02);
Gi0/4, зала София, ляв access point (OFAP00);

Уникални MAC адреси:
1 ноември – 557;
2 ноември – 553;
Общо за двата дни – 769;

MAC адреси по производител, първите 10 (благодарение на Точо, който го изсмята):
Apple 121
Samsung 108
Intel 93
LG 75
HTC 49
Murata 38
Sony 38
Hon Hai 32
Motorola 27
Nokia 24

Вдигането на мрежата мина нормално, само с няколко грешки (основно мои, липсващи vlan-и по switch-ове и някакви промени в последния момент). Кабелите бяха пуснати сравнително лесно, като за това помогна, че не ни беше за пръв път (Явор беше опъвал част от тях по същите места в предишните поне две години), а за останалите имахме достатъчно помощници и клещи. Само един switch беше конфигуриран там на място, тоя за зала Бургас, понеже тогава ни го дадоха (Пешо седя в един ъгъл с кратък списък изисквания от мен и го човърка). Въпреки някои забавяния, мисля, че самата мрежа беше съвсем по график и беше пусната най-лесно, въпреки относително многото хамалогия. Единствените неща, което настроих в петък вечерта в заведението, в което ядохме, бяха IPv6 (понеже не беше толкова приоритетно) и да добавя останалите устройства в icinga-та (която така и не гледахме).

Имахме няколко проблема по време на събитието:

Имаше доста broadcast трафик от arp пакети, за клиенти, които са били асоциирани, после са се разкачили и изчезнали от arp cache, но отвън още се опитват да им пратят нещо. Решението, което сглобих, беше да вадя списък на всички изтекли dhcp lease-ове (чрез някакъв perl скрипт, който намерих в github), и за всички тях чрез conntrack tool-а да трия всичкия им съществуващ state. Не съм сигурен доколко помогна, вероятно тоя broadcast не е бил толкова много така или иначе.

Имаше няколко случая на arp spoof, до които не се добрахме (срам);

В един момент решихме да вдигнем worker-ите на nginx-а на restreamer-а и се оказа, че просто rtmp модула не се оправя с повече от един worker. Това е нещо, което трябва да debug-на за в бъдеще.

И най-идиотския проблем – спираше ни ipv6. По някаква причина от време на време просто сървъра и спираше да отговаря на ipv6 пакети, и да ги route-ва, като все още нямам обяснение защо и не е проблем, който съм виждал където и да е другаде, но със сигурност поне 80% от оплакванията, че не работи wireless-а идваха от android телефони, които просто се опитваха да минават по v6. В списъка ми е да го проверя от какво може да е било, обмислям да изтормозя някой от съществуващите ми v6 router-и и да видя дали мога да го репродуцирам.

За следващия път съм си отбелязал следните неща:

Работещ ipv6 :) (Петко предлага да сме само по v6, но това не звучи като добра идея);
Да отделим хора за NOC, които да следят мрежата и да хващат проблеми (arp spoof-ове и т.н.);
По-подробен monitoring (който да го гледа NOC-а);
Никакви switch-ове и подобни, които отнемат над половин час, за да се подкарат;

(за Варна ще пиша после)

Спи ми се ужасяващо, та ще направя поне бегъл опит да съм кратък.

Бях тия два дни на криптографска конференция в Оряховица. Добре, че Титов си спомни, че имаме да ходим, щото аз тотално бях изключил и в неделя вечер събирах спешно багаж… Пристигнахме към 12 вечерта, пихме с хората до 1-2 и станахме сутринта в 7. “I’m too old for this shit”, както е казал народа.

(Именуването на селищата в България е ужасно. Има Горна Оряховица, Долна Оряховица, Оряховица, Оряхово и Оряховец, например, и ако не помниш за кое точно са ти говорили може да се озовеш на майната си. Това е и без да споменаваме колизиите)

Гледах да не пропускам от лекциите, като някои от тях ми дойдоха много (нещата за дискретния логаритъм съдържаха твърде много математика за заспалата ми глава), но имаше и доста интересни неща. Едното беше e-voting-а и една примерна система („a href=”https://vote.heliosvoting.org”>Helios) – там забавното е, че позволява да сумираш криптирани числа, без да виждаш какви са числата всъщност (лекцията има втора част, но е в ранната сутрин утре, та ще пропусна). Друго беше иде
ята за proxy re-encryption и методите за делегиране на тая възможност, като това
и предното ме накараха да се замисля да проуча ElGamal, понеже и двете се базир
ат на него.

Третото и най-интересно за нас беше searchable encryption, който би имал приложе
ние и при нас. Лошото е, че текущите варианти leak-ват доста информация при заяв
ки, но вероятно схемите подлежат на подобрение.

Имаше и забавление – един introductory CTF с 4 задачи – разделиха ни на два отбора и ни дадоха да решим задачите и да видим кои ще се справят по-бързо. Задачите бяха елементарни (като за увод) – едно декриптиране, една програмка за reverse-engineering (да се извади един ключ), една за exploit-ване (супер лесна) и един
pcap файл, от който да се извади telnet парола.
(около тоя CTF вече съм сигурен, че не мога да чета асемблер, та за reverse-ването си търсих C декомпилатор, с който да я обърна до нещо, което мога да чета. Силно ме е срам).

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

(а самото място е много приятно, сравнително тихо (като няма спорещи математици наоколо:) ) и доста чисто и хубаво направено. Аз очаквах да изглежда древно и по
социалистически и бях доста приятно изненадан.)

(презентацията)

[slide 2 Идеята за тази лекция]

Идеята за тази лекция ми дойде около няколко разговора с различни хора и от нашият опит с правенето на pCloud. Много често ни се случваше да погледнем конкуренцията как е направила нещо и да се ужасим в първия момент.
(а след това да се зарадваме, че се срещу нас има такива хора)

За всичките неща, за които ще говоря има лесни решения – прости като идея и сравнително лесни за реализация, като правенето им трябва да доведе до един по-добър свят.

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

Нищо от това, което ще кажа не е особено ново, гениално или изобщо велико откритие. Всичкото е откриваемо с малко четене в google, wikipedia и от време на време някоя книга. Извинявам се предварително, че нямаме осигурени възглавници за хората, на които ще им се доспи от скучните неща, които ще разказвам.
(ако четете това като текст – нищо против нямам да го ползвате за приспиване)

[slide 3 Защо ние го говорим това]

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

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

[slide 4 Кои сме ние]

Минутка за реклама – ние сме cloud storage услуга, направена правилно. Startup сме, има ни от около година, имаме около 600k потребители и 600TB заето място и правим всякакви интересни неща, за които обаче ще ми трябва тричасов слот, че да ги изброя :)

Стараем се да сме максимално отворени – имаме пълна документация на API-то ни, както и код, който си говори с него. Ние самите за приложенията, които пишем ползваме същото API, т.е. не крием нищо от разработчиците :)

[slide 5 Authentication]

Почти всички услуги трябва да пазят в някакъв вид пароли за потребителите си и да им дават да влизат в системата, за да получат достъп до някаква допълнителна функционалност. Човек би си помислил, че това е изчистено и изяснено и трябва да няма проблеми…

[slide 6 Стандартен метод за auth]

По принцип в повечето случаи влизането в системата се реализира чрез изпращане на user и парола и получаване на отговор/token, с който да работим след това.

Което е лоша идея, понеже паролата ви минава по мрежата в някакъв вид, и не може да сте сигурни дали някой не подслушва или дали някой не се прави на отсрещния сървър.

[slide 7 Правилен метод]

Правилният метод, който използва един прост криптографски примитив, се нарича challenge-response. Има и реализация в самия HTTP протокол, т.нар. digest authentication, както и в много други системи (например SIP). В web твърде рядко се среща, поради нуждата от още една заявка (или поради неинформираността на разработчиците).

Работи по следния начин:
Сървърът ви генерира nonce – някаква стойност, която е произволна, няма да се повтори пак. Смятате криптографски hash в/у нея и паролата и изпращате резултата на сървъра. Той от своя страна може да направи същото изчисление и да разбере, че вие знаете същата парола.

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

Методът е по-бавен от другия, понеже изисква още една заявка (да си вземете nonce, с който да работите), т.е. вкарва още един round-trip. Това не е проблем, понеже това така или иначе не трябва да е особено бърз процес – т.е. колкото по-бърз е, толкова по-лесно може да се използва за brute-force атаки.

Тази схема с малко разширяване дава възможност и клиентът да потвърди, че сървъра има паролата (т.е. да се получи двустранна auth.), което ще ви оставя за домашно :) Ние все още не го реализираме, но е в плановете за светлото бъдеще.

[slide 9 Plaintext в базата данни]

Пазенето на паролите се оказва проблем, който твърде малко хора успяват да решат.

Така като гледам, сме 2014, и все пак се случва някоя сериозна услуга да пази паролите в plaintext. Това в някакви моменти е удобно – lost password функционалността може да ви прати директно паролата по пощата (сигурността на което няма да обсъждам).

От друга страна обаче, поне няколко услуги биват hack-нати всяка година и паролите им попадат в ръцете на лоши хора (или в целия internet). Това е доста неприятно за потребителите, понеже те въпреки съветите на експерти и други заблудени люде все пак използват същата парола на много места, което води до допълнителни пробиви и подобни неприятни проблеми.
(съвсем скорошен пример – преди седмица-две-три източиха на ebay паролите)

[slide 10 Първи лесен (и грешен) вариант]

Първото решение на проблема, което е лесно и грешно, е просто да се съхранява някакъв криптографски hash на паролата – md5 (много-лоша-идея) или sha1 (не-толкова-лоша идея). Това се атакува тривиално с rainbow таблици.

Съвсем накратко, rainbow таблиците са пресметнати таблици с (почти) всички възможни пароли, така че лесно да може да се намери в тях някакъв валиден string, който да отговаря на дадения hash. Също така имат метод за съхраняване на по-малко данни, та по принцип за md5 таблиците са под 2TB, за sha1 има таблици с повечето пароли пак в някакъв такъв размер.

Накратко – лоша идея.

[slide 11 Втори лесен (и правилен) вариант]

Второто решение (и първото работещо) е известно на света от поне 1970та година, от хеширането на паролите в старите unix системи, дори в повечето езици името на функцията – crypt() идва от там (тя дори не криптира).

Идеята е проста, генерираният hash да е на някакъв salt и паролата. Salt-ът се подбира да е различен за всяка парола, и се слага преди получения hash. Така лесно може да се пресметне, но не може да му се генерира rainbow таблица (т.е. ако се генерира, ще трябва да съдържа и възможните salt-ове).

[slide 12 Трети не-толкова-лесен (но правилен) вариант]

Третият вариант, който може да се използва (и който сме реализирали при нас) е да се пази “частичен” hash на паролата (т.е. по-точно пълния state на hash функцията) и някакъв salt, така че да може и да се реализира challenge-response. Това ни отне малко повече време за реализация, но така не пазим пароли в plaintext и можем да реализираме challenge-response, за да гарантираме максимална сигурност на потребителите си.

Много близко е до lenghtening атаката в/у хешове.

( Корекция след самата лекция: Реално погледнато, challenge-response може да се реализира дори с хеширани пароли по предишния начин)

[slide 13 Четвърти (велик и труден за правене) вариант]

И последният метод, който дава най-голяма сигурност, и който не съм виждал реализиран никъде, освен на една лекция. Идеята му е в общи линии като на password-authenticated key agreement протоколите, повечето от които поне доскоро бяха патентовани и като цяло не се срещат особено често.

На база на паролата се захранва един pseudo-random генератор, от който след това се генерира двойка RSA ключове (частен и публичен). На сървъра се дава само публичния ключ, а клиентът няма нужда да пази нищо, понеже от паролата може да генерира същата двойка когато си реши. Автентикацията става чрез стандартните схеми за RSA и дава възможност да се пазите от всичките атаки по-горе, и дава още едно ниво на сигурност – ако някой ви се добере до базата на сървъра, с информацията после няма да може даже да влиза при вас, т.е. даже няма да има нужда потребителите да си сменят паролите.

За съжаление не съм виждал никъде реализация на схемата. Описанието и видях в една лекция на Дан Камински преди няколко години.

[slide 14 Further reading]

И понеже темата е доста обширна, може да потърсите този стандарт – password-based key derivation function, както и да погледнете конкурсът за нови такива алгоритми за съхраняване на пароли, може да са ви полезни.

Специално PBKDF2 показва едно доста важно свойство на всички тези схеми. Важно е проверката на паролата да не е максимално бързо действие, а да отнема някакво малко, но достатъчно време, така че да да се направят brute-force атаките по-трудни.
Самият PBKDF е схема за прилагане на хеш функция много пъти (1000, 10000 или нещо такова) върху входни данни и salt, така че от това да се получи някакъв набор битове, които да се използват или като съхранена парола, или като ключ за нещо друго. Поради големия брой действия, които няма как да се направят по-лесно, лесно може да се сметнат параметри, които да ви дадат нещо като 10ms за извършване на сметката, което да доведе до невъзможност да се правят повече от 100 теста в секунда на един core.
М/у другото, пример за използвана такава схема е WPA при wi-fi мрежите – там ключът за комуникация се генерира с pbkdf2 с 1000 пъти sha1 и essid-то (името) на мрежата за salt. Ако някой е пробвал да чупи такива пароли знае, че върви доста по-бавно, отколкото просто на хешове.

[slide 15 Комуникация]

Изразът с тъпата брадва идва от едно изречение на Дийкстра, “Молив не може да се наостри с тъпа брадва, същото важи и за 10 тъпи брадви”. Подобен израз, който може би е по-подходящ (и за който се сетих на лекцията) е “Манчестърска отвертка” – която всъщност е чук, идеалният инструмент за решаване на всякакви проблеми.

[slide 16 Стандартни неща]

По принцип всичко живо използва JSON и HTTP. Те са бавни протоколи, текстови, с много overhead и не-чак-толкова удобни за parse-ване (добре поне, че има такива библиотеки в почти всеки език).

Да не говорим, че HTTP е мислен за съвсем различни неща от тези, за които се използва в момента.

[slide 17 Трябва алтернатива]

Добре е да имаме алтернативи. Не всичките ни клиенти са browser-и, но всички са принудени да ползват интерфейси, писани за тях, което е доста неприятно и на моменти – много неефективно (но понеже хората са свикнали, вече не обръщат внимание). Най-добрият пример е какво ползват мобилните приложения – все http базирани api-та, а те уж са устройства, които трябва да пестят от батерия и CPU колкото се може повече.

Дори в самите browser-и вече не е това единственият подходящ и ефективен начин – в момента навлизат websockets и webrtc, точно заради това.

(имах въпрос от публиката после защо нещо не съм много оптимистично настроен по темата webrtc, човекът (Лъчко всъщност) се надявал да може да замести skype – понеже това, което реално успява да прави skype е да работи през всякакви мрежи и NAT-ове, което за останалата телефония е сложно и не се справя толкова добре. Webrtc-то още не е стигнало да бори наистина сериозно такива проблеми и вероятно ще му трябва доста време, докато започне да се справя с тях).

[slide 18 Примерен binary протокол]

По тази причина ние сме направили допълнителната възможност да може да се комуникира с интерфейсите ни през просто binary api.
Като казвам просто – то наистина е такова, описанието му се събира на няколко страници, реализацията (която имаме публикувана в github) е 700 реда на C или 536 реда на java, заедно с коментарите. Има много по-малко overhead, и се обработва много лесно на всякаква платформа. Също така в себе си има няколко хитрини, например ако в даден пакет определен string се среща повече от веднъж, съдържанието му се пази само на едно място и останалите са reference.

Разбира се, има и други варианти – в един предишен проект сме използвали protobuf (който се оказа доста удобен), има msgpack и какви ли не още отворени проекти с публични реализации за повечето платформи.
(ползвали сме protobuf за един друг проект и даже аз, дето по принцип не пиша код се оправих съвсем лесно да си parse-вам данните)

[slide 19 QUIC и пътят напред]

И да слезем по-надолу – един от проблемите в съществуващите протоколи е, че осъществяването на връзка е бавно. Нужни са 3 пакета (и 1 RTT), за да се осъществи връзка м/у две точки по TCP, а когато добавим SSL/TLS, добавяме и още 2-3 RTT-та в зависимост от някои настройки на протокола.

Едно от съществуващите решения е разработка на google, казва се QUIC – Quick UDP Internet Connections, протокол, който замества комбинацията от TCP+TLS. Има в себе си всички полезни неща от TCP, като правилните алгоритми за напасване на скоростта и congestion avoidance, но криптирането в него е по подразбиране, и осъществяването на връзка става в рамките на едно rtt, заедно с избирането на ключове и т.н..
Има също така интересни feature-и, като например multiplexing – да се обработват няколко заявки в една връзка (като в SCTP). Друго нещо е forward error correction, да може да коригира грешки в пакетите или изгубени такива по вече пратени данни.

Ние сме в процес на разглеждане на протокола, ако ни хареса достатъчно, мислим да го използваме. В момента има поддръжка в chrome и opera, ако придобие достатъчно разпространение, ще реши проблема и с firewall-ите. Разработката на google е пусната под BSD лиценз, и е сравнително малко код на C++, та би трябвало скоро да се появи и на други места.

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

[slide 20 Употреба на SSL/TLS]

Ако не сте живели под камък в последната година и половина, вероятно сте наясно защо е важно да се ползва криптиране на връзките и по принцип SSL/TLS.
(ако сте, питайте търсачките за Edward Snowden)

Вече повечето услуги имат поддръжка за TLS – отне години и доста лобиране/мрънкане от страна на общността, но е често срещано. Не винаги е реализирано правилно обаче…

[slide 21 Правилна употреба на SSL/TLS]

Първото е, че в твърде много случаи не се обръща внимание на шифрите, които се използват, съответно сигурността на връзката с някои места е почти същата като за без криптография. Пример за това е как преди около година Android смениха списъка си с поддържани шифри/алгоритми и приоритетите им, понеже “в java стандарта било така” (предишния им списък беше взет от openssl). Java 6 е стандарт на около 10 години и в новия е оправено…

Друго важно нещо е т.нар. forward secrecy – това е възможността след осъществяването на връзката двете страни да разменят през DH или друг алгоритъм ключове, които са само за тази сесия и се забравят след нея. Така се подсигуряваме, че дори да изтекат главните ключове на сървъра, то записаната от преди това комуникация няма да може да се декриптира и ще остане тайна.

За заинтересуваните хора, които имат сървъри – на този сайт може да проверите поддръжката си на подходящите алгоритми и шифри, резултатът може да ви е интересен.

И разбира се, SSL/TLS не е панацея, и те имат собствени проблеми (като например heartbleed наскоро).

[slide 22 SSL/TLS Session caching]

За услуги, които имат повече от един физически сървър, който поема криптираните сесии (но на същия domain), има друг полезен момент – да се реализира глобален SSL session cache, който да пази определени параметри, за да не се renegotiate-ват всеки път. Това спестява едно RTT от всяка заявка и определено се усеща.

За целта може да ви се наложи да използвате някакъв backend storage (memcache или redis), в който всичките ви сървъри да пазят тези сесии, но да се подкара не е особено сложно и може да има видим ефект за потребителите ви.

[slide 23 Privacy]

Много услуги правят грешката да разкриват информация за потребителите си, която реално не трябва да излиза извън тях. Например често през някоя функционалност, като lost password или invite може да разберете дали даден потребител е регистриран в услугата.
Това е неприятно, понеже улеснява всякакви атаки в/у вашите потребители, особено ако не сте ориентирани към разпространяване на информацията на потребителите ви и продаването и/им (като почти всички социални мрежи)
(корекция от публиката на лекцията – всички социални мрежи)

Примерът за разкриването дали даден файл (което btw е проблем, който идва основно от дедупликацията в повечето такива услуги) е как един определен service можеше да му кажеш “аз ще ти кача файл с тоя MD5” и той казваше “а, аз го имам, заповядай”. Това за известно време сериозно се използваше за share-ване на файлове без реално да се вижда какво става…

[slide 24 Не всички клиенти са равни]

Изобщо, на моменти имам чувството, че много от интерфейсите са правени от някой, който приятелката му го е зарязала заради някой developer и той сега държи да си го върне. Представям си човек, който стои в тъмна стаичка, пише спецификация и си мисли “и аз на теб да ти го …”…

Няма един правилен интерфейс, един правилен начин, един пръстен, който ги владее и т.н.. Колкото и да ни се повтаря от някакви хора, които нямат въображение, няма да стане вярно :) Има нужда от интерфейси, който да са удобни за различни хора, по различен начин, от различни среди и различни начини на мислене.

[slide 25 Предаване на параметри]

Например, предаването на параметри. При нас параметър може да бъде предаден където ви е удобно – като GET, като POST, в URL-то на POST-а, или в cookie. Даваме ви възможност за прострелване в крака, но от друга страна ви даваме начин да ни ползвате от възможно най-простите клиенти на тоя свят, които нямат POST.

[slide 26 обработка на request-и в движение]

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

Това се дължи най-вече на ползването на HTTP и криви сървъри, и като цяло може да не е така – повечето content може да се обработва в реално време, докато се качва – да се копира на други места, да му се смятат checksum-и и какво ли не още. Не е нужно да караме потребителите да чакат, само защото нас ни е домързяло да направим няколко прости подобрения.

[slide 27 blatant self-promotion]

И оставащата част от презентацията е хубави неща, които са специфични за cloud storage услуги, или “защо ние сме по-добри от останалите”. Не само ние правим тези неща, но май само ние правим всичките.

[slide 28 Thumbnail combining]

Нещо, което пак идва от тъпата брадва на HTTP/AJAX и компания – ако имате да покажете галерия от thumbnail-и, няма смисъл да ги дърпате един по един. Много по-ефективно е да може да ги комбинирате в един голям файл и да ги показвате, докато пристигат.

Конкретните методи за това са доста грозни (thumb-овете, изредени по един на ред в base64 и се декодират после), но си личи промяната в скоростта.

[slide 29 On-the-fly zip]

Нещо, което идва основно от мързела на разработчиците – не е нужно да генерирате zip файл и така да го дадете на потребителя, може директно да му го stream-нете, понеже zip-ът е такъв удобен формат (явно идва от времената, в които е трябвало да може да се пише на лента). Не е единственият такъв, но е пример за как някои неща могат да се случват моментално, вместо да се изчакват.

[slide 30 Rsync-подобен протокол]

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

Идеята е много проста – ако от едната страна имате част от даден файл или негова по-ранна версия, е много по-лесно да копирате само разликите, а не целият файл. Поддържаме го и в двете посоки – и за качване, и за сваляне на файлове, като самата идея не е сложна за реализация, дори и в web приложения. Не ползваме директно rsync протокола, понеже не пасва добре в нашия интерфейс, но сме сравнително близо, и също така за една част от хешовете използваме друга функция, понеже се оказва по-удобна.

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

[slide 31 Видео с напасващ се bit rate]

Една хубава възможност, която доста video услуги биха могли да предлагат – да се напасва bitrate на видеото към връзката ви (т.е. да не праща с повече, отколкото вие може да приемете), което прави възможно да гледате видеа и на доста неприятна връзка.

[slide 32 Файлови операции]

И накрая нещо, което е повече интересно, отколкото важно – интерфейсът за дребни промени по файловете, редакция на място е доста удобен и помага да се пренесат различни приложения и действията им директно към storage услугата.

[slide 33 Други готини неща за в бъдеще]

Тук исках да кажа и други неща, но не ми стигна времето да ги извадя.

Това е един план за светлото бъдеще (в рамките на годината) – да направим end-to-end криптиране на файловете на потребителите, т.е. да им дадем функционалност, чрез която те още при себе си да криптират всичко и да не можем да го четем, както и да са сравнително сигурни, че не не им подменяме или омазваме файловете. Би трябвало всички да го правят – реално погледнато няма причина нещата, които са лични за потребителя да могат да бъдат известни на оператора на услугата, и има доста разработки по въпроса.
Например, има дори няколко paper-а по темата за криптирана база данни – тя стои криптирана на един сървър (който няма ключовете), вие пращате криптирана заявка, сървъра прави някакви сметки и ви дава отговор от вашите данни, който също е криптиран и който само вие може да разберете. Все още нещата са в начални стадии, но са една добра идея за бъдещето.

[slide 34 Отворени сме към други идеи]

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

Приемаме всякакви корекции и идеи – по принцип имаме натрупана работа като за 3-4 години напред, но това още не е успяло да ни уплаши :)

(презентация)

[slide 3 Често срещана практика]

(този трик вероятно има някакво стандартно име, което аз не знам, цялата лекция ми хрумна една вечер докато не можех да спя и така и не се зарових)

Много често ни се налага да генерираме token/код, който да изпратим на някой потребител (по страничен канал), за да се удостовери. Едно често срещано решение е да се генерира нещо съвсем random, което обаче води до пазене на твърде много state и много често не е практически възможно.

[slide 5 просто решение – подпис с криптографски hash/hash mac]

Проблемът има просто решение, чрез криптографски (hash) подписан token, от който може да се извади цялата информация, без да е нужно да се гледа някакъв state. Генерира се тривиално, като до информацията се долепя един HMAC подпис с някакъв secret, който ви е познат на вас.
(hmac е метод за прилагане на hash функция, например sha1. Не е добра идея да се използва директно SHA1 или нещо от същото семейство, понеже подлежи на lengthening атака, но може да се ползва SHA3)

Така тази информация се проверява тривиално, и не изисква да пазите каквото и да е и да могат да ви препълнят някакви таблици, да генерират писания в базата и т.н.

[slide 6 Инвалидация на token]

Схемата има един проблем – няма прост начин да се инвалидира. За това има няколко различни workaround-а:
Имаме timestamp, при който знаем кога изтича token-а и като цяло го правим да е валиден за кратко.
Слагаме в него нещо, което потребителя може да промени и така да го инвалидира (например паролата му, чрез смяната и може да ги направи невалидни).
Можем и да пазим кога последно сме генерирали token и да не признаваме по-стари (или по-нови) такива.
В общи линии последните две неща ни карат да питаме външен източник, когато проверяваме token-а, но пак ми дават възможност да държим много по-малко state.

[slide 8 VERP ]

За всички, които трябва да пращат поща и да знаят дали адресът не е bounce-нал – проста схема, в която пишем в Return-path: адресът, на който сме пратили писмото и по отговорите на този адрес знаем кой точно не се е получил. Към това лесно се добавя един прост подпис, така че да не се получават случайни писма при някакво глупаво изчерпване.

[slide 9 TCP Syncookies]

Вече default на всички tcp/ip стекове. Идеята е съвсем проста – ISN (initial sequence number) на сесията, който връщаме в SYN+ACK пакета представлява hash на secret и още няколко неща, така че когато получим третия пакет от handshake, можем да сме сигурни, че този клиент е искал да се свърже с нас.
(За повече подробности потърсете за SYN flood и защита от него).

[slide 10 client-side session]

Също така можем да спестим място от потребителски сесии – можем да пазим само последен timestamp и нищо друго, а самата сесия да е в cookie при потребителя и да не ни интересува. Така можем да сме сигурни, че ние сме му я подали и че не съдържа нещо, което не сме искали.

Никога повече няма да ползва WYSIWYG редактор, за да си пиша презентациите.

(tldr – може да видите какво ползвам в github и да си го нагласяте по ваш вкус)

Преди rogueconf бях решил, че повече не ми се занимава с libreoffice и кривото писане на лекции, та с малко търсене в google и съвети от хора открих pandoc, който се оказа доста удобен инструмент – от markdown генерира pdf презентации (и reveal.js и други такива бози), като сгъва markdown-а до latex, и от него прави pdf чрез beamer модула. Пример за това може да се види в лекцията ми от rouge2014.

Аз обаче имам навика да пиша и текста на самата лекция, освен презентацията, т.е. процесът ми е “бележки, презентация, текст, и после редактиране на последните две докато стават за нещо”. Дразнеше ме идеята, че трябва да редактирам два файла и че не мога да свържа добре нещата, защото обичам после и да блогна текста.

В крайна сметка стигнах до setup-а от github repo-то горе, който изглежда по следния начин:
В един .pandoc файл си пиша презентацията, и след всеки slide – текстът, в html коментар (който pandoc-а игнорира);
Чрез Makefile (щото съм мързел) от .pandoc файла генерирам:
презентация (с разни параметри, които ще разкажа);
бележки (реално текстът на .pandoc файла, подреден чрез a2ps така, че да се събира добре на landscape A4 листи);
blog post, който казва номер на slide, заглавие и след това текста от коментара (което се прави чрез тъп php скрипт, който си написах).

(едно от големите удобства на makefile и т.н. е, че може да си отворите презентацията с evince, при всяка промяна на файл да пускате make и той автоматично ще reload-не файла, така че да си виждате промените)

За да генерирам презентацията, както аз искам (т.е. какво може лесно да пипнете по кода горе) са правени следните неща:

–slide-level 2 – на колко “нива” са ви slide-овете. Примерната презентация е на 2, тази за pCloud api-то е на 3, като май 3 е идеално за нормално 40-минутна презентация и изглежда много добре с тая тема (Warsaw), понеже така отгоре се виждат секцията и под-секцията. Мисля, че май първо видях Харалд Велте да ползва нещо такова и бая ми хареса, но не бях мислил как го прави.

–template beamer.my – наложи се да пипна стандартния beamer template, щото по default не изкарваше кирилица (за pCloud-ската го използвах и да сложа логото в нея, което беше бая куц процес). Също така там има едно място, в което може да махнете да показва slide-ове за тези, които не са от най-долното ниво (т.е. в примерната презентация да няма “проблемът”, “решението” и “примери”).

-V colortheme:krok – има beamercolorthemekrok.sty в директорията, което е crane color theme от beamer-а, само че със сменени цветове (при мен зелено, в pcloud API-то – странно синьо).

Разбира се, може да си изберете и други теми, на този сайт има матрица с комбинациите от тема и тема за цветовете (темите за шрифтовете са малко и май default-а е ок).

Цялото нещо си има и проблеми – добавянето на лого беше супер мъчително (и стана със странен hack, в който не ми се навлиза), да се влияе на шрифтовете от markdown-а до latex-а е малко сложно, и има някакви странности (например, като сложех коментар веднага след заглавния slide, ми добавяше един празен). Също така ако не знаете latex (като мен) може да ви е доста криво да си правите някакви custom неща, но па google е добър приятел и даже в stackoverflow им texexchange, където хората редовно си задават такива въпроси и може да намерите нещо полезно.

И мина RIPE-SEE-3.

Проведе се в х-л Кемпински, за два дни, беше с малко лекции/workshop-и и доста разговори/networking (видях се с хора, с които не се бях виждал от 10+ години).

Пропуснах първите неща от първия ден, че бях зает да си нося лаптопа на ремонт (и все пак да се наспя), та хванах сесиите след обяда. Първо слушах човека от DT по темата за новата мрежа, която правят (TeraStream) – интересна идея, забавното беше как чак 2011 осъзнали, че мрежата им е остаряла и не става, но па сега я правят както трябва – чист ipv6 (ipv4 е service с тунели отгоре), 100gbps и anycast на интересните услуги. Също така им е хрумнало в адреса да слагат няколко бита, които да играят ролята на QoS битовете, и да раздават няколко префикса на потребител, например един за видео/телевизия, един за voice, един за internet, и мислят как да стандартизират процеса за избиране на source адрес.
RIPE разказаха за различните неща, които правят – конференции и т.н., Erik Vinecke от cisco разказа нещо за мерене на ipv6 deployment-и, което заедно със следващите две неща не слушах, понеже си препрочитах моята лекция.
(чух някакви части от лекцията на Nathalie Trenaman за нейния deployment на ipv6 у тях, и си беше интересно и доста мъчително, Мариян я пита във въпросите що се е мъчила да се занимава с vendor-и, вместо да ползва opensource неща)

Моята (реално на Весо) лекция мина много по-добре, отколкото очаквах, и понеже няма записи малко по-късно ще я напиша на текст и кача заедно с презентацията. Хората изглеждаха заинтересувани, и даже се водеше една от по-техническите на конференцията.

Накрая на първия ден вечеряхме във Весело село (в което никога не бях ходил, и ми стана ясно защо), но храната ставаше, и успяхме даже да направим нещо интересно – да подкараме група на мрежовите оператори (за пореден път), понеже всеки, който питахме там каза “да, бих се записал”. Да видим :)

Втория ден започна с лекция за Ansible (което се оказа някакъв вариант на chef/puppet/cfengine), нищо интересно, след което имаше доста интересна лекция за “Crowdsourcing Infrastructure Geolocation”, т.е. проект, който по различни начини определя къде се намират ip-тата на разни router-и, за да може човек да си визуализира traceroute (note to self, да си оправя всичките DNS LOC записи). Искрено се надявам проекта да успее :)

От следващите неща слушах IXP панела, където от няколко български exchange-а, един чешки и (май единствения) сръбски хората обсъждаха различни оперативни неща. За съжаление не успяха да стигнат до техническата част, но доста дъвкаха for-profit и non-profit моделите, което пак беше интересно.

Следващият слот беше по “Governance” темата и привлече най-страшните въпроси. Първо говори един човек от CERT България (който не беше лектора по програма) и беше в общи линии изяден с парцалите, понеже нищо не знаеше.
После говори Венета Донова за net neutrality-то в Европа и в България, основно за законовите моменти около него – беше разширение и update на лекцията и от openfest (ако не се лъжа), и се получи доста добре.
Последва я Аглика Клайн от Europol EC3 – отдел, който се занимава с техническата част на разследванията, анализа и координиране на операции. В общи линии въпросите към нея бяха “защо да ви вярваме”, “вие сте тия, дето ни тровят най-много живота”, спряхме се на това как детското порно се използва основно срещу доставчиците (имаме си достатъчно такива случаи в България) и т.н., и т.н.. Успя да издържи на въпросите, но се измъкна от някои въпроси. Имаше и момента, че от една страна нямат право да приемат feedback и каквото и да е от хората или фирмите (само от държавите-членки), но от друга страна са пускали по молба на microsoft advisory, да кажат на хората, че XP-то спира да се поддържа.
(после имаше и допълнителни разговори и обяснение как една от причините никак да не ги обичаме е, че ги използват много усилено срещу нас, и че те са от хората, които трябва да се борят за улесняване на security research-а, не срещу него (както са направили в Германия със забраната да се пишат exploit-и), трябва да и пратя на FX лекцията за хардуера, който law enforcement хората ползват и колко е счупен)

Имаше три lightning talk-а, от които единия беше за BGNOG-а (който споменах по-горе), успяхме да стигнем от идея до реализация за около 12 часа.

В последният слот интересните лекции бяха две. Едната беше за RIPE Atlas проекта, и за anchor машините (за които мисля да взема една в нашия datacenter, Мариян се замисли за три), самият проект има лесен начин да се интегрира в monitoring системите ми и мисля тия дни да му отделя малко време. Другата лекция беше сравнителен анализ на internet-а в България, Турция и Румъния, гледан от BGP гледна точка, от Renesys – накратко, в Турция нещата не са добре, при нас и в Румъния са доста по-чисти, като в Румъния са около три пъти по-големи. Удобни сме от гледна точка на латентност за финансови и т.н. институции да си слагат тук нещата, дано успеем да се възползваме.

Като цяло събитието беше страхотно, и трябва да се направи пак (следващото е в Белград догодина, и може би след това пак да се случи при нас), много беше полезно от всякакви гледни точки – и контакти, и свършена работа, и никак не съжалявам за двата изкарани дни. Вероятно ще се сещам още неща и ще дописвам в идващите дни :)

Update: Трябваше да привлачим и Яна на събитието, понеже изкарах накрая поне половин час да давам идеи как да привлекат повече хора – имаше около 220 дошли, и те го считаха за голям успех, но аз си мисля, че даже чистите мрежови администратори в България са поне 150-200 и щеше да им е интересно да дойдат. Едното нещо, което може да помогне е NOG-а, другото – просто да си говорят директно с някакво количество хора/LIR-ове, не през някакви тежки mass mail-вания до адреси от базата им, щото тях никой не ги чете сериозно.

Update 2: Сайт с наземни кабели, за който не знаех (като допълнение на за подводните).

Не че не сте видели от други места, но:
DSA-2896
heartbleed.com
официалния сайт на openssl.

apt-get update && apt-get -y dist-upgrade и ритнете каквото трябва.

(алтернативното заглавие беше fuckfuckfuckfuckfuckfuckfuckfuckfuckfuck)

Update: Сайт, който тества за проблема.
Update 2 command-line test tool.

Това ми е в общи линии лекцията от rogueconf, презентацията може да се свали от тук, записът от тук. Има прилични разлики в това, което говорих, и реално ми се искаше да наблегна много повече на дистрибутирането, но нямах време да се подготвя и да го събера в нормалното време.

(и определено можеше да е по-добре, не става добре да говоря на конференции, където имам занимания и с организацията)

Single points of failure

[за какво става въпрос]

Single point of failure е единичен компонент от система, при чиито отказ цялата система спира да работи.

В системите, които правим/ползваме и са повече от един сървър, на който ни е всичко (т.е. един гигантски SPOF) такива неща пак се срещат доста често.

[авиационен модел]

Това е мечтания модел, който даже съществува в реалния свят. Това е напълно подсигурена система, при която имате главен компютър с един софтуер и един хардуер, backup компютри с два различни хардуера и един софтуер, който е различен от главния, и система за следене и кворум. В самолета освен това има и двама пилоти и всякакви резервни варианти.

[авиационен модел 2]

Това е скъпо. Толкова скъпо, че го правят само за случаи, при които умират хора (т.е. дори и в медицинската апаратура не се стига до такива подсигурявания).

Също така системите стават твърде усложнени, като пример – A380, който е наистина подсигурена система, има в себе си 530км кабели. Цената да се изгради и да се поддържа такава система не е по силите на някой друг.

[три неща]

И три неща, за които няма да говоря подробно.

[Софтуерни]

Софтуерните SPOF-ове никой не се опитва да ги заобикаля, или поне не сериозно. Правенето на няколко независими реализации на дадено нещо рядко е оправдано, отнема двойно повече усилия и се дебъгват два пъти подобни проблеми без да може кой-знае колко да се приложат знанията от едното в другото. Поддръжката на две различни системи за същото нещо и комуникацията между тях правят цялото нещо повече от два пъти по-скъпо и сложно.

А проблемите, които се получават от тях са доста по-неприятни, понеже са лавинообразни – ако на няколко места имате същия софтуер, може да очаквате, че ще се чупи по същия начин и в същото време.

[Meatware]

Човешките SPOF-ове са още по-гадна работа. Известни са още като “Bus factor”, т.е. колко човека трябва да ги блъсне автобус, за да спре да работи даден проект (и в много случаи факторът е 1).

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

Метод за омекотяване е писането на документация, което па всички го мразят.

[цена]

Оценката кога си струва да се вложат средства, за да се избегне SPOF не винаги е тривиална и е за друг вид лекция. Има неща като risk assessment, гадаене по черва на гълъби, хвърляне на зарчета и статистически анализи, които се използват за целта, но много често и хората, които ги предлагат ги объркват…
(който се интересува от проблемите на анализа на риска, може да зачете Насим Талеб)

Като едно лично правило, гледам системите да нямат в себе си нещо, което е наистина трудно за дистрибутиране, или ако го има, да е максимално подсигурено (хубав хардуер, monitoring, резервни части, някакъв вариант да се реагира).

[state]

И нека се хванем с основния проблем във всички тези неща – състоянието, или state, както му викаме.

От машините на Тюринг насам състоянието е нещо основно в това, което правим. Няма система без някакъв state, и съответно една голяма част от решаването на проблемите със SPOF-овете идват от там (иначе просто щяхме да хвърляме хардуер, докато нещата почнат да изглеждат добре).

Искам да го повторя и да покажа, не съществуват stateless системи.

[примерна не-stateless система]

Ето един често срещан пример – смята се, че ако имаме такава схема, то web сървърите ни са stateless, понеже реално са взаимозаменяеми.

От гледна точка на системата те имат два вида state. По-маловажният са заявките, които се обработват в момента (които не се смятат за важни и съответно дори да се загубят, се смята, че може да се повторят. Важният state е един бит, който казва дали този сървър е активен или не, и дали може да обработва заявки.

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

[решения]

Ето няколкото типа решения на проблема.

[do nothing]

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

[backup plan]

Може да не е толкова безсмислен като тоя от слайда :)
Тук решението е да знаем какво правим, ако нещо се счупи. За някои по-малко важни системи например backup plan-а може да е “машината е в гаранция, ако се счупи нещо, обаждаме се на тия от които сме я взели и така”, или “обаждаме се на другарче”.

[cold spare]

Това вече влиза в категорията на решения, които уважаващ себе си админ би приложил. В реалния свят това е да имате резервна гума, някъде в шкафа резервни електрически крушки, или при системите – една готова цяла машина, която може да замести останалите, дискове или някакви други резервни части, за офис – втора internet връзка през някое 3g, която може да се ползва временно, ако наоколо са прекопали някой кабел.

Това е и едно от най-често срещаните решения, понеже доста лесно се прави. От друга страна може да предизвика прилично количество donwtime, докато се “стопли” резервата.

(някъде тук на лекцията се оказа, че има хора, които не държат резервни крушки у тях…)

[hot spare]

Това е също доста често срещано – имате готов топъл spare, който във всеки един момент е синхронизиран с това, което прикрива и при нужда автоматично може да поеме работата на изгорелия компонент.

Това много често се изполва в setup-и с бази данни или подобни неща, при които чистото дистрибутиране (за което ще говоря по-нататък) не може да стане заради CAP теоремата.
(ще намразите cap теоремата след малко)

Тук има един специфичен момент, т.нар. fencing – ако втората система поема работата на главната, трябва по някакъв начин да се гарантира, че главната е спряла и не прави нищо, за да не се стигне до омазване на shared state или нещо такова. За целта има няколко типа решения, някои от които просто спират тока на главната :)

[CAP теорема]

И така, преди да си говорим за най-хубавия начин – да имате N на брой машини, те да вършат едновременно работа и хем да се scale-вате, хем да сте защитени от сривове, да кажа защо това е непостижима мечта…

Теоремата е съвсем проста и гласи следното: една дистрибутирана система може да има най-много две от следните три свойства: Консистентна, винаги достъпна, издържаща разделение.

Консистентна значи, че във всеки един момент една заявка към нея ще даде същия отговор, без значение към коя част от нея се обръщаме, т.е. ако питаме базата “колко реда има в таблица X”, всичките и сървъри ще кажат същото нещо.

Винаги достъпна значи, че дори да са отпаднали някакви компоненти, тя все пак ще продължи да ни отговаря.

Издръжливостта на разделение значи, че не може да се достигне т.нар. split brain ситуация – ако системата се раздели на две части, не може двете да мажат в/у данните и да се получи при тях различна версия.

Това например значи, че не може по някакъв елементарен начин да си направите master-master репликация на базата данни.

[дистрибутиране]

И да си поговорим за мечтата, всичко да е дистрибутирано. Винаги ми се е искало да мога просто да добавям нов хардуер и нещата да работят и на него. Дори за някои неща това сме го постигали …

Това е постижимо, с някои ограничения. Понеже не ми хрумна по-добър начин, ще ви дам няколко примерни системи, които почти успяват да решат проблема :)

[load ballancers + web]

Това е един доста класически случай за повечето сайтове, на които не им се иска да имат downtime. Слагате отпред два load ballancer-а, които знаят кой от web сървърите отзад работи и балансират м/у тях заявките. Това работи много добре, сравнително стандартизирано е и сглабянето му не отнема особено много време. Достатъчно стандартно е, че amazon да предлагат компонентите му като някакъв service.

При отпадане на компоненти системата го усеща и спира да му подава трафик.

RAID масивите са доста близки като идея до това.

[синхронни бази]

По принцип повечето ACID бази данни използват сихнронна репликация, т.е. всяка заявка за писане се счита за завършена (т.е. се казва на клиента) когато всички компоненти от системата са я потвърдили. Това е почти същото като предния вариант.

[hack-ът за eventual consistency]

И има една добавка, като удобен hack при системи, при които има случаи, в които може да се прочетат стари данни, т.нар. eventual consistency.

В общи линии това представлява система, за която операциите за писане са приключили при запис в X компонента, като обикновено X=N/2 + 1. Тогава имаме inconstent четене, което може да чете от 1 компонент, и ако ни трябва консистентно, четем от N-X+1 компонента. Това се използва основно за системи, при които консистетният read е рядка операция.

[sharding + replication]

Това е текущият метод за репликиране на база данни. В общи линии умножавате факторите за на колко искате да разделите данните (за performance) и за redundancy и получавате колко железа ви трябват (в случая са 2X2).

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

(това може да го приемате и малко като спам)

Тия дни писахме една сравнително хубава обява за работа и я пуснахме в jobs.bg и stackoverflow. До тук няма кандидати, та въпросите ми са:

1) толкова ли е зле обявата?
2) хора ли няма, дето да отговарят?
3) На грешното място ли я пускаме?

Ако 2) е вярно, явно ще трябва да почна да правя деца и да ги уча…

Това чак не е интересно.

Ровейки един spam, който един приятел е получил, се загледах в DKIM подписите. Оказва се, че DKIM-а се лови от тривиално replay-ване, т.е.:

Правите си account на някое уважавано място (например gmail, в конкретния случай обаче е abv.bg). Пращате си mail до себе си, който ви генерира едни валидни подписи. Взимате цялото съобщение като source, един ваш smtp сървър, и го пращате на който си искате. От гледна точка на хората, уважавания доставчик е минал през вашия сървър и е пратил съвсем валидно писмо…

DKIM-а не знам кой го е мислил, но ето header-ите му:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out;
	t=1393422571; bh=4dLtPPWnymIO/8L0CLbvGZYxlQ5bZYMBimz0R/Li/JY=;
	h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:DKIM;
	b=RQhl7IakYWwDQb70tpH3nG6V7CFcisAs/AyIO9/g0OpaIFD0jJpm8KbGOZ+UvVpK5
	oeSzu2HLUUFOd6/o+8NHJWHTEwPKf80RZXtnkN4Jp2S/OKKBC5TImFupHy+s1uUgjhD
	9yDf3LZES95JquPBNdYbotBZhc6wd9x1dNTJKCM=

Превод в ефир: Ето мой подпис на ето тези полета, които съм си харесал, които са тривиални за фалшификация.

Това е толкова тривиално, че чак българските spamer-и го ползват. Чак се чудя дали това с валидния DKIM подпис е нарочно или просто така е станало…

Интересна работа. Имаме SPF (описване на валидни източници) и DKIM (подписване на header-и от валидните източници), и нямаме свястна комбинация от двата протокола, която ДА ВЪРШИ НЯКАКВА РАБОТА.
(и разбира се, ако сте с валиден DKIM подпис, gmail и разни други мърлячи ще показват в получения ви mail картинки от външни линкове. Ето как тривиално спамерите ще видят дали ви е верен/работещ/четен mail-а)

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

Проблемът е следният: как да разберем, че не можем да пращаме mail до определено място, като ни дойде bounce от там? Да се parse-ва самото писмо е загубена кауза, понеже няма никакъв ясен формат.

Идеята е сравнително проста: във всеки mail има Return-Path: header, който винаги е първи, и към който се bounce-ва mail-а. Ако всяко съобщение има уникален такъв, може да се познае за кой получател (и може би и за кое съобщение) става въпрос. Самият bounce може да се познае по празният return-path (така че ако някой заблуден spam реши да дойде, да не създаде проблем).
(като всички такива хитрини, и тази е открита от Дан Бернщайн и даже си има нещо като стадарт – Verp)

Има различни начини да се направи, последният вариант, който написахме правеше return-path-а да е във следния формат:
UID_TIMESTAMP_SIGN@bounce.domain.com
където uid беше id-то на потребителя от базата, timestamp си е unix-ки timestamp и sign е sha1 на uid_timestamp_secret, като secret само ние си го знаем и така можем да проверим дали наистина ние сме го генерирали това. За да се избегне един race condition, в който потребителя си е сменил email-а преди ние да получим bounce, може в sign да се включи и оригиналния email адрес, така че bounce просто да не match-не сигнатурата си.
(гледайки сега по стандарта, заради graylist-а може да е добра идея да сменя първото _ с +)

От там нататък просто ви трябва нещо просто, което да засилва цялата поща за @bounce.domain.com към един скрипт, който да прави тривиален анализ на header-ите и да казва “да, тоя mail не е верен”.

Днешния ден може да го броим за полезен.

Изнесохме с Митьо и Петко сайтовете на турнето при мен, подкарахме един setup за ruby приложения (продадох се и аз на хипстърската страна на силата), та там нещата са ок. Остава да припалим (почти за идеята) dnssec на it-tour.bg, ама трябва да видя как може да стане номера (register.bg го предлагат, ама domain-а са го регистрирали през superhosting).

На ludost.net вече има wildcard сертификат за всичко, който се приема (и vasil.ludost.net вече пренасочва само към https). Има валидни сертификати на jabber-а, irc-то, пощенските неща и квото-там-намерих. Тия дни ще си направя и TLSA записи.

Подкарахме https и за initlab.org и cassie.initlab.org, но понеже там Петко взе безплатните сертификати от startssl, трябва да почакаме един ден, докато се update-не OCSP-то.

Около това си преписах скрипта, който генерира config-а на apache на marla (за всички сайтове да има https и v6 vhost-ове). Следва да разцепя още малко конфигурациите, за да могат да разделя .ludost.net нещата от другите и да форсирам https за *.ludost.net. Някъде по пътя – tlsa :)

С това може да борим hackaton-а за thedaywefightback.org за приключен.

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

Около всякаквите неща на конгреса и това, съм си формулирал следния план за действие:

В рамките на следващите 3 месеца:
Ще подкарам dnssec за domain-ите си (вече има за ludost.net, остава да се разбера с registrar-а ми да ми сложат DS записите);
Ще сложа SSHFP и TLSA записи за каквото трябва в dns-а (което ще иска да накарам някои хора да си upgrade-нат bind-овете);
Ще се погрижа за сертификати за всичките domain-и при мен (има за ludost, може би няма да са от cacert);
Ще форсирам tls на входа на jabber сървъра (тва е въпрос на един рестарт);
Ще подкарам tls на каквито ftp неща има при мен;

След това, поетапно:
Ще спра не-tls irc-то, на нормалния порт ще има съобщение “закачете се по ssl на 6697”;
Ще направя http-то да връща само redirect към https, по същия начин за ftp-то;
Ще отрежа на jabber-а не-tls комуникацията с други сървъри;
Ще махна не-криптираните варианти на pop3, imap и smtp submission;

Още не знам какво ще правя със самото междусървърно smtp и още една-две услуги, които търкалям.

И малко по работа (почти “минутка за реклама”).

Пуснахме си новия проект – pCloud – преди няколко седмици. Представлява storage на данни, с хубаво API и клиенти.

Около него пускаме и кода на част от клиентите – тези за desktop операционните системи, като той се състои от две части – нещо, което може да mount-не файлова система, и нещо, което графично да си говори с него. Кодът може да се намери в github, в момента е в сравнително beta състояние (т.е. вече файловата система не успяваме да я накараме да гръмне лошо). Целия код там е под BSD лиценз.

(докъде стигнах, да качвам код в github)

https://github.com/krokodilerian/trafstat.git

Система за събиране и анализ на трафик, базирано на tcp retransmit-и и bgp routing таблици.

Аз я използвам на няколко места да си анализирам трафика и да го балансирам откъде да минава. Имаме пусната една версия на ts.hahpss.com, на която може да гледате от един български сайт как изглежда трафика към вас.

Системата за мен е много по-хубава от различните варианти с ping от време на време (smokeping, mtr и т.н.), понеже е върху целия трафик на web сървъра, който реално потребителите виждат, а не нещо, което може да има различно поведение и различни shaper-и.

Кодът е леко допипнат, за да става за публична употреба, но има още доста да се желае (например трябва да сложа един __packed__ атрибут на една структура, дето пращам по мрежата). В момента може да се каже, че е в works-for-me версия, но мисля, че повечето админи биха се справили да го подкарат при себе си. Изисква да може да си пипнете web сървъра и да може да вземете отнякъде read-only BGP feed.

Състои се от няколко компонента:

– модул за nginx, който за всеки request взима колко трафик е направен, колко е било mss-то на връзката (за да може да се изчисли броя сегменти) и броя tcp retransmit-и, и го праща до един централен сървър по UDP. Мариян е навит да напише същия модул за apache.

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

– cron script, който попълва в базата данни за всички router-и, за които знае системата routing таблиците им (prefix-и и aspath-ове).

– друг cron script, който на колкото-време-му-кажете хваща лога на демона, сдъвква го и вади заявки, с които да запише трафика по префикси и типове.

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

Има и някакви визуализиращи неща, които ще се появят по-късно.

Не съм решил какъв да е лиценза, защото и вътре има няколко неща, които не са мои (bgpdump от ripe), приемам идеи.

И още един интересен работен проблем.

Имаме следната стандартна задача – да log-нем колко трафик е направил даден HTTP request. Тривиалният начин:

while ( (len=write(...))>0  ) total+=len;

т.е. колкото сме подали на kernel-а, толкова.

Това води до проблем, когато срещу нас стои някой от т.нар. download manager-и. Те дават възможност даден файл да бъде точен с няколко паралелни връзки. Това се реализира с Range header-а в HTTP, и ако например искаме да свалим даден файл от 1MB с две паралелни връзки, едната трябва да подаде range от 0 до 524287, втората – от 524288 до 1048576.
Разбира се, авторите на тоя тип софтуер са идиоти, и вместо това подават request-и от 0 до края и от 524288 до края на файла, като просто прекъсват първата връзка, след като са получили каквото им трябва. Това обаче остава връзката с пълен буфер от данни (в ядрото), който в моя случай се мотае м/у 1MB и 2MB, което от своя страна в повечето случаи брои по 2MB отгоре на всеки такъв request.

Решението на този проблем е едно ioctl:

while ( (len=write(fd, ...))>0  ) total+=len;
ioctl(fd, SIOCOUTQ, &bytesunsent);
total-=bytesunsent;

… което е прекрасно, докато човек не тества с нормална връзка при по-голяма латентност и не открие, че в разни web сървъри всъщност като напишете последните данни и стигнете до логването (т.е. викнете ioctl()-то), буферът е все още пълен и ще log-нете по-малко трафик, отколкото е направен.
На теория можем да хванем момента, в който буферът е празен със SO_LINGER опцията – тогава close() ще block-не, но това не ни решава проблема, понеже пък след това file descriptor-а няма да го има. Има друго решение – с shutdown(), read докато получим 0, и тогава да видим тия данни, което обаче е криво за писане и вероятно има някакъв проблем.
В крайна сметка моето решение е “проверявай буфера само на връзки, които не са завършили нормално”, и това дава горе-долу верни стойности. Някой да му идва по-добра идея?

Пишех малко код (опасна работа), съответно стигнах до момента, в който трябваше да изкарам някакъв адрес (ipv4 или ipv6) в четим вид. Тръгнах да ровя и открих, че има inet_ntop(), което поддържа и двете. Без да чета внимателно, написах следното:

struct sockaddr *saddr;

inet_ntop(saddr->sa_family, saddr, msg.ip, 255);

Това за всеки, който е погледнал по-внимателно man-а е ясно, че не работи – трябва да подам не sockaddr, а структурата вътре, я in_addr, я in6_addr – което е криво, понеже трябва да напиша няколко if-а и т.н.. Питах google, не намерих нищо особено полезно, след което отворих Unix Network Programming на Stevens около тая функция и какво открих – човекът е описал тоя проблем, и даже е написал sock_ntop(), който работи директно със sockaddr структурата (и реализира ония няколко if-а).
Ето примерен код как се реализира.

Въпросът е, защо в libc я няма тая функция? Мрън, книгата е вече на 16 години, все някой можеше да се сети и да вкара нещо такова.
(ако някой все пак се сеща за нещо такова в libc, да каже)

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

Kristofer Kielhofner е намерил гаден проблем в Intel 82574L мрежовите карти, който с пакет, в който на специфична позиция пише 0x32 просто crash-ва картата (бъгове в power management-а вероятно), в internet storm center-а има по-съкратена информация.

(това е мрежовата карта по доста от сървърните дъна от последните години)

Решението, което аз виждам (и което вече пуснах) изглежда така:

for i in `cat list-of-ips`; do  do ping -i .001 -c 128 -p 34 -s 1110  $i ; done

(броя пакети съм си го харесал да е толкова, може и да няма нужда от толкова много)
(съответно, смяната на 34 с 32 го прави tool за трепане на машини)

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

Update: до тук аз поне не съм успял да го reproduce-на (както и при някои други хора), та може да е сравнително изолиран проблем.
Update 2: Press release от intel по въпроса.

Появи се въпросът какъв ми е процесът на писане (Стефан ме пита, и той ще пише по темата). Донякъде като продължение на post-а ми работния ми процес.

По принцип широко разпространено е грешното мнение, че ползвам някакъв сръбски bullshit генератор, който ми пише post-овете. Това не е вярно. Македонски е.
(open up with a joke, they said)

По принцип пиша няколко типа неща – blog post-ове, документация (понякога се чувствам като единствения такъв човек на тоя свят), лекции/презентации и описания на системи, които са донякъде като документация.

Първо, аз съм мързелив, съответно много рядко сядам да се мъча в/у нещо. Работя на тласъци (хаха), редовно се прекъсвам с четене на поща, писане на някого, четене на 9gag, къпане и т.н.. Голяма част от идеите и мислите ми идват, когато не съм си пред машината или като правя нещо коренно различно – съответно просто идва момент, в който сядам, написвам всичко което ми е хрумнало и ако е достатъчно, минава редакция и го качвам, ако не, се захващам с други глупости. Повечето ми blog post-ове са написани на един път, защото съм издъвкал цялата идея в главата си предварително.
(например това го захващам за трети път)
(най-много неща ми се изясняват сутрин, докато се къпя)

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

Ако работя в/у нещо по-голямо, си правя план преди това (който рядко си прилича с крайния резултат), служи повече като място, на което да си водя бележки за какво трябва да говоря. Пиша го по максимално прост начин, като под-точките се отбелязват с 8-интервални tab-ове, като в C код – така ако твърде много се забия в нещо, лесно мога да го видя и да го премисля или изнеса в отделна точка/абзац.
Планът ми помага най-вече защото паметта ми е основно асоциативна и трудно мога да си спомня всички неща, свързани с дадена тема без някакво подсказване – например ми е трудно да изброя книгите, които съм чел през годината, но ако ми кажете автор/заглавие, мога да кажа за какво става въпрос в тях.

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

При писането и редактирането на текст се старая да следвам правилата на Оруел за писането, от Politics and the English language (някои хора твърдят, че ползвам твърде много passive voice, но според мен там, където го ползвам си е правилно).

По принцип обсъждам бележките си с различни хора, най-вече за да не напиша някоя голяма глупост (помага това, че познавам няколко много цинични човека, които никак не се притесняват да ми обяснят колко съм тъп) и за да имам някакъв frame of reference за публиката. За по-сериозните неща правя поне една редакция, за да оправя текста (основно да махна неща, от които няма нужда), за някои давам текста да го прегледа някой друг. Повечето ми лекции са минавали такава редакция, повечето ми blog post-ове – не.

От известно време използвам git, за да си държа в него лекциите и нещата към тях (даже от време на време давам на някой достъп, така с Яна правихме бележките за лекцията за депресията), но още не съм го използвал за нещо повече от backup и sharing система. Използвам gvim с голям шрифт за писане на текстовете, vim в терминал за писане на бележките, както и вградения spell checker. Имам spell checker и в browser-а и понякога си хващам грешките като paste-вам там.

Като обобщение – аз съм мързелив, разхвърлян и несистемен, направо е чудо, че успявам да свърша нещо.