I actually wondered if we could timeout sessions where no valid command is
received, and whether this would solve the problem.
A further anti-DOS wrinkle would be to limit the time between commands, and
limit the number of syntax errors allowed.



> -----Original Message-----
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: 30 April 2002 05:51
> To: James Users List
> Subject: Re: James stops responding after many TCP connections to SMTP
> service - DOS attack possible?
>
>
> We're using Avalon to handle connections for us.  I'll forward these
> notes on to the Avalon dev list.
> --
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
>
> Brad Wallace wrote:
> > Just a follow-up - I've determined that it takes approximately 1500-1700
> > tcp connections, one every 5 seconds, to cause this OutOfMemoryError.
> > Without these connections, my James installation is stable for days.  It
> > still looks like an easy way to take out a james server - in my case
> > this happens in about 2.2 hours, but I expect that the same effect could
> > be created by sending the connections faster.
> >
> > I'm going to have to try going back to James 1.2.1 to see if I can get
> > around this b/c it's useless in my environment with this kind of bug.
> >
> >
> > -Brad
> >
> >
> > Brad Wallace wrote:
> >
> >>Hi All - I'm running James in a load balanced environment (required by
> >>our policies...  ;-)  One side effect of this is that the load balancers
> >>establish repeated TCP connections to the SMTP service and then break
> >>them (TCP RST or FIN I expect).  They do this to verify that the service
> >>is listening and accepting inbound connections.  Right now I'm running
> >>in debug mode, so these connections are being logged - I've included
> >>samples below.
> >>
> >>Here's the problem - after james has been running for some period of
> >>time less than 1 week, I get the following on stdout:
> >>
> >>Logging Error: Unknown error writing event.
> >>java.lang.OutOfMemoryError
> >>        <<no stack trace available>>
> >>
> >>and then james stops responding.  So far I've had to restart james each
> >>time to get this fixed.  I'll admit that the frequent TCP connection
> >>setups and breakdowns are a quirk of this type of environment, but it
> >>concerns me also b/c this seems like an easy DOS (Denial of Service)
> >>attack on a james server - simply establish and break TCP connections
> >>every 5 seconds or so for a while and it will hang until someone
> >>restarts it - it's not yet clear exactly how long you have to repeat
> >>these TCP connections for, but it's somewhere in the hours - days range,
> >>but not weeks.  And every 5 seconds probably isn't frequent enough to
> >>trigger most firewall's DOS filters, so this is pretty likely to get
> >>through.
> >>
> >>I'm running:
> >>
> >>James 2.0a2 with just the SMTP listener (no pop3, nntp, remote admin,
> >>etc)
> >>java-1.3.1_02
> >>Solaris 7
> >>
> >>Thanks much for any input.
> >>
> >>-Brad
> >>
> >>Logs Excerpts:
> >>
> >>smtpserver.log:
> >>
> >>Tue Apr 23 22:02:58 GMT 2002 [INFO   ] (smtpserver): Hello Name is:
> >><local machine name>
> >>Tue Apr 23 22:02:58 GMT 2002 [DEBUG  ] (smtpserver): Max message size
> >>is: 0
> >>Tue Apr 23 22:02:58 GMT 2002 [INFO   ] (smtpserver): Connection from
> >><load balancer IP> (<load balancer IP>)
> >>Tue Apr 23 22:02:58 GMT 2002 [DEBUG  ] (smtpserver): Socket to <load
> >>balancer IP> closed remotely.
> >>java.net.SocketException: Connection reset by peer: Connection reset by
> >>peer
> >>        at java.net.SocketInputStream.socketRead(Native Method)
> >>        at java.net.SocketInputStream.read(SocketInputStream.java:90)
> >>        at
> >>java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
> >>        at
> >>java.io.BufferedInputStream.read(BufferedInputStream.java:204)
> >>        at java.io.DataInputStream.readLine(DataInputStream.java:449)
> >>        at
> >>org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHan
> dler.java:163)
> >>        at
> >>org.apache.avalon.cornerstone.blocks.connection.ConnectionRunner
> .run(Connection.java:163)
> >>Tue Apr 23 22:02:58 GMT 2002 [ERROR  ] (smtpserver): Connection timeout
> >>on socket
> >>
> >>connections.log:
> >>
> >>Tue Apr 23 22:11:34 GMT 2002 [DEBUG  ] (connections): Starting
> >>connection on Socket[addr=<load balancer IP>/<load balancer
> >>IP>,port=<source port>,localport=<james smtp port>]
> >>Tue Apr 23 22:11:34 GMT 2002 [DEBUG  ] (connections): Ending connection
> >>on Socket[addr=<load balancer IP>/<load balancer IP>,port=<source
> >>port>,localport=<james smtp port>]
> >>Tue Apr 23 22:11:36 GMT 2002 [ERROR  ] (connections): Exception
> >>accepting connection
> >>java.net.SocketException: Software caused connection abort
> >>        at java.net.PlainSocketImpl.socketAccept(Native Method)
> >>        at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:468)
> >>        at java.net.ServerSocket.implAccept(ServerSocket.java:243)
> >>        at java.net.ServerSocket.accept(ServerSocket.java:222)
> >>        at
> >>org.apache.avalon.cornerstone.blocks.connection.Connection.run(C
> onnection.java:93)
> >>        at
> >>org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execu
> te(ExecutableRunnable.java:47)
> >>        at
> >>org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerT
> hread.java:80)
> >>Tue Apr 23 22:11:38 GMT 2002 [DEBUG  ] (connections): Starting
> >>connection on Socket[addr=<load balancer IP>/<load balancer
> >>IP>,port=<source port>,localport=<james smtp port>]
> >>Tue Apr 23 22:11:38 GMT 2002 [DEBUG  ] (connections): Ending connection
> >>on Socket[addr=<load balancer IP>/<load balancer IP>,port=<source
> >>port>,localport=<james smtp port>]
> >>Tue Apr 23 22:11:40 GMT 2002 [ERROR  ] (connections): Exception
> >>accepting connection
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to