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.
Summary
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 login.access(5).
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 fail.
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 not.
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:
-:joe:console
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:
-:joe:ALL EXCEPT LOCAL
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:
-:wheel:ALL EXCEPT LOCAL
Finally, if one wishes to control the vttys from which the consoleuser 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 tothe 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 commonfashion 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
192.168.100.52, then, the following entry would limit "joe" logins to only that host:
-:joe:ALL EXCEPT 192.168.100.52
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 suffice:
-: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:
-:ALL:ALL
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:
+:joe:box.cool.org
4. Appendix
login.access(5)
ftpd(8)
Lasker v1.0
|