Re: Linux clients in network - experiences?
Hello,
> [debian-security CC:ed since people there certainly have experience in the
> 'Server/network set up' section below. Please don't crosspost when you reply.
Well, what about people subscribed to only one list but interested in both
aspects of your message? :-)
The main point I'd think of and that you may have missed would be software
installation and maintenance. Don't assume it's something you only do once
as you're bound to buy more machines, deal with hardware failures, etc.
Centralize your logs, automate everything you can. Ideally your OS install
procedure should be like "network boot or pop in floppy; enter install
password; check back half an hour later", which should take care of all
configuration and customization.
I suggest reading through http://www.infrastructures.org/ -- this would
probably have saved me years of accumulated time since I reached a similar
situation to yours in 1996, although the initial development effort could
have been very hard to accomodate.
If Debian is your only OS, FAI (http://www.informatik.uni-koeln.de/fai/)
can deal with installation, tough you may want to hack it so that most
packages are simply copied verbatim (like a bigger basedebs.tar) and then
upgraded, instead of apt-get'ing everything, which takes a lot longer.
Also, if sensitive information is to be exchanged (e.g. ssh host keys),
you'll need a secure channel to the install server (we use a dedicated ssh
key, protected by the installation password, to scp a few files).
Standard security updates can be done with cron-apt, and you may either
use apt-proxy or set up a Debian mirror. In case you want to use testing
rather than stable, some packages will inevitably be broken, so I'd suggest
a semi-manual mirror: the Packages.gz lists that apt-get uses on "normal"
machines should be updated only when the "test" machine, which "cron-apt"s
the regular package list, updates successfully with no broken dependencies.
This doesn't solve the problem of installing new software / updating the
configuration on multiple machines. A shared /usr/local can help for
non-packaged software and for part of the configuration (symlinks from /etc
for selected files). For the rest, one could use a special .deb whose
installation scripts and dependency list makes the necessary changes, but
alas I've not tried it yet.
Of course, you had better make sure not to be the only one who understands
the system, unless you intend to work there forever with no vacations.
Don't skimp on documenting SOPs (machine installation, account creation,
configuration change...)
Which leads to training: no matter how "intuitive" your standard GUI is,
if it's not Windows, users will be lost and complain because they're not
used to it. Warn them when you set up their account, point them to a Web
page where you'll maintain a how-to list (how do I read my mail, how do I
use a floppy, how do I print... no matter how easy it seems *for you*).
Some problems can be left for the time they arise, but others should be
anticipated (we hadn't anticipated USB sticks, but that was somewhat easy;
we hadn't anticipated Wi-Fi either, and this proves to be much harder to
control right now).
Also, since you are preoccupied by security, tell said users that network
sockets are off-limits and check this. Otherwise, sooner or later, some
power-user will bring in his own laptop, or worse, plug a Wi-Fi access
point and leave it open, thereby drastically reducing the utility of your
firewall. (But perhaps you intend to lock everything up inside a Faraday
cage, to prevent keyboard/monitor eavesdropping?) Unfortunately, although
many Ethernet switches have remote management, keeping track of which
machines are on which port is a daunting task.
> Server/network set up
> - unix account management: I suspect NIS is not really an option in a
> security conscious environment (just hearsay, though, I'll look at it).
[8<]
> - networked filesystem. NFS is certainly not the right tool here.
They were not designed with security in mind, but they have their uses,
and they are difficult to escape in mixed-UNIX environments.
If you can't avoid it and use, say, LDAP, NIS can be an option if you
specify the server (not just have the clients listen to broadcasts) and
set up a custom scheme for changing passwords (I think yppasswd either
expects the server's root password in clear on the network, or trusts the
hash from a client). The main issues are that password hashes aren't easy
to hide (severity depends on whether you'll tolerate weak passwords), and
it's not very flexible if you want to manage account expiration, relate
mail aliases to users, set up temporary mail redirections for former users
and so on.
NFS is worse: it trusts the clients by default. You can configure all
sorts of UID mappings on the server, but managing logins/logouts on the
clients would be a nightmare. Perhaps it can be secured if all traffic on
your network is IPsec-based? OTOH, on the heterogeneous Linux - FreeBSD -
Solaris - HPUX (not to speak of Windows and MacOS) I help manage, I can't
think of a replacement for sharing home directories, all the more so as
we're not looking for that high a security level (suggestions welcome,
though I'd have to convince a lot of other people, most of whom have more
urgent business). That said, NFS should be safe for shared read-only data
(e.g. /usr/local, Debian mirror).
> - firewalls/routers: build my own, or buy? (I see an endless debate coming
> here :-)
It might be convenient that your Wi-Fi access point have some filtering
features in firmware.
> - What experience do you have with setting the default locale to something
> like de_CH.UTF-8? Personally, I have quite a good impressions, but my primary
What keeps me from jumping that fence, apart from the time I'd spend
reconfiguring everything, is that my choice shell (zsh) is said not to
support UTF-8, and that my choice newsreader (trn4) looks like it
doesn't either. But that doesn't count as *experience*.
> - what is the color of my briefs?
White and blue, separated along a diagonal?
Hope this helps,
Cedric Ware.
Reply to: