HTML

A rendszergazda naplója

A rendszergazda naplója, hasznos megoldásokkal rendszergazda jelölteknek és felhasználóknak.

Friss topikok

Linkblog

2014.08.25. 19:21 Hegedűs_Gábor

Letiltottam magam a Facebook-ról

Címkék: Facebook tiltás

Egyik nap szokatlan kéréssel fordult hozzám az egyik ügyfelünk. Úgy gondolta, hogy napi szinten túl sokat tölt a Faceook böngészésével és ez már a munkájának a rovására megy. Ez azért is volt különösen súlyos probléma számára, mert vezető beosztásban dolgozik a cégnél, és gyakran napi 10-12 órát tölt bent a munkahelyén.

Szenvedélye a Facebook iránt olyan erős volt, hogy képtelennek érezte magát, hogy saját magától ne nyissa meg az oldalt. Külső kényszerre volt szüksége, ezért megkeresett minket. Nem mondom, hogy először nem csodálkoztunk a kérésen. Hogy lehet az, hogy valakinek nincs elég önereje ahhoz, hogy egyszerűen ne nyisson meg egy oldalt. Aztán be kellett hogy lássuk, hogyha alkoholfüggőség, vagy szerencsjáték függőség létezik, akkor Facebook függőségnek is léteznie kell. Ez egyébként informatikusoknak elég furcsa jelenség, hiszen szerintem a legtöbb szociálisan analfabéta közöttünk van, így minket a Facebook teljesen hidegen hagy. :)

A Facebook és egyéb közösségi média oldalak tiltása egyre általánosabb jelenség a cégeknél, egyre több vezető gondolja úgy, hogy a Facebook folyamatos használata csökkenti az egyes munkavállalók produktivitását. Könnyen ki lehet számolni, hogyha egy kolléga napi 2 órát foglalkozik a közösségi médiával, akkor csak kevesebb mint 4 napot dolgozik egy héten. És ezt sokan ki is számolják. Persze a kép nem ennyire fekete-fehér. Akik ezt ilyen pontosan kiszámolják, ritkán gondolnak arra, hogy egy munkavállalónak mindenképp szüksége van egy kis szünetre, kikapcsolódásra munka közben, hiszen nem vagyunk robotok, képtelenek vagyunk a megszakítás nélküli munkavégzésre. Mások ilyenkor dohányoznak, e-mailt olvasgatnak, hírportált böngésznek, aknakeresőznek, és millió más módját találják meg az agyuk kikapcsolásának. Vajon egy olyan munkavállaló, aki 8 órán keresztül egyfolytában dolgozik, mint egy robot, annak nem csökken a produktivitása, vagy a koncentrációja? Valószínűleg igen.

De mivel ez (félig) egy szakmai blog, megválaszolom azt is, hogy hogyan lehet a Fcebook-ot letiltani a gépünkről, anélkül, hogy százezreket kellene költenünk intelligens tűzfalakra. Elég a számítógépünk hosts fájlját szerkeszteni, ami "felülírja" a Facebook elérhetőségeit és át tudja azt irányítani egy nem létező címre. Ennek mikéntjéről itt olvashatunk:
http://cariblogger.com/2010/07/how-to-block-facebook-using-hosts-file/

1 komment

2010.06.21. 12:08 Hegedűs_Gábor

Webszűrő, Internet szűrés. Gyerekek a neten.

Címkék: gyerek felhasználóknak webszűrő internet szűrő internet szűrés

Kisgyermekes családapaként félve tekintek a fiamnál hamarosan beköszöntő Internet korszak felé. Még csak 6 éves, de mint informatikus apa, szerintem már eljött az ideje, hogy saját számítógépet kapjon. Saját számítógéppel persze együtt jár a hálózat is.

Szerintem az egyik legjobb dolog, ami azt emberiséggel történt, az az Internet. Hogy is foszthatnám meg a fiamat ettől az előnytől? Mert ugye nem sok választásunk maradt, ha a Web árnyoldalaitól is meg szeretnénk kímélni csemetéinket.

Munkám során egyre több cégnél merül fel az igény arra, hogy az Internetes tartalmakat megszűrjük egy arra alkalmas webszűrő "tűzfal" segítségével. Már régóta tudtam, hogy erre jól kidolgozott, megbízható módszerek léteznek. Azt viszont sosem gondoltam, hogy az otthoni Internet szűrés kedvéért százezres nagyságrendben fogok beállítani ilyen eszközöket.

Egy rövid kutatás után azonban azt találtam, hogy az általam legjobbak tartott, profi alkalmazásokban megtalálható Blue Coat tartalomszűrő ingyenesen hozzáférhető otthoni használatra, K9 Web Protetcion néven.
A termék az alábbi oldalról tölthető le: http://www1.k9webprotection.com/getk9/index.php

A letöltéshez nincs szükség semmilyen regisztrációra, csak az e-mail címünket kell megadni. A telepítés is pofon egyszerű, ha mindenre csak igennel válaszolunk, akkor is egy tökéletesen beállított webszűrőt kapunk. A termék 80 kategóriát azonosít, melyeket akár egyesével is beállíthatunk, ha az előre beprogramozott szűrő nem lenne megfelelő. Például az Adult/Mature Content megkülönböztethető a Sex Education kategóriától. A szűrést kiegészíthetjük saját kulcsszó listával is.

És hogy mennyire hatásos a dolog? 

  • Naponta több mint 30 milliárd weboldal-lekérdezés ellenőrzése, 54 millió felhasználónál
  • 94%-os felismerési arány
  • Dynamic Real-Time Rating (DRTR) technológia, a fel nem ismert oldalak automatikus kategorizálására.

Persze ennek ellenére nem gondolom, hogy a szűrő átjátszhatatlan, de arra szerintem tökéletes, hogy "véletlenül" ne kerülhessen webszemét gyermekünk szeme elé.

Szóljunk azért egy pár szót egyéb megoldásokról is. Ugyancsak ingyenes, és magyar kötődésű a BBP, Biztonságos Böngészés Program. Hogy miért csak kötődésű és nem fejlesztésű? Mert az oldalon sehol nem találtam erre utaló hivatkozást. A telepítendő program neve Dolphin Knight P, amely nem csak a megtekintehető weboladalakat szűri, de programkorlátozásokat, és egyéni kulcsszólistákat is tud. (A Blue Coat is tudja az utóbbit, csak limitáltabb változatban.)

A BBP úgy tűnik, hogy nagyobb tudása ellenére nem egy online, azonnal változó adatbázisból veszi a blokkolandó weblapok címeit, hanem saját adatbázisra, kulcsszógyűjteményre támaszkodik. Ez a megoldás biztosan kisebb felismerési aránnyal rendelkezik és sokkal kevésbé finomhangolható.

Szinte szóra sem érdemes a Microsoft saját szülői felügyelet webszűrője. Azért a teljesség kedvéért megemlítem, hogy az Eszközök/Internet beállítások/Tartalom/Tartalmi tanácsadó/Engedélyezés alatt lehet bekapcsolni. Bár ennek sok értelme nincs, mert alapbeállítás szerint innentől egyetlen weblapot sem tudunk többet megnézni jelszó nélkül. :)

1 komment

2010.02.09. 18:41 Hegedűs_Gábor

Ingyenes spam szűrő Exchange 2003 szerverhez, hetedik, utolsó rész, SmartIMF

Címkék: ingyenes exchange rendszergazdáknak spam szűrés smartimf

Rendszer: Windows 2003 SBS SP2, Magyar; Exchange Server 2003 SP2.

SmartIMF

A SmartIMF egyike a nagyon kevés számú ingyenes Exchange spam szűrési megoldásnak. Az alábbi URL-en letölthető program teljes funkcionalitást biztosít. 30 nap letelte után azonban indításnál egy vásárlásra buzdító képernyőt kell néznünk egy ideig. A program regisztrált változata egyébként mindössze 45 fontba kerül, érdemes megvásárolni.

A programmal meg tudjuk valósítani az IMF-ből kimaradt fehérlista funkciót és a hamar túl nagyra növekvő archív mappa méretét is kordában tudjuk tartani. Nem utolsó sorban ki tudjuk vele listázni az archív mappa tartalmát is, beletekintéssel a levelekbe és az SCL értékekbe (feltéve, ha jól állítottuk be az IMF-et).

A SmartIMF beállítása.

Futtassuk le a telepítőt, mindenre válaszoljunk "igennel" és "tovább-bal".

Indítsuk el a programot az asztalon található "SmartIMF" parancsikonnal. A képernyőn a "No archive folder selected in Tools|Options" felirat fog megjelenni. Válasszuk a Tools menü Options menüpontját. Az "Archive Folder Path"-nál tallózzuk ki a "C:\Program Files\Exchsrvr\Mailroot\vsi 1\UceArchive" útvonalat, az "Auto Message Delete: Enabled" opciót állítsuk "True"-ra, az "Auto Message Delete: Retention Age"-nél állítsunk be pl. 30 napot. Ennyi ideig maradnak a spam-ek az archív mappában, a régebbi üzenetek törlődnek. A "Whitelist: Accept User Rules" opciót állítsuk "Domain"-ra. Ez a beállítás szükséges ahhoz, hogy a fehérlistánkat megfelelően be tudjuk állítani.

Nagyon fontos, hogy ezek után, az eddig esetlegesen az archív mappában található és kilistázott üzeneteket a "Bulk Delete/All" kiválasztásával töröljük. Erre azért van szükség, mert a későbbiekben létrehozott fehérlista szabályok az összes eddigi üzeneten végigfutnak és esetleg nagyon régi és nemkívánatos üzeneteket teszünk vissza újra az e-mail forgalomba.

Ha a jobb oldalon felül a "Service Stopped" üzenet áll, akkor most már rányomhatunk erre a feliratra és rövidesen a "Service Running" fog megjelenni. A fehérlistázási és régi üzenet törlési funkció csak ebben az állapotban működik. Ettől kezdve ezzel elméletileg többet nem kell foglalkoznunk.

Az ötödik részben említettem, hogy az 5-ös SCL archíválási beállítás viszonylag sok téves riasztással fog járni. Ezen felül a bevezetőben az volt az alapfeltevésünk, hogy Magyarországról elhanyagolható mennyiségű spam érkezik. Ezek miatt most fehérlistára tesszük az összes ".hu" végződésű e-mail címet.

Válasszuk a "Tools/WhiteList Rules Editor" menüpontot. Fent, az első "Rule Name" mezőbe írjunk bármit, mondjuk azt, hogy "Magyar címek". A beírt sor maradjon kiválasztva és az alsó "Field" mezőben válasszuk ki a "From:" mezőt. A "Search Value"-ba írjuk be a következőt: ".hu". Ezek után nyomjunk az "OK" gombra.

Ezzel a beállítások végére értünk és létrehoztunk egy nagy hatékonyságú spam szűrési megoldást, mely a lehető legalacsonyabb téves azonosítási rátát is biztosítja.

Dőljünk hátra és élvezzük munkánk gyümölcsét!

Szólj hozzá!

2010.02.09. 17:39 Hegedűs_Gábor

Ingyenes spam szűrő Exchange 2003 szerverhez, hatodik rész, IMF Custom Weighting

Címkék: ingyenes exchange rendszergazdáknak spam szűrés imf custom weighting

Rendszer: Windows 2003 SBS SP2, Magyar; Exchange Server 2003 SP2.

IMF Custom Weighting

A Custom Weighting nem egy külön szűrő, hanem az Intelligent Message Filter része. Lehetőségünk nyílik az SCL értékek növelésére, maximalizálására, illetve csökkentésére bizonyos kulcsszavakkal történő egyezés esetén. Az egyezés a tárgyban, az üzenet "body"-ban, illetve a kettőben egyszerre lehet. Sajnos a feladóban nem, pedig legtöbbször ez is nagyon hasznos lenne, rengeteg üzenet érkezik "Viagra" feladóval.

Az IMF Custom Weighting beállítása.

Természetesen az előző részben ismertetett módon engedélyezni kell az Intelligent Message Filter szűrőt. Ezek után 2 dologra lesz szükségünk, egy kulcsszó listára és egy .dll regisztrálására.

A "C:\Program Files\Exchsrvr\bin\MSCFV2" útvonalon létre kell hoznunk egy MSExchange.UceContentFilter.xml rögzített formátumú fájlt. Nagyon fontos, hogy a fájlnak "unicode" kódolásúnak kell lennie, más kódolás esetén nem fog működni.

Ezek után a parancssorban a regsvr32 "C:\Program Files\Exchsrvr\bin\MSCFV2\MSExchange.UceContentFilter.dll" parancsot kell kiadnunk.

A .dll regisztrálása után indítsuk újra az SMTP szolgáltatást.

A fő kérdés az, hogy honnan kerítünk egy használható kulcsszó listát. Ilyet nekem nem sikerült találni, csak egy, az Outlook levélszemét szűrőjéhez készített változatot, melyet a saját ötleteimmel kiegészítve adaptáltam az IMF Custom Weighting-hez. Az alábbiakban itt most ezt publikálom, természetesen semmiféle garanciát nem tudok rá vállalni, mindenki saját felelősségére használja. Emlékezzünk rá, hogy "unicode" formátumban mentsük:
<?xml version="1.0" encoding="UTF-16"?>
<CustomWeightEntries xmlns="http://schemas.microsoft.com/2005/CustomWeight">
     <CustomWeightEntry Type="BOTH" Change="MAX" Text="Special offer"/>
     <CustomWeightEntry Type="BOTH" Change="MAX" Text="Gratis piller"/>
     <CustomWeightEntry Type="BOTH" Change="MAX" Text="Free Pills"/>
     <CustomWeightEntry Type="BOTH" Change="MAX" Text="Viagra"/>
     <CustomWeightEntry Type="BOTH" Change="MAX" Text="pfizer"/>
     <CustomWeightEntry Type="BOTH" Change="MAX" Text="eCard"/>
     <CustomWeightEntry Type="BOTH" Change="MAX" Text="cialis"/>
     <CustomWeightEntry Type="BOTH" Change="3" Text="over 21"/>
     <CustomWeightEntry Type="BOTH" Change="3" Text="over 18"/>
     <CustomWeightEntry Type="BOTH" Change="3" Text="adults only"/>
     <CustomWeightEntry Type="BOTH" Change="3" Text="pharmacy"/>
     <CustomWeightEntry Type="BOTH" Change="3" Text="casino"/>
     <CustomWeightEntry Type="BOTH" Change="3" Text="replica"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="money back"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="cards accepted"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="removal instructions"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="extra income"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="Dear friend"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="for free?"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="for free!"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="SPECIAL PROMOTION"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="order today"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="order now!"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="money-back guarantee"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="100% satisfied"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="adult web"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="must be 21"/>
     <CustomWeightEntry Type="BODY" Change="3" Text=" xxx "/>
     <CustomWeightEntry Type="BODY" Change="3" Text=" xxx!"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="subscribe"/>
     <CustomWeightEntry Type="BODY" Change="3" Text="unsubscribe"/>
     <CustomWeightEntry Type="SUBJECT" Change="3" Text="watches"/>
     <CustomWeightEntry Type="SUBJECT" Change="3" Text="advertisement"/>
     <CustomWeightEntry Type="SUBJECT" Change="3" Text=" xxx"/>
     <CustomWeightEntry Type="SUBJECT" Change="3" Text="adult"/>
     <CustomWeightEntry Type="SUBJECT" Change="3" Text="be 18"/>
     <CustomWeightEntry Type="SUBJECT" Change="3" Text="18+"/>
     <CustomWeightEntry Type="SUBJECT" Change="3" Text="erotic"/>
     <CustomWeightEntry Type="SUBJECT" Change="3" Text="sex"/>
     <CustomWeightEntry Type="SUBJECT" Change="3" Text="$$"/>
     <CustomWeightEntry Type="SUBJECT" Change="2" Text="diploma"/>
     <CustomWeightEntry Type="SUBJECT" Change="2" Text="degree"/>
</CustomWeightEntries>

A fenti példából jól látható a fájl szerkezete, tetszőlegesen hozzáadhatunk újabb sorokat.

A működés ellenőrzése.

Küldjünk a szerverünk által kezelt egyik e-mail címre egy levelet, melynek a tárgyában szerepel a "viagra" szó. (Bármilyen meglepő, az IMF alapértelmezésben nem "köpi ki" magától a "viagra" szót tartalmazó üzeneteket.)

A Message Tracking Centerben ellenőrizhetjük, hogy mi történt a levéllel. Ha minden rendben, az IMF kiszűri a levelet. Persze megnézhetjük közvetlenül az IMF archívumban is, vagy a SmartIMF program segítségével is.

A következő, egyben utolsó részben a SmartIMF programról lesz szó.

Szólj hozzá!

2010.02.08. 17:49 Hegedűs_Gábor

Ingyenes spam szűrő Exchange 2003 szerverhez, ötödik rész, Intelligent Message Filter

Címkék: ingyenes exchange rendszergazdáknak spam szűrés intelligent message filter

Rendszer: Windows 2003 SBS SP2, Magyar; Exchange Server 2003 SP2.

Intelligent Message Filter

Az IMF az Exchange 2003 szerver legjobban dokumentált spam szűrési megoldása. "Az Intelligent Message Filter szűrő heurisztikus elven működik, minden üzenetet elemez, hogy megállapítsa, melyik kéretlen levél. Ezt követően spamvalószínűségi szintet (spam confidence level, SCL) rendel a levelekhez, amelynek alapján az Exchange Server vagy az Outlook eldöntheti, hogy a kéretlen levelek mappájába kézbesítse-e az adott üzenetet."

Az Intelligent Message Filter beállítása.

Global Settings/Message Delivery/Properties/Intelligent Message Filter.
(Ne felejtsük el a Servers/Sajátszerverünk/Protocols/SMTP/Saját SMTP Virtual Server/Properties/Advanced/Edit alatt engedélyezni az IMF-et)

Minél nagyobb egy üzenet SCL értéke, annál valószínűbb, hogy SPAM. Megfigyelésem szerint a 8-as értékű üzenet majdnem 100% biztonsággal kéretlen levél, az 5-ös szinten viszont már az összes hírlevél szűrésre kerül és egyes legitim, főleg rövid, pár szavas levelek is a "kukába" kerülnek. Ha nem akarunk kockázatot vállalni, ne állítsuk a szűrőt 7-es alá.

A Gateway Blocking Configuration-nél azt állítjuk be, hogy szerver szinten milyen SCL értékű levelek kerüljenek archívumba, vagy azonnali elutasításra. A Store Junk E-mail Configuration-nél az kerül beállításra, hogy milyen SCL értéktől kezdődően továbbítsa az Exchange szerver a felhasználó levélszemét mappájába a gyanús leveleket. Ha például az első értéket 7-re állítjuk, és a másodikat 5-re, akkor a 7,8,9 értékű levelek az archívumba mennek, az 5,6 értékű levelek pedig a felhasználó levélszemét mappájába. Ez így egy teljesen biztonságos beállítás, nyugodtan ajánlható bárkinek.

Persze, mi nem a biztonságos megoldást választjuk, mert az nem elég hatékony a kéretlen levelekel szemben. Állítsuk mindkét értéket 5-re és a "When blocking messages"-t "Archive"-ra. Ezzel az összes gyanús levél a  "C:\Program Files\Exchsrvr\Mailroot\vsi 1\UceArchive\" mappába kerül, .eml kiterjesztéssel, melyek Outlook Express segítségével megtekinthetők. Hogy miként fogjuk a "jó" leveleket mégis fehérlistázni? Főleg anélkül, hogy erre az Exchange beépített lehetőséget biztosítana? Erre majd a hetedik részben fogunk kitérni, a SmartIMF program használatának bemutatásánál.

Az Intelligent Message Filter az egyetlen szűrő, ahol nem elég az előbb említett helyen elvégezni a beállítást, 2 registry módosítást is véghez kell vinnünk.

Az első registry módosítás ahhoz kell, hogy az IMF automatikus frissítéseket kapjon a Windows Update-en keresztül. Hogy miért nem ez az alapértelmezés? Ki tudja...
A HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange helyen hozzunk létre egy új "duplaszó" értéket, ContentFilterState néven. Értékként vegyünk fel 1-et.

A második registry módosítás ahhoz szükséges, hogy az archivált üzenetekbe az SCL érték is elmentődjön, ez a további analízishez jöhet jól.
A HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange helyen hozzunk létre egy új kulcsot, ContentFilter néven: Ezen belül hozzunk létre egy új "duplaszót", ArchiveSCL néven, 1-es értékkel. A Contentfilter kulcs alatt további beállításokat eszközölhetünk, de ezekre most nem térek ki (ArchiveDir, CheckAuthSessions)

A registry módosítások után indítsuk újra az SMTP szolgáltatást.

A beállítás után futassuk a Windows Update-et is!

A működés ellenőrzése.

A fent említett "C:\Program Files\Exchsrvr\Mailroot\vsi 1\UceArchive\" mappában tekinthetők meg az üzenetek, melyeket a hetedik részben ismertetett SmartIMF segítségével kezelhetünk. Lehetőség van a Connection Filetringnél bemutatott számlálók hozzáadására is ("MSExchange Intelligent Message Filter").

A következő részben maradunk továbbra is az IMF-nél, hozzáadjuk a saját kulcsszó listánkat, mellyel még több kéretlen levelet szűrhetünk ki. 

Szólj hozzá!

2010.01.16. 17:09 Hegedűs_Gábor

Ingyenes spam szűrő Exchange 2003 szerverhez, negyedik rész, Recipient Filtering

Címkék: ingyenes exchange rendszergazdáknak spam szűrés recipient filtering

Rendszer: Windows 2003 SBS SP2, Magyar; Exchange Server 2003 SP2.

Recipient Filtering

Hát erről elég nagyképű egy egész bejegyzést írni. :) A lényeg annyi, hogy kiszűrjűk azokat a címzetteket, akik nincsenek az Active Directory-ban. Ezt az alábbi beállításokkal tehetjük meg.

A Recipient Filtering beállítása.

Global Settings/Message Delivery/Properties/Recipient Filtering.
(Ne felejtsük el a Servers/Sajátszerverünk/Protocols/SMTP/Saját SMTP Virtual Server/Properties/Advanced/Edit alatt engedélyezni a Recipient Filteringet)

A következő részben érdekesebb téma következik, az Intelligent Message Filter.

Szólj hozzá!

2010.01.16. 16:34 Hegedűs_Gábor

Ingyenes spam szűrő Exchange 2003 szerverhez, harmadik rész, Connection Filtering

Címkék: ingyenes exchange rendszergazdáknak spam szűrés connection filtering

Rendszer: Windows 2003 SBS SP2, Magyar; Exchange Server 2003 SP2.

Connection Filtering

A Connection Filetring az ingyenesen hozzáférhető RBL (Real Time Block List) listákat használja. Ezek a listák a spamküldő zombi gépek és mail szerverek IP címeit tartalmazzák. Sajnos ingyenességük mellett elég magbízhatatlanok, sok téves találatot adnak. Tapasztalataim szerint Magyarországon a "safe.dnsbl.sorbs.net" és az "sbl-xbl.spamhaus.org" (nem a zen.spamhaus.org) feketelisták a legjobban használhatók. A sorbs.net több spamet talál meg, de a tévesen azonosított levelek száma is magasabb. A spamhaus a legmegbízhatóbb RBL lista. Más RBL szolgáltatókkal csak saját felelősségre próbálkozzunk.

A Connection Filtering beállítása.

Global Settings/Message Delivery/Properties/Connection Filtering.
(Ne felejtsük el a Servers/Sajátszerverünk/Protocols/SMTP/Saját SMTP Virtual Server/Properties/Advanced/Edit alatt engedélyezni a Connection Filteringet)

Az "Add..." gomb segítségével adhatjuk hozzá a fent említett feketelistákat. Mivel relatíve sok téves riasztásra számíthatunk, ezért a Microsoft lehetőséget biztosított kivételek felvételére is (nem úgy, mint a sender filetringben). Ezeket a címeket az "Exception..." gomb segítségével tudjuk felvenni. Itt erősen ajánlott az az összes Magyar címmel érkező levél  (.hu) és az ingyenes levelezési szolgáltatók címeinek hozzáadása. Ezekkel viszonylag kis mennyiségű kéretlen levelet fogunk átengedni, az első esetben azért, mert szerencsére még ritka a Magyar spam, az utóbbiaknál pedig a jól beállított küldő szerverek (pl. SPF rekord) biztosítják az alacsony spam rátát.

(A "citromail.hu" és a "freemail.hu" ki is maradhatott volna, hiszen a .hu ezeket is lefedi)
Ha valakinek több ingyenes levelezési szolgáltató jut eszébe, nyugodtan adja hozzá azokat is. Sőt, ha külföldi partnerekkel van a cégünknek üzleti kapcsolata, akkor ezeket a domain-eket is érdemes felvenni.

A működés ellenőrzése.

Exchange 2003 esetén elég nehéz nyomon követni a Connection Filtering működését. Egyetlen lehetőségünk van, a "Futtatás"-ban a perfmon.msc-t indítva a MSExchangeTransport Filter Sink objektumot kell felvenni. Az alábbi számlálók mutatják a szűrő működését.

A következő bejegyzésben a Recipient Filtering-ről lesz szó.

Szólj hozzá!

2009.12.03. 20:34 Hegedűs_Gábor

Ingyenes spam szűrő Exchange 2003 szerverhez, második rész, Sender Filtering

Címkék: ingyenes exchange rendszergazdáknak spam szűrés sender filtering

Rendszer: Windows 2003 SBS SP2, Magyar; Exchange Server 2003 SP2.

Sender Filtering

A spammerek egyik kedvenc taktikája, hogy olyan üzeneteket küldenek, ahol a feladó címében a saját levelezési domain-ünk szerepel. Így például elkerülik az Intelligent Message Filter-t is, amely tévesen megbízhatónak tekinti az összes saját domain-ről érkező üzenetet.

Sokáig gondolkodtam rajta, hogy milyen mellékhatásokkal kell számolnom akkor, ha a Sender Filteringbe beleteszem a saját domain-ről érkező leveleket. Természetesen a saját hálózaton belüli levelezést nem akadályozza, és elég ritkán fordul elő az is, hogy az Internetről saját domain-ről érkező legitim levelet kapjunk. Bár ez utóbbival vigyázni kell. Előfordulhat, hogy valaki pl. otthonról egy olyan SMTP fiókkal küld üzeneteket, amelynél a feladó címe a mi domain-ünket tartalmazza. Ebben az esetben erre a címre külön figyelmet kell szentelnünk.

A Sender Filtering beállítása I.

Az alábbi ábra mutatja, hogyan kell beállítani a szűrést abban az esetben, ha nincs "külsős" SMTP fiókunk.

Global Settings/Message Delivery/Properties/Sender Filtering.
(Ne felejtsük el a Servers/Sajátszerverünk/Protocols/SMTP/Saját SMTP Virtual Server/Properties/Advanced/Edit alatt engedélyezni a Sender Filteringet)

Így kiszűrjük az összes saját domain névvel érkező üzenetet. Az alsó kapcsolók tetszőlegesen választhatók, bár a "Filter messages with blank sender", vagyis az "üres" feladóval érkező levelek szűrését érdemes bekapcsolni.

A Sender Filtering beállítása II.

Sokkal érdekesebb a helyzet, ha egyes címeket ki kell hagynunk a szűrésből. Sajnos a Sender Filtering esetében nincs whitelist funkció, így elég sokat kell gépelnünk.

Tegyük fel, hogy az it@mydomain.hu címet kell kihagynunk. Ebben az esetben nem tudjuk a "*@mydomain.hu" szűrőt felvenni, helyette a következőket kell egyesével begépelnünk:

.*@mydomain.hu
-*@mydomain.hu
_*@mydomain.hu
a*@mydomain.hu
b*@mydomain.hu
c*@mydomain.hu
d*@mydomain.hu
...
i.*@mydomain.hu
i-*@mydomain.hu
i_*@mydomain.hu
ia*@mydomain.hu
ib*@mydomain.hu
ic*@mydomain.hu
...
is*@mydomain.hu
iu*@mydomain.hu (itt hagytuk ki az it@mydomain.hu címet)
iv*@mydomain.hu
...
j*@mydomain.hu
k*@mydomain.hu
l*@mydomain.hu
...
x*@mydomain.hu
y*@mydomain.hu
z*@mydomain.hu

Érdekes mellékhatásai is lehetnek a feladó szűrésnek, melyekre először biztos nem gondolunk. Például a PHP sendmail funkciója elszállhat, és az eddig működő weblapunk hibaüzenet dobhat, ha a php.ini-ben megadott e-mail cím letiltásra kerül a Sender Filtering szűrővel.

A működés ellenőrzése.

Legegyszerűbb módszer, ha az "Archive filtered messages" kapcsolót kipipáljuk, a "C:\Program Files\Exchsrvr\Mailroot\vsi 1\Filter\" könyvtárban .tmp kiterjesztéssel megjelennek a kiszűrt levelek. Ezeket a jegyzettömbbel tudjuk elolvasni, illetve .eml-re átnevezve Outlook Express-el is megnézhetjük.

A következő részben az RBL szűréssel foglalkozunk.

Szólj hozzá!

2009.11.10. 20:08 Hegedűs_Gábor

Ingyenes spam szűrő Exchange 2003 szerverhez, első rész

Címkék: ingyenes exchange rendszergazdáknak spam szűrés

Rendszer: Windows 2003 SBS SP2, Magyar; Exchange Server 2003 SP2.

Exchange 2003 spam szűrési stratégiák.

A spam szűrés ma már egyre fontosabb szerepet tölt be az életünkben. Az biztos, hogy mindenképp foglalkoznunk kell vele, azt viszont már nehezebb eldönteni, hogy milyen védekezési módszert válasszunk. Az egész spam szűrést kihelyezhetjük, megszabadulva az összes gondtól, vagy telepíthetünk spam szűrő szoftvereket, és próbálkozhatunk ingyenes, saját fejlesztésű módszerekkel is. Ez a cikk ez utóbbira mutat be egy alternatívát.

Az Exchange 2003 szerverben sok olyan funkció található, amellyel hatásosan küzdhetünk a kéretlen levelek ellen, bár ezek elég kezdetleges módon vannak megvalósítva, illetve nem erre célra készültek. Az ingyenes szoftverek száma pedig konvergál a nullához. Összesen 3 darab ilyen szoftvert találtam, az első az IMFcompanion, a második a SmartIMF, és a harmadik az ORFilter. Az első kettő a beépített Intelligent Message Filtert egészíti ki whitelist és egyéb funkciókkal, az utóbbi teljes spamszűrési megoldást kínál. Az IMFCompanion fejlesztését régen abbahagyták, ezért nem nagyon bíztam benne és voltak is működési problémák. A SmartIMF jól működik, később még bővebben szólok róla, hiszen része az ingyenes spam szűrési megoldásomnak. Az ORFilter fejlesztése is abbamaradt, ezért sajnos egyes funkciók már nem jól működnek benne (pl. spam-ek postafiókba irányítása, loggolás, kivételek kezelése), de ennek ellenére nagyon jó szűrési arányt tud felmutatni, és szinte az összes általam is felsorolt módszert egyesíti magában.

A rendszer átfogó bemutatása.

Fontos az elején megemlíteni, hogy a közölt módszerek magyarországi viszonyokra lettek "kifejlesztve", figyelembe véve azt a sajátosságot, hogy szerencsére egyelőre a spam-ek elenyésző hányada származik Magyarországról. A rendszer egyszerveres környezetben működik, más felépítés esetén nem várt következményekkel kell számolnunk.

A módszerrel megvalósított spam szűrési ráta tapasztalataim szerint 95%+, a téves találatok aránya 1%-.

Akkor tehát a védelem szintjei, az egyes filterek (nem működési sorrendben):

  • Sender Filtering. Kiszűrjük azokat, akik hamisított feladóval, a saját domain-ünket használva küldenek spam-et.
  • Connection Filtering. Az ingyenesen hozzáférhető Real Time DNS Blocklist-eket használjuk a kéretlen levelek számának csökkentésére.
  • Recipient Filtering: Kiszűrjük a nem valós címre érkező leveleket.
  • Intelligent Message Filter: Tovább szűrjük a leveleket a beépített tartalomelemző segítségével. Erős szűrést alkalmazunk, később whitelistelünk.
  • IMF Custom Weighting: Finomítjuk az IMF szűrőt, saját kulcsszó gyűjtemény használatával.
  • SmartIMF: whitelist segítségével "visszatesszük" a hibásan azonosított leveleket a normál e-mail forgalomba.

A következő részben a Sender Filteringről lesz szó.

Szólj hozzá!

2009.10.23. 19:21 Hegedűs_Gábor

Laptop melegszik

Címkék: laptop melegszik felhasználóknak rendszergazdáknak

Igaz, ennek a bejegyzésnek nyáron kellett volna születnie, de jobb később, mint soha.

Biztos már sokakkal előfordult, hogy nem tudták megmagyarázni, az eddig tökéletesen működő laptop miért kezdett el melegedni. Kitisztítgatták, ki is porszívózták és utána aggódva figyelték a CPU hőmérséklet folyamatos emelkedését.

Pedig a megoldás egyszerű. Az alábbi képen ugyan nem látszik a kosz, pedig ott van.

Sajnos nem elég a ventillátort kiszerelés nélkül kiporszívózni, akkor sem, ha máshol nem látunk koszt. Az alábbi képen jól látható, hogy a ventillátort kivéve, a levegő beömlő nyíláson vastag "porszivacs" található. Ezt eltávolítva a hőmérséklet drasztikusan csökkenni fog.

1 komment

2009.09.22. 19:22 Hegedűs_Gábor

Startup script Group Policy-ból, Login Script adminisztrátori jogokkal, korlátozott felhasználók esetében

Címkék: rendszergazdáknak startup script logon script login script startup szkript logon szkript login szkript

Megjegyzés: Javított verzió! Csak erős idegzetűeknek! :)

Rendszer: Szerver: Windows 2003 SP2, Angol. Kliensek: XP Professional SP3, Magyar

Probléma: Szerettem volna egy olyan login script-et írni, ami az összes problémámat megoldja, belenyúl a registry-be, fájlokat másol, ini fájlokat állít be. Kényelmes rendszergazdák, akik csak rendszergazdai jogosultsággal rendelkező felhasználókkal dolgoznak, rögtön rávágják, hogy szépen tegyek bele mindent a C:\windows\sysvol\domain\scripts\login.bat-ba és a domain felhasználó beállításainál rendeljem hozzá ezt a login szkriptet. Ez tökéletesen működik mindaddig, amíg nem korlátozott felhasználókról van szó.

Viszont korlátozott felhasználóknál rögtön gond van. Nem tudnak a registry-be írni, nem másolhatnak fájlokat bárhová, stb.

Egy kicsit körülnéztem a "piacon" és találtam egy-két bíztató kiinduló pontot. Az Group Policy-n keresztül elérhető, un. startup szkript ígéretesnek nézett ki, mivel local system jogosultságokkal fut. Aztán hamar rájöttem, hogy startup szkript csak számítógépekhez rendelhető, mivel még azelőtt lefut, mielőtt a felhasználó bejelentkezne. Így nem tudom az (leendő) aktuális felhasználó profilját elérni, a szkriptben a %userprofile% típusú változók értelmetlenné válnak.

Akkor viszont mit lehet tenni? A gépspecifikus feladatokat már kivettem, de még mindig több jogosultságra van szükségem, mint a bejelentkezett felhasználónak. Első gondolatom a "runas" volt. De hamar rájöttem, hogy biztonsági okokból, "by design" a runas jelszóval SEHOGY nem paraméterezhető. Van ugyan egy kis huncutság, kerülő megoldás, de nem túl szép. Helyette maradt a psexec, ami elsősorban távoli eljáráshívásra lett kitalálva, de gyönyörűen lehet lokálisan is használni és password-el is paraméterezhető.

Kérdés annyi maradt, hogy milyen felhasználói fiókot használjak a szkript futtatásához. Először a helyi számítógép rendszergazdai fiókjára gondoltam, de ez sajnos nem volt megfelelő, hiszen a hálózaton megosztott erőforrásokat, hálózati mappákat ezzel a fiókkal nem lehet elérni. A Domain rendszergazdai fiók szóba sem került, mert ugyan a felhasználók nem képzett hacker-ek, de azért paraméterként mégsem célszerű ezt a jelszót használni. Két megoldás merült fel: 1., mégis lokál rendszergazda és net use paranccsal elérni a hálózati meghajtót. 2., létrehozni egy új biztonsági csoportot, ami a megfelelő megosztásokat éri csak el és ezt a csoportot hozzáadni a klienseken a rendszergazdákhoz. A másodikat választottam, mivel így nem kellett változtatnom a már megírt szkriptjeim UNC útvonalain.

A megoldás már körvonalazódott. GPO-s startup script a registry változtatásokra, a felhasználóknak tiltott mappák elérésére. GPO-s logon script, rendszergazdai jogokkal, a korlátozott felhasználó által végre nem hajtható, fiókokhoz kötött műveletekre.   

Következzen hát részletesen is, mert elég sok buktatója van a dolognak.

1. Először létrehozunk egy biztonsági csoportot (pl. scriptgroup) és egy domain felhasználót (pl. script), aki ennek a csoportnak a tagja. Létrehozunk egy megosztott mappát, benne a logon szkripttel. A mappára olvasási jogot adunk a "scriptgroup" biztonsági csoportnak.

2. A felhasználót hozzáadjuk a kliensek "Rendszergazdák" csoportjához Group Policy segítségével. Itt nagyot bukhatunk, mert ha nem jól csináljuk, könnyen kitörölhetünk mindenkit a rendszergazdák közül, kivéve az előbb létrehozott biztonsági csoportot. Szóval, vegyünk egy megfelelő group policy-t, kisebb cégeknél akár a "Default Domain Policy"-t. Nyissuk ki a "Computer Configuration\Windows Settings\Security Settings" ágat és jobb egérrel kattintsunk a "Restricted Groups"-ra. Válasszuk az "Add group" menüpontot. Itt adjuk hozzá a "scriptgroup" biztonsági csoportunkat. Az utána megjelenő képernyőn a "This group is a member of:" melletti "Add" gombot használjuk.

 

 

 

 

 

Itt írjuk be azt, hogy "Rendszergazdák". Ugyanis ezzel a beállítással a kliensek lokális "Rendszergazdák" csoportjához hozzáadódik a mi "scriptgroup" csoportunk. A felső gomb használatával lecseréltük volna a "Rendszergazdák" csoport bejegyzéseit.

 

 


3.
A stratup script futattásához is létre kell hoznunk egy group policy bejegyzést. Ennek leírását itt találhatjuk. Egy kérdés merül csak fel, melyik GPO-t használjuk, mivel az AD-ban alapértlemezett "Computers" csoporthoz nem lehet ilyet hozzáadni. Itt eljárhatunk a hivatkozásban bemutatott, külön létrehozott OU segítségével, vagy akár létrehozhatunk a "Default Domain Policy" mellé egy teljes domain-re érvényes "Default Domain Computers Policy"-t is. Fontos, hogy figyeljünk arra, hogy a policy security beállításainál hozzáadjuk a "Domain Computers" csoportot, read és apply jogokkal.

Nagyon fontos, hogy a hivatkozásban is ismertetett módon elvegyük az "Authenticated Users" csoporttól a "Read" és az "Apply Group Policy" jogokat. Ez azért szükséges, hogy a felhasználók a munkaállomásokról ne tudják elolvasni a szkriptet és az átadott paramétereket se tudják kitallózni a \\szerver\sysVOL\domain\Policies\xxx\Machine\Scripts\scripts.ini helyről (thx to Blaise(R)).

Fontos az is, hogy a startup szkript alapértelmezetten felkínált helyén NE változtassunk, ne legyen pl. UNC útvonalon, mert így nekem sehogy sem akart működni.

Szóval nálam a startup szkript így néz ki:

A "jelszo" nálam paraméterként lett átadva, de ez lényegében mindegy. Szerepelhetett volna magában a szkriptben is. Ha jól beállítottuk a GPO jogosultságait, akkor a felhasználók nem fogják tudni elolvasni a jelszót. 

A szkript végén látható egy átirányítás, ami az amúgy láthatatlan kimenetet menti el mégis láthatóan egy "log.txt" nevű fájlba. A végén szereplő "2>&1" miatt a normál és a hiba kimenet is átirányítódik.

Maga a startup szkript tartalmaz a külső leírásban is szereplő "NET USER rendszergazda %1" parancsot is, ami a lokális rendszergazda jelszavát módosítja az átadott paraméter szerint. Persze az én startup szkriptem fő feladata nem ez volt, hanem pl. registry módosítások, de ezeket most nem részletezem.

Nagyon fontos feladat volt viszont, hogy  a később a logon szkript által használt psexec.exe fájlt a kliensekre másoljam, így a startup szkriptnek tartalmaznia kell a következőt: IF NOT EXIST %windir%\psexec.exe copy \\fs\script\pstools\psexec.exe %windir%

Másik fontos feladat, hogy a később lefutó logon szkript részére "lerakjuk" a jelszót egy biztonságos helyre. Hogy miért nem tudjuk itt is átadott paraméterként, vagy a szkriptben magában megadni a jelszót? Mert a logon szkript esetében nem tudjuk elvenni a felhasználóktól "Read" és az "Apply Group Policy" jogokat.
Tehát a startup(!) szkriptünknek kell egy ilyen sort is tartalmaznia: "echo jelszo >c:\dpsys\temp.tmp". Ez a "jelszo"-t beleírja a "c:\dpsys\temp.tmp" fájlba. A "dpsys" könyvtár jogosultságait módosítsuk úgy, hogy csak a "scriptgroup" felhasználói csoport tudja olvasni és írni, a hétköznapi felhasználóknak ne legyen semmilyen joga. (Ezt akár innen, a startup szkriptből is meg tudjuk tenni, de ezt most nem részletezem.)

4. Jöhet a logon szkript. Itt merül fel a kérdés, hogy miért a GPO-s logon szkript? Miért nem a "profile" login script? Azért, mert a GPO logon szkript kimenete nem látható.
Szóval a kiválasztott OU-n szerkesszük a GPO-t. Nyissuk ki a "User Configuration\Windows Settings\Scripts" ágat. Kattintsunk duplán a "Logon" feliratra.
A logon szkript nálam így néz ki:

Mint látható, a logon szkriptben már nyugodtan lehet UNC útvonalat használni.

A logon szkript feladata, hogy beolvassa a startup szkript által elhelyezett jelszót és ennek segítségével, "script" (rendszergazda) felhasználó jogosultságaival futtassa a tényleges logon szkript batch file-t.

Több módszer is létezik, amivel a "c:\dpsys\temp.tmp"-ből ki tudjuk olvasni a jelszót. Egyik módszer szerint, vázlatosan: 

  • "1.tmp" fájlban ez szerepel: "psexec.exe -u dp\script -p " (Itt vége a fájlnak, nincs Enter(!), viszont van egy szóköz a végén)
  • "2.tmp" fájlban: "-accepteula cmd.exe /c c:\dpsys\real_logon.bat %1 >>c:\dpsys\log.txt 2>&1"
  • "real_logon.bat" fájlban: A tényleges logon szkript parancsai.


A "logoncc.bat": 

rem A parancs kezdő részének átmeneti parancsfájlba másolása:
copy 1.tmp temp.bat
rem Jelszó hozzáfűzése:
type c:\dpsys\temp.tmp >>temp.bat
rem A parancs második részének hozzáfűzése:
type c:\dpsys\2.tmp >>temp.bat
rem A kész parancsfájl meghívása:
call temp.bat %1
rem A feleslegessé vált parancsfájl törlése:
del temp.bat

A psexec.exe segítségével érjük el, hogy a logon szkript (real_logon.bat) a "scriptgroup" csoport, "script" felhasználójával fusson le, akinek lokális rendszergazdai jogai vannak és eléri a szerveren lévő megosztást is. A "temp.bat" a végén ezt a parancsot futtatja:
psexec.exe -u dp\script -p jelszo -accepteula cmd.exe /c c:\dpsys\real_logon.bat %1 >>c:\dpsys\log.txt 2>&1
A "dp\script" a domain "script" nevű felhasználója. A "jelszo" itt a startup szkript által "lepakolt" jelszó. A végén a kimenet itt is átirányításra kerül.   
Itt viszont már elég sok a buktató. Az "-accepteula" kapcsoló nélkül nem fut a dolog, mert a psexec láthatatlan felugró ablakokat dobál, a licensz elfogadására. A "cmd.exe /c" nélkül nem mindig fut, ha pl. UNC útvonalat használunk a real_logon.bat-hoz. A "%userprofile%" pedig azért kerül paraméterként átadásra, mert ha más felhasználói fiók alatt futtatjuk a scriptet, akkor a szkripten belül használt %userprofile% változó nem az eredeti felhasználó fiókjára fog mutatni, hanem a "script" felhasználó fiókjára. Így viszont még elmenthetjük az "eredeti" profil útvonalát.
A %userprofile% nem véletlenül van zárójelek között, enélkül ugyanis nem 1 darab paraméterként mennének át a szóközt is tartalmazó útvonalak. Még egy buktató lehet a magában a .bat fájlban is. Ha az átadott paraméterre %1-el hivatkozunk, akkor az nyitó és záró zárójeleket is tartalmazni fog. Egy kis trükkel elhagyhatjuk ezeket a zárójeleket, mégpedig a %~1 hivatkozás használatával.

3 komment

2009.08.24. 18:06 Hegedűs_Gábor

A ... kötet árnyékmásolatát nem lehetett létrehozni, mert nem sikerült kialakítani az ehhez szükséges struktúrákat a lemezen. VolSnap Event ID: 28

Címkék: rendszergazdáknak eseményazonosító 28 árnyékmásolat event id 28 shadow copy

Rendszer: Windows 2003 SBS SP2, Magyar.

Jelenség: Az eddig működő árnyékmásolatot nem lehet bekapcsolni az adott meghajtón, hibaüzenettel elszáll. (Tipikusan az ugyanazon a lemezen működő másik partición semmi probléma nem jelentkezik.) Az eseménynaplóban 28-as eseményazonosítójú Volsnap hiba található, a címben szereplő szöveggel.

Gyorsan ideírom angolul is, mivel nekem mindig problémát jelent a hibaüzenetek korrekt fordítása (angolul mindig sokkal több a találat): "The shadow copy of volume X: could not be created due to a failure in creating the necessary on disk structures."

Természetesen a Google rengeteg találatot hoz a problémával kapcsolatban, van itt SP2 előtti (nem működő) hotfix, meg a legkülönbözőbb külső gyártótól származó szoftverek feltételezett hibája, stb. Ami nagyjából közös, hogy mindig egyik napról a másikra "elromlik" az árnyékmásolat. Ez azért szomorú, mert nélküle nem működnek az NTBackup-os mentések és a ráépülő külső szoftverek sem.

Én végigpróbáltam az összes fellelhető megoldást, de semmi sem segített. Bár egy-két érdekes paranccsal így is sikerült megismerkednem. Akit érdekel, keressen a "vssadmin list writers", "vssadmin list providers" háza táján, vagy általában véve a vssadmin segédprogrammal kapcsolatban, hátha az ezekhez kapcsolódó megoldások fognak bejönni.

A vége felé az a megérzésem támadt, hogy a problémának valamilyen árnyékmásolatokhoz kötődő méretkorlátozáshoz lehet köze, de a meghajtó tulajdonságai között hiába állítottam a felső korlátot, nem történt javulás. A felhasznált lemezterületeket a "vssadmin list shadowstorage" parancs segítségével lehet megjeleníteni, ebből a lefoglalt hely és a felső korlát a grafikus kezelőfelületen is leolvasható.

 

 

 

 

 

 

 

 

 


Delete all old shadow copies.

 

 

 

 

  

Miután semmi sem segített, utolsó kísérletként fogtam és letöröltem a problémás meghajtó összes régi árnyékmásolatát. Így a tárolásra felhasznált hely nullára csökkent és láss csodát, az árnyékmásolatok minden gond nélkül elindultak. Persze, arra kíváncsi leszek, hogy ez így meddig fog működni.

Szólj hozzá!

süti beállítások módosítása