[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vchkpw
Subject:    Re: [vchkpw] chmod vchkpw file if using CHKUSER_ENABLE_UIDGID?
From:       FX <gentoo () sbcglobal ! net>
Date:       2005-12-24 3:33:26
Message-ID: 43ACC186.7070700 () sbcglobal ! net
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]