If you have hacked accounts in your system a send email rate limit (with notifying the admin if the limit kicks in) is the only way to detect zero day SPAM emails (if you can detect the new SPAM wave by “normal” means it’s already too late and you are probably on several RBL black lists).
The GWIAs have the knowledge of all active accounts and could track an hourly or daily send limit and produce the error message for the user and notify the admin.
by: Edmund W. | over a year ago | Agents
Comments
This would be urgently needed - at least as a last counter measure against RBL black listing and such. Also it would make GroupWise more secure and trustworthy.
A vital missing tool. No account should be able to go into blast mode without structured safeguards and sign-offs.
Mailbomb protection already exists. Also, please see https://www1.v1ideas.com/MFI/novell-gw/Idea/Detail/1126
This is the real core of the problem, that there is no way whatsoever to control authenticated relaying off of GWIA.
Massimo, you did not understand - or read it - .. this is the OTHER way arround. Limit the SENDING side - of your internal hacked accounts, sou you won't end up on the RBL lists.
I've never ever seen or heard of hacked internal accounts in GW, aka sends of SPAM via internal network, like via a remote controlled GW client. What I see basically every day are hacked accounts that authenticate to GWIA from external, and send external, aka relaying, and that's because GW has absolutely no means of configuring/disabling authentication vie GWIA from external.
As a reply a short story what’s going on: We have 40k active email users, the last phishing waves where quite well made – proper German, the right addresses, context … so let’s be optimistic that only on of 1000 accounts gets compromised – that’s 40 accounts. Our findings (with the latest accounts) is that the infection and the time when accounts are used to send zero day premium SPAM is apx. 2 month. So during this 2 month someone was looking at the user’s computer. There is (beside multi factor authentication) no way out of this mess.. Let’s stick to the email side. We had SPAM waves using SMTP-Auth, GW-Client and WebAccess, if you are a large enough target – the bad boys use whatever means you offer to your users. How do we detect such accounts – by behavior analyses – which is – in Germany ¬- at the legal limit. If some account starts to show unusual activity – the disable the account (since there is only the on/off option at the moment).
This is why a sending rate limit (or send quota) would be nice, just slowing down things (and make you unattractive for the bad boys).
Consider yourself blessed if you did not see this yet, my guess is that sooner or later they get to everyone.
I see a need on both the inbound and outbound, it's just a good idea.
Inbound:
Inbound side of SMTP, you want per-user limits on number of messages per min, hour, and day and limits on recipients. Basically to slow/stop attacks via SMTP. This would be a good idea on the clients (desktop and web) since it is another popular vector.
Outbound:
For outbound SMTP, you want the same per-user limits as on the inbound. Should something get past the inbound checks, the outbound will slow the rate, likely preventing wide-scale banning of the SMTP server.
For both of the above, there should also be rate-limits and such for POP and IMAP too, so that they aren't hammered by a bad actor (DDoS).
That said, it's hard for me to imagine anyone not using a third-party email security appliance both in front of (inbound), and behind (outbound). There is simply more control with the purpose-built solutions that go far beyond simple rate limits. That's not to say GWIA shouldn't have the basics, it should, just that i don't think they are a substitute for a quality email security appliance e.g. MS exchange gateways have very impressive rate-limit controls, but most still use a third-party solution as defense-in-depth.
Edmund: Interesting story. I have quite a few high profile customers where some basically constantly have at least one, often multiple accounts compromised. But the result is in literally all cases, spam sent via SMTP auth through the GWIA. Not a single time did I hear or witness spam sent via hacked GW clients (or Mapi calls or some such), nor via webaccess. Especially as such action would leave easily visible traces in the account.
I *did* have spam sent via hacked mobile devices though.
I'm not saying it doesn't happen, just I've never seen it, not personally, nor in the GW forums, which I work for 17 years now. ;)
Anyways, we agree that GW needs *much* better control over authentication and sending mail. Like limits to concurrent logins, easy configuration which access methods are allowed (and authenticated relaying via GWIA should be disabled by default).
I had a user's account hacked, the spammer used Webaccess/Client to add a out-of-office notice containing SPAM and added the SPAM to the user's signature line. Each time a new person emailed the hacked account, or the user sent an email, the SPAM was attached.
@Edmund: Limiting the send rate does not do the trick alone ! You end up on lists, b/c you send spam to honeypots and there a single mail is enough to get blacklisted, you only reduce te chance that you hit the honey pot early.
Best would be to spam detect your outbound mails, like we do on some edu orgs with GWAVA and GWIA.
What has helped me is to enable:
--disallowauthrelay
as well as Relay Allow overrides (IPAddress to * or IPAddress to *@yourdomain.com) for internal scripting engines that send mail via GWIA relay.