|
HowTo will deal with all aspects of the login.access
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
|
|
