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

Ето какво има зад цензурираните части:

Страница  32

Страница 33

Страница 41

Страница 42

Страница 43

Страница 44

И за да не реши някой, че нещо “тайно” съм публикувал – Дневник просто са копирали от PDF-а и без да искат са качили открития текст.

Та така. Следващият път – по добре.

На този фон, онзи ден чета това. Освен непосредственият популистки ефект, ако това стане ще бъде и вредно за и без това хилавото електронно управление в България. Връща ни към момента, в който институциите се занимават с несвойствени дейности – издаване и поддържане на персонални кодове, задължително различни и по различни правила. Издаването на ПИК е по подобен начин на електронния подпис, но не ходиш на едно място, веднъж на една до три години, а във всяка институция; не може да се използва навсякъде по сходен начин, а според каквито бюрократични правила са генерирали локалните публични администратори; сигурността не е много по-висока от тази на име+парола, прави възможни цели класове MitM и side channel атаки, няма възможност за стандартно криптиране + липсва концепцията за неотменяемост, при която не може след това да кажеш “не бях аз”.

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

За Държавата:

• Вместо да подкрепя ретроградни схеми, технологично подходящи за края на 90-те, да промотира използването на Квалифициран електронен подпис, чрез въвеждането на допълнителни отстъпки, правещи го икономически ефективен;
• Вместо институциите да мерят колко десетки-стотин-ХХХ нужни общо на 0.5% от потребителите електронни услуги са внедрили, да си погледнат обобщените статистически анализи и да реализират приоритетно най-използваните и с най-голяма административна тежест;
• Когато се замислят нови режими и промени на съществуващите, да се използва момента и за електронизация на процеса – завърти ли се колелото веднъж, нещата винаги стават по-трудно и стресово за потребителите и администрацията;
• Три институции предоставят около 90% от всички използвани електронни услуги в България. Добри или лоши, те работят и всеки ден десетки хиляди си спестяват много нерви и време. В “нормална” държава тази практика ще се мултиплицира и доразвие, но при нас да откриеш колелото и след това да се похвалиш си е в реда на нещата.

За доставчиците на удостоверителни услуги:

• Профилите на издаваните сертификати продължават да се различават, което от своя страна затруднява разработчиците;
• Има дори един доставчик, който в опита си да е by the book, така се е увъртял, че част от най-разпространените библиотеки за работа със сертификати не могат да им парснат публичните части коректно. Ако толкова държаха да издават така, нормалното продължение би било да се пуснат бъгове, да напишат малко код с pull request, където е възможно. Ама не, дебелокожото “ние сме си ОК и си издаваме така” е широко разпространено…

За разработчиците на електронни услуги:

• Коректната имплементация на подписване+верификация не е тривиална задача. Не я подценявайте. Вижте кой какво е направил и питайте, поне първия първия път, когато ви се налага да създадете нещо в областта;
• Когато трябва да се направи горното, но многоплатформено е още по-криво. Обикновено това е последна грижа и на клиента, та все не остава ресурс за него. Планирайте добре, натиснете клиента – отложите ли многоплатформеността, може да отнеме години, а междувременно увеличаващите се потребители на алтернативни OS с право ще ви “хранят”. Грубо и звучно.

За потребителите:

• Огледайте се. Страниците на доставчиците на удостоверителни услуги са добро начало за старт. Може да се окаже, че това, което ви е необходимо е вече разработено и внедрено. И цената на подписа ще е една добра инвестиция;
• Натискайте институциите, където смятате, че може да се подобри нещо. Където нещо може да се електронизира. Където липсват услуги, а ви трябват. Обратната връзка не винаги отива в кръглата папка и ще помогне приоритизацията и планирането на задачите.

P.s. Написаното е мое лично мнение, което не е задължително да съвпада с позицията на споменатите и тези, които ще се разпознаят.

Идеята се роди в края на деня, в който представихме целия софтуер за компютърната обработка пред ЦИК, неправителствени организации и медиите. Тогава се разви една не особено ухоприятна дискусия, която във времето се разви и прехвърли в различни форуми. Изписаха се множествени простотии, тук-таме и ценни мнения. Някои пък използваха темата, за да отправят личните си нападки към където/който са си набелязали, с което разводниха допълнително и без това оцапаната дискусия.

Изводите за мен са няколко:

• Хората не знаят какво се случва от момента, в който са пуснали бюлетината до обявяването на резултатите. Недоволни винаги ще има, а практиката да се култивират бъдещи аргументи не е от вчера;
• Други хора, които не разбират от софтуер, още по-малко от свободен такъв, се изказват компетентно и дават ценни съвети. Дори и с най-доброто желание да помогнат, в сегашната ситуация това единствено пречи на нормалното протичане на изборите;
• Досега мислех, че в България повече хора могат да делят и сравняват дробни числа, отколкото да програмират, но явно наистина сме нация техническа.

Самата методика си има и своето чисто програмистко предизвикателство. Задачи с близка сложност вървяха по ученическите олимпиади. Тъй като ЦИК така или иначе публикува числовите данни, та дори и по новия Изборен кодекс сканираните протоколи, нищо не пречи да си организираме hackatoon с награди, за по-интересно. По-глобалната цел е да има повече хора, които разбират от механиката на нещата и в бъдеще да могат да помогнат, като измислят нещо по-добро.

А и някои ще си припомним олимпиадните страсти :)

На финала, връзките отново:

Страница на конкурса: https://electionscontest.wordpress.com

Кодово хранилище: https://github.com/elections-contest/pe2013

• Премахната поддръжката за urlfilter.ini за Opera – това беше доста крив вариант за филтриране, който отдавна е deprecated;
• Добавена информация за Adblock Plus за Android;
• Коригирани статистиките за операционните системи – имаше проблем с визуализацията на Mac OS;
• Обновен списъка с филтрите – след голямото коледно прочистване са добавени доста нови, подадени от потребители филтри.

Ако все още не сте изпробвали технологията, открийте как на Adblock за българи. Промените могат да се следят и в Twitter.

Накратко, проблемът е, че в процеса на оторизация към Oracle базата данни, listener-а връща към клиента AUTH_VFR_DATA (salt) и AUTH_SESSKEY, без значение дали опитът за оторизация е успешен или не. След внимателен анализ, Esteban Martinez Fayo открива, следната зависимост:

aes192(AUTH_SESSKEY, sha1(real_password+AUTH_VFR_DATA)+0x00000000)[:40] == 0x0808080808080808

Това дава възможност да се инициира offline bruteforce атака, след прихващането на AUTH_VFR_DATA и AUTH_SESSKEY. Това става чрез директен sniff по мрежата или чрез включване на trace logging на ниво support в oracle client.

След като написах набързо работеща bruteforce програма, реших да се възползвам от multithreading, rule engine и оптимизираните криптографски имплементации на hashkill. Преработката като plugin стана за 20 минути, докато се ориентирам в кода, а след като Милен пое нещата в свои ръце се сдобихме с първата в света публична версия на o5logon чупачка върху GPU – браво!

Накрая, понеже oracle trace файловете са пълни с всякаква информация, а изваждането на сесията и salt-а е неудобно на ръка, спретнах python скрипт, който parse-ва данните и ги представя в hashkill или John the Ripper формат.

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

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

Така е то, всички администрации могат да се включат в eGovernment инициативите, дори и когато не подозират;)

1. И двата законопроекта изключват конвенционалното гласуване, ако си упражнил (в случая на ДСБ дори ако просто си се регистрирал) правото си на глас по електронен път. Гласуването е в рамките на 2 до 3 дена и то ограничено по брой пъти. По идея дистанционното електронно гласуване е, че то се извършва извън изградената защитена среда. Възможностите за контролиран вот по този начин са безгранични. За успешното протичане на процеса е необходимо времето да се удължи (например в Естония е 5 дена), без да има ограничения на броят на коригиране на вота от избирателя, което е напълно излишно. Ако все пак реши да гласува в секцията, подаденият глас по електронен път просто се инвалидизира на база избирателният списък. За инвалидизирането може да се приложи асиметрична криптография, която да гарантира анонимността на електронния вот. Последното апропо, би трябвало да се регламентира законово, а не да се оставя за оформяне в методически указания, защото има твърде много подводни камъни в имплементацията, които трябва да се премислят.
2. Поради липса на надеждна електронна идентичност, в проектите е предвидено поредното погазване на чл. 2 на ЗЕУ. Въпросът за достъпността на предвидените за регистрацията данни е ясен и на малките деца. По план обаче, до изборите трябва да да имаме първите издадени държавни eID карти, да не говорим за наличието и на електронни подписи. Последните, естествено по стар български обичай “по-католици от папата”, бяха леко скопени откъм идентификационни данни с последните промени в ЗЕДЕП. Още помня учудването в очите на естонските експерти, докато им обясняваха как в ЕГН-то има много тайни лични данни, та затова си правим харакири и позволяваме издаване на ЕП само с единия гол псевдоним вътре. Хората обясниха, че и техния национален идентификатор е по подобна на нашата схема и след кратко обсъждане, решили, че по-добре да си развиват електронното управление, отколкото да подкопаят основите му с един замах. Въпреки всичко, дори и малкото, което имаме постигнато на този фронт може да се използва успешно и с помощта на технически мерки да използваме сигурната отдалечена идентификация. Както между другото го правят стотици хиляди фирми и граждани ежемесечно с услугите на НАП, АМ и електронното банкиране.
3. ДСБ предлагат електронно гласуване в рамките на секцията чрез тактилен терминал. Хубаво, но цената няма да оправдае инвестицията. Какво ги правим после 12К терминали? Когато Русия изгради най-голямата в света мрежа за видеонаблюдение, по време на последните избори, паралелно с това вървеше и конкурс за идеи какво после да правят стотиците хиляди камери, активни мрежови устройства сървъри и т.н. В нашият случай вероятно областните управители ще трябва да им търсят место за съхранение. Да не говорим за десетките примери в световен мащаб за отказване от такъв вид гласуване поради несъвършенства на технологията и общото мнение на коментиращи, че си искат дистанционно гласуване през Интернет, а не упражнения тип 2009, когато имаше  подобно експериментално гласуване, но с неизвестни резултати.
4. ГЕРБ предлагат “От един IP адрес не може да гласуват повече от двама избиратели.”. Всеки системен администратор под, но все пак близо до средното ниво може да обясни защо това е абсолютно ненужно и даже вредно, защото създава false sence of security.

Разбира се, може още доста да се дращи по написаното в проектозаконите. Най-общо нещата могат да се систематизират така:

• Необходимо е да се преосмисли подхода за провеждане на дистанционното електронно гласуване (виж горе);
• Необходимо е да се използват стандартните математически и криптографски подходи за гарантиране анонимността на вота. Няма нужда да се преоткрива топлата вода. Съществуват готови решения в други държави, които България може да използва, както и множество комерсиални такива. За привеждането на готовите решения обаче в използваем за страната ни вид ще трябва време.
• Нормално би било платформата за дистанционно електронно гласуване да е с отворен код. Иначе отново ще се сблъскаме с такива изказвания.

* В законопроектът на ГЕРБ, електронното гласуване е предложено в §42. 042 (oct) = 0x22 (hex). Разбира се, че е случайно, за потвърждение може да гледате това (интервала 4:40-5:00 мин).

От години използвам Linux като основна работна среда.

От горното изречение, особено думата “основна”, личи, че понякога се налага и да се пали win/mac, където се стартират ред приложения, било поради недобра съвместимост, било защото просто са специализиран софтуер, писан само за конкретната операционна система.

Години наред решението бе да се закачиш на отдалечена машина по VNC/RDP/whatever и да си свършиш работата по най-бързия начин, преди да си се издразнил от разликите в интерфейса и от това да падне продуктивността. Възможностите за seamless интеграция (използване на отдалечените приложения въвместно с останалите в работната среда) бяха ограничени и трудни за конфигуриране и използване – SeamlessRDP на rdesktop, Seamless mode на VirtualBox, VMware Fusion и т.н.

Благодарение на развитието на проекта FreeRDP, вече имаме свободна имплементация на RemoteApp. Липсващото парченце от пъзела е приложение, което да улесни конфигурирането на отдалечените приложения.

За целта последните дни работих върху WinConn, графичен мениджър за RemoteApp приложения с отворен код. На страницата можете да видите задължителните снимки на екрана, видео в действие и да го инсталирате от моето PPA в Ubuntu.

Разработката на WinConn съвпадна с Ubuntu App Showdown – триседмичен конкурс за програмиране на приложения в Ubuntu. Ако ви хареса, след 10ти юли ще можете да гласувате чрез рейтинговата система в Ubuntu Software Centre. Разбира се, приемам всякакви предложения за подобрения, бъгове и т.н. в Launchpad.

Offloading-а на изчисленията върху графична карта (GPU) ускорява значително процеса поради специфичната архитектура на този вид хардуер. Съществуват платени и свободни(pyrit) имплементации за такъв вид атаки, като съвсем наскоро oclHashcat-plus също се сдоби с такава поддръжка.

За целите на одита на безжичните мрежи или ако просто искате да проверите дали някой не е прихванал и изпратил WPA handshakes към вашата мрежа за чупене, създадох Distributed WPA PSK auditor. Услугата приема WPA handshakes в libpcap формат и поддържа специално създадени и уникално филтрирани списъци с думи(wordlists). Самият сървър не извършва cracking процеса, като това се прави от потребители, които автоматизирано с помощта на help_crack свалят поредния packet capture и wordlist и тестват за съвпадение. Скрипта е написан на python и е многоплатформен. За момента под Windows се поддържа aircrack-ng, а под posix системи pyrit и aircrack-ng. Можете да видите открития PSK само за мрежи, информацията за които сте качили вие самите, като преди това е необходимо да сте си генерирали уникален ключ. Повече информация можете да откриете на самия сайт.

Идеята за всичко това дойде от sorbo, който поддържа wpa.darkircop.org. DWPA е написан от нулата и има доста разлики и подобрения – по добро управление на речниците, многоплатформеност на help_crack, специално създадени речници с помощта на wlc, оторизационна схема за достъп до откритите PSK и много други.

Когато пооправя сорса, ще го пусна с отворен код. Междувременно, можете да помогнете като дарите CPU/GPU чрез help_crack.

Ако някой се сеща какво още му липсва или има други идеи за Calibre, да пише смело, докато още ми се занимава с python :)

От спортна злоба реших да препипам сайта и когато ми прищрака ще пускам по нещо. Днес пуснах advisory, по проблем, за който разказах на последния OpenFest. Там имаше интересни коментари и се събраха още весели идеи по темата.

Ще ми е интересно да коментирате какво ново искате да видите на сайта.

Още с публикуването на addons.opera.com, статистиката за използването на българския лист се промени драстично, като Opera се изравни и в момента изпреварва Firefox. Не е ясно дали това е поради кривия update механизъм или реална работа, но това ще си проличи съвсем скоро.

Ако харесвате и използвате Opera, опитайте новото разширение!

Има разработено GUI приложение – Cryptonit, подобно да DSTool, което обаче отдавна не се поддържа от оригиналните разработчици – IDEALX/OpenTrust. В резултат, от доста време приложението крашва при старт на 64 bit платформа. Направил съм необходимите корекции и можете да намерите коригирана версия за Ubuntu/Debian в моето PPA. Настройването на приложението е тривиално.

От това веднага трябва да е станало ясно, че ключа за декриптиране вероятно е забит в самото приложение. След прилагането на не-чак-вуду-техники (strings and friends), нямащи нищо общо с reverse engineering, става ясно, че регистърът е криптиран с DES-CBC, а 20 минути по-късно декриптирането се свежда до една команда с OpenSSL:

alex@volatile:~$ openssl des-cbc -d -K [find_it_youself] -iv 00f00ab00bc00cf0 -in 29112010.TXT -out spam.txt

Разбира се, изпратих поща на КЗП за проблема, описвайки и възможността недоброжелател да декриптира регистъра и да го постне по руските и китайските спам форуми. След това резултатът е ясен, а действието ефективно ще подкопае и без това крехките устои на SPAM регистъра.

Отговор вече повече от седмица няма.

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

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

Съвсем свободно можете да разгледате информация, за това как са похарчени милиарди български и европейски средства тук: http://umispublic.minfin.bg

За всекидневната си работа използвам лаптоп, работния профил живее на TrueCrypt криптиран дял. Така имам два профила – другия живее в home директорията.

Когато преди няколко дни криптирания профил отказа да се зареди със съобщението, че вече се използва, го отдадох на регресия в trunk-а на Firefox. Странното беше, че този в home директорията работеше и премахването на .parentlock в TrueCrypt дяла не помогна.

Днес реших да огледам по-внимателно ситуацията и се оказа, че проблема съвсем не е в trunk build-а, а по-скоро в packaging-a – изключението в AppArmor, което е необходимо на този етап, не е обновено.

Ако имате подобен проблем, можете да направите следното:

Редактирате като root /etc/apparmor.d/usr.bin.firefox-4.0 , където заменяте firefox-4.0b7pre с firefox4.0b8pre (s/firefox-4.0b7pre/firefox4.0b8pre) на всички редове. Алтернативно вероятно ще откриете файла /etc/apparmor.d/usr.bin.firefox-4.0.apparmor , който е коректен и го заменяте с горния. След това проверете и symlink-а в /etc/apparmor.d/disable/usr.bin.firefox-4.0 дали сочи на правилното място(към основния файл, който заменихте)

За да приложите промените ще се наложи да презаредите AppArmor правилата:

sudo /etc/init.d/apparmor reload

Ден 1-ви
Хакер влиза в обществена столова и с възмущение забелязва, че всеки може да развие солницата и да сипе вътре каквото и да е. Прибира се той вкъщи и пише гневно писмо на директора: “Аз, meG@Duc|, открих уязвимост на солниците във Вашата столова. Злоумишленик може да сипе в тях отрова. Вземете мерки спешно!”

Ден 2-ри
Директорът сред прочие делови писма прочита горното и вдига рамене: “На кой идиот може да му дойде това на ума?”

Директорът на столовата разпределя документа на Отговорника по информационна сигурност по компетенция. Последният размишлява известно време дали да попълни Доклад за инцидент, Предложение за превантивно действие, направо Искане за коригиращо действие или някой друг документ, на който не му помни името. Свързва се с Консултантите, които обаче са заети с други клиенти и така или иначе не помнят какво са писали в Процедурите и Политиките за информационна сигурност. Те го финтират финно, като му обясняват, че откато са предали системата в ръцете на клиента, вероятно е имало развитие и не искат в желанието си да помогнат да навредят. На финала на разговора, му споменават, че всякакви ги имало и да не обръща внимание на такива простотии.

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

Ден 5-ти
Хакерът идва в столовата и сипва във всички солници отрова. Загиват 300 души, директора три месеца го влачат в следствие и съд и го оправдават за липса на престъпен състав. Хакерът пише писмо в стил “Видяхте ли?!!”

Вече съмнение няма и машината се задейства. Събира се Форумът по информационна сигурност, Консултантите са викнати по спешност, срещу съответното възнаграждение. Отговорникът прилежно е попълнил Доклад за инцидент, добавил го е в Регистъра на инцидентите, запознал е чрез Докладна-записка Групата за връзки с обществеността (Главният готвач и една от по-приказливите лелички), прегледал е окло 18 пъти Планът за непрекъсваемост на дейността, Матрицата за достъп, както и други странни документи. Консултантите проверяват всички записи и уверяват клиента, че системата работи.

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

Ден 96-ти
Директорът купува солници със специално проектиран катинар с код. Посетителите чувстват, че някаква идея в тоя живот им убягва.

Ден 97-ми
Хакерът забелязва, че дупките в солниците пропускат сол в двете посоки. И не само сол. Той пише възмутено писмо на директора и пикае във всички солници. 300 човека престават да посещават столовата, 30 попадат в болница с отравяне. За капак пише на директора СМС “Как е?” Директора три месеца го мотаят по съдилища и му дават година условно.

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

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

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

Ден 188-ми
Директорът се заклева до края на живота си да няма нищо общо със заведения за хранене и мирно да пренася дървени трупи в Сибир. Инженерите разработват нова конструкция солници с едностранна клапа. Междувременно сервитьорките прибират старите солници и раздават сол по заявка.

Ден 190-ти
Хакерът гепва 1 нова солница от стола и вкъщи изучава устройството й. Пише гневно писмо на новия директор: “Аз, meG@Duc|, задигнах 1 солница и намирам този факт за възмутителен! Всеки може да задигне солница от Вашата столова!” Директорът – заклет трезвеник – прочита писмото, прибира се вкъщи и удря една водка.

На другия ден, след пълна инвентаризация, отново се попълва Доклад за инцидент. Преглеждат се записите от видеонаблюдението и Дневниците на на сервитьорките с раздадените солници срещу подпис. С помощта на консултантите се извършва кросчек на обективните доказателства, който ограничава кръга на заподозрените до около 50 човека. Междувременно, Отговорникът по информационна сигурност наказва с Искания за коригиращи действия всеки, който срещне случайно в коридорите, в резултат на което служебните и клиентски тоалетни се препълват с изпокрили се служители на стола.

Ден 193-ти
Хакерът отива в стола и вижда, че всички солници са закрепени към масите с вериги. На поредната сбирка на хакерите се похвалва със своите успехи и получава заслужена награда за защита интересите на обществото и потребителите. За щастие директорът не научава за това и няма да се пропие преждевременно.

Ден 194-ти
В рамките на гениално обмислена операция всички хакери от сбирката се промъкват в столовата и изсипват всичката сол в джобовете си. Хакерът meG@Duc| пише възмутено писмо на директора, че в тази столова няма никаква грижа към потребителя и всеки може да лиши честния човек от сол за един миг. Спешно са нужни дозатори на солта, работещи след логване с парола.

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

Относно идеята за паролата, местния админ гуру обяснява, че тези неща не се правят така на парче и ще се помисли за цялостно решение, в унисон с най-добрите световни практики. Изпращат го навън за няколко месеца, за да почерпи знание от извора. Благодарение на обширните си познания и практика по ISO 27001, там си намира по-добра работа и се спасява с декларацията, че вече нещата са стабилни и полето за изява в столовата е му е отесняло.

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

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

Ден 200
Посетителите на столовата с ужас откриват, че за да си сипят малко сол, трябва да отидат при сервитьорката и да си покажат личната карта, за да получат специален 8-символен код за еднократна употреба за активиране на солницата. За черния пипер процедурата се повтаря.

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

Техническите подробности по инсталирането и конфигурирането са тук.

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

Искам да споделя общите впечатления при използването на reCAPTACHA за българи. Оказа се, че задачите, давани от тази услуга доста затрудняват средния потребител. Явно като човек, който прекарва доста голяма част от времето си да чете на чужд език, съм подценил сложността. Ето и тъжната статистика:

Близо 1 милион успешни попадения, малко повече reload-и и 160`000 неуспешни опита. Това определено показва, че reCAPTCHA не е подходяща за български потребители.

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

В края на краищата нещата се подреждат чрез прилагане на крути мерки кой, кога и на кого изпраща версия, много reverts и merge conflicts от централното хранилище. Нервите и времето, което отделихме е просто неоценимо.

Някой има ли опит в подобни ситуации?

Остава сега да видим доколко reCaptcha ще затрудни редовните потребители – още в началото имаше индикации, че е твърде сложно. Събираме статистика, която ще ни помогне да вземем решение дали ще оставим нещата така, или ще сложим по-четима captcha. Което от гледна точка на сигурността си е неприятно.

Ако някой има опит в подобна ситуация, да споделя “за” и “против” :)

Първо, след кратко търсене се оказва, че всички медии са пуснали връзки към 4shared или към svejo.net, като първото е самият хостинг, а второто – страница за споделяне на връзки между потребители в Интернет. В споделеното пространство в 4shared откриваме един tgz архив и 26 jpg файла, качени от потребител “kamchia”. Въпросният потребител явно е отбелязал, че не желае контактните му детайли да са публично достояние. Сваляме намерените файлове и без да се затормозяваме с отварянето им за момента, продължаваме нататък.

На svejo.net отново попадаме на познатият ни потребител “Kamchia”. Разглеждайки профила му откриваме, че е споделил още три връзки, отново към 4shared, но този път към файловете на друг потребител – gamizbond.(регистриран още на 2 окт 2009 г.) Тук вече имаме достъп до профила, в URL-то към който очевидно имаме санитиран електронен адрес: gamizbondabvbg -> gamizbond@abv.bg . Сещайки се, че svejo.net удобно използват Gravatar за показване на потребителските снимки, връщаме се обратно и виждаме генерираният аватар на Kamchia. Който е разглеждал услугата с по-критичен поглед знае, че в URL-то се подава MD5 хеш на електронният адрес, в случая на лицето в svejo.net, което споделя връзките. В нашият случай откриваме, че f4332600438ab3197ac61a3c99cc9431 е MD5 хеш от вече познатият ни e-mail gamizbond@abv.bg. Не беше силно изненадващо, но поне имаме някаква форма на доказателство за връзката kamchia <-> gamizbond.

Нека сега обърнем малко внимание на файловете. Декомпресираме архива, виждаме че съдържа всички останали картинки и проверяваме какво има в EXIF таговете им. В поддиректория gamizov, таговете са зачистени. От spravka , обаче става ясно, че картинките са сканирани/обработени с Adobe Photoshop CS2 под Windows, както и времето в което това се е случило. По резолюцията пък може да се проучи и моделът на скенера. Разбира се, EXIF записите могат да се манипулират.

По-интересни неща откриваме, разглеждайки хедърите на tgz архива. От тях става ясно, че *nix потребителя Nasko , от групата Nasko е компресирал файловете, имащи респективното време на модификация. С HEX редактора откриваме, че uid/gid на потребителя е 767. Това е малко странно, имайки предвид uid/gid резервациите при по-разпространените Linux дистрибуции е над 1000 (Debian/SUSE) и над 300 при RedHat базираните (а при *BSD?). Това значи, че за да има такъв uid, потребителят Nasko използва RedHat дистрибуция (респ. Fedora/CentOS) и то вероятно на споделен хостинг, от където е създал и качил архива на 4shared. Разбира се, горните записи също могат да бъдат манипулирани ;)

Горните действия ми отнеха под 10 минути. Следите може и да са финно моделирани, за да насочат в определена посока. Такава очевидно има и компетентните е време да поемат натам.

На този свеж фон, някои институции, било защото в тях все още се завъртат технократи, било защото са осъзнали, че това е единственият нормален път, развиват електронните си услуги. Всекидневно хиляди счетоводители подават различни документи, декларации, правят справки и т.н., без врява, без рязане на ленти и прочие дивотии. Това е станало за тях част от работния процес и те изискват всичко да работи безотказно. Само си представете, какво би станало в офисите на НАП, ако 120000 (от около 180000) фирми, подаващи в момента месечните си ДДС декларации с електронен подпис през Интернет, се подредят на опашка. Не искам да съм наблизо. И това е само за една от услугите.

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

Днешната случка има за мен два съществени извода:

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

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

Авторът е ръководил изграждането на част от електронните услуги на НАП. Изразеното мнение е лично и не трябва да се приема като официална позиция на която и да било институция.

След обновяването на системата ми до една от alpha версиите на Karmic преди време се оказа, че има регресия и електронния ми подпис не “захапва”. Ефекта беше, че при заредена PKCS#11 библиотека във ФФ, сертификата въобще не се показва. След малко ровичкане се оказа, че проблемът е в OpenCT – това е слоя, чрез който се комуникира с CCID четеца за смарткартата. CCID предоставя общ интерфейс за комуникация, който има добра поддръжка в OpenSC проекта и унифицира достъпа до смарткартата. За съжаление, версията в Karmic е с бъг точно там и това не позволява коректно да се разпознаят едни от най-разпространените четци в България.

Новата версия е оправена и доказано работи. Докато в Ubuntu обновят пакетите, аз компилирах коригирани за amd64 платформа. Ако имате подобни проблеми, може(х)те да ги изтеглите от тук. Разбира се, за кой ли път, не подкрепям безразборното сваляне на binary пакети от случайни места в Интернет :)

Не е бюджетна организация – точно така, в държавния бюджет няма пари за фирмата, каквото си изкара, това си яде.

ИО е печелившо дружество – например 3.5 милона, само за 2008 г., които се връщат в държавния бюджет под формата на дивидент към мажоритарния собственик МФ.

Не е избрана “по подразбиране” в държавните поръчки – всъщност ИО почти не участва в такива, поради това, че вътрешния ресурс редовно е “на ръба” и просто няма кой да поеме нови задачи. Дори има обратен процес – даден проект се печели от друга фирма, тя си оставя ръцете/свършва парите/съвсем нищо не прави/прави го “почти готов”/etc.  (подчертайте вярното) и когато ЕС (или други, с които в момента плашат в дадено ведомство) почука на вратата, се налага да се организират сложни спасителни акции – все за Родината, разбира се.

Не печели проектите на МФ без търг и процедура – структурата на ИО е така замислена, че максимално да покрива нуждите на министерството и агенциите към него. Специалистите, които работят в ИО познават много добре бизнеса на клиента. Това е изключително сериозно конкурентно предимство. Въпреки това и в МФ и в неговите агенции (НАП, Митници, АДВ и пр.) работят доста български и чужди фирми, но на едни други цени.

Не държи държавните регистри и бази данни – да, обслужва, развива и администрира част от тях, но в ИО реално живее единствено бившия търговски регистър “ДЕЛФИ”, който, поради промяната на законодателството в момента е на доизживяване. Обслужва се onsite и ЕСГРАОН.

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

Не печели от изборите луди пари – парите за информационната обработка на изборите са съвсем различни от пълните пари за изборите. Например, за Евроизбори 2007 + Местни избори 2007 ИО е взела общо 1’352’000 лв. Ако някой все още смята, че изборите са един прост калкулатор, нека зачете тук, за да разбере какво точно правим.

Над 800 човека!? Не сте ли множко? – Това е броя на служителите с клоновете по страната. В централно управление са приблизително половината. Компанията е системен интегратор, демек има всякакви хора – администратори, програмисти, тестови инженери,  поддръжка, обучение и прочие. За всичко това трябват хора, или поне никой още не е измислил как да го прави без.

В ИО работят по чиновнически калпаво – развойните екипи не са по-различни от тези в останалите фирми – работят по утвърдени методологии, програмират със съвременни средства. Създали са множество работещи системи, които се използват всекидневно от хиляди потребители. Само за една разработена услуга, например ДДС по Интернет, ежемесечно над 110’000 фирми си спестяват разхождането до офисите на НАП и подават данните си с електронен подпис по Интернет. Представете си ги сега подредени на опашки. А останалите успешни проекти, за които не се шуми – внедрени в МФ, Митници, БНБ, Сметна палата, ДКСИ, МО, електронния подис, съдилищата, детските градини, училищата…

В ИО работят с допотопни технологии – В ИО има различни екипи, които покриват почти целия enterprise развоен спектър – Oracle, Java EE, SAP, Microsoft.NET и т.н. Обаче от изискванията на клиентите не може да се избяга – поддържат се стари софтуери на DOS, Delphi и т.н. Когато възникне бизнес нуждата от пренаписването и технологичното им усъвършенстване и това ще стане. Наред с горните mainstream решения, има и много код изписан и на C/C++, PHP, x86 Assembler, Python и пр.

***

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

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

От това ще загубим всички. Без изключение.

P. s. Защо пиша за това ли? Затова.

“В рамките на България не беше нещо изключително. Първо, този вирус е относително стар. Второ, това е реплика на една стара технология. Това е компютърен червей, който, пуснат на едно място, сам започва да пълзи и да се разпространява. Той погасява домейните и не може да работи пощата. Едно от нещата, които прави, е, че изведнъж целият управленски потенциал на инфраструктурата изчезва. Дори и уебмейл. Той не разрушава данните, но задръства нещата и те спират”

Изказването е относно методите на червея Conficker и е направено от Евгений Николов, от екипа на NLCV към БАН.

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

Добър reverse engeneering на червея с доста подробности можете да видите тук:

http://mtc.sri.com/Conficker/

Силно се надявам коментара да е просто журналиситческа фикция и некадърност.

В края на краищата, днес ми писна да ми насича видеото по SSHFS и седнах да довърша започнатото.

В компанията на домашно розе и Sunday’s Fantasy – цигари, напълнени с тютюн за лула, направих бекъп и дръпнах направо топлия имидж от x-wrt.org. За рутери като моя трябва да се внимава с версията на Linux ядрото, тъй като wireless драйверите за 2.6 доскоро бяха силно експериментални и дори не ги включваха в имиджа по подразбиране.

Още в началото – греда: опита да ъпгрейдна през webif2 интерфейса се оказаха невъзможни. Проблема се крие в това, че haserl, wrapper-а за shell скриптовете, имплеметиращи интерфейса на webif2, е компилиран по подразбиране с максимална големина на POST заявката 2MB. Новите имиджи са от 2.3MB нагоре, според включените пакети. За да прескочите проблема, логвате се по ssh в рутера и действате от там с mtd по познатата схема. Препоръчително е да изтриете и конфигурацията (-e linux), защото няма да ви свърши работа с новите пакети на 8.09.

Wireless-а по подразбиране е изключен, активацията и настройката му при мен премина без проблеми. Ядове имаше с регистрирането на пренасочването на портовете (port forwarding). Новото Kamikaze 8.09 използва друг тип конфигурация на firewall-а, която явно от X-Wrt все още не са доизчистили. Опитите да се добавят rules през интерфейса(r4710) бяха безуспешни. Отново логване през ssh и ръчна модификация на /etc/config/firewall (за разлика от /etc/firewall в предишните версии). Обърнете внимание на новата UCI структура на конфигурацията – не става просто да се прехвърли старата. В моят случай, за да “захапе” уеб интерфейса беше достатъчно да добавя един запис от тип ‘redirect’:

config ‘redirect’ ‘dev_http’
option ‘src’ ‘wan’
option ‘proto’ ‘tcp’
option ‘dest’ ‘lan’
option ‘src_dport’ ’80’
option ‘dest_ip’ ‘192.168.1.2’
option ‘dest_port’ ’80’
option ‘src_ip’ ”

След това можеше да се редактират записите и през уеб интерфейса.

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

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

Edit: освен ако не искате да помогнете с оправянето на драйверите, не инсталирайте 2.6 kernel-а с Broadcom wireless chipset – след няколко дена работа се оказа, че не е толкова стабилен, колкото изглеждаше в началото. ;)

За да избегнете последния ефект, отворете конфигурационния файл на OpenSC:

/etc/opensc/opensc.conf

и проментере с любимия си редактор параметъра от раздел opensc-pkcs11.pkcs11 така:

num_slots = 1;

Това ограничава директориите, които се зареждат от картата до само една и на практика не включва втората проблемна такава.

Как да подкарате подписа с OpenSC под Linux четете тук.