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.