Re: [cobalt-security] RaQ550: Potential open relay - even with POP-before-SMTP

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

Hi Graeme,

> What on *earth* is that first netmask? Surely, surely that's a typo...

Yeah, it was not only a typo, it's was a brainfart of mine which slipped in 
when I composed the message. Sorry for that. :o(

The netmask was of course 255.255.255.224.

> > 1) It appears that the GUI interface of the RaQ550 allows relaying
> > for network address ranges instead of single IP addresses.
>
> It always has done. This is because it "mirrors" the functionality of
> sendmail's access file, which allows the same thing. (one point to
> Cobalt)

I wouldn't rate that as a point for Cobalt as all the other RaQs (and the 
Qube) entered the IP address(es) and not networks in the access file. Just 
the RaQ550 does it differently and for no good reason I'd say.

> > 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".
>
> Correct; this is probably by design and is absolutely normal operation
> for a great many GUI admin or control panel bolt-ons to UNIX systems
> (one more point to Cobalt).

When you look at the script in question (RaQ550 
/usr/sausalito/handlers/base/email/access.pl) you'll see that using the 
netmask is programming wise the easiest approach. If you'd have to single out 
all the individual IP addresses which should be allowed to relay, then you 
need a lot more programming effort. The easy way which was chosen is 
unfortunately much more insecure and allows more IPs to relay than you 
usually would want.

The question remains:

If you enter the primary IP address and network as 
62.138.160.164/255.255.255.224, why should the RaQ550 then alow relaying of 
emails for the entire 62.138.0.0/16 network? Even if it had restricted it to 
62.138.160.0/24 that would have been a bit too much in certain circumstances. 

Depends who's in the same subnet with your box. In a large colo center with a 
rented RaQ550 this could be quite uncomfortable.

> Hmm... this sounds Just Plain Wrong. I've just checked a couple of 550s
> I have here, and - to my horror - they are on a /24 network and allow
> relaying for that entire /24 (one more point to Michael).

Yeah.

> > 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.
>
> I'd check that there's no interface aliases left hanging around if I
> were you. Unfortunately I'm looking at a customer machine so I cannot go
> adding/removing IP addresses!

I checked for interface aliasses and it is clean:

[root network-scripts]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:10:E0:05:E9:EA
          inet addr:192.168.9.1  Bcast:192.168.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:349533 errors:0 dropped:0 overruns:0 frame:0
          TX packets:371055 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:5 Base address:0xa000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:180689 errors:0 dropped:0 overruns:0 frame:0
          TX packets:180689 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

Additionallly /etc/sysconfig/network-scripts/ contains only one ifcfg-eth* 
with the correct settings related to the 192.168.9.1 IP, so that old 62.138 
network entry in /etc/mail/access had no longer a business of being there.

-- 

With best regards,

Michael Stauber