[NT4]Exchange "lijkt" nog steeds te relayen ?*

[Verwijderd]

Bij vrienden van mij wordt gebruik gemaakt van Exchange 5.5 (SP4) op NT4.0 (SP6a). Na een opmerking van de provider bleek dat de server "helemaal" open stond voor relaying.

Op basis van een artikel op de Microsoft site heb ik de restricties gezet binnen imc. Daarop laten testen met behulp van abuse.net, welke de melding gaf dat er niet meer gerelayed wordt.

Echter bij een controlle blijkt dat er in de "out" map alweer ruim 10.000 mailtjes klaar stonden.

Staat de server nu nog steeds open ?
Hoe kan ik er voor zorgen dat dit niet meer gebeurd ?

[Han]

Volgende keer even je OS [NT4] in je titel vermelden...

Zie ook: Windows Operated Systems Policy

* Han heeft al een topicreport aangemaakt, een modje zal je OS in de titel zetten.

[mutsje]

Je kunt relay compleet uitzetten maar ook voor bepaalde ip adressen open zetten.
Ik zou ook eens in de trackinglogs gaan kijken waar het vandaan komt. Dan kun je daar ook stappen tegen ondernemen.

[ Voor 20% gewijzigd door mutsje op 17-02-2003 08:38 ]

[spook]

kun je zien waar die mail vandaan komt?
gaat het om 1 server of bestaat de omgeving uit meerdere exchange servers..
staat er nog een "relay/contend scanner" tussen exchange en inet ?
heb je in de internet mail connector aangegeven welke domeinen geaccepteerd worden ?

Als je in de internet mail connector aangegeven hebt voor welke domeinen hij mail accepteerd en dat relay dus niet mag zou er niet meer gerelayd kunnen worden.
Als je echter meerdere exchange/mail servers hebt of andere servers die mail accepteren en contact hebben met je exchange omgeving kan het zijn dat er via die servers relay loopt

[Verwijderd]

Eerst ter aanvullig: de mailtjes lijken replies te zijn uit naam van de postmaster dat de mailtjes non-deliverable zijn. Hierover heb ik net een stukje op Microsoft gevonden dat de "Disable auto-replies to the Internet" check box aangevinkt moet zijn. Helaas weet ik niet of deze aangevinkt staat (waar kan ik deze checkbox vinden ?).

Ik zit momenteel niet bij de server en ik ben niet echt bekend met Exchange...

Mutsje, waar kan ik de tracking logs terug vinden ?

Spook, ik kan in bovenstaande replies zien waar ze van daan komen...
Er staat 1 server (SBS 4.5 voor 5 users)
De server zit via een ISDN met een Cisco 1600 "direct" aan het Internet.
Binnen imc heb ik aangegeven dat alleen gebruikers op het netwerk mogen relayen.

[mutsje]

start >> run >> typ in \\servername\ nu komen de shares vanzelf omhoog. De trackinglog directorie is standaard geshared als \\servername\tracking.log Helaas maak ik geen gebruik van IMC maar van X400 connectors dus kan je niet helpen met vinkjes..

colega heb ff op andere mailserver ingelogt..

Op je IMC dan tabblad InternetMail. Onder knop Advanced Options. Hier kun je auto reply UIT zetten.

veel suc6

[ Voor 28% gewijzigd door mutsje op 17-02-2003 09:13 ]

[blackd]

Titelfix, zie XceeD

[Verwijderd]

mutsje schreef op 17 February 2003 @ 09:09:
start >> run >> typ in \\servername\ nu komen de shares vanzelf omhoog. De trackinglog directorie is standaard geshared als \\servername\tracking.log Helaas maak ik geen gebruik van IMC maar van X400 connectors dus kan je niet helpen met vinkjes..

colega heb ff op andere mailserver ingelogt..

Op je IMC dan tabblad InternetMail. Onder knop Advanced Options. Hier kun je auto reply UIT zetten.

veel suc6

Zorgt deze optie dat naar "mensen van buiten" geen non-delivery report gestuurd wordt ?

[mutsje]

Verwijderd schreef op 17 februari 2003 @ 09:31:
[...]


Zorgt deze optie dat naar "mensen van buiten" geen non-delivery report gestuurd wordt ?

bij mijn weten wel ja.
Kwestie van aanzetten en kijken wat er gebeurd.

[spook]

in de admin van exchange kun je onder de site bij connecties de internet mail connector vinden, hier in kun je achter een advanced knop (heb de admin niet bij de hand en weet de tab naam niet zo) auto replay en out of office replay aan en uitzetten.
Auto replay wordt meestal uitgezet, out of office replay is een keuze die je moet maken. als je die uitzet komen vakantie meldingen en zo niet meer door maar voorkom je eventuele mailstormen.

Ingeval van veel replayes ivm met poging tot relay zou ik op de firewall de verzendende ip op blok lijst zetten

[Verwijderd]

Zojuist even kontakt gehad.

Het blijkt dat de optie Disable autoreplies al "aan" stond.

Nu moet ik maar uit gaan zoeken of ik het IP adres kan blokken.
Kan ik deze in de berichten terug vinden ?

[spook]

in de header kun je of ip adres of dns naam van de server terug vinden.
dns naam kun je zo terug tracen naar ip adres.
Als ze echt proberen te spammen is het handig de provider te mailen met mail + header.

[Verwijderd]

je moet bij het ROUTING tabblad opgeven, dat ALLEEN computers in een bepaalde IP range kunnen gebruikmaken van Exchange.
in mijn geval is dat de range 10.0.0.0 op m'n werk.
verder is auto-replyen uitzetten wel een goed idee, maar als je er 10.000 tegelijk ziet gaan dan is er toch nog iets niet OK met wie wel en niet mag mailen.
en je kan die lijsten handmatig dumpen heh.

[Verwijderd]

Gisteravond heb ik weer een poging gewaagd.

Op advies van Microsoft heb ik de logging aangezet om te kijken of er iets in het event log komt. Hieronder een opsomming:

1) IP range is beperkt tot het netwerk
2) Zelfs na het aangeven dat een connectie geauthenticeerd moet zijn, worden de mailtjes gemaakt. (na het starten van de imc)
3) Eventlog geeft niet terug
4) Hieronder tref je een voorbeeld van zo'n berichtje aan...

Message-ID: <D126DA7BF8B9D311A591005004EB7948223F18@PDCNT01>
From: System Administrator <[e-mail]>
To: [e-mail]
Subject: Undeliverable: Printer Cartridges - Up To 80% Off Retail - Free S
hipping Special Offer for 4thezoocrew1
Date: Fri, 7 Feb 2003 15:04:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-MS-Embedded-Report:
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C2CEB1.CF25F470"

[ Voor 4% gewijzigd door Verwijderd op 18-02-2003 08:30 ]

[Verwijderd]

lijkt me eerder iets kwa een virus.

[Verwijderd]

Moest je, om gemaakte wijzigingen actief te maken, niet eerst een service disablen en daarna weer enablen? Ik werk eigenlijk nauwelijks met Exchange, maar ik meen me zoiets te herinneren.

[0siris]

zie vorige reactie BazzH: stop eens alle services die met exchange te maken hebben, en start ze dan eens? (zijn zeker 6 services)

[Verwijderd]

Zelfs de nodige keren gereboot...

Zelfs met de connection dicht, werden de mailtjes aangemaakt om te versturen (zie bovenstaand bericht...)

Duinkonijn, welk virus / worm is hiertoe in staat ?
Ik weet dat McAffee draait (wordt volgens mij zelfs regelmatig geupdate !)

[0siris]

Met connectie dicht, kijk eens bij IMS , tabblad queues, en kijk daar eens naar zowel "outbound messages awaiting conversion" en "outbound messages awaiting delivery". Gooi beide wachtrijen es helemaal leeg. (open relay met exchange? been there! )

[Verwijderd]

0siris schreef op 18 February 2003 @ 09:55:
Met connectie dicht, kijk eens bij IMS , tabblad queues, en kijk daar eens naar zowel "outbound messages awaiting conversion" en "outbound messages awaiting delivery". Gooi beide wachtrijen es helemaal leeg. (open relay met exchange? been there! )

Osiris, het klopt dat er sprake "was" van een open relay.
Op basis van de diverse documenten van Microsoft heb ik restricties op de relay gelegd, maar dezxe lijken niet te werken.

De connection heb ik middels authenticatie dichtgegooid, maar zelfs dan worden er nieuwe mailtjes aangemaakt en klaar gezet. Dit nadat en de map exchsrvr\out leegegooid was en de queue weggegooid was.

op dit moment loopt er ook een thread in de Microsoft nieuwsgroep, ik ben benieuwd of daar nog iets uit komt...

[0siris]

ik meen me te herinneren dat dat bij mij ook zo was: er bleven maar nieuwe mailtjes gemaakt worden. Echter, ze kwamen er niet bij met een datum jonger dan ik die open relay gedicht had. Ik heb gewoon elk uur ofzo die wachtrijen zoals ik beschreef, leeggekieperd, en op een gegeven moment kwam er niets meer bij!
Wij hadden destijds nog een dialup connectie met internet, waarbij we nog per "telefoontik" betaalden.....
<edit>Ik hoop trouwens voor je dat je het snel opgelost krijgt: anders kom je misschien nog terecht op zo'n spam-blacklist....maar je zult zien dat je straks een stuk sneller kan surfen, en dat Exchange een STUK minder resources vreet!</edit>

[ Voor 24% gewijzigd door 0siris op 18-02-2003 10:11 ]

[Verwijderd]

Misschien te kort door de bocht, maar deze mailtjes moeten toch ergens vandaan komen ?

Hoe heb je trouwens voorkomen dat deze verstuurd zouden worden ?

PS.: telefoontikken, helaas hier ook...

[0siris]

Verwijderd schreef op 18 February 2003 @ 10:10:
Misschien te kort door de bocht, maar deze mailtjes moeten toch ergens vandaan komen ?

Ja, komt natuurlijk ERGENS vandaan, maar ik weet niet waar ze vandaan kwamen, maar het waren er tienduizenden, kan me voorstellen dat dat dan nog in een of ander temp-tmp-tijdelijk pre-bestand staat ofzo

Hoe heb je trouwens voorkomen dat deze verstuurd zouden worden ?

Tja, ik ben een avond op mijn werk gebleven, daar de router uitgezet, en alles lopen configgen, bureau opruimen, dingen in outbound queue in Exchange verwijderen, net zo lang tot het weg was

[Verwijderd]

Osiris, ook heb ik na het aanpassen een relay test via abuse.net gedaan.
Deze komt bij stap 6 en geeft hierbij aan dat er mogelijk uit naam van het bedrijf mail gestuurd kan worden. Weet jij toevallig of dit normaal is ?

De Microsoft site biedt hier geen duidelijkheid in.

[0siris]

Verwijderd schreef op 18 februari 2003 @ 10:48:
Osiris, ook heb ik na het aanpassen een relay test via abuse.net gedaan.
Deze komt bij stap 6 en geeft hierbij aan dat er mogelijk uit naam van het bedrijf mail gestuurd kan worden. Weet jij toevallig of dit normaal is ?

De Microsoft site biedt hier geen duidelijkheid in.

Mijn Exchange kwam ook niet door deze test...nou ja, het is niet anders. Ik ben bezig met een Linux machine waarop ik binnenkomend SMTP verkeer scan op virussen / spam alvorens ik het naar Exchange doorstuur. Mijn Linux machines slaagden met vlag en wimpel voor de relay test op abuse.net

Ik weet niet hoe exchange 2000 uit de test komt op abuse.net, maar ik kwam zelf ook niet veel verder dan test6 (al stukken beter dan failen op test 1 zoals het was toen we een open relay waren)

[mutsje]

Relay kun je zelf testen door in te proberen te loggeon via telnet.

Als dit niet werkt(krijg je acces is denied) kun je er zeker van zijn dat het van buitenaf ook niet lukt.

Die mailtjes die nog nog klaar staan , staan ergens in een queue opgeslagen(logfile).

Wat je heel erg rigoreus kunt doen is je logfiles verplaatsen uit je [mtadata]directory (zoek wel even op technet welke PERSE moeten blijven staan).

Ik geloof zo uit mijn hoofd de eerste 28 logfiles. Dan Stop/Start Microsoft Exchange services en gaat hij de logfiles opnieuw verwerken.(Zorg wel dat je de oude logfiles niet weg gooit want dan is de mail ook weg. Maar je kunt dan gerichter gaan zoeken..

[StevenK]

Verwijderd schreef op 18 February 2003 @ 10:48:
Osiris, ook heb ik na het aanpassen een relay test via abuse.net gedaan.
Deze komt bij stap 6 en geeft hierbij aan dat er mogelijk uit naam van het bedrijf mail gestuurd kan worden. Weet jij toevallig of dit normaal is ?

De Microsoft site biedt hier geen duidelijkheid in.

Als je relay-blocking goed hebt ingesteld, is het versturen uit naam van het bedrijf, vanaf *die* server niet mogelijk.

Vanaf het internet is het wel mogelijk, en daar kan Exchange niets tegen doen.

[Verwijderd]

StevenK schreef op 18 februari 2003 @ 13:45:
[...]

Als je relay-blocking goed hebt ingesteld, is het versturen uit naam van het bedrijf, vanaf *die* server niet mogelijk.

Vanaf het internet is het wel mogelijk, en daar kan Exchange niets tegen doen.

En dit zou je dan wel kunnen tegenhouden met een ander product (zoals een Linux variant) ?

Vanaf het Internet wel mogelijk (uit naam van het bedrijf) ???
Dan heb je de restricties alleen nodig om te zorgen dat uit jouw (domein)naam verstuurd kan worden ?

[mutsje]

Meer spitwerk... hoe een mogelijk virus identificeren en uitschakelen.

MORE INFORMATION
You can use Findbin.exe to crawl Exchange Server message transfer agent (MTA) .dat files. Findbin.exe is primarily used to extract messages that may contain a virus.

In most cases, a batch file is created for the most common types of e-mail virus (such as ExplorerZipWorm, ILOVEYOU, or Melissa). If a batch file is not created for a virus, Findbin.exe requires the following syntax (where hex_string is the name of the attachment that the virus uses converted to hexadecimal, files are the files that you want to look for, and move_folder is the folder that you want to move the files to):
findbin.exe [hex_string] [files] [move_folder]

For example, if the virus always uses an attachment that is named Badvirus.vbs, convert the name Badvirus.vbs to hexadecimal to use as the hex_string. Badvirus.vbs is 62616476697275732E766273 in hexadecimal. The files that you want to look for in files are usually db*.dat, which are the MTA .dat files. For move_folder, choose a subfolder of the Mtadata folder that you want to move the files to, such as the Virus folder. Therefore, the command line to find Badvirus.vbs in your MTA .dat files and move those files to the Virus subfolder is the following:
findbin.exe 62616476697275732E766273 db*.dat VIRUS

Cleaning Up a Worm Virus Attack from the Mtadata Folder
Identify your MTA's database folder. Inspect the server's registry for the MTA database path value in the following location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters\

Copy Findbin.exe to the Mtadata folder that you identified in step 1.
Stop the MTA and any dependent services.
Create a subfolder of the Mtadata folder named Virus.
From an MS-DOS prompt or a command prompt window, run Findbin with the correct syntax. It may take some time to process all of the files. When the cursor returns to the MS-DOS prompt window, the files have all been processed. Any files that contain the string that you specified are moved to the Virus folder, and you can safely delete those files at your discretion.
Run Mtacheck. If you do not encounter any problems, skip to step 8. If you do encounter problems when you run Mtacheck, proceed to step 7.
If you encounter any problems when you run Mtacheck, copy the files from Db000002.dat through Db000026.dat from the Server\Setup\platform\Bootenv folder of your Exchange Server CD-ROM to the Mtadata folder that you identified in step 1. After you copy the files, you need to remove the Read Only attribute from the copied files or you will not be able to successfully run Mtacheck or start the MTA.

IMPORTANT: Do not overwrite the Db000001.dat file.
Restart the MTA.
Repeat steps 1 through 7 again if you encounter another significant backlog on the MTA because of virus mail

[mutsje]

DB000001.dat DB000009.dat DB000011.dat DB000019.dat DB000021.dat
DB000002.dat DB00000A.dat DB000012.dat DB00001A.dat DB000022.dat
DB000003.dat DB00000B.dat DB000013.dat DB00001B.dat DB000023.dat
DB000004.dat DB00000C.dat DB000014.dat DB00001C.dat DB000024.dat
DB000005.dat DB00000D.dat DB000015.dat DB00001D.dat DB000025.dat
DB000006.dat DB00000E.dat DB000016.dat DB00001E.dat DB000026.dat
DB000007.dat DB00000F.dat DB000017.dat DB00001F.dat
DB000008.dat DB000010.dat DB000018.dat DB000020.dat

deze datfiles moet je laten staan mocht je je logfiles weg willen donderen.
http://support.microsoft....?scid=kb%3ben-us%3b271905

[ Voor 95% gewijzigd door mutsje op 18-02-2003 15:49 ]

[Verwijderd]

Ehm

lieve mensjes,

De mailtjes die erlinden quote zijn Automatic Replies van de Exchange bak, die een catchall van de provider leegsleurt, kijkt of ie de geadresseerde kent, en zo niet terug mailt met de melding dat de geadresseerde onbekend is.

Er is wel zeker iets mis met z'n configuratie (want mijn exchange bakje hier komt wél door test 6 zonder problemen.) maar ten eerste denk ik dat er nog veel meuk in z'n queue's hangt en ten tweede vind ik de zoektoch naar een virus niet zinnig: Als hij een virus heeft, dna staat het misschien beleefder om hem te wijzen op het pr0gramma STINGER op de mcafeeb2b.com website, en eventueel op een demo versie van de verschillende bekende virusscanners, voor servers EN werkstations.
Want als je het al weggefiltert krijgt uit de mailqueue's dan nog heb je dat virus aan boord.

[Verwijderd]

Verwijderd schreef op 18 February 2003 @ 15:51:
Ehm

lieve mensjes,

De mailtjes die erlinden quote zijn Automatic Replies van de Exchange bak, die een catchall van de provider leegsleurt, kijkt of ie de geadresseerde kent, en zo niet terug mailt met de melding dat de geadresseerde onbekend is.

Er is wel zeker iets mis met z'n configuratie (want mijn exchange bakje hier komt wél door test 6 zonder problemen.) maar ten eerste denk ik dat er nog veel meuk in z'n queue's hangt en ten tweede vind ik de zoektoch naar een virus niet zinnig: Als hij een virus heeft, dna staat het misschien beleefder om hem te wijzen op het pr0gramma STINGER op de mcafeeb2b.com website, en eventueel op een demo versie van de verschillende bekende virusscanners, voor servers EN werkstations.
Want als je het al weggefiltert krijgt uit de mailqueue's dan nog heb je dat virus aan boord.

Ha knettergek,

Hoe kan het dat er automatic replies gestuurd worden, terwijl dit gedisabled staat ?

De queue heb ik inmiddels een paar keer weggegooid, maar het lijkt dat er op een andere plaats ook wat klaar gezet wordt (wellicht de logfiles) ?

Waarom kom jij wel door test 6 heen (ik ben uitgegaan van Microsoft's instellingen) ?

Wat adviseer jij me op dit punt ?
Wellicht IMC opnieuw aanmaken / Exchange opnieuw installeren ?

[ Voor 4% gewijzigd door Verwijderd op 18-02-2003 16:50 ]

[mutsje]

Verwijderd schreef op 18 February 2003 @ 15:51:
Ehm

lieve mensjes,

De mailtjes die erlinden quote zijn Automatic Replies van de Exchange bak, die een catchall van de provider leegsleurt, kijkt of ie de geadresseerde kent, en zo niet terug mailt met de melding dat de geadresseerde onbekend is.

Er is wel zeker iets mis met z'n configuratie (want mijn exchange bakje hier komt wél door test 6 zonder problemen.) maar ten eerste denk ik dat er nog veel meuk in z'n queue's hangt en ten tweede vind ik de zoektoch naar een virus niet zinnig: Als hij een virus heeft, dna staat het misschien beleefder om hem te wijzen op het pr0gramma STINGER op de mcafeeb2b.com website, en eventueel op een demo versie van de verschillende bekende virusscanners, voor servers EN werkstations.
Want als je het al weggefiltert krijgt uit de mailqueue's dan nog heb je dat virus aan boord.

messages staan in een queue. deze staat in je MTADATA directorie. Dus als je deze leegt is je reply probleem van mailtjes die nog "vast" staan ook opgelost ik zit zeker niet lukraak te posten maar probeer hem te helpen.

muts.

[nightowl]

Heb je de werkstations al gescant op virussen. Een soortgelijk probleem heb ik eens gezien bij een klant met 50 gebruikers. Hier hadden 2 medewerkers een email met virus in hun mailbox. Dit virus bleef email aanmaken. Was overigens ook verdomd lastig te verwijderen. Uiteindelijk van beide gebruikers alle email verwijderd, gereboot op werkstations en server en daarna was het probleem over.

[Verwijderd]

mutsje schreef op 19 februari 2003 @ 11:49:
[...]


messages staan in een queue. deze staat in je MTADATA directorie. Dus als je deze leegt is je reply probleem van mailtjes die nog "vast" staan ook opgelost ik zit zeker niet lukraak te posten maar probeer hem te helpen.

muts.

In de mtadata map zie ik alleen:
priv.edb
pub.edb

Inmiddels ben ik ook samen met een Microsoft man bezig om het probleem te verhelpen. Ik houd jullie op de hoogte...

[mutsje]

erlinden.

In je exchsrvr\mdbdata staan je Priv.edb en Pub.edb
In je exchsrvr\MTADATA directory staan alle logfiles.

In je mtadata directory staat de mail in. In zogenaamde logfiles van 5mb max per stuk.

[Verwijderd]

Met dank aan Microsoft is het probleem opgelost.

Na een aanpassing van een registry key, werkt het systeem sinds vandaag weer naar behoren. Waarschijnlijk is nog wel een bulk aan non-delivery mailtjes verstuurd, maar deze worden niet langer aangemaakt.

Daarnaast is er geen sprake meer van open relay en wordt de server niet meer gebruikt door externe "processen".

Van mij mag er dus een slotje op.

[mutsje]

welke key ging het nou om. Ook leuk om ff de oplossing te posten vind jezelf ook niet.

[Verwijderd]

Deze heb ik niet bij de oplossing geplaatst, omdat het een specifieke instelling op deze locatie was. Mocht je toch geinteresseerd zijn:

hkey_local_machine\system\currentcontrolset\services\msexchangeimc\parameters

relayflags op b (hexadecimaal) in plaats van 3 gezet.

[mutsje]

ok dus daar moeten de tweakers naar kijken bij relay problems.. leuk om in gedachten te houden. thanks dude.

ik vul dit soort dingen zelf in op een website forum. alleen oplossingen.

[seq_uence]

Mutsje welk forum is dat dan ? Wel leuk om ff te weten nietwaar ?

Ik zit trouwens te kijken op abuse.net maar kan zo 123 niet vinden waar je die test kan uitvoeren, zal er wel overheen kijken. Wie helpt ff ? b.v.d.

[mutsje]

forum staat op www.hanmar.mine.nu Let wel dit is geen vraag maar raak forum maar alleen een forum waar solutions in staan.

[Verwijderd]

opgeven dat alleen het interne domein mag relayen, en van extern alleen de provider (waar je de mail van krijgt, dus het IP van de smtp server). Precies kan ik maandag pas kijken op het werk welke restricties aan en uit moeten, heb thuis geen exchange server staan .