SUMMARY: Prohibit login through specific service

From: Nobuhira Kaminaga (kaminaga@tokyo.cwomnes.net)
Date: Thu Feb 18 1999 - 23:49:45 CST


I made security related questions in two separated posting in recently. They
are:

        Titled: Access control

                Can I control access to services (ex. ftp, telnet, etc.) under
                Solaris from any or specific network/host/port ?

                I can't deploy Solstice Firewall for this purpose due to
                budget limitation. Can I do it only with Solaris ? Or if it
                can't be done only with Solaris, is there any appropriate
                freeware to make this kind of control ?

        Titled: Prohibit login through specific service

                Can we allow/prohibit under Solaris access to specific service
                for each account like as follows ?:

                        - root can't access to Solaris via telnet. So system
                          administrator needs to login to Solaris by telnet
                          with ordinary user account at first and then needs
                          to use "su" command to becomes root.
                        - Some accounts can't access to Solaris via ftp.

I had responses from peoples listed at the end of this message and I found
duplication in answers for two separated posting since these two postings
cover same area. So I integrated answers for two postings into one and
summarized as you see at the end of this message.

Thank you for your attention,

Nobuhira

A. Control root login behavior

        Make one of followings for the line in /etc/default/login:

        1. "CONSOLE=/dev/console" to allow root's interactive login only at
           console ("su" command works for remote interactive session)
        2. "CONSOLE=" to disallow root's interactive login completely
           ("su" command works for remote interactive session)
        3. Comment "CONSOLE=" line to allow any root's interactive login

   Refer http://docs.sun.com:80/ab2/coll.47.4/SYSADMIN1/@Ab2PageView/idmatch(SECSYS-11995)?#SECSYS-11995
   for more information.

B. "r" services can be controlled by /etc/hosts.equiv

C. Create a flat file called /etc/ftpusers. One-user-per-line, list the
   users that should NOT have access to ftp.

D. And/or use ftp.deny & ftp.allow files

E. If people can get access from an ftp session make sure their shell is in
   /etc/shells. If you want to prohibit people then remove their shell from
   /etc/shells. They all want the same shell? Then copy ksh to ksh.no.ftp and
   give the second shell to the accounts that are not allowed access via ftp
   and leave the first in /etc/shells.

F. Set the user's shell to something like /bin/nosh which will make login
   impossible

G. Comment line for the service in /etc/inet/inetd.conf to disable the
   service completely.

H. As for using telnet you do realise the ordinary user and root passwords
   will be transmitted in the clear over the network. Have a look at ssh
   the secure shell. It may be used with tcpwrappers as well with
   the added advantage that everything is encrypted. Pop over to
   http://www.ssh.fi/.

I. Wietse Venema's TCP wrappers which can be found at:
 
        ftp://ftp.porcupine.org/pub/security/
        ftp://info.cert.org/pub/tools/tcp_wrappers
        ftp://coast.cs.purdue.edu/pub/tools/unix/tcp_wrappers/
        ftp://ftp.win.tue.nl/pub/security/
        http://www.cert.org
        http://www.ugu.com/

J. Firewall

   Try obtaining drawbridge v2.0 from Texas A&M University anonymous FTP.
   This runs on a DOS v5.0 PC and acts as a firewall which can control system
   access on a network, host, and port basis.

   You can get a freeware packet filtering firewall from
   http://www.cyber.com.au/cyber/product/ipfilter/.

K. Also look at the tcpserver package from
   ftp://koobera.math.uic.edu/www/software/ucspi-tcp-0.84.tar.gz

L. Special thanks to following peoples:

        Bryan Blackburn <blb@pobox.com>
        Robin Brown <ROBIN_BROWN@phl.com>
        Heidi Burgiel <burgiel@math.uic.edu>
        N. Chandrasekhar <nchandra@wipinfo.soft.net>
        Ameet Chaubal <achaubal@admin.tavsnet.com>
        Benjamin Cline <benji@hnt.com>
        Roy Culley <tgdcuro1@gd2.swissptt.ch>
        Ray Delaney <rdelaney@bbt.com>
        Casper Dik <casper@holland.Sun.COM>
        Charles Donelle <Charles.Donelle@microcell.ca>
        David Evans <DJEVANS@au.oracle.com>
        Dave S. Foster <foster@bial1.ucsd.edu>
        Gary Franczyk <gfranczyk@carbomedics.com>
        Charles Gagnon <charlesg@Basit.COM>
        Jeff Kennedy <jeff.kennedy@natdecsys.com>
        Jeffrey C. Keyser <jkeyser@frycomm.com>
        Brooke King <jbking@sandia.gov>
        Michael Kriss <kriss@fnal.gov>
        Brion Leary <brion@dia.state.ma.us>
        Eric Lewandowski <eric@disco.cs.odu.edu>
        Timothy Lorenc <lorenct@load.com>
        Dave McFerren <davem@solve.net>
        Alan Orndorff <dwarfie@mindspring.com>
        Eric D. Pancer <eric@outlook.net>
        Dwight Peters <dpeters@nswc.navy.mil>
        Greg Sawicki <sawicki@shell1.interlog.com>
        Rik Schneider <rik@netasset.com>
        Michael Shealy <Michael.Shealy@delta-air.com>
        Umesh C. Singhal <usl@ho.wipro.co.in>
        Eric Sobalvarro <eric@razorjack.com>
        Matthew Stier <Matthew.Stier@tddny.fujitsu.com>
        Michael Sullivan <mps@discomsys.com>
        Mike van der Velden <mvanderv@yahoo.com>
        Sam Vilai <sam.vilain@nz.unisys.com>
        Karl Vogel <vogelke@c17mis.region2.wpafb.af.mil>
        John Weekley <weekleyj@inlink.com>
        Nickolai Zeldovich <kolya@zepa.net>



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:15 CDT