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 nonstandar
