Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.development.apps > #286

Re: Security problem

From Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups comp.os.linux.development.apps
Subject Re: Security problem
Date 2011-12-01 22:34 +0000
Message-ID <87hb1jrkdv.fsf@sapphire.mobileactivedefense.com> (permalink)
References (4 earlier) <ZP6dnXFAC4ua8krTnZ2dnUVZ8h6dnZ2d@lyse.net> <87ipm0quu6.fsf@sapphire.mobileactivedefense.com> <48CdnRF6pcCgBkrTnZ2dnUVZ7tmdnZ2d@lyse.net> <87pqg8qku7.fsf@sapphire.mobileactivedefense.com> <y5Kdnf2iCMVDYUrTnZ2dnUVZ7t6dnZ2d@lyse.net>

Show all headers | View raw


David Brown <david.brown@removethis.hesbynett.no> writes:
> On 01/12/11 18:10, Rainer Weikusat wrote:
>> David Brown<david@westcontrol.removethisbit.com>  writes:
>>> On 01/12/2011 14:34, Rainer Weikusat wrote:
>>>> David Brown<david@westcontrol.removethisbit.com>   writes:
>>>>> On 01/12/2011 11:24, Noob wrote:
>>>>>> David Brown wrote:
>>>>>>
>>>>>>> The easiest and most effective step to limiting dictionary attacks is
>>>>>>> simply to use a non-standard port.  Put your sshd on port 222 instead of
>>>>>>> 22, and no attacker will ever find it.
>>>>>>
>>>>>> Famous last words.
>>>>>>
>>>>>> Meet nmap.
>>>>>
>>>>> Worms and script kiddies go for standard ports, using common login
>>>>> names and passwords, on large ranges of IP addresses.
>>>>
>>>> Yes. And the solution to this problem is to use 'strong' passwords or
>>>> no passwords at all but key based authentication.
>>>
>>> No, that is /part/ of the solution.  There are many things that
>>> contribute to increasing the security and reducing the risk of
>>> successful attacks.
>>
>> Using some non-standard port for a server contributes at best 16 bits
>> of entropy to the amount of information an attacker needs to guess in
>> order to perform successful brute-force attack and that's ludicrous.
>>
>> Really sophisticated attack software demonstrating that:
>>
>> [rw@sapphire]~/work/mss-dns $time sh -c 'yes | nc -v -w 1 192.168.1.100 1-65535 2>&1 | grep -B 1 ^SSH-'
>> (UNKNOWN) [192.168.1.100] 22 (ssh) open
>> SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1
>>
>> real    1m5.822s
>> user    0m10.397s
>> sys     0m3.376s
>>
>
> With a real-world attack across the internet, it takes a /lot/ longer
> than that to do the scan, especially assuming the machine is set up to
> DROP incoming packets for other ports (and what internet-facing server
> is not set up like that?).

For a real-world attack, no one would test ports in decreasing
numerical order and try to establish a complete TCP connection using
an ordinary connect call.

As to 'what internet-facing servers have their TCP stacks configured
to operate in standard-compliant way instead of
Security-By-Voodoo-Dance mode', I know quite a few. 

[...]

>> There are 65536 different ports but 281,474,976,710,656 different
>> eight character passwords composed of the members of the base64
>> alphabet (6 bit of information per character), this means the 'random
>> port' (and it usually isn't even random) increases the 'search space'
>> by a whopping 0.00000002% (2E-8).
>>
>
> You are missing the point - it's a cheap and effective way of getting
> extra protection.

Could you perhaps enlighten me which part of

	65536 / 281474976710656 = 0.00000000023283064365

escaped your mathematical understanding? It's a costly (needs to be
configured) and cumbersome (needs to be taken into account when using)
way of getting exactly nothing: Provided your problem is 'secure
access to the server' you CANNOT assume that 'no one will ever look
for a ssh server running on port 55423!'. The system has to be
resilient against brute force attempts based on the assumption that
people will do that (remember 'the others have more time and they are
smarter') and if it is, changing the port buys you nothing in this
respect. 

[...]

>>>> actually, antisocial behaviour (at least in some theoretical
>>>> sense): When you notice 'lights on and strange noises' in your
>>>> neighbour's house while he's on holiday, you should call the
>>>> police (send a complaint to the abuse] address corresponding with
>>>> the IP) instead of thinking "Glad they didn't come over here" and
>>>> turn back to your TV.
>>>
>>> The analogy has broken down long before this stage.  You don't see
>>> attacks on "neighbouring" IP addresses no matter how hard you look.
>>
>> But you do see that some system was very likely compromised when the
>> IP address it is using appears in the auth.log file:
>>
>> Dec  1 17:07:39 sapphire sshd[9671]: Failed password for invalid user oracle from 112.78.3.183 port 49229 ssh2
>>
>> And that's very similar to seeing 'unauthorized people' digging
>> through someone else's posessions.
>
> I thought you were talking about seeing attacks on other people's
> systems, and couldn't see how you were monitoring that.

Since this makes absolutely no sense, have you considered the
possibilty that your conjecture could be wrong?

Back to comp.os.linux.development.apps | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Security problem jacob navia <jacob@spamsink.net> - 2011-08-31 01:29 +0200
  Re: Security problem GangGreene <GangGreene@invalid.com> - 2011-08-30 19:47 -0400
    Re: Security problem jacob navia <jacob@spamsink.net> - 2011-08-31 02:20 +0200
    Re: Security problem David Brown <david@westcontrol.removethisbit.com> - 2011-09-02 16:19 +0200
      Re: Security problem Noob <root@127.0.0.1> - 2011-12-01 11:24 +0100
        Re: Security problem David Brown <david@westcontrol.removethisbit.com> - 2011-12-01 13:11 +0100
          Re: Security problem Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-12-01 13:34 +0000
            Re: Security problem David Brown <david@westcontrol.removethisbit.com> - 2011-12-01 16:19 +0100
              Re: Security problem Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-12-01 17:10 +0000
                Re: Security problem David Brown <david.brown@removethis.hesbynett.no> - 2011-12-01 23:17 +0100
                Re: Security problem Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-12-01 22:34 +0000
                Re: Security problem David Brown <david@westcontrol.removethisbit.com> - 2011-12-02 10:25 +0100
                Re: Security problem Richard Kettlewell <rjk@greenend.org.uk> - 2011-12-02 10:37 +0000
                Re: Security problem Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-12-02 14:44 +0000
                Re: Security problem David Brown <david@westcontrol.removethisbit.com> - 2011-12-02 17:11 +0100
                Re: Security problem André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-12-03 11:45 +0100
                Re: Security problem Noob <root@127.0.0.1> - 2011-12-05 13:26 +0100
  Re: Security problem Carlos Moreno <moreno_news@mailinator.com> - 2011-09-01 11:47 -0400
    Re: Security problem Richard Kettlewell <rjk@greenend.org.uk> - 2011-09-01 17:01 +0100
      Re: Security problem Carlos Moreno <moreno_news@mailinator.com> - 2011-09-01 15:48 -0400
        Re: Security problem Richard Kettlewell <rjk@greenend.org.uk> - 2011-09-01 22:44 +0100
          Re: Security problem Richard Kettlewell <rjk@greenend.org.uk> - 2011-09-02 14:27 +0100
      Re: Security problem Jasen Betts <jasen@xnet.co.nz> - 2011-09-02 11:06 +0000
        Re: Security problem Richard Kettlewell <rjk@greenend.org.uk> - 2011-09-02 13:49 +0100
          Re: Security problem Carlos Moreno <moreno_news@mailinator.com> - 2011-09-02 13:58 -0400
            Re: Security problem Richard Kettlewell <rjk@greenend.org.uk> - 2011-09-02 19:31 +0100
  Re: Security problem "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-09-01 21:01 +0200

csiph-web