From owner-freebsd-security Thu Apr 20 15:34: 6 2000 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 9BD6937B765 for ; Thu, 20 Apr 2000 15:34:02 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id SAA36370; Thu, 20 Apr 2000 18:33:11 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 20 Apr 2000 18:33:11 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Randy Bush Cc: Christopher Nielsen , freebsd-security@freebsd.org Subject: Re: log-in-vain [ was: 10 days ] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 20 Apr 2000, Randy Bush wrote: > > Something you might want to do, if you haven't already, is enable > > log_in_vain in /etc/rc.conf by adding 'log_in_vain="YES"'. It will log > > connection attempts on ports that have nothing listening on them. It can > > be very enlightening. > > but what does one *do* with the info? there is so much scanning and so many > baby cracker attempts that it does little good writing to source address > admins. and the sources are spoofed in the majority of the cases anyway. > > while i think log watching is important, it can be massive data. so i try > to keep it down to those data about which i can do something, either by > changing my defenses or by dealing with the source of the problem. > > i am open to having my mind changed on this. One of the fundamental problems with IDS is what you do with the results. The only intrusions you're interested in are the ones where they succeed -- the rest are just statistics you can use to bump your IT budget for security software :-). The best bet is to harden your boxes as much as you can, and watch for actual intrusions rather than attempts. Usually this means watching real system events, using tripwire or the like, and avoid any potential vulnerabilities (remove unnecesary services, only use cryptographically strong remote access mechanisms, limit access to the host to specific trusted IPs where possible, make use of one-time passwords, run services in chroot/jail sandboxes, et al). One nice feature of Jail is that you can limit all remotely started processes to running within a jail, only allowing console logins to gain strong privileges. Once we have our first pass at MAC in TrustedBSD, that will be a great way to limit vulnerability. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message