From owner-freebsd-security Sat Dec 2 4:45:48 2000 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (beleriand.online.bg [195.138.137.181]) by hub.freebsd.org (Postfix) with SMTP id A5BBE37B402 for ; Sat, 2 Dec 2000 04:45:41 -0800 (PST) Received: (qmail 2310 invoked by uid 1000); 2 Dec 2000 12:45:02 -0000 Date: Sat, 2 Dec 2000 14:45:02 +0200 From: Peter Pentchev To: freebsd-security@FreeBSD.ORG Subject: Re: Move along, nothing to see here. Re: Important!! Vulnerabili ty in standard ftpd Message-ID: <20001202144502.A1968@ringworld.oblivion.bg> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <21A918476AFBD311B0C80000D1ECF0FF01A865FC@vejxoisnte85.scott.af.mil> <32502992254.20001201181055@ipfw.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <32502992254.20001201181055@ipfw.org>; from pccb@yahoo.com on Fri, Dec 01, 2000 at 06:10:55PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Dec 01, 2000 at 06:10:55PM -0500, Peter Chiu wrote: > Hello Garrett, > > Friday, December 01, 2000, 10:44:42 AM, you wrote: > > GGCAL> Speaking from experience in a related case: > > GGCAL> I have had my website system hacked twice in the last year - BOTH times it > GGCAL> happened because the hacker got into ANOTHER system where an individual with > GGCAL> a trusted account had his userid and password stored on that server in a > GGCAL> plain text file - they pogoed from that system with that userid and got > GGCAL> in... > > GGCAL> The results from the investigation? There was nothing else I could do to my > GGCAL> system to make it more secure - in fact I got kudos for it being as secure > GGCAL> as it was. But as long as people keep info insecurly there's nothing you can > GGCAL> do but keep watch and hope to catch them (and of course have good backup > GGCAL> sets!). > > Implement ssh2 RSA login only (disable password login everywhere). > Also make sure your users use a non-blank pass pharse. This will not necessarily help; if another machine (or even an account on another machine) has been compromised, the attackers could easily install a backdoored (read: logging) ssh client. I've seen that kind of client several times, and it's not so hard to do it. It might be a bit harder, if only an account was compromised, to get the legitimate user of that account to actually execute the backdoored client instead of the system one; but.. seriously.. besides seasoned admins, who have already been burned, just what percentage of the average users examine often their profile/rc scripts for 'new' aliases? :\ G'luck, Peter -- This sentence every third, but it still comprehensible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message