|
| | | Junior Member
 
Group: Forum Members
Last Login: 10/10/2008 12:16:58 PM
Posts: 24, Visits: 55 |
| | I've got my Imail server (latest version) set to only relay email for a private IP space of 192.168.168.0 255.255.255.0 and somehow an outside server in Itally was able to relay email (100s of thousands) through it and now my IP space is starting to get black listed. This has been happening for about a week before I noticed it. How do I stop them? Is there a log someplace I can see if they are using a specific account to authenticate against or a log to see user send counts? If they are not authenticating against an account to send the emails is it possible they somehow hacked the relay? Is it possible to fake the private IP space I'm allowing to relay for? Help! |
| |
| | | 
Supreme Being
Group: Administrators
Last Login: 11/24/2008 7:15:23 PM
Posts: 98, Visits: 133 |
| Do you have a mail scanner or gateway in front of your mail server that handles all incoming traffic? If so does its IP fall within the range you're relaying for?
Jason H.
http://blogs.imailserver.com |
| |
| | | Junior Member
Group: Forum Members
Last Login: 10/10/2008 12:16:58 PM
Posts: 24, Visits: 55 |
| | I tracked the issue down to a root compromised account. Not sure how they got access to the root account, maybe the buffer overflow issue in 9.22? I'd suggest anyone running 9.22 to upgrade to 9.23 and change all their root passwords. I've seen some other posts about root accounts being compromised. Might also want to check who is authenticating in the logs. Not sure this will help and I hope its not a larger issue or hole in Imail that will allow them back in, a total pain. I'm looking for an smtp gateway like IMgate that can sit in the middle or something similar, not sure yet if IMgate is compatible with 9.23. Maybe a Barracuda SPAM firewall will do the same thing and give me some SPAM protection. Also debating upgrading to 10 or moving to another email server... |
| |
| | | Forum Newbie
Group: Forum Members
Last Login: 6/11/2008 9:48:57 AM
Posts: 6, Visits: 17 |
| | hmm, that makes two servers.. same problem, spammers were authenticating as root with password of 'password' even though the account was "disabled" ... |
| |
| | | Junior Member
Group: Forum Members
Last Login: 10/10/2008 12:16:58 PM
Posts: 24, Visits: 55 |
| | I'd just like to add another warning here. I've been watching my logs closely since this happened. I noticed someone else authenticating against an unused account. I have an account called "spam" that I was dumping spam too and they authenticated against it and sent 1 email. My guess is that was just a test to see if they could use it as a relay or that they still had access. None-the-less very suspicious. The password for this account was a tough one, so not something they cold have guessed, although they might have changed it when they got access to the root account. It also appears that a user can still authenticate against the system and send email even when that account has been disabled. I'd suggest anyone with this issue closely monitor their logs for awhile and change all passwords for user accounts... something is not right in Imail world. I'd like to see Imail add a daily authentication log report or email count report per user. I'd also like them to actually disable an account when you disable access to it. |
| |
| | | 
Forum Guru
Group: Ipswitch Employees
Last Login: 8/19/2008 3:48:11 PM
Posts: 64, Visits: 178 |
| NeoRye (6/10/2008)
I'd just like to add another warning here. I've been watching my logs closely since this happened. I noticed someone else authenticating against an unused account. I have an account called "spam" that I was dumping spam too and they authenticated against it and sent 1 email. My guess is that was just a test to see if they could use it as a relay or that they still had access. None-the-less very suspicious. The password for this account was a tough one, so not something they cold have guessed, although they might have changed it when they got access to the root account. It also appears that a user can still authenticate against the system and send email even when that account has been disabled. I'd suggest anyone with this issue closely monitor their logs for awhile and change all passwords for user accounts... something is not right in Imail world. I'd like to see Imail add a daily authentication log report or email count report per user. I'd also like them to actually disable an account when you disable access to it. Can you please tell me exactly how your root user is configured? We have attempted to duplicate this issue on multiple versions and have not been able to do so. Please note that suspending an account only applies to web access. Unchecking "Grant account access" is the only way to completely disable an account.
Ted Nichols
Ipswitch QA |
| |
| | | Junior Member
Group: Forum Members
Last Login: 10/10/2008 12:16:58 PM
Posts: 24, Visits: 55 |
| | OK, I was not able to authenticate against an account that has the "Grant Account Access" unchecked when I tried either. To be honest I'm not sure I missed that or not. I thought the root account was disabled when they were authenticating. I can however send an email to a disabled account, but that may or may not be a good thing. Has anyone else had a disabled account able to send email through it or seen that in their logs? |
| |
| | | Junior Member
Group: Forum Members
Last Login: 10/10/2008 12:16:58 PM
Posts: 24, Visits: 55 |
| | Could they have gained access to it with the buffer overflow issue found in 9.22 as described below? That was the version I was using when they got access to the root account, I upgraded to 9.23 but they still would have had access to the second account if they changed the password for it or somehow retrieved it. Not sure its related or that they just guessed the password or perhaps some other exploit. I do have a Sonicwall Firewall and their IPS (Intrusion Prevention Service) installed, so it got passed that too. Description:
Secunia Research has discovered a vulnerability in the IMail Client, which potentially can be exploited by malicious people to compromise a user's system.
The vulnerability is caused due to a boundary error within the IMail Client when processing emails containing multipart MIME data. This can be exploited to cause a data segment-based buffer overflow via an overly long "boundary" parameter (more than 212 bytes).
Successful exploitation may allow execution of arbitrary code.
The vulnerability is confirmed in IMail Client 9.22 included with Ipswitch IMail Server 2006.22. Other versions may also be affected.
|
| |
|
|