Hi all, I'm just sorting through the train-wreck of a SPAM attack on one of my RaQ550's and I've got a hard time believing what I see there.
Sun Cobalt, you didn't do your homework! Some background info on that particular RaQ550: This RaQ550 used to have the IP address 62.138.160.164 and the netmask 62.138.160.224. However, some time ago the IP address was changed to 192.168.9.1 and the netmask to 255.255.0.0 as the box was moved behind a firewall. >From that point on the public IP address 62.138.160.164 was forwarded to the internal 192.168.9.1 IP address. There is just a single site on that box - the primary site: merkava.smd.net In the GUI Interface "Email Server Settings" / "Advanced" there were never made any additions or changes with the exception of the activation of "POP Authenticated Relaying" to dissalow unwanted relaying. Now take a look at /etc/mail/access - which was never edited manually: ------------------------------------------------------------------------------------------------ # # /etc/mail/access # # This file is automatically generated # Please put custom changes at the end # Cobalt Networks 1999 # Put custom additions below (Do not change/remove this line). # Cobalt Access Section Begin 62.138 RELAY smd.net RELAY 192.168 RELAY # Cobalt Access Section End ------------------------------------------------------------------------------------------------ Regardless if you use "POP Authenticated Relaying" or not, this setting allows anyone from the Subnets 62.138.0.0/16 and 192.168.0.0/16 to relay email through this box. Sorry, but THIS is madness. Isolation of the problem: =================== 1) It appears that the GUI interface of the RaQ550 allows relaying for network address ranges instead of single IP addresses. It also appears that the decission as to which network address ranges are used is based on the netmask you specify in "System Settings" / "TCP/IP". I checked with a couple of RaQ550s and some allow to relay for the entire Class C network they belong to. Some allow the entire Class B network to which they belong. And the craziest case I had is a customers box which allows an entire Class A network to relay and all domains of the DE domain (DE = Germany). 2) Why does the GUI not purge network settings which are no longer in use from /etc/mail/access? After all, the RaQ's primary IP address is now 192.168.9.1 with the netmask 255.255.0.0. So as soon as the network settings of the RaQ were changed the old entry concerning the 62.138 network should have been removed from /etc/mail/access when the network settings were changed. For comparance lets check a RaQ4: ============================== Here an /etc/mail/access from a RaQ4: ------------------------------------------------------------------------------------------------ # # /etc/mail/access # # This file is automatically generated # Please put custom changes at the end # Cobalt Networks 1999 smd.net RELAY www.smd.net RELAY 192.168.10.2 RELAY 192.168.10.3 RELAY # Put custom additions below (Do not change/remove this line). ------------------------------------------------------------------------------------------------ As you can see, each individual IP address which the virtual sites use is listed individually and is individually allowed to relay. Combined with POP-before-SMTP this pretty much locks down Sendmail and stops most forms of unwanted relaying. IMPLICATIONS: ============= If you operate a RaQ550 on a public IP address, then there is the high potential risk that your server allows more hosts and networks to relay email through you than desired. Depending on the netmask you specified it is possible that entire Class A, Class B or Class C networks are allowed to relay email through your box. Regardless if you are using "POP Authenticated Relaying" or not. That's the definition of an open relay. FIX: ==== /usr/sausalito/handlers/base/email/access.pl needs a serious overhaul. It should no longer allow relaying based on the netmask. Instead relaying should only be allowed for those individual IP addresses which were assigned to both the primary site as well as the virtual sites. Furthermore upon the change of an IP address of a virtual site or the change of the primary IP address old entries should be purged from /etc/mail/access -- With best regards, Michael Stauber _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
