Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.apps Subject: Re: Security problem Date: Fri, 02 Dec 2011 14:44:30 +0000 Lines: 128 Message-ID: <877h2fkp81.fsf@sapphire.mobileactivedefense.com> References: <5LadnfB9uvXse_3TnZ2dnUVZ7oGdnZ2d@lyse.net> <87ipm0quu6.fsf@sapphire.mobileactivedefense.com> <48CdnRF6pcCgBkrTnZ2dnUVZ7tmdnZ2d@lyse.net> <87pqg8qku7.fsf@sapphire.mobileactivedefense.com> <87hb1jrkdv.fsf@sapphire.mobileactivedefense.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net Whv7wGnC6V46AVk/UDNXrAwjV0sQ/Wj5aaq0FlIcrd7M7IMS8= Cancel-Lock: sha1:Bs0UyI8pyG96Jm1GpnkkHmFsWiY= sha1:dfChjt/Ru+DBfkt9fdJOiH/l04Q= User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.development.apps:289 David Brown writes: > On 01/12/2011 23:34, Rainer Weikusat wrote: >> David Brown 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.