activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Anderson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-875) TCP connector (server) will stop accepting connection if an invalid connection is made to him.
Date Wed, 29 Aug 2007 02:24:23 GMT

    [ https://issues.apache.org/activemq/browse/AMQ-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40040
] 

Eric Anderson commented on AMQ-875:
-----------------------------------

I just spent some time trying to repro this on rev. 570602 without luck.  Specifically I was
trying to recreate the exception noted by telnetting to 61616 and tracing the session establishment
code in the debugger.  I tried both 1) allowing the wireformat info to be sent to the client
and allowing the timeout to occur, and 2) closing the connection from the client end before
the initial wireformat info is sent.

In both cases it seemed like the transport code was catching any socket exceptions and cleaning
up in an orderly way.  

I did notice one very peculiar behavior though.  I set up 20 different bash shells to do a
"telnet 0 61616", then fired off the connections to the AMQ broker concurrently.  What I saw
was that while connection #n was waiting for a response to its wireformat message, connection
#n+1 was sitting idle, no initial handshake message having been sent from the broker.  As
soon as connection #n timed-out, I would see the initial data from the server on the screen
of session #n+1.  Meanwhile, connection #n+2 sat idle until n+1 timed out, and then it too
would receive the initial handshake message, and so on.

So it would seem that, given this behavior, it might be easy to instigate a mini-DOS attack
against the broker simply by creating connections to the openwire transport and sending nothing
on them.  All bogus connections would have to time out before subsequent valid connections
would be negotiated.  I could easily see how a port-scanning application could cause similar
problems if it connected to port 61616 and then for some reason did not immediately tear down
the TCP connection.

-Eric

> TCP connector (server) will stop accepting connection if an invalid connection is made
to him.
> ----------------------------------------------------------------------------------------------
>
>                 Key: AMQ-875
>                 URL: https://issues.apache.org/activemq/browse/AMQ-875
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 4.0
>            Reporter: Hiram Chirino
>            Assignee: Hiram Chirino
>             Fix For: 5.2.0
>
>
> Charles reported on the mailing list:
> Hi All,
> We've just had a nasty situation : our ActiveMQ Server standalone plain
> vanilla TCP Transport, no persistency, no nuffink) on one of our live
> installations suddenly refused to accept any new connections - no clients
> could connect. All currently connected clients were fine, and messages were
> being processed sent and received fine. Just no-one else could connect.
> After 20 minutes, new connections were suddenly allowed.
> The following exception was in our log.
> 2006-Aug-11 12:17:47.726 aqualive [ActiveMQ Transport Server:
> tcp://blah:61616]  ERROR org.apache.activemq.broker.TransportConnector -
> Could not accept connection: java.net.SocketException: Connection reset by
> peer: socket write error
> java.net.SocketException: Connection reset by peer: socket write error
>  at java.net.SocketOutputStream.socketWrite0(Native Method)
>  at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
>  at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
>  at
> org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedO
> utputStream.java:108)
>  at java.io.DataOutputStream.flush(DataOutputStream.java:101)
>  at
> org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:125)
>  at
> org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.jav
> a:141)
>  at
> org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormat
> Negotiator.java:128)
>  at
> org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiato
> r.java:64)
>  at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:52)
>  at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:52)
>  at
> org.apache.activemq.broker.TransportConnection.start(TransportConnection.jav
> a:75)
>  at
> org.apache.activemq.broker.TransportConnector$1.onAccept(TransportConnector.
> java:136)
>  at
> org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.
> java:137)
>  at java.lang.Thread.run(Thread.java:534)
> My interpretation of the above that something (port scanner maybe ? Our
> curious IT department ?) is connecting to the listening socket, and the
> TransportServer is trying to tell the connecting process what the wireformat
> is - and the connection process is just sitting there, not responding,
> acknlowedging, or doing anything at all - yet not closing the connection.
> Therefore, the transport server is blocked, preventing anyone else
> connecting. After 20 mins - which I am guessing is somekind of lowlevel
> timeout, seeing as all the default AMQ timeouts seen to be of the order of 1
> - 30 secs - a low level TCP exception is thrown, freeing the whole shebang
> up.
> I notice there is an InactivityMonitor, and looking at the code there is the
> following comment
> // Disable inactivity monitoring while processing a command.
> Could this be the case ? That - until the wireformat has been negotiated -
> there is no timeout configured ? Is there anything we can do to reduce this
> timeout from 20 mins ? Or have I completed gone down the wrong track ?
> This is AMQ 4.0, Win2K, JRE 1.4.2
> Cheers,
> Charles

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message