Michael Heiming <michael+USENET@www.heiming.de> writes:

> In comp.security.ssh Unruh <unruh-spam@physics.ubc.ca>:
>> Randy Yates <yates@ieee.org> writes:
>
>>>Folks,
>
>>>Forgive the OT nature, but I'm dying to bounce this off of some
>>>reputable and knowledgable people in security, and I think this
>>>group is rich in such members.
>
>>>The problem of being owned, hacked, kiddied, yada-yada-yada is
>>>so common nowadays I was thinking of ways to at least detect
>>>such situations and came up with this.
>
> [..]
>
>> A far far better idea is to run an OS that is not so subject to "being
>> owned, hacked, kiddied, yada-yada-yada". You are trying to provide
>> protection at the worst possible point, instead of the best.
>
> Indeed, this was my first thought about the "problem" I can't
> really see. Since this was posted to css, I am presuming somehow
> owned through ssh?

Not that I can detect. It's just that I'm not ever sure.

> - Disable direct root logins, use 'su/sudo'.

Done.

> - Deny ssh logins other then from trusted systems/networks

That defeats the purpose of ssh and my need. I want to be able
to login from potentially unkown systems/networks.

> - Allow keylogin only over public networks

Again, I can't always predict where I'll be loging in from.

> Another idea would be to run sshd on another port this obfuscates
> malicious scripts at least.

Done.

> Or you could send your system a mail
> and let it configure through procmail to open sshd to a certain
> IP you just send?

I had thoughts along those lines, but hadn't gone quite that far.

No, I don't think I'm owned. I just hate the idea of it ever happening,
and like I said in an adjacent post, I don't see that you can ever
guarantee it won't without using a physically and logically separate
system.
--
% Randy Yates % "Maybe one day I'll feel her cold embrace,
%% Fuquay-Varina, NC % and kiss her interface,
%%% 919-577-9882 % til then, I'll leave her alone."
%%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO
http://home.earthlink.net/~yatescr

begin quoting Randy Yates <yates@ieee.org> :
> Michael Heiming <michael+USENET@www.heiming.de> writes:
[snip]
>> - Disable direct root logins, use 'su/sudo'.
>
> Done.

Do you have a need to become root when you log in remotely? If
not, there are some systems that can keep you from even running
su/sudo if you log in from the outside world.

>> - Deny ssh logins other then from trusted systems/networks
>
> That defeats the purpose of ssh and my need. I want to be able
> to login from potentially unkown systems/networks.

You may want to read up on port-knocking.

>> - Allow keylogin only over public networks
>
> Again, I can't always predict where I'll be loging in from.

Not even with a USB thumbdrive with the key on it?

Perhaps one-time-passwords. Keep a list with a couple of dozen
passwords (or password fragments) in your wallet, and cross 'em
off when you use 'em.

>> Another idea would be to run sshd on another port this obfuscates
>> malicious scripts at least.
>
> Done.

You can also, I think, set up scripts that deny access from
machines that attempt to connect to disallowed ports, or that fail
to correctly log in.

>> Or you could send your system a mail
>> and let it configure through procmail to open sshd to a certain
>> IP you just send?
>
> I had thoughts along those lines, but hadn't gone quite that far.

You /really/ should look at port-knocking.

--
--Stewart Stremler----------------------------...rohan.sdsu.edu--
Oh, hell, the best curmudgeons do it on natural talent, not practice.
--Lawrence Watt-Evans (September 2005)

stremler@rohan.sdsu.edu writes:

> You may want to read up on port-knocking.

Port knocking is very cool. I read the original paper and it's a
great idea.

Curious though, anyone here cactually using it with ssh? Curious what
implementations are out there and for what os's

--
Todd H.
http://www.toddh.net/