Login Access HOWTO

Login Access HOWTO


        If there are any questions or comments, please direct them to
walt@erudition.net. The newest copy of this HowTo can always be retrieved
from www.freebsd-howto.com. All rights for the reproduction of this
document are reserved.


	This HowTo will deal with all aspects of the login.access(5)
facilities to control remote and local logins on a FreeBSFD system.

        1.      Background

	        1.1.    TCPD vs. login.access

        2.      login.access(5) Entry Format
	        2.1.    Overview of Fields
	        2.2.    Example Entries

		        2.2.1.  Managing Console and Local Logins
		        2.2.2.  Managing Remote Logins

        3.      Default Access Strategy

	        3.1.    Default Deny Access Strategy

        4.      Appendix

	1.	Background

	There are a number of ways to manage login access on FreeBSD
systems. An older, but still useful method is login.access(5). A newer and
widely used method is tcp wrappers. Each have their advantages and
disadvantages. This HowTo will focus primarily on the usage

	When a login attempt is made, be it remote or local, the login(1)
program is invoked. All login attempts are prompted with a login and
password prompt. Following this, if either the user does not exist, the
password is incorrect for an existing user, or there is an access failure
for the user when /etc/login.access is checked, the login attempt will

	1.1.	TCPD vs. login.access

	TCPD, also known as tcp wrappers, which is now built into the
FreeBSD base system as of 3.3-RELEASE, offers two significant advantages.
Firstly, not only can it be used to control access to shell logins, but
also ftp and any other service. Secondly, because tcp wrappers wrap
services, someone who does not have access does not even see the service
prompt. For instance, they would not even see the login prompt. This is
because tcp wrappers control access according to hostmasks, and do not
have to determine if a particular user has remote access permission or

	Conversely, the login.access(5) facility is based on user access.
Because it has to determine what user's login is being attempted prior to
allowing or denying access, all login prompts filtered only via
login.access(5) are seen by everyone. Secondly, it can only be used for
shell logins and can not be used to control access for any service as
login(1) is the only login program that uses login.access(5) to control
login access. Morever, even the shell login access permission is now
limited with the advent of sshd(8), as sshd(8) does not by default use
login(1) for logging users into the system, however, sshd can be set to
use login(1), in which case the login.access(5) facility will still be
enforced with ssh(1) logins.

	2.	login.access(5) Entry Format

	2.1.	Overview of Fields

	The access control entries in login.access are simple and
intuitive. Each entry consists of three fields. The first field is the
allow/deny field, the second is the user/group field, and the last is the
host/tty field.

	The first field, the allow/deny field, uses only two operators:
'+' and '-'. If an entry as '+' in the first field, then it denotes access
is allowed, and if the '-' operator is in the first field, then it denotes
access is denied.

	The second field contains the usernames and/or groups for which
that particular entry will control access. There are also a two special
keywords which can be used in the user/group field. The first is 'ALL'
which denotes *all users*. The second keyword is 'EXCEPT,' which can be
used to write compact entries and exclude all but one or more entries.

	The final field, the host/tty field, contains the hosts, IPs,
hostmasks, and/or ttyvs from which logins will be policed by that
particular entry. Specific hosts can be specified by name as usual. IPs,
as well, as usual, or, octets can be left broken off to block entire C,
B, or A class networks. Likewise, parts of domain names can be left off,
beginning with only a '.' to block entire domains. Finally, ttyvs can be
specified, on which logins for the users/groups on that virtual
terminal will be allowed or denied.

	2.2.	Example Entries

	The following sections will contain example entries for various
scenarios, covering instances of every possible combination/usage for
login.access(5) entries. 

	2.2.1.	Managing Console and Local Logins

	If one wishes to deny all remote logins and only permit local,
console logins, to protect a special user entry, the following entry in
/etc/login.access would suffice:

	-:joe:ALL EXCEPT console

	The previous entry would disallow all logins for the user "joe"
except for those done from the console. The next entry, a bit more useful,
would deny non-console logins to all users in admin group "wheel":

	-:wheel:ALL EXCEPT console

	Conversely, if one wishes to only allow remote logins to the user
"joe", the follow entry would accomplish this:


	Local logins differ from console logins in that they are local to
the LAN, but not necessarily at the console. As such, it will denote any
host that can be resolved just by the hostname and does not require the
fully qualified domain name. For instance, if a box on the LAN is named
"blip," then it can be access simply as "blip" and does not require
"blip.somedomain.com." Such hosts are termed "local" and are denoted by
the keyword 'LOCAL.'

	As such, if one would wish to limit access to an account via LAN
access only, the following entry would accomplish this:


	In the previous entry, the account with username "joe" would be
denied from everywhere except access via the local LAN and/or console. A
more useful entry may be to allow only users in the administration group
"wheel" to be allowed access via the local LAN and/or console. The
following entry would accomplish this:


	Finally, if one wishes to control the vttys from which the console
user can login from, the following syntax will be useful:

	-:<user>:ALL EXCEPT <ttyv0> <ttyv1> ...

	For instance, if one wishes to limit root logins at the console to
the first virtual terminal, the follow entry would accomplish this:

	-:root:ALL EXCEPT ttyv0
	2.2.2.	Managing Remote Logins

	If one next wishes to control what hosts a user attempts to login
with, the follow syntax is used:

	-:joe:ALL EXCEPT <host 1> <host 2> ...

	Hosts can be specified in a number of fashions. The most common
fashion is to use the full domain name of the box. For instance, if a
box's hostname is "blip" and the domain name is "cool.org," then an entry
in /etc/login.access may go thusly:

	-:joe:ALL EXCEPT blip.cool.org

	In the above entry, only "joe" logins from blip.cool.org all be
allowed. All other "joe" logins will be denied access. If, however, a
remote box does not have a domain name, then access can easily be
controlled via IP. For instance, if the IP of blip.cool.org is, then, the following entry would limit "joe" logins to only
that host:


	Sometimes, users' hostnames are variable, such as with dynamic IP
dialup accounts, or, one simply wishes to allow access to the box to an
entire domain. let us presume one first wishes to allow access to a user
account from a Mindspring dialup account. The following entry would

	-:joe:ALL EXCEPT .mindspring.com

	Note that hostmasks are accomplished by simply chopped off the
variable portion of the hostname and leaving the remainder, with the
leading period (.). Likewise, IPs can be broken up in a similar fashion.
Often, the IPs one is assigned by an ISP with a dynamic IP dialup only
change within the last octet. As such, chopping off that portion and
leaving the trailing period (.) will accomplih an IP mask:

	-:joe:ALL EXCEPT 192.168.100.

	In the above entry, all "joe" logins from the class C 192.168.100
network will be allowed, whilst, all other login attempts will fail. 

	If one wishes to allow logins to a particular account from
multiple hosts, this can easily be accomplished by listing all of the
hosts separated by a space. For instance, if one wishes to allow all "joe"
logins from blip.cool.org and Mindspring accounts, the following will
accomplish this:

	-:joe:ALL EXCEPT blip.cool.org .mindspring.org

	3.	Default Access Strategy

	There are two possible access strategies that can be used:
'default to allow' or 'default to deny'. These two general access
stretegies are also present in firewall setups as well as tcp wrappers. In
short, any facility that controls access to something else. The 'default
to deny' policy denies connexions by default and requires allowed
connexions to be explicitly allowed, while, the 'default to allow' policy
allows connexions by default and requires disallowed connexions to be
explicitly denied. Each strategy has its respective advantages and
disadvantages and will not be discussed here.

	3.1.	Default Deny Access Strategy

	If one wishes to enforce a 'default to allow' policy, then entries
such as given in the previous section will suffice. If one wishes to
enforce a 'default to deny' policy, then entries will have to be setup
slightly differently. Firstly, one will need to enter the following entry
at the end of the /etc/login.access file:


	The above entry will deny all login attempts from anywhere for any
user. Thereafter, login attempts that are allowed will need to be listed
above it. For instance, if one wishes to allow logins for the user "joe"
from box.cool.org, then the following entry would accomplish this:


	4.	Appendix


Leave a Reply

Your email address will not be published. Required fields are marked *