Jeremy Kitchen wrote:

On Friday 23 December 2005 02:22 pm, FX wrote:
I don't see 'chmod 4755 vchkpw' at
http://www.inter7.com/vpopmail/install.txt but I'm seeing it on various
websites--are there added risks by doing this?


yes. if you have local users on the system, they can now use vchkpw to attempt to brute force authenticate vpopmail account passwords. Also, if vpopmail is configured to check /etc/passwd accounts, they can attempt to brute force these as well.
Thanks, I'm the only user and vpopmail isn't configured to check /etc/passwd.

[...]
One thing you could do to mitigate this is to make the vchkpw binary mode 4750, and set the group to say.. vchkpw. Then any user in the vchkpw group (which should not be many) can execute it, and users not in the group cannot.
Thanks for suggesting 4750. I've only seen 755, 6111 and 4755 suggested for vchkpw so I thought vchkpw might require the last bit for some reason.
Any reason 4750 is more appropriate than 4110 or 6110?

Basically, I'm wondering about this because I'm using
netqmail-1.05+chkuser-2.08b+vpopmail and considering using
CHKUSER_ENABLE_UIDGID feature of chkuser.

chkuser doesn't use vchkpw. If you want to use chkuser, you either have to make your smtp service run as a user who can read the vpopmail domains, or make qmail-smtpd setuid (not a good idea, since there's absolutely zero reason for qmail-smtpd to be setuid)
With chkuser, you can run qmail-smtpd as weak user 'qmaild' and if CHKUSER_ENABLE_UIDGID is defined, qmail-smtpd (if patched with chkuser) will switch to the vpopmail user only while executing chkuser operations. This only works when not using TLS.

"Used to switch between UIDS/GIDS, used if you want to apply a more safe mechanism, and if you're NOT using TLS (as TLS seems not to like switching of UID/GID). When not defined, qmail-smtpd must be executed as vpopmail user. When defined, qmail-smtpd runs as inoffensive qmail user, switching to vpopmail user only while executing chkuser operations."

What do you recommend?

I recommend you tell us what you're trying to do, precisely, and we can make a recommendation :)
I want to setup netqmail-1.05 + chkuser-2.08b + vpopmail-5.4.13 and I wanted to verify vchkpw permissions recommended on various sites before blindly using them. More precisely, I'm interested in using CHKUSER_ENABLE_UIDGID which allows me to run qmail-smtpd (patched with chkuser) as user 'qmaild'--and have qmail-smtpd automatically switch to user 'vpopmail' only while executing instructions that require vpopmail.

When I read the vpopmail install docs, it didn't mention recommended permissions for vchkpw. When I searched online, I came across 755, 6111, and 4755 which made me wonder why all users needed execute permission on it.

Also, you might pick up a book on UNIX security, so you can get a better understanding of how to run a secure UNIX system. :) I've been meaning to get one for myself for a long time, so let me know if you find a good one ;)

-Jeremy
Me too--I primarily work with MS Windows security and consider myself a UNIX noob.
But if you use Debian, this is a good place to start:

http://www.debian.org/doc/manuals/securing-debian-howto/

If you don't have time to read that, here are some suggestions I have for other beginners like me (don't worry--i won't recommend separate xen3/vmware selinux guest for each daemon this year):

0. hire/bribe/convince someone more experienced than you to review your setup no matter how obvious if there's any chance you (or your source of info) might be wrong 1. uninstall all programs & services you don't need or use--and keep the ones you use patched with latest security fixes 2. run bastille-linux script for the basics and read each screen (its a tutorial as well as hardening script) 3. use a packet filter to deny both incoming and outgoing packets by default--explicitely allow each incoming and outgoing port (specify IP or CIDR ranges allowed for each when possible)--do this on every machine, not just your firewall or servers. with shorewall, generating & managing proper iptables rules is super easy 4. use rate-limiting for new incoming connections, log messages, and alert emails 5. consider using an iptables queue program that drops all connections from countries not specifically allowed to connect to your server (combining geoip with iptables queue is trivial) 6. run each service in separate chroot if practical, remember to use a separate partition/drive for each chroot mount point and don't copy any files not specifically required 7. if running apache, use mod_evasive and mod_security behind a lightweight (no file access) reverse proxy like pound-1.9.5 8. if you have to run sshd, use a nonstandard port and/or use port-knocking. only allow 'sshclients' group members to connect and use password-protected keys instead using ssh protocol v2 only
9. use syslog-ng and log to a secured logging server on separate hardware

Reply via email to