|
Internal spam attacks are typically caused by mail client infected by specific viruses which continually send out mail automatically using the contacts in the address book. We have observed that typically these viruses infect various versions of MS Outlook.
The nature of these attacks is that the clients (desktop email client software applications like MS Outlook), which are infected, automatically pump large volumes of mail into the server containing arbitrary messages and either valid or invalid recipients (depending on the objective of the virus writer).
In some rare cases, it is possible that some employee may misuse the mail system by sending out unsolicited mail to certain groups of users, or may send bulk mail to internal and/or external users using the mail server resources.
Learning from our various deployments across many verticals, which house all kinds of users, and clean/unclean networks, Mithi has continuously upgraded the security framework in the collaboration product (Connect Xf) to not just survive these conditions but to thrive in them. Below you will find a short note on some of the key techniques deployed in the solution to handle these threats. |
|
| 1. Authenticated Relay: SMTP Authentication for sending mail. |
| All connections by the client PCs have to be authenticated even to deliver mail to local recipients. This ensures that spurious spam programs/code/malware, which become aware of the server IP, cannot simply connect to port 25 and push mail through. Each connection is authenticated with a valid Email ID and password. |
|
| 2. Password policies |
|
As a compliment to the above technique, it is essential to have “good” and “strong” passwords. Connect Xf supports several features to enforce this like minimum password length, custom password complexity rules, password expiry, etc. We recommend to customers that they must deploy these policies on their site to enhance security. |
|
| 3. Mail usage control via policies |
Many a times, authentication is not enough protection since the virus attacks manage to use the stored password for authentication and can send junk mail through the server. The next level of protection required is to define policies controlling the flow of mail through the server like: - Controls for maximum recipients in a mail or the maximum mail size or maximum number of attachments, prevent run away abusive usage of the server resources in case of an attack or even during normal operations.
- Policies based on mail attributes like mail size, recipients, senders, etc., will ensure that various user groups in the organization have varying levels of control and access while sending mail. For example, only a few selected users can send mail to the distribution lists, OR a few groups of users cannot send mail to external domains, OR a few groups of users cannot send mail with attachments etc.
- Rate control is a technique used to restrict the number of mail a client PC or user can send in a day. This is configurable and ensures that even if a client does get infected and makes it past the mail policies, it will be blocked when it crosses the prescribed limit for the day.
- Spoof check is a feature on the server mail scanner, which confirms that the connecting sender id, is same as the authentication id and is same as the sender header in the mail body as well. This prevents users from using another user’s authentication to impersonate that person.
- Domain spoof check ensures that a particular client (server, PC, mobile) can only send mail with the "from" id being in the listed allowed domains. This prevents client devices from authenticating with one id while pushing mail with different varying from ids. To understand this, once a client authenticates over SMTP, as such that connection is open relay, which means that technically the client can send a mail "from:anybody" "to:anybody". However, in a regular corporate environment, Connect Xf can impose a check which specifies that over an authenticated SMTP connection, the sender email ids must belong to a specified list of allowed domains ONLY. Policy wise, this makes complete sense, since senders in a corporate environment can only be of the sender's domain. This greatly reduces the impact on the server when the clients are compromised by viruses or hackers.
|
|
