[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] OT: Break-In report



James P. Kinney III wrote:
> On Wed, 2008-01-02 at 08:15 -0600, Les Mikesell wrote:
>> Rob Owens wrote:
>>> I particularly like the use of " " as a directory name.  Nice and 
>>> invisible.  Also note that the invader put his files in two directories 
>>> which have the "sticky" bit set:  /dev/shm and /var/tmp
>>>
>>> In the end, it seems that all the invader succeeded in doing was a bunch 
>>> of port-scanning.  The OS is going to be re-installed anyway, just to be 
>>> safe.
>> It is probably looking for additional systems to compromise, and may 
>> have  reported itself back to some controlling system.
>>
>>> Are there any organizations out there that this should be reported to? 
>>> (For instance, the way one might send reports to an antivirus group or a 
>>> content filtering group).
> 
> Run a tool like rootkithunter (http://rkhunter.sourceforge.net/)  to see
> if it is a know setup (most are as they are run by "script kiddies" and
> not the black hat pros that write them).
> 
> If the system is a K12LTSP box, rpm -Va will check the integrity of
> every package installed and report if the config or binary has been
> changed. This is a good start for production machines that really can't
> be whisked offline for a wipe and rebuild.

It's a Debian Etch machine.  Any similar recommendations for that system?


>> There is quite a lot of ssh password guessing going on over the 
>> internet.  If you have systems with the ssh port exposed, you can expect 
>> to see a few hundred attempts a day
> I have seen systems that are hit thousands of times a day. Tools like
> sshdfilter will do great things like block the attacker with an iptables
> rule after a set number of failed logins. Sometime moving ssh to a port
> other than 22 will help, but the "security through obscurity" arguments
> arise here (i.e. - it only lasts until someone port scans and finds the
> new port number).
> 
On my home systems, I always disable password authentication for ssh.  I
also set my firewall to enable ssh connections only from subnets that I
expect to get valid connections from.  For instance, the subnet for the
ISP that my family members use (so they can connect to copy family
photos, or so I can connect when I'm at their house).  I also disable
root access via ssh.

I've heard about the various packages that block connections based on x
number of failed attempts.  I'm going to look at them a little more
seriously now.

-Rob


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]