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

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

Re: Security problem

Show all headers | View raw

On 01/12/2011 23:34, Rainer Weikusat wrote:
> 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.
>

True enough - and as I noted, there are more sophisticated ways to do 
the scan.  The scan would not take 4 months - but neither can it be done 
reliably in a minute.

> 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.
>

"Security By Voodoo" ?  "iptables --policy INPUT DROP" (at least on the 
externally-facing internet) is the first line of most firewalls.  Not 
"REJECT", but "DROP".  "REJECT" is what you use internally, or when you 
expect accidental traffic on a port and want to politely tell them you 
won't accept it.  "DROP" is what you use when the traffic shouldn't be 
there, and you have no interest in being polite.  You do it to give the 
attacker minimal information, and as a bonus it will slow down programs 
as they can't tell if the traffic is dropped or if it's just slow.

Now, you are of course correct that the "standards" say you should 
reject packets, not drop them.  These standards were written when IP 
networking was between military bases and the occasional university (but 
not students, of course).  When they were written, the assumption was 
that any unexpected packet was a mistake from a legitimate source - so 
you want to politely inform them of the mistake.  But these days the 
great majority of such packets are illegitimate - worms, crack attempts, 
etc.  There is no need to be polite or helpful to such sources.

Some people argue that reject is better than drop because it informs 
mistaken users quickly, and that sophisticated attackers and scanners 
are mostly unaffected by the extra timeouts.  But in fact they are still 
/somewhat/ affected by the timeouts - and unsophisticated attacks, as 
most are, /are/ slowed by the timeouts.  In addition, each message can 
give information to the attacker - OS fingerprinting, sequence numbers, 
hints about random number generation, etc.

So for serious, determined attackers, drop doesn't add much more 
protection than reject.  But for drive-by's, it certainly does help - 
and it does so at a lower cost to your system (cpu and bandwidth).

I've seen examples of more sophisticated systems, such as rejecting the 
first few packets from an address then dropping the rest or blacklisting 
the IP entirely.  If you are a likely target for a serious attack, then 
you obviously have to be more careful - but most people and most 
companies are not likely targets.

I think a simple DROP is the most practical choice for the majority of 
internet-facing systems, and I also believe it is the most commonly used.

> [...]
>
>>> 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?

And what part of "layered security" have you forgotten?

There is a reason why you build up security in layers, rather than 
relying on a single point such as a good password.  For example, it is 
common to disable root login by ssh - then the attacker needs to guess 
the user name as well as the password, even though the entropy of 
usernames is quite low.

> It's a costly (needs to be
> configured) and cumbersome (needs to be taken into account when using)

It's negligible cost to configure - and cost saving (cpu and bandwidth) 
in use.

I can agree that it may be cumbersome for some uses, especially for use 
with other software or scripts that assume ssh is on port 22.  But for 
normal ssh command-line logins, it is not a problem.

> 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.

Security is not about absolutes - there is no way to provide "perfect" 
or "complete" security and still allow some access.  Security is about 
balancing the risks and the consequences of these risks with the cost of 
protection and the ease of use of legitimate services.  Assuming we are 
not talking about a popular or high-value target (which increases the 
risks of determined sophisticated attacks), then the risk of someone 
trying to break in to port 22 is high - while the risk on port 55432 is 
very, very low.

I fully agree that you can't assume that an attack on port 55432 will 
never happen.  But you can perhaps assume that the chances are low 
enough that you don't need to bother with additional protection (such as 
failtoban, rate limiting, etc.).  Balance your risks and costs - when 
you reduce the risks, you can reduce the costs for the same overall 
security.

>
> [...]
>
>>>>> 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?

I agree it makes little sense - but that was the only interpretation I 
could make from your "watching the neighbour's house" analogy.

It is time to drop this part of the thread, I think.

Back to comp.os.linux.development.apps | Previous | Next — Previous 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