[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 28 Dec 2008 23:18:28 +0300
From: Solar Designer <solar@...nwall.com>
To: popa3d-users@...ts.openwall.com
Subject: Re: user restrictions
On Fri, Dec 26, 2008 at 01:15:43PM -0500, Steve Bailey wrote:
> Is there a way to assign an IP range (10.0.0.0/8) as internal and allow all users to connect from those addresses and then to limit which users are able to POP from outside IP addresses?
There's no such built-in feature in popa3d, and I don't think there
should be one. However, you can implement this in a number of ways.
You have not provided any detail on your current setup, so I can't
provide specific instructions.
If you're on a system with PAM, you can build popa3d with PAM support,
then configure a stack of PAM modules to implement what you need. For
example, on Linux-PAM you may use the bundled pam_access module.
Alternatively, you may run two instances of popa3d - put them on
different IP addresses using DAEMON_ADDR in params.h or using an
equivalent feature of your inetd clone (such as "bind = ..." with
xinetd). Then use a packet filter (such as iptables on Linux),
libwrap (if popa3d or your inetd clone is built with libwrap support),
or a built-in feature of your inetd clone to limit access to one of the
instances, if that is needed. (It is possible that merely "binding" one
popa3d instance to a "private" IP address will be sufficient under your
setup, eliminating the need for any packet filtering or the like.) In
the instance that remains available for connections from "outside" IP
addresses, use either pam_listfile (needs PAM) or a forward-port of this
patch to a current version of popa3d (doesn't need PAM):
http://www.openwall.com/popa3d/contrib/popa3d-0.4-allowdeny.patch.gz
> What we are trying to do is only let certain users access their accounts via pop from outside our network but they all need to access from inside.
Understood. Please note that even if users are denied access, they may
still happen to "reveal" their passwords (to someone observing Internet
traffic) when they try to login. User authentication and authorization
is only done after the PASS command is received. If you want to reject
those unauthorized logins earlier - after the USER command, but before
PASS, you'll need to patch the code on your own. One drawback of such
change is that it will allow for easy probing of either permitted or
denied usernames (depending on how you implement this) from the remote.
I hope this helps.
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
