Date: Mon, 9 Dec 2002 14:15:47 -0800 (PST) From: Mike Hoskins <mike@adept.org> To: freebsd-security@freebsd.org Subject: Re: gateway security? Message-ID: <20021209134844.A9836-100000@fubar.adept.org> In-Reply-To: <200212091317.15077.timothy@voidnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021209134844.A9836-100000>