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

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

Гледах “The imitation game”, след което прочетох “Alan Turing: The Enigma”(по която уж е правен филма) и крайното ми мнение е, че не струва:
– Ненужно драматичен е, през цялото време основната ми мисъл беше “тука прекаляват”;
– Избрали са за ролята на Тюринг актьор, който играе аутисти и психопати (и докарва още повече драматичност);
– Сериозно се различава от реалността (има доста неща в wikipedia по въпроса) – например Enigma-та е счупена от поляците, след което англичаните доразвиват идеята, като ролята на Тюринг е сериозна, но не е като на единствен човек, който е бутал цялото нещо;
– Споменали са само малка част от работата му, криптоаналитичните му занимания не са по-важни от машината на Тюринг и приносът му в създаването на информатиката (“Computer science” звучи по-подходящо, ама “компютърни науки” не изглежда добре). Силно препоръчвам на всички програмисти и изобщо компютърджии “The Annotated Turing: A Guided Tour Through Alan Turing’s Historic Paper on Computability and the Turing Machine”, обяснение на paper-а му по темата изчислимост, в който могат да се видят в общи линии за пръв път различни основни програмистки похвати.

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

А днес гледах “Citizenfour”, на чиито принцип е трябвало да направят филма за Тюринг.
(и това е филм, който трябва да гледате, и за който силно се надявам (и изобщо не вярвам) да го дават по кината в България)

И най-накрая сме готови с (почти) всички видеа от OpenFest 2014, може да се свалят от архива, или да се гледат в тубата. Липсва ни само едно видео (“I reject your reality and substitute my own”), което самите хора ще си го редактират и ще качат.

(this is a guest post from Boyan Krosnov, the original is here)

An open letter to Mr. David Cameron,

Sir,

This letter is in reaction to you statement: ” But the question remains: are we going to allow a means of communications which it simply isn’t possible to read. My answer to that question is: ‘No we must not’. “Source: link

Mr. Cameron, firstly this letter has nothing to do with recent events in Paris. It is solely addressing the issue of private communications.

End-to-end computer-assisted encryption with ephemeral keys has existed on this world since at least 1977. Even 130 years ago, in 1885, the one-time pad was already invented. If you don’t understand what these are, then please ask your technical advisers. Essentially, someone with a book (for one-time pad), a pen and a sheet of paper can encrypt and decrypt secret messages from/to a party located on the other end of the world. They can communicate these messages in public using a variety of low tech means. For example, they could post innocent-looking messages in a classifieds section of a newspaper. Anyone, without the necessary procedures and a copy of the pad, would not be able to know the content of their communication, and if the scheme is implemented correctly, would not be able to detect that a conversation is taking place. This is not a new development. Even the modern idea of a Sneakernet has existed at least as long as the Internet has existed.

Short of inventing a time machine, your goal is unachievable. :)

On a more serious note though, what you are promoting in your speech is scary and deeply immoral.

Since end-to-end encryption exists, I know of only three ways you could try to achieve your goal of total on-demand, and probably retro-active snoop-ability of communications. These are ineffective and in some cases even impossible to implement, but anyway here they are:

• Option 1. to have a backdoor in every end-point device manufactured in the UK or brought in through the UK border. This approach does not prevent a sufficiently dedicated person from building a secure end-point from scratch, like with the one-time pad and newspaper approach I mentioned. Backdooring online services is a sub-case of this.
  
  and/or
• Option 2. to introduce a key escrow requirement for all encrypted communication beginning and ending and maybe even crossing the UK, and also detect and block all encrypted communication, not conforming to the key escrow rules. The latter might be impossible to implement, but that’s a whole other matter.
  
  and/or
• Option 3. Ban encrypted communication altogether. Which would tear down the whole of what you call “the digital economy”, and revert the UK back to a technological state resembling the 80s, while the rest of the world moves on.

The reality of the matter is that all three, apart from being totally ineffective in dealing with the threat of isolated terrorist acts, open the door for massive abuse, not just by the government, but also by related and unrelated third parties. Other people have explained this a lot better than I ever could. For example, in Cory Doctorow’s talk here. To quote just one line ” – … but we both understand, that if our government decided that weaponizing water-bourne parasites was more important than addressing them and curing them, then we would need a new government.”

Let me be clear on one point: We don’t trust nation states with our private thoughts and conversations. We need private communications not just for the paranoid, perverts and criminals, but for businesses, law enforcement, journalists and for regular every-day private conversations between friends and family members.

Your scheme would ruin private communication for all of us. The bad guys are already using secure and undetectable communication media.

Privacy is the opposite of total surveillance. You can’t have both. So unfortunately, for the goals you outlined, we need to have a working and secure private communication for everyone in the world to use, regardless of their sex, skin color, sexual orientation, age, religious views (or lack thereof), wealth, social status or intent. Your scheme for a total surveillance state must be stopped.

With good meaning and respect,
Boyan Krosnov
Sofia, 2015-01-13

(c) 2015, Boyan Krosnov, public domain

Някои дреболии, дето изникват тия дни:

Описание как да си настроим ssh-а, така че да е минимално vulnerable към възможните проблеми (дето се мисли, че съществуват след лекцията на Апелбаум)
(мисля, че автора прекалява, ама па параноята е нещо важно в нашата професия)
(събирам желание да си rekey-на сървърите)

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

Също така, в initlab ще има лекция/дискусия на тема “Design patterns for web-application scaling”, която даже ще stream-ваме online. Ще е в общи линии админска, но вероятно ще се допускат developer-и, ако не говорят много глупости.
(няма какво да се притеснявате, vloo ни е забранил да ползваме брадвата в тоя студ, а па и земята е твърде замръзнала, че да заравяме някой)

За тестове сме пуснали initLab TV, което в общи линии върти всичките записи, дето има на va.ludost.net.

Всички видеа от 31C3 са качени, ако има достатъчно желаещи, може да организираме гледане на най-добрите.

И довърших една книга, дето май всички трябва да прочетат.

(да, правя опити да пиша по-често)

И последен ден на 31C3.

Започнах с лекцията за online гласуването в Норвегия – имаше реализирана система на база на ел-Гамал (където има интересната възможност да се събират криптирани числа, без да се виждат), по принцип “стандартът” по темата е горе-долу този (не помня url-тата по въпроса). Докато тествали открили няколко бъга, но като цяло защитата в дълбочина ги спряла. Отказали са се от системата, понеже не давала нищо повече – не се увеличил броя гласуващи и като цяло гласувалите по internet не били различни от тези, които гласували на място.

“Why are computers so @#!*, and what can we do about it?” беше сравнително скучно (някъде по средата излязох да ям и го слушах през gsm-а), поредното нещо по темата как трябва да си правим кода доказуем и да ползваме технологиите за целта.

Във “State of the onion” имаше разни интересни неща, които съм си отбелязал – ooniprobe (мислех да взема една хардуерна проба, но вероятно просто софтуерното нещо ще е достатъчно), направили са TOR weekly news, и Roger е разказвал на NSA около 2008ма колко е готин TOR и във Washington post има статия по въпроса (след като едно от leak-натите неща от Snowden са били бележките на хората от NSA от тая среща).

Infrastructure review беше доста интересно, setup-ът им става все по-голям всяка година и все по-интересен, чак ми идва желание да се включа в някой екип. Гледайте го за повече подробности.

TOR deanonimization talk-а разказа как са изброили доколкото е възможно hidden service-ите в мрежата и какво горе-долу има на тях. Също така обясниха как с pattern-а на трафика, ако човек има достъп до guard node на потребителя и има достатъчно места, на които да следи изходящия трафик, има някакъв вариант да се види къде отива, както и ако имат някакъв такъв достъп до guard node на hidden service. Като цяло нищо ново, и за съжаление нямаше хубаво описание на ловенето на traffic pattern-и.

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

(това го пиша в доста насмукано състояние, да се приема за оправдание за грешките)

Сутринта започна с лекция за full-body scanners, т.е. скенерите, които от известно време се ползват на американските летища и разни други места за разглеждане на пътниците. Хората бяха разгледали един от скенерите (Rapiscan Secure 1000), който работи с backscatter рентгенови лъчи. Нещата, които разказаха са, че:
– скенерът не генерира достатъчно радиация, за да е опасен (нивата са съвсем мижави), и като цяло не е лесно да е пипне така, че да е опасен;
– има начин да се подслушва донякъде образа, който вади, извън самия скенер (почти като подслушването на нечий монитор, като се знаят периодите на хоризонтално и вертикално сканиране и като може да се уловят отдалече разсеяните лъчи);
– оригиналният софтуер може да записва картинки (на ДИСКЕТА), твърди се, че тоя на TSA нямал тая функционалност;
– има вариант да се атакува машината, т.е. да се пренесе през нея нещо, което трябва да хване, по няколко начина (например като се направи да е само спрямо фона и да не се различава от него, или като се нанесе по тялото и да не се отличава от него, в случая с пластичния експлозив).
Този тип машини в момента не се ползват от TSA, понеже са искали да се отърват от гледането на “голи” хора, и софтуера да казва “еди-къде-си по човека има съмнителен обект”, а още никой не е успял да го напише (и звучи като доста безнадеждна задача).
Имаше и други забавни моменти, например как са си купили машината от ebay и се опитват да се снабдят с машина от другия вид (ако не се лъжа, с милиметрови вълни), за да изследват и нея.

Let’s build a quantum computer не беше лошо, в общи линии беше някакъв малък увод (непълен) в квантовите компютри и как човекът за две години като дипломна работа е сглобил 2-qubit-ов компютър, който работи при около 10-13 градуса по Келвин.

Между останалите лекции се засякох с Филип Пепс (от FOSDEM) и си говорехме с него и още някой по темата за техните видео записи и мрежата им, и как може да им потрябват hack-ове от типа на опъването-на-кабели-като-за-български-internet (лепена оптика с duct tape по стените, например). Има шанс да ходя до там да се забавлявам догодина…

Лекцията за NORX/Caesar беше за един конкурс за authenticated encryption, шифър с метод за прилагане. Представиха конкурса и техния участник (който изглежда интересен, но е цял шифър с метода и бая ме притеснява), направен със съвсем прости операции и като цяло доста по-прост от доста блокови шифри, които съм виждал.
Странно ми беше, че конкурса е за метод за прилагане И шифър, т.е. не просто за за метода (като нещо, което да замести GCM/CBC и компания), та за това голяма част от участниците просто ползват AES.

Лекцията за ядрените оръжия беше леко забавно, но в нея нямаше нищо, което го няма в wikipedia.

Докато си почивах, се запознах с човека от totalism.net, в общи линии hackerspace на един остров не-съвсем-в-нищото, където има net, топло е и човек може да си работи и почива спокойно, като даже не излиза особено скъпо. Bandwidth-а им не е много, но ако някой ден реша да ходя на “почивка”, може да е там…

Последва стандартния whisky workshop, на който се насмуках прилично. Харесах си сериозно само едно уиски, някакъв странен edition на glenfarcas, дето беше cask strength, 60 градуса и с истински вкус/
аромат.

Гледах лекцията за Computer science in DPRK (т.е. по темата Северна Корея), имаше интересни моменти – как имат клон на OSX с превод (почти на принципа, на който нашите хора едно време крадяха и превеждаха софтуер директно в binary-тата), как имат таблет с аналогова телевизия, клон на andoid с patch-нати app-ове (и добавени, като например един с речи на лидерите им). Като цяло доста полезна гледна точка (лекторът беше водил лекции там в един от университетите).

А лекцията за exploit-ването в perl беше адски забавна, как явно самите хора, които ползват perl не схващат някои негови кривотии и как самият език не се държи по очаквания начин (т.е. как реално погледнато някои неща в него се държат като в shell script, а не като в LISP) и какви адски забавни атаки могат да се получат (например, да се пробута аргумент който като се предаде на функция, да се приеме като два аргумента и да избута тия след него). Аз лично се смях с глас…

Втори ден на CCC. Сутринта беше тихо, само в irc се обсъждаше миризмата на крака и какво може да се направи по въпроса.

Започнах с tea with RIPE, говорихме си малко за RIPE Atlas пробите и пихме чай, ама аз някъде по средата трябваше да бягам за друга лекция (това със слушането на лекциите през локалната gsm мрежа е страхотно, може да се слуша лекцията, докато вървиш към нея (и закъсняваш)).

Първата, на която ходих беше “Why is GPG unusable”, която беше сравнително бедна от страна на съдържание, имаше базови идеи, къде да четем и т.н. и как проблемите в gpg/pgp са същите от около 15 години и нищо не е направено по тях. Имаше нещо интересно – книгата “Evil by design”, която мисля да погледна.
(полезни отбелязани бележки: трябва да се тества с потребителите, cryptocat се ползва, щото е готин, identities в момента (като pgp fingerprint-а) не са особено използваеми, щото не могат да се помнят).

Telecoms & NSA лекцията беше основно историческа, като някаква част от нещата съм ги чел в “The codebreakers” (как още от първата световна война тогавашния еквивалент на NSA е събирал копия на всички телеграми), лекторът е работил в NSA и е писал малко книги по темата, като интересното сега беше една статия в the intercept, както и документ за разследването на щатското министерство на правосъдието на NSA (в което NSA се описва като криминална организация и трябва да се зачете по-подробно).

Лекцията за internet-базираното гласуване в Естония беше също доста интересна. Атаките, които те описваха бяха основно на оперативно ниво (клиенти, как можем да се доберем до инсталацията на сървъра и т.н.), т.е. самата система изглежда работеща. Спрямо post-а ми по темата имат частично решение на първия проблем – всеки може да подаде колкото си иска гласа и се зачита последния, така че човек може да гласува пред някой, да си вземе парите и после да гласува както си иска. Системата им дава QR код, който важи 30 минути след гласуването, чрез който (криптографски сигурно) може да се провери дали системата е отчела вярно за кого си гласувал.
Имаше доста интересно описание как са атакували и счупили системата за гласуване във Вашингтон, през някакъв нормален shell injection.
Като цяло освен нещата, които аз бях отбелязал съществува проблема, че реално нищо в хардуера и софтуера ни не е достатъчно сигурно, че да му вярваме. Също така, поне с това, което знаем/можем в момента, моментът с купуването на гласове/принуждаване не може да бъде избегнат и е някакъв tradeoff за всяко отдалечено гласуване.

Finding the Weak Crypto Needle in a Byte Haystack обясни метод, чрез който при криптоанализ може да се търси повторение на keystream в поток от данни. Схемата е доста проста и с квадратична сложност (което при криптографията е нищо работа) и изглежда съвсем тривиално за реализация.

Information Control and Strategic Violence не струваше, лекцията беше да ни кажат, че в Сирия има корелация между насочеността на убийствата и работещия internet (т.е. колкото повече работи internet-а, толкова повече убитите са жертви на насочено насилие, т.е. прибрани, измъчвани и разстреляни).

(Пропих кафе, очаквах това да стане чак на третия ден)

Privacy and Consumer Markets беше лекция как/защо да търсим/правим механизми за обръщане на стандартния модел – вместо да ни набиват реклами, чрез които да избираме какво искаме, да правим “задания” какво ни трябва и да можем да намираме лесно това, което ни трябва, чрез reverse auction и подобни системи. Също така имаше идеята да се комбинират достатъчно хора, за да имат нужния buying power, за да им се обръща внимание (нещо което е доста близо до kickstarter-ската идея). Беше кратък обзор на нещата, но като цяло с добри идеи.

(тези две лекции бяха по 20-30 минути, и това изглежда като много лоша идея, понеже почти нямаха съдържание, толкова кратките май не трябва да ги има в програмата)

Някъде по това време изскочи тоя tweet, с който май съм бая съгласен:
(18,46,24) marlabot: (notice) wikileaks: Politics at this year’s CCC is conspicuously provincial and stupid. No-one from BRICS. No Ukraine. No Bitcoin. Endless security mercenaries.

Mining for Bugs with Graph Database Queries беше страхотна лекция – публикували са инструмент, който се казва Joern, който може да търси интересни pattern-и върху един граф, наречен от тях code property graph, който е комбинация от AST дървото и няколко други графа, които компилатора прави по време на компилация. Идеята е, че знаем как изглежда тип vulnerability (единия от примерите – malloc() и memcpy(), където изразът за дължината на първото е различен от тоя на второто и работят със същия буфер), можем лесно да намерим всичките срещания на pattern-а му и после да ги прегледаме. По принцип е инструмент за хора, които audit-ват код, но с внимателно писане на тестовете може да се използва и за regression testing, инструменти за автоматичен audit, разпознаване на бъгове чрез pattern recognition и т.н.

Но ако трябваше да отбележа само една лекция от деня, щеше да е тази на Jacob Appelbaum и Laura Poitras, “Reconstructing narratives”. Заглавието не звучеше особено интересно и гледах “Mining for bugs”, та после гледах записа на тази, и понеже още не съм я обмислил, ето по-важните неща:
Лекцията беше за неща, които в същия момент бяха публикувани в Der Spiegel, подробности за програмата за targeted killing на ЦРУ, и данни от NSA за счупена криптография.
От всичките неща само за две е ясно, че не са счупени (GPG и OTR);
(т.е. има накакви данни за чупене на SSH, SSL, IPSec, PPTP (последното никой не учудва))
NSA имат някакви неизвестни за останалите атаки в/у AES;
Като цяло сме още по-кофти преебани;
Трябват ни големи ключове и добри криптосистеми, защото май само това върши работа;
(трябва да си отделя някакво време да прегледам оригиналните документи и да си изградя някаква картина, но преди това искам да поспя и се надявам да нямам кошмари как ми декриптират ssh сесиите)

(in other news, тук вали сняг (и ако вали в сряда сутринта, има приличен шанс да си изтърва втория полет и да карам нова година във Франкфурт), а като се прибирам температурите в София ще са под -10. Искам си локалното затопляне и времето от миналата година.)

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

(Видях се с Denisa Kera, която ни гостува преди време в initlab, и тя ми спомена за интересен проект, crowdfunding за някой разследващ човек, да дебне политици и да събира за тях какво правят, това е линка, който ми прати. Звучи като забавна идея, за другата подобна, която имах (crowdfunding за лобиране) ме разубедиха)

Сутринта към 9-10 беше учудващо празно, ама това доста бързо се промени. Мисля, че спокойно има едни 7-8 хиляди човека (може би и 10), за доста лекции залите се пълнят, а зала 1 събира 3000 човека…

(докато чаках да почне откриването забелязах доста wifi мрежи, които се казваха “Not fuzzing with your wifi” от 1 до 20)

Откриването беше твърде оптимистично и прилична част от него беше wishful thinking – “it’s not the shady intelligence agencies with big budges ruling the internet, but us” и подобни, но като цяло нямаше нещо глупаво, и започнаха с “welcome to the largest hacker conference in the free world”, което зарадва всички.
Споменаха си менторската програма, да се помага на хора/деца, дошли за пръв път на конгреса, има бегъл шанс да се навия за година, ако идвам (т.е. ако ще мога да издържа пак тия тълпи).

Keynote беше трагедия. В началото си бях отбелязал, че е нищо особено, но в общи линии се оказа директно зле – Alec Emprire ot Atari Teenage Riot чете нещо от някакви листи, пуска клипове с не-особено-кадърна-музика и като цяло говори за твърде известни и ясни неща. Може би единственото интересно беше разказа му как Spotify тръгнали да им ban-ват един албум (и с него всичкото от label-а, в който са), щото нещо се говорело вътре за нацисти, те им обяснили подробно, че са най-антинацистката група, която може да има (заедно със статии от вестници и т.н.) и им отговорили “nazi or anti-nazi – doesn’t matter”…

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

Reproducible builds лекцията беше също доста интересна, имаше обяснения кои проекти докъде са (оказва се, че прилична част от debian вече е с такива build-ове), както и са работили по въпроса за android, мисля, че това все повече ще намира приложение, особено при всякакви crypto-свързани неща.
(трябва да дам на pcloud-ци да видят какво може да се приложи)

(Като човек гледа мястото, може да си помисли, че е на някой woodstock, пълно е със странни хора. Всъщност, странни даже не започва да ги описва…)

Лекцията за EMV беше донякъде rehash на стари атаки, с подобрения и в общи линии как се появяват по-добри и ефективни skimmer-и. Накратко, можеш да се добереш до pin-а на карта само със skimmer (тук имаше малко нов research), или можеш да правиш транзакции с карта, на която не знаеш pin-а. Лекторът беше от фирма, която се занимава да помага на хора да се разберат с банката, ако не признае някоя измама и не им върне парите, както с audit на различни такива системи.

Лекцията за SS7 беше… полезна. Накратко – все едно сме в internet-а от 70та година, всеки може да си пише с всеки без auth и да подава какви ли не съобщения. Целия research тръгнал от фирми, които могат да локализират по телефонен номер къде точно се намира, от това изскочили какви ли не весели работи:
Може да се пита в коя клетка е телефона (което е прилично локализиране);
Може да се пита за gsm координати на телефона (което уж е само за полицията, но поради глупост в протокола можеш да си spoof-неш from-а и да получиш данните);
Можеш да подадеш в нечий HLR-а къде се намира някой (без auth);
Можеш да изпълняваш USSD кодове (*xxxx#) за нечий телефон (от които може да правиш forwarding и какво ли не още), и т.н. прекрасни неща.
Имаше и демонстрации (например как могат да видят баланса на чужда prepaid карта).
Най-тъжното беше в последните няколко слайда, как реално потребителите могат или да си хвърлят телефона, или да мрънкат на оператора, щото за това няма нищо, което може да се направи в endpoint-а.
Talk-ът на Karsten Nohl след това продължи темата с няколко нови атаки, най-вече в/у 3G с малко помощ от SS7, както и с някои интересни наблюдения как в момента всички ползват 64бита ключове за A5/3, и никой не ползва пълните 128бита, понеже няма никъде подходящи sim карти.
Като цяло, тия две лекции трябва да се гледат. Във втората казаха, че са update-нали вече gsmmap с нова информация, както и че са пуснали android приложение за телефони с определен baseband, което може да дебне за част от атаките.
(приложението е под GPL)
(лекцията на Karsten я слушах/гледах на лаптопа, докато се редях на опашката за тениски, която се виеше през цялото фоайе на CCH като странна змия. Да живеят streaming-а, пускането на лекциите през локалния gsm и доста издръжливата wireless мрежа).

Code pointer security също беше полезно, като цяло идеята е, че пазят само указателите, които сочат към код, което прави възможно да утрепеш приложението, но не и да го exploit-неш по някакъв начин (директно счупват return-oriented programming-а). Overhead-а им е до около 10% и като цяло изглежда много използваемо.

Деня приключих с ECC Hacks, лекция на DJB и Tanja Lange, в която обясняваха как работят елиптичните криви. Беше много добре, мисля, че сега имам доста по-добра идея как работят и мисля, че трудно може да се направи по-добро обяснение от това.

Нулев ден на 31C3.

Станах си нормално в 9-10, добрах се спокойно до летището, летях (и в двата полета) с пищящи деца и се чудех защо изобщо хората се размножават, след което на Мюнхен за 30 минути се изсипа едно весело количество сняг и полета ми го забавиха с час и половина (който иска, може да гледа снимки).

(В Хамбург още не вали)

Изсипах си нещата в хотела и се добрах до CCH, откъдето пиша това. Отворили са още повече място от миналата година, ние имаме една малка маса, дето се надяваме да ни събере (assembly-то ни се казва Eastern-European Hackerspaces и сме набутани в “international” частта, малко като зоопарк за странни видове (което тук нищо не значи, “странно” е най-простото определение за почти всичко)).

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

Утре се почва в 11:00, да видим колко човека ще побере голямата зала и колко ще оцелее wireless-а…

(моята предварителна програма:

27.12
11:00 saal1 opening/keynote
12:45 saalG aluminum casting
14:00 saal1 scada | saalG reproducible bulids | saal6 textile
16:00 saal1 emv
17:10 saal1 SS7
18:30 saal1 mobile self-defense
20:30 saalG code pointer integrity
21:45 saal1 ecchacks | saalG cloud consp | saal6 banking
23:00 saal2 rocket kitten
24:00 saal1 citizenfour
00:00 Hall13 ripe atlas workshop

28.12
11:00 hall13 ripe morning tea
11:30 saalG gpg
12:45 saal1 PNR | saal2 telecoms/nsa
13:00 hallC tor operators meetup
14:00 saal1 estonia voing
16:00 sall6 automobiles
16:45 saalG crypto needle
17:15 DIYISP anycast vpn
17:30 saal1 information control
18:15 saal2 privacy and markets
19:00 saal6 blow stuff with your brain
20:30 saal1 reconstructing narratives | saalG bug hunting
21:45 saal1 fernvale | saal2 field station
23:00 saal2 sources

29.12
11:00 hall13 ripe morning tea
11:30 saal1 RMS | saalG scanner
12:45 saal2 quantum computer
14:00 saal6 file formats
16:00 Saal2 emet | saalG caesar and norx
17:15 saal2 nuclear weapons
18:30 saal2 maker movement
19:30-21:30 hallB whisky workshop
20:30 saal6 agri-tech
21:15 saal2 cs in DPRK
22:00 saal1 perl expoloit
22:45 saal2 megacode
22:30 saal1 infocalypse

30.12
11:00 hall13 ripe morning tea
11:30 saal6 internet voting in norway
12:45 saal1 why computers are bad and what to do
14:00 saal1 state of the onion | saal6 lets encrypt
16:00 saal2 crypto dust | saalG infrastructure review
17:15 saal2 tor hidden svc
18:30 saal1 closing event
)

Гледайки плановете от началото на годината:

С четенето на сериозни книги като гледам съм се справил, въпреки че ми пак ми висят някакви неща, дето са бая интересни и важни и не намирам време за тях (статистиката в goodreads);
Ходих на Балканския компютърен конгрес (даже говорих);
Почнах да поспивам чак като напуснах работа в края на декември (горе-долу);
Свирих… пак твърде малко, въпреки че поне вече си организираме дрънчане в лаба;
Техническите лекции тая година ми бяха свързани с работата – криптография, сигурност, web услуги, може да се каже, че все пак съм наблегнал на техническите;
Изобщо не съм писал сериозно в блога.

Иначе, като цяло:

Годината мина в конференции и работа. Поне по списък съм направил 5 лекции по всякакви теми, и май си бяха много, а конференциите са около 10, плюс още едно-две събития:
Два пъти RailsGirls София (екип)
Ro[ug]e conf 2014 (екип, лектор)
RIPE-SEE-3 (лектор)
HackFMI 3 (жури)
PlovdivConf (екип)
BurgasConf (лектор)
VarnaConf (екип)
CryptoBG конферецията (посетител)
YAPC-Europe (екип)
EuroBSDCon (екип)
Balccon (лектор)
Openfest (екип)
(след няколко дни) 31C3 (посетител)
Това по никакъв начин не е нормално.

Като гледам, едвам съм писал в блога.

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

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

Заех се сериозно да редактирам Reverse engineering for beginners, харесва ми, и има поне още два месеца работа там.

Пренесохме initlab на по-голямо и хубаво място, в малко странен квартал.

Не направих не-курса за системни администратори поради липса на време, но пък имам идея за BGP workshop.

Продължава да не ме боли главата.

И понеже паметта ми тотално сдава багажа, не мога да се сетя други неща, дето съм вършил през годината и дето да си струват да се споменат тук, ако някой има желание, може да допълва :)

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

От чисто теоретична страна има няколко нерешими проблема:

Купуването на гласове става още по-лесно. Ако хората могат да гласуват отдалечено, нищо не пречи на купуващите гласове да си setup-нат едно място за гласуване, където да се изреждат платените хора и да си подават гласовете. За такова нещо защити няма и няма как да има (това със следенето колко се гласува от един IP адрес е тривиално за прескачане, през tor или произволен ботнет). Не казвам, че в момента не е възможно (практиката показва обратното), но с internet-базираното гласуване нещата стават тривиални.

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

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

Разбира се, изобщо не отказвам някой да ми обясни колко не съм прав и да даде примерна система, че така и така ми се чупи нещо :)

(алтернативното заглавие беше “мизерии, които правим като нямаме BGP”)

След доста мъки с onlinedirect в initlab си пуснахме втора връзка, през TBC.bg. За да можем да ползваме и двете, се наложи малко бърникане по setup-а и забавни неща, които съм описал по-долу, разделени на v4 и v6.

Преди всичко може да погледнете схемата на мрежата.

За IPv4 имаше два проблема: трафикът, влизащ от един доставчик трябва да излиза пак през него (нормален policy routing), и трябва по някакъв начин да се избира през кой интерфейс да се излиза (чрез gwping).

Policy routing-а е стандартен, описан е на хиляда места и за това без много подробности, идеята е че се прави routing таблица за всеки доставчик, в нея се вкарват пътя до самия доставчик, default през него и пътищата към локалните вътрешни мрежи, след което се слагат правила, че ip адреса от тоя доставчик изходящия трафик ползва определената таблица. Или, погледнато на cassie:

vasil@cassie:~$ cat /etc/iproute2/rt_tables|grep -v #
255     local
254     main
253     default
0       unspec

2       od
3       tbc

vasil@cassie:~$ ip r show table od
default via 93.152.128.1 dev eth0.5
93.152.128.0/17 dev eth0.5  scope link
172.31.190.0/24 dev eth0.2  scope link

vasil@cassie:~$ ip r show table tbc
default via 94.26.100.129 dev eth0.6
94.26.100.128/27 dev eth0.6  scope link
172.31.190.0/24 dev eth0.2  scope link

vasil@cassie:~$ ip rule
0:      from all lookup local
32764:  from 94.26.100.155 iif lo lookup tbc
32765:  from 93.152.143.66 iif lo lookup od
32766:  from all lookup main
32767:  from all lookup default

За изходящия трафик проблемът се решава чрез gwping (който намерих от тук и ми спести час-два писане на нещо такова). Това е прост скрипт, който ping-ва през двете връзки нещо определено (например google) и ако през едната го няма, я маха от routing-а, а иначе държи два default route-а с различна тежест, т.е.

vasil@cassie:~$ ip r
default
        nexthop via 93.152.128.1  dev eth0.5 weight 1
        nexthop via 94.26.100.129  dev eth0.6 weight 2
...

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

За IPv6 нещата се оказаха малко по-сложни (но по-изчистени), понеже свързаността ни идва от един тунел до моя машина в telepoint (бяхме на HE.net, ама ни омръзна да ни се отваря немския google). От там имаме една наша /64, която се появява във вътрешната мрежа на лаба. За да мога да прекарам тунела да работи и през двете връзки, просто пуснах два отделни тунела от cassie до tyler през двата доставчика, след което в/у тях пуснах с quagga OSPFv3. В него от страната на cassie announce-вам префикса на локалната мрежа, от другата страна – default route. В общи линии в конфигурацията имам следните неща:

cassie (тук вътрешния ми интерфейс е eth0.2):

interface vk-ipv6-od
 ipv6 ospf6 priority 0
!
interface vk-ipv6-tbc
 ipv6 ospf6 priority 0
!
router ospf6
 router-id 255.1.1.1
 redistribute connected route-map internal
 interface vk-ipv6-od area 0.0.0.0
 interface vk-ipv6-tbc area 0.0.0.0
!
route-map internal permit 10
 match interface eth0.2
!
route-map internal deny 20

tyler (тук външния ми интерфейс за IPv6 е eth1, а правя redistribute kernel, понеже default route се вижда като такъв):

interface lab-ipv6-od
 ipv6 ospf6 priority 0
!
interface lab-ipv6-tbc
 ipv6 ospf6 priority 0
!
router ospf6
 router-id 255.1.1.2
 redistribute kernel route-map external
 redistribute connected route-map external
 interface lab-ipv6-od area 0.0.0.0
 interface lab-ipv6-tbc area 0.0.0.0
!
route-map external permit 10
 match interface eth1
!
route-map external deny 20

Учудващо, но работи и даже не успях да си отрежа клона, докато го подкарвах. Има няколко дребни момента, например че OSPFv3 няма auth. на пакетите (или поне го няма реализиран в quagga) и ще му трябва ipsec в един момент, или че може да е по-интересно да вземем от двата доставчика IPv6 адреси, да ги раздаваме на потребителите и те да избират от кой да излизат (което ще е интересно да се тества колко добре работи, ако работи изобщо).

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

Нещата, които си взех за мен:
“Мир на страха ни” на Георги Мишев (автобиография, прочетох за нея в блога на Евгени Тодоров, и преди малко я приключих, заслужава си въпреки отнесения стил на писане);
“Психология на тълпите” на Густав Люобон (препоръча ми я преди някакво време longanlon);
“Патрули: училищен надзор” на Сергей Лукяненко и Аркадий Шушпанов (сега видях, че има и втори автор и май ще съжалявам);

Нещата за подаръци:
“Сигурно се шегувате, г-н Файнман” – Ричард Файнман (превели са го най-накрая, помня с какво удоволствие четох оригинала);
“Белене – сказание за концлагерна България” на Стефан Бочев (за която би трябвало да съм писал, едно от най-хубавите описания на човешката природа, освен всичко останало);
“Рекло телето дъба да мушка” на Александър Солженицин (неясно къде ми е другото копие);
“Секретността – американският опит” на Даниел Мойнихан (взех две копия и едното вече го подарих на някой);
“Невидимата горила” на Даниел Саймънс и Кристофър Шабри (превели са я скоро, една от най-хубавите книги за бъговете в човешкото мислене).

(и заедно с книгата на Файнман ми подариха “Да паднеш в черна дупка” на Нийл Тайсън, която не знам кога ще подхвана)

Снощи (до тая сутрин) бях на концерт на Concrete Sun, Villagers of Ioannina City и Smallmanband, на стандартното място в mixtape.
(добро прекарване на в общи линии първия/втория ми безработен ден)

Влизането се забави с около час (което май е стандартно), но първата група почна почти веднага след като хората влязоха. Concrete sun изобщо не ми бяха интересни, звучаха стандартно и плоско, като … в общи линии новата metallica. Бяха и малко прекалени във викането към публиката, но явно тва им е стила на действие.

Вторите бяха Villagers of Ioannina City и тотално размазаха. Не знам дали мога да ги опиша, но имаха една отнесена китара, доста приличен (и добре чуващ се) бас, един човек на духови инструменти (да гледаш как някой подскача и куфее с кларинет е любопитно), клавир и доста странни ритми. Като цяло, странен и ставащ за танцуване метъл (няколко човека отидохме след като свириха да си вземем CD-то им, аз тъкмо си го въртя).

А smallman си бяха smallman. Свириха си с кеф, изсвириха всякакви интересни неща и завършиха заедно с клавириста на Villagers с едно изпълнение на Angel на Massive attack. Раздвижихме добре куфелния мускул, попяхме/повикахме и като цяло преживяването си струваше висенето до 3 :)

(ужасно вредно е да се чете Пратчет от лесно-пристрастяващи-се-хора, за поредна вечер седя до 3, за да си дочета книгата)

След някакво количество по-тежки книги – всичкия Оруел и последствията от него (Albert Maltz, Евгени Замятин, E. Tangye Lean), после Echopraxia на Peter Watts и т.н. (тук може да се види списъка), реших да си почина с малко Пратчет. Хванах каквото ми беше под ръка (Jingo), после продължих с нещата за стражата, първо по-тежките (“Night Watch”, “Thud!”), след продължих с първите (“Guards! Guards!” и т.н.).

Накрая снощи изчетох “The last continent”, и изведнъж си спомних/открих пак, че той всъщност е адски смешен – смях се бая време на разните шеги (които в оригинал определено са по-добри, май ще си планирам препрочитане на старите неща). Езикът му е страхотен, идеите му също, и малките и дребните шеги се получават много добре. Явно в някакъв момент след серията с магьосниците нещо е станало с него (и не е алцхаймера, щото той дойде доста по-късно) – докато преди идеята на книгата беше важна, но беше важно и да е смешна, в последните му неща важността на идеята избутва хумора доста назад, сяка
ш е нямал желание да се шегува толкова.

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

Също така, тоя частичен препрочит ми показа, че определено серията за света на Диска трябва да се прочете от повечето хора. За предпочитане – в оригинал (и през деня, че да се намира време за сън).

(това е писано от Петко Борджуков и публикувано в сайта на OpenFest 2014, препубликувам тук с неговото разрешение)

Основният подход при изграждането на безжичната мрежа в Интерпред се въртеше около два основни принципа – много хардуер и липса на сложна конфигурация.

Хардуерът

Тази година Крокодила си беше поставил за цел да имаме поне 10 устройства, които да пръснем из сградата. В крайна сметка имахме 11:

ap00 - alix2d2 с dnma92 и cm9 MiniPCI Wi-Fi карти (София – дясно)
ap01 - alix2d2 с dnma92 и cm9 MiniPCI Wi-Fi карти (G3)
ap02 - alix3d2 с dnma92 MiniPCI Wi-Fi карта (София – ляво)
ap03 - alix3d2 с dnma92 MiniPCI Wi-Fi карта (G1)
ap04 - Cisco WAP561 (Пловдив)
ap05 - Cisco WAP561 (Бургас)
ap06 - alix3d2 с TP-Link MiniPCI Wi-Fi карта с чипсет AR9280 (G1)
ap07 - alix3d2 с cm9 MiniPCI Wi-Fi карта (резерва)
ap08 - alix3d2 с cm9 MiniPCI Wi-Fi карта (резерва)
ap09 - TP-Link WDR4300 (лоби)
ap10 - TP-Link WDR4300 (Варна)

С изключение на двете устройства Cisco, всички използвани Wi-Fi карти бяха с чипсет Atheros. dnma92 е двубандова и поддържа 2×2 MIMO, cm9 е двубандова, но поддържа само 802.11b/g, двете устройства TP-Link поддържат 3×3 MIMO на
5-гигахерцовата си карта и 2×2 на 2,4-гигахерцовата.

Софтуерът

На всички устройства (с очевидното изключение на двете Cisco) беше инсталирана OpenWRT Barrier Breaker, рекомпилирана с CONFIG_PACKAGE_ATH_DFS=y и CONFIG_ATH_USER_REGD=y, което да позволи използването на канали от 52 до 64.

Допълнително на всички железа беше пуснат SNMP сървър.

Конфигурацията

Имахме три основни разновидности на конфигурацията на точките за достъп – 802.11n в 5GHz и 2,4GHz спектър, 802.11b/g в 2.4GHz спектър и двете Cisco.

Обща част

Всички точки за достъп извършваха .1q тагване на рамките и бяха свързани с останалата част от мрежата през един „trunk“ порт и имаха следната конфигурация на мрежата:

management: eth0.600
wireless (bridge mode): eth0.601, wlan0 и wlan1, ако има такъв

Бриджът, в който са добавени безжичните интерфейси, няма никакъв адрес от трето ниво.

Интервалът за излъчване на beacon рамки беше 250 милисекунди, за да се намали натоварването на каналите (повече за това – в частта за мрежата за бавни устройства). Докато експериментирах с тази настройка, забелязах, че понякога Wi-Fi клиентите не откриваха дадена точка за достъп при сканиране. Този проблем се наблюдаваше, при beacon интервал по-голям от 300ms.

На безжичните карти беше зададена България за regulatory domain и беше активирано излъчването на 802.11d информационен елемент в beacon рамките с надеждата клиенти, които по подразбиране на поддържат канали 12 и 13 да бъдат „заразени“ с правилния regdomain от някоя точка за достъп на видим от тях канал.

Точките за достъп бяха конфигурирани да си говорят по 802.11f, за да се намали времето за миграция на клиент помежду им. Това наложи да оправя поддръжката на .11f в конфигурационните скриптове на OpenWRT, защото в Barrier Breaker по подразбиране IAPP работи само в шифрирани мрежи, и дори в този случай се чупи, заради използване на изведени от употреба команди за установяване на име на физически интерфейс (eth0.600 например) по име на логически интерфейс (wan, lan, и т.н.).

Силата на сигнала на всяка точка за достъп беше далеч под максималната – почти всички радиа бяха конфигурирани да излъчват с между 8 и 10dBm с цел да се „поощряват“ клиентите да преминават между тях. 5-гигахерцовите радиа бяха усилени малко повече отколкото 2.4-гигахерцовите, за да ги предпочитат двубандовите клиенти (не беше особено ефективно, повече – за догодина). Отнесох доволно количество подхвърляния докато се разхождах с лаптопа си в петък, гледайки силата на сигнала и дали машината ми преминава между точки за достъп по очаквания начин. Това беше едно от най-досадните неща за конфигуриране.

Точките за достъп за бавни устройства (със SSID OpenFest Legacy Devices)

Още от преди да започнем да мислим мрежата, от няколко места ни предупреждаваха да „отрежем бавните устройства, защото забавят всички други“. Крокодила настояваше за отделна Wi-Fi мрежа за бавни устройства, за да няма хора без Интернет на Феста.

Реших да изровя малко повече информация по въпроса, преди да се втурна да се доверявам на необосновани подхвърляния. Открих следните две статии: http://www.revolutionwifi.net/2012/12/wi-fi-probing-behavior-and-configured.html и http://www.revolutionwifi.net/2010/10/limit-ssids-data-rates-to-maintain.html, които ми разясниха същността на проблема.

Решението беше да заделя един канал, който да е изцяло за стари устройства и да ги оставя да си работят там, за да им е бавно само на тях. Двете виртуални точки за достъп, които бяха заделени за тях (вж. графика 1), бяха конфигурирани да излъчват на първи канал и да поддържат всички Basic Rates – от 1 до 54.

Точките за достъп за бързи устройства (със SSID OpenFest 2014)

Всички виртуални точки за достъп, които бяхме зачислили за бързи устройства, бяха оставени изрично само с 54Mbps basic rate.

Двете точки за достъп Cisco (със SSID OpenFest)

Изрично бяха с различно SSID, за да бъдат извън „роуминг домейна“ на машините ни с OpenWRT. Конфигурацията им се състоеше в това да им сложа парола, да задам в кой VLAN да бъдат виртуалните им точки за достъп и да им намаля радиата до минимум (или 25%, според уеб интерфейса им).

Разпределение на каналите

Имахме ограничено физическо пространство, в което трябваше да работят заедно 6 точки за достъп в 2,4-гигахерцови спектър и 5 – в 5-гигахерцовия. Разпределението в 5-гигахерцовия спектър беше лесно, защото там имаме достатъчно на брой канали, които са на разстояние повече от 20MHz един от друг, а и затихването на сигнала в този спектър е по-голямо.

Конфигурацията на 2,4-гигахерцовите мрежи обаче не беше толкова лесна за избор – в крайна сметка реших да разделя спектъра на 1-и, 4-и, 7-и, и 13-и канали, за да оставя 13-и канал незашумен.

Физическо разпределение

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

Проблеми

Проблемите (за щастие) бяха малко и с ограничен ефект.

В края на първия ден имахме проблем с деасоцииране на клиенти от една или няколко точки за достъп. За съжаление, не успяхме да определим причината – от части заради ограниченото време, в което проблемът продължи, от части от това, че нямахме удобен метод за централизирано следене на безжичната мрежа.

Дебъгването на този проблем изведе наяве и друг – тъй като всичките точки за достъп бяха в един Ethernet сегмент, ARP заявките (както и теоретично всеки друг Ethernet broadcast) се излъчваха в радиоефира от всяка точка за достъп. Това стана особено забележимо в края на първия ден, когато доста от хората си бяха тръгнали. ARP таблицата на рутера се беше поизпразнила, за разлика от NAT таблицата му. Наблюдавахме излъчване на около 20 ARP заявки в секунда, идващи от самия рутер. Това е проблем, който ще трябва да решим за следващата година.

Бележки

Няколко души изразиха силно съмнение в това, че двата TP-Link WDR-4300 ще се справят. Устройствата си работиха абсолютно безпроблемно, без значение, че са на по-малко от половината от цената на Alix устройство с нужната периферия.

Неща, които липсваха

Липсваха ни скриптове, които да извеждат броя закачени клиенти на всяко радио, RSSI за всеки клиент, MAC адреси и т.н. SNMP сървъра, предложен в пакетната система на OpenWRT доста лесно се надгражда, но нямахме време да си ги допишем.

Липсваше ни система за централизирано наблюдение и управление на точките за достъп. Имахме само 7 устройства, които да се конфигурират на ръка, но това не пречеше да е досадно да се настройва конфигурация отделно на всяко желязо. Да не говорим, че търсенето към кое AP е закачен определен клиент беше също доста бавно и неефективно.

Мрежите ни бяха отворени. Мисля, че толкова много хардуер би се справил с конфигурация, подобна на тази на CCC – WPA Enterprise, който приема всяка комбинация на потребителско име и парола.

Липсваше ни метод за подтикване на двубандовите клиенти да се закачат на 5-гигахерцова мрежа. Тук нямаме тривиално решение – или трябва да имплементираме нещо ново в hostapd, или да измислим нещо хитро с blacklist-ване на всички MAC адреси по подразбиране за всяка 2.4GHz мрежа. Идеи са добре дошли.

Не успяхме да си изпрограмираме спектрален анализатор, който да приема данни от HackRF-а на Крокодила и да ни рисува Density Map в (близко до) реално време. Оглеждам https://www.kismetwireless.net/spectools, на които трябва да им се допише поддръжка за HackRF.

Благодарности

Благодарим на Elwix, BIX, Нет Ис Сат и Точо за заетия хардуер.

Петко

И ето едно описание на малкия ни streaming setup (използван по турнето и на OpenFest в по-малките зали).

Като за начало, ето картинката, по която ще се движим, в pdf и vsd формат.
На картинката имаме следните означения:
– червените линии са безжична връзка;
– светлосините – стерео по кабел;
– тъмнозелените – mono по кабел;
– тъмносините неща са бележки;
– бележката “OPT” значи нещо, без което можем да минем.

В бележките където има отбелязани жакове значат следното:
– 6.35мм, 3.5мм – моно/стерео, големи и малки жакове;
– RCA, известни при нас като чинчове;
– firewire – IEEE1394, още го ползваме да си връзваме камерата.

Компонентите са следните:
– аудио миксер;
– безжични микрофони, брошка и дръжка (AKG и HED в тая схема);
– слушалки (headphones) за наблюдаване и дебъгване;
– лаптоп за encode-ване и пускане на музика (опционално);
– озвучаване на залата (Room PA or speakers);
– камера
– amphony L1500 за безжично пренасяне на звук
– проектор
– лектор, с лаптоп
– мрежа

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

За stream-ване звукът влиза в камерата от пулта, и през firewire се дърпа от encoding лаптопа. Задължително е да има слушалки на камерата, за да може да се прецени как е звукът, който влиза в нея.
Със звука на камерите има следния проблем – доста от тях имат AGC (automatic gain control) и когато е тихо, усилват до невероятна сила фоновия шум (тих брум от миксера или просто шума в залата). За това е важно на всичките камери да се намери къде е и да се спре, и да се настрои нивото на входа.

Setup-ът на лаптопа е доста забавен, и изглежда по следния начин:
Избира се някаква директория, в която ще се записва видеото, и в нея се създава named pipe, който да се казва av.m2t (разширението е донякъде важно). След това в два терминала (note to self – да го направя на един скрипт) се пускат следните неща:

dvgrab –format raw –size 0 – | ttee av.m2t log.`date +%s`.m2t
(ttee може да се свали от github, като там трябва един fix, ако се ползват 32битови машини да се компилира с 64-битов file offset, за да не гърми на 4GB файлове).

avconv -i av.m2t -v:c copy -a:c copy -f mpegts udp://10.99.0.1:2500
(вместо avconv може да се ползва ffmpeg, то реално е същото)

С малко patch-ване може трите да се сложат едно след друго (ако ttee плюе на stdout), но тогава трябва да му се спре output-а на stderr, че терминала се напълва с глупости.
avconf/ffmpeg изпраща stream-а до един централен encoder, който да го encode-не и прати до restreamer-а. Правим го, за да decouple-нем записа от encode-ването (щото записващите лаптопи са слабички, а и като спре stream-а да не се чупи записа), описано е в предишния пост.

На някои лекции трябва да се пуска звук от лаптопа на лектора. За целта този звук трябва да се закара от лаптопа на лектора (който е отпред) до пулта (който най-често е най-отзад в залата). По принцип една опция е да се пусне дълъг кабел (който обаче може да направи проблем с брум и като цяло да няма откъде да мине или да няма такъв), за това ползваме най-често едно Amphony L1500, което може да носи звук цифрово през ефира. То си има малки бъгове (понякога някакви неща на 5ghz му шумят, и също така трябва да има активност, иначе спира да предава и трябва да минат 3-4 секунди със звук, преди да започне да предава пак), но като цяло за тази цел върши много добра работа.
Най-крайният вариант (който много много много избягваме) е лекторът да си сложи микрофона на колонките на лаптопа.

На картинката има няколко опционални неща:
– звукът за лектора (не на всички им трябва);
– мрежата за лектора (пак така, някои са оптимисти и ползват wifi);
– слушалките на пулта – по принцип се чува достатъчно добре от озвучаването в залата.

Setup-ът, въпреки голямото описание е доста прост и отнема половин час за сглобяване и 10-15 минути за събиране. Използвахме го в този му вид за повечето конференции тази година, а подобен на него – за последните 3-4 години.

(мислех да oпиша първо как правим записите и stream-а в малките зали на Interpred, но там ще трябва да чертая схеми и ще ги оставя за по-нататък)

За да можем да гледаме събитието локално и по Internet, тази година направихме следния restream setup:

Навън (в delta.bg) имахме сложена една машина, наречена grendel, която имаше 10gbps порт и достатъчно свързаност, че да може да ни бута трафика (още ме е яд, че не минахме 1gbps, догодина може нарочно да пуснем fullhd 1080p stream само за това). На него имаше пуснат nginx с nginx-rtmp модула, който приемаше stream-а и пускаше на потребителите rtmp и HLS. Имахме също страничка, която можеше да показва видеото директно в browser-а и я показвахме в iframe на сайта на OpenFest.

Графика на трафика на restreamer-а.

Същият restreamer с nginx имахме и на router-а в самия Interpred, и там препращахме потребителите, които искаха да гледат локално (и overflow телевизорите/лаптопите). Препращането ставаше чрез split DNS, т.е. за stream.openfest.org връщах локалният ip адрес вместо този на grendel.
Нямам графика на тоя трафик отделно, в общи линии би трябвало да е разликата между външния интерфейс и вътрешния интерфейс на router-а.

На restreamer-ите нямаше ipv6, понеже така и не успях да накарам някой от моите клиенти да работи по v6 за rtmp и мисля, че щеше само да създаде странни проблеми.

В настройките на nginx-а няма нищо, което да го няма в default-ната конфигурация, та ще ги пропусна. Единственият по-куц момент е, че явно модула не е дописан и на повече от един worker нещата се чупят, т.е. реално трябва да се праща по един stream на всеки worker, което не е ясно как може да се направи, или да се допише така, че м/у worker-ите да може да се дели един stream (което значи да му се добави shared memory и да се пише внимателно).

Самите потоци с видео влизаха на eagle, и от там биваха пуснати до двата сървъра. От по-малките зали пращахме директно по UDP raw HDV потоците, а от зала София, поради възможностите на restreamer-а – RTMP.
Причината за UDP-то (което беше една много добра идея на Петко) е, че така се получава decouple-ване на софтуера, който изпраща и записва от този, който приема, т.е. ако умре restreamer-а в който и да е момент, записващата част няма да има проблем, и ако restreamer-а се върне, ще може директно да продължи да чете потока от мрежата.

За encode-ването използвахме ffmpeg, ето как (с някои дребни промени по url-тата):

ffmpeg -re -i 'udp://@10.3.0.1:2600?overrun_nonfatal=1&buffer_size=81921024&fifo_size=178481' \
	-c:v libx264 -s 1280x720 -profile:v high -level 4.2 -preset ultrafast -filter:v yadif -g 60 \
	-b:v 2000k -acodec aac -ar 44100 -ac 2 -bsf:a aac_adtstoasc \
	-flags +global_header -strict -2 -threads 2 \
	-f tee -map 0:v -map 0:a "[f=flv]rtmp://localhost/of/g1|[f=flv]rtmp://1.2.3.4/of/g1" \
	-c:v libx264 -s 854x480 -profile:v high -level 4.2 -preset ultrafast -filter:v yadif -g 60 \
	-b:v 500k -acodec aac -ar 44100 -ac 2 -bsf:a aac_adtstoasc \
	-flags +global_header -strict -2 -threads 2 \
	-f tee -map 0:v -map 0:a "[f=flv]rtmp://1.2.3.4/of/g1-low|[f=flv]rtmp://localhost/of/g1-low"

Тук има няколко интересни неща:
– Вдигнали сме буферите на UDP-то за приемане на пакети (и имаме същото нещо от другата страна, за изпращане). В първоначалните тестове (по време на setup-а YAPC::EU 2014) открихме, че UDP е наистина unreliable на default-ните буфери (около 256к) за толкова много трафик и губи достатъчно пакети, че картината да се намазва почти постоянно. Съответно след като с тестове се видя, че при TCP проблемът го няма, лесно се стигна до правилния извод и от тогава тия неща ни работят като слънце.
(интересното е, че на VarnaConf правихме тоя setup без да вдигаме буферите и работеше, и едното съмнение беше, че щото е бил прав кабела м/у двете машини и без никакви switch-ове нещата са били ок. По-вероятно ми се вижда просто някой буфер да е бил по default по-голям на тогавашния ни encoder (един лаптоп на Петко), но няма как да го проверим).
(тази опция изисква и да се пипнат едни sysctl-та по kernel-а, имайте го предвид)

– ffmpeg-а може да създава няколко потока от един вход, и да ги пуска на няколко различни места. Така от един поток можехме да пуснем low и high quality потоци и към двата restreamer-а, без да се налага да се слага нещо по пътя, което да копира пакети или потоци. Наложи се да компилирам една последна версия, че да работи добре, но не беше особен проблем.

– “-g 60” е keyframe интервала, което в общи линии определя колко бързо ще се покаже нещо при потребителя, след като събере някакви данни.

– “-flags +global_header” се налагаше, за да може да бълва rtmp като цяло през тия разчеквания. Не помня как го намерих :)

Като цяло, всичкото това ми отне около два-три часа четене.

За зала София се наложи да направим малка добавка – понеже ffmpeg-а не можеше да слуша на rtmp (т.е. за половин час с Guru не можахме да го накараме), засилихме потока от залата директно в локалния restreamer, и с ffmpeg си го взимах от там и го пращах нататък. Така вкарвахме още 20-тина секунди латентност в излъчването, но пък си решихме доста приятно проблема.

Като цяло този setup не направи никакви проблеми и си работи двата дни като слънце, eдинствено в overflow залите в началото пускахме големия stream от зала София (1080p на 5mbps) и това създаваше малко проблеми на декодерите.

(благодаря на Яна за корекциите по текста)

И ето го описанието на мрежата на 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-ове и подобни, които отнемат над половин час, за да се подкарат;

(чувствам се адски изморен, добре, че пих два големи lagavulin-а да се освестя, и след тоя post отивам да спя)
(също така, планирам подробен post за как сме направили мрежата и ще изтормозя Петко да напише нещо за как направихме wifi-то, което имаше учудващо малко проблеми/оплаквания)

Искам да напиша една голяма благодарност до доброволците на OpenFest 2014. Екипът си го знае, ние в това сме били бая години и сме тренирани, но тук си говорим за хора, които нямаха идея в какво нещо се забъркват, издържаха два дни юркане, тичане, викане (основно от моя страна) и всякакви странни проблеми, които се появяваха. Routing-а на хората към overflow залите всъщност се получи идеално, в доста случаи и без да се налага някой да тормози – просто екипът доброволци уговаряше и насочваше потока както трябва (нещо, което досега не бяхме правили, нямахме добър опит и тренинг и импровизирахме през половината време).
(сещам се за определението на братя Стругацки, че добрата книга е за обикновеният човек, набутан в необикновени ситуации…)

Утре ще допълня списъка, ето една начална версия:

== Оператори за зала София ==
* Юлия
* Пешо
* Павлина
* Димитър

== Overflow ==
* Росен
* Димитър

== 2ри етаж ==
* Neter

== Мрежов екип ==
* Явор
* Точо

== g1 ===
* Иван
* Благовест

== Varna ===
* Марио
* Владо младши
* Олег

== представяния
* Стефан Кънев

== Unconference хора
* Иван Димитров
* Митьо
* Тони Стойчев
* Божо
* Емануил

== misc
* vloo
* Мюмюн
* Исмаил
* (чичо) Данчо
* Захари
* vloo
* Нейчо
* Доби
* Вальо

== рецепция
* Камелия
* Сияна
* Елеонора

И основен екип (който искрено се надявам да е пиян вече, че имат нужда):
Яна
Мариян
Петко
някакъв зелен идиот
Христина
Стефан Леков
Ирина
Стефан Вартоломеев
Християн (Guru)
Горица