Posts Tagged ‘работа’

2015-06-17 разни мрежови

Wednesday, June 17th, 2015

не-Курсът по системна/мрежова администрация води до доста интересни открития.

Cisco IOS 12.2(11)T9 в/у 2600 (последния IOS, който има за тоя device, който мога да събера в моя flash/памет и в който има IPv6) по някаква причина не разпознава BGP peer-ите като directly connected, ако са вързани по някой сериен link и ттрябва да му се казва ebgp-multihop (не съм тествал за другите интерфейси). Отне бая ровичкане, и доста ровене в debug-а.

По default ipip и подобните тунели под linux слагат за TTL на външния пакет TTL-а от вътрешния пакет (“ttl inherit”). Смисълът на това тотално ми се губи, понеже троши traceroute по ужасен начин. Сега разбрах защо всички примери, дето съм виждал по въпроса имат накован в config-а ttl.

И една дреболия, дето драснах днес – прост скрипт за nagios, който се връзва по SNMP до дадено устройство, и проверява дали всички портове, за които има description са UP, и дали всички останали са DOWN. Доста полезно е за следене на switch-ове и подобни, като има малко трески за дялане, но като цяло е бая удобно за по-прости setup-и (където няма нужда да се връзва конкретен порт с нещо друго).

2015-06-14 жив съм

Sunday, June 14th, 2015

Качих един progress report за ISP курса, в който вероятно съм пропуснал някакви неща, но участниците ще си кажат и ще се допълва.

Тия дни около курса се чудех с какви IPv6 адреси да го правя, и накрая се реших, навих един LIR (благодарности на Драго от delta) да ми request-нат адреси и ASN. По случая вече си имам AS200533 и 2001:67c:21bc::/48, които ще използвам и за курса, и да направя един малък тунелен брокер за IPv6 тунели за желаещи (с дублиране на тунелните, BGP и такива забавни неща), очаквайте подробности по някое време, като успея да се заема сериозно.

Иначе, жив съм – имам си кило занимания около разни проекти, openfest (очаквайте новини), ходих да консултирам студенти във ФМИ по мрежи (трагедия), изпитахме си хората за мрежова сигурност 2 (по-малка трагедия), ходих днес на театър на “Контрабасът” (беше страхотно). Определено трябва да пиша повече, почва да ми се губи какво съм вършил…

2015-05-27 upgrade до jessie на останалите ми сървъри

Wednesday, May 27th, 2015

И изглежда приключих с upgrade-ите на личните ми машини до jessie. Малко изводи/наблюдения:

– прочетете release notes, полезни са (има например как да не си инсталирате systemd);
– инсталирайте си needrestart, който при всеки нов инсталиран/upgrade-нат пакет може да провери какво трябва да се рестартира и да си каже. Това се оказа много полезно около update-ите на openssl и като цяло може само да разбира кой процес кои библиотеки ползва, доста улеснява живота;
– инсталирайте си debian-security-support, казва кога даден пакет вече не се поддържа от security екипа (има някакво количество подобни бози);
– ако имате някакви пакети, които сте компилирали сами, с debootstrap може лесно да си направите един jessie chroot и да си ги приготвите там предварително. Аз така търкалям собствен build на ircd-ratbox (който да поддържа utf8 в nick-овете и имената на каналите, заедно с още една-две добавки) и си пренесох patch-а за нула време;
– postgres се мигрира много лесно до новата версия, има три команди, описани в /usr/share/doc/postgres-нещоси;
– mysql-а па изобщо няма проблеми (ако ползвате системния, не съм гледал ситуацията с percona);
– имах огромен проблем с ejabberd, дотолкова, че накрая се ядосах, пуснах го в някакъв вид и го мигрирах до prosody. Мисля, че проблемът беше, че mnesia базата беше синхронизирана преди между две машини и понеже някои настройки не бяха махнати, разни update-и в/у схемата не са се случвали изобщо;
– погледнете после и направете apt-get autoremove, да почистите нещата, които не ви трябват, или да кажете изрично за нещо, че ви е нужно. Хубаво е да се чистят ненужните неща, да не влачите по 5 версии на разни стари библиотеки;
– Ако като мен ползвате неща, които apache сервира от /home, ще трябва да си пипнете /etc/apache2/apache2.conf, за да си позволите да се чете там (и да дадете AllowOverride, че default-а му е доста зъл). Също така са казали, че всичко,което се include-ва от sites-enabled и conf-enabled (conf.d е разкарано), трябва да завършва на .conf (което наложи малко да пригаждам конфигурацията си към него). Също така access/allow нещата са много променени и ако имате нещо по-сложно, ще трябва да се заровите в документацията;
– GRUB-а в момента по default пуска някакъв страшен видео-режим, който не запали на единия монитор в telepoint. В /etc/default/grub има GRUB_TERMINAL=console, което може да се разкоментира за целта.

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

Самият upgrade мина сравнително безболезнено, reboot-а също си мина ОК. Мисля си тия дни да обърна внимание и на koi.obshtestvo.bg, където обаче има lxc контейнери и ще трябва да се действа по-внимателно.

2015-04-24 първи upgrade на сървър до jessie

Friday, April 24th, 2015

Новия Debian stable (Jessie) се кани да излезе след ден-два, та по случая реших да upgrade-на cassie (router/сървър-a в initLab). Причина за upgrade беше и продължаващия проблем с drop-ване на определени пакети, най-вероятно от интеракция на route cache и двата отделни пътя навън.

Като цяло нещата минаха съвсем спокойно (mysql-а се upgrade-на сам, за postgres-а трябваше да се направи една кратка процедура по upgrade, пак сравнително автоматична), и за няколко неизползвани неща (като varnish) ми каза, че трябва да си пренапиша конфигурацията. Имаше обаче два мрежови проблема (за справка, описанието на мрежовия setup там):

– в последната quagga, която е в jessie, ospf6d е счупен, съответно външната IPv6 свързаност изобщо не захапа. След някакво ровене в changelog-ове намерих следното на сайта на quagga:
“[ospf6d] A large amount of changes has been merged for ospf6d. Careful evaluation prior to deployment is recommended.”
Реших да не го дебъгвам повече и минах нещата на BGP, с което така и така се чувствам по-комфортно (при v6 и quagga изборът не е много голям).

– след 3.6 са махнали routing cache, което води до любопитното поведение, че един tcp connection не може да просъществува дълго, понеже пакетите му почват да се мятат между двете връзки и доста бързо идва един reset. Оказа се, че има хубаво решение с CONNMARK, като връзката в началото се маркира откъде е излязла, след което с policy routing правила се праща през вече определения ѝ път.

Чакам да видя какво още ще се счупи (поне отварянето/отключването на вратата работят, та няма да се наложи да я режем с флекс).

2015-04-15 end-to-end криптография за домашна/фирмена употреба

Wednesday, April 15th, 2015

Питаха ме тия дни “как да си говорим без да ни подслушват”, и понеже е просто, ето какво препоръчвам аз (и съм ползвал). Това не включва operational security неща (не говорете близо до други хора, не си качвайте записите някъде, не си давайте компютъра на непознати и т.н.), а само как да си направим setup, който може да се използва правилно. Базиран е на неща, които аз съм правил, т.е. конкретните препоръки са от моята практика.

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

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

Като за начало – някакво собствено желязо, с криптиран диск, с debian stable и автоматични security update-и.
Ползвам debian, понеже си е стабилно и security update-ите работят както трябва и не чупят системата.
Криптирания диск е допълнителна мярка за сигурност. Реално на сървъра няма да пазите кой-знае каква важна информация, но си остава добра идея. Това влачи със себе си проблема, че на рестарт някой трябва да въвежда passphrase, но за това има начини да се прави по сравнително сигурен начин.
Виртуалните машини са твърде лесни за атака, че да се разчита на тях. Вариант са, защото при тоя setup данните не са чак толкова важни, но не ги препоръчвам.

Понеже всичката комуникация ще върви по TLS, е добре да си имате правилно подписан сертификат. Всички сме наясно, че сигурността на сертификатите е малко трагична, но помага понякога да се хванат разни MITM атаки. Има сравнително евтини CA-та, като скоро и ще работи това на EFF, което ще е съвсем безплатно.
Ако искате да избегнете всичките възможни атаки, може да си направите собствено CA и да го инсталирате по клиентите, но е по-сложно и доста често не се спазва както трябва и просто се казва на клиента да приема всякакви сертификати, което е лоша идея.

Следващата стъпка е XMPP (Jabber) сървър. Аз лично използвам ejabberd, понеже е сравнително прост за конфигурация, бърз и ако не трябва да дебъгвате S2S, направо идеален.
В него трябва да спрете некриптираните връзки като цяло, и да не включвате S2S (server-to-server) модула, така че да е ясно с кой говорите. Можете да си включите и конференциите, но за тях още няма end-to-end криптография.

Финално, трябват ви open-source клиенти, които да поддържат двата протокола (OTR и ZRTP). По принцип jitsi поддържа и двете и е доста добър избор (въпреки че е доста тежко и писано на java), като работи под всички desktop операционни системи и има alpha за android. За телефони (ios и android) за съобщения има chatsecure (само OTR). Също така аз самия ползвам pidgin с OTR plugin, който обаче няма ZRTP (и като цяло много кофти аудио поддръжка).
(някой може да допълни с още клиенти)

Този setup ви дава възможност да си говорите с end-to-end криптография и да сте много трудни/невъзможни за подслушване (по последните документи от NSA, OTR е нещо, за което не са намерили никакъв вариант да го счупят).

2015-04-01 presentation build system

Wednesday, April 1st, 2015

(мразя днешния ден, та да взема поне аз да свърша нещо полезно)

Тия дни около курса по мрежова сигурност си update-нах системата за build-ване на презентации и съответно съм я качил в github. Бая улеснява живота:

– Може да си добавяте картинки както си искате, системата ги resize-ва и следи коя презентация от кои зависи и я rebuild-ва;
– Както и преди, може да си пишете текста на презентацията заедно със слайдовете и се extract-ва автоматично;
– Може да си правите страници със заглавия ( ‘###’ и на следващия ред ‘#### някакво заглавие’ и ще запълни цялата страница с него);
– Вече няма нужда да пишете каквото и да е в Makefile-а, той автоматично захапва всички .pandoc файлове в текущата директория.

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

2015-03-26 drop database

Thursday, March 26th, 2015

Днес получих поредното потвърждение за любимия си израз “Системният администратор се учи на гърба на потребителите”.

Правехме някаква миграция на obshtestvo, и около нея се налагаше няколко пъти да се drop-ват и преналиват едни бази. Хванах се на няколко пъти как съм пуснал DROP DATABASE и чак след това съм погледнал къде съм го пуснал, и не го бях сбъркал нито един път.
(нещото беше малко под пара, иначе гледам да правя нещата по-бавно)

Това не-сбъркване е продукт на МНОГО омазвания преди това, изгубени данни, възстановяване от backup-и и псуване. Трябва да има такива практически, реалистични упражнения и занимания за хората, които се занимават с админстване, просто защото “добрите практики” не стигат, особено като човек бърза, а аз още твърдя, че добър админ се познава по това как се справя като го вдигнат в 4 сутринта с махмурлук…

И по темата, тия дни се каня да си обявя новия не-курс, подробности за това – скоро.

2015-02-27 Reverse engineering for beginners

Friday, February 27th, 2015

Тия дни приключих с първата редакция на Reverse Engineering for Beginngers на Денис Юричев, и снощи ми е merge-нал последния pull request.

Книгата е много добра за начинаещи не само в reverse engineering-а, но и за хора, които искат да видят как работи отдолу асемблера и какво генерират компилаторите. Пълно е с всякакви интересни факти и като цяло не е много за четене (въпреки че генерираният pdf е около 950 страници). Има вид на подходящ учебник за един нормален едносеместриален курс, та даже някой може да реши да пробва да води по него :) Книгата е под creative commons лиценз, и може да се ползва за всякакви цели.

По принцип source на книгата може да се намери в github, авторът приема смислени редакции. Аз мисля да направя втори пас за редактиране, понеже досега оправях английския да звучи като английски и да е ясен, но може да се направи доста по темата да звучи наистина добре. Ако някой може да помогне с нещо друго (LaTeX-а не е чак толкова сложен), няма лошо да праща :) В todo-то на автора има “MIPS, Objective-C, Visual Basic, anti-debugging tricks, Windows NT kernel debugger, Java, .NET, Oracle RDBMS”, а в самата книга на доста места има “TODO” (например да се опишат в appendix A разни SIMD x86 инструкции).

2015-01-06

Tuesday, January 6th, 2015

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

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

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

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

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

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

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

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

2014-12-23 гласуване по Internet

Tuesday, December 23rd, 2014

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

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

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

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

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

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

2014-12-18 Internet свързаността на initlab

Thursday, December 18th, 2014

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

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

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

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

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

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

2       od
3       tbc

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

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

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

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

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

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

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

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

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

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

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

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

OpenFest 2014 – малкият streaming setup

Monday, November 10th, 2014

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenFest 2014 – restreaming

Friday, November 7th, 2014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2014-11-05 мрежата на openfest

Wednesday, November 5th, 2014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2014-07-22 cryptobg

Tuesday, July 22nd, 2014

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

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

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

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

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

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

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

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

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

2014-06-01 Лекцията ми от Websummit 2014, “Възможности, които всички web услуги трябва да имат”

Sunday, June 1st, 2014

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

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

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

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

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

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

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

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

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

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

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

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

[slide 5 Authentication]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[slide 14 Further reading]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[slide 22 SSL/TLS Session caching]

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

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

[slide 23 Privacy]

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

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

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

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

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

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

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

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

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

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

[slide 27 blatant self-promotion]

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

[slide 28 Thumbnail combining]

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

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

[slide 29 On-the-fly zip]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2014-05-18 Stateless auth tokens (lightning talk от PlovdivConf 2014)

Sunday, May 18th, 2014

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

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

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

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

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

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

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

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

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

[slide 8 VERP ]

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

[slide 9 TCP Syncookies]

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

[slide 10 client-side session]

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

2014-05-09 pandoc

Friday, May 9th, 2014

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

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

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

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

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

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

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

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

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

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

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

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

RIPE SEE 3

Tuesday, April 15th, 2014

И мина RIPE-SEE-3.

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

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

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

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

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

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

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

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

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

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

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

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

2014-04-08 openssl vulnerability CVE-2014-0160

Tuesday, April 8th, 2014

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

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

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

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