Blokování odchozího SMTP provozu z pracovních stanic v SBS 2003 Standard síti

Představte si následující situaci. Firma používá Small Business Server 2003 R2 Standard (SBS) a na něm provozuje mimo jiné poštovní server Exchange. Server by měl být jediným oprávněným strojem pro odesílání elektronické pošty do internetu. Ovšem pracovní stanice v SBS síti zpravidla přistupují k internetu prostřednictvím SBS serveru. Tedy přes stejnou IP adresu. Stačí, tedy aby některá z nich byla zavirována, odesílala spam a na problém je zaděláno. IP adresa vašeho Exchange Serveru se díky stanici octne na spam blacklistech a problém je na světě. E-maily z vaší veřejné IP adresy budou ostatními poštovními servery hodnoceny jako spam a v nejhorším případně nebudou adresátovi vůbec doručeny. Tomu je třeba všemi prostředky zabránit.

Pokud nemáte SBS Premium s ISA Server firewallem či vašemu serveru není předřazen hardwarový firewall, nabízí se následující řešení.

Řešení

SBS Standard totiž umí pomocí Group Policy aplikovat na klientské stanice IPsec filtr, který pomocí pravidel dokáže blokovat provoz z pracovních stanic. V našem případě, tedy aplikujeme na pracovní stanice pomocí Group Policy pravidlo blokující odchozí TCP komunikaci z portu 25. Kompletní návod včetně obrázků najdete tady.

Měli byste mít na paměti, že Group Policy se aplikuje pouze na stanice, které jsou v doméně. Strojů umístěných v pracovní skupině se vůbec netýká a mohou dále komunikovat bez omezení. Proto je dobré řešit vše v rámci ISA Serveru případně před Small Business Server předřadit HW firewall, který ošetří SMTP komunikaci směrem do internetu globálně pro celou síť.

Nefunkční připojení k síti po aktualizaci KB968389

Na jednom z SBS 2003 R2 Premium serverů jsem se setkal s nepříjemným problémem. Provedl jsem aktualizaci a po restartu serveru kompletně přestalo fungovat připojení k síti. Nebylo možné se tedy připojit na server ani ze serveru ven. Server byl zkrátka kompletně odstřižen, a tak nezbývalo, než usednout do auta a přihlásit se lokálně. Všechno se mi povedlo vyřešit. Pro případ, že se potkáte s nečím podobným, tady jsou mé poznatky.

Na stroji běžel Small Business Server 2003 R2 SP2. Nainstalovány byly veškeré aktualizace kromě osudné KB968389. Jediným specifikem serveru je vypnutá služba WINS. Server totiž neslouží klientům ve vnitřní síti, a proto je služba zakázána. Po nainstalování KB968389 a následném restartu server před přihlášením zobrazil chybu ve smyslu: “Nepodařilo se nastartovat některou ze služeb nebo ovladač”. Po přihlášení nebylo možné využívat žádné připojení k síti. Síťová připojení přitom nehlásila žádnou chybu a tvářila se jako aktivní. Z event logu jsem zjistil, že celou věc způsobuje služba IPsec, která nemůže nastartovat a zároveň blokuje veškerý síťový provoz. Nezabral ani ruční pokus o spuštění, služba se vždy ihned ukončila.

Po odinstalování aktualizace KB968389 problémy ihned po restartu odezněly a všechno fungovalo. Pokoušel jsem se aktualizaci znovu nainstalovat. Tentokrát jsem službu WINS povolil a až poté spustil aktualizaci. Po restartu vše funguje. Nakonec jsem zakázal službu WINS a vše i po dalším restartu funguje.

Vypadá to tedy, že aktualizace KB968389 vyžaduje běžící službu WINS. Po restartu ji pak můžete volitelně zakázat, pokud pro to jako já máte důvod.

Provoz 20000 paketů/s aneb server měl plodný den

dell-poweredge

Od technika telehousu, kde mám umístěn jeden ze svých serverů jsem se nedávno dozvěděl, že můj stroj má mimořádně “plodný” den a z nějakého důvodu generuje do sítě datový tok 20 000 paketů za sekundu. Po bližším ohledání jsme zjistili, že jde o multicast UDP provoz na cílovou IPv4 adresu 224.0.1.24. Pro případ, že se potkáte s něčím podobným vězte, že na vině může být služba WINS. V mém případě vytížila procesor téměř na 100% a vzdálené přihlášení na server přes RDP trvalo opravdu pekelně dlouho.

Podle materiálů, které jsem našel v dokumentaci, se jednotlivé WINS servery mezi sebou snaží pravidelně komunikovat a případně synchronizovat své databáze. Při tomto procesu nejspíše došlo k nějaké chybě a server tvrdohlavě hrnul provoz do sítě. Možná šlo o bezpečnostní problém viz odkaz na Microsoft KB níže. Služba WINS pro mě nebyla nijak podstatná, takže jsem ji zakázal. Od té doby se už podobné problémy neobjevily.

Několik faktů

  • Windows Small Business Server 2003 R2 Standard
  • Konfigurace se dvěma síťovými kartami (jedna do LAN, druhá do internetu) Server byl jediným WINS serverem v lokální síti
  • Protokol UDP, port 42
  • Cílová adresa IPv4 224.0.1.24
  • Poučení pro přístě: Co nepotřebuješ, zakaž a vypni:)

Informace

http://support.microsoft.com/kb/890710

Jak do Sharepointu vložit odkaz na soubor, v jehož cestě je obsažena mezera?

Zadání:

Sharepoint má pro psaní nových Oznámení jednoduchý webový editor, který mimo jiného automaticky rozpoznává, zda to, co píšete není hypertextový odkaz. Pakliže ano, zařídí jeho vytvoření, podtrhne text a změní jeho barvu na modrou. Problém nastane, pokud je ve vašem odkazu obsažena mezera. Pak editor vytvoří odkaz jen po první mezeru. Zbylé znaky za mezerou do něj už nezahrne.

Vytvoření odkazu na soubor, v jehož cestě je obsažena mezera lze vytvořit pomocí následujícího příkladu.

Cesta ksouboru:
\\server\disk d\seznam.xls

Sharepoint automaticky vytvoří odkaz jen zčásti:
\\server\disk

Řešení:

Do editoru vložte odkaz v následující podobě. Mezeru nahraďte řetězcem %20 a na začátek vložte file:.

file:\\server\disk%20d\seznam.xls

Jak nastavit Sender Policy Framework (SPF) záznam?

Co  vlastně SPF znamená?

Jak už název Sender Policy Framework napovídá, jedná se o technologii, která na základě adresy odesílatele e-mailu ověřuje, zda je poštovní server, ze kterého zpráva přisla, autorizován odesílat e-maily pro danou doménu.

Jinak řečeno. Za pomoci SPF jsem schopen definovat, kterým poštovním serverům dám možnost odesílat poštu za mou organizaci. Všechny ostatní zakáži.

Tak například – z ryze administrátorského hlediska. Mám ve firmě dva poštovní servery. Chci, aby oba mohli nadále odesílat a přijímat poštu pro firemní domény, ale chci zabránit, aby někdo cizí odesílal podvržené zprávy, tvářící se, že pocházejí z naší firmy. Nastavím tedy SPF. Oba naše poštovní servery jsou vedeny v MX záznamu na našem DNS serveru. Vyhovuje nám tedy následující podoba záznamu: “v=spf1 mx -all”. Problém vyřešen.

Co mi SPF přinese?

V prvé řadě bude moci každý cílový poštovní server, kam posíláte e-mail, ověřit, že zpráva pochází z vašeho poštovního serveru a nejedná se o podvržený e-mail, tvářící se, že přichází z vaší organizace. Funguje to i naopak. Pokud váš mail server podporuje SPF technologii, každý příchozí e-mail do vaší firmy, bude prověřen, zda pochází z autorizovaného zdroje.

Jaké jsou nevýhody této technologie?

Asi nejpodstatnější nevýhodou se zdá být zvýšený počet DNS dotazů, což vede k vyššímu vytížení DNS serverů. Pokud se ve vašem záznamu použijete příkaz include, pak se cílový server dotazuje vaší domény a k tomu ještě includované domény. Jestli vám include nic neříká, pro tuto chvíli na něj klidně zapoměňte. Dočtete se o něm dále.

Pro koho je SPF vhodné?

SPF by mělo zajímat každého správce poštovního serveru a každou organizaci, která si alespoň trošku základá na důvěryhodnosti své elektronické poštovní komunikace.

Pro koho SPF není vhodné?

Obecně se uvádí, že se Sender Policy Framework mohou mít problém mobilní uživatelé, kteří za den vystřídají několik různých připojení, poskytovatelů a hlavně poštovních serverů. Ale v dnešní době jsou pěkná řešení i na tuto problematiku. Možností je opravdu hodně, zmiňme například možnost VPN připojení do firemní sítě, Outlook Anywhere (RPC over HTTPS) či Outlook Web Access.

Je potřeba záznam nějak průběžně měnit nebo ho stačí nastavit jednorázově?

Odpověď je v zásadě jednoduchá. Záznam jednou vytvoříte a nemusíte se o něj nikterak starat. Rozumné je ale vše zkomunetovat a především mít na paměti, že nějaký takovýto záznam pro vaší doménu používáte. Úpravu SPF je třeba provést zpravidla v případě změny vašeho ISP, hostingu a změny vašeho poštovního řešení.

Co pro oživení SPF musím udělat?

Na vašem DNS serveru je potřeba přidat SPF záznam ve formátu TXT. Tím je vše hotové. Některé firmy  používají DNS servery svých wehosterů či providerů. Změnu DNS záznamů je pak potřeba provést přes webové rozhraní či písemným požadavkem.

Chcete-li kontrolovat příchozí poštu pomocí SPF, zapněte tuto funkci na vašem poštovním serveru. Zprávy přijaté od neautorizovaných serverů, pak budou zahazovány a bezpečnou cestou tak snížíte množství příchozího spamu a podvržených e-mailů.

Jak to funguje?

1. Jirka z firmy1 odesílá e-mail kolegovi Petrovi z firmy2.

2. Poštovní server firmy1 zprávu zpracovává a odesílá pomocí SMTP na server firmy2, kde pracuje Petr.

3. Firma2 používá na svém poštovním serveru antispamové řešení, které mimo jiné umí vyhodnocovat SPF. Zpráva od Jirky je přijata a podléhá spamové kontrole a ověření pomocí SPF. Server se dotazuje DNS serveru, který drží SPF záznam pro firmu1.

4. Ten pak odpovídá a vrací výsledek dotazu.

5. Server firmy2 zjistí ze SPF záznamu, zda je server firmy1 oprávněn odesílat poštu za doménu firma1.cz. Pakliže ano, je zpráva doručena Petrovi. V opačném případě je e-mail označen jako spam.

Správná syntaxe záznamu a příklady

Nyní už víme, že SPF je TXT záznamem v DNS a jak přibližně vypadá komunikace mezi servery. Pojďme přejít k samotné podobě záznamu.

Nejjednodušší záznam vypadá takto: “v=spf1 -all”

Co to znamená? Vaše doména nepoužívá e-mail. Máte na ní například jen webové stránky a poštu odesíláte z jiné domény k tomu určené. Jakýkoliv e-mail pocházející z domény s tímto záznamem bude po vyhodnocení SPF zahozen, případně označen jako spam. “-all” na konci znamená, že žádný autorizovaný server neexistuje.

O poznání zajímavější je: “v=spf1 mx -all”

Výraz se vyhodnocuje zleva doprava. MX znamená, že všechny servery, které jsou uvedeny ve vašich MX záznamech budou považovány za důvěryhodné a SPF je vyhodnotí jako autorizované. Všechny ostatní budou díky “-all” označeny jako neautorizované.

“v=spf1 mx mx:mail.firma1.cz -all”

Má stejný výsledek jako předchozí výraz s tím rozdílem, že mezi oprávněné servery získáné z MX záznamů přidáváme mail.firma1.cz.

“v=spf1 include:mujisp.cz -all”

Dejme tomu, že jsme malá firma a chceme ušetřit za investice do vlastního serveru. Náš ISP bude firma mujisp.cz. Domluva zní tak, že poštu budeme posílat přes jeho server. Náš SPF záznam tedy může vypadat právě takto. Include zajistí, že se přečte SPF záznam z domény providera mujisp.cz a jeho obsah bude považován za náš. Provider musí mít SPF nastaven.

“v=spf1 ip4:192.168.0.1/16 -all”

Poslední ukázka demonstruje přidání poštovních serverů z IP rozsahu 192.168.0.1 – 192.168.255.255 mezi důvěryhodné. Všechny ostatní vyhodnotí jako zakázáné.

Závěr

SPF není všelék na spam, ale rozhodně stojí za to, ho zavést. Vytvoření zabere jen několik desítek minut a pak již vše pracuje za vás. K dispozici jsou také velmi povedené nástroje pro vytvoření a případně i ověření správnosti vašeho SPF záznamu.

Zdroje

Nástroje pro vytvoření: http://old.openspf.org/wizard.html
Nástroje na otestování: http://www.openspf.org/Tools
Microsoft SPF Record Wizard: http://www.microsoft.com/…/wizard/
Syntaxe: http://www.openspf.org/SPF_Record_Syntax
Časté chyby: http://www.openspf.org/FAQ/Common_mistakes

Video – Jak nastavit SPF?

SBS 2003 – Jak probudit počítač přes Vzdálené webové pracoviště?

Narazil jsem na zajímavý doplněk pro Small Business Server 2003. Přináší do rozhraní Remote Web Workplace (Vzdálené webové pracoviště) nové tlačítko pro vzdálené probuzení počítače, ke kterému se chcete připojit. Software plně využívá RWW a pomocí Wake on LAN technologie rozširuje jeho možnosti.

rww-wol.png

Vše vypadá velmi jednoduše i pro uživatele. Zatím jsem neměl možnost tento software vyzkoušet, ale pokud získáte nějakou praktickou zkušenost, budu velmi rád, když se o ni podělíte.

Podrobnější informace najdete na: http://dnn.sbstools.de/produkte/WakeOnLANfürRemoteWebArbeitsplatzRWW/tabid/654/Default.aspx

Exchange 2003 SP2 IMF – ID události 7515

Před pár dny mě zaujala událost v Event logu s ID 7515, která se mi občas na pár serverech začala objevovat. O co tedy jde? V prvé řadě je třeba říci, že tento event je pozorovatelný na Exchange serveru se SP2 a spuštěným Intelligent Message Filterem (IMF). IMF je technologie pro detekci spamu na. Na základě analyzování každé jedné zprávy ohodnotí email patřičnou známkou, ukazující potenciální možnost, že jde skutečně o spam. S hodnoceními se pak dále pracuje.

Praxe je taková, že většina spamu dosahuje průměrné maximálně velikosti několika kB. Microsoft se tímto inspiroval i při vytváření IMF. Zprávy větší než 3 MB tak neprocházejí procesem analýzy, aby zbytečně nezatěžovaly server a jsou rovnou doručovány. Kromě toho je ale také generována událost do event logu s ID 7515.

Shrnuto podtrženo, máte-li aktivní IMF na vašem Exchange serveru, pak každá zpráva větší než 3 MB nebude filtrována a vygeneruje vám událost s ID 7515. Toť celé zajemství tohoto eventu. Je to tak dáno by design.

Blížší info můžete načíst v tomto KB907691.

Na Vista klientech nelze upravit text e-mailu pomocí Outlook Web Access

Windows Vista jakožto klient připojující se na webové rozhraní Exchange Serveru 2003, nepodporuje některé ActiveX komponenty, které jsou nutné pro správnou funkci editoru Outlook Web Access. Výsledkem je, že v okénku pro vepsání samotného textu e-mailu se objeví křížek, znemožňující jakýkoli vstup. Řešení tohoto problému popisuje KB 911829. Napravuje situaci hotfixem, který je třeba zaplikovat na Exchange Server. Po instalaci vše funguje tak, jak jste zvyklí z Windows XP.