December óta új munkahelyen dolgozom, de ez még az előző helyen volt, ott az ugyfelek döntő többségénel Windows Server 2003 / 2008 Small Busness Server-t üzemeltettünk Trend Micro Worry Free Business Server 3.6, 5.1, vagy 6.0 antivírussal. Az egy dolog, hogy az elmult két évben egyetlenegy alkalom sem volt mikor sikeres vírusirtásról szamolt volna be a rendszer, de ez már a sokadik eset volt, hogy kiverte a biztosítékot valami miatt.
Kicsit részletesebben a környezetről:
Két szerver, az egyiken Windows Server 2003 SBS Premium, naprakészre patchelve, SBS jó szokas szerint egy vason az ISA 2004 SP3 (Microsoft Best Practice szerint külön szerverre kéne rakni), Exchange 2003 SP2 (Microsoft Best Practice szerint nem ajánlott tartományvezérlőre telepíteni 
), WSUS, és Trend Micro Worry Free Business Security Server 5.1
A másik egy sima Windows Server 2008 tartománytag, semmi különös funkcióval, egy külső gyártó programja fut rajta, ebből a szempontbol nem sok vizet zavar.
Kb. 20 kliens, XP SP3, Trend Micro klienssel, hogy megfelelő legyen a vírusvédelem.
A hiba:
Monitoring rendszerünk az elmult napokban kiabált, hogy a Secutity event log (biztonsági esemenynapló) tele van sikertelen bejelentkezési kísérlettel, naponta ugy 5-600 darab. A log nagyon informatív volt Event ID 537, íme egy példa:
Logon Failure:
Reason: An error occurred during logon
User Name:
Domain:
Logon Type: 3
Logon Process: Xå�
Authentication Package: NTLM
Workstation Name:
Status code: 0x80090308
Substatus code: 0x0
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: -
Source Port: -
A logon process pedig teljesen véletlenszerű mókásabbnál mókásabb karaktereket tartalmazott. Ebből ugyebár csak a status code és az Event ID ami használható valamire, így ezek mentén indultam el.
Az eventid.net-en elég jo tippeket szoktak adni az emberek, most is volt jópar megoldásnak látszó dolog, de sajna egyik se volt érvenyes a környezetre.
[link]
Tovább kutakodtam az event id alapján, így találtam a következő Microsoft oldalt: [link] . Ez már eléggé ígéretesnek tűnt, a registrybe be is pakoltam a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa alá a DisableLoopbackChecket, szerver újraindítás után még mindig ugyanez a hiba.
További keresgélés hatására megtaláltam a következő SBS-es oldalt, ami a Trend Micro-ra fogja a dolgot:[link]
Konkrét megoldás sajna itt sem volt, de visszajuttam az MS-hez meg máshol emlegették, hogy a Trend Micro konzolban nezzem meg a proxybeállitasokat, de azok is jók voltak, jöttek szépen a frissítések a víruskergetőhöz, meg szépen be is volt írva a megfelelő felhasználónév és jelszó a proxy hitelesítéshez.
Itt már kezdtem feladni a dolgot, mivel kb ennyi infóm volt, és sehol egy épkézlab megoldás, így előkaptam a Wireshark-ot, hátha elkapom vele a csomagot ami az autentikaciós hibát okozza. Wireshark elő, figyeltem kb 10-15 percig a forgalmat amíg nem jött az event logban a hiba, es kiszűrtem a Wiresharkban az NTLM-hez tartozó csomagokat.
Hoppá, itt találtunk valamit! Néhány kliens a csm50.url.trendmicro.com-ról szeretne adatot szedni mikor a hiba jön az event logban. Ha kifelé akar menni, akkor az ISA logban is nyomának kell lennie, és íme itt az eredmény pár perc monitoring után.
Amúgy ez a csm50.url.trendmicro.com a Trend Micro URL hitelesitő szolgáltatása ami elvileg globálisan ki van kapcsolva a Security Severben, de úgy látszik a klienseket ez nem nagyon érdekli.
Tehát az ISA elhajtja a Trend Micro-t, mivel nem hitelesít a Web Proxynál. Egy nagyon jó kérdes, hogy miért nem hitelesít az antivírus kliens, mikor a saját szervere is ugyanezen az ISA server gépen van és arról siman le tudja szedni a frissítéseit, de ezt a gondot már meghagyom a Trend Micro programozóinak.
Gyorsan letrehoztam egy szabályt ami kiengedi az összes kerest a csm50.url.trendmicro.com fele, és meg is szűntek a hibák a logban.
Azért az öröm nem volt teljes, mert később volt egy másik URL is (http://tis17-en.url.trendmicro.com), szintén Wireshark-al kaptam el:
Folyt köv...
