Users of VSNL's service have been experiencing random mail relay denied errors.(Check for 3 weeks back in this List) The Probability of these increasing has become extremely likely. The reason that relay denied errors are cropping up is due to SPAM. The reason is this- Old mail servers, like the ones serving the bulk of Unix servers in India are full of security bugs. They were built before the days of microscopic scrutiny by hackers over the Internet. A large number of organizations currently running Unix servers in India are susceptible to attacks. Here is how it all goes. Right now, VSNL operates , say, 5 servers in the Calcutta region. When one of us sends mail, The Mailer at this end- i.e. VSNL takes that mail and sends it i.e. routes it to another mailer, which has access to the destination. This is , of course, by using the underlying Internet network. The DNS record for a Host, i.e. a machine like cal.vsnl.net.in actually contains a record called MX which points Mail towards a Mail accepting station. This way, a mail agent at say Giasbm01 can say handle mail for http://www.abc.com. There is normally more than 1 MX record, with varying weights, for Reliability, Fault tolerance, High Load etc. There are thus more than 1 Mailer Programs/Daemons/Services like exchange / Sendmail (typically) running at most places. VSNL uses sendmail. So, If you have an account at cal.vsnl.net.in and you send mail, it might actually be rerouted from giascla as the cal server might be on high load, or as was the case recently, it was being upgraded and so the MX record rerouted mail to giascla. /elsewhere. Here is where the trouble started. A known Spammer has abused Giascla recently. The reason they can be abused is due to the fact that giascla used to run something called an OPEN RELAY. An open Relay allows non-users of the local account to send mail using it. It is similar to you using the smtp server in your Outlook /other Mail Client entry as giascla.vsnl.net.in instead of your own server, say cal.vsnl.net.in. This is A *BIG SECURITY PROBLEM AS UNKNOWN/FICTIOUS USERS CAN SEND SPAM FROM THIS SERVER. * TO stop this, many large networks maintain a so called RBL, a list of mailers which have open relays, and refuse services to them to protect the members in their network, effectively disconnecting us from the internet mail service. Some networks go further, they ban any IP address from the offending network to pass packets through their network, effectively cutting us from the Internet. This Nuisance exists because of oversight by the ISP's staff. Giascla was secured recently but here is the reason for this mail- THERE STILL EXISTS AN OPEN RELAY IN CALCUTTA. The offending server is cal3. Unless something is done quickly, we may find ourselves Stuck without mail access to the outside world. I have been in touch with some anti Spam Activists and have been working on this problem for the Last 1 week. Indro and I have been advised to collect some other legitimate users and communicate this problem to the senior staff at VSNL. We need your co-operation in this regard. Please go through the attachment and you will come to realise the seriousness of this problem and the problems affecting INDIA as a whole. Please contact either Indro or me by Mail and we can fix a date when we can communicate with VSNL about this problem along with the solutions, say by Wednesday/Thursday. (We have the solution, we have analysed the problems at Calcutta thoroughly over the past 1-week.) The sooner we get cracking, the better. We have already received Spam in this list before. Since the List is still within 100 members and the volume of mail is low, Indra moderates it. However, with more members, we shall surely land in hot water with SPAM. WE NEED TO ACT NOW! There are further Security holes, which are so horrifying that I cannot say anything about them in Public yet. If you are interested, Please mail me and I shall enlighten you (Prepare to be shocked) Thanking you for your patience, Shanker Shanker R Swaminathan Student of ME (Computer Science and Engineering) Jadavpur University Calcutta 700032 Proof of the Open relay---The person who helped me is a leading anti Spam activist and a founder member of CAUCE in India 220 cal3.VSNL.net.in ESMTP Sendmail 8.8.8 (1.1.3.6) Sun, 21 Nov 1999 11:11:36 +0 500 (GMT+0500) 250 cal3.VSNL.net.in Hello [203.197.20.219], pleased to meet you 250 [EMAIL PROTECTED] Sender ok 250 [EMAIL PROTECTED] Recipient ok 354 Enter mail, end with "." on a line by itself 250 LAA0000011645 Message accepted for delivery Please contact Either Indro or me if you need more details. I have CCd a copy of the relevant Traces to him. Shanker
Open Relays - A ticking time bomb The basic function of an SMTP server is to relay mail - as the RFCs specified in the good old days when the Internet was a small, cozy community restricted to a few universities and research laboratories. In fact, relaying was a necessity, given the uncertain nature of email services in those days - just to provide an alternative route for mail. However, as the Internet became more and more popular, it attracted the attention of spammers - the same people who used to deluge your postal mailbox with junk mail advertising everything from Get Rich Quick schemes to secret virility pills guaranteed to work twice as well as Viagra, at half the cost. These people gleefully switched over to sending their trash by email - citing vague reasons like - "We are saving a tree by sending email instead of using paper" "It costs nothing to download an email - just hit delete if you don't want it" "It is much cheaper for me to send email than pay for stamps and envelopes" When the victims of their spam started tracing them, some spammers had their accounts disconnected and were successfully sued by their ISPs. Spammers, therefore, started to hide their tracks, using forged email headers and abusing third party smtp servers instead of using their ISP's SMTP servers. Such "open" relays, which allow anyone (not just authorised users) to send mails through them - are now routinely abused by spammers, who pump several megabytes of spam through it (millions of mails, sometimes) - leading to server crashes or, at the least, slowing your mailserver to a crawl, with legitimate email bouncing because all available resources on the system have been hijacked by the spammer. Earlier, spammers were systematically scanning for and abusing Malaysian, Indonesian, Japanese and Korean open relays - most of which have ended up in the MAPS RBL [*], cut off from over 40% of the Internet. Additionally, all networks in the .my (Malaysia) domain were barred for several months from accessing all the IRC networks (Undernet, EFNet etc). Some of the larger Malaysian ISPs had to give written undertakings that they would close open relays and crack down on spammers among their users. [*] If your server has the misfortune of landing in the RBL, several hosts will bounce packets from these boxes at the router level - and your box will crash with all the bounces if the spammer has not crashed it already. To see how you can get into (or leave) the RBL - visit http://maps.vix.com/rbl/candidacy.html Spammers have now discovered India it appears. The anti spam community around the world has noticed a steady increase in the amount of spam originating from Indian open relay SMTP servers. The problem is compounded by the fact that several of these servers are running old Mail Transport Agents (mostly outdated versions of Sendmail) which are anonymous open relays. That is, they allow spammers to relay mails without their IP address being logged in an rDNS lookup, as is the case with most modern MTAs. Worse, such old MTAs have gaping security holes. Because sendmail runs as UID 0 (the same as root) a spammer can easily gain root access on a unix system running such an outdated MTA. This (or something quite similar) happened just after the Pokhran blasts, when BARC's servers were hacked by MilW0rm. Here is a partial list of the Indian servers which have been abused in the past few days. All these are running outdated sendmail versions. [1] National Informatics Centre, Karnataka (kar.kar.nic.in) - They were running an insecure, outdated version of sendmail on a Sun Unix platform (SMI/SVR4), and were listed in the MAPS RBL list. After I mailed them with the facts, the systems adminstrator Mr.D.Krishna Rao took prompt action to upgrade to sendmail 8.9.1 and secure their server (which was, therefore, removed from the RBL list). [2] VSNL - mailbg.vsnl.net.in ; giascla.vsnl.net.in ; bom4.vsnl.net.in No response yet - even after several months. The giascla server is currently in the RBL, cut off from 40% of the Internet. The other two are also slated for inclusion soon. Two are running SMI/SVR4 and the other is running Sendmail 5.6 - which is even older. [3] Tata Institute of Fundamental Research - tifr.res.in Again an SMI/SVR4 box. Based on a phone number mentioned in the spam, the spammer has been traced down and the details mailed to the TIFR sysadmin. The following may be of some use with regards to securing your server against spammers / hackers. Sendmail : The classic Unix MTA - it has been around for several years and is still extremely popular (and is free). Sendmail admins can see http://www.sendmail.org/tips/relaying.html which has quite a few useful bits of information. Sendmail builds lower than 8.8 are fundamentally insecure, and full of security holes. Additionally all versions of sendmail prior to 8.8.9 are susceptable to a HELO buffer overflow attack - and most recently, several thousand sendmail 8.8 installations have been exploited by a spammer using RCPT TO:<"victim@target"> - with the "" in the envelope. If you have one of these sendmail versions, disable or update it immediately and audit your machine's security. Sendmail Inc describe version 8.6 and earlier as "Not supported, not secure and should NOT be run on a network-connected computer." If you are running Sendmail 8.8, see Claus Assmann's check_rcpt Sendmail 8.8 antirelay patches, which fix relay vulnerablities using "", %, ! and : vulnerabilties in 8.8.x sendmail. Visit his page at http://www.sendmail.org/~ca/email/check.html for more details. More useful information is available at http://hexadecimal.uoregon.edu/antirelay/ Sendmail 8.8 is effectively unsupported and susceptible to a buffer overflow attack (caused when a HELO of over 1024 characters is sent). There are probably more relaying holes lurking in it. Sendmail 8.9.0 and 8.9.1 are susceptable to relaying attacks using the : pathing control character in the RCPT TO:<> header. Update to 8.9.x or later, or consider the latest beta for sendmail (sendmail 8.10.0.Beta6) which supports Authenticated SMTP. It also (amongst other things) has built in support for multiple dns based blacklists (like the RBL). When upgrading sendmail to secure versions: Always generate a new sendmail.cf - continuing to use the sendmail.cf from a previous version which had a relaying vulnerability will usually result in that relaying vulnerability not being fixed. If you are uncomfortable with M4 scripting, WIDE in Japan have a .cf generator which may be useful. It can be downloaded from ftp://ftp.jpcert.or.jp/pub/security/tools/CF/ If you need sendmail on a machine so that processes can send out mail, but no inbound mail facilities are needed, all you need to do is change sendmail's startup settings by removing the "-bd" flag. It's the -bd flag (-bD if run in the foreground) which tells sendmail to listen on port 25 and if that is deleted, it will only deliver locally generated mail rather than acting as a full-blown mailserver. Please note: this will only secure a server for as long as the -bd flag is disabled, so should be regarded as a temporary measure. Eventually, someone is bound to accidentally re-enable the -bd flag. Wherever possible, please update to sendmail 8.9.3 or later. Redhat linux users check out ftp://admin.netus.com/sendmail/ and download preconfigured, secure sendmail 8.9.3 rpms. Linuxconf users beware! - Linuxconf was found to be generating faulty (old) check_rcpt tables as recently as 20 July 1999. Make sure your version is newer than this before using it to generate sendmail.cf files. Sun Admins may see http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access for updates to sendmail 8.9.x. QMail - >From the QMail FAQ - - From the qmail FAQ http://www.qmail.org/qmail-manual-html/misc/FAQ.html#5.4. 5.4. How do I allow selected clients to use this host as a relay? I see that qmail-smtpd rejects messages to any host not listed in control/rcpthosts. I know I could entirely disable this feature by removing control/rcpthosts, but I want to be more selective. Answer: Three steps. First, install tcp-wrappers, available separately, including hosts_options. Second, change your qmail-smtpd line in inetd.conf to smtp stream tcp nowait qmaild /usr/local/bin/tcpd /var/qmail/bin/tcp-env /var/qmail/bin/qmail-smtpd (all on one line) and give inetd a HUP. Third, in tcpd's hosts.allow, make a line setting the environment variable RELAYCLIENT to the empty string for the selected clients: tcp-env: 1.2.3.4, 1.2.3.5: setenv = RELAYCLIENT Here 1.2.3.4 and 1.2.3.5 are the clients' IP addresses. qmail-smtpd ignores control/rcpthosts when RELAYCLIENT is set. (It also appends RELAYCLIENT to each envelope recipient address. See question 5.5 for an application.) Alternative procedure, if you are using tcpserver: Install tcpcontrol (http://pobox.com/~djb/tcpcontrol.html). Create /etc/tcp.smtp containing 1.2.3.6:allow,RELAYCLIENT="" 127.:allow,RELAYCLIENT="" to allow clients with IP addresses 1.2.3.6 and 127.*. Run tcpmakectl /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp Finally, insert tcpcontrol /etc/tcp.smtp.cdb before /var/qmail/bin/qmail-smtpd in your tcpserver line MS Exchange Update to MS Exchange 5.5 service pack 2 or later. Service pack 3 is available at http://www.microsoft.com/exchange/DeployAdmin/sp3.htm Also check out the MS Knowledge base articles - http://support.microsoft.com/support/kb/articles/q193/9/22.asp?FR=0 http://support.microsoft.com/support/kb/articles/q195/9/69.asp?FR=0 http://support.microsoft.com/support/kb/articles/q196/6/26.asp?FR=0 Microsoft have discovered a new vulnerability not yet being exploited by spammers. Details in q237927. There is a fully supported patch available - update now! - ftp://ftp.microsoft.com/bussys/exchange/exchange-public/fixes/Eng/Exchg5.5/PostSP2/imc-fix MS Exchange 5.0 can only be secured against unauthorised relaying by disabling all internal POP3/SMTP access. That is, all internal clients must be running Microsoft exchange software and third party clients like Eudora cannot be used after this. This is an ad hoc fix, because eventually someone will probably re-enable POP3/SMTP. Please update to MS Exchange 5.5sp2 or later as soon as possible. To quickly verify a machine: Any MS Exchange mailserver which shows a version number below 5.5.2448 on its SMTP port is unlikely to be fully secure. 5.5.2448 is only secure by explicit configuration as MS Exchange defaults to no relaying control MS IIS SMTP Service: See Knowledge Base article http://www.microsoft.com/exchange/DeployAdmin/sp3.htm Lotus cc:Mail: This is totally outdated, unsupported and full of security holes. If not properly setup, any mail sent to postmaster@[literal.IP.address] will cause the server to mailbomb itself into the ground with an infinite loop of bounce messages. Upgrade to Notes or use a firewall. Lotus Notes This can easily be secured and Lotus has recently released information on doing so: Update to Lotus Notes version 4.6.2 or later In NOTES.INI, set: SMTPMTA_REJECT_RELAYS=1 SMTP_OCH_REJECT_SMTP_ORIGINATED_MESSAGES=1 - (NOT "SMTPMTA_OCH_..") SMTPMTA_RELAY_FORWARDS=1 WARNING: If SMTPMTA_OCH_REJECT_SMTP_ORIGINATED_MESSAGES=1 is used, the host will still relay. Check your spelling! For Notes 5.x: The configuration document in the Domino Directory has a section for SMTP Inbound Controls. Enter a * in both of the following fields: "Deny messages from external internet domains to be sent to the following internet domains:" "Deny messages from the following external internet hosts to be sent to external internet domains:" Netscape Messaging Server - Netscape Messaging Server: Netscape's documentation is poor and the antirelay examples they provide are easily defeated. Among other holes, a spammer may set as many non-local RCPT TO:<> lines as he likes, as long as he sets at least one local RCPT TO:<> as the first recipient. Bob Poortinga has put together several pages detailing how to properly configure NMS to prevent relaying at http://www.tsc.com/~bobp/nms-no-relay.html. IMail - This is a popular NT based MTA - used by several NT mailservers. Imail 5.x can be secured with little effort. The only portion of it that is rough is advising remote users that they will have to use SMTP authentication to send mail. This just means checking a single control in most POP3 clients (Outlook / Eudora / Pegasus etc). They can set Relay For Addresses in SMTP Security and then only allow their local blocks or known, trusted blocks. If you have Admin access to port 8181 on the box you can set this there also, instead of hammering your sysadmean (if the mailserver is remotely hosted). MDaemon - Go to Setup | Relay Control and tick the "This Server Does Not Relay" Box. If the server doesn't host any "gateway" domains, this covers the majority of relay techniques. At this point, however, anybody claiming to be a local user in the MAIL FROM can still relay. Go to the IP Shielding window and enter the IP blocks from which legitimate users can originate mail. If desired, tick the "Insure Sender's Address..." box. Note that if the server hosts "gateway" domains, than ANY address at the gateway domain will be considered a valid local user regardless of the "Insure" box. You will also need to insert the valid IP blocks for the "gateway" domains or relaying will be enabled for anybody forging an address from a "gateway" domain. The big drawback to the way MDAEMON operates is that although it will now pass all of the relay tests I have been able to run on it, it also won't allow somebody with a local address to send email into it, whether directly or through another server. You will get a 500-series "domain.com is not allowed access from this location" message. For more information on securing other MTAs - visit the below pages (from where most of this information above has been taken). The MAPS TSI page - http://maps.vix.com/tsi/ar-fix.html ORBS http://www.orbs.org/otherresources.cgi Suresh Ramasubramanian | [EMAIL PROTECTED] Founder Member, CAUCE India Phone: +(91-40)3736553/3745398 | eFax: +(1-603)590-5437 Stop Spam | Join CAUCE | http://www.cauce.org
