I've encountered an issue in trying to setup an iptables firewall (shorewall) on a debian etch server (hostname zeus). Zeus is a NIS client retrieving account info from a NIS server somewhere in our infrastructure.
I setup a preliminary/testing list of firewall rules which doesn't include any rules for NIS, with the default rule for the NIS serverzeus conversation to DROP. I've included an ssh rule which allows everyone to ssh to zeus. The 1st twist is that I have disabled user logins on zeus, via PAM, and only root can ssh to that machine. The 2nd twist is that the root account is local to zeus i.e. there's no root account in the NIS database, so all ssh root@zeus authenticate locally.
So far, so good. My firewall rules should allow something like ssh root@zeus since the authentication is done locally and no NIS operations are required for root to be granted access.
A final thing is that I ssh to zeus using pubkey authentication.
The thing is that this setup doesn't work. The ssh -vvv command shows that the client I ssh from, sends the pubkey and then sits there waiting for zeus to reply. No reply...
After a few hours I suspected that NIS has something to do with this problem. I stop the NIS client on zeus and, voila, the whole thing works like a charm, I ssh with no problems.
I start ypbind on zeus again. In order to verify that NIS is indeed the source of my problems, I tcpdump the conversation between zeus and the NIS server and it seems that whenever I ssh to root@zeus from a client, NIS kicks in and zeus query the NIS server. Since there is no firewall rule which allows NIS to take place between zeus and the NIS server, ssh fails.
Remember I use pubkey authentication.
I have several questions regarding this problem. a) Is there a way to instruct ssh mechanism to try pubkey authentication 1st and IF that fails to try password authentication? b) Suppose I don't use pubkey authentication. Since the root@zeus account is local how can I instruct PAM to check only /etc/passwd and NOT NIS? c) A more generall question. How does PAM interact with /etc/ nsswitch.conf - zeus's nsswitch.conf uses the compat option for passwd, groups and shadow entries and /etc/passwd has a +:::::: at the end. d) Another option would be to include a firewall rule which would allow zeus to talk to the NIS server. A while different discussion I suspect since ypbind on debian etch doesn't allow you to bind a specific port (-p option) to it. RPC nightmare..... So I wouldn't want to go down that track. Plus I'd really like to know why this NIS @#!@# takes place, when I ssh using pubkey (ie no password checking) on a local (non NIS) account.
thx for reading my huge post. vassilis
Les réponses au message de Billis (vvatikiotis@gmail.com)
Billis wrote: > I've encountered an issue in trying to setup an iptables firewall > (shorewall) on a debian etch server (hostname zeus). Zeus is a NIS > client retrieving account info from a NIS server somewhere in our > infrastructure. > I setup a preliminary/testing list of firewall rules which doesn't > include any rules for NIS, with the default rule for the NIS server> zeus conversation to DROP. I've included an ssh rule which allows > everyone to ssh to zeus. The 1st twist is that I have disabled user > logins on zeus, via PAM, and only root can ssh to that machine. The > 2nd twist is that the root account is local to zeus i.e. there's no > root account in the NIS database, so all ssh root@zeus authenticate > locally. > So far, so good. My firewall rules should allow something like > ssh root@zeus > since the authentication is done locally and no NIS operations are > required for root to be granted access. > A final thing is that I ssh to zeus using pubkey authentication. > The thing is that this setup doesn't work. The ssh -vvv command shows > that the client I ssh from, sends the pubkey and then sits there > waiting for zeus to reply. No reply... > After a few hours I suspected that NIS has something to do with this > problem. I stop the NIS client on zeus and, voila, the whole thing > works like a charm, I ssh with no problems. > I start ypbind on zeus again. In order to verify that NIS is indeed > the source of my problems, I tcpdump the conversation between zeus and > the NIS server and it seems that whenever I ssh to root@zeus from a > client, NIS kicks in and zeus query the NIS server. Since there is no > firewall rule which allows NIS to take place between zeus and the > NIS server, ssh fails. > Remember I use pubkey authentication. > I have several questions regarding this problem. > a) Is there a way to instruct ssh mechanism to try pubkey > authentication 1st and IF that fails to try password authentication? > b) Suppose I don't use pubkey authentication. Since the root@zeus > account is local how can I instruct PAM to check only /etc/passwd and > NOT NIS? > c) A more generall question. How does PAM interact with /etc/ > nsswitch.conf - zeus's nsswitch.conf uses the compat option for > passwd, groups and shadow entries and /etc/passwd has a +:::::: at the > end. > d) Another option would be to include a firewall rule which would > allow zeus to talk to the NIS server. A while different discussion I > suspect since ypbind on debian etch doesn't allow you to bind a > specific port (-p option) to it. RPC nightmare..... So I wouldn't want > to go down that track. Plus I'd really like to know why this NIS @#!@# > takes place, when I ssh using pubkey (ie no password checking) on a > local (non NIS) account.
NIS is used for more than just authentication. If permissions are checked, then NIS will get used.
Try disabling SSH's PAM (UsePAM no) via sshd_config and restart your SSH daemon. See if that still causes a problem. If not, then certainly some check inside of the pam stack is to blame.
> NIS is used for more than just authentication. If permissions are > checked, then NIS will get used. Even for local only accounts?
> Try disabling SSH's PAM (UsePAM no) via sshd_config and restart > your SSH daemon. See if that still causes a problem. If not, > then certainly some check inside of the pam stack is to blame. Will try tha thx.
Anything on the relationship of nsswitch.conf and PAM and how they interact with eachother? Any documentation/howto/etc you can point me to?
Stachu 'Dozzie' K. wrote: > On 09.08.2007, Chris Cox wrote: >> NIS is used for more than just authentication. If permissions are >> checked, then NIS will get used. > Eh? When and how? I thought that NIS serves mapping between usernames > and UIDs, and permissions are usually saved with UIDs instead of > usernames.
A script might do an ls -l or something that will do a uid to name mapping, etc. It's just one of those things that can trip you up. It's one of the reasons why you run a nscd with NIS, but of course, that in itself can cause a world of grief since it caches everything, including password data.
Stachu 'Dozzie' K. wrote: > On 10.08.2007, Chris Cox wrote: >> Stachu 'Dozzie' K. wrote: >>> On 09.08.2007, Chris Cox wrote: >>>> NIS is used for more than just authentication. If permissions are >>>> checked, then NIS will get used. >>> Eh? When and how? I thought that NIS serves mapping between usernames >>> and UIDs, and permissions are usually saved with UIDs instead of >>> usernames. >>>> A script might do an ls -l or something that will do a uid to name >> mapping, etc. > Ah. So it's not checking the permissions (which statement suggests > some access control), it's just displaying ownership.
The problem is that many things do uid to name lookups (including security related things... because your uid COULD change). But nscd can be a pain just because of the password change issue.... though you can understand why a caching daemon helps in a yp world.
On 10 Aug, 10:42, billis wrote: > > NIS is used for more than just authentication. If permissions are > > checked, then NIS will get used. > Even for local only accounts?
How can you tell it's local? There is a specified order for various things to be looked up, in /etc/nsswitch.conf. But many graphical tools automatically reset it to an order you may *not* want when they parse and re-write that table. It's tricky to preserve.
Look, NIS is a serious security and integration problem and has been for years. For example, the insistence by Sun's NIS variant on using / etc/passwd and /etc/shadow and /etc/group and /etc/gshadow *and publishing system accounts with uid's less than 500* has been breaking client software for many years.
NIS should *NEVER, NEVER, NEVER* publish the root and other low numbered UID's, because if you're not extremely careful with your client setups, the NIS published root password *will* be accepted on every client machine. And it mucks up the "useradd" command for accounts like "nagios" or "nrpe" that should be local.
Don't believe me? Try it, and let me know which distribution your client is. running so I can remember that that client did it right.
> > Try disabling SSH's PAM (UsePAM no) via sshd_config and restart > > your SSH daemon. See if that still causes a problem. If not, > > then certainly some check inside of the pam stack is to blame. > Will try tha thx. > Anything on the relationship of nsswitch.conf and PAM and how they > interact with eachother? Any documentation/howto/etc you can point me > to?
I'd grab a PAM book: from the last time I had to manipulate it for internal use, it was a bit tricky.
What I wound up doing for a setup like yours was using a local NIS server and slave, and setting the NIS server to grab the NIS tables from the company master and stripping out the low UID's. User passwords were being done from Windows in a weird shared upstream Oracle approach talking with their Active Directory servers, so my NIS slave didn't have to publish any changes upstream.
It was vastly, vastly safer than having NIS publish those low-numbered system accounts.
Stachu 'Dozzie' K. wrote: > On 10.08.2007, Chris Cox wrote: ... >> The problem is that many things do uid to name lookups (including >> security related things... because your uid COULD change). > Any example? You can have many logins for given UID, and I would say > that it's more common case.
I didn't mean to suggest it WOULD change... but in all fairness, in my own experience, I've had to change UID number more often than usernames (because of collisions, etc with other NIS).
>> But nscd >> can be a pain just because of the password change issue.... > You know, the nscd man page (Linux one) says that shadow file isn't > cached at all. I'm not sure if it applies to database, not only the > plain file, but since nscd is supposed to cache getpw* and getgr* > calls...
Ok... it is true that you can push a shadow map, but that's not portable in a mixed *ix environment. In a portable NIS environemnt it's the caching of passwd that causes grief with regards to nscd.
Of course, eventually the client WILL have the right password... but it's just another security hole while it's cached.
Nico wrote: > On 10 Aug, 10:42, billis wrote: ... > NIS should *NEVER, NEVER, NEVER* publish the root and other low > numbered UID's, because if you're not extremely careful with your > client setups, the NIS published root password *will* be accepted on > every client machine. And it mucks up the "useradd" command for > accounts like "nagios" or "nrpe" that should be local.
I certainly agree with that, but you know, the default Makefile on most commercial *ix boxes do not include a UID threshold and so by default, they'll export them all. I was impressed that SUSE actually thought of restricting it.
> Don't believe me? Try it, and let me know which distribution your > client is. running so I can remember that that client did it right. >>> Try disabling SSH's PAM (UsePAM no) via sshd_config and restart >>> your SSH daemon. See if that still causes a problem. If not, >>> then certainly some check inside of the pam stack is to blame. >> Will try tha thx. >>> Anything on the relationship of nsswitch.conf and PAM and how they >> interact with eachother? Any documentation/howto/etc you can point me >> to? > I'd grab a PAM book: from the last time I had to manipulate it for > internal use, it was a bit tricky.
nsswitch.conf precedes pam. So, it was used to create a set of sources for various "name" services. But you are right, a pam stack also allows you to configure a set of sources (for more than merely name services).
So there can be some overlap.
> What I wound up doing for a setup like yours was using a local NIS > server and slave, and setting the NIS server to grab the NIS tables > from the company master and stripping out the low UID's. User > passwords were being done from Windows in a weird shared upstream > Oracle approach talking with their Active Directory servers, so my NIS > slave didn't have to publish any changes upstream. > It was vastly, vastly safer than having NIS publish those low-numbered > system accounts.
If you are using SUSE/openSUSE, by default the lower UIDs aren't pushed and there are variables in the /var/yp/Makefile that you can tune.
Billis wrote: Nico: No lower UID are published, the emphasis on 'are' (present tense). I inherited this system and indeed root and lower uids were published but not anymore. getent on the client reports only the local root account on the client. Same goes for all low UID accounts.
Our NIS server is a solaris 9 machine and all I had to is add - root:x:::::: at the end of the /etc/passwd. Im not sure though what that imples. Our NIS client doesn't retrieve any root/lowUID information, other than its local accounts. So it seems this is fixed. But when I check the NIS map files (under /var/yp), the root acc information is still there. To my absolute horror, on the NIS server *was* possible to do a ypcat passwd | grep root and there you could have the root hashed password....shudder. Is there any way to edit the NIS map files and remove all sensitive information altogether? I haven't found anything about removing a NIS user from the NIS maps and it seems that the -user mechanism doesn't do that, instead it excludes the particular account from the NIS service. Oh and the map files under /var/yp are binary, so manually editing doesn't seem very likelly.
But the problem still remains, the account info is still stored in the passwd.byname/passwd.byuid files in /var/yp. Any suspected user could use ypcat locally (on the NIS master) to query the database. The horror....
chris: the tweak on the sshd_config worked like a charm. The other alternative was to fiddle with the PAM stack for the ssh service. Didn't want to take that road since.
A last question concerning ypbind. I've seen that some implementations can bind to a fixed port using the -p option. Unfortunately ypbind from the default Debian repositories doesn't support that option. Any ideas on where I could a package with a suitable version of ypbind?
On 14 Aug, 15:07, billis wrote: > billis wrote: > Nico: No lower UID are published, the emphasis on 'are' (present > tense). I inherited this system and indeed root and lower uids were > published but not anymore. getent on the client reports only the > local > root account on the client. Same goes for all low UID accounts. > Our NIS server is a solaris 9 machine and all I had to is add - > root:x:::::: at the end of the /etc/passwd. Im not sure though what > that imples. Our NIS client doesn't retrieve any root/lowUID > information, other than its local accounts. So it seems this is > fixed.
You're basically screwed. The NIS server for SunOS and Solaris have *NEVER* properly filtered out the lower UID's from the password files they use. If you keep your own passwd and groups and other /etc/ files in /var/yp instead of using the system files, you can generate and manipulate them for NIS only, but it makes synchronization with the server password database nightmarish. They may do this now for Solaris 9 and 10, but I was battling this way back in SunOS 4.1.2.
The Linux implementation is vastly more sensible.
> But when I check the NIS map files (under /var/yp), the root acc > information is still there. To my absolute horror, on the NIS server > *was* possible to do a ypcat passwd | grep root and there you could > have the root hashed password....shudder. Is there any way to edit > the > NIS map files and remove all sensitive information altogether? I > haven't found anything about removing a NIS user from the NIS maps > and > it seems that the -user mechanism doesn't do that, instead it > excludes > the particular account from the NIS service. Oh and the map files > under /var/yp are binary, so manually editing doesn't seem very > likelly.
It's not a map file problem. It's a basic NISi configuration problem, either in the Makefile settings or in the original ypinit settings. I'd have to dig into a Solaris box to find out if it supports the options.
Frankly, I find it safer to make a small, secure *Linux* box the NIS server and publish to Solaris slaves as necessary due to exactly this sort of silliness.
> chris: the tweak on the sshd_config worked like a charm. The other > alternative was to fiddle with the PAM stack for the ssh service. > Didn't want to take that road since. > A last question concerning ypbind. I've seen that some > implementations > can bind to a fixed port using the -p option. Unfortunately ypbind > from > the default Debian repositories doesn't support that option. Any > ideas > on where I could a package with a suitable version of ypbind?
RedHat or CentOS 5? Debian has versions, I assume you're using a current Debian?
On Aug 15, 2:59 am, billis wrote: > > RedHat or CentOS 5? Debian has versions, I assume you're using a > > current Debian? > Debian's ypbind doesn't have that option.... Strange for such a nice > distro
Doh, ypbind's man page in Debian is probably outdated since it doesn't report a -p option available. a ypbind --help does show that the -p option is available though. Solved, thx vassilis
Vulnerabilite.com ne peut être tenu responsable des propos tenus dans le Newsgroup comp.os.linux.security
Message de Chris Cox (ccox_nopenotthis@airmail.net) (10 Aout 2007)
