NIS+PAM+SSH+Firewalling.....all in the mix - Security

This is a discussion on NIS+PAM+SSH+Firewalling.....all in the mix - Security ; 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 ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: NIS+PAM+SSH+Firewalling.....all in the mix

  1. NIS+PAM+SSH+Firewalling.....all in the mix

    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.

    thx for reading my huge post.
    vassilis


  2. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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.

  3. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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.

    --
    Secunia non olet.
    Stanislaw Klekot

  4. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    > 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?


  5. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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.

    NIS can create a LOT of traffic to the yp server.


  6. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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.

    --
    Secunia non olet.
    Stanislaw Klekot

  7. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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.

  8. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    On 10.08.2007, Chris Cox wrote:
    > 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).


    Any example? You can have many logins for given UID, and I would say
    that it's more common case.

    > 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...

    --
    Secunia non olet.
    Stanislaw Klekot

  9. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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.


  10. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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.


  11. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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.


  12. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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?






  13. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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?


  14. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    > 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


  15. Re: NIS+PAM+SSH+Firewalling.....all in the mix

    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


+ Reply to Thread