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

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

Re: Security problem

Show all headers | View raw

On 02/12/2011 15:44, Rainer Weikusat wrote:
> 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.
>

I've working here under the assumption that most simple scans do wait 
for connections, even if they wait less than normal timeouts.  Your 
example "nc" scan is like that.  Sophisticated scanners used by experts 
will not wait, just as you said, and will run much faster.  My 
assumption has been that "amateur" scans will wait for connections - if 
that's not the case, then my timing arguments are all bogus and wrong.

Let me take a step back here to try to summarise our differences, to see 
if they are differences of opinion, or differences of fact.

1. I recommend DROP over REJECT for unused ports.
Pros:

It makes you less visible to a casual check, since the attacker doesn't 
easily see why they can't get in (maybe it's the wrong IP address, bad 
routing, firewalling, etc.).

It avoids reply packets with sequence numbers, which could be used by an 
attacker (such as for idle scans of another machine).

Cons:

It makes it harder for real users to see what has gone wrong.


It will make no significant difference when an attacker does a full port 
scan.


2. I like to put sshd on a non-standard port.
Pros:

It will stop casual checks and automated attacks.

Assuming you pick a port over 1023, it will stop "privileged port" scans.

It makes it easy to add tripwires to the firewall to trigger complete 
bans on IP addresses probing standard ports.


Cons:

It might annoy users, especially if they are using ssh along with other 
programs.


It will make no significant difference to a determined attacker doing a 
full scan (unless you also have firewall rules detecting and blocking 
scans).



Am I missing anything here?  My conclusion is that both techniques 
reduce the bother from casual attacks, though neither is a significant 
hinder to a serious attacker.


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

My history is inaccurate.  My point is that there was much more trust at 
that time, justifiably so - you played nicely because everyone else 
played nicely and followed all the rules.

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

I see now where I've missed your point, coming from a misinterpretation 
of your analogy.  You talked about watching your neighbour and helping 
out if he gets burgled.  But that's not at all what you are doing on the 
network here - you are tracking the people attacking your system, and 
informing the relevant responsible authority (computer owner, ISP, 
university, company, etc.) that they have a problem.  That's something 
very different - in your analogy, it's a bit more like stopping a 
burglar entering your house, and informing the guy's parole officer of 
the attempt.

That makes a lot more sense, and it's something I have done in the past 
- but like you I think it seldom leads to results.  I would only bother 
if the attack was from something recognisable, such as a university network.

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