SOCKS proxy & PAM configuration exposure

I've got a problem with a proxy configuration. We have an LDAP group that lists all users who are authorised to use the proxy to FTP (usually Filezilla) out to the world, and by implication those not in the group should be denied. My users are delighted that this has been enabled and those that wish to get out can do so, however we're not stopping anyone not in the group (and therefore not authorised)

We found this out because I'm not authorised but whilst troubleshooting for a user I connected out no problem. That ended up being a user password problem, so they failed the LDAP check and so PAM prevented the connection.

I haven't got a test server so I will have to get a slot outside business hours (which will be a nightmare in itself) to try out my thoughts but I wanted to sanity check it first. The server is running CentOS The proxy server is SOCKS in /usr/sbin/ss5 and running as the root user.

My suspicion is about the PAM file, /etc/pam.d/ss5 and the way it has been set up. We have this:-

#%PAM-1.0
auth       include      system-auth
account    required     pam_nologin.so
auth       required     pam_wheel.so use_uid group=SocksUsers
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    required     pam_loginuid.so

My theory is that the line defining the allowed group also includes the use_uid option and given that the ss5 daemon is running as the super-user everyone is automatically authenticated. There is a proxy authentication required, but messages is /var/log/secure give me this when I authenticate to the proxy correctly and give invalid credentials to an internet-based FTP site:-

Nov 28 15:03:14 gateway-b ss5: pam_unix(ss5:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=donald.trump
Nov 28 15:03:14 gateway-b ss5: pam_winbind(ss5:auth): getting password (0x00000008)
Nov 28 15:03:14 gateway-b ss5: pam_winbind(ss5:auth): pam_get_item returned a password
Nov 28 15:03:14 gateway-b ss5: pam_winbind(ss5:auth): user 'donald.trump' granted access

Yes, some Windoze joker created me a test account with that name. Sorry about that. No political persuasion inferred, naturally - I'm British after all.

Before I try to get a slot, does anyone want to contradict my theory? I'd be grateful for avoiding unnecessary effort if I've gone off on the wrong track.

Many thanks, in advance,
Robin

Hi Robin,

What is in /etc/pam.d/system-auth ?

The content of /etc/pam.d/system-auth is below:-

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_winbind.so try_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     required      pam_access.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_winbind.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so

session     required      pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Have we done something really bad? Well, I suppose it's bad enough to allow anyone with a valid account :o

I know it's designed to be flexible and allow applications to abstract the authentication/authorisation etc. , but it is very confusing!

Apologies,
Robin

So, limited testing options have just left me with the theory unless anyone can suggest how I could set up a couple of servers to match. Basically, no there servers have access to the public internet, so I'm a bit stuck how I can do this without asking the network people to expose my test server to the public side - and that's another headache all together.

Am I missing something simple? I'm concerned to prove to myself that I would actually drive through a proxy to a dummy sftp server I can set up internally.

Robin - very confused

Hi Robin. Try putting

auth       required     pam_wheel.so use_uid group=SocksUsers

above:

auth       include      system-auth

Otherwise if

auth        sufficient    pam_winbind.so try_first_pass 

succeeds, then no further modules will be called in the pam_stack..

       sufficient
           if such a module succeeds and no prior required module has failed the PAM framework returns success to the application or to the superior PAM stack immediately
           without calling any further modules in the stack. A failure of a sufficient module is ignored and processing of the PAM module stack continues unaffected.

Thanks for the suggestion. I'd tried to read the manual pages but got rather goggle-eyed, so it is now smack-in-the-face obvious that we've got the order wrong.

I feel a fool for not spotting it :o

Mind you, I didn't do it in the first place, so it's not too bad. :rolleyes:

I will see if I can get this put in sometime and report back.

Kind regards,
Robin

Thanks for the pointers. I am pleased to report that we have changed /etc/pam.d/ss5 from this:-

#%PAM-1.0
auth       include      system-auth
account    required     pam_nologin.so
auth       required     pam_wheel.so use_uid group=SocksUsers
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    required     pam_loginuid.so

.... to this (grouping all the auth statements together too):-

#%PAM-1.0
auth       requisite	pam_succeed_if.so debug user ingroup socksusers
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    required     pam_loginuid.so

When we moved the rule up the order before the include statement, the use_uid meant that the rules were being applied to the account running the code, not the connecting user, i.e. it was testing the single account root for every connection.

Notes:-

• I've set this to be requisite to just exit if the account does not have the required group.
• I found that pam_succeed_if.so gave me the debug option for logging.
• The pam_succeed_if.so also can be extended if multiple acceptance criteria were required.
• The group appears to be case-insensitive, but shows as all lower case when running something like id rbatte1 | sed 's/) /)\n/g ; s/,/\n/g' | sort -nk1,1.5

I hope that this might be useful to someone else.

Robin

You can define a 'case ignore' in an LDAP schema for group names, for example.
This:
How to Add a Group Mapping Rule (Solaris CIFS Administration Guide)

mentions the fact that because windows group names in AD, LDAP's cousin, are case insensitive you have issues with group names in Solaris which are case sensitive. I never ran into this problem. And I assume that group names are case sensitive in most UNIXes.

How do you deal with this mishmash?

I think that all the groups are really given to us as lower case, but someone had tried to mix-case things to make it more readable. Sadly, we have some groups containing spaces, which messes up various things, like sorting output from ls -l looking for large files etc.

After more testing, it seems that our CentOS 6 install is ignoring the case of the group.  I'm not sure if we have coded to ignore case or it just does.  It might cause a problem for some though, I'm sure.

I hope that you are not wanting an expert opinion from me - I'm just muddling through :o



Robin

So, implementation has gone very well, until someone asked the question "How do we know users are not sharing passwords?" There are controls in place to force regular changing of password, but of course they could be shared too. Is there a way for pam to log (anywhere) the source IP addresses?

I've looked at pages for pam_debug.so but I can't understand it.

What I see in /var/log/secure is something like this:-

Mar  1 12:13:12 PRX002 ss5: pam_succeed_if(ss5:auth): 'user' resolves to 'donald.trump'
Mar  1 12:13:12 PRX002 ss5: pam_succeed_if(ss5:auth): requirement "user ingroup socksusers" not met by user "donald.trump"
Mar  1 12:13:51 PRX002 ss5: pam_succeed_if(ss5:auth): 'user' resolves to 'rbatte1'
Mar  1 12:13:51 PRX002 ss5: pam_succeed_if(ss5:auth): requirement "user ingroup socksusers" was met by user "rbatte1"

So I get a nice message that I'm allowed through and donald.trump is not. What would be nice is something more like sshd kicks out:-

Mar  1 13:24:40 PRX002 sshd[4523]: Accepted publickey for rbatte1 from 10.13.13.13 port 46960 ssh2

Is there a way to turn this sort of thing on? There is nothing useful in

• /var/log/messages
• /var/log/secure
• /var/log/audit/audit.log
• directory /var/log/ss5 is empty (and not referenced in /etc/rsyslog.conf either)

I'm sure pam is meant to be helpful, but it's very confusing.

Robin