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

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

Re: Security problem

Show all headers | View raw

David Brown <david@westcontrol.removethisbit.com> writes:
> 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:

[...]


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

Sending 65536 TCP SYNs means 'transmitting 3.75M of data'. Copying a
file of that size from a computer in the UK using a not exactly
state-of-the-art DSL connection ("BT Business Broadband") to a server
in New Jersey took 38s when I tried it. And that was a flow-controlled
transmission over a high-latency link (RTT is about
0.1s). Transmitting the same amount of data from a compromised machine
in a hosting provider datacenter to another machine in the same
location is going to be a LOT faster. 

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

A standards-compliant TCP stack is supposed to reply with a RST
segment when it receives a SYN destined at a non-existant port. Minus
possible kernel bugs when handling this situation, this is completely
impenetrable for any outside party. And the packet filtering code is
also just code and could thus also contain yet unknown and possibly
exploitable errors.

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

The only thing this will 'slow down' is application trying to
establish a connection: These will retransmit SYNs for about three
minutes (also mandated by an internet standard) before aborting the
attempt. But there's no reason to wait for replies when searching for
a service: Such an application would just keep sending SYNs and
process replies if they arrive. 

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

Given that the first widely-used TCP/IP implementation was essentially
written by students, that a somewhat strange assertion ...

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

Actually, I want to be *impolite* and tell 'them' to take their crap
elsewhere fast.

[...]


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

Not based on your nonsense interpretation of my statement: Log lines
like the one quoted above tell the person reading them that
computer such-and-such has very likely been compromised and the ideal
socially responsible way to deal with that is to notify your 'neighbour'
that 'strange things' are going on in some parts of his house. Not the
least because the same system will very likely also be used to target
other computers operated by other people. Granted, the volume of these
events is much too high to deal with them one-by-one and it is in no way
certain that trying to deal with them will lead to anything. But "I'm
safe from drive-by attack and you can go to hell for all I care" is
nevertheless not a mindset to be proud of.

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