lkml.org 
[lkml]   [2011]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Finding a hidden bound TCP socket
From
Any comments?  The behavior seems broken.  At the very least its very
inconsistent with other Unixes.

On Tue, Nov 15, 2011 at 3:23 PM, richard -rw- weinberger
<richard.weinberger@gmail.com> wrote:
> On Tue, Nov 15, 2011 at 8:21 PM, G. D. Fuego <gdfuego@gmail.com> wrote:
>> Hello,
>>
>> I have a question about an odd linux networking behavior, that could
>> potentially be a local networking DoS.  I'm curious if anyone is
>> familiar with this behavior.
>>
>> Essentially I was assisting someone with tracking down a hidden tcp
>> connection.  Attempts to bind to a particular port were failing,
>> saying the socket was in use, even though netstat was not reporting
>> any sort of connection.  They were initially suspecting a root kit,
>> but after a bit of digging, I came across this page:
>>
>> http://dcid.me/2007/06/hidden-ports-on-linux/
>>
>> From the page:
>>
>> "Here is the idea. If you get this simple C program, it will attempt
>> to bind every TCP port from 1025 to 1050, but it will not listen on
>> them. After it is done, if you do a netstat (or fuser or lsof) nothing
>> will be shown. However, if you try to use the port, you will get an
>> error saying that it is already in use."
>>
>> I tested it out and confirmed that connections opened by their test
>> program do in fact cause the port to be unavailable for use, and they
>> are not reported in netstat, lsof, ss, or any other networking tools
>> that I tried.  I'm unable to to find any references to the ports being
>> in use anywhere I've looked within /proc.  Are you aware of another
>> way to figure out which process may be bound to the port?  In our
>> case, we figured out via trial and error which software was likely
>> triggering this behavior.
>>
>> It seems to me that this could be a potentially interesting local
>> networking DoS.  By binding to all ephemeral ports in this way, you'd
>> prevent the local system from being able to establish any tcp
>> connections, and it would be a pain to figure out which process was
>> causing the problem.
>>
>> My lame attempts to exploit this failed due to a max file descriptor
>> limit, but I'm told this could be doable by forking more processes for
>> doing the binding.
>>
>> Is this behavior known/expected?
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>
> CC'ing netdev
>
> --
> Thanks,
> //richard
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-11-23 21:29    [W:0.057 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site