On Mon, 9 Dec 2002, Eric Timme wrote:
> archives and finding any discussions. I've read over the general primer, but
> would like to read about some actual deployment of security when your
> headless gateway sits in a dark closet, accumulating dust.

I'm not sure which general primer you mean, so I'll post a few references
to start... If you've already read through these, just disregard:

Handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/security.html

Man pages:
tuning(7)
security(7)
firewall(7)

You've probably already gleaned the handbook, but the man pages have been
added and updated more recently and are often overlooked. If you really
want something hardcopy, the 2nd edition of _Building Internet Firewalls_
is probably a good read (I still refer to my first ed. once in awhile):

http://www.oreilly.com/catalog/fire2/

> Currently I have a pretty restrictive set of firewall rules in place, allowing
> only http and ssh traffic from the outside, and I require DES public/private
> keys for ssh access. There is a single user account on the gateway, and root

Consult the man pages above, and triple check your rule chains. Making
sure rules are as restrictive as possible, carefully tuning timeouts to
your needs, etc.

> logins are disallowed from all but console. The gateway is doing a single
> NFS export of my public_html directory for easy access from an internal
> FreeBSD gateway.

Can you export this from a "more trusted" (I.e. farther from the hostile
network) server r/o to the gateway? If someone did compromise the
gateway, could they cause other clients on the network to read potentially
hostile data?

If it's not feasible to move NFS, you should take checksums of critical
files and compare running copies to the trusted backup at regular
intervals. This is probably a good idea anyway... Be warned, it takes
some tweaking to checksum enough critical files to catch intruders w/o
checksumming so many that the system slows to a crawl while the security
check is running. :)

Routine backups, if you value the data (most likely the NFS export), are a
good idea as well. If you suspect a compromise, you want to be able to a)
compare the current system (or significant parts of it) to a "known good"
image and b) restore a working system as quickly as possible if evidence
of a compromise is found. This can be as simple as scp'ing a tarball to
some backend machine, then writing the archive to CDR. Don't backup
compromised data though... Schedule backups to run after your routine
integrity checks.

> with this partitioning scheme I just barely fit, and use ad1 for additional
> space), and use secure level 2 for daily operations.
<snip>

Tuning(7) will help here.

> I've been using snort with a remote acid installation with alright success,
> but it has never quite worked right, and am considering junking it, simply
> because I don't see a lot of other people using it, and it has only been of
> marginal success, spending more time picking up proxy scans from IRC and
> false positives than anything else.

When it comes to IDS, your best bet is to monitor the internal segment
(I.e. what's just behind your firewall/gateway) and alarm on what you know
should not be there. For the most part, that's how people avoid a
seemingly endless flood of false positives. Heuristic algorithms are
getting better all the time, but it's mostly just educational institutions
and IDS dvelopers monitoring external flows today.

> like to find something that could email me status updates daily, or bi-daily,
> ala the daily messages, which I currently forward to myself, to help reassure
> me nobody is poking around in it.

What sort of status updates do you have in mind? If you're forwarding the
daily/monthly/etc. reports, you will be given useful statistics about the
machine. What other statistics would you like to monitor? You can script
and cron just about anything. A sort of "security through obscurity"
advantage this may have is that a potential intruder may know where to
disable the default reports... But may overlook an obscure cronjob that
will end up catching him/her.

I think a combinaton of the things mentioned here and in the man pages
will lead to an environment with a reasonable level of trust.

Good luck,

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]