Byla vydána verze 5.0 webového aplikačního frameworku napsaného v Pythonu Django (Wikipedie). Přehled novinek v poznámkách k vydání.
TuxClocker je Qt GUI nástroj pro monitorování a nastavování (přetaktovávání) hardwaru na Linuxu. Aktuální verze je 1.4.0. Z novinek lze vypíchnout monitorování využití AMD a NVIDIA VRAM nebo sledování spotřeby energie procesorů AMD a Intel.
O víkendu (15:00 až 23:00) probíhá EmacsConf 2023, tj. online konference vývojářů a uživatelů editoru GNU Emacs. Sledovat ji lze na stránkách konference. Záznamy jsou k dispozici přímo z programu.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek i s náhledy aplikací v Týden v GNOME a Týden v KDE.
Organizace Apache Software Foundation (ASF) vydala verzi 20 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Desktopové prostředí Cinnamon, vyvíjené primárně pro distribuci Linux Mint, dospělo do verze 6.0. Seznam změn obsahuje především menší opravy a v říjnovém přehledu novinek v Mintu avizovanou experimentální podporu Waylandu.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzích 2.2.2 a 2.1.14. Přináší důležitou opravu chyby vedoucí k možnému poškození dat.
V ownCloudu byly nalezeny tři kritické zranitelnosti: CVE-2023-49103, CVE-2023-49104 a CVE-2023-49105 s CVSS 10.0, 8.7 a 9.8. Zranitelnost CVE-2023-49103 je právě využívána útočníky. Nextcloudu se zranitelnosti netýkají.
I letos vychází řada ajťáckých adventních kalendářů. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2023. Pro programátory v Perlu je určen Perl Advent Calendar 2023. Zájemci o UX mohou sledovat Lean UXmas 2023. Pro zájemce o kybernetickou bezpečnost je určen Advent of Cyber 2023…
Byla vydána verze 2.12 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
DKIM využívá elektronický podpis s dvojicí soukromý a veřejný klíč. K podpisu soukromým klíčem dochází na SMTP serveru (např. firemní server nebo server poskytovatele připojení) a není potřeba žádná součinnost ze strany uživatele. Předmětem podpisu je hash těla zprávy, některé hlavičky a hlavně doména, ze které e-mail pochází.
Pro distribuci veřejných klíčů se využívá DNS a předpokládá se, že DNS záznamy pro danou doménu může nastavovat jen její vlastník.
Server příjemce si tedy veřejný klíč pro danou doménu stáhne z DNS a ověří pomocí něj elektronický podpis zprávy.
Jedná se o dvě různé úrovně podepisování e-mailů. V případě S/MIME nebo GPG podepisuje zprávu její autor (osoba) a tento podpis je vázán na danou e-mailovou adresu. Zatímco DKIM podpis pouze dokazuje, že e-mail pochází z dané domény.
Podepisování na serveru a podepisování odesílatelem se vzájemně nevylučují. Je možné obě metody kombinovat – každý podpis slouží k jinému účelu.
Na příkladu Postfixu si ukážeme, jak do svého poštovního serveru můžeme podporu DKIM přidat. K zapojení DKIM do procesu zpracování pošty použijeme technologii milter, takže postup v případě, že používáme místo Postfixu Sendmail, bude velice podobný.
Nainstalujeme si potřebný balíček – v Debianu/Ubuntu by to šlo takto:
# aptitude install dkim-filter
Vytvoříme si podpisový klíč:
# mkdir /etc/mail # cd /etc/mail # dkim-genkey -d naše-doména.cz
Program nám vygeneroval dva soubory: default.private
(soukromý klíč) a default.txt
(soubor obsahující veřejný klíč a informace pro nastavení DNS). Soubor se soukromým klíčem by měl patřit rootovi a neměl by být čitelný jinými uživateli.
Poznámka: při generování klíče můžeme zadat i tzv. selektor (parametr -s
) – pro jednoduchost použijeme výchozí: default
.
Teď potřebujeme nastavit správně DNS, aby ostatní servery mohly zjistit, jaký je náš veřejný klíč. Vytvoříme si DNS záznam podle vzoru uvedeného v souboru default.txt
. Např.:
default._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQPmhgFl/Zj6f7ciMCyMYBk8oeSAJOOxBrgqarIyjkmeTNOr3oMeneP/uLOT9zP5VGYLUtepalxDsbs2WypjDa6MOm7mPHOrsW8WSSKTDTQsGyGekMgPu2QhV5I7BjTzIpYyOOJNoqMYKoqckQBno7CLaXuwI7lIvcc3Jdo7f+MwIDAQAB" ; ----- DKIM default for veverka.ch
Pokud zadáváme záznam do webového rozhraní našeho správce DNS, zadáme default._domainkey
a v=DKIM1; g=*; k=rsa; p=MIGfMA0G … wIDAQAB
(bez uvozovek) a zvolíme typ záznamu TXT
.
Nastavíme si DKIM milter: v souboru /etc/dkim-filter.conf
zadáme tyto hodnoty:
Domain naše-doména.cz KeyFile /etc/mail/default.private Selector default
A do souboru /etc/default/dkim-filter
přidáme řádek:
SOCKET="inet:8891@localhost"
DKIM teď bude naslouchat na místním portu 8891. Místo síťového portu můžeme použít i UNIXový socket.
Zbývá už jen nastavit Postfix – do souboru /etc/postfix/main.cf
přidáme tyto řádky:
# DKIM podpis SMTP serveru smtpd_milters = inet:localhost:8891 non_smtpd_milters = inet:localhost:8891
E-maily odeslané z naší domény teď budou obsahovat elektronický podpis. Jedná se o podpis serveru, nikoli odesílatele (osoby). Podpis je realizován formou hlavičky ve zprávě – např.:
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=veverka.ch; s=default; t=1241265143; bh=opC+T+DvWgIbxfSLcsOLnAcFxNGJTZfSK4iWmZj Vwic=; h=Message-Id:Date:From:To; b=DOhq7UkgV0xHaVrrOEP17cv/iwDo9Dw tqgxOeI2q5ei4ab/Io5TWCDFS9M9RxbHnBNGHXbAUYjz83R+bFbPVIwRwQAzuanNNjS SVd4cEw6ClLnPLi3AMeDdaYXm2GhY96sFBKzoXCtVolv04nF+O0811T8NRIbz0+F6zz 317QSM=
DKIM-filter podpisy zpráv nejen vytváří, ale i ověřuje. Pokud máme dva servery s podporou DKIM, můžeme si to snadno vyzkoušet. Výsledek pak vypadá takto:
Authentication-Results: veverka.ch; dkim=pass (1024-bit key) header.i=@frantovo.cz; dkim-asp=none
Cílový server ověřil elektronický podpis (veřejný klíč zjistil z DNS záznamu) a vložil hlavičku o úspěšném ověření. Pokud zkusíme podpis podvrhnout, např. tak, že na odesílacím serveru nastavíme jiný klíč a neaktualizujeme DNS záznam, výsledek bude tento:
Authentication-Results: veverka.ch; dkim=hardfail (verification failed) header.i=@frantovo.cz; dkim-asp=none
Jestliže nemáme dva e-mailové servery s DKIM, můžeme si jeho funkčnost ověřit např. tak, že pošleme e-mail na adresu firmy Eland Systems: autorespond+dkim@dk.elands ys.com. Za chvíli nám přijde odpověď s výsledkem, zda se náš podpis podařilo ověřit. Nebo si můžete poslat zprávu do schránky na GMailu a ve webovém rozhraní se vám u přijaté zprávy ukáže: podepsáno od naše-doména.cz
.
DKIM je jedna z technologií, která může pomoci v boji proti tolik nenáviděnému spamu. Nepodepsané (nebo špatně podepsané) e-maily sice nebudeme zahazovat jako spam, ale ty správně podepsané za spam považovat nemusíme. Pokud by se přesto o spam jednalo, víme alespoň, kdo je za něj zodpovědný.
Zároveň může DKIM podpořit důvěryhodnost e-mailů pocházejících z vaší organizace u jejich adresátů. Tedy alespoň u těch, kteří tyto podpisy dokáží interpretovat a ověřovat (např. uživatelé GMailu). I přes absenci elektronického podpisu, jako je S/MIME či GPG, je příjemce schopný ověřit původ zprávy – alespoň na úrovni domény, např. firma.cz
. Což může teoreticky fungovat jako opatření proti podvodným e-mailům – rhybaření (phishing) – a to především při nasazení Author Domain Signing Practices.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Děkuji, jdu si to nahodit na server
Dobré a jednoduché.
Ja by som však všetky maily z domén, ktoré majú v DNS publikovaný tento kľúč a sú ním nepodpísané zahadzoval. Takisto zahadzovať maily, ktoré majú chybný podpis. Dá sa to takto nastaviť?
Dobré by bolo, keby sa to dalo integrovať aj s greylistingom, t.j. podpísaný mail prijať okamžite ostatné predať na greylist (teda dočasne odmientnuť s chybou 4xx, čo normálny server doručí do 20 minút).
Inak podobný výsledok dostaneme aj so SPF. Tam v DNS publikujeme servre, ktoré môžu odosielať poštu z našej domény. V tomto prípade netreba rátať hash a kryptograficky ho overovať, ale stačí pozrieť IP adresu servra, ktorý mail posiela. BTW cca pred 2 rokmi som si prebehol celú sk. doménu a SPF používalo cca 2,5 % domén.
A to je prave spatne tohle by si mel kazdy admin ohlidat nikdo nebude posilat firemni postu pres nejakeho ISP horni-dolni. Pokud uz nekdo chce odesilat postu a port 25 je blokovany ma to udelat bud pres VPN a nebo pres web rozhrani.
paráááda
ak mam se servery viacej domen a chcem pre kazdu zvlast podpis ?
vygenerujem kluc, ale kde zadam postfixu ktorym klucom ma podpisovat maili pre danu domenu ?
To naštěstí ne – jsou dvě řešení:
KeyList
viz komentář pode mnou.DKIM milter potom pro svoje domény klíč přidává a pro cizí ho ověřuje.
Pro Debian Edge balicek tento balicek neexistuje? Jak tento balicek/program zprovoznit na debianu etch? Dekuji Jakub
zdravim,
pouzit certifikaty by v necem pomohlo. A byl bych jednoznacne pro.
I kdyz spammer Vam casem bude klidne podepisovat dokumenty certifikatem z Verisign.
Jenomze to ma par hacku, minimalne u nas v "Bananistanu" = CR.
0) dokud nebude certifikat pro uzivatele za pivo (invex, interval.cz, hlaska), tak to nema smysl. O cene serverovych certifikatu radeji nemluve.
1) hodne velky problem je jednoduse nainstalova a vubec nainstalovat certifikat pro usery. Idealne vyridit a predinstalovat do postovniho klienta.
2) zakony. Spam se bude rozesilat a nikomu se moc nestane. Anebo musite podepsat neco o ochrane udaju a opet v tom litate.
3) Misto obcanky chipovou kartu a na ni mit certifikaty. Idealne mit nejakou klicenku se statnimi a duveryhodnymi certifikaty.
4) Dokud bude bezpecnost v rukou Microsoftu, tak bych to ani nedelal. To proste nema smysl. At uz aplikace nebo hlasky typu nebezpecny obsah s certifikatem....
5) ono bylo vcelku chyba, ze se v hodne protokolech nepouziva defaultne nejake SSL/TLS a podobne.
Certifikaty jsou kouzelna technologie. Jen IT svet ji nejak nezvladl.
gf
I kdyz spammer Vam casem bude klidne podepisovat dokumenty certifikatem z Verisign.
Pak ale půjde dohledat, kdo spamovat.
hodne velky problem je jednoduse nainstalova a vubec nainstalovat certifikat pro usery. Idealne vyridit a predinstalovat do postovniho klienta.
V první řadě musí uživatelé používat poštovního klienta. Pro mě je to samozřejmost, ale lamy si chodí číst poštu přes web. Nechápu.
Misto obcanky chipovou kartu a na ni mit certifikaty. Idealne mit nejakou klicenku se statnimi a duveryhodnymi certifikaty.
Moje řeč Tohle by s elektronickým podpisem hodně pohnulo – každý by měl svůj certifikát na kontaktní čipové kartě a zároveň by to byla občanka.
ono bylo vcelku chyba, ze se v hodne protokolech nepouziva defaultne nejake SSL/TLS a podobne.
Dnes hlavně FTP a SMTP – FTP by se mělo zahodit úplně (resp. používat jen pro anonymní veřejné stahování) a používat místo něj SFTP. SMTP by šifrování prospělo, taky se někdy mezi servery používá*, ale v principu to nikoho nespasí – člověk dopředu neví, jestli se všechny servery po cestě domluví na TLS, tudíž by měl stejně šifrovat na úrovni zprávy (S/MIME nebo GPG).
Certifikaty jsou kouzelna technologie. Jen IT svet ji nejak nezvladl.
Nemyslím si – vždyť na certifikátech a PKI stojí dneska všechny banky a elektronické obchody, bez SSL by tenhle byznys byl nepředstavitelný. Jenže to jsou serverové certifikáty, s klientskými je to horší – ty občanky s tokenem by hodně pomohly…
*) mezi klientem a serverem to považuji za samozřejmost, když se klient prokazuje jménem a heslem.
No, a prave vsetko toto by mohlo vyriesit SPF. Ono, dnes spamy rozosielaju hlavne vselijake zombie pocitace. Tych je povedzme 10 000(este dost male cislo). A ak by mal spammer udrzovat pre kazdu domenu tych 10 000 ip adries ktore mozu pre danu domenu rozosielat maily, tak by sa asi zblaznil. Naviac, je to skoro nerealne. DKIM je super vec-spolu s SPF sa doplnaju. Myslim si,ze keby vsetky mailove servre zacali SPF pouzivat, tak by sa spam minimalne obmedzil a spammarom by to pridalo omnoho viac prace.
......................................
Za DKIM zase hovori to, ze ak by mal spammer pre kazdu priblblu domenu generovat certifikat ktory je za prachy, tak by ho to stalo dost vela prachov-naviac mal by viac papierovaciek a zmenit odosielaciu domenu by nebolo az tak jednoduche.
Tohle vůbec není nutné*, SPF a DKIM ADSP jsou více méně alternativy – jedna pracuje s oprávněnými IP adresami a druhá s oprávněnými podpisovými klíči – v obou případech si ale ty oprávněné klíče nebo IP adresy propaguješ sám skrze DNS → nemusíš tedy platit nic navíc, stačí mít vlastní doménu. Nemusíš se ani nikoho ptát nebo žádat o posvěcení certifikátu nějakou autoritou – prostě si jen vytvoříš soukromý a veřejný klíč a ten veřejný vystavíš do DNS záznamu (TXT). Vedle toho do DNS můžeš vystavit i pravidlo, že všechny e-maily z tvé domény musí pocházet od vybraných IP adres, nebo být podepsané vybraným klíčem.
Ať jedno či druhé, přijde mi to jako velice rozumné řešení, protože jako vlastník doménového jména můžeš omezit, odkud se pošta z tvé domény smí posílat, ale nic to nestojí. Kdo nemá vlastní doménu, ten používá např. SMTP server svého poskytovatele nebo firmy, školy atd. → takže není problém, aby tenhle SMTP server byl mezi těmi, které z dané domény smějí posílat.
*) pravda, Microsoft by si přál, aby se platilo za kde co a on si z těch peněz mohl část užírat, ale to mu neprojde.
A pokud by mi prisel spam s podpisem, tak by se presne vedelo, kdo za tim stoji.Ale to je přesně to, co DKIM dělá. Vás totiž nezajímá, kdo SPAM vytvořil, vás zajímá, kdo vám ho poslal. A to právě podle DKIM zjistíte. Pokud ho ten dotyčný poslal kvůli špatné konfiguraci serveru nebo zavirovanému počítači, je to stejně jeho problém a on ho musí vyřešit. Pokud se má bojovat se spamem tak, že se budeme snažit zabránit posílání spamu, nejde řešit původního odesílatele (ten se klidně bude připojovat pokaždé odjinud pod jinou identitou), ale právě toho, kdo e-mail (byť třeba nechtěně) rozesílá.
BTW: spam chodí i ze „seriózních“ domén (Hotmail…), přímo z jejich serverů – psal jsem jim stížnost, ale neobtěžovali se s odpovědí – kéž by aspoň tomu chudákovi, který to posílal, zablokovali SMTP a upozornili ho – pravděpodobně má postižené Windows a z jeho počítače se spamuje.
Tyhle případy DKIM nevyřeší, ale spoustu spamu, který je odesílaný z pochybných serverů ano – hlavně když se nasadí DKIM ADSP, což je alternativa k SPF
Noví uživatelé by mohli mít nějakou kvótu – třeba postal nanejvýš deset zpráv1 za den… a kvóta by jim postupně rostla, až by časem omezení neměli vůbec. Uživatelé by si svých účtů aspoň víc vážili. Kdyby někdo zaspamoval, tak by o účet přišel, nebo by přinejmenším dostal omezení (mohl by jen přijímat a posílat jen málo zpráv). Časem by se vyprofilovaly důvěryhodné servery, které nepodporují spamery a mají takto přísná pravidla, a ostatní by od nich mohli bez obav přijímat poštu – a vůči ostatním by se praktikovaly přísnější metody (např. greylisting, který zdržuje poštu).
*) nebo hvězdičky?
Predpokladam, ze DNS se mysli NS pro danou domenu....overitelny napr pres dig domena.cz NS ....?
Diky
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access regexp:/etc/postfix/filter.regexp reject_unauth_destination, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, permitSubor filter.regexp obsahuje len jeden riadok:
/^/ FILTER filter:("filter" je definovany v master.cf) To sposobi, ze vsetci z lokalnej siete a prihlaseni budu pusteni bez kontroly, inym sa nastavi content_filter na "filter". 2) Ten test nie je pre DKIM, ten elandsys funguje.
asi jsem tupy, ale "("filter" je definovany v master.cf)"
jak? kde?
filter unix - n n - - pipe flags=Rq user=filter null_sender= argv=/usr/local/bin/filter.sh -f ${sender} -- ${recipient}
jde to i jinak do casti preposlani do scanneru
127.0.0.1:10025 inet n - - - - smtpd
pridate
-o smtpd_milters
-o non_smtpd_milters