abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
dnes 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 4
dnes 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 2
dnes 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 1
včera 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 9
včera 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
včera 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
16.10. 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
16.10. 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (15%)
 (2%)
 (0%)
 (2%)
 (71%)
 (11%)
Celkem 55 hlasů
 Komentářů: 3, poslední dnes 20:46
    Rozcestník

    MessageWall - kladivo nejen na spam

    2. 1. 2003 | Jiri Svoboda | Sítě | 9634×

    Jak konečně vyřešit problémy se spamem.

    Úvod

    Problematika nevyžádaných mailů, případně rovnou obsahujících nějaký typ viru, neztrácí na aktuálnosti, spíše naopak. Dnes bych vás rád seznámil s jednou z možností obrany. Jak poznáte dále, není to sice možnost ideální (taková prostě neexistuje), leč z mnou prozkoumaných mě zaujala nejvíce, a sám ji již několik měsíců úspěšně používám. Jde o projekt jménem MessageWall, který je krátce charakterizovatelný slovy 'SMTP proxy'.

    Princip funkce

    MessageWall se spustí jako démon, naslouchající na konkrétní síťové adrese (konfigurační volba 'listen_ip'), a to na standardním SMTP portu 25. Současně otevře několik spojení s cílovým MTA (dáno konfigurační volbou 'backend_ip'). Tento cílový MTA může běžet jak na libovolném dalším dostupném stroji (například již v lokální síti), tak přímo na stroji s MessageWallem. Stačí ho jen nakonfigurovat, aby naslouchal na příslušné adrese a portu (v mém případě je to např. Postfix naslouchající pouze na 127.0.0.1:25). MessageWall sám není MTA a nedělá nic jiného, než že veškerá spojení transparentně (téměř) přesměrovává na cílový (backend) MTA. Nároky na kladené MTA nejsou nikterak velké a vyhoví jim prakticky každý běžný/moderní MTA (Sendmail, Postfix, qmail).

    Jak jsem již zmínil v závorce výše, ona zmíněná transparentnost není zdaleka stoprocentní, ale to je právě to, co se od programu očekává. Každý přicházející či procházející mail je kontrolován široce konfigurovatelnou sadou pravidel. Pokud mail pravidlům z nějakého důvodu nevyhoví, je odmítnut již na úrovni SMTP spojení, v případě nevhodné přílohy je možné tuto odstranit. V ideálním případě se tedy u nevyžádaného mailu vlastně nepřenese více, než úvodní sekvence SMTP povelů a odpovědí. Úplný seznam dostupných kontrol je k dispozici na domovské stránce projektu, pro účely tohoto článku vybírám následující:

    • antivirová kontrola s použitím pattern souborů z programu Open AntiVirus
    • kontrola proti internetovým blacklistům
    • kontrola MX/A záznamu zdrojové adresy
    • kontrola zdrojové a cílové adresy
    • kontrola jmen souborů MIME příloh
    • kontrola MIME typu příloh, případně jejich odstranění

    Pro doplnění: mezi další vlastnosti patří například podpora SMTP autentizace a SSL/TLS spojení, a to jak ze strany klientů, tak s cílovým (backend) serverem.

    Instalace

    Kompilace a instalace výjimečně není zcela triviální posloupností ./configure; make; make install, tím ale nechci říci, že je složitá. Její podrobný popis je k dispozici na domovské stránce projektu, zde provedu jen lehký nástin, abyste věděli, co vás čeká.

    Nejprve je třeba zkompilovat a nainstalovat podpůrné knihovny 'firestring'a 'firedns'. Obě jsou dostupné rovněž na webu MessageWallu a v jejich případě vystačíte s klasickou posloupností ./configure; make; make install. Standardně se instalují do adresáře /usr/local/lib, takže je vhodné zkontrolovat přítomnost tohoto adresáře v /etc/ld.so.conf a poté spustit ldconfig. Autoři ještě doporučují instalaci 'daemontools' (slouží, jak název napovídá, pro usnadnění práce s démony - nepoužil jsem) a knihovny 'OpenSSL'.

    Nyní již k instalaci vlastního MessageWallu. Začnete opět klasickým ./configure; make; make install. Poté však musíte udělat několik manuálních kroků. Konkrétně to znamená nakopírovat profily (předpřipravené seznamy filtrovacích pravidel) do příslušného adresáře a podobně nakopírovat soubor s virovými signaturami. V neposlední řadě je třeba vytvořit dva uživatele a dvě skupiny a připravit jim jejich domovské adresáře (MessageWall neběží pod rootem a běží v chroot prostředí). Tím je instalace hotova.

    Konfigurace

    Hlavní konfigurační soubor MessageWallu je standardně /usr/local/etc/messagewall.conf. Tento je dobře okomentován, takže by s nastavením neměl být vážnější problém. V mém případě jsem musel téměř všechny konfigurační položky odkomentovat, protože se MessageWall odmítal spustit a tvářil se, že nezná default hodnoty. Důležité je správně nastavit položky 'listen_ip' a 'domain', případně 'backed_ip', u zbytku se dá vesměs vystačit s default nastavením.

    Ve výše zmíněném konfiguračním souboru je, mimo jiné, definován výchozí profil (seznam filtrovacích pravidel) a odkazy na další konfigurační soubory, umístěné v rootu chroot prostředí. Konkrétně jsou to například soubor 'special_users', kde jsou definovány adresy a profily uživatelů s jiným než výchozím profilem a nebo soubor 'relay_ips' se seznamem IP adres, které mají povolen relay.

    Soubor profilu vypadá například takto (profil Medium, který je po instalaci jako defaultní):

    reject_score=1
    dnsbl=1,list.dsbl.org
    dnsbl=1,bl.spamcop.net
    rmx_required=1,1
    filename_reject=1,.exe
    filename_reject=1,.pif
    filename_reject=1,.scr
    filename_reject=1,.vbs
    filename_reject=1,.bat
    filename_reject=1,.com
    filename_reject=1,.shs
    filename_reject=1,.wsc
    header_rejecti=1,Precedence:junk
    header_rejecti=1,X-Mailer:Microsoft CDO
    header_rejecti=1,X-Mailer:eGroups Message Poster
    header_rejecti=1,X-Mailer:Delphi Mailing System
    header_rejecti=1,X-Mailer:diffondi
    header_rejecti=1,X-Mailer:RoryMAILER
    header_rejecti=1,X-Mailer:GreenRider
    header_rejecti=1,X-Mailer:GoldMine
    header_rejecti=1,X-Mailer:MailPro
    header_rejecti=1,X-Mailer:charset(89)
    header_rejecti=1,X-Mailer:MailWorkZ
    header_rejecti=1,X-Mailer:bulk
    virus_scan=1,virus.patterns

    První řádek definuje celkové maximální 'skóre', při jehož dosažení bude mail odmítnut, další řádky jsou pak již jednotlivá filtrační pravidla. První parametr každého pravidla (za rovnítkem) je opět 'skóre', tentokrát to, o které se celkové 'skóre' zvýší při 'pozitivním nálezu'. V konkrétním případě to znamená, že bude odmítnut každý mail, který neprojde byť jen jediným pravidlem.

    Spuštění

    Před spuštěním je nutné si uvědomit, že musíte mít volný SMTP port 25 na 'listen_ip' adrese, aby se na něj MessageWall mohl 'bindnout'. Prakticky to znamená odsunout případný běžící MTA na jinou adresu. Prvotní spuštění je pak vhodné udělat prostým zavoláním binárky z příkazové řádky, protože se z probíhajícího výpisu okamžitě dozvíte, co se děje, a tedy i případné problémy. Pokud se daří MessageWall spustit, stačí se již jen postarat o jeho pravidelné spouštění při startu serveru. Autoři k tomu doporučují výše zmíněné 'daemontools', já si do svých startovacích scriptů prostě přidal:

    /usr/local/bin/messagewall 2>&1 | logger -p local0.notice &

    (předtím jsem ovšem patřičně upravil /etc/syslog.conf a doplnil konfiguraci rotace logů).

    Nevýhody

    Jak jsem již zmínil na začátku, ideální tento systém není. Během několikaměsíčního provozu jsem narazil na pár věcí, na které bych rád případné zájemce o provoz upozornil.

    První nepříjemností je, že MessageWall je ochoten přijmout jednotlivý mail pouze pro jediného příjemce. Pokud je mail adresován více příjemcům, musí se jeho přenos pro každého z nich znovu opakovat. Prakticky to vypadá takto:

    220 domena.cz MessageWall 1.0.8 (You may not relay)
    MAIL FROM:<nekdo@nekde.cz>
    250 MessageWall: OK
    RCPT TO:<prvni@domena.cz>
    250 MessageWall: OK
    RCPT TO:<druhy@domena.cz>
    452 MessageWall: SMTP/TEMPORARY: One recipient per message from external hosts, please

    Nyní záleží na odesílajícím serveru, jak se zachová. Naprostá většina serverů zareaguje správně, dokončí přenos, a po chvíli vyvolá nové spojení pro dalšího příjemce. Bohužel jsem však v logu našel i případ serveru, který okamžitě po chybě '452' spojení ukončil a vyvolal nové. Toto nové spojení však ihned znovu se stejnou chybou skončilo a tento kolotoč se neustále opakoval mnoho hodin (nakonec jsem zmíněnému serveru zatnul tipec díky iptables)...

    Toto nepříjemné chování MessageWallu je jen zdánlivě nelogické. Důvodem je to, že každý jednotlivý cílový adresát může mít zcela jiný soubor filtračních pravidel. Pro některé z nich může být jeden konkrétní mail 'závadný', pro jiné naopak. Protože se však vyhodnocování děje již během SMTP přenosu a ne až po jeho ukončení, zvolili autoři programu toto řešení.

    Logickým důsledkem je prodloužení doby potřebné k doručení jednotlivého mailu všem adresátům, a především pak navýšení zátěže linky. Oblíbené 'odeslání pětimegabajtového filmečku všem lidem z adresáře' pak může v případě více adresátů ve vaší doméně dramaticky zvýšit přenášený objem dat. Je na každém z vás odhadnout nebo vysledovat, kolik takových mailů chodí a jak moc je pro nás toto chování nepříjemné a podle toho rozhodnout o (ne)nasazení MessageWallu.

    Zatímco na předchozí nepříjemnost jsem narazil již při počátečním testování, na druhou jsem narazil až během provozu. Jedná se o nastavení omezení velikosti jednotlivého mailu. Při prvotní konfiguraci jsem tuto velikost nastavil na standard používaný v naší společnosti, totiž 4MB. Později jsem si při prohlížení MRTG grafu zátěže naší linky všiml náhle se objevivších podivně pravidelných 'pahorků'. Po chvilce pátrání jsem viníka našel v MessageWallu, konkrétně to vypadalo nějak takto:

    220 domena.cz MessageWall 0.9.36 (You may not relay)
    EHLO foo
    250-MessageWall: Hello
    250-PIPELINING
    250-8BITMIME
    250 SIZE 4194304
    MAIL FROM:<nekdo@nekde.cz> SIZE=5000000
    250 MessageWall: OK
    RCPT TO:<nekdo@domena.cz>
    250 MessageWall: OK

    Přenos mailu se normálně spustil a po přenesení 4MB skončil s chybou. Po asi čtvrthodinové odmlce vzdálený server znovu navázal spojení a situace se opakovala. A to opět mnoho dlouhých hodin...

    Logické by bylo, že pokud MessageWall v odpovědi na EHLO specifikuje maximální velikost (zde 250 SIZE 4194304), vzdálený server by v případě delšího mailu vůbec neměl pokračovat. Pokud už pokračuje, měl by ho MessageWall odmítnout ihned poté, co nepřípustnou velikost sám vyspecifikuje (zde MAIL FROM:<nekdo@nekde.cz> SIZE=5000000). Bohužel toto se neděje a po důkladném pátrání v RFC jsem zjistil, že se zmíněnou situací není vůbec počítáno. Po dotazu u autorů MessageWallu mi byly mé závěry potvrzeny, leč bez náznaku řešení. Situaci jsem dočasně vyřešil zvýšením limitu velikosti mailu, v případě potřeby si však v budoucnu hodlám opravit zdrojový kód k obrazu svému.

    Závěr

    Nemám závěry rád, a proto nechť si z výše poskytnutých informací udělá každý svůj závěr sám. Já osobně však MessageWall (kromě řešení dvou výše zmíněných nepříjemností) používám k téměř plné spokojenosti...

           

    Hodnocení: 43 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    2.1.2003 13:02 pet
    Rozbalit Rozbalit vše Omezeni velikosti
    Domnivam se, ze pri omezeni velikosti mailu na strane SMTP serveru a nastaveni velikosti v MessageWallu na hodnotu vetsi by melo vse fungovat spravne. Sice je to pro vsechny uzivatele stejna hodnota, ale aspon neco.
    CIJOML avatar 3.1.2003 16:16 CIJOML | skóre: 58 | Praha
    Rozbalit Rozbalit vše nejlepsi je spam assasin
    nejlepsi je spam assasin ;) a kdo ho nepouziva, je trubka ;)
    20.12.2003 14:55 Nikola Ciprich
    Rozbalit Rozbalit vše nejlepsi je spam assasin
    tak to je opravdu reakce hodna inteligenta...
    20.2.2004 22:29 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
    Rozbalit Rozbalit vše Omezeni velikosti
    Máte-li klienta s Windows a chcete blokovat spam (zadarmo), zkuste Spaminhilator (freeware). Umí podobné věci jako tady MW (DNSRBL) + Baynes filtr. Funguje jako proxy...
    7.8.2003 13:07 Jan Nemsak
    Rozbalit Rozbalit vše MessageWall a fetchmail
    Mate niekto skusenosti s pouzitim MesageWallu ak vyberate postu z domenoveho kosa fetchmailom a predavate ju lokalnemu MTA? Mozem pouzit messagewall ak mam taketo riesenie? Lebo neviem ci fetchmail zvlada to, ze ak je sprava urcena pre viac prijemcov, posle to MTA osobitne (ked to vyzaduje messagewall)
    6.6.2008 11:58 srnka
    Rozbalit Rozbalit vše Re: MessageWall a fetchmail
    Pozrela som na oficialnu stranku Debiana, ze co najdem k MessageWallu, ci nie je pridany do repozitarov medzi stabilne balicky, lebo inak riskujem, ze balik moze obsahovat bugy a take cosi instalovat na server nechcem. Posledne, co k MessageWall bolo uverejnene, je z roku 2006: http://www.debian.org/News/weekly/2006/29/ a to info o odstraneni balicku, z dovodu bugov. O tych blizsie: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274732

    Neviem, ci to bolo potom odstranene, ale na servri Debian.org uz potom spominany MessageWall nie je. Stranka messagewall.org tiez nefunguje. Takze napriek tomu, ze znie tento program zaujimavo, radsej pohladam nejaky iny ekvivalentny.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.