Re: Security Plan

[Donovan Rebbechi <elflord@panix.com>]

On Sun, 5 Dec 1999, David Webster wrote:

> This is a plan I've worked up to improve Indy's security. Comments are
> more than welcome.
> 
> - - Remove ALL services, unless otherwise authorised by user during install.

* 	It should be assumed that any service installed by the user ( NFS,
	Apache, or whatever ) is wanted.

*	As long as the service isn't remotely exploitable, maybe it's not
	such a problem. And some services should certainly run ( such as cron )

> - - Remove as many SUIDs as possible. (Is removing ALL possible?)

Removing all is impossible. Obviously, these for example *must* be suid:

mount
su
suidperl

What we could do is make sure that nothing is unnecessarily SUID. And also
if we can make something  suid-(some user) instead of suid-0, it's
obviously an improvement 

> - - Stop remote printing ability, unless asked for by user.

Seems to make sense

> - - For the admin utilities (fdisk, etc.) move away from 755, to 510.

Also makes sense.

> ? - Collect similar commands into 'groups', assign group name to that
> collection of commands, and if a user needs to have that functionallity,
> add them to that group (provide easy way for root-user to add other users
> to groups). (i.e. have groups: local (for users accessing from terminal) 
> remote (if install is server, for remote users), printing, admin, etc...) 
> [Unsure about this one. Anyone any thoughts?]

Makes things more secure, but also makes life more difficult. Not so good.

> - - firewall set to DENY, unless service is explicitly asked for

Another idea with the firewall: simply deny anything that the user hasn't
enabled. ie probe to see what services the user is running

> - - GUI Tool for setting up logs. [Any log monitoring software out there?]

Good idea

> - - Get firewall to log requests/detect portscans, and warn user.

the best way is to have an email sent to root.

> - - Suggest against use of telnet, include ssh.

Encluding crypto is a great idea. But we have export issues to deal with.
Personally, I'd like to put as much crypto as possible. 

Ultimately, we will want to be on CD. We will need strategies for getting
crypto onto CD.

> Tools like log monitors, facilities like cron'ed checks for SUIDs, regular
> checksum checks (weekly?).

OpenBSD does this kind of thing. It automatically emails root with
security reports.

One thing to keep in mind is that we don't need or want to make the users
life very difficult so as to make a questionable gain of knocking out all
local exploits. I say the gain is questionable because on a users's
workstation, it should be easy enough to make it inaccesible from
outside, making local exploits a non-issue.

OTOH, perhaps we could have some kind of "paranoid" install ( suited to
servers ) which takes some of the more extreme precautions you mention.

-- 
Donovan