From: J G Miller on
On Thu, 17 Jun 2010 13:44:39 +0000, General Schvantzkoph wrote:
> I require RSA authentication and I use denyhosts,
> but I also keep my pants up with both a belt and suspenders (that's for
> real, it's not just an expression).

I really do not understand people's reaction to too much security
being overkill ie a bad thing.

Too much security never hurt, as compared to too little.

From: General Schvantzkoph on
On Thu, 17 Jun 2010 14:20:41 +0000, J G Miller wrote:

> On Thu, 17 Jun 2010 13:44:39 +0000, General Schvantzkoph wrote:
>> I require RSA authentication and I use denyhosts, but I also keep my
>> pants up with both a belt and suspenders (that's for real, it's not
>> just an expression).
>
> I really do not understand people's reaction to too much security being
> overkill ie a bad thing.
>
> Too much security never hurt, as compared to too little.

Everything has a performance cost, if something isn't adding any
additional security you might not want to use it. Denyhosts is aimed at
cutting off password guessing attacks, however of you've disabled
password access then it's not clear what it's doing for you. My ssh
server is a dedicated machine so I figure the cost of denyhosts is
essentially free so I run it anyway with the hope that it will at least
discourage attackers from trying something else.

From: The Natural Philosopher on
J G Miller wrote:
> On Thu, 17 Jun 2010 13:44:39 +0000, General Schvantzkoph wrote:
>> I require RSA authentication and I use denyhosts,
>> but I also keep my pants up with both a belt and suspenders (that's for
>> real, it's not just an expression).
>
> I really do not understand people's reaction to too much security
> being overkill ie a bad thing.
>
> Too much security never hurt, as compared to too little.
>
too much security != to more an more supposedly secure programs layered
on each other.

Too many layers are a recipe for one to be flawed, thus reducing
security, or for valid users frustrated by difficulty of use to actively
seek ways to circumvent them.

I personally rely on firewalls to limit access to only what is needful,
from the internet at large, and keep the rest simple. Like no protection.

It's my setup, I can do what I like. I cant see anyone on this lan doing
anything to and if they get physical access to these premises I've a lot
more things to worry about than the ability to log into couple of Linux
servers.





From: J G Miller on
On Thu, 17 Jun 2010 14:33:53 +0000, General Schvantzkoph wrote:

> Everything has a performance cost

Indeed. And the cost of an intrusive hacker doing damage
costs you how much? If you do not care about your data or
system because it has no value, then why pay the performance
cost of security?

> if something isn't adding any additional security you might
> not want to use it.

Indeed not. You may just want to rely on a single point of
security and if that fails, well then the hackers may be able
to get in.

So which is more secure -- redundant security or a single
lock?

As I say, the security policy is entirely up to the individual
concerned and there is no one size fits all, except to
reiterate that too much security never hurt in any way
like too little.
From: The Natural Philosopher on
F. Michael Orr wrote:
> On Thu, 17 Jun 2010 13:29:00 +0100, The Natural Philosopher wrote:
>
>> David Brown wrote:
>>> On 17/06/2010 11:12, Todd wrote:
>>>> Hi All,
>>>>
>>>> With this command:
>>>>
>>>> ssh -l todd -X 192.168.255.14 /usr/bin/VirtualBox
>>>>
>>>> I can run VirtualBox console on another computer with X11. All I get
>>>> is asked for my password.
>>>>
>>>> I don't get it. How is this any more secure that plain old telnet?
>>>> Both are just a user name and password. You could hack it the same old
>>>> way other services are hacked by running the dictionary at them. I do
>>>> believe OPH Crack over on the Windows side calls this "Rainbow
>>>> tables".
>>>>
>>>> I ask this because I will be needing to open SSH (port 22) for a
>>>> vendor to get in on. And, well, I just don't get the advantage of ssh
>>>> over anything else.
>>>>
>>>>
>>> Arrange with the vendor to use a non-standard port. If you open port
>>> 22 to the world, you'll get lots of unwanted attempts at breaking in.
>>> If you put your ssh server on port 12345, it will be free from attacks.
>>>
>>>> What am I missing? Is there a way to tighten ssh up?
>>>>
>>>> Many thanks,
>>>> -T
>>> ssh has a range of benefits over other remote solutions such as telnet
>>> or rsh.
>>>
>>> First is that the entire session is encrypted, so it can't be
>>> eavesdropped or modified under way (unlike telnet). As another poster
>>> has mentioned, this is less relevant in practice than many people
>>> think, but it's nice to have.
>>>
>>> You can use private/public keys instead of or as well as passwords.
>>>
>>> You can can store options for your ssh client for ports and other
>>> options, organised by server, which is very convenient if you need to
>>> connect to many servers.
>>>
>>> The traffic can be compressed, which is nice for slower links.
>>>
>>> You can tunnel other ports through the link - it's great for ad-hoc
>>> remote connections.
>>>
>>> You can use "scp" for copying files conveniently.
>>>
>>> You can arrange for multiple ssh sessions to share a single link,
>>> reducing overhead and link connection times.
>>>
>>> In short, it's securer and much more flexible than telnet or similar
>>> solutions.
>>>
>>>
>> However, none of these are really insurmountable by other means.
>>
>> Its only mire secure if you think your link can and will be
>> eavesdropped: In practice this is extremely unlikely.
>>
>
> On a privately controlled network, yes. However, on anything crossing
> the Internet, one cannot assume this to be true.

POne cant assume enything to be true, BUT its very very hard tpo
eavesdrop conversations between specific endpoints even with NSA level kit.


If one were serious
> about compromising an organization, then all one would have to do would
> be to set up a man in the middle router, which would silently capture all
> traffic to/from a site. If this traffic were not encrypted, this would
> be a problem.
>

All? that's already a very very hard thing to do with most routers.


And not something to be done without ISPs explicit knowledge and consent.

>> And telnet is not something one uses for bulk transmission of data
>> anyway, so compression isn't really an issue.
>>
> <SNIP>
>
>> These days anyone bothered about security tends to use something at a
>> much lower level. e.g. firewalling to prevent access except from
>> defined places, and/or VPN networks to routinely encrypt ALL traffic.
>
> Firewalling is a necessary tool, but offers no protection against common
> exploits such as MitM or IP spoofing.
>

I've never managed to spoof IP across the Internet. Its almost
inmpossible without control of an ISP.



You talk in generalities.


I have., lets say, a telnet session on one IP address that will only
accept packets to and from one other.

Tell me how you propose to steal my passwords IN DETAIL, not just 'with
IP spoofing' and what ISP's kit you need to gain control of, and why, if
you had elses, and what use a person with such computing knowledge and
inside power, could possibly make of them?




> VPNs are inherently no more secure than an SSH connection, and it can be
> argued that for user level access are in fact less secure. The main
> weakness of a VPN is that the remote machine becomes at least partly
> integrated into the local site. For a site-to-site VPN, this is fine.
> However, for user-level access one has to rely on the remote machine's
> security, which is an unknown. There are tools such as clean access to
> deal with this, but they are, IMO, something of a kludge. SSH
> connections, in the hands of someone who actually knows what they are
> doing, have the benefit of treating a remote machine as a remote machine.
>
>
Yawn. More theoretical twaddle.


Talk specifics. How do you propose to break into a server, on a specific
IP address, using telnet, given only the knowledge that it has a telnet
server operational on its IP address?


But a server that you personally cannot reach. I could even say you know
the IP address of the one machine that occasionally logs into it.

I'll even allow there is wifi at each end, on a WEP style encryption,
and you know the physical locations.