Date: Sat, 18 Dec 2004 22:14:17 -0500 (EST) From: "Jerry Bell" <jerry@syslog.org> To: bv@wjv.com Cc: freebsd-security@freebsd.org Subject: Re: Strange command histories in hacked shell history Message-ID: <4916.24.98.86.57.1103426057.squirrel@24.98.86.57> In-Reply-To: <20041218160834.GA76897@wjv.com> References: <20041218120130.C67DC16A4D1@hub.freebsd.org> <20041218160834.GA76897@wjv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I do agree with that, espeically the first paragraph " ... no > matter how paranoid your philsophy ..." > > I have had one instance of an attempt was I had missed one machine > out of about 8 applying one security patch. All were patched > within hours, the one that got hit was 2 days later. You have to > get to any patches as soon as the hole becomes known. Really bad things usually happen as a result of a series of small mistakes or oversights. > > And my machines are pretty accessable to the world being on a > backbone. One machine was getting about 300,000 spams/day until > I finally took off all MX for that domain. If anyone has problems > they need to perform a whois and use those contacts. It's one of > those domains whose name alone drives it up the list. > Spammers, IMO, are one of the strongest offenders of system hacking today - they have a real financial interest in getting into your system. > I haven't set the security levels high as that means that any > problems would require driving to the colo - and that's about > 1/2 hour at 3AM - and two to three times higher during the daylight > hours. > If your problem with hardening your system is the need to "be in front of it", there are some ways around it. Probably the most reliable and convenient is a network KVM and network power switch. Sometimes, you can get your colo to provide that for an extra charge, or you can buy it yourself (quite a few choices on ebay these days. It doesn't take many trips to the colo at 12am to make it worthwhile :) Alternatively, most all of the "hardening" can be worked around, such as lowering the security level and rebooting, or using the /usr/share/examples/ipfw/change_rules.sh script for modifying ipfw rules remotely. It certainly isn't as convenient as being at the console, but you can do it, if you're careful. Jerry http://www.syslog.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4916.24.98.86.57.1103426057.squirrel>