unix build recommendations for internal systems

unix build recommendations for internal systems

Post by Brig » Tue, 18 Feb 2003 19:54:14



Dear All

I'm sure many people are familiar with how to harden the OS by
reducing the number of packages installed and limiting the available
services - there is obviously a tradeoff with usability (as ever with
security) as well as cost of administration.

For exposed machines (DNS, webserver, mailserver) then IMO you lock
the system down as tight as a drum (similarly for other secure systems
such as authentication servers)...note these are behind a firewall but
at least one service is exposed to an untrusted network

But what is the received wisdom when it comes to "Internal" machines -
these machines don't reside in the DMZ and are effectively isolated
from external networks (such as the Internet)?

I feel that the services (particularly the network services) should
still be minimised, but perhaps restricting the installed packages is
too great an administrative burden ... what do you all think? - do you
consider the risk of installing one of the more fully featured
installations to be unreasonable ... e.g to keep Oracle installations
up to date it can be useful to have apps such as 'make' available
(which is included in the developer packaged installation for
Solaris)...I would like to have a generic build for internal systems
(for consistency) so the build will have to accommodate a variety of
applications and services

The obvious answer is that the security stance depends entirely upon
the environment and the associated risk - does anybody know of
reference material that quantifies this for different industries?
From my point of view I would say that we are on the low side of
average risk - vulnerability would be largely be via physical access
to the office environment We aren't a particularly attractive target
for such activity - there is no obvious financial gain to be achieved,
our physical security is fairly ok and, being in a large city, there
are loads of more attractive targets in our vicinity. As with any
company there is the risk of a disgruntled employee...

With this in mind I'm inclined to allow pretty much any level of
install.

But what about "r commands", do you allow rlogin, rsh in your internal
environments?

And authentication ... NIS and standard passwords?

I'm inclined to lock this down even for internal systems (am I being
paranoid?)

We can use ssh in place of telnet/rlogin and ssh to encrypt (tunnel) X
sessions
_or_ alternatively we can leave the traffic unencrypted but use a
stronger authentication mechanism (kerberos or secureID) - I'm not
particularly concerned with encrypting network traffic internally but
I want to protect the authentication

Of the two options which do you think is the best for internal
systems?

Is there any reference material which can guide me when it comes to
setting the security policy for unix build on Internal systems. I want
a secure environment but I don't want to unnecessarily burden the sys
admins or inconvenience the users.

thanks

Bright

 
 
 

unix build recommendations for internal systems

Post by all mail refus » Wed, 19 Feb 2003 04:08:29



>But what is the received wisdom when it comes to "Internal" machines -

Make them as hard as you conveniently can.  This is easier if you start
earlier rather than waiting for all your users to become dependent on
FTP servers on every host for example.  There should be a reasonably
obvious point beyond which it's not worth the effort.

Quote:>I feel that the services (particularly the network services) should
>still be minimised, but perhaps restricting the installed packages is
>too great an administrative burden ... what do you all think? - do you
>But what about "r commands", do you allow rlogin, rsh in your internal
>environments?

>And authentication ... NIS and standard passwords?

NIS and NFS are rather a pain from the security POV.  If you can do
without them that's good.  If you need something centralised and NIS-like
and you can't find a suitable alternative then NIS might be better than
all separate maintainance; particularly in a low-threat environment.
If you're preparing new stuff you could be all ssh and no r* from day one.
For older established places getting to that point takes effort.

Quote:>a secure environment but I don't want to unnecessarily burden the sys
>admins or inconvenience the users.

Limiting packages (and especially establishing a standard install) are
simplifying and time-saving steps that should be appreciated by the admins.
What you really don't want is anarchy with vast numbers of machines all
different for poorly-documented reasons.

--
decoy mail addresses: obtain username via 0x4f/tcp or 0x50/tcp

 
 
 

unix build recommendations for internal systems

Post by Colin McKinno » Mon, 24 Feb 2003 07:53:57



> But what is the received wisdom when it comes to "Internal" machines -
> these machines don't reside in the DMZ and are effectively isolated from
> external networks (such as the Internet)?

I don't know about wisdom....I have read that 80% of compromises are
carried out by 'insiders'. This kind of suggests that internal security is
important too. I prefer to start from the point of a minimal level of
service and add functionality as the need arises - that way I can be the
guy who gave the users access instead of being the one who took it away.

If you can get a strong security framework in place as early as possible
then it'll make life a lot simpler later on.

Good luck,

Colin
(looking for work in Scotland as Unix systems / network /database /security
administrator)

 
 
 

unix build recommendations for internal systems

Post by G » Wed, 26 Feb 2003 02:16:19


Check out the benchmarks from the Center for Internet Security
(cisecurity.org). They have host-hardening benchmarks and audit tools
for almost all the major Unix flavors.

GG



> > But what is the received wisdom when it comes to "Internal" machines -
> > these machines don't reside in the DMZ and are effectively isolated from
> > external networks (such as the Internet)?

> I don't know about wisdom....I have read that 80% of compromises are
> carried out by 'insiders'. This kind of suggests that internal security is
> important too. I prefer to start from the point of a minimal level of
> service and add functionality as the need arises - that way I can be the
> guy who gave the users access instead of being the one who took it away.

> If you can get a strong security framework in place as early as possible
> then it'll make life a lot simpler later on.

> Good luck,

> Colin
> (looking for work in Scotland as Unix systems / network /database /security
> administrator)

 
 
 

unix build recommendations for internal systems

Post by Brig » Wed, 26 Mar 2003 20:36:00


Sadly ... the actuality is that very few application vendors know what
packages are required for their application. They simply direct us to
install the 'User Cluster' or the 'Developer Cluster'
Indeed - even the OS vendor (in this instance Sun) doesn't know what
packages are required for some of the Sun supplied applications and
gives similar advice.

A poor alternative is to install the requisite package cluster and
remove some packages.

How do you find out what packages to install/remove?


> Check out the benchmarks from the Center for Internet Security
> (cisecurity.org). They have host-hardening benchmarks and audit tools
> for almost all the major Unix flavors.

> GG



> > > But what is the received wisdom when it comes to "Internal" machines -
> > > these machines don't reside in the DMZ and are effectively isolated from
> > > external networks (such as the Internet)?

> > I don't know about wisdom....I have read that 80% of compromises are
> > carried out by 'insiders'. This kind of suggests that internal security is
> > important too. I prefer to start from the point of a minimal level of
> > service and add functionality as the need arises - that way I can be the
> > guy who gave the users access instead of being the one who took it away.

> > If you can get a strong security framework in place as early as possible
> > then it'll make life a lot simpler later on.

> > Good luck,

> > Colin
> > (looking for work in Scotland as Unix systems / network /database /security
> > administrator)

 
 
 

unix build recommendations for internal systems

Post by Matt » Sat, 29 Mar 2003 10:07:57


The most important thing is too make sure the application is running as
expected. You may find you app is unsupported by the vendor unless you
have the software clusters suggested installed. In that case stick with
what they recommend.
Otherwise, lsof is your friend. Use it to see which libraries and files
the app is using. It's possible that the app may open and close some
libraries/files from time to time, in which case it may break, but
generally apps tend to keep hold of the files. There are probably tools
around that will show all the files that are used, but I can't suggest
any off the top of my head.
Try installing in a chroot jail, and copy the libraries you find you
need by hand. Rather time consuming, and it can be frustrating, but
you'll know you got a minimal system then.

As for securing the system, if it's really critical data (e.g. accounts,
staff details etc.), put in on a seperate network behind a router and
firewall. If it's used by limited number of staff, put it in an internal
DMZ, with the staff on the 'internal' side, and carefully control the
data that their machines send and receive from the rest of the company
and world.

In all cases, standard practices apply. Shut down unneccasery services.
Keep the system patched. Remove setuid root on all tools (unless one of
them is an obsolute requirement for the app). If possible run a firewall
on the box itself. Log everything possibly to a seperate syslog server
and check the logs. Give users the minimum authorisation required, use
secure authentication. Portscan the box. Use Nessus. And so on and so
forth. Treat it like a machine on the Internet. There are plenty of
guides on the web on this topic.

I hope at least some of the above is of use.

Matt
(Also looking for work, but in the East Midlands: UNIX
(Solaris,Linux,*BSD) Systems, networking, security)


> Sadly ... the actuality is that very few application vendors know what
> packages are required for their application. They simply direct us to
> install the 'User Cluster' or the 'Developer Cluster'
> Indeed - even the OS vendor (in this instance Sun) doesn't know what
> packages are required for some of the Sun supplied applications and
> gives similar advice.

> A poor alternative is to install the requisite package cluster and
> remove some packages.

> How do you find out what packages to install/remove?


>>Check out the benchmarks from the Center for Internet Security
>>(cisecurity.org). They have host-hardening benchmarks and audit tools
>>for almost all the major Unix flavors.

>>GG



>>>>But what is the received wisdom when it comes to "Internal" machines -
>>>>these machines don't reside in the DMZ and are effectively isolated from
>>>>external networks (such as the Internet)?

>>>I don't know about wisdom....I have read that 80% of compromises are
>>>carried out by 'insiders'. This kind of suggests that internal security is
>>>important too. I prefer to start from the point of a minimal level of
>>>service and add functionality as the need arises - that way I can be the
>>>guy who gave the users access instead of being the one who took it away.

>>>If you can get a strong security framework in place as early as possible
>>>then it'll make life a lot simpler later on.

>>>Good luck,

>>>Colin
>>>(looking for work in Scotland as Unix systems / network /database /security
>>>administrator)

 
 
 

1. Linux system building - need a recommendation

I am collecting components for my first home-built system. I could use
some advice on components.

Specifics: I am planning to use Mandrake Linux 7.2 (of course, I will
upgrade to the new 2.4 kernel when it is out). The system will include
an IBM Deskstart 75GXP HD, Pioneer DVD drive, and an HP 8250i CD writer.
I haven't settled on a video card, yet, but am leaning towards an NVIDIA
GeForce (but open to recommendations backed by good reasons). I am not a
gamer, but I do want to watch an occasional DVD and I do a fair amount
of graphics. I'll use some sort of Soundblaster type of audio card, not
likely to be top of the line. Finally, I'm going to go to 256MB of ram
(Mushkin, most likely).

I've been leaning mostly towards a Pentium III 866 (133 Mhz FSB) and had
more or less settled on the ASUS CUSL2 for the MB. However, I keep
reading recommendations supporting the AMD Athlon as a better deal for
the home builder, and if I went in that direction the most popular board
seems to be ABIT KT7-RAID (I'd go the raid version for the Ultra-ATA100
support, not for RAID which I don't need at home).

Finally, I've been offered an exceptional deal on an bundled Intel
D815EEA with a PIII 800 and heat sink at a superb price (prob half what
it would cost me to buy online), so this is a very tempting offer, and
for the work that I do, the 800 to 866 MHz step up isn't really worth
doubling the cost of the MB+Processor.

I would appreciate any advice people have on which of the above
configurations will be the best for me to work with. I have done plenty
of system upgrades and so forth, so I'm comfortable with the mechanics
of plugging in cables and cards, but I haven't done a system build from
scratch before, and I need something that is likely to work and has
worked for others so I am don't hit the limit of my abilities trying to
get the hardware working and Linux up and running. If anyone has
actually used these components and built a Linux based-system, I would
appreciate their advice as well.

Thanks in advance for any help. Please reply to group or in private.
Neal Lippman

2. the community network.

3. Wanted: UNIX system/network programming book recommendation

4. compiling with elf

5. Need recommendations for buying UNIX system

6. 1 * KvRJZqnwW-wide PATH and MANPATH

7. UNIX's Book about the internal system

8. KDE's KSocket and KServerSocket

9. Building UNIX system V on a SUN SPARC

10. Does any Know How To FTP between a Unix system and a Non Unix operating system.

11. Recommendations for internal mail server

12. Recommendation on an Internal PCI modem

13. HELP - Internal IP Address recommendations?