Date: Mon, 13 Jan 2003 13:00:17 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: questions@FreeBSD.ORG Subject: Re: Security Report Message-ID: <20030113130017.GD7583@happy-idiot-talk.infracaninophi> In-Reply-To: <20030113113128.E92084-100000@freebsd.rf0.com> References: <20030113112846.GB7583@happy-idiot-talk.infracaninophi> <20030113113128.E92084-100000@freebsd.rf0.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 13, 2003 at 11:32:00AM +0000, Rus Foster wrote:
> On Mon, 13 Jan 2003, Matthew Seaman wrote:
>=20
> > On Mon, Jan 13, 2003 at 11:16:50AM +0000, Rus Foster wrote:
> >
> > > Is it my imagination or should FreeBSD automatically make run a cron =
job
> > > to generate a security report? If so does anyone have the cron line?
> >
> > No, you're not imagining things. See /etc/crontab for the invocation
> > of the periodic(8) script. The security report is generated as part
> > of the daily periodic job.
> >
>=20
> Thanks. Don;t suppose there is a tool to harden FreeBSD as well is there?
> I couldn't see anything in ports
There are any number of tools to help you eliminate vulnerabilities
and generally harden up your system. With FreeBSD you're starting
=66rom a pretty good base already, and just applying common sense will
go a long way towards keeping you clear. However, these are
untrusting times and there are a number of extra measures that you can
certainly take.
i) Read the security(7) man page.
ii) Eliminate any services, network daemons etc. that you may have
enabled, but that you aren't using. Make sure that you can
account for all of the entries in the output of 'netstat -a'.
Install 'nmap' from ports and scan your host at regular intervals.
Even better, if you can swing it, is to get a friend to scan your
host from a remote location. For those network services you need
to supply, configure them on the basis of 'least privilege' ---
ie. deny all access by default and only open up sufficient for
authorised uses. Run servers as unprivileged users and use
chroot(8) and jail(8) to limit your exposure even if a server is
compromised. Choose software packages with a good reputation for
security. Learn about ipfw(8) or ipf(8) and hosts_options(5) as
well as any server specific configuration options. It's a good
idea to defend in depth -- configure your servers strictly even if
you also have a firewall ruleset that does an equivalent job.
After all, mistakes happen and this way, you should be several
steps away from disaster.
iii) If you're giving out or selling login accounts (including to
things like web sites or ftp accounts) to other users, sit down
and write an acceptable usage policy detailing what is, and is not
permissible to do from your machine and the penalties incurred for
infraction. Get all your users to agree and sign off on this
policy. Then enforce it strictly. Make sure that login messages
(like /etc/issue (see gettytab(5)), /etc/motd, etc/ftpwelcome)
can't be construed as an invitation to hack into your machine.
=20
iv) Proper, on-going maintainance of the system is vital for
ensuring security. It's just not possible to spend a few days
securing a machine and then have it be 'secure' for ever after.
Keep up to date with security advisories. Update machines
regularly. Clean out old software installations or user accounts
that are now surplus to requirements.
v) Your best defense is useless if the black hats can sneak in
under your guard and do nefarious things without your noticing.
Develop a nasty, suspicious character. Make sure that any and all
activities of a potentially sensitive nature result in log file
entries or some other form of audit trail. Paranoia is good.
Think about using intrusion detection systems such as snort.
Monitor your filesystems for suspicious changes --- tools like
tripwire are invaluable for detecting trojans and root kits.
System logs make good bedtime reading.
vi) Eschew plaintext. ssh(1) is your friend. Avoid plain telnet
or rsh. Remember that remote X sessions are easy to snoop as
well: employ ssh's ability to pass X protocol data through an
encrypted tunnel.
vii) Remember that there is no such thing as absolute security. A
clever enough and sufficiently determined attacker will always be
able to beat you. (What would you do if a couple of thugs broke
into your house and began breaking your fingers until you told
them the root password?) Be measured in the policies you adopt.
Weigh up the value of what you are trying to protect and the cost
--- not just financial, but in terms of aggravation to legitimate
users --- of the security measures you impose.
viii) And finally, take good backups and keep them in a secure,
off-site location. Sleep well at night.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030113130017.GD7583>