Archive for February, 2014

2014-02-27 DKIM

Thursday, February 27th, 2014

Това чак не е интересно.

Ровейки един spam, който един приятел е получил, се загледах в DKIM подписите. Оказва се, че DKIM-а се лови от тривиално replay-ване, т.е.:

Правите си account на някое уважавано място (например gmail, в конкретния случай обаче е abv.bg). Пращате си mail до себе си, който ви генерира едни валидни подписи. Взимате цялото съобщение като source, един ваш smtp сървър, и го пращате на който си искате. От гледна точка на хората, уважавания доставчик е минал през вашия сървър и е пратил съвсем валидно писмо…

DKIM-а не знам кой го е мислил, но ето header-ите му:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out;
	t=1393422571; bh=4dLtPPWnymIO/8L0CLbvGZYxlQ5bZYMBimz0R/Li/JY=;
	h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:DKIM;
	b=RQhl7IakYWwDQb70tpH3nG6V7CFcisAs/AyIO9/g0OpaIFD0jJpm8KbGOZ+UvVpK5
	oeSzu2HLUUFOd6/o+8NHJWHTEwPKf80RZXtnkN4Jp2S/OKKBC5TImFupHy+s1uUgjhD
	9yDf3LZES95JquPBNdYbotBZhc6wd9x1dNTJKCM=

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

Това е толкова тривиално, че чак българските spamer-и го ползват. Чак се чудя дали това с валидния DKIM подпис е нарочно или просто така е станало…

Интересна работа. Имаме SPF (описване на валидни източници) и DKIM (подписване на header-и от валидните източници), и нямаме свястна комбинация от двата протокола, която ДА ВЪРШИ НЯКАКВА РАБОТА.
(и разбира се, ако сте с валиден DKIM подпис, gmail и разни други мърлячи ще показват в получения ви mail картинки от външни линкове. Ето как тривиално спамерите ще видят дали ви е верен/работещ/четен mail-а)

2014-02-23 крокодиловден

Sunday, February 23rd, 2014

И стандартния post за празнуването на крокодиловден.
(празнувах на 22ри, щото 23ти е неделя и в понеделник никой нямаше да иде на работа)

Събрахме се, пихме, веселихме се, т.е. стандартното. Очаквах, че като ставам на 33 някой ще ми върне жеста и ще ми сковат кръст и т.н., но имаше само един чук и пирони…

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

От останалите неща това, което мога да фокусирам:
Мандолина;
Glenfidich 18, Glenfidich 12 и един Gentlemen Jack;
Един стар Sun сървър;
Един търмък и подобни инструменти за градина/user-и;
Надуваема овца, вазелин и т.н. (познайте от кого);
Тиган за палачинки (с идеята да каня хората, дето ми го подариха и да им готвя, оптимисти);

…и други. Като ми се спи малко по-малко, ще ги допиша.

Весело беше, догодина пак.

2014-02-13 bounce processing

Thursday, February 13th, 2014

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

Проблемът е следният: как да разберем, че не можем да пращаме mail до определено място, като ни дойде bounce от там? Да се parse-ва самото писмо е загубена кауза, понеже няма никакъв ясен формат.

Идеята е сравнително проста: във всеки mail има Return-Path: header, който винаги е първи, и към който се bounce-ва mail-а. Ако всяко съобщение има уникален такъв, може да се познае за кой получател (и може би и за кое съобщение) става въпрос. Самият bounce може да се познае по празният return-path (така че ако някой заблуден spam реши да дойде, да не създаде проблем).
(като всички такива хитрини, и тази е открита от Дан Бернщайн и даже си има нещо като стадарт – Verp)

Има различни начини да се направи, последният вариант, който написахме правеше return-path-а да е във следния формат:
UID_TIMESTAMP_SIGN@bounce.domain.com
където uid беше id-то на потребителя от базата, timestamp си е unix-ки timestamp и sign е sha1 на uid_timestamp_secret, като secret само ние си го знаем и така можем да проверим дали наистина ние сме го генерирали това. За да се избегне един race condition, в който потребителя си е сменил email-а преди ние да получим bounce, може в sign да се включи и оригиналния email адрес, така че bounce просто да не match-не сигнатурата си.
(гледайки сега по стандарта, заради graylist-а може да е добра идея да сменя първото _ с +)

От там нататък просто ви трябва нещо просто, което да засилва цялата поща за @bounce.domain.com към един скрипт, който да прави тривиален анализ на header-ите и да казва “да, тоя mail не е верен”.

2014-02-11 The Day We Fight Back

Tuesday, February 11th, 2014

Днес е the day we fight back.

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

2014-02-09 орг

Sunday, February 9th, 2014

(мяу. т.е. това е много насмукан post)

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

Приемаме кандидати, които не искат заплащане, не пият, биха вършили тая работа и все още нямат жълта книжка.
(bonus е кандидатите да могат да ми помогнат да се занеса в леглото след такива писания)
(също така, ако някой ден си взема клавиатура с LED клавиши, ще взема и дрегер към нея, и в пияно състояние backspace ще свети винаги, когато има наблизо думи, които spellchecker-а не харесва.)

Update: Сутринта си видях машината и изобщо не си спомнях, че съм писал тоя post. Оставям го некоригиран…
Update 2: “не пият” да се чете като “не пият много”…

2014-02-01

Saturday, February 1st, 2014

По случая, че ми пристигнаха бутилките Glen els Ember, едно дребно наблюдение:

Ако Steven Moffat и Joss Whedon направят сериал заедно, ще сме ок след това света да свърши.
(в който да участват Sarah Alexander, Morena Baccarin, Alyson Hannigan, Gina Belman, Sarah Michelle Geller, Nathan Fillion, Richard Coyle, и… може и още някакви, от мен да мине)