OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: CIDR blocks & relay security...
From: Greg A. Woods (woodsweird.com)
Date: Sun Dec 10 2000 - 00:33:25 CST

[ On Sunday, December 10, 2000 at 13:09:50 (+1100), Craig Sanders wrote: ]
> Subject: Re: CIDR blocks & relay security...
>
> i'm not interested in opinion. i wanted a specific answer to a specific
> technical question. i.e. why isn't it possible to read the netmask along
> with the IP address?

No, It's not possible to look up the netmask and IP addresses of
interfaces portably, at least not without running another system
program.

I looked into this issue extensively during recent development work on
smail-3 and concluded that even on the most modern *BSD variants, the
only way to get anywhere is to run the /sbin/ifconfig command and then
filter the output based on what interfaces the smtpd is actually
listening on.

If I remember correctly the system calls (ioctls) used by /sbin/ifconfig
are not (so far as I could tell) completely portable between even NetBSD
and FreeBSD, for example (there are tricky differences between them on
how you find the list of interface names, for example, and these
differences even extend across versions of the same variant if you go
back far enough). If you want to dynamically test a given client
connection (and dynamic things are generally good to do when a daemon is
normally a long-running entity!) you'd have to ask via "/sbin/route get"
(or the system calls it uses) which interface a given remote client is
routed through in order to do the netmask lookup.

I did discover that if the *BSD SIOCGIFNETMASK ioctl() were enhanced to
work on any socket (instead of requiring an interface name be
specified), i.e. if the complications of looking the client address up
in the routing table to find the interface name and thus its netmask
where delegated to the kernel where the code that does this is already
in existence, then it might be "easy" to find out if a client was on the
local subnet or not. However without such a feature I think it's insane
to even try to find the netmask of the interface through which a client
connection arrived. Note this feature would obviously require kernel
modifications so would be highly unportable unless/until all systems you
cared about acquired similar changes.

Finally there's the issue that even if you go to all this trouble you've
still only identified directly attached subnets, and thus you've not
gotten any further than you'd get by simply looking for the client
address in the ARP table with "/usr/sbin/arp -n NNN.NNN.NNN.NNN" (other
than you'd not be making the assumption that the client was connected
with an interface that used ARP). Note too that /usr/sbin/arp was once
one of those evil /dev/kmem grovellers, and on at least one modern *BSD
(NetBSD) it now uses a special unprivileged sysctl(2).

Also, isn't the assumtion that any other client on a directly attached
local subnet where you might be listening is allowed to relay through
you a rather risky assumption in the first place? If your ISP's router
is on one of those subnets is it authorised to relay through your server
simply because of this?

In the end I believe for the purposes of SMTP relay authorisation
there's no sense whatsever in trying to guess whether the client is on a
directly attached subnet, regardless of how you might go about doing it.
(I did keep the "localnet" magic keyword in smail-3 for now, though it
will not be used in the default setting of smtp_remote_allow, and it
still only refers to the traditional class-full network).

In addition I personally don't think removal of any code which guesses
the netmask of a local TCP endpoint would make Postfix into "software
that refuses to work until the user changes the default settings" -- my
take on it is that all SMTP daemons should, by necessity and by design,
refuse to relay e-mail for any and every client, BY DEFAULT. Enabling
of any relaying should always require explicit specification of all
individual client addresses and/or address blocks which are authorised
to relay mail via the relay host in question. 

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoodsacm.org>      <robohack!woods>
Planix, Inc. <woodsplanix.com>; Secrets of the Weird <woodsweird.com>