SPAM and a relay server

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Someone is using one of my clients servers as a relay.

We thought we had fixed the issue and locked everything down internally as thought that was where it was coming from - also locked down in Domino server doc due to some suggestions made by you guys / research etc, but have noticed a sudden increase in the number of nonsense emails going out to random addresses from there again...

Server is set up with message labs.

Firewall is a bit sus -

Its set that ALL WAN traffic in is denied apart from some specific traffic - message labs on port 25, and LAN traffic is allowed out.

The firewall is still allowing you to telnet into the server though??!?...


Any ideas??

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Is that telnet on port 25?

Are you sure a client isn't compromised on the internal side of the LAN?

 

Edit: Doh! Sorry I am now confusing things more!!

The telnet I used was to port 25, and got through!

 

Hi Leehaa,
Have you tested the mail server from outside to see if it is allowing open relay?
Try this linky to test for open relay.

HTH
NB

 

I always use this link to test my mail servers from the outside world. Run the MX lookup from there then it will test to see whether its an open relay for you.

Like Stoney, I'm leaning towards it being a compromised internal machine. This would be especially likely if your firewall was allowing all traffic outbound.

 

Hi Leehaa,

If you managed to telnet into the server from outside of the LAN on port 25 then I would say that you firewall is allowing access to the email server and thus allowing relaying.

If not, I would setup a network sniffer and see if you can pin point where a lot of smtp traffic is coming from on the internal side of the LAN.

HTH

 

Thanks for all the input folks.

Sparky - yes the MX records do go to the message labs first.

Ran the MX record test and all pointed to message labs.

I ran the above relay test and it failed (which indicates it may be a internal machine)...

Will keep at it...

but it worries me that we were still able to telnet into port 25 when we shouldn't be able to??!? A colleague (who does contract work for us from time to time) has tried it from his home LAN and he could get in too?...but as I said, the relay test failed? Am really confused???

 

Lee

Just because you can telnet to port 25 on the server doesn't mean its allowing relaying. In fact, it just indicates that the SMTP service is up and running on that port (as it should be). Your MX records point correctly to the MessageLabs servers, so, providing you're not running an open relay, your maail server isn't vulnerable to an open-relay type of attack. Of course, as Sparky says, you shouldn't be able to telnet to the SMTP service if you're routing via a gateway server.

 

I am not that clued up on this side of things. Please can you advise? What is a safe network sniffer to use? How about this:

http://netsecurity.about.com/od/securitytoolprofiles/p/aapranalogx.htm ??

Thank you

 

Oh - right -ok. Thank you.
So why, do you think, it is that we can still telnet to the service? I know it isn't such a huge issue now, but it bugs me, and I want to know why it's still happening!!

 

Lee - use Wireshark. It dumps on any other sniffer out there

 

Aaaaah!! Just found out that although the telnet banner was displaying...do anything else and it gets rejected!! Doh - Lol

 

Groovy - thanking you!!

 

Well there you go then - breathe easier!

Now all you've got to do is find the rogue machine internally - though that shouldn't be too hard. Ask your firewall guys to set up logging on the 'allow any outbound' rule (oooooh - I just got a shiver down my spine when i typed that!) and see which machines are making repeated connection attempts to outside IPs on port 25 and 6667 (IRC) - indicative of a mass mailing worm trying to spam and also connect back to the mothership (a bot herder) via an IRC channel