This article may help clear up your smtp queues
http://support.microsoft.com/?kbid=324958
You may also want to turn off NDRs
MLF
Printable View
This article may help clear up your smtp queues
http://support.microsoft.com/?kbid=324958
You may also want to turn off NDRs
MLF
All clean. I just need to read up and figure out how the heck they are getting in...
BTW: I already went through the instructions listed above. (The relaying part)
Looking through the logs it seems they hit between 5 and 8am PST. (For the past couple of days) The weird thing is that the IP address has not been reported to any spam lists yet. It probably sends out a good deal of email. I will check in the morning.
First questions are:-
1. Fully Patched including Exchange 2000 updates?
2. Other publicly available services this server runs?
3. Properly firewalled? (check it remotely - every port).
4. DMZed? ('Cos if it isn't the trusted network may be compromised).
You might want to run this over it first.... It tries a few "creative" attempts to force a relay.
Good point..Quote:
Originally posted here by Tiger Shark
4. DMZed? ('Cos if it isn't the trusted network may be compromised).
Machine inside could be the sender.
Does anyone access via VPN? Could be another place to look.
What are your relay settings?
Most spammers get in via authenticated user accounts assuming you have NOT ran the IIS lockdown tool on Exchange and ensured all forwarding options are turned off. It's tough to prove if it's inside or out but at high volume my guess is outside automated bot. The network accounts are the SAME as the accounts presented on the outside. Meaning if user bob has a password of bullet to access the network then a bot could get relay capability on the exchange server by guessing “bullet”. Not difficult at all. In fact you will see it come back now and try things common like administrator, guest etc. Funny to watch. In addition if the mail accounts were merged from an older system or propagated via active directory then all those bogus unused accounts will appear on the exchange server public side. You can prevent some of that BS by turning forwarding off completely; it is not a default setting in 2000.
lol, Tiger I am no expert what was it you said in another thread I often stare at the screen and mutter “do I know wtf I am doing?” BUT I have recovered from many complete disasters and never had to restore a backup. Knocks on wood. I too had an employee running exchange; she was terminated after crash number 3. I have since had crash number 4 – backups appending to a hard disk versus overwriting and the FTP script failing to copy them off. Hard disk space is critical and exchange gives very little indication that there are issues. It just likes to run right into the brick wall at full speed.
I am glad the information store was not corrupted, I had some faith it would come back after clearing all the crap out. :) BTW your mail queues will continue to fill up because chances are there are still outlaying messages waiting to be sent and the queue time is large. Make sure this guy watches and clears all bad mail and queues. In addition I would not allow remote access of ANY kind on the public card/IP. Put it in a DMZ or stick another NIC in there for private access if it’s necessary or encrypt it. Tiger has a good solution I will implement soon, GFI Mail Guard I think? But if you only open port 25 and sniff it you should be ok, but a complete compromise of the mail server will open the network. If you don’t want to spend money or keep your cost down and pass on some good profit you can build a small linux mail forwarder. It won’t strip bad stuff like GFI but you can run it on an old box and it won’t cost much. Just google a howto linux smtp forwarder or relay.
Now on the client side that’s tougher. If you have SMTP logging enabled you can look for those event ids I listed earlier. I don’t think you will find them posted anywhere but I know for fact that those are indications of external authentication on the SMTP virtual servers. Oh, Also don’t forget to enable security monitoring for this server on the domain controller. There is no way to stop internal spamming unless your client has implemented desktop virus protection to stop the bots on outlook and you lock down spy ware somehow. Even in a system locked pretty tight you will see large volumes of bad mail but at least you can stop the malicious content. It’s hard to stop all those people wanting to play “chain letter mamma” mailing crap to their entire address book but routinely deleting that bad mail folder and setting the queues times back from a couple of days to a few hours is a small risk but easier on the system. I think the default settings are a couple of days for exchange to deliver mail. I say, if it’s not there in something like 7-10 hours - move it to bad mail and delete it. I average about 1000 undeliverable messages each day. That will add up and like Tiger said, on an active exchange server if you do not clear out those items along with logs it will fail within weeks.
Good points.Quote:
Originally posted here by Tiger Shark
First questions are:-
1. Fully Patched including Exchange 2000 updates?
2. Other publicly available services this server runs?
3. Properly firewalled? (check it remotely - every port).
4. DMZed? ('Cos if it isn't the trusted network may be compromised).
You might want to run this over it first.... It tries a few "creative" attempts to force a relay.
1) Fully patched as far as the OS goes, but I am not sure about Exchange. I will check on that.
2) It runs Outlook Web Access and Remote Desktop. It does not run the companies website. (Hosted at yahoo) As far as I know that is all that is running.
3) Small Business Server comes with ISA server installed on it, so it does have a software firewall. However, a quick port scan from GRC.com shows the following ports open:
25, 80, 88, 110, 111, 119, 135, 139, 143, 389, 464, 443, 548, 563, 593, 636, 691, 993, 995, 1026, 1029, 1033.
4) Its not DMZed. Its has all their files on that one machine.
I ran the abuse.net test a while ago and it came up negative, however it came up positive this time around.
Edit: Added a pic of the relay settings. They do have 2 or 3 external users so what are the best settings to use?Quote:
Mail relay testing
Connecting to 66.27. for anonymous test ...
<<< 220 server.domain.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713 ready at Wed, 8 Sep 2004 07:45:22 -0700
>>> HELO www.abuse.net
<<< 250 server.domain.com Hello [208.31.42.77]
Relay test 1
>>> RSET
<<< 250 2.0.0 Resetting
>>> MAIL FROM:<[email protected]>
<<< 250 2.1.0 [email protected]....Sender OK
>>> RCPT TO:<[email protected]>
<<< 550 5.7.1 Unable to relay for [email protected]
Relay test 2
>>> RSET
<<< 250 2.0.0 Resetting
>>> MAIL FROM:<spamtest>
<<< 250 2.1.0 [email protected]....Sender OK
>>> RCPT TO:<[email protected]>
<<< 550 5.7.1 Unable to relay for [email protected]
Relay test 3
>>> RSET
<<< 250 2.0.0 Resetting
>>> MAIL FROM:<>
<<< 250 2.1.0 <>....Sender OK
>>> RCPT TO:<[email protected]>
<<< 550 5.7.1 Unable to relay for [email protected]
Relay test 4
>>> RSET
<<< 250 2.0.0 Resetting
>>> MAIL FROM:<spamtest@[66.27.]>
<<< 250 2.1.0 spamtest@[66.27.]....Sender OK
>>> RCPT TO:<[email protected]>
<<< 550 5.7.1 Unable to relay for [email protected]
Relay test 5
>>> RSET
<<< 250 2.0.0 Resetting
>>> MAIL FROM:<[email protected]>
<<< 250 2.1.0 [email protected]....Sender OK
>>> RCPT TO:<[email protected]>
<<< 550 5.7.1 Unable to relay for [email protected]
Relay test 6
>>> RSET
<<< 250 2.0.0 Resetting
>>> MAIL FROM:<spamtest@[66.27.]>
<<< 250 2.1.0 spamtest@[66.27.]....Sender OK
>>> RCPT TO:<securitytest%abuse.net@[66.27.]>
<<< 550 5.7.1 Unable to relay for securitytest%abuse.net@[66.27.]
Relay test 7
>>> RSET
<<< 250 2.0.0 Resetting
>>> MAIL FROM:<spamtest@[66.27.]>
<<< 250 2.1.0 spamtest@[66.27.]....Sender OK
>>> RCPT TO:<securitytest%[email protected]>
<<< 250 2.1.5 securitytest%[email protected]
Relay test result
Hmmn, at first glance, host appeared to accept a message for relay.
THIS MAY OR MAY NOT MEAN THAT IT'S AN OPEN RELAY.
Some systems appear to accept relay mail, but then reject messages internally rather than delivering them, but you cannot tell at this point whether the message will be relayed or not.
You cannot tell if it is really an open relay without sending a test message; this anonymous user test DID NOT send a test message.
*COUGH* Pwn3dQuote:
25, 80, 88, 110, 111, 119, 135, 139, 143, 389, 464, 443, 548, 563, 593, 636, 691, 993, 995, 1026, 1029, 1033
There's no firewall there if these ports are OPEN.... Though the lack of 445 interests me..... PM me with the IP will you..... I'll Nmap it for you and see what it really looks like....
My Mail Sentry, (M$ SMTP), fails this one but it forwards it in to the Exchange server which fails it out.... I don't think this will be your problem. Try to do the same manually via telnet and actually send a message to an external account.Quote:
Relay test 7
>>> RSET
<<< 250 2.0.0 Resetting
>>> MAIL FROM:<spamtest@[66.27.]>
<<< 250 2.1.0 spamtest@[66.27.]....Sender OK
>>> RCPT TO:<securitytest%[email protected]>
<<< 250 2.1.5 securitytest%[email protected]
Quote:
Edit: Ok. Now this is looking like a paying job. He wants to setup some security and kick this spammers @ss. Where is a good place to start looking for this spammer?
Keep an eye for the emplyees too ;)...just to be safe. See if they got anything going on that might compromise the server. Any employees fired lately? Just some things to think about.
I dont think that any employees have been fired recently, but when I was out I deleted all the Active Directory accounts (and mailboxes) of those employees that were not working for the company anymore. All passwords were changed a week ago as well.Quote:
Originally posted here by Cybr1d
Keep an eye for the emplyees too ;)...just to be safe. See if they got anything going on that might compromise the server. Any employees fired lately? Just some things to think about.
Ouch..... Not a "pretty" sight.....
That ISA server is either not running or misconfigured......Quote:
Starting nmap V. 3.00 ( www.insecure.org/nmap )
Interesting ports on (xxx.xxx.xxx.xxx):
(The 1570 ports scanned but not shown below are in state: closed)
Port State Service
25/tcp open smtp
80/tcp open http
88/tcp open kerberos-sec
110/tcp open pop-3
111/tcp open sunrpc
119/tcp open nntp
135/tcp filtered loc-srv
139/tcp open netbios-ssn
143/tcp open imap2
389/tcp open ldap
443/tcp open https
445/tcp filtered microsoft-ds
464/tcp open kpasswd5
548/tcp open afpovertcp
563/tcp open snews
593/tcp filtered http-rpc-epmap
636/tcp open ldapssl
691/tcp open resvc
993/tcp open imaps
995/tcp open pop3s
1026/tcp open LSA-or-nterm
1029/tcp open ms-lsa
1033/tcp open netinfo
1720/tcp open H.323/Q.931
3005/tcp open deslogin
3052/tcp open PowerChute
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
3372/tcp open msdtc
3389/tcp open ms-term-serv
4444/tcp filtered krb524
Remote operating system guess: Windows Millennium Edition (Me), Win 2000, or WinXP
Nmap run completed -- 1 IP address (1 host up) scanned in 142 seconds
Seriously... A firewall is in order IMO. It looks like you simply have the box out there on the public net with all the services required to run an AD controller let alone an exchange server on a trusted network..... You even have the global Catalog ports available...... I wouldn't be surprised if I couldn't join my laptop to your domain with a little effort.....
First thing I would suggest is down the box...... Painful I know..... But show the owner this message and if he isn't conviced ask here for second opinions about how quickly this box could be compromised. Then get a firewall up.... Hell a linksys would do to start.... If this is a small business I would look towards a WatchGuard SOHO but you may have to wait a few days for that... the linksys is a drive to your local CompUSA away......