On Sat, 1 Jan 2000, Todd A. Jacobs wrote:
> Next, upgrade your version of SSH to one that isn't vulnerable to buffer
> overflows, change your passwords, and make sure that SSH is compiled to
> run from inetd. It's much slower that way, but by limiting SSH sessions to
> systems defined only in you
> > On Sun, 2 Jan 2000, Michael Hatchard wrote:
>
>^
>
> >
> >
> > > How can I keep this person out of our system??
> >
>
> Even easier
> As this guy is already in tomorrow, simply go back to yesterday
> and shutdown
> That way he will never have hacked in
> ;-)
> Phil
On Sat, 1 Jan 2000, Todd A. Jacobs wrote:
> Next, upgrade your version of SSH to one that isn't vulnerable to buffer
> overflows, change your passwords, and make sure that SSH is compiled to
> run from inetd. It's much slower that way, but by limiting SSH sessions to
> systems defined only in you
On Sun, 2 Jan 2000, Michael Hatchard wrote:
> Someone has hacked into our system.
> I'm not quite sure how he is getting in.
He's almost certainly using the "RSA buffer overrun" exploit in ssh.
Try replacing ssh with OpenSSH from
ftp://ftp.redhat.de/pub/rh-addons/security/
> pico
I've never se
On Sun, 2 Jan 2000, Michael Hatchard wrote:
> How can I keep this person out of our system??
First, reinstall everything. Unless you've been diligently using a
reliable intrusion detection system such as tripwire, you can't guarantee
that essential services haven't been compromised. Reformat and
of course you installed every security update that redhat released
correct?
On Sun, 2 Jan 2000, Michael Hatchard wrote:
> To All
>
> Someone has hacked into our system.
>
> I'm not quite sure how he is getting in.
>
> But here is some info from my logs.
>
> It looks like it starts here from
"Todd A. Jacobs" wrote:
> On Sun, 2 Jan 2000, Michael Hatchard wrote:
^
>
>
> > How can I keep this person out of our system??
>
Even easier
As this guy is already in tomorrow, simply go back to yesterday and shutdown
That way he will never have hacked in
;-)
Phil
--