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

И случихме ТърновоConf 2016.

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

Интересните работи (по техническата част) бяха следните:

Оказа се, че в хотела има някакъв “internet” през кабелната телевизия, с 20mbps download и 1mbps upload. Последваха малко телефонни обаждания, намерихме си резервен вариант през 3g и 4g, а един ден преди събитието се открихме с един приятел и evo.bg ни докараха 1gbps връзка на място, с която тотално ни решиха проблемите. Малко изненадаха хотела с бързото пристигане и окабеляване, но нещата минаха съвсем лесно.

За това събитие паралелно бяхме вързали fosdem-ските videobox-ове, с които вървеше отделен stream, представляващ picture-in-picture (ще кача примерни записи от него и малко encode-нати видеа отделно, за сравнение). Работеха доста добре, бяха полезни за switch-ове и не създадоха никакви допълнителни проблеми, така че вероятно някоя конференция можем да я направим само с такива, ако решим. За изходящия stream от тях трябваше да заделим един лаптоп с i7, но той се справи съвсем добре и май без никакви особени проблеми (трябва да видя streamdump-овете как са).

Успя да ни умре за малко единия контролен лаптоп (един thinkpad t410), понеже при default-ната работа на вентилатора му и виртуалката с контролния софтуер беше успял да прегрее ужасяващо. Решението беше да се накове ръчно вентилатора на максималната възможна скорост.

Имахме сериозен проблем със смущения в микрофоните, при които опрях до там да извадя малкия SDR dongle и да слушам ефира, да видя какво точно се случва. В общи линии имаше зашумяване в целия ефир около нашите честоти (520, 530 и 750MHz), като единствено headset-а ни на 2.4ghz работеше добре, и с останалите май доста изтормозихме публиката. Текущата хипотеза е, че най-вероятно смущенията са идвали от доста мощния поточен бойлер, който беше наблизо, та издирвам някой с такъв, за да идем близо до него и да тестваме дали има тоя ефект. След това вероятно ще си мислим и екраниране…

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

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

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

От фондация “Отворени проекти” пуснахме становище по въпроса, което initLab подкрепи, и се надяваме още хора да се зачетат и коментират.

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

Та, ако смятате, че има нещо полезно, което да кажете – на сайта на предложението може да пуснете коментар. Самият сайт е доста куц – праща ви паролата по mail-а в plaintext, и има всякакви малоумни неща, като да не може да се слага каквато и да е латиница в title на коментара, и какво ли още не – но е официалният начин да се пращат коментари към институцията, която е изготвила законопроекта и поне донякъде са задължени да им обърнат внимание.

Направихме и втория BGP workshop, на който още хора откриха колко лесно се подкарва IPv6 :) При достатъчно желаещи ще направим и трети след около месец. Също така може да помислим по въпроса хората да имат отделно устройство за подкарване и да са си сами потребители, понеже една от най-гадните задачки се оказва да убедиш всичките ти приложения на операционната система да се bind-ват на определен ip адрес, когато излизат навън.
(а аз тотално се изложих, понеже мислех да се включа вместо един от участниците, който не дойде, ползвайки pine64, което ми пристигна наскоро, и някъде на средата открих, че kernel-а му няма 802.1q и че трябва да компилирам отнякъде нов… което ще свърша, като си подкарам някаква среда скоро).

От интересните неща, които (пре)открихме беше, че ICMP echo reply от 8.8.8.8 винаги е орязан до 64 байта payload, колкото и голям пакет да се прати. Това води до въпроса “абе, защо нещо някъде ми реже пакетите?”…

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

(а вечерта бяхме на Jimmy Carr, от който лицето още ме боли от смях)

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

Как бихте реализирали система за backup, на която сървъра не може да прочете данните на клиента (т.е. са криптирани подходящо) и compromise на клиента не води до възможност за декриптиране на backup-ите му?

Ако имате 12 диска, кое е по-reliable – 2 raid масива в raid5 от 6 диска или 1 масив от 12те диска в raid6? Кое е по-производително?
(изобщо, какво е raid6?)

Имате дърво с директории и (много) файлове в тях, как ще намерите кои файлове се повтарят?
(задължително трябва да се знае какво е -print0)

Какви са трите типа ssh тунели? Какво е socat?
(ssh трябва да го знаят всички, socat-а почти на всички някога е трябвал)

Пак към ssh-а, защо не трябва да се логваме на чужда машина с agent forwarding и как точно се exploit-ва?
(това е забавна задача за практическо упражнение)

Защо не трябва да се сверява часовникът на машина с ntpdate, който се пуска от cron-а веднъж на ден/час?

При смяна на DNS запис с TTL от 3600 секунди, колко време отнема да се научи от 90% от internet? 95% ? 99% ? 100% ?
(същия въпрос за 60-секунден TTL. Bonus points, ако споменат на БТК/vivacom малоумните resolver-и)

Защо на натоварен linux сървър не трябва да има swap?
(не мисля, че е само за linux, но трябват малко тестове още за останалите)

Какво е rollback plan и кога трябва да имаме такъв?
(bonus points за “винаги”)

Защо не трябва да се смесват различни модели/производители на дискове в един и същи raid масив?

Каква е разликата м/у strace и ltrace?

Какъв е основният протокол за контрол/комуникация с мрежови устройства?

Защо не трябва да се филтрира цялото ICMP?

Как можем да сменим root паролата на linux-ка машина, като имаме достъп до конзолата?
Как можем да направим това трудно/невъзможно?

Защо не се ходи с къси гащи в datacenter?

Предимства и недостатъци на hardware и software raid?

Инструменти за анализ на натоварването на машина, кои в кои случаи се ползват?

Ще правим втори BGP workshop, пишете ми да ви запиша (вече има 11 човека в списъка).

(трябва да ви има тук, за да ви броим за записани)

Update: Workshop-ът се премести на 3.04, понеже преди това има ArduinoDay.

И направихме първия BGP workshop. Бяхме бая на гъсто, но като цяло се събрахме.

Бяха се записали 18 човека, 2-3 не дойдоха (Мариян замести единия), всички успяха да пуснат повечето си сесии, като една част от хората подкараха и IPv6. Беше малко разбъркано от организационна гледна точка (хората идваха по различни време, някои си тръгнаха по-рано и им изпаднаха сесиите), но мисля, че всички се забавляваха :)

Целта на занятието беше хората да подкарат BGP в трите стандартни сценария – transit (т.е. връзка към internet доставчик, който дава пълна routing таблица), втори transit, два peer-а (т.е. хора, с които си търкаляте трафик само за вашите мрежи), и internet exchange (един vlan, два route server-а и свободна обмяна на prefix-и). Имаше свързаност през AS200533 (initlab) и с една врътка отделно през AS57344 (telehouse), ето и схема на setup-а.

Имаше всякакви забавни проблеми, например основния, че хората по подразбиране не се сещат да сложат филтри и няколко пъти беше пускана пълна таблица през exchange-а. Друг интересен момент беше, че понеже exchange си announce-ваше и собствената мрежа, OpenBGPD по някаква причина слагаше път към нея през самия route server и се губеше възможността да се говори с другия. Имаше и забавни сблъсъци м/у опитите за настройка на мрежата и network manager, който решаваше да изтрие разни неща.

Имахме различни интересни устройства, като повечето бяха linux-и с quagga или bird (доста от тях на flash-ка с ubuntu от Мариян), няколко бяха на raspberry pi или подобни мижави устройства, имаше един малък juniper-ски router и един JunOS във виртуалка.

Имаше сериозен интерес (18 записани човека, и 6-7 още, на които отказах, защото нямаше място), та вероятно ще повторим упражнението пак след няколко седмици, ще се обяви тук и на разните места за целта (и ще пиша на всички, на които отказах за тоя път).

Ще направим първия BGP workshop на 13.03 в лаба, от 13:00 в лекционната. Желаещите да се запишат да ми пишат (или на Мариян) и да кажат с какво устройство ще са или дали ние ще им осигурим някакво (за да участвате, трябва да ви има записани в wiki-то за тая дата.

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

Update: Местата за това провеждане се запълниха, ще пиша кога ще правим следващия.

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

In other news, с Мариян мислим да правим BGP workshop. Ще се случи в initlab, като датата не е ясна, има един doodle по въпроса, а някакво описание може да се намери в лабовото wiki.

Накратко идеята е хората да дойдат, да си пуснат някакво устройство (което или те си носят, или ние им даваме в някакъв вид, или си boot-ват една flash-ка на лаптопа) и да си подкат bgp и routing в три стандартни сценария – upstream-и, peer-и и internet exchange. Ще раздаваме съвсем инстински адреси за анонсиране, та някаква част от упражнението ще е видима от internet :)

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

Тази година направихме доста по-сериозен setup за видео-записа. За малко начална информация, може да видите схемите за зала “България”, камерна зала и студио “Музика”.
(или доста по-артистично нарисуваните от Guru схеми за зала “България” и камерната зала)

Изискванията ни тази година бяха доста по-високи от предишните:
– Възможност за гледане на камерата или директно на сигнала от лектора, за всички зали;
– За двете по-големи зали, възможност да се снима задаващия въпроса от публиката;
– Пак за двете по-големи зали, контрол от видео-миксера какво излиза на изхода на проектора;
– Поне 720p разделителна способност на записа;
– Full HD (1080p) stream от зала “България”;
– Стерео-запис и стерео-звук от зала “България” (които не се използваха, защото лекцията, на която се очакваше да трябват отпадна в последния момент);
– Запис на случващото се на сцената (свирещите музиканти) в зала “България”;
– WebM stream (което отпадна, поради липса на време и мощност за encode-ване).

Всичките ни setup-и имат следните общи идеи:
– Всичкият звук се събира в един аудио пулт, от него се изважда звук до озвучаването на залата и до една от камерите (която маркираме като primary камера). Това се прави, за да сме сигурни в синхронизацията на звука и видеото (иначе има шанс да се получи един-два кадъра разсинхронизация на звука и видеото, което е доста дразнещо);
– На primary камерата се държеше memory карта, на която се правеше backup запис;
– В зала “България” през миксера минаваше и intercom-а, чрез който се комуникираше с операторите;
– По принцип в залите разполагахме камера за близък план (да снима лектора), общ план и към публиката (т.е. към задаващите въпроси);
– Всичките видео източници – видео камери, лаптоп на лектора и т.н. – се настройват да изваждат същата разделителна способност на същия refresh rate, и се вкарват в един видео миксер (някакъв ATEM), по SDI или HDMI (за по-близките). За целта камерите се настройват на същото нещо, а за лектора на лаптопа се слага scaler, който да може да приеме различните входове и да сгъне сигнала.
– От видео-миксера се изважда сигнал за запис (основно на atomos ninja или нещо подобно), сигнал за restreaming, в две от залите – сигнал до проектора.
– Streaming-а се изпращаше до един сървър, към който се закачаха reencoder-и, за да изкарват stream-овете с различните качества.

Зала “България” беше на 1080i60 (t.e. 1920×1080, 60Hz), другите две зали на 720p60 (1280×720, 60Hz). Честотата се подбира така, че да не се получава мигане, ако камерата вижда екрана (което миналата година беше сериозен проблем в записите). Разделителната способност беше такава, понеже в двете по-малки зали scaler-а можеше да изважда 1080p или 720p, а видео-миксерите не поддържа 1080p като вход.

Тази година за setup-а имаше доста улеснения, които си направихме по време на подготовката:
– Макари с навити кабели, които лесно да могат да се разпънат (и после съберат);
– Готово dolly за камера, така че сравнително лесно да може да се мести;
– Изтестван и лесен интерком до камерите;

За съжаление имахме доста проблеми при setup-а и се наложи да откараме до около 1:30 на място, за да ги изчистим. Доста от техниката ни пристигна след 9, имаше концерт в камерната зала, имахме на няколко пъти проблеми с тока от различни фази на съседни контакти, и имаше няколко сложни неща, които се наложи да правим (включващи катерене по стълби и инсталация на техника по тавана в едната зала).

Има нов set видеа от openfest 2015, които могат да се намерят в youtube или в нашия архив. Нещата са от първия ден на феста от зала България, като имаме отделно музиката, която се свири в главната зала (youtube или нашия архив).

Остават още 11 лекции, и има проблеми с още 2, за които ще видим дали можем да направим нещо. Извинявам се за забавянето (което си е съвсем по моя вина).

Около CCC се видях с хората от FOSDEM, споменаха ми, че имат нужда от хора за видео екипа, та преди няколко дни се замъкнах там, с Марио, Маги, Любо1 и Любо3 …

FOSDEM е интересно събитие. Името идва от Free and Open-Source Developers’ European Meeting, и си е точно това – събират се огромно количество разработчици на различни проекти и си разказват разни неща. По случая има 25 зали, като повечето от тях са DevRoom-ове, т.е. ориентирани към един проект. Това, комбинирано с мястото – кампусът на ULB, т.е. няколко разпръснати сгради в различна възраст и вид (от такива, каквито може да очакваме в провинциален изпаднал български “университет” до хубави и лъскави такива) създаваше доста проблеми…
(сумарно по една сметка е имало около 618 лекции)

Като цяло, моето преживяване там се състоеше от три дни ранно ставане (6:30 си е гадно даже по CET), носене и дебъгване на техника напред назад (в събота имаше за добавка много дъжд и по едно време якето ми беше повече вода, отколкото яке) и малко писане/дебъгване на други работи. Понеже самите devroom-ове осигуряват някакви хора да се грижат за самото протичане на лекциите и т.н., има идеята те да се занимават с оперативната част на аудио и видео нещата, но нещо не се получаваше.

FOSDEM-ският setup за видео/аудио е доста интересен. Това е схемата на setup-а на една зала, идеята е следната – дават се две кутии (доста приятно изглеждащи, от дърво, рязани на лазер, изглеждат така), като в едната се включва лектора, в другата – камерата. Микрофоните и т.н. озвучаване от залата се включват в камерата, и самата камера на единия си канал вади този сигнал, на другия – звукът от нейния собствен микрофон. Двете кутии по отделно пускаха по 2mbps h.264 stream до централно място и го записваха при себе си, а на края на деня записите от тях се преточваха до централно място. Гледането на stream-а беше гледане на двата паралелно, а записите ще са двата stream-а, смесени по определен начин (вече има някакви качени на сайта).

Проблемите бяха доста:
– софтуерът, който трябваше да контролира кутиите (в тях имаше едно bananapi с linux) се оказа счупен, в петък ремонтираха някакви неща, но записите от събота сутрин поне за момента ги няма, а streaming-а припали в неделя по някое време.
– При 24 зали и 25 камери (една резервна) нямаше как всички да са еднакви, и три от тях бяха доста неприятни. Като цяло имахме 3-4 различни модела, с някакви странности (част от тях си забравяха настройките при падане на тока). Всички бяха вързани на HDMI, което донякъде улесняваше процеса.
– Пак при тия 24 зали нямаше достатъчно информация за хората в тях как да оперират камерите, което и вероятно ще си проличи на записите.
– Звукът се осигуряваше от екипа на университета, и там имаше доста трагични моменти, например всички безжични микрофони в една сграда да са на същата честота. Също така не бяхме успели да изтестваме всички камери директно по залите в петък, и се оказа, че на някои места звукът идва на line, на други – на mic ниво.
– Като цяло видео екипът беше малък – имаше голяма нужда от още хора, ние петимата бяхме половината екип и не ни остана много време да седнем. Не помогна това, че всичко ни беше в една сграда (която е в единия край на кампуса) и трябваше да ходим до останалите всеки път, като се налагаше да се види нещо.

Имаше и разни хубави неща (които може да се опитаме да направим и при нас):
– Имаха много добри walkie-talkie-та, които бяха по tetra – цифрови, без шум, и в общи линии се чуваха спокойно по целия кампус. Имаше малко хардуерни проблеми с някои от тях, но като цяло бяха супер и ми се ще да ги ползваме за следващия openfest (но ме е е страх да проверявам цени).
– Това с опростяването на video setup-а е стъпка в правилната посока, трябва да измислим и ние нещо такова (но малко по-гъвкаво).
– Имат доста хубав setup за encode-ване, а ако бяха подкарали системата за рязане, при която самите стаи си отбелязваха края и началото на лекция, щеше да е страхотно.
– Доста от координацията я правехме с един piratepad, в който се отбелязваше текущия статус, какво кога следва и разни графици. Вършеше добра работа.

(както винаги на събития, на които съм в организацията – не съм гледал нито една лекция)

Update: Снимка от прибирането, банда полузаспали хора.

Кодът, който пиша е грозна работа и пълен с hack-ове. Явно така ми харесва :)

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

Редове 11-18 се занимават с това да сменят статуса на лампите. Това, което правят е просто да сменят статуса на релетата на netcontrol-а, id-тата са от 13 до 15 включително (което отговаря на релета от 5 до 7, втория set в устройството).

Редове 20-39 се занимават с взимането на текущия state на системата:
– ред 23 взима дали е ден или нощ, от една малко patch-ната версия на sunwait. Сметката е сравнително проста, има я описана на доста места и се оказа един от най-лесните начини. (очаквах да има директно инструмент в debian, дето да ми го каже, но не открих такъв)
– ред 24 взима дали лампите са светнати, като взима статуса на едно от релетата. Това е малко некадърно, понеже поглежда дали е светната само една от лампите, но ме мързи да измисля по-приличен начин, който да лови неконсистентно светнати лампи. Също така това може да се направи доста по-човешко, без cut и awk.
– редове 26-29 питат контрола на входната врата дали е заключена или не (системата е описана във wiki-то на лаба).
– и редове 31-37 проверяват дали trigger-ът за форсиране на светването на лампите е вдигнат (който е един файл в /tmp)

Редове 41-44 са функция за печат на текущия статус, в общи линии за debug-ване.

Редове 47-53 инициализират един пакетен unix domain socket, който е в общи линии нещо като UDP socket – лесен начин за получаване на отделни съобщения. Инициализираме го за получаване, връзваме го във файловата система и го правим nonblocking.

На ред 56 ни започва главния цикъл.

В началото на цикъла се възползваме от socket-а (редове 57-61), като изчакваме или да се появи нещо на socket-а, или 60 секунди, което се случи по-рано. В първоначалната версия socket-ът го нямаше и имаше просто sleep(60), но така се налагаше да се изчака всеки път sleep-а, преди да се промени нещо. Така е възможно когато fauna-та получи информация, че вратата е отключена, да форсира демона да препровери състоянията и да светне лампите.
Тук може четенето от socket-а да се прави, докато не остане нищо в него, за да можем да се предпазим от DoS-ване, заедно с някакъв минимален timeout.

Нататък (редове 63-66) взимаме текущото състояние и dump-ваме малко информация.

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

Редове 73-84 хващат моментите, в които лампите са включени:
– Ако е ден и не сме форсирани от trigger-а, гасим лампите;
– Ако е нощ, вратата е заключена, не е вдигнат trigger-а и са минали 15 минути от заключването, гасим лампите. Така човек може да си тръгне спокойно от лаба и да не се пребие в тъмницата, като му угаснат лампите веднага като заключи.

Редове 86-97 обработват ситуацията, когато лампите са изключени:
– Ако trigger-ът е вдигнат, палим лампите;
– Ако е нощ и вратата е отключена (т.е. има хора в лаба), палим лампите.

Системата е кратка, цялата е един hack и работи прекрасно. Интегрира се лесно със съществуващите друг системи в лаба и ни дава още една доста полезна функционалност, и ни спестява да се сещаме да включваме лампите, когато навън е тъмно и railsgirls имат да идват към лаба :)

Човек и добре да живее, трябва да прави интервюта.
(и после почва да живее зле)

Писал съм преди за интервютата, дето правих, но не очаквах нещата да станат по-зле… От известно време в securax си търсим php и js програмисти и QA, в чиито интервюта участвам, и идват всякакви интересни хора.

Процентът хора, кандидатстващи за програмисти и неспособни да напишат fizzbuzz се е увеличил. Освен стандартните грешки в самия код, имаше един-двама човека, които казаха, че “това без internet не могат да го напишат” и един случай, в който седнаха да пишат очаквания output вместо програмата, която да го прави.
(рекордът беше днес, когато след като дадох на един човек задачата, той просто си тръгна с някакво оправдание)

За QA и понякога за програмистите имаме един тривиален тест с няколко математически/логически задачи, да ги видим как/дали мислят и дали разбират английски (което си е доста важно при нас, понеже някаква част от фирмата не говори български). Откриват се всякакви странности, например:
– едната задача е да се сметне ако нещо с ДДС е 600 лв, колко е без (ДДС-то е 20%). Редовният отговор е 480, и имаше два куриоза – 400 и 576.
– друга задача гласи “One brick is one kilogram and half a brick heavy. How much does a brick weight?”. Повечето хора казват или един килограм, или килограм и половина, а много директно не могат да си преведат цялото изречение и си мислят, че им се казва “една тухла тежи един килограм”…
– има няколко глупави въпроса като от обща култура, които нямат голям смисъл, но водят до забавления. Единият е “Who was the first person in space”, на което двата ми любими отговора досега са “Louis Armstrong” и “Adam”.
(и сигурно ще сменя тия задачи, че вече са ми скучни)

В повечето случаи изобщо не се стига до по-сложни въпроси (алгоритми, сложности, някакви практически проблеми, fizzbuzz без if-ове), просто защото не са по силите на човека. Идея си нямам дали само при нас е така, или просто аз помня само ужасяващите случаи, някой има ли наблюдения по въпроса?

Днес свършихме още едно добро дело за initLab – доподкарахме системата за лампите по фасадата.

Цялата работа тръгна от това, че на ул. Рила (на която е лаба) в голяма част няма осветление, което притесняваше хората, които трябваше да идват/да си тръгват по нощите. Преди година-две писахме на общината, отговориха ни, че някой хубав ден ще сложат, прехвърлиха топката към някаква фирма за общински поръчки и нещата така си останаха. В един момент Пешо каза, че те 10-20-30W LED лампите не харчат много ток и светят достатъчно силно, не пречи да сложим ние малко лампи и да осветяваме улицата.

През лятото си взехме стълба, лампи и в рамките на седмица-две монтирахме лампите, заедно с ключове, с които да се светват. Понеже сме мързеливо племе (и в автоматизацията е истината), сложихме на всяка лампа по едно реле, и с един neomontana netcontrol си навързахме управление да си палим автоматично лампите. Днес подкарахме целия проект, който си има страничка във wiki-то, и някой ден може да се навия да кача source на контролиращото нещо (от което за сега има само screenshot, понеже е някаква адска гняс от shell script и php).

(от забавните неща, patch-нах си малко sunwait да ми казва дали е ден или нощ)

ИББ на 20.01.2016 ще бъде в Кривото на НДК (защото ще се прави ремонт в това на “Дондуков” и “Будапеща”), запазени са места от 19:00. Седмицата след това пак сме си в старото.

Добрите хора, дето анализират активните проби на големия китайски firewall са пуснали инструменти за преглеждане на логове – bz2 или директно git clone https://www.bamsoftware.com/git/active-probing.git . Няма лошо да свалите и да тествате дали се намира нещо по вашите логове, ако е много, може да питате researcher-ите дали ще им е полезно :)

За някои типове логове се налага малко пипване, например в grep-garbage-http.py да се пипне regex-а да е

combined_log_re = re.compile(r'^([\w:._-]+) ([\w._-]+) ([\w._-]+|"[\w._-]*") \[(.*) ([+-])(\d\d)(\d\d)\] "(.*)" (\d+) (\d+|-) "(.*)" "(.*)"')

(маха се $ накрая, понеже в моите логове накрая се сипва vhost-а)
За един друг тип логове направих

sed 's/^[a-z0-9:.]* //' 

за да почистя от началото vhost:port (понеже се оказа, че имам и такива)

Едно от нещата, с които се занимавам, е да помагам на Общество.бг с разни админски дейности.

opendata.government.bg е един от техните проекти, който след доста мъки се deploy-на в държавната администрация, и има някакво количество проблеми с хостинга си там (например падаше около DDoS-овете около изборите). Днес в един момент видях някакви аларми на monitoring-а за машината и открих, че ми е доста трудно да се логна, и се зачудих дали няма някой нов DDoS, и на smokeping-а ситуацията изглеждаше зле.

Порових се малко и въпреки сериозното натоварване се оказа, че (учудващо) CKAN-а (който е писан на python) явно удържа на напора и сервира спокойно каквото му искат хората. В крайна сметка бяхме успели да претоварим shaper-а на виртуалката (или знам ли, целия host), което май има шанс да се оправи тия дни.

По-интересното обаче беше причината – за пръв път публикувана и систематизирана на едно място информацията за проверените агенти на ДС. Мен лично ме радва как интересът към това не спада, и че въпреки че се чуват гласове “какво от това”, че данните не са точни, не са пълни и т.н., те са добра стъпка към запомнянето на миналото и историята.

Надявам се да има още такива данни, които да предизвикат интереса на хората :)

И кратка равносметка на 2015:

– Приключих с първия пас на редактирането на Reverse engineering for beginners, и може да помисля за втори в/у новите неща, които са се появили.
– Правихме пак курс по сигурно програмиране, след който заедно с още няколко неща там вече нищо общо не искам да имам с ФМИ.
– Направих нов не-курс, този път си сглобихме малко ISP, като някаква част от setup-а му остана за net-а на initlab.
– Пуснах ipv6 тунелен брокер за разни хора, дето си нямат ipv6 у тях (и вече някои от тях правят странни топологии :) ).
– Направихме доста събития от турнето;
– Случи се openfest 2015, където с Яна бяхме главните координатори. Не беше леко преживяване, и още не съм си подредил мислите по въпроса. (Видео-записите – скоро).
– Почнах пак работа в securax, като още ме е срам да казвам, че се водя мениджмънт (и за да компенсирам, админствам малко неща).
– Направих една лекция, и написах една друга до средата. Мисля, че трябва да отделя малко повече време в писане.
– Пак не блогвах достатъчно.

(мислех да кача малко снимки, дето съм правил на 32c3, но повечето са на бутилки от whisky workshop-а)

И последен ден на конгреса.

(личеше си, че някакво количество хора са си тръгнали, стана по-хладно и имаше повече въздух за дишане. Това 1.2mw топлина не си е работа…)

Почнах с лекцията за searchable encryption, която обаче си беше доста слаба – нямаше нищо ново и като цяло беше представена лошо.

Лекцията за DDoS mitigation проблемите в общи линии беше най-вече грешки, които системите за защита допускат, имаше някакви интересни неща, но не беше нещо особено.

Infrastructure review ми е от любимите лекции на тия събития и тая година не ме разочарова – пълно беше с интересни неща за различните части от инфраструктурата, за проблемите, които са имали и трудно може да се предаде с няколко думи, просто я гледайте :)

Закриването ставаше, като цяло нямаше много информация в него (малко статистики, но не казаха къде ще е събитието догодина).

Следват няколко дни почивка в Хамбург и прибиране към София.

Ден трети на 32c3.
(да отбележа, пиша това след whiskey workshop-а по събрани бележки)

Започнах деня с “In)Security of Embedded Devices’ Firmware – Fast and Furious at Large Scale” – лекция, в която се обясняваха методи за събиране и статичен и динамичен анализ на големи количества firmware за различни устройства. Като цяло доста полезно, въпреки че разчита доста, че повечето неща са linux-базирани (което си е така в твърде много от случаите).

Последваха две лекции за TOR. Първата беше по темата hidden/onion services (сменят термина), като най-накрая ще има hidden service на един hop в мрежата – т.е. ако просто се знае кой сте и искате да предоставяте услугата в мрежата, може RP (точките, през които се свързват с вас) да са ви наблизо, а не на 3 hop-а (което доста забързва нещата). Също така сменят малко алгоритми и се очертава .onion адресите да станат доста по-дълги и трудни за помнене.
(в този или следващия talk споменаха за RFC-то за .onion домейна, което си е доста добро постижение за проекта)

В “state of the onion” разказаха за какво се случва в проекта, организацията му и че са пуснали първата си кампания за набиране на средства.

Лекцията за “Gibberish detection” беше доста интересна и даваше следващото средство в arms race (някой да ми намери превода на български) с борбата със спамещи domain-и и подобията им, метод за разпознаване дали дадено име е “смислено” или някаква глупост. Кодът им го има в github, и ще е интересно да се интегрира в wiki-та и подобни системи.

“10 years after “We lost the war”” иска отделен blog post. Гледайте през relive и мислете по въпроса, а аз ако намеря някъде текста, ще го публикувам с коментари. Не просто си заслужава да се чуе (и да се изтърпи, понеже на моменти е бавна), директно си е важна, понеже това е лекция от типа “как да променим света” (от смислените такива).
(също така, note to self, да напиша нещо по темата utilitarian use of power, което е проблем, който аз самия имам)

Не гледах нищо повече от деня, понеже говорих с разни хора по разни теми (например по работа с хора от TOR, дано излезе нещо), последва whiskey workshop-а, на който си харесах разни неща, които съм снимал и ще кача тия дни.