Сигурен съм, че сте чели старата история за хакера в стола. Тъй като отново съм на тема ISO 27001:2005, нека направим едно упражнение, при което ще проследим как ще се развие събитието, ако в стола има внедрена Система за управление на информационната сигурност.

Ден 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-символен код за еднократна употреба за активиране на солницата. За черния пипер процедурата се повтаря.

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

След почти три годишно ослушване, най-после днес намерих време да скова (свестен) сайт за българския adblock списък. Като подхванах, направих и интеграция с Twitter, където commit log-овете от кодовото хранилище заминават директно.
Другото ново нещо е филтъра за Opera, който се генерира автоматично от моя списък в комбинация с актуалния на Fanboy.
В процес на разработка са и статистики за използването(10x myst!) на списъка, но за тях – по-нататък.
Приятно сърфиране!

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

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

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

Този път вероятно за пследно.

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

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

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

В последните няколко седмици с колегите сме част от един адски цикъл. Изградили сме стройна организация от двадесетина човека, с които заедно творим и редактираме общи документи. Когато в началото всеки си имаше част, по която работеше, беше лесно. Когато обаче започнахме с крос промените, включихме външни консултантски ресурси и случайни елементи, нещата приеха грозен обрат. Разхвърчаха се десетки различни версии на един документ, всичките с проследени промени, коментари, зажълтени, позеленени, почервенени и прочие нишани по текстовете и диаграмите. Отделно, координаторите работиха в SubVersion, като към тях пристигаха документи, редактирани в поне шест различни версии на MSWord и три на OpenOffice. Диаграмите, рисувани на салфетки по кръчмите на ръка бяха бонус. Опита да вкараме на въоръжение онлайн система за колаборативно редактиране се оказа неуспешен, защото все още възможностите им са твърде далече от тези на десктоп офис пакетите.

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

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

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

Остава сега да видим доколко 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) фирми, подаващи в момента месечните си ДДС декларации с електронен подпис през Интернет, се подредят на опашка. Не искам да съм наблизо. И това е само за една от услугите.

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

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

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

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

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

Edit: проблемът е решен отдавна и няма нужда да използвате моите пакети.

След обновяването на системата ми до една от 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/

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

По старата схема “обущарят ходи бос” в къщи изтерзаният ми Linksys WRT54g v2.2 безжичен рутер беше останал да търкаля development snapshot на OpenWRT “Kamikaze” и такъв на X-Wrt. Преди няколоко месеца направих вял опит за ъпгрейд към последния release candidate, но мотиките, които настъпих тогава ме върнаха към изпитаното “работи ли, не барай!”.

В края на краищата, днес ми писна да ми насича видеото по 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 – след няколко дена работа се оказа, че не е толкова стабилен, колкото изглеждаше в началото. ;)

Понеже много народ се изреди да пита, ще опиша тук workaround за един досаден проблем при използването на електронен подпис върху смарткарта с ОС  Siemens CardOS V4.3B и OpenSC. Става въпрос за постоянното питане за Secondary PIN, който обикновено не е известен. Това като резултат се отразява, че при използването на сертификата в Firefox/Thunderbird/OpenOffice излиза диалога за PIN, след което излиза втори, на който трябва да се набие Esc. И това на всеки renegotiation – скръб.

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

/etc/opensc/opensc.conf

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

num_slots = 1;

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

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

Edit: Blueman версия > 1.0 не изглежда по този начин и долното описание не е актуално.

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

Скромното ми мнение е, че в Linux света нещата трябва да стават все по-лесно. По темата, за която пиша мрежата е пълна с HOWTOs и step-by-screen обяснения, които обаче можа да объркат начинаещите. Затова направо към проблема:

Стъпка 0: С какво разполагаме
Dell XPS 1330
Nokia E65
Ubuntu Intrepid Ibex 8.10, 64bit edition
Връзката между компютъра и телефона ще става по Bluetooth.
Нещата ще работят по подобен начин и с друг хардуер/ОС, просто инсталирайте пакетите и ги конфигурирайте по същата схема.

Стъпка 1: Инсталиране на допълнителни пакети и хранилища
Приемаме, че използвате Gnome среда. NetworkManager е аплет, чрез който управлявате мрежовите връзки. Версията му трябва да е поне 0.7 и ако използвате прясно Ubuntu или Fedora вече я имате. NetworkManager от тази си версия поддържа Mobile broadband, но за да се активира първо трябва да се конфигурира връзката между телефона и компютъра и то по такъв начин, че NM да я разпознава и използва.
За тази цел ще се наложи да инсталираме допълнително приложение, а именно BlueMan [http://blueman-project.org/] С негова помощ могат да се правят и други полезни неща, но нека се фокусираме над главното.
За Ubuntu можете да го инсталирате от PPA страницата на проекта:
https://edge.launchpad.net/~blueman/+archive/ppa
За Intrepid това става като изберете:
System -> Administration->Software sources-> таб Third-Party software -> Add…
И там добавите реда:
deb http://ppa.launchpad.net/blueman/ppa/ubuntu intrepid main
Добре е да добавите и публичния ключ на хранилището, за да може да се проверяват цифровите подписи на пакетите. Как става това вижте на PPA страницата.
Когато го добавите, презаредете хранилищата и използвайте любимия си пакетен инсталатор, за да инсталирате blueman. Към него ще ви предложи да се обновят няколко системни библиотеки, свързани с Bluetooth поддръжката – потвърдете ги.
На терминала това става така:
sudo apt-get update; sudo apt-get install blueman;

Стъпка 2: Конфигуриране
Ако всичко е минало успешно в Applications->Accessories трябва да се е появил Blueman Bluetooth Manager. Когато го стартирате ще видите Bluetooth устройствата, които сте свързвали към компютъра си. Ако все още не сте го направили с телефона си, включете Bluetooth услугата му, погледнете дали е visible, за да може да бъде открит и цъкнете на Inquiry. Следвайте въпросите и свържете двете устройства.
Когато приключите, изберете Edit -> Services. Тук ще видите активните и неактивните услуги, които ще използвате с през Bluetooth връзката ви. В колонката статус цъкнете срещу Serial, а ако искате да не се връщате постоянно на тази стъпка отбележете и Autostart. Продължете като цъкнете бутона Configure (най-в дясно). Тук разширете Add new serial port, в Host изберете вашия телефон, в Service – Dial-Up Networking. Цъкнете на Add Port и отбележете чекбокса „This is a GSM/GPRS/EDGE/3G dialup connection”. Потвърдете всичко.
Последно остана да конфигурирате и NetworkManager. Цъкнете върху него с десен бутон и изберете „Edit Connections…”, след това „Mobile Broadband” и „Add..”. Там изберете вашия мобилен доставчик и настройките за него автоматично ще се заредят.

Стъпка 3: Свързване
Връзката от тук нататък става като цъкнете на NetworkManager. В списъка трябва да се е появил нов раздел – Mobile broadband. Там трябва да е и новосъздадената ви връзка. Избирате я след няколко секунди сте в Интернет през мобилният си телефон.

Сутринта попаднах на Вени Марковски по “БиТиВи-ту нъ културътъ”. За друга тема беше отишъл, но не пропусна да спомене за публикуването сайтовете на Президента и прокуратурата под Creative Commons. Това събитие, разбира се, беше подобаващо отразено в блог пространството.

Случайно бях на компютъра и реших да разгледам. Направи ми впечатление, че избраните варианти (уклони?) на двете страници е различен: за президента е “Признание-Без производни произведения 2.5 България“, а прокуратурата “Признание 2.5 България“. Доколкото последния е по-малко рестриктивен, без да съм специалист по темата, считам, че е некоректен, тъй като дава възможност за разпрстранение на модифицирано съдържание от страницата с цитиране на источника.

Дори и нещата да не са така, отново прозира познатата схема в България: някой предлага нещо, евентуално след години някой се сеща за предложението и го прави формално, без да се задълбочава в значението на действието, с тайната надежда да спечели евтин PR. За реализацията на подобна идея трябва да има насочено разбиране към проблема и съответните формални санкции – ПМС-та, заповеди и т.н. Докато този тип неща се решават, като на маса се разберат едни хора и после единия издудне на системния администратор по телефона “…абе Пенчо, вземи тури едно [...] отдолу на сайта…”, няма да видим светлинка в тунела :(

Edit: регресията е отстранена в актуалните весии на wine

От време на време пускам някоя стара игра за разтоварване. Почти винаги на лаптопа ми има Heroes of Might and Magic IV. На български. Противно на разбиранията на старите геймъри и здравата логика :)

Та ситуацията е следната: dual boot visa 64 + ubuntu; под vista играта гърми със син екран (хех, следващото нещо, което ще trace-на ще е това, хубав DoS, не иска административни права. С потенциал за code execution ;).

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

След ослушване и следвайки правилото “The fastest way to close your bug is to submit a patch” се порових из кода на wine. Порових с Пламен и стрелях в тъмното. Резултата може да се прочете в бъг тракера на wine, а компилиран за Ubuntu пакет може(х)те да дръпнете тук.

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

Тече кампания… тежка и с неясен край…

Моята гледна точка към ситуацията е проста – *всички* слушат. Това не е параноя, а реална ситуация.

За “ИТ” хората това са дадености – некриптирана парола не пращаш; към сайт, за който не знаеш как пази информацията за теб (демек, не е под твой контрол;) не пишеш истински данни и т.н. Дали те снифи (разбирай, подслушва) ДАНС, системния администратор, ъплинк доставчика, съседа (кракнал безжичната ти мрежа в къщи и ARP отровил XP-то ти) или просто някой те е гледал в ръцете и след това ти чете пощата – това е без значение.

Твоите съкровени тайни са вече извън твоя контрол.

Когато си в началото на жизнения път, нямаш толкова много тайни. Дори, повечето ти деяния могат да минат за “здрави/жестоки/изродски/яки (или както сега там_му_се_казва)”. Тогава желанието просто да се чуе за теб надделява.

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

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

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

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

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

Някои хора питат: какви са тези радетели за отворено общество, които искат да се затворят и да пазят тайни?

Накрая, това е бъдещето на всяка тайна – да излезе на яве. А тогава?

select to_date(’01.01.2008′, ‘DD.MM.YYYY’) + to_number(‘FF’, ‘XX’)
from dual
===
trunc(sysdate)

===

Another beer, please!

Днес намерих малко свободно време и реализирах идеята на Явор – добавих възможност за изпращане на ваши адреси за българския лист [http://stanev.org/abp/] на AdblockPlus. За да прескоча СПАМ-а съм използвал чудесната reCaptcha, а има и елементарни проверки за повторение. Добавянето няма да става автоматично, а след преглед от моя страна.

Сигурно вече ви е направил впечатление аскетичния дизайн на страничката – ако някой иска да я направи по приятна за окото – да заповяда :)

Ето ви една добра новина: вече можете да свалите MS Office съвсем безплатно от държавен сървър. Чудото се случва на страничката на Фонд “Условия на труд” към Министерството на труда и социалната политика. Попадайки там, първото, което трябва да направите е да се отърсите от натрапчивото чувство, че дизайнера е хрупал халюциногенки, които от своя страна са извратили представата му за цветове/разположение/използваемост и т.н. черни магии.

Ако вече не сте се отказали, продължете смело напред – погледнете сивата лента под картинката, разполагаща България на явно заслуженото място на дъното на Атлантика. Това всъщност е меню и трябва с мишката да посочите “Проекти и програми”. Тогава друго меню ще се свлече и от там избирате “Готови продукти”. Това, което търсите е третата връзка, Risk.rar (145MB). Това творение на програмисткият гений е Access приложение и за по-лесно в инсталационния пакет са добавили и MSOffice 97 Professional.

И така, граби народе! Докато има! Безнаказано! Дори и Linux потребителите (да ви е честит и новия 2.6.26 kernel) могат да се впуснат в приключението, с чаша вино в ръка ;)

Благодаря на Voland, който ми обърна внимание към далаверата.

Edit: е, то се е видяло: иранците ще ни оправят.

The Onion Router (TOR) е свободна имплементация на технология, целяща да създаде инфраструктура за гарантиране на (псевдо)анонимност в мрежата. Това става като всеки участник в TOR става отделно звено, а връзката се насочва през произволни участници в мрежата. Комуникацията между TOR звената е криптирана, но при последното звено, така наречения exit node, се налага да се използва първоначалния протокол, за да се изгради връзката с търсения сървър. Ако не използвате криптиране от край-до-край, като примерно качите връзката на SSL обслужващия ви exit node може да прихване и подслуша комуникацията.
Всъщност, горното е отдавна известно и е подчертано още на първата страница на проекта. Комбиниране с възможността да се инжектира съдържание в обратния отговор (примерно web bug, който да ни се „обади”, когато пристигне при оригиналния клиент), нещата вече губят всякаква възможност за гарантиране на анонимност. Въпреки това, много хора не го разбират или просто не им пука толкова.
В средата на миналата година, шведски консултант по ИТ сигурност направи точно горното – инсталира на няколко машини TOR сървъри, пусна sniffer и зачака. След като само за няколко седмици успя да „налови” паролите за пощите на маса посолства, вдигна тежка олелия и го обявиха за хакер номер едно. После и го арестуваха.
За мен горния случай единствено показва колко малко се разбират проблемите на ИТ сигурността в горните организации. Ако правилно си спомням, много малко държави въобще използваха Интернет за преносен канал с мисиите зад граница (хм, няма да конкретизирам…). Та дори и нашата малка България се впусна в изграждането на сателитни мрежи – помните скандала със Соломон Паси преди време…
Както и да е. Преди 2-3 години аз също в името на опита и любопитството проверих какво се пренася. Тогава не излезе нищо неочаквано – пощи, порно страници, форуми.
Реших сега да опитам отново – наистина ли трафика е станал толкова „сериозен”? Инсталацията на опитната установката отне около 10 минути, след което отидох, разбира се, на бира.
Когато се завърнах, прегледах логовете. Само един бърз поглед показа, че играта с времето само е загрубяла – беше пълно с адреси към гнусна детска порнография.
Тук идват и резонните въпроси:
• Какво ще кажат нашите приятели от ГДБОП, ако от ISP-то ми слушат трафика? Тук историята се доближава до тази с торентите – както там не си изясниха технологията, така и тук вероятно ще имат заблуждения.
• Всъщност, прави ли ме инсталирането и конфигурирането на TOR сървър „Доставчик на далекосъобщителна услуга”? Не мисля, че закона може да се прочете така, но на практика аз в случая имам клиенти, за които си нямам и понятие кои са, но които обслужвам. Да не говорим, че и логовете, които евентуално ще пазя са абсолютно безсмислени.
• Защо, след като в ситуацията в момента е такава, МВР не пусне няколко TOR сървъра и не спре *източниците* на незаконното съдържание? Без значение дали са на територията на България или навън, варианти има. Не мисля, че кампании от типа „Натопи другарчето, ако го усетиш да прави нещо нередно” ще помогнат повече.
Проблемът такъв, какъвто генерализирано го виждам е, че за кой ли път законите (и то не само в България) изостават твърде много от процесите в истинския свят.
TOR и подобните системи не са заплаха. Има десетки и много по-големи бот-мрежи, създадени, за да обслужват единствено и само престъпни цели, от компютрите на нищо неподозиращи Windows потребители. От там се сипе SPAM, инициират се DDoS атаки, bruteforce-ват се услуги и какво ли още не.
Все си мисля, че трябва да направим нещо по въпроса. А вие?

Моят приятел и колега Косьо, заедно с още трима капитани-разбойници поеха едно скромно начинание, за което искам да пиша накратко тук.
Първо се метнаха на самолет до Чикаго. Там са си харесали една спортна яхта, която към момента е изтеглена на сух док. На място ще натоварят лодката на камион и ще я откарат до океана – на има-няма 800 км. Там се пуска на вода и на платна, ще се приберат в България.
Интересното тук е, че това ще е най-младият екипаж, прекосил Атлантика с яхта. Отделно, Косьо пък ще е най-младия българин, свършил тази работа :)
През цялото време екипажът ще разполага със сателитен телефон, през който ще блогват какво им се случва по пътя и ще изпращат снимки. Очаква се и първото (доколкото ми е известно) използване на услуга от така нареченото електронно правителство от насред океана, но за това когато му дойде времето ;)
Ако ти е интересно, можеш да следиш събитията на живо на блога на проекта http://chicagoandback.org

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

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

След известно разглеждане се спрях на SSHFS – отдалечена файлова система, използваща SCP за преносен протокол. Sshd имам на всяка машина, а се оказа, че и под Windows има shell extension-и, които директно mount-ват отдалечения ресурс.

Който е прехвърлял големи обеми данни със SCP е забелязал силното намаляване на производителността спрямо ширината на канала, както и лекото „насичане“ в комуникацията.

Мислейки си за 300-те GB компресиран бекъп на една от базите, която е с навика да расте с по 10 GB на ден, се зарових в търсене на проблема.

Такъв недостатък не би останал незабелязан и съответно вече имаше решение – High Performance Networking patch за OpenSSH.

Причините за деградиралата производителност са следните:

• Статичен размер на I/O буфера в имплементацията на протокола.
  До версия 4.6p1 въпросният буфер е бил едва 64 KB, което е крайно недостатъчно и предизвиква ненужно фрагментиране на данните.. Всеки фрагмент от своя страна се криптира отделно и води до допълнителен overhead.
  В последната версия на OpenSSH 4.7p1 буфера е увеличен на 2 MB. Това дава добро увеличение на производителността, но все още има какво да се желае.
• Имплементациите на използваните алгоритми за криптиране не са multithread.
  Това директно оказва влияние върху оптималното използване на процесорите. В днешно време сървърите разполагат с повече от един процесор, да не говорим за дву- и четири ядрените хардуерни решения.
• Когато използваме собствени (или dedicated) канали, които може би имат и криптиране на по-долен слой или пък не пренасяме чувствителни данни, можем да използваме eNULL алгоритъм за криптиране, или иначе казано – без такова.

По решението на горните проблеми работи екип на Pittsburgh Supercomputing Center, който е реализирал patch за OpenSSH. По редица причини този patch все още не е станал част от официалната дистрибуция и се налага прилагането му на ръка.

Работейки с Ubuntu, реших първо да намеря прекомпилирани deb пакети, с които да експериментирам. За продукционна машина това не е добра идея, тъй като заедно с HPN patch-а може да ви нахулят и хубав излъскан троянски кон – но вие това си го знаете :)

След като не открих прекомпилиран пакет се заех да свърша работата сам. Както се досещате, гредата дойде от там, че както всяка уважаваща себе си дистрибуция, разработчиците на Debian/Ubuntu имаха свои собствени patch-ове, които решават един или друг проблем за интегрирането на OpenSSH. Прилагането на patch-a гръмна на 6 места, като две от тях бяха вече наложени от допълнителните patch-ове, а за останалите трябваше лека намеса на ръка. Няма да се впускам в подробности, защото те са конкретни за текущото състояние на двете кодови дървета и са тривиални за решение.

Ето накратко стъпките:

1. Ако не сме прекомпилирали пакети до момента е добре да си дръпнем необходимите ни tool-ове:
   alex@dawn:~/openssh$ sudo apt-get install build-essential devscripts fakeroot
2. Изтегляме необходимите ни dev пакети спрямо информацията за връзките в openssh:
   alex@dawn:~/openssh$ sudo apt-get build-dep openssh
3. Изтегляме source пакета на openssh (в случая е openssh_4.7p1-5ubuntu1):
   alex@dawn:~/openssh$ apt-get source openssh
4. Изтегляме двата HPN patch-а (в случая версия 13v1), включващи динамичното оразмеряване на I/O буфера, eNONE алгоритъма и multithreading имплементацията за брокера за криптиране:
   alex@dawn:~/openssh$ wget http://www.psc.edu/networking/projects/hpn-ssh/openssh4.7-dynwindow_noneswitch.diff.gz
   alex@dawn:~/openssh$ wget http://www.psc.edu/networking/projects/hpn-ssh/openssh4.7-CTR-threading.diff
5. Влизаме в директорията със source кода и прилагаме двата patch-а:
   alex@dawn:~/openssh$ cd openssh-4.7p1
   alex@dawn:~/openssh$ zcat ../openssh4.7-dynwindow_noneswitch.diff.gz | patch
   alex@dawn:~/openssh$ cat ../openssh4.7-CTR-threading.diff | patch
   Първия би трябвало да изгърми тук-таме, втория трябва да се приложи безпроблемно. Тук трябва да се разходим из кода, като в генерираните .rej файлове има информация за това какво не е успяло да се приложи. Редактираме .h и .c файловете на ръка.
6. Обновяваме changelog-а, където е важно да инкрементираме версията на пакета, за да не го намажем при по-късен upgrade:
   alex@dawn:~/openssh$ dch -i
7. Компилираме source-а и изготвяме пакетите:
   alex@dawn:~/openssh$ dpkg-buildpackage -rfakeroot
   Ако всичко е минало добре, би трябвало да имате няколко .deb и .udeb пакета, тъй като в Debian OpenSSH е разделен на модули. Инсталирате първо клиента, след това сървъра така:
   alex@dawn:~/openssh$ sudo dpkg -i openssh-client_4.7p1-5ubuntu1alex-hpn13v1_i386.deb
   alex@dawn:~/openssh$ sudo dpkg -i openssh-server_4.7p1-5ubuntu1alex-hpn13v1_i386.deb
   Разбира се, имената на пакетите могат да варират според това какво сте написали на стъпка 6.

След рестартиране на sshd можете да направите малко експерименти. За да използвате patch-а не е необходимо и клиента на отсрещната машина да е да patch-нат – достатъчно е само сървъра да е подобрен.

При моите експерименти в 100 MBit локална мрежа установих два пъти повишаване на производителността. През Интернет(колкото и относително да е това, bgpeering) около 20%.

На финала, ако горните стъпки са ти се сторили сложни и времеемки, можете да използвате моите пакети:

openssh-server_47p1-5ubuntu1alex-hpn13v1_i386.deb (md5:774856d4167be8770203f7c1c8e9af80)

openssh-client_47p1-5ubuntu1alex-hpn13v1_i386.deb (md5:0e5499487010c1e18ca7832318aa87a1)

Отново не препоръчвам инсталирането им в продукционна среда – ако го направите сигурно много ми вярвате :)

Ще се радвам да споделите вашите наблюдения върху производителността с HPN-SSH patch-а.

Bonus info:

Прегледах и двете платени Windows имплементации за mount на sshfs като локално устройство:

• SftpDrive – просто приложение, което прави точно това, което очакваме. Няма настройки за SSH протокола (алгоритми за криптиране, SCP и т.н.)
• WebDrive – може да mount-ва Amazon S3, WebDav по SSL, SFTP/SCP, като поддържа подробната настройка на комуникационните параметри. За съжаление поне последната версия, която тествах бе доста бъглива. Има и допълнителен cache, който когато е включен се грижи за background трансфер на данните. Малко по-скъп е от горното приложение.
• Мернах и решение с отворен код на SourceForge, което обаче беше докарано до под кривата круша и е дефакто неизползваемо.

Накратко, ако ви трябва прозрачна интеграция на sshfs под Windows, препоръчвам SftpDrive (да си помислят за комисионна в моя полза;)

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

Всъщност това, което исках е добро филтриране на така досадните реклами. След кратко оглеждане се спрях на най-използваното разширение за това – AdBlock Plus.

Както се оказа, никой не си е поиграл за да състави общ списък за българските сайтове. В резултат, тук-там правилата от общия списък (EasyList) пропускат банери и шаренията успява да пробие.

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

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

Да пусна и моите 2 ст. по темата.

Преди ~5 години (началото на 2003 г.) бях делегат на годишната конференция на EEMA. Като сериозна и независима организация (основана през 1987), те създават работни групи по различни наболели проблеми. Тогава течеше усилен дебат по въпроса на отворения код и неговото използване в публичния сектор. Аз участвах в групата за eGovernment, където трябваше да изготвим позицията на организацията по темата.

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

Някои бележки относно приложението на отворения код в публичния сектор

Въвличането на все повече хора в разработката на софтуер с отворен код води до появата на много нови мнения за това как даден продукт трябва да се развива, какви да са неговите възможности и пр. Особено важно е да се синтезира най-доброто, за да се постигне успех. За външния наблюдател тези процеси изглеждат анархистични и разнопосочни, което е определено странно и едновременно стряскащо за служителя от държавния сектор, търсещ оптималното решение. Всъщност, протичащите процеси са просто още един изглед на Демокрацията и това, което се случва е съвсем нормално за обществото, в което живеем. Такава среда е особено продуктивна и дружелюбна към всички нови технологии и налагащи се стандарти, като помага за тяхната интеграция и развитие по един изчистен и свободен начин – така, както обществото се отнася към въпроса за прозрачност и адекватност на държавните решения.

Една от основните задачи на Електронното правителство е да интегрира съществуващите системи в една обща информационна инфраструктура, използвайки технологи като Web Services, PKI и т.н. Една такава отворена инфраструктура ще помогне на малките играчи на софтуерния пазар да се включат в изграждането на нови и нови услуги по най-добрия начин и в мащаби, които могат да управляват. В същото време, в момента някои от най-големите компании се опитват да наложат затворени решения, само защото това е единствения начин да запазят пазарните си ниши и дивиденти.

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

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

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

The end.

Може би не е необходимо да пояснявам, че в тази леко закостеняла организация, доминирана и управлявана от големите корпорации, моите романтични брътвежи не намериха място в крайния доклад. Впоследствие, въпросния документ, изпратен надлежно в централата на ЕС в Брюксел, послужи за основа на стратегията за развитие на IT в Съюза.

Измина повече от месец от местните избори. Въпреки това, все още в над 200 места продължават препирните кой, как и защо е станал общински съветник/кмет. Резонно е да се хвърлят и обвинения в най-странни и невинни посоки – просто за замътване на обстановката, защото, както знаем – в мътни води не знаеш какво ще хванеш.

В следващите редове ще се опитам да “отворя” процесите по обработката на изборните резултати. Не, че са някаква тайна, но са описани в различни документи, респектиращи с обема и скучният си език.

Всичко започва сутринта в изборния ден. Събират се секционните избирателни комисии (СИК), разполагат бюлетините, отварят изборните секции и започват да чакат. Хората идват, гласуват и пускат пликовете с маркираните бюлетини.

Когато приключи гласуването, членовете на СИК се затварят, измъкват бюлетините от пликовете и ги разделят на купчинки по партии/кандидати. След това броят. Бройката на СИК членовете варира, обикновено от 9 до 13, винаги нечетна. Те се предлагат от различни политически партии, за да няма договаряне. Когато се скарат за бройките, сдобрят се, пак се скарат и накрая здравият разум победи (разберат/наговорят се), изготвят СИК протокола.

СИК протокола има две части – основна и разпределение. В основната се записват числа от типа – колко бюлетини получихме, колко хора дописахме в списъка, колко празни пликове намерихме и т.н. Разпределението се състои от бройката на гласовете по партии/кандидати. Когато го попълнят се подписват и го мъкнат в Общинската избирателна комисия (ОИК).

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

Подписаната разписка се носи на специално нарочен отговорник, който проверява налични ли са всички подписи и я потвърждава.

По време на въвеждането в ОИК, на регулярни интервали се изпращат потвърдените до момента СИК протоколи в Централната избирателна комисия (ЦИК). Това се прави за публикуване на данните в Интернет, както и за нуждите на оперативните справки. Всички данни се изпращат подписани с цифров сертификат за електронен подпис, без да се криптират. Това гарантира невъзможността за промяна/подмяна, както и прозрачността – който иска – да sniff-и.

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

След приключването на въвеждането, трима от членовете на ОИК се вдигат и мъкнат в ЦИК в София СИК протоколите, копие на локалната база данни (подписана с електронен подпис) и още някои допълнителни решения, записки и т.н.

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

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

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

Когато превъвеждането приключи, всички справки за несъответствия се предават на ЦИК за вземането на решение. Обикновено, това са написани с левия крак протоколи или операторски фантазии. Последното почти не се среща, защото всичко се регистрира и последствията са мълниеносни – от отрязване на парите по договора, до предаване на съответните органи. Добрата новина е, че хората вече се научиха и глупости не правят – главицата на всяко пиленце си му е мила :)

ЦИК се произнася и оповестява публично решение за грешките. Решението се въвежда в системата и се проверява дали води до промени в изборния резултат. Ако това се случи се сезира Върховният административен съд (ВАС) за касиране на изборите в съответното място.

Когато всичко приключи, се генерира и отпечатва изборният Бюлетин – на хартия и в електронен вид. Според вида избори, Бюлетина е от 300-400 страници до над 3500 (за сравнение, “Война и мир” е около 1300) за Местните избори.

За един малък домашен проект ми се наложи да измисля бекъп решение за кодовото хранилище и базата данни. Хрумнаха ми два бързи варианта:

• Закачам USB памет на щайгата и копирам там всекидневно експорти;
• Регистрирам в Google потребител за електронната им поща и пускам там бекъп-а по gmailfs.

Разбира се, като всеки уважаващ себе си програмист, нямам резервни USB стърчишки, особено ако трябва да ги завирам в архаична щайга (Celeron 433 MHz / HDD 20GB / RAM 512 MB) за постоянно. Трябва да поясня, че в Wikipedia не препоръчват gmail да се използва за бекъп – имат навика да трият акаунта при прекомерно използване, а и не се знае кога ще сменят API-то и ще угаснат файловете там.

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

• Бекъп пространство – поща в gmail, към момента дават 2-3 GB, напълно достатъчно за случая;
• Скрипт за експорт на кодовите хранилища, по възможност да проверява дали има нови версии и ако няма да прескача стъпката с бекъпа;
• Скрипт за пълен експорт на PostgreSQL-а;
• Възможност за добро компресиране и силно криптиране на файловете – използвах 7z, видя ми се подходящ за случая;
• Пилешки познания по bash scripting (е нека и гурутата да се посмеят сега), обилно гарнирани с крушова водка. Последното е необходимо на автора за да си припомни bash-а, че рядко му се налага да злоупотребява с него…

След известно ръчкане настъпих и първите мотики:

• Използвам Ubuntu Gutsy Gibbon, към момента е dev версия. gmailfs-а при опит да се mount-не ме наплюва с 400: Bad Request. Това очевидно идва от гугълските сървъри, където някой нещо реже с флекс. По най-грубия възможен начин решавам проблема така: след известно взиране в python кода откривам, че грешката е в libgmail. Отивам на страницата на библиотеката, завирам се в cvs-а, от където измъквам топла-топла последната версия, само на два дена, милата. Грозно намазвам старата библиотека, намираща се в /usr/share/pycentral/python-libgmail/site-packages с тайната надежда, че когато поддържащия ubuntu-джия, обнови пакета, ще имам по-нова версия, ако ли не поне същата.
  Разбира се, номера минава и вече имам достъп до gmail пощата.
• gmailfs не се mount-на човешки (поне при мен), в резултат на което на нея не можах да използвам примерно mv

След още малко човъркане и двойно повече взиране в man страниците, изковах следните скриптчета:

svn_backup

#!/bin/bash
#Backup svn repos, alex [at] stanev.org
svnbase='/var/svn'
backup_target='/mnt/gmail'
svndump='/tmp/backup'
pass='archive_password'
wd=$PWD
cd $svnbase
for repo in $(ls -d */); do
repo=${repo%/}
svn info file://$svnbase/$repo > $svndump/$repo.curr
touch $svndump/$repo.last
if ! cmp -s $svndump/$repo.curr $svndump/$repo.last ; then
svnadmin dump -q $svnbase/$repo | 7z a -mx=9 -p$pass -si$repo $svndump/$repo.7z
if ! [[ -f $backup_target/$repo.7z ]] ; then
ext='.7z'
elif ! [[ -f $backup_target/$repo.1.7z ]] ; then
ext='.1.7z'
elif [[ $backup_target/$repo.7z -nt $backup_target/$repo.1.7z ]] ; then
ext='.1.7z'
rm $backup_target/$repo$ext
else
ext='.7z'
rm $backup_target/$repo$ext
fi
cp $svndump/$repo.7z $backup_target/$repo$ext
mv -f $svndump/$repo.curr $svndump/$repo.last
rm $svndump/$repo.7z
fi
done
cd $wd

pg_backup

#!/bin/bash
#Backup postgre db, alex [at] stanev.org
backup_target='/mnt/gmail'
pgdump='/tmp/backup'
pass='archive_password'
sudo -u postgres pg_dumpall | 7z a -mx=9 -p$pass -sipostgres $pgdump/postgres.7z
if ! [[ -f $backup_target/postgres.7z ]] ; then
ext='.7z'
elif ! [[ -f $backup_target/postgres.1.7z ]] ; then
ext='.1.7z'
elif [[ $backup_target/postgres.7z -nt $backup_target/postgres.1.7z ]] ; then
ext='.1.7z'
rm $backup_target/postgres$ext
else
ext='.7z'
rm $backup_target/postgres$ext
fi
cp $pgdump/postgres.7z $backup_target/postgres$ext
rm $pgdump/postgres.7z

Накратко, горните упражнения правят следното:

svn_backup обикаля всички хранилища и изтегля информация за HEAD revision. Ако има промени се прави копие към директорията за бекъп. Тъй като в случая с gmailfs използваме отдалечена файлова система, отсреща се пазят по две копия на един и същи файл. При качване на следващия винаги се изтрива по-стария. Това повишава мижавата вероятност са имаме поне един цял файл, ако връзката се разпадне в момента на предаване.

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

Настройте вашите пътища, сменете паролата и сте почти готови!

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

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

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

Намерих малко време и направих един бърз експеримент със CCID четец и SetCOS смарткарти, които под windows вървят със SetWEB-а. Резултата е успешен.
Ето какво направих:

0) Хардуер
alex@si:~$ pcsc_scan
PC/SC device scanner
V 1.4.9 (c) 2001-2006, Ludovic Rousseau <ludovic.rousseau@free.fr>
Compiled with PC/SC lite version: 1.4.2
Scanning present readers
0: ACS ACR 38U-CCID 00 00

[snip]

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 9F 94 80 1F C3 00 68 11 44 05 01 46 49 53 45 31 C8 07 90 00 19
3B 9F .. 80 1F C3 00 68 1. 44 05 01 46 49 53 45 31 C8 .. 90 00 ..
Setec SetCOS 4.4.1

1) ОС
alex@si:~$ uname -a
Linux si 2.6.22-10-generic #1 SMP Wed Aug 22 07:42:05 GMT 2007 x86_64 GNU/Linux
alex@si:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION=”Ubuntu gutsy (development branch)”

2) Пакети
alex@si:~$ sudo aptitude install opensc libccid mozilla-opensc

Към тези пакети най-вероятно ще се задействат dependecies, необходимо е да се потвърдят.

3) Тест
Провери дали работи pcscd и пусни pcsc_scan
Трябва да се върне информация за четеца и картата, както и при вадене/пъхане да се прочита информация за текущата смарткарта.

4) Потребителски софтуер
Ако горните стъпки са ОК, вече разполагаш с работещ подпис под linux. Последно остава да се конфигурира потребителския софтуер. Той трябва да поддържа работа през PKCS#11 интерфейс, което си е стандартно отвсякъде.
Пример за Firefox/Thunderbird:
цъка се на Edit->Preferences->Advanced->Encryption->Security Devices
после Load и се оказва пътя към PKCS#11 библиотеката на openSC:
/usr/lib/opensc/opensc-pkcs11.so

Потвърждава се, инсталират се базовите сертификати на StampIt (незадължително) и това е – вече трябва да можеш да използваш смарткартата за клиентска оторизация.

Уговорки:
горното би трябвало да работи без промяна и на Debian. Въпреки, че съм използвал development версия на Ubuntu (утре излиза Tribe6, ще се пие бира!) +, че е 64 битова системата, вярвам, че ще работи и под други дистрибуции аналогично.

Изобщо, като цяло инсталацията си е stright forward процес, без допълнителни “врътки”.

Edit: пътят към opensc pkcs#11 библиотеката може да е различен във вапата дистрибуция. Например, под Ubuntu 8.10 e /usr/lib/opensc/opensc-pkcs11.so

Петъка ми възложиха една рутинна, но необичайна за компанията ми задача – да инсталирам вътрешен форум. “Но от тези, с тредовете. Знаеш ли какво е ‘thread’?”

Хм, при нас е весело, както се пееше в един популярен шлагер.

От доста време се боря за такава комуникация – все пак имаме 3 сгради в София и още 27 клона из България. Друг е въпроса, че исках висшето ръководство да  узрее за една такава стъпка – нека първо решат какво искат да споделят, а тогава да им връчим мегафона.

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

Въпроса е по-скоро идеологически и философски. От една страна CMS ще свърши работа, ако си имаме едно проактивно ръководство, което в целта си да натрупа повече средства за акционерите (това е правилната посока) тупа по рамото тружениците и ги напъстства в живота (one of us технология). Апропо, имаме си и “Фирмени комуникации”, та те може да родят нещо интересно. Дано не е след 9 месеца, че при стъпкване на главата може и да пометнат.

Другия вариант е да връчим силата на хората. Web 2.0 и подобни – уики + форум + фото галерия (да, ходим на паметни team buildings) и като за организация като нашата – анонимен достъп за редактиране.  Това ще работи, когато няма да има кой да се занимава с хората и те ще се самозадоволяват. Може би грубо, но поне няма да е публично, от това най-боли, чувал съм.

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

Ако все пак си напреднал, чети надолу.

Хм, упорито си ти…

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

Опитай пак!