General Issues Concerning Linux Workgroup Configurations
Table of Contents
You will have noticed that these and related web pages fall under a
section called Workgroup Recipes. As with most recipes in the kitchen,
there are usually many possible ways to make (more or less) the same
same thing. This is equally true for various workgroup server configurations.
Please remember as you look at configuration recipes presented here
that many other possible recipes exist. Many other styles and philosophies
might be used when setting up systems. Most importantly, global policies
are important when you chose an information technology method. I might
present a configuration that is appropriate for a workgroup with trusting
relationships; however this might not be at all appropriate if you have
a workgroup setup consisting of mostly hostile clients.
Therefore always use your common sense and assess the relevancy and
suitability of any configuration recipes presented here. In short,
know yourself. Do not blindly implement solutions just because they work
without seriously looking at the assumptions and
technological limitations underlying any configuration.
Many recipes here assume a
subnet approach to configuration and security:
Subnet configurations are generally rather simple; they are easy to
This would typically be the kind of configuration used in departmental
infrastructures in small companies or small groups in academic networks.
Any subnet considered here is typically a class C network, thus an example
subnet 192.168.196 would have these parameters:
- network address 192.168.196.0
- broadcast address 192.168.196.255
- gateway address 192.168.196.1
Some configurations described here would be appropriate for workgroups
where a trusting kind of relation is in place. What do I mean by that?
A typical trust configuration might consist of, for example,
a small company where all the desktop access and most of the
systems access comes from inside the company. Moreover access is from
employees who have a vested interest in the well-being of the company.
But even in a more-or-less trusted environment the system administrator has
a responsibility to monitor for trust violations, and guard against abuse.
It happens. Indeed, some
of the worst assaults can come from inside a company, for who has a better
opportunity than the guy with the keys?
As with most small departments, physical access controls are nonetheless
widely used. Server room doors are still tightly controlled, and few people
have the keys. The building and its offices are locked after hours, and
access controls are in place. During hours people tend to know each other;
strangers would not normally walk in off the street and plug their laptop
into an ethernet port without someone noticing :-) (of course, whether the
stranger is challenged or not is another matter.)
By way of contrast here are some examples of typical untrusted relationships:
Systems providing internet kiosks to the public.
Undergrad labs in university settings.
Laptop computers, especially where the user has the super-user account
credentials. Hell, forget the credentials - stop and think about it.
Perhaps in the workplace you control
the desktops. Now imagine that every evening the user can pack up the
desktop, throw it in their car, and take it home, or on vacation, or to
their geek buddy's place. Now how much do you trust that desktop?
ISPs renting out customer access and services to internet servers.
What do I mean by login access policies? Basically what I wish to do
is describe various remote and local access schemes that a system administrator
could implement across a Linux workgroup. These kind of policies are
implemented frequently, for example, in academic networks.
Here are some examples, starting from the worst, in terms of security.
This sort of thing was once rather common in UNIX-based systems:
Everyone uses telnet and/or rsh, and system policies allowed unrestricted
~/.rhosts access in the intranet, and perhaps even across the Internet.
(ie. no password required). Similar principles may even be in place for
Only ssh access is allowed; however it is globally allowed between all
machines in the intranet and perhaps even to the Internet. Root-access is
~/.ssh/authorized_keys* files without passphrases are allowed which
remove the need to provide a password.
Only ssh access is allowed from within the intranet. Access from outside
the intranet is generally blocked. However one or two machines may be
configured to allow Intranet-access via ssh. These few machines are
firewalled, heavily configured and monitored. Password-less access is not
allowed, except for some kinds of controlled and monitored access (e.g.
cvs via ssh tunnelling).
Now what about super-user access? Suppose we take the last login access
policy above (point c), and propose a layered model of super-user
access for a linux workgroup, built around a concept of
A few (perhaps 2 or 3) critcal machines, which we call Core Servers,
provide important services to the workgroup. These servers are configured
differently than other small, dedicated servers in the company; and
certainly differently from desktops. Here are some notes about
configuration policy options that could be built around Core Service.
Remote and local access to Core Servers policy:
The Core Servers are only 'remotely' (ssh) accessable from inside the network.
This policy is reinforced
in such files as /etc/hosts.allow and /etc/hosts.deny, and/or
/etc/ssh/sshd_config, and/or firewalling. These machines may even
be cut off from the internet via router policy.
Who has login access to the Core Servers? Here are two scenarios:
Only root is ever allowed to log into the Core Servers. Other users
are blocked via mechanisms like, for example, /etc/nologin.
Alternatively pam could be used to allow a select group of users
access, via /lib/security/pam_access.so and configuration files:
/etc/pam.d/[sshd | login | *dm | ppp]
sudo could be used to
limit access for these users.
root password policy:
The Core Servers have differing root passwords from all other machines.
If any other node in the workgroup is externally accessible, then its root
password and/or passphrase is again different from any client machine, and
most especially from the Core Servers.
In general, no client or server node have any kind of password-less root
access to another machine, anywhere, at any time. Exceptionally the Core
Servers might have password-less access to other machines, depending
on access policy. See below.
Remote management access policy:
One of the functions of a Core Server is remote configuration and
management of other servers and clients.
Here are a couple of examples of remote configuration management from a
This is the list of noteworthy concepts mentioned in this document:
- assumptions and
- Core Servers
- Mixed-mode Configuration Management
- PULL-style Configuration Management
- PUSH-style Configuration Management
- subnet approach to configuration and security
- trust configuration
This is the list of files referenced in this document:
- /etc/pam.d/[sshd | login | *dm | ppp]
Created: Sat Jan 3 12:16 MET 2004
Last Modified: Tue Jun 1 13:37 2004
Copyright © 2004, Denice Deatrich
Number of sections provided: